2026年10月8日にOpenAIのZDR・Private Safety Processing発表、現行APIガイド、データ管理ガイドを再確認した。ZDRでリクエスト後のプロンプト・応答保持を減らすことと、複数のやり取り・会話・アカウントにまたがる安全監視を行うことは別の設計で、顧客管理ストレージ、権限、鍵、限定的な安全シグナル、適格性、法定保持例外を記録する。2026年9月22日の段階的ロールアウトをすべての顧客への即時提供と読み替えず、検知後のエスカレーションと保持を自社の契約・運用で決める。
生成AIやAIエージェントを全社に広げようとするとき、情報システム部門や法務から必ず出てくる問いがあります。プロンプトや応答のデータは、ベンダー側にどれだけ残るのか。 この問いへの答えとして「ZDR(ゼロデータ保持)に対応しています」という説明を受け取ったとき、それをどこまで安心材料として扱ってよいのでしょうか。
2026年8月19日、OpenAIは「Offering Zero Data Retention for frontier models」と題する発表で、ZDRを維持したまま安全監視を行う「Private Safety Processing」のプレビューを公表しました。公式ページは2026年9月22日にAPI顧客への段階的なロールアウト開始を追記し、現在はAPIガイドで顧客管理ストレージと運用責任を説明しています。この記事では、発表・更新・ガイドを分けて読みます。
30秒で要点
- OpenAIは2026年8月19日、ZDR(ゼロデータ保持)を維持しながら安全監視を行う「Private Safety Processing」のプレビューを発表した
- ZDRは「リクエスト処理後にプロンプトも応答も保持せず、OpenAI従業員によるレビュー対象にもしない」仕組みだが、OpenAI自身が既存のZDR互換の安全システムには限界があると認めている
- 既存の仕組みは各インタラクションを個別に評価するにとどまり、複数のやり取りにまたがって現れるリスク(ガードレールの反復的な探り・複数アカウントをまたぐ連携等)を捉えられない
- 公式ページは2026年9月22日にAPI顧客への段階的ロールアウト開始を更新した。適格性や顧客管理ストレージの要件を確認し、児童性的虐待の疑いがある画像はZDRでも例外的に保持される
表が収まらない場合は、横にスクロールできます
| 用語 | 意味 |
|---|---|
| ZDR(Zero Data Retention・ゼロデータ保持) | リクエスト処理後にプロンプト・応答を保持せず、提供企業の従業員によるレビュー対象にもしない設定 |
| Private Safety Processing | ZDRを維持したまま、複数のやり取りにまたがるリスクを検知しようとする仕組み。OpenAIが2026年8月に発表したプレビュー機能 |
| 単発評価(individual interaction evaluation) | 1回ごとのやり取りだけを見て安全性を判定する方式。複数回にまたがるパターンは対象外になりやすい |
ZDRが解決していたことと、していなかったこと
OpenAIの発表文は、ZDRを「OpenAI does not retain their prompts or model responses after a request is processed. Customer content is not available to OpenAI personnel for review(リクエスト処理後にプロンプトも応答も保持せず、顧客のコンテンツはOpenAI従業員のレビュー対象にもならない)」と定義しています。医療・金融・法務など、機密性の高いデータを扱う企業がAIを導入する際、この設定は重要な前提条件になってきました。
しかし発表文は同時に、既存のZDR互換の安全システムが抱える限界も認めています。これらのシステムは「evaluate each interaction individually(各インタラクションを個別に評価する)」にとどまっており、ガードレールの反復的な探り、複数アカウントをまたぐ連携、エージェントが停止指示を受けた後も動作を続けるといった、複数のやり取りにまたがるパターンとして現れるリスクは、単発評価では捉えられないというのです。
つまり、ZDRが解決していたのは「データがどこかに残ってしまう」という懸念であり、「不正なパターンを見つける」という別の課題は、そのままでは解決されていなかったことになります。この2つを一つの言葉(「ZDR対応」)で語ってしまうと、片方が解決すればもう片方も解決したかのような誤解が生まれます。
なぜ「ZDR対応」を万能の安心材料にしてしまうのか
ベンダーから「ZDRに対応しています」という説明を受けたとき、多くの担当者はそれを「セキュリティ・安全性への配慮が行き届いている」という総合的な評価として受け取りがちです。これは、ZDRという一つの技術的な設定が、データ保護という分かりやすい価値と強く結びついているために起きやすい誤解です。
しかし今回のOpenAIの発表そのものが、「ZDRを実現すること」と「安全監視を機能させること」が別々の課題であり、両立させるために新たな仕組み(Private Safety Processing)が必要だったことを示しています。ベンダー自身が両立の難しさを認めて新機能を発表しているという事実は、逆説的に「ZDR対応」という言葉だけでは安全監視の水準を保証できないことの裏付けでもあります。
「安全監視の単位」が変わるという論点
Private Safety Processingが目指しているのは、単発のやり取りではなく、複数のやり取りにまたがるパターンとしてリスクを検知することです。これは、安全監視の単位が「1回のやり取り」から「一連のやり取り」へ移ることを意味します。
ここで見落としてはいけないのは、この仕組みがリスクを検知したとして、検知結果をどう解釈し、どう対応するかという責任がどこにあるかという点です。OpenAIの発表は、Private Safety Processingがリスクを検知する仕組みであることは説明していますが、検知後の判断・対応をOpenAI側がどこまで担うのかについては、本記事が確認できた発表文の範囲では明確ではありません。ZDRを維持するという制約のもとで安全監視を行うということは、監視結果の解釈と運用の負荷が、これまで以上に顧客側に戻ってくる可能性がある設計だと理解しておく必要があります。これは単純な「改善」ではなく、トレードオフとして捉えるべき変化です。
「もう使える」と一括りにしないための時期と要件の確認
OpenAIの公式ページは2026年9月22日の更新で、Private Safety ProcessingをAPI顧客へ段階的にロールアウトしていると案内しています。発表時点の「in September」という見込みから、実際の提供開始を示す更新へ進んだ点は反映する必要があります。一方、APIガイドは顧客管理ストレージ、権限、暗号鍵の認可、適格なエンドポイントなどの要件を示しています。段階的ロールアウトは、すべての組織が直ちに利用できることや、検知効果が第三者検証済みであることを意味しません。契約・地域・エンドポイント・自社の運用担当を確認してから導入計画へ組み込みます。
ZDRの例外——法律で保持が義務づけられるケース
発表文の脚注には、米国法(18 U.S.C. §2258A)により、児童性的虐待の疑いがある画像(CSAM)についてはZDRデプロイであっても手動レビューと報告のために保持し続けると明記されています。ZDRは「無条件・無例外でデータを消す」という意味ではなく、法律で保持が義務づけられる領域では例外が設けられているという点も、前提として押さえておく必要があります。
確かなことと、まだ確かではないこと
確かなこと: OpenAIが2026年8月19日にZDR対応のPrivate Safety Processingをプレビューし、9月22日にAPI顧客への段階的ロールアウト開始を更新したこと。既存のZDR互換の安全システムが各インタラクションを個別に評価する限界、顧客管理ストレージと運用要件、CSAMの例外保持が公式資料に記載されていること。
まだ確かではないこと: 自社組織が段階的ロールアウトの対象になる時期、複数のやり取りにまたがる検知が実際にどの程度有効か、検知後の業務判断・エスカレーションを誰が担うかです。これらは契約、エンドポイント、設定、顧客側の運用によって変わり、公式の説明だけでは自社の効果を保証しません。
自分でも試せる、最小の検証
自社が検討・導入しているAIベンダーに対して、「ZDR対応」という説明を受けたら、それに続けて「では、複数回のやり取りにまたがる不正利用は、どの仕組みで検知していますか」と一段掘り下げて質問してみてください。この問いに具体的な仕組みで答えられるかどうかが、ZDR対応という言葉の中身を見極める最小限のチェックになります。
判断軸の提示
ベンダーから「ZDR対応」と説明されたとき、それを安全性全般の保証として受け取らず、「データを保持しないこと」と「不正なパターンを検知すること」という別々の課題として問い直すこと。この2つが両立しているかどうかは、発表内容を鵜呑みにせず、検知後の責任分担まで確認して初めて判断できます。