LLM APIのデータ保持とZDR：稟議で使える確認手順

LLM APIの選定では、保存目的と期限が自社の条件に収まるなら通常保持を選び、提供側での内容保存を認められないならZDR（ゼロデータ保持）の適用範囲を確認する、という順番が実用的です。「学習に使われない」だけでは、入力や応答がサーバーに残らないとは判断できません。

稟議で必要なのは、ベンダー名に丸を付けることではありません。どの契約が、どの組織・プロジェクトに適用され、どのモデル、API、追加機能を使うのか。中継サービスと自社のログを含め、内容が残る場所を一つずつ説明できることです。

まず「誰による、何の保存を禁止するのか」を決めてください。提供側の永続保存を禁止する条件と、顧客管理のストレージも含めてどこにも内容を残せない条件では、同じZDRという名称でも採用判断が変わります。以下は2026年10月6日に確認した公式資料に基づく、導入時の確認方法です。個別テナントへの適用、実データの削除、法的な適合性を認定するものではありません。

通常保持とZDRは、送信データの条件から選ぶ

期限付き保持を許容する用途では、期間、目的、閲覧権限、削除方法を明示した通常保持の経路が候補になります。公開情報の要約や架空データによる試作でも、社内の指示文や識別子を付けると、その部分は公開情報ではなくなるため、実際の送信内容で判断します。

これはデータ分類だけで結論を固定する表ではありません。たとえば社内規程が未公開仕様の30日保存を認め、契約と全保存先を確認できるなら、通常保持として審査できます。逆に、公開資料の処理でも取引先名を含む指示文の保存が契約で禁止されていれば、その送信内容には別の条件が必要です。

判定の例を二つ考えます。どちらも説明用の架空のケースです。

• 公開マニュアルの分類：入力を公開資料と固定の指示文に限定し、契約で許容した目的の30日以内の保存、自社ログの本文除去を確認できた場合、通常保持で承認する余地があります。会話履歴を無期限に残す機能を加えるなら、この承認のままでは使えません。
• 顧客の未公開契約の要約：業務条件が「外部処理者での内容の永続保存なし」なら、ZDR契約と実際のモデル・機能を照合します。顧客管理の安全確認用保存を認めるかどうかも別に決めます。契約にZDRと書かれていても、この条件が曖昧なままでは判定できません。

秘密鍵やアクセストークンは、どちらの経路でも入力から除去します。保持条件は、送信してよい情報の範囲を広げる許可ではありません。

「学習に使わない」「保存しない」「削除する」を分ける

稟議書の「データ保持」という一欄には、異なる処理が混ざりがちです。次の六項目で記録すると、どこに通常保持の期限を設定し、どこにZDRの確認が必要かを整理できます。これは保存先の見落としを減らすための整理方法で、認証規格ではありません。

学習利用を止めても、安全監視の記録や会話状態が消えるとは限りません。また、削除APIがあることは「作成時から保存しない」ことと別です。暗号化されていても、保存された内容には保存先と期限があります。

ZDRが対象とする内容の範囲も明記します。本文、識別可能なメタデータ、集計値、スキーマ、一時メモリーをすべて同じものとして扱うと、業務の要求とサービスの定義を比較できません。規程が本文の永続保存だけを禁止するのか、一時メモリーや技術的なメタデータにも条件を課すのかを、承認者と先に合わせます。

公式資料で確認すべき適用範囲

サービス全体に「ZDR対応」と書く代わりに、利用予定の経路に当てはまる箇所を引用し、契約と設定に照合します。ここでは承認判断を変える差分を示します。モデルや機能の全一覧を置き換える表ではありません。

OpenAI：組織・プロジェクトとAPI機能を照合する

OpenAI APIは、明示的に同意しない限りAPIデータを学習に使いません。一方、通常の不正利用監視ログは原則最大30日で、法律やサービス保護に関する例外があります。ZDRとModified Abuse Monitoringは承認が必要です。プロジェクトの設定が組織の設定を継承しているかも確認します。ZDRではResponsesとChat Completionsのstoreがfalseとして扱われますが、対象外のAPIが管理する状態までなくなるわけではありません。OpenAIのデータ管理資料

