データレジデンシー、データ主権、データローカリゼーション

インフラストラクチャチームのための実践ガイド

システム環境から任意のデータセットを、あるいは顧客レコード、VMバックアップ、監査ログ、ファイル共有アーカイブ、SaaSエクスポートを選択してみるとします。いや、これらに限らず、今週サポートデスクに上がってきた調査対象のリソースでも何でもいいのですが、そういったデータについて次の質問にスムーズに回答できるでしょうか。

そのデータは物理的にどこに保存されているのか？

どのような法律の適用対象となるのか？

そこから移動させることは合法なのか？

最初の質問は通常、インフラストラクチャ担当者なら誰でも答えられるはずです。しかし、あとの2つの質問はどうでしょうか。

昨今では、このような質問がクラウド戦略、ベンダーの選択、障害復旧（DR）計画、そしてAIの導入に大きく影響し、プロジェクトの進行を可能にも不可能にもする重要な要因となっています。

ただし、データレジデンシー、データ主権、データローカリゼーションのそれぞれによって生じる制約は異なります。その違いを理解することは、データ保護戦略においてアベイラビリティゾーン（AZ）やリテンションポリシーを理解することと同じくらいに大切です。たとえば、AIがデータ主権に影響するかどうか、社内の法務担当者にEU AI規制法などについて訊いてみてください。意外なほどの影響の広がりに驚かされるかもしれません。

データレジデンシーとは

データレジデンシーとは、単純にデータが物理的にどこに保存されているかを示すものです。

たとえば、欧州の企業がバックアップファイルをアイルランドのダブリンに保存し、オブジェクトストレージをドイツのフランクフルトに配備し、DRコピーをポーランドのワルシャワにレプリケートしている場合、それぞれのデータのレジデンシーは単にそれぞれの地域を指します。

このようなデータの保存場所は、法律や規則によって自ずと決まる場合もありますが、それだけで場所を決める企業や団体は稀です。コンプライアンスは重要ですが、レイテンシや顧客との契約、サイバー保険の規定や障害復旧（DR）目標、リソースの調達要件など、さまざまな要因も無視できません。

たとえば、欧州の顧客にサービスを提供しているSaaSプロバイダは、レイテンシを短縮するためにフランクフルトを選択するかもしれません。政府系の顧客には国内ストレージが絶対的な要件になるかもしれません。地域によってはサイバー保険の保障外となるために、データを保存できる地域が限られる場合もあるでしょう。

つまり、重要なことは、データレジデンシーそのものは単に物理的な所在地を指すものですが、現実的にはそこにさまざまな要素が複雑に絡み合っているということです。

データ主権とは

データレジデンシーはデータがどこにあるかを示しますが、データ主権はどこの法律が管轄するかを示します。

ある国の行政区域内にデータが存在する場合、その地域の行政機関がその国の法律にもとづいて法執行を行います。それがデータ主権の基本となります。

問題は、物理的な場所と法適用は必ずしも合致せず、アーキテクチャ図で表せるような単純明快なものではないという点です。米国の企業が欧州の顧客データをフランクフルトに保存してレジデンシー要件を満たすことはできますが、それによって米国の法律の適用外になるとは限りません。プロバイダ、親会社、サービスオペレータが米国の管轄下に属する場合、米国の法令の対象となります。これは、コンプライアンスの議論を複雑化する主要な要因です。ストレージの設置場所と管轄する法執行機関は決して無関係ではありませんが、必ずしも一致するわけではないという現実があります。

一般的に、インフラストラクチャチームはデータをどこに置くべきかを重視し、コンプライアンスチームはどこの法律が適用されるのかを注視する傾向があります。

国境を超えるデータ主権 ― シュレムⅡ判決と米国クラウド法

インフラストラクチャの設計においてもっとも重大な誤解の一つに、当事国の法適用はその国内のみ、という前提があります。これは、将来的に深刻なリスクにつながりかねない間違った解釈です。

コンプライアンスチームとインフラストラクチャチームが同じ会議に出席して、これについて話し合うと、大概、議論がかみ合いません。

