データ主権とは「誰がコントロールを握るか」の問題

多くの経営層に「自社の機密データはどこにあるか」と尋ねれば、地域名は答えられます。しかし「誰がそのデータを閲覧・コピー・停止できるか」と聞くと、答えは曖昧になります。このギャップこそがデータ主権の本質であり、規制当局もその点を明確に指摘し始めています。2026年11月5日、スペインのデータ保護機関AEPDとギリシャの同機関が、コントロールを契約条項ではなく技術的事実として扱う安全な処理環境に関する共同ガイドを発表しました。

同じ週、コントロールが紙の上だけに存在した場合のリスクを示す2つの事例がありました。4州の司法長官連合は、監視ソフトが侵入者を記録したにもかかわらず誰にも通知しなかった企業と和解を発表。また、英国では善意で公開されたスプレッドシートに約8,000人分の従業員データが隠れていた事例が明るみに出ました。

本記事では、主権・プライバシー・セキュリティの失敗はすべて同じ根本原因に起因すると主張します。誰かが「コントロールがある」と信じ、誰もそれが機能しているか確認しなかったのです。以下のセクションでは、規制当局の最新の期待、ロケーションとコントロールの違い、サプライヤー集中がもたらすリスク、最近の執行・開示事例の示唆、AIアシスタントが抱える同様の課題、そして「信じる」から「確認する」への定期的なコントロールレビューの重要性について解説します。

主なポイント

1. 規制当局は主権を「コントロール」と定義

AEPDとギリシャ当局のガイドでは、インフラを第三者が提供していても、プロバイダーが実質的かつ有効なコントロールを保持する必要があるとし、契約から技術的事実への転換を示しています。

2. ロケーションは「どこ」、コントロールは「誰」

サーバーが適切な国境内にあっても、鍵の保有者、システム管理者、データにアクセスできる下請け業者が誰かは別問題です。

3. 機能しないコントロールは、ないより悪い

1,330万人に影響した和解事例では、多要素認証の未導入、ファイルの暗号化なし、アラートが設定されていない監視ソフトが問題となりました。

4. データは信頼されたチャネルから流出する

定例の情報公開で、約8,000人分の病欠データが隠れたまま公開され、スプレッドシートの内容を誰も確認していなかったことが原因でした。

5. AIアシスタントも同じギャップを引き継ぐ

銀行規制当局の新たなガイダンスでは、第三者AIに対しても銀行が責任を持つ必要があり、アシスタントはユーザーの権限内で人と同じポリシー下で行動しなければなりません。

欧州ガイドが「本音」を明文化

AEPDとギリシャのデータ保護機関は、Eurostat、スペインデータ総局、イタリアのGarante、英国情報コミッショナー事務局の意見も取り入れてガイドを作成しました。インフラに関する文書としては注目すべき関係者の顔ぶれであり、複数の法域で監督機関が同じ見解を持っていることを示唆しています。

要点は、個人データの管理責任を持つ組織は、第三者がインフラを提供していても、処理環境に対して実質的かつ有効なコントロールを維持しなければならないということです。サプライヤーのWebサイト上の証明書や契約書の条項だけでは不十分です。また、単一プロバイダーへの依存を避けるべきだと警告し、この種の処理にはデータ保護影響評価（DPIA）が原則必須であると指摘しています。

これは責任の所在が変わったことを意味します。これまで多くの組織は、認証取得や標準書類の締結、サプライヤーの証明書をプライバシープログラムに提出することで主権を担保してきました。しかしガイドは、責任ある組織が「自分たちがレバーを握っている」と証明できるかどうかを問うています。誰がアクセス権を持つか、設定を変更できるか、他者の許可なくデータを移動・削除できるかを示せるでしょうか。

この3つすべてに「はい」と答えられる組織は多くありません。多くの場合、レバーはクラウドプロバイダーの管理者やマネージドサービスプロバイダーの技術者、あるいはサプライチェーンのさらに下流の下請け業者が握っています。これは意図の問題ではなく、インフラをサービスとして購入し、その購入自体をコントロールと見なしてしまうことが原因です。

ただし、ガイドは監督機関による安全な処理環境に関する指針であり、それ自体が新たな法律を創設するものではありません。しかし監督機関は、既存法をどう解釈するかをガイドで示しており、その方向性は明確です。責任主体はコントロールを示せなければならず、サプライヤーの約束だけでは証明になりません。

ロケーションは「どこ」、コントロールは「誰」

取締役会レベルでは、3つの用語が混同されがちです。データレジデンシーはデータの保存場所を指し、データローカライゼーションはデータを特定地域内に留めることを義務付ける法律を指します。主権は、誰がそのデータに対して権限を持ち、アクセスを強制できるかを示します。最初の2つを満たしても、3つ目で失敗することがあります。

