マネージャーパターンとは、中央の LLM（マネージャー）が、専門化されたエージェントのネットワークをツール呼び出しを通じて起動することで調整し、それらの結果を 1 つの一貫したやり取りにまとめ上げるマルチエージェントのオーケストレーションパターンである。これは エージェント構築の実践ガイド が広く適用可能と名指す 2 つのマルチエージェントの類型の一つであり、もう一方は 分散型パターン である。このガイドはこれを「ツールとしてのエージェント（agents as tools）」とも表現している。マネージャーに公開されたエージェントは、マネージャーの視点からはツールだからである。
用法
エージェントをノードとするグラフとしてモデル化すると、マネージャーパターンのエッジはツール呼び出しである。マネージャーはタスクをそれに適したエージェントに委任し、結果を受け取り、ユーザーと対話するコンポーネントであり続ける。ガイドの具体例は翻訳エージェントで、そのマネージャーはスペイン語、フランス語、イタリア語の 3 つの専門エージェントを保持している。それぞれが固有の名前と説明を持つツールとして登録されているため、複数の翻訳の依頼は、同じマネージャーからの複数のツール呼び出しになる。OpenAI Agents SDK ではこの変換が明示的に行われる。専門エージェントは as_tool(...) によってツールに変換され、ツール名とツールの説明を与えられ、マネージャーの tools 配列に列挙される（OpenAI Agents SDK を参照）。
ガイドは、ツールとしてのエージェントを、エージェントが必要としうる 3 つのツール類型の一つとして扱っている。残りの 2 つは、コンテキストを取得するデータツールと、外部システムで何かを変更するアクションツールである。したがってこのパターンは、別個の仕組みとしてではなく、通常の 関数呼び出し の応用として提示されている。
適用される場面
ガイドはこのパターンを、ちょうど 1 つのエージェントにワークフローの実行を制御させ、ユーザーへのアクセスを持たせたいワークフローに最適なものとして提示している。そこから、述べられている利点が導かれる。マネージャーは決して制御を手放さないため、コンテキストを失わず、専門的な機能は単一の統一されたユーザー体験の背後で必要に応じて利用可能なままになる。
これには 2 つの前提が伴う。第一に、作業が、専門エージェントが完了して結果を返せるタスクに分解できなければならない。マネージャーが専門エージェントに到達する唯一の手段は、結果が返ってくるツール呼び出しだからである。第二に、ガイドのより広い助言がまず適用される。ガイドは、複数のエージェントを導入する前に、単一エージェントの能力を最大限に引き出すことを推奨している。その根拠は、エージェントを増やすと関心の分離が直感的になる一方で、複雑さとオーバーヘッドが増すため、ツールを備えた単一のエージェントで十分な場合が多い、というものである。分割のきっかけとして挙げられているのは、多数の条件分岐が蓄積したプロンプトと、選択を混乱させるほど重複したツールである。
このパターンは、独立に確立された分類法ではなく、一ベンダーによる自社の顧客経験の特徴づけである。ガイドはこの 2 つの類型を、顧客との取り組みから浮かび上がったものとして説明しており、そのコード例は一貫してそのベンダー自身の SDK を前提としている。
関連用語
- 分散型パターン — 同じガイドが挙げるもう一方の類型。制御が 1 つのエージェントにとどまるのではなく、対等なエージェント間で移譲される
- Planner-Worker モデル — 計画と実装の役割を階層的に分ける、別途報告されている構成
- サブエージェントアーキテクチャ — ツール呼び出しではなくコンテキストの分離という観点で説明される、関連する構成
- 関数呼び出し