LLMデータの4要件とは — 「残さない・見せない・学ばせない・出さない」を分けて確認する

用語説明 第8回。第7回で扱った ZDR（ゼロデータ保持） の読者から、こんな質問が続きました。 「ZDRに対応しているベンダーなら、担当者にも見られないし、学習にも使われないし、データは日本から出ない——で合っていますか？」 答えは「いいえ」です。この4つは別々の約束で、片方を満たしてももう片方は満たしません。 このページでは、混同されがちな4つを① 残さない（ZDR）② 見せない（ZOA）③ 学ばせない（学習条項）④ 出さない（データレジデンシー）として分け、 5社の公式ドキュメントの逐語で「どこが既定で、どこが申請制・審査制か」を並べます。契約前のチェックリストとして使える形にしました。

「保存しない」「担当者が見られない」「学習に使わない」「データが域外に出ない」は、4つの別々の約束です。

1社が4つ全部を既定で満たすことは、まずありません。実際、AWS は①と②を「データセキュリティモデル」として説明し、①には保持必須モデルの例外リストを置いています。Microsoft は③を明文化しつつ、①は乱用監視ログを既定で最大30日保持します。Anthropic は④を inference_geo というリクエスト単位の指定で提供し、既定は global です。「4要件のどれが既定で、どれが申請制か」を1つずつ確認する——それがこのページの目的です。

● 最終更新:  |  方針: 各社の公式ドキュメントで逐語を確認できた内容のみ掲載。確認できていない項目は「未確認」と明記します

なぜ「4要件」に分けるのか

理由は単純で、提供元が違えば当たり前のように満たしている要件が違うからです。技術的に見ると、4つは処理の流れの別々の段階に対応しています。

① 残さない / ZDR

Zero Data Retention — 入出力を保存しない

推論が終わったあと、プロンプトと応答を保持しないという約束。保持期間（0日か30日か）の話です。

② 見せない / ZOA

Zero Operator Access — 運用担当者が見られない

保存されていてもいなくても、サービス運営者側の人間が中身にアクセスできないという別の約束。保持の話とは独立です。

③ 学ばせない / 学習条項

Training restriction — モデル改善・訓練に使わない

そのデータを自社モデルの訓練に使わないという契約条項。保存してよいかとは別の条項で、契約書側に書かれます。

④ 出さない / レジデンシー

Data residency — 保存・処理される場所を固定する

どこに保存し、どこで処理するかの話。保存場所と処理場所は別で、エンドポイントやデプロイ種別で決まります。

「ZDR対応」という一文を読んだときに確認すべきは、それが4つのうちのどれを指しているかです。ここを取り違えると、監査や社内規程で「担保できているつもり」の状態が生まれます。

① 残さない — ZDR（ゼロデータ保持）

まず「既定かどうか」を確認します。ZDRは「既定で保存しない」であって「常時有効」ではありません（詳しくは 第7回 ZDR）。

“uses a zero data retention (ZDR) data security model. This means that by default, Amazon Bedrock does not store model inputs or outputs.” — AWS 公式ドキュメント（Amazon Bedrock のデータセキュリティモデル）
  • 既定の保持期間は提供元ごとに違います。AWS は保持モードで選び（none / default / inherit / aws_review）、アカウント単位・プロジェクト単位で設定します（新規プロジェクトは継承が既定）。Microsoft は乱用監視ログを既定で最大30日保持し、申請が承認されると保管なし（modified abuse monitoring）に切り替わります。OpenAI は ZDR が承認制で、既定は最大30日のログです。
  • 例外モデルがあります。AWS は保持が必要なモデルを明示しています。たとえば OpenAI 系モデルは分類器がフラグを立てたトラフィックに限り最大30日、Claude Fable 5 / 5.1 は全トラフィックを30日保持。対象モデルは変わります（2026-09-26 改定）。「ZDRにしたから全部ゼロ」ではありません。
  • 「保存しない」と「ログが出ない」も別です。保持しない構成でも、リクエストのメタデータ（誰がいつ呼んだか）は運用ログとして残ります。中身が残らないことと、呼び出しの記録が残らないことは別問題です。

② 見せない — ZOA（ゼロオペレーターアクセス）

ZDR は「残さない」、ZOA は「人間が見られない」。保存されているかいないかとは独立した約束です。

“zero operator access (ZOA) ... no operators of the service can access model input or output” — AWS 公式ドキュメント（Amazon Bedrock）
  • 「人間が見るかどうか」は乱用監視の設計で決まります。Microsoft の場合、自動レビュー（LLMによる判定）は既定で行われ、データは「システムに保存されず、AIモデルの訓練にも使われない」と説明されています。人間によるレビューは乱用監視システムがフラグを立てた場合のみで、レビューはEEA（欧州経済領域）在住の担当者が行う——という形でアクセス主体を限定しています。
  • 組織向けのオプトアウトがあります。Microsoft の modified abuse monitoring が承認されると保管も人間によるレビューも行われなくなります（自動レビューは残ります）。
  • ZOA の逐語は公開されていない提供元もあります。その場合、「ZDRだから見られない」と推測せず、確認できない項目として扱うのが当サイトの立場です。

