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

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

Claude Platformのworkspace geoが実際に制御する範囲を整理し、日本企業のデータローカライゼーション要件に対する現実的な選択肢を検討します。

結論:現状は「us」固定で日本を選べない

結論から書きます。Claude Platformのworkspace geoで現在選べる値は「us」の1つだけです。日本(またはアジア太平洋地域)にデータを保存する選択肢はありません。「workspace geoを日本に設定すればデータローカライゼーション要件を満たせるか」という問いへの答えは、現状では「できない」です。この前提を押さえたうえで、情シス・コンプライアンス部門が実際にどう判断すべきかを見ていきます。

workspace geoが制御する範囲

workspace geoは、ワークスペース作成時に設定する項目で、データの保管場所(at rest)と、画像のトランスコードやコード実行などエンドポイント処理が行われる場所を制御します。設定手順は次のとおりです。

  1. Consoleにログインし、「Settings」から「Workspaces」を開く
  2. 「新規ワークスペース作成」を選択する
  3. 作成フォーム内でworkspace geoを選択する(現状は「us」のみ表示される)
  4. 作成後はworkspace geoを変更できないため、この時点の選択が確定する

Claude Platform on AWSでは、workspace geoという設定項目自体が存在せず、Managed Agentsのセッションは実質的に「us」として動作します。

inference geoとの違いを混同しない

workspace geoとよく混同されるのがinference geoです。inference geoはAPIリクエストごとに、モデル推論をどこで実行するかを制御するパラメーターで、inference_geoをリクエストに含めるか、ワークスペースのデフォルト値として設定します。選べる値は"global"(既定、最適なパフォーマンスのため任意の地域で実行)と"us"(米国インフラのみ)の2つで、こちらも日本を含むアジア太平洋地域は選択肢にありません。

workspace geoが「保存データがどこにあるか」、inference geoが「推論処理がどこで実行されるか」という別レイヤーの設定である点は、Claudeのデータレジデンシー — inference geoとworkspace geoの違いで詳しく解説しています。本記事はこの2つのうちworkspace geoに絞り、日本企業のデータローカライゼーション要件との適合性を評価します。

なぜ「選択肢が無い」という前提が重要か

workspace geoは技術的には地域を切り替えられる設計になっていますが、現在提供されている値は「us」のみです。設計上は選択肢でも、日本企業にとっては実質的に「固定」です。この違いは、社内稟議や外部監査の資料で「データ保存地域は選択可能」と記載してしまうと、実態と食い違う説明になりかねません。ワークスペース作成前に、公式ドキュメントの制限事項を必ず確認してください。

inference geoには組織単位で制限をかけられる

inference geoは個々のAPIリクエストで指定できるだけでなく、ワークスペース単位で制御することもできます。管理者はConsoleまたはAdmin APIのdata_residencyフィールドで、次の2つを設定できます。

ワークスペースレベルのinference geo制御
  • allowed_inference_geos: ワークスペースが使用できるgeoを制限する。リクエストがこのリストに無いinference_geoを指定した場合、APIはエラーを返す
  • default_inference_geo: リクエストでinference_geoが省略されたときのフォールバック値を設定する。個々のリクエストで明示的に上書きできる

「グローバルルーティング」の既存のオプトアウト設定(米国限定運用)を行っていた組織は、allowed_inference_geos: ["us"]default_inference_geo: "us"へ自動的に移行済みです。コード変更は不要で、既存のデータレジデンシー要件はそのまま維持されます。日本企業が「常に米国インフラのみで処理させたい」という要件を持つ場合、この2つの設定でワークスペース全体に強制できます。ただしこれも「米国のみに固定する」設定であって、「日本に限定する」設定ではない点は変わりません。

米国限定のinference geo(inference_geo: "us")を選択すると、Claude 4.6以降のモデルでは入力・出力トークン、キャッシュ書き込み・読み取りのすべての課金区分で標準料金の1.1倍が適用されます。Priority Tierのコミットメントがある場合、消費されたトークンも1.1倍でTPM(分あたりトークン数)から差し引かれます。データレジデンシー要件のためにinference geoを米国限定にする場合は、このコスト増分を予算に織り込む必要があります。

Claude Platform on AWSではworkspace geoという概念自体が無い