確認する順番は、契約対象の組織、実際のプロジェクト設定、モデル、API、追加機能です。Filesや会話管理などの対象外機能、バックグラウンド処理、外部MCP、画像・ファイルの安全確認例外は、使うものだけを公式の対象表に照合します。モデル固有の適格性も確認し、「同じAPIだから今後の全モデルも対象」とは記録しません。API別の保持条件

ZDR with PSP：顧客管理ストレージへの保存もある

OpenAIのZDR with Private Safety Processing（PSP）では、選ばれたやり取りと安全確認結果が暗号化され、顧客が管理するストレージに30日のTTLで保存されます。OpenAI側には運用上の参照情報などがあり、ハードウェアで保護された環境が自動で確認します。したがって、提供側に内容のコピーを保持させない条件と、どこにも内容を永続保存しない条件は同じではありません。PSPの公式説明

顧客管理の保存を認める場合は、バケット、TTL、アクセス権、鍵の管理者を稟議の保存先一覧に追加します。鍵の失効は記録の削除を意味しません。PSPの暗号化と保存

OpenAI管理のストレージで保存するPrivate Retention with PSPは、顧客管理のZDR with PSPとは別の保持区分で、ZDRではありません。OpenAIの保持区分

Claude：リクエストが成功してもZDRの対象外になり得る

Claude APIのZDRは組織ごとの適用です。30日保持が必要なモデルもあるため、モデル・機能を照合します。機能欄がNoの呼び出しも自動拒否されず、その機能の条件で処理され得ます。成功応答はZDRの適格性を証明しません。Claude APIのデータ保持資料

適格な機能でも、構造化出力のスキーマやキャッシュ診断のハッシュなどが残る条件があります。スキーマに機密情報を埋め込まず、法令・安全性の保持例外も確認します。Claudeの機能別条件

通常保持について、商用サービスの説明はAPI入出力を原則30日以内に削除するとしていますが、機能別資料は保存を必要としない会話内容やモデル別の条件を分けています。最大削除期間を、すべてのリクエストが必ず保存される期間と読み替えず、使用モデル・機能・契約に沿って確認します。商用サービスの保持期間

Gemini：Developer APIとVertex側の条件を分ける

現在のGemini Developer APIのZDR資料は、保証されたZDRや企業向けDPAが必要ならVertex AIを使うよう案内しています。有料サービスの入力・応答を製品改善に使わないという条件から、Developer APIの無保存を導くことはできません。同経路のGoogle Search・Mapsによるグラウンディングには無効化できない30日の保存があり、Interactionsの状態保存やFilesなども個別に確認します。Gemini Developer APIのZDR資料

AI Studioなどの製品ログは別欄です。Interactionsは既定でstore=true、Generate Contentは既定でfalseですが、プロジェクトやリクエストの設定で変わります。有効なログは既定55日で、7・14・28・55日を選べます。ログから保存したデータセットは自動失効しません。これは不正利用監視の保持期間と同じ説明ではありません。ログとデータセット

Vertex側を検討する場合も、Google Cloudの条件を読み直します。Cloud側のGoogle Searchグラウンディングは、顧客・利用者に結び付けない派生クエリなどを最大3日保存する説明で、Developer APIの30日とは別です。Mapsは30日です。対象の不正利用監視には例外申請の仕組みがありますが、Advanced AIのモデル・機能には追加の安全性条件があり、ZDR対象とは限りません。Google CloudのZDR資料

Cloudで有効にしたリクエスト・応答ログ、Interactions、エージェントの状態などを、移行前の保存先一覧に追加します。一時RAMキャッシュをGoogleがZDRと両立すると説明していても、自社がメモリーまで禁止する条件にはそのまま適用できません。Cloud側の機能別保存

AzureとBedrock：クラウド側の実効条件を確認する

Azureでは、Microsoftが販売・ホストするモデルの経路を確認します。Azure内の状態を持つ機能や診断ログは別の保存先です。承認済みの監視変更でContentLogging=falseが確認できる場合も、全アプリのログがゼロになるわけではありません。この項目が存在しない状態をfalseとは扱えません。Anthropicが処理するClaude in Microsoft Foundryの条件も、この経路と混同しません。Microsoftのデータ保護資料

