LLMのトークンコストを抑えるモデルルーティング｜利用量の可視化と使い分けの基準

モデルルーティングとは、リクエストごとに転送先のモデルを選び分ける仕組み。コスト削減を目的とする場合は、そのタスクを処理できる最も安いモデルへ流す形になる。

安いモデルへ流す前に、何にどれだけトークンを使っているかを測っていなければ、振り分けの基準は作れません。米国の上級ビジネスリーダー534人を対象にした EY の AI Pulse 調査では、AI に投資している組織の回答者のうち82%がトークン利用コストを懸念する一方、予算のガードレールを設けて使用量を能動的に監視していると答えたのは64%にとどまりました。設問は「能動的な監視」と「明確な予算ガードレール」の両方を備えているかを聞いているので、同じ母数の3分の1超は、その両方が揃っているとは答えていないことになります。

モデルルーティングは「安いモデルに流す」の一言では終わりません。測る → 単価差を確かめる → 呼び出し自体を減らす → 残りを振り分けるの4段に分かれます。並べた順がそのまま着手の順で、キャッシュやバッチで呼び出し自体を減らせる範囲を先に潰しておくほうが、振り分けを当てる範囲が狭くなります。

LLMのトークンコストはどこで膨らむのか

LLM のトークンコストは、モデル1回あたりの単価よりも、1つのタスクを終えるまでにモデルを何回呼ぶかで決まる部分が大きくなります。チャット窓に1往復入力する使い方なら請求額は読めますが、計画を立て、ツールを呼び、結果を検証し、失敗したらやり直す構成では、利用者から見た「1タスク」の裏で何回もモデルが動きます。

しかも、往復のたびに直前までの文脈を丸ごと送り直すため、入力トークンは会話が進むほど積み上がります。単価表の数字を眺めているだけでは、この積み上がりは見えません。エージェント型のツールを本番へ載せたときにコストが読みにくくなるのは、この構造によるものです。

会計事務所の EY は、この問題に対して自社で「AI ルーター」と呼ぶ仕組みを構築しました。各タスクを処理できる最も安いモデルへ自動で振り分けるもので、利用者側の操作は変わりません。モデルを開き、プロンプトを入れ、回答を受け取る。その裏でどのモデルが選ばれたかは意識せずに済む設計です。同社のグローバル AI コンサルティングリーダーである Dan Diasio 氏は、一部部門でトークン消費が最大60%減ったと述べたと報じられています。ただし EY 自身の説明では、この60%はルーター単体の効果ではなく、研修と統制の施策を併せた2026年4月の導入以降の減少幅とされています。自社事例である以上、どの組織でも同じ幅が出るわけではありません。

EY 公式リリースでの Diasio 氏の発言は、支出の潮目が変わったことを端的に示しています。

「AI が時間を節約する」は、もはや十分なビジネスケースではない。

EY 公式ニュースルーム 2026年7月のリリース（Dan Diasio 氏の発言より一部抜粋。URL は記事末尾の参考資料）

問いは、導入するかどうかから、いくらで何を得ているかへ移りつつあります。EY 自身は AI に年間10億ドル超を投じ、約1,000体の AI エージェントを運用していると報じられています。もっとも、規模の桁が違ってもコストが膨らむ構造（1タスクあたりの往復回数と、往復ごとの文脈の送り直し）は変わりません。違うのは総額ではなく、削減額が判定コストと検証の手間を上回るかどうかの分岐点です。月数百ドル規模でも、支出が特定の用途に偏っていれば振り分けで削れます。

振り分けが成立する条件

ルーティングが意味を持つのは、すべてのリクエストが最上位モデルを必要としないからです。ログを分類する、決まった書式へ変換する、短い文章を要約する。こうした処理は最上位モデルでなくても結果が変わりにくい一方、単価は階層によって何倍も違います。

逆に言えば、扱っているタスクが全部同じ難易度で、しかも全部が最上位モデルを必要とするなら、振り分けても削れる余地はありません。最初の確認事項は「自社のリクエストは難易度が散らばっているか」です。散らばっていなければ、「呼び出し自体を減らす」側から手を付けるほうが早い場合もあります。

まず利用量を可視化する（モデル別・用途別・入出力別の内訳を取る）

