「データを残さない」契約の落とし穴｜ゼロデータ保持の対象外になる機能を先に確認する

出発点：公式ドキュメントに書かれている条件

金融、医療、法務、人事、研究開発など、機密性の高いデータを扱う企業が生成AIを導入する際、最初に確認されるのが「入力したデータは保存されるのか」「学習に使われるのか」という点です。

OpenAIの開発者向け公式ドキュメントには、次の条件が記載されています。

• 2023年3月1日以降、APIへ送信されたデータは、明示的にデータ共有へ同意しない限り、モデルの訓練や改善には使用されない
• 不正利用の監視のためのログは通常最大30日間保持される。法律でより長い保持が必要とされる場合のほか、サービスや第三者を害から守るために合理的に必要な場合にも、より長く保持され得る
• 対象となる顧客は、ゼロデータ保持（Zero Data Retention）などの統制の承認を受けることで、この不正利用監視ログから自社のコンテンツを除外できる
• これらの統制は現時点でOpenAIによる事前承認と、追加要件への同意が前提となる

つまり、既定の状態でも学習には使われないが、監視目的のログは一定期間残る。そのログから自社のコンテンツを除外する設定にするには、申請と承認が要る、という構造です。ここで確認しておきたいのは、ZDRが「ログを一切作らない」設定ではなく、「不正利用監視のログから顧客コンテンツを除外する」統制として定義されている点です。また、特定の顧客やモデルについては別の扱いになる条件も文書に記載されています。

2026年8月19日の発表が追加した論点

OpenAIは2026年8月19日、フロンティアモデル向けZDRと、安全監視を両立させるPrivate Safety Processingを発表しました。公式発表から確認できる範囲は次のとおりです。

重要な例外もあります。公式発表の脚注では、児童性的虐待素材（CSAM）の疑いがある画像は、ZDRであっても保持、人による確認、関係機関への報告の対象になり得るとされています。したがって、「ZDRならいかなる場合も保持・閲覧されない」と契約や社内説明へ書いてはいけません。例外は公式文書と自社の契約条件で最終確認してください。

見落とされる「対象外」の一覧

実務上もっとも重要なのは、ゼロデータ保持の対象にならないエンドポイントが明示されている点です。公式ドキュメントは、対象外として次を列挙しています。

/v1/conversations
/v1/conversations/items
/v1/chatkit/threads
/v1/assistants
/v1/threads
/v1/threads/messages
/v1/threads/runs
/v1/threads/runs/steps
/v1/vector_stores
/v1/files
/v1/fine_tuning/jobs
/v1/evals
/v1/batches
/v1/videos

技術用語が並んでいますが、経営判断としての意味は明確です。可否はエンドポイント単位で決まっており、用途の名前では決まらないということです。会話の履歴を保持する機能、ファイルをアップロードする機能、事業者側に検索用のデータを格納する機能、まとめて処理する機能が対象外として列挙されています。一方で、文章をベクトルに変換する処理（/v1/embeddings）は対象に含まれると記載されています。

ここに実務上の分岐点があります。社内文書を生成AIに検索させる、いわゆるRAGの構成でも、事業者側にファイルとベクトルストアを置く実装と、変換処理だけを利用して検索用のデータは自社側に持つ実装では、結論が変わります。前者は上記の一覧に含まれる機能を使い、後者は必ずしも使いません。

したがって、「ゼロデータ保持で契約したから社内文書を入れても安全」という説明は、それだけでは成立しません。契約の名前でも用途の名前でもなく、実装がどのエンドポイントを呼んでいるかで決まります。

確認すべき8項目

生成AIを業務に入れる際、事業者や委託先へ確認する項目を整理します。製品名にかかわらず共通して使えます。

7番目が、本記事で強調したい項目です。この質問を投げると、事業者ではなく自社の開発担当者や委託先が答えることになります。なぜなら、どの機能を使っているかは実装側の情報だからです。

「安全ですか」という一問では比較できません。提案を受けた構成が次のどこに当たるか、根拠資料とともに回答してもらいます。

4は常に3より優れているという順位ではありません。保持場所、調査可能性、鍵管理の負担、費用を自社要件に照らして選びます。Private Safety Processingと顧客管理鍵の方式は、2026年8月23日時点では今後の提供・開発に関する発表であり、現在使える前提には置けません。

