米国クラウドプロバイダーとの契約に関するデータ保護当局からの照会への対応方法

国内のデータプライバシー監督当局からの書簡は、単なるコンプライアンス上の定型業務ではありません。データ保護当局が米国クラウドプロバイダーとの契約について質問する場合、それは非常に具体的な問いかけです。すなわち、「米国のプラットフォームを通じて処理されるデータが、米国政府によるアクセスからどのように保護されているのか」を問われています。

この照会は、データ主体からの苦情、国家監査プログラム、またはSchrems II判決後の執行動向などがきっかけとなる場合があります。いずれの場合でも、求められるのは同じです—契約だけでは解決できないリスクに対して、組織がどのように対応したかを明確かつ文書化し、技術的に検証可能な形で説明することです。

本記事では、このような照会を受けたDPO（データプライバシー責任者）や法務・コンプライアンスチーム向けに、「評価」「文書化」「是正」「対応」の4段階フレームワークをご紹介します。

エグゼクティブサマリー

主旨：米国クラウドプロバイダーとの契約に関するDPA（データ保護当局）からの照会は、GDPR第V章のコンプライアンス体制、特にTransfer Impact Assessment（TIA）が誠実に実施されているか、補完的対策が技術的に有効か、データ主権に関する文書が精査に耐えうるか、を直接問うものです。顧客が管理する暗号鍵（プロバイダーではなく欧州組織が保持）は、EDPB（欧州データ保護会議）が米国監視法リスクへの対応策として推奨するアーキテクチャ上の対策です。

重要性：GDPR第58条の下で、DPAは広範な調査・是正権限を持ちます。処理の一時的または恒久的な禁止、データフローの停止命令、最大2,000万ユーロまたは全世界年間売上高の4%の罰金を科すことが可能です。2018年以降、GDPR違反による累計罰金額は58億8,000万ユーロを超えています。DPAへの協力不足自体が違反となる場合もあります。どのように対応するか—文書の質、補完的対策の信頼性、是正への積極性—が結果に大きく影響します。

5つの重要なポイント

1. DPAが本当に何を問うているのかを理解してから回答する。多くの照会は一つの問いに集約されます：「プロバイダーが処理データの平文に技術的アクセスを持っているか？」それ以外—SCC、TIA、DPFへの依拠—はその答えのための背景情報です。
2. EUデータセンターの所在は防御策にならない。CLOUD Actはデータの所在地ではなく、プロバイダーの管理権限に基づいて適用されます。米国企業がEUインフラを運用していても、そこに保存されたデータの所有・管理権は米国企業にあります。欧州各国のDPAはこの違いを十分に認識しており、回答でも直接的な対応を求められます。
3. EU-USデータプライバシーフレームワークはCLOUD Actリスクを解消しない。DPFは認証済み米国企業のデータ移転ルールを規定しますが、CLOUD ActやFISA第702条の要求を防ぐものではありません。DPF依存が主な対策である場合、その理由説明が求められますが、説得力のある説明は困難です。
4. 不十分なTransfer Impact Assessmentは悪化要因となる。CLOUD Actリスクを認識しつつ、契約上の措置のみでリスクが緩和されたと結論付けたTIAは、コンプライアンスプロセスが誠実に実施されていない可能性を示唆します—単に結論が誤っているだけではありません。
5. 回答前に是正措置を講じることで立場が大きく強化される。是正計画がすでに進行中で、顧客管理型暗号化の導入証拠がある場合、DPAとの対話は、問題となっているアーキテクチャに依存し続けている場合とは根本的に異なります。

執行の背景：なぜDPAがこの質問をするのか

米国クラウドプロバイダーとの契約に関するDPA照会は、突然現れたものではありません。これは、2020年7月のCJEU（欧州司法裁判所）によるSchrems II判決に端を発し、その後激化してきた一連の法的・政治的動向の帰結です。この背景を理解することで、DPOは照会を単なる事務手続きとしてではなく、正確に位置付けて対応できます。

法的背景：Schrems II、CLOUD Act、DPFの脆弱性

Schrems II判決によりEU-USプライバシーシールドは無効となり、標準契約条項（SCC）は米国法がその有効性を損なう場合、補完的対策が必要であることが確認されました。EDPBの「勧告01/2020」では、米国プロバイダーが暗号化されていないデータや鍵に一切アクセスできない「顧客管理型暗号化」が、米国監視法リスクへの主要な技術的補完策として特定されています。Schrems II以降のTIAでこの結論に至っていない場合、その評価の適切性を再検討すべきです。

