Shuichiro Ogawa

Notes ・ updated 2026-07-01

エージェンティックコーディング：オーケストレーションパターンの現在地（2026）

2026年半ば、エージェンティックコーディング（LLM エージェントによるソフトウェア開発）のオーケストレーションは急速に収斂しつつある。 Anthropic、OpenAI、Google、Microsoft、Amazon の各社がマルチエージェント・フレームワークを本番投入し、設計上の共通課題と分岐点が明確になった。

本ノートでは、エージェント間通信のパターン、オーケストレーション・アーキテクチャ、主要フレームワークの設計思想、収束しつつあるベストプラクティスを整理する。

関連: design-agent-tools-landscape-2026（デザインエージェントツール）／agentic-experience-design-synthesis（AX とデザイン）／mcp-design-agent-integration（MCP 統合）／multi-agent-end-user-value（マルチエージェントの価値）。

エージェント間通信の5パターン

エージェント同士がどう情報をやりとりするかの設計選択は、システム全体の性能・コスト・デバッグ容易性を規定する。 2026年時点で実用されているパターンは5つに整理できる。

1. 階層型（Supervisor / Tool-Mediated）

親エージェント（オーケストレータ）が子エージェントを「ツール」として呼び出し、結果を集約する。 子同士は直接通信しない。

独立に分解できるサブタスクに向く。 品質ゲートを親が一元管理でき、子の失敗時にリトライやフォールバックが容易である。 子のコンテキストが最小化されるため、各子は専門に集中できる。

親がボトルネックになる（全通信が経由する）。 多数の結果を統合すると親のコンテキストウィンドウが飽和しやすい。 深いネストはレイテンシと情報損失を増やす。

Claude Code（Agent tool）、Claude Managed Agents（coordinator-worker）、OpenAI Agents SDK（agent-as-tool）、LangGraph（supervisor node）、CrewAI（hierarchical process）、Google ADK（AgentTool）、Amazon Bedrock（supervisor mode）、MS Agent Framework（MagenticOrchestration）が採用している1234。

2. ハンドオフ（Transfer）

一方のエージェントが会話の制御権と全履歴をもう一方に渡す。 バトンリレー方式で、同時に制御を持つのは1エージェントだけである。

会話中にドメイン専門性が切り替わる場面（カスタマーサポートの部門ルーティングなど）に向く。 会話の文脈が途切れず、実装もシンプルである。

並列処理ができない（線形）。 誤ルーティングでループや行き止まりが生じうる。 全履歴を渡すためコンテキストウィンドウを圧迫する。 複雑な依存構造には向かない。

OpenAI Agents SDK が handoff() を一級プリミティブとして定義した点が特徴的で、このパターンの代表的実装である。 前身の OpenAI Swarm（transfer_to_agent）、LangGraph（条件付きエッジ）、MS Agent Framework（HandoffOrchestration）も対応する25。

3. 共有状態（Blackboard）

複数エージェントが共有の状態オブジェクトを読み書きする。 エージェント間の直接メッセージはなく、データ構造の変更を通じて間接的に通信する。

複数エージェントが同じデータ構造を段階的に充実させる場面、疎結合にしたい場面に向く。 エージェント間の結合度が低く、新エージェントの追加が容易である。 部分的な結果が即座に全体から見える。

状態の競合と整合性の管理が必要になる。 誰がいつ何を書いたかのデバッグが難しい。 並列実行時のスレッド安全性を考慮する必要がある。

LangGraph の StateGraph がこの抽象の中核で、フレームワーク全体がこのパターンの上に構築されている。 CrewAI（Flow の Pydantic モデル、スレッドセーフなプロキシ）、Google ADK（InvocationContext.session.state）も対応する3。

4. メッセージパッシング（Chat-Based）

エージェントがテキストメッセージを直接やりとりする。 グループチャット（全員が全メッセージを見る）またはペアワイズ通信で、発言順はマネージャかラウンドロビンで決定する。

レビュー、批評、合意形成、多視点分析に向く。 自然言語による柔軟なやりとりが可能で、議論的タスクに適する。

トークン消費が大きい（全エージェントが全メッセージを読む）。 制御が難しく（終了条件の設計が必要）、スケールしにくい。 収束しないリスクがある。

