Strands Agentsで学ぶマルチエージェント設計 - パターン選択の判断基準
こんにちは。サービス開発室の武田です。
最近、Strands Agentsというエージェントフレームワークを勉強しています。このフレームワークにはマルチエージェントシステムを構築するためのパターンがいくつか用意されています。複数あるパターンの中から「どのパターンを選べばいいのか」を理解するために整理してみました。
今回は、Strands Agentsの全体像と パターン選択の判断基準 についてまとめます。
Strands Agentsとは
Strands Agentsは、Python製のオープンソースエージェントフレームワークです。
主な特徴は次のとおりです。
- Amazon Bedrock、Anthropic API、OpenAI、Llamaなどさまざまなモデルに対応
- 複数のオーケストレーションパターンを提供
- Bedrock AgentCore Runtimeによりローカル開発からAWS本番環境へシームレスに移行可能
基本的な使い方
もっともシンプルなエージェントは、数行のコードで作成できます。
Bedrockモデルを指定してAgentを作成し、文字列を渡すだけで動作します。
なぜマルチエージェントが必要なのか
単一のエージェントでも多くのタスクをこなせますが、いくつか難しい場面があります。
たとえば長大なコンテキストでは精度が低下しやすいですし、1つのシステムプロンプトで複数の専門性を持たせるのは困難です。また、条件分岐やループを含む複雑なワークフローを単一エージェントで実現するのも難しいですね。
マルチエージェント構成にすると、翻訳・要約・分析などそれぞれに特化したエージェントを用意できます。条件分岐やループを含むワークフローも定義しやすくなりますし、状況に応じてエージェント間で動的に引き継ぐこともできます。
マルチエージェントパターン
Strands Agentsでは、公式ドキュメントで 3つの主要パターン （Graph、Swarm、Workflow）が解説されています。本記事ではこれらに加え、Agents as ToolsとA2Aも含めた5つのアプローチを紹介します。
| パターン | 一言説明 | 実行制御 | ループ | 並列 | エラー処理 |
|---|---|---|---|---|---|
| Agents as Tools | エージェントをツールとして呼び出す | 明示的呼び出し | - | - | - |
| Graph | 有向グラフでフロー定義 | 構造化された条件判定 | ○ | ○ | 開発者が明示的に定義 |
| Swarm | 自律的なhandoffで協調 | 自律ハンドオフ | ○ | - | エージェント依存 |
| Workflow | 決定論的DAGでタスク管理 | 事前定義のDAG | × | ○ | ダウンストリーム全体が停止 |
| A2A | HTTPプロトコルで通信 | リモート呼び出し | - | - | - |
それぞれのパターンの概要を見ていきましょう。
Agents as Tools
エージェントを@toolデコレーターでラップし、別のエージェント（オーケストレーター）から呼び出す階層構造です。
もっともシンプルなパターンで、専門家エージェントに処理を委譲するだけの場合に適しています。
Graph
開発者が定義した有向グラフにしたがってエージェントを実行します。条件関数によるルーティングとループ（サイクル）に対応しています。
公式ドキュメントでは「決定論的有向グラフベースのエージェント編成」と説明されています。グラフ構造に基づいた予測可能な流れで実行され、ノード間でデータを受け渡せます。フィードバックループや反復的なワークフローにも対応しています。
Swarm
複数のエージェントが自律的に協調するパターンです。エージェント自身が文脈を理解して、次の引き継ぎ先を判断します。
公式ドキュメントでは「創発的知能」というコンセプトで説明されています。すべてのエージェントが過去の履歴にアクセスでき、専門性に基づいて引き継ぎ先を自律的に判断します。状況に応じて柔軟に協調できるのも特徴ですね。
Workflow
決定論的なDAG（有向非循環グラフ）でタスクを管理します。依存関係に基づいて並列実行が最適化されます。
公式ドキュメントでは「再利用可能なツールとしてカプセル化すべき、繰り返し可能で複雑な操作」に適していると説明されています。Graphとの違いは、DAGなのでループができないこと、そしてワークフロー全体を1つのツールとして扱える点です。データパイプラインのような固定フローを再利用したい場合に向いています。
A2A （Agent-to-Agent）
HTTPプロトコルでエージェント間通信するパターンです。エージェントをサーバーとして公開し、異なるシステム間での連携を実現します。
マイクロサービスアーキテクチャとの親和性が高く、プラットフォームを跨いだ連携に適しています。
パターン選択の判断基準
どのパターンを選ぶべきかは、公式ドキュメントでも言及されているとおり、実行パスがどう決定されるか がポイントです。
"The critical distinction is how execution paths are determined"
— Strands Agents公式ドキュメント
次のフローチャートを参考にしてください。
フローチャートの分岐ポイントを補足です。
- 動的な判断が必要か？（Graph / Swarmの分岐）
- ルーティングを誰が決めるかという違い
- Swarm: LLMが会話の文脈を理解して、次のエージェントを判断する
- Graph: 開発者がコードで条件を定義し、予測可能なルーティングを実現する
- ループが必要か？固定フローをツールとして再利用したいか？（Graph / Workflowの分岐）
- GraphとWorkflowはどちらも有向グラフでフローを定義しますが、用途が異なる
- Graph: ループ（サイクル）を許容。レビュー→修正→再レビューのような反復処理が可能
- Workflow: DAG（有向非循環グラフ）でループ不可。固定フローを再利用可能なツールとしてカプセル化したい場合に最適
ユースケース別の推奨パターン
| ユースケース | 推奨パターン | 理由 |
|---|---|---|
| 翻訳・要約・分類 | Agents as Tools | 専門タスクへの単純な委譲 |
| コードレビュー→修正サイクル | Graph | ループが必要 |
| カスタマーサポート | Swarm | 問い合わせ内容で動的に振り分け |
| データパイプライン | Workflow | 固定フローを再利用可能なツールとして定義 |
| マイクロサービス連携 | A2A | 異なるシステム間の通信 |
まとめ
Strands Agentsは複数のマルチエージェントパターンを提供しており、それぞれ異なる特性を持っています。Agents as Toolsは専門家への単純な委譲、Graph/Swarm/Workflowは公式の主要パターンで、A2Aはプラットフォーム間通信に使います。
パターン選択のポイントは「実行パスがどう決定されるか」です。条件分岐やループが必要ならGraph、LLMに判断を任せたいならSwarm、固定フローを再利用可能なツールとして定義したいならWorkflowがよさそうですね。
各パターンの詳細な実装例については、別記事で紹介予定です。参考になれば幸いです。
