Single AgentとMulti-Agentの違い
いつ複数のAgentに分けるべき？

AIエージェントを設計していると、次の疑問が出てきます。

一つのAgentにすべて任せるべきなのか。

それとも、複数のAgentへ仕事を分けるべきなのか。

調査担当、コーディング担当、レビュー担当。

役割ごとにAgentを分ければ、なんとなく高度なシステムに見えます。

しかし、Multi-Agentだから優れているわけではありません。

むしろ仕事を分けすぎると、

• Agent同士の調整
• 情報の受け渡し
• 重複作業
• APIコスト
• 状態管理
• エラーの伝播

など、新しい複雑さが生まれます。

重要なのはAgentの数ではありません。

その仕事を独立した単位へ分ける意味があるか。

ここがSingle AgentとMulti-Agentを分ける基本的な判断軸です。

1. Single Agentとは？

Single Agentでは、一つのAgentが仕事全体を担当します。

たとえばCoding Agentなら、

User
 ↓
Agent
 ├ Repository Search
 ├ File Read
 ├ File Write
 ├ Shell
 └ Test
 ↓
Result

という構成です。

Agent自身が、

• どのファイルを見るか
• 何を変更するか
• どのToolを使うか
• テストするか
• 修正を続けるか

を判断します。

仕事の途中で複数のToolを使っていても、判断主体が一つならSingle Agentです。

2. Multi-Agentとは？

Multi-Agentでは、一つのAgentが仕事全体を抱えず、複数のAgentへ処理を分けます。

たとえば調査なら、

User
 ↓
Lead Agent
 ├─ Subagent A：市場調査
 ├─ Subagent B：競合調査
 └─ Subagent C：技術調査
 ↓
Lead Agent
 ↓
統合
 ↓
Report

という構成です。

ここで重要なのは、

単にAgentを3つ起動することではありません。

それぞれに、

• 担当範囲
• Goal
• Tool
• 出力形式
• 終了条件

を持たせ、

仕事を分担させることに意味があります。

OpenAIのAgents APIでも、独立したタスクをSubagentへ委任し、各Subagentが独自のContext（そのAgentが現在の判断に使う会話・作業情報）を持ちながら並行して作業する構成が提供されています。公式ガイドでも、別々の文書レビューや異なる観点からの障害調査など、互いに独立した仕事でSubagentを使うことが推奨されています。

3. なぜMulti-Agentに分けるのか

主な理由は4つあります。

1. 並列化できる

たとえば10社の競合調査を一つのAgentが順番に行うと、

会社A
↓
会社B
↓
会社C
↓
...

と進みます。

しかし、それぞれ独立して調べられるなら、

        ┌ Agent A
Lead ───┼ Agent B
        ├ Agent C
        └ Agent D

と並行処理できます。

AnthropicのResearchシステムでも、Lead Agentが複数のSubagentへ独立した調査を割り振り、並列検索した結果を統合する構成が採用されています。Anthropicは、特に複数の独立した方向を同時に探索する「breadth-first（複数の方向を広く並列に探索する）」な調査でMulti-Agentが有効だったと報告しています。

2. Contextを分離できる

一つのAgentが大量の資料を読み続けると、Contextが膨らみます。

そこで、

Agent A → 法律資料だけ読む
Agent B → 技術資料だけ読む
Agent C → 市場資料だけ読む

と分ければ、それぞれが必要な情報だけを持てます。

これは単なる高速化ではありません。

不要な情報を混ぜない

という意味があります。

Agentごとに異なるContextを持てることは、Multi-Agent設計の大きな特徴です。OpenAIのAgents APIでもSubagentは独立したContextを持ちます。

3. Toolを役割ごとに限定できる

Single Agentへ、

• GitHub
• Database
• Email
• Shell
• Search
• CRM

など、すべてのToolを与えることもできます。

しかしMulti-Agentなら、

Research Agent
 └ Web Search

Coding Agent
 ├ Files
 ├ Git
 └ Shell

Customer Agent
 ├ CRM
 └ Email

のように分けられます。

これはTool選択をシンプルにするだけでなく、

権限を分離する

意味もあります。

必要のないAgentへ危険なToolを渡さない設計ができます。

なお、Agentごとに利用可能なToolをどこまで分離できるかは、利用するAgent基盤によって異なります。たとえば現在のOpenAI Agents APIでは、SubagentはSessionに設定されたMCP ToolやWeb Search、EnvironmentのFile・Command Toolなどを継承します。

4. 専門的なInstructionを与えられる

すべての仕事を一つの長いInstructionへ書くよりも、

Research Agent
「一次情報を優先して調査する」

Review Agent
「事実誤認と根拠不足だけ確認する」

Coding Agent
「既存仕様を壊さず実装する」

と役割を限定した方が、Agentの目的が明確になることがあります。

Multi-Agentは、

複数の人格を作る技術

というより、

責任範囲を分ける設計

として考える方がよいでしょう。

4. ではMulti-Agentの方が強いのか？

