workspace geoによるデータローカライゼーションは日本企業の要件を満たすか

結論:workspace geoは「us」だけで、日本は選べない

Claude Platformのworkspace geoで選べる値は「us」の1つだけです。日本やアジア太平洋地域にデータを保存する選択肢はありません。「workspace geoを日本にすれば国内保存の要件を満たせるか」という問いには、直接APIの設定だけでは「できない」と答えることになります。

日本リージョンを指定できるのは、直接APIではなく提携クラウドの側です。Amazon Bedrockには東京(ap-northeast-1)と大阪(ap-northeast-3)を含む日本向けの推論プロファイルがあります。

2つのgeoは、制御する対象が別物

データレジデンシーの設定は2つあり、混同すると監査資料の記述がずれます。

2つの違いの詳細はClaudeのデータレジデンシー — inference geoとworkspace geoの違いにあります。ここでは日本企業の要件にどこまで届くかを扱います。

workspace geoを設定する手順と、後戻りできない点

workspace geoは、Consoleでワークスペースを作る時点で確定します。

「データ保存地域は選択できる」と稟議や監査資料に書くと、実態と食い違います。設計上は地域を選べる項目でも、日本企業にとっては現状「us」固定です。なお、レート制限はどのgeoを使っても共通です。

inference geoは「米国に固定」までしかできない

inference geoは、ワークスペース単位でも制限できます。管理者はConsoleまたはAdmin APIのdata_residencyフィールドで、次の2つを設定します。

以前に「グローバルルーティング」のオプトアウトで米国限定運用にしていた組織は、allowed_inference_geos: ["us"]とdefault_inference_geo: "us"へ自動的に移行されています。コードの変更は要りません。「常に米国のインフラだけで処理したい」という要件なら、この2つでワークスペース全体に強制できます。ただし、これは「米国に固定する」設定であり、「日本に限定する」設定ではありません。

実際にどこで動いたかは、レスポンスのusage.inference_geoで見られます。監査で「米国限定で処理された」ことを示したいときの手がかりになります。公式ドキュメントのcURL例は次の形です。

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": "us"が入ります。Batch APIでも使え、バッチ内のリクエストごとに値を変えられます。

米国限定を選ぶと、Claude 4.6以降のモデルでは入力・出力・キャッシュ書き込み・キャッシュ読み取りのすべてが標準料金の1.1倍になります。Priority Tierのコミットメントがある場合は、1トークンあたり1.1トークン分がTPM(分あたりトークン数)から引かれます。inference_geoは4.6より前のモデルには対応せず、指定すると400エラーです。

Claude Platform on AWSの「リージョン」は推論の場所を決めない

AWS経由の「Claude Platform on AWS」には、workspace geoという設定項目がありません。Managed Agentsのセッションは、実効的に「us」のworkspace geoで動きます。

紛らわしいのは、この製品のワークスペースがAWSの単一リージョンに紐づく点です。SDKでもAWS_REGIONが必須で、日本のリージョンを指定すること自体はできます。しかし公式ドキュメントでは、このリージョンが決めるのは、呼び出すゲートウェイのエンドポイントと、IAM・CloudTrail・請求の範囲です。モデル推論の場所は固定しません。推論の場所はここでもinference_geoで決まり、値はusとglobalです。

2026年9月18日00:00 UTCより前に作ったワークスペースでは、Anthropicがリクエスト処理やデータ保存、推論をAWSの外で行う場合があります。それ以降に作ったワークスペースは、AWSのインフラで処理と保存が行われます。いずれの場合も、構成するサブサービスは予告なく変わりえます。

東京リージョンのワークスペースを作っても、それが「国内処理」の根拠にはなりません。Bedrockとは別の製品なので、Bedrockの東京リージョン対応の話をここに持ち込むのも誤りです。

日本を指定できる経路は、提携クラウドの側にある

日本向けの固定が必要なときの選択肢を、公式ドキュメントの記述どおりに並べます。

Bedrockの地域表では、東京(ap-northeast-1)が「Global, JP, In-region only」、大阪(ap-northeast-3)が「Global, JP」です。JPは複数リージョンにまたがる推論プロファイルで、日本の範囲内で振り分けます。東京の「In-region only」は、プロファイルを介さない単一リージョン指定ができるという意味です。地域を絞ると、グローバルエンドポイントより10%高くなります。

費用の上乗せ幅は、どの経路でも約1割です。ただし基準が異なります。直接APIの米国限定は標準料金の1.1倍、Bedrockの地域指定はグローバルエンドポイント料金の1.1倍です。BedrockとGoogle Cloudの料金は、各クラウド側が独自に定めています。

モデルによる差も大きい点に注意が必要です。Claude Fable 5.1は、Bedrockのリージョナルエンドポイントが現状us-east-1だけです。つまり「日本の推論プロファイルで使いたいモデル」が対応しているかを、モデル名ごとに調べる必要があります。Bedrockと直接APIで機能の差もあるため、現在の利用機能が移せるかの確認も欠かせません。

Google Cloudも同じ考え方で、inference_geoは適用されません。エンドポイントはグローバル・マルチリージョン・リージョナルの3種類で、マルチリージョンの識別子は現状usとeuだけです。リージョナルエンドポイントの対象はClaude Sonnet 4.6以前のモデルです。それより新しいモデルは、グローバルかマルチリージョンのエンドポイントを使います。

Microsoft Foundryは、AzureでホストされるモデルにUS Data Zone Standardというデプロイ種別があります。これは米国内に推論をとどめるもので、inference_geo: "us"に相当し、1.1倍の倍率が付きます。デプロイ作成時の「Region scope」でGlobalかData Zoneを選びますが、Claude Sonnet 5.5ではGlobalを選びます。選べるのはGlobalとUS Data Zoneだけです。

Bedrockでは、推論リージョンはエンドポイントのURLや推論プロファイルで決まります。そのためinference_geoは適用されません。直接APIと同じ書き方で国内に固定できると考えると、設計が合いません。

要件の種類で、検討の出発点が変わる

日本企業が保存地域を気にする理由は、業界や社内規程で異なります。必要なのが「国内の保存・処理そのもの」なのか、「委託先の管理体制と契約統制」なのかで、進む道が分かれます。

個人情報保護法の「外的環境の把握」義務との関係は、Claude Data Residencyは個人情報保護法の「外的環境の把握」にどう効くかで扱っています。暗号鍵を自社で握る方向なら、CMEKが日本企業の暗号鍵管理要件を満たすかが参考になります。

Managed Agentsを使う場合は、エージェント単位でinference_geoを固定でき、セッション作成時に上書きもできます。セルフホスト型サンドボックスなら、ツール実行とファイルシステムは自社管理のインフラに残ります。ただしメモリストアの中身はAnthropicが保管し、セッションの間だけサンドボックスにコピーされます。「ツール実行が社内に残る」と「会話の記憶が社外に保管される」は別の話なので、要件の対象がどちらかを分けて考える必要があります。

まとめ

「日本に置いたつもり」が崩れやすい箇所は3つあります。Platform on AWSで東京リージョンを選んだワークスペース、Bedrockで日本向けプロファイルを使いたいモデルの対応状況、Managed Agentsのメモリストアです。最初に、使いたいモデルがその経路の地域指定に対応しているかと、社内の要件が保存先そのものを問うのかを確かめると、検討の無駄が減ります。