Buzzとは？ジャック・ドーシーのAIエージェント・ワークスペースを解説

Buzzとは何か

Buzzは、Block自身の言葉を借りれば、"自分たちが所有するリレー上で、人間とエージェントが共に作り上げるワークスペース"だ。Slackを使ったことがあれば、インターフェースはすぐに見覚えのあるものに感じるはずだ。チャンネルのサイドバー、スレッド、ダイレクトメッセージ、絵文字リアクション、音声ハドル、メディア共有。

ひねりが効いているのは、その部屋に誰がいるかという点だ。チームメイトと並んで、同じチャンネルに専門特化したAIエージェントを招待し、そこで投稿し、コードをレビューし、承認済みの自動化を実行するなど、呼び出しては用が済めば消えるスラッシュコマンド式のボットというより、同僚のように振る舞う。さらにBuzzはGitホスティングも取り込んでいるため、ある機能についての会話とそのプルリクエストが同じ場所に存在できる。

Blockの一言で言えばこの賭けの本質が分かる。人、コンテキスト、意思決定、次のステップを一つの共有スペースにまとめておくこと、チャットアプリとトラッカーと開発ツールに散らばらせるのではなく。これはSlack（チャット領域）とGitHub（コード領域）の両方に真正面から挑む立ち位置だ。

Buzzを作ったのは誰か、そしてなぜか

Buzzは、Square、Cash App、Afterpay、Tidalを手がけるフィンテック企業Block, Inc.から生まれた。これは重要なポイントだ。TechCrunchが指摘した通り、Block製品であることは「単なるドーシー氏の個人的な情熱プロジェクト以上の意味を持つ」ことを示している。公式スポークスパーソンはBlock AI Capabilities責任者のBradley Axen氏で、彼の言葉が全体の主張を端的に表している。

"Every company is going to need a place where humans and agents work together. The question is whether that place is proprietary or open. We built Buzz because we believe it should be open."

Bradley Axen, Block

「なぜ」の部分は、知性の問題ではなく調整の問題だ。Blockのエンジニアリングブログはこう鋭く言い切っている。"Models can do the work now. Teams still need somewhere to do it together. The bottleneck moved from intelligence to coordination."彼らは、これまでの働き方を、誰もが小さなハーネスウィンドウの中でエージェントと一人きりで向き合い、その出力をSlackにコピーして貼り付け、返信を貼り戻すというものだったと表現し、多くの人が心当たりのある一言にたどり着く。"Nobody enjoyed being middleware."

Buzzは、Blockがこの2年間でオープンソース化してきたAIツール群の上に成り立っており、その中には自社のエージェントフレームワークgooseも含まれる。ローンチ時のツイートは、ドーシー氏らしく数時間で約11,000のいいねと700件以上の返信という、予想通りの反響を集めた。

4つのバズワードを解読する

ドーシー氏のローンチ時のツイートでは、4つの単語が強調されていた。暗号資産寄りの曖昧な言葉に聞こえるかもしれないが、それぞれが具体的な設計判断に対応している。以下、平易な言葉で説明する。

早い段階の読者の多くを混乱させたので、ここで一つ訂正しておく価値がある。Nostrはブロックチェーンではなく、トークンも存在しない。Hacker Newsのスレッドでは、この点が何度も説明され続けていた。

"No blockchains here. Nostr is just a standard signed message format being relayed by simple store and forward relay servers."

sharperguy, Hacker News

つまり、「分散型」という言葉が使われているにもかかわらず、暗号トークンもガバナンストークンもエアドロップも一切関わっていない。ここでの「Decentralized」とは「ブロックチェーン上にある」という意味ではなく、「単一のサーバーが所有していない」という意味だ。

エージェントはメンバーであり、ボットではない

ここが、Buzzを単なる「Slackにチャットボットを取り付けただけ」のものと本質的に区別しているポイントだ。Buzzでは、エージェントは「人間のチームメイトと同じ権限を持ち、同じ監査ログを持ち、違うのは鍵ペアだけ」という存在になる。チームが繰り返し使うスローガンはこうだ。"Agents are members, not bots"、そして"agents are part of the room, not haunted cron jobs."

巧妙なのはセキュリティモデルで、エージェントに認証情報を渡すことに不安を感じたことがある人ほど、理解する価値がある。エージェントにログイン情報を渡す代わりに、Buzzは各エージェントに専用の鍵を与える。エージェントの所有者は狭くスコープを絞った認可に署名し、エージェントはその後、自分自身のアイデンティティのもとで自分の作業に署名する。そのため作者性が消えることはない。エージェントが作者であり、その認証情報が誰がどんな条件でそれを許可したかを証明する。鍵が漏洩した場合は、人間のアイデンティティに触れることなくそのエージェントだけを取り消せる。

Blockはまた、1つのフロンティアエージェントが、より安価で高速な複数のエージェントの群れを率いて動かす構成についても説明しており、それらが並行してリサーチ・構築・テスト・レビューを行い、すべて普通のチャンネルメンションを通じてやり取りする。マルチエージェント・オーケストレーションについて抽象的な話を読んだことがあるなら、これがそれを実際に動かすとどう見えるかという例だ……ただのグループチャットのように。