AutoGen/AG2 の GroupChat がこのパターンの代表で、MS Agent Framework（GroupChatOrchestration）も対応する67。

5. コンテキスト隔離＋要約返却（Isolated Context）

各サブエージェントが独立のコンテキストウィンドウで動作し、最終的な要約テキストだけを親に返す。 中間ステップ（ツール呼び出し、推論過程）は親から見えない。 階層型と重なるが、「何を隠すか」の設計選択が核心である。

サブエージェントの探索が広範で、中間ステップが親のコンテキストを汚染する場面に向く。 親のコンテキスト蓄積を防止でき、並列サブエージェントが互いに干渉しない。 信頼境界のリセット（子は親の権限を継承しない）も利点になる。

要約時の情報損失がある。 子の推論過程を親から観察できず、デバッグには別途トレーシングが必要になる。 必要なコンテキストをすべてプロンプトで明示的に渡す必要がある。

Claude Code / Claude Agent SDK がこのパターンを主要設計原理としている。 サブエージェントは新鮮な会話で起動し、最終メッセージだけが返る。 Claude Managed Agents も各エージェントを隔離セッションスレッドで実行し、プライマリスレッドには凝縮された活動概要だけを表示する89。

オーケストレーション・アーキテクチャ

通信パターンの上に、タスク全体をどう構造化するかのアーキテクチャが乗る。

アーキテクチャ概要向いている場面主な欠点
パイプライン固定順序のステップ連鎖。各ステップの出力が次の入力になる順序が自然に決まるタスク。ステップ間にゲートチェックを挟めるレイテンシ蓄積。後段が前段に影響できない
ファンアウト/ファンイン独立サブタスクを並列実行し集約。同一タスク複数回実行（投票）の変形もある独立タスクのレイテンシ削減。冗長性による信頼性向上集約ロジックの設計が必要。コストは並列数に線形
ルーター入力を分類し専門エージェントへ振り分け入力タイプで処理が根本的に異なる場合ルーティング精度がシステム性能を決定する
DAG依存関係をグラフで表現し、依存が解決済みのノードから実行複雑な依存関係と部分並列が必要な場面動的タスク追加が困難。設計が複雑
オーケストレータ-ワーカー中央の LLM がタスクを動的に分解しワーカーに委譲分解自体が入力依存で予測不能な場面コスト予測困難。オーケストレータの能力に依存
評価-最適化ループ生成→評価→フィードバック→再生成の反復明確な評価基準がある反復改善コスト/レイテンシ蓄積。収束保証なし
議論/敵対的複数エージェントが異なる立場で議論し結論品質を高める判断品質の最大化。多視点分析トークンコスト高。収束しないリスク

Anthropic は「プロンプトチェイニング（パイプライン）」「ルーティング」「並列化（ファンアウト/ファンイン）」「オーケストレータ-ワーカー」「評価-最適化」の5つをワークフロー/エージェントパターンとして整理している1。

設計上の根本的な対立軸

モデル駆動 vs フレームワーク駆動

モデル駆動（Claude Agent SDK、AWS Strands）はフレームワークの判断ロジックを最小化し、モデル自身の推論・計画・ツール呼び出し能力にワークフローを委ねる。 Claude Code のコードベース分析（arXiv 2604.14228）によると、AI 判断ロジックはコード全体の1.6%で、残り98.4%は権限管理・コンテキスト制御・ツール実行・エラー回復のインフラである10。

フレームワーク駆動（LangGraph、Google ADK Workflow Agents）は制御フローをグラフや DAG としてコードで明示的に定義する。 ルーティングロジックは Python コードにあり、LLM プロンプトにはない。

タスクが予測不能なときはモデル駆動が優位で、信頼性と監査可能性が必要なときはフレームワーク駆動が優位になる。 どちらかが普遍的に正しいわけではない。

コンテキスト戦略: 隔離 vs 共有

方式代表特徴
隔離Claude Agent SDKサブエージェントに新鮮なコンテキスト。中間ステップは親から不可視。コンテキスト蓄積を解決するが情報損失がある
全履歴共有OpenAI ハンドオフハンドオフ時に全会話履歴を転送。文脈の連続性は最大だがコンテキスト圧迫が増す
構造化共有LangGraph StateGraph共有する状態を型付きで明示的に定義。中間的な選択だがスキーマ設計が必要

