---
title: "シングルエージェントとマルチエージェントの違い｜使い分けの判断基準とコスト・失敗モード【2026年版】"
url: "https://www.issoh.co.jp/tech/details/4261/"
published: 2024-11-20
updated: 2026-09-27
categories: ["AIエージェント・MCP"]
publisher: "株式会社一創"
---

# シングルエージェントとマルチエージェントの違い｜使い分けの判断基準とコスト・失敗モード【2026年版】

AIエージェントの設計で最初に迫られるのが、1体のエージェントに任せるか、役割の違う複数のエージェントに分担させるかという選択です。日本語の解説記事はマルチエージェントの利点を並べたものが大半ですが、実務で効くのは「どこまでシングルで押し切れるか」の線引きのほうです。ここではシングルエージェントとマルチエージェントの構造的な違いを押さえたうえで、Anthropicが公開したトークン消費の実測値、UCバークレー中心の研究チームが分類した14の失敗モード、Cognitionが2026年4月に更新した設計原則を根拠に、選択の基準を条件として示します。

## まとめ

- **シングルエージェント**は1体のLLMがツールを呼びながらタスクを完結させる構成。文脈が1本のスレッドに保たれ、挙動を追跡しやすい。
- **マルチエージェント**は役割を分けた複数のエージェントが協調する構成。並列で広く探索できる反面、文脈が分裂して矛盾した判断が起きる。
- コストは無視できない。Anthropicの実測では、エージェントはチャット対話の約4倍、マルチエージェントは**約15倍のトークン**を消費する。
- それでも成果が出る領域はある。同社の社内リサーチ評価では、マルチエージェント構成が単体のClaude Opus 4を**90.2%上回った**。読み取り中心・並列探索型のタスクが該当する。
- 失敗も体系化されている。MAST（Multi-Agent System Failure Taxonomy）は7フレームワークの実行トレースから**3カテゴリ14種類の失敗モード**を特定した。
- 2026年4月、Cognitionは「マルチエージェントを作るな」から立場を更新し、**書き込みを単一スレッドに保ったまま他エージェントが知性だけを寄与する構成**なら機能すると示した。
- **判断基準は「シングルで始め、条件を満たしたときだけ分割する」**。分割してよい条件は判断基準の章に条件付きで整理した。
- 実装の起点も変わった。AutoGenはメンテナンスモードに移行し、後継の**Microsoft Agent Frameworkが2026年4月3日に1.0でGA**（現行1.11.0）。

## シングルエージェントとマルチエージェントの構造的な違い

### シングルエージェント：1体のLLMとツール群で完結する構成

シングルエージェントシステムは、1体のエージェントが環境を観測し、次に取る行動を自分で決め、ツールを呼び出して目的を達成する構成です。エージェントが1体であることは「機能が少ない」という意味ではありません。検索・ファイル操作・コード実行といったツールを何十個持たせても、それらを呼ぶ主体が1つならシングルエージェントです。

この構成の本質的な利点は、統合管理のしやすさにあります。判断の履歴が1本のコンテキストに直列で積まれるため、「なぜこの行動を取ったのか」をログを遡れば必ず説明できます。障害時の切り分けも、追うべきスレッドは1本だけ。マルチエージェント化を検討する前に、まずこの性質を手放す覚悟があるかを問うべきです。

### マルチエージェント：役割分担した複数エージェントの協調

マルチエージェントシステム（MAS）は、自律的に動く複数のエージェントが、それぞれの役割を持って協調しながら1つの目標を達成する構成です。調査担当・実装担当・レビュー担当のように専門を分け、統括役が仕事を割り振る形が典型になります。

各エージェントが独立したコンテキストウィンドウを持つため、1体では入りきらない量の情報を扱えます。並列に動かせるので、探索範囲を広く取るタスクなら実時間も短縮できる。代償として、エージェント間で何を共有し何を捨てるかという設計判断が新たに発生します。この設計を誤ると、後述する14の失敗モードに直行します。

なお「マルチエージェントシステム」という語は、制御工学や強化学習の分野で古くから使われてきた分散協調システム（交通流シミュレーション、群ロボット制御など）も指します。本記事が扱うのはLLMを頭脳とするAIエージェントの構成であり、古典的MASの数理モデルとは別の話題です。

### 比較表：制御・コンテキスト・コスト・障害切り分けの違い

