OpenRouterのプロバイダールーティングを解説：2026年10月アップデート

OpenRouterは2026年10月28日、デフォルトのプロバイダールーティングを刷新しました。初回トークンまでの時間は16.9%短縮され、429の発生イベントは全体で67%減少。その一方で、リクエスト単価は約6%上がっています。自動ルーティングでは、気づかないうちに高価なプロバイダーへ切り替わることもあるため、見出しの数字だけでなく、このトレードオフまで見ておきたいところです。

OpenRouterの新しいルーターは、入力トークンの最安値だけを見て接続先を決めるわけではありません。価格、待ち時間、リトライまで含めて「良い回答を得るまでにかかるコスト」を見積もり、Routing Costが最も低いプロバイダーへリクエストを送ります。

結論を30秒で。根拠となる数字も確認

OpenRouterのプロバイダールーティングは、プロンプトトークンの価格ではなくRouting Costを最適化する仕組みになりました。リクエストでprovider.sort、provider.order、provider.only、provider.ignoreを明示していない場合、自動的に適用されます。OpenRouterの発表によると、複数のプロバイダーが提供するモデルへ送られる、全トラフィックのおよそ77%が対象です。

結果は、2,400万件のリクエストと1,030億個の入力トークンを対象に、旧ルーターと新ルーターへ均等に振り分けて1週間実施したswitchbackテストによるものです。

\*リクエストの割合とイベント数の減少率は、いずれも発表に記載された数値です。67%減と47%減は、それぞれ429イベント全体とリトライ全体を指します。1つのリクエストで複数回エラーが発生する可能性があるため、発生率同士の単純な比率ではありません。

発表によると、呼び出し側で測定したTTFT p95は6,032 msから4,504 msへ、リクエスト全体のp50は4.00秒から3.24秒へ短縮されました。失敗した試行に費やされた時間も、1リクエストあたり349 msから242 msへ減っています。

結論としては、対話型チャットやエージェントなら、コストが約6%上がっても許容できる場合は新しいデフォルトを使うのがおすすめです。一方、1セント単位の差が重要な大規模バッチ処理では、価格だけを基準にする設定へ戻すのがよいでしょう。

Routing Costをひとことで説明すると

Routing Costは、プロバイダーごとに「1回の試行はいくらかかるか」「その試行はどれくらいの確率で成功するか」を見ています。OpenRouterの例では、試行そのものに$0.40、待ち時間に$0.60かかるので合計は$1.00。これを成功確率80%で割ると、良い回答1件あたりのコストは$1.25になります。この値が低いプロバイダーほど多くのトラフィックを受けます。

この数値を決める主な要素は3つです。

1. 表示価格ではなく実効価格。OpenRouterは直近のトラフィックから入力・出力トークン数を推定し、プロバイダーごとの実際のキャッシュヒット率とトークン価格を適用します。発表の計算例では、キャッシュされていない入力40Kトークンが$2.00/Mで$0.080、キャッシュ済み入力60Kトークンが$0.50/Mで$0.030、出力約4Kトークンが$8.00/Mで$0.032。合計は$0.142です。入力価格が安くても、キャッシュ済みトークンや出力トークンが高いプロバイダーは、ここで優位性を失います。
2. 待ち時間を金額に換算。スループットは、初回トークンまでの時間も含めた、リクエスト全体の出力トークン毎秒です。たとえば初回トークンまで5秒、その後5秒で500トークンを生成した場合は50 tok/sとなります。ルーターは、一般的なプロバイダーの料金と速度をもとにモデルごとのレートを設定し、待ち時間をコストへ変換します。エージェントのツール呼び出しでは各ステップで初回トークンを待つため、TTFTにはより大きな重みが付けられます。
3. 失敗にかかるコスト。429はプロバイダーにリクエストを拒否された状態です。拒否を待ったあと、別の接続先へ送り直す必要があります。例として、待ち時間が2.50、エラー率が0.4%でペナルティを掛けると、コストに0.01が加わります。信頼性に関わるエラーには約8倍重いペナルティが設定され、エラー率1%でコストは約8%上昇します。ほかのプロバイダーより大幅に悪いプロバイダーは、復旧するまでトラフィックを止められます。品質面では現在、形式が正しいツール呼び出しを確認しており、正しい形式が95%ならコストに約5%が加算されます。問題が検出されたプロバイダーは、発表によるとテスト用トラフィックまで絞られます。