例えば、自国にあるデータセンターに顧客記録を保存し、その運営を外国プロバイダーの子会社が担う組織を考えてみましょう。レジデンシーとローカライゼーションの要件は満たされますが、もしプロバイダーの本国政府が子会社のデータ開示を強制できる場合、組織のコントロールは条件付きです。これは米国クラウド法を巡る議論の根底にある懸念であり、契約書の郵便番号だけでは十分な証明にならない理由です。

ロケーションをコントロールに変えるには3つの質問が必要です。まず「誰が暗号鍵を保有しているか？」サプライヤーが保有していれば、そのスタッフや法的命令で地理に関係なくデータが解読されます。顧客管理の暗号鍵はその権限を組織に移し、二重暗号化は単一の認証情報で全てが解読されないようにします。

次に「誰が環境を管理しているか？」管理者はほぼ全てを閲覧・変更できるため、管理者の所在地もディスクの所在地と同じくらい重要です。データを地域内に置いても、遠隔地から管理を許していれば、問題の本質は解決されていません。

さらに「どの下請け業者がデータに触れているか？」サプライヤーの保証は、そのサプライヤー自身の下請けには及ばないことがほとんどです。サプライチェーンのどこまでがアクセスできるかを正直に把握するサードパーティリスク管理が重要です。

これらは国境を越えたデータ移転を不可能にするものではありません。標準契約条項などの仕組みはGDPR遵守の正当な手段です。しかし契約条項の強さは、組織がその条件を実際に満たしているか検証できるかどうかにかかっており、結局はコントロールの問題に戻ります。

単一プロバイダーは単一障害点

AEPDガイドは単一プロバイダーへの依存を警告しており、主権圧力が最も高まっている地域に関するKiteworksの調査結果も、その警告が理論ではなく現実的であることを示しています。Kiteworks 2026 データセキュリティ＆コンプライアンスリスク：中東のデータ主権によると、中東の回答者の44%が主権関連のインシデントを経験しており、欧州の32%、カナダの23%より高い割合です。

インシデントの内訳も示唆的です。規制調査が22%、主権関連の侵害が20%、第三者の障害が19%、政府のアクセス要求が15%、無許可の転送が13%を占めています。認知度は74%と高く、93%が主権フレームワークが自社の業務に影響していると回答しています。問題を認識していても防げていません。

これらの多くがサプライヤーに起因していることに注目してください。第三者の障害は明白ですが、政府のアクセス要求や無許可の転送、さらには一部の侵害も、プロバイダーがどこまでアクセスでき、誰がそれを強制できるかに依存しています。集中すれば影響も拡大します。1社がデータ・鍵・管理を握っていれば、1つの障害や法的命令、障害発生で全てが影響を受けます。

同じ調査で、48%が今後地域クラウド利用を増やすと回答し、33%が地政学的リスクを理由に挙げています。地域プロバイダーへの移行は一部リスクを減らしますが、単に依存先を変えるだけなら新たな集中リスクを生むだけです。リスクの「住所」が変わるだけで、コントロールの必要性はなくなりません。

レジリエンスも同じ議論の中にあります。リハーサルされていないエグジットプランは希望に過ぎません。データ・鍵・ポリシーを許容できる期間内に他環境へ移せるか、実際に試したことがあるかが問われます。単一プロバイダー依存を尋ねる監督官は、そのリハーサルの有無を問うているのです。

存在しても機能しないコントロール

最初の失敗パターンがサプライヤーの保証を信じることなら、2つ目は自社ツールをテストせずに信じることです。2026年11月6日、ニューヨーク州司法長官は、コネチカット・ミシガン・ニュージャージー各州と連携し、Perry Johnson & Associatesおよび関連4社との和解を発表しました。最大1,000万ドル（うち30万ドルは確定、970万ドルは条件付き）の和解金で、約1,330万人（ニューヨーク州民は約420万人）が影響を受けました。

事実は明白です。2023年3月、従業員の認証情報を使って侵入者がアクセス。リモートアクセスには多要素認証がなく、保護対象保健情報を含むファイルは暗号化されていませんでした。ある会社のソフトは侵入者の活動を記録していましたが、アラート設定がなく、2か月後にハッカーからの連絡で発覚しました。

この事例では、すべてのコントロールが「存在」していました。ログ記録ソフトも、リモートアクセスも、ファイルも。しかし、それぞれが本来の役割を果たす設定がなされていませんでした。多要素認証は侵入経路に未導入、暗号化はファイルに未実装、監視ツールはアラート未設定でした。

