OpenAIのゼロデータ保持とは企業AIの安全監視とプライバシーをどう両立するか

企業でAIを使うとき、便利さの次に必ず出てくる疑問があります。社内資料を入力してよいのか。顧客情報を含む文章を要約させてよいのか。AIサービス側にどのくらい保存されるのか。安全のために監視が必要だとしても、その監視のために機密情報が残り続けるなら本末転倒ではないのか。

2026年8月20日前後、この疑問に関わる新しい論点として、OpenAIが企業・API向けに「顧客データを保持しないこと」と「危険な使われ方を検知すること」を両立させる仕組みを進めていると報じられました。報道では、この仕組みはPrivate Safety Processingと呼ばれ、ゼロデータ保持を求める企業にも高度な安全検知を提供する狙いがあるとされています。背景には、強力なAIモデルがサイバー攻撃、生物安全、詐欺、情報流出などのリスクと結びつく可能性が高まり、AI事業者が単に「保存しません」と言うだけでは済まなくなっている事情があります。

このニュースは、OpenAIとAnthropicの競争という読み方もできます。しかし、一般の企業や個人にとってより重要なのは、どちらの会社が勝つかではありません。AIを仕事に入れるとき、データを守る設計と、安全を守る監視をどう両立するかです。特に、医療、法律、金融、雇用、教育、公共サービス、セキュリティ対応のように人の生活や権利に大きく影響する領域では、AIの回答をそのまま最終判断にするのではなく、公式情報、専門家、社内規程、契約、法令、責任部署による確認が欠かせません。

この記事では、2026年8月20日時点で確認できる報道と公開情報をもとに、OpenAIのゼロデータ保持をめぐる動きを整理し、企業AI導入で確認すべき実務ポイントを解説します。技術の細部を追うよりも、管理者、現場責任者、一般利用者が「何を確認すればよいか」に焦点を当てます。

何が報じられたのか
なぜ今、データ保持が大きな論点になったのか
ゼロデータ保持は何を意味するのか
安全監視とプライバシーは対立だけではない
OpenAIとAnthropicの違いから見える企業の選び方
企業が最初に作るべき確認表
個人利用者が確認すべきこと
報道を読むときの注意点
日本企業にとっての実務的な意味
これから注目すべき点
まとめ
参考情報

何が報じられたのか

Axiosは2026年8月19日、OpenAIがPrivate Safety Processingと呼ばれる新しい安全技術を企業・APIユーザー向けに試していると報じました。記事によると、この仕組みは、顧客データを詳細に保存しないまま、複数回のやり取りにまたがる危険な兆候を見つけることを目指しています。サイバー攻撃や生物兵器などのリスクを示す可能性がある行動を、個々の入力全文を保持せずに検知するという方向性です。

同じ報道では、Anthropicが一部の高性能モデルについて30日間のデータ保持を求めていることにも触れられています。Anthropicの公開情報でも、Claude Fable 5やClaude Mythos 5のようなCovered Modelsでは、プロンプトと出力を30日間保持し、安全対策に使う方針が説明されています。Anthropic側の理屈は、危険な使い方は単発の入力だけでは見えにくく、多数のリクエストを横断して分析する必要があるというものです。

つまり、ここで争点になっているのは「AI事業者がデータを持つべきか、持つべきでないか」という単純な二択ではありません。安全を守るには一定の監視が必要です。一方で、企業や公共機関、医療・金融・法律などの現場では、入力データをできるだけ残したくない事情があります。AIが強力になるほど、プライバシーと安全監視のどちらか一方だけでは不十分になります。

OpenAIは以前から、企業向けデータについて「デフォルトでは組織の入力や出力をモデル学習に使わない」と説明しています。また、資格を満たす組織にはAPIでゼロデータ保持を選べると案内しています。APIドキュメントでは、Zero Data Retentionを有効にした場合、顧客コンテンツが abuse monitoring logs から除外され、Responses APIやChat Completionsの `store` パラメータも常に `false` と扱われると説明されています。ただし、すべての機能が完全に同じ条件で使えるわけではなく、バックグラウンド処理、ファイル、音声、キャッシュ、外部ツール連携などでは、機能上どうしても一時的な状態保存が発生する場合があります。