利用量の可視化とは、請求額の合計を、モデル別・タスク種別・入出力別の3軸へ割って把握することを指します。合計額だけを見ても、どのモデルをどう替えれば下がるかは決まりません。

最初に押さえるのは入出力の内訳です。Anthropic 公式の価格ページによれば、Claude Opus 5 は入力100万トークンあたり5ドル・出力25ドル、Claude Sonnet 5 は入力2ドル・出力10ドル、Claude Haiku 4.5 は入力1ドル・出力5ドル（2026年8月30日確認）。いずれも出力側が入力側の5倍です。なお、一時は予定されていた Sonnet 5 の入力3ドル・出力15ドルへの引き上げについては、行われないと同じ価格ページに明記されています。つまり長文を生成させる用途と、長文を読ませて短く答えさせる用途では、同じトークン数でも請求額の伸び方がまるで違います。合計トークン数だけを追っていると、この差は見えなくなります。

次にタスク種別。同じモデルを呼んでいても、社内文書の要約と、コードの修正提案では、1タスクあたりの往復回数も出力量も別物です。リクエスト単位ではなくタスク単位で合計しないと、「1回あたりは安いが回数が多い処理」が過小評価されます。

測る手段は3系統に整理できます。ベンダー純正のレポートとして、Anthropic 公式には Claude の Admin 使用量レポート API があり、組織単位の消費をプログラムから取得できます。3軸のうち2軸は、ここで機械的に取れる部分です。group_by=model でモデル別に割れ、未キャッシュ入力・キャッシュ読み出し・出力が分かれて返るので入出力別の内訳もそのまま出ます。OSS のトレーシング基盤としては Langfuse と Helicone があり、どちらも自前のサーバへ立てる分は無料です。運用の手間を払いたくない場合のクラウド版は、Langfuse 公式の価格ページによれば無料の Hobby プランに月50,000ユニットの取り込みが含まれ、有料は月29ドル / 199ドル / 2,499ドルの3段階、10万〜100万ユニット帯の超過は10万ユニットあたり8.00ドル。Helicone 公式の価格ページでは無料枠が10,000リクエスト、Pro が月79ドル、Team が月799ドルと記載されています（いずれもクラウド版の料金、2026年8月30日確認）。3系統目は自前のログですが、リクエストごとにモデル名・タスク種別・入出力トークン数を必ず一緒に残すこと。テナント単位で課金まで積む場合は、即時カウントと課金記録を分ける設計が別途要ります。この3つが揃っていないログは、後から振り分け判断の材料になりません。

測っていない状態で振り分けると何が起きるか

計測なしで振り分けを入れると、削減額を主張できません。導入前後の比較対象がないためです。それ以上に困るのは、品質が落ちたときに原因を特定できないことです。安いモデルへ流れた結果なのか、プロンプトを変えた影響なのか、切り分けようがありません。

さらに、削減の当たりを外しやすくなります。実際には出力の長い1用途が請求額の大半を占めているのに、呼び出し回数の多い別用途を安いモデルへ移して「あまり下がらなかった」と結論づける。よくある取り違えです。支出が一部の用途に偏っているかどうかはここで初めて見えるため、まずは支出の大きい順に並べ替えるところから入るほうが確実です。

どのタスクをどのモデルに回すか、振り分けの基準をつくる

どの階層のモデルへ流すかは、タスクの性質と許容できる品質差から、あらかじめ言葉で決めておきます。ルーティングが費用面で成立するのは、同じベンダー内でもモデル階層によって単価が大きく開いているためです。

Claude では Opus 5 と Haiku 4.5 で出力単価に5倍の開きがあります。OpenAI 公式の価格ページの標準（Standard）ティア・short context の行では、gpt-5.6-sol が入力4.00ドル・出力20.00ドル、gpt-5.6-terra が入力2.00ドル・出力12.00ドル、gpt-5.6-luna が入力0.20ドル・出力1.20ドル（100万トークンあたり、2026年8月30日確認。sol は公式ページに期間限定のプロモーション価格と記載）。同じページには Batch / Flex / Fast mode の各ティアと long context の行も並んでおり、たとえば Fast mode の short context では sol が入力8.00ドル・出力40.00ドルになります。どの行を見ているかで金額が変わるので、自社の利用条件に対応する行で読む必要があります。sol と luna の入力単価差はどのティア・どの文脈長で揃えても20倍で、比自体は表の選び方に依存しません。この開きが、振り分けで得られる差額の原資になります。ただしここで挙げた単価はいずれも各社 API の直販価格で、Bedrock や Azure 経由では料金体系が別です。実際の差額は、自社が通す経路の価格表で計算し直す必要があります（経路ごとに消費の出方が変わる例はGLM-5.3 の経路別コスト比較で扱いました）。単価と課金仕様は改定も速いため、最新値は各社の公式 pricing ページで確認を。

