【ITニュース解説】Single Agent vs Multi-Agent: 11 AI Agents, $50 and Zero Lines of Code

AIエージェントとは、人間が話すような自然な言葉を理解し、生成する「言語モデル」というプログラムを利用して、まるで人間のようにタスクをこなす自律的なプログラムのことだ。これらのエージェントは、ファイルを読み込んだり、コンピューターのコマンドを実行したり、コードを編集したりといった作業を繰り返し行い、与えられた仕事を完了させる。AIエージェントには、単独で全ての作業を行う「シングルエージェント」と、複数のエージェントが連携して作業を分担する「マルチエージェント」という二つの主なタイプがある。

最近行われたある実験では、プログラミングタスクをAIエージェントに与え、そのパフォーマンスがどのように変わるかが検証された。このタスクは、休暇レンタル予約プラットフォームのサーバー側（バックエンド）を構築するというもので、七つの小さな独立したプログラム（マイクロサービス）から構成される。実験では、同じ言語モデルを使用し、4種類の異なるエージェント構成が試された。全ての構成で同じタスクが与えられ、パイプライン型には50ドルの予算が設定された。

最も優れた結果を出したのはシングルエージェントだった。一つのエージェントが最初から最後まで全ての作業を一人でこなし、28点満点中28点という最高スコアを達成した。これは、タスクがエージェントが一度に扱える情報量（コンテキスト）の範囲内に収まれば、単独のエージェントが非常に効率的であることを示している。

一方、マルチエージェント構成は苦戦した。まず、「階層型」という構成では、統括するエージェントが専門のエージェントに仕事を割り振る形を取ったが、結局統括エージェント自身がほとんどのコーディングを行うことになり、スコアは18点に留まった。これは、エージェントごとに作業ステップ数に上限があったり、一度に記憶できる情報量（コンテキスト）が限られていたことが原因である。まるで、小さな作業台で全ての作業をこなさなければならないような状況だ。

次に、「スウォーム（群れ）型」という構成では、8つのエージェントがリーダーなしで、共有ファイル上で同時に作業を進めた。しかし、結果は9点と低迷した。この構成では、それぞれのサービスがデータをやり取りする境界部分で問題が発生した。例えば、一部のエージェントが「customer_name」のようにアンダースコアで単語をつなぐ命名規則（snake_case）を使用し、別の一部が「customerName」のように大文字小文字を使い分ける命名規則（camelCase）を使ったため、サービス同士が互いに情報を理解できなくなってしまった。これは、複数のエージェントが並行して作業する際に、明確なルールや契約がなければ、整合性のない結果が生じることを示している。

最も衝撃的だったのは「パイプライン型」の構成である。この構成では、11の専門エージェントが診断、分解、アーキテクチャ設計、実行、テスト、検証、レビューといった段階に沿って順番に作業を進める。しかし、50ドルの予算はコードを一行も書く前の計画段階で全て使い果たされ、最終的なコードの出力はゼロ行で、スコアは0点だった。この結果は、「計画」という目に見える活動が盛んに行われたとしても、それが必ずしも具体的な成果につながるとは限らないことを如実に示している。シングルエージェントが最高スコアを達成したのとほぼ同額のコストで、パイプライン型は計画だけで予算を使い切ってしまったのだ。

これらのマルチエージェント構成が失敗した背景にはいくつかのメカニズムが考えられる。一つは「調整コスト」だ。複数のエージェントが互いに合意するためには、それぞれが連絡を取り合う必要がある。エージェントの数が増えるにつれて、必要な連絡経路の数は指数関数的に増大し、調整にかかる労力は莫大になる。また、パイプライン型では、各エージェントが前のエージェントの作業の「要約」しか受け取らないため、途中で失われた情報が二度と戻らないという問題も指摘されている。さらに、レビュー段階で主観的な意見による却下が発生したり、厳格な形式で書かれた「契約」が自己目的化してしまい、その作成だけで予算を使い果たすケースもあった。これは、エージェント間の協調作業がいかに難しいかを示している。