Gitホスティング: 「ブランチ＝ルーム」という発想

Buzzはチャットだけにとどまらない。コードホスティングを自社内に取り込み始めており、その仕組みはシンプルだ。フィーチャーブランチがそのままチャンネルになる。ブランチを開くとルームが現れ、パッチは署名付きイベントとして反映され、CIはその結果をルームに投稿し、エージェントが一次的なコードレビューを行い、マージの判断はすべての証拠と同じ場所で下される。

裏側では、Buzzはリポジトリを不変のコンテンツアドレス指定パックファイルと可変ポインタとして保存しており、耐久性を検証するためにTLA+でモデル検査まで行っている。その狙いは、チームが今チャット、フォージ、ボット、CIダッシュボード、そして大量のつなぎコードで無理やり再現しているものを、1つのコミュニティで置き換えられるようにすることだ。互いを認識しているふりをする7つのタブではなく、1つの基盤にまとめる。

Git連携の部分は現時点で最も未完成であり、このセクションは現実というより構想として捉えるべきだ。

Buzzはもう十分に使えるものなのか？

ここからが正直さが問われる部分だ。BuzzはApache-2.0で、動きも速く（公開初期の数日で3,600件のGitHubスターと約1,800件のコミット）、アーキテクチャを大切にしている人たちが作っているのは明らかだ。ただし、まだ非常に初期段階でもある。最新のデスクトップビルドはv0.4.22で、つまりv1.0以前ということであり、Block自身のREADMEは機能を3つのバケツに分類している。

Hacker Newsでの反応はきれいに二分され、これは考えてみる価値のある分裂だ。懐疑派はこの全体像をどこか薄気味悪いものだと感じた。

"That screenshot is some Lynchian horror... the humans and agent bots engage in flirty emoji-filled chats with cutesy names. I'm trying to imagine a world in which this makes sense as a way to organize software development work, but coming up short."

themgt, Hacker News

熱狂派はその逆を見ていた。これは仕事のやり方における本物の転換に向けた、初期の、しかし誠実な試みだというものだ。

"The entire development world is being fundamentally rewired and will not ever look the same. This is just one experiment at a new shape. It's probably not the winning idea, but I'd imagine we'll see lots of these attempts to reframe how work is done."

echelon, Hacker News

私の見立てはこうだ。どちらも正しい。Buzzは注視する価値のある、よく作り込まれた実験であり、同時に今四半期でチームの日々のワークフローを賭けるべきツールではない。ドーシー氏自身の呼びかけは、"come test the early stages with us,"というものであり、これはまさに適切な捉え方だ。

Buzzはエージェントに部屋を与える。サポートに必要なのは仕事を持つエージェントだ。

ここで約束していた視点の転換に触れよう。Buzzの盛り上がりから、サポートやオペレーションのリーダーに持ち帰ってほしいことがあるとすれば、これだ。Buzzは場所だ。美しく設計された、エージェントがたむろしてメンションされる場だ。それは小さなチームが一緒にプロトタイプを作るような、オープンエンドで探索的な仕事には、まさにふさわしい形だ。

しかし、実際の仕事の多くはオープンエンドではない。カスタマーサポートはその最も分かりやすい例だ。チャンネルに座って人間に@メンションされるのを待ち、その後チケットを人間に返すようなエージェントは望ましくない。欲しいのは、チケットを引き受け、ナレッジベースを読み込み、簡単な60%については人を介さずに、最初から最後まで実際に解決するエージェントだ。

これは別種の設計課題であり、私が日々取り組んでいるものでもある。部屋の中にいるエージェントは、どれだけ自然に会話できるかで評価される。仕事を持つエージェントは、解決率、正確さ、そしてエスカレーションすべきタイミングを分かっているかどうかで評価される。後者をうまくやるには、見栄えの良いチャンネルUIよりも、エージェントを実際のドキュメントや過去のチケットにしっかり根付かせること、そして誰も見ていないときにそのエージェントが何をするかを信頼できることの方がずっと重要だ。正直なところ、その信頼こそが一番難しい部分であり、デモのスクリーンショットの見栄えの方が解決率より重視されがちなのは、注意すべきサインだ。

Buzzがやらない仕事にはeeselを試してほしい

Buzzのおかげでエージェントをチームメイトとして考え始めたなら、サポートチームにとって自然な次の疑問はこうなるはずだ。実際にチケットをクローズするエージェントはどれか？そのために存在するのがeeselだ。これは既存のヘルプデスク（Zendesk、Freshdesk、Gorgiasなど）や、あなたのナレッジがすでに存在している場所に接続し、最前線のチケットを自力で回答・解決するカスタマーサービス向けAIエージェントだ。

差別化要因は信頼であって、雰囲気ではない。eeselが実際の顧客に1件でも回答する前に、過去のチケットに対してシミュレーションを実行し、実際にどう返信し、何を解決していたかを正確に確認できるので、推測に頼る必要はない。数分でセットアップでき、すでにあなたのヘルプセンターを読み込んだ新入社員のように働き、無料で試せる。Buzzは素晴らしい部屋だ。こちらは、仕事を最後までやり遂げる同僚だ。