欧州のGDPR（一般データ保護規則）が良い例です。この規則はEU居住者のすべての個人データーに、データがどこにあろうと適用されます。EU居住者の個人情報を含むデータセットは、それがパリにあっても、ニューヨークにあっても、シンガポールにあっても、東京にあってもGDPRの対象となります。

この問題が特に注目され出したきっかけは、2020年のシュレムⅡ判決（Schrems II ruling）です。アイルランドに保存されたフェイスブックのデータの米国への移転に異議を申し立てたシュレム氏に対するシュレムⅠ判決は、EU・米国間の個人情報移転の枠組み「プライバシーシールド」へとつながりました。しかし、シュレムⅡ判決はそれを無効とし、国境をまたいで個人情報を扱う企業により厳格な基準適用を課すものとなりました。

米国クラウド法（US CLOUD Act）も、米国サイドから同様の規制を適用するものです。特定の条件において、米国に本拠を置くプロバイダが米国外に保存するデータに対しても、米国の法律と権限が適用されるとするもので、前述の例におけるフランクフルトのデータは国境を越えても米国の管理下に属します。

ワークロードによっては、このような複雑なコンプライアンスリスクに対応可能なものもありますが、政府関連、防衛関連、医療、重要な社会インフラなど、リスクを許容できないものもあり、プラットフォーム選択が極めて重要になります。

このため、データ主権の議論には近年、法律やコンプライアンスの専門家から、調達担当、セキュリティアーキテクト、インフラストラクチャエンジニアに至るまで、幅広い関係者が含まれるようになっています。同じデータセットを、それぞれが違うレンズを通して見ることになるため、それぞれの視点を考慮した総合的な判断が必要になります。

データローカリゼーションとは

データローカリゼーションは、データレジデンシーを厳密にルール化したもので、データがどこに保存されるかよりも、むしろ、どこに保存してはならないかを規定します。

たとえば、ある特定のカテゴリーに属する情報は国外への持ち出しが禁止されていたり、国外へのレプリケーションやバックアップはもちろん、国外からのアクセスや処理が厳密に制限されていたりする場合があります。政府の機密情報、防衛、医療、金融取引に関する情報、重要な社会インフラに関する情報などは通常、このカテゴリーに含まれますが、実際のルールは行政組織によって大きく異なります。

このようなデータローカリゼーションのルールには、データレジデンシー要件とは異なり、アーキテクチャの柔軟性で対応できるような幅はほとんど許容されません。データレジデンシー要件では、適正な管理下で国境をまたぐバックアップや、その際にデータが特定リージョンに残ることを許容する場合がありますが、ローカリゼーションルールでは例外が認められることはありません。

つまり、データローカリゼーションルールのために国ごとに個別のインフラストラクチャスタックを維持しなければならない可能性があり、相当に費用が嵩むのは想像に難くありません。企業や団体はSaaSの導入を制限し、障害復旧（DR）戦略を練り直す必要があります。ローカリゼーションルールさえなければ、どこかの地域に統合てきたはずのバックアップ環境を国ごとに個別に設けなければならず、リリース、マイグレーション、プラットフォームアップグレードのすべての作業が複雑化する可能性があります。

データレジデンシー、データ主権、データローカリゼーションの違い

ここまで説明してきたデータレジデンシー、データ主権、データローカリゼーションの違いを表にまとめると以下のようになります。

概念	何を示すのか	決定因子	柔軟性
データレジデンシー	データが物理的にどこに保存されているのか	パフォーマンス、ユーザーの好み、コンプライアンス	通常はビジネス上の意思決定に依る
データ主権	データに適用される法律や権限は何か	地域の適用法、企業の所有権や権利構成	場所、所有権、プロバイダの構造に依る
データローカリゼーション	データは国外（特定の領域外）に取り出せるのか	法規制	例外を認めない絶対条件の場合が多い

なぜ今これらの課題が注目されるのか

昨今、データレジデンシーとデータ主権が頻繁に取りざたされるようになったのには、いくつか理由があります。

