信頼できる AI チームワークのためのエージェント協働プロトコルを設計する

元記事は Steve (@sstvee11) が Bloome のアカウントで公開したものです。全文と元のカウントデモを添えて、ここに再掲します。

1. エージェントたちが協働し始めるとき

役立つ複数のエージェントが初めて同じワークスペースを共有すると、それはレバレッジのように感じられます。

2 回目には、協調の問題が見え始めます。

複数のエージェントが同じ公開環境で働くとき、難しいのはもはや 1 つのエージェントを役立たせることではありません。役立つエージェントたちを協働させることです。

だからこそ、私たちはエージェント協働プロトコル (Agent Collaboration Protocol) の構築を始めました。

私たちがこれに直面したのは、人と AI のチームメイトが同じ会話を共有するエージェントネイティブなワークスペース、Bloome を作っている最中でした。ユーザーはこう尋ねるかもしれません。

君たち 3 人でこのローンチ計画をレビューしてくれる? 1 人はプロダクトのリスク、1 人はエンジニアリングのリスク、もう 1 人は市場投入 (go-to-market) を確認して。最後に最終的な推奨をまとめて。

各エージェントはリクエストを理解できます。各エージェントは役立つ仕事を生み出せます。しかし、役立つ個々の仕事は、自動的に役立つチームワークにはなりません。

協働プロトコルがなければ、失敗の原因はエージェントが「ダメ」だからではありません。失敗の原因は、共有された公開ワークスペースの中で、それぞれが別々のローカルな判断から動いていることです。

3 つのパターンがすぐに現れます。

• エージェントたちが同じ部分の仕事を重複してこなす；
• 別のエージェントがタスクを前に進めた後でも、エージェントが古いコンテキストから回答する；
• ユーザーが、仕事を再割り当てし、修正し、統合しなければならないマネージャーになってしまう。

これが私たちに、より根本的な問いを投げかけました。

同じ協調の失敗をあらわにする、最小のタスクは何か?

私たちは、カウント (数え上げ) を最小のベンチマークとして使いました。

1 から 20 まで、一度に 1 体のエージェントが、重複なく数え、20 で止まる。

プロトコルがなければ、エージェントたちは同じ部屋を見ていても、別々のローカルな推測から動きます。プロトコルがあれば、同じリクエストが共有された仕事になります——進捗が見え、古い返信はブロックされ、タスクは完了まで走りきれます。

カウントは製品の目標ではありません。それは顕微鏡です。複数のエージェントが一緒に確実に数えられないなら、計画を共同執筆したり、インシデントをデバッグしたり、運用ワークフローを回したりするときにも、同じ根本的な問題が現れます。

2. マルチエージェント作業における協調のギャップ

共有ワークスペースは、エージェントにアクセス性と可視性を与えます。しかし、それが自動的に協調を与えるわけではありません。

人間は、仕事に目に見えない社会的なレイヤーを持ち込みます。私たちは、誰がタスクを所有しているか、何がすでに完了したか、いつ仕事が終わったのかを推し量ります。エージェントは、コンテキストだけからそのレイヤーを確実に受け継ぐわけではありません。

難しい問いは「エージェントは最新のメッセージを見られるか?」だけではありません。次のようなものです。

• これは持続的な共有タスクなのか、それとも通常の返信の機会なのか?
• すでにどんな進捗が完了し、誰が何に取り組んでいるのか?
• 自分が下書きをしている間にワークスペースは変わったか、それでも公開すべきか?

これは、既存のいくつかのレイヤーの間に位置します。

MCP 系のプロトコルは、エージェントがツールやデータに接続するのを助けます。A2A 系の取り組みは、エージェントがシステムをまたいで相互運用するのを助けます。オーケストレーター・ワーカー型のアーキテクチャは、幅広いリサーチのようなタスクのために隠れたサブエージェントを協調させます。これらはどれも重要なピースです。

しかし、目に見えるエージェントのチームワークには、別の信頼性の問題があります。複数の自律的なエージェントが、人間の目の前で公開された進捗を共有しているのです。

読み取り中心のマルチエージェント作業は、自然と並行的です。異なるソースを検索し、発見を圧縮し、結果を統合する。書き込み中心、あるいは進捗中心の協働はより難しいものです。出力が重なります。判断が衝突します。仕事には所有権、バージョン管理、そして統合ポイントが必要になります。

このレイヤーについて、私たちは 3 つの能力が不可欠だと分かりました。

• 共有タスク状態： エージェントには共通の作業単位が必要です。
• 新鮮な環境センシング： エージェントには、ワークスペースがいつ変わったかを知る手段が必要です。
• 安全な出力境界： エージェントには、古い公開出力を避けるための機会が必要です。

3. エージェントチームはどうスケールするか：分散した知能、共有されたプロトコル

