AI APIのデータ保持と企業プライバシー審査｜一次資料で確認する12問

「API経由なら学習されないから、データは残らない」は本当ですか。

「API経由なら学習に使われないのだから、データも残らない」という理解は、後半が成り立ちません。学習への利用とデータの保持は別の軸です。入力と出力を既定では学習に使わないという定めは主要事業者の公式ページにあり、ここは事実です。一方で、不正利用の監視や安全性の確認のために一定期間は内容を保持する運用が一般的で、何日残るかは事業者、契約プラン、使う機能で変わります。審査で先に確定させるのは「何が、どこに、いつまで残り、誰が見られるか」です。

学習利用と保持は、別の軸です

学習に使わないと明記している事業者でも、不正利用の検知や障害対応のためにリクエストを一定期間保存します。保持期間が短いからといって、学習利用の条件まで同じとは言えません。

保持の既定値は、事業者とプランと機能で変わります

一律の日数はありません。

2026年9月24日時点で公表されている例では、OpenAIが不正利用の監視を目的としてプロンプトと応答を最大30日間保持し、保持ゼロはその保持を外す選択肢として説明されています。GoogleのGemini Enterprise Agent Platformでは、保持ゼロにするために領域ごとの設定や例外申請が必要で、一部の高度な機能や検索・地図のグラウンディングは保持ゼロにできないとされています。

効くのは機能単位の洗い出しです。同じ契約の中でも、状態を持つ機能や検索連携を使うと保持の扱いが変わります。たとえば、要約だけに使っていたAPIを、社内文書を検索させる構成に広げたときです。契約全体の可否より、「この機能はどちら側か」の一覧のほうが判断に使えます。

セキュリティチェックシートに使う12問は、何を確認しますか。

確認するのは、入力・出力・会話の記録と学習利用、システムログの項目と保持期間、削除とアクセス制御、暗号化、保存・処理地域、委託先責任、DPA、SLA、監査報告、インシデント通知の12項目です。どの問も、資料で確認できるもの、契約で確認するもの、いまは答えが示されていないもののどれに当たるかを併記し、あとから根拠をたどれる形にします。

各行に置く5つの欄

12問は、確認する問い、分類、確認する一次資料、記録する根拠、答えが示されていない場合の質問の5列で並べます。

• 確認する問い：何を確かめたいのかを一文で書きます。
• 分類：資料で確認できるもの、契約で確認するもの、いまは答えが示されていないもののどれか。
• 確認する一次資料：公式ドキュメント、セキュリティFAQ、契約条項、提供される監査報告のどれを見たか。
• 記録する根拠：読み取れた事実を短く写し、判定日とURLを添えます。
• 答えが示されていない場合の質問：回答が出たあとそのまま回せる文面にしておくと、法務とベンダーの両方に渡せます。

分類の欄が埋まっていると、どの資料まで遡ればその問いが埋まるのかが一目で分かります。

3つの分類で、質問先を決める

• 資料で確認できる問い：URLと判定日があれば、そのまま根拠になります。
• 契約で確認する問い：条項の版と締結単位を書きます。
• いま答えが示されていない問い：質問文だけを残し、未確定のままにします。

3つを分けておくと、法務に渡したときに確認済みと要確認の区別がそのまま伝わります。

入力・出力・会話データの学習利用は、どこまで確認できますか。

APIや法人プランでは、送信したデータを既定では学習に使わないとする記載が主要事業者の公式ページにあります。適用はプラン単位で、個人向けの画面はまた別の条件です。

既定は「学習に使わない」、適用はプラン単位です

OpenAIは、ビジネスデータとAPIプラットフォームのデータを既定ではモデルの学習や改善に使用しないと説明しています。Googleも、明示的な許可や指示がある場合を除いて、顧客データをモデルの改善に使わないと説明しています。いずれも対象となるプランとサービスに限った話です。個人向けの画面では、設定を変えない限り会話がモデルの改善に使われ得るため、この2つを同じ前提で社内に説明すると、あとで食い違います。

もし法人プランと個人向けアカウントを同じ社内ルールで扱っているなら、ここを分けて書き直すところから始めます。

オプトインの扱いも確認項目です。

