マルチエージェント構成をいつ選ぶか｜単一エージェントで足りる線引きと、分割するときの設計判断

エージェントを実装していると、どこかの時点で「これは1つのループで持たせるには重すぎるのではないか」と感じる瞬間が来ます。ツールが増え、システムプロンプトが長くなり、1回の実行で扱う情報量が膨らんでいく。そこで自然に浮かぶのが、役割ごとにエージェントを分ける「マルチエージェント構成」です。ただ、分けること自体は目的ではありません。分ければ解ける問題と、分けたことで初めて生まれる問題があり、後者のほうが厄介なケースは珍しくありません。この記事では、単一エージェントで足りる線引きと、複数に分割するときの設計判断を、公開されている一次情報を確認しながら実務目線で整理します。フレームワークの選定そのものは別記事に譲り、ここでは「構成をどう決めるか」に絞ります。

既定は「分けない」#

まず前提として、Anthropicは2024年12月公開のエンジニアリングブログ「Building effective agents」で、エージェント的なシステムを作る際の指針として「最も単純な解を見つけ、必要なときだけ複雑さを増すことを推奨する」と述べています。同記事は、複雑さを足すのは「それが明らかに結果を改善するときだけ」にすべきだとも書いています。マルチエージェント化は、この文脈でいえばかなり後半に来る選択肢です。

反対側の主張も明確に存在します。Cognitionは自社ブログの「Don't Build Multi-Agents」(Walden Yan、2025年6月12日公開)で、マルチエージェント構成は脆いと論じています。同記事が挙げる原則は2つで、1つ目は「コンテキストを共有せよ。個別のメッセージだけでなく、エージェントの全トレースを共有せよ」、2つ目は「行動は暗黙の決定を含んでおり、決定が衝突すれば結果は悪くなる」というものです。記事中の例はこうです。タスクは「Flappy Birdのクローンを作る」で、これをサブタスクに分けたところ、サブエージェント1がサブタスクを取り違えてスーパーマリオ風の背景を作り、サブエージェント2はゲームアセットに見えずFlappy Birdらしい動きもしない鳥を作ってしまい、最終段のエージェントが「この2つの伝達ミスを結合するという望ましくない仕事」を負うことになった、というものです。同記事はさらに、各エージェントに前段の文脈を共有させた場合でも、鳥と背景の視覚スタイルが全く食い違う結果になりうるとし、その原因を「サブエージェント1の行動とサブエージェント2の行動が、事前に規定されていない、互いに矛盾した前提に基づいていたこと」だと説明しています。前者が原則1、後者が原則2に対応する例です。

この指摘は実務感覚とよく一致します。エージェントを分けた瞬間に、次の代償が付いてきます。

• コンテキストの分断: 一方が知っている前提を他方が知らない。結果として、同じ質問に別々の答えを出す、同じ調査を二重に行う、といった無駄が生じます。
• 状態の二重管理: どのエージェントが何を確定させたのかを、アプリ側で持ち直す必要が出てきます。
• デバッグの困難さ: 出力がおかしいとき、どのエージェントのどの判断が原因かを特定する手間が跳ね上がります。
• トークン消費の増加: 同じ前提を複数回渡し直すため、総トークン量は素直に増えます。なお総トークン量と壁時計時間(実際の待ち時間)は別の指標です。後者は並列化がはまれば短縮しうる一方、逐次的な構成では起動のたびに前提を集め直す分だけ伸びます。

Cognitionは対処として、まずは単一スレッドの直線的なエージェントを勧め、それでも文脈が長くなる場合には、行動と会話の履歴を要点・出来事・決定に圧縮する層を挟む案を示しています。「単純なアーキテクチャでかなり遠くまで行ける」という書き方です。分割を検討する前に、まずこの線を疑うのが順序として妥当です。

分けてよくなる条件と、分けてはいけない条件#

とはいえ、分割が有効な領域も実測で示されています。判断を条件に落とし込みます。

分けてよくなる条件#

Anthropicは2025年6月13日公開のエンジニアリングブログで、自社のリサーチ機能について、統括役のエージェントが処理を調整し、並列に動く専門サブエージェントへ委譲する「オーケストレーター・ワーカー型」を採用したと説明しています。同社の内部リサーチ評価では、Claude Opus 4を統括役、Claude Sonnet 4をサブエージェントとした構成が、単一のClaude Opus 4を90.2%上回ったと報告されています。また、サブエージェントを直列ではなく3〜5体並列で動かし、各サブエージェントが3つ以上のツールを並列で使うようにした結果、複雑なクエリで調査時間を最大90%短縮できたとも書かれています。ただしこれらはいずれも2025年6月時点、当時のモデル世代(Claude Opus 4とClaude Sonnet 4)での測定値です。

LangChainの公式ドキュメントは、マルチエージェントの動機を3点に整理しています。コンテキスト管理(モデルのコンテキストウィンドウを圧迫せずに専門知識を与える)、分散開発(異なるチームが独立して機能を開発・保守し、明確な境界のもとで合成する)、並列化(サブタスク用の専門ワーカーを起動して同時実行する)です。