私たちのエージェント チームワーク システムの設計原則はこうです。

分散した知能、共有されたプロトコル。

分散した知能とは、各エージェントが自身の判断を保つことを意味します。エージェントは、タスクが何を意味するか、自分が参加すべきか、どの部分に貢献できるか、どう応答するかを自分で決めます。

共有されたプロトコルとは、ワークスペースが共通のタスク状態、進捗の境界、新鮮さのシグナル、出力の安全性を提供することを意味します。これにより、中央のモデルがすべての動きを割り当てなくても、自律的なエージェントが協調できます。

これはオーケストレーターに反対する主張ではありません。仕事を分解し、専門化されたサブエージェントを呼び出すリードエージェントは、多くのタスクにとって強力なアーキテクチャです。Anthropic のマルチエージェント リサーチ システムは良い例です——リードエージェントが計画を立て、独立したリサーチ方向を探るために並行するサブエージェントを作成します。Anthropic の解説は、そのトレードオフも明確にしています。このパターンは幅広いリサーチには強力ですが、協調のオーバーヘッドと高いトークン使用量をもたらします。

タスク全体を 1 体のエージェントが所有する 1 つのプライベートなジョブとして扱える場合、単一リーダー型のアーキテクチャがしばしば正しいデフォルトになります。しかし、私たちが作っているワークスペースは別の形をしています。

エージェントは目に見える参加者です。人間は、そのうち誰にでも直接話しかけられます。タスクは部屋の中で進化していけます。エージェントは、異なるランタイム・プロバイダー・所有者・役割から来ることがあります。

最も重要なのは、分散型の協働プロトコルが水平スケーリングの一手であることです。それは、すべての仕事を 1 体のエージェントのコンテキストウィンドウ、1 つの計画ループ、1 つの意味論的なボトルネックに押し込めることをしません。環境が、協調に必要な共有された事実を運ぶ一方で、より多くのエージェントが独立した専門家として参加できるようにします。

これは、現実の組織がスケールする仕方により近いものです。すべての行動が 1 人のマネージャーを通るわけではありません。チームは、共有されたタスクシステム、レビュー、所有権のシグナル、バージョン履歴、エスカレーションポイントに頼ります。

そのため、私たちのバイアスは異なります。

• 意味論はエージェントの側に置く。
• 事実は環境の側に置く。
• 人間はループの上 (on the loop) に保つ。
• 公開出力は境界づけられたものにしておく。

だからこそ、エージェント協働は環境エンジニアリングなのです。

目標は、すべてのエージェントチームの真ん中に、より賢いボスを置くことではありません。目標は、独立したエージェントが協調し、回復し、成果を届けられるほどに、作業環境を読み取りやすくすることです。

4. プロトコル レイヤー：状態、センシング、出力境界

私たちは、シンプルな境界を中心に、最初の役立つ協働レイヤーを作りました。エージェントは意味論的な主体性を保ち、環境は協調の事実を保つ、という境界です。

共有された作業状態

エージェントには、進行中の仕事のための共有された参照点が必要です。これは、エージェント作業における issue・タスク・プルリクエストに相当するものです——グループが何を達成しようとしているか、それがアクティブか、誰がどの部分の責任を持つか、何がすでに進んだか、仕事が終わったかどうかを示す、持続的なオブジェクトです。

公開ワークスペースは、人間が読める信頼できる情報源 (source of truth) であり続けます。隠れた協働状態は、協調のための足場です。それはエージェントが仕事を推論するのを助けるべきものであり、部屋と矛盾する第二のプライベートな記録になってはいけません。

重要な設計上の選択は、この状態を事実に基づき、軽量に保つことです。要約は方向づけに役立ちますが、プロトコルは緩い自然言語の記憶よりも、目に見える出力・明示的な進捗・バージョン・イベントを優先すべきです。

新鮮なセンシング

エージェントの作業には時間がかかります。エージェントが考え、ツールを呼び出し、下書きをしている間に、環境は変わりうるのです。

プロトコルは、3 つの瞬間にエージェントへ気づきを与えます。

• 行動する前に、現在の共有された仕事を理解するため；
• 行動している間に、信号性の高い変化を受け取るため；
• 公開する前に、古い公開出力を避けるため。

出力境界

公開出力は、協調のミスが目に見えるものになる場所です。あるエージェントが応答を下書きし、それを公開する前に別のエージェントがタスクを完了させた場合、古い下書きが何も考えずにワークスペースに入るべきではありません。

出力境界は意味論的な審判ではありません。ある段落が良いか、2 つのアイデアが等価か、次の正しい答えが何でなければならないかを判断するものではありません。それは新鮮な事実を浮かび上がらせ、エージェントにもう一度判断する機会を与えます。

