本番AIシステムで見かける最も高くつく間違いは、あらゆる用途に1つのモデルを使うことです。
チームは1つのフラッグシップモデル（GPT-5.5、Claude Opus 4.8など）を選び、それを中心にアプリを構築します。月々の請求額は5桁（数万ユーロ規模）に達します。リクエストを異なるモデル階層へ振り分けると、通常は請求額の大部分を削減できます。以下のモデルケースでは約70～75%で、多くの場合はレイテンシも同時に改善します。
これがマルチモデル・オーケストレーションです。システム内の各タスクに適したモデルを使うことであり、趣味のAIと本番AIを分ける違いです。
この記事では、パターン、ルーティングロジック、トレードオフ、実装手順を解説します。
1つのモデルが最適ではない理由
2026年に提供されているモデルは、おおまかに次の階層に分かれます。
フラッグシップ推論階層（GPT-5.5、Claude Opus 4.8、Gemini 3.1 Proの各思考モードと、DeepSeek R1）：複雑な推論に優れ、高価（一般的なフラッグシップでは入力100万トークン当たり$3～30、出力は$15～50。特殊なプロ階層はさらに高額）で、低速（通常5～30秒）です。
フラッグシップ汎用モデル（GPT-5.5、Claude Sonnet 5、Gemini 3.1 Pro）：大半の知的作業に優れ、価格は中程度（入力100万トークン当たり$2～5、出力100万トークン当たり$12～30）、速度は妥当（2～5秒）です。
中間階層モデル（Claude Haiku 4.5、Gemini 3.5 Flash、OpenAIの中間階層）：単純から中程度のタスクに適し、安価（入力100万トークン当たり$1～2.50、出力100万トークン当たり$5～15）で高速（1～2秒）です。
小規模モデル（各プロバイダーの現行最小階層。Gemini 3 Flash Preview、小規模なオープンソースモデルなど）：単純な構造化タスクに適し、非常に安価（入力100万トークン当たり$0.50～1）かつ非常に高速（1秒未満）です。
特化型モデル（埋め込み、リランキング、画像、音声モデル）：特定のタスク向けに最適化され、用途が絞られているため非常に安価なことがよくあります。
（定価は2026-07-07に各ベンダーの料金ページで確認済みです。見積もりに使う前に再確認してください。）
一般的なAIアプリは、さまざまな種類のLLM呼び出しを行います。呼び出しごとに要件が異なります。
- ユーザー意図の分類：単純な分類と高速な応答が必要です。中間階層モデルが最適です。
- 文書からの構造化データ抽出：構造化出力の信頼性と中程度の複雑さへの対応が必要です。中間階層またはフラッグシップ汎用モデルが適します。
- ユーザーの質問への実際の回答作成：品質とコンテキスト処理が必要です。フラッグシップ汎用またはフラッグシップ推論モデルが適します。
- 過去の会話の要約作成：単純な要約です。中間階層または小規模モデルが適します。
- バックグラウンドでのバッチ処理：レイテンシには左右されませんが、処理量が重要です。小規模または中間階層モデルが適します。
これらすべてにフラッグシップモデルを使うのは無駄です。分類や要約には不要で、構造化抽出にも不要な場合が多くあります。本当に恩恵を受けるのは、ユーザー向けの回答だけです。
コスト削減は現実的
一般的な知的作業向けAIアプリでは、リクエストが次のように分布する場合があります。
- LLM呼び出しの60%：単純な分類、抽出、要約。中間階層または小規模モデルが最適です。
- 呼び出しの30%：中程度の複雑さ。中間階層またはフラッグシップ汎用モデルが適します。
- 呼び出しの10%：複雑な推論または最終的なユーザー向け回答。フラッグシップモデルが適します。
すべてにフラッグシップを使うと、コストはフラッグシップ料金の100%です。適切にルーティングすると、次のようになります。
- 60%を小規模モデルのコスト（フラッグシップの1/30）で処理：元のコストの2%。
- 30%を中間階層のコスト（フラッグシップの1/5）で処理：元のコストの6%。
- 10%をフラッグシップのコストで処理：元のコストの10%。
合計は元のコストの18%、つまり82%の削減です。月額€10,000なら、月額€8,200を節約できます。
数値はトラフィックの構成によって変わりますが、傾向は一貫しています。大半のアプリでは、平均的な呼び出しは最も難しい呼び出しよりはるかに安く処理できます。ルーティングはその差を活用します。
基本的なオーケストレーションパターン
本番のマルチモデルシステムでは、いくつかのパターンが繰り返し使われます。
パターン1：タスクベースのルーティング
タスクの種類ごとに異なるモデルを使います。最も単純なパターンです。
# モデルIDは2026-07-07に確認済み。SMALL_TIERには利用中のプロバイダーの
# 現行小規模モデルを指定し、決め打ちせず最新のモデル一覧を確認すること。
def route_request(task_type):
if task_type == "classification":
return SMALL_TIER
elif task_type == "extraction":
return "claude-haiku-4-5"
elif task_type == "summarization":
return "claude-haiku-4-5"
elif task_type == "user-facing-response":
return "claude-sonnet-5"
elif task_type == "complex-reasoning":
return "claude-opus-4-8"
タスクは呼び出し元のコードによって分類されます。そのコードは、自分が何を要求しているかを把握しています。ルーティングは決定論的で、デバッグも容易です。
パターン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：意図を分類する。 顧客は何について質問していますか？（5～10カテゴリ）
ルーティング：小規模モデル。単純な分類タスクです。コスト：チケット当たり約$0.0005（小規模モデルの料金で約500トークン）。
ステップ2：緊急度と感情を判定する。 顧客は不満を感じていますか？緊急ですか？
ルーティング：同じ小規模モデル。これも単純な分類です。コスト：チケット当たり約$0.0005。
ステップ3：関連ナレッジを取得する。
ルーティング：埋め込みモデル＋リランキングモデル。専門の仕事には専門のツールを使います。コスト：チケット当たり約$0.002（検索1,000回当たり約$2のリランキングが大部分）。
ステップ4：AIが回答できるか、人間へのエスカレーションが必要かを判定する。
ルーティング：Claude Haiku 4.5。取得したコンテキストを考慮する、やや高度な分類です。コスト：チケット当たり約$0.002（コンテキスト約2Kトークン）。
ステップ5（AIが回答できる場合）：顧客向けの回答を生成する。
ルーティング：Claude Sonnet 5。顧客が読む内容なので、品質が重要です。コスト：チケット当たり約$0.015（入力約3K／出力400）。
ステップ6（AIが回答できない場合）：人間の担当者向けに要約を生成する。
ルーティング：中間階層モデル。顧客向けではなく、有用な要約です。コスト：チケット当たり約$0.004。
ステップ7：品質を確認する。 回答は基準を満たしていますか？
ルーティング：高速な判定役としてClaude Haiku 4.5を使います。コスト：チケット当たり約$0.002。
これらはモデルケースの数値です。独自のトラフィックで再計算できるよう、想定トークン量を手順ごとに示しています。
AIが回答するチケット（70%と仮定）：チケット当たり約$0.022。 人間にエスカレーションするチケット（30%）：チケット当たり約$0.009。 加重平均：チケット当たり約$0.018。
代わりにすべての手順をフラッグシップ推論階層で実行すると（同じトークン量、入力約$5/M、出力$25/M）、チケット当たり約$0.06～0.08です。マルチモデル方式なら請求額を約70～75%削減できます。
1日1,000件なら、約$50/日、年間では約$18,000の節約です。大きな金額ですが、運用面でより大きな利点は通常レイテンシです。ルーティングされたパイプラインなら、単純なチケットに30秒ではなく1秒で回答できます。
ルーティングロジック
ルーティングの実装方法はいくつかあります。
アプローチ1：タスクの種類でハードコードする
最も単純です。呼び出すタスクが分かっているため、モデルを選びます。
def classify(text):
return openai_client.chat.completions.create(
model=SMALL_TIER, # 利用中のプロバイダーの現行小規模モデル
messages=[{"role": "user", "content": f"分類してください：{text}"}],
)
def respond(context, query):
return claude_client.messages.create(
model="claude-sonnet-5", # IDは2026-07-07に確認済み
max_tokens=1024,
messages=[{"role": "user", "content": f"コンテキスト：{context}\n\n質問：{query}"}]
)
長所：透明性があり、デバッグと変更が容易です。 短所：同じ種類のタスク内でリクエストの複雑さに適応しません。
アプローチ2：ルーターモデル
小規模モデルが各リクエストを分類し、ルーティングします。
ROUTER_PROMPT = """
このリクエストをtrivial、moderate、complexのいずれかに分類してください。
1語だけを出力してください。
リクエスト：{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)
長所：適応性があり、平均コストが低くなります。 短所：エスカレーションが必要なケースでは低速（2回呼び出す）になり、信頼できる検証が必要です。
実際の本番システムでは、主要なタスク種類はハードコードでルーティングし、ばらつきの大きい特定のサブタイプにはカスケードを使う、ハイブリッド方式がよく採用されます。
落とし穴
避けるべき間違いを挙げます。
落とし穴1：品質を低下させながらコストを最適化する
すべてを小規模モデルへルーティングしてコストを下げるのは簡単です。品質も低下したことに気づくのは困難です。ルーティングの変更には、必ず品質監視を組み合わせてください。
有効な規律として、タスクを安価なモデルへ移す際は、品質指標を使って1週間A/Bテストします。品質が維持されたという根拠なしに変更をリリースしないでください。
落とし穴2：ルーターを過剰設計する
高度なロジックで100種類のタスクを扱うルーターは、置き換え対象のルーティングより保守が困難です。単純に始めてください。高度な方式の80%の効果を単純な方式で得られるなら、単純な方をリリースします。
よくある構成では、5～10種類のタスクを扱う50行のルーターで、効果の90%を得られます。それを超えると、収穫逓減が生じます。
落とし穴3：レイテンシを無視する
通常、安価なモデルは高速でもあり、これは利点です。しかしカスケード（安価なモデルを試してからフラッグシップへ移る）では、難しいケースのレイテンシが倍増する可能性があります。ユーザー向けのフローでは重要です。
レイテンシに敏感なユーザー向け回答では、既定でフラッグシップを使ってコストを受け入れる方法が有効です。カスケードはバッチ処理または非同期処理に使ってください。
落とし穴4：プロバイダー障害に対応しない
複数のモデルに依存すると、障害の起き方も増えます。フラッグシップモデルの停止、レート制限、APIキーの期限切れなどです。ルーティングロジックにはフォールバックが必要です。
最低限、すべての「プライマリ」モデルに、別のプロバイダーの「フォールバック」モデルを用意します。フォールバックで品質が低下しても、システムは稼働し続けます。
落とし穴5：ルートごとの品質を測定しない
どのルートが良好で、どれがそうでないか把握する必要があります。そのためには評価が、できれば自動評価が必要です。
有効な構成は、本番の呼び出しごとに、使用モデル、リクエスト、レスポンス、可能であれば品質シグナル（ユーザーのフィードバック、後続指標、自動評価）を記録することです。ルート別の指標に集約し、ユーザーから苦情が来る前に品質ドリフトを捉えます。
今後の方向性
次のような傾向が予想されます。
サービスとしての自動ルーティング。 OpenRouter、Helicone、Portkeyなどは、設定可能なルールに基づいてモデルを選ぶ「スマートルーティング」の提供を拡大しています。大きく成熟していくでしょう。
モデルごとの特化が進む。 コード、数学、特定分野に特化したモデルが増え、ルーティングには特化型モデルがさらに組み込まれます。
コストが下がり続ける。 2026年のモデルは、同等品質の2024年モデルより10倍安価です。2028年までに、さらに10倍下がると予想されます。マルチモデル・オーケストレーションの経済性は改善し続けるでしょう。
オンデバイス階層。 ローカルAI機能を備えたスマートフォンやノートパソコンは、一部のリクエストに「無料」の階層を提供します。ルーティングロジックには、「可能ならデバイス内に留める」という選択肢が次第に加わります。
プロバイダー間のAPI標準化。 OpenAI互換APIはすでに広く採用され、プロバイダーの切り替えはますます容易になっています。標準化がさらに進み、複数プロバイダー戦略を採用しやすくなるでしょう。
スターターチェックリスト
マルチモデルシステムをゼロから構築する場合、または単一モデルから移行する場合は、次の手順を使います。
-
タスクを洗い出す。 アプリはどのようなLLM呼び出しを行いますか？頻度とコストはおおよそどの程度ですか？
-
複雑さで分類する。 タスクの種類ごとに、単純、中程度、複雑のいずれかを決め、モデル階層に対応させます。
-
ルーターを構築する。 ハードコードしたタスクベースのルーティングから始めます。過剰設計は避けます。
-
フォールバックを追加する。 すべてのプライマリモデルに、別のプロバイダーのフォールバックを用意します。
-
ルートごとに品質を測定する。 ロギングと基本的な評価を設定します。品質が維持されているか把握する必要があります。
-
反復改善する。 品質を維持できるタスクは安価なモデルへ移します。品質が崩れるタスクは高価なモデルへ戻します。継続的に調整します。
-
調整を止めない。 モデルは変わり、新しいモデルが登場し、価格も動きます。2026年5月に最適なルーティング構成が、2026年11月には最適でない可能性があります。
あらゆる用途に1つのモデルを使うのをやめる
マルチモデル・オーケストレーションは、本番AIシステムで最も高いROIが見込める変更の1つです。適切に実装すれば、各タスクに適したモデルを使うことで、多くの場合は品質を向上させながらコストを60～90%削減できます。
技術的なハードルは低く、基本的なルーティングロジックは数十行のコードです。一方、運用上の規律には高いハードルがあります。ルーティングの判断が妥当であり続けるよう、品質を継続的に測定する必要があります。
あらゆる用途に1つのモデルを使うのをやめましょう。タスクを洗い出し、それぞれに適したモデルを選び、結果を測定し、反復改善してください。削減効果は現実的で、品質向上は多くの場合、その副次的な恩恵です。
