【訂正】OpenAIのZDRは「何も保存しない」保証ではない ― API利用前の確認票
「ゼロデータ保持」という名前だけで、サービス全体に何も残らないとは説明できません。API提供元の扱いと、自分が作ったアプリのログや接続先の扱いは、別々に確認する必要があります。
2026年9月5日、8月22日の記事を現行の公式API資料で見直しました。これは契約・管理画面・実際の通信を検査した報告ではありません。初稿の過剰な断定を訂正し、確認が必要な場所を整理した記録です。
1. 初稿の「保証する」という説明を訂正する
初稿では、ZDRをプロンプトも応答も保持せず、社員も閲覧できない状態を保証するものと、一律に説明していました。この書き方では対象と例外が抜け落ちます。
現行のデータ管理ガイドでは、ZDRは承認が必要な保持制御です。監視ログから顧客コンテンツを除外しますが、対象外の機能ではアプリケーション状態が残り得ます。
同ガイドのEyes OffとSafety Retentionには、特定の顧客・モデルについて事前の書面通知を伴う適用除外が記載されています。後者では重大なリスクの調査・予防のため、検知対象の内容を保持して人が確認する場合もあります。画像・ファイルにも別の例外があります。「常に無保存・人の閲覧なし」と一般化できません。
これはすべてのZDR利用者の内容が常時保存されるという意味でもありません。自分への通知や契約を調べず、逆方向の断定に置き換えるのも誤りです。
2. 組織名だけでなく、実際に使うプロジェクトを見る
公式ガイドの設定手順では、組織とプロジェクトの両方で保持制御を設定でき、プロジェクト側では組織設定の継承も選べると説明されています。組織の設定値だけを読めば十分、という構造ではありません。
確認担当者には、組織だけの記録で終えず、サービスが使用するプロジェクトと設定の対応も残してもらいます。「組織はZDRらしい」「別のテスト環境では有効だった」という情報だけで、本番の説明を確定しないためです。
組織設定を取得するAPIの資料もありますが、当サイトでは管理者用の資格情報を取得せず、APIも実行していません。公式の応答例を自社の設定値として掲載することもしません。設定を読める担当者がいない場合は、その不足を残し、確認できる人へ引き継ぐ段階です。
3. 実務では、説明する一文と確認先を対にする
今回の見直しで作った確認票は、ZDRの取得申請書でも、法的な適合判定表でもありません。顧客に何を説明しようとしているかと、その根拠がどこにあるかを対応させるための編集用の表です。
| 説明する内容 | 先に確認するもの | 記録に残すもの |
|---|---|---|
| API提供元での扱い | 現行資料と自分に適用される条件 | 確認日、対象機能、例外、未回答の質問 |
| 利用中の保持設定 | 実際の組織・プロジェクトとの対応 | 確認担当者、設定の読み取り結果、継承先 |
| 自社のアプリに残る内容 | 入出力ログ、エラー記録、バックアップの設計と実装 | 保存項目、保存期間、閲覧できる担当者 |
| 接続先へ渡す内容 | 外部ツールへ送る項目と、そのサービス側の条件 | 送信先、送信目的、保存条件の根拠 |
例えば、API提供元側の確認を終えても、自社アプリのエラー報告に入力本文を付けていたなら、その記録は別の確認対象です。これは今回のサービスで見つかった事故ではなく、確認を分ける意味を示す仮の例です。「APIがZDRだからエラーログも無保存」と説明を飛ばさないようにします。
表を埋めるときは、顧客の実データを貼らず、設定項目と確認結果だけを残します。空欄を「問題なし」に変換せず、「担当者確認待ち」「その機能は未点検」と書けば、次の作業が決まります。APIキーの値や生の入力内容を、この確認票へ保存する必要はありません。
見直しのタイミングも、初稿にあった「半年ごと」という一律の間隔だけでは不足します。当サイトの提案は、少なくともモデル・接続機能・保存処理・契約条件を変えたとき、または提供元から通知が届いたときに、影響する行を読み直すことです。これは公式が定めた点検頻度ではなく、変更と説明の食い違いを減らすための運用案です。
4. 未確認の提供予定を、現行機能として案内しない
初稿のPrivate Safety Processingについては、9月の本格展開を確定事項として結んでいました。今回開いたAPI資料と公式ドメインの検索では、同機能の一般提供開始や自分の利用資格を裏付けられていません。そのため、現在使える機能としての導入案内は撤回します。検索で確認できなかったことを、機能が存在しない・計画が中止されたという証明には使いません。
次に必要なのは、契約担当者が持つ通知と、対象機能の提供条件を照合することです。記事を読んだだけで設定を変えたり、機密データを送ったりする段階ではありません。法令や顧客契約への適合性は、この技術記事だけでは判定できません。
同じく「どこで動くか」と「どこへ情報を送るか」を分ける例は、セルフホスト環境の記事でも整理しています。
2026-09-05の訂正： 無条件の無保存・閲覧不可と読める説明、未確認の提供開始の断定、根拠のない利用者像の推測を削除しました。題名と表紙を変更し、組織・プロジェクト・自社ログ・接続先を分ける確認票を追加しました。公開日は当初の記録を維持しています。