これらを実務の条件に翻訳すると、次のようになります。

• 読み取り中心で並列化できる: 調査・情報収集・複数ソースの横断検索など、副作用がなく同時に走らせても壊れない仕事。
• サブタスクが独立していて結果を合流できる: 各ワーカーの成果を機械的にマージでき、順序に依存しない。
• 単一ループに責務やコンテキストが収まらない: ツール定義や資料が多すぎて、1つのシステムプロンプトに載せると指示が薄まる。LangChainの公式ドキュメントも、分割を検討する場面として「単一のエージェントがツールを持ちすぎ、どれを使うかの判断を誤るとき」を挙げています。個数の閾値は示されていないため、判断は症状ベースになります。
• 権限や到達範囲を分離したい: Claude Codeの公式ドキュメントは、サブエージェントが「独自のコンテキストウィンドウで、独自のシステムプロンプト、固有のツールアクセス、独立した権限を持って動く」と説明しています。役割ごとに与えるツールと権限を絞り込む動機はここにあります。ただし同ドキュメントは、親会話の権限モードが優先されて子側の設定が無視される場合(親がbypassPermissionsやacceptEditsのとき)も明記しているため、これ単体をセキュリティ境界として扱うのは避け、権限の最小化の一手段と位置づけるのが妥当です。
• 役割ごとにモデルやコストを変えたい: 同ドキュメントは、Haikuのような高速で安価なモデルへタスクを振ってコストを制御する使い方にも触れています。

分けてはいけない条件#

一方でAnthropicは前掲のマルチエージェントリサーチ記事で、「すべてのエージェントが同じコンテキストを共有する必要がある領域や、エージェント間の依存が多い領域は、現時点ではマルチエージェントに向かない」と明記しています。具体例として「ほとんどのコーディングタスクは、リサーチに比べて本当に並列化できるタスクが少ない」と述べています。分割の成功例が調査系に偏っているのは、この性質によるものです。

実務で避けるべき条件を挙げます。

• 逐次的で、前工程の判断に依存する: 後段の判断が前段の結論なしに決まらないなら、分けても待ち時間が増えるだけです。
• 書き込みや副作用を伴い競合する: 同じファイル、同じレコード、同じチケットに複数のエージェントが書き込む構成は、競合と上書きの温床になります。
• 要件が曖昧で共有コンテキストが要る: 前提が固まっていない仕事を分割すると、Cognitionが指摘した「矛盾した前提に基づく決定」がそのまま起こります。
• コード側の分岐で足りる: 条件分岐や順次実行で書けるものを、わざわざLLMの判断に委ねる必要はありません。

構成の型と選び分け#

構成は二択ではなく、単一エージェントから階層型まで段階があります。OpenAIのAgents SDK公式ドキュメントは、オーケストレーションを「LLMに判断させる」方式と「コードでエージェントのフローを決める」方式の2カテゴリに分け、前者は「タスクがオープンエンドで、LLMの知能に頼りたい場合に最も有効」、後者は「速度・コスト・性能の面でタスクをより決定的で予測可能にする」と説明しています。この対比が選び分けの軸になります。

Anthropicは前掲の「Building effective agents」で、統括役が動的にタスクを分解してワーカーへ委譲し、結果を統合するオーケストレーター・ワーカー型について、「必要なサブタスクを事前に予測できない複雑なタスクに適する」と説明しています。並列化との違いは、サブタスクが事前定義ではなく統括役によって入力に応じて決まる点だとされています。逆に言えば、サブタスクが事前に列挙できるなら、コードで並列実行を書くほうが素直です。

フレームワークごとの実装の違いや選定については別記事で扱っています。

コンテキストの受け渡しが設計の本体#

分割の成否を決めるのは、構成図の形ではなく「何を渡し、何を渡さないか」です。ここで、サブエージェント型とhandoff型が挙動として別物であることを押さえておく必要があります。

まず「要約だけを返す」という挙動は、方式全般の仕様ではなく設計の選択です。Anthropicのコンテキストエンジニアリングに関する記事は、長い文脈への対処法の1つとしてサブエージェント構成を挙げ、そこでの振る舞いを「各サブエージェントは数万トークン以上を使って広範に探索するかもしれないが、返すのは凝縮され蒸留された作業の要約(多くの場合1,000〜2,000トークン)だけである」と説明しています。詳細な検索コンテキストはサブエージェント内に隔離され、統括役は結果の統合と分析に集中する、という関心の分離です。ただしこれは同社が示す構成例の挙動であり、1,000〜2,000トークンという数字も一般的な仕様値ではありません。

実装側の既定はどうなっているか。OpenAIのAgents SDKでは、エージェントをツールとして呼ぶ構成は「制御を渡す代わりに、中心のエージェントが専門エージェントのネットワークをオーケストレーションしたい場合」の選択肢として位置づけられており、統括役は制御を保持したまま、サブエージェントの最終出力を受け取ります。同ドキュメントは「親の実行の会話状態は自動では継承されない」こと、そして「親と子で同じsessionを明示的に渡せば履歴を共有できる」ことも書いています。要約に絞りたい場合は、出力を加工する仕組み(custom_output_extractor)を別途使う形です。つまり隔離は既定の性質としてある一方、「要約だけ返す」かどうかは実装者が決める部分だ、と理解しておくと事故が減ります。

