目錄
本記事の情報は2026年8月時点のものです。Private Safety Processingは現在もEarly Customersとのテストおよび段階的なRolloutの途中です。
OpenAIは、企業やAPI開発者に直接影響する重要な変更を発表しました。対象となるAPI顧客にZero Data Retention（ゼロデータ保持、ZDR）を引き続き提供すると同時に、新しい安全機構であるPrivate Safety ProcessingをPreviewしています。この2つが同じ発表の中で扱われているのは偶然ではありません。両者が向き合っているのは、徐々に表面化してきた同じ矛盾だからです。AIが1回の質問へ答えるだけでなく、数十分から数時間にわたってAgent Taskを実行するようになると、一部のリスクは複数回のInteractionを前後関係ごと見なければ分かりません。しかしCross-interactionのSafety Analysisには通常、何らかのStateやRecordが必要で、それが企業側のData Retention制限と衝突します。
一般的なChatGPT Webユーザーにとって、今回の発表は新しいPrivacy Toggleが突然追加されたという話ではありません。主な対象は条件を満たすAPIおよびEnterprise Workloadsで、特にFinancial Records、Health Data、Client Contracts、未公開Product Data、Internal Researchなどを扱う処理です。本当に理解するべきなのは、単純な「OpenAIはデータを保存しない」という一文ではありません。どの内容がSafety Monitoring Logsへ入らないのか、どの機能はそれ自体がApplication Stateの保存を必要とするのか、さらにデータがExternal MCPやSaaSへ送られた場合、その先ではまったく別のRetention Policyが適用されるのかまで分けて考える必要があります。
Zero Data Retentionとは？まず「Trainingに使わない」と「Contentを保存しない」を分ける
OpenAI APIデータはデフォルトでTrainingに使われない。ZDRが扱うのは別のRetention Layer
OpenAI APIへ送信されたデータは、顧客が自ら共有を選択しない限り、デフォルトではモデルのTrainingや改善には使用されません。ただし、「Trainingに使わない」と「まったく保存しない」は以前から別の話です。通常のAPI利用では、OpenAIがUsage Policiesの適用やAbuse DetectionのためにAbuse Monitoring Logsを作成する場合があり、そこにはPrompt、Response、さらにContentから派生したSafety Classification情報などが含まれる可能性があります。これらは通常、最長30日間保存されます。
Zero Data Retentionは、このレイヤーをさらに制限する仕組みです。条件を満たしOpenAIの承認を受けた組織では、Customer Contentをこの種のAbuse Monitoring Logsへ入れないようにできます。また、ZDRをサポートするResponses APIやChat CompletionsなどのEndpointsでは、storeが強制的にfalseとして扱われます。そのため、より正確に言えば、通常のAPIでもデータはデフォルトでモデルTrainingへ使われず、ZDRではさらにAbuse Monitoringや一部機能状態のためにOpenAIがCustomer Contentを保持する範囲を制限します。
ただし、ZDRを「OpenAIのSystem内に1Byteも残らなくなる」と理解することもできません。Account Data、Billing、Usage Statistics、Support RequestsなどのSystem DataはCustomer Contentとは分けて扱われており、ZDRを有効にしてもすべて消えるわけではありません。そのため企業がData Processing Assessmentを行う場合、Customer Content、Application State、System Dataを分けて確認する必要があります。
すべてのOpenAI API機能がZDRに対応しているわけではない
ZDRはAPI Platform全体を一括で切り替えるGlobal Switchではありません。Chat Completions、Responses、Embeddings、一部のImage、Audio、Moderation系機能はZDRをサポートできますが、Conversations、Assistants、Threads、Vector Stores、Files、Fine-tuning、Batchesなどは機能そのものがApplication Stateを保持する必要があるため、同じZero Retentionの考え方をそのまま適用することはできません。
これは仕組みを考えれば分かりやすい点です。Vector Storeを使うということは、後のRetrievalで利用するためにDataを保存する必要があります。Conversationを翌週も継続するなら、何らかのPersistent Stateも必要です。そのため企業が本当に確認すべきなのは「OpenAIにZDRがあるか」ではなく、実際のWorkflowで使用する各EndpointとToolがZDR Eligibleかどうかです。
ZDR対応に見える一部の機能にも独自の制約があります。例えばBackground Modeでは後からPollingするためにResponse Dataを一時的に保存する必要があり、Code Interpreterも現在は完全なZDRとそのまま組み合わせることができません。一部のPrompt CachingやHosted Container機能にも、機能上必要な短期的Temporary Storageが存在する場合があります。こうしたTemporary Storageは「完全なPromptを30日間のAbuse Investigation Logへ保存する」こととは別ですが、ZDRが「Dataが一度もStorageへ書き込まれない」という意味ではないことも示しています。
Remote MCPを使う場合、第三者のRetention Policyは別に考える必要がある
この点はAgent Workflowで特に見落とされやすい部分です。OpenAI側でZDRを使用していても、Responses APIからさらにRemote MCP ServerへContentを送信した場合、その先のData Processingは第三者サービス自身のRetention Policyに従います。OpenAIのZDRがNotion、CRM、Search Service、自前MCP Serverまで自動的に延長されることはありません。
そのためAgent Systemで本当に確認すべきなのは、End-to-endのData Flowです。Dataがどこから入り、どのModelを通り、どのToolsを呼び出し、どの第三者がRaw Contentを受け取り、それぞれの地点で何日保存されるのかを整理する必要があります。Model Provider側の一部分だけを確認しても、その後本当にDataが保存される場所を見落とす可能性があります。
Agentの登場で、なぜZero Data Retentionに新しいSafety Problemが生まれた？
1つのPromptでは正常に見えても、連続した操作をまとめて初めてRisk Patternが見えることがある
OpenAIは今回の発表で、既存のZDR対応Safety Systemは主に各Interactionを個別に判断してきたと説明しています。しかしAgentが長時間かつMulti-step Taskを処理するようになると、Risky Patternが単一Promptの中に現れるとは限りません。例えば設定値を調べる、権限について質問する、Credential関連の処理を求める、といった操作は1つずつ見ればすべて正常に見える可能性があります。複数のInteractionを前後関係ごと見ることで初めて、高リスクなWorkflowを組み立てていると分かる場合があります。
Agentはこの問題をさらに長い時間軸へ広げます。Agentは情報を検索し、計画を立て直し、Toolを呼び、結果を観察し、そのうえで次のActionを判断することができます。各Stepごとにユーザーが新しいInstructionを出す必要もありません。OpenAIが挙げている例には、ユーザーが停止するよう求めたあともAgentがActionを続けるといったケースも含まれます。こうしたUser IntentからのDeviationも、Activity全体のContextを見たほうが判断しやすくなります。
その結果、矛盾は非常に明確になります。Safety Systemは長いContextを見たほうがCross-step Riskを判断しやすい。一方、企業はSensitive Customer ContentをModel Providerに長期間保存させたくない場合があります。Private Safety Processingが解決しようとしているのは、この2つを分離することです。
Private Safety Processingはどう動く？Automated SystemはPatternを見るが、PersonnelはContentを直接見ない
ZDR Modeでは、Cross-interaction DataをCustomer-controlled Environmentへ残せる
OpenAIが現在公開しているDesignによると、Private Safety Processingは複数のData Storage Modeで利用できるよう設計されています。ZDR Deploymentでは、Cross-interaction Analysisに必要なCustomer ContentをCustomer-controlled Infrastructureへ残し、Automated Safety Systemsが関連Interactionを分析してSuspicious Patternを判断します。OpenAI Personnelが直接読める完全なConversation Logを先に作成する方式ではありません。
OpenAIはさらに別のModeも開発しています。Data自体はOpenAI提供Storageへ置くものの、Customer-controlled KeysでEncryptし、OpenAI PersonnelはKeyを持たないため、Underlying Customer Contentを直接読むことができないという設計です。これは企業で一般的なCustomer-controlled Encryption Keysに近い方向ですが、現時点では完全なTechnical White Paperがまだ公開されていないため、Confidential Computing、TEE、Key Lifecycleなどの具体的なInfrastructure Detailsを推測で補うべきではありません。
Safety Teamが受け取るのは限定されたSignalであり、Prompt Summaryではない
Private Safety ProcessingがPotentially Problematic Activityを検出した場合、OpenAIが現在説明しているOutputはnarrowly defined safety signalです。主な目的は、どのCategoryのActivityが関係しているかを示すことであり、Raw Prompt、Response、Complete Content SummaryをそのままPersonnelへ渡すものではありません。
つまり、Automated Systemは複数のRelated Interactionsを分析できますが、OpenAI Personnelが見るのは限定されたRisk Signalだけです。Underlying ContentはCustomer-controlled Environmentに残るか、Customer-controlled Keyによって保護されます。その後Appeal、Legitimate Useの説明、確認済みAbuseのInvestigation Supportなどが必要になった場合、Customer自身が関連情報を提供するかどうか判断できます。
ここがPrivate Safety Processingで最も注目すべき点です。Safety Monitoringそのものを削除するのではなく、「Contentを分析できること」と「Human PersonnelがRaw Contentを読めること」を切り離そうとしています。
Private Safety Processingは今すぐ使える？現在はEarly Testing段階
Private Safety Processingは、すべてのOpenAI API顧客がすぐ有効化できる正式機能ではありません。OpenAIによると、現在はEarly Customersとテストを行っており、2026年9月から段階的にRolloutを開始する予定で、同時にTechnical White Paperも公開するとしています。
現時点で確認できるDesign Directionはいくつかあります。Private Safety ProcessingはCross-interactionのSafety Analysisをサポートすること、OpenAI PersonnelがそのためにUnderlying Customer Contentへ直接アクセスしないこと、Customer-controlled Infrastructureをサポートすること、さらにOpenAI StorageとCustomer-controlled Keysを組み合わせたModeも開発中であること、最終OutputはLimited Safety Signalsであることです。
一方、本当に重要なInfrastructure Questions、例えばEncryption Architecture、Execution Environment、Key Revocation、Signal Schema、Retention Lifecycle、False Positive Handling、さらに第三者がこれらのBoundaryをVerificationできるかどうかは、Technical White Paper公開後でなければ判断できません。そのためProcurementやCompliance Assessmentを進めているTeamは、Private Safety ProcessingをUpcoming Capabilityとして確認することはできますが、現時点のAnnouncementだけを正式なSecurity Specificationとして扱うのは適切ではありません。
Zero Data Retentionはどのようなデータに向いている？
Sensitive DataはZDRを優先的に検討する価値があるが、「機密」なら必ず最高レベルにすべきとは限らない
OpenAIは今回の発表で、Financial Records、Health Data、Confidential Business Plans、Proprietary Researchなどを利用例として挙げています。こうしたDataでRetentionが特に重要になる理由は、単純に「Privateだから」だけではなく、Regulation、Client Contracts、NDA、社内Security Policyなどが関係する場合があるためです。
例えば未公開Financial Statements、Health Records、Client Contracts、R&D DataなどをAPIへ送るWorkflowでは、TransmissionがEncryptedかだけを確認しても十分ではありません。Model ProviderがRaw Contentを保存するのか、何日保存するのか、誰がアクセスできるのか、Trainingへ利用されるのか、どの機能がApplication Stateを作るのか、さらにModelを離れたDataがどのThird-party Serviceへ送られるのかまで確認する必要があります。
ZDRはその中の重要な一部分を解決しますが、自動的にComplianceを満たすButtonではありません。Industry、Country、ContractによってThird-party Data Processingへの要求は異なるため、まずData Classificationを行い、そのうえでどのWorkflowに本当にZDRが必要か判断するほうが合理的です。すべてのProjectへ一律に最も厳しい条件を適用する必要はありません。
ZDRでは一部の機能柔軟性も失われる
完全なZDRでは、Persistent Stateを必要とする一部の機能が制限されます。そのためPublic Dataの整理、一般的なBrainstorming、公開済みContentのSummaryなど、Sensitivityが低いWorkloadsまで必ず最高レベルのData Controlにする必要はありません。企業ではHigh-sensitive WorkflowをZDR Projectへ分離し、一般Contentには別ProjectとData Policyを使うようなArchitectureのほうが現実的です。すべてをZero Retentionにするために、本当に必要な機能まで失うことを避けられます。
Zero Data Retentionにも例外はあり、Legal Obligationsは残る
ZDRを使用していても、どのような状況でもContentが絶対に保存されないと理解することはできません。OpenAIは今回の発表で、Child Sexual Abuse Materialの疑いがあるImagesについては、法的義務により保存、Human Review、法令に基づくReportingが行われる可能性があり、CustomerがZDRを利用していてもこの義務はなくならないと明記しています。
OpenAIのAPI Data ControlsにもSafety Retentionに関連する仕組みがあります。Severe Risk Activityを調査・防止するために合理的に必要だと判断した場合、特定Customerおよび特定Modelについて、一時的に通常のZDR Eligibilityを変更できる仕組みがあり、その場合は影響を受けるCustomerへ事前にWritten Noticeを行う必要があります。
これは企業がCompliance Reviewを行う際に重要な部分です。Product Nameに「Zero」が入っているかではなく、Scope、Exceptions、Notification Process、そして実際にどのEndpoints、Models、Toolsがその条件の対象になるのかを見る必要があります。
OpenAIとAnthropicの違いは、どちらがPrivacyを重視しているかだけではない
OpenAIの今回の発表はAnthropicとの直接対決として書かれやすいテーマです。AnthropicはFable 5やMythos 5などの高能力Modelsで異なるSafety Trade-offを採用しており、Cross-request Jailbreak、Cyber Misuse、そのほか複雑なAttack Patternsを検出するため、関連Trafficを30日間保持します。またAnthropicは、そのDataを新しいClaude ModelsのTrainingへ使わないことも明確にしています。
両社が直面している問題は実際には同じです。ただし、Safety Observationに必要なRaw Dataをどこへ置くかについて異なる答えを出しています。Anthropicの方法は比較的直接的で、Model Providerが一定期間Raw Trafficを保持し、Safety TeamがCross-interaction Investigationを行います。一方、OpenAIのPrivate Safety ProcessingはCustomer ContentをCustomer-controlled Environmentへ残すか、将来的にはCustomer-controlled Keysで保護し、Automated SystemからLimited Safety Signalsだけを取り出すことを目指しています。
これは単純な「OpenAIはPrivacy重視、AnthropicはSafety重視」という違いではありません。どちらもCross-interaction Risk Detectionを実現しようとしており、Raw Evidenceを誰が保持するのかについて異なる設計を選んでいます。どちらが最終的により信頼できるかは、現時点では十分な公開情報がなく判断できません。特にOpenAIのPrivate Safety Processingはまだ全面Rollout前で、Full White Paperも9月公開予定です。
ZDRが進むほど、企業自身のAudit Trailがむしろ重要になる
Model ProviderがHuman Personnelから直接見えるComplete Customer Contentを保存しない場合、Incident発生時にProvider側からどこまで詳細を復元できるかは、Complete Prompt／Responseを保存するArchitectureとは当然異なります。ただしZero Retentionが「一切追跡できない」という意味ではありません。むしろより多くのResponsibilityがEnterprise側へ戻ってきます。
AgentがすでにInternal Data、External Tools、Production Workflowへ触れるようになっているなら、企業は自分たちのActivity Logsを保持しておくべきです。例えばAgentがどのTaskを受け取ったか、どのInternal Dataを読んだか、どのToolを呼び出したか、どのInformationを外部へ送ったか、どのRecordsを変更したか、どのActionsがHuman Approvalを経たかなどです。
ZDRはProviderがSensitive Customer Contentを保持する範囲を減らせますが、企業側のObservabilityを置き換えるものではありません。逆に言えば、Model Providerが保持するものが少なくなるほど、企業自身がAgentのActivityを把握しておく必要性は高くなります。
AWS AgentCore Web Searchも別のAgent Boundaryを扱っている
あわせて見る価値があるもう一つの例がAmazon Bedrock AgentCore Web Searchです。AWSではWeb SearchでServer-side Domain Restrictionsを設定でき、管理者がAgentに特定DomainからResultsを取得させるかどうか制御できます。この制限はPromptへ「このサイトを検索しないで」と書く方式ではなく、Infrastructure側で直接強制されます。
Private Safety Processingが扱う問題とは異なりますが、Design Directionはかなり近いものがあります。モデルへ「特定サイトを検索するな」とInstructionするより、SystemがそのDomainのResultを返さないほうが制約をVerificationしやすい。同様にSafety Personnelへ「CustomerのSensitive Promptを読まないで」と依頼するより、PersonnelがKeyを持たずUnderlying PlaintextへアクセスできないArchitectureのほうが明確です。
Agent Systemでは、このようにModel Outsideへ置かれたRestrictionのほうが、Prompt内のRuleより検証しやすい場合があります。ただし、現在AWS公式DocumentationからDomain FilteringなどのCapabilityは確認できる一方、「Publication Date Filterが8月19日に初めて同時発表された」といった正確なTimingまでは十分なEvidenceがないため、この部分を同日のNewsとして強く結びつけるのは避けたほうがよいでしょう。
APIのZDRを一般ChatGPT Web版へそのまま当てはめることはできない
これは実際の利用で特に誤解されやすい点です。OpenAIが今回扱っているZero Data Retentionは、API Platformで条件を満たすOrganizations向けに提供するData Retention Controlであり、一般のChatGPT Plusユーザーに新しく追加された設定ではありません。
一般ChatGPT Productには、Chat History、Deletion、Model Improvement、Data Retentionについて独自のPolicyがあります。そのためChatGPT Webを開いてClient ContractをUploadして会話した場合、「OpenAIにはZDRがあるから、このConversationもZero Data Retentionだ」と判断することはできません。
Sensitive Dataを扱う場合、最初に確認するべきなのは、DataがどのProduct、どのEndpointから送信されるのかです。そのうえで、そのProductに実際に適用されるData Controlsを確認します。
企業がAI Data Retentionを評価するとき、まず確認したい4つのこと
1つ目：実際に使うEndpointがZDR Eligibleか確認する
AccountにZDRが有効かだけを確認するのではなく、実際のWorkflowで利用するResponses、Chat Completions、Files、Vector Stores、Code Interpreter、Background Mode、Remote MCPをすべて一覧にします。1か所でもPersistent Stateが必要なら、Workflow全体を単純に「完全Zero Retention」と表現することはできません。
2つ目：PromptとResponse以外に何が残るのか確認する
Account Data、Billing、Usage Statistics、Application State、Temporary Data、Legal Exceptionsは個別に確認する必要があります。本当に意味のある質問は「ProviderがZeroと言っているか」ではなく、「Zeroの対象はどのData Categoryか」です。
3つ目：Third-party ToolsもData Flowへ含める
AgentがGoogle Drive、Notion、CRM、Web Search、External MCPなどを呼び出す場合、それぞれのサービスに独自のRetention Policyがあります。OpenAI側だけZDRを有効にしても、Workflow全体がZero Retentionになるとは限りません。
4つ目：Private Safety Processing White Paper公開後にUnderlying Architectureを再確認する
9月にTechnical White Paperが公開されたあと、特に確認したいのはCustomer-controlled KeysのManagement、ContentがどのExecution Environmentで処理されるのか、Safety SignalにどのFieldsが含まれるのか、SignalのRetention Period、Key Revocationがどう機能するのか、Critical Incident発生時にどのようなForensicsが可能なのかです。
こうしたDetailsのほうが、Announcementにある「PrivacyとSafetyを両立する」という一文より、企業が正式Environmentへ導入できるかを判断する材料になります。
Private Safety Processingの本当の新しさは、Safety SignalとRaw Contentを分離すること
OpenAIが今回初めて「API DataをTrainingに使わない」と発表したわけではありません。このPolicyはすでに存在しています。本当に新しいProblemはAgentによって生まれました。Modelが自ら多くのStepを連続実行できると、単一PromptのSafety Checkだけでは全体Riskを見抜けない可能性があります。一方、その解決策としてWork Content全体をModel Providerへ保存すると、Enterprise Data Control Requirementと直接衝突します。
Private Safety Processingが試みているのは、Automated SystemsがCross-interactionのPatternを判断する能力を維持しながら、OpenAI Personnelが直接取得できるInformationをLimited Safety Signalsへ縮小することです。Underlying Customer ContentはCustomer Control下に残すか、Customerが管理するEncryption Keysで保護します。
このArchitectureが実際のAbuse InvestigationでPrivacyと十分なForensicsを同時に維持できるかは、まだ分かりません。9月のWhite Paper、実際のRollout、その後のThird-party Security Reviewの有無などのほうが、現在のAnnouncementより判断材料として重要になるでしょう。
ただし一つ明確なのは、企業が今後AI Serviceを評価するとき、Model CapabilityとToken Priceだけを比較する時代ではなくなるということです。Dataがどのくらい保持されるのか、誰が見られるのか、Keyを誰がControlするのか、どの機能がStateを必要とするのか、Safety Systemがどの程度Informationへアクセスできるのか、External ToolsがContentをどこへ送るのかまで、正式なProcurement条件として確認する必要があります。
よくある質問 FAQ
いいえ。ZDRは主に、条件を満たすCustomer ContentをAbuse Monitoring Logsへ入れず、ZDR対応EndpointによるApplication Stateの保存を制限する仕組みです。一方、Account、Billing、Usage StatisticsなどのSystem Dataは引き続き存在する可能性があり、Endpointや機能によってRetention条件も異なります。
OpenAI APIへ送信したDataは、Customerが自ら共有を選択しない限り、デフォルトではModel Trainingや改善へ使用されません。このPolicyとZero Data Retentionは別のものです。Trainingへ使われなくても、通常API利用ではAbuse Monitoring Retentionが存在する場合があります。
まだです。OpenAIによると現在はEarly CustomersとTesting中で、2026年9月から段階的なRolloutを開始し、同時にTechnical White Paperも公開する予定です。現時点では公開済みのDesign Directionとして見るべきで、すべてのCustomerが利用できる正式機能ではありません。
現在公開されているArchitectureでは、Safety SystemがTriggerされたからといって、OpenAI PersonnelがUnderlying Customer Contentへ直接アクセスする仕組みではありません。Automated Systemsが関連Interactionを分析し、Limited Safety Signalを出力します。その後AppealやInvestigationへの協力が必要な場合、Customer自身が関連Contentを提供するか判断できます。
必ずしもそうではありません。Remote MCP ServerはThird-party Serviceであり、そのServiceへ送信されたDataには独自のRetention Policyが適用されます。OpenAI側のZDRがすべてのExternal SaaS、MCP Provider、そのほかのToolsへ自動的に適用されることはありません。
必ずしもそうではありません。ZDRはSensitivityが高く、ContractsやData Governance Requirementsの対象になるWorkflowで特に検討価値があります。ただしPersistent Stateが必要な一部機能は制限されるため、Data Sensitivityに応じてProjectsやData Policiesを分けるほうが現実的です。すべてのWorkloadsへ同じ設定を一律に適用する必要はありません。