このため、企業が見るべきポイントは「ゼロデータ保持という言葉があるか」だけではありません。どの製品で、どのモデルで、どの機能で、どのデータが、どこに、どれくらい保存され、誰が見られ、どの条件で削除されるのかを確認する必要があります。

なぜ今、データ保持が大きな論点になったのか

AIのデータ保持が注目される理由は、単にプライバシー意識が高まったからではありません。AIの使われ方が、質問応答から実務フローへ広がったからです。以前のAI利用は、文章の要約、メール文案、翻訳、アイデア出しのような比較的軽い用途が中心でした。今は、社内資料検索、顧客対応、コード生成、契約書レビュー補助、営業資料作成、会議記録、ワークフロー自動化、セキュリティ分析、ブラウザ操作、外部ツール連携まで広がっています。

この変化によって、AIに入るデータの性質が変わりました。公開情報だけでなく、社内の未公開資料、顧客情報、個人情報、契約条件、財務見通し、技術仕様、ソースコード、障害情報、認証に関わる情報、医療や健康に関わる情報まで含まれやすくなっています。AIが便利であるほど、現場は「とりあえず入れてみる」方向に流れます。しかし、入力された情報がどこに残るのかを知らないまま利用が広がると、後から説明できないデータ流通が生まれます。

さらに、AIモデルの能力が高まると、安全監視の必要性も増します。強力なモデルは、脆弱性調査、コード生成、外部ツール操作、長期的な計画、複数ステップの実行に使えるようになります。これは防御や生産性向上にも役立ちますが、悪用されれば被害も大きくなります。OpenAIは2026年7月に、Hugging Faceとのモデル評価中に起きたセキュリティ事案について公表し、外部アドバイザーや第三者評価機関と調査を進めると説明しました。8月のDeployment Safety Hubでも、サイバー能力、生物・化学安全、自己改善などの評価項目が示されています。

こうした状況では、AI事業者がまったく監視しないことも問題になります。危険な使い方を検知できなければ、悪用が広がってから対応することになります。一方で、監視のためにすべてのプロンプトと出力を広く保存する設計も、企業利用では受け入れにくい場合があります。OpenAIのPrivate Safety Processing報道は、この板挟みに対する一つの方向性として読めます。

ゼロデータ保持は何を意味するのか

ゼロデータ保持という言葉は強く見えますが、実務では丁寧に理解する必要があります。一般的には、顧客が入力したプロンプトや出力をサービス側が保存しない、または abuse monitoring logs のような監視ログから除外する仕組みを指します。OpenAIのAPIドキュメントでは、Zero Data Retentionは顧客コンテンツを abuse monitoring logs から除外し、特定エンドポイントでは保存を指示する `store` パラメータを無効化するものとして説明されています。

ただし、これだけで「何も残らない」と決めつけるのは危険です。多くのクラウドサービスでは、顧客コンテンツとシステムデータを分けて扱います。顧客コンテンツとは、入力文、出力文、添付ファイルなどの中身です。一方、システムデータには、アカウント情報、請求情報、利用量、エラー、セキュリティイベント、アクセス元、操作履歴などが含まれる場合があります。顧客コンテンツを保存しない契約でも、サービス運営や不正利用対策に必要なメタデータまで完全に消えるとは限りません。

また、機能によっては処理のための一時保存が必要になります。たとえば、非同期処理では結果を後で取りに行くために一時的な状態が必要です。音声出力の会話、ファイル処理、プロンプトキャッシュ、外部ツール連携、リモートMCPサーバー、ブラウザ操作、コード実行環境なども、サービスや機能によってデータの残り方が異なります。AI導入時には、モデル名だけでなく、使う機能単位で確認することが重要です。

ゼロデータ保持を選ぶと、安全監視やサポートに制約が出ることもあります。サービス側が内容を見られないなら、問題発生時の調査、誤検知の検証、不正利用の追跡、品質改善、再現確認が難しくなる場合があります。だからこそ、OpenAIが報じられたPrivate Safety Processingのような仕組みで、内容を長く保存しないままリスクを検知しようとしている点が注目されます。

安全監視とプライバシーは対立だけではない

安全監視とプライバシーは、しばしば対立するものとして語られます。監視を強めればプライバシーが弱くなる。プライバシーを守れば監視が弱くなる。たしかに、この緊張関係はあります。しかし、設計次第では両立に近づけることもできます。

