
ZDR導入前に決める7項目——OpenAIの横断検知でも調査証跡は自社に残る
Private Safety Processingの最新公開状態を再確認。一般提供日などの未確認事項と、ZDR採用前に固定すべき相関ID・担当者・初動時間を整理する。
「誰におすすめ」に当てはまらなければ、この記事はスキップしてOKです。
更新(2026年9月5日): 8月公開時の報道中心の整理を、OpenAIとAnthropicの一次情報で再検証した。Private Safety Processingは現在も早期顧客とのテスト中と説明されている。一般提供日・価格・検知率・通知SLAは公開一次情報で未確認のため、導入済みとは扱わない。
Change——横断検知はZDRと両立する設計になった
OpenAIが2026年8月19日に公表したPrivate Safety Processingは、ZDR対応の安全処理を複数の関連するやり取りへ広げる。ZDR環境では顧客コンテンツを顧客管理インフラに置き、自動システムが潜在的な不正を検知して、活動種別を示す限定的なシグナルをOpenAIへ返す。OpenAIは、フラグが立った場合も担当者が基礎となる顧客コンテンツへアクセスしないとしている。
ただし、9月5日時点の同ページは早期顧客とのテスト中と記したままだ。9月中の展開開始と技術白書共有は計画として書かれているが、一般提供日、適格条件、価格、検知率、誤検知率、通知SLAは確認できない。予定と提供済みを混ぜないことが最初の判断になる。
誰におすすめ
エンドユーザー入力をOpenAI APIへ渡すSaaSまたは社内AI基盤の開発・セキュリティ責任者で、ZDRを本番採用する前に監査とインシデント応答を設計する人に向く。チャットUIを個人利用しているだけなら対象外だ。
Impact——アラートを調べる証拠は顧客側にある
OpenAIは、顧客が自社システムにある情報を使ってアラートや執行判断を調査すると説明する。ZDRで本文を残さないとしても、誰が、いつ、どのモデルへ、どの操作を行い、どのポリシー判定と応答になったかを結び直せなければ、限定シグナルを受けても調査できない。
ここで必要なのは『全文を保存するか、何も保存しないか』の二択ではない。本文を恒久保存せず、調査に必要なメタデータと相関を短期間だけ残す設計が中間にある。保持期間とアクセス権は、自社の契約、法令、脅威モデルに合わせる。
OpenAIの既定の不正利用監視ログは最大30日保持されうる。承認済みのZDRまたはModified Abuse Monitoringを使う顧客は、自社ユーザーのポリシー遵守と適用法上の監視・報告義務への対応責任を負う。またZDRは全機能に一律ではなく、対象外の機能はアプリケーション状態を保持しうる。
何をすべきか
Action——本番投入前に7項目を固定する
- Admin APIまたは管理画面で、実際の組織保持設定を取得して証跡化する。
- 利用する全エンドポイントのZDR適格性を確認日付きで表にする。
- ユーザーまたはサービス主体を仮名IDで追えるようにする。
- リクエスト、ツール実行、ポリシー判定、モデル応答へ同じ相関IDを付ける。
- 本文を除いた時刻、モデル、操作、判定、結果コードを最小期間だけ保存する。
- アラート担当者、初動時間、停止権限、OpenAIへの共有判断者を決める。
- 一般提供条件または技術白書の公開を再評価トリガーにする。
注意点
Anthropicはcovered modelsについて、複数リクエストにまたがる攻撃を理由に30日保持を採用する。ただし現在の公開文書は、一部組織がFableをZDRで利用できる例外にも触れている。『OpenAIはゼロ、Anthropicは必ず30日』とベンダー名だけで決めず、自組織へ適用される設定と例外を確認するべきだ。
最小イベント台帳の具体項目はOpenAI指定ではなく、本記事の運用案である。法令・契約・脅威モデルに合わせて、保存項目、保持期間、閲覧権限を決裁する必要がある。
結論は単純だ。ZDRを選ぶ前に、削除するデータではなく、アラートから事実へ戻るために残す最小証跡を決める。


