スーパーバイザーエージェント
スーパーバイザーエージェントは、専門化されたサブエージェントのチームを管理する永続的なコーディネーターです。会話の状態を読み取り、次にどのスペシャリストが動作すべきかを決定し、メッセージをルーティングし、返された結果を統合して目標に向かって進めます。ワンショットのデコンポーザー（分解器）とは異なり、スーパーバイザーは多数のターンにわたってループ内にとどまり、機能ごとに委任し、タスクが完了するかユーザーに返されるまで再計画を行います。
課題
単一のエージェントに多数のツール、指示、ドメインを与えると、焦点が定まらなくなります。プロンプトが肥大化し、ツール選択の精度が低下し、無関係な関心事を混同してしまいます。実際のワークフローでは、ステップごとに異なる専門知識（調査、コーディング、請求、コンプライアンスなど）が必要になりますが、単一のフラットなエージェントでは、適切なタイミングで適切な機能を確実に選択したり、長期にわたるマルチステップのやり取りの一貫性を維持したりすることは困難です。
適用対象
作業が、マルチターンの会話やループにわたって連携する必要がある複数の明確で再利用可能なスペシャリスト機能に及ぶ場合、ルーティングの決定が固定された計画ではなく変化する状態に依存する場合、そしてポリシーの適用、ハンドオフの管理、どのエージェントが何を行ったかの監視を行うための明確で中央集権的な場所が必要な場合に、スーパーバイザーを使用します。これは、均一な並列ワーカーよりも、異種混合のエージェントチームに適しています。
解決策
スーパーバイザーは、制御ループと共有会話状態を所有します。各ターンで最新のメッセージと目標を検査し、直接回答するか、指定されたスペシャリストに委任するか、または終了するかを決定します。委任は機能ごとに行われます。各サブエージェントには宣言されたスコープ（例：コードエージェント、データエージェント、ナレッジエージェントなど）があり、スーパーバイザーはコンテキストの関連するスライスを選択されたエージェントにルーティングします。スペシャリストは、自身の焦点を絞ったツールループを実行し、結果または明確化の要求を返します。スーパーバイザーはそれを記録した上で、次のステップを決定します。
スペシャリストの各ターンの後、制御はスーパーバイザーに戻るため、エージェント同士が自由に呼び出し合うのではなく、スーパーバイザーが唯一の決定ポイントであり続けます。スーパーバイザーは、部分的な結果を統合し、スペシャリスト間の競合を解決し、目標が達成されたタイミングを判断し、ユーザーに引き渡すタイミングを決定します。ステップ予算、遷移許可ルール、明示的な終了条件などのガードレールにより、ループの無限循環を防ぎます。構造化されたハンドオフメッセージと共有トレースにより、すべての委任が監査可能になり、チームは誰が何をなぜ依頼されたかを確認できます。
コンポーネント
メリット
- より小さくクリーンなプロンプトを持つ、焦点を絞ったスペシャリスト
- 中央集権的なルーティングとポリシー適用
- 独立して進化できるモジュール式エージェント
- 誰が何を行ったかの明確な監査トレイル
リスク
- 無限ループまたはピンポンハンドオフ（往復）ループ
- 調整オーバーヘッドによるレイテンシとコストの増大
- スーパーバイザーがルーティングのボトルネックになる
- ハンドオフ間のコンテキスト喪失による品質低下
非推奨のケース
- 単一の機能でタスク全体を処理できる場合
- 固定された並列ファンアウト（オーケストレーター・ワーカー）の方が適している場合
- レイテンシやコストの予算により、余分なホップが許容されない場合
テクノロジー
事例
- 請求、技術、アカウントのスペシャリスト間にまたがるカスタマーサポートのルーティング
- コーディング、テスト、ドキュメント作成のエージェント間で分割されたソフトウェアタスク
- 検索、分析、執筆のエージェントに委任するリサーチアシスタント
KPI
- タスク成功率 / 目標達成率
- 人間の介入なしに意図した成果に達したセッションの割合。スーパーバイザーチームの主要な品質シグナルとなります。
- 解決されたタスクあたりのハンドオフ数
- 完了までの平均委任回数。これが上昇傾向にある場合は、より高度な作業が行われているのではなく、優柔不断やルーティングの混乱が生じている兆候であるため注意が必要です。
- 調整オーバーヘッド
- 単一のエージェントと比較して、スーパーバイザーに起因する追加のトークン、呼び出し、およびレイテンシ。これが良好であれば、ルーティングがそのコストに見合っていることを意味します。
- ルーティング精度
- ラベル付きケースに照らして判定された、最初の試行で正しい専門エージェントに送信された委譲の割合。
観察された失敗パターン
- 2つのエージェントが、予算（バジェット）によってループが遮断されるまで、進捗がないまま処理を相互に引き渡し続ける
- スーパーバイザーが誤った専門エージェントにルーティングしてしまい、スレッドを二度と復旧できない
- 引き渡しの際に重要なコンテキストが脱落し、専門エージェントが誤った問題を解決してしまう
- 専門エージェントの部分的な結果が競合し、スーパーバイザーがそれらを一貫性のない形でマージしてしまう
得られた教訓
- ループが必ず終了するように、厳格なステップバジェットと明示的な終了条件を強制する
- 引き渡しを、生のメッセージダンプではなく、意図とスコープを持った構造化されたものにする
- ルーティングの曖昧さを減らすため、専門エージェントのスコープを狭く、重複しないように保つ
- すべての委譲をインスツルメント（可視化・計測）する。見えないマルチエージェントループをデバッグすることはできない
FAQ
- オーケストレーター・ワーカー（orchestrator-workers）パターンとは何が違うのですか？
- オーケストレーター・ワーカーは、1つのタスクを並列の（多くの場合同質な）ワーカー呼び出しに分解してマージします。一方、スーパーバイザーは、マルチターンのループ全体で異質な専門エージェントを統括する永続的なコーディネーターであり、固定された計画を実行するのではなく、状態の遷移に応じてルーティングを再決定します。
- 無限の引き渡しループを防ぐにはどうすればよいですか？
- 各専門エージェントのターンの後に制御をスーパーバイザーに戻し、エージェント間の自由なピアツーピア呼び出しを禁止します。また、ステップやトークンのバジェットを設定し、許可された遷移を定義し、明示的な終了条件を追加することで、ループが無限に循環するのを防ぎます。
- 専門エージェントはどのようなときにスーパーバイザーに制御を戻すべきですか？
- スコープ内のタスクを完了したとき、自身が持っていない機能が必要になったとき、意思決定を要する曖昧さに直面したとき、またはそのリクエストに対して自身が適切なエージェントではないと検知したときです。その後、スーパーバイザーが統合を行い、次のステップを選択します。