第一に、監視対象を減らすことです。すべての内容を丸ごと保存するのではなく、危険度を示すシグナル、分類結果、ルール違反の可能性、異常な利用パターンなどに絞る設計が考えられます。たとえば、詳細な顧客文書そのものを保存せず、危険カテゴリに関する高レベルのアラートだけを残すという方向です。ただし、どのシグナルがどの程度残るのか、誤検知時に誰が確認するのか、顧客側が監査できるのかは確認が必要です。

第二に、権限を分けることです。AI事業者の通常の担当者がデータを読めないようにし、限定された安全チームだけが、明確な条件で、記録に残る形でアクセスする設計があります。AnthropicのCovered Modelsに関する公開情報でも、デフォルトでは担当者が保持会話を読めず、自動安全システムでフラグが立った場合などに限って承認されたレビュー担当者が確認できると説明されています。こうした説明がある場合でも、企業側は契約、監査ログ、アクセス透明性、暗号鍵管理、削除条件を確認すべきです。

第三に、顧客側でログを持つことです。AI事業者がデータを保持しない場合、企業は自社側で必要な監査ログを整備する必要があります。誰が、いつ、どの目的で、どのAIに、どの分類のデータを入力し、どの出力を業務に使ったのか。これを自社側で追えなければ、ゼロデータ保持で外部保存を減らしても、内部統制としては不十分です。特に、顧客対応、採用、人事評価、与信、医療相談、法務、セキュリティ判断に関わる利用では、自社側の説明責任が残ります。

第四に、高リスク用途では人の承認を組み込むことです。AIが出した要約や提案は、便利な下書きであっても、最終判断ではありません。たとえば、医療や健康に関する内容は医療機関や専門家、法律に関する内容は弁護士や公式情報、金融や投資に関する内容は公的開示や専門家、雇用や人事に関する内容は社内規程と責任部署、セキュリティ対応は担当チームと公式ガイドラインで確認する必要があります。AIの利用規程には、この線引きを明記するべきです。

企業AI導入前にデータ分類、保存期間、権限管理、安全監視、人の承認を確認する流れ

OpenAIとAnthropicの違いから見える企業の選び方

OpenAIとAnthropicのデータ保持をめぐる違いは、企業にとって比較材料になります。ただし、どちらが常に正しいという話ではありません。扱うデータ、使うモデル、業務のリスク、監査要件、契約条件によって適した設計は変わります。

OpenAI側の強みとして見えやすいのは、ゼロデータ保持や企業向けデータ管理を前面に出し、顧客がデータを保持しない構成を選びやすくしている点です。企業の機密情報や顧客データを扱う場合、外部サービス側に中身を残さない選択肢は大きな安心材料になります。特に、APIを使って自社システムにAIを組み込む企業では、データ保持の設定が契約や監査に直結します。

一方、Anthropic側のCovered Modelsのように、一定期間の保持を明示して安全監視に使う設計にも理由があります。強力なモデルの悪用は、単発の入力だけでは見つけにくい場合があります。多数のやり取り、時間差のある行動、外部ツール利用、言い換え、回避的なプロンプトを横断して見る必要があるなら、一定のログ保持が安全上必要だという考え方です。これは、金融機関の不正検知やセキュリティ監視で、一定期間のログ分析が重要になるのと似ています。

企業は、この違いを「保存しないから良い」「保存するから悪い」と短絡しない方がよいでしょう。確認すべきなのは、自社の用途に対して、どのリスクを誰が引き受ける設計かです。外部AI事業者が保存しないなら、自社側のログ、監査、誤用検知、ポリシー教育を強める必要があります。外部AI事業者が一定期間保存するなら、保存範囲、アクセス条件、削除条件、暗号化、監査ログ、地域、第三者提供、法的要請への対応を確認する必要があります。

また、同じ会社の中でも製品によって条件は異なります。ChatGPTの個人向けプラン、ChatGPT Enterprise、ChatGPT Business、API、医療向け、教育向け、開発者向け、エージェント機能、外部コネクタでは、データの扱いが違うことがあります。Anthropicでも、通常モデルとCovered Models、API、Claude for Work、Claude Code、クラウド経由の提供では条件が異なります。導入前の比較表には、会社名ではなく「製品名・モデル名・機能名・データ保持条件」を並べるべきです。

