Claude Data Residencyの旧opt-out移行で何が変わったか

何もしなくてもよいが、仕組みは変わった

米国限定ルーティングへのオプトアウトを組織単位で設定していたワークスペースは、すでに新しいinference_geoベースの仕組みへ自動で移行されています。allowed_inference_geos: ["us"]とdefault_inference_geo: "us"が自動設定され、コード変更は要りません。対になるworkspace geoによるデータローカライゼーションは日本企業の要件を満たすかもあわせて読めます。

困るのは、後からグローバルルーティングへ切り替えたいときと、監査で設定の根拠を問われたときです。以下では、自分の環境が移行の対象か、何が書き換わったか、本当に米国で動いているかをどう示すか、の順に進みます。

自分の環境は自動移行の対象か

同じClaudeでも、使っている基盤によって答えが変わります。次の4つのどこで呼んでいるかで切り分けられます。

Claude Platform on AWSでは、ワークスペースを結び付けたAWSリージョンが決めるのは、呼び出すゲートウェイのエンドポイントと、IAM・CloudTrail・請求の範囲です。推論がどこで動くかは決まりません。推論の場所は、リクエストごとのinference_geoかワークスペースの既定値で固定します。

Claude Platform on AWSの処理場所には、作成時期による違いもあります。2026年9月18日00:00 UTCより前に作ったワークスペースでは、リクエストの処理・データの保存・推論がAWSの外で行われる場合があります。それ以降のワークスペースは、AWSのインフラで処理され、保存されます。

旧オプトアウトと新しい制御は何が違うか

移行の対応は1行です。グローバルルーティングのオプトアウト(米国限定)が、allowed_inference_geos: ["us"]とdefault_inference_geo: "us"の組に置き換わりました。そのワークスペースのキーを使うリクエストは、これまでどおり米国のインフラ上で動きます。

本当に米国だけで処理されているかを確かめる

設定値は意図を示し、レスポンスの値は実績を示します。確かめ方は2通りです。

1つ目は、リクエストごとの確認です。POST /v1/messagesにinference_geoを足して送ると、レスポンスのusageオブジェクトに実際の推論地域が返ります。

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-5",
    "max_tokens": 1024,
    "inference_geo": "us",
    "messages": [{"role": "user", "content": "Summarize the key points of this document."}]
  }'

返ってくるusageは次の形です。ログを別途突き合わせなくても、inference_geoの値で足ります。

{
  "usage": {
    "input_tokens": 25,
    "output_tokens": 150,
    "inference_geo": "us"
  }
}

2つ目は、組織全体の集計です。Usage and Cost APIは、使用量をinference_geoで絞り込み・グループ化できます。管理者用のキー(ANTHROPIC_ADMIN_KEY)で、モデル別・日別に地域の内訳を取る例です。

curl "https://api.anthropic.com/v1/organizations/usage_report/messages?\
starting_at=2026-02-01T00:00:00Z&\
ending_at=2026-02-08T00:00:00Z&\
group_by[]=inference_geo&\
group_by[]=model&\
bucket_width=1d" \
  -H "anthropic-version: 2023-06-01" \
  -H "x-api-key: $ANTHROPIC_ADMIN_KEY"

絞り込みに使える値はglobal・us・not_availableの3つです。2026年2月より前に出たモデル(Claude Opus 4.6とSonnet 4.6より前)はinference_geoを受け付けないため、集計ではnot_availableと表示されます。

費用レポートでも、descriptionでグループ化すると、応答にmodelやinference_geoといった項目が含まれます。1.1倍がかかる米国限定推論の費用を、モデルと並べて追えます。

ワークスペースの許可リストが引き起こすエラー

allowed_inference_geosに載っていない値をリクエストで指定すると、APIはエラーを返します。"us"だけを許可しているワークスペースで"global"を指定すれば、このエラーに当たります。

組織一律だった旧オプトアウトからの移行後に、リクエストごとのinference_geoを使い始めるチームは、先にワークスペース側の許可リストを見ておきます。原因の切り分けが速くなります。