一つはコンプライアンスの厳格化です。10年前までは、国境をまたぐデータのコンプライアンスを気にするのは、いわゆるハイパースケーラーか多国籍の金融機関ぐらいでした。その以外の普通の企業に規制当局は無関心だとされてきましたが、2022年頃に状況が変わりました。今は中規模SaaSベンダーでさえ、データフローの説明責任を問われます。

二つ目は対象範囲の広がりです。EUデータ法、デジタルオペレーションレジリエンス（DORA）法、EU AI法などの枠組みが導入され、従来の個人情報保護の概念を超越して、運用データ、産業システム、サードパーティプロバイダ、クラウドプラットフォーム、AI主導のワークロードなど、幅広いデータに厳しい要件が課されるようになっています。

三つめはソフトウェア自体の問題です。かつてはデータガバナンスの話題の対象にさえ上らなかったプロダクトにも、今ではAI機能が追加されて、さまざまな形でデータがやり取りされるようになっています。言うまでもなく、生産性向上ツール、コラボレーションツール、CRMプラットフォーム、カスタマーサポートシステム、開発ツールもAIサービスを通じたデータを処理し、そのデータはインフラストラクチャチームが簡単にネットワークダイアグラムで想定し得る範囲を超えて、複数の行政区域にまたがって処理されている可能性があります。

データベースがどこに設置されているのかを把握していな組織は滅多にないでしょう。しかし、AIを利用したワークフローが最終的にどこにデータを送っているのかを完全に把握している組織も滅多にありません。このギャップがガバナンスの課題を複雑化しているのが現状です。

データレジデンシールール違反の代償

データレジデンシーのルールに違反した場合のもっともわかりやすい代償は罰金などのペナルティです。しかし、それはもっとも高くつく代償ではありません。

よくあるのは、このようなパターンです：〈規制当局からの照会〉 → 〈法務対応の停滞〉 → 〈顧客の契約更新の停滞〉 → 〈無理のあるマイグレーション〉。

つまり、もっとも高くつく代償は、サービスの停滞です。EUでは、標準契約条項（Standard Contractual Clauses）にある程度のセーフガードを組み合わせてもハイパースケーラーのコンプライアンスが不十分と判断されているので、標準的な企業のコンプライアンスへのハードルはさらに高くなります。

ましてや、中小規模の企業がこのクロスボーダートラップ（国境の落とし穴）にはまった場合、アーキテクチャの緊急見直しプロジェクトに数百時間分のリソースがとらわれ、通常業務が完全停滞する恐れがあります。

これを防ぐには、デプロイメント時にすべての想定課題に対応しておくしかありません。この先行投資は、データがどこに行ったのかを規制当局に問われて初めて確認するよりも、はるかに経済的です。

データレジデンシーの水漏れはどこから

データレジデンシーのルール違反がもっとも発生しやすいのは、プライマリーデータベースではありません。どのような組織でも、主要なデータベースには大概、監督の目が十分に行き届いています。

問題となりやすいのは、周辺システムです。たとえば、バックアップ、分析プラットフォーム、SaaSとの統合システム、AIツール、障害復旧（DR）環境、サポートツール、IDサービスなど、枚挙に暇がありません。データはそのような周辺システムに到達する頃に、オーナーシップが複数のチーム、ベンダー、プラットフォームに枝分かれする傾向があります。

本番環境のワークロードはデータレジデンシー要件を完全に満たし、コンプライアンスパターンも十分に検証済みなのに、その周辺環境で生じている水漏れに気づいていない組織は少なくありません。

クラウドとSaaSのワークロード

クラウドアーキテクチャによく見られる最大の間違いの一つは、データレジデンシー要件はリージョン選択によって満たせるという誤解です。実際には、クラウドコンソールで「東京」を選択することは、プライマリーワークロードがどこで実行されるかを選択しているにすぎません。昨今のアプリケーションは本番環境のデータベースに保存するレコード以外にも非常に多くのデータを生成します。

