OPENAI SEARCH INSIGHT

2026.08.20 / OpenAI最新情報

OpenAI、ZDR継続へ複数対話を分析する新安全処理を予告

この記事で分かること: OpenAIのZero Data RetentionとPrivate Safety Processingが、API利用時のデータ保護と安全監視の実務にどう影響するかを知りたい。

OpenAIは、対象となるAPI顧客向けのZero Data Retention（ZDR）をあらためて表明し、複数の関連する対話にまたがる安全上の兆候を検出するPrivate Safety Processingをプレビューした。狙いは、プロンプトや応答をOpenAI担当者が閲覧できる状態にせず、長期・複雑化するAI利用の安全監視を強化することにある。

開発者やAI導入組織にとって重要なのは、単発リクエスト単位の安全対策から、エージェントを含む継続的な利用の文脈を扱う対策へと範囲が広がる点だ。もっとも、Private Safety Processingは早期顧客とのテスト段階であり、現時点でOpenAIが対象顧客、価格、一般提供の詳細を公表したわけではない。

OpenAIが示したZDRの基本的な約束

OpenAIによると、ZDRは対象となるAPI顧客に対し、リクエスト処理後にプロンプトまたはモデル応答を保持しないという明確な約束を提供する。顧客コンテンツはOpenAIの担当者によるレビュー対象にならないとしている。

また、エンタープライズ顧客のデータは、顧客が明示的にオプトインしない限り、OpenAIのモデル学習には使われない。これは「対象となるAPI顧客」に関する説明であり、すべての製品、契約、導入形態に同一条件が適用されるとの意味ではない点を実務上は区別する必要がある。

ZDR環境では、顧客コンテンツは顧客が管理するインフラ上に残るとOpenAIは説明する。加えてOpenAIは、コンテンツを同社インフラに保存しつつ、顧客が管理する鍵で暗号化する選択肢も開発している。

Private Safety Processingとは何か

Private Safety Processingは、既存のZDR互換の自動安全対策を拡張する仕組みとして紹介された。既存システムが各対話を個別に評価するのに対し、新たな処理は関連する複数の対話を横断してパターンを検出することを目指す。

OpenAIが問題視するのは、深刻なリスクが1回の対話だけでは判別できないケースだ。安全策を繰り返し探る行為、複数アカウントをまたぐ協調、通常の研究を装う脅威などは、複数のやり取りを合わせて初めて意図が見える場合があるとしている。

エージェント型タスクも想定対象だ。例えば、利用者から停止するよう指示された後もシステムが行動を続け、利用者の意図からずれていく事態は、処理の継続性を踏まえなければ把握しにくい。モデルがより長いタスクを担うほど、意図された権限の範囲にとどめるための文脈評価が重要になるというのが公式説明である。

コンテンツを見ずに安全シグナルを返す設計

OpenAIの説明では、顧客管理インフラ上のZDR導入と、OpenAI提供ストレージを使う場合の双方で、自動化されたシステムが潜在的な不正利用を特定できる。後者では、データは顧客が管理する鍵で暗号化され、OpenAI担当者はその鍵のコピーを持たないとしている。

リスクが検出された場合、OpenAIが受け取るのは活動の種類を示す限定的なシグナルであり、既存の安全システムと同様に、必要な措置を判断するために使われる。フラグが立った場合でも、OpenAI担当者が基礎となるプロンプトや応答にアクセスするわけではない。

顧客側は、自らのシステムで利用可能な情報を使い、アラートや措置の判断を調査できる。正当な利用を説明する、異議を申し立てる、または確認済みの不正利用に関する調査を支援する場合には、顧客が関連情報をOpenAIと共有することを選べる。

なぜZDRと安全監視の両立が課題になるのか

一部の最近のフロンティアモデル導入では、安全監視を理由としてAI提供者が機微なコンテンツを保持することを顧客に求めてきた、とOpenAIは指摘する。これは、セキュリティ上の義務や利用者に対する約束を抱える組織にとって、導入上の摩擦になり得る。

Private Safety Processingは、こうした背景の下でZDRを継続して提供するために設計されたものだという。安全性の検知範囲を広げることと、顧客データを担当者が直接見られない状態に置くことを、技術・運用の両面で両立させようとしている。

ただし、限定的な安全シグナルの具体的な内容、検出ルール、執行基準、誤検知時の運用詳細は、今回の公式発表では網羅的に示されていない。導入判断では「データを保持しない」という表現だけでなく、どの自動処理がどの範囲の関連性を扱うのかを契約・技術資料で確認することが重要になる。

