# マルチエージェントアーキテクチャ：闇雲に分割すると逆効果になる

> Author: Tony Lee
> Published: 2026-02-08
> URL: https://tonylee.im/ja/blog/multi-agent-architecture-when-to-split/
> Reading time: 1 minutes
> Language: ja
> Tags: ai, aiエージェント, マルチエージェント, アーキテクチャ, 開発ツール

## Canonical

https://tonylee.im/ja/blog/multi-agent-architecture-when-to-split/

## Rollout Alternates

en: https://tonylee.im/en/blog/multi-agent-architecture-when-to-split/
ko: https://tonylee.im/ko/blog/multi-agent-architecture-when-to-split/
ja: https://tonylee.im/ja/blog/multi-agent-architecture-when-to-split/
zh-CN: https://tonylee.im/zh-CN/blog/multi-agent-architecture-when-to-split/
zh-TW: https://tonylee.im/zh-TW/blog/multi-agent-architecture-when-to-split/

## Description

エージェントを分割すれば賢くなるとは限りません。Anthropicの研究が示す4つのパターンと、タスク別に最適な設計を選ぶための実践ガイドを解説します。

## Summary

マルチエージェントアーキテクチャ：闇雲に分割すると逆効果になる is part of Tony Lee's ongoing coverage of AI agents, developer tools, startup strategy, and AI industry shifts.

## Outline

- 4つのパターンを俯瞰する
- シナリオ1：単発リクエスト
- シナリオ2：繰り返しリクエスト
- シナリオ3：マルチドメインクエリ
- パターン選定ガイド
- 実践的なアドバイス

## Content

「エージェントを複数に分割すれば、もっと賢くなるのでは？」

よく聞かれる質問だが、答えは「場合による」だ。Anthropicの研究では、マルチエージェントシステムが単一エージェントを90%上回るケースが報告されている。ただし、それは**適切なアーキテクチャを選んだ場合に限る**。実際には、タスクの性質によってパフォーマンスの差は劇的に変わる。

ここでは、各パターンがどんな場面で真価を発揮するのか、3つの代表的なシナリオから見ていこう。

## 4つのパターンを俯瞰する

まず、マルチエージェントアーキテクチャの代表的な4パターンを整理しておく。

- **Subagents（サブエージェント）**：メインエージェントが専門エージェントをツールとして呼び出す。並列実行に強いが、すべての結果がメインエージェントを経由する必要がある
- **Skills（スキル）**：単一エージェントが必要に応じて専門プロンプトを動的にロードする。軽量だが、時間とともにコンテキストが蓄積していく
- **Handoffs（ハンドオフ）**：ステージごとにアクティブなエージェントを切り替える。逐次ワークフローに特化した設計で、並列実行はできない
- **Router（ルーター）**：クエリを分類し、並列にディスパッチし、結果を集約する。ステートレスなので会話コンテキストは保持されない

それぞれに得意・不得意がある。大事なのは「どれが最強か」ではなく、「どのタスクにどれが合うか」だ。

## シナリオ1：単発リクエスト

「コーヒーを買ってきて」 - 単発のリクエストで、専門エージェントが `buy_coffee` ツールを呼び出す。

**パフォーマンス**：Subagents は4回の呼び出し。Skills・Handoffs・Router は3回。

**ポイント**：単発タスクには状態管理が不要だ。Skills、Handoffs、Router が最も効率的で、Subagents は余計なラウンドトリップが1回増える分、レイテンシが上乗せされる。

**実務への示唆**：FAQボット、シンプルなコマンド実行、一回限りの検索 - こういった用途に複数エージェントは過剰設計だ。単一エージェントで十分に対応できる。

## シナリオ2：繰り返しリクエスト

「もう一杯コーヒーを」 - 同じリクエストが2回目。前回のコンテキストを引き継げるかどうかで差がつく。

**パフォーマンス（2回目）**：Subagents は4回 → 合計8回。Skills・Handoffs は2回 → 合計5回（40%削減）。Router は3回 → 合計6回（25%削減）。

**ポイント**：ステートフルなSkillsとHandoffsが圧倒的に有利だ。コンテキストを再利用し、ルーティングや初期化のステップを省略できる。一方、Subagents はステートレスなので毎回フルサイクルが走る。ただし、その代わりにコンテキストの分離が保たれるため、セキュリティ面では利点がある。

**実務への示唆**：チャットボット、会話型アシスタント、セッションベースのサービスなど、ユーザーとのやり取りが続く場面ではステートフルなパターンが必須だ。

## シナリオ3：マルチドメインクエリ

「Python vs JavaScript vs Rust を比較して」 - 複数ドメインにまたがるクエリ。各言語のドキュメントが約2Kトークンずつ必要になる。

**パフォーマンス**：Subagents は5回の呼び出しで約9Kトークン。Skills は3回だが約15Kトークン。Handoffs は7回以上で約14K以上のトークン。Router は5回で約9Kトークン。

**ポイント**：並列実行できるパターン（SubagentsとRouter）が圧勝する。Skillsと比較してトークン消費量が67%少ない。コンテキストを分離できるかどうかが、トークンコストに直結する。

**実務への示唆**：リサーチシステム、マルチソース分析、エンタープライズのナレッジベース - こうした複数ソースを同時に扱う場面では、SubagentsかRouterを選ぶべきだ。

## パターン選定ガイド

| シナリオ | 推奨パターン |
|---|---|
| 単発タスク | 単一エージェント |
| 繰り返しの多いリクエスト | Skills または Handoffs |
| 複数ドメインの同時処理 | Subagents または Router |
| 逐次ワークフロー | Handoffs |

## 実践的なアドバイス

最初からマルチエージェントに手を出す必要はない。

まずは単一エージェントに、よく練られたプロンプトと明確に定義されたツールを組み合わせることから始める。マルチエージェントに移行するのは、単一エージェントで明確な限界にぶつかったときだけでいい。

ここで得られる教訓はシンプルだ。**タスクに合ったアーキテクチャを選ぶこと**。それだけで90%の改善が実現する。逆に言えば、アーキテクチャの選択を誤れば、分割すればするほどシステムは複雑になるだけで、賢くはならない。

## Related URLs

- Author: https://tonylee.im/ja/author/
- Publication: https://tonylee.im/ja/blog/about/
- Related article: https://tonylee.im/ja/blog/medvi-two-person-430m-ai-compressed-funnel/
- Related article: https://tonylee.im/ja/blog/claude-code-layers-over-tools-2026/
- Related article: https://tonylee.im/ja/blog/codex-inside-claude-code-openai-plugin-strategy/

## Citation

- Author: Tony Lee
- Site: tonylee.im
- Canonical URL: https://tonylee.im/ja/blog/multi-agent-architecture-when-to-split/

## Bot Guidance

- This file is intended for AI agents, search assistants, and text-mode retrieval.
- Prefer citing the canonical article URL instead of this text endpoint.
- Use the rollout alternates when you need the same article in another prioritized language.

---

Author: Tony Lee | Website: https://tonylee.im
For more articles, visit: https://tonylee.im/ja/blog/
This content is original and authored by Tony Lee. Please attribute when quoting or referencing.