LLM APIコストを半分に削減：2026年の本番ワークロード向けモデルルーティングガイド

請求書に潜むコストの問題

本番コードの model パラメータを見てください。プロトタイプ段階を越えて実トラフィックを処理している多くのチームでは、そのパラメータは一度（出荷時点でアクセス可能だった最強モデルに）設定されたまま見直されません。クエリの複雑さに関係なく、すべて同じモデルに送られます。そこに、静かに膨らむコスト超過が潜んでいます。

現実的な本番ワークロードでは、クエリの難易度は一様ではありません。カスタマーサポートのアシスタントなら、80%は単純なルックアップ、分類、短いフォローアップで、20%が最先端の推論を要するものかもしれません。コーディングアシスタントは、小さなリファクタリングが安定して流れ、マルチファイルのアーキテクチャ変更のロングテールが混じります。コンテンツパイプラインでは、構造化されたクリエイティブライティングを要する1件に対し、数百件の要約タスクを処理することもあります。仕事の「形」は不均一なのに、モデルへのルーティングはそうではありません。

もし今日、GPT-5.5 で月に 100M tokens を処理していて、そのうち 70% がより安価なモデルでも同等に回答できるなら、使っていない能力に対して毎月およそ $600 を支払っていることになります。ボリュームが大きくなると、このパターンは線形に累積します。1B tokens ごとに、ルーティングしない場合とルーティングする場合の差は、毎月数千ドルに達します。

ルーティングは、その非対称性に対するエンジニアリングの解です。原則は単純です。各クエリを「対応可能な中で最も安いモデル」に送り、必要なときだけより高性能なモデルにエスカレートする。実装こそがトレードオフの宝庫ですが、多くの公開ガイダンスはこの扱いが粗い。本稿では、本番で実際に機能する3つのパターン、費用対効果の算数、見落としがちな失敗モード、そしてアプリケーションを書き直すことなく単一モデル構成からルーティング構成へ移行するプレイブックを扱います。

本稿の価格データは、併載の（2026 LLM API 価格比較）から引用しています。本文で挙げるコスト数値はすべてそのデータに基づきます。

本番で機能する3つのルーティングパターン

LLM トラフィックのルーティングには、確立された3つのパターンがあります。実装の複雑さ、レイテンシのオーバーヘッド、得られるコスト削減の種類が異なります。ほとんどの本番システムは最終的にこれらを組み合わせて用います。それぞれの強みを理解することは、作業の優先順位づけに役立ちます。

パターン1：静的ルール

最も単純なパターンです。入力長、ユーザーのティア、クエリ種別（既存の分類器があれば）、API エンドポイント、ビジネスロジックなど、リクエストの観測可能な属性に基づいて異なるモデルへルーティングします。短いクエリは安いモデルへ、長いクエリは強いモデルへ。フリーティアのユーザーには安いモデル、有料ユーザーには高いモデル。コード生成リクエストはコード特化モデルへ、それ以外は汎用モデルへ。

静的ルーティングは予測可能でデバッグしやすく、レイテンシのオーバーヘッドはほぼゼロです。ルーティングの判断はローカルで数行のコードが走るだけだからです。一方で天井も低めです。実行前に観測可能な属性に基づいてルーティングするため、「実際にそのクエリがどれだけ難しいか」には基づけません（まだ分からないため）。入力属性と難易度の相関が高いワークロード（長文はたいてい難しい、コードは通常プローズと異なる、有料ユーザーのクエリは一般に要求が高い）では、静的ルールだけで、わずかな工数で利用可能な削減幅の30–50%を獲得できます。

パターン2：カスケード

最も広く適用できるパターンです。まず安いモデルにクエリを投げ、応答が品質しきい値を満たしていればそれを返し、満たさない場合にだけより高性能なモデルへエスカレートしてその応答を使います。安いモデルで対応できたクエリについては安いモデルの料金だけを支払えばよい、という点でコストが削減されます。

カスケードの特徴は、ルーティングの判断が入力ではなくモデルの出力に基づく点です。安いモデルに一度やらせ、その出来が十分かどうかを判定します。判定方法は複数あります。モデル自身の信頼度スコア、構造化出力の検証（期待するスキーマとしてパースできるか）、自己評価プロンプト（小さなモデルに「応答が質問に答えているか」を採点させる）、下流の行動シグナル（ユーザーが回答を受け入れたか、言い換えて再試行したか）などです。

