OpenRouter BYOKの料金・フォールバック・キー ローテーション（2026年）

OpenAIのキーが有効で、リクエストも成功している。それでもOpenRouterの残高が減ることはあります。BYOKは単一の課金スイッチではなく、プロバイダー利用料、プラットフォーム手数料、フォールバック時の処理枠がそれぞれ別に動く仕組みです。しかも現在のルールは、以前の「月100万リクエスト」という基準から変わっています。

まず、何の請求なのかを切り分ける

OpenRouter BYOKでは、ワークスペースに保存したプロバイダーの認証情報を使いつつ、APIとルーティングの窓口はOpenRouterのまま利用します。そのため、費用は大きく3つの経路に分かれます。

最初に問うべきなのは「キーを登録したか」ではなく、「実際にこのリクエストを処理したのはどのプロバイダーか」です。キーを設定していても、レート制限、上流アカウントの残高不足、権限不足、一時的なプロバイダー障害で失敗することがあります。フォールバックが有効なら、OpenRouterは別のプロバイダー経由でリクエストを完了させ、その経路をOpenRouter残高へ請求する場合があります。詳細はBYOK課金に関するサポート説明のとおりです。

BYOKで変わること、変わらないこと

BYOKでは、対象トラフィックがプロバイダーの認証情報を通じてルーティングされますが、APIとルーティング層はOpenRouterが担います。BYOKドキュメントによれば、認証情報は暗号化され、指定プロバイダーへルーティングされるリクエストにのみ使用されます。

ただし、BYOKにしても推論が無料になるわけではありません。モデル利用分はプロバイダーが請求し、該当する無料枠を超えればOpenRouterが別途プラットフォーム手数料を請求することがあります。また、自前キーを渡しても、ワークスペース、アカウント、リクエスト単位のプライバシールールを回避できるわけではありません。利用可能なエンドポイントが残っていなければ、認証情報が有効でもリクエストは失敗します。

現在のBYOK手数料はリクエスト数ではなく推論額で決まる

現在のOpenRouter pricingでは、BYOKの手数料無料枠はリクエスト数ではなく、定価ベースの推論額で定められています。

この枠は、同じモデルとプロバイダーをOpenRouter上で通常利用した場合の価格を基準に測定されます。プロバイダーと個別契約した請求額とは限りません。無料枠を超えると、5%のBYOK手数料がOpenRouterクレジットから差し引かれます。プロバイダー側の請求はこれとは別です。

3種類のコストを別々に管理する

1. プロバイダー推論コスト：BYOK認証情報に紐づくアカウントへ、プロバイダーが請求します。
2. BYOKプラットフォーム手数料：現行プランの無料枠を超えた後、OpenRouterが5%をOpenRouterクレジットから請求します。
3. フォールバック時の推論コスト：想定していたBYOK経路ではなく、OpenRouter負担のプロバイダー処理枠を使った場合にOpenRouterクレジットで支払います。

クレジット購入手数料はさらに別です。OpenRouter pricingには、Pay-as-you-goのプラットフォーム手数料として5.5%が記載されています。チャージ時の請求があっても、特定のリクエストでフォールバックが起きた証拠にはなりません。

検索に古い「100万リクエスト」情報が残る理由

OpenRouterは2025年10月の発表で、月100万件のBYOKリクエストまではプラットフォーム手数料なし、その後は5%と案内していました。これは日付入りの告知にある過去のポリシーであり、現在はBYOK料金が2026年8月に変更された旨がページに記されています。見積もりには現行料金ページの定価ベース推論枠を使い、確認日も記録しておくべきです。

BYOKを厳格な境界にするかはフォールバック設定で決まる

OpenRouterの標準的なルーティング目標は、リクエストを成功させることです。BYOKガイドでは、優先キー、共有OpenRouterエンドポイント、フォールバックキーがルーティング内でそれぞれ異なる位置づけとして説明されています。

• 優先BYOKキーは、設定された順序で試行されます。
• それらが失敗すると、OpenRouterの共有処理枠が試行される場合があります。
• フォールバックとして設定したBYOKキーは、共有エンドポイントの後に試行されます。
• 同一プロバイダーに一致するキーが複数あれば、順に試行されます。