→ この「見せない」を深掘りした記事を公開しました: 第9回 ZOA（ゼロオペレーターアクセス）。アクセスを止める3層、CMK／BYOK／HYOKの違い、各社の承認フロー（Customer Lockbox・Access Approval・Key Access Justifications・EKM）と緊急時の例外までを逐語で整理しています。

③ 学ばせない — 学習に使わせない条項

保存するかどうかとは別の条項です。「保存はするが訓練には使わない」は成立します。

“Customer Data and Customer Content is ... NOT used to train any generative AI foundation models without your permission or instruction.” — Microsoft（Azure / Microsoft Foundry のデータ・プライバシー文書）
“By default, Anthropic does not use customer data from commercial deployments to train models.” — Anthropic（地域コンプライアンスの文書）
  • 「提供元に渡らない」も別立てです。Microsoft は「Models sold by Azure のデータは OpenAI や他のモデル提供元から利用可能にならず、提供元が運営するサービスとやり取りしない」と明記しています。再販（Azure経由のDeepSeekなど）を検討するときは、この一文が効きます。
  • 既定で「訓練に使う」サービスもあります。失敗例として分かりやすいのが DeepSeek で、プライバシーポリシーにはサービス改善と「機械学習モデル・アルゴリズムの訓練」のためにデータを使う旨と、オプトアウトの権利が記載されています。ただし API にも同じ条項が適用されるか、オプトアウトの手続きだけで③を満たせるかは、一次情報では確認できていません（個人データを中国国内で処理・保存する旨の記載もあります）。導入時は契約条項の確認が必要です。
  • 「無料プラン」と「API・商用」は別条項です。同じ会社でも、消費者向けUIと API／商用契約では学習条項が違うことがあります。このページの整理はAPI・商用の公式ドキュメントに基づきます。

④ 出さない — データレジデンシー

ここが最も誤解されています。保存場所と処理場所は別で、片方を選んでももう片方は担保されません。

“Data-at-rest (storage) ... remains physically stored in the specific Google Cloud location you chose. This residency is maintained regardless of which endpoint you use.” — Google Cloud（生成AIのデータレジデンシー文書）

つまり Google Cloud では、保存先は選んだロケーション、処理場所は選んだエンドポイントで決まります。そしてエンドポイントには3段階あります。

  • jurisdictional multi-region エンドポイント（US / EU） — 処理もその管轄内に限定されます。域外に出したくない場合はこれ。
  • global エンドポイント — 「任意のGoogleのロケーションで処理される可能性があり、regional isolation や data residency の保証は提供しない」と明記されています。
  • AWS の cross-Region inference — 保存は「Bedrock を使っている AWS リージョンに保存」ですが、推論は geographic プロファイル（US / EU / APAC）か global プロファイルに広がります。global の Data residency は「Any supported AWS commercial Region worldwide」で、AWS 自身が Geographic の利用を推奨しています。
  • Azure はデプロイ種別で決まります。Standard / Regional は顧客が指定した Azure geography 内（運用上、同地理内の別リージョンで処理される場合あり）、DataZone は US / EU / APAC（EU Data Zone は EFTA 諸国を含む）、Global は任意の Azure リージョン。Global Standard を選んだ時点で、処理場所は選べません。
  • Anthropic（Claude API）はリクエスト単位です。inference_geo は us か global の2択で、既定は global。Workspace の geo は us のみで作成後に変更できません。US固定は全トークンが1.1倍。さらに Opus 4.5 / Sonnet 4.5 / Haiku 4.5 以前のモデルに inference_geo を付けると400エラーになります。ここでの inference_geo は Anthropic の API を直接使う場合の話で、Bedrock・Vertex AI・Foundry などパートナー基盤上の地域対応は基盤側の設定として別に確認が必要です。

「リージョンを選べる」＝「データが域外に出ない」ではありません。地理固定のオプションを明示的に選び、契約で裏を取る必要があります。

5社マトリクス — どこが「既定」でどこが「申請制」か

2026-09-29 時点で各社の公式ドキュメントから確認できた範囲です。「申請制」は、契約前に動かない可能性があるという意味です。

