LLM のデータ保持と ZDR：prompt を読めるすべての事業者
目次
prompt は単に「AI 企業」へ送られるわけではありません。agent stack では、平文の prompt が複数の事業者を経由します。どこを通るかは構成次第です。agent framework の telemetry、tracing platform、memory store、analytics tool、AI gateway、そして 3 種類ある inference provider のいずれかです。それぞれに異なる保持ポリシー、保存リージョン、学習利用の条項があります。prompt を最も長く保持するのは、通常 API の手前にある自社側の仕組みです。model vendor の標準ログは約 30 日で削除されますが、tracing や memory store の多くは、明示的に削除するまで残ります。zero data retention（ZDR）は実効性のある有用な契約ですが、対象になるのは 3 つの軸のうち 1 つ、かつ経路上の 1 事業者だけです。本記事では、経路全体を整理し、誰が何をどれだけ保持するのか、ZDR が何を対象とし、何を対象外とするのかを説明します。
TL;DR
- 平文を扱うすべての hop がデータを収集できます。agent 側の tracing と memory store は、どの model provider よりもはるかに長く prompt を保持します。
- provider の保持期間は機能ごとに異なります。Claude API では caching は ZDR 対象ですが、batch job は 29 日間保持され、Fable 5 では 30 日間の保持が必須です。
- データの所在地は server に従います。DeepSeek の公式 API はデータを中国に保存し、ほかの選択肢はありません。
- 最も注意が必要なのは無料 endpoint です。無料枠の対価として、学習利用権が設定されている場合がほとんどです。
- ZDR は訴訟でも効力を保ちました。NYT の証拠保全命令で除外されたのは、zero-retention の API 顧客だけでした。
agent stack では誰が prompt を読めるのか
経路上の全員です。その経路は、多くのチームが描く構成図よりも長くなります。
左から順に見ていきます。agent layer は自社の領域ですが、自社だけで完結することはほとんどありません。framework には telemetry が組み込まれています。tracing や observability の platform は、完全な prompt と response を保存するための製品です。memory 機能は会話内容を vector store に書き込みますが、通常は自動で失効しません。Web UI に session replay 用の analytics snippet があれば、backend に届く前、user が入力している最中から prompt を取得できます。gateway は self-hosted なら 1 事業者、SaaS なら 2 事業者が関与し、SaaS gateway には 2 つの形態があります。1 つ目は multi-provider aggregator です。1 つの API で背後の複数 provider に request を振り分けるため、データの取り扱いは常に gateway 自身のポリシーと、その request の送信先となった host のポリシーを合わせたものになります。2 つ目は security vendor が提供する gateway です。data-loss-prevention（DLP）や guardrail gateway は、payload の検査、redaction、policy enforcement 自体が製品機能です。つまり、すべての prompt を読むことが機能の前提であり、検知された prompt は通常、設計上 security event として保持されます。
gateway の先には、3 種類の inference provider があります。model vendor 自身の API、自社の cloud tenancy 内で model を動かす cloud provider、独自の logging policy で open weights を提供する GPU host です。迂回経路に当たる dedicated tenant や自社 GPU 上の self-hosted inference だけが、第三者に平文を渡さずに済む構成です。ただし、この構成にも後述する注意点があります。
以降を整理する原則は 1 つです。見ることと保持することは別の問題です。 どの box も技術的には収集できます。実際に収集するかどうかは、default、設定、契約で決まり、経路上の各所で大きく異なります。
実際に prompt を保持するのは誰か
通常、最も長く保持するのは自社の tool です。security questionnaire で重視される provider の保持期間は数日単位ですが、ほとんど確認されない agent 側の store には無期限で残ります。
agent layer は設計上データを保持します。 tracing platform は、prompt と output の database を提供する製品です。保持期間は偶発的な policy ではなく、project 設定です。default は tool ごとに異なるため、内容を把握しておく必要があります。GitHub Copilot の OpenTelemetry integration は、明示的に content capture を有効にしない限り、span の構造、timing、token 数を export しますが、prompt の内容は含めません。ほかの agent tool も採用すべき、privacy を優先した設計です。Cursor の privacy mode が存在するのは、default mode では code data が共有されるためです。model provider が 30 日後に削除しても、trace store には 300 日目でも残っています。
gateway が何を保持するかは実装次第です。 billing には request ごとの token 数、model、timestamp が必要なため、gateway は usage record を残さざるを得ません。一方、payload を保存する必要はありません。prompt と response body は memory 上だけを通し、永続化せずに処理できます。ただし、よく使われる 2 つの gateway 機能は、気づかないうちにこの境界を越えます。request inspection や observability console は、その 1 hop 手前にある tracing SaaS と同じく、定義上 payload storage です。gateway-side caching も gateway 上に prompt の内容を保存します。semantic cache は prompt の embedding と cached response 全文を保持し、response cache は request と response の両方をそのまま保存します。保存先は gateway が動作する disk です。SaaS か self-hosted かを問わず、gateway を評価するときは、次の 3 点を分けて確認します。request record に何が含まれるか、observability view が何を永続化するか、cache が何を書き込むかです。
provider の保持方針は企業単位ではなく、機能単位です。 この考え方は、機能ごとの対象可否を開示している Anthropic の API データ保持ドキュメントを見ると分かりやすくなります。prompt caching は cache state を memory 上だけに保持するため、ZDR の対象です。batch processing は async job に storage が必要なため、job を 29 日間保存します。code-execution container は最長 30 日間保持されます。uploaded file は削除するまで残ります。同ページには率直な説明があります。stateful feature を使うことは、その特定のデータについて「ZDR 契約の対象外にする選択」です。OpenAI 側では、data-controls のドキュメントに ZDR 対象の endpoint が記載されています。abuse-monitoring log は default で最長 30 日間保持され、cached prompt は暗号化された key-value tensor として GPU-local storage に保存され、上限付きの TTL が設定されます。Claude API における標準の商用データは、30 日以内に削除されます。
データは物理的にどこへ保存されるのか
保存先は serving infrastructure の所在地です。provider の種類によって答えが変わります。cloud-hosted model は最も明確です。Amazon Bedrock では cloud provider が data processor となり、inference は選択した region 内に留まります。規制対象の企業がまずこの方式を選ぶのはそのためです。model vendor 自身の API は、その vendor の infrastructure 上で動きます。OpenAI は大半の endpoint で米国と EU の regional processing を提供していますが、小規模な vendor は何も公開していない場合があります。最も明確な例は DeepSeek です。privacy policyには、personal data を中華人民共和国で収集、処理、保存すると明記されており、公式 API に米国や EU を選ぶ option はありません。同じ open weights を米国の GPU host で動かせば、この地理的条件は一切引き継がれません。つまり、model のデータがどこへ行くかは model ではなく、誰が serving するかで決まります。
primary copy の先にも 2 つの保存先があります。cache と batch file は request log とは別に、それぞれの存続期間中、serving region に残ります。さらに、すべての provider は subprocessor（自社の下流 vendor）と backup を利用しています。削除に関する約束は通常、active system からの削除として記述され、backup への反映には別の期間が設けられています。data-flow diagram が API vendor の logo で終わっているなら、少なくともこの 2 つの box が抜けています。
誰が保持を要求し、誰が prompt を学習に使うのか
default を超えてデータを残す要因は 3 つあります。provider が表立って説明するのは、そのうち 1 つだけです。
policy 上の要件。 一部の model は、安全性の条件としてデータ保持を義務付けています。Claude Fable 5 と Mythos 5 は、ZDR 顧客にも 30 日間の保持を求めます。要件を満たさない保持設定の organization から request が送られると、黙って受理されるのではなく 400 で拒否されるため、強制動作は明確です。abuse escalation も別の保持期間が適用される要因です。usage-policy 違反として flag された content は、通常とはまったく異なる期間で保持されます。Anthropic の consumer policy では、flag された input と output は最長 2 年、classifier score は最長 7 年とされています。
legal hold。 NYT 対 OpenAI の訴訟では、データ保持の約束がどう扱われるかを明確に確認できました。2025 年 5 月の証拠保全命令により、OpenAI は本来削除するはずだった output log を、consumer tier 全体で保存するよう求められました。user が削除した chat も対象でした。この命令は同年 9 月に範囲が縮小され、その後、裁判所は discovery で 2000 万件の chat log の提出を命じました。API 購入者にとって重要なのは、enterprise と zero-data-retention の顧客が除外された点です。保全対象となるデータが保持されていなかったためです。削除 policy は litigation hold によって変更されますが、そもそも保存しない architecture には保全対象がありません。
データを収集する仲介事業者。 経路の中間で平文を収益化する事例は実際にあり、最大規模の記録済み事例は user に最も近い場所で起きました。2025 年 12 月、security researcher の調査により、数百万 install を持つ「privacy」VPN の browser extension が AI chat page に script を注入していたことが判明しました。ChatGPT、Claude、Gemini など 8 つの assistant で、すべての prompt と response を傍受し、会話を data broker 系の関連企業へ送信していました。この収集は VPN が有効かどうかに関係なく実行され、同 publisher の extension 群を使う約 800 万 user に影響しました。この incident は API gateway ではなく client-side interceptor によるものでしたが、図中のすべての box に同じ教訓が当てはまります。平文を扱う仲介者はすべて収集地点になり得ます。収益化の incentive があり、両端からは傍受を検知できません。仲介事業者を信頼できるかどうかは、機能一覧ではなく business model の問題です。
学習利用の条項。 大手 vendor の business API は、default では顧客データを学習に使いません。一方、consumer product では opt-out しない限り学習に使う例が増えています。agent traffic を consumer account ではなく API key で送るべき理由の 1 つです。また、学習利用を user 自身が探して変更する toggle にしている製品も増えています。default で学習利用が有効になっており settings 内に opt-out が埋もれている consumer plan、telemetry や code-sharing の設定が学習への同意も兼ねる developer tool、data-sharing の opt-in と引き換えに割引や無料 quota を提供する vendor program、有料 tier と無料 tier で学習設定を分ける aggregator dashboard などです。toggle は account 単位で、workspace 単位の場合もあります。terms の更新で default が変わる可能性もあるため、一度確認するだけでは不十分です。これらの switch の監査は、key rotation と同じ定期 checklist に含める必要があります。
無料 model は特に注意が必要です。 ここまで挙げたリスクはすべて無料 tier に集中します。無料 model の提供費用は通常、その traffic から利益を得る事業者が負担しています。多くの場合は model vendor 自身です。そのため、無料版に送った prompt はその事業者の policy に従って処理され、学習利用権が条件に含まれることも珍しくありません。処理場所もその事業者の所在地に依存し、中国 vendor なら中国になります。aggregator gateway が endpoint ごとの data policy と、学習に使う provider を除外する switch を公開しているのは、こうした条項が主に無料 route に存在するためです。原則は単純です。無料 endpoint は API call ではなく、データ提出として扱ってください。無料 inference の費用は誰かが負担しており、対価になるのは通常、利用者の prompt です。
ZDR は実際に何を意味するのか
ZDR が固定するのは 3 つの軸のうち 1 つです。対象は経路上の 1 事業者で、かつ対象機能に限られます。これは欠点ではなく ZDR の定義です。境界を理解して初めて正しく使えます。
- 3 つの軸。 学習利用、保持期間、人によるアクセスは互いに独立しています。business API はすでに顧客データを学習に使いません。ZDR がゼロにするのは payload の保持です。人によるアクセスは abuse process で別に管理されます。これらを混同すると、ZDR の効果を実態以上に見せることになります。
- ZDR でも残るもの。 usage metadata と billing record、safety-classifier の output、利用者が有効にした stateful feature のデータです。現在、大手 2 社とも abuse-monitoring の例外で payload を直接保持するのではなく、一方は payload を含まない safety signal、もう一方は classifier result のみを保持する設計を採用しています。
- ZDR の対象外。 provider より手前にあるすべての要素です。tracing store、gateway log、vector memory は対象になりません。model vendor と ZDR 契約を結びながら tracing SaaS に全 prompt を無期限で残す構成は、よく見られる一方で最も一貫性に欠けます。
- self-hosting の注意点。 自社 GPU で open weights を動かせば第三者をすべて排除できますが、問題は自社 infrastructure に移ります。inference server の request logging、access log、trace file が対象です。self-hosting は保持の対象領域を移すだけです。縮小するには、意図的な log 管理が必要です。
Synthorai の対応
gateway hop は Synthorai の管理下にあるため、取り扱いを明確に定めています。zero-retention mode では、request body と response body は memory 上だけを通過し、永続化されません。保存するのは billing に必要な usage record です。timestamp、model、token 数、および発言内容を保存せず、紛争時に request を照合するための content hash が含まれます。upstream は routing より前に provider 候補を filter します。Synthorai が採用するのは、Synthorai の traffic に対して zero data retention を約束する provider だけです。例外は Claude Fable 5 です。この model は vendor によって 30 日間の保持が義務付けられており、契約で除外できません。provider の選択は保持方針の選択でもあります。gateway の役割は、この条件を policy PDF に埋もれさせるのではなく、route ごとに明示することです。Fable 5 の route では、保持要件を後から判明する条件ではなく、documented metadata として付与します。
FAQ
LLM provider は default で API データを学習に使いますか？
いいえ。大手 vendor の business API は、default では顧客データを学習に使いません。この方針は各 provider の data-controls ドキュメントに記載されています。例外は主に、大手以外のサービスに集中しています。opt-in ではなく opt-out を採用する consumer product、一部の open weights 向け GPU host、学習利用権が価格条件に含まれる無料 tier の endpoint です。
ZDR なら provider は何も保存しないのですか？
いいえ。ZDR は、対象機能の prompt と response payload を保持しないという意味です。usage metadata、billing record、safety-classifier の output は残ります。batch job や file upload などの stateful feature は、その性質上データを保存するため ZDR の対象外です。見出しではなく、機能ごとの対象可否を示す table を確認してください。
無料 model に production data を送っても安全ですか？
無料 endpoint は API call ではなく、データ提出として扱ってください。無料枠の費用は traffic から利益を得る事業者が負担しており、学習利用権が条件に含まれることも珍しくありません。データは費用を負担する事業者の所在地で処理されます。使い捨ての実験なら妥当な取引ですが、customer data、code、credential を含む場合はほとんど適しません。
self-hosting は自動的に最も privacy の高い選択肢になりますか？
平文の経路からすべての第三者を排除できる点には、明確な効果があります。ただし、保持自体はなくなりません。inference server、reverse proxy、tracing はすべて default で log を記録します。default の logging を使った self-hosted stack は、ZDR API より多くの prompt data を保持する可能性があります。privacy を決めるのは hosting model ではなく、logging configuration です。
情報源は 2026-08-29 に確認済みです。上記の provider に関する主張は、すべて vendor 自身のドキュメントまたは裁判所の一次資料へ link しています。この分野の policy は公開前の 1 か月だけでも 2 回変更されているため、最新情報は各 link を正として確認してください。本記事は engineering の観点による整理であり、法的助言ではありません。
関連：Fable 5 の 30 日間保持要件、prompt caching の仕組み、provider ごとの cache 比較。