モデルオーケストレーション：AIシステムはモデルをどう選び、組み合わせるか | ライブラリ

原則： 賢そうに見えるという理由だけで、複数のモデルをオーケストレーションしてはいけない。仕事の種類ごとに要件が明確に異なり、安価な経路で十分な場合、より高性能な経路へ引き継ぐべき場合、処理を止めるべき場合を測定できるときに使う。

モデルオーケストレーションとは何か、何ではないか

モデルオーケストレーションは、タスクの各工程で使うモデル、設定、次の処理を選ぶ運用レイヤーだ。小型で高速なモデル、高価なフロンティアモデル、ローカルモデル、決定論的なコードの中から適切な手段を選ぶ。予算、応答時間、データの機密性、出力品質、障害時の動作もここで管理する。

これはマルチエージェントシステムの別名ではない。固定されたワークフローが三つのモデルを使っても、それは固定ワークフローのままだ。また、エンドポイント名だけを書き換える万能プロキシでもない。モデルごとにツール利用、コンテキスト上限、構造化出力、安全上の挙動、失敗の仕方が異なる。単純な一つのプロンプトを五つのモデルに分割する理由にもならない。

まず、適切な一つのモデルで基準となる構成を作る。通常処理の費用が高すぎる、特定のタスクだけ精度が低い、データを端末内に置く必要がある、独立した検証が必要、といった具体的な問題がログから確認できた時点でオーケストレーションを加える。

ルーティングの判断木

ルーターを最初から別のLLMにする必要はない。初期版は少数の規則で書いた方が理解しやすいことが多い。

タスクは決定論的に処理できるか
├─ はい → LLMを使わず、コード、SQL、検索、検証器で処理
└─ いいえ
   データを特定の地域または端末内に置く必要があるか
   ├─ はい → ローカルモデルまたは地域要件を満たすモデル
   └─ いいえ
      結果は取り消せない、または高リスクか
      ├─ はい → 高性能モデル + 検証 + 必要に応じて人間
      └─ いいえ
         安価なモデルがこのタスク分類の評価を通過しているか
         ├─ はい → 安価なモデル
         └─ いいえ → 高性能モデル

各工程の後:
- スキーマ違反またはツールエラー → 一度だけ修正し、その後は引き継ぐ
- 検証可能な確信度が低い → 検索、高性能モデル、または人間へ
- タイムアウトまたは事業者の障害 → 互換性のある予備経路へ
- セキュリティ問題 → 勝手に迂回せず停止

ルーティングに使う信号は、高価なモデルを呼ぶ前に取得できるものにする。要求の種類、言語、入力サイズ、データ源、必要なツール、テナント、SLA、リスク分類などだ。モデルの自己評価も一つの信号にはなるが、それだけを根拠にしてはいけない。モデルは自分の誤りを自信満々に承認することがある。

実用的なアーキテクチャ

実用的な構成は、少数の役割が明確なレイヤーからなる。

入力の正規化で不要なデータを除き、テナントと実行IDを付ける。
ポリシーゲートで利用可能な事業者、地域、データ分類、上限費用、承認が必要な操作を決める。
ルーターがバージョン管理された規則または分類器で経路を選び、判断理由も返す。
モデルアダプターが内部のメッセージ、ツール、構造化出力を各事業者のAPI形式へ変換する。
実行レイヤーがタイムアウト、最大ステップ数、冪等性キーを付けてモデルとツールを動かす。
検証器がスキーマ、引用、業務規則、その他の機械検証可能な結果を確認する。
引き継ぎ制御が修正、上位モデルへの切り替え、別モデル、人間による確認、停止のいずれかを選ぶ。
可観測性と評価ストアにプロンプトの版、モデル、ルーティング理由、応答時間、費用、検証結果、最終状態を記録する。

ドメインロジックが事業者名を知る必要はない。内部契約は task、risk、data_class、allowed_tools、output_schema、budget 程度でよい。事業者ごとの差はアダプターが扱う。ただし、抽象化のためにすべてを最低限の共通仕様へ切り詰めてはいけない。特定モデルの機能が結果を明確に改善するなら、機能フラグとして明示的に使い、代替経路も維持する。

混乱を生まない引き継ぎとフォールバック

引き継ぎは、入力が予想より難しかった、検証に失敗した、別の能力が必要になった、という明確な理由で別経路へ処理を渡すことだ。未整理の会話履歴を丸ごと渡してはいけない。次のモデルに必要なのは、元の目的、検証済みの事実、ツールの結果、これまでの失敗、残りの予算である。

フォールバックは、利用不能や既知の障害パターンに対処する。順序は事前に決める。例えば、一時的な通信障害に限って同じモデルを再試行する。スキーマ違反なら出力を修正する。事実確認に失敗したら高性能モデルへ渡す。事業者の障害なら別の事業者を使う。取り消せない操作なら人間に渡す。無限の再試行は耐障害性ではなく、見えない請求書だ。

すべての切り替えでセキュリティポリシーを保つ必要がある。所在地要件によって主モデルへ送れなかったデータを予備モデルへ送ってはならない。「承認が必要」という規則を、フォールバックで「自動的に試す」へ変えてもいけない。

評価と成功一件あたりの費用

百万トークンあたりの価格は調達情報であって、システムの指標ではない。見るべきなのはタスクを一件成功させるための費用だ。

全実行費用 + 検索 + ツール + 検証 + 人手による修正
──────────────────────────────────────────
定義した成功条件を満たしたタスク数