Anthropic のマルチエージェント研究システム（Opus 4 がリード、Sonnet 4 がワーカー）の実測データは、この対立軸に定量的な指針を与える。 単一エージェント比で性能が90.2%向上したが、トークン消費は約15倍で、性能向上の80%はトークン支出で説明できた9。 並列サブエージェント間のプロンプトキャッシュ共有により、5並列エージェントのコストは逐次実行とほぼ同等になるという設計上の工夫がある8。

主要フレームワークの設計思想

Claude Code / Claude Agent SDK / Claude Managed Agents

Anthropic は「単純に始め、単一エージェントの限界が証明されてからマルチにする」を明示的に推奨している1。

3層のマルチエージェント支援を提供する。 CLI レベル（Claude Code の Agent tool）、SDK レベル（Claude Agent SDK の AgentDefinition、ツール制限、モデルオーバーライド、5階層ネスト）、API レベル（Claude Managed Agents、最大20種のエージェント、25並行スレッド、共有サンドボックス/ファイルシステム/ボールト）である811。

設計の核心はコンテキスト隔離である。 サブエージェントの中間ツール呼び出しと推論はそのコンテキスト内にとどまり、最終メッセージだけが返る。 「コンテキスト蓄積」（マルチエージェントシステムの最大の実用上の問題）をアーキテクチャレベルで解決している。 ピアツーピア通信は現時点では未対応で、feature request が出されている12。

OpenAI Agents SDK

「少数のプリミティブで十分な能力」を設計方針とする。 Agent、Handoff、Guardrail、Tracing の4概念で構成される2。

ハンドオフを一級プリミティブとした点が設計上の最大の特徴である。 Agent A が Agent B にハンドオフすると、全会話履歴が転送され、B は最初から会話に参加していたかのようにコンテキストを参照できる。 Anthropic のコンテキスト隔離とは根本的に異なる設計選択である。

前身の Swarm は実験的/教育的フレームワークで、routines（instructions + tools）と handoffs の2概念だけで構成されるステートレス設計だった。 本番利用は推奨されていない5。

LangGraph

グラフベースの状態機械を設計方針とする。 制御フローをノードとエッジとして明示的に定義し、ルーティングロジックは Python コードで書く3。

StateGraph が中核で、ノード（状態を受け取り更新を返す Python 関数）、エッジ（固定または条件付き遷移）、Command（状態更新＋ルーティング指令の複合）、サブグラフ（階層的合成）、interrupt()/Command(resume=...) による human-in-the-loop を提供する。

本番向け機能（チェックポイント/永続化、ストリーミング、監査証跡、ロールバック、LangSmith 連携）が最も成熟している。 ベンチマークでは主要フレームワーク中で最もレイテンシが低いとされ、CrewAI と比較して「マネジメントオーバーヘッド」によるトークン消費が約3分の1である13。

CrewAI

ロールベースのエージェント協調を設計方針とする。 Agent（role + goal + backstory + tools）、Task（description + expected_output + assigned agent）、Crew（Agent と Task のコンテナ、プロセスタイプ指定）で構成される14。

プロトタイピングの速度は最速である。 ロールベースの設計は直感的で、アイデアからプロトタイプまでの距離が短い。

本番投入には課題がある。 チェックポイントが組み込まれていない。 エージェント間通信の粒度が粗い。 hierarchical プロセスは循環委任やドリフトを生じることがある。 LangGraph 比で約3倍のトークン消費が報告されている13。

実務者コミュニティでは「CrewAI でプロトタイプし、LangGraph で本番化する」という移行パスが定着しつつある。

Microsoft Agent Framework 1.0

2026年4月に GA となった、AutoGen と Semantic Kernel の統合フレームワークである。 エンタープライズ向けマルチエージェントオーケストレーションを目指し、.NET と Python のクロスランタイムで動作する7。

5つのオーケストレーションパターン（Sequential、Concurrent、GroupChat、Handoff、Magentic）を公式に提供する。 元の AutoGen はメンテナンスモード（バグ修正のみ）に移行し、コミュニティフォークの AG2 が独立して開発を継続している6。

