OpenRouterの米国内リージョナルルーティング：設定方法と制限

OpenRouterのUS in-region routingは、単に米国のプロバイダーを優先する機能ではない。データが米国内で復号・処理されるようにする、実質的なデータレジデンシー対策だ。ただし、利用できるのはBusinessとEnterpriseプランに限られる。また、米国内で処理できるエンドポイントが見つからない場合、リクエストは米国外へフォールバックせず失敗する。

30秒でわかる結論

米国内でプロンプトを処理しながら、複数のモデルプロバイダーを使い分けたい組織にとって、OpenRouter US in-region routingは有力な選択肢になる。一方、一般的な公開データを扱うだけなら必須ではない。ゼロデータ保持の設定を置き換えるものでもなく、プロバイダーの利用規約確認も別途必要だ。

OpenRouterは2026年9月9日、既存のEUエンドポイントに加えて米国向けルーティングを発表した。公式発表によると、米国ホスト名に送ったリクエストは、処理のライフサイクル全体を通じて米国内で復号・処理される。

機密性の高いサービスにはUSルーティングを使い、リスクの低いトラフィックはグローバルのままにする、といった段階的な移行も可能だ。

リージョナルエンドポイントが実際に制御する範囲

リージョナルホスト名によって制御されるのは、OpenRouterがリクエストを復号・処理する場所と、リクエストを処理できるプロバイダーのエンドポイントだ。OpenRouterはサーバーツールについても管轄区域を判定しており、選択したリージョンの外部へデータを送るツールは、グローバル基盤へ黙って切り替えるのではなく無効化される。

モデルの開発元がどの国の企業かだけでは、ゲートウェイがデータをどこで復号し、推論をどこで実行するかは判断できない。

OpenRouterが示している処理経路は次のとおりだ。

1. リクエストがus.openrouter.aiに到達する。
2. TLSの終端、復号、ゲートウェイ処理、対象となるサーバーツールの処理が米国内で行われる。
3. ルーティング対象は、米国内で稼働するプロバイダーのエンドポイントに限られる。
4. 対象プロバイダーが米国内で推論を実行する。
5. 利用可能な経路がない場合、OpenRouterは404 No endpoints found supporting your data region.を返す。

このフェイルクローズ設計は重要だ。グローバルへのフォールバックなら可用性は上がるが、厳格なデータレジデンシーポリシーは破綻する。リージョナルリクエストでは、OpenRouterは処理の完遂よりもデータの所在を優先している。

「プロバイダーの国籍より重要なのは、実際のデータ経路、ログの扱い、サブプロセッサー、ホスティング地域、そしてゼロデータ保持を強制できるかどうかだ」— r/openrouterのu/MembershipEmergency7

この懸念は、調達時に見るべきポイントをよく表している。リージョナルルーティングが答えるのは、OpenRouterが示す処理場所の問題だ。契約、保持期間、サブプロセッサー、監査用エクスポート、インシデント対応手順については、別途確認しなければならない。

米国経由のリクエストを設定する

OpenRouter US in-region routingの設定では、通常、リクエストを書き換えるのではなくAPIのベースURLを変更する。同じAPIキー、リクエストボディ、モデルID、プロバイダー設定、フォールバック、プライバシー設定をそのまま引き継げる。

1. プランの利用条件を確認する

OpenRouterは、in-region routingの対象をBusinessとEnterpriseの顧客としている。公開されている料金ページでは、従量課金利用に5.5%のプラットフォーム手数料が示されているが、USルーティング向けのセルフサービス型の追加料金は掲載されていない。予算を組む前に、Businessの料金または契約料金を確認しておこう。

2. 米国で利用できるモデルを調べる

リージョナルホスト名経由でモデル一覧のエンドポイントを呼び出す。返されるカタログには、少なくとも1つの対象米国プロバイダーのエンドポイントがあるモデルが含まれる。

curl https://us.openrouter.ai/api/v1/models \
  -H "Authorization: Bearer $OPENROUTER_API_KEY"

プロバイダーやデプロイ状況が変われば、リージョナルカタログも変わる。モデルの確認は、一度作ったスプレッドシートで済ませるのではなく、デプロイ時のチェックに組み込むべきだ。

3. USベースURLからリクエストを送る

curl https://us.openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "meta-llama/llama-3.3-70b-instruct",
    "messages": [
      {"role": "user", "content": "Summarize this internal policy."}
    ]
  }'

この例のモデルは、OpenRouterのsovereign AIドキュメントに掲載されているものだ。本番利用の前に、現在のUSカタログに存在することを確認してほしい。

4. Guardrailsでリージョンを強制する

アプリケーション側の設定は、運用中にずれることがある。OpenRouterのsovereign AIドキュメントによると、Guardrailsではワークスペース、チーム、メンバー、APIキー単位でallowed_data_regionsにusを設定できる。許可されていないホスト名へ送られたリクエストは、処理前にHTTP 403で拒否される。

規制対象のアプリケーションでは、ワークスペースのデフォルトに設定するのが安全な出発点だ。開発者全員がリージョナルホスト名を覚えておく必要がなくなるためである。機密性の高いサービスだけを、ワークスペースのデフォルトより厳しいAPIキー単位のルールにすることもできる。

5. 成功だけでなく失敗もテストする