基準を言葉にするときは、「難しいタスクは上位へ」では運用できません。判定できる形に落とす必要があります。入力の長さ、期待する出力の長さ、失敗したときのやり直しコスト、正解が一意に決まるかどうか。このうち受信時点でそのまま測れるのは入力の長さだけです。残り3つはタスク種別ごとに事前に決めておき、リクエストに種別のタグを付けて参照する形にすれば、判定自体は機械的に回せます。下位へ倒せるのは「正解が一意に決まる」かつ「やり直しが安い」が揃うタスクで、やり直しコストの高い処理は、失敗したときの受け皿を上位に用意する前提でしか落とせません。裏を返せば、振り分けの判定材料になるのは、可視化で作ったタスク種別の分類そのものです。

単価差だけを見て階層を決めると読み違える箇所もあります。Anthropic 公式ドキュメントによれば、Claude 4.7 以降のモデルは新しいトークナイザを使っており、同じテキストでも約30%多いトークンを生成します。世代をまたいで比較するときは、単価の比だけでなくトークン数の増分も併せて見ないと、実際の請求額の順序が入れ替わることがあります。本記事で原資として挙げた Opus 5 と Haiku 4.5 の組も、この世代をまたいでいます。Opus 5 が新しいトークナイザ、Haiku 4.5 が従来のトークナイザなので、同じテキストでも Opus 5 側のトークン数は多く出る。5倍というのは単価の比です。同じテキストを入力する場合、入力側の実効的なコスト差は単価比の5倍より大きくなりえます。ただし増分は内容と処理の形で変わると公式も注記しており、実タスクの請求額の比がどこに落ちるかは自社のワークロードで測るしかありません。

振り分け以外にも単価を下げる手段はあります。Anthropic 公式の価格ページによれば、Claude ではキャッシュヒット分が基本入力単価の0.1倍で課金され、5分キャッシュの書き込みが1.25倍、1時間キャッシュの書き込みが2倍。即時性が要らない処理なら Batch API で入力・出力とも50%の割引を受けられます（キャッシュで逆に割高になりやすい設定は別記事にまとめています）。階層を決める前に「そもそもキャッシュやバッチで足りないか」を見ておくと、ルーティングを入れる範囲を狭くできます。順序が大事な理由はもう1つ、キャッシュがモデルごとに張られることです。同じ前提を複数モデルへ散らす振り分けを入れるとヒット率が下がり、1.25倍（5分）や2倍（1時間）を払った書き込みを読み出しで回収できないまま終わることがあります。キャッシュが当たっている経路はそのまま残し、キャッシュの当たらない単発処理から振り分けを当てるほうが噛み合います。

ルーティングの実装方式を比較する（Bedrock / Microsoft Foundry / OpenRouter / LiteLLM）

実装方式は、振り分けの判定を誰が持つかで3つに整理できます。クラウドのマネージド機能に任せるか（Bedrock / Microsoft Foundry）、複数ベンダーを束ねる集約 API に任せるか（OpenRouter）、自前のプロキシで戦略を宣言するか（LiteLLM）。おおまかには、判定を手放すほど導入は軽く、自前で握るほど手間が増えます。ただし OpenRouter のように導入も自由度も低い位置があるので、単純な一直線のトレードオフではありません。なお、ここで比べるのは「どう振り分けるか」の判定層です。統一 API・キー管理・ガバナンスといったゲートウェイ製品としての比較（Portkey・Cloudflare・Bifrost を含む）は別記事で扱っています。

