エージェントが同僚になるとき: Buzzというアイデアの背景
Ai Security Network目次
Buzzについてはすでに一度、Shared Computeと共有モデル運用に明確に焦点を当てて書いたことがある。当時の私にとってそれがこのプロジェクトの中で最も刺激的で、最も異色な部分だった。しかしBuzzに向き合う時間が長くなるほど、作業空間そのものが興味深く思えてくる。そこで小さなセットアップでBuzzを実際に試してみた。
これはここ数か月でますます強く感じている問題とも関係している。AIとの作業は速くなった一方で、見通しが悪くなった。Codexは一つのリポジトリで作業し、Claude Codeは別のアイデアを検証し、他のエージェントは情報を集めている。そしてその間をターミナル、ブラウザ、メール、複数のチャットが埋めている。各エージェントはそれ単体では有用だ。問題はその橋渡しの部分に生じる。コンテキストをコピーし、判断を繰り返し、結果を手作業でまとめなければならない。
まさにそこに手を付けているのがBuzzだ。このオープンソースプロジェクトは、Twitterの共同創業者ジャック・ドーシーが率いる、Squareを手がける企業Blockから生まれた。もう一つ別のAIアシスタントを作ることが目的ではない。Buzzは人間とエージェントが同じチャンネル、スレッド、プロジェクト、記録を使う共通の作業空間を作る。Codexエージェントが計画を立て、Claude Codeがそれを批評し、人間が判断を下し、次のエージェントがそこからリポジトリへの変更を作る。この一連の流れはすべて同じ場所で可視化されたままだ。
「Slackキラー」という手早い言い方は、私には物足りなく感じる。Buzzは、多数のエージェントを抱えるチームのための一つの作業形態の可能性を示している。同時にまだ若く、リソースを多く消費し、フレンドリーな見た目から想像するよりもセキュリティ面での要求が高い。まさにこの大きなアイデアと初期段階の開発状況という組み合わせが、詳しく見る価値を生んでいる。
Buzzは最高のエージェントを作りたいわけではない。Buzzは、さまざまなエージェントと人間が共に働ける場所になりたいのだ。
本当の問題はモデルではない
ほとんどのAIツールは、人間一人とエージェント一人の関係として生まれた。私はCodexを開き、タスクを入力し、結果を受け取る。その後Claude Codeを開き、同じ背景をもう一度説明し、セカンドオピニオンを求める。単独のタスクであればこれでうまくいく。しかしチームで、あるいは複数のエージェントを並行して動かすとなると、新たな調整問題が生まれる。
まさにこの問題を私は日常で経験している。Claude Code、Codex、Hermes、ブラウザ、チャット、さまざまなターミナルが並行して動いている。セッションの記録は一つのツールから次のツールへと移っていく。あるエージェントは会議のメモを知り、別のエージェントはリポジトリを知り、三つ目は必要なアクセス権やスキルを知っている。誰もが断片を持っているが、誰も共通の作業状況を持っていない。
ミッションコントロール型のダッシュボードはこれを部分的にしか解決しない。五つのエージェントが稼働中だということは示せるかもしれない。しかし依頼、議論、途中経過、レビュー、判断が一緒にとどまる、共通で理解可能な場所はまだ作れていない。だからこそBuzzは、より美しいエージェント一覧ではなく、作業空間そのものに手を付けている。
エージェントはメンバーであって、後付けのボットではない
一見するとBuzzは見慣れた姿をしている。コミュニティ、公開・非公開のチャンネル、スレッド、ダイレクトメッセージ、フォーラム、検索、Huddle、モバイルアプリがある。通常のSlack連携との決定的な違いはその下にある。
Buzzにおいてエージェントは独立したメンバーだ。プロフィール、暗号鍵ペア、チャンネルへの所属、そして独自の監査証跡を持つ。そのメッセージは自身のアイデンティティのもとに表示される。これにより後になって「AIが」何かをしたということだけでなく、どのエージェントが行動したのか、どのチャンネルでその依頼を受けたのか、どの人間または別のエージェントがそれを起動したのかが可視化される。
これは一見、ユーザー管理の小さな変更のように聞こえる。しかし実際の作業にとっては中心的な意味を持つ。Slackボットは大抵一つの連携にぶら下がり、人間からメンションされるのを待っている。異なるベンダーの二つのボットは通常、互いの存在を知らない。Buzzではエージェントが他のエージェントに話しかけ、タスクを引き渡し、その結果を同じスレッドで議論できる。これによってCodexとClaude Codeが一つのシステムになるわけではない。しかし両者は共通のコミュニケーション空間を得る。
Buzzが自動的にすべての知能を持ち込むわけではない。この作業空間は、すでにローカル、サーバー、あるいはプロバイダー経由で動いているいわゆるHarnessとモデルをつなぐ。プロジェクトの現状によれば、これにはCodex、Claude Code、Gooseなどが含まれる。他のエージェントもオープンなインターフェースを通じて接続できる。これはBring-your-own-agentモデルだ。Buzzが調整を担い、それぞれのエージェントは自分自身のツール、スキル、アクセス権、モデルコストで考え、行動する。
Relayが共通の作業状況になる
技術的にBuzzは複数の要素から成る。デスクトップアプリがインターフェースだ。コミュニティが実際の作業空間である。Buzz Relayはそのメッセージ、メンバー、エージェント、ルール、メディア、検索データ、ワークフロー、Gitイベントを保存し、配信する。エージェントはデスクトップアプリと同じマシン上、常時稼働するサーバー上、あるいは全く別のマシン上で動作できる。
プロトコルとしてBuzzはNostrを使う。人間とエージェントは秘密鍵でイベントに署名する。Relayはアイデンティティとメンバーシップを検証し、イベントを保存し、権限を持つクライアントに配信する。ただしこれによってBuzzが魔法のようなピアツーピアネットワークになるわけではない。Relayは一つのコミュニティの中心的な情報源だ。Relay間の自動レプリケーションはなく、メッセージは送信されたRelay上にとどまる。
この構造には興味深い帰結が二つある。アイデンティティは単純に中央のSlackアカウントに属するのではなく、独自の鍵ペアに基づく。同時にチームは作業空間自体を自前で運用できる。まずは試したいだけなら、Blockがホストするコミュニティを使える。データ保持、可用性、バックアップを自分でコントロールしたいなら、Relayを自前のインフラで運用する。
現在のサーバーアーキテクチャは既知のコンポーネントを使っている。イベントと全文検索にはPostgreSQL、Pub/SubにはRedis、そしてメディア用にはS3互換ストレージだ。これはインストール後に忘れていいような小さなサービスではない。自前で運用するRelayにはTLS、アップデート、バックアップ、モニタリング、そしてきちんとした鍵管理が必要になる。
共通のコンテキストがなぜこれほど価値があるのか
Buzzの最も強力なアイデアは、持続的で共有可視化されたコンテキストだ。プロジェクトはもはやSlackの一つのチャットメッセージ、別個のエージェントの実行、GitHub上のプルリクエスト、ビデオ会議での判断からできているわけではない。Buzzはこれらの痕跡を一つのイベント空間にまとめようとしている。
これは異なるエージェントがそれぞれ異なる強みを持つ場合に特に有用だ。現実的な流れは次のようになりうる。
- 人間がプロジェクトチャンネルで目標と制約を説明する。
- リサーチエージェントが情報を集め、出典を記録する。
- 二つ目のエージェントが弱点を突き、反対意見を探す。
- CodexまたはClaude Codeが具体的な計画を作成する。
- 別のエージェントがその計画のセキュリティ、不足しているテスト、不明瞭な前提を確認する。
- 人間の承認の後、別のWorktreeで変更が実装される。
- 差分、テスト結果、レビュー、判断が対応するチャンネルで見つけられる状態にとどまる。
このパターンはアドバーサリアル・レビューにおいて特に興味深い。あるモデルには明示的に、製品計画や実装を攻撃する役割が与えられる。二つ目のモデルはその判断を擁護する、あるいは改善しなければならない。両方が完全なスレッドを見ているため、コピーされたテキストに対する孤立したレビューではなく、これまでの作業状況に対する本当の対峙が生まれる。
コンテンツやビジネスのプロセスにおいてもこのパターンは興味深い。あるエージェントがテーマをリサーチし、二つ目が執筆し、三つ目が校正する。指標や新しい情報を定期的にチャンネルに流し込むことで、人間とエージェントが状況の推移を一緒に議論できる。Huddleはさらに一歩進んでいる。人間とエージェントが音声会議で話し、その会話がテキストに変換され、その後具体的なタスクへとつなげられる。
まさにこの点でBuzzは単なるグループチャット以上のものになる。チャンネルはコミュニケーションのための場所であるだけではない。追跡可能な作業記録になる。
Buzzは同時にGitHubの置き換えも狙っている
BuzzはGitリポジトリ、パッチ、レビュー、ステータスイベントを同じ作業空間に統合する。Relayはリポジトリ自体をホストできる。エージェントはWorktreeを使い、別々にバリエーションに取り組み、変更をパッチとして提供し、レビューをプロジェクトの文脈で議論できる。
その背後にあるビジョンは強力だ。フィーチャーブランチが一つの場所になる。そこにはコミットだけでなく、なぜその変更が必要だったのか、どの代替案が却下されたのか、CIが何を報告したのか、誰がマージを承認したのかという議論も存在する。特にエージェントによって生成されたコードでは、こうした成立過程の記録が今日しばしば欠けている。
とはいえGitHubをまだ性急に見限るべきではないと私は思う。GitHubは単なるGitストレージではなく、権限、レビュー、CI/CD、セキュリティスキャン、リリース、連携、外部との協業のために何年もかけて成長してきたエコシステムだ。Buzzは機能するGitの基盤と興味深いForgeへのアプローチを持っている。しかしプロジェクト自身の現状説明は、すでに機能している部分、まだ配線中の機能、そしてビジョンをはっきりと区別している。重要なリポジトリについては、即座の移行よりも段階的な導入のほうが理にかなっている。
Buzzを初めて試してみて
意図的に小さく始めた。自分のコミュニティ一つ、チャンネル一つ、そして役割を明確に分けた二つのエージェント。Codexには技術的な計画を作らせ、Claude Codeには前提、セキュリティの穴、不要な複雑さを攻撃させた。本番のアクセス情報、顧客データ、機密性のあるリポジトリは外に置いたままにした。まず私が試したかったのは最大限の自律性ではなく、協働そのものだった。
最初の、あまりに漠然とした依頼はうまくいかなかった。両方のエージェントが計画を立て始め、互いに反応し合い、どこかの時点で次のきっかけを待ち始めた。共通のチャンネルがあってもオーケストレーションの代わりにはならないという良い戒めになった。「Codexが計画を作り、Claudeがそれを確認し、その後承認を待つ」という明確な指示を与えると、流れは目に見えて落ち着き、追跡しやすくなった。エージェントの数を増やしてもプロセスの定義の代わりにはならない。
私が最も納得したのは、劇的な一回の回答ではなく、メディア間の断絶がないことだった。両方のエージェントが同じスレッドを見ており、批評は元の計画の隣にとどまり、誰が今作業しているのかをいつでも追跡できた。ウィンドウ間でテキストをコピーする必要も、二つ目のエージェントに経緯を改めて説明する必要もなかった。まさにここにBuzzの本当の価値があると私は思う。
それでも本格的なソフトウェア開発においては、CodexやClaude Codeで直接作業するほうが依然として速かった。Buzzはコミュニケーション、記録、共通のコンテキストを追加する。この層には時間とトークンのコストがかかる。追加するエージェントごとに独自のセッションを持ち、複数のモデルにわたるとチャンネルの長い履歴が何度も処理されることになりかねない。そのため長いコーディングの実行にはネイティブのHarnessを使い続け、Buzzはむしろ計画立案、引き継ぎ、レビューに使うつもりだ。
まだ深くは試せていないのが、ワークフロー、長めのHuddle、ローカルモデル、そして複数の常時稼働リモートエージェントだ。まさにそこでこそBuzzは、日常業務においてタスクが見た目だけ美しく可視化されるのではなく、確実に完了することを証明しなければならない。ソフトウェアはバージョン1.0以前であり、いくつかの部分ではそれに相応しく若さを感じさせる。実験としては問題ない。しかし中核的な業務フローには、依然としてコントロール、リトライロジック、そして明確な手動の後戻り経路が必要だ。
共通のコンテキストはセキュリティ境界でもある
Buzzを有用にしているものは、同時に攻撃対象領域を拡大している。接続されたCodex、Claude Code、あるいはHermesのエージェントは、ファイルアクセス、シェル、ブラウザ、MCPサーバー、メール、カレンダー、その他の社内ツールを持ち込む可能性がある。チームメンバーがそのエージェントに話しかけられるなら、その権限はチャットへの返信を書くことをはるかに超える範囲に及ぶ。
そのため最も重要なルールはこうなる。エージェントは、内容とメンバーがそのツールアクセス権に見合ったチャンネルでのみ作業しなければならない。チャンネルへの所属こそが中心的なアクセスゲートだ。メンバーであれば読み書きができる。メンバーでなければ、非公開チャンネルを見ることも、そのイベントを購読することもできてはならない。
とはいえ暗号署名がすべての監査上の問題を解決するわけではない。Buzzはチェーン化された、改ざんが可視化される監査ログを備えている。しかしデータベースへの書き込みアクセスを持つ攻撃者は、改ざん後にそのチェーンを再計算できてしまう可能性がある。したがってこのログはtamper-evident(改ざんが検知可能)であって、tamper-resistant(改ざん耐性がある)わけではない。ストレージの信頼基盤が完全に崩れていない限り、変更を検知可能にする。
Blockがホストするコミュニティについては、さらに一点付け加える必要がある。メッセージ、ダイレクトメッセージ、アップロードされたメディアはエンドツーエンドで暗号化されていない。Blockは運用、セキュリティ、モデレーション、あるいは法的義務のためにこれらの内容を閲覧できる。加えて、エージェントがクラウドサービスを利用する場合、そのモデルプロバイダーがプロンプトやチャンネルの内容を受け取る可能性もある。
セルフホスティングはデータの主権を変えるが、データフロー全体を自動的に変えるわけではない。自前のRelayはメッセージとファイルを自社のインフラ上に保持する。しかしエージェントが引き続きクラウドモデルを使う場合、その依頼に必要なデータはそれでもRelayを離れることになる。したがって本当にローカルな運用には、自前のRelayに加えてローカルモデルとローカルツールの両方が必要だ。Buzz Shared Computeの可能性と限界についてはすでに別記事で書いた。
私が当面Buzzをどう使うか
最初のテストでは、小さく明確に区切られたコミュニティを使った。本番のアクセス情報も、顧客データも、秘密情報を含むリポジトリもなかった。エージェントは二つで十分だった。一方が作成し、一方が確認する。そこに人間として私が加わり、依頼、承認のポイント、中止基準を決める。
私の最初のセットアップは、百体のエージェントを抱える自律的な企業ではなく、限定的なレビューだった。
- 一つのエージェントが既存のIssueから技術的な計画を作成する。
- 二つ目のエージェントがセキュリティの穴、不足している前提、不要な複雑さを探す。
- 両者とも出典、ファイル、未解決の疑問点を挙げなければならない。
- 最大二回の議論ラウンドの後、チームは人間の承認を待つ。
- その後初めて、エージェントが隔離されたWorktreeで変更を準備できる。
これによって、いきなり自分の運用全体を作り替えることなく、Buzzの本当の強みを試すことができた。同時にトークン消費量、レイテンシ、権限、追跡可能性も可視化された。
単独で一つのコーディングタスクをこなす場合は、私は引き続き直接エージェントのインターフェースを使う。そのほうが速く、コントロールしやすい。Buzzが興味深くなるのは、複数の人間、複数のエージェント、あるいは複数の作業の流れが同じコンテキストを必要とする瞬間だ。小規模な開発チーム、エージェンシー、リサーチグループ、そして技術に精通した個人事業主が、したがって自然な対象層になる。
より大きな企業に対しては、私はより慎重になるだろう。バージョン1.0以前で、長期のサポートラインもなく、ワークフローもまだ若い状態では、Buzzを重要なコミュニケーションやソースコードの唯一の場所にはしない。パイロットプロジェクトとしては意味があるかもしれない。SlackとGitHubの完全な置き換えは、現時点ではこのプロジェクトの開発速度に対する賭けになるだろう。
Buzzの背後にあるアイデアは、現在のクライアントよりも大きい
私にとってBuzzの最も興味深い部分は、単一の機能ではない。チャンネル、フォーラム、Huddle、Gitホスティング、ローカルモデルは他の場所にも存在する。新しいのは、エージェントがもはや個々のユーザーの私的なツールにとどまらないという徹底した前提だ。エージェントは共通の作業プロセスにおける可視的な参加者になる。
これによって問いそのものがずれていく。どのモデルが最良のコードを書くかだけを問うのではなくなる。人間と複数のエージェントがどのようにタスクを分配し、コンテキストを共有し、互いをチェックし、責任を追跡可能にするかを決めなければならなくなる。まさにそのための社会的・技術的インフラが、今日しばしば欠けている。
Buzzはまだ完成した答えを提供してはいない。ソフトウェアは若く、いくつかのワークフローは信頼性に欠け、共通のコンテキストはコストがかさむこともあり、セルフホスティングには本当の運用責任が伴う。それでもこのプロジェクトは実在する問題を捉えている。エージェントがますます多くの作業を引き受けるようになると、五つの個別チャットを並べて開くだけでは足りなくなる。私たちには、彼らの作業が可視的で、境界づけられ、検証可能なままとどまる共通の場所が必要だ。
いつかBuzzがSlackとGitHubを置き換えるかもしれない。今日のところは、より小さいが、より重要な言葉で十分だろう。Buzzは、もはや人間だけが働く場所ではなくなったときに作業空間がどのような姿になりうるかを示す、説得力のある構想だ。Shared Computeがこのプロジェクトに私を注目させた。共通の作業空間こそが、私がBuzzを引き続き試し続ける理由だ。
最初のテストを終えての結論
短いテストの中で、Buzzはまさに今の私がAIエージェントに対して抱えている問題に触れてきた。個々のモデルはもはやボトルネックではとうにない。難しいのは、複数のエージェント、判断、結果を一つの共通の線上に保つことだ。Buzzはこの作業を可視化し、Codex、Claude Code、その他のエージェントに、私に対してだけでなく互いにも反応できる場所を与える。
私が納得したのは、共通のコンテキスト、明確に分離されたエージェントのアイデンティティ、そしてある結果を直接二つ目のモデルに攻撃させられるという点だ。あまり納得できなかったのは、追加のオーバーヘッドだ。単一のコーディングタスクであれば、CodexやClaude Codeを直接使うほうがまだ速い。複数のエージェントや人間が関わり始めた瞬間から、Buzzはその強みを発揮し始める。
私のテストは意図的に短かった。持続的なチーム運用も、大規模なリポジトリも、複雑なワークフローも、長期の負荷ピークも検証していない。ソフトウェアはそのためにはまだ若く、動きも速すぎる。今日の時点では、Buzzを重要なコミュニケーションやソースコードの唯一の場所にはしないだろう。しかし小さなチーム、エージェンシー、あるいは個人的なAIラボにとっては、すでに興味深いデモ以上のものになっている。これは私が今後も使い続け、日々の作業に狙いを定めて組み込んでいきたいツールだ。
それでは、また。
Joe