たとえば、バックアップはオフサイトへの保存が必要です。収集されたログも、どこかでインデックス付けされて保存されます。モニタリングプラットフォームはテレメトリーによってデータを集約します。アナリティクス用には、レポーティングウェアハウスが構築されるかもしれません。カスタマーサポートシステムは各種アタッチメントを保存し、DR用のデータレプリケーションもどこか特別な保存先が必要です。サードパーティとの統合システムがコラボレーションツールやCRMシステム、請求管理プラットフォーム、マーケティングサービスに情報をコピーすることも一般的です。それぞれのシステムがそれぞれ個別のレジデンシープロフィールを持つことになります。

本番環境データベースの最適なロケーションを何か月もかけて決定したのに、ログアーカイブがすべて別の場所に保存されていることが後になって判明した例もあります。誰かがそう設定したわけではなく、採用したベンダーサービスのデフォルトがそうなっていただけです。

SaaSプラットフォームにいたっては、根底にあるアーキテクチャの個々のコンポーネントをすべてユーザーが管理するわけもなく、レジデンシーの複雑化は避けられません。

オーストラリアのソフトウェア企業Atlassianによるデータレジデンシーへのアプローチは、ぜひ参考にしたい取り組みです。同社は、どのプロダクトが厳密なリージョン設定を持ち、どのデータタイプがグローバルで、テナントのリージョン間移行が何をもたらすのかを明確にドキュメント化しています。特定地域に固定されたサービスもあれば、共有グローバルプラットフォームに依存するサービスもあるため、それぞれの状況を記録して透明化する試みが必要になります。

AI機能

AIはデータレジデンシーに、かつてない複雑な課題をもたらしています。大手ソフトウェアベンダーの既存プロダクトには、次々とAI機能が追加されていますが、AIコンポーネントはそれらのプロダクトを支えるプラットフォームのレジデンシーアーキテクチャから独立し、独自に機能している場合がほとんどです

たとえば、CRMは欧州圏内で運用されていても、エンドポイントにサービスを提供するAIモデルは別の場所から機能している場合があります。AI機能は、本体とは別に単独で機能するデータ処理システムと考えるべきです。

ヘルプデスクのサポートチケットをAIで要約するプラットフォームを想像してみてください。顧客データはテナントの選択したリージョンに存在しますが、要約リクエストを処理する推論サービスは別のリージョンに属していたりします。

ドキュメント検索システムにも同じことが言えます。エンベディング、ベクトルデータベース、プロンプト履歴、検索インデックスはすべてデータの集合体であり、それぞれが独自のストレージロケーション、リテンションポリシー、レジデンシー管理を必要とします。個々の詳細を親システム（プロダクト本体）のコンプライアンスチームがまったく把握できていないことは珍しくありません。

開発ツールも同様です。コード完成プラットフォームとAIアシスタントはプロンプト、テレメトリー、インタラクションのログを独自に保持しますが、それらにはソースコード、認証情報、社内アーキテクチャの詳細や顧客情報など、センシティブなデータが含まれている可能性があり、注意が必要です。

さらに、ビジネスインテリジェンスプラットフォームも例外ではありません。AI生成のレポートには数行しか表示されていなくても、基底となる推論リクエストには非常に大きなデータセットが処理されており、レジデンシーも複雑化します。AIガバナンスとレジデンシーガバナンスは近年、密に関わり合うようになっています。

これらのシステムでは次の点を確認すべきです。

推論はどこで行われるのか？プロンプトは保持されるのか？エンベディングの保存先はどこか？モデルのトレーニングにテナントのデータは使用されるのか？処理は特定リージョンに限定可能なのか？

これらの問いに対応するために、推論プロセスはリージョン内に限定し、プロンプトは保持せず、顧客データによるトレーニングを無効にして、アーキテクチャの透明性を明確にしているベンダーもいます。他方で、とにかくデプロイしやすいモデルエンドポイントにプロダクトを接続しているだけのベンダーも少なくありません。

この状況は、社内で開発したAIシステムにも当てはまります。検索拡張生成（RAG）パイプラインも、エンベディングストアも、プロンプトのキャッシュも、ベクトルデータベースやファインチューニングのデータセットに推論ロジックも、すべてデータストアを生成するので、レジデンシーをどうすべきかの決定は避けて通れません。