Microsoft 公式ドキュメントによれば、model router の Balanced モードは最高品質モデルとの品質差が小さい範囲（例として1〜2%）で最も費用対効果の高いモデルを選び、Cost モードはより広い帯（例として5〜6%）を許容して最も安いモデルを選びます。品質差をどこまで許すかを数字で握れる点が特徴。加えて既定の構成では自動フェイルオーバーが有効で、単一モデルの一時的な障害は次点のモデルへ透過的に回されます。日本から使う場合は、Japan East / Japan West を含むリージョンで Global Standard と Data Zone Standard に対応しています。ひとつ注意が要るのは Anthropic のモデルです。公式ドキュメントは、Claude モデルだけが例外で、model router で使う前にモデルカタログから個別にデプロイしておく必要があると明記しています。

Amazon Bedrock の intelligent prompt routing は、単一のサーバーレスエンドポイントから同一モデルファミリー内の2モデルへ振り分けます。AWS 公式のコンソール手順には「exactly two models within the same family」と明記される一方、API リファレンスの CreatePromptRouter は models を配列とし「At least one model must be specified」と書くだけで上限に触れていません。コンソールで組むなら2モデル、API で組むなら現行の挙動をコンソールの Prompt Routers と実機で確かめるのが確実です。同じドキュメントには英語プロンプト向けにのみ最適化されているとも明記されているため、日本語中心のワークロードで採用する場合は事前の検証が欠かせません。日本語プロンプトでの選択精度に関する公開データは今回確認できませんでした。なお公式の対応モデル表は Claude 3.5 系・Llama 3.x・Nova 世代までの掲載で、同じページの CLI 例にはより新しいモデル ID が載っており記述が一致しません。採用前にコンソールの Prompt Routers で現行の選択肢を確認するのが確実です。

OpenRouter の Auto Router は、公式ドキュメントによればルーティング自体に追加料金がかからず、選ばれたモデルの通常料金だけを支払います。エンドポイントの差し替えだけで試せるぶん、入口としては手数が少ない方式です。ただし Auto Router はプロンプトを自動選択された第三者の推論プロバイダへ渡す方式で、データ保持や学習利用の方針はプロバイダごとに異なります。公式にはプロバイダのデータポリシーで絞り込む設定があるので、業務データを通す前に確認が要ります。

マネージドに任せる場合と自前で持つ場合の分かれ目

分かれ目は3つ。第一に、振り分けの理由を後から説明する必要があるか。監査や社内説明で「なぜこのリクエストが安いモデルへ行ったか」を示す義務があるなら、判定ロジックが非公開のマネージドは説明しづらくなります。第二に、クラウドをまたぐか。Foundry は Azure 内で OpenAI・Anthropic・xAI などをまたいで振り分けられますが、Bedrock と Foundry はどちらも自クラウド内が主戦場です。クラウドをまたいで流したいなら OpenRouter か自前になります。ただし OpenRouter は判定そのものを任せる方式なので、基準を自社で書きたいなら自前（LiteLLM）側です。第三に、運用の手が空いているか。LiteLLM を自前で立てるなら、プロキシの死活監視・モデル追加時の設定更新・障害時のフォールバック確認までが運用側の仕事になります。

裏返せば、まず効果を確かめたいだけの段階なら、マネージドから入るほうが速く進みます。日本語中心のワークロードなら、英語プロンプト最適化と明記された Bedrock は事前検証の負担が大きくなります。ただし残る3方式も日本語での選択精度は公開されていないため、どれを選んでも自社データでの突き合わせが前提です。小さなリクエストを大量に捌くなら判定課金のない OpenRouter から、という具合に入口を選べます。マネージドで削減幅の当たりを取り、制御が足りなくなってから自前へ移す。この順序のほうが失敗しにくくなります。

LiteLLM Router の最小構成イメージ

マネージドを選ぶ場合、読み手の側の作業はエンドポイントの差し替えとモードの選択で終わるため、設定として書く実体はほとんど残りません。以下は自前で判定を持つ場合に何を宣言することになるか、その最小構成イメージです。

model_list:
  # cost-based-routing が最安を選ぶのは、同じ model_name にぶら下げたデプロイの中
  - model_name: cheap
    litellm_params:
      model: openai/gpt-5.6-luna
      api_key: os.environ/OPENAI_API_KEY
      input_cost_per_token: 0.0000002
      output_cost_per_token: 0.0000012
  - model_name: cheap
    litellm_params:
      model: anthropic/claude-haiku-4-5
      api_key: os.environ/ANTHROPIC_API_KEY
      input_cost_per_token: 0.000001
      output_cost_per_token: 0.000005
  - model_name: strong
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY

