OpenAI APIに送ったプロンプトと応答は、既定では不正利用の監視用に最大30日保存されます。この保存を外す管理機能がZDR（Zero Data Retention、ゼロデータ保持）です。この記事では、OpenAI ZDRの対象と申請の流れ、Modified Abuse Monitoringとの違い、ZDRでも残るデータ、storeが強制的にfalseになることを踏まえた実装、2026年9月に提供が始まったZDR with Private Safety Processingの設定手順を、公式ドキュメントの記載だけで整理します。数値と仕様はすべて2026年10月22日時点の確認です。
まとめ：OpenAI ZDRで消える保存と消えない保存の境界
ZDRは「OpenAIに何も残らない」スイッチではありません。外れるのは不正利用監視ログに入る顧客コンテンツと、Responses APIとChat Completions APIの保存です。Assistants・Batch・Files・ベクトルストアなど、仕組み上データを置いておく機能は、ZDRを有効にしても削除するまで残ります。
実装面では、storeが常にfalse扱いになるため、previous_response_idで前の応答を参照する作りは使えません。会話履歴と暗号化された推論アイテムを自分で送り直す設計にします。
最新モデルでZDRを続けるには、自社のS3・Azure Blob・GCSを安全審査用の保存先として接続する「ZDR with Private Safety Processing（PSP）」が加わりました。日本の案件では、国内保存のjpリージョン自体がZDRかMAMの承認を前提にしている点が判断を左右します。
OpenAI ZDRとは｜既定30日の不正利用監視ログを外す申請制の管理機能
まず、ZDRが何を止めるのかを、既定の保存と比べて押さえます。
既定で30日残る不正利用監視ログとアプリケーション状態の2種類
OpenAIのデータ管理ガイドによると、API経由のデータが保存される形は2つあります。1つは不正利用監視ログで、利用規約の執行と悪用対策のために生成され、プロンプトと応答、分類器の出力などのメタデータを含むログです。既定ではすべてのAPI機能で生成され、最大30日保持されます。もう1つはアプリケーション状態で、会話の続きやファイル検索のように、機能を動かすために保存されるデータです。
学習への利用は別の話です。2023年3月1日以降、APIに送ったデータは明示的にオプトインしない限りモデルの学習に使われません。つまり「学習されないか」はAPIなら最初から解決しており、ZDRが扱うのは「30日間、OpenAI側に残るか」のほうです。
ZDRとModified Abuse Monitoring｜storeをfalseに固定
承認された顧客が選べる管理機能は、Modified Abuse Monitoring（MAM）とZDRの2つです。どちらも顧客コンテンツを不正利用監視ログから除外し、この点に差はありません。
| 項目 | MAM | ZDR |
|---|---|---|
| 監視ログの顧客コンテンツ | 除外 | 除外 |
| Responses等のstore | 指定どおり | 常にfalse扱い |
| 対象外機能の利用 | 全機能を使える | 使えるが状態は残る |
| 申請 | 事前承認が必要 | 事前承認が必要 |
違いは1点で、ZDRでは /v1/responses と /v1/chat/completions の store を、リクエストでtrueを指定しても常にfalseとして扱います。MAMはプラットフォームの全機能を通常どおり使いたい組織向け、ZDRはアプリケーション状態まで残したくない組織向けという分け方です。
営業経由の事前承認と組織・プロジェクト単位で保存方針を選ぶ設定手順
MAMもZDRも画面のスイッチだけでは有効になりません。OpenAIの事前承認と追加要件への同意が必要で、窓口は営業チームです。承認後は、Settings → Organization → Data controlsにData Retentionタブが現れ、組織とプロジェクトの2階層で設定します。
- 組織単位：組織全体をZDRかMAMのどちらかにする
- プロジェクト単位：組織の設定を継承するdefault、ZDRかMAMの明示指定、無効にするNoneから選ぶ
- 有効にした顧客は、利用者に利用ポリシーを守らせ、法令上の報告義務を果たす責任を負う
本番だけZDR、検証用はNoneのように分けられます。APIキーをどのプロジェクトで発行するかが、そのまま保存ポリシーの選択になります。
ZDRを有効にしても残るデータ｜対象外エンドポイントと例外の一覧
「ZDRにしたから何も残らない」と社内に説明すると、後で食い違いが出ます。残るものを先に列挙しておきます。
Assistants・Batch・Files・ベクトルストアがZDR対象外となる範囲
データ管理ガイドのエンドポイント表を、ZDRの可否で整理すると次のとおりです。
| エンドポイント | ZDR対象 | アプリ状態の保持 |
|---|---|---|
| responses・chat | 対象 | なし（例外あり） |
| embeddings・moderations | 対象 | なし |
| audio（文字起こし等） | 対象 | なし |
| realtime | 対象 | なし |
| conversations・agents | 対象外 | 削除するまで |
| assistants・threads | 対象外 | 削除するまで |
| vector_stores・files | 対象外 | 削除するまで |
| batches・fine_tuning | 対象外 | 削除するまで |
表の「対象外」は使えないという意味ではなく、ZDRを有効にしていても状態が残るという意味です。Assistants系のオブジェクトはAPIや画面で削除してから30日後にサーバーから消え、削除しなければ無期限に残ります。社内文書の検索に使うベクトルストアも対象外なので、Responses APIのファイル検索とベクトルストアの仕組みを採るなら、削除の運用を別に決めておきます。
Background modeの約10分・音声出力1時間・プロンプトキャッシュ24時間
ZDR対象のResponses APIにも、短時間の保存が残る例外があります。
- Background mode：ポーリングのため、応答データを約10分ディスクに保存する
- 音声出力：複数ターンの会話のため、アプリケーション状態を1時間保存する
- プロンプトキャッシュ：暗号化したキーと値のテンソルをGPUローカルに置き、24時間の期限後は残さない
- Hosted ShellとCode Interpreterのコンテナ：稼働中だけ一時的にファイルを書き、期限切れか削除で消える
審査資料には「ZDRでも最大24時間、GPU上に暗号化キャッシュが残りうる」と書いておくと、質問に先回りできます。
CSAM判定画像と外部MCPサーバーへ送ったデータという2つの例外
画像とファイルの入力は、送信時に児童性的虐待コンテンツ（CSAM）の検出にかけられます。分類器が疑いありと判定した画像は、ZDR・MAM・後述のPrivate Retentionのいずれでも、人による確認のために保持されます。OpenAIのZDRに関する発表によれば、この保持の理由は法律上の報告義務であるという説明です。
もう1つは外部サービスです。Responses APIのリモートMCPサーバーツールで送ったデータは、そのMCPサーバー側の保持方針に従います。ZDRの効力が及ぶのはOpenAIのインフラの内側までです。
ZDR有効時のResponses API実装｜storeを常にfalseとする会話履歴
ZDRに切り替えると、既存コードの一部が動かなくなります。API呼び出しの基本はResponses APIとChat Completions APIの違いを整理した記事に譲り、ZDR固有の差分に絞ります。
previous_response_idに頼らず履歴を毎回送るPython実装
Responses APIは、previous_response_id に前の応答IDを渡すだけで会話を続けられます。ただしこれは応答がOpenAI側に保存されている前提の方式です。ZDRでは保存されないため、会話状態のガイドにある、履歴を自分で持って毎回送る方式に寄せます。
pip install openaifrom openai import OpenAI
client = OpenAI() # OPENAI_API_KEY には ZDR を設定したプロジェクトのキーを入れる
model = "gpt-6-astra"
# 会話履歴はアプリ側で保持する（ZDR では OpenAI 側に残らないため）
history = [{"role": "user", "content": "契約書レビューの観点を3つ挙げて"}]
first = client.responses.create(model=model, input=history, store=False)
print(first.output_text)
# 推論アイテム（暗号化済み）を含む出力をそのまま履歴へ足す
history += first.output
history.append({"role": "user", "content": "2つめの観点を詳しく"})
second = client.responses.create(model=model, input=history, store=False)
print(second.output_text)ZDRの組織では store=False を省いてもfalse扱いです。明示するのは、ZDRなしの検証用プロジェクトでも挙動をそろえるためです。
推論アイテムのencrypted_contentを次ターンへ渡す理由と保存先の注意
推論モデルのガイドによると、storeがfalseのとき、またはZDRの組織では、応答の推論アイテムに encrypted_content が既定で付きます。以前は include での明示が必要でしたが、現在は互換のために受け付けているだけで、指定は不要です。前のコードで first.output を丸ごと履歴に足しているのは、この暗号化された推論を次のターンへ引き継ぐためです。
見落としやすいのは保存先の移動です。OpenAI側に残らない代わりに、履歴はアプリ側のDBやログ基盤に残ります。アプリ側の保持期間とマスキングも同じ審査の対象に入れてください。
ZDR with Private Safety Processing｜自社保存での安全審査
2026年に入り、ZDRの前提が変わりつつあります。高性能なモデルほど、1回のやり取りでは見えないリスクを検出するための保存を求められるようになったためです。
2026年8月19日の予告から9月22日の段階提供開始までの経緯
OpenAIは2026年8月19日、前述の発表でPrivate Safety Processing（PSP）を予告しました。既存の安全システムは1回ごとのやり取りしか評価できません。PSPは、内容をOpenAIの担当者が見られない形のまま、関連するやり取りをまとめて自動審査するための仕組みです。発表は9月22日に更新され、API顧客への段階的な提供が始まりました。DevDay 2026のまとめでも、ZDR with PSPは企業向けの「Private Intelligence」の一部として紹介されています。
GPT-6 Astraの提供経路とデータ境界を扱った記事のとおり、最新モデルはデータの置き場所が採否を分けます。PSPは、そこでもZDRを続けるための仕組みです。
HPKEとEKMの二重暗号化と人がデータを読めない安全審査環境の構成
ZDR with PSPのガイドによると、処理は2つの流れで動きます。
- 安全分類器の照会か承認済みのサンプリング方針で、一部のやり取りが選ばれる（照会は違反の認定ではない）
- 選ばれた記録を暗号化し、顧客のリージョンのクラウドストレージに書き込む。OpenAIが持つのはメタデータと保存場所の索引だけ
- 人のアクセスを無効にしたハードウェア認証済みの審査環境だけが復号し、自動審査する
- 平文で外に出るのは、事前に定義された範囲の安全シグナルだけ。詳細な結果は暗号化して顧客のストレージに戻す
記録は内側をOpenAI管理のHPKEで、外側を顧客管理のEKMで二重に暗号化します。EKMを有効にすると、OpenAIの鍵だけでは復号できません。鍵の認可を取り消せば復号は止まりますが、記録の削除や処理済みの取り消しにはならない点に注意が要ります。暗号化と書き込みは非同期で、推論の応答は待たされません。
プロジェクト単位で全トラフィックに効くPSP有効化とモデルへの適用範囲
PSPはプロジェクト単位で有効になり、有効にしたプロジェクトでは、PSPが不要なモデルへのリクエストも含めて全トラフィックに適用されます。PSPなしのZDRで足りるモデルを使い続けたいなら、ZDRだけを設定した別プロジェクトにリクエストを振り分けます。
接続を外すとポリシーは組織の既定に戻り、PSP必須のモデルは使えなくなる可能性があります（必須モデルの一覧は未掲載）。また承認済み顧客でも、OpenAIは書面の事前通知でモデルを対象外にでき、その場合は暗号化した監視ログをOpenAI側に保存する「Private Retention with PSP」などに切り替わると明記されています。
PSPの外部ストレージ接続｜AWS S3のIAMロールとManagement API登録
保存先はAWS S3、Azure Blob Storage、Google Cloud Storageの3つから選べます。ここではAWSの手順を、CLIで再現できる形にします。
30日ライフサイクルと信頼ポリシーをAWS CLIで用意する設定例
ガイドの要件は、ACL無効・パブリックアクセス全ブロックの専用バケット、接頭辞 openai/ を30日で失効させるルール、OpenAIのロールにだけAssumeRoleを許す信頼ポリシーの3点です。データレジデンシーを使わない場合、推奨リージョンはus-west-1とされています。ライフサイクルはput-bucket-lifecycle-configuration、ロールはcreate-roleで作れます。
# 1) ライフサイクル：openai/ 配下を30日で失効（これより早く消すルールを置かない）
cat > lifecycle.json <<'EOF'
{"Rules":[{"ID":"psp-retention","Filter":{"Prefix":"openai/"},
"Status":"Enabled","Expiration":{"Days":30}}]}
EOF
aws s3api put-bucket-lifecycle-configuration \
--bucket your-psp-bucket --lifecycle-configuration file://lifecycle.json
# 2) 信頼ポリシー：OpenAI のロールを、自社の OpenAI プロジェクトIDを ExternalId にして許可
cat > trust.json <<'EOF'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow",
"Principal":{"AWS":"arn:aws:iam::790389265272:role/CustomerStorage"},
"Action":"sts:AssumeRole",
"Condition":{"StringEquals":{"sts:ExternalId":["proj_xxxxxxxx"]}}}]}
EOF
aws iam create-role --role-name psp-role \
--assume-role-policy-document file://trust.jsonロールには、バケットに対する s3:GetLifecycleConfiguration と、オブジェクトに対する s3:GetObject・s3:PutObject・s3:DeleteObject だけを許すポリシーを付けます。OpenAI側のPrincipal ARNは書き換えません。
Admin APIキーでexternal_storageを登録しvalidateする手順
登録は管理画面のOrganization settings → Data controls → Data retention → Connect storageからもできますが、構成管理に載せるならManagement APIです。プロジェクトの推論用キーでは動かず、組織のAdmin APIキーが必要です。
OPENAI_API_BASE='https://api.openai.com' # 米国は us.api、欧州は eu.api
OPENAI_STORAGE_URL="$OPENAI_API_BASE/v1/organization/external_storage"
# 登録（応答の id は extstorage_ で始まり、status は pending）
curl --fail-with-body -sS -X POST "$OPENAI_STORAGE_URL" \
-H "Authorization: Bearer $OPENAI_ADMIN_KEY" \
-H "OpenAI-Organization: $OPENAI_ORG_ID" \
-H 'Content-Type: application/json' \
--data-binary '{"project_id":"proj_xxxxxxxx","provider":{"type":"aws",
"bucket":"arn:aws:s3:::your-psp-bucket",
"role_arn":"arn:aws:iam::123456789012:role/psp-role"}}'
# 検証（成功すると status が validated になり、プロジェクトが ZDR with PSP に切り替わる）
curl --fail-with-body -sS -X POST "$OPENAI_STORAGE_URL/$EXTERNAL_STORAGE_ID/validate" \
-H "Authorization: Bearer $OPENAI_ADMIN_KEY" \
-H "OpenAI-Organization: $OPENAI_ORG_ID"登録しただけではポリシーは変わらず、validateが通った時点で切り替わります。検証中、OpenAIは csg_validation_ で始まるテスト用オブジェクトを書き込み、ExternalIdなしと proj_smoketest-verifier でのAssumeRoleが拒否されることも確かめます。この拒否を通そうとして条件を緩めてはいけません。
pending・validated・unhealthyの状態と検証失敗時のエラー対処
状態は3つです。pending は登録済みで未検証、validated は検証に成功した記録、unhealthy は設定か権限に問題が見つかった状態を表します。validatedは「その時点で通った」という意味で、接続が生き続けている保証ではありません。画面のRefreshは保存済みの状態を読み直すだけで、再検証はしません。
エラーで多いのは、組織にPSPの利用権が無い customer_managed_retention_not_enabled、地域に検証済みストレージが無い customer_storage_not_ready（401）、ホスト違いの incorrect_hostname です。暗号化記録を最低30日保持する義務も課されます。
日本企業がOpenAI ZDRを申請する判断基準｜jpリージョンと他制度の比較
最後に、国内の案件で判断に効く条件をまとめ、申請するかどうかを言い切ります。
jp.api.openai.comの国内保存はMAMかZDRが前提で推論は国外という条件
データ管理ガイドのデータレジデンシー表では、日本（jp.api.openai.com）は保存が国内、推論の処理は国内非対応で、利用にはMAMかZDRの承認が要るとされています。米国以外の地域を使うには、監視ログ管理の承認とModified Retentionの契約変更が必要です。さらに、2026年3月5日以降に公開されたモデルをデータレジデンシーのエンドポイントで使うと、料金が10%上乗せされます。
国内保存のためにjpリージョンを選んだ時点で、ZDRかMAMの申請は避けられません。PSPの保存先はデータレジデンシーに合わせる決まりですが、Azureは米国かEUと書かれており、日本リージョンでPSPを組めるかは公式の記載がなく未確認です。
ChatGPT Enterprise・Azure OpenAIとの保存制度の比較
ZDRはAPIの組織とプロジェクトに対する管理機能で、ChatGPTの画面で使う分には効きません。OpenAIのエンタープライズ向けプライバシーの説明では、ChatGPT EnterpriseとBusinessの保持期間はワークスペース管理者が決め、削除した会話は原則30日以内にシステムから消えるとされています。プランごとの管理機能はChatGPT EnterpriseとBusinessの違いをまとめた記事で比べました。
Azure経由でOpenAIのモデルを使う場合は、OpenAIのZDRではなくMicrosoftの制度に従います。監視ログを止める申請の条件と手順はAzure OpenAIのオプトアウト申請を解説した記事にまとめたとおりです。同じモデルでも経路で申請先が変わるため、利用する経路を先に決めます。
ZDRを申請すべき案件と見送ってよい案件を保存要件で判断する線引き
申請すべきなのは、契約や社内規程で「委託先に30日でもデータを残さない」と求められる案件です。医療・金融・個人情報を大量に扱う問い合わせ対応、未公開の設計情報を読ませるコード生成などがこれにあたり、jpリージョンを使う案件も前述のとおり申請が前提になります。
見送ってよいのは、学習に使われないことさえ確認できれば足りる社内業務です。APIは既定で学習に使われないので、30日の監視ログを許容できるなら、申請の手間と機能の制約を負う理由はありません。逆に、AssistantsやBatchを中心に組んだ既存システムをZDRに乗せる計画は、対象外の機能ばかりで効果が薄く、Responses APIへの作り直しを先に見積もるべきです。どの機能に載せ替えるかの設計と申請資料の準備まで含めて進めたい場合は、生成AI導入支援の相談窓口で要件整理から対応します。
OpenAI ZDRの申請と運用でよくある質問と公式情報に基づく回答
2026年10月22日時点の公式ドキュメントに基づいて答えます。
OpenAI ZDRはどうすれば使えますか？
OpenAIの営業チームに問い合わせ、事前承認を受けて追加要件に同意する必要があります。承認されるとData controlsにData Retentionタブが現れ、組織かプロジェクトの単位でZDRを選べます。承認基準は公開されていません。
ZDRとModified Abuse Monitoringはどちらを選べばよいですか？
どちらも不正利用監視ログから顧客コンテンツを外します。違いは、ZDRがResponses APIとChat Completions APIのstoreを常にfalseにする点です。previous_response_idに頼った作りを残すならMAM、アプリケーション状態も残さないならZDRです。プロジェクトごとの使い分けもできます。
ZDRを有効にすれば学習にも使われなくなりますか？
学習とZDRは別の仕組みです。APIのデータは2023年3月1日以降、ZDRの有無にかかわらず、オプトインしない限り学習に使われません。ZDRが変えるのは、最大30日残る監視ログとアプリケーション状態の保存です。
ZDRはChatGPTの画面での利用にも適用されますか？
適用されません。ZDRはAPIの組織とプロジェクトに対する管理機能です。ChatGPT Enterprise、Edu、Businessでは管理者が会話の保持期間を設定します。併用する組織は、2つの保存ルールを別々に審査資料へ書いてください。
Private Safety Processingの料金と対象モデルは決まっていますか？
2026年10月22日時点で、ZDR with PSPのガイドに料金と対象モデルの一覧は記載されていません。分かっているのは、9月22日からAPI顧客へ段階的に提供されていること、PSPを必須とするモデルがあること、保存先のS3やBlob、GCSの保管費用は顧客側の負担になることです。採用前に営業窓口で対象モデルと提供時期を確認してください。
関連記事
- GPT-6 Astraとは？提供3経路の料金とデータ境界の判断【2026年9月】：最新モデルでデータの置き場所が採否を分ける理由です。
- GPT-6 Solとは？6.1 Solの変更点とLuna・Astraの使い分け【2026年10月】：ZDRを設定したプロジェクトで呼ぶモデルの選び方です。
- OpenAI Responses APIとChat Completions APIの違い｜移行手順と見送る条件【2026年10月】：ZDR対象のResponses APIへ移行する手順です。
- Azure OpenAIのオプトアウト申請：不正使用監視のログ保持を止める条件と手順：Azure経由で同じ目的を果たす申請です。
- Azure OpenAI Serviceとは？ChatGPTとの違い・できること・料金・データ保護を解説【2026年8月版】：OpenAI直とAzureの経路を選ぶ判断の起点です。