データ主権の厳しい要件を課されている企業は、直接管理するインフラストラクチャにAIワークロードをデプロイする傾向にあります。それはオンプレミス環境であったり、プライベートクラウドや主権クラウド環境であったりします。背景には、ガバナンス対象のデータにAIモデルをなるべく近く配置するほうが、データが国境を超えないことを証明するよりも簡単だという考え方があります。

バックアップとDR

データレジデンシー問題の隠れた巣窟となっているのは、バックアップ環境です。

本番環境の重要性は誰もが意識するところで、常に監視対象となっていますが、バックアップシステムは往々にして、数年前の設定がそのまま引き継がれ、再検証されていない場合がよくあります。

本番環境のデータは顧客契約に沿って国内保存されているのに、毎晩のバックアップはどこか別のリージョンに保存されているケースが多々あります。たとえば、5、6年前に担当していたセキュリティエンジニアがマイグレーション時にデフォルトのリージョン間レプリケーションをそのまま使用して、それがそのままずっと忘れ去られていたりすることがあります。社内のインフラストラクチャチームにとっては本番環境とバックアップは別物ですが、規制当局は、レジデンシー違反が本番環境かバックアップかなんて気にしません。たとえ、バックアップであってもデータはデータです。

リカバリ用のスタックにもしばしば同じ問題が見られます。イミュータブルリポジトリやWORMストレージ、さらにはスナップショットアーカイブが別の地域に属していたりします。DRレプリカは指定のフェイルオーバーサイトで実行されるのに、ログリテンションプラットフォームが本番環境と別サイトに独立して業務レコードを保持している場合もあります。各レイヤーに独自のレジデンシーが生じてしまうことで、問題が複雑化します。

プライマリーワークロードの実行場所は詳細にドキュメント化しているのに、リカバリコピーの保存先に無頓着な組織が多く、普段何気なく使用しているバックアップアーキテクチャが監査時に突然コンプライアンスの課題として顕在化してしまう話をよく聞きます。

ベンダーサポートも同様に、普段は見過ごされがちです。バックアップベンダーがインシデントのトラブルシューティングを行う際、サポートエンジニアが他国からアクセスすることは珍しくありません。そこでバックアップセットをマウントして調査することが往々にしてありますが、サポートエンジニアはデータレジデンシーに気を配ったりはしません。これは、ごく一般的にサポート業務ですが、規制当局は、データが国境をまたぐ特別なケースと捉えるでしょう。つまり、ストレージの配置場所だけでなく、誰がどこからアクセスするのかも重要なポイントとなります。緻密なデータレジデンシープログラムでは、データをどこに保存するのかと同時に、誰がアクセスどこからアクセスするのかも事前に明確にしておくのが原則とされています。

暗号化と鍵の管理

データレジデンシーの課題の解決策として、暗号化を採用する組織は少なくありません。保存されたデータと移行中のデータの両方を暗号化すれば、不正アクセスからデータを保護できます。ただし、データを暗号化しても、データの保存場所は変わりません。当たり前ですが、マレーシアにあるデータは暗号化しても、そのままマレーシアにあり、データレジデンシーは同じです。暗号化済みのバックアップが他国のサイトにレプリケートされたら、そのデータのロケーションはその国になることにも注意が必要です。

さらに忘れてならないのは、暗号鍵を管理するのは誰か、という点です。プロバイダが管理する暗号化では、暗号鍵はクラウドプラットフォームで生成、管理されます。ユーザーには、高度な暗号化を利用できる利点がありますが、第三者への信頼を大前提としたセキュリティ戦略です。

顧客管理の暗号鍵を使用すれば、セキュリティは高まりますが、鍵は依然としてプロバイダの鍵管理システムインフラストラクチャに属している場合がほとんどです。

このため、厳格な規制の対象となるワークロードには、外部の鍵管理モデルを使用するのがより一般的になっています。BYOK（Bring Your Own Key）を利用することでも制御力は高まりますが、HYOK（Hold Your Own Key）と鍵管理の外部システムを利用して、鍵情報を完全にプロバイダ環境の外で管理する方法もあります。この場合、プロバイダは暗号化されたデータを保管しますが、その復号化に必要な鍵の処理には関わりません。