5社のデータ保護4要件の比較
提供元① 残さない② 見せない③ 学ばせない④ 出さない
AWS Bedrock 既定は保存なし（保持モードで明示）。保持必須モデルの例外あり ZOA をデータセキュリティモデルとして明記（例外モデルでは人手レビューあり） 既定で訓練に使わない旨を明記 保存は使用リージョン。cross-Region は Geographic を選ぶ
Microsoft Foundry 乱用監視ログを既定で最大30日。modified abuse monitoring の承認で保管なし 自動レビューは既定、人間レビューはフラグ時のみ・EEA在住者 「許可・指示なく基盤モデルの訓練に使わない」＋提供元に渡らない Standard / DataZone / Global の3種。Global は任意リージョンで処理、Standard は指定した geography 内（同地理内の別リージョンあり）
OpenAI API ZDR は申請制（承認＋修正保持契約）。既定は最大30日 公式明記は未確認（各社で仕様変更が多いため、最新の公式ドキュメントで要確認） API / ビジネス利用のデータを訓練に使わない旨を明記 プロジェクト単位で地域を選択。US以外は承認＋修正保持契約、UAEは追加承認
Anthropic ZDR は申請制（on request） 公式明記は未確認（各社で仕様変更が多いため、最新の公式ドキュメントで要確認） 既定で商用データを訓練に使わない inference_geo（＝処理する国を指定する設定。us/global、既定 global）。US固定は1.1倍
Google Cloud 契約・個別設定で対応（一律の既定値は未確認） — AI/ML Privacy Commitment で訓練に使わない旨を説明（要旨・逐語は未取得） ロケーション＋エンドポイント。jurisdictional（US/EU）なら処理も域内

← 横にスクロールできます。空欄は「無い」ではなく「当サイトで一次情報を確認できていない」を意味します。

契約前に確認する5ステップ

  1. 自社で必須の要件を決める。規制業種・顧客契約・社内規程で「絶対に外せない」のは4つのうちどれか。全部必須だと思うと、選定が止まります。
  2. 提供元の「既定」を調べる。この記事の表がその下地です。既定の保持期間（0日 / 30日）と、例外モデルの有無を確認します。
  3. 既定で足りない分を設定・申請する。Bedrock の保持モード、Azure のデプロイ種別、Anthropic の inference_geo、ZDR／modified abuse monitoring の申請。ここで初めて「申請制」の壁に当たります。
  4. 契約書・DPAで固める。申請制の項目は、画面の設定だけでは保証になりません。文書（修正契約・DPA）で受け取るのが原則です。
  5. 記録して、モデル追加時に再確認する。どの要件をどう担保したかを残します。例外モデルのリストは改定される（AWSは2026-09-26に更新）ため、新モデルを足すたびに見直します。担当者交代で最も失われるのがこの記録です。

よくある誤解 3つ

誤解 1

「ZDRなら担当者にも見られない」

ZDRは①、ZOAは②で別の約束です。ZDRを選んでも、サービス運営者側のアクセス可否は別に決まります。

誤解 2

「保存しないから学習にも使われない」

訓練への利用は契約条項（③）で決まります。①が満たされていても③の記載が無ければ、担保したことになりません。

誤解 3

「リージョンを選んだから域外に出ない」

Global系の選択肢（Azure Global、Bedrock global、inference_geo=global）は任意リージョンで処理されます。地理固定のオプションを選ぶ必要があります。

誤解 4

「相乗りしているだけだから安全」

再販経路では、再販元の条項（学習に使わない・提供元に渡さない）が効きます。ただしデプロイ種別とエンドポイント次第で処理場所が変わります（例: Azure経由のDeepSeek）。

よくある質問

「ZDR対応」と書いてあるベンダーなら安心ですか？
まず4要件のどれを指しているかを確認してください。①のみの約束であることが多く、②〜④は別途の確認が必要です。加えて①自体にも例外モデルがあり、対象モデルは改定されます。
リージョン固定はどう選べばいいですか？
処理場所まで固定したいなら、地理を明示するオプションを選びます。Bedrock は Geographic の cross-Region inference、Azure は DataZone / Regional、Anthropic は inference_geo: us、Google Cloud は jurisdictional multi-region（US / EU）エンドポイントです。global 系は「任意のリージョンで処理」と明記されているので、固定には使えません。
無料プランや個人向けアプリでも同じ整理でよいですか？
いいえ。消費者向けUIとAPI・商用契約では条項が違うことが多く、学習条項で特に差が出ます。このページの整理はAPI・商用の公式ドキュメントに基づきます。個人向けプランを使う場合は、そのプランの規約を別途確認してください。
なぜ4つに分ける必要があるのですか？「保存しない」で十分では？
たとえば「保存はするが訓練に使わず、担当者も見られず、処理は国内」という構成は成立しますし、逆に「保存はしないが、提供元に渡って訓練に使われる」構成もあります。監査で問われるのは要件ごとなので、まとめて「ZDR」と呼ぶと説明できなくなります。

出典