router_settings:
  routing_strategy: cost-based-routing
  fallbacks: [{"cheap": ["strong"]}]

宣言しているのは2つ。cheap グループに並べたデプロイのうち最安を選ぶ戦略と、cheap 側がエラーを返したときに strong へ回すフォールバック順です。ここで取り違えやすいのは、コストベース戦略が働くのは同じ model_name にぶら下げたデプロイの中だけで、「簡単なタスクだから cheap、難しいから strong」という判定を LiteLLM が代わりにやってくれるわけではない点。どちらのグループを呼ぶかはアプリ側が決めます。コストベースの判定は、デプロイごとの入力単価と出力単価の合計を突き合わせて行われます。単価は litellm_params に input_cost_per_token / output_cost_per_token を書けばそれが使われ、書かなければ LiteLLM が持つ価格表からモデル名で引かれます。注意が要るのは 0 の扱いです。このコストベース判定は値を真偽で見るので、0 を書くと未指定と同じ扱いになって価格表へ戻ります。無料モデルを確実に最安として選ばせたいなら、現行実装では極小の正値を置く回避策がある。ただしこれは判定側に固有の話で、LiteLLM の他の機能では明示的な 0 が無料モデルの正式な指定です（公式ドキュメントは、両方を 0 にすると予算チェックを丸ごとスキップすると説明しています。未指定や null では適用されたままです）。ただし価格表に無い名前だと極端に高い既定単価が当たります。単価の判明したデプロイが同じグループにあれば、そちらに負けて選ばれません。グループ内が全部その状態だと今度は全員が同額で並び、コストでは優劣が付かなくなります。同額のときはルーター内部の並び順で先頭が採られるため、実コストが安いほうへ寄る保証はここで消えます（同額時の挙動は公式ドキュメントに規定がありません）。実際、プロバイダ接頭辞付きの名前（openai/gpt-5.6-luna）が価格表の裸のキー（gpt-5.6-luna）に一致せず、同額になった結果より高いデプロイが元のリスト順で選ばれる、という不具合が公式リポジトリに報告されています（Issue #35787、2026年8月30日時点で open）。上の設定例で単価を明示しているのは、この経路を踏まないためでもあります。この既定値は公式の中でも記述が割れていて、routing ドキュメントは deployment_cost = $1 と書く一方、判定を行う litellm/router_strategy/lowest_cost.py は入力・出力とも 5.0 を既定にしています（2026年8月30日時点の main、commit 2708620d）。どちらにせよ実単価より桁違いに大きいので、未知のモデル名や独自デプロイでは単価を明示しておくのが確実です。エラーにも0にもならず順位だけが黙って入れ替わるので、ここでは明示しました。fallbacks が発火するのも接続エラーやレート制限といった例外で、出力の質が低いことは検知しません。振り分けの結果いくらかかったかは、コールバックから取得できます。

import litellm

def track_cost(kwargs, completion_response, start_time, end_time):
    # リクエストごとの応答コストを自前の計測基盤へ送る
    print(kwargs.get("response_cost"))

litellm.success_callback = [track_cost]

ここで取れた値をモデル名・タスク種別と一緒に保存しておけば、可視化で作った記録とそのままつながります。難易度に応じて強いモデルと弱いモデルを選び分けるルーター自体は研究側でも扱われていて、応答品質を落とさない条件下でコストを1/2以下に抑えられた例が報告されています（RouteLLM, arXiv:2406.18665、ICLR 2025 採択）。ただしこれは選好データで学習した判定器を使った特定条件下の結果で、ここで示した設定ファイルがそのまま同じ幅を出すという話ではありません。判定を自前で書く方式では、その判定の質がそのまま削減幅になります。

振り分け後の品質を落とさないための検証とフォールバック設計

安いモデルへ流したタスクの出力が、上位モデルと比べて業務上許容できる範囲に収まっているか。これは請求額とは別の指標で確認します。ここを飛ばすと、コストは下がったが手戻りが増えた、という結果になりかねません。

