本文へスキップ
KNOWLEDGE — AI NEWS
OpenAIのZDRを保つ新しい安全監視
OpenAIが2026年8月19日、リクエストの処理後にプロンプトと応答を保持しないZDR（Zero Data Retention）を維持したまま、安全上のリスクを検知する「Private Safety Processing」のプレビューを公式サイトで公表しました。従来は各やり取りを個別に評価していた検知を、複数の関連するやり取りにまたがって行いつつ、OpenAIの担当者には元の内容を渡さない設計です。公式には、現在は初期顧客とテスト中で、提供開始と技術文書の公開は9月を予定していると記載されています。
Summary
この記事の要点
機能そのものより、AIに業務データを渡す判断がどこで変わるかに絞って整理します。要点は3つです。
「安全監視のためにデータを預ける」という条件が外れる方向にある
公式発表では、最近のフロンティアモデルの提供において、安全監視のために機微な内容をAI提供者側に保持させることを顧客に求める例があったと述べられています。今回のプレビューは、その条件を課さずに検知を行うための仕組みです。
対象はAPIであり、ChatGPTの各プランの話ではない
今回ZDRの対象として記載されているのは、条件を満たすAPIの顧客です。同じOpenAIでも、APIとChatGPTでは契約もデータの扱いも別の枠組みです。社内で議論するときに、この区別が抜けると結論を誤ります。
まだプレビューであり、日本での条件は書かれていない
公式には初期顧客とのテスト段階であり、ロールアウトの開始は9月を予定していると記載されています。対象地域や日本向けの条件についての記載は今回の発表にはありません。今すぐ運用を変える段階ではないと考えています。
Basics
前提：ZDRと「安全監視」は、もともと相反しやすい
今回の発表を読むには、AI提供者がデータを持つ理由が2つあることを分けて理解する必要があります。すでに把握している方はこの節を飛ばして構いません。
AI提供者が利用者のデータを保持する理由は、大きく「モデルの学習に使うため」と「不正利用を検知するため」に分かれます。前者について公式発表では、OpenAIの企業顧客のデータは明示的に同意しない限り学習には使わないと記載されています。問題になりやすいのは後者です。不正利用の検知は、内容を見なければ判断できないという性質を持つためです。
| 用語 | 意味 | 実務での意味合い |
|---|---|---|
| ZDR（Zero Data Retention） | リクエストの処理後にプロンプトと応答を保持しないという取り決め | 提供者側にログが残らないため、社内規程や取引先との約束を満たしやすくなる |
| 安全監視 | 不正利用や意図から逸れた動作を検知する仕組み | 検知のために内容を見る必要があり、ZDRと衝突しやすい |
| 顧客管理の鍵による暗号化 | 保存はするが、復号の鍵を顧客側だけが持つ方式 | 保存場所が提供者側でも、提供者は中身を読めない |
| エージェント | 依頼を受けて複数の手順を自分で実行するAI | 1回の応答では見えない問題が、連続した動作の中で起きうる |
今回の発表は、この「検知のために内容を見る必要がある」という前提を、担当者に見せずに自動処理だけで成立させようとする試みです。AIを業務へ組み込む全体像は生成AIのEC活用に、エージェントに権限を渡すときの考え方はPerplexity Computerの権限に関する記事にまとめています。
Announcement
公式発表の要点
OpenAIは2026年8月19日、公式サイトでPrivate Safety Processingのプレビューを公表しました（出典: OpenAI「Offering Zero Data Retention for frontier models」）。業務での判断に関係する点は次のとおりです。
| 項目 | 公式に記載されている内容 |
|---|---|
| 発表日・発表主体 | 2026年8月19日、OpenAI |
| ZDRの内容 | 条件を満たすAPI顧客に対し、リクエスト処理後にプロンプトと応答を保持しない。顧客の内容はOpenAIの担当者が閲覧できず、企業顧客のデータは明示的に同意しない限り学習に使わない |
| 今回の新規点 | Private Safety Processingのプレビュー。関連する複数のやり取りにまたがる兆候を、担当者に内容を見せずに自動で検知する |
| 従来との違い | これまでのZDR互換の安全システムは、やり取りを1件ずつ個別に評価している |
| データの置き場所 | ZDR構成では顧客が管理するインフラ上に残る。加えて、OpenAI側に保存し顧客が管理する鍵で暗号化する選択肢を開発中。OpenAIの担当者は鍵の複製を持たない |
| 検知時に渡るもの | 活動の種類を示す限定的なシグナルのみ。フラグが立った場合でも担当者は内容にアクセスできない |
| 顧客側の対応 | アラートや措置は自社のシステム内の情報で調査できる。異議申し立てや調査協力のために、顧客が選んで情報を共有できる |
| 提供段階 | 現在は初期顧客とテスト中。ロールアウト開始と技術ホワイトペーパーの公開は9月を予定 |
| 例外 | 法令上の要請により、児童性的虐待素材の疑いがある画像は、ZDR構成でも確認と報告のために保持される |
公式発表では、想定される用途として金融記録・医療データ・非公開の事業計画・独自研究といった機微な情報を扱う組織が挙げられ、Glean・Databricks・Abridge・Microsoftの名前が掲載されています。対象地域や日本向けの提供条件についての記載は、今回の発表には含まれていません。本記事の執筆時点（2026年8月20日）で一次情報から確認できるのはここまでです。
Analysis
セルフプラスの見解 — 効くのは「何を送っているか」を把握している事業者だけ
ここからは公式発表を踏まえたセルフプラスの分析で、事実の要約とは分けて記載します。この発表は一見すると大企業向けの話に見えますが、EC事業者にとっては、AIに顧客データを渡してよいかという日常の判断に直結します。
1. ECのAI利用は、気づかないうちに個人データを送っている
問い合わせ返信の下書き、レビューの要約、注文内容からの提案文の作成。いずれもAIに任せやすい作業ですが、渡している文面には氏名・住所・電話番号・注文履歴が含まれています。ここを整理せずに使い始めている事業者は少なくありません。まず、自社が何を送っているかを次の観点で棚卸しする必要があります。
| 使っている作業 | 送っている可能性がある情報 | 先に決めること |
|---|---|---|
| 問い合わせ返信の下書き | 氏名・住所・電話番号・注文番号・返品理由 | 送る前に個人を特定する項目を落とすか、落とさないなら委託先として整理する |
| レビュー・アンケートの要約 | 投稿者名・購入商品・自由記述内の個人的な事情 | 要約に投稿者名を含めない。健康状態など機微な記述の扱いを決める |
| 商品説明・広告文の生成 | 未公開の価格・仕入条件・発売前の商品情報 | 秘密保持契約の対象が混ざっていないかを確認する |
| 受注・在庫データの分析 | 取引先名・原価・粗利 | 取引先との契約で外部提供が制限されていないかを確認する |
今回の発表が意味を持つのは、この棚卸しが済んでいる事業者だけです。何を送っているか分からない状態では、提供者側の保持方針が変わっても判断材料になりません。
2. APIとChatGPTを混同すると、社内の議論が噛み合わなくなる
今回ZDRの対象として記載されているのは、条件を満たすAPIの顧客です。自社開発のツールやアプリからOpenAIのAPIを呼んでいる場合がこの区分に入りますが、ZDRが実際に適用されるかは、適用条件を満たしているかを自社の契約で確認する必要があります。一方、担当者がブラウザでChatGPTを開いて使っている場合は、別の契約と別のデータ方針の下にあります。「OpenAIはデータを保持しないらしい」という一言が社内を回ると、実際には対象外の使い方まで安全だと誤解されます。
ECの現場では、この2つが同時に走っていることがほとんどです。開発チームはAPIを、運用チームはChatGPTを使っている、という状態です。社内で方針を出すときは、契約の種類ごとに分けて書く必要があります。ChatGPTのビジネス向け契約の中身はChatGPT Businessの座席に関する記事で整理しています。
3. カート別に見ると、多くの事業者は「まだ動かなくてよい」
Shopify・Shopify Plus・ecforceのいずれを使っていても、今回の発表を受けてストア側の設定を変える必要はありません。Private Safety Processingはプレビュー段階で、提供開始は9月予定と記載されているためです。今の段階で費用や工数をかけるべき対象ではありません。
ただし、自社でAPIを呼ぶツールを作っている場合は別です。そこに顧客データが流れているなら、ZDRの適用条件を自社の契約で確認する作業には、今から着手する価値があります。カート標準の機能で完結している運用と、独自に組んだ連携がある運用とで、必要な確認の量が変わります。ShopifyのAI活用とecforceのAI活用で、それぞれの標準機能の範囲を整理しています。
4. 「保持しない」は、日本の法令上の整理を肩代わりしない
ZDRは、提供者がデータを保持しないという約束です。これは重要ですが、自社が外部のサービスへ個人データを渡したという事実そのものを消すものではありません。日本の個人情報保護法の下では、外部への委託として整理し、委託先の監督や社内規程との整合、プライバシーポリシーの記載範囲を確認する作業が別に必要になります。
ここを混同したまま「ZDRだから大丈夫」と社内で説明してしまうと、後から整理し直す手間のほうが大きくなります。法令面の最終的な判断は、自社の顧問弁護士や個人情報保護の担当部門に確認することをおすすめします。
「担当者が見られない」は、例外がないという意味ではありません
公式発表には、Private Safety Processingで検知が起きた場合でもOpenAIの担当者は顧客の内容にアクセスできないと記載されています。一方で同じ発表の注記には、法令上の要請により、児童性的虐待素材の疑いがある画像はZDR構成でも確認と報告のために保持されると明記されています。仕組みとしての設計と、法令上の例外は別の層の話です。自社の規程や取引先への説明に転記するときは、こうした例外も含めて公式の記載どおりに書くほうが、後で説明を修正せずに済みます。
Action
明日から何をすべきか
今すぐ契約や設定を変える必要はありません。3つとも、提供者や機能の変化に関係なく必要になる整理です。
AIに送っている情報を、作業ごとに1枚へ書き出す
問い合わせ対応、レビュー要約、原稿作成、データ分析の4つについて、実際に貼り付けている内容を確認します。担当者に聞くのではなく、直近の依頼文を実際に見るほうが確実です。この一覧が無いと、提供者側の方針が変わっても自社への影響を判断できません。
契約の種類ごとに、社内向けの方針を分けて書く
自社ツールから呼ぶAPI、ChatGPTのブラウザ利用、その他のAIサービスを分けて、それぞれ何を送ってよいかを決めます。1つの方針でまとめると、どこかで実態と合わなくなります。1行ずつで構わないので、契約ごとに分かれていることが重要です。
個人を特定する項目を落としてから送る形を、既定にする
氏名・住所・電話番号・メールアドレスを伏せても、返信の下書きや要約の質はほとんど落ちません。落とす作業を人の注意力に任せず、ツール側で自動的に置き換える形にできれば、提供者側の方針に関係なく安全側に立てます。9月の提供開始を待つより先に効きます。
OpenAIの他の動きは防御指針に関する記事と企業向け調査の記事にまとめています。AIエージェントを業務へ組み込む進め方はAIエージェント一括支援で扱っています。
FAQ
この発表に関するよくあるご質問
ZDRはChatGPTの有料プランにも適用されますか。
今回の発表でZDRの対象として記載されているのは、条件を満たすAPIの顧客です。ChatGPTの各プランについての記載は今回の発表にはありません。契約の種類ごとにデータの扱いが異なるため、自社が使っている形態を確認してください。
Private Safety Processingは今日から使えますか。
公式には、現在は初期の顧客とテスト中であり、提供開始と技術ホワイトペーパーの公開は9月を予定していると記載されています。本記事の執筆時点で一般提供は始まっておらず、日本での提供条件についても記載を確認できていません。
ZDRなら顧客の個人情報をそのまま送ってよいですか。
ZDRは処理後にプロンプトと応答を保持しないという約束であり、外部へ個人データを渡す行為そのものが無くなるわけではありません。委託先としての整理や社内規程との整合は、ZDRの有無とは別に確認する必要があります。
