業務システムから生成AI APIを使うとき、「入力した顧客情報や社内データは、AI事業者側にどのくらい残るのか」は避けて通れない確認事項です。モデル性能が高くても、データ保持の条件が自社のセキュリティ要件や顧客との契約に合わなければ、本番導入は進められません。
OpenAIは2026年8月19日、対象となるAPI顧客向けのZero Data Retention（ZDR）を維持しながら、複数のやり取りにまたがる安全上のリスクを検知する「Private Safety Processing」を発表しました。ポイントは、単に「データを保存しない」という話ではありません。長時間動くAIエージェントでも安全監視を成立させつつ、顧客コンテンツへの人のアクセスを最小化する設計を目指している点です。
2026年8月20日時点ではPrivate Safety Processingはプレビュー段階です。したがって、すべてのAPI利用者が同じ条件で利用できると考えるのは早計です。
SEやフリーランスが実務で見るべきなのは、「ZDRという名前があるか」ではなく、対象組織・対象エンドポイント・保存先・監査・例外・自社側のログ設計まで含めて要件を確認できているかです。
OpenAIのZero Data Retention（ZDR）とは
Zero Data Retentionは、条件を満たして承認されたAPI顧客について、OpenAI側での顧客コンテンツの保持を抑えるためのデータ保持設定です。OpenAIは企業向けデータについて、明示的なオプトインがない限りモデル学習に利用しない方針も案内しています。
ただし、「OpenAI APIを使えば自動的にZDRになる」という意味ではありません。OpenAIのAPIドキュメントでは、通常は不正利用監視のためのログが生成される場合があり、ZDRやModified Abuse Monitoringは対象顧客向けの管理機能として案内されています。
また、エンドポイントや機能によってデータ保持の扱いは異なる可能性があります。実務で「当社はZDRだから保存されない」と一括りにするのではなく、実際に使うAPI機能ごとの扱いを公式ドキュメントで確認する必要があります。
なぜPrivate Safety Processingが必要になったのか
AIエージェントが長時間動き、複数のツールを使うようになると、1回の入力だけではリスクを判断しにくいケースが増えます。
たとえば、単独では問題のない質問を何回も重ねて安全対策の弱点を探る行為や、複数の操作を組み合わせた結果として危険性が高まるケースです。個々のメッセージだけを見ると普通でも、時系列で見ると問題が見えてくることがあります。
一方で、その検知のために会話全文をAI事業者側へ長く保存する設計にすると、ZDRを必要とする企業のセキュリティ要件と衝突します。Private Safety Processingは、この「複数のやり取りをまたぐ安全監視」と「顧客データの保持を抑える要件」を両立させるための仕組みとして発表されました。
Private Safety Processingの仕組み
OpenAIの説明では、Private Safety Processingは関連する複数のやり取りを自動システムが評価し、問題の兆候を検知します。基礎となる顧客コンテンツへの人のアクセスを前提にしない形で、安全上必要な情報を限定して扱う設計が示されています。
ZDRの考え方と組み合わせることで、企業側は機密データをAI事業者へ長期保存させることなく、より長い文脈での安全監視を実現できる可能性があります。ただし、現時点ではプレビュー段階であり、実運用上の細かな仕様や対応範囲は今後の公式資料も確認する必要があります。
「ZDRなら何も残らない」と考えない方がよい理由
ZDRという言葉だけを見ると、APIに関係するあらゆる情報が完全にゼロになるように感じます。しかし、実務では対象となるデータの範囲を分けて考える必要があります。
OpenAIの監査ログは、APIキー、ユーザー、サービスアカウント、プロジェクト設定などの管理・構成イベントを追跡するための仕組みです。これはプロンプト本文やモデル応答そのものとは目的が異なります。
このため、社内のセキュリティ説明資料に「ZDR＝ログが一切存在しない」と書くのは避けた方がよいでしょう。「何のデータが対象か」「管理ログはどう扱われるか」「使うAPI機能に固有の保存があるか」を分けて整理する方が安全です。
SE実務で確認したい5つのポイント
1. ZDRの適用範囲を確認する
最初に確認したいのは、自社のAPI OrganizationやProjectでZDRが利用可能か、そして実際に使う機能が対象かです。「会社としてOpenAIの法人向けサービスを使っている」ことと、「そのAPI通信にZDRが適用されている」ことは同じではありません。
2. 自社側に残すログを先に決める
AI事業者側でデータを保持しない場合でも、自社の障害調査や監査にはログが必要です。ただし、プロンプト全文や顧客情報を無制限にアプリケーションログへ残すと、自社側が新しい情報漏えいポイントになります。
リクエストID、処理時刻、利用モデル、エラー種別、処理結果の成否など、調査に必要なメタデータと、本文として残す必要がある情報を分離します。機密データを残すなら、保存期間、閲覧権限、暗号化、削除手順まで決める必要があります。
3. AIエージェントの権限をZDRと別に設計する
データが保存されないからといって、AIエージェント自体の操作が安全になるわけではありません。顧客DBの読み取り、ファイル更新、メール送信、決済、クラウド操作などを任せる場合は、最小権限、操作上限、人の承認、緊急停止を別途設計します。
ZDRは主にデータ保持の論点であり、権限管理や誤操作防止を代替する仕組みではありません。
4. インシデント時に何を調査できるか確認する
保存する情報を減らすと、漏えいリスクを下げられる一方、後から原因を調べる材料も減ります。本番障害や不正利用の調査で何が必要なのかを事前に整理し、自社が保持する監査証跡とOpenAI側の管理ログの役割を分ける必要があります。
5. 契約・規程上の表現を実装と一致させる
顧客へ「入力データは保存されません」と説明する場合、その表現が実際の構成と一致しているか確認します。API本体の保持条件が厳しくても、自社のAPサーバー、APM、エラートラッキング、プロキシ、バックアップ、問い合わせ管理などに本文が残る可能性があります。
フリーランスSEが受託案件でAI APIを組み込む場合も、サービス提供者の仕様だけを説明するのではなく、自分が構築するシステム全体でデータがどこを通り、どこに保存されるかを図にしておくと判断しやすくなります。
メリットと注意点
今回の発表のメリットは、AIモデルの能力が上がり長時間のエージェント処理が増えても、企業側が安全監視とデータ保持の厳格化を両立しやすくなる可能性があることです。特に、顧客データや機密情報を扱うシステムでは、導入検討の選択肢が広がります。
一方、Private Safety Processingは2026年8月20日時点でプレビュー段階です。対象顧客、具体的な申し込み条件、対応機能、運用上の制約などは、今後の公式情報で更新される可能性があります。
またZDR自体も、すべてのAPI利用者・すべての機能へ一律に適用されるものではありません。導入判断では、ニュース記事だけでなく、実際に使用する時点のData controlsドキュメントと契約条件を確認する必要があります。
向いている組織・まだ急がなくてよいケース
ZDRやPrivate Safety Processingの考え方が特に重要なのは、機密性の高いデータをAPIで処理し、なおかつAIエージェントを長時間動かしたい組織です。金融情報、医療情報、顧客の契約情報、社内の未公開資料、独自研究データなどを扱うシステムでは、保持条件を細かく確認する価値があります。
一方、公開情報だけを要約する小規模な社内ツールや、個人情報を扱わない試作であれば、最初から高度なZDR構成だけに注目するより、入力データを匿名化し、権限を絞り、ログ設計を整える方が先になる場合もあります。
機能名から導入を決めるのではなく、扱うデータの機密度と業務リスクから必要な対策を決めるのが現実的です。
これから導入を検討するなら
最初に、AIへ送るデータを「公開情報」「社内情報」「機密情報」「個人情報」のように分類します。次に、各データについてOpenAIへ送信してよい条件と、自社側で残すログの範囲を決めます。そのうえで、利用予定のAPI機能がZDRへ対応しているか、組織・プロジェクトに適用されるかを公式ドキュメントと契約窓口で確認します。
AIエージェントを導入する場合は、さらに「読むだけ」「更新できる」「外部へ送信できる」と操作権限を分けます。高リスク操作には承認を挟み、エラー時の停止方法を用意します。Private Safety Processingが利用可能になっても、この基本設計は不要になりません。
実務では、AIへ送信するデータの種類、OpenAI側と自社側それぞれの保持条件、AIに許可する操作、インシデント発生時に調査できるログを1枚に整理すると、関係者と合意しやすくなります。
まとめ
OpenAIが2026年8月19日に発表したPrivate Safety Processingは、Zero Data Retentionを必要とするAPI顧客でも、複数のやり取りにまたがる安全リスクを自動的に扱いやすくするための取り組みです。
企業やSEにとって重要なのは、ZDRを単なる「保存ゼロ」のラベルとして見るのではなく、対象エンドポイント、監査ログ、自社側の保存、AIエージェントの権限まで含めて確認することです。
2026年8月20日時点ではPrivate Safety Processingはプレビュー段階です。導入を検討する場合は、公開された仕組みを参考にしつつ、実際の契約・対象機能・Data controlsの最新情報を確認してから設計へ反映するのが現実的です。
コメント