OpenAI Zero Data Retentionが示す企業AI安全設計｜プライバシーと不正利用監視をどう両立するか

目次

---

1. 「保存しないAI」は安全監視をどう成立させるのか

機密データを扱う企業にとって、生成AIの利用条件は「性能が高いか」だけでは決まりません。顧客情報、医療情報、金融記録、契約書、研究データ、ソースコードをAIに渡すなら、入力や出力がどこに保存され、誰が見られ、どの目的に使われるのかを説明できなければなりません。一方で、AIが高性能になるほど、不正利用や危険な連続操作をどう検知するかも重要になります。

ここで難しいのは、プライバシーと安全性がしばしば緊張関係に見えることです。安全監視のために会話内容を保持すれば、機密保持の約束が弱くなります。逆に、内容を一切保持しなければ、複数回のやり取りにまたがる悪用や、長いエージェントタスクの逸脱を見落とす可能性があります。企業AIの現場では、この二つをどう両立するかが調達と設計の中心課題になっています。

OpenAIは2026年8月19日、Zero Data Retentionに対応した安全処理として「Private Safety Processing」を発表しました。OpenAIの公式発表によると、Zero Data Retentionは、対象となるAPI顧客について、リクエスト処理後にプロンプトやモデル応答を保持しないという約束です。さらに、顧客コンテンツはOpenAIの担当者がレビューできず、企業顧客データは顧客が明示的に選ばない限りモデル学習に使われないと説明されています。

今回の発表が示しているのは、「ログを長く持つか、何も見ないか」という二択ではありません。顧客の管理下にあるデータを守りながら、関連する複数のやり取りに現れる危険なパターンを自動的に検知し、必要なときだけ限定的な安全信号を返す設計です。企業がAIを本番導入するとき、プライバシー保護と不正利用監視を別々の項目として扱うのではなく、同じアーキテクチャの中で設計する段階に入ったと言えます。

2. OpenAIが発表したPrivate Safety Processingとは

OpenAIが問題意識として挙げているのは、深刻な安全リスクが単発のリクエストだけでは見えにくくなっていることです。たとえば、悪意ある利用者が何度も保護機構を探る場合、複数アカウントで協調する場合、通常の調査に見せかけて段階的に危険な目的へ近づく場合があります。AIエージェントが長いタスクを実行する場面では、利用者の意図から外れた行動を続けるリスクもあります。

従来のZDR対応の安全システムは、個々のやり取りを評価する形が中心でした。Private Safety Processingは、その保護を関連する複数のやり取りへ広げるものです。OpenAIの公式発表では、顧客コンテンツをOpenAI担当者に見せることなく、パターンを検知できるようにすると説明されています。これは、長い文脈を安全に扱うための仕組みであり、単なるログ保存ポリシーの更新ではありません。

保存場所についても、二つの形が示されています。一つは、ZDR導入で顧客コンテンツが顧客の管理するインフラ上に残る形です。もう一つは、OpenAIのインフラに保存する場合でも、顧客が管理する鍵で暗号化する形です。この場合、OpenAI担当者は鍵のコピーを持たず、基礎となるコンテンツへアクセスできないと説明されています。

リスクが検知されたときにOpenAIへ渡るのは、活動の種類を示す狭く定義された信号です。OpenAI担当者がプロンプトや応答本文を受け取るのではなく、安全上の判断に必要なシグナルだけを扱う設計です。顧客側は、自社システム上で利用できる情報を使ってアラートや判断を調査し、必要に応じてOpenAIへ関連情報を共有できます。

現時点では、Private Safety Processingは初期顧客とテスト中とされています。OpenAIは9月に展開を開始し、技術ホワイトペーパーも共有する予定だと説明しています。なお、OpenAIの注記では、CSAMに該当する可能性がある画像については、法令上の報告義務により、ZDR導入でも手動レビューや報告のために保持される例外があるとされています。

3. なぜ企業AIの調達条件が変わるのか

この発表は、AIベンダーのプライバシー機能が「学習に使いません」という表明だけでは足りなくなっていることを示しています。企業が知りたいのは、学習利用の有無に加えて、保持期間、レビュー権限、暗号鍵の管理、監査可能性、安全検知の範囲、例外処理の条件です。ZDRのような条件は、法務やセキュリティ部門だけでなく、AIを業務フローへ組み込む事業部門にも直接関係します。

たとえば、金融機関が顧客相談の要約にAIを使う場面を考えます。入力には口座状況、家族構成、資産情報、病歴に近いセンシティブ情報が混ざるかもしれません。医療機関なら、診療記録や検査結果の要約にAIを使う可能性があります。製造業なら、未公開の設計情報や不具合レポートが渡されます。これらの業務では、AIの出力精度だけでなく、入力が後から誰に見られるのかが導入可否を左右します。

一方で、企業AIは完全に閉じれば安全になるわけでもありません。社内の正規利用者が、権限を超えてデータを集めようとする場合があります。外部からプロンプトインジェクションを受けたエージェントが、本来の目的から外れてツールを呼ぶ可能性もあります。複数回の対話で少しずつ危険な情報を組み立てるケースもあります。単発の入出力だけを見る安全対策では、こうした振る舞いを見落としやすくなります。