| 観点      | シングルエージェント   | マルチエージェント      |
| ------- | ------------ | -------------- |
| 制御の主体   | 1体（線形）       | 統括役＋専門役（分散）    |
| コンテキスト  | 1本に連続        | エージェントごとに分裂    |
| 並列実行    | 不可（逐次）       | 可（探索を広く取れる）    |
| トークン消費  | チャットの約4倍     | チャットの約15倍      |
| 障害の切り分け | 1スレッドを遡る     | どのエージェントかの特定から |
| 向くタスク   | 依存関係のある実装・変更 | 読み取り中心の並列調査    |

トークン消費の数値は、Anthropicがリサーチ機能の開発で公開した実測値です（2025年6月13日）。「約15倍」はチャット対話との比較であり、シングルエージェントとの比較ではない点は正確に押さえてください。

## マルチエージェントの構成パターン

「複数のエージェントを協調させる」と言っても、連携のさせ方でシステムの性質は大きく変わります。Microsoft Agent Frameworkは実装済みのオーケストレーションパターンとして5種類を提供しており、この分類が実務の語彙としてそのまま使えます。

| パターン       | 連携の形             | 向く用途           | 典型的な事故        |
| ---------- | ---------------- | -------------- | ------------- |
| sequential | 前段の出力を次段が受け取る直列  | 原稿生成→校正→要約     | 少ない（実質パイプライン） |
| concurrent | 同じ入力を並列処理して集約    | 多観点レビュー        | 結論の衝突         |
| handoff    | 担当外と判断したら会話ごと委譲  | サポートの一次受付      | たらい回し         |
| group chat | 同じ場で複数が発言        | 設計の妥当性検討       | 会話が終わらない      |
| Magentic   | 統括役が計画・再計画して割り振る | Web調査・コード実行の複合 | 同じ手順の反復       |

### Magenticパターンの中身とMagentic-Oneの位置づけ

Magenticパターンは、Microsoft Researchが2024年11月に公開したMagentic-Oneの設計を吸収したものです。統括役のOrchestratorがタスク台帳（Task Ledger）と進捗台帳（Progress Ledger）の二重ループを持ち、Webブラウズ・ファイル操作・コード生成・端末実行の専門エージェントに仕事を割り振ります。行き詰まりを検知すると計画を立て直すのが特徴です。

論文（arXiv:2411.04468）のGAIAテストセットでのスコアは、全エージェントにgpt-4o-2024-05-13を使った構成で**32.3%**、Orchestratorの外側ループとCoderにo1-previewを併用した構成で**38.0%**でした。日本語記事でよく見る「38%」は後者の混成構成の値であり、GPT-4o単独の成績ではありません。

そして重要なのは現在の扱いです。Magentic-One自体は研究プロトタイプであり、2026年時点で単体のプロダクトとして新規採用する対象ではありません。設計思想はMicrosoft Agent Frameworkのオーケストレーションパターンとして引き継がれているため、実装の入口はAgent Frameworkになります。

## コストの実測：15倍のトークンを回収できるタスクかどうか

マルチエージェント化の是非は、性能ではなく採算で決まります。Anthropicが公開した数値がこの議論の土台になります。

同社の社内リサーチ評価では、Claude Opus 4を統括役、Claude Sonnet 4をサブエージェントに置いた構成（統括役がサブエージェントを動的に生成して並列探索させる、orchestrator-worker型）が、単体のClaude Opus 4を**90.2%上回りました**。これは絶対精度ではなく、単体構成に対する相対的な上回り幅です。同じ記事に、エージェントはチャット対話の約4倍、マルチエージェントは約15倍のトークンを消費すると明記されています。

さらに重要なのがBrowseComp評価の分析です。性能のばらつきの95%を3つの要因が説明し、そのうち**トークン使用量だけで80%**を占めました。残りはツール呼び出し回数とモデル選択です。つまりマルチエージェントの成績は、賢い協調が生んだというより、大量のトークンを並列に投入した結果という側面が強い。この読み方を踏まえると、採算ラインは次のように引けます。

- **回収できる**：タスクの価値がトークン費用を明確に上回る領域。深掘りリサーチ、広範な競合調査、大規模コードベースの読解のように、探索を広げるほど成果が積み上がり、かつサブタスクが互いに独立しているもの。
- **回収できない**：単価の低い定型処理。1件あたり数円で回している問い合わせ一次対応をマルチエージェント化すると、精度の上積みより費用の増加が先に効く。
- **そもそも成立しない**：前の判断が次の判断の前提になる実装タスク。並列化しても各エージェントが異なる前提で書き始め、後から統合できません。

## マルチエージェントが壊れるとき：14の失敗モード

