CLOUD Actについて詳しく解説

※CLOUD Act対策は、情報工学研究所にお任せいただければ短期間で対応が可能です。以下の情報は2025年12月1日現在の、CLOUD Actに関する情報の一例です、結果を保証するものではありません、安全にご不安な場合はぜひご情報工学研究所に相談ください。

1. そもそもCLOUD Actとは何か ― 「場所」ではなく「誰のクラウドか」の法律

CLOUD Act（Clarifying Lawful Overseas Use of Data Act）は、2018年に米国で制定された法律で、米国の捜査当局が、米国の管轄下にあるクラウド事業者などに対して、海外に保存されているデータであっても提出を命じることができると明確化したものです。

ここで重要なのは、

• 「データがどこの国のデータセンターにあるか」ではなく

• 「そのクラウド事業者が米国法の管轄下にあるか（US企業か、USに拠点を持つか）」

で決まる点です。
AWS、Microsoft Azure、Google Cloud などの米国系クラウドだけでなく、米国に子会社や事業拠点を持つ他国企業も対象となり得ると解説されています。

2. 注意点① 「日本リージョンだから安全」は誤解の可能性

日本企業にとって一番の落とし穴は、

「東京リージョンを使っているから、データは日本の法律だけの問題でしょ？」

という誤解です。

CLOUD Actは、**米国企業や米国の管轄下にある事業者が「保有・管理できるデータ」**であれば、
物理的にどこの国に保存されていても、米国当局の要請対象になり得るとされています。

• AWS東京リージョン

• Azure Japan Region

• Google Cloud 東京リージョン

といった「国内データセンター」であっても、提供主体が米国企業である限り、CLOUD Actの射程に入るというのが大枠の理解です。

このため、

• 「データが日本にある＝海外政府からは見られない」は成り立たない

• 「どの国の企業のクラウドを使うか」がリスクの本質

という視点が必要になります。

3. 注意点② 日本企業でも「米国とのつながり」で対象になり得る

CLOUD Actの対象は、単に「米国企業」だけではありません。
AWSの解説などによれば、米国外の企業であっても、米国にオフィス・子会社などを持ち、米国裁判所の管轄に入る場合には、CLOUD Actの適用対象となり得るとされています。

さらに、日本の有識者によるCLOUD Actスタディグループの報告書でも、

• 日本企業であっても「米国政府が管轄権を主張し得る形態」で米国と関係している場合、

• 米国からのデータ提出要請が日本国内の拠点やサーバーに波及する可能性

があると指摘されています。つまり、

• 米国に親会社・子会社・支店がある

• 米国市場向けサービスを展開している

• 米国上場や米国当局に登録している

といった日本企業も、「潜在的にCLOUD Actリスクを抱えている」前提で設計する方が安全です。

4. 注意点③ 個人情報保護法・GDPRなど「他の法令との衝突リスク」

CLOUD Actが厄介なのは、他国のプライバシー法制と「正面衝突」しうる点です。

特にEUでは、GDPR（一般データ保護規則）との関係が大きな論点になっており、
欧州のデータ保護当局や専門家からは、

• 「GDPRに基づく保護義務」
  vs

• 「CLOUD Actに基づく米国当局への協力義務」

という相反する命令に企業が挟まれるリスクが指摘されています。

日本でも、個人情報保護法（APPI）や、業種ごとの守秘義務規制（医療・金融・通信など）があります。
たとえば：

• 患者データやカルテ

• 金融取引データ

• 通信ログ・通話内容

• 機微な顧客情報、社内不正調査データ

などを米国系クラウドに保存している場合、

「日本法や契約・就業規則に基づき秘匿すべき情報」
と
「CLOUD Actに基づく開示請求」

が同時に成立し得るという点が最も大きな注意点です。

このような「法の衝突」にどう対応するかは高度な法的判断が必要であり、
自社だけで判断せず、専門家の関与を前提に体制やルールを設計する必要があります。

5. 注意点④ 利用者・顧客に知らされない可能性（秘密保持命令）

CLOUD Actにおける捜査協力要請には、しばしば**「通知禁止（gag order）」**が付くとされています。

これは、

• クラウド事業者（や企業）が

• 利用者や顧客に対して

• 「あなたのデータが捜査当局に開示されました」と知らせることを禁止する命令