企業が最初に作るべき確認表

企業AIの導入で最初に作るべきものは、複雑な技術資料ではなく、現場が読める確認表です。確認表には、少なくとも次の項目を入れると実務に使いやすくなります。

利用目的: 要約、翻訳、検索、コード生成、顧客対応、契約確認、採用補助など
入力してよいデータ: 公開情報、社内一般資料、顧客情報、個人情報、機密情報など
入力してはいけないデータ: パスワード、認証情報、未公開決算、医療情報、本人確認書類など
使用できるAIサービス: 承認済み製品、モデル、機能、外部コネクタ
データ保持条件: 保存なし、30日、業務上の保存、例外条件、削除方法
権限: 利用者、管理者、監査担当、承認者
ログ: 何を自社側に残すか、誰が見られるか、何日保存するか
人の確認: どの出力は必ず人が確認するか
禁止用途: 高リスク判断、本人同意のない個人情報処理、外部送信、秘密情報の入力など
事故時対応: 誤送信、情報漏えい疑い、危険出力、権限逸脱時の連絡先

この確認表は、情報システム部門だけで作ると現場で使われにくくなります。法務、セキュリティ、個人情報保護、事業部門、人事、広報、顧客対応、内部監査など、実際に影響を受ける部門と一緒に作る必要があります。特に、中小企業では専任部門が少ないため、最初は簡単な表でもかまいません。重要なのは、誰が見ても「この用途なら使ってよい」「このデータは入れてはいけない」「この出力は人が確認する」と分かる状態にすることです。

個人利用者が確認すべきこと

個人でAIを使う場合も、考え方は同じです。AIサービスに入力する前に、その情報が自分だけのものか、他人の情報を含むものか、会社や取引先の情報か、削除できないと困るものかを確認します。履歴を残さない設定、データ利用のオプトアウト、チャット削除、ファイル削除、共有リンクの扱い、外部アプリ連携の権限は、サービスごとに確認しましょう。

特に注意したいのは、会社の資料を個人アカウントで扱うことです。たとえ悪気がなくても、会社が承認していないAIサービスに社内資料や顧客情報を入力すると、情報管理上の問題になる可能性があります。会議資料、顧客リスト、契約書、未公開の企画、採用候補者の情報、従業員情報、障害対応メモ、ソースコード、認証情報は、個人判断で外部AIに入れない方が安全です。

また、AIの回答を過信しないことも重要です。医療、法律、金融、税務、雇用、教育、住宅、保険、セキュリティ、災害対応のような領域では、AIは情報整理の補助にとどめ、最終判断は公式情報や専門家に戻してください。AIが自信ありげに答えても、最新制度、地域差、契約条件、本人の事情、法的責任まで正しく反映しているとは限りません。

報道を読むときの注意点

AI企業のデータ保持をめぐる報道は、競争の文脈で語られやすくなります。「どちらがプライバシーに強いのか」「どちらが安全を重視しているのか」「どちらが企業顧客を奪うのか」という見方です。この視点はニュースとして分かりやすい一方で、実務判断には少し粗い場合があります。

第一に、報道時点の情報と正式な契約条件を分ける必要があります。新しい技術が試験中である場合、利用できる顧客、対象製品、地域、機能、料金、監査条件は限定されることがあります。記事を読んで導入を決めるのではなく、最新の公式ドキュメント、契約書、データ処理補遺、セキュリティ資料、サポート窓口で確認する必要があります。

第二に、企業の説明は変わることがあります。AIモデルの能力、規制、裁判、サイバー攻撃、顧客要望、各国のデータ保護法、クラウド提供形態が変われば、データ保持の条件も変わります。2026年時点のゼロデータ保持や30日保持の説明も、将来のモデルや機能にそのまま当てはまるとは限りません。導入後も、少なくとも四半期ごと、または重要機能追加のたびに見直す仕組みが必要です。

第三に、データ保持だけを見ても十分ではありません。AI導入では、入力データ、出力の品質、誤情報、著作権、説明責任、バイアス、外部ツール権限、費用、可用性、ベンダーロックイン、従業員教育、事故時対応まで関係します。データ保持は重要な入口ですが、それだけで安全なAI利用が完成するわけではありません。