つまり、今後の企業AI調達では、プライバシーと安全監視を別々のチェックリストに分けるだけでは不十分です。「内容を誰が見ないか」と「危険なパターンをどう見つけるか」を同時に確認する必要があります。Private Safety Processingのような考え方は、AI基盤を選ぶときの新しい評価軸になるでしょう。

4. ZDR時代の安全設計で見るべき判断軸

第一に、入力と出力の保持条件を具体的に確認することです。「保存しない」という表現だけでは、処理中の一時保存、監査ログ、添付ファイル、画像、ツール実行結果、エラー時のログがどこまで含まれるか分かりません。OpenAIのZDRは、対象API顧客のプロンプトとモデル応答をリクエスト処理後に保持しないという形で説明されています。自社の利用範囲がその対象に入るか、例外が何かを契約と技術文書で確認する必要があります。

第二に、暗号鍵の管理主体を見ることです。OpenAIの発表では、OpenAI提供ストレージを使う場合でも、顧客管理の鍵で暗号化する選択肢を開発していると説明されています。これは、保存場所がクラウドか自社インフラかだけでなく、誰が復号できるかが重要であることを示しています。鍵管理、ローテーション、アクセス監査、緊急時の停止手順まで含めて設計するべきです。

第三に、安全信号の粒度を確認することです。安全のためにすべての会話内容をベンダーへ渡すのか、リスク種別だけを渡すのかでは、プライバシー影響が大きく変わります。Private Safety Processingでは、リスクが検知された場合に、活動の種類を示す限定的な信号がOpenAIへ渡ると説明されています。企業側は、その信号がどのような判断に使われ、どの記録が自社側に残るのかを把握する必要があります。

第四に、顧客側の調査能力を用意することです。OpenAIは、顧客が自社システム上で利用できる情報を使ってアラートや enforcement の判断を調査できると説明しています。これは、ベンダー任せにしない運用を意味します。社内のAI利用ログ、ツール実行履歴、権限変更、承認記録、チケット履歴を突き合わせられなければ、限定的な安全信号を受け取っても原因分析ができません。

第五に、例外処理と法令対応を明文化することです。CSAMのように、法令上の報告義務がある領域では、ZDRでも保持や手動レビューが発生する例外があり得ます。企業は、自社の規制業種、地域、データ分類に応じて、どの例外を許容し、どの利用を禁止するかを先に決める必要があります。

5. 導入時に避けたい落とし穴

一つ目の落とし穴は、ZDRを導入すれば自動的にすべてのリスクが消えると考えることです。ZDRはデータ保持に関する強い条件ですが、社内のアクセス権限、プロンプトへの機密混入、ツール連携の承認、出力の二次利用、ローカルログの保存までは別途設計が必要です。AI基盤側が保持しないとしても、自社アプリや業務システムが全文ログを残していれば、実質的なリスクは残ります。

二つ目は、安全監視を「ベンダーが見てくれるもの」と捉えることです。Private Safety Processingの発想では、OpenAI担当者が本文を読むのではなく、限定的な信号をもとに enforcement を判断します。企業側にも、アラートの背景を調べる運用が必要です。誰が調査し、どのログを見て、どの部署へ連絡し、利用者へどう説明するのかを決めておかなければ、検知だけが宙に浮きます。

三つ目は、エージェント化による連続リスクを軽く見ることです。チャットAIの利用では、一つの質問と一つの回答で完結する場面が多くありました。しかし、AIエージェントは複数のツールを呼び、ファイルを読み、外部システムへ書き込み、長いタスクを続けます。この場合、単発の入力よりも、行動の連鎖をどう監視するかが重要になります。ZDR対応の安全設計も、エージェントの実行履歴と合わせて考える必要があります。

四つ目は、例外を利用者に説明しないことです。「一切保存されません」とだけ伝えたあとで、法令対応や安全上の例外があると分かれば、信頼を損ないます。CSAMのような例外、顧客が任意でOpenAIへ情報共有する場面、社内調査でログを参照する場面は、利用規程や社内ガイドラインに明記するべきです。

五つ目は、調達段階で技術文書を読み込まないことです。ZDR、暗号化、顧客管理鍵、安全信号、保持例外は、営業資料の一文だけでは判断できません。実装予定の範囲、提供開始時期、対象モデル、対象API、地域、監査証跡、サポート体制を確認し、自社のデータ分類と照らし合わせる必要があります。

6. まとめ

OpenAIが2026年8月19日に発表したPrivate Safety Processingは、Zero Data Retentionを前提にしながら、複数のやり取りをまたぐ安全リスクを自動的に検知しようとする取り組みです。対象API顧客のプロンプトや応答を処理後に保持しないというZDRの約束を保ちつつ、顧客管理インフラや顧客管理鍵、限定的な安全信号を組み合わせることで、プライバシーと不正利用監視の両立を目指しています。

企業がここから学ぶべきことは、AIの安全設計を「データを保存するかしないか」の一点に閉じないことです。保持条件、暗号鍵、安全信号、社内調査ログ、ツール実行履歴、法令上の例外をまとめて設計して初めて、機密データを扱うAI基盤として説明できます。

OpenBridgeでは、生成AI、AIエージェント、RAG、MCP、業務システム開発の知見を活かし、企業のAI導入に必要なデータ保護、権限設計、ログ設計、ガバナンス設計を支援しています。高性能なAIを使うほど、プライバシーと安全監視は対立させるのではなく、最初から同じ設計図の中で扱う必要があります。