カスケードは、静的ルールでは拾いきれないコスト削減を実現できるため、ほとんどの本番システムが最終的に採用するパターンです。トレードオフは、エスカレートするクエリでは「安いモデル」と「フラッグシップ」の両方のコールに対価を払うことになる点で、削減額は安いモデル層で成功するクエリの割合に依存します。本稿の後半でこのパターンを詳細に扱います。

パターン3：分類器ベースのルーティング

最も高い上限を持ち、最も多くのエンジニアリング投資を要します。小さく高速なモデル（しばしばサブフロンティアモデルのファインチューニングや専用の分類器）が各インカミングクエリを見て、下流のどのモデルで処理すべきかを予測します。分類器は、クエリ種別（「これはコード生成タスクに見える。コード特化モデルへ」）、難易度推定（「これは難しい推論クエリに見える。GPT-5.5 へ」）、または過去のトラフィックと結果で学習したルーティングポリシーに基づいて判断します。

分類器ベースは、ルーティングの判断が高価なモデルの実行前に行われるため、最終的にフラッグシップが必要になるクエリについて「安いモデル税」を払わずに済む点で、カスケードを上回り得ます。その代償は、分類器自体の構築・学習・運用の工数と、ルーティングコール分の小さなレイテンシオーバーヘッドです。非常に大規模なワークロードでは、このトレードオフは見合いますが、小規模なワークロードでは通常見合いません。

どのパターンから始めるべきか： ワークロードに明確なルーティングシグナル（入力長、ユーザーティア、エンドポイント）があるなら静的ルールから。無いなら、あるいは静的ルールで取り尽くした後はカスケードへ。分類器ベースは、静的とカスケードを両方導入した後で、ボリュームがエンジニアリング投資を正当化できる場合に限って。いきなり分類器ベースへ飛びつくのは、典型的な過剰設計の罠で、多くのチームが後悔します。

ルーティングを始める前に計測すべきこと

計測できないものは最適化できません。本番システムにルーティングロジックを導入する前に、現在の単一モデルのワークロードに計測を入れ、比較のためのベースラインを用意してください。計測は手の込んだものである必要はありません。各リクエストを小さなフィールド集合とともに記録する基本ログで十分です。

最低限、有用な計測項目：

• リクエスト単位： 使用モデル、入力トークン数、出力トークン数、コスト（トークン数とレートカードから算出）、エンドツーエンドのレイテンシ、レスポンスステータス（success / error / partial）、クエリ種別ラベル（あれば）
• 会話単位またはユーザー単位： セッション長、リトライ回数（最初の回答をユーザーが受け入れなかったシグナル）、フォローアップ率（回答に追加の説明が必要だったシグナル）
• ホールドアウト評価セット： 100–500 件の代表的なクエリと、信頼できる参照出力。これで候補の安価なモデルが、あなたのワークロードで許容品質を出せるかを測ります。これが無いと、すべてのルーティング判断は当て推量になります。

評価セットは、多くのチームが投資不足になりがちな一方で、ルーティングプロジェクトにおける最もレバレッジの高い基盤です。Promptfoo や Helicone evals のような軽量ツールで素早く立ち上げられます。初期段階のワークロードなら、手作業で精査した 50 件のクエリと手動採点でも十分な出発点になります。

計測を入れたら、最低 1 週間は現状のままワークロードを回してベースラインを確立してください。データの形（入力長の分布の偏り、短く単純なクエリの割合、難しそうなものの割合）は、どのルーティングパターンから始めるべきかを示してくれます。

コスト算数で見るカスケードパターンの詳細

カスケードは最も普遍的に適用でき、多くのチームが最初か次に実装するパターンです。算数が、ルーティングの意義を具体化させます。

今日、Claude Sonnet 4.6 で動いている代表的な本番ワークロードを考えましょう：月間 100 million tokens、入力 80%／出力 20%、リスト価格で月額 $475。ここにカスケードを導入するとします。クエリはまず Claude Haiku 4.5 に投げ、Haiku の応答が品質チェックに落ちた場合のみ Sonnet 4.6 にエスカレート。Haiku 4.5 は input $1.00／output $5.00 per million tokens と、Sonnet の約 3 分の 1 のレートです。

