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

LLM APIで「学習に使われない」と「保存されない」は別の条件です。顧客データ、未公開コード、契約書、個人情報などを送る場合、モデル提供会社がAPIデータを学習に使わないという説明だけでは、ZDR(Zero Data Retention)の稟議根拠になりません。

先に結論を示します。通常の保持条件を受け入れられるのは、送信データの分類が低く、保持期間、保存目的、削除手段、処理者、社内ログが自社ポリシーの範囲内にある場合です。ZDRが必要なのは、保存そのものを許容できないデータを扱い、かつ公式文書または契約で対象の組織・project・endpoint・model・featureまでZDR適格だと確認できる場合です。

判断を止める条件も明確です。次のどれかが未確認なら、機密データを本番routeへ流しません。

• 契約上のZDR対象となる組織、projectまたはworkspace
• 実際に呼ぶendpoint、model、regionと有効なfeature
• gateway、cloud、MCP、web searchなどを含む全処理経路
• abuse/safety log、file、cache、session、batch、agent stateの扱い
• 自社のAPI gateway、APM、trace、error log、databaseへの保存

store=falseを付けた、管理画面に「学習利用なし」と表示された、あるいはgatewayにZDRバッジがある、という一つの確認だけでは通しません。合格条件は、以下の6つの保存面を一つのroute evidence cardに記録し、各面に根拠、owner、適用範囲、再確認日があることです。

60秒で選ぶ：通常保持かZDRか

最初にデータ分類を決めます。ベンダー比較から始めると、「便利な機能があるから例外を受け入れる」という逆向きの判断になりやすいためです。

「通常保持」は即座に危険という意味ではありません。保持目的と期間が明示され、用途と契約に合い、削除とアクセス制御が実装されていれば、公開データの要約や低リスクの分類には合理的です。一方、ZDRも万能な安全認証ではありません。データ所在地、暗号化、アクセス権、法令対応、モデル出力の安全性は別途審査します。

合格を一文にすると、次のようになります。

“

承認したデータ分類だけが、承認済みの組織・projectから、承認済みendpoint/model/featureを通り、契約で定めた処理者だけに送られ、providerと自社の保存面に未確認項目がない。

この一文を証明できなければ、ベンダー名が有名でもrouteは未承認です。

「保存されない」を6つの面に分解する

ZDRレビューで最も多い失敗は、異なる保存を一つの「data retention」にまとめることです。実務では、routeを次の6面に分けます。これは法的な認証規格ではなく、各社の公式資料にある例外を見落とさないための監査フレームです。

1. モデル学習への利用

promptやresponseを基盤モデルの改善や学習に使うか、という面です。「APIデータはデフォルトで学習に使わない」は重要ですが、後述する監視ログやapplication stateの保持を否定しません。opt-outの有無だけでZDR欄を合格にしないでください。

2. Abuse・safety監視ログ

不正利用や安全性監視のためにcontentや識別可能なmetadataを記録する面です。通常保持とZDRの差が現れやすい場所ですが、法律上の義務、重大な不正利用、安全性調査などの例外が残る場合があります。「絶対に一切保持されない」と書かず、契約と公式例外をそのまま証跡にします。

3. Providerのapplication state

会話、thread、response object、agent memory、sessionなど、API機能を成立させるstateです。ZDR組織でも、stateful endpointが対象外ならここに保存が残ります。request bodyのstore=falseは一つの制御であり、組織の契約条件や別resourceの保存を自動的に変えるものではありません。

4. Feature固有の保存

file upload、batch、fine-tuning、eval、vector store、prompt cache、code execution、web/search grounding、session resumptionなどです。同じmodel名でも、有効にしたfeatureで保持境界が変わります。稟議書に「Claude」「GPT」「Gemini」とだけ書かず、feature inventoryを添付します。

5. Subprocessor・下流tool

cloud、gateway、aggregator、MCP server、検索サービス、外部toolなど、providerの外へ出る経路です。上流providerがZDRでも、下流サービスが独自に保存すればend-to-endのZDRではありません。誰がどの契約で処理するかをroute図に入れます。

6. 自社のログとdatabase

API gateway、reverse proxy、APM、trace、error report、prompt analytics、support ticket、data lake、backupなどです。provider側のZDRが正しくても、自社のmiddlewareがrequest/response bodyを記録していれば「ゼロ保持のシステム」とは言えません。ここはベンダーに質問するのではなく、自社が設定と削除を所有します。

6面は直列です。一つの面だけが合格しても、経路全体は合格しません。逆に、ある面で短期保持が必要なら、それを隠してZDRと呼ぶのではなく、保持目的、期間、アクセスowner、削除方法を明記して通常保持routeとして審査します。

