エージェント型システムでは、意思決定をどのように、どこで行うかを慎重に検討することが重要です。
より多くの意思決定を LLM に委ねると、システムがより多様なタスクに対応できる可能性が高まる一方、速度、信頼性、堅牢性が損なわれる可能性があります。
可能な限り、意思決定プロセスを LLM から切り離し、明示的なソフトウェアコードとして実装してください。これは特に、高リスクのワークフローや本番環境のワークフローに当てはまります。
LLM ベースのエージェント型システムを設計する際、特に重要なのは、意思決定のうちどこまでを LLM モデルに担わせ、どこからを明示的なソフトウェアに担わせるかという選択です。
この選択は、次のアプローチを両端とするスペクトラムとして捉えると理解しやすくなります。
ルーターベースのアーキテクチャは、処理の順序とロジックをコードで明示的に定義し、限定された領域のタスクでテスト容易性、予測可能性、堅牢性を確保します（「ワークフローエージェント」とも呼ばれます）。
オーケストレーターエージェントは、大規模言語モデル（LLM）を利用し、自然言語のプロンプトに基づいてタスクフローを動的に決定します。事前定義されたロジックでは不十分、または実現不可能な自由度の高い対話に適しています。
高リスクの本番ワークフローには通常、ルーターベースの機能を多く採用し、柔軟で汎用的な対話が求められるアプリケーションに限ってオーケストレーターを使用することを推奨します。
ルーターベースのアーキテクチャ
ルーター型エージェントシステムの特徴
意思決定フローをコードやソフトウェアで明示的に定義し、ソフトウェアが進む経路の選択に LLM を使用
明確で予測可能な経路によって結果の一貫性が高まるという点で、従来のソフトウェアシステムに近い構造
厳密に定義できるタスクに最適
次は、「ルーター方式」を採用した航空会社の予約チャットボットエージェントの簡単な例です。LLM は質問の意図を 3 つの候補から分類しますが、最終的にはソフトウェアがその意図を定型文の回答に対応付けます。LLM が厳しく制約されているため、ユーザーはより一貫した動作を得られます。
オーケストレーターアーキテクチャ
ルーターシステムとは対照的に、オーケストレーター型エージェントシステムには次の特徴があります。
ソフトウェアではなく、自然言語のプロンプトでロジックフローを定義注：プログラミング言語と比べ、自然言語には本質的に曖昧さと柔軟性があります。後述するように、これは長所であると同時に短所でもあります。これは「指示ではなく意図」に基づくアプローチと捉えられます。
複数の処理方法を用意し、LLM が実行順序と手法を決定
ソフトウェアでは明示的な定義が難しい、新たなロジック経路を動的に作成
この曖昧さによって出力が一貫しないこともありますが、うまく機能すれば「魔法」のように感じられます。
次の例では、同じ航空会社の簡単な課題にオーケストレーター方式を適用しています。適切な回答をソフトウェアに決めさせるのではなく、意思決定を LLM レイヤーに委ねます。これはマルチエージェントシステムです。「司令塔」のオーケストレーターエージェントがユーザーの問い合わせを振り分け、フライト変更専用のエージェントに引き継ぎ、そのエージェントが最終的にユーザーへ回答します。
この例では、LLM レイヤーが分類、ルーティング、回答作成の役割を担っています。ルーターの例では、LLM が担うのは分類だけで、残りはソフトウェアが処理していました。
可能な場合は、次の利点があるルーターベースの方式を推奨します。
速度と効率：外部 API に依存するオーケストレーターに比べ、ローカル計算は高速です。また、「IF/ELSE」ロジックを Python で処理する方が、LLM プロバイダーに料金を支払って 4,000 億パラメーターのモデルで処理するよりも、はるかに低コストです。
テスト容易性と予測可能性：確立されたソフトウェア開発手法により、デバッグ、テスト、保守が大幅に容易になります。
透明性と信頼性：動作のばらつきが少ないため、トラブルシューティングが容易になります。さらに、アプリケーションフローの大部分が、LLM の不透明で解釈不能な重みではなく、透明性が高くバージョン管理されたソフトウェアとして表現されます。
ルーター方式の短所は、硬直的で柔軟性に欠け、自由度の高い問題への対応が難しいことです。毎回まったく同じ回答を返すチャットボットは、ユーザーに退屈で変化がないと思われる可能性があります。
オーケストレーター設計には、次の強力な機能があります。
計画：回答を動的に計画
ツール選択／エージェントへの引き継ぎ：適切なツールを選択、またはエージェントにタスクを委任
出力の反復的な組み合わせ：出力を反復し、創造的に再構成
完了の判定：回答を確定するのに十分な情報が集まった時点を判断
Pydantic-AI や OpenAI の Agents SDK などのフレームワークを使用すると、オーケストレーションを簡単かつ迅速に実装できます。そのため、デモや概念実証に適しています。
一方、このアプローチには次の短所があります。
LLM による計画の各段階と、その後のアクションが正しく適切である保証はありません。ルーターシステムにも同じ問題はありますが、制約が厳しい分、動作の予測可能性は高くなります。
単純で明確に定義されたタスクでは、マルチエージェントシステムの全機能が必要になる可能性は低いでしょう。たとえば航空会社のエージェントの例では、航空会社のサポートシステムを利用する人が実際に行いたい問い合わせは、限られた種類しかないと考えられます。
LLM に含まれるロジックが多いため、悪意のある攻撃者によるジェイルブレイクや悪用を受けやすくなります。
意思決定が LLM の内部に抽象化されるため、システムの把握も難しくなります。ただし、Langfuse や Braintrust などの監視ツールが部分的に役立つ場合があります。
読者への注記：モデルの能力は急速に変化していますが、以下の内容が近い将来に変わる可能性は低いでしょう。
問題の範囲を特定します。
必要な意思決定ロジックを図で簡単に定義できますか？
アプリケーションで障害や予期しない動作が発生することを許容できませんか？
いずれかに「はい」と答えた場合は、ルーター機能の方が適しています。
可能な限りルーター方式を使用することを推奨します。原則として、システムの一部をコードで表現できるならコードで表現してください。つまり、必要のない場面で LLM を使いすぎないことが重要です。
ルーター方式の限界に達した場合でも、オーケストレーターが持つ自由度の高い利点の一部は、制約を設けた形で再現できます。例：
ツール選択／エージェントへの引き継ぎ：条件分岐や LLM 分類器で簡単に実装可能
完了の判定：シンプルな LLM 分類器で、ユーザーに返す前に回答が完全かどうかを確認可能
一方、「計画」と「出力の反復的な組み合わせ」を硬直的なルーターシステムで実現するのが、はるかに難しいことは間違いありません。そのため、LLM 分類器などのロジックによってタスクにこれらが必要だと判断された場合は、システム内に制約の少ないオーケストレーター分岐を作ることを推奨します。
ルーターとオーケストレーターのどちらを選ぶかは、アプリケーションの要件の明確さ、複雑さ、対話形式に応じて決める必要があります。現時点では、明確に定義されたタスクには、ルーターベースの方式が信頼性、効率、テストのしやすさをもたらします。オーケストレーターは、より幅広い会話型の対話に優れた柔軟性を発揮します。
LLM が進化し続けるにつれ、両方式のバランスは変化する可能性があります。本番ワークロードにはルーターベースまたはハイブリッドのアーキテクチャを優先し、動的で人間らしい対話を要する自由度の高い問題に限ってオーケストレーターを使用するのがよいでしょう。