Claude Data Residencyの旧opt-out移行で何が変わったか
米国限定ルーティングをオプトアウトしていた組織は自動的にinference_geo設定へ移行済みです。コード変更は不要ですが、仕組みの変化点を確認します。
何もしなくてもよいが、仕組みは変わった
米国限定ルーティングへのオプトアウトを組織単位で以前から設定していた場合、そのワークスペースはすでに自動で新しいinference_geoベースの仕組みへ移行済みです。具体的にはallowed_inference_geos: ["us"]とdefault_inference_geo: "us"が自動設定され、コード変更は一切不要です。既存のデータレジデンシー要件は新しいgeo制御の下でそのまま強制され続けます。ただし「何が」「どう」変わったのかを理解しておかないと、後からグローバルルーティングへ切り替えたいときや、監査で設定の根拠を説明するときに困ります。
旧オプトアウトはどんな設定だったか
移行前の旧オプトアウトは、組織レベルで全リクエストを米国インフラに制限する単一の設定でした。ワークスペース単位やリクエスト単位の細かい制御はできず、オプトアウトするかしないかの二択だったのが特徴です。
新しいデータレジデンシー制御は何が違うか
新しい仕組みは、旧オプトアウトが担っていた役割を2つのメカニズムに分割しています。
- リクエスト単位の制御:
inference_geoパラメーターを各APIコールに付けることで、"us"か"global"かをリクエストごとに指定できます - ワークスペース単位の制御: Consoleの
default_inference_geoとallowed_inference_geosという2つの設定で、ワークスペース内の全キーに対するgeoポリシーを一括で強制できます
つまり旧オプトアウトの「組織全体を一律に米国縛りにする」という粗い制御が、リクエスト単位の柔軟性とワークスペース単位の強制力に分かれた形です。
移行後のワークスペースで実際に何が設定されたか
旧オプトアウトを使っていたワークスペースは、次の対応表の通りに自動移行されています。
| 旧設定 | 新しい設定 |
|---|---|
| グローバルルーティングのオプトアウト(米国限定) | 新しい設定allowed_inference_geos: ["us"]、default_inference_geo: "us" |
そのワークスペースのキーを使うAPIリクエストは、引き続きすべて米国インフラ上で実行されます。現状の挙動を維持するための追加対応は不要です。
グローバルルーティングを使いたくなったときの手順
データレジデンシー要件が変わり、パフォーマンスや可用性を優先してグローバルルーティングを使いたい場合は、ワークスペースのinference geo設定を更新します。allowed_inference_geosに"global"を追加し、default_inference_geoを"global"に設定すれば、そのワークスペースからのリクエストはグローバルルーティングの対象になります。
リクエストごとにinference_geoを明示して確認する
ワークスペースの既定値に任せず、リクエスト単位で明示的にinference_geoを指定することもできます。POST /v1/messagesの呼び出しにパラメーターを1つ足すだけです。
curl https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{
"model": "claude-opus-5",
"max_tokens": 1024,
"inference_geo": "us",
"messages": [{"role": "user", "content": "Summarize the key points of this document."}]
}'レスポンスのusageオブジェクトにはinference_geoフィールドが含まれ、実際にどこで推論が実行されたかを確認できます。移行後に「本当に米国だけで処理されているか」を検証したいときは、このフィールドを見れば済み、ログを別途突き合わせる必要はありません。
ワークスペース側でallowed_inference_geosを設定している場合、そのリストに無い値をリクエストで指定するとエラーが返ります。旧オプトアウトの時代は組織全体が一律に米国限定だったため起きなかった種類のエラーなので、移行後にリクエスト単位のinference_geo指定を使い始めるチームは、ワークスペース側の許可リストとの整合を先に確認しておく必要があります。
パートナー基盤経由の利用ではこの移行が当てはまらない
旧オプトアウトからの自動移行は、Claude API(第一者)とClaude Platform on AWSを対象にしています。同じClaudeでも、利用しているプラットフォームによってはこの移行の仕組み自体が当てはまりません。
Amazon BedrockとGoogle Cloudでは、推論のリージョンはエンドポイントURLやinference profileで決まる仕組みのため、inference_geoパラメーター自体が存在しません。以前これらの基盤上でリージョンを米国に固定していた場合、その制御は今後もエンドポイント選択やinference profileの設定で行うことになり、allowed_inference_geosのようなワークスペース単位の設定には影響されません。
Microsoft Foundry経由の場合もinference_geoは使えませんが、代わりにAzureのUS Data Zone Standardというデプロイ形態を選ぶことで、推論を米国内に留められます。この場合の1.1倍の追加料金は、Azure上でUS Data Zone Standardを使うデプロイにも同じ倍率で適用されます。OpenAI SDK互換エンドポイントを使っている場合もinference_geoパラメーターは指定できないため、旧オプトアウト相当の制御が必要ならAPI呼び出し自体をinference_geoに対応した経路に切り替える必要があります。
移行によって料金は変わるか
移行そのものは料金体系を変えません。レガシーモデル(inference_geoパラメーターに対応しない旧世代モデル)は移行の影響を受けず、これまで通り標準料金のままです。Claude 4.6以降の新しいモデルで米国限定推論(inference_geo: "us")を使う場合は、トークン単価が入力・出力・キャッシュ書き込み・キャッシュ読み込みすべてで標準の1.1倍になりますが、これは移行前から適用されている価格体系であり、移行によって新たに発生した負担ではありません。
Priority Tierのコミットメント契約がある組織は、この1.1倍がトークン消費のカウント方法にも影響することを押さえておく必要があります。inference_geo: "us"で消費した1トークンは、コミット済みTPM(1分あたりのトークン数)の消費として1.1トークン分としてカウントされます。プロンプトキャッシュなど他の料金倍率が消費レートに反映される仕組みと同じ扱いです。
Batch APIでもgeoを個別指定できる
移行後のinference_geoパラメーターはBatch APIでも使えます。バッチ内の各リクエストごとに個別のinference_geo値を指定できるため、同じバッチジョブの中で米国限定リクエストとグローバルリクエストを混在させることも設計上は可能です。旧オプトアウトの時代はワークスペース全体が一律だったので、この粒度の使い分けは新しい仕組みになって初めて可能になった点です。
workspace geoは移行対象の設定とは別物
ここまでのallowed_inference_geosとdefault_inference_geoは、推論をどこで実行するかを制御するinference geo側の設定です。旧オプトアウトからの自動移行が書き換えたのもこちらだけで、データの保存先やエンドポイント処理の実行地域を制御するworkspace geoは移行の対象になっていません。
workspace geoはワークスペース作成時に選び、後から変更はできません。現状選べる値は"us"のみです。新しいワークスペースを作ってworkspace geoを設定する場合、Consoleの「Settings」>「Workspaces」から新規ワークスペースを作成し、作成フローの中でworkspace geoを選択します。旧オプトアウトが自動移行されたのは既存ワークスペースのinference geo側の設定であり、workspace geoについては元から選択肢が"us"しかなかったため、移行前後で変わったことはありません。
移行後も残る制約
- ワークスペースgeoは米国のみ: 保存先を制御する
workspace geoは現状"us"しか選べず、しかもワークスペース作成後は変更できません。オプトアウト移行の対象になったinference_geoとは別の設定なので混同しないよう注意が必要です - レート制限は全geo共通:
inference_geoを切り替えても、レート制限はgeoをまたいで共有されます。米国限定運用からグローバルルーティングに変えても、レート制限枠そのものは増減しません。エラーへの対処はClaude rate limitエラーの対処を参照してください - 選べる値は
usとglobalの2つだけ: 日本を含む他地域を明示的に指定するオプションは、移行後の新しい仕組みでも用意されていません - モデル世代による対応差:
inference_geoパラメーターはClaude 4.6以降のモデルのみ対応し、Claude Opus 4.5・Sonnet 4.5・Haiku 4.5以前のモデルに指定すると400エラーになります。レガシーモデルを使い続けている組織は、移行後もgeo設定を意識する機会自体が発生しません - Claude Managed Agentsは別軸で個別指定できる: エージェントの設定で
inference_geoをピン留めすると、そのエージェントを実行するセッションはワークスペースの既定値ではなくピン留めされたgeoに従います。セッション作成時の個別上書きも可能で、ピン留めの無いエージェントはワークスペースの既定inference geoに従います
まとめ
旧オプトアウトからの移行は自動で完了しており、これまで米国限定運用をしていた組織はallowed_inference_geos: ["us"]とdefault_inference_geo: "us"が設定された状態でそのまま運用を続けられます。コード変更は不要ですが、旧設定が「組織一律の二択」だったのに対し、新しい仕組みは「リクエスト単位のinference_geo」と「ワークスペース単位のallowed_inference_geos/default_inference_geo」に分かれている点を理解しておくと、将来グローバルルーティングへ切り替える判断がしやすくなります。inference geoとworkspace geoという2つの設定軸そのものの詳細、および日本の個人情報保護法との関係はClaude Data Residencyと外的環境の把握で扱っています。