「調整が複雑になる」という抽象的な注意書きで済ませる解説が多いのですが、失敗の内訳はすでに研究として体系化されています。UCバークレーを中心とする研究チームの論文「Why Do Multi-Agent LLM Systems Fail?」（arXiv:2503.13657）は、ChatDev・MetaGPT・AG2・Magentic-One・OpenManusなど7つのフレームワークの実行トレースを分析し、MAST（Multi-Agent System Failure Taxonomy）として**3カテゴリ14種類**の失敗モードに分類しました。

数字の出どころを正確に書いておきます。分類法そのものは専門家が150本のトレースを精査して構築したもので、注釈者間の一致度はCohenのκ=0.88。これをLLM注釈器で1,642本まで拡大しており、そちらの人間との一致はκ=0.77（精度94%）です。

| カテゴリ        | 主な失敗モード                                                 | 現場での見え方               |
| ----------- | ------------------------------------------------------- | --------------------- |
| システム設計の問題   | タスク仕様の不遵守／ロール逸脱／同じ手順の反復／会話履歴の喪失／終了条件の未認識                | 同じ調査を延々と繰り返し、止まらない    |
| エージェント間の不整合 | 会話のリセット／確認要求の失敗／タスクの脱線／情報の出し惜しみ／他エージェントの入力の無視／推論と行動の不一致 | 担当Aの結論を担当Bが無視して別方向に進む |
| タスク検証の欠落    | 早期終了／検証の欠如・不完全／誤った検証                                    | 未完成の成果物を「完了」として返す     |

この論文が重いのは、失敗を数えたことよりも、**小手先の修正では十分に効かない**と示した点にあります。ChatDevのワークフローを調整（CEO役に最終判断権を持たせる）しても成功率の向上は9.4%、高次のタスク目標を検証する工程を追加してもProgramDevで15.6%の改善にとどまりました。プロンプトの手直しやロール定義の整理では、構造由来の失敗は消えません。

## 「作るな」から「書き込みは単線に」へ：Cognitionの2つの記事

マルチエージェント懐疑論の代表が、CognitionのWalden Yanが2025年6月に公開した「Don’t Build Multi-Agents」です。原則は2つ。ひとつ、**個々のメッセージではなくエージェントのトレース全体を共有せよ**。ふたつ、**行動には暗黙の判断が含まれ、矛盾した判断は悪い結果を生む**。並列に走るサブエージェントは不完全な情報しか持たないまま作業を進め、各自が暗黙に置いた前提が成果物に埋め込まれる。統括役が後から統合しようにも、前提が食い違っている以上つなぎ合わせられない、という主張でした。

同社は2026年4月22日、「Multi-Agents: What’s Actually Working」でこの立場を更新しています。結論は**「書き込みは単一スレッドに保ち、他のエージェントは行動ではなく知性を寄与させる」**という設計原則です。実際に機能しているパターンとして3つが挙がりました。

- **Code-Review Loop**：レビュー専任エージェントが変更を独立に点検する。1つのPRあたり平均2件のバグを検出し、うち58%が重大なものだったと報告されています。
- **Smart Friend**：主となる軽量モデルが、難所に当たったときだけ強いモデルへ委譲する（能力のルーター）。
- **Manager-Child**：統括役が仕事を分割して子エージェントを起動し、進捗を共有チャネルで束ねて統合する。

この更新は、Anthropicの実績と矛盾しません。Anthropicが成功したのはリサーチ、つまり**読み取り中心で副作用がなく、サブタスクが独立している**領域です。Cognitionが今も警告するのは、複数エージェントが並行して書き込む（コードを編集する）構成です。両社が到達した線は同じ——**読み取りは並列してよい、書き込みは単線に保て**。エージェント同士が自由に交渉し合う無秩序な群れ（swarm）は、いまも実用に乗っていません。

## 選択の判断基準：シングルで始め、条件を満たしたときだけ分割する

ここは玉虫色にせず言い切ります。**デフォルトはシングルエージェントです。**マルチエージェントは、次の3条件のうち少なくとも1つを満たすときにだけ検討してください。

1. **タスクが読み取り中心で、サブタスクが互いに独立している**。調査・収集・分類のように、並列に走らせても各自の結論が衝突しないもの。ファイルを書き換える、外部にリクエストを送るといった副作用のあるタスクは該当しません。
2. **扱う情報量が単一のコンテキストウィンドウに収まらない**。要約による圧縮や検索での絞り込みを先に試し、それでも溢れる場合に限ります。コンテキスト長の不足は、まずRAGや要約で対処するのが順序です。
3. **ツール群が競合している**。1体に数十のツールを持たせた結果、選択を誤るようになった場合は、ツール集合ごとにエージェントを分けるhandoff構成が効きます。

