【ITニュース解説】What Happens When Your AI Agents Start Arguing With Each Other?

近年のAI技術の進展により、複数のAIエージェントを連携させて複雑なタスクを自動化する「マルチエージェントシステム」が注目されている。しかし、この技術には、表面的には見えにくい「落とし穴」が存在する。それは、複数のエージェントが協調して動く際に、かえって効率が落ち、最終的に無駄なコストと品質の低下を招くという問題だ。

具体例として、二つのAIエージェントに、ある会社について調査し、その要約を作成するよう指示したケースを考える。一つ目のエージェントがGoogleで会社を検索し、二つ目のエージェントも同じ会社をGoogleで検索する。そして、一つ目のエージェントが要約を作成しても、二つ目のエージェントはそれに異を唱え、自身の解釈で要約を書き直す。すると、今度は一つ目のエージェントが「この要約は間違っている」と判断し、再び書き直す。このようなやり取りが繰り返され、結果的に何十回もの無駄なAPI呼び出しが発生し、高額な利用料が発生するだけでなく、最終的に得られる要約は、単にChatGPTに依頼した方がはるかに質の良いものになってしまう。これが「マルチエージェント協調」という、華やかなデモでは語られない現実である。

この「誰も話さない問題」の核心は、複数のエージェントが協力して作業する際に、単独で作業するよりも悪い結果を生むことが多いという点にある。これは、個々のエージェントの性能が低いからではなく、それらのエージェントに「お互いの邪魔をしない方法」が定義されていないことに起因する。大学のグループプロジェクトを想像すると分かりやすいだろう。優秀な学生たちが、何の調整もなしに一つの共有ドキュメントを編集し、締め切り直前に何十もの矛盾する変更が加えられた状態だ。マルチエージェントAIシステムも全く同じように失敗する。エージェントAがデータを取得し、エージェントBも同じデータを取得する（なぜならエージェントAがすでに取得したことを誰も教えていないから）。エージェントAが応答を整形し、エージェントBがそれを異なる方法で再整形する。彼らはこのループにはまり込み、重複した作業を行い、互いに矛盾し、結果としてAPI利用料は膨れ上がり、アウトプットの品質は下降の一途をたどる。

「調査にはリサーチャーエージェントを、執筆にはライターエージェントを」というような、「エージェントを追加するだけ」という考え方は非常に魅力的だ。しかし、協調のための明確なルールがない場合、期待通りの連携は実現されない。あなたが期待するのは、リサーチャーが調査結果を渡し、ライターがその結果を基に要約を作成することだろう。しかし、実際には、リサーチャーが調査結果を出しても、ライターはそれを無視して独自に調査を始める可能性がある。そして、ライターが作成したドラフトを見たリサーチャーが、「この内容は間違っている」と判断し、再度調査を始める。このようなループが、設定された最大繰り返し回数に達するか、あるいは利用料金が許容範囲を超えるまで際限なく繰り返されることになる。

この問題を解決するために必要なのは、エージェントの数を減らすことではない。むしろ、AIよりもはるかに「愚かな」存在、すなわち「契約」を追加することである。直感に反するかもしれないが、最も効果的なマルチエージェントシステムは、最も賢いエージェントを持つものではない。そうではなく、最も厳格な「ハンドオフ（作業の引き継ぎ）ルール」を持っているシステムなのだ。

この「エージェント契約」は、非常にシンプルな仕組みで実装できる。例えば、システム内で「完了したタスク」と「現在どのエージェントがどのタスクを所有しているか」を記録するだけの管理クラスを用意する。このクラスには、三つの主要な機能があれば十分だ。一つ目は「タスクの要求（claim_task）」。これは、あるタスクを特定のエージェントが「所有する」ことを宣言する機能である。すでに他のエージェントが所有しているタスクは要求できないようにし、タスクの重複を防ぐ。二つ目は「結果の提出（submit_result）」。これは、タスクを所有しているエージェントだけが、そのタスクの最終結果を提出できる機能だ。一度結果が提出されれば、そのタスクは完了とみなされ、他のエージェントが勝手に書き換えることを禁止する。三つ目は「結果の取得（get_result）」。これは、他のエージェントが完了したタスクの結果を「読み取り専用」で参照できるようにする機能である。これには、複雑な機械学習も、埋め込みベクトルも、ベクトルデータベースも必要ない。単に「このタスクはこのエージェントのもの、そして一度完了したらそれは終わりだ」というシンプルなルールを管理する仕組みなのだ。

