ZDRとは？データを残さないAI契約の中身と5つの確認点
「顧客情報をAIに入れて大丈夫でしょうか」「ゼロデータ保持を契約すれば、もう誰にも見られないという理解でいいですか」——AIの導入相談を受けていると、この2つはほぼ必ず出てきます。
結論から言うと、ゼロデータ保持（ZDR）が約束しているのは「事業者の人間が中身を見ない・リクエスト処理後に残さない」ことであって、「誰も何も見ない」ことではありません。自動化された安全確認の仕組みは動き続けます。
株式会社Fyveは中小企業のAI導入を支援していますが、この点を曖昧なまま契約してしまうと、社内向けの説明が後から崩れます。この記事では、OpenAIが2026年8月19日にプレビュー発表した新しい仕組みを一次情報から読み解いたうえで、私たちが実際に自社とクライアント環境で確認している5つの点を整理します。
結論：ZDRは「誰も見ない」ではなく「人が中身を見ない」
ZDR（Zero Data Retention＝ゼロデータ保持）は、AI事業者と交わす契約上の取り決めのひとつです。対象となる顧客に対して、事業者が次のことを約束します。
- リクエストの処理が終わった後、入力したプロンプトとモデルの応答を保持しない
- 顧客の内容は、事業者の担当者がレビューできる状態に置かない
- 企業顧客のデータは、明示的に許諾しない限りモデルの学習に使わない
ここで読み違えやすいのが2番目です。「担当者が見られない」と「システムが一切関知しない」は、まったく別のことを言っています。
ZDRが約束していること／していないこと
私が相談の場でよく使う整理はこうです。
- 約束していること：中身を残さない。人が読める場所に置かない。勝手に学習させない
- 約束していないこと：安全性の自動チェックをしないこと。悪用の兆候を機械が判定しないこと
- そもそも守備範囲の外：自社の社員がAIに何を貼り付けるか。自社が繋いだ外部連携がどこまで届くか
3番目が抜け落ちたまま「ZDRを契約したので安全です」と社内に説明してしまうと、事故が起きたときに説明が持ちません。守れる範囲を正確に把握しておくことが、結果として導入を早くします。
この質問が増えているのは、AIの性能とは別の理由から
導入のヒアリングをしていると、「顧客情報や認証情報をAIに渡すのが不安だ」という言葉をそのままの形で聞くことがあります。ツールの性能や費用対効果の話に入る前の段階で、この一点が理由で止まっている会社は少なくありません。
ここで起きているのは、性能の不足ではなく説明の不足です。データがどこに行き、誰が見て、いつ消えるのか。それが分からないから決められない。逆に言えば、この構造さえ整理できれば止まっていた検討が動き出します。実際、私が最初の面談で時間を割くのは機能の紹介ではなく、この部分の整理であることが多いです。
OpenAIが8月19日に発表した「Private Safety Processing」とは
この「中身は見ないが、安全確認はする」という部分に、新しい方式が出てきました。OpenAIが2026年8月19日に公開した「Offering Zero Data Retention for frontier models」という発表の中で、Private Safety Processingという仕組みがプレビューとして示されています。
何をする仕組みなのか
公式の説明を要約すると、次のような設計です。
- これまでのZDR対応の安全確認は、やりとりを1件ずつ独立して評価していた
- Private Safety Processing は、その保護を関連する複数のやりとりにまたがって拡張する
- 横断して見るのは自動化された仕組みだけで、OpenAIの担当者は保持された顧客の内容にアクセスしない
- リスクを検知したとき事業者に返るのは「関与した活動の種別を示す、狭く限定されたシグナル」であり、中身そのものではない
データの置き場所についても2つの形が示されています。ZDRの構成では顧客が管理するインフラ上に内容が留まります。加えて、OpenAI側のストレージに保存する選択肢も開発中で、その場合は顧客が管理する鍵で暗号化されます。公式は「OpenAIの担当者はその鍵の写しを持たないため、元の内容にアクセスできない」と明記しています。
なぜ1件ずつの検査では足りないのか
公式が挙げている理由が、実務の感覚とよく合っています。「最も深刻なリスクは、1回のやりとりの中では必ずしも見えない」——具体例として次の3つが示されています。
- 悪意のある利用者が、安全装置を何度も繰り返し探る
- 複数のアカウントにまたがって協調的に動く
- エージェントによる作業の途中で、停止を指示された後も動き続けるなど、利用者の意図から外れていく
3番目は、AIに連続した作業を任せている人ならすぐ想像がつくはずです。1つひとつの操作はすべて許可された正当なものなのに、積み上がった結果が意図と違う——これは1件ずつの承認では原理的に捕まりません。
いつから使えるのか（ここは正確に）
時期についての公式の記述は控えめです。現時点で確認できるのは次の範囲に留まります。
- 現在は一部の顧客とテスト中（early customers）
- ロールアウトの開始と技術ホワイトペーパーの公開は、2026年9月を予定
- 対象プラン・価格・適用条件についての記載は、この発表時点ではない
つまり、今日この機能を自社で有効化する話ではありません。それでも取り上げる価値があると考えたのは、この発表が「安全監視のために内容の保持を求める」という業界の流れに対する回答になっているからです。公式も「最近の一部の導入では、安全監視のために機微な内容を保持することを顧客に求めていた。多くの組織にとって、それは自らのセキュリティ上の義務と衝突する」と書いています。この論点は、契約更新の時期に必ず自社にも降りてきます。
「1つ1つは正しいのに、結果が違う」——私が踏んだ失敗
先ほどの3番目のリスク、つまり「操作は正当なのに意図から外れる」という型について、私は実際に踏んだことがあります。
あるクライアントのWebサイトを制作していたときのことです。完成前のサイトが検索結果に出てしまわないよう、クローラー向けの設定でインデックスを拒否した状態にしていました。制作作業はAIに任せ、GitHubへのプッシュまで通す運用にしていました。
ところが作業の過程で、AIがその設定をインデックス許可の状態に書き換え、そのままプッシュしてしまいました。プライベートリポジトリでしたが、ホスティングサービスへの自動デプロイが繋がっていたため、変更は本番環境まで通ります。
これは「危険な操作」の集合ではなかった
後から振り返って厄介だと感じたのは、途中のどの操作も、単体で見れば止める理由がなかったことです。
- 設定ファイルを編集する——制作中なので当然、許可している
- 変更をコミットする——これも通常の作業
- リモートにプッシュする——そう運用すると決めていた
- 自動デプロイが走る——そういう構成にしていたのは自分
1件ずつ承認を求められていたとしても、私はすべて「はい」を押していたはずです。問題が形になったのは4つが順につながった後で、その形は個々の操作を見ている限り現れません。
この経験以降、私は取り返しのつかない領域には明示的な禁止（deny）を設定する運用に変えました。判断を都度求めるのではなく、そもそも到達できないようにする、という考え方です。Private Safety Processing の「横断して見なければ分からないものがある」という前提は、この失敗の構造とまったく同じことを指しています。
失敗確率ではなく「戻せるか」で線を引く
権限を切るときの基準として、私は「危ないかどうか」ではなく「戻せるかどうか」を使っています。
- 戻せる操作：ファイルの編集、ローカルでの実行、下書きの作成。間違えても直せる
- 戻せない操作：公開、削除、外部への送信、支払い。実行された瞬間に外の世界が変わる
失敗確率で線を引くと「めったに起きないから許可」という判断になりますが、めったに起きないことは必ず起きます。戻せるかどうかで引けば、判断がぶれません。
「中身を見ずに判定する」は、自社の運用にも作れる
Private Safety Processing の考え方で応用が利くのは、「全部を人が読む」か「何も見ない」かの二択にしないという点です。中身を人に見せないまま、機械が判定して結果だけを渡す。この構造は、規模の小さい会社でも自前で作れます。
機械の検査を先に置き、人の判断を後ろに回す
私は自社の記事や成果物を外部に出す前に、二段構えの確認を通しています。
- 1段目（機械）：取引先の固有名詞・認証情報・内部の情報など、パターンとして機械的に判定できるものを検出する。1件でも見つかれば、その先の工程に進ませない
- 2段目（判断）：機械では決められない領域——たとえば「業種と地域の組み合わせで特定できてしまわないか」といった、文脈を読まないと判断できないもの
この分け方の利点は、疲れない検査を先に置けることです。パターンで決まるものを人が目視で追いかけると、必ずどこかで見落とします。逆に、文脈を読む必要がある判断を機械に任せると、今度は正しいものまで止まって使い物になりません。
迷ったら止める、を初期設定にする
もうひとつ決めているのは、判定できなかったときは通さないという原則です。検査そのものが動かなかった、結果が読み取れなかった——こうした「分からない」状態を、成功として扱わないようにしています。
自動化された仕組みは、壊れても誰も気づきません。人が操作していれば「反応がおかしい」と分かることが、無人で動く仕組みでは静かに通り過ぎてしまいます。だから、判定不能は不合格と同じ扱いにしておく。ここを曖昧にすると、チェックがあること自体が安心材料になって、かえって危険になります。
AIに任せる範囲を広げるほど、この設計の重要度は上がります。公式が「AIがより長く複雑な作業を担うようになるにつれ、正当な活動と悪用を見分けるうえで、広い文脈がますます重要になる」と書いているのは、事業者側から見た同じ話です。
ZDRを契約しても、自社側に残る3つの経路
ここまでは事業者側の話でした。実務でより頻繁に問題になるのは、契約では塞げない自社側の経路です。私が現場で繰り返し見ているのは次の3つです。
1. 人が持ち出す経路
技術的に防げる範囲は年々広がっていますが、思わぬリスクは意外と人為的な場面にあるというのが私の実感です。契約が業務向けプランでも、社員が個人アカウントのAIに資料を貼り付ければ、その契約は一切関係ありません。
だから私はクライアントに対して、技術的な対策と同時に人に関するガイドラインを社内で定めることを必ずお願いしています。ここを事業者の契約で埋めようとすると、必ず破綻します。
2. 連携が広げる経路
MCP（Model Context Protocol）などの外部連携は、AIから社内システムを触れるようにする仕組みです。便利な反面、API経由で情報のやりとりを許可する機能である以上、漏洩のリスクは常にあります。
私が連携を入れるかどうかを決めるときの基準は2つだけです。「本当に必要か」と「水際で対策が取れるか」。そして、使っていない連携を許可のまま残しておくことに、セキュリティ上の利点は一つもありません。使わないものは外す。これだけで攻撃面はかなり減ります。
3. 権限を構造で分けていない経路
介護施設の業務システムを作ったとき、1つの事業所の中で複数の立場の人が同じデータベースに触れる構成になっていました。ここで私は、事務員・管理者向けのアプリと、その他の職員向けのアプリを別々のアプリとして作り、構造的に権限を分ける設計にしました。
1つのアプリの中でアカウントの種類を分ける案もありましたが、ログインや認証の手間が増えて現場で使われなくなると判断して却下しました。実務では、とにかく手間を減らすことが最優先です。運用でカバーする設計は、忙しい現場では必ず形骸化します。
中小企業が今日確認できる5つのチェック
ここまでを、明日の朝に自社で確認できる形に落とし込みます。どれも事業者に問い合わせる前に、自社の管理画面で確かめられる項目です。
1. 契約しているのは個人向けか、業務向けか
同じサービス名でも、プランが変わればデータの扱いが変わります。個人向けプランは初期設定で学習に使われる場合があり、業務向けプランでは使われない、という差が各社にあります。記憶ではなく、請求画面で実際の契約種別を見てください。
2. 「保持しない」設定はどの経路に効いているか
見落としが多いのがここです。API経由の利用には効いていても、ブラウザから使う画面には効いていない、といった食い違いが起こります。経路ごとに確認するのが確実です。社内でどの経路が実際に使われているかの把握が先になります。
3. 使っていない連携を許可のままにしていないか
連携は入れるときには慎重に検討するのに、外すことは誰も考えません。四半期に一度など棚卸しの日を決めて、使っていない許可を落とす運用にしてください。
4. 取り返しのつかない操作に、明示的な禁止をかけているか
公開・削除・外部送信・支払いといった戻せない操作は、明示的に禁止する設定を置きます。私の失敗はここが空いていたために起きました。判断を都度させるのではなく、到達できなくするのが確実です。
5. 連続した作業の結果を、後から一覧で見返せるか
これが最も抜けやすい項目です。1件ずつの承認記録があっても、正しい操作が積み重なって意図から外れたことは、そこからは読み取れません。作業の結果を後からまとめて見返せる形にしておくと、単体では正常に見える逸脱に気づけます。Private Safety Processing が事業者側でやろうとしているのは、まさにこの層の話です。
「渡す前」と「渡した後」でルールを2階建てにする
ここまでの内容を運用の形にまとめると、AI利用のルールは2階建てにするのが分かりやすいと考えています。
1階：渡す前（学習と保持の設定）
プランの選択と設定でほぼ決まる領域です。学習に使われるか、どれだけ保持されるか、どの経路に効くのか。ここは各社のポリシーを読んで判断する話なので、比較して選べば片がつきます。主要なサービスのプラン別の違いは、こちらの記事で表にまとめています。
2階：渡した後（逸脱をどう見つけるか）
こちらは契約では買えない領域です。権限をどう切るか、連携をどこまで許すか、結果をどう見返すか。事業者がどれだけ優れた仕組みを用意しても、自社の設定が緩ければその緩さがそのままAIに渡ります。
開発ツールを使う場面での具体的な設定については、それぞれ次の記事で詳しく扱っています。
社内やクライアントへの説明は「リスク先行」で組む
私がこの話を説明するときは、順番を固定しています。まずどんなリスクが考えられるかを先に説明し、そのうえで可能性を限りなく低くする方法を提示するという順です。
先に「安全です」と言ってしまうと、後からリスクの話が出たときに前言の撤回に見えます。逆にリスクから入ると、対策の一つひとつが前進として受け取られます。そして人為的な部分は技術では防ぎきれないことも、この段階で正直に伝えます。ここを曖昧にしたまま導入すると、事故が起きたときに信頼を失うのは提案した側です。
事業者が判定を誤ったとき、自社は説明できるか
あまり語られませんが、実務で効いてくるのがこの点です。自動化された仕組みが「悪用の疑いあり」と判定したとき、その判断が正しいとは限りません。正当な業務が誤って引っかかることは十分にあり得ます。
今回の発表では、この場合の扱いにも触れられています。顧客は自社が持っている情報を使ってアラートや対応の判断を調査でき、異議を申し立てたい場合や、正当な活動であることを説明したい場合には、顧客が選んで関連情報をOpenAIと共有できる、とされています。共有は自動ではなく顧客の選択である、という書き方になっている点が重要です。
自社側に記録がなければ、説明のしようがない
ここから導かれる実務上の結論は明快です。調査に使える記録を自社が持っていなければ、異議を申し立てる材料がありません。
「誰が」「いつ」「どの用途で」AIを使ったのかが自社側に残っていなければ、事業者から「この種別の活動が検知されました」と言われても、正当な業務だったと示すことができません。中身を渡さない設計であるからこそ、説明の材料は自社側にしか存在しないという構造になります。
これは新しい負担というより、AI利用を業務に組み込むなら遅かれ早かれ必要になるものです。少なくとも、どの部署がどの業務でどのサービスを使っているかの一覧は、早い段階で作っておくことをお勧めします。
よくある質問
ZDRを契約すれば、社内のAI利用ルールは不要になりますか
なりません。ZDRが対象にしているのは事業者側のデータの扱いであり、社員が個人アカウントに何を貼り付けるかは対象外です。むしろ契約を結んだ後こそ、社内ルールの整備が必要になります。
Private Safety Processing は、今すぐ自社で使えますか
2026年8月30日時点では使えません。公式の記述は「一部の顧客とテスト中」で、ロールアウトの開始と技術ホワイトペーパーの公開は9月を予定、とされています。対象プランや価格についての記載はまだありません。詳細は公開される技術ホワイトペーパーで確認してください。
ゼロデータ保持なら、AIに何を入れても問題ないということですか
そうは考えないでください。保持しないことと、渡してよいことは別です。特に顧客から預かった情報については、自社とAI事業者の間の契約だけでなく、その情報の持ち主に対して自社が負っている約束の方が先に来ます。ここは契約書の条項ではなく、業務設計の問題です。
中身が見られないなら、悪用されても分からないのでは
今回の発表は、まさにその懸念に対する回答として出されたものです。自動化された仕組みが横断してパターンを判定し、検知したときには活動の種別を示す限定的なシグナルだけが事業者に渡る、という設計になっています。また顧客の側は、自社が持っている情報でアラートの内容を調べられ、必要であれば自分で選んで情報を共有できる、とされています。
まとめ
ゼロデータ保持は強い約束ですが、万能の盾ではありません。この記事の要点を3つにまとめます。
- ZDRは「人が中身を見ない・残さない」の約束であって、「誰も何も見ない」ではない。自動の安全確認は動き続ける
- 1件ずつの検査では捕まらない失敗がある。すべての操作が正当なのに、積み上がった結果が意図と違う——私自身が踏んだ型がこれ
- 「渡す前」は契約と設定で買えるが、「渡した後」は自社の設計でしか埋まらない。5つの確認点はすべて自社側の項目
まずは自社の契約種別と、使っていない連携の棚卸しから始めてみてください。この2つは今日中に確認できて、効果がはっきりしています。
どこから手を付けるべきか判断が難しい場合や、社内・クライアントへの説明の組み立てで迷われている場合は、株式会社Fyveの専属AI活用顧問サービスでご相談を承っています。自社の状況に合わせて、優先順位から一緒に整理します。
AIを使う会社と、使わない会社。
その差は、開き始めています。
ここ数年でAIは急速に進化し、正しく導入できている企業とそうでない企業とでは、業務効率や人件費に大きな差が生まれ始めています。「AI導入に興味はあるが、実際に何ができて、どこから手をつければいいか分からない」——そんな方は、まずこの無料プレゼントに目を通してみてください。