Claude Platform on AWSを利用する場合は、workspace geoという設定項目自体が存在しません。Managed Agentsのセッションは実質的に「us」のworkspace geoとして動作する設計になっています。AWS経由でClaudeを利用していて日本国内のデータ処理を検討している場合、workspace geoの選択肢を探すのではなく、AWS BedrockのAsia-Pacificリージョンでの提供状況を確認するのが正しいアプローチです。この点は直接APIのworkspace geoと、提携クラウド経由の利用とで、確認すべき設定項目そのものが異なるという整理につながります。

業界別に見る、データローカライゼーションが必要になる場面

日本企業が生成AIのデータ保存地域を問題にする典型的な場面は、業界によって性質が異なります。

業界・領域典型的な要求元論点になりやすい点
金融典型的な要求元FISCの安全対策、金融庁のモデル・リスク管理原則論点になりやすい点委託先(クラウド事業者)の所在地・データ移転経路の管理体制
重要インフラ(電力・通信・鉄道等)典型的な要求元経済安保推進法の基幹インフラ制度、業界所管省庁の指針論点になりやすい点特定重要設備の導入時審査、供給途絶リスクの評価
一般企業(個人情報を扱う場合)典型的な要求元個人情報保護法の越境移転規制論点になりやすい点第三者提供に該当するか、本人同意・体制整備のいずれで対応するか

いずれの業界でも「データがどの国のインフラで処理されるか」自体が単独の絶対要件になっているとは限らず、契約(DPA)・アクセス制御・監査証跡といった補完的な統制と組み合わせて評価されるのが一般的です。ただし、業界の指針や社内規程が「国内保存」を明文で必須としている場合は、workspace geoでは要件を満たせないという前提から検討を始める必要があります。

代替として検討できる経路

workspace geoとinference geoが米国限定である一方、Anthropicは提携クラウド経由の別の経路も提供しています。AWS Bedrock・Google Cloud Vertex AI・Microsoft Foundry経由でClaudeを利用する場合、リージョナルエンドポイントの対応状況はプラットフォームごとに異なり、日本を含むアジア太平洋地域への展開も案内されています。ただし対応時期・対応範囲はプラットフォームとリージョンの組み合わせによって差があるため、導入前に必ずAnthropicの公式情報とAnthropicの営業窓口で対象プラットフォーム・リージョンの提供状況を直接確認してください。

データを国内に置くこと自体が絶対要件ではなく、個人情報保護法における体制整備が目的である場合は、workspace geoではなく契約・監査証跡側の対応で要件を満たせるケースもあります。個人情報保護法の「外的環境の把握」義務との関係は、Claude Data Residencyは個人情報保護法の「外的環境の把握」にどう効くかで扱っています。暗号鍵の管理主体を自社に置く方向で規制対応を検討する場合は、CMEKが日本企業の暗号鍵管理要件を満たすかも合わせて確認すると、データ所在地・鍵管理・契約統制の3方向から自社の要件を整理できます。

運用チームが今すぐ確認すべきチェック項目

workspace geoの設定判断に入る前に、次の順序で確認すると手戻りが少なくなります。

  1. 自社(または業界)の要件が「データの国内保存」そのものを求めているか、それとも「委託先の管理体制・契約統制」を求めているかを切り分ける
  2. 前者であれば、workspace geo・inference geoの直接API経路では現状満たせないことを前提に、提携クラウド経由のリージョナル対応状況を確認する
  3. 後者であれば、DPA(データ処理契約)・Compliance APIによる監査証跡・アクセス制御の整備で対応できるかを検討する
  4. どちらの経路を選ぶ場合も、公式changelogでworkspace geo・inference geoの対応地域拡張がアナウンスされていないか定期的に確認する

まとめ

Claude Platformのworkspace geoは、現状「us」以外の選択肢が無く、日本企業がデータローカライゼーション要件をworkspace geoの設定だけで満たすことはできません。inference geoも同様に米国かグローバルの2値に限られています。データの国内保存そのものが要件であれば、提携クラウド経由のリージョナル対応状況を確認するか、契約・監査証跡側の統制で補完する方向を検討してください。業界の要件が委託先管理や契約統制を求めているにすぎない場合は、workspace geoの制約を過度に恐れず、Compliance APIやDPAといった別の統制で要件を満たせる可能性があります。

この記事を共有:XはてブLinkedIn