マルチ Agent システム

マルチ Agent システムは、1 つの Agent にすべてを任せるのではなく、タスクを複数の Agent に分散します。Mastra では通常、Agent、Workflow、またはその両方を組み合わせ、システムの各部分に明確な役割を持たせます。

目的は、適切なコンテキスト、Tool、責任を適切なコンポーネントに割り当てることです。この分担が明確であれば、長いプロンプトや過剰な Tool と責任を抱えた 1 つの Agent よりも、マルチ Agent システムの方が理解しやすくなります。

マルチ Agent システムを使用するタイミング

1 つの Agent では作業範囲を適切に区切れなくなった場合に、マルチ Agent システムを使用します。

よくある例は次のとおりです。

• 調査、計画、執筆、レビューなど、タスクが異なる種類の作業にまたがる。
• 1 つの Agent に必要なコンテキストや Tool が多すぎる。
• タスクの一部を並列実行する必要がある。
• 段階ごとに異なるプロンプト、モデル、ガードレールが必要になる。
• ルーティング、実行、統合の境界を明確にしたい。

可能であれば、まず 1 つの Agent から始めます。構造を追加することで品質、速度、信頼性が明確に向上する場合に、Agent を増やしてください。

マルチ Agent パターンは、コンポーネント間でコンテキスト、判断、責任を明確に分担する必要があるシステムに有効です。実際の設計では、タスクの進行中にどのコンポーネントが制御を維持するかが重要です。

Handoff

Handoff パターンでは、制御を 1 つの Agent から別の Agent へ移します。Supervisor パターンとは異なり、最初の Agent がタスク全体を指揮し続けることはありません。代わりに、現在の Specialist がやり取りの次の部分を引き継ぎます。

次の Specialist が中央の Coordinator を介して報告するのではなく、やり取りを直接続けるべき場合に Handoff を使用します。一方で、次の Agent が何を引き継ぎ、何を範囲外とするかをシステムが判断する必要があるため、コンテキスト管理がより重要になります。

Mastra では、Agent、Workflow、Memory を組み合わせてこのパターンを実装します。Workflow でタスクをルーティングできますが、このパターンの本質は、担当が次の Agent に移ることです。

Workflow

Workflow パターンでは、実行経路をコードで定義します。次の動作を Agent に判断させるのではなく、Step、分岐、ループ、並列ブロックで順序を定義します。

タスクの内容が十分に理解され、実行経路があらかじめ分かっている場合に Workflow を使用します。主な利点は予測可能性です。明示的な構造により、システムのデバッグと監査が容易になります。一方で、タスクが進行中に変化した場合は適応しにくく、柔軟性が下がります。

Mastra の Workflow では、Handoff や Council などの連携パターンを実装できます。呼び出す Agent にかかわらず、制御ロジックが Workflow 自体に含まれる点が Workflow の特徴です。

Supervisor

Supervisor パターンでは、1 つの Lead Agent がタスク全体を制御し続けます。Supervisor は、委任のタイミング、呼び出す Specialist、渡すコンテキスト、結果の統合方法を決定します。

タスクが自由形式で、全体の順序があらかじめ分からない場合にこのパターンを使用します。たとえば調査タスクでは、前段階で判明した内容に応じて、異なる観点からの調査が必要になることがあります。Supervisor はタスクの進行に合わせて適応できます。 一方で、Supervisor が連携の中心になるため柔軟性は高いものの、結果は適切な委任と明確な Subagent の境界に大きく左右されます。

Mastra では、このパターンは Supervisor Agent に直接対応します。Supervisor Agent は agents プロパティに Subagent を定義し、stream() または generate() で連携させます。Mastra は、このパターンの制御に役立つ委任フック、メッセージフィルタリング、Memory 分離も提供します。

ヒント

手順については、Supervisor Agent チュートリアルを参照してください。

Council

Council パターンでは、複数の Agent が同じ問題に個別に取り組み、その出力を比較または統合して 1 つの最終回答を作成します。問題を分割する Supervisor とは異なり、Council は同じ問題を共有し、同じ問いに複数の視点を取り入れます。

問いが曖昧、評価的、または重大で、速度より回答品質を重視する場合にこのパターンを使用します。一方で、Council は意図的に作業を重複させるため、通常は他のパターンより時間とトークンを多く使い、コストが高くなります。

Mastra には Council 専用のプリミティブはありません。Agent と Workflow を使ってこのパターンを実装します。複数の Agent を並列実行して出力を収集し、最後に統合またはレビューする Step を追加します。.parallel() などの Workflow 制御フローメソッドが、このパターンの構造を提供します。

パターンを選択する

これらのパターンは、主に制御の分担方法が異なります。

パターン	制御を維持する主体	使用する場合	トレードオフ	Mastra での実装
Handoff	現在の Specialist	Specialist 間で担当を移す必要がある	コンテキストの引き継ぎがより重要になる	Workflow と Memory を組み合わせた Agent
Workflow	実行グラフ	経路があらかじめ分かっている	タスクの変化に適応しにくい	Workflow
Supervisor Agent	1 つの Lead Agent	実行中に委任を調整する必要がある	結果は適切な連携と明確な境界に左右される	Supervisor Agent
Council	最終統合 Step	複数の独立した視点が必要なタスク	コストとレイテンシが増える	Workflow の並列処理を使った Agent

実際には、これらのパターンを組み合わせることもよくあります。

• Workflow に、Supervisor が主導する Step を 1 つ以上含める。
• Handoff フローをルーティング Workflow から開始する。
• Council を Workflow 内で実行し、その結果を最終承認 Step に渡す。
• Supervisor が、内部構造の固定されたタスクを Workflow に委任する。

タスクのラベルではなく、連携上の課題に基づいてパターンを選択してください。