必ずしもそうではありません。

たとえば、

ファイルを読む
↓
修正する
↓
テストする
↓
エラーを見る
↓
また修正する

という作業があります。

この処理では、

前の結果が次の判断に強く影響します。

ここを、

Agent A：読む
Agent B：修正
Agent C：テスト

と機械的に分けると、毎回大量の情報をAgent間で受け渡す必要があります。

それなら、一つのAgentがContextを維持しながら処理した方が簡単です。

OpenAIのMulti-Agentガイドでも、短いタスクや依存関係のある処理はメインAgentで扱うことが推奨されています。また、複数Agentが同じファイルを編集する場合には変更の調整が必要になると説明されています。

つまり、

分割できるから分ける

のではなく、

分けても情報依存が弱いか

を見る必要があります。

5. 最も重要なのは「独立性」

Multi-Agentを使うかどうかを判断するとき、最初に見るべきなのは、

各タスクが独立しているか

です。

たとえば、

分けやすい

日本市場を調査
米国市場を調査
欧州市場を調査

それぞれ独立して進められます。

分けにくい

仕様を読む
↓
コードを書く
↓
実行結果を見る
↓
修正する

処理間の依存が強い。

この違いです。

最も根本的な判断基準は、

仕事を独立した役割へ分けることで、Context・Tool・権限・専門性・並列性のいずれかに明確なメリットがあるか？

です。

その上で、並列化できるかを見る簡単な方法として、

「その仕事を複数人へ同時に渡しても成立するか？」

と考えるのが実践的です。並列化はMulti-Agentを選ぶ強力な理由の一つですが、直列処理でもContext分離や権限分離にメリットがあればSpecialist型やRouter型としてのMulti-Agent設計が有効になります。

6. Multi-Agentの代表的な構成

Multi-Agentにはいくつか典型的な構造があります。

Orchestrator / Worker

最も分かりやすい構成です。

        ┌ Worker A
Orchestrator
        ├ Worker B
        └ Worker C
             ↓
        結果を統合

中央のAgentが、

• タスクを分解する
• Subagentへ渡す
• 結果を回収する
• 最終結果をまとめる

役割を持ちます。

AnthropicのResearchシステムもLead AgentとSubagentによるOrchestrator / Worker型です。

Specialist Agents

役割ごとに専門Agentを用意します。

Planner
 ↓
Researcher
 ↓
Coder
 ↓
Reviewer

ただし、これは並列処理とは限りません。

仕事が順番につながっている場合は、

複数Agentでも直列処理

になります。

Agentの数と並列性は別の話です。

Router型

入力によって担当Agentを変える構成です。

User
 ↓
Router
 ├ 技術質問 → Tech Agent
 ├ 契約質問 → Legal Agent
 └ 請求質問 → Billing Agent

この場合、すべてのAgentが毎回動くわけではありません。

適切な専門Agentへ仕事を渡すことが目的です。

7. 複数の結果を使う場合は「どう統合するか」が必要になる

複数のAgentから結果を受け取る構成では、

「誰が最終判断し、どう結果を統合するのか」

を決める必要があります。

たとえば、

Agent A「A案が良い」
Agent B「B案が良い」
Agent C「判断不能」

となった場合、結果を並べるだけでは仕事が終わりません。

そこで、

• Lead Agent
• Orchestrator
• Reviewer
• Human

など、最終的に結果をまとめる役割が必要になります。

Multi-Agent設計では、

仕事の分解方法だけでなく、再統合方法も設計する

必要があります。

8. Multi-Agentには調整コストがある

Agentを増やせば、処理能力だけでなく通信も増えます。

たとえば、

Lead
↓
Agent A
↓
Lead
↓
Agent B
↓
Lead

と情報を渡すたびに、

• Token
• API Call
• Context
• 待ち時間

を使います。

Anthropicも実際のMulti-Agent Research開発で、Agent同士の調整、重複作業、不要なSubagent生成などが問題になったと報告しています。初期には簡単な質問へ大量のSubagentを生成してしまうような失敗もあったと説明しています。

つまり、

Agentを増やすこと自体にもコストがある

ということです。

9. よくある失敗：役割を細かく分けすぎる

たとえば、

Planning Agent
Search Agent
Reading Agent
Summary Agent
Writing Agent
Review Agent
Citation Agent

と細かく分ければ、高度に見えます。

しかし、一つ一つの仕事が小さすぎると、

Agent間で説明するコストの方が大きくなる

ことがあります。

人間の仕事でも同じです。

5分で終わる作業を5人へ分けて、

• 説明する
• 引き継ぐ
• 確認する
• 結果をまとめる

方が時間がかかることがあります。

Multi-Agentも同様です。

10. Toolの重複にも注意する

第3回『AIエージェントのToolとは？』で見たように、AgentはToolを使います。

では、

Agent A
Agent B
Agent C

へ同じToolをすべて与えるべきでしょうか。

必ずしもそうではありません。