Google ADK

コードファースト、Google 社内製品（Agentspace、CES）と同一フレームワークを設計方針とする。 AgentTool（エージェントを別エージェントのツールとしてラップする）を sub_agents 委譲より推奨し、ルートエージェントが制御を保持する設計を重視している4。

Google の A2A（Agent-to-Agent）プロトコルをネイティブに対応する点がユニークで、フレームワーク横断・言語横断のエージェント相互運用を目指している。 SequentialAgent、ParallelAgent、LoopAgent の3つのワークフローエージェントを提供する。

AWS Strands Agents SDK

モデル駆動アプローチを採用し、Claude Agent SDK と設計思想が近い。 フレームワークがワークフローを規定せず、モデルの計画・推論・ツール呼び出し能力に委ねる。 2026年に v1.0 GA、1,400万ダウンロード超を達成した15。

Mastra

TypeScript ネイティブのエージェントフレームワークで、Y Combinator W25、2026年4月に3,500万ドル調達、週30万ダウンロード超。 グラフベースのワークフローエンジン（.then()、.branch()、.parallel()）、durable agent（クライアント切断に耐える）、イベントシステム（Redis Streams / Google Cloud Pub/Sub）を提供する16。

通信プロトコル: MCP と A2A

エージェント間の通信標準として、MCP と A2A が相補的な役割を担いつつある。

MCP（Model Context Protocol）はエージェントからツール/リソースへのアクセスを標準化する。 ステートレスなリクエスト-レスポンスが基本で、DB、API、ファイルシステムへの接続に使う。

A2A（Agent-to-Agent Protocol、Google 提案）はエージェント間のタスク委譲と複数ステップの協調を標準化する。 タスク状態、メモリ、コンテキストを持つステートフルな設計である。

標準的なアーキテクチャは、エージェント間の通信に A2A、各エージェントが内部でツールにアクセスする際に MCP を使う構成になりつつある。

収束しつつあるベストプラクティス

以下の7点は、Anthropic、OpenAI、実務者コミュニティで広く合意されている。

単一エージェントで限界を証明してからマルチにする。 最も強い合意点である。 単一エージェント＋良質なツールで大半の問題は解決できる。 マルチエージェントは、単一エージェントの限界が証明された場合にのみ導入する1。

ワークフロー（固定フロー）をエージェント（動的フロー）より優先する。 Anthropic の明示的な階層: プロンプトエンジニアリング → ワークフロー（パイプライン/ルーター/ファンアウト）→ 自律エージェント。 自律エージェントは、タスク分解自体が予測不能な場合の最後の手段である1。

各エージェントのコンテキストを最小化する。 必要な情報だけを渡す。 無関係な情報はモデルの注意を散らし、コストを増やす。 大きなコンテキストウィンドウがあっても、この原則は変わらない。

ツール設計がエージェント能力を決定する。 明確な説明、情報量のあるエラーメッセージ、使いやすい API。 単一エージェントにもマルチエージェントにも等しく当てはまる1。

可観測性を最初から組み込む。 トレーシング、ロギング、各エージェントの入出力記録は必須である。 可観測性なしのマルチエージェントのデバッグは現実的に不可能である。 OpenAI Tracing、LangSmith、Claude Code JSONL トランスクリプトなどが実用されている。

明確な終了条件を定義する。 あらゆるエージェントループとマルチエージェント相互作用に、最大ターン数、最大トークン数、収束検出、人間承認のいずれかを設定する。 無制限ループが最も多い障害モードである。

ステップ間にゲートチェックを置く。 パイプラインやオーケストレータ-ワーカーで、中間出力を検証してから次ステップに渡す。 障害を早期に捕捉し、不良な出力がシステム全体に伝播するのを防ぐ。

既知のアンチパターン

エージェント過多。 エージェント数は品質に線形相関しない。 追加ごとにコスト、レイテンシ、デバッグ複雑性が乗算的に増える。 各エージェントの追加に具体的な正当化が必要である。

早すぎるマルチエージェント化。 単一エージェントの能力を使い切る前にマルチに手を出す。 改善幅が複雑性コストに見合わないことが多い。

