OpenRouter、データ所在地を米国またはEUに保証する「In-Region Routing」機能を追加

本日、先月 10 月に提供を開始した EU ルーティングに続き、「US In-Region Routing（米国国内ルーティング）」を正式にリリースします。これにより、AI ワークロードの処理場所について、確実なコントロールが可能になります。

us.openrouter.ai 宛てのリクエストは米国内で復号化され、米国のプロバイダーエンドポイントのみへルーティングされます。これにより、リクエストのライフサイクル全体を通じて、プロンプトと生成結果が米国国内に留まります。同様に、eu.openrouter.ai は EU 内での処理を保証します。

企業は、データの所在地（データレジデンシー）や処理に関するより強力な保証を求めています。OpenRouter の In-Region Routing は、米国または EU への設定を容易にするソリューションです。

仕組み

openrouter.ai ではなく、地域固有のベース URL を通じて API リクエストを送信してください：

https://us.openrouter.ai/api/v1
https://eu.openrouter.ai/api/v1

API キー、リクエスト本文、モデル ID は変更されません。また、プロバイダーの優先順位、フォールバック設定、プライバシー設定も既存のアカウントからそのまま引き継がれます。

us.openrouter.ai を指すサービスと、残りのトラフィックを openrouter.ai で処理するサービスを併用することも可能です。

us.openrouter.ai または eu.openrouter.ai に送信されたリクエストは、それぞれのリージョン内で復号化・処理され、その地域で稼働しているプロバイダーのみが対応します。もし該当するリージョン内にモデルを提供できるプロバイダーが存在しない場合、外部にルーティングされることはなく、404 エラー（「データ領域に対応するエンドポイントが見つかりません」）としてリクエストは失敗します。 （原文の技術表記: No endpoints found supporting your data region.）

リージョンエンドポイントは、同じモデル ID の下にグローバルカタログの一部を処理します。少なくとも 1 つのプロバイダーがそのリージョン内でモデルを提供できる場合、そのモデルは該当リージョンにリストされます。

ライブ一覧を確認するには、リージョン固有のドメインを通じて `/api/v1/models` を呼び出すか、In-Region Routing（US または EU）でモデルページをフィルタリングしてください。今後、両リージョンにさらに多くのモデルとプロバイダーを追加していく予定です。

Discord の #feedback で、次に追加してほしいリージョン内モデルをご提案ください。

また、Guardrails を使用して、特定のワークスペース、チーム、または API キーに対して In-Region Routing を強制することも可能です。ガードレールの「許可されるデータリージョン」を 1 つのリージョンに設定すると、OpenRouter は別のホスト名から届いた該当するリクエストをすべて拒否します。

設定画面の Guardrails セクション、または Management API を通じて設定できます。

In-Region Routing は、Business プランと Enterprise プランで利用可能です。

US/EU モデル（リージョン内で提供）

インリージョンルーティングを採用しない場合、米国や欧州に拠点を置く研究所が提供するモデルを利用しても、そのリクエストを処理するデータセンターが必ずしも同地域にあるとは限りません。グローバルエンドポイントでは、OpenAI、Anthropic、Google、xAI、Meta、NVIDIA、Thinking Machines、Mistral などのプロバイダーが提供しているモデルは、リクエストを処理する事業者の所在地に関係なくどこでも実行可能です。

データレジデンシー（データ所在）レビューでは、「リクエストが復号化された場所」や「推論が実行された場所」を確認します。そのため、米国チームがグローバルエンドポイントで GPT-5.6、Claude Opus 5、Gemini 3.6 Flash を利用していても、コンプライアンス審査に合格できないケースがあります。OpenRouter のインリージョンルーティング機能は、リクエストを指定した地域（米国または EU）内に留めることを保証します。

地域限定で利用可能な中国製オープンウェイトモデル

オープンウェイトモデルの性能は急速に進化しており、これらへのトラフィックシフトによりコストを大幅に削減できます。OpenRouter では、米国および欧州から発せられるリクエストにおいて、オープンウェイトモデルへ割り当てられるトークンの割合が着実に増加しています。

NVIDIA の Nemotron 3 Ultra や Thinking Machines の Inkling など、米国発のモデルが成長を牽引しています。しかし、依然として利用されているのは中国発のモデルが大半であり、それらの導入承認にはハードルがあるのが実情です。

「インリージョン・ルーティング」は、データの所在地要件を満たすチームにとって、中国発のオープンウェイトモデルから価格と性能のメリットを引き出す手段となります。米国または欧州のプロバイダーがホストするモデルの場合、リクエストはそのプロバイダーに直接送られ、開発元のラボは関与しません。DeepSeek V4 Pro、Kimi K3、そして GLM 5.2 は、Baseten、Fireworks、Azure が米国データセンターから提供しているため、米国向けインリージョン・ルーティングの対象です。us.openrouter.ai を通じてこれらにプロンプトを送信すれば、データは米国内で復号化され、実行されます。また、GLM 5.2 は Mistral の欧州データセンターから提供される eu.openrouter.ai でも利用可能です。

エンドツーエンドの地域別ルーティングの保証

ゲートウェイが地域別ルーティングを提供する場合、それは以下のいずれかの意味を持ちます。決定的な違いは、プロンプトが平文のままその地域外に存在するかどうかです。

推論専用の地域別ルーティングでは、ゲートウェイがプロバイダーの推論処理をあなたの指定した地域に固定します。しかし、リクエスト自体はゲートウェイが動作する場所で復号化・処理された後、プロバイダーへ転送されます。この経路の一部において、あなたのプロンプトデータは平文のまま地域の外側に存在することになります。

また、サーバーツールの地域別対応は見落とされがちですが、これによりプロンプトデータが管轄区域から漏洩するリスクがあります。例えば、ウェブ検索機能などは、推論エンドポイントが地域限定であっても、グローバルなインスタンスを使用することがあります。

一方、エンドツーエンドの地域別ルーティングは、OpenRouter の「In-Region Routing」が採用している方式です。この仕組みでは、データが経路全体を通じて常に指定された地域内に留まります。us.openrouter.ai または eu.openrouter.ai へのリクエストは、その地域内で復号化され、すべての処理ステップでその地域内で実行されます。実際に受け取るのは、その地域で稼働しているプロバイダーのみです。

もしその地域にモデルを提供できるプロバイダーが存在しない場合、リクエストは失敗し、404 エラー（No endpoints found supporting your data region.）が返されます。データが地域の外へ漏れることは決してありません。特定の管轄区域でツールを提供する前に、OpenRouter はサーバーツールとその動作環境のデータ所在地を包括的に評価します。地域外へのデータ転送を引き起こす可能性のあるツールは、グローバルインフラストラクチャにフォールバックさせるのではなく、完全に無効化されます。

いずれのゲートウェイがデータ所在地を保証しているかを評価する際は、以下の 2 つの質問を必ず行ってください。

1. リクエストはどこで復号化・処理されるのか？
2. そのツールはどこで動作するのか？

はじめるには

In-Region Routing（地域内ルーティング）は、Business プランおよび Enterprise プランで利用可能です。プラン設定 から Business プランへアップグレードするか、エンタープライズチーム にお問い合わせください。

その後、米国 または EU のモデルリストから対象のモデルを選択し、リクエストを https://us.openrouter.ai/api/v1 または https://eu.openrouter.ai/api/v1 へ送信してください。

詳細については、ドキュメント をご覧ください。