モデルの改善への協力が設定で選べる場合、それが既定で有効かどうか、誰が切り替えられるか、切り替えた範囲がどのデータに及ぶかで、記録すべき根拠が変わります。APIキーやプロジェクトの単位で設定が分かれる事業者もあります。

保持ゼロは、承認された顧客だけが選べる選択肢です

OpenAIは、要件を満たす組織がAPIプラットフォームでゼロデータ保持ポリシーを選択できると説明しており、対象は適格なAPI顧客に限られ、事前の承認が必要とされています。管理画面のスイッチだけで有効になるものではないため、申請と承認の期間を導入計画に織り込みます。削除するまでデータが残る状態保持型の機能が対象外であることも、契約前に一覧にしておく項目です。

Googleの場合は、1つの設定では済みません。監視目的のプロンプト記録は領域ごとの例外申請になり、リクエストとレスポンスの記録機能を有効にしないこと、Interactions APIで保存を明示的に無効にすることなど、領域ごとの操作が必要だとされています。使用中の機能がどちら側にあるかを一覧にしないと、契約した範囲を説明できません。

システムログは何を記録し、誰が触れるのか。

ログは「内容が入るか」と「項目と保持期間」を分けて確認します。運用ログがあることを、そのまま内容の保存と読み替えると、実装と説明がずれます。誰が触れるかは、提供事業者側の役割と、利用企業側のキー管理の両方で決まります。

内容が入るログと、項目だけのログ

不正利用の監視や障害対応のログには、プロンプトや応答そのものが含まれる場合と、時刻や件数、モデル名、ステータスといったメタデータだけの場合があります。前者は内容の保持と同じ扱いになり、後者は内容を残さずに運用を追う仕組みです。どちらなのかは監視に関する説明で確認し、書かれていなければ質問票に入れます。

もし自社のアプリ側でも同じ内容をログに出しているなら、その扱いは自社の設計次第です。

公式ドキュメントに書かれている例

MixRouteは公式ドキュメントで、内容は記録せず、システムログのみを7日間保持するとしています。この記載はMixRouteのデータセキュリティ文書で確認できます。内容を記録しない範囲と、運用に必要なメタデータを残す範囲を分けた書き方で、審査ではこの分け方自体が根拠になります。自社が使う機能がこの範囲に入るかどうかまで、同じ粒度で見ておくと後から説明がぶれません。

アクセス制御は、キー単位の制御まで確認する

アクセス権限は、提供側の運用体制と、自社側のキー管理という2つの層に分けて考えます。MixRouteは公開されたAPIドキュメントで、APIキーごとに呼び出せるモデルの制限、あらかじめ割り当てて使った分だけ減る予算、IPアドレスの許可リスト（CIDR対応）、有効期限を設定できるとしています。予算はアカウント残高が常に外側の上限になり、キー側の設定は内側の上限として働きます。許可リストは単独の防御として当てにせず、別の層と組み合わせて使う前提で扱うよう、コンソールの注記で示されています。

通信暗号化・保存地域・委託先は、どの資料で確認しますか。

暗号化はセキュリティページと契約条項、保存・処理の地域はデータ所在地に関する案内、再委託先は委託先一覧とデータ処理契約で確認します。3つとも、記録しておく単位が違います。

• 暗号化：通信はTLS、保存時はAES-256といった方式と、鍵を誰が管理するか。
• 保存・処理の地域：選べるかどうか、選べない場合にどこで行われるか。
• 再委託先：一覧が公開されているか、なければ責任分界と通知の主体。

暗号化は、方式と鍵の持ち主まで書く

「暗号化されています」だけでは審査の根拠になりません。通信の方式とバージョン、保存時の方式、鍵を提供事業者が管理するのか顧客側で持ち込めるのかを分けて記録します。OpenAIは、保存時にAES-256、転送時にTLS 1.2以上を使用し、対象の顧客は自社の暗号化キーを管理できると説明しています。鍵の持ち主が変われば、インシデント時の影響範囲の説明も変わります。

保存地域は「選べるか」と「選べない場合の場所」