2018年制定の米国CLOUD Actは、これに拍車をかけています。米国企業は、保存場所を問わず、正当な米国政府の要求があれば世界中のデータを提出する義務があります。GDPR第48条は、外国裁判所や行政命令のみを根拠とした個人データの第三国移転を禁止しており、CLOUD Actはこの規定が想定する国際協定には該当しません。両制度の対立は構造的なものです。

2023年7月に採択されたEU-USデータプライバシーフレームワーク（DPF）は、CLOUD Actリスクを解消しません。DPFは認証企業のデータ移転ルールを規定しますが、米国政府からの要求を防ぐものではありません。FISA第702条は2024年4月に適用範囲を拡大して再承認されました。2025年初頭には、米国プライバシー・市民的自由監督委員会の5人中3人がトランプ政権により解任され、DPFのインテリジェンス監督体制は機能不全に陥りました。DPFの前身であるSafe HarbourやPrivacy ShieldもCJEUにより無効化されています。DPF認証のみでは十分なリスク緩和策とはなりません。

なぜ執行が強化されているのか

2018年以降、DPAによる執行は段階的に進化してきました。初期はガイダンスや周知が中心でしたが、2022年以降は急激に強化され、2023年にはMetaに対し違法な米国データ移転で初の10億ユーロ超のGDPR罰金が科されました。2024年のDLA Piper GDPR罰金調査では、同年だけで欧州全体で12億ユーロの罰金が記録され、執行はテクノロジー分野だけでなく金融やエネルギー分野にも拡大しています。2018年以降の累計GDPR罰金額は58億8,000万ユーロを超えました。執行はもはや大企業や著名企業だけに限定されていません。DPAは中堅・業界特化型組織にも調査を拡大し、EDPBの「協調執行フレームワーク」を活用して各国の優先事項を調整しています。米国とのデータ移転は、すべての主要欧州管轄で優先的な執行対象となっています。

ステージ1 — 評価：DPAが本当に何を問うているかを理解する

照会を受けた際、最初にすべきは回答案の作成ではありません。何がきっかけで照会が発生したのか、当局が何を求めているのか、自社の現状アーキテクチャがどうなっているのかを正確に把握することです。拙速な回答は、不完全な説明となり、かえって問題を増やすリスクがあります。

照会の種類とその意味を特定する

米国クラウド利用に関するDPA照会は、（1）苦情主導型（データ主体や競合他社による苦情）、（2）監査主導型（業界内の米国クラウド利用に関する国家またはEDPB主導の監査）、（3）インテリジェンス主導型（DPA独自の監視による違反の発見）の3つに分類されます。どのタイプかによって、当局が既に把握している情報や、回答の自由度が異なります。

実際の技術的リスクをマッピングする

回答文作成前に、率直な内部評価を実施してください。中心となる問いはシンプルです：「米国クラウドプロバイダーが処理データの平文に技術的アクセスを持っているか？」「暗号鍵をサービスの一部として管理しているか？」どちらかに該当する場合、理論上ではなく実際にリスクが存在し、その点を説明する必要があります。評価結果は、GDPR第30条記録、既存のTIA、データ移転メカニズムと照合し、対象となるすべての米国プロバイダーとの関係を特定してください。

ステージ2 — 文書化：証拠パッケージを組み立てる

DPAは主張ではなく、文書による証拠を求めます。GDPR第58条の下で、DPAは業務遂行に必要なすべての情報へのアクセスを要求できます。GDPR第5条2項は、説明責任を管理者に明確に課しています—コンプライアンスを「証明」する必要があり、単なる主張では不十分です。

証拠パッケージに必要なもの

中核となる文書は、対象となる米国プロバイダーごとのTransfer Impact Assessmentです。各TIAでは、関連する米国法（CLOUD Act、FISA 702）を特定し、それらがSCCの有効性にどう影響するかを評価し、採用した技術的補完策を明示し、それらが本質的に同等の保護を実現する理由を示す必要があります。顧客管理型暗号化導入前に作成したTIAは、提出前に更新してください—その更新自体が説明責任へのコミットメントの証拠となります。

技術的な補足証拠としては、暗号化の適用範囲や鍵の保管場所を示すアーキテクチャ図、鍵がEEA管轄下にあることを示す鍵管理手順、HSM導入記録、アクセス制御が機能していることを示す監査ログなどが挙げられます。第30条記録、米国プロバイダーとのデータ処理契約、高リスク処理に関するDPIA記録もパッケージに含めてください。