たとえば、

Research Agent
├ Web Search
└ Document Read

Coding Agent
├ File Write
├ Shell
└ Git

Review Agent
├ File Read
└ Test

のように、

役割に必要なToolだけ持たせる

設計ができます。

これにより、

• Tool選択の複雑さ
• 誤操作
• 権限範囲

を減らせます。

Multi-Agent設計はTool設計とも密接につながっています。

11. Agent同士で状態をどう共有するか

Multi-Agentになると、次の問題が出てきます。

Agent Aが知っていることを、Agent Bは知っているのか？

たとえばResearch Agentが、

「公式資料では仕様Aだった」

という情報を得たとします。

Coding Agentがそれを知らなければ、古い仕様で実装するかもしれません。

そこで、

• Contextを引き渡す
• Summaryを渡す
• Shared Stateを使う
• Fileへ保存する
• Databaseへ保存する

などの方法が必要になります。

ただし④ではここに深入りしません。

この問題は次の記事、

「AIエージェントに『状態』はなぜ必要？Session・Context・Memoryの違い」

で詳しく扱います。

12. Claude Code・Codex・Antigravityを見る視点も変わる

Coding Agentを比較するときも、

単に、

どのモデルが一番賢いか

だけを見るのでは不十分です。

見るべきなのは、

• Subagentを使えるか
• 並列処理できるか
• Contextをどう分離するか
• AgentごとにToolを制御できるか
• 結果をどう統合するか

というAgent Architecture（Agentの役割分担・Tool・Context・実行関係をどう組むかという設計構成）です。

OpenAI Agents APIでは、複数のSubagentを同時実行する設定が公式に用意されています。

GoogleではAgents CLIを通じて、AntigravityやClaude Code、CursorなどのCoding Agent環境から、ADK Agentの構築・テスト・評価・デプロイを進められる仕組みが提供されています。

つまり今後Coding Agentを見るときには、

Model性能

だけではなく、

仕事をどう分解・委任できるか

も重要な評価軸になります。

13. Single Agentを選ぶべきケース

Single Agentが向いているのは、

1. タスクが短い

数ステップで終わる。

2. 手順の依存関係が強い

一つ前の結果を見ながら次へ進む。

3. 同じファイル・データを繰り返し扱う

Contextを共有した方が自然。

4. Toolがそれほど多くない

一つのAgentでも管理できる。

5. まずシンプルに作りたい

これはかなり重要です。

最初からMulti-Agentにしなくてもよいのです。

14. Multi-Agentを検討するケース

逆に、次の条件が増えてきたらMulti-Agentを検討できます。

1. 独立したサブタスクへ分解できる

市場A / 市場B / 市場Cの調査など。

2. 並列化すると大幅に速くなる

独立した探索・調査など。

3. Toolや権限を役割ごとに分けたい

Research / Coding / Reviewなど。

4. Contextを分離したい

大量資料を一つのAgentへ詰め込みたくない。

5. 専門的なInstructionが必要

担当ごとに判断基準が異なる。

15. CORE SPECの判断基準

Single / Multi-Agentを決めるときは、次の順序で考えるとシンプルです。

この仕事は一つのAgentで処理できる？
↓
YES
↓
まずSingle Agent

NO / 複雑
↓
独立したタスクへ分けられる？
↓
NO
↓
Single Agentの設計を改善

YES
↓
並列化・Context分離・権限分離に価値がある？
↓
NO
↓
Single Agent

YES
↓
Multi-Agentを検討

つまり、

Single Agentを基本形にして、分ける理由が生まれたらMulti-Agentにする

という考え方です。これは技術仕様上の絶対ルールではなく、まずシンプルな構成から始めるための設計ヒューリスティックです。

これは単純ですが、かなり重要です。

16. Agent設計は「組織設計」に近づいていく

Agentが一つなら、

このAgentに何をさせるか

を考えれば済みます。

しかし複数になると、

誰が何を担当するのか

何を共有するのか

誰が判断するのか

どこで統合するのか

を設計する必要があります。

これは、

ソフトウェア設計であると同時に、仕事の分業設計

でもあります。

Multi-Agentの本質は、

Agentをたくさん起動することではありません。

仕事をどの単位へ分けると、全体としてうまく進むのか。

そこを考えることです。

まとめ

Single AgentとMulti-Agentの違いは、Agentの数だけではありません。

Single Agentは、

一つのContextと判断主体を中心に仕事を進める構成

です。

Multi-Agentは、

仕事を複数の独立した役割へ分解し、結果を調整・統合する構成

です。

Multi-Agentが向いているのは、

• 独立した仕事へ分けられる
• 並列化できる
• Contextを分離したい
• Toolや権限を分けたい
• 専門性を分けたい

場合です。

一方、

• 短い
• 前後関係が強い
• 同じ情報を使い続ける

仕事なら、Single Agentの方がシンプルです。

最も重要なのは、

Agentを増やすことではなく、仕事を適切な単位へ分けること。

です。