F-2: シングルエージェント vs マルチエージェント¶

この相反は何か¶

1つのLLMインスタンス（エージェント）がすべてのツールと文脈を持って処理するか、複数の専門化されたエージェントに分割して協調させるかという二者択一です。マルチエージェントは近年大きな注目を集めていますが、この選択は「かっこよさ」ではなく、専門性の分離と調整コストのトレードオフで決まります。

この選択が二者択一として現れる理由は、エージェント間の調整メカニズム（Supervisor、メッセージパッシング、共有メモリなど）が導入されると、システムの複雑性が非連続的に跳ね上がるためです。2つのエージェント間でも、合意形成・コンテキスト共有・エラー伝播・デバッグの難度は単一エージェントとは質的に異なります。「少しだけマルチ」という中間はなく、調整インフラを入れるか入れないかの境界が存在します。

AIエージェント固有の事情として、LLMのコンテキスト窓は有限であり、ツール定義やドキュメントを詰め込むほど推論精度が下がるという問題があります。また、プロンプトインジェクション（F14）の被害範囲を限定するために、権限をエージェント単位で分離したいという安全上の動機もあります。これらが「分割の利益」として働きますが、それが調整コストに見合うかどうかは [task_variability] と [cost_sensitivity] で判定します。

選択肢A：シングルエージェント¶

1つのLLMインスタンスがすべてのツール、すべての文脈、すべての権限を持ち、タスク全体を処理します。制御フローは1つのループまたはワークフロー内で完結し、エージェント間通信は存在しません。

シングルエージェントの最大の利点は単純さです。デバッグは1つのコンテキスト窓の中で閉じますし、テストも1つのエージェントの入出力で完結します。状態共有の問題がなく、合意形成も不要です。コンテキスト窓に収まる限り、すべての情報が1つの推論に利用可能であるため、情報伝達のロスがありません。

コスト面でもシングルは有利です。マルチエージェント構成では、Supervisorがタスクを分解し、各Workerが独立してLLMを呼び、結果をSupervisorが集約するため、LLM呼び出し回数が乗数的に増えます。シングルなら1つのループで済む処理が、マルチでは3〜5倍のトークンを消費することも珍しくありません。

一方、シングルの限界はコンテキスト窓の容量と権限の粒度です。ツール定義が20個を超えるとコンテキストが膨張し、ツール選択の精度が下がります。また、すべてのツールに対する権限を1つのエージェントが持つため、プロンプトインジェクションが成功した場合の被害範囲が最大になります。

選択肢B：マルチエージェント¶

複数の専門化されたエージェント（Worker）を、調整役（Supervisor）が束ねる構成です。各Workerは自身の専門領域に必要なツールと文脈だけを持ち、Supervisorがタスク分解・予算配分・結果集約を担います。

マルチエージェントの利点は専門性の分離、権限の最小化、並列実行の3つです。各Workerのコンテキスト窓には専門領域の情報だけが入るため、推論精度が向上します。権限もWorker単位で最小権限を付与でき、あるWorkerが侵害されても被害は限定されます。独立したサブタスクを並列に処理すれば、[latency_budget] を節約できます。

しかし代償は調整コストです。Supervisorのタスク分解が不適切なら、Worker間で重複作業や情報不足が発生します。Worker間のコンテキスト共有はSupervisor経由の明示的メッセージパッシングに限られるため、シングルなら暗黙的に利用できた情報が失われます。デバッグでは複数のコンテキスト窓を横断的に追う必要があり、分散トレーシングが不可欠になります。エラー伝播（あるWorkerの失敗が他に与える影響）の設計も必要です。

マルチが有効な典型例は、コード生成（コーディングエージェント）＋テスト実行（テストエージェント）＋レビュー（レビューエージェント）のように、専門性の軸が明確に分かれるケースです。

選定基準¶

選定は [task_variability] と [cost_sensitivity] を軸に、以下の条件で判定します。

マルチに倒す条件（すべて該当する場合）：

専門性/権限の軸が2つ以上に明確に分かれます。つまり、ツールセットAとツールセットBを1つのコンテキストに入れるとノイズになり精度が落ちる、あるいはセキュリティ上分離が必要です。
並列実行による時短が [latency_budget] の達成に貢献します。
[task_variability] が高く、各専門領域内で自律的な判断が必要です。
調整コスト（Supervisorのトークン消費、エラー伝播の設計、デバッグ複雑性）が分割の利益を下回ります。

シングルに留まる条件（いずれか該当する場合）：

ツールセットが20個以下で、1つのコンテキスト窓に収まります。
[cost_sensitivity] が高く、LLM呼び出し回数の増加が許容できません。
専門性の軸が1つしかない、または分離しても情報共有が頻繁に必要です。
チームの運用能力として、マルチエージェントのデバッグ・モニタリングが困難です。

デフォルトとハイブリッド¶

デフォルト：まずシングルエージェントで始めてください。 マルチエージェントの調整コストは過小評価されがちです。シングルでボトルネック（コンテキスト溢れ、権限の粗さ、レイテンシ）が明確になった時点で、そのボトルネックを解消する最小限のWorkerを追加します。

ハイブリッド：Supervisor＋専門Workerの構成が定石です。Supervisorはタスク分解・予算配分・結果集約のみを担い、自身ではツールを呼びません。各Workerは独立したコンテキスト窓で動作し、Worker間の直接通信は避けます。Worker数の目安は2〜5で、それ以上に増やす場合は調整コストの増大を慎重に評価してください。Worker内部はB3 予算付き自律ループで構成し、Worker単位のステップ上限・コスト上限を設定します。

判断を誤ったときの症状¶

シングルを選ぶべきだったのにマルチを選んだ場合：

Supervisorのタスク分解とWorker間の調整にトークンの大半が消費され、本来の処理よりも「段取り」のコストが上回ります。
Worker間で同じ情報を繰り返し渡す「コンテキストの往復便」が発生し、レイテンシが増大します。
あるWorkerの失敗が他のWorkerに波及し、障害の原因特定に時間がかかります。
結局、ほとんどのタスクが1つのWorkerだけで完結しており、Supervisorは単なるパススルーになっています。

マルチを選ぶべきだったのにシングルを選んだ場合：

コンテキスト窓にツール定義が溢れ、ツール選択の精度が低下します（存在するツールを呼ばない、間違ったツールを呼ぶ）。
1つのプロンプトインジェクションですべてのツール権限が奪取されるセキュリティインシデントが発生します。
処理時間がSLA（[latency_budget]）を超過しますが、並列化する手段がありません。
異なるドメイン知識（法務と技術など）を1つのプロンプトに詰め込んだ結果、どちらの領域でも品質が低下します。