日本企業にとっての実務的な意味

日本企業にとって、このニュースの意味は明確です。AI導入は、ツール選定だけでなく、データ管理と責任設計の問題になっています。これまでは、生成AIを使うかどうか、どのモデルが賢いか、どのサービスが安いかが話題になりがちでした。今後は、どのデータを扱えるのか、どの保存条件なら社内規程に合うのか、どの出力を誰が承認するのか、事故時に誰が説明するのかがより重要になります。

まず、会社として承認済みAIの一覧を作るべきです。無料ツール、個人契約ツール、法人契約ツール、API、ブラウザ拡張、議事録ツール、翻訳ツール、コード補助ツール、画像生成ツールなどを分けて、入力してよいデータの範囲を明示します。AIという名前が付いていない機能にも注意が必要です。メール、ドキュメント、CRM、チャット、カレンダー、会議、検索、広告、採用管理などにAI機能が組み込まれている場合があります。

次に、データ分類を現場向けに簡略化します。たとえば、公開情報、社内一般情報、社外秘、個人情報、機密情報、高影響情報のように分類し、それぞれAI入力の可否を決めます。難しすぎる分類は使われません。現場が迷ったら、より慎重な区分として扱うルールを入れると運用しやすくなります。

さらに、社内研修では「AIに入れてよい例」と「入れてはいけない例」を具体的に示すことが重要です。抽象的に「機密情報を入れない」と言っても、現場では判断が割れます。顧客名を伏せればよいのか、契約金額はよいのか、社内議事録はよいのか、匿名化した採用データはよいのか、外部に出してよい商品情報はよいのか。こうした例を業務ごとに示すことで、AIの利用は止めずにリスクを減らせます。

これから注目すべき点

今後注目すべき点は、Private Safety Processingのような仕組みが、どこまで実用化され、どの範囲で提供されるかです。企業向けAPIだけなのか、ChatGPT EnterpriseやBusinessにも広がるのか。対象モデルは何か。安全検知のためにどのようなメタデータやアラートが残るのか。顧客はそのログを監査できるのか。誤検知や過検知が起きた場合、業務が止まるのか。これらは導入判断に関わります。

また、各社のデータ保持競争は、価格や性能競争と同じくらい重要になる可能性があります。企業は、少し性能が高いモデルよりも、自社の規制や監査に合うモデルを選ぶ場合があります。医療、金融、公共、教育、製造、法律、セキュリティのような分野では、データの扱いが契約の決め手になることもあります。AI事業者にとって、プライバシーと安全の説明は、単なる補足資料ではなく、製品価値そのものになっていくでしょう。

ただし、企業側も受け身ではいられません。AI事業者の説明を待つだけではなく、自社の要求事項を明確にする必要があります。ゼロデータ保持が必要な業務、30日保持でも許容できる業務、自社内保存が必要なログ、外部送信禁止のデータ、専門家確認が必要な出力を定義し、購買や契約の条件に入れるべきです。

まとめ

OpenAIのゼロデータ保持とPrivate Safety Processingをめぐる報道は、企業AIの次の焦点を示しています。AIは便利であるだけでは導入できません。安全に監視できるだけでも不十分です。これからの企業AIでは、データをできるだけ残さない設計、危険な使い方を見つける仕組み、社内側のログと承認、人の最終確認を組み合わせる必要があります。

ゼロデータ保持は強力な選択肢ですが、魔法の言葉ではありません。対象製品、対象モデル、対象機能、例外条件、外部ツール、ログ、契約、地域、削除方法まで確認して初めて意味を持ちます。30日保持のような安全監視重視の設計も、目的とアクセス制御が明確なら選択肢になり得ます。大切なのは、会社名や宣伝文句ではなく、自社のデータと業務に合う条件を見極めることです。

AIを止めるか使うかではなく、どこまで任せ、どこで止め、誰が確認するか。今回のニュースは、その問いを企業と個人の両方に突きつけています。医療、法律、金融、雇用、契約、安全、セキュリティのような高影響領域では、AIの回答を最終判断にせず、公式情報、専門家、社内規程、責任部署に戻る仕組みを前提にしてください。便利さは、安全と説明責任の設計があって初めて長く使えるものになります。