評価セットには、実際のタスク分類、境界事例、長い入力、複数の言語、セキュリティシナリオを含める。経路ごとに成功率、応答時間、試行回数、引き継ぎ頻度、人の介入、エラー種別を追う。単一モデルの基準構成とも比較する。費用だけを最適化したルーターは安く失敗することを学び、平均品質だけを最適化したルーターは何でもフロンティアモデルへ送る。

一度に変更するルーティング判断は一つにし、同じ評価セットを再実行する。本番環境は別に監視する。要求の構成が変われば、以前のポリシーが通用しなくなるからだ。公開ベンチマークを自社製品の証拠にしてはいけない。自分たちのタスクと成功条件における性能が重要だ。

セキュリティとデータ所在地

ルーターはセキュリティ上重要な基盤だ。データの送信先を決めるメタデータを見るため、データ分類は事業者を選ぶ前に行い、プロンプトの指示ではなくポリシーレイヤーで強制する必要がある。

モデルごとに利用可能な地域、保存条件、学習利用の方針、暗号化、監査機能、利用可能なツールを記録する。モデルを呼ぶ前に個人情報と秘密情報を最小化または削除する。プロンプト全体を保存し、ログが新たな漏えい元になってはいけない。ツールの認証情報はモデルのコンテキスト外に置き、実行ごとにツールを認可する。

ローカルモデルだから自動的に安全とは限らず、クラウドモデルだから自動的に危険とも限らない。推論の実行場所、テレメトリの送信先、キャッシュに残る情報、ログを閲覧できる人、操作を監査できるかという全体の流れで判断する。

よくある失敗

感覚だけのルーティング: 「難しいタスク」の定義がない。対策はタスク分類、評価セット、バージョン管理された規則。
すべてにフロンティアモデル: 効果がない工程でも高品質に価値があると仮定する。対策は安価な基準構成と成功一件あたりの費用測定。
すべてに最安モデル: 再試行と人手修正で節約が消える。対策は最初のAPI呼び出しではなく実行全体を数える。
通知されないフォールバック: 障害が成功に見える。対策は理由、経路、最終状態を記録し、縮退運転を示す。
引き継ぎ時の状態消失: 次のモデルが作業を繰り返すか、未検証の主張を信じる。対策は構造化された引き継ぎ情報。
モデルが自分を採点する: 同じ弱点が二度通る。対策は決定論的な検証、独立した評価モデル、またはリスクに応じた人の確認。
抽象化レイヤーがワークフローを所有する: 製品が視覚的なAgent Builder、そのメモリ、独自ツール定義に依存する。サービスが消えれば退路も消える。対策は状態、プロンプト、スキーマ、評価、規則を自社管理の形式で版管理すること。
評価なしの事業者変更: JSONに互換性があっても挙動には互換性がない。対策は変更前に代表タスクを再実行すること。

具体例: 顧客問い合わせの振り分け

ある企業が複数言語のサポートメールを受け取っている。システムは分類を付け、関連資料を検索し、返信案を作る。契約変更と返金は人の確認を必要とする。

コードが署名を除き、添付ファイルを検出し、個人情報を識別する。
小型のローカルモデルが言語、話題、リスクを固定JSONスキーマへ分類する。
ポリシーゲートが機密性の高い添付ファイルを外部APIへ送らない。通常の質問には承認済みクラウド事業者を許可する。
安価なモデルが検索済みの記事を受け取り、引用付きの返信案を作る。
検証器が引用文書の存在、禁止された約束がないこと、製品に関する各主張に根拠があることを確認する。
スキーマ違反なら一度だけ対象を絞って修正する。事実が一致しなければ、元の目的、資料、検証結果を高性能モデルへ渡す。高リスク案件は直接人へ渡す。
システムは選択した経路、理由、総費用、担当者が返信案を承認、修正、却下したかを記録する。

複数回の評価を経て、安価なモデルは定型的な質問を安全に処理できる一方、曖昧な苦情では修正が増えると分かるかもしれない。その場合、ルーターはメールの長さではなく、話題、リスク、検索結果の組み合わせで上位経路へ切り替える。これはブランドの序列ではなく、証拠に基づくオーケストレーションだ。

参考資料

Building effective agents (Anthropic) - 単純なワークフローとエージェント型システムを実務的に区別し、機能する最小構成を選ぶ理由を説明する。
RouteLLM (LMSYS) - 質問に応じて高性能な経路と安価な経路を選ぶルーターの研究。
FrugalGPT (Stanford University) - モデルのカスケード、予算、品質と費用の最適化を扱った初期研究。
NIST AI Risk Management Framework - 運用責任を含むAIリスクの把握、測定、管理のための枠組み。
OWASP Top 10 for LLM Applications - ルーター、ツール、フォールバックが考慮すべき攻撃と運用リスクの一覧。
OpenAI Evals - 評価タスクを記述し、モデルの挙動を比較するための公開フレームワークと例。

覚えておくこと

オーケストレーションはモデルの寄せ集めではない。判断、引き継ぎ、検証、停止を担う制御レイヤーだ。まず一つのモデルと測定可能な基準構成から始める。ブランドの威信ではなく証拠で経路を選ぶ。再試行と人手も含め、成功一件あたりの費用を数える。モデルを呼ぶ前にセキュリティポリシーを適用し、フォールバックでも維持する。状態、評価、ツール契約は自分たちが管理できる形式で持つ。良いオーケストレーションは地味で、監査でき、交換できる。