この違いは、データレジデンシーはともかく、データ主権の有無に影響します。少なくとも、規制当局の見方には大きく影響するはずで、それはすなわちコンプライアンスの強化を意味します。

主権クラウドアーキテクチャと国内クラウドプロバイダおよびデプロイメントモデルを評価する際、最初に調査されるのは、誰が暗号鍵を握っているのかという点です。これに注目しない監査担当者はいません。暗号鍵を管理できるということは、データを実際に使用できることを意味するので、データがどこにあるか以上に重要です。

厳格な要件に対処するためのアーキテクチャオプション

これまで標準的とされてきたクラウドレジデンシー管理を不十分と感じる組織は、今後増え続けるでしょう。

適正なリージョンと契約内容に加え、暗号化も完璧。であっても、法規制や顧客の要件がすべて満たされるとは限りません。

そこで、よく議論されるのが、主権クラウドか、インフラストラクチャの直接管理か、という2つの選択肢です。

主権クラウド

クラウド大手（ハイパースケーラー）は主権の問題を熟知しています。Microsoft、AWS、Googleの各社は、地域的なデータレジデンシーの枠を超えたワークロードのサポートを導入しています。ユーザーのワークロードとハイパースケールプラットフォームの間に運用上および法規制上の分離を確立することが目標で、欧州では、この流れでMicrosoft Cloud for SovereigntyやAWS European Sovereign Cloud、Googleによる主権管理フレームワークなどの取り組みが進んでいます。

同様の取り組みは、パートナーシッププロジェクトとしても進んでおり、たとえば、フランスではThales-GoogleジョイントベンチャーのBleu and S3NSがフランス政府によって推進されています。これは、ハイパースケーラーのテクノロジーとローカル企業の地域に根差したソリューションを組み合わせ、パブリッククラウドデプロイメントでは解決しきれない主権の課題に対応していく試みです。

ここで気を付けなければならないのは、「主権クラウド」という確立されたアーキテクチャが存在するわけではない点です。プロバイダによって捉え方がさまざまで、運用管理の分離に重きを置いているプロバイダもいれば、地域ごとの要件対応に力を入れていたり、暗号鍵のオーナーシップやサポートアクセスの制限を重視していたりするプロバイダもいます。したがって、クラウドプロバイダの主権クラウドサービスを選択する際は、特に解消したいリスクは何なのかを、まず明確にしておく必要があります。

オンプレミス、HCL、ハイブリッドクラウド

ワークロードの種類にもよりますが、一般的に「シンプルイズベスト」はここでも真理であり、データは直接管理するインフラストラクチャにのみ保存するのがもっとも効果的です。

よって、政府、医療機関、金融機関、重要な社会インフラ、防衛関係、その他の厳格な規制の対象となる分野では、オンプレミスデプロイメントが主流です。自分で運営する設備、あるいは責任や条件が明確に定義された設備でデータが管理されている限り、データレジデンシーの課題への対応はおのずと簡素化されます。

データはどこにあるのか？→ このビルの中。誰がアクセスできるのか？→ このアクセス許可リストで定義。バックアップはどこにあるのか？→ このロケーション。と打てば響くような回答が得られます。

だからクラウドは使うな、という意味ではありません。実際、ほとんどの企業や団体はクラウドを利用し続けているし、要はデータの配置次第です。厳格なレジデンシー、主権、ローカリゼーション要件が課されるデータはオンプレミスに置き、比較的センシティブでないワークロードをパブリッククラウドに移行して、スケーラビリティと柔軟性をビジネス価値につなげるやり方が一般的です。これは、「ワークロードはその要件をもっとも満たしやすい場所に置くべし」という、ハイブリッドクラウド戦略の基本原則にも合致します。

このモデルを実践するには、いくつか重要な決まりごとがあります。①データがどこにどのように保存されているのかを完全に可視化する。②クロスボーダーのレプリケーションに頼らない高可用性を実現する。③バックアップとリカバリのワークフローを規定のリージョン内で確立する。④管理者アクセスパスの確実な制御と監査を可能にする。⑤データ主権の要件に則った暗号化と鍵管理アーキテクチャを確保する。