また、確認先は二層あります。

「モデル提供者は学習に使わない」という説明だけでは、開発会社側のデータベースやログに何が残るかは分かりません。一次・二次・接続の三行が揃って、初めて実装と契約を照合できます。

社内での確認手順

1. 利用中のAI機能を一覧化する。部門ごとに聞き取り、業務名と用途を書き出します。
2. 各機能について、実装がどのAPIや機能を使っているかを確認する。自社開発なら開発者へ、委託なら委託先へ確認します。
3. 対象外の機能を使っているものを特定する。これが優先確認の対象です。
4. そこで扱っているデータの機微度を確認する。個人情報、顧客の非公開情報、未公開の技術情報が含まれるかを見ます。
5. 対応方針を決める。構成を変える、扱うデータを制限する、そのまま受け入れる、のいずれかを記録に残して決めます。

5の「そのまま受け入れる」も正当な選択肢です。重要なのは、知らないまま使っている状態から、知ったうえで決めた状態へ移すことです。

規制業種で追加される論点

金融、医療、公共など、業界固有の規制がある場合は、上の8項目に加えて次を確認します。

• 委託先管理の枠組みで、その事業者を評価できているか
• 再委託が発生する場合、その一覧と承諾の要否
• 監査の際に、事業者から提出される資料は何か
• 事故が起きた場合の通知の条件と時限
• 契約終了時のデータの取り扱い

これらは生成AI特有の論点ではなく、従来の外部委託と同じ枠組みです。生成AIだからといって、既存の委託先管理の外に置く理由はありません。逆に、既存の枠組みに載せられないサービスは、その時点で採用の可否を検討する材料になります。

「安全な構成」と「使える構成」の折り合い

データを一切外部に出さない構成を選べば、確認項目は減ります。しかし、その場合は使えるモデルや機能が限られ、費用も変わります。実務では次の順で折り合いを付けるのが現実的です。

第1段階：扱うデータを分類する。公開情報、社内情報、機微情報の3つで十分です。 第2段階：機微情報を扱う用途を、当面は対象から外す。効果が大きい用途であっても、確認が終わるまでは外します。 第3段階：社内情報を扱う用途について、上記8項目を確認する。 第4段階：確認が終わった範囲から順に広げる。

この順序であれば、確認作業が終わるのを待たずに導入を進められます。全社で一斉に始めようとすると、確認が終わるまで何も動きません。

データ区分と用途の切り分けを一緒に作るならAI導入可否アセスメント、社内データの保管と連携から見直すならデータ活用基盤構築で扱います。セキュリティ全体の中での位置づけを決めたい場合はセキュリティ対策の優先順位整理が該当します。

稟議書に載せる5行

技術資料をそのまま添付するだけでは、決裁者は判断できません。最低限、次の5行を埋めます。

「安全性を確認済み」と一行で済ませず、誰が何を根拠に確認したかまで残すことが、ベンダー変更や監査で効きます。

契約書と実装のずれが生まれる場面

契約時には条件を確認したのに、稼働後にずれが生じることがあります。発生しやすい場面を挙げます。

場面1：機能を追加したとき 最初は文章の生成だけだったところに、ファイルのアップロード機能や履歴の保持機能を追加すると、使うエンドポイントが変わります。契約は変わっていないのに、条件の適用範囲が変わります。

場面2：開発の担当が変わったとき 実装の経緯を知らない担当者が引き継ぐと、当初の制約が伝わりません。「なぜこの機能を使っていないのか」が記録されていないと、良かれと思って使い始めます。

場面3：外部の開発会社を変えたとき 新しい事業者は、前任者が避けていた構成を採用する可能性があります。引き継ぎ資料に、条件と、その条件のために避けている実装を明記しておく必要があります。

場面4：サービス側の仕様が変わったとき 提供事業者が新しい機能を追加し、既存の機能の位置づけが変わることがあります。契約更新時だけでなく、事業者からの通知を受け取る仕組みが要ります。

対策は共通しています。「この構成では、この機能を使わない」という判断そのものを記録に残すことです。判断の理由が残っていれば、担当が変わっても維持されます。

社内規程に落とす際の記載例