特定の1社にトラフィックが集中しすぎないよう、発表によると2つの安全策もあります。すべてのプロバイダーには少量のトラフィックを流し続け、復旧を検知できるようにすること。そして、障害中のプロバイダーへの送信を抑えながら、プロバイダーごとの処理能力の上限を学習し、あふれた分を別の接続先へ回すことです。

デフォルトルーティングが本番アプリで問題になる理由

ユーザーからの報告を見ると、トークン単価だけでは捉えきれない問題が4つあります。

ツール呼び出しの途中でスキーマが崩れる

私の場合、ツール呼び出しを実際に壊したのは、どのプロバイダーがいくらかという価格ではなく、リクエストの途中で接続先が切り替わったことでした。

— u/Michael_Jeffords、避けているプロバイダーについてのr/openrouterスレッド

現在の品質スコアは、主に形式が正しいツール呼び出しとベンチマーク精度のフラグを使っています。これは発表にも記載されています。会話の途中で接続先が変わると、量子化方式や拒否の挙動まで変わる可能性があります。プロバイダーによって品質は異なり、より強く量子化したモデルを提供するところもあるためです。

キャッシュが外れて請求額が膨らむ

あるスレッドでは、約700Kトークンのコンテキストで、本来$0.20程度のキャッシュ済みリクエストが、プロバイダー変更後には約$2.00請求された事例が報告されています。「キャッシュが壊れて10〜32倍多く支払う」問題の典型です。新しいルーターは、キャッシュが有効な間は会話を最初のプロバイダーに固定し、アルゴリズムで接続先を選ぶのも最初のリクエストだけにします。これはOpenRouterのキャッシュ対応ルーティングによるものです。ただし、別のプロバイダーへフォールバックすると、この固定は解除されます。問題を解消したユーザーは、スティッキーセッションを使ってプロバイダーを1社に固定していました。

これを事前に手動設定しないといけないのは、ORのかなり根本的な欠陥だと思います。

— u/welcome_to_milliways、キャッシュ破損についてのr/openrouterスレッド

高価な接続先へのフォールバックに気づけない

ある本番環境の報告では、トラフィックの一部がSonnetからOpusへ、表示価格で約5倍高い接続先へ気づかないうちに移動しました。稼働率は正常なままなのに、全体の消費額は1時間あたり$184から$412へ増えています。詳しくは@CarbonOnXの報告を参照してください。新しいルーターでは、このトレードオフが明確になります。最安のプロバイダーよりも、高速で信頼性の高いプロバイダーが優先されることは十分にあり得ます。

有料アカウントでも429が発生する

429についてのスレッドでユーザーが指摘しているように、OpenRouterの残高を追加しても、上流プロバイダー側の処理能力が増えるわけではありません。429は、そのモデルに割り当てられたプロバイダーの共有プールが上限に達したことを示します。今回のテストでは429イベントが67%減りましたが、本番での対策としては、レート制限にかかったプロバイダーを固定対象から外すか、明示的に無視する必要があります。まずはOpenRouterの429エラーを解決する方法を、旧来の価格重視デフォルトについてはOpenRouter Auto Routerガイドを参照してください。

実用に耐える3つのルーティング設定

どの設定を選ぶかは、手間をかけずに速度を得たいのか、厳格なコスト上限を設けたいのか、挙動を決定的にしたいのかで変わります。いずれも同じproviderオブジェクトを使います。provider.orderは新しいロジックを迂回し、指定した順番でプロバイダーを試します。provider.onlyとprovider.ignoreは候補を絞り込んだあと、残った候補から新しいアルゴリズムで選びます。明示的なprovider.sort（price、throughput、latency）を指定すると、新しいデフォルトの選択方法が置き換わります。