主要routeの現在地：ブランドではなく適用範囲を読む

以下は2026年7月27日に公式資料で確認した選択の入口です。表は企業やサービス全体への認証ではありません。申請資格、契約、endpoint、model、featureは変わるため、本番承認時に該当行を再確認してください。

OpenAIでは、デフォルトのabuse-monitoring保持とendpoint固有のapplication stateを分けます。ZDRが有効でも、stateを必要とするresourceまで自動的に対象になるわけではありません。Safety retentionや画像・fileの安全審査例外も公式資料の範囲で記録します。

Anthropicでは、組織にZDRが有効かだけでなく、modelとfeatureの組み合わせを確認します。公式資料は一部のstateful機能に加え、特定modelに30日保持が必要な場合も示しています。管理画面で呼べることと、ZDR適格であることを同一視しません。

Geminiでは、Paid Servicesの「製品改善に使わない」と、承認projectのZDRを別欄にします。たとえばGrounding with Google SearchまたはMapsには30日の保存があり、無効化できないと説明されています。さらにAI Studioのproject logging、requestの実効store、log保持期間、dataset作成・export・share・削除を別証跡にします。GoogleがZDR compatibleと扱う24時間TTLのproject-isolated RAM cacheも、自社ポリシーが一時memoryさえ許さないなら不合格です。

AzureとBedrockは、direct vendor APIの条件をそのまま移植しません。処理者、control plane、ログownerが変わるからです。Bedrockでmodel providerからpromptが隔離されても、顧客が有効にしたAWS loggingやagent resourceは消えません。Azureのmodified abuse monitoringも、すべてのstateを消す一般的なZDRラベルではありません。

Gatewayを使うなら「上流がZDR」で終わらせない

Gatewayは認証、rate limit、fallback、model切替、監査ログをまとめられるため、企業導入で有用です。しかし、ZDR審査では処理者と保存面が一つ増えます。

最低限、次のchainを一行で書けるようにします。

application → 自社API gateway → 外部gateway → 選択されたupstream endpoint → tool/subprocessor → response → 自社observability

外部gatewayに「ZDR only」設定があっても、次の質問が残ります。

1. gateway自身はrequest/response、metadata、error bodyを保存するか。
2. fallbackによって非ZDR endpointへ移らないか。
3. model aliasが別providerや別regionへ解決されないか。
4. web search、MCP、file処理などの下流toolは別契約か。
5. incident調査時に一時的なfull-body loggingを有効化できるか。
6. upstreamのZDR適格性を誰が、どの頻度で更新するか。

公開されているZDR条件をこの調査で確認できなかったgatewayを、ZDR必須workload向けに推奨することはできません。これは品質や価格への評価ではなく、証跡不足時に機密trafficを止めるというルールです。公式direct routeを使う場合も、同じ6面の確認は必要です。

稟議に添付するroute evidence card

長いポリシー文書を添付するだけでは、本番設定との対応が分かりません。1 deployment routeにつき1枚、以下のcardを作ります。環境が違うなら、development、staging、productionを別cardにします。

text
Route ID: llm-prod-ja-01
Purpose / data class: 顧客問い合わせ要約 / 個人情報をredact後に送信
Owner: Platform Security / 再確認日: 2026-08-27

Chain:
app → internal gateway → [cloud/gateway] → exact endpoint → exact model

Scope:
organization/project/workspace:
region:
endpoint + API version:
model + version/alias resolution:
enabled features:
disabled features:
subprocessors/tools:

Six retention planes:
1. training use:
2. abuse/safety logs:
3. provider application state:
4. files/cache/batch/search/agentなどのfeature storage:
5. gateway/cloud/tool/subprocessor:
6. 自社log/trace/database/backup:

Evidence:
official URL + checked date:
contract/DPA/order form:
admin/config export:
test request ID（機密データなし）:
logging/redaction test:
deletion/TTL test:

Exceptions and STOP:
unknown or non-eligible item:
blocked data classes:
fallback behavior:
approval owner:

URLだけでなく確認日を残すのは、公式の対象表が変わるからです。contract名だけでなく、契約が適用されるorganization/project/workspace IDも記録します。設定画面のscreenshotだけに依存せず、可能ならconfig export、policy-as-code、API responseなど再現可能な証跡を使います。screenshotを使う場合は、取得者、日時、対象IDをticketに紐付けます。

test requestには架空または公開データを使います。機密データを送ってZDRを試す必要はありません。request IDと時刻を起点に、provider dashboard、自社gateway、APM、SIEM、error tracking、backupへbodyが残っていないかを確認します。意図的に4xx/5xxとtimeoutも発生させ、成功時だけでなくerror pathのloggingを検証してください。