プロバイダーの順序にはもう1つ注意点があります。一致するBYOKエンドポイントは、リクエストしたorder配列でそのプロバイダーが後ろに置かれていても、共有エンドポイントより先に試されます。つまり、一般的なプロバイダー順序のルールから想像するより早い段階でBYOKキーが使われることがあります。

可用性を取るか、請求の確実性を取るか

ダッシュボードのAlways use for this providerは、同じプロバイダーに対してOpenRouterの共有認証情報を使わないようにします。ただし、これは「OpenRouterクレジットを一切使わない」という全体設定ではありません。OpenRouterのサポート記事によれば、プロバイダー間フォールバックが可能なままであれば、AnthropicのBYOKキーからGoogle Vertexのような別の互換プロバイダーへ移る可能性は残ります。

請求先を確実に限定したいなら、リクエスト自体を制約します。

{
  "model": "anthropic/claude-sonnet-4.5",
  "messages": [
    { "role": "user", "content": "Summarize this document." }
  ],
  "provider": {
    "only": ["anthropic"]
  }
}

provider.onlyを指定すると、Anthropic側の失敗は別プロバイダーへの暗黙的な切り替えではなく、APIエラーになります。規制対象のワークロード、プロバイダー固有のデータ契約、すべてのリクエストを特定の上流アカウントへ対応付ける必要があるコストレポートには、こちらが適しています。一方、厳格なプロバイダー帰属より可用性を重視する対話型プロダクトでは、標準設定としては向きません。

r/openrouterのユーザーも、同じ制御方法に触れています。

「リクエスト自体でproviderのorder/onlyを指定すれば、自分のBYOKだけを強制的に使わせられる。」 — u/Randomdotmath、Reddit thread

信頼性設計にフォールバックを組み込むなら、その分の予算も確保しましょう。不要なら、リクエスト境界で無効化します。

手数料を疑う前にActivityで経路を確認する

OpenRouterのFAQによると、Activityでは利用履歴を確認でき、モデル、プロバイダー、APIキーで絞り込めます。確認すべき項目は次のとおりです。

1. 実際の提供プロバイダー：BYOK認証情報に紐づけたプロバイダーと一致しているか。
2. モデルとエンドポイント：ルーターが別の互換エンドポイントを選んでいないか。
3. アプリケーションAPIキー：どの環境またはワークスペースキーがリクエストを送ったか。
4. クレジットの差し引き：推論利用額、BYOK手数料、チャージに伴う残高変動のどれか。

Activity上のプロバイダーがBYOKプロバイダーと異なるなら、認証情報を変更する前にフォールバックを調べてください。一致していて、利用量がプランの無料枠に近いなら、BYOKプラットフォーム手数料を疑います。有効なキーをローテーションして、実際にはルーティングポリシーの問題だったという事態を避けられます。

ローテーションに耐える本番用キー構成

OpenRouterのアプリケーションキーと、上流プロバイダーのBYOK認証情報は、所有者も用途も異なる別のシークレットとして扱います。

BYOK認証情報を設定・テストする手順

本番トラフィックの調査に入る前に、まずこの手順で確認します。

1. ワークスペースのBYOK設定でプロバイダー認証情報を追加するか、BYOK management APIで作成します。
2. プロバイダー、環境、用途が分かる名前を付けます。
3. ワークスペース認証情報を共有する前に、モデル、OpenRouter APIキー、メンバーのフィルターを設定します。
4. キーは優先セクションに置き、課金上・障害時の役割が明確な場合に限ってフォールバックキーを追加します。
5. テストリクエストを送り、Activityで実際の提供プロバイダーを確認してから、共有フォールバックを有効のままにするか決めます。

クラウドプロバイダーでは、認証情報を単純に置き換えることはできません。

これらの制約は、OpenRouterのプロバイダー別BYOKドキュメントに基づくものです。有効なシークレットでも、リソース種別、リージョン、デプロイメント、権限が誤っていれば設定エラーです。BYOKが未対応である証拠ではありません。

