# マルチエージェント移行設計——シングルから3フェーズで進める

> シングルエージェントからマルチへの移行は、ツール数10本超・並列処理要件・権限分離の3条件で判断します。3フェーズの段階的移行手順と失敗パターン4選を解説します。

- Canonical: https://kuucorp.com/blog/single-to-multi-agent-migration-smb/
- Date: 2026-07-10
- Last modified: 2026-07-10
- Publisher: Kuu株式会社 (https://kuucorp.com)

---
AIエージェント1本で業務自動化を始めた企業が、6〜12ヶ月後に「ツール過多・並列対応不可・権限管理の限界」という壁に直面するのは共通したパターンです。「マルチエージェントに切り替えよう」と判断したとき、問題は**どう移行するか**です。単にエージェントを増やすだけでは、エラー伝播とコスト爆発という新たなリスクが発生します。

本記事では、移行を判断するシグナルの見極めから、3フェーズの段階的移行手順、移行失敗パターンの回避策までを解説します。[エージェントガバナンス](/ai-governance/)の視点で、移行設計は一度きりの決断ではなく継続的な設計判断です。

## 移行を検討すべき3つのシグナル

> シングルエージェントは「ツール過多」「並列処理要件の発生」「権限分離の必要」の3条件を超えた時点で移行を検討します。

以下の3つのシグナルが現れたとき、マルチエージェントへの移行を本格的に検討します。

**シグナル1: ツール数が8〜10本を超える**

1エージェントが抱えるツールが増えるほど、正しいツールを選択する精度が下がります。Anthropicの構築指針では、ツールが増えると「ツール選択の誤り・タスク完了の失敗」が起きると明示されています。目安として8〜10本が移行検討の閾値です。

**シグナル2: 並列処理要件が発生する**

「A部署の日報集計」と「B部署の在庫確認」を同時処理したい場合、シングルエージェントでは逐次実行しか対応できません。リードタイムの短縮が業務要件になった時点で、マルチへの移行が投資対効果に見合い始めます。

**シグナル3: 権限を役割単位で分離する必要が生じる**

経費承認フローと顧客データ検索が1エージェントに混在すると過剰権限になりやすく、セキュリティリスクが高まります。権限スコープを役割単位で切り分ける必要が出たとき、それはエージェント境界の再設計を求めるサインです。

## 移行前に試すべき最適化

> 移行前にツール整理・ルーティング追加・プロンプト再設計を試すと、シングルのままで改善できるケースが多くあります。

Anthropicのガイドラインが一貫して強調するのは「**計測可能な改善があるときにのみ複雑さを追加する**」という原則です。移行を決断する前に以下の3点を試してください。

1. **ツール群の整理**: 使用頻度の低いツールを削除し、残りを「読み取り系」「書き込み系」「外部API系」に分類します。ツール定義を整理するだけで選択精度が改善するケースは珍しくありません。
2. **ルーティングの追加**: 入力を「CRM処理」「財務処理」等に分類するルーティングステップを事前に設けると、単一エージェントのままで専門性が向上します。
3. **プロンプトのモジュール化**: 業務別の指示を変数として切り出しておくと、後の分割作業をほぼそのまま引き継げます。移行準備を兼ねた設計です。

これらを試して**なお性能が頭打ち**になった段階で、次のフェーズに進みます。

## 3フェーズの段階的移行手順

> フェーズ1で責任範囲を分解し、フェーズ2でパイロット並列実行を検証、フェーズ3でオーケストレーターを統合します。

### フェーズ1：エージェントの責任を分解する（1〜2週間）

既存の1体エージェントが持つ処理を「役割別マップ」として書き出します。たとえば「顧客対応エージェント」であれば、①FAQ検索・②注文照会・③クレームエスカレーションという3つの責任に分解できます。

各責任を切り分けた場合の**境界線**を決定し、文書化します。Googleの設計指針では「単一エージェントが複数の明確に異なる責任を管理している」ことが移行の判断基準とされており、この文書が後の設計判断の基軸になります。

### フェーズ2：最も独立性の高い責任をパイロット移行する（2〜4週間）

分解した責任の中から、**失敗コストが低く独立性が高い**ものを1つ選び、サブエージェントに切り出します。「シングルエージェント + 1サブエージェント」の構成でパイロット運用し、以下の3点を測定します。

- タスク完了率（シングル構成との比較）
- 応答レイテンシの変化
- トークンコストの増加率（エージェント間通信だけで4倍超になりやすい）

パイロット段階でコスト増加率が許容範囲を大幅に超える場合、境界設計の見直しかシングルの最適化継続を選択します。

### フェーズ3：オーケストレーターを統合する（4〜8週間）

パイロットが成功したら、オーケストレーター（司令塔エージェント）を導入し、複数サブエージェントを制御する構成に移行します。オーケストレーターは「タスクを受け取り、サブエージェントに委譲し、結果を統合する」役割を担います。

この段階では**エラー伝播対策**と**コスト管理**の2点が最も多くの問題を引き起こします。次のセクションで具体的な対策を確認してください。

## 移行で起きやすい失敗パターン4選

> 失敗の多くは「役割境界の曖昧さ」「エラー伝播の設計不足」「コスト見積もりのズレ」の3点に集中します。

**失敗1: 役割の境界が曖昧なままエージェントを増やす**

「リサーチ」と「分析」の境界が不明確なまま実装すると、両エージェントが同じデータを取得してコストが重複します。RACI（責任分担表）を設計段階で先に定義してください。

**失敗2: エラーが連鎖・増幅する設計**

エージェントAの誤出力がエージェントBの入力になると、エラーが複合的に拡大します。マルチエージェント設計の研究では、中央オーケストレーターなしの独立運用でエラー増幅率が約17倍になることが示されています。チェックポイントを必ず設計に組み込んでください。

**失敗3: トークンコストの過小見積もり**

エージェント間のコンテキスト転送だけでトークン消費がシングル比4〜5倍になります。[LLMゲートウェイ](/blog/llm-gateway-routing-rate-limiting/)でのコスト上限設定とレート制限を移行前に組み込んでください。

**失敗4: 可観測性の後回し**

[トレーシング基盤](/blog/agent-observability-tracing-instrumentation/)を設計段階から組み込まないと、障害発生時の原因追跡が困難になります。[エージェントハーネス](/blog/agent-harness-architecture/)の構築と並行して進めることを推奨します。

## 参考

- [Building effective agents | Anthropic](https://www.anthropic.com/engineering/building-effective-agents)
- [Choose a design pattern for your agentic AI system | Google Cloud](https://docs.cloud.google.com/architecture/choose-design-pattern-agentic-ai-system)
- [Multi-Agent Orchestration: Architecture Patterns | Apptad](https://apptad.com/insights/multi-agent-orchestration-architecture-patterns/)

## まとめ

シングルエージェントからマルチへの移行は、時期を読み誤ると設計・運用・コストのすべてで過剰な負担を背負います。3つのシグナルで移行タイミングを判断し、最適化を先に試みたうえで、3フェーズの段階的アプローチで移行するのがリスクの低い手順です。

移行設計の伴走支援は、Kuuの[AI運用管理サービス（AI-Ops）](https://kuucorp.com/services/ai-ops/)にお任せください。エージェント境界の設計からコスト管理・可観測性の実装まで一貫してサポートします。