逆に、次の場合はマルチエージェント化を採用すべきではありません。**単価の低い定型処理**（15倍のトークンが利益を食い潰す）、**手順が確定している業務フロー**（それは自律エージェントではなくワークフローとして書くべきです）、**複数のエージェントが同じ対象に並行して書き込む構成**（書き込みは単線に保つ）。そして最も多い失敗は、**「複数のAIが協調する構成が先進的だから」という理由で分割すること**です。MASTが示したとおり、分割は失敗モードを14種類追加する行為でもあります。

## 実装の現在地：フレームワークと連携プロトコル（2026年7月時点）

この領域は入れ替わりが速く、2024年から2025年前半の日本語記事はすでに前提が崩れています。2026年7月13日時点の状況は次のとおりです。

| フレームワーク                   | 現行版                       | 位置づけ                          |
| ------------------------- | ------------------------- | ----------------------------- |
| LangGraph                 | 1.2.9                     | 現役／状態遷移をグラフで明示                |
| CrewAI                    | 1.15.2                    | 現役／Crews と Flows の二本立て        |
| OpenAI Agents SDK         | 0.18.2                    | 現役／Swarm の後継                  |
| Google ADK                | 2.4.0                     | 現役／2.0で破壊的変更                  |
| AutoGen                   | 0.7.5（2025-09-30）         | メンテナンスモード                     |
| Microsoft Agent Framework | 1.11.0（1.0 GAは2026-04-03） | AutoGen と Semantic Kernel の後継 |

実務上いちばん影響が大きいのはAutoGenの扱いです。公式リポジトリは「AutoGenはメンテナンスモードに入った。新機能や機能強化は行われず、今後はコミュニティ管理となる。新規ユーザーはMicrosoft Agent Frameworkから始めること」と明記しています。廃止ではありませんが、新規プロジェクトでAutoGenを選ぶ理由はほぼ消えました。既存資産については、Semantic KernelがAgent FrameworkのGA後も最低1年はサポート継続とされており、今すぐ捨てる必要はありません。

エージェント間・ツール間の接続プロトコルも標準化が進みました。**MCP**（Model Context Protocol）はエージェントとツール・データ源をつなぐ規格で、2025年12月9日にLinux Foundation傘下のAgentic AI Foundationへ寄贈され、現行仕様は2025-11-25版です。**A2A**（Agent2Agent）はエージェント同士をつなぐ規格で、2025年6月23日にLinux Foundationへ寄贈され、現行はv1.0.1（2026年5月28日）。JSON-RPC・gRPC・HTTP+JSONの3つのトランスポート束縛を持ちます。両者は競合ではなく、ツール接続がMCP、エージェント間連携がA2Aという住み分けです。

### handoff構成の最小コード（OpenAI Agents SDK）

担当を切り替える判断そのものをLLMに委ねるのがhandoffの要点です。以下はPython 3.10以上・環境変数`OPENAI_API_KEY`の設定を前提とします。

```
from agents import Agent, Runner

billing = Agent(
    name="billing_agent",
    handoff_description="請求・支払いに関する問い合わせの担当",
    instructions="請求と支払いに関する質問だけに答える。",
)
tech = Agent(
    name="tech_agent",
    handoff_description="技術的な不具合の切り分けの担当",
    instructions="技術的な不具合の切り分けだけを行う。",
)
triage = Agent(
    name="triage_agent",
    instructions="問い合わせ内容を読み、担当するエージェントへ引き渡す。",
    handoffs=[billing, tech],
)

result = Runner.run_sync(triage, "先月の請求額が二重になっています")
print(result.final_output)
```

引き渡し先の各エージェントに`handoff_description`を書いておくと、統括役がどのエージェントを選ぶかの精度が上がります。ここを省くと、統括役はエージェント名と指示文だけで判断することになり、たらい回しが起きやすくなります。