です。

このため、日本企業としては、

• 自社が米国当局からの要請を受けたかどうか

• どの顧客の、どのデータが対象になったか

を、顧客に一切知らせられない状況に置かれる可能性があります。

これは、

• 顧客との秘密保持契約（NDA）

• 取引先とのコンプライアンス条項

• 社内のプライバシーポリシー

と衝突し得るポイントであり、
「通知できない場合がある」ことをどこまで説明しておくかは、契約やプライバシーポリシーの書き方として重要な論点になります。

6. 注意点⑤ 対象となるデータは「本文だけではない」 ― メタデータの危険性

CLOUD Actは、もともと米国の「電子通信プライバシー法（ECPA）」および「ストアド・コミュニケーションズ法（SCA）」を改正する形で導入された法律です。

ここで扱われるのは、

• メールやチャットなどのコンテンツ（本文）

• 送信者・受信者・日時・IPアドレスなどのメタデータ（通信記録）

の両方です。

メタデータは一見「たいした情報ではない」ように感じますが、
実際には、

• 誰と誰がどのタイミングで頻繁にやりとりしているか

• どのIPや端末からアクセスしているか

• 位置情報や利用時間帯のパターン

などから、企業活動や個人の行動パターンがかなり詳細に推測できる点が問題です。

「本文が暗号化されていればOK」
ではなく、
「ログやメタデータをどう扱うか」も含めた設計が必要

というのが、CLOUD Act環境下での大きな注意点になります。

7. 注意点⑥ 「ソブリンクラウド」「国内リージョン」だけでは足りない

近年、EUやAPACを中心に、

• データ主権（Data Sovereignty）

• ソブリンクラウド（Sovereign Cloud）

といったキーワードが注目されています。

しかし、EUの専門家の多くが指摘しているように、

物理的にEU内・自国のデータセンターに置いただけでは、
CLOUD Actによる米国法の射程を完全に排除できない

という現実があります。

日本でも、「ガバメントクラウド」に米国系クラウドが採用されていることから、
行政データをどう守るかが議論されています。

データ主権を確保したい分野（医療・行政・インフラ・防衛など）では、

• 「どこの国の会社が運営するクラウドか」

• 「どこの国の法律が支配するか（支配株主・本社所在地など）」

という**「法的な所在地」**まで含めて検討する必要があります。

8. 注意点⑦ 暗号化していれば安心？ ― 鍵の管理主体がポイント

CLOUD Actと暗号化の関係も、よく誤解されるポイントです。

8-1. 暗号化していても、事業者が鍵を持っていれば…

多くの米国クラウド事業者は、

• データを保存時・通信時に暗号化していますが

• 暗号化キーをクラウド側のHSM等で管理し、必要に応じて復号可能

というモデルを採用しています。

この場合、クラウド事業者が復号鍵を持っているため、
CLOUD Actに基づく要請があれば、

• 「復号済みデータ」

• あるいは「鍵＋暗号化データ」

を提供することが技術的には可能になってしまいます。

8-2. BYOK／クライアントサイド暗号化の限界

一方で、

• BYOK（Bring Your Own Key）／BYOE

• クライアントサイド暗号化

• エンドツーエンド暗号化

といった仕組みを使い、「鍵を自社側で管理する」「サービス提供者が内容を見られない」構成にすることで、
CLOUD Actを含む第三者からのアクセスに対するリスクを軽減しようというアプローチがあります。

ただし、

• 実際にそのサービスが本当に「プロバイダから鍵が見えない構成」になっているか

• メタデータやログが丸裸のまま残っていないか

• 他の法令（暗号化禁止・バックドア要求等）と矛盾しないか

など、設計と検証が難しいのが現実です。
英国がAppleに対して暗号化バックドアを要求し、Appleがサービス提供を一部取りやめた例などからも、
強い暗号化を巡る圧力は続いていることが分かります。

したがって、

「暗号化しているからCLOUD Actを気にしなくてよい」

とは言えず、鍵管理モデルまで含めてアーキテクチャを検討する必要があります。

9. 注意点⑧ 「二国間協定（Executive Agreement）」が増えると何が変わるか

CLOUD Actには、米国と他国との間で

• 「エグゼクティブ・アグリーメント（Executive Agreement）」

