Claudeのデータレジデンシー—inference geoとworkspace geoの違い

データレジデンシーとは何か

データレジデンシーとは、データが処理・保存される地理的な場所を利用者が管理できる仕組みです。Claudeでは、推論の実行地域と、保存データの置き場所を別々に制御します。

この記事に出てくる「geo」は、geography(地理的な地域)の略です。inference_geoは推論の地域、workspace geoは保存の地域を指します。

Claudeのデータレジデンシーを支える2つの設定

Claudeのデータレジデンシーは、1つの設定ではありません。inference geo(推論がどこで実行されるか)とworkspace geo(データがどこに保存されるか)という、独立した2つの制御で成り立っています。混同すると、料金設計や、CMEKのような暗号鍵管理という別軸との切り分けを含むコンプライアンス対応を誤ります。

inference geoはAPIリクエストごとにinference_geoパラメーターで指定できます。一方のworkspace geoは、Consoleでワークスペースを作成する時点で決まります。

2つのgeoは何を決めて、どこで設定するのか

制御する対象も、設定する場所も、変えられるタイミングも違います。

workspace geoを決める操作は、ConsoleのSettings > Workspacesで新しいワークスペースを作り、作成画面でgeoを選ぶ流れです。保存地域を変えたいときは、新しいワークスペースを作ります。

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

inference geoをリクエストごとに指定する

inference_geoはPOST /v1/messagesの任意パラメーターです。指定しなければ既定のglobalが使われ、最適なパフォーマンスと可用性を求めて、利用できるどの地域でも推論が走ります。米国内に固定したい場合は"us"を明示します。

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": "要約してください"}]
  }'

レスポンスのusageオブジェクトには、推論が実際に実行された地域を示すinference_geoフィールドが返ります。

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

ワークスペース単位で既定値を固定することもできます。ConsoleまたはAdmin APIのdata_residencyフィールドで、default_inference_geo(未指定リクエストの既定値)とallowed_inference_geos(そのワークスペースで使える値の許可リスト)を設定します。個別のリクエストは、明示的なinference_geoで既定値を上書きできます。

許可リストの外の値を指定したときは、上書きにならずAPIエラーが返ります。許可リストは既定値を変える手段ではなく、使える値そのものを絞る制約です。

米国で推論されたかを後から確かめる

リクエスト単体の確認は、レスポンスのusage.inference_geoを見れば済みます。組織全体で「usのはずのトラフィックが本当にusだったか」を調べるには、Usage and Cost APIが使えます。

curl "https://api.anthropic.com/v1/organizations/usage_report/messages?\
starting_at=2026-09-01T00:00:00Z&\
ending_at=2026-09-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"

not_availableは、inference_geoに対応していないモデルの使用量に付く値です。2026年2月より前に出たモデル(Claude Opus 4.6とClaude Sonnet 4.6より前)が該当します。集計にnot_availableが混ざっていても、地域指定が失敗しているわけではありません。

コスト側のレポートでは、descriptionでグループ化すると、返ってくる項目にmodelと並んでinference_geoが含まれます。請求の内訳を地域で割りたいときは、こちらを使います。

米国限定推論の1.1倍はどの経路で掛かるのか

Claude 4.6以降のモデルでinference_geo: "us"を指定すると、入力トークン・出力トークン・キャッシュ書き込み・キャッシュ読み取りのすべてで、標準料金の1.1倍が適用されます。globalを選べば標準料金のままです。経路ごとの扱いは次のとおりです。

Priority Tierを契約している場合、1.1倍はコミットしたTPM(1分あたりのトークン数)の消化速度にも効きます。inference_geo: "us"で消費した1トークンは、コミット枠から1.1トークン分を引き落とします。プロンプトキャッシュの倍率がバーンダウン率に効くのと同じ扱いです。

Claude Codeの/cost・ステータスライン・--max-budget-usdが出すコスト見積もりは、Claude Code v2.1.239から1.1倍を含むようになりました。それ以前は、米国限定ワークスペースで見積もりが実際の請求より少なく出ていました。

inference_geoでつまずきやすい場面

古いモデルに付けると失敗します。Claude Opus 4.5・Claude Sonnet 4.5・Claude Haiku 4.5およびそれ以前のモデルでは、inference_geoを付けたリクエストが400エラーになります。料金は標準のままです。