OpenRouterのBYOK設定では、モデルスラッグ、OpenRouter APIキーハッシュ、ワークスペースメンバーでフィルターを設定できます。認証情報が利用対象になるには、有効なフィルターをすべて満たす必要があり、ドキュメントでは各フィルターにつき最大100件まで設定可能です。明示的な許可リストを使いましょう。拡大し続ける1つの広範な認証情報を維持するより、大規模チームはワークスペースで分離するほうが適切です。

プロバイダーキーを変えずにOpenRouterアプリケーションキーをローテーションする

OpenRouterのAPI key rotation cookbookでは、BYOKプロバイダー認証情報は特定のアプリケーションキーではなくOpenRouterアカウントに関連付くものと説明されています。無停止での切り替え手順は次のとおりです。

1. 分かりやすい名前と適切な上限を持つ、新しいOpenRouter application keyを作成します。
2. シークレットマネージャーに保存し、古いキーを使うすべてのサービス、ジョブ、環境へデプロイします。
3. Activityで本番トラフィックが新しいキーを使用していることを確認します。
4. 移行完了後にのみ、古いキーを削除します。

Management APIのドキュメントでは、Management API keyは管理用認証情報であり、completionエンドポイントは呼び出せないとされています。古いアプリケーションキーを無効にする前に、代替キーを利用可能な状態にしておく必要があります。

プロバイダー認証情報は別途ローテーションする

プロバイダーキーのローテーションは別の変更です。各プロバイダーの認証情報ポリシーに従い、ワークロードが実際に使うモデル、リージョン、権限、クォータをテストしてください。

1. 必要最小限の権限で、上流側に代替認証情報を作成します。
2. 別名を付け、優先順位を管理したうえでOpenRouter BYOK接続へ追加します。
3. テストリクエストを送り、Activityを確認します。
4. 代替認証情報をプライマリ位置へ移し、エラーとプロバイダー利用状況を監視します。
5. 重複運用期間の後、上流側で古い認証情報を失効させます。

この手順は、OpenRouterで文書化されている優先順位の挙動をもとにした運用上の推奨です。失効に関する最終的なルールは各プロバイダーのポリシーに従います。OpenRouterのBYOK create APIは生の認証情報を受け取りますが、保存時に暗号化され、後続のAPIレスポンスでは返されないとされています。OpenRouterは復旧用コピーではないため、元の認証情報は自分たちのシークレットマネージャーで保管してください。

OpenRouter BYOKを標準にすべきでないケース

単一プロバイダーのネイティブログ、エンドポイント固有の厳密な挙動、ベンダー独自ツールが、統合ルーティングより重要なら、プロバイダーAPIを直接使うほうが適しています。一方、複数のプロバイダーアカウントを使う場合、既存のプロバイダークレジットやコミット済みキャパシティを活用したい場合、ワークスペース単位の制御が必要な場合には、BYOKが向いています。

OpenRouter BYOK FAQ

自分のキーを使っていてもOpenRouterから請求されますか？

はい。プロバイダーはBYOK認証情報経由の推論を請求できます。OpenRouterは、現在のプランの無料枠を超えた分について5%のBYOKプラットフォーム手数料をクレジットから差し引く場合があります。また、フォールバックにより、別プロバイダー経路の費用をOpenRouterクレジットで支払うこともあります。

「Always use for this provider」でフォールバックはすべて止まりますか？

いいえ。指定したプロバイダーに対してOpenRouter自身の共有認証情報を使わなくなるだけで、別の互換プロバイダーへの移行は止まりません。プロバイダー間の経路を完全に排除する必要がある場合は、provider.onlyを使います。

企業はBYOKの安全性と予算をどう管理すべきですか？

OpenRouterによれば、認証情報は暗号化され、生のプロバイダーキーはmanagement API経由で返されません。また、BYOK利用額はデフォルトでガードレールおよびワークスペース予算の対象外です。BYOKドキュメントでは、合算予算が必要な場合はInclude BYOK spendまたはinclude_byok_in_budgetsを有効にするよう案内しています。エンタープライズでは、最小権限の認証情報、ワークスペース分離、フィルター、シークレットマネージャーでの保管、ローテーション、Activityレビューも行うべきです。

許容できない失敗に合わせて標準構成を決める

リクエスト完了、プロバイダー帰属、コスト可視性のうち、どれを妥協できない要件とするかに合わせて、ルーティングと予算の制御を選んでください。