「データを預けても安全か」を 3 つの独立した軸に分解した概念図。① 学習不使用(利用規約が規定)、② 政府アクセス遮断(CLOUD Act・FISA・NSL が規定)、③ 事業者運用アクセス遮断(暗号化・CMK/BYOK・テナント分離が規定)を 3 つの門として並べ、各門は条件次第で閉じうる半開として描き、完全遮断の保証ではないことを示す。

この記事の要点

  1. 「学習に使わない」は「保持しない」でも「誰も見られない」でもありません。学習・政府アクセス・事業者の運用アクセスは、それぞれ別の問いとして切り分けます。
  2. AI や SaaS に客先・自社のデータを預ける前に、リスクを評価したい実務担当者向けです。
  3. 「削除すれば消える」「閉環境なら誰も見られない」という二択ではなく、どの軸が・どの条件で・どこまで遮断されるかを切り分けて、預ける構成(プラン・リージョン・鍵・契約類型)を選べるようになります。
  4. CLOUD Act などの基礎は 米国プロバイダとデータ主権 へ、暗号化・鍵管理の基礎は 保存データの守り方 へ譲り、本記事は「残存」と「越境アクセス」に集中します。

Key Points (for international readers)

  1. "Not used for training" does not mean "not retained" or "no one can see it." Treat training use, government access, and provider operational access as three separate questions.
  2. For practitioners who place customer or business data into AI/cloud services and need to assess the risk first.
  3. Instead of a binary ("delete = gone" / "private enclave = safe"), learn which axis is blocked, under what conditions, and how far — so you can choose plan, region, key management, and contract type deliberately.
  4. The US/EU legal background (CLOUD Act, FISA, GDPR, Schrems II) is the focus of the English edition; basics live in the predecessor article.

執筆時点: 2026-06-22 / 対象法域: 日本(個人情報保護法)を主軸、米国・EU を補助

本記事は教材であり、法的助言ではない

本記事は教材であり法的助言ではありません。各社の保持期間・ZDR の有無や条件・CLOUD Act 等の射程は流動的かつ事案依存です。公開時点の整理にすぎないため、利用前に必ず最新の公式情報と専門家にご確認ください。

前段記事「米国企業にデータを預けるということ」では「取り出しの速さの非対称」を扱いました。本記事はその続編として、明示的に範囲外としていた「削除後の残存」と「マネージド環境での運用アクセス」を扱います。

用語ミニ解説(はじめての方へ):

  • ZDR(Zero Data Retention): 入力・出力を保存しない契約オプション。事前承認制で、対象が限られます。
  • abuse 監視: 不正利用を検知するために、学習や履歴とは別枠でデータを一定期間保持・確認する運用。
  • litigation hold(訴訟保全): 訴訟が予見された段階や裁判所の命令により、通常なら削除されるデータを保全する義務。通常の削除より優先されます。
  • (Clarifying Lawful Overseas Use of Data Act = データの合法的な海外利用を明確化する法律、2018 年成立。"Act" は「法律」): 米国の管轄に服する事業者へ、データの所在が国外でも開示を強制しうる枠組み。
  • BYOK / CMK(Bring Your Own Key / Customer Managed Key): 暗号鍵を顧客側で管理する方式。
  • 個人情報保護法 28 条: 外国にある第三者(国外に所在する事業者など)へ個人データを提供する際のルール(本人同意などが必要)。
  • (Software as a Service): ソフトを手元に置かず、ネット越しにサービスとして使う/提供する形態。
  • (General Data Protection Regulation): EU の一般データ保護規則。EU 域内の個人データの扱いを定めます。

「データを預けても安全か」という問いは、実務では 3 つの独立した問いに分かれます。この 3 つを混ぜると、「学習に使われないから安全」「暗号化しているから政府も見られない」といった誤った安心や、逆に「クラウドに置いた時点で全部筒抜け」という過剰な不安が生まれます。本記事は、この 3 軸を最初に切り分けることから始めます。

「学習に使わない」だけでは安心できない — 3 者分離

データ保持の 3 層を時間軸で示した図。運用保持(ユーザー削除で制御しやすい)、abuse 監視・安全分類の保持(削除や学習除外と独立。API 既定 30 日、フラグ時は最大 2 年)、法的保持(litigation hold)が通常の削除を上書きする様子を、標準の短い段階と延長する上書きの対比で示す。

預けたデータの安全性は、次の 3 つの軸に分けて評価します。