と呼ばれる二国間協定を締結する仕組みが用意されています。

すでに、

• 米国―英国間

• 米国―オーストラリア間

では、この種の協定が締結され、発効しています。

これらの協定があると、

• 相手国の捜査当局が、米国プロバイダに直接データを要求しやすくなる

• 従来のMLAT（司法共助条約）よりも迅速に電子証拠を入手できる

といったメリットがある一方で、

「どのような範囲のデータが、どの手続きで、どの国の法の下で扱われるか」

という点が非常に複雑になります。

日本では、CLOUD Actを巡るスタディグループが、

• 仮に日米間でこうした協定を結ぶ場合、

• 憲法・通信の秘密・個人情報保護法等との整合性をどう図るか

について詳細な検討を行っています。

将来、日本が米国と同種の協定を結んだ場合、

• 日米それぞれの当局からのデータ要請が増える可能性

• 日本企業に対する法的義務や説明責任の枠組みが変わる可能性

があるため、動向ウォッチは必須と言えます。

10. 実務で押さえておきたいチェックポイント（まとめ）

最後に、ブログの締めとして、「CLOUD Act時代に日本企業が注意すべき実務ポイント」をチェックリスト形式でまとめます。

10-1. 自社データの「地図」をつくる

• どのクラウド（AWS/Azure/GCP/その他）を使っているか

• どの国のリージョンに、どの種類のデータを置いているか

• メール・グループウェア（Microsoft 365 / Google Workspaceなど）、ログ、バックアップの保存先

を棚卸しし、**「どのデータがCLOUD Actリスクを持っているか」**を見える化します。

10-2. 「米国との関係」を整理する

• 自社・グループ会社の中で米国に拠点を持つ法人はあるか

• 米国上場・米国当局への届出義務などはあるか

• 主要なベンダー・SaaS提供者に米国企業はどれくらい含まれているか

を洗い出し、法的な管轄リスクの範囲を整理します。

10-3. 契約・規程の見直し

• 顧客とのNDA・基本契約書に「外国政府への強制開示の可能性と通知制限」についてどう書くか

• プライバシーポリシーや社内規程に、CLOUD Act等の国外法に基づく開示リスクをどう位置づけるか

• クラウドベンダーとの契約で、

  • 通知義務（政府要請があった場合に知らせてくれるか）

  • 争訟・異議申立てのプロセス

  • データ保管場所・サブプロセッサーの開示

などがどこまで明記されているかを確認します。

10-4. 技術的対策の検討

• 機微性の高いデータは、

  • 国内事業者のクラウド

  • もしくはオンプレミス／プライベートクラウド
    に分離するアーキテクチャを検討する

• 可能な範囲で

  • クライアントサイド暗号化

  • BYOK/BYOE

  • エンドツーエンド暗号化

といった仕組みを導入し、「クラウド事業者が内容を読めない」状態を増やす努力をする（ただし他法令との整合性・運用負荷を要検討）。

10-5. インシデント対応・説明責任の準備

• もしCLOUD Act等に基づく開示要請を受けた場合、

  • 誰が窓口となり、

  • どの弁護士・専門家と連携し、

  • 社内でどうエスカレーションするか

をあらかじめフロー化しておきます。

• 顧客・ステークホルダーへの説明方針（開示可能な範囲での透明性レポート、公表ポリシーなど）も検討しておきましょう。

11. 終わりに ― 「クラウドをやめる」ではなく、「理解したうえで使う」

CLOUD Actは、

• 国境をまたぐ捜査協力を効率化し、

• 国際的な犯罪・テロ対策に寄与する側面

も確かに持っています。

一方で、

• データ主権

• プライバシー

• 企業秘密・知財

• 顧客との信頼関係

に対して無視できないインパクトを与える法律でもあります。

**「クラウドを使うか・使わないか」**ではなく、

「どのクラウドを、どのデータに、どの前提条件で使うのか」

を意識して設計し、
CLOUD Actを含む各国の法制度を正しく理解したうえでクラウドを活用することが、
これからの日本企業に求められるスタンスだと言えるでしょう。

※繰り返しになりますが、本記事はあくまで一般的な情報提供です。
具体的な案件・契約・システム構成に関わる判断は、必ず弁護士や専門家に相談してから行ってください。