個別のフレームワークについては、Googleの[Agent Development Kit（ADK）の定義と役割](https://www.issoh.co.jp/tech/details/7936/)、AWSの[Strands Agentsの使い方と特徴](https://www.issoh.co.jp/tech/details/7199/)、開発現場でサブエージェントを実際に並列実行する[Codexサブエージェントの設定方法](https://www.issoh.co.jp/tech/details/11463/)を併せて確認してください。

## 運用で効く設計：評価・可観測性・権限分離

マルチエージェントを本番に置くと、単体では表面化しなかった問題が運用側に回ってきます。競合記事がほとんど触れない領域ですが、事故が起きるのは決まってこの層です。

**可観測性を先に用意する。** MASTの失敗モードは、どれもトレースを見なければ検知できません。「同じ手順の反復」も「他エージェントの入力の無視」も、最終出力だけを見ている限り「なんとなく品質が低い」としか観測されない。エージェント単位・ツール呼び出し単位でスパンを記録し、トークン消費を可視化する仕組みを、実装より先に入れてください。[Langfuseによるトレース収集と評価](https://www.issoh.co.jp/tech/details/6031/)はこの用途に使えます。トークン使用量が性能ばらつきの80%を説明するというAnthropicの分析は、裏を返せば**トークン量を計測していないチームは性能の8割を説明できない**ということです。

**終了条件を人間が握る。** group chat型で最も多い事故は、会話が終わらないことです。最大ターン数・最大トークン数・コスト上限のいずれかをハードリミットとして設定し、超えたら人間に返す設計にします。エージェント自身の「もう十分だ」という判断は、MASTのタスク検証の欠落（早期終了・誤った検証）そのものです。

**権限は役割ごとに絞る。** エージェントを分割したのに全員が同じ強い認証情報を共有している構成は、攻撃面だけが増えます。外部Webを読む役割を持つエージェントは、プロンプトインジェクションの入口です。書き込み権限を持つエージェントとは資格情報を分け、破壊的な操作には承認ゲートを挟む。[Auth0 for AI Agentsによるエージェントの認証・権限管理](https://www.issoh.co.jp/tech/details/9411/)のように、エージェントごとにIDと権限を割り当てる方向が主流になりつつあります。

## よくある質問

### シングルエージェントとは何ですか？

1体のAIエージェントが環境を観測し、自ら次の行動を決め、ツールを呼び出しながらタスクを完結させる構成です。ツールをいくつ持っていても、判断する主体が1つならシングルエージェントに分類されます。判断の履歴が1本のコンテキストに残るため、挙動を追跡しやすいのが最大の利点です。

### シングルエージェントで統合管理するメリットは何ですか？

3点あります。第一に、コンテキストが分裂しないため矛盾した判断が構造的に起きません。第二に、障害時に追うべきトレースが1本で済み、原因の切り分けが速い。第三に、トークン消費がマルチエージェント構成より大幅に小さく、単価の低い処理でも採算に乗ります。

### マルチエージェントにすれば精度は必ず上がりますか？

上がりません。MAST論文は、ベンチマーク上の性能向上はしばしば僅少であり、ワークフローを改善しても成功率の向上が9.4%にとどまった例を示しています。精度が上がるのは、読み取り中心でサブタスクが独立しているタスクに限られます。まずシングルエージェントで作り、限界を実測してから分割してください。

### エージェントは何体から「マルチエージェント」ですか？

判断する主体が2つ以上あればマルチエージェントです。ただし体数は本質ではありません。重要なのは、独立したコンテキストを持つ主体が何体書き込むかです。レビュー役を1体足しただけでも文脈は分裂しますし、逆に10体が並列に読み取るだけなら書き込みは単線のまま保てます。

### Magentic-Oneは今でも使えますか？

研究プロトタイプのため、新規プロジェクトで単体採用する対象ではありません。実装の入口はMicrosoft Agent Framework（1.0が2026年4月3日にGA、現行1.11.0）で、Magenticはそのオーケストレーションパターンの1つとして選べます。

## 関連記事

- [Agent Development Kit（ADK）とは何か？その定義と役割を詳しく解説](https://www.issoh.co.jp/tech/details/7936/)
- [Strands Agentsとは？AWS製OSSエージェントSDKの使い方・特徴を解説【読み方も】](https://www.issoh.co.jp/tech/details/7199/)
- [Codexサブエージェントとカスタムエージェントの使い方｜TOML定義・config.toml設定・並列実行【2026年7月版】](https://www.issoh.co.jp/tech/details/11463/)
- [BeeAIフレームワークとは何か？IBM発オープンソースのマルチエージェントAI基盤の全貌を徹底解説](https://www.issoh.co.jp/tech/details/8653/)
- [Langfuseとは？読み方・機能・使い方とLangSmithとの違いを解説【2026年最新】](https://www.issoh.co.jp/tech/details/6031/)

---

出典: [シングルエージェントとマルチエージェントの違い｜使い分けの判断基準とコスト・失敗モード【2026年版】](<https://www.issoh.co.jp/tech/details/4261/>)（株式会社一創）