これらを実現する取り組みにおいてしばしば話題にのぼるのが、ハイパーコンバージドインフラストラクチャです。たとえば、StarWind Virtual SANのようなプラットフォームを利用することで、可用性に優れた共有ストレージをローカルサーバーリソースで構築でき、コンピューティング、ストレージ、アベイラビリティサービスを単一の運用環境で実現できます。また、事前構成済みのデプロイメントモデルとしてStarWind HCIアプライアンスを活用しても、同様のアーキテクチャアプローチを統合プラットフォームで実現できます。

データの保存、レプリケーション、リカバリにおいては、外部システムへの依存を減らせば減らすほど、データがどこにあって、誰がアクセスできるのかを把握しやすくなるのは間違いありません。

データレジデンシー戦略の策定

以下のチェックリストは、大概の環境に共通するデータレジデンシー戦略の策定ステップを示すものです。

– データのカタログを作成します（インベントリにないデータにはレジデンシーもありません）。これは、インフラストラクチャチームが実際に管理しているシステムから始めます。データベース、ファイル共有、バックアップ、SaaSプラットフォーム、アナリティクス環境、オブジェクトストレージ、コラボレーションシステム、AIプラットフォームなど、リスク要因になりやすいデータを網羅する必要があります。
– データカタログを分類します。個人情報、金融、医療、公共事業、機密情報、ログ、メタデータなどが考えられます。このカテゴリによって適用すべきルールが決まります。
– フローをマッピングします。本番環境、レプリケーション、バックアップ、DR、モニタリング、サポートアクセス、AI機能、サードパーティとの統合などのフローが考えられます。サポートとAIのフローはドキュメント化が未発達の分野であり、注意が必要です。
– データセットの各コピーに対するレジデンシーを確認します。プライマリー、レプリカ、スナップショット、ログ、バックアップなどがあり、それらがすべて同じリージョンに属することは稀です。
– レジデンシー要件を明確にします。ベンダーは、特定のリージョンや運用上の制約があれば、できる限り明確にしておく必要があります。
– 暗号鍵の管理アーキテクチャを決定します。ユーザー管理、BYOK、HYOKなど、ワークロードの種類ごとにその必要性を明確にしておきます。
– リージョンごとにDRプロセスをテストします。リストアを実行した後、データが規定のリージョンにリストアされることを確認します（リストア後にレジデンシーが変わらないようにします）。レジデンシー問題は当局による監査で判明する前に、テストで見つけておかなければなりません。

クラウドベンダーやSaaSベンダーに確認すべきこと

クラウドベンダーやSaaSベンダーと契約する際、確認しておくべきことは山ほどあります。決してベンダーを疑っているわけではなく、きっとこういうことだろうと、確認せずに決めつけることがとても危険だからです。

基本的なことでも確認は必要です。たとえば、プライマリーワークロードはどこに保存されるのか？バックアップはどこに保存されるのか？ログは、メタデータは、テレメトリー、DRコピーはどこに保存されるのか？を明確にしておくべきです。

基本を確認したら、データ主権の詳細を明らかにします。プロバイダは法的にどこの地域に属するのか？米国クラウド法など、領域を超えた法適用の影響を受けるのか？親会社はどうか？サポート担当者は顧客データにアクセスするのか？アクセスするならどこから？などを確認します。

AIを活用したプロダクトに関しても、訊いておくべきことがあります。推論はどこで実行されるのか？プロンプトは保存されるのか？プロンプトや顧客データはモデルのトレーニングに使用されるのか？エンベディングやベクトルインデックスは保存されるのか？ AIの処理は特定リージョンに限定されるのか、あるいはロードに応じてモデルエンドポイントが移り変わるのか？などです。

最後に、暗号化について訊くのも忘れないでください。顧客管理の暗号鍵はサポートされるのか？ BYOKは利用可能か？外部の鍵管理はサポートされるのか？顧客管理の暗号鍵で保護できるのはプラットフォームのどのレイヤーか？などの確認が必要です。

まとめ

