OpenAIは2026年8月19日、最先端モデル向けに「Private Safety Processing」をプレビューした。これは、Zero Data Retention（ZDR）を選んだ顧客のコンテンツをOpenAIの担当者へ渡さず、関連する複数の対話をまたいで悪用パターンを検出するための設計である。これまでZDR対応の安全システムは対話を一件ずつ評価していたため、履歴をつなげなければ見えにくい挙動をどう扱うかが残っていた。安全監視と保存方針が衝突する場面で、OpenAIは原文ではなく限定的な安全シグナルを返す方式を提示した。
Private Safety Processingは、早期顧客とテストしているプレビュー段階にある。OpenAIは2026年9月に段階導入を始め、技術白書も公開する計画だ。全顧客がすぐ使える一般提供でも、完成した独立監査済みの仕組みでもない。その前提を置いたうえで、この発表は企業がZDRをどう監査するかを変える可能性がある。
単発評価では追えない悪用パターン
最先端モデルが長時間のエージェント作業を担うようになると、有害な要求は一回のプロンプトだけでは判定しにくくなる。OpenAIが例に挙げたのは、停止命令の後も動作を続ける挙動、複数アカウントに分けた探査、研究を装った連続要求である。いずれも一つの対話だけを切り出せば、直ちに危険と決めにくい。関連する履歴の組み合わせに、活動の意図が現れる場合がある。
現行のZDR対応安全システムは、各対話を独立して評価する。顧客コンテンツを悪用監視ログから除くというZDRの要件を守るには、OpenAI側へ会話履歴を集めない運用が自然だったからだ。しかし、その設計では対話のあいだにまたがる行動を検出する情報も切り離される。Private Safety Processingはこの制約に対し、顧客管理の基盤にコンテンツを残しながら関連した複数対話を評価する方向を示した。
ここでいう「監視」は、OpenAIの担当者が利用者の会話を読めるようにすることとは異なる。自動システムは顧客コンテンツを処理するが、OpenAIへ返すのは活動の類型を示す限定的な安全シグナルだという。原文を見せずに相関を扱えるかが、この設計の中心になる。シグナルがどの程度まで内容を表すのか、別の顧客やアカウントとの関連をどう判断するのかは、まだ公開されていない。
原文を渡さずに警告を返す経路
OpenAIの説明では、ZDRを使う配備で顧客コンテンツは顧客管理の基盤に置かれる。Private Safety Processingがリスクを検出しても、OpenAIの担当者はその顧客コンテンツを受け取らない。代わりに顧客は自社システムの情報を使い、どの警告が出たのか、どの執行判断が必要かを確認する。警告に異議を申し立てるときや、正当な利用を説明するときだけ、必要な情報を顧客が任意で共有できるとしている。
この経路は、顧客が制御する情報とOpenAIに渡る情報を分けるためのものだ。したがって「担当者が原文を受け取らない」ことは、コンテンツが一切処理されないことや、メタデータが存在しないことを意味しない。複数対話のパターンを検出するために自動システムが処理し、その結果として限定された安全シグナルが生成される。企業が確認すべきなのは、処理の有無を一語で問うことではなく、どのデータがどこで処理され、誰にどの情報が戻るのかである。
OpenAIは別の選択肢として、自社基盤に保存したデータを顧客管理鍵で暗号化し、OpenAIの担当者が鍵を持たない方式も開発している。この方式は現行の提供内容ではない。顧客管理の基盤にデータを置くZDR配備と、OpenAI基盤上で顧客管理鍵を使う保存方式を同じものとして扱うと、導入時のデータ経路を取り違えることになる。
安全シグナルによる運用が有効に働くには、顧客側で警告と執行判断の理由を調べられなければならない。OpenAIの担当者に原文を預ける運用より顧客の確認作業が増える可能性はあるが、発表時点で警告の分類、粒度、誤検知への対応手順は示されていない。白書では、顧客が異議申立てに使える情報の範囲も実務上の確認項目となる。
ZDRを三つの約束に分けて読む
OpenAI APIの通常の悪用監視ログには、プロンプト、応答、分類器の出力などが入り得て、既定では最大30日保持される。ZDRとModified Abuse Monitoringを利用するには、事前承認と追加要件の受諾が必要である。対象は無条件の全API顧客ではない。組織単位またはプロジェクト単位で設定する運用でもあり、契約や承認の状態を含めて確認する必要がある。
承認されたZDRでは、悪用監視ログから顧客コンテンツを除外し、Responses APIとChat Completions APIのstoreは常にfalseとして扱われる。これは保持に関する設定である。一方、APIの事業データは既定でモデル学習に使われず、明示的にオプトインした場合だけ共有される。学習に使わないことと、監視ログやアプリケーション状態に何がどれだけ残るかは、別の制御として読むべきだ。
さらに、ZDRは全機能でアプリケーション状態が残らないことを約束する名称ではない。現行のデータ管理文書では、ConversationsとAssistantsの関連APIのほか、Vector StoresやFilesなどもZDR適格外となっている。これらのエンドポイントや機能は状態を保持し得る。ZDRを前提にしたシステムでも、利用するAPI機能によってデータ経路は変わる。
Responses APIにも個別の例外がある。プロンプトキャッシュは暗号化されたkey/value tensorをGPUローカルに最大24時間保持し得る。音声出力のアプリケーション状態は複数ターンの利用に備えて1時間残る場合があり、Background modeではポーリングのために約10分間ディスクへ保存する場合がある。第三者のMCPサーバーや外部サービスに渡ったデータは、OpenAIのZDRではなく相手側の保持方針に従う。
画像とファイル入力には、さらに法定対応の例外がある。OpenAIはCSAM検知のためにそれらを走査し、CSAMの疑いがあると分類された画像は、ZDRでも手動確認と法定報告のために保持されるとしている。企業の監査では、「学習しない」「悪用監視ログに原文を入れない」「OpenAI担当者が原文を受け取らない」を一つの約束にまとめない方がよい。承認状態と利用エンドポイントを確認し、キャッシュや一時状態も調べる。外部連携と法定例外は別枠で点検する必要がある。
Anthropicは30日保持を選んだ
複数リクエストをまたぐ攻撃をどう検出するかは、OpenAIだけが直面する問題ではない。AnthropicはCovered Modelsについて、全トラフィックを30日保持する方針を示している。対象にはClaude Fable 5やMythos 5が含まれ、複数のリクエストにまたがる攻撃やBest-of-N jailbreakを調べるためだという。Covered Modelsを使う場合、従来ZDRだった対象組織も30日保持を有効にする必要がある。
二社の公式方針は同じ課題に別の答えを置く。Anthropicは30日という保持期間を安全監視のために選び、OpenAIはプレビュー中のPrivate Safety Processingで、原文から切り離した限定シグナルによる相関監視を掲げる。これは、安全性の優劣を示す比較ではない。両社が同等の検出力を実証したわけでも、OpenAIがAnthropicを名指しして対抗したわけでもない。
ただし企業の調達基準には、モデル性能や料金に加え、安全監視の設計も入る。長いタスクを扱うモデルほど、単発対話では見えない不正利用への対応が必要になる一方、保持期間や人間が参照できる範囲は、業務データの持ち方に直結する。安全チーム、法務、開発部門は、どの設計がどの用途に使えるのかを比較することになる。
9月の段階導入で白書を待つ項目
OpenAIはPrivate Safety Processingを早期顧客とテストしており、2026年9月に段階導入を始める計画である。発表では技術白書も予告したが、関連対話をどの条件で結び付けるのかは公開されていない。複数アカウントにまたがる探査を検出する設計なら、関連付けの単位と誤った関連付けを避ける仕組みが、顧客のリスク評価を左右する。
もう一つの確認点は、限定的な安全シグナルの内容である。顧客が自社で警告と執行判断を調べるなら、シグナルは利用目的の正当性を説明する手掛かりにも、誤検知を訂正する入口にもならなければならない。反対に、シグナルが詳細すぎれば、原文を渡さないという設計が保護する範囲をどこまで維持できるかが問われる。どこに線を引くかは、実装の説明を待たなければ判断できない。
顧客管理の基盤に置く現行のZDR配備と、開発中の顧客管理鍵方式も区別が必要である。鍵を誰が管理し、障害時や調査時に誰がどの操作を行えるのかが分からなければ、「OpenAIが鍵を持たない」という説明だけで導入判断はできない。外部のMCPサーバーや接続先を含むシステムでは、OpenAIの設定外へ出たデータの保持方針も別途確認しなければならない。
技術白書と段階導入で、関連対話の定義とシグナルの粒度が示され、誤検知時の手順も固まれば、企業は安全監視とZDRを同時に満たせるかを評価できる。鍵管理の方法や第三者による検証も欠かせない。今回のプレビューはその可否を約束した発表ではなく、保持を監視の前提にしないための設計を試す出発点である。