問いおもに規定するもの
① 学習不使用入力をモデルの訓練に使うか利用規約・プラン契約
② 政府アクセス遮断国家が法的経路で取得できるかCLOUD Act・FISA・NSL など
③ 事業者運用アクセス遮断事業者の従業員が平文を見られるか暗号化・CMK/BYOK・テナント分離

API や商用プランでは「学習に使わない」が既定になりつつありますが、これは②③とは別の問題です。学習に使われなくても、データは保持されることがあり、政府が法的経路で取得しうることもあり、事業者の運用担当者が平文を見うることもあります。①の基礎は AI サービスを使う前に読む利用規約 に譲り、本記事は②③に踏み込みます。

さらに、混同されやすい 2 組を分けておきます。1 つは「保持するか」と「学習に使うか」は別だということです。「学習に使わない」と明言する事業者でも、運用や不正利用監視のためにデータを一定期間保持します。もう 1 つは「消えたか」と「誰が見られるか」は別だということです。削除しても即座に物理消去されるとは限らず、保持されている間は②政府・③事業者の射程に入りうるからです。

削除してもすぐには消えない — 保持の 3 層

各社の保持(retention)は単一の「保持期間」ではなく、性質の異なる 3 層が重なっています。まず自分の関心がどの層かを切り分けます。

  • 運用保持: 会話履歴やアプリ状態を、サービス提供のために保持する層。ユーザー削除やプラン設定で制御できることが多い層です。
  • abuse 監視・安全分類の保持: 不正利用検知やポリシー執行のために、ユーザー削除や学習除外とは独立に保持される層。たとえば OpenAI の API は既定で 30 日、Anthropic はフラグが立った場合に入出力を最大 2 年・分類スコアを最大 7 年、Google は Gemini Apps(消費者向け)で人間レビュー済みデータを最大 3 年とされます(いずれも 2026-06 時点の各社公式)。
  • 法的保持(litigation hold): 訴訟の保全命令などにより、通常なら削除されるデータが上書き的に長期保持される層。ユーザー側からは制御できません。

「削除した」と「消えた」の間には段階があります。多くの方が想像する「削除=即消去」は最初の段階にすぎません。ユーザーが削除すると履歴やアカウントからは即座に除去されますが、これは「見えなくなる」であって物理消去ではありません。バックエンドの恒久削除までには時間差があり、OpenAI の ChatGPT は「30 日以内に恒久削除」、Anthropic は「バックエンドから 30 日以内」とされます。一方で、Google や Microsoft の消費者向けサービスの実消去ラグは公式に数値が見当たりません。つまり「30 日」は標準ケースの目安であり、abuse 監視や法的保持が乗ると伸びます。

ZDR(Zero Data Retention)を使えば保持を避けられそうに見えますが、万能ではありません。事前承認制で対象のエンドポイントやプランが限られ、CSAM(児童性的虐待)検出時の保持や、一部の新モデルにかかる安全目的の保持、不正利用判定のスコアなどは ZDR でも残りうるとされます。

保持を最も強く上書きするのが訴訟保全命令です。報道された NYT(ニューヨーク・タイムズ)対 OpenAI の事例では、裁判所が「通常 30 日以内に自動削除される、削除済みの ChatGPT チャットや API のデータまで保全せよ」と求め、Free・Plus・Pro・Team と ZDR なしの API が対象となり、Enterprise・Edu や ZDR 契約下の API は対象外とされました(この保全義務は 2025-09-26 に終了したと OpenAI は公表しています)。ここから言えるのは、上位プランほど保持の上書きを受けにくかったという事実であり、「ZDR や Enterprise なら必ず及ばない」と一般化はできない、ということです。

マネージド閉環境でも事業者は見られるのか

AWS Bedrock・Azure OpenAI Service・GCP Vertex AI のようなマネージド閉環境は、いずれも「顧客の入力をモデル学習に使わない」を契約・規約で明示します。ただし、いずれも「許可または指示があれば例外」という留保が付き、これは①の軸(利用規約)の話です。本節の主題は、学習に使わないとして保持・運用される間に、事業者や政府がアクセスしうるか(②③の軸)です。

ここで効くのが BYOK / CMK(顧客が暗号鍵を管理する方式)です。ただし鍵が守る範囲には限界があります。BYOK/CMK が確実に守るのは主に保存時(at-rest)のデータで、鍵を失効させれば事業者も復号できなくなります。一方で、推論時にデータが平文で処理される領域(LLM は暗号化したままでは推論できず、入力時に平文へ戻す必要がある)、事業者がサービス運用のために復号権限を持つ領域、そして abuse 監視のログは、鍵の射程の外になりうるとされます。GCP は、エンドポイントの一時メモリ上のデータや abuse 監視ログを顧客管理鍵(CMEK)の対象外と明文化しています。Bedrock や Azure OpenAI は推論時の平文可視性を直接明言しておらず、この点は公式情報からは確定できません(本記事では未確認として扱います)。

