Strands AgentsのGraph・Swarm・Agents as Toolsを組み合わせてみた
こんにちは。サービス開発室の武田です。
前回の記事ではA2Aパターンについて紹介しました。今回は、これまで紹介してきたパターンを組み合わせる 複合パターン を試してみます。
今回組み合わせるのは次の3つのパターンです。各パターンの詳細はそれぞれの記事を参照してください。
- Agents as Tools - エージェントをツールとしてラップする階層構造
- Graph - 有向グラフによる構造化されたフロー制御
- Swarm - 自律的なhandoffによるエージェント間協調
なぜ複合パターンか
これまで5つのパターンを紹介してきましたが、それぞれに得意・不得意があります。
| パターン | 強み | 弱み |
|---|---|---|
| Agents as Tools | シンプル、モジュール性 | フロー制御なし |
| Graph | ループ・条件分岐、予測可能 | ルーティングの事前定義が必要 |
| Swarm | 柔軟、動的、創発的知能 | 予測困難、エラー処理がエージェント依存 |
| Workflow | 詳細な追跡、並列最適化 | ループ・条件分岐不可 |
| A2A | プラットフォーム独立 | 設定コスト |
実際のユースケースでは、1つのパターンだけでは対応しきれない場面があります。たとえば「企画フェーズでは複数人が自由に協議し、その後は順番に処理を進めたい」というケースです。企画の協議にはSwarmの自律的な対話が向いていますが、全体のフロー制御にはGraphの予測可能性がほしいですよね。
こうした場面で、各フェーズに最適なパターンを選択して組み合わせる のが複合パターンの考え方です。
複合パターンを実現するMultiAgentBase
複合パターンを実現する鍵は、MultiAgentBaseクラスです。
公式ドキュメントでは、Graphについて次のように説明されています。
A Graph is a deterministic directed graph based agent orchestration system where agents, custom nodes, or other multi-agent systems (like Swarm or nested Graphs) are nodes in a graph.
「エージェント、カスタムノード、他のマルチエージェントシステム（SwarmやネストされたGraph） がグラフのノードになる」という点がポイントです。
SwarmはMultiAgentBaseを継承しており、GraphBuilderのadd_node()はMultiAgentBaseを受け付けます。つまり、SwarmをGraphのノードとして直接配置できます。
from strands.multiagent.graph import GraphBuilder
from strands.multiagent.swarm import Swarm
# Swarmを作成
planning_swarm = Swarm(nodes=[editor, marketer, writer], entry_point=editor)
# GraphのノードとしてSwarmを直接渡せる（関数ラップ不要）
builder = GraphBuilder()
builder.add_node(planning_swarm, "planning")
builder.add_node(research_agent, "research")
builder.add_edge("planning", "research")
これにより、パターンの組み合わせが自然に実現できます。
実装例1: シンプルなパイプライン（Graph基本）
まずは複合パターンの基準となる、シンプルなパイプラインから見ていきましょう。すべてのノードが単一のAgentで構成されています。
構造
エージェント定義
企画・調査・執筆・レビューの4つのエージェントを定義しています。各エージェントには出力形式を指定したシステムプロンプトを与えています。
グラフ構築
add_edgeでシーケンシャルな依存関係を定義し、set_entry_pointで開始ノードを指定します。Graphの記事で紹介した基本形と同じですね。
この形がベースラインです。次のステップで、各ノードをSwarmやAgents as Toolsに置き換えていきます。
実装例2: Graph + Swarm
ユースケース
コンテンツ制作で、企画フェーズでは複数の専門家が自由に協議し、その後は順次処理を進めたいケースです。
構造
企画フェーズだけをSwarmに置き換えています。Swarmの自律的なhandoffで、編集者・マーケター・ライターが協議して企画を練ります。
Swarm用エージェント定義
3つのエージェントそれぞれに、次の引き継ぎ先を示唆するシステムプロンプトを与えています。最後のcontent_writerには「他のエージェントには引き継がないでください」と指示して、Swarm内での協議を完了させます。
企画Swarmの構築
Swarmの構築は基本形と同じです。max_handoffs=5、max_iterations=10、execution_timeout=300.0で安全機構を設定しています。
Swarm + Graph統合
ポイントはbuilder.add_node(planning_swarm, "planning")です。SwarmはMultiAgentBaseを継承しているため、add_nodeにそのまま渡せます。残りのノードは単一のAgentです。
実装例1との違いは、企画ノードだけがSwarmに変わった点です。全体のGraphフローは同じまま、企画フェーズの内部で複数の専門家が自律的に協議するようになりました。
実装例3: フル構成（Graph + Swarm + Agents as Tools）
最後に、3つのパターンを組み合わせた完全な複合パターンです。
構造
各フェーズの特性に合わせてパターンを選んでいます。
- 企画 → 自由な協議が必要なので Swarm
- 調査 → 専門家に明示的に委譲するので Agents as Tools
- 執筆 → 単一の処理なのでシンプルなAgent
- レビュー → 複数観点からの評価が必要なので Swarm
企画フェーズ（Swarm）
実装例2と同じ構成です。
調査フェーズ（Agents as Tools）
トレンド分析と事例調査の2つの専門エージェントを@toolでラップし、調査オーケストレーターが使い分けます。Agents as Toolsパターンの記事で紹介した「複数の専門エージェント」と同じ構造ですね。
オーケストレーターのシステムプロンプトで「必ず両方のツールを実行してください」と指示しているのがポイントです。これにより確実に情報収集が行われます。
レビューフェーズ（Swarm）
技術レビュアー・文章レビュアー・最終編集者の3人がSwarmで協調します。企画Swarmと同様の構成ですが、役割が異なります。
全体のGraph構築
4つのノードをGraphで接続しています。2つのSwarm、1つのAgents as Toolsオーケストレーター、1つのシンプルなAgentが、それぞれの特性を活かしながら1つのパイプラインとして動作します。
パターン選択の振り返り
これまで紹介してきた5つのパターンをあらためて整理します。
| パターン | 実行制御 | 強み | 弱み |
|---|---|---|---|
| Agents as Tools | 明示的呼び出し | シンプル、モジュール性 | フロー制御なし |
| Graph | 構造化された条件判定 | ループ・条件分岐・並列実行 | ルーティングの事前定義が必要 |
| Swarm | 自律ハンドオフ | 柔軟、動的、創発的知能 | 予測困難、エラー処理がエージェント依存 |
| Workflow | 事前定義のDAG | 詳細な追跡、並列最適化 | ループ・条件分岐不可 |
| A2A | HTTP通信 | プラットフォーム独立 | 設定コスト |
これらを組み合わせることで、各パターンの弱みを補完できます。
組み合わせの例
| 組み合わせ | ユースケース | 構成イメージ |
|---|---|---|
| Graph + Swarm | 協議フェーズ + 順次処理 | 企画をSwarmで、全体フローをGraphで制御 |
| Graph + Agents as Tools | フロー制御 + 専門家委譲 | 調査フェーズで専門家を明示的に呼び出し |
| Graph + Swarm + Agents as Tools | 複雑なパイプライン | 各フェーズに最適なパターンを選択 |
設計のポイント
フェーズ分解
まずタスクをフェーズに分解し、各フェーズの特性を考えます。
- 自由な議論が必要 → Swarm
- 専門家に明示的に委譲 → Agents as Tools
- 予測可能な順次処理 → Graph / シンプルなAgent
過度な複雑さを避ける
複合パターンは強力ですが、すべてのフェーズにSwarmを使う必要はありません。「このフェーズはシンプルなAgentで十分」という判断も重要です。実装例3でも、執筆フェーズは単一のAgentにしています。
安全機構の設定
Swarmにはmax_handoffsとexecution_timeoutを、Graphにはset_max_node_executionsを設定しましょう。複合パターンでは複数のパターンが組み合わさるため、全体の実行時間が長くなりがちです。各レベルでの安全機構が重要です。
まとめ
複合パターンは、Strands Agentsの 複数のパターンを組み合わせて 実践的なシステムを構築するアプローチです。
SwarmはMultiAgentBaseを継承しているためGraphのノードとして直接配置でき、Agents as ToolsはAgentに組み込むだけで使えます。各フェーズの特性に合わせてパターンを選ぶことで、単一パターンでは難しいユースケースにも対応できます。
公式ドキュメントでは、パターン選択について次のように説明されています。
the most difference you should consider among those patterns is how the path of execution is determined
「実行パスがどう決定されるか」が各パターンの本質的な違いです。複合パターンでは、この基準を各フェーズに適用して最適なパターンを選択します。どなたかの参考になれば幸いです。
