shirokuronoir

API保存ゼロを誤解しない5確認

API保存ゼロを誤解しない5確認

OpenAIは2026年8月19日、対象となるAPI顧客へZero Data Retention（ZDR）を継続提供し、Private Safety Processingを準備していると発表しました。機密データを扱う組織には重要な更新ですが、「ZDRを有効にすれば、使う機能に関係なく何も保存されない」と理解するのは危険です。

公式発表とAPIデータ制御の公式ドキュメントを照合し、導入前に止めるべき経路を6ケースの簡易判定で確認しました。

先に結論

ZDRは、対象顧客が承認を受け、対象APIを条件どおり使ったときの保持制御です。契約名だけを確認して終わらず、対象資格、APIごとの適格性、アプリケーション状態、外部サービス、例外処理をリクエスト経路ごとに確認してください。

特にConversations、Files、Video、background mode、外部MCPを同じ「保存ゼロ」として扱わないことが重要です。送信前のルーターで、許可、拒否、個別確認の3段階に分けると運用しやすくなります。

OpenAIの一次情報で確認したこと

OpenAI公式発表「Offering Zero Data Retention for frontier models」では、対象となるAPI顧客について、処理後にプロンプトとモデル応答を保持せず、顧客コンテンツをOpenAI担当者が確認できないというZDRの考え方が説明されています。企業データは、顧客が明示的に選ばない限りモデル学習へ使わないとも記載されています。

同時に公開されたPrivate Safety Processingの予告は、関連する複数のやり取りから危険なパターンを自動検出しつつ、OpenAI担当者へ元のプロンプトや応答を見せない設計です。ZDR環境では顧客管理の基盤に内容を置き、限定された安全シグナルだけを返す方針が示されています。これはプレビュー段階で、技術ホワイトペーパーは9月に公開予定です。

OpenAI APIのデータ制御ドキュメントでは、ZDRは事前承認が必要で、組織またはプロジェクト単位に設定できると説明されています。Responses APIとChat Completionsでは、ZDR有効時にstoreをtrueで送ってもfalseとして扱われます。

ただし、ZDR対象外のAPIや機能はアプリケーション状態を保持する場合があります。ConversationsやFilesはZDR対象外で、外部MCPへ送ったデータは接続先の保持方針に従います。Responses APIのbackground modeはポーリングのため約10分間ディスクへ保存します。つまり、保持制御はモデル名ではなく、API、ツール、実行モードの組み合わせで判断する必要があります。

今回試したこと

実データやAPIキーは使わず、公式ドキュメントの保持条件を固定した簡易ルーターへ6件の架空要求を流しました。判定は、通常許可をALLOW、送信停止をBLOCK、追加確認をREVIEWとしています。

| ケース | 判定 | 理由 |

|—|—|—|

| Responses API、ZDR、外部送信なし | ALLOW | ZDR時はstoreがfalseとして扱われる |

| Conversations API | BLOCK | ZDR対象外で、状態は削除まで保持される |

| Files API | BLOCK | ZDR対象外。削除期限を別に管理する必要がある |

| Video API | BLOCK | ZDR対象外で、処理と取得のため保存が発生する |

| Responses APIのbackground mode | REVIEW | ポーリングのため約10分の一時保存がある |

| Responses APIから外部MCPを利用 | REVIEW | 接続先サービスの保持方針が適用される |

結果はALLOWが1件、BLOCKが3件、REVIEWが2件でした。これはOpenAIサービスの性能検証ではなく、構成レビューで見落としやすい保存経路を、送信前に止められるか確認する運用テストです。

導入前に確認する5項目

1. ZDRの対象資格と設定単位

ZDRは全API利用者へ自動適用される機能ではありません。承認状況を確認し、組織全体かプロジェクト単位かを決めます。新規プロジェクトが既定設定を継承するかも監査対象にします。

2. APIごとの適格性

利用APIを一覧化し、公式表のZDR eligible列と照合します。Responses APIが対象でも、会話状態、ファイル、動画など周辺APIが同じとは限りません。

3. 一時状態と削除条件

「学習に使わない」「不正利用監視ログへ残さない」「アプリケーション状態を保存しない」は別の条件です。保存場所、保持時間、削除方法を分けて記録します。

4. 外部ツールへの送信

remote MCPやネットワーク接続で第三者へ送ったデータは、OpenAI側のZDRだけでは制御できません。接続先の保持期間、ログ、再委託先を確認できない場合は機密データを送らない設計にします。

5. 例外と安全監視

公式発表とドキュメントには、安全上または法令上の例外があります。「ゼロ」という言葉だけで判断せず、例外の対象、通知方法、社内の調査手順まで確認します。

今日から行う3つのアクション

1. 本番コードが使うAPI、ツール、実行モードを1行ずつ棚卸しする

2. 各行へALLOW、BLOCK、REVIEWと根拠URL、保持時間、削除担当を記録する

3. BLOCKとREVIEWの経路へ架空データを流し、送信前に停止または承認へ戻ることをテストする

AIへ強い権限を渡すときは、プロンプトではなく外側の制御で止める必要があります。「AI決済を任せる前の5つの制御」で整理した予算、期限、承認、監査ログと同じ考え方を、データ送信にも適用できます。

判断基準

導入可否は「ZDR契約があるか」ではなく、機密データが通る全経路に未確認の保存先がないかで決めます。1つでも根拠のない経路があれば、その経路は止めたままにします。公式表の更新を定期確認し、モデルや機能の変更時に判定を再実行してください。

関連記事

出典

執筆・検証: しろのあ。一次情報、ローカルで確認した運用判定、未検証の実サービス部分を分けて記載しています。