DPOが見落としがちな点として、「鍵を保持している」だけでなく、プロバイダーが運用上、平文データにアクセスできないこと—サポートや診断、サービス経路を含め—を証明する必要があります。プロバイダーのアーキテクチャがこれをサポートしていない場合は、回答提出前に是正段階で対応してください。

ステージ3 — 是正：回答前にギャップを解消する

評価の結果、米国プロバイダーが平文データに技術的アクセスを持っている、または暗号鍵を代理管理している場合、回答前に是正できるか、それともギャップを開示しつつ信頼できる是正計画を提示する必要があります。いずれにせよ、計画のないギャップ説明よりも、是正措置を講じてから回答する方がはるかに有利です。

是正策としての顧客管理型暗号化の導入

EDPBガイダンスが推奨する是正策は「顧客管理型暗号化」です。データは米国プロバイダーのインフラに到達する前に暗号化され、鍵は顧客が独自に生成し、EEA管轄内のハードウェアセキュリティモジュールで保持します。米国プロバイダーは暗号文のみを処理し、鍵を一切保持しないため、CLOUD Act要求があっても可読データは提供できません。このアーキテクチャは契約では解決できない課題を解消します。

ドイツ、フランス、オランダ、英国など欧州各国の組織にとって、顧客管理型暗号化は、プロバイダーごとにインフラを分けずに管轄別の鍵運用を可能にします。これは米国プラットフォームからの移行を意味するものではなく、データが米国インフラに到達する前に暗号化レイヤーを自社管理下に置くことを意味します。セキュアメール、セキュアなファイル共有、セキュアMFT、セキュアなウェブフォームを統合暗号化モデルで実現するプラットフォームなら、既存のクラウド投資を維持しつつ、DPAが問うCLOUD Actギャップを解消できます。是正措置はリアルタイムで文書化し、マイルストーンや責任者を明記することで、DPAが高く評価する説明責任体制を示せます。

ステージ4 — 対応：当局への回答方法

リスク評価、証拠パッケージの組成、是正措置の完了または進行中であれば、回答準備は整っています。どのように対応するか—その姿勢、網羅性、透明性—が結果に大きく影響します。

効果的なDPA回答の原則

指定された期限内に回答してください。DPAへの非協力はGDPR第83条で違反とされています。期限が本当に不十分な場合は、早めに当局へ連絡し、延長理由を説明してください。

ギャップについては率直に説明しましょう。DPAは回避的な回答を見抜いています。過去のTIAで不十分な契約措置に依存していた場合や、プロバイダーが暗号鍵を管理していた場合は、是正措置とともに率直に認めてください。EDPBや各国DPAは、協力姿勢や是正への取り組みを執行判断の軽減要素として一貫して評価しています。

技術アーキテクチャを前面に出しましょう。最も説得力のある証拠は法律論ではなく、「米国プロバイダーが平文データにアクセスできない」ことの明確な技術的証明です。アーキテクチャ図、HSM導入記録、RBACマトリクスなどが説得力ある回答の核心です。法律的な枠組みは技術的証拠の補足であり、代替にはなりません。回答には必ずGDPR第39条に基づきDPOが承認し、DPOがTIAプロセスに十分関与していなかった場合は、その点も説明責任の一環として明記してください。

Kiteworksによる欧州組織のDPA照会対応支援

米国クラウドプロバイダーとの契約に関するDPA照会は、リスクであると同時にチャンスでもあります。誠実な評価、技術的証拠、信頼できる是正体制で対応する組織は、契約上の主張だけで精査に耐えない文書を提出する組織とは根本的に異なる立場に立てます。適切な対応は、率直な評価と、それに見合ったアーキテクチャの整備から始まります。

Kiteworksは、DPA照会への信頼性ある回答を可能にする技術アーキテクチャを提供します。プライベートデータネットワークは、顧客管理型暗号化を採用し、鍵は欧州組織が管轄管理下のHSMで保持し、Kiteworksや米国政府要求からは一切アクセスできません。DPAから「米国プロバイダーが平文データに技術的アクセスを持つか」と問われた際、「いいえ」と即答でき、その証拠となるアーキテクチャ文書もすぐに提示できます。

Kiteworksは、ドイツ、フランス、オランダ、英国、その他欧州管轄での管轄別鍵運用をサポートし、EDPBのSchrems II補完策要件を満たします。包括的な監査ログ、アクセス制御、データガバナンス文書により、DPA回答に必要な証拠パッケージを支援します。

データ主権や米国クラウドプロバイダーに関するDPA照会対応について詳しく知りたい方は、カスタムデモを予約してください。

追加リソース 

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