1. 新しいデフォルトを使い続ける（対話型チャットとエージェント）

コードの変更は必要ありません。ユーザー向けチャットや、各ツール呼び出しで初回トークンを待つマルチステップのエージェントに向いています。レイテンシとリトライを減らせる分、コストが約6%高くなることを受け入れる設定です。APIレスポンスとアクティビティページに返される実際のプロバイダーを、TTFT p50や429率と一緒に1週間記録しましょう。429の割合が新しい約4%の基準値に近く、キャッシュヒット率も維持できているなら、そのままで構いません。特定のプロバイダーで失敗が集中する、またはキャッシュヒット率が大きく落ちるなら、3つ目の設定へ移行します。

2. 最安の経路に固定する（バッチ処理とコスト上限がある処理）

速度よりもコストを優先したい場合、価格ベースのルーティングを使う方法は3つあります。

{ "provider": { "sort": "price" } }

またはモデルスラッグに:floorを付けます（meta-llama/llama-4-maverick:floor）。アカウント設定でデフォルトのsortをpriceにする方法もあります。詳しくは発表のFAQを参照してください。なお、:floorは、単独のsortでは対象にならないflex-tierエンドポイントも許可します。これはOpenRouterのルーティングガイドに記載されています。

上限も組み合わせると安心です。

{ "provider": { "sort": "price", "max_price": { "prompt": 1.0, "completion": 2.0 } } }

大きなプロンプト、短い出力、安価なリトライを前提とする処理に向いています。

3. 安定したプロバイダーを固定する（キャッシュやツール呼び出しを使う本番環境）

リクエストごとの最適化よりも、正確性、キャッシュヒット、コンプライアンスを優先したい場合は固定します。

{
  "provider": {
    "order": ["deepinfra", "together"],
    "allow_fallbacks": true,
    "require_parameters": true
  }
}

require_parametersで避けられるのは、必要なリクエストパラメーターに対応していないエンドポイントだけです。プロバイダー間でツール呼び出しやスキーマの挙動が同一になることまでは保証しません。allow_fallbacks: falseとしたorderは、コンプライアンスやBYOKなど、未承認のプロバイダーへ切り替わるくらいなら停止したほうがよいケースに限って使うべきです。多くのアプリではフォールバックを許可し、only/ignoreで候補を絞り、安定したsession_idを渡してウォームキャッシュを再利用します（スティッキールーティング）。特定のプロバイダーが不安定なら、ガードレールでブロックし、直接プロバイダーのAPIを使った場合とも比較してください。モデルを決めたあと、直接接続に切り替えたことで遅延やキャッシュ問題が解消したというユーザーも複数います（報告例）。

自動ルーティングは以前より良くなりました。ただし、わずかに高いトークン単価が1週間続くよりも、1回の悪い接続切り替えのほうが高くつくなら、プロバイダーの固定は依然として有効です。

FAQ

新しいルーティングを使うためにコードを変更する必要はありますか？

ありません。providerのsort、order、only、ignoreを明示していないリクエストには、新しいルーターが自動的に適用されます。

価格だけでルーティングするにはどうすればよいですか？

provider.sortを"price"に設定するか、:floorを付けるか、アカウントのデフォルトsortをpriceに設定してください。

新しいルーティングによってproviderのorderは上書きされますか？

されません。orderは新しいルーティングを迂回します。only/ignoreでは先に候補を絞り、そのあと新しいアルゴリズムが選択します。

新しいルーティングでコストは上がりますか？

結論の表のとおり、テストでは1,000リクエストあたり6.0%、100万トークンあたり7.3%上がりました。

実際にどのプロバイダーがリクエストを処理したか確認できますか？

OpenRouterのドキュメントによると、APIレスポンスのproviderフィールドとアクティビティページで確認できます。

有料アカウントなのに429が出るのはなぜですか？

原因は残高ではなく、上流プロバイダーの共有プールにある制限です。レート制限にかかったプロバイダーを固定するか、候補から除外してください。