この失敗はコンプライアンスチェックリストには現れにくいものです。チェックリストは「コントロールの有無」を問いますが、和解条件が問うているのは「コントロールが機能しているか」です。必要な改革には、セキュリティプログラムとインシデント対応プロトコル、多要素認証、パスワード管理、暗号化と資産管理、年次HIPAAリスク評価、データの収集・利用・保持・廃棄ポリシーが含まれます。多くは「所有」ではなく「運用」に関するもので、定期的なチェックが必要です。

規制データの場合、リスクはHIPAAセキュリティ規則と継続的なリスク分析の期待に直結します。実務的な教訓は医療分野以外にも及びます。すべてを記録する監査ログも、誰も見なければただの日記です。監視ツールも、出力を受け取って行動する担当者がいて初めてコントロールと呼べます。

誰も見ていなかった扉からデータが流出

すべての損失が攻撃者によるものとは限りません。2025年12月9日、Jackson Lewisの分析で報告された事例では、Royal Cornwallが2023年の情報公開請求に応じてスプレッドシートを公開し、その中に現・元従業員約8,000人分の病欠データが隠れていたことが明らかになりました。問題発覚後、ファイルは削除され、開示ログは一時停止、スプレッドシートはリリース前に完全無効化するルールが導入されました。

注目すべきは、チャネルの「普通さ」です。情報公開は信頼され、日常的かつ承認されたデータ流出経路です。誰も盗もうとしたわけではありません。組織は自分たちのファイルの中身を把握しておらず、機微な情報が隠しシートに残っていたことに気づきませんでした。

これはプライバシー問題であると同時に主権問題でもあります。ファイルの中身を把握できない組織は、その内容がどこに行ったか、誰が読めるか、どの法律が適用されるかも把握できません。データ分類がそれらの問いに答えるコントロールであり、データ損失防止はファイルが外部に出る直前で分類を強制する手段です。どちらも、なくて困るまで地味な存在です。

このケースの解決策はプロセス変更であり、適切な対応でした。しかし、なぜ「隠しシート」ルールがインシデントから学ばれたのかが本質的な問いです。文書を公開したり、パートナーとファイルを共有したり、規制当局にデータを送る組織は、同じリスクに直面しています。テストは簡単ですが、ほとんど実施されていません。過去に外部送信したファイルの代表サンプルを抜き出し、送信者が意図しなかった情報が含まれていないか確認してみてください。

個人情報や健康データの場合、PIIやPHI規制下でその答えは重大な意味を持ちます。ファイル公開時に送信者が「見ること」を前提としたコントロールは習慣に過ぎず、忙しい日には破綻します。

AIアシスタントも同じ課題を引き継ぐ

ここまで述べた内容はすべてAIアシスタントにも当てはまり、銀行監督当局もその点を認識しています。2026年11月5日、American Bankerは、OCCがAIエージェントへの業務委任に関する非拘束ガイダンスを発表したと報じました。ガイダンスは目的・潜在リスク・コントロール・人的監督・レジリエンス・テストの6本柱で構成され、各AIシステムの目的・認可ユーザー・データ権限・権限範囲を文書化することが求められています。銀行は第三者AIに対しても責任を持ち、システムの自律性が高まるほどコントロールの厳格さも求められます。

これを主権の観点で捉え直すと、文書を読みアクションを起こすアシスタントは新たなデータ移動経路であり、触れるものすべてのコントロール課題を引き継ぎます。サプライヤーのインフラ上で動けばサプライヤー問題、分類されていないファイルにアクセスすれば分類ギャップ、誰も見ていないツールでアクティビティを記録すればアラートギャップが生じます。

答えは「同等性」であり、別プログラムを作ることではありません。アシスタントは仕える人の権限内で行動し、人と同じポリシー・ログで管理されるべきです。AI専用のルールセットを作れば、2つのコントロール体系が乖離し、そのギャップが規制当局の指摘対象となります。銀行は第三者AIにも責任を持つため、実際に自社ポリシーを外部アシスタントに適用できるかが問われます。

この理由から、ゼロトラスト・データ交換アプローチが有効です。データが移動するすべての場面で、従業員・パートナー・アシスタントを問わず検証が行われ、組織がポリシーを「借りる」のではなく自ら保持します。AEPDのコントロール要件にも、OCCの委任要件にも同じ原則が適用されます。

主権に関する2つの誤った対応

1つ目の誤答は「すべて自社運用に切り替える」ことです。最も強力なコントロールに思えますが、ごく一部の業務以外では、全環境を自前で構築・運用するには高度なスキルと資金が必要で、多くの組織には維持できません。運用が弱ければ、まさに和解事例で問題となったアラート未設定や暗号化漏れが発生します。コントロールはサーバーの所有とイコールではありません。