フレームワークへの過適合。 タスクをフレームワークの抽象に合わせて歪める。 Anthropic の明示的警告: 「フレームワークは下層の API 呼び出しを隠蔽し、デバッグを困難にし、モデル能力の完全な活用を妨げうる」1。

コンテキスト肥大。 全エージェントに全情報を渡す。 コンテキストが多いほど性能が上がるわけではない。 注意の拡散、コスト増大、品質低下を招く。

暗黙の状態共有。 グローバル変数やファイルシステムの暗黙的な規約を通じた通信。 競合状態とデバッグ困難を招く。 共有は明示的な機構（共有状態、メッセージパッシング）で行う。

自律への過信。 人間のチェックポイントなしにエージェントに過大な判断を委ねる。 高リスク操作（ファイル削除、外部 API 呼び出し、デプロイ）では危険性が高い。

フレームワーク比較

Claude Code/SDKOpenAI Agents SDKLangGraphCrewAIMS Agent Framework
通信コンテキスト隔離+要約ハンドオフ（全履歴）共有状態タスク委譲5パターン選択可
制御フローモデル駆動モデル駆動グラフ明示ロール駆動ハイブリッド
トークン効率高（キャッシュ共有）中最高低（約3倍）中
本番投入度高高最高中高
学習コスト低低中〜高低中
言語TypeScript/PythonPythonPython/JSPython.NET/Python

パターン選択の判断フロー

  1. タスクを固定ステップに分解できるか → パイプライン。独立して並列化できるステップがあれば＋ファンアウト/ファンイン。
  2. 入力タイプで処理が根本的に異なるか → ルーター → タイプ別の専門パイプライン/エージェント。
  3. サブタスクが入力に依存して動的に決まるか → オーケストレータ-ワーカー。反復的な品質改善が必要なら＋評価-最適化ループ。
  4. 多視点分析が必要か → 議論/敵対的。
  5. 上記のいずれにも該当しない → 単一エージェント＋ツールで十分（マルチ不要）。

大半のタスクは1と2の組み合わせで処理できる。3以降に進む前に、1と2の限界を確認する。

出典

Footnotes

  1. Anthropic. “Building effective agents.” 2024-12. https://www.anthropic.com/research/building-effective-agents ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  2. OpenAI Agents SDK. https://openai.github.io/openai-agents-python/ ↩ ↩2 ↩3

  3. LangGraph documentation. https://langchain-ai.github.io/langgraph/ ↩ ↩2 ↩3

  4. Google ADK. https://developers.googleblog.com/en/agent-development-kit-easy-to-build-multi-agent-applications/ ↩ ↩2

  5. OpenAI Swarm (experimental). https://github.com/openai/swarm ↩ ↩2

  6. AutoGen / AG2 documentation. https://microsoft.github.io/autogen/ / https://docs.ag2.ai/ ↩ ↩2

  7. Microsoft Agent Framework 1.0. https://learn.microsoft.com/en-us/agent-framework/ ↩ ↩2

  8. Claude Agent SDK: Subagents. https://code.claude.com/docs/en/agent-sdk/subagents ↩ ↩2 ↩3

  9. Anthropic. “How we built our multi-agent research system.” https://www.anthropic.com/engineering/multi-agent-research-system ↩ ↩2

  10. Claude Code architecture analysis. arXiv 2604.14228. https://arxiv.org/html/2604.14228v1 ↩

  11. Claude Managed Agents: Multi-Agent Sessions. https://platform.claude.com/docs/en/managed-agents/multi-agent ↩

  12. GitHub: Agent-to-Agent Communication feature request. https://github.com/anthropics/claude-code/issues/4993 ↩

  13. Multi-Agent Orchestration: Supervisor vs Swarm (DEV Community). https://dev.to/focused_dot_io/multi-agent-orchestration-in-langgraph-supervisor-vs-swarm-tradeoffs-and-architecture-1b7e ↩ ↩2

  14. CrewAI documentation. https://docs.crewai.com/ ↩

  15. Strands Agents SDK 1.0. https://aws.amazon.com/blogs/opensource/introducing-strands-agents-1-0-production-ready-multi-agent-orchestration-made-simple/ ↩

  16. Mastra. https://mastra.ai/ ↩

← Notes 一覧 ・ ホーム