レート制限はすべてのgeoで共有です。usに固定してもglobalとは別枠のレート制限は用意されないので、コンプライアンス要件でus固定にしても、スループットの余裕は増えません。レート制限の余裕を確保する目的で地域を分散させる設計は、この仕組みでは成り立ちません。

ゼロデータリテンション(ZDR)との関係は、保持のルールを定めたページ側の表で見ます。機能別の表では、データレジデンシーはZDRの対象が「Yes」です。一方でBatch APIは「No」(29日間保持)、Claude Managed Agentsも「No」(セッションのトランスクリプトは削除するまで残る)です。地域を指定しても、これらの機能の保持の扱いは表のとおりです。

BatchとManaged Agentsでの指定

Batch APIはinference_geoをサポートしています。バッチ内の各リクエストが、それぞれ独立して値を持てるので、1つのバッチジョブの中で一部をus、残りをglobalに振り分けられます。バッチ処理そのものの仕組みはClaude Batch APIの使い方で扱っています。

Claude Managed Agentsは、エージェント単位でのgeo固定に対応します。modelをオブジェクト形式にして、idと並べてinference_geo("us"または"global")を渡すと、そのエージェントが動かすセッションのモデルリクエスト全体が、指定した地域で推論されます。セッション作成時に、個別のセッションだけ上書きすることもできます。

ただし、上書きのmodelオブジェクトにinference_geoを含めないと、そのセッションではエージェントのピンが外れ、ワークスペースのdefault_inference_geoに従います。上書きはmodelオブジェクトを丸ごと置き換えるため、ピンを保ちたいときはidと並べてinference_geoも書き直します。

ピン留めしていないエージェントは、リクエストの時点でワークスペースの既定inference_geoに従います。ピン留めでusにしたエージェントのセッションにも、同じ1.1倍が掛かります。

Managed Agentsはworkspace geoの設定にも従います。セルフホスト型サンドボックスを使う構成では、ツール実行とサンドボックスのファイルシステムは利用者側のインフラに留まり、Anthropicの地域設定の対象外です。ただし、接続したメモリーストアの中身はAnthropic側に保存され、セッションのたびに利用者のサンドボックスへコピーされます。この部分はAnthropic側に保存されるため、workspace geo(保存地域)の設定が関わります。

旧オプトアウトからの移行で何が変わったか

以前、組織単位で「グローバルルーティングをオプトアウトし、推論を米国内に限定する」設定を使っていた場合、その設定は自動的に新しい仕組みへ移行済みです。ワークスペースにはallowed_inference_geos: ["us"]とdefault_inference_geo: "us"が自動設定されており、コード変更は不要です。移行の詳細は旧opt-outの移行で何が変わったかにあります。

旧オプトアウトは組織単位の一括設定でしたが、新方式はリクエスト単位(inference_geoパラメーター)とワークスペース単位(default_inference_geo / allowed_inference_geos)の2階層に分かれました。グローバルルーティングへ切り替えたい場合は、ワークスペースの許可地域リストにglobalを追加し、既定値もglobalに変更します。

推論は動かせても、保存場所は動かせない設計

推論の場所は状況に応じて動かしてよく、データの置き場所は動かさない。この線引きのための分離と読めます(Anthropic ISO 42001認証取得のようなガバナンス面の裏付けとあわせて検討する価値があります)。地域制御が1つの設定だったなら、レイテンシー最適化のためのリージョン切り替えと、法規制対応のための保管地域固定が、同じスイッチを取り合うことになります。

ただし、選べるworkspace geoは"us"の1つだけです。EU域内での保管を要件に置く組織には、今のところ選べる設定がありません。個人情報保護法の観点でデータレジデンシーを検討する場合は、Claude Data Residencyは個人情報保護法の「外的環境の把握」にどう効くかが法務面の論点を扱っています。

まとめ

推論の場所だけが問われるなら、設定はあとからでも変えられます。データの保存地域まで問われる場合は、ワークスペース作成時のworkspace geoが唯一の分かれ目で、あとから直せません。実装全体の見取り図はAnthropic API完全ガイドにあります。