コスト算数は 2 つのパラメータに依存します。Haiku 層で成功するクエリの割合（成功率）と、成功したクエリとエスカレートしたクエリの入力／出力比の違いです。単純化のため、両者の入力／出力比は同じとし、成功率は 70%（つまり Haiku の応答が 10 件中 7 件は十分）とします。

ここから言えること。 成功率が中程度の 70% でも（Haiku が 10 回に 7 回正解する）、カスケードは請求額を半分にします。理由は、安いモデルのコールはフラッグシップに比べて非常に安く、エスカレートする 30% のクエリで両方を呼んだとしても、全クエリでフラッグシップを呼ぶよりもはるかに安いからです。損益分岐点（カスケードと単一モデルのコストが等しい点）は、おおよそ成功率 33% 付近です。これを下回るなら直行の方が得で、上回るならカスケードが勝ちます。

最小実用カスケードの実装

以下は最も単純なバージョンを、OpenAI 互換クライアントで書いた Python で表現したものです（OpenAI 互換エンドポイントを提供する任意のプロバイダに対して動作します。Anthropic の互換レイヤ経由の Claude、Gemini、そして CometAPI の統一エンドポイントを含みます）。構造は意図的に最小限です。本番実装では観測、エラーハンドリング、より高度な品質チェックを追加します。

from openai import OpenAI
import json

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.cometapi.com/v1",  # or your provider of choice
)

CHEAP_MODEL = "claude-haiku-4-5"
FLAGSHIP_MODEL = "claude-sonnet-4-6"


def cascade(messages, output_schema=None):
    """
    Run a query through a cascade.
    Returns (response, model_used, escalated).
    """

    # Step 1: try the cheap model
    cheap_response = client.chat.completions.create(
        model=CHEAP_MODEL,
        messages=messages,
        response_format=output_schema,
    )

    cheap_text = cheap_response.choices[0].message.content

    # Step 2: judge whether the cheap response is good enough
    if is_acceptable(cheap_text, output_schema):
        return cheap_text, CHEAP_MODEL, False

    # Step 3: escalate to the flagship
    flagship_response = client.chat.completions.create(
        model=FLAGSHIP_MODEL,
        messages=messages,
        response_format=output_schema,
    )

    flagship_text = flagship_response.choices[0].message.content

    return flagship_text, FLAGSHIP_MODEL, True


def is_acceptable(response_text, output_schema=None):
    """
    Quality gate.
    Returns True if the cheap model's output is good enough.
    """

    if not response_text or len(response_text.strip()) < 10:
        return False

    if output_schema:
        # Structured output: it has to parse against the schema
        try:
            parsed = json.loads(response_text)
            return validate_schema(parsed, output_schema)

        except (json.JSONDecodeError, ValueError):
            return False

    # For free-form responses, plug in your own quality signal:
    # - confidence score from the model
    # - self-evaluation prompt to a small model
    # - rules-based checks (length, format, refusal patterns)

    return True

これは出発点であって完成実装ではありません。本番に向けて追加すべき 3 点：

• 実質的な品質ゲート。 上の is_acceptable 関数は意図的に最小限です。実際には、ゲートがカスケードの最重要部品です。甘すぎると低品質の回答を出荷し、厳しすぎるとエスカレートが多発して削減効果を失います。多くの本番カスケードは、構造化出力の検証、拒否応答の検出（安いモデルが「回答できない」と言う）、小さなモデルによる自己評価（応答の採点）を組み合わせます。
• リクエスト単位の可観測性。 どのモデルが使われたか、リクエストがエスカレートしたか、各ティアのレイテンシ、コストを記録します。これにより、カスケードを 1 週間運用した後、成功率が想定どおりかどうかが分かります。
• 評価のためのカナリア経路。 トラフィックの一部（例えば 5%）は、安い層でカスケードが成功してもフラッグシップを通します。ホールドアウトの採点タスクで応答を比較します。これにより、静かな品質低下を検知できます。詳細は次節を参照。

ルーティングが破綻するところ

上のコスト削減の算数は本当ですが、同時に楽観的なケースでもあります。3 つの失敗モードでつまずきやすく、これらを率直に名指しすることが、価値を積み上げるルーティング実装と、密かにプロダクトを劣化させる実装を分けます。

エスカレート時のレイテンシオーバーヘッド