Amazon Bedrockでは、モデル提供元が入力へアクセスしないことと、AWSで保存しないことを分けます。現在はRegionと有効な保持モード、モデルのallowed_modesを照合します。noneは永続保存しないモードで、Responsesのstore=trueは拒否され、バックグラウンド処理も使えません。通常のモードではstore=falseでも安全確認用の保持があり得ます。Bedrockの保持モード

対象モデルでnoneが使えない場合は、許可済みモデルへ替えるか、明示的な適用承認を取得するか、送信を見送ります。aws_reviewへ緩めて呼べるようにする操作は、ZDRを満たす修正ではありません。Regionを変えた場合やクロスリージョン推論でも再照合します。自社が有効にした呼び出しログやアプリの保存は、引き続き別に管理します。Bedrockのデータ保持

ゲートウェイを使う場合は、転送先とフォールバックも記録する

ゲートウェイには、モデル切り替えや認証・予算管理をまとめる利点があります。ただし、承認する処理経路にはゲートウェイ自身の保存条件も追加します。

業務アプリ
  → 自社ゲートウェイ
  → 外部の中継サービス
  → 実際に選択された提供元のAPI・モデル・Region
  → 検索や外部ツール

応答・エラー
  → 自社のAPM、トレース、ログ、DB、バックアップ

モデルの別名がどの提供先に解決されるか、混雑・障害時にどこへ切り替わるかを含めて確認します。通常保持の経路なら、切り替え先も許容した期間と目的に収まること。ZDRを必須とする経路なら、非適格な切り替え先へ送らないことが条件です。

OpenRouterのZDR指定は、同社がZDRと分類する推論エンドポイントへのルーティング制限です。アカウント側などで強制した条件をリクエストのfalseで解除することはできませんが、この制限がプラグイン・外部ツールへ自動適用されるとは限りません。BYOKやPrivate Deploymentの申告は、独立した検証済み保証として扱わず、実際の接続先と契約を照合します。OpenRouterのZDRルーティング

中継事業者には、本文、識別子、エラー本文の保存、障害調査時の一時ログ、再委託先、上流の適格性更新を確認します。上流のZDR説明だけで中継事業者の条件を埋めることはできません。本ページでは、適用範囲の証拠がない中継先をZDR必須用途向けに推薦しません。

稟議に添付する記録を、一つの利用経路ごとに作る

文章による規程と実装の設定を結び付けるため、一つの利用経路につき次の記録を作ります。本番と検証環境の組織・プロジェクトが違うなら、適用証拠も分けます。空欄は確認済みを意味しないため、未確認項目には担当者と解決期限を付けます。

利用経路ID／版：
用途／送信可能なデータ：
申請者／承認者／確認日／次回確認期限：

【業務条件】
通常保持 または ZDR：
提供側の本文保存上限：
顧客管理ストレージの本文保存：許可／禁止、上限、目的
自社の本文ログ保存：許可／禁止、上限
メタデータ・スキーマ・一時メモリーの許容範囲：
法令・安全性などの例外に対する判断：

【適用範囲】
契約／DPA／注文書の識別情報と該当箇所：
契約の相手方／実際の処理者：
組織・プロジェクト・ワークスペースの正確なID：
Region／処理先地域：
API・バージョン／モデルID・版：
使用機能／使用禁止機能：
中継先／外部ツール／フォールバック先：

【保存先ごとの記録】
対象データ／目的／保存期間／削除方法／閲覧権限／担当者：
学習・製品改善：
不正利用・安全性の監視：
APIの状態：
追加機能：
中継先・外部ツール：
自社ログ・DB・バックアップ：

【照合資料と結論】
公式URL／確認日／適用する行・条件：
対象IDに結び付いた設定証拠：
自社の本文除去・期限・変更拒否の確認結果：
未確認事項／担当者／解決期限：
判定：通常保持で承認／ZDRで承認／条件付きの保留／不採用
承認するデータと機能／変更時の再確認条件：

保存の記録には、本文が残るのか、内容を含まない運用メタデータだけなのかを具体的に書きます。「暗号化」「管理画面で設定済み」だけでは、保存期限や対象プロジェクトを説明できません。設定証拠には、対象ID、取得日時、取得者を付け、契約の適用先と一致するかを確認します。