ただし、これらの実験結果は、マルチエージェントが常に劣っているというわけではない。このニュース記事の筆者は、自身の経験から異なる見解を示している。筆者は過去に26のAIエージェントを使って、自身のウェブサイトのセキュリティ監査を行った。この監査では、コードの各部分を並行して「読む」役割のエージェントが11体、それらのレポートを結合するエージェントが2体、セキュリティ、パフォーマンス、アーキテクチャなどの項目を個別に評価するエージェントが12体、そして厳格な評価を行う最終ジャッジエージェントが1体という構成だった。結果として、実際にコード内に潜んでいた「コードインジェクション」という重大なセキュリティ脆弱性（プログラムの実行コードとして不正な値が埋め込まれ実行されてしまう脆弱性）を発見することに成功したのだ。

筆者の監査と実験のパイプライン型の違いは、「何を生成するか」にある。筆者の監査では、各エージェントはコードの独立した部分を読み、その発見事項は個別にコードで検証された。つまり、各エージェントの出力が完璧に同期している必要はなく、最終的に人間がコードで確認できた。一方で、実験のパイプライン型は「何かを構築する」ことを目指しており、各エージェントの出力が次のエージェントの入力となり、全てが最終的に一つの動作するシステムとして統合される必要があった。ここから筆者は、「並列に働くエージェントは、それぞれの発見がコードで個別に検証できる場合に、独立した部分を『読む』作業に有効だ。しかし、何かを『構築する』ために調整を必要とするエージェントの連鎖は、準備段階で燃え尽きてしまう」という教訓を導き出している。

このことは、AIを使うと開発者が感じる「速さ」と実際の作業速度との間にギャップがあるという別の調査結果とも関連している。ある調査では、経験豊富な開発者はAIを使うことで20%速くなると感じていたが、実際にはAIを使わない場合よりも19%も作業に時間がかかっていた。つまり、私たちはAIを使っていると「効率的になっている」と感じるが、必ずしもそうではない場合があるのだ。パイプライン型の実験結果は、この知覚ギャップの極端な例とも言えるだろう。多くの活動が視覚的に行われ、計画や文書が作成されても、実際に動作するものは何も生まれていないのだから。

このような状況を避けるために重要なのは、「機械的な検証」だ。誰かが作業を終えたという「意見」よりも、その作業が実際に成功したか、つまり「動作するか」を機械的にチェックすることが不可欠である。テスト、コンパイラ、自動実行されるスクリプトのような「機械的なゲート」は、作業が次の段階に進む前に、自動的に合否を判断し、一貫した結果を出す。これにより、曖昧さや主観的な判断が排除される。筆者の経験でも、自動的な校正フック、特定のコミットメッセージを拒否するルール、スキルの設定ミスを検出するスクリプトなどが、AIエージェントの作業品質を確保するために不可欠だったと述べられている。

これらの知見に基づくと、AIエージェントを効果的に活用するためのルールが見えてくる。第一に、タスクがAIエージェントの「コンテキスト」（一度に扱える情報量）に収まる限り、シングルエージェントを使用するのが最も効率的だ。第二に、各部分の依存度が低い「ルーズに結合された」作業を複数のエージェントで分担する場合、共有されたファイル、テスト、継続的インテグレーションのような「共有記録」を通じて調整を行い、不整合を自動的に拒否する「機械的なチェック」を導入することが重要だ。第三に、複数の選択肢が考えられるような曖昧なトレードオフが発生する場合にのみ、統括するエージェントが意思決定を行う「階層型」を検討する。

また、AIエージェントに情報を提供する際には注意が必要だ。エージェントに「念のため」としてプロジェクト全体のコードや、関連性の低い高品質なチュートリアルを与えるのは逆効果になることがある。AIモデルはノイズのような意味のない情報は無視しやすいが、関連性の低いクリーンな情報は正しいものと誤解して参照してしまう可能性があるからだ。例えば、あるサービスの価格に関する質問に対して、別のよく似たサービスの価格チュートリアルを与えてしまうと、モデルは正しい情報だと信じてしまい、誤った回答を生成しかねない。

結論として、AIエージェントのチームを構成する際に、単にエージェントの数を増やしても、ほとんどの場合は調整コストが増大するだけである。エージェントのチームが行き詰まったとき、本当に必要とされるのは、もう一体のエージェントを追加することではなく、「ノー」と明確に異議を唱え、作業の不備を指摘できる「テスト」や「フック」、「スクリプト」のような機械的な検証ツールだ。