日本の開発・セキュリティ実務で見直す点

日本で機微情報を扱う開発チームは、まず自社のデータフローを、API送信前、処理中、応答後、ログ・監査保管に分けて整理したい。ZDRはOpenAI側の保持に関する約束であり、顧客側のアプリケーションログ、観測基盤、プロキシ、分析ツールに残るデータまで自動的に消去するものではない。

• 利用中の契約・組織・API構成がZDRの対象条件に合致するかを確認する。
• プロンプト、応答、ツール呼び出し、エージェント状態を自社側でどこまで保存するか決める。
• 停止指示、権限逸脱、反復的な異常操作について、アプリケーション側の監査・中断制御を設計する。
• 安全シグナルを受けた場合の調査担当、顧客通知、エスカレーション、異議申立ての手順を定める。
• 暗号鍵を顧客が管理する保存方式を検討する場合、鍵管理、失効、復旧、アクセス権限を評価する。

特にエージェント導入では、単一の入力・出力だけでなく、セッション、タスク連鎖、外部ツール実行の履歴をどう統制するかが焦点になる。OpenAIの仕組みに依存する範囲と、自社で検知・停止・証跡化すべき範囲を分けて設計する必要がある。

Agent Memories編集部の考察

今回の新規性は、プライバシーを優先して対話を単発で扱うZDR環境でも、複数の対話に現れる安全上のパターンを自動処理で見ようとする点にある。従来の「保持するか、監視を弱めるか」という二者択一を避けるアーキテクチャ上の試みと評価できる。

一方で、企業の評価軸は「OpenAI担当者が本文を閲覧しない」ことだけでは足りない。安全シグナルが生成される条件、そのシグナルに基づく措置、利用者の説明や再審査の経路、顧客が自らのログで検証できる範囲が、実際の統制と説明責任を左右する。

したがって、導入担当者はZDRをデータ保護要件の一部として位置付けつつ、エージェントの権限管理、停止可能性、操作記録、インシデント対応を別個に整備すべきだ。Private Safety Processingが一般化した場合も、顧客環境のガバナンスを代替するものではない。

提供状況と今後の公式計画

Private Safety Processingは早期顧客とテスト中である。OpenAIは、顧客がAIの高機能化に伴っても自社コンテンツの保護方法を予見できることを求めていると説明し、そのために今回プレビューを公開した。

OpenAIは2026年9月にPrivate Safety Processingの展開開始と技術ホワイトペーパーの公開を予定している。これは予定の表明であり、今回の発表だけから個別組織への提供開始時期、対応モデル、地域別の利用可否を断定することはできない。

よくある質問

ZDRではOpenAIはプロンプトと応答を学習に使いますか？

OpenAIは、対象となるAPI顧客について、エンタープライズ顧客データを顧客が明示的にオプトインしない限りモデル学習に使用しないと説明している。自社の利用形態が対象条件を満たすかは、契約および公式の利用条件で確認が必要だ。

Private Safety ProcessingでOpenAI担当者は会話本文を読めますか？

公式説明では、担当者は基礎となる顧客コンテンツにアクセスしない。リスク検知時には活動の種類を示す限定的なシグナルを受け取るとしており、フラグ付与自体が会話本文の担当者閲覧を意味するものではない。

顧客は安全アラートの理由を調べられますか？

OpenAIは、顧客が自社システム内で利用可能な情報を用いて、アラートおよび措置判断を調査できるとしている。異議申立てや正当な活動の説明を望む場合、顧客は関連情報を共有する選択ができる。

OpenAI提供ストレージを使う場合、暗号鍵は誰が持ちますか？

開発中の選択肢では、コンテンツは顧客が管理する鍵で暗号化される。OpenAIは担当者がその鍵のコピーを持たないため、基礎コンテンツへアクセスできないと説明している。

まとめ

OpenAIは、対象API顧客に対するZDRの約束を再確認するとともに、複数対話の安全上の兆候を扱うPrivate Safety Processingを示した。要点は、安全監視を広げても顧客コンテンツをOpenAI担当者に開示しないという設計方針にある。

実務では、ZDRの対象条件、自社ログの保持、鍵管理、安全シグナルへの対応、エージェントの停止・権限統制を一体で確認したい。今後予定される技術ホワイトペーパーと展開情報で、実装要件と運用上の境界を精査する段階となる。

本カテゴリはMiraigent / Agent Memoriesによる非公式編集記事です。OpenAIとの提携・承認・後援を示すものではありません。