対応モデルで成功するテストに加え、USカタログにないモデルを使ったテストも1件実行しよう。リージョナルな404を個別にアラート対象にしておけば、運用チームが障害対応のつもりでベースURLをグローバルエンドポイントへ変更してしまう事態を防げる。

混同されがちなプライバシー制御

US in-region routingが制御するのは地理的な処理場所だ。ZDR、データ収集フィルター、プロバイダーの規約は、それぞれ別のリスクを扱う。要件を満たす設計では4つすべてが必要になる場合もあり、どれか1つを有効にしたからといって、他の条件まで満たされるわけではない。

OpenRouterのプロバイダーのログに関するドキュメントは、重要な区別を示している。ユーザーは、学習やデータ収集のポリシーを基準にプロバイダーを絞り込める。しかし、保持要件が自動的にルーティングルールへ変換されるわけではない。プロバイダーの規約を評価する責任はチーム側に残る。

厳格なリクエストでは、リージョナルルーティングとプライバシーパラメーターを組み合わせられる。

{
  "provider": {
    "zdr": true,
    "data_collection": "deny"
  }
}

条件を追加するほど、対象となるプロバイダーの集合は狭くなる。その結果として404が返ったり、選べるモデルが減ったりしても、必ずしもルーティングの不具合とは限らない。ポリシーを適用した結果である可能性が高い。

導入前にワークロードを検証する

本番導入のレビューでは、「米国のプロバイダー」という説明だけで判断せず、実際の経路と失敗時の挙動を確認する必要がある。実務上の課題は監査可能性だ。OpenRouterは地理的な保証を説明しているものの、レイテンシー、保持条件、キャッシュの挙動、契約上の根拠まで含めた、モデルとプロバイダーの対応表を一元的に公開しているわけではない。

承認前には、次の順番で確認するとよい。

1. 本番と同じアカウント、プライバシー設定を使い、USモデルカタログを取得する。
2. 必要なモデルを選び、OpenRouterに表示される対象プロバイダーのエンドポイントを記録する。
3. ワークスペースまたはAPIキー単位でUS Guardrailsを適用する。
4. ワークロードで必要なら、ZDRを有効にし、データ収集を拒否する。
5. プロバイダーの現在の保持条件とサブプロセッサーを、調達部門を通じて確認する。
6. モデル、提供プロバイダー、リクエストID、ステータス、レイテンシー、ポリシー関連の失敗をログに残す。
7. 利用できないモデルでテストし、openrouter.ai経由で再試行するコードパスが存在しないことを確認する。
8. モデル、プロバイダー設定、プライバシールールを変更した際に、チェックを再実行する。

導入後も経路を観測すべき理由は、コミュニティの報告からもわかる。あるRedditの議論で、u/Cooperman411は「ZDR（Zero Data Retention）を有効にしているので、Deepseekをプロバイダーとして見つけられなかった」と述べている。これはベンチマークではなく一個人の体験談だが、プライバシー制御によって想定していた経路が使えなくなることを示す例ではある。

別のワークロードで報告されたキャッシュヒット率やレイテンシーを、そのまま自分の環境に当てはめてはいけない。プロバイダーの選択、プライバシーフィルター、プロンプトの形、モデルのデプロイ状況、トラフィック条件はいずれも結果を変えうる。本番に近いリクエストで実測することが重要だ。

US in-region routingを選ぶべきケース

OpenRouter US in-region routingは、米国内での処理境界をフェイルクローズで維持する必要があり、多少カタログが小さくなっても複数モデルへのアクセスを重視する組織に向いている。正式なデータレジデンシー要件がない個人開発者やチームなら、通常はグローバルエンドポイントのままでよい。リージョナル機能には上位プランが必要で、利用できる経路も減る可能性があるためだ。

選ぶ理由は速度ではなくデータレジデンシーに置くべきだ。OpenRouterは米国エンドポイントの一般的なレイテンシーベンチマークを公開しておらず、リージョナルなプロバイダープールも異なる可能性がある。

OpenRouter US in-region routing FAQ

ツールも米国内に保持されますか？

OpenRouterは、サーバーツールを管轄区域ごとに評価し、選択したリージョンの外部へデータを送るツールを無効化すると説明している。導入前に、ワークロードで必要な特定のツールが対象になるか確認してほしい。

保証はすべてのメタデータに及びますか？

発表資料が明示的に扱っているのは、プロンプト、完了結果、リクエスト処理、プロバイダールーティング、サーバーツールだ。請求記録、不正利用の監視データ、ログ、バックアップなど、組織のポリシーで確認が必要なその他のメタデータについては、OpenRouterに契約上の詳細を問い合わせるべきだ。

個人アカウントでUSエンドポイントを使えますか？

in-region routingはBusinessとEnterpriseプラン向けに案内されており、Freeや通常の従量課金プランは対象ではない。プランの利用資格がない開発者でも、プライバシー設定やプロバイダールーティングの制御は使えるが、それらはリージョナルな処理保証の代わりにはならない。

リージョナルカタログ、Guardrailsによるブロック、プライバシーフィルター適用後のプロバイダープール、プロバイダーの規約をすべて確認し、問題がない場合にだけ導入を承認しよう。チェックに失敗したら、モデルかワークロードの設計を変更すること。グローバルへのフォールバックは、データレジデンシーの境界を無効にしてしまう。