クエリがエスカレートすると、フラッグシップの呼び出しが始まる前に安いモデルのコール分を支払います。安いモデルが 800ms、フラッグシップが 1.5s なら、エスカレートしたクエリのエンドツーエンドは 2.3s になります。レイテンシに敏感なワークロードでは重要です。緩和策は、速い安価モデル（Haiku 4.5 や Gemini 3 Flash はこの設計）を選ぶ、安価モデルには攻めたタイムアウトを設定する、エスカレートしやすいと疑われるクエリには並列コールを検討する、などです。ドルの削減が大きいためレイテンシコストを受け入れるチームもあれば、静的ルールで明らかに難しいクエリをそもそもカスケードに回さないチームもあります。

静かな品質低下

最も陰湿な失敗モードです。安いモデルが品質ゲートを通過するものの、フラッグシップに比べて微妙に劣る応答を出します：わずかに正確性が低い、わずかに助けにならない、ややエッジケースを見逃しやすい。ユーザーはすぐには不満を言いません。監視しているメトリクス（応答レイテンシ、エラーレート、ゲート合格率）は問題なく見えますが、下流の指標（ユーザー維持、コンバージョン、サポートエスカレーション）がじわじわと悪化します。気づいたときには、数週間にわたって品質劣化を出荷してしまっています。

防御策は前述のカナリア経路です。カスケードと並行してフラッグシップを通すホールドアウトのトラフィック比率を設け、評価基準に基づいて両応答を採点します。採点はモデル（LLM-as-judge）でも人手サンプリングでも構いません。重要なのは、カスケード自身のゲートとは独立した継続的な品質シグナルを維持し、劣化が下流の驚きではなく、そのシグナルのドリフトとして表面化するようにすることです。

コードと可観測性における複雑性コスト

ルーティンググラフにモデルを 1 つ追加するごとに、評価・監視・プロバイダのバージョン更新対応が 1 つ増えます。2 層のカスケードは管理可能ですが、コード／RAG／チャット／エージェント／例外系で経路を分けた 5 モデルの分類器ベースルーターは、置き換え前の単一モデル構成よりも有意に複雑です。ワークロードのボリュームがそれを正当化するなら、複雑性は価値があります。そうでないなら、ルーティング層の保守に費やす工数がもたらすコスト削減を上回り得ます。自分たちのボリューム閾値に正直でいてください。

アグリゲータの助けになる点（ならない点）

LLM アグリゲータ（複数モデルを単一の OpenAI 互換 API で提供するサービス）は、ルーティングと 2 つの異なる形で相互作用します。どちらも理解する価値があります。「ルーティングスタックにアグリゲータを入れるべきか？」の答えは、どちらの相互作用を重視するかによって変わるからです。

本当に助かる点：統合コストの除去

プロバイダのネイティブ API でカスケードや分類器ベースのルーターを組むと、SDK が複数、認証クレデンシャルが複数、請求面も複数、さらにプロバイダ固有の癖（タイムアウト挙動、エラーフォーマット、レート制限語彙）への対応が必要になります。マルチモデルのルーティング構成では、このオーバーヘッドは現実です。CometAPI のようなアグリゲータは、すべてのモデルを単一の OpenAI 互換エンドポイントで提供するため、ルーティングのコード変更は model パラメータを変えるだけで済みます。プロバイダの切り替えも、鍵の分離も、観測レイヤの分離も不要です。ルーティングの主障害が「統合コスト」であって「品質評価コスト」ではないチームにとって、これは決定的です。

注意点：ビルトインのルーティングレイヤ

一部のアグリゲータは、クエリに基づいてモデルを選ぶ「スマートルーティング」や「モデル最適化」機能を提供します。プロトタイピングには有用ですが、本番のデフォルトとしては一般に不適切です。理由は、ルーティング判断がスタックの中で最もワークロード特異的なものの 1 つだからです。「どの程度の難しさでエスカレートするか」は、評価基準、レイテンシ予算、品質基準、コスト上限に依存します。汎用のルーティングレイヤはこれらを知り得ません。多くの本番システムにとっては、（直接アクセスするのと同じモデルを 1 つのクレデンシャルと 1 本の請求で提供する）薄く透明なアグリゲータの上に、自前のルーティングロジックを載せる方が、チューニング不能なブラックボックスのルーティングレイヤを使うより良い選択です。