言い換えると、鍵を顧客が完全に分離して保持する構成(外部鍵管理など)でない限り、暗号化は事業者・政府アクセスへの決定的な遮断にはなりません。逆に、外部鍵で顧客が鍵を握れば、事業者は「技術的に開示できない」と主張しうる余地が生まれます。ただし、平文を必要とする処理(abuse 監視など)には鍵分離も及びません。

政府アクセスの射程はリージョンで決まらない

政府アクセスの射程を決める要因を整理した判定フロー。データの所在(リージョン)ではなく事業者の管轄が第一の決定要因であること、終端は必ず取得ではなく経路ごとの条件に依存する case-by-case であることを示す。下部に FISA 702 は別経路である旨の注記を添える。

「東京リージョンに置けば米政府は手を出せない」「米クラウドに置いたら全部筒抜け」——どちらも単純化しすぎです。CLOUD Act・FISA・NSL の定義と基本構造は 米国プロバイダとデータ主権 に譲り、ここでは射程の決定要因だけを整理します。

一次資料(法文と米司法省の解説文書)から読み取れる第一の決定要因は、データの所在ではなく「事業者の管轄」です。米司法省は「会社が外国に保存することを選んだデータにも例外はない」「米国が会社に対して人的管轄を持たなければ開示は強制できない」と述べています。米国の主要クラウドの提供元は米国法人であるため、人的管轄に服します。したがって、東京リージョンの保存データであっても、事業者の管理下にあれば CLOUD Act などの射程に及びうる、という関係になります。

ただし「及びうる」は「必ず取得される」ではありません。実際の取得には経路ごとの制約があり、通信内容の取得には令状(相当の理由)が必要で、NSL は通信内容を対象にできず、FISA 702 のターゲットは「米国外の非米国人」に限られます(なお FISA 702 の法的根拠は再授権が議会で合意に至らず 2026 年 6 月 12 日に失効しましたが、監視自体は既に有効な外国情報監視裁判所(FISC)の認証に基づき当面——多くの報道では 2027 年 3 月頃まで——継続するとされ、再授権の行方は流動的です。効力の最新状況は利用判断の際にご確認ください)。リージョン選択は保存地を日本に寄せる有効な一手ですが、(i)処理時の越境(デプロイ種別によっては任意の地域で処理されうる)と、(ii)事業者の管轄、の 2 点は別に確認しないと「日本リージョンだから安全」とは言えません。

本記事固有の論点として、この射程は削除後の残存データと閉環境にも当てはまります。ユーザー削除後に残る abuse 監視ログは、事業者が平文で保持・閲覧しうる領域であり、政府アクセスの経路上に残りやすい領域です(ただし、実際に取得されるかは、その内容が通信内容か取引記録かの分類や、令状の要否など経路ごとの条件によって変わります)。閉環境でも、推論時の平文処理や事業者が持つ復号権限が残るため、鍵を顧客が完全分離していない限り暗号化だけでは遮断しきれません。最終的な判断は事案ごとに異なり、弁護士への確認が必要です。

日本の実務 — 個人情報保護法 28 条か、委託か

日本の個人情報保護法における判定フロー。まずクラウド事業者が個人データを取り扱うかを見て、取り扱わなければクラウド例外、取り扱う場合は国内(委託=25 条の監督義務)か外国(28 条)かで分岐し、28 条ルートでは同意要否が同等水準国・基準適合体制などで分かれる流れを示す。

