すべての処理に同じモデルを使うと、不要なコストがかかる場合があります。ただし、複数モデルに振り分けるだけで自動的に改善するわけではありません。
分類、抽出、文案作成、難しい推論では、求められる品質やレイテンシが異なることがあります。モデルの振り分けは、その違いを活用する仕組みです。一方で、分類器の呼び出し、プロバイダー固有の障害、一貫しない安全上の挙動、追加の評価作業も生じます。コスト削減を主張できるのは、実測したトークン数、現在の料金、品質基準を使って計算した場合だけです。
これがマルチモデルオーケストレーションです。品質、レイテンシ、プライバシー、コストの制約を明示し、処理の種類ごとにモデルまたは専門サービスを選びます。
この記事では、代表的な設計パターン、振り分けの判断方法、トレードオフ、実装手順を説明します。
一つのモデルが常に最適とは限らない理由
プロバイダーのモデル一覧は頻繁に変わります。それでも、自社の処理内容に応じて機能の層を定義できます。
高性能な推論層： 難しい計画や分析に使う候補です。自社の事例で、正確さ、ツールの挙動、レイテンシの高パーセンタイル値、生成される推論トークンの総数を評価します。
汎用層： 品質は重要でも長い推論を必要としない、利用者向けの文案作成や幅広い知識を扱う作業の候補です。
低レイテンシ層： 範囲を限定した分類、抽出、書き換えの候補です。小規模モデルだからといって、必要な精度を満たすとも、処理全体のレイテンシが短いとも限りません。
ローカルまたは小規模モデル層： データの保管・処理場所、オフライン動作、推論一回を追加する際の提供コストが重要な場合の候補です。比較には、ハードウェア、運用、消費電力、同時実行数、量子化の影響も含めます。
専門サービス（埋め込み、再ランキング、画像、音声）： 実際に行う処理で汎用モデルと比較します。専門サービスであること自体は、高品質や低い総コストの証拠になりません。
判断する時点で、最新のモデル一覧と料金ページを確認します。OpenAIのモデルと料金、Anthropicのモデルと料金、Googleのモデルと料金です。長期的なアーキテクチャ判断に、特定時点の提供状況や料金を固定した前提として組み込まないでください。
一般的なAIアプリでは、さまざまな種類のLLM呼び出しが発生します。呼び出しごとに要件は異なります：
- 利用者の意図の分類：曖昧な事例や対象外の事例も含む正解付きデータセットで、低レイテンシの候補を評価します。
- 構造化データの抽出：モデルサイズではなく、フィールドレベルの精度とスキーマの有効性を測定します。
- 利用者向け応答の生成：事実の正確さ、方針への適合、レイテンシの高パーセンタイル値を測定します。
- これまでの会話の要約：意思決定、名前、制約条件、否定形の省略を検出するためにテストします。
- バックグラウンドのバッチ処理：スループット、再試行コスト、期限内の完了率を測定します。
最も安い候補で十分とも、最も高い候補が最良とも決めつけないでください。すべての経路を同じ評価セットで検証します。
計測データから削減額を計算する
各呼び出しの種類について、以下を集計します：
- 月間呼び出し数
- 入力トークン、キャッシュ済み入力トークン、出力トークンの分布
- 再試行率とカスケード発生率
- ツール、検索、バッチ処理、ホスティングの料金
- レイテンシのパーセンタイル値
- その経路に対するリリース評価の合格率
最新の料金を使って、候補経路ごとのコストを計算します。
monthly route cost = calls × (
input_tokens × input_price
+ cached_tokens × cached_price
+ output_tokens × output_price
) + tool_charges + hosting + expected_retry_cost
ベースラインと比較できるのは、同じ品質・安全性のリリース基準を満たした候補だけです。結果とともに前提条件も示してください。トークン費用が下がっても、手作業での修正、インシデント、レイテンシが増えれば、総コストは高くなる場合があります。
計測データがなければ、まず本番の結果に影響を与えないシャドー評価を行います。一般的なトラフィック配分だけを根拠に、削減率を公表してはいけません。
基本的なオーケストレーションパターン
本番環境のマルチモデルシステムでは、次の設計パターンがよく使われます。
パターン 1：タスク別の振り分け
異なる種類のタスクを異なるモデルに送信します。これが最も単純なパターンです。
# Resolve these aliases from reviewed configuration; provider IDs change.
def route_request(task_type):
if task_type == "classification":
return SMALL_TIER
elif task_type == "extraction":
return EXTRACTION_TIER
elif task_type == "summarization":
return SUMMARY_TIER
elif task_type == "user-facing-response":
return RESPONSE_TIER
elif task_type == "complex-reasoning":
return REASONING_TIER
呼び出し元のコードは、何の処理を求めているか分かっているため、そこでタスクを分類します。振り分け結果は一意に決まり、問題も追跡しやすくなります。
パターン 2：複雑さに応じた振り分け
各リクエストの複雑さを推定し、その結果に応じて振り分けます。
def route_by_complexity(request):
complexity = estimate_complexity(request)
if complexity < 3:
return "small"
elif complexity < 7:
return "mid"
else:
return "flagship"
複雑さは、リクエストの長さやキーワードなどのルールで推定することも、低コストの分類モデルにスコアを付けさせることもできます。同じ種類のタスクでも難易度が異なる場合に使える方法です。
パターン 3：カスケード方式
まず低コストのモデルを試し、出力が基準を満たせば採用します。満たさなければ、より高性能で高コストのモデルへ切り替えます。
def cascade(request):
cheap_response = call_model("small", request)
if is_acceptable(cheap_response):
return cheap_response
return call_model("flagship", request)
この方法が機能するのは、出力が「許容できる」かを、信頼度スコア、検証処理、別の品質確認用LLMなどで判定できる場合です。単純なリクエストの多くを低コストモデルで処理し、難しいものだけを高コストモデルへ送れます。
パターン 4：専門モデルへの振り分け
専門的なタスクには専門モデルを使用します：
- 埋め込み：チャットモデルで埋め込みを生成するよりはるかに安価な、専用の埋め込みモデルを使います。
- リランキング：専用のリランカーを使用します。
- ビジョン：画像分析にはビジョン特化モデルを使用します。
- 音声：文字起こしや音声合成には音声モデルを使います。
- コード：コードタスクにはコード特化モデルを使用します。
専門モデルや小規模モデルは、範囲の狭いタスクでは速く、安く、品質も高い場合があります。ただし、名称だけでその利点を判断してはいけません。実際に使うモデル、プロバイダー、プロンプト、言語、レイテンシのパーセンタイル値、料金表、評価セットで比較してください。
パターン 5：プロバイダー間の振り分け
冗長性を確保し、料金面の選択肢を増やすために、複数プロバイダーのモデルを使用します。
providers = ["openai", "anthropic", "google"]
preferred = "anthropic" # primary
fallback = "openai" # fallback
def call_with_failover(request):
try:
return call(preferred, request)
except (RateLimit, ProviderError):
return call(fallback, request)
これにより、単一プロバイダーの障害やレート制限に備えられます。また、料金改定を活用でき、プロバイダーが値下げしたときは、より多くの処理をそちらへ移せます。
現実的な例：カスタマーサポートAI
具体例として、顧客対応AIでマルチモデルオーケストレーションを使う場合を考えます。
システムはチケットごとに、次の処理を行います：
ステップ 1：意図の分類。 顧客は何について問い合わせていますか？
振り分け候補：正解付きの意図分類テストに合格する低レイテンシモデルです。
ステップ 2：緊急性と感情の判定。 顧客はいら立っているか、緊急性はあるかを判定します。
振り分け候補：緊急事案を見逃す割合が、別途定めた安全基準を満たす場合に限り、同じモデルを使います。感情の推定は、緊急性を判断する信頼できる代替指標ではありません。
ステップ 3：関連知識の取得。
振り分け候補：埋め込み検索と再ランキングを組み合わせ、実際の問い合わせに即した検索テストで評価します。
ステップ 4：AIが回答できるか、人へ引き継ぐ必要があるかを判定。
振り分け候補：人へ引き継ぐべき案件を漏らさないか、特に再現率を評価したモデルです。アカウントへのアクセス、安全、法務、金融など、社内規程で定めた案件では、規則によって人への引き継ぎを強制します。
ステップ 5（AIが回答可能な場合）：顧客向け応答の生成。
振り分け候補：高品質な汎用モデルです。事実の正確さ、社内規程、プライバシー、文調がリリース基準を満たすまでは、文案作成だけに使います。
ステップ 6（AIが回答できない場合）：担当者向けの要約生成。
振り分け候補：問題、根拠、実施済みの手順、顧客側の条件、不確かな点を落とさず要約できる低コストモデルです。
ステップ 7：品質チェック。 応答は基準を満たしていましたか？
振り分け候補：決定論的な検査と、較正済みの判定モデルを組み合わせます。判定モデルは独立した保証にはならないため、サンプルを抽出して人による確認も行います。
各ステップを計測し、実測したトークン分布、現在の料金、人への引き継ぎ率、再試行率、人による確認のコストを上の計算式に入れてください。問い合わせの構成と合格基準によって結果が変わるため、ここでは一般的な削減率を示しません。
振り分けの判断方法
振り分けを実装する方法はいくつかあります。
アプローチ 1：タスクの種類をコードで固定する
最も単純な方法です。呼び出し元がタスクの種類を把握しているため、そこでモデルを選びます。
def classify(text):
return openai_client.chat.completions.create(
model=SMALL_TIER, # your provider's current small model
messages=[{"role": "user", "content": f"Classify: {text}"}],
)
def respond(context, query):
return claude_client.messages.create(
model=RESPONSE_TIER, # reviewed config alias, not a frozen provider ID
max_tokens=1024,
messages=[{"role": "user", "content": f"Context: {context}\n\nQuery: {query}"}]
)
利点：振り分けが明確で、問題を追跡しやすく、変更も容易です。 欠点：同じ種類のタスク内でリクエストの難しさが変わっても対応できません。
アプローチ 2：振り分け専用モデル
小規模モデルがリクエストを分類し、処理先を決めます。
ROUTER_PROMPT = """
Classify this request as: trivial, moderate, or complex.
Output one word.
Request: {request}
"""
def route(request):
classification = small_model_call(ROUTER_PROMPT.format(request=request))
return MODEL_BY_COMPLEXITY[classification]
利点：カテゴリ内の複雑度に適応します。 欠点：振り分け用の呼び出しによってレイテンシと障害箇所が増え、調整も必要です。
アプローチ 3：埋め込みを使った振り分け
既知のパターンに該当するリクエストの場合、過去の例との埋め込み類似性を使用します。
def route(request):
embedding = embed(request)
closest = find_nearest_example(embedding)
return closest.suggested_model
利点：ベクトル検索だけなので高速で、検証済みの事例を増やすほど精度が上がる場合があります。 欠点：ラベル付き例セットの構築が必要です。
アプローチ 4：カスケード方式
まず低コストモデルを試し、必要に応じて高性能モデルへ切り替えます。
def cascade(request):
cheap = small_model_call(request)
if validates(cheap):
return cheap
return flagship_call(request)
利点：入力に応じて切り替えられ、平均コストを抑えられます。 欠点：切り替えが必要な場合は二回呼び出すため遅くなり、信頼できる検証処理も必要です。
実際の本番システムでは、主要なタスクはコードで固定し、結果のばらつきが大きい一部のタスクだけにカスケード方式を使う、ハイブリッド構成がよく採用されます。
落とし穴
避けるべきいくつかの間違いがあります：
落とし穴 1：コスト最適化で品質を落とす
すべてを小規模モデルへ振り分ければ、コストを下げるのは簡単です。しかし、品質まで下がったことは見落としやすいため、振り分けを変える際は必ず品質も監視してください。
有効な進め方は、重要な入力分類と失敗パターンを網羅できるサンプルが集まるまで、低コスト経路をシャドー評価またはA/Bテストすることです。単に一週間試したという事実だけでは根拠になりません。事前に定めた品質・安全基準を満たすまで変更を公開してはいけません。
落とし穴 2：振り分け機構を過剰設計する
多数のタスク分類と分かりにくい判断を持つ振り分け機構は、元の処理より保守が難しくなる場合があります。測定結果で正当化できる最小限の経路から始めてください。
経路を追加するのは、運用上の判断が実際に変わり、測定対象の制約が、担当者、テスト、代替経路の維持コストに見合うほど改善する場合だけです。
落とし穴 3：レイテンシを無視する
低コストモデルが速いとは限りません。レイテンシと品質は別々に測ります。最初のモデルが基準を満たさず別モデルへ切り替える方式では、少なくとも一回余分に呼び出すため、利用者向け処理の高パーセンタイル側のレイテンシが大きく伸びる場合があります。
利用者向けでレイテンシが重要な処理では、直接一つのモデルへ送る場合とカスケード方式を、合格率と高パーセンタイル側のレイテンシの両方で比較します。バッチ処理や非同期処理では切り替えの遅延を許容しやすいものの、適切な経路はワークロードによって異なります。
落とし穴 4：プロバイダー障害への備えが足りない
複数のモデルに依存すると、障害の起点も増えます。高性能モデルの停止、レート制限、APIキーの期限切れなどが起こり得るため、振り分け処理にはフォールバックが必要です。
レート制限、タイムアウト、プロバイダー障害が起きたときの動作を明示します。別プロバイダーへの切り替えが適切なのは、そのデータ処理条件、処理地域、ツールとスキーマの契約、評価結果を受け入れられる場合だけです。条件を満たさなければ、安全側で停止する、キューに入れる、人へ引き継ぐ、のいずれかにします。品質が大幅に低い回答を返すことは、可用性の確保とはいえません。
落とし穴 5：経路ごとの品質を測らない
どの経路が機能し、どの経路で問題が起きているかを把握するには、評価が必要です。可能な範囲で自動化します。
本番の各呼び出しについて、使用したモデル、リクエスト、応答、可能であれば品質シグナル（利用者の反応、後続工程の指標、自動評価）を記録します。経路ごとに指標を集計し、利用者から苦情が来る前に品質の変化を検知してください。
現行サービスへの依存を再検証する
モデルID、廃止予定日、コンテキスト上限、料金、レート制限、処理地域、構造化出力やツールの仕様は、それぞれ別々に変わる可能性があります。設定上のエイリアスが指すモデルを変える前に、最新の公式資料を確認し、経路ごとの評価を再実行してください。OpenAI互換の通信方式でも、スキーマ、ツールの挙動、トークン計算、安全方針、データ処理が同等とは限りません。
始め方のチェックリスト
マルチモデルシステムを新しく構築する場合や、単一モデルから移行する場合は、次の順で始めます。
- タスクを整理する。 アプリが行うLLM呼び出しの種類、概算頻度、概算コストを洗い出します。
- 複雑さで分類する。 タスクごとに「単純」「中程度」「複雑」のいずれかを決め、対応するモデル層を選びます。
- 振り分け処理を作る。 まずはタスクの種類をコードで固定する単純な方式から始めます。過剰に設計してはいけません。
- 障害時の動作を決める。 影響の大きさとデータ方針に応じて、テスト済みのフォールバック、キュー、安全側での停止、人への引き継ぎを使い分けます。
- 経路ごとに品質を測る。 ログと基本的な評価を用意し、品質を維持できているか確認します。
- 繰り返し改善する。 品質を維持できるタスクは低コストモデルへ移し、品質が崩れるタスクは高性能モデルへ戻します。継続的に調整してください。
- 調整を続ける。 モデルも料金も変わります。2026年五月に最適だった設定が、2026年十一月には最適でない可能性があります。
根拠を示せる場合だけモデルを振り分ける
マルチモデルオーケストレーションは、呼び出しの種類に実質的な違いがあり、各経路を評価できる場合に、コストやレイテンシを抑えられる可能性があります。一方で、運用コストを増やし、一貫性を損なうこともあります。一般的な削減率ではなく、実測したベースライン、振り分け後の結果、品質基準、評価期間を示してください。
振り分け条件のコードは短くても、本番運用には、設定管理、評価、可観測性、プライバシー審査、再試行時の挙動、フォールバック経路の設計が必要です。
タスクを整理し、実行可能な候補を比較し、根拠を示せる場合だけ振り分けを行い、公開後も測定を続けてください。