たとえば、架空の「マニュアル分類 v1」を通常保持で承認するなら、判定文は次のように書けます。

公開マニュアルと固定指示文のみを送信する。承認済みの契約、プロジェクト、API、モデル、機能に限定し、提供側の保存は承認した目的で30日以内、自社ログには本文を残さない。履歴・ファイル・検索の追加や接続先の変更は再申請する。

30日はこの架空の業務条件であり、全サービス共通の期限ではありません。実際の全保存先がこの条件に収まる資料を添付して、初めて承認候補になります。

オフラインで、許可と拒否の判定を確かめる

実装チームは、承認範囲を設定の一覧として保持し、変更が範囲外なら送信前に止める仕組みを作れます。次はその判断を説明する自社条件の例です。実在のAPIやSDKに接続せず、Node.jsの標準機能と架空のデータだけで実行できます。

import assert from "node:assert/strict";

// この例の値はすべて架空。契約・テナントの実証データではない。
const approved = {
  scope: {
    contract: "demo-contract-v1", org: "demo-org", project: "demo-project",
    region: "demo-region", endpoint: "demo-endpoint", model: "demo-model-v1",
    gateway: "none", loggingPolicy: "no-body-v1"
  },
  features: ["plain-text"],
  policy: { mode: "standard", maxProviderDays: 30, maxCustomerDays: 0 },
  provider: { eligibleZdr: false, days: 30, evidence: "demo-policy" },
  customer: { days: 0, evidence: "demo-storage-inventory" },
  self: { bodyLogging: false, evidence: "demo-log-check" },
  exceptionsAccepted: true,
  validUntil: "2026-11-01"
};

function decide(card, actual, today) {
  const reasons = [];
  for (const key of Object.keys(card.scope)) {
    if (!actual.scope?.[key] || actual.scope[key] !== card.scope[key]) {
      reasons.push(`scope:${key}`);
    }
  }
  if (!Array.isArray(actual.features) ||
      actual.features.some(f => !card.features.includes(f))) {
    reasons.push("features");
  }
  if (today > card.validUntil) reasons.push("expired");
  if (!card.exceptionsAccepted) reasons.push("exceptions");
  for (const key of ["provider", "customer", "self"]) {
    if (!card[key]?.evidence) reasons.push(`evidence:${key}`);
  }
  for (const [key, max] of [
    ["provider", card.policy.maxProviderDays],
    ["customer", card.policy.maxCustomerDays]
  ]) {
    if (!Number.isFinite(card[key]?.days) || card[key].days < 0 ||
        !Number.isFinite(max) || max < 0 || card[key].days > max) {
      reasons.push(`retention:${key}`);
    }
  }
  if (card.self?.bodyLogging !== false) reasons.push("body-log");
  if (card.policy.mode === "zdr") {
    if (card.provider?.eligibleZdr !== true || card.provider.days !== 0) {
      reasons.push("zdr-scope");
    }
  } else if (card.policy.mode !== "standard") reasons.push("mode");
  return { allowed: reasons.length === 0, reasons };
}

const actual = {
  scope: { ...approved.scope }, features: ["plain-text"]
};
const today = "2026-10-06";
assert.equal(decide(approved, actual, today).allowed, true);

const zdr = structuredClone(approved);
zdr.policy = { mode: "zdr", maxProviderDays: 0, maxCustomerDays: 0 };
zdr.provider = { eligibleZdr: true, days: 0, evidence: "demo-zdr-scope" };
assert.equal(decide(zdr, actual, today).allowed, true);
assert.equal(decide(zdr, { ...actual, features: ["file"] }, today).allowed, false);
assert.equal(decide(zdr, {
  ...actual, scope: { ...actual.scope, model: "other-model" }
}, today).allowed, false);

const unknown = structuredClone(zdr);
unknown.provider.evidence = "";
assert.equal(decide(unknown, actual, today).allowed, false);

const customerStorage = structuredClone(zdr);
customerStorage.customer.days = 30;
assert.equal(decide(customerStorage, actual, today).allowed, false);
customerStorage.policy.maxCustomerDays = 30; // 別途承認した架空の条件
assert.equal(decide(customerStorage, actual, today).allowed, true);
assert.equal(decide(zdr, actual, "2026-11-02").allowed, false);
console.log("offline decision examples: passed");

