主要フレームワークは「制御フローの持ち方」で5系統に大別できる。重要なのは機能数ではなくどの設計思想が自分のタスクに合うかだ。
| フレームワーク | 設計思想（型） | 強み | 選定基準 |
|---|---|---|---|
| LangGraph | グラフ型（状態機械） | 可観測性・タイムトラベルデバッグ・中断再開・人間承認・監査 | 明示的制御フローと状態永続化・監査が要る本番 |
| CrewAI | 役割/プロセス型＋Flow | 役割×タスクの直感的抽象で立上りが速い | 業務をロール分担にマッピングしたい |
| AutoGen / AG2 | 会話型（GroupChat） | 探索的・ブレスト的タスクに柔軟。Magentic-Oneの再計画 | フローを固定しづらい研究的・汎用問題解決 |
| OpenAI Agents SDK / Swarm | handoff型（関数移譲） | API表面が極小・低レイテンシ・高い透明性 | 少〜中規模（〜8前後）の専門家ルーティング |
| Google ADK | ワークフロー型（決定論＋LLM） | 決定論で予測可能・テスト容易・A2A/MCP統合 | 「順次→並列→反復」に分解できる本番 |
| Microsoft Agent Framework | データフロー型グラフ | 並行・型安全・テレメトリ・ミドルウェア（1.0 GA） | エンタープライズ要件（型安全・.NET） |
| Claude Agent SDK | orchestrator-worker型 | コンテキスト隔離で main の肥大・汚染を防ぐ。深掘り調査に強い | 独立分割できる探索・調査・収集 |
トポロジ→要件の逆引き: 監査・人間承認・再現性が要る→グラフ型（LangGraph / MS Agent Framework / ADK）。探索的・創発を活かす→会話型（AutoGen）。少数の専門家へ低レイテンシで振り分け→handoff型（OpenAI Agents SDK）。独立サブタスクを並列・コンテキスト隔離で→orchestrator-worker（Claude Agent SDK）。異種ベンダー連携→A2Aプロトコル層を併用。
単一→マルチへ拡張する判断は単純だ。まず単一エージェントで詰める→ボトルネックを計測（コンテキスト肥大？逐次レイテンシ？専門性不足？越境連携？）→読み取り中心で独立分割できるならマルチ化、最小構成（supervisor＋数ワーカー）から。そして実運用で最も効くのが、各ステップに作業Agent＋Review Agentをペアで置く構成だ。
ファイル経由handoffには、第2回で触れた圧縮要約の弱点（不可逆な情報損失）を原本ファイル参照で相殺できるという利点もある。.work/<team>/ に成果物を残し、必要なら原本に立ち返れる。古いファイルの破棄/圧縮ポリシーも設計に含めておく。
全エージェントに最上位モデルを使うのは無駄だ。タスクの重さで振り分ける。
探索 / 検索 / 単一ファイル編集 / ドキュメント # → 軽量モデル（Haiku級）
マルチファイル実装 / オーケストレーション # → 中位（Sonnet級）
アーキ決定 / セキュリティレビュー / 複雑デバッグ # → 最上位（Opus級）
# Planner-Executor なら「重い計画＝Opus級、実行＝軽量」で分離Berkeley らの「Why Do Multi-Agent LLM Systems Fail?」（MAST, arXiv:2503.13657）は、初の経験的失敗分類を提示した。14モード × 3カテゴリに整理される。
重要な含意は、失敗が単一原因に偏らず、上流の「仕様・役割・検証」の弱さに起因すること。だから図1の作業＋レビューのペアが効く——カテゴリ③（検証の欠如）への直接の処方箋になっている。対策は戦術的（プロンプト改善・役割明確化・自己検証）と構造的（標準通信プロトコル・記憶管理・検証機構）の二層で打つ。
A2Aは仕様だけでは ID 検証・注入耐性が不足する。最大の弱点は、エージェント間通信を「信頼された内部」と誤認することだ。外部データ（Web/メール/RAG/ツール出力）に紛れた指示が、A2A経由で無検査に多hop伝播する——これが間接プロンプトインジェクション＝信頼境界の問題。根本原因は instruction と untrusted data を同じコンテキスト窓で等価に扱うことにある。
補強の柱は4つ。(1) ID確立（A2Aはアイデンティティをトランスポート層で扱い mTLS＋OAuth2 を併用。SPIFFE/SPIRE で短命SVID）、(2) 権限委譲（RFC 8693 Token Exchange で act クレームに委譲チェーンを表現し各hopで最小権限化）、(3) 信頼境界（コンテンツ正規化・spotlighting・隔離LLM）、(4) 攻撃連鎖の封じ込め（最小権限ツールスコープ＋承認ゲートでブラスト半径限定）。脅威モデリングの共通言語として MAESTRO や OWASP Agentic Security Initiative（ASI Top10）も押さえておく。
分散したエージェントは「どこで誤りが生まれたか」が見えないと運用できない。OpenTelemetry GenAI Semantic Conventions でスパンツリーに計装する——トップに invoke_agent、子に各LLM呼び出しの chat、各ツールの execute_tool。trace_id で「誰が誰を呼び、どこで壊れたか」を再構成できる。受け皿は LangSmith（軌跡採点）／ Langfuse（OSS・OTel）／ Arize Phoenix（OSS・ドリフト検知）。
回復の基盤はリトライ＋指数バックオフ＋ジッタ／サーキットブレーカ／安価モデルへのフォールバック。MAS特有の注意は「リトライ嵐」——10並列×10リトライ＝死んだサービスへ100リクエストの協調DoS。ブレーカは個別呼び出しでなくサービス単位で共有する。そして停止規則（stop rule）を必ず置く: ループ検知・トークン/リトライ予算を安全機構にし、「これ以上安全に前進できないと証明できたら止める／人間判断が要るなら昇格する」。従来型ブレーカはタイムアウトは拾えてもハルシネーションや推論ループは拾えないので、意味的ガードレール（検証ゲート・ループ検知）を別途置く。
n²·T。→ 子の返却上限・スター/疎トポロジ・予算ガードレール。