cardの完成条件は、すべての欄が「なし」「対象外」「確認済み」のいずれかで、空欄がないことです。「不明」は未解決として扱い、承認者、期限、解決方法を書きます。期限までに解決しなければrouteを開けません。

設定を証明する最小テスト

文書の読み合わせが終わったら、非機密データで技術確認を行います。

1. Aliasを解決する。 実際のmodel ID、provider、regionをrecordし、fallbackを一時的に無効化する。
2. Stateful featureを切る。 conversation、thread、file、batch、cache、search、MCP、agent memoryなど、不要な機能を明示的に無効化する。
3. Provider側を確認する。 対象org/project/workspaceに契約上のcontrolが適用されている証跡を保存する。
4. 正常系を送る。 公開テキストでrequestし、request ID、endpoint、model、feature flagを保存する。
5. 異常系を送る。 validation error、timeout、rate limitなどを再現し、error bodyがログに残らないことを確認する。
6. 自社側を検索する。 gateway、APM、trace、SIEM、support tool、database、backupで本文と識別子を検索する。
7. TTLまたは削除を検証する。 保持を許容する面は、期限後に消えること、delete操作が対象resourceへ届くことを確認する。
8. Fail-closedを試す。 非適格feature、unknown endpoint、ZDRでないfallbackを選んだとき、機密classのrequestがblockされることを確認する。

「requestが200で返った」はZDRの試験結果ではありません。合格は、承認されたrouteだけが通り、禁止routeが止まり、providerと自社の証跡がcardに一致することです。

変更管理：modelを替えただけでも再審査する

ZDRの承認はベンダーに永久付与するものではなく、routeの特定versionに対する判断です。次の変更をproduction deployのgateにします。

実装では、route cardの承認versionをdeployment manifestに紐付けます。CI/CDはendpoint、model、feature、gateway policy、logging policyの差分を検出し、cardにない変更をfailさせます。緊急fallbackも例外にしません。承認済みZDR endpointが使えないなら、非ZDRへ自動移行するのではなく、機密classだけを止める設計にします。

定期レビューだけに頼ると、変更と確認の間に空白が生まれます。推奨する再確認タイミングは、provider告知、契約更新、model/endpoint migration、feature enablement、gateway切替、logging変更の直前です。加えてcardへ次回確認日を入れ、owner不在や期限切れをdeployment blockerにします。

よくある不合格と直し方

「APIデータは学習に使われないのでZDR」

学習面だけの合格です。監視ログ、state、feature、subprocessor、自社ログを追加し、それぞれの保持期間とownerを確認します。

「store=falseを指定したので全機能が保存しない」

そのparameterが制御するresourceしか証明していません。組織のZDR契約、endpoint適格性、file/cache/toolなど別resourceの保存を確認します。

「契約にZDRと書いてあるので、すべてのmodelが対象」

modelまたはfeature固有の例外があり得ます。実際のmodel IDとversion、alias解決先を公式表に照合します。

「providerがZDRなのでgatewayもZDR」

処理者が一つ増えています。gateway自身のlog、fallback、subprocessor、incident logging、upstream endpointの選択証跡が必要です。

「provider側は保存しないのでシステム全体も保存しない」

自社のtraceやerror reportにpromptが残る典型的な失敗です。正常系だけでなくvalidation error、timeout、retryでもredactionを試します。

「ZDRだから秘密鍵を送ってよい」

ZDRはsecret managementではありません。credential、private key、access tokenは送信前に除去し、漏えい時はrotationとincident responseを行います。

採用後の次のアクション

まず、候補routeを一つだけ選び、非機密データでroute evidence cardを完成させてください。6面すべてに根拠があり、禁止featureとfallbackをfail-closedで止められたら、セキュリティ・法務・privacyの承認範囲内で該当データclassだけを開放します。カードが完成しない場合は、通常保持に分類し直して低リスク用途に限定するか、別routeまたは送信しない設計へ切り替えます。

保持条件を通過した後に初めて、価格と品質を比較します。最安のLLM APIプロバイダーを実コストで選ぶ手順では、token単価だけでなくgateway、retry、accepted output、data boundaryを含めて次の候補を絞れます。Googleのconsumer履歴やAI Studio/Cloud resourceの削除が目的なら、APIのZDR稟議とはownerが異なるため、Google AIのデータ削除を経路別に確認するガイドへ進んでください。

最後の承認文は短く保てます。

“

Route ID、対象data class、6つの保存面、契約・設定証跡、禁止feature、recheck dateが一致するため承認する。一致しない変更または期限切れでは機密trafficを自動停止する。

これが書けないrouteは、まだ「ZDRかどうか」を判断できていません。機密データを先に流さず、空欄を埋めることが次の作業です。