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

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

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

inference geoはAPIリクエストごとにinference_geoパラメーターで指定でき、値は"global"(既定)と"us"の2択です。一方のworkspace geoはConsoleでワークスペースを作成する時点で決まり、あとから変更できません。選べる値は"us"のみです。この2軸はそれぞれ制御する対象も、設定する場所も、料金への跳ね返り方も異なります。

Inference/Workspace geoの違い

両者は「いつ・どこで効くか」がまったく違います。inference geoはリクエスト単位の一時的な制御、workspace geoはワークスペースに紐づく恒久的な制御です。

workspace geoが対象にするのは、保存データだけではありません。画像のトランスコードやコード実行といった「エンドポイント処理」もこの地域設定に従います。つまり、推論結果をどこで作るか(inference geo)と、その周辺のデータをどこに置くか(workspace geo)は、Anthropicの設計上ハッキリと役割分担されています。

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",
    "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指定で上書きできます。allowed_inference_geosに含まれない値を明示的に指定した場合は、上書きではなくAPIエラーになります。ホワイトリストは既定値の変更手段ではなく、そのワークスペースで許可する値そのものを絞り込む制約として働きます。

inference geoとworkspace geoの制限

データレジデンシーの仕組みには、公式が明記している制限がいくつかあります。まず、レート制限はすべてのgeoで共有です。inference_geoをusに固定しても、globalと別枠のレート制限が用意されるわけではありません。次に、inference geoの選択肢はglobalとusの2つだけで、地域を細かく選べるわけではありません。workspace geoも同様にusの1択で、変更経路自体が存在しません。

この制限は、コンプライアンス要件からinference geoをus固定にしても、スループット面での恩恵は無いことを意味します。レート制限の余裕を確保する目的で地域を分散させる、という設計はこの仕組みでは成立しません。

Workspace geoはなぜ作成後に変更できないのか

Workspace geoはワークスペース作成時に決まり、その後は変更できません。理由は公式ドキュメントに明記されていませんが、保存データとエンドポイント処理の地域を後から動かす操作は、既存データの物理移動を伴うため、恒久設定として設計されているとみるのが自然です。

選べる値は"us"だけです。将来的にリージョンが増える可能性はありますが、公式ドキュメントが案内しているのはこの1択に限られます。Claude Platform on AWSではさらに事情が異なり、workspace geo自体が設定不可で、実効的なworkspace geoは常に"us"として扱われます。

US限定推論はなぜ1.1倍の料金になるのか

Claude 4.6以降のモデルでinference_geo: "us"を指定すると、入力トークン・出力トークン・キャッシュ書き込み・キャッシュ読み取りのすべてのカテゴリーで、標準料金の1.1倍が適用されます。global(グローバルルーティング)を選べば標準料金のままです。

この倍率は、Claude API(ファーストパーティ)とClaude Platform on AWSに適用されます。Claude in Microsoft Foundryでも、Azureホスト型のUS Data Zone Standardデプロイメントには同じ1.1倍が掛かります。BedrockとGoogle Cloudは自前のリージョン別料金体系を持つため、この倍率の対象外です。

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

古いモデル(Claude Opus 4.5、Claude Sonnet 4.5、Claude Haiku 4.5以前)はinference_geo自体に対応していません。パラメーターを付けてリクエストすると400エラーが返り、料金への影響もありません。

Batch/Managed Agentsのgeo指定

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

Claude Managed Agentsは、エージェント単位でのgeo固定に対応します。エージェントのモデル設定でinference_geoをピン留めすると、そのエージェントが動かすセッション全体が、指定した地域で推論を実行します。セッション作成時に個別のセッションだけ上書きすることもできます。ピン留めしていないエージェントは、ワークスペースの既定inference_geoをリクエストごとに引き継ぎます。

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

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

以前、組織単位で「グローバルルーティングをオプトアウトし、推論を米国内に限定する」設定を使っていた場合、その設定は自動的に新しい仕組みへ移行済みです。ワークスペースにはallowed_inference_geos: ["us"]とdefault_inference_geo: "us"が自動設定されており、コード変更は不要です。既存のデータレジデンシー要件は、新しいgeo制御の下でそのまま維持されます。

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

InferenceとWorkspaceのgeoを分けた狙い

この2軸分離は、パフォーマンスとコンプライアンスの要求を両立させるための設計に見えます。もし地域制御が1つの設定だったら、レイテンシー最適化のためのリージョン切り替えと、法規制対応のためのデータ保管地域固定が、同じスイッチを取り合うことになります。inference geoをリクエスト単位で自由にしつつ、workspace geoを恒久固定にすることで、Anthropicは「パフォーマンスは動かしてよいが、データの物理的な所在地は動かさない」という線引きを明確にしています。

一方で、workspace geoの選択肢が"us"しかない現状は、地理的な選択の自由という意味では限定的です。EU域内でのデータ保管を求める組織にとっては、この設計はまだゴールに届いていません。個人情報保護法の観点からデータレジデンシーを検討する場合は、Claude Data Residencyは個人情報保護法の「外的環境の把握」にどう効くかで法務的な論点を扱っています。

まとめ

Claudeのデータレジデンシーは、inference geo(推論の実行地域、リクエストごとにglobal/usを選択)とworkspace geo(データ保存とエンドポイント処理の地域、ワークスペース作成時に固定、usのみ)という、性質の異なる2つの設定でできています。us限定推論はClaude 4.6以降で1.1倍の料金がかかり、古いモデルはそもそもパラメーター自体に対応していません。

API実装者は、料金試算とコンプライアンス要件の両方から、この2軸を混同せずに設計へ落とし込む必要があります。実装全体の見取り図はAnthropic API完全ガイドを、課金がどう画面表示に反映されるかはClaude Code v2.1.239を参照してください。ワークスペースの新規作成やAdmin APIでの一括設定を予定しているチームは、公式のWorkspace-level restrictions節で許可地域リストの設計を先に固めておくと、あとからの手戻りが減ります。