inference_geoに対応するのはClaude 4.6以降のモデルです。Claude Opus 4.5・Sonnet 4.5・Haiku 4.5とそれ以前のモデルにパラメーターを付けると、400エラーが返ります。

グローバルルーティングへ切り替える手順

データレジデンシーの要件が変わり、性能と可用性を優先したくなった場合は、ワークスペースの設定を更新します。

設定は、ConsoleかAdmin APIのdata_residencyフィールドから変更します。Claude Platform on AWSでも、同じワークスペース設定を使えます。そこではinference_geoを省略したとき、既定値が設定済みならその値、未設定ならglobalで処理されます。

料金とPriority Tierへの影響

旧世代モデルの料金は、移行の影響を受けません。Claude 4.6以降のモデルで米国限定推論を使うと、次の倍率がかかります。

旧世代モデルはinference_geoを受け付けず、標準料金のままです。Priority Tierの消費量は、プロンプトキャッシュなど他の倍率が消費レートに反映される仕組みと同じ扱いです。倍率は、Batch APIの割引とも重なって適用されます。

パートナー基盤の価格は別体系です。Bedrockにはリージョナルとグローバルの2種類のエンドポイントがあり、Google Cloudにはグローバル・マルチリージョン・リージョナルの3種類があります。Claude 4.5以降のモデルでは、リージョナルとマルチリージョンのエンドポイントに、グローバルに対して10%の上乗せがあります。Foundryは例外で、Azure上でUS Data Zone Standardを使うデプロイに、同じ1.1倍が適用されます。

Batch APIとManaged Agentsでの指定場所

Batch APIでも、inference_geoは使えます。バッチ内の各リクエストが、それぞれinference_geoの値を持てます。同じバッチの中で、米国限定のリクエストとグローバルのリクエストを混在させる構成も可能です。

Claude Managed Agentsでは、指定がエージェントの設定側に移ります。モデル設定をオブジェクト形式で書き、idと並べてinference_geoを指定します。

{
  "name": "Geo-pinned assistant",
  "model": {"id": "claude-opus-5-5", "inference_geo": "us"}
}

ピン留めしたエージェントのセッションは、ワークスペースの既定値ではなく、固定した地域に従います。セッション作成時の個別上書きもできます。ピン留めのないエージェントは、各リクエストが処理される時点のワークスペース既定値に従います。

"us"に固定したエージェントのモデルリクエストは、同じ1.1倍で課金されます。セルフホスト型サンドボックスを使うと、ツール実行とサンドボックスのファイルシステムは手元のインフラに残ります。ただし、接続したメモリストアの中身はAnthropicが保持し、セッションのためにサンドボックスへコピーされます。

workspace geoは移行対象の設定とは別物

ここまでのallowed_inference_geosとdefault_inference_geoは、推論をどこで動かすかを決めるinference geo側の設定です。移行表に載っているのはinference geo側の対応だけです。データの保存先とエンドポイント処理(画像のトランスコードやコード実行など)の地域を決めるworkspace geoは、移行表にありません。

workspace geoはワークスペースの作成時に選び、後から変更できません。現在選べる値は"us"のみです。Consoleの「Settings」>「Workspaces」から新しいワークスペースを作り、作成フローの中で選びます。

Claude Platform on AWSでは、workspace geoは設定できません。そこで動くManaged Agentsのセッションは、実効的なworkspace geoが"us"になります。

移行後も残る制約

• レート制限は全geo共通: inference_geoを切り替えても、レート制限はgeoをまたいで共有されます。グローバルに変えても、枠は増減しません。エラーへの対処はClaude rate limitエラーの対処にあります
• inference geoの値は2つだけ: 選べるのはusとglobalです。日本を含む他の地域を指定するオプションは、新しい仕組みにもありません
• workspace geoは米国のみ: しかも作成後に変更できません

まとめ

旧オプトアウトからの移行は自動で完了しており、米国限定の運用はallowed_inference_geos: ["us"]のまま続きます。監査では、設定値に加えてUsage and Cost APIのinference_geo集計を見せると、実績で示せます。inference geoとworkspace geoという2つの設定軸の詳細と、日本の個人情報保護法との関係はClaude Data Residencyと外的環境の把握で扱っています。