retention-check.mjsとして保存し、node retention-check.mjsで実行します。この例では通常保持の許可、ZDRの許可、未承認機能・モデル、証拠の欠落、期限切れ、顧客管理ストレージの許容差を確認します。公開したコードはこの架空条件でオフライン実行しています。

evidenceに文字列があることは証拠の真偽を確認した結果ではありません。実運用では、記録の版と承認者、証拠へのアクセス、失効、実際の転送先を別途管理し、アプリが申告した設定だけを信頼しない設計にします。この例も、PSPが特定のテナントで使えることや、内容の削除を証明するものではありません。

送信が成功したかを確かめる作業と、保存条件を確かめる作業は分けます。権限を持つ担当者が本番適用を確認するときは、承認済みの非機密データを使い、正常応答と合成エラーの両方で自社の本文除去を確認します。保存を認めた場所ではTTLと削除手順を確認し、バックアップや外部ツールを含む対象範囲を記録します。提供側の内部削除は、外からログが見えないことだけで証明せず、契約・適用証拠と提供側から取得できる資料を使います。

モデル・機能・ログが変わったら承認範囲を更新する

利用経路の承認を永続的なベンダー承認にしないことが、導入後の維持に役立ちます。稟議記録の版をデプロイ設定と結び付け、次の差分で再照合します。

通常保持として承認済みの処理まで一律にZDRへ変える必要はありません。変わった経路が、元の目的と期間に収まることを確認すれば継続候補になります。一方、ZDR必須のデータを、障害時だけ通常保持のモデルへ送るのは別の承認です。事前に認められた切り替え先がなければ、そのデータの処理を保留し、他の用途と分けて扱います。

よくある質問

store=falseを付ければZDRになりますか？

なりません。応答・会話状態と、監視、追加機能、中継先、自社ログの保存は別です。Bedrockの通常モードではstore=falseでも安全確認用の保持があり得るため、実効モードを確認します。Bedrockの公式条件

通常の30日保持なら、ZDRより危険なので不採用にすべきですか？

期間の数字だけでは決まりません。業務がその目的・期間・閲覧権限・例外を認め、全保存先が条件内なら通常保持は候補です。反対に、本文の永続保存を認めない業務では、30日が短く見えても条件外です。先に自社の要求を決め、その要求に各保存先を照合します。

Geminiの有料APIはZDRとして稟議に書けますか？

有料で製品改善に使われないことだけでは書けません。現在のDeveloper APIの資料は、保証されたZDRが必要な場合にVertex AIを案内しています。移行後もCloud側のモデル、機能、監視例外を確認します。Developer APIの現在の案内、Google CloudのZDR条件

ZDRなのに顧客のストレージへ保存する仕組みがあるのですか？

あります。OpenAIのZDR with PSPは、選ばれた暗号化データを顧客管理ストレージで30日保存する仕組みです。顧客側も含めて本文の永続保存を禁止する要求には、そのまま適合しません。顧客管理の保存を認める要求なら、目的、期限、アクセス権を含めて審査します。PSPの公式説明

ZDR契約があり、APIも成功したら適用確認は終わりですか？

終わりません。Claudeのように、対象外機能も自動拒否されず、その機能の保持条件で処理される場合があります。契約と正確なモデル・機能を照合し、対象外の利用は自社側で制限します。Claudeの機能別保持条件

ZDRならメタデータも一時メモリーも一切残りませんか？

一律には判断できません。Claudeの適格な機能にもスキーマ等の保存条件があります。本文・識別子・スキーマ・一時メモリーを分けて自社条件に照合します。Claudeの適格機能と条件

次の作業は、候補を一つ選び、その経路の記録を埋めることです。通常保持の期限と目的が条件内なら、その用途に限定して承認を進めます。ZDRが必要なら対象契約・組織・モデル・機能と全保存先を照合し、不明な点だけを担当者に解決してもらいます。データ条件を満たした候補どうしの費用を比べる段階では、同じモデルを購入先別に比較する方法へ進めます。