「フォールバック」という言葉が指すものは、方式ごとに別物です。Bedrock のフォールバックモデルは基準となるアンカーで、AWS 公式ドキュメントによれば、もう一方のモデルの応答品質が設定した差だけ上回ると予測されたときにそちらへ切り替え、基準を満たさなければフォールバックモデルが処理します。リクエストを受けた時点の予測で行き先を決める仕組みで、答えが悪かった後の再試行ではありません。Foundry の model router に既定で入っているのは可用性のフェイルオーバーで、単一モデルの一時障害を次点へ透過的に回すもの。LiteLLM の fallbacks は、接続エラーやレート制限といった例外が返ったときに次のグループへ投げ直す仕組みです。裏を返せば、出力の質が低いことを検知して上位へ回し直す機能は、OpenRouter の Auto Router も含めどの方式にも標準では入っていません。品質で戻したいなら、判定と再実行は自前で書くことになります。障害時にどう振る舞うかは、導入前に一度は意図的に壊して確かめておくのが確実です。

もう1つ見落としやすいのがコンテキスト長です。Microsoft 公式ドキュメントによれば、model router の実効コンテキスト長は、振り分け先のうち最も小さいモデルの上限に制限されます。長い文書を投げる用途でルーターを噛ませると、単体のモデルを直接叩いていたときには通っていた入力が、通らなくなる可能性があります。振り分け先を model subset で絞れば下限は上がるので、長文を扱う用途では対象モデルの選定とセットで確認するのが実務的です。

そして、測っていない次元を断定しないこと。トークン数と請求額は正確に測れますが、コーディングの正確さ、事実確認の堅さ、ツール呼び出しの安定性は別の話です。「どこまで安い側に倒せるか」は、自社の実タスクで出力を突き合わせて決めるしかありません。ベンチマークの数字は出発点にはなりますが、そのまま自社の許容範囲にはなりません。突き合わせを仕組みにするなら、エージェントの評価基盤の作り方が土台になります。

段階的に適用範囲を広げる運用手順

適用は、支出の大きい上位数用途だけから始めます。品質の確認が取れてから対象を広げる進め方です。全社のリクエストを一斉にルーター経由へ切り替えると、品質の変化が起きたときに切り分けができなくなります。

順序は4段で固定できます。まず1〜2週間分の利用量を、モデル別・タスク種別・入出力別に集計する。次に支出の大きい順に並べ、上位2〜3用途を選ぶ。その用途だけをルーター経由に切り替え、切り替え直後の一定件数は上位モデルの出力と並べて突き合わせる。定常運用では、やり直しや再実行が発生した割合を品質の代理指標として実行履歴から見る。この割合が切り替え前より上がっていたら、その用途は階層を戻す。問題がなければ次の用途へ広げる。この繰り返しです。

振り分けの前段には、呼び出し自体を減らす段があります。多段で動くエージェントでは、1回を安くするより往復を1回減らすほうが総額を動かす場面があります。毎回同じ前提や仕様書を送り直しているならプロンプトキャッシュでヒット分が基本入力単価の0.1倍まで落ちますし、即時性が要らない一括処理は Batch API の50%割引の対象。手順が固まったタスクを毎回ゼロから推論させ直すのをやめる、という設計上の判断も同じ層に入ります。

実行履歴の保存は、この段階展開を支える材料でもあります。どのタスクがどのモデルで処理され、いくらかかり、やり直しが発生したか。これをリクエスト単位で残しておけば、「安いモデルへ回したせいで手戻りが増えていないか」を後から検証できます。可視化で作ったテーブルを、そのまま振り分けの答え合わせに使えます。監視のための監視ではなく、判断を戻せる状態を作るための記録です。

まとめ

支出が下がるかどうかは、ツールを選ぶ前に確かめる2つの前提と、そのあとの採算計算で決まります。前提は、扱うリクエストの難易度が散らばっているか。そして課金がトークン従量か。全部が最上位モデルを必要とするなら振り分けても削れる余地はなく、利用者単位・サービス単位の定額課金なら安いモデルへ流しても請求額は動きません。ここに当てはまらないことを確かめてから、方式の比較に入る順序です。

条件を満たすなら原資は階層間の単価差で、Claude は Opus 5 と Haiku 4.5 の間で出力側5倍、OpenAI は gpt-5.6-sol と gpt-5.6-luna の間で入力側20倍（各社 API 直販の公式 pricing、2026年8月30日確認。Bedrock / Azure 経由は別体系）。ただし手元に残るのは、削減額から判定コストを引いた残りです。小さなリクエストを大量に捌く用途ほど、1,000リクエストあたり1ドルのような判定側の課金が無視できなくなります。世代をまたぐ比較では、トークナイザの違いでトークン数自体が増える点も単価比とは別に見る必要があります。