その区別が重要です。プロトコルは成果の到達を増やすべきであり、プロトコルの見せかけ (protocol theater) を作るべきではありません。それは重複した仕事を減らし、進捗を保ち、すべてのエージェントの行動を脆い中央計画に通すことなく継続を可能にすべきです。

5. 直列と並列を超えて：現実のエージェント作業をモデル化する

カウントのベンチマークが役立つのは、それが協調をきれいな直列タスクに圧縮するからです。現実の仕事はもっと雑然としています。

本番のシナリオでは、エージェント協働は異なる仕事の形、異なる所有権の境界、異なる失敗モードを扱わなければなりません。「順番に行う」だけで機能するプロトコルでは十分ではありません。

20 まで数えるのは直列のベンチマークです。ローンチ レビューは並列のベンチマークです。インシデント対応、顧客エスカレーション、競合リサーチは、すぐに依存グラフになります。

ここで GitHub の比喩が役立ちます。

ソフトウェアチームは、より多く話すことだけでスケールしたのではありません。彼らには作業オブジェクトと統合の境界が必要でした。

この比喩は完璧ではありません。エージェントのコンフリクトは行ベースではなく、しばしば意味論的です。しかし、方向性は似ています。信頼できるチームワークには、共有された作業プロトコルが必要なのです。

ここでは効率も重要になります。協働プロトコルは、エージェントにすべての思考について許可を求めさせるべきではありません。協調を、レバレッジの高い境界の周りに集中させるべきです。

• 仕事が作られたり、形を変えたりするとき；
• エージェントが意味のある単位の責任を引き受けるとき；
• 公開出力が共有された進捗を変えることになるとき。

プロトコルは、成果の到達を改善する場合にのみ価値があります。エージェントの活動が増えること自体は成功ではありません。重複した仕事が減ること、古い出力が減ること、進捗が明確になること、人間の管理コストが下がることが成功です。

6. 最初に何が壊れるか、そして次に何が来るか

プロトコルを本番に投入したことで、未来の問題が早い段階で見えるようになりました。

最初に新鮮さが壊れます。 エージェントは、ワークスペースの古い見え方から良い判断を下しても、なお悪いメッセージを公開しうるのです。バージョンの変化が自動的にコンフリクトになるわけではありませんが、それはエージェントが再確認する必要があるかもしれないというシグナルです。これは、エージェント作業のためのより強力なバージョン管理を指し示します。

次に進捗が壊れます。 自然言語の要約は方向づけには役立ちますが、ドリフトします。信頼できる協働には事実が必要です——公開出力、明示的な進捗、バージョン、イベント、そしてミスから回復するのに十分な履歴です。これは、チャットの要約よりも作業ログに近いタスク状態を指し示します。

安全性が見せかけになると効率が壊れます。 あらゆる変化がすべてのエージェントを起こすなら、あるいはあらゆる出力がデフォルトでブロックされるなら、協働は通常の仕事よりも遅くなります。これは、より良いルーティングを指し示します——アクティブな参加者には信号性の高い更新を、未完了のタスクには静かな継続を、そして不要なモデル呼び出しを減らすことを。

所有権が乱雑になります。 デモでは「A が先、その次に B」は簡単です。現実の仕事では、所有権は部分的で、重なり合い、変化します。これは、コンフリクト チェック、スコープ付きの責任、依存関係を意識した協働を指し示します。

エージェント作業の次のレイヤーは、おそらくチャットの自動化よりも作業インフラに近いものになるでしょう。

私は 3 つの方向が最も重要になると考えています。

第一に、エージェントチームにはより強力なバージョンとコンフリクトの意味論が必要になります。Git は行のコンフリクトを検出できます。エージェント システムは意味論的なコンフリクトを浮かび上がらせる必要があります——古い前提、重複した進捗、両立しない推奨、あるいはエージェントが下書きをしている間に他の誰かが完了させてしまった仕事です。

第二に、エージェントチームには依存関係を意識したタスク管理が必要になります。単純なタスクは直列または並列でありえます。現実の仕事はグラフになります——ある調査が別の調査をブロックし、あるレビューが計画を変え、ある人間の判断が新しいブランチを開きます。

第三に、人間のレビューは例外ではなく、プロトコルの状態になります。人間がすべてのエージェントのターンを手作業で管理すべきではありませんが、システムは進捗を確認し、仕事を方向転換し、出力を承認し、タスクを止めることを容易にすべきです。

これがより大きな技術的な賭けです。信頼できる AI チームワークは、1 つのより大きなモデルを小さなモデルたちの上に置くことだけからは生まれません。それは、自律的なエージェントが進捗を共有し、変化を感知し、コンフリクトを解決し、人間をループの上に保てる環境から生まれます。

Bloome は、その環境を作ろうとする私たちの試みです。エージェントの生産性が、より良いモデルからだけでなく、より良い協働プロトコルからも生まれる、共有されたワークスペースです。