データレジデンシーは、構築済みのアーキテクチャの場所を確認して済む問題ではありません。そもそも、構築後にどこにあるのかを確認するのではなく、先にレジデンシーを確定した後でアーキテクチャの構築を開始すべきです。それを怠ると、あとで緊急の移行が必要になり、余計な費用が嵩む可能性があります。ベンダーとの契約前にデータフローをあらかじめマッピングして、緊急で移行しなければならないような事態を防止するのが正しいやり方です。

データレジデンシーの問題は、まず本番環境のデータに関わるシステムから整理します。本番環境のデータベースにとどまらず、バックアップ、ログ、AI機能、SaaS統合などのレジデンシーを一つひとつ確認していきましょう。

2026年の今、問われるべきはデータベースがどこにあるかといったレベルの問題ではなく、エンベディングや推論プロセスのログが最終的にどこに行く着くのか、サードパーティのサポートチケットがリージョン内で処理されるのか、といった問題です。1年半もしたら、ローカリゼーションルールは法務上の手続きではなく、エンジニアリング案件になるでしょう。それをインフラストラクチャの制約と捉え、解決策を見い出したチームは、将来スタックの積み替えや緊急のマイグレーションをしなくて済む、生産的なチームとなるはずです。

よくある質問（FAQ）

データレジデンシーとデータ主権の違いは何ですか？

データレジデンシーはデータの物理的な保存場所（地理的な情報）であり、データ主権は国境や所有権にもとづいてデータに適用される法的な権利を指します。データレジデンシーとデータ主権は合致するとは限りません。たとえば、サーバーがフランクフルトにあってEUの管理下に属していても、米国の親会社に所有され、米国クラウド法の適用対象となる場合があります。

データレジデンシーの問題はクラウのドリージョン選択で解決できますか？

プライマリーデータベースに関しては、選択したリージョンがそのままレジデンシーとなるので、答えはYesです。しかし、バックアップ、ログ、メタデータ、分析抽出データ、AIプロセス、カスタマーサポートのモニタリングなどでは、元のリージョンがそのまま引き継がれず、個々に検証が必要になるので、注意が必要です。

データレジデンシーとデータローカリゼーションは同じことを指していますか？

いいえ、データレジデンシーはビジネス上の選択または契約上の取り決めとなるものです。一方、データローカリゼーションは法的な制約で、特定のカテゴリーに属するデータが特定の条件下で国境（行政区域）をまたぐことを禁ずるものです。

AIはデータレジデンシー要件にどう影響しますか？

AIを活用した機能がシステムに組み込まれることで、モニタリングが困難なデータの流れが発生します。プロンプト、エンベディング、推論プロセスのログなどは、往々にしてテナントリージョンの外で処理されます。これは、特別なエンジニアリングによって明示的に回避しない限り、EU AI法やGDPR（一般データ保護規則）などに対する直接のコンプライアンスリスクとなります。

BYOKとHYOKの違いは何ですか？

BYOK（Bring Your Own Key）では、ユーザー管理の暗号鍵をクラウドプロバイダ環境内に保存するので、理論上、クラウドプロバイダはいつでも暗号鍵にアクセスできます。一方、HYOK（Hold Your Own Key）では、ユーザー管理の暗号鍵を、クラウドプロバイダ環境外のユーザー管理のインフラストラクチャに保存します。仮に、クラウドプロバイダが属する国の当局による強制執行によってクラウドプロバイダが暗号の解除を義務付けらるような状況になっても、ユーザーの暗号鍵はその対象外となります。

データレジデンシーの課題は、オンプレミスのインフラストラクチャを使用することで解決できますか？

はい。オンプレミスおよびハイパーコンバージドインフラストラクチャ（HCI）では、データロケーション、管理者アクセス、リカバリプロセスを完全に管理でき、グローバルなパブリッククラウドで発生しがちな法的曖昧さを回避できます。

StarWindのハイパーコンバージドのご利用については、クライムにご相談ください。

関連トピックス:

コメントを残す

この記事のトラックバック用URL

クライム主催セミナー

出展・参加イベント

カテゴリーで絞る

関連リンク

よく読まれている記事

新着記事

Top30タグリスト

メールマガジン登録

最近のコメント