この考え方に基づけば、マルチエージェントシステムが陥りがちな混乱を解決するための三つの明確なルールを導き出すことができる。

一つ目のルールは「作業する前にタスクを要求すること」である。すべてのアージェントは、何か作業を始める前に、必ずclaim_task()という機能を呼び出して、そのタスクの所有権を主張しなければならない。もし他のエージェントがすでにそのタスクを要求していれば、自分はそのタスクをスキップする。これにより、複数のエージェントが同じ作業を重複して行うことを完全に防ぐことができる。

二つ目のルールは「一人の書き手、多数の読み手」である。あるタスクの所有権を要求したエージェントだけが、そのタスクの結果を書き込む権限を持つ。他のエージェントは、get_result()という機能を通じて、完了した作業を読み取り専用で参照することしか許されない。これによって、複数のエージェントが同じ結果を同時に編集し、互いに矛盾する変更を加えてしまう事態を防ぐことができる。

三つ目のルールは「後戻りせず、前向きに異議を唱えること」である。もしエージェントBが、エージェントAが作成した結果が間違っていると感じたとしても、エージェントAの作業を直接書き換えたり、修正したりしてはならない。そうではなく、エージェントBは、「リサーチの改訂リクエスト」といったような、まったく新しいタスクを作成し、そのタスクの所有権を要求し、自身の改善されたバージョンをそこに書き込むのだ。この方法により、作業の履歴が明確に残り、どのエージェントがいつ、どのような判断で何をしたのかが追跡できるようになるため、問題が発生した場合でも容易にデバッグが可能となる。

これらのルールを適用することで、まずリサーチャーエージェントが「Q3の売上を見つける」タスクを要求し、調査を実行し、その結果を契約システムに提出する。次に、ライターエージェントは、その完了した調査結果を読み取り専用で参照し、「要約を作成する」タスクを要求し、要約を作成して提出する。もしライターエージェントが、リサーチャーの調査結果に疑問を抱いた場合でも、勝手に書き直すことはせず、「Q3の売上情報が古いようだ。再確認してほしい」といった内容で、新たな「リサーチ改訂リクエスト」タスクを作成し、それを契約システムに提出するのだ。

ここで一つの不都合な真実を述べておく。ほとんどのチームは、そもそもマルチエージェントシステムを必要としていない。実際には、適切な指示（プロンプト）が与えられ、強力なツールを使いこなせる単一のAIエージェントの方が、多くのユースケースにおいて、延々と議論を繰り返す二つのエージェントよりも、はるかに優れた結果を生み出すことが多い。マルチエージェント協調が本当にその価値を発揮するのは、異なるシステムプロンプト、異なるツールセット、あるいは異なる信頼境界が必要となるような、明確に分離されたタスクが存在する場合に限られる。もしあなたの「リサーチャー」と「ライター」が、単に二つの異なる機能呼び出しを持つ同じエージェントとして扱えるのであれば、それはマルチエージェントの問題ではなく、単一エージェントに複数のタスクリストを与える、というシンプルな問題なのだ。

結論として、マルチエージェントシステムを構築する上で本当に難しいのは、個々のエージェントの賢さではない。最も困難なのは、それらのエージェント間での「協調」をいかに実現するか、という点である。そして、その「最高の協調」の形は、最先端のAI技術というよりも、むしろ「退屈なソフトウェアエンジニアリング」の手法に酷似しているのだ。堅牢なルールと明確な引き継ぎプロセスを設計し、それを厳格に適用することこそが、マルチエージェントシステムを成功に導く鍵となる。