品質側は自社で測るしかない領域です。劣化は請求額と違って自動では表面化しないため、人手のサンプリングか評価の仕組みを別に置くことになります。実効コンテキスト長が振り分け先の最小モデルに引っ張られる方式かどうかも、長い文書を扱うなら導入前に確認する対象です。

次の一歩は小さくて構いません。1〜2週間分の利用量をモデル別・タスク種別・入出力別の3列で集計し、支出の大きい上位2〜3用途だけをマネージドのルーター経由へ切り替える。効果と品質の当たりが取れてから、対象を広げるか自前構成へ移すかを決めれば間に合います。

よくある質問

Q. EY で報告された60%削減は、自社でも同じ幅が出ますか？

同じ幅が出るとは限りません。最大60%というのは EY 自社の一部部門での数字で、同社の説明ではルーター単体の効果ではなく、研修と統制の施策を併せた2026年4月の導入以降の減少幅とされています。対象タスクも規模も組織ごとに違います。研究側でも品質を落とさずコストを1/2以下に抑えた例が報告されていますが、これも特定条件下の結果です。削減幅は自社の利用実績で確かめるほかありません。

Q. 日本語中心のワークロードでも使えますか？

明記があるのは Bedrock だけです。Amazon Bedrock の intelligent prompt routing は英語プロンプト向けにのみ最適化されていると公式ドキュメントに明記されています。残る3方式は、日本語での選択精度に関する公開データが確認できませんでした。Microsoft Foundry の model router は Japan East / Japan West を含むリージョンで Global Standard と Data Zone Standard に対応していますが、これはデータの所在とデプロイ種別の話で、日本語での選択精度の根拠にはなりません。

Q. プロンプトキャッシュやバッチ処理とは、どちらを先に入れるべきですか？

多くの場合はキャッシュとバッチが先です。Claude の場合、毎回同じ前提や仕様書を送り直しているならキャッシュヒット分は基本入力単価の0.1倍まで落ちます（書き込み側は5分キャッシュで1.25倍かかるので、少なくとも1回は読み出す前提の処理向き）。即時性が要らない一括処理は Batch API で入力・出力とも50%の割引を受けられます。この2つで足りる範囲を先に潰しておくと、ルーティングを適用する範囲そのものを狭くできます。キャッシュはモデルごとに張られるため、順序を逆にすると、振り分けでヒット率を落としてから潰すことになります。

Q. ルーター経由にすると扱えるコンテキスト長は変わりますか？

方式によっては短くなります。Microsoft 公式ドキュメントによれば、model router の実効コンテキスト長は振り分け先のうち最も小さいモデルの上限に制限されます。長い文書を投げる用途では、単体のモデルを直接呼んでいたときには通っていた入力が通らなくなる場合があるため、導入前に最大入力長の確認が要ります。

参考資料

• AWS 公式: Amazon Bedrock intelligent prompt routing
• Microsoft 公式: Model router for Microsoft Foundry
• OpenRouter 公式: Model Routing（Auto Router）
• LiteLLM 公式: Router – Load Balancing / Fallbacks
• LiteLLM: router_strategy/lowest_cost.py（コスト判定の実装。commit 2708620d 時点）
• LiteLLM Issue #35787: Lowest-cost routing does not resolve provider-prefixed model pricing
• LiteLLM 公式: Custom LLM Pricing（0 を明示すると予算チェックをスキップする仕様）
• Anthropic 公式: Claude API Pricing
• Anthropic 公式: Admin API – Messages Usage Report
• OpenAI 公式: API Pricing
• RouteLLM: Learning to Route LLMs with Preference Data (arXiv:2406.18665)
• EY 公式: AI Pulse survey – C-suites pivot from AI adoption to unlocking value
• AWS 公式: Amazon Bedrock pricing（ルーティングの課金）
• EY says its ‘invisible’ AI router has helped cut token consumption by up to 60%（60%発言の出典）
• The Next Web: EY built an ‘AI router’ to stop its own AI bills from spiralling

判断そのものを生成モデルから切り離す経路もある。型付きの判断だけを返すモデルの料金と制約はJevとは｜文章を書かない判断モデルの仕組み・料金と、日本語で使う前に見る制約にまとめた。