日本法では、米クラウド AI の利用が「個人データの第三者提供」に当たるかを段階的に判定します。「米クラウド=必ず 28 条」とは断定できず、設計次第でクラウド例外にも委託にも 28 条にもなりえます。

  1. まず「取り扱うか」を見る(クラウド例外): 個人情報保護委員会は、判断基準を「保存データに個人データが含まれるか」ではなく「クラウド事業者において個人データを取り扱うこととなっているか」だとしています。契約で「事業者がサーバ上の個人データを取り扱わない」と定め、適切にアクセス制御していれば、提供に当たらず本人同意も委託先監督義務も不要になってしまいます。
  2. 取り扱う場合、国内か外国か(委託か 28 条か): 取り扱う事業者が国内であれば委託(27 条 5 項 1 号)として本人同意が不要になってしまいますが、委託先の監督義務(25 条)はかかります。外国にある第三者であれば 28 条が上書きします。サーバが国内にあっても、外国事業者が取り扱うなら 28 条に該当しうる、とされる点に注意します。
  3. 28 条ルートなら同意要否が分かれる: 本人同意を不要にするルートは、同等水準国(現在は EU と英国。米国は含まれません)への提供、提供先の基準適合体制の整備、法令に基づく場合などです。米クラウド利用では基準適合体制ルートが中心になりますが、この場合は年 1 回程度以上の定期確認などの継続義務がかかります。いずれにも当たらなければ、本人同意と移転先国の制度などの情報提供が必要です。

注意したいのは、クラウド例外に乗って「提供に当たらない」場合でも、安全管理措置と「外的環境の把握」(その外国の制度を把握したうえで必要な措置を講じる義務)は残るということです。「クラウド例外だから何もしなくてよい」ではありません。なお、規約上で監視・分析でき、保守用 ID でアクセスできるクラウド事業者を「委託を受けて取り扱う事業者に該当する」と判断した実例もあります(個人情報保護委員会の 2024-03-25 注意喚起)。

まとめ

「データを預けても安全か」は、学習・政府・事業者の 3 つの問いに分けると見通しがよくなります。学習に使わないことは保持しないことでも、誰にも見られないことでもありません。削除しても abuse 監視や法的保持の層は残り、その残存データこそ政府アクセスの対象になりえます。閉環境の鍵管理が守るのは主に保存時で、推論時の平文や監視ログには届きにくく、リージョン選択は保存地を寄せても事業者の管轄は変えません。日本法では「米クラウド=必ず 28 条」ではなく、取り扱うか・国内か外国か、の 2 段階で判定します。大事なのは、どの軸が・どの条件で・どこまで遮断されるかを切り分け、プラン・鍵・リージョン・契約類型を選ぶことです。個別の適否は、必ず一次資料と専門家でご確認ください。

預ける前後に確認する項目を、コピーして使える形でまとめます。

text
[預ける前]
□ 預けるデータに個人データが含まれるか棚卸しし、クラウド例外 / 委託 / 28条 のどれに当たるか判定したか
□ 28条ルートなら、同等水準国 / 基準適合体制 / 同意 のどれで根拠づけ、基準適合体制なら継続確認の運用を設計したか
□ プラン(consumer / API / Enterprise)と ZDR の要否を、abuse監視の保持・litigation hold の影響まで含めて選んだか
□ 閉環境なら、BYOK/CMK が守る範囲(保存時)と守らない限界(推論時・監視ログ)を理解して鍵管理方式を決めたか
□ リージョン選択が変えるのは保存地であって事業者の管轄ではない、と社内で共有したか

[預けた後]
□ abuse監視・安全分類の保持はユーザー削除でも残る前提で、保持上限を契約・DPA で確認したか
□ EU の個人データを扱うなら、保存制限・消去権と監視保持の整合(必要・期間限定)を点検したか

[開示請求・政府要求が来たとき]
□ 政府アクセスは事業者の管轄で決まり「およびうる」域だと切り分け、弁護士に確認したか
□ litigation hold が通常の保持・ZDR を上書きしうる前提で、対象プラン・隔離範囲をベンダーに確認したか

References

  • OpenAI: Your data(developers.openai.com/api/docs/guides/your-data、2026-06 時点)
  • Anthropic: Privacy and data retention(privacy.claude.com、2026-06 時点)
  • Google: Gemini Apps Activity / Vertex AI data governance / ZDR(support.google.com・cloud.google.com、2026-06 時点)
  • Microsoft: Microsoft 365 Copilot privacy(learn.microsoft.com、2026-06 時点)
  • AWS Bedrock: Security and privacy(aws.amazon.com/bedrock、2026-06 時点)
  • Azure OpenAI: Data privacy(learn.microsoft.com/azure/ai-foundry、2026-06 時点)
  • 米司法省: CLOUD Act White Paper(18 USC 2713 / 2703)
  • 個人情報保護委員会: 外国第三者提供編ガイドライン / FAQ(ppc.go.jp)
  • EUR-Lex: GDPR 第 5 条・第 17 条 / CJEU C-311/18(Schrems II)
  • 前段記事: 米国企業にデータを預けるということ(/blog/us-data-access-sovereignty-for-builders)