handoffは逆です。OpenAIの公式ドキュメントは、handoffが「LLMにはツールとして提示される」こと、そして「handoffが起きると、新しいエージェントが会話を引き継ぎ、それまでの会話履歴全体を見ることになる」と明記しています。渡しすぎが問題になる場合のために、入力フィルタで受け渡す内容を加工する仕組みも用意されています。

つまり、隔離したいならサブエージェント型、文脈を引き継いで担当だけ替えたいならhandoff型、という使い分けになります。ここを混同すると、隔離したつもりでhandoffを使って履歴が全部流れていたり、引き継いだつもりでツール呼び出しにして前提が失われていたり、という事故が起きます。

出力契約・失敗・競合をどう決めるか#

分割した瞬間に、エージェント間のインターフェースがシステムの一部になります。人間のチームで言えば、口頭の申し送りではなく書式の決まった報告書に変える作業です。

出力契約の作り方そのものは構造化出力の話題と重なります。詳細はそちらを参照してください。

コスト・レイテンシと観測の準備#

分割はコスト構造を変えます。Anthropicは前掲のマルチエージェントリサーチ記事(2025年6月13日公開)で、エージェントは「チャットでのやり取りに比べて約4倍のトークンを使い、マルチエージェントシステムはチャットの約15倍のトークンを使う」と報告しています。同社環境での当時の実測値です。同社は、この経済性が成立するのはタスクの価値が十分に高い場合だと位置づけています。Anthropicの別記事も「エージェント的なシステムは、より良いタスク性能のためにレイテンシとコストを差し出すことが多く、そのトレードオフが妥当かどうかを検討すべきだ」と述べています。

レイテンシも一方向には改善しません。並列化で短縮できる部分がある一方、Claude Codeの公式ドキュメントは、サブエージェントを使わず本体の会話で進めるべき場合として「レイテンシが重要な場合。サブエージェントはまっさらな状態から始まるため、コンテキストを集めるのに時間がかかることがある」と挙げています。起動のたびに前提を集め直すコストは無視できません。

見積りの実務としては、次の3点を分割前に押さえておくと判断が早くなります。

• 現行の単一構成での1リクエストあたりトークン数と所要時間の実測値。
• 分割後に見込む並列度と、統括役へ返す要約のトークン上限。
• 役割ごとのモデル割り当て(統括役は高性能モデル、定型のワーカーは軽量モデル、という配分)。

トークン課金の考え方と削減の定石は別記事にまとめています。

そして分割する以上、トレースは必須です。どのサブエージェントが、どの入力を受け取り、どのツールを何回呼び、何を返したか。これが後から追えないマルチエージェントは、事実上デバッグできません。分割の意思決定と同時に、観測基盤の準備を始めてください。

単一から分割へ移る順序#

以上を踏まえると、実務での進め方は段階論に落ち着きます。いきなり構成図を描くのではなく、次の順序で確かめます。

取り消せない操作に人の確認をどう挟むかは、分割構成でも単一構成でも共通の論点です。設計の詳細はこちらで扱っています。

本文中の数値・仕様は、Anthropicの公式エンジニアリングブログ(マルチエージェントリサーチシステム、Building effective agents、コンテキストエンジニアリング)、Cognitionの公式ブログ、LangChain公式ドキュメント、OpenAI Agents SDK公式ドキュメント、Claude Code公式ドキュメントで確認できた範囲に基づきます。各社の評価結果は特定のタスク・モデル構成での測定値であり、他の業務に一般化できるものではありません。なお「Building effective agents」は2024年12月公開で、同記事には公開後にツール環境が変化した旨の注記がありますが、本稿で引用したのは設計原則の部分です。仕様は更新されるため、実装時は最新の公式情報で裏取りしてください。

よくある質問#

まとめ#

マルチエージェント構成は、うまくはまる領域が確かに存在します。調査や情報収集のように、副作用がなく並列に探索できて、結果を機械的に合流できる仕事では、実測レベルの改善が公開されています。一方で、同じ情報源が「共有コンテキストが必要な領域や依存が多い領域には現時点では向かない」とも述べており、反対側からは「分けたことで矛盾した前提に基づく決定が生まれる」という批判が出ています。どちらも正しく、対象タスクの性質が判断を分けているだけです。

実務での結論はシンプルです。既定は分けないこと。分けるかどうかは構成の流行ではなく、自分たちのタスクが並列化に向くか、書き込みが競合しないか、権限を分ける必要があるかという条件で決めること。そして分けると決めたら、渡す情報・返させる形式・失敗時の扱い・観測の仕組みを、構成図より先に固めること。この順序を守れば、分割は選択肢の1つとして扱えるようになります。