【ITニュース解説】My AI agents don't talk to each other

この記事は、複数のAIエージェントを連携させて複雑なタスクを処理する際に直面する問題と、その解決策について解説している。多くの人が最初に考えるのは、エージェント同士が会話を通じて協力し、共通の会話記録に情報を追加していく「グループチャット型」のシステムだ。しかし、この設計は実際の運用では様々な課題に直面し、うまく機能しなかったという。

グループチャット型の設計で問題となった点は主に三つある。一つ目は「文脈（コンテキスト）の肥大化」だ。エージェントが互いに会話する場合、それぞれのエージェントは、他のエージェントが過去に発言したすべての情報を自分の記憶として参照する必要がある。エージェントの数が増えれば増えるほど、それぞれのエージェントが処理しなければならない情報量は劇的に増加し、システム全体のパフォーマンスが低下したり、運用コストが増えたりする。まるで、たくさんの人が同時に話す会議で、全員の発言を完璧に理解し続けなければならないようなものだ。

二つ目の問題は「誤情報の伝播」である。もしあるエージェントが誤った情報を自信満々に主張した場合、他のエージェントはその情報を疑うことなく「正しい前提」として受け入れてしまう。この誤りが連鎖的に伝わっていくと、最終的には完全に誤った結論が、あたかも論理的に導き出されたかのように見えてしまう。どこで誤りが生じたのか、後から追跡することも非常に難しい。

三つ目は「意思決定プロセスの不透明性」だ。システムが特定の結論に達した理由を問われた場合、正直な答えは「エージェント間で会話があったから」という曖昧なものになってしまう。これでは、なぜそのような結論になったのかを明確に説明できず、システムの動作を改善したり、監査に耐えたりすることができない。

これらの問題を解決するために、著者はエージェントの役割を根本的に見直した。それは、エージェントを「他のエージェントを呼び出す機能」としてではなく、「特定の領域に関する主張をする著者」として捉える、という考え方だ。

この新しい設計では、エージェント同士は直接会話しない。代わりに、すべてのエージェントが「共有の記録」と呼ばれる一つのデータベースのような場所に、自分の主張を書き込む。各エージェントは、それぞれが担当する「管轄領域」を持っており、その領域内でしか主張できない。例えば、「検証」エージェントは「何が真実か」についてのみ主張し、「設計」エージェントは「どうあるべきか」についてのみ主張するといった具合だ。これは、エージェントができること（例えば、ドキュメントを読んだりモデルを呼び出したりすること）ではなく、エージェントがどの情報について責任を持つか、という「管轄」の区別である。

エージェントの出力は、構造化された「行データ」として共有記録に保存される。このデータには、主張の内容（例：屋根の形状が切妻である）、その主張をしたエージェント（著者）、証拠の種類（例：実測値に基づく）、そして関連するコードなどが含まれる。このようにデータ形式が統一されているため、他のエージェントが情報を読み取る際に曖昧さが生じない。

エージェント間で意見の不一致が生じることも頻繁にあるが、その場合もエージェント同士が議論することはない。共有記録が、明確なルールに基づいて不一致を解決する役割を果たす。この解決ルールにはいくつかの原則がある。まず、権限はエージェント全体に与えられるのではなく、特定の「領域」にスコープされる。例えば、「検証」エージェントは実測値に関しては最も権限を持つが、資金調達に関する主張では権限を持たない。次に、情報の「証拠のグレード」が重視される。実測値（MEASURED）に基づく主張は、言及された情報（STATED）、既存の記録（RECORD）、モデルによる予測値（MODELED）よりも高い優先順位を持つ。つまり、たとえ権限の高いエージェントの主張であっても、その根拠となる証拠が弱ければ、権限の低いエージェントの、より強い証拠に基づいた主張には勝てないのだ。本当に解決できない不一致は「競合」として明確に表面化され、隠蔽されることなく、人間による介入や判断を促すことになる。この仕組みにより、意見の食い違いは「データの問題」として扱われ、解決された後も元の主張は削除されず「格下げ」されるため、履歴として確認できる。この設計のおかげで、新しいエージェントを追加しても、他のエージェントが処理すべき情報量（コンテキスト）が劇的に増えることはなく、システム全体の調整コストを一定に保つことができる。

さらに重要な点として、エージェントの定義を「固定化」することが挙げられる。エージェントが特定の領域で主張し、その主張に権限が伴う場合、そのエージェントの「身元」は非常に重要になる。もし、ある情報が「検証」エージェントによって主張されたと偽装された場合、その情報は不当に高い権限を持って扱われてしまう可能性がある。そのため、各エージェントの定義（その身元と権限）は、セキュリティ上の境界として厳密に管理され、変更されないように固定される。これにより、誤った情報や不正な情報がシステムに混入することを防ぐ。

この新しい設計には利点だけでなく、いくつかのトレードオフも存在する。一つは「創発的行動の喪失」だ。エージェント同士が自由に会話するシステムでは、時には予期せぬ協力や、人間には思いつかないような独創的な解決策が生まれることがある。しかし、厳格に定義された「著者」モデルでは、そのような予測不能な創造性は期待できない。その代わりに、システムがなぜ特定の結論に至ったのか、そのプロセスを明確に説明できるという「説明可能性」と信頼性を手に入れることができる。これは、何を重視するかという重要な判断である。

二つ目のコストは、「人間による初期設計の必要性」だ。各エージェントがどの「管轄領域」を担当し、どの情報について権限を持つかを決めるのは、人間の専門知識が不可欠な設計作業である。システムが扱う問題領域を深く理解していなければ、この領域分けを適切に行うことはできない。

三つ目に、「データ読み取りの複雑化」が挙げられる。競合する複数の主張の中から、定義されたルールに基づいて正しい情報を解決して読み取る処理は、単にデータベースからデータを読み出すよりも手間がかかる。そのため、頻繁に参照されるデータについては、キャッシュのような仕組みを導入するなど、システム設計上の工夫が必要になる場合がある。

この記事の著者は、自身の建設技術会社ML Systemsでこのエージェントシステムを実際に運用している。7つのAIエージェントと一人の人間レビュアーが、各住宅に関する情報を共有記録に書き込み、読み込んでいる。特に、建設現場では壁の中の情報など、複数の情報源が必ずしも一致しないことが多いため、このような明確な不一致解決の仕組みが非常に有効に機能しているという。このシステムはすでに製品として展開されており、エージェント層と共有記録の仕組みは実用性が証明されている。