2つ目の誤答は「保証を買って終わりにする」ことです。認証・証明・契約条項は価値がありますが、AEPDガイドはそれらが実質的・有効なコントロールの代替にはならないと明言しています。書類だけで止まる組織は「意図の記録」しか残らず、規制当局はさらなる証明を求めます。

重要なのは、インフラの所在に関わらず、組織が「本当に必要なレバー」を握っているかどうかです。鍵の管理、ポリシー設定、ログの閲覧、データ移動の実行ができるか。これら4つの条件は、サプライヤーのインフラ上でも満たせますし、自社インフラでも満たせない場合があります。

失敗パターンに名前を付けましょう。書類だけの対応は「保証シアター」、安心感を集めるだけでコントロールをテストしないプログラムです。未検証のコントロールは「休眠コントロール」、存在するが沈黙しているものです。どちらもよく見られますが、存在確認型の監査では見逃されがちです。

Kiteworksがデータのある場所にコントロールを実現

Kiteworks Control Planeは、上記4つの条件を軸に設計されています。シングルテナントで運用され、顧客ごとにデータと鍵が分離されます。二重暗号化を適用し、ジオフェンシングやデータ主権コントロールにより、組織がコンテンツのアクセス・交換場所を指定できます。ポリシーエンジンと監査ログは、従業員・パートナー・AIエージェントを問わず、機微なコンテンツの移動を一元管理します。

この点が「同等性」の課題を解決します。Kiteworks Secure MCP Serverは、ClaudeやCopilotなどのAIアシスタントがエンタープライズコンテンツを扱う際、仕えるユーザーの権限を継承し、ロールベースや属性ベースのコントロールをすべてのAI操作に適用します。認証情報はOSのキーチェーンで管理され、モデルには一切渡されません。監査ログは組織のSIEMに連携されます。Kiteworks Compliant AIは、AIが規制データにどう触れるかを規制当局に示す必要がある組織向けに、このガバナンスを実現します。

主権要件への対応を進める組織には、データ主権コンプライアンス機能と単一のデータポリシーエンジンが、監督官に示せる具体的な証拠となります。人とAIが同一プレーン上にあるため、ルール変更はすべてのアクターに即時適用され、1つの記録に反映されます。

どんな製品も、次に述べるレビューの必要性をなくすものではありません。しかし、鍵・ポリシー・ログを顧客自身の権限下に置くプラットフォームなら、レビューにきちんと答えられます。

四半期ごとにコントロールをレビュー

四半期ごとのレビューは半日で実施でき、規制当局や和解条件で繰り返し問われる事項に答えることができます。まず鍵から始めましょう。機微データを保持するすべてのシステムをリストアップし、それぞれの暗号鍵の保有者を記録します。「サプライヤー」となっている場合は要改善です。

次にアラートをテストします。多要素認証失敗、大量ダウンロード、新しい国からのログインなど、ツールが提供するとされるコントロールを3つ選び、テスト環境で実際に発生させます。通知を受け取った担当者とその反応速度を記録しましょう。誰も見ていない受信箱に届くアラートは、実質的に「発火していない」状態です。

続いて外部送信ファイルのサンプリングです。直近四半期に組織外へ送信した文書を20件抽出し、隠しシート・メタデータ・個人情報など、送信者が意図しなかった情報が含まれていないか確認します。

最重要サプライヤー2社について、サプライチェーンの下請けや管理者までアクセス権をマッピングし、所定期間内にエグジットできるか確認します。答えが不明ならリハーサルを計画しましょう。

最後にAIアシスタントのレビューです。それぞれについて、どの権限を使い、どのシステムにアクセスし、どこにアクティビティが記録されるかを明記します。人間ユーザーと異なる点があれば、ギャップを埋めてください。

結果を1ページにまとめ、プライバシー・セキュリティ・調達担当者に共有します。90日後に再実施し、比較しましょう。同じ指摘が繰り返される場合は、組織が「問題を記録しているだけ」で「解決していない」サインです。

鍵・ポリシー・ログを自社の権限下に置くことで、主権の説明責任がどう実現できるか、カスタムデモを今すぐご予約ください。

追加リソース

• ブログ記事  
  データ主権：ベストプラクティスか規制要件か？
• eBook  
  データ主権とGDPR
• ブログ記事  
  データ主権の落とし穴に注意
• ブログ記事  
  データ主権ベストプラクティス
• ブログ記事  
  データ主権とGDPR【データセキュリティの理解】