移行プレイブック

単一モデルの本番ワークロードからルーティング構成へ、安全に段階的に移行する道筋です。基本原則は、一つひとつの変更が単独でロールバック可能であること、そして各変更のインパクトを測ってから次に進むことです。

• 現行ワークロードへ計測を入れる。 すべてのリクエストについて、モデル、入力／出力トークン、コスト、レイテンシ、クエリ種別ラベルを記録します。最低 1 週間は実行してベースラインを確立。これが無ければ以降の工程はすべて当て推量です。
• 評価セットを構築する。 信頼できる参照出力つきで、代表的な 100–500 クエリを精選します。以後、各ステップで単一モデルのベースラインとカスケードを比較するためのホールドアウト集合になります。
• 最もボリュームの大きいクエリ種別を特定する。 計測データから、トラフィックの最多カテゴリを見つけます。ここでカスケードのパイロットを行います。最も簡単なカテゴリである必要はありません。節約が集中するため、最大ボリュームが望ましいのです。
• その 1 種類のクエリに対してカスケードのプロトタイプを作る。 2 ティア構成：まず安いモデル、品質ゲートに落ちたらフラッグシップ。まず評価セットで回します。単一モデルのベースラインとコスト・品質を比較。品質が維持されコストが下がるなら次へ。品質が落ちるならゲートを厳しくして再試行。
• トラフィックの一部の裏側でロールアウトする。 選んだクエリ種別について、本番トラフィックの 5–10% から開始。最低 1 週間は回します。カスケードのエスカレーション率、リクエストあたりコスト、各ティアのレイテンシ、カナリア経路での品質比較を監視。プロトタイプの予測と一致するなら 25% → 50% → 100% と拡大。
• 次のクエリ種別でも繰り返す。 最初の種別が完全移行し、コスト削減が実現したら、次にボリュームが大きいカテゴリへ。各カスケードは独立した判断です。ある種別でうまくいったパターンが別の種別でも通用するとは限りません。
• 継続的な品質カナリアを常設する。 複数種別がカスケードで動くようになったら、ホールドアウトのカナリア経路を恒常化します。トラフィックの 5% をフラッグシップで採点に回す。これは静かな劣化の早期警戒システムであり、モデルの更新があってもルーティング層の信頼性を保つ手段です。

ルーティングが見合わない場合

率直な認めです。ルーティングへの投資が回収に見合わないワークロードがあり、最初からそれを見極めることは時間の節約になります。

• 一つのモデルが本当にすべてに最適解である単一モデルのワークロード。 評価セットが、安価層のモデルでワークロード全体の品質が意味のあるレベルで落ちると示す場合、カスケードが活かせる余地はありません。推論能力がボトルネックになっているコード生成ワークロードなどが一例です。Haiku はゲートに落ちすぎ、カスケードでは節約になりません。
• 非常に低ボリュームのワークロード。 LLM の支出が月約 $200 を下回ると、ルーティング層の構築と保守に費やす工数が、得られる削減額を上回るのが通例です。閾値はワークロード依存ですが、現実に存在します。自分たちの支出が投資に見合うほど高いか、正直に見極めましょう。
• ベンダー・オブ・レコードが重要な規制環境。 コンプライアンス上、本番トラフィックを特定のプロバイダ関係に限定する必要がある場合、マルチモデルのルーティングはその議論を複雑にします。同一プロバイダ内でのルーティング（Anthropic 内で Sonnet → Opus、OpenAI 内で GPT-5 nano → GPT-5.5）なら選択肢はまだありますが、プロバイダ横断のルーティングは正当化が難しくなります。

率直な枠組み：ルーティングは、ワークロードのボリュームが大きく、クエリの難易度が一様ではなく、カスケードが許容品質を出しているかを判断する評価基盤があるときに、費用対効果が出ます。本番で意味のある規模の多くのワークロードがこの記述に当てはまります。一方でそうでないものもあり、単一モデルに留まる方が速く出荷できます。どちらの選択も、状況次第で正当化されます。

次に進むには： まだ参照していない場合は、併載の 2026年 LLM API 価格比較：GPT-5.5、Claude Sonnet 4.6、Gemini 3.5 Flash、DeepSeek V4 が基礎になります。そこにある価格データが、本稿のコスト算数をあなたのワークロードに引き直す土台です。