OpenAIは、対象となる法人プランとAPIの顧客向けに、米国、欧州、英国、日本、カナダ、韓国、シンガポール、オーストラリア、インド、UAEでの保存を案内し、対象の顧客は米国または欧州での推論も選べるとしています。対象プランとエンドポイントに限られるため、自社の契約と利用エンドポイントが対象に入るかを確認します。

選べない場合は、実際の保存先と処理の実施国を一覧にします。

日本企業が海外事業者にデータを渡す構成では、保存先と処理の実施国を書き出したうえで、外国にある第三者への提供の扱いを法務に確認する項目として渡します。同意の要否や適法性の判断は、エンジニアと事業部門だけで決められるものではなく、法務に渡す項目です。確認の工程を開発の最初に入れておくと、実装が終わってから止まりません。

顧客との契約でデータの所在を聞かれるチームは、保存地域が選べるかどうかを先に確かめておくと説明が早いです。

再委託先は、一覧の有無から確認する

提供事業者がさらにどのクラウド基盤を使っているかは、委託先の一覧やデータ処理契約の記載で確認します。一覧が公開されていない場合は、インシデント発生時の責任分界と通知の主体を契約で確認する項目に変えます。委託先が変わったときに通知されるかどうかも、運用が長くなるほど効いてきます。

DPA・SLA・監査報告・インシデント通知は、公開されていますか。

DPA、SLA、第三者監査報告、インシデント通知の条項は、公式サイトに置かれている場合と、NDAの下で個別に提供される場合、いまは答えが示されていない場合に分かれます。契約形態と利用予定プランの条項を単位に確認します。

3つの区分に分ける

セキュリティ認証の取得状況は公式サイトで確認できる場合があり、監査報告そのものはNDAの下で提供されるのが一般的です。DPAとSLAは契約時に締結し、インシデント通知は期限と経路が条項に書かれます。どれが表に出ていて、どれが請求すれば出るのかを先に確定させると、質問が契約項目に絞られます。

適用範囲も確認します。

監査報告は対象となるサービスや拠点が限定されていることがあり、自社が使う機能が対象に入っているかで意味が変わります。取得している認証名だけを社内資料に写すと、範囲の説明が抜けます。

契約形態とプランを単位に確認する

同じ事業者でも、契約の区分によって提供される資料と条項が変わります。DPAやSLAの有無、監査報告の提供方法、通知の期限は、利用予定のプランに紐づけて確認します。確認したい資料が決まったら、自社のプランの区分と提供条件を一覧にしておくと、法務への説明が一度で済みます。プランの区分と提供条件を確認する

確認で埋まらなかった項目は、どう質問すればよいですか。

問い合わせでは、対象業務、送るデータ項目、契約形態、利用予定の機能を並べ、保持期間、学習利用、削除、アクセス制御、保存地域、委託先を一問ずつ確認します。回答は記録として残し、資料で確認した範囲と契約で確認した範囲を分けて保管します。

質問文に添える4点

対象業務、送るデータ項目、契約形態、利用予定の機能の4点です。この4点がないと「一般的にはこうです」という回答しか返ってきません。4点が揃っていれば、回答が自社の構成に当てはまるかを判断できます。データ項目は、氏名、メールアドレス、注文履歴といった単位まで細かく書きます。「顧客情報」という括りでは、回答が自社の構成に当てはまるかを判断できません。

質問は一問ずつ投げます。

保持期間と学習利用を同じ文に入れて尋ねると、片方だけの回答で会話が終わり、もう片方が宙に浮きます。保持期間、学習利用、削除の手順と完了確認、アクセス権限、保存・処理地域、再委託先の6つを、それぞれ別の行として用意します。

回答は、判定日と出典とセットで残す

回答は、誰が、いつ、何に対して答えたかが分かる形で残します。資料で確認した項目はURLと判定日（この確認では2026年9月24日）、契約で確認した項目は条項の版と締結単位、未回答の項目は質問文のまま保管します。次に同じ審査が来たときに、前回の回答と公式サイトのどちらが新しいかを比べられます。

未回答が残っていても、開発を止める必要はありません。どの機能が未確認のまま使われているかを一覧にしておけば、確認が取れた範囲から先に進み、取れない範囲だけを切り離せます。契約条件と未回答項目の回答を一度に確認したいときは、自社の構成に合わせた確認項目を依頼するところから始められます。