生成AIの利用について社内規程を整備する場合、条件を細かく書きすぎると、サービスの仕様変更のたびに改定が必要になります。実務的には、規程には原則だけを書き、具体的な条件は別紙で管理する形が維持しやすくなります。

規程本文に置く内容の例：

• 業務で利用する生成AIサービスは、事前に申請し承認を得ること
• 入力してよい情報の区分は別に定める
• 承認された用途以外に利用しないこと
• 利用状況は定期的に報告すること
• 条件に変更が生じた場合は速やかに報告すること

別紙に置く内容の例：

• 承認済みサービスの一覧と、それぞれの用途
• 情報区分ごとの可否
• サービスごとの確認済み条件（保存、学習利用、保存場所）と確認日
• 禁止する利用方法の具体例

別紙は更新頻度が高いため、規程本体とは別に、担当部門が改定できる形にしておきます。

従業員への説明で伝えるべきこと

規程を作っても、現場が理解していなければ守られません。説明する際は、禁止事項の列挙ではなく、次の3点を伝えるほうが定着します。

1. なぜ制限があるのか 顧客との契約や、業界の要求で、データの取り扱いに条件があることを説明します。会社の都合ではなく、取引を続けるための条件であることが伝わると、納得感が違います。

2. どこまでなら使ってよいのか 禁止事項だけを伝えると、現場は萎縮して一切使わなくなります。使ってよい範囲を明示するほうが、実際の業務改善につながります。

3. 迷ったときに誰に聞くのか 判断に迷う場面は必ず出ます。聞く先が明確であれば、勝手な判断が減ります。

事故が起きた場合の初動

入力してはいけない情報を入力してしまった、という事態は起こり得ます。そのときの手順を先に決めておいてください。

1. 何を、いつ、どのサービスへ入力したかを記録する
2. 該当サービスの契約条件を確認する（保存の有無、期間）
3. 事業者へ削除の可否と手続きを問い合わせる
4. 情報の内容に応じて、社内の報告先へ連絡する
5. 対象となる情報の関係者への連絡の要否を検討する
6. 再発防止として、規程または実装のどちらを直すかを決める

6番目が重要です。人の注意で防ぐ設計にしていると、同じ事故が繰り返されます。入力できない仕組みにできるのであれば、そちらを優先してください。

FAQ

Q1. ゼロデータ保持を申請すれば必ず適用されますか

公式ドキュメントには、事前の承認と追加要件への同意が前提と記載されています。申請すれば自動的に適用されるものではありません。適用条件は事業者へ直接確認してください。

Q2. 対象外のエンドポイントを使わなければRAGは構築できませんか

構築できます。公式の一覧では、文章をベクトルに変換する処理は対象に含まれています。検索用のデータを自社側に持つ構成であれば、対象外として列挙されている機能を必ずしも使いません。どの構成を採るかは、性能、費用、運用負荷との兼ね合いで決まるため、要件を先に整理してから比較してください。

Q3. 既定でも学習に使われないなら、それで十分ではありませんか

学習利用と保存は別の論点です。学習に使われなくても、一定期間ログが保持される場合があります。どちらを問題視するかは、扱うデータと社内規程によって異なります。

Q4. 他社のサービスでも同じ確認が必要ですか

必要です。既定値も選べる範囲も、提供事業者ごとに違います。サービスの名前ではなく、自社が結んでいるプランの条件と、実装が呼び出している機能の両方を見てください。

Q5. すでに数か月使っています。今から確認する意味はありますか

あります。過去に入力したデータの扱いと、今後の扱いを分けて確認してください。保持の期間と削除の方法は機能ごとに異なり、明示的に削除するまで残るものもあれば、一定期間で削除されるものもあります。どちらに当たるかを確認したうえで、必要な対応を決めてください。

参考情報

• OpenAI 開発者向けドキュメント Your data
• OpenAI「Offering Zero Data Retention for frontier models」（2026年8月19日）
• GXO AI導入可否アセスメント
• GXO データ活用基盤構築

本文の条件および対象外エンドポイントの一覧は、OpenAIの開発者向けドキュメントを本記事の公開日に参照して書き起こしたものです。2026年8月19日の発表事項は同社公式ページを2026年8月23日に再確認しました。提供条件は変更される可能性があるため、契約や設計の判断前に最新のドキュメント、発表ページおよび契約条件を確認してください。