AI推論後のデータ保存を防ぐ「ZDR」の適用範囲とは——OpenRouterが解説記事を公開
要点
- AIモデルのルーティング基盤を提供するOpenRouterが、推論処理後のデータ保持を防止する「Zero Data Retention（ZDR）」の仕様や適用範囲に関する技術解説を公開した。
- ZDRはAIプロバイダーが推論完了後にプロンプトや生成応答を永続ストレージへ保存しないポリシーであり、モデルによる処理そのものや自社アプリ側のログは保護対象に含まれない。
- OpenRouterはエンドポイント単位でデータ保持方針を厳格に評価し、不正検知などを目的に一時保管を行うエンドポイントはZDRの対象外として分類している。
- 「学習拒否（No training）」や「データレジデンシー（処理地域の制限）」とは管理する領域が異なり、厳格なデータ管理を行うには各機能の個別設定が必要となる。
- プロバイダー側のインメモリプロンプトキャッシュはZDR互換とみなされる一方、生成結果を保存するレスポンスキャッシュ機能は設定方法によって挙動が異なる。
AIモデルのルーティング基盤を提供する米OpenRouterは2026年9月11日、推論処理後のデータ保持を遮断する「Zero Data Retention（ZDR、ゼロデータ保持）」に関する解説記事を公式ブログで公開した。AI APIを業務システムへ組み込む企業が増加するなか、ZDRが実際に保証する境界線や、関連するプライバシー制御機能との役割分担について客観的な指針を示している。
プロバイダー側での推論後保存を防ぐ「ZDR」の定義
OpenRouterの説明によると、ZDRとはAIプロバイダーがAPIリクエストを処理して応答を返却した後に、入力プロンプトや生成された応答テキストを永続ストレージに保存しないデータ取り扱いポリシーを指す。
OpenRouterでは、プロバイダー全体の包括的な利用規約と、個別のモデル向けエンドポイント（接続先URL）に適用されるポリシーが異なる場合があるため、評価をエンドポイント単位で実施しているという。ポリシーの適用状況が明確に確認できないエンドポイントについては、安全側に倒す保守的な判断として「データの保持および学習利用あり」と分類する方針をとっている。
なお、ZDRによるルーティングはOpenRouter自身のログ保存ポリシーとも独立して管理されている。OpenRouter側でも、ユーザーが明示的に「入力・出力ログ機能」を有効化（オプトイン）しない限りプロンプトや応答本文は保存されない。ただし、利用状況の確認や請求管理に必要なリクエストのメタデータ（トークン数、処理遅延時間、利用モデル名、コストなど）については、本文とは別に保持される仕様となっている。
ZDRが保証する境界線と保護対象外となる領域
解説記事では、ZDRがプロバイダー側の推論エンドポイントにおける保存を防ぐための枠組みであり、リクエストが通過するすべてのシステムを包括する万能のプライバシー設定ではない点が強調されている。
ZDRによって保証される範囲と、対象外となる領域は以下のとおり整理されている。
- 保証される領域: プロバイダーが推論完了後にプロンプトやモデルの応答を永続保存しない。保存されたデータが存在しない状態となるため、保持データを用いた事後的なモデル学習も間接的に防止される。
- 保証の対象外となる領域:
- データ転送および処理: プロバイダーへのデータ送信や、モデルが回答を生成するために入力内容を処理すること自体は発生する。
- 自社ネットワーク内への局所化: データが自社のネットワーク内部だけに留まることを意味するわけではない。
- 処理地域の制限: リクエストが処理される国や地域を限定する制御は含まれない。
- 自社アプリケーション側のログ: 自社システムのエラー追跡ツール、アナリティクス、データベース、各種ログに残るプロンプトや応答の複製は削除されない。
- 外部ツールやプラグイン: Web検索プラグインや外部連携ツールを有効化している場合、それらのツールは各提供元のデータポリシーに従って処理される。
- 不正検知などの一時保持: 「モデルの学習には使用しない」と掲げていても、不正利用対策（abuse detection）や法的義務への対応を目的に一時的なデータ保管を行うエンドポイントについて、OpenRouterはZDRの対象外として扱っている。
「学習拒否」や「データレジデンシー」との相違点
OpenRouterは、ZDRと混同されやすい他のプライバシー制御機能との違いについても詳細に言及している。
まず「学習拒否（No training on your data）」との違いについて、学習拒否は入力データがモデルの性能改善に使用されるのを防ぐ制御であるのに対し、ZDRは推論後のデータ保存そのものを防ぐ制御であると説明している。プロバイダーが「学習は行わない」と約束していても、不正検知のためにデータを短期間保持するケースがあるため、両方の保護が必要な場合は双方の設定を有効化する必要があるという。OpenRouterのAPIでは、永続保存や学習を行うプロバイダーを除外する data_collection: "deny" パラメータと、zdr: true を併用することで明示的な制御が可能となっている。
また、特定の国や地域内に処理を限定する「データレジデンシー（地域固定）」との違いについても解説されている。データレジデンシーは欧州のGDPR（一般データ保護規則）対応などを目的に「どこで処理するか」を制御するものであり、「処理後にデータを残すか」を制御するZDRとは独立した概念だという。OpenRouterでは、BusinessおよびEnterpriseプランの利用者向けに、米国（us.openrouter.ai）およびEU（eu.openrouter.ai）のドメインを経由したインリージョンルーティングを提供している。
キャッシュ機能の挙動とOpenRouterでの適用方法
プロンプトやレスポンスのキャッシュ機能とZDRの関係についても仕様が明らかにされた。
プロバイダー側が提供する「インメモリプロンプトキャッシュ（in-memory prompt caching）」については、プロンプトがディスクなどの永続ストレージに書き込まれず、処理性能向上のためメモリ上に一時展開されるだけであることから、OpenRouterはZDRと互換性があるものとして扱っている。
一方、生成された回答を一時保管する「レスポンスキャッシュ（response caching）」機能は挙動が異なる。OpenRouterのアカウント全体でZDRを有効化している場合はレスポンスキャッシュが自動的に無効化されるが、個別のAPIリクエストで provider.zdr フィールドを指定した場合にはレスポンスキャッシュの無効化が連動しない。そのため、あらゆるレイヤーでデータ保存を完全に排除したいシステムでは、レスポンスキャッシュの設定状況を個別に確認する必要があるとしている。
OpenRouterにおいてZDRを適用する方法としては、アカウント設定、ガードレール機能、またはAPIリクエスト時の provider.zdr パラメータの指定が用意されている。