2026年8月19日にOpenAIが公開した「Offering Zero Data Retention for frontier models」は、機密データを扱う企業にとって単なるプライバシー告知ではありません。ポイントは、Zero Data Retention（ZDR）を維持したまま、複数回のやり取りをまたいだ安全監視を可能にするPrivate Safety Processingを予告したことです。これまで『安全性を上げるにはログ保持が増えるのでは』と懸念していた法務・情報システム・開発責任者は、保存場所、暗号鍵、対象エンドポイントの整理を先に進めやすくなりました。
この記事では、公式発表とOpenAI Developer Docsだけを根拠に、何が変わるのか、どのAPI運用ならZDRを維持しやすいのか、逆にどこで保存例外が残るのかを整理します。結論から言うと、Responses APIやChat Completions中心の実装なら設計しやすい一方、ThreadsやAssistantsのようにアプリケーション状態を保持する機能は別管理が必要です。
OpenAIのZero Data Retention発表で何が変わったのか
OpenAIの公式発表では、ZDRは『リクエスト処理後にプロンプトやモデル応答を保持しない』という約束として説明されています。そのうえで今回新しく示されたのが、Private Safety Processingです。これは既存のZDR互換な安全システムが各リクエストを個別に見るのに対し、関連する複数のやり取りから危険兆候を自動検知する仕組みとして案内されています。
重要なのは、『安全性を上げるためにOpenAI担当者が中身を読む』設計ではない点です。公式説明では、OpenAIの担当者は基になるプロンプトや応答へアクセスせず、限定的な安全シグナルだけを受け取る想定です。つまり、社内稟議で問題になりやすい“人手レビュー前提の監視”とは切り分けて説明できます。
Private Safety Processingはどこまで踏み込むのか
公式発表によると、ZDR環境では顧客コンテンツは顧客が管理するインフラに残ります。加えてOpenAIは、OpenAI側のインフラに保存する場合でも、顧客が管理する鍵で暗号化する方式を開発中だと述べています。ここは実務上かなり大きく、保存の有無だけでなく『鍵を誰が握るのか』まで説明できるため、金融・医療・研究開発のような高機密領域で検討材料になります。
ただし、現時点ではPrivate Safety Processingは一般提供ではなく、early customers向けテスト段階です。公開日である2026年8月19日時点ではプレビュー情報として受け止めるべきで、『すべてのZDR顧客がすぐ使える』と断定してはいけません。記事や社内共有では、9月に技術ホワイトペーパー共有予定とあわせて、実装可否は営業・契約・組織設定で確認が必要だと書くのが安全です。
API運用で先に確認したい保存例外と対象範囲
OpenAI Developer Docsでは、ZDRは誰でもセルフサーブで有効化できる機能ではなく、適格な顧客が承認を受けたうえで組織またはプロジェクト単位に設定する仕組みです。設定後はData RetentionタブからZero Data RetentionまたはModified Abuse Monitoringを選べます。ここを知らずに『APIは最初から全部ゼロ保持』と誤解すると、監査説明で食い違いが起きます。
同じドキュメントで特に重要なのがエンドポイント差です。`/v1/responses` と `/v1/chat/completions` はZDR対象ですが、ZDR有効時は `store=true` を送っても常に `false` として扱われます。一方で `/v1/assistants`、`/v1/threads`、`/v1/vector_stores`、`/v1/conversations` などはアプリケーション状態を保持するため、ZDR対象外です。Agent構成を組む際に永続状態が必要なら、その時点で保存責任の線引きをやり直す必要があります。
さらにDocsには、必要に応じてOpenAIがSafety RetentionやEyes Offの条件を適用する可能性も明記されています。たとえば重大リスクの調査・防止が合理的に必要な場合、事前通知付きで保持条件が変わることがあります。通常運用ではZDRでも、例外時の契約文言まで法務と確認しておくと、セキュリティレビューで止まりにくくなります。
導入判断のチェックリスト
導入前は次の順で見ると整理しやすいです。1つ目は、扱うデータが本当にZDRを要求するか。2つ目は、想定アーキテクチャがResponses API中心か、それともThreadsやFilesなど保存を伴う機能を含むか。3つ目は、異常検知時の社内責任分担をどう置くかです。ZDRは『何も考えなくてよい魔法』ではなく、保存しない設計と、例外時の統制設計をセットで作る前提だと理解した方が運用で失敗しません。
日本企業の実務に引き直すと、PoC段階ではResponses APIで閉じる最小構成を先に作り、保存が必要な会話履歴や添付ファイルは自社基盤で管理する設計が始めやすいです。そのうえで、本番化前に『営業経由のZDR承認』『対象エンドポイント一覧』『例外時の保持条件』『社内ログとの突合方法』をチェックリスト化すると、情報システム部門と開発部門の会話が揃います。
よくある誤解Q&A
Q. ZDRを有効にすれば、どのAPIでも保存ゼロになりますか。A. いいえ。公式Docsでは、ResponsesやChat CompletionsのようにZDR対象のAPIがある一方、ThreadsやAssistantsのようにアプリケーション状態を保持する機能は対象外です。設計段階でAPIごとの保存挙動を分けて確認する必要があります。
Q. 今回の発表でPrivate Safety Processingはすぐ本番導入できますか。A. 2026年8月19日の公式発表時点ではearly customers向けのテスト段階です。一般提供や個別契約条件は明記されていないため、導入判断では『提供済み機能』と『近い将来の運用方針』を分けて説明するのが適切です。
Zero Data Retentionの適用可否や、Responses API中心での安全な企業導入設計を整理したい場合は、 お問い合わせください 。要件整理からアーキテクチャ設計、社内説明用の論点整理まで支援できます。
