OpenRouterのプライバシー設定。ZDR・ログ・プロバイダー選択を企業向けに解説

公開日：2026年9月6日更新日：2026年9月21日

OpenRouterは、OpenAI互換の一つのAPIから複数のAIモデル提供者へ接続できるサービスです。モデルの選択、フォールバック、予算制限をまとめられる一方、企業が機密情報を扱う場合は「OpenRouterと実際のモデル提供者の双方をデータ経路として管理する」必要があります。ゼロデータ保持（ZDR）も、名前だけで自動的に適用されるとは限りません。

本稿ではOpenRouterの公式ドキュメントとプライバシーポリシーを基に、入力・出力ログ、ZDR、プロバイダー選択、ガードレール、フォールバック時の注意点を整理します。製品設定や提供条件は更新されるため、実装時は管理画面と公式文書の最新版を確認してください。情報は2026年9月5日時点です。

OpenRouterのデータ経路

OpenRouterを使うと、利用者のアプリケーションはOpenRouterのAPIへリクエストを送り、OpenRouterが選択されたモデル提供者へ転送します。回答は逆の経路で戻ります。このため、データを処理する主体はOpenRouterだけでも、最終モデル提供者だけでもありません。

構成を評価するときは、アプリケーション、OpenRouter、モデル提供者、追加プラグインやログ保存先を順に並べます。各地点で、本文、添付ファイル、利用者識別子、IPアドレス、モデル名、料金など何が扱われるかを確認します。プロンプト本文を保存しなくても、時刻やトークン数などのメタデータが残る場合があります。

複数モデルへフォールバックする設定では、通常時と障害時で送信先が変わります。主モデルがデータ保持要件を満たしていても、代替モデルが同じ条件とは限りません。許可したプロバイダーと地域の範囲を明示的に制限することが重要です。

OpenRouter自身のログ設定

OpenRouterの公式説明では、通常の入出力本文のログ保存は既定で無効です。モデル改善を目的としたデータ利用は任意参加で、参加した場合に1%の割引を提供する仕組みが案内されています。任意設定である以上、組織管理者は現在の状態を確認し、一般利用者が独自に変更できるかも把握する必要があります。

本文ログを無効にしても、請求、性能、セキュリティ、ルーティングに必要なメタデータは保存されます。どの項目がどの期間残るかは、最新のプライバシーポリシーと契約で確認します。社内規程が「本文を保存しない」だけでなく「利用者や処理対象を推測できるメタデータも制限する」場合は、別の評価が必要です。

設定画面のスクリーンショットを一度残すだけでは不十分です。組織設定が更新されたときに検知し、定期的に監査します。APIキーを個人アカウントへ発行すると、中央の設定を外れて利用される可能性があるため、組織単位の発行と失効手順を整えます。

入出力ロギング機能の注意点

OpenRouterには、完全なプロンプトと回答を保存する入出力ロギング機能があります。公式ドキュメントではベータかつ任意参加で、隔離されたGoogle Cloud StorageへAES-256で暗号化して保存し、組織管理者が参照できると説明されています。

このログはデバッグ、品質評価、コスト分析に便利ですが、機密情報を集中させます。公式案内では最低3か月保存され、削除を依頼しない場合はさらに長く残る可能性があります。短期保存を求める組織は、機能を有効にする前に削除条件、依頼方法、バックアップの扱いを確認します。

暗号化されていることと、アクセスが不要であることは別です。組織管理者の多要素認証、職務分離、閲覧監査、退職者の権限削除が必要です。開発者がデバッグ目的で全本文を見られる設計ではなく、必要な案件だけ、期限付きで閲覧できる形を検討します。

地域ルーティングとの組み合わせにも制約があり得ます。モデル推論を特定地域へ限定しても、ログ保存先が同じ地域とは限りません。推論とログのデータ所在地を別々に確認してください。

ゼロデータ保持（ZDR）とは

OpenRouterのZDRは、リクエストを処理するプロバイダーについて、入力・出力を保存しない経路を選ぶための仕組みです。ガードレール設定でZDRを強制すれば、条件を満たさない経路を避けられます。単にモデル名を指定するだけで、常にZDRになるとは限りません。

「ゼロ」は、あらゆる情報が世界中のどこにも残らないことを意味しません。利用者側のアプリログ、OpenRouterの請求メタデータ、ネットワーク機器、接続ツールには情報が残る場合があります。また、不正利用防止や法的義務による例外が契約に定められている可能性があります。

ZDRを必須にする場合は、ポリシーとして強制し、違反するモデルやプロバイダーへはリクエストを送らないようにします。条件に合う経路が利用できないとき、エラーで停止するのか、条件を緩めて代替へ送るのかを明確にします。機密業務では、条件を緩めず停止する方が一般に安全です。

ガードレールで制御できること

OpenRouterのガードレールには、予算、利用可能モデル、利用可能プロバイダー、ZDR、データ地域、プロンプトインジェクション、PIIや機密情報のフィルタリングなどの設定があります。組織、APIキー、リクエストで複数の規則が適用される場合、より厳しい規則が優先されると説明されています。

予算制限は、漏えいしたキーや無限ループによる費用拡大を抑えます。ただし、月間上限だけでは、一人が短時間に使い切ることを防げません。キー、利用者、日次、モデル単位で上限と通知を設けます。

モデル・プロバイダーの許可リストは、品質とデータ保護の双方に有効です。新しいモデルが追加されても自動的に業務データを送らず、法務・セキュリティ・品質評価を通過したものだけ許可します。禁止リストより、最初は許可リストの方が範囲を制御しやすくなります。

PIIフィルターは補助策です。氏名やメールアドレスの一般的な形式は検出できても、顧客番号、社内コード、自由記述の病歴を完全には見つけられません。送信前のデータ分類とマスキングをアプリケーション側でも行います。

フォールバックの利点とリスク

OpenRouterはmodelsに順序付きの候補を指定し、コンテキストエラー、モデレーション、レート制限、停止などが起きた場合に別モデルへ切り替える機能を提供します。可用性を高められますが、回答品質、価格、安全ポリシー、データ所在地が変わる可能性があります。

代替モデルは、主モデルと同じテストに合格したものだけにします。「最も安い利用可能モデルへ自動で送る」構成は、低リスクな公開情報には便利でも、機密業務には不向きです。コンテキスト長が違えば、入力が切り詰められたり料金が増えたりする可能性もあります。

実際に使われたモデルとプロバイダーは、レスポンス情報や利用ログで記録します。業務結果に問題が起きたとき、どのモデルが回答したか分からなければ原因を追えません。監査では要求モデルだけでなく、実処理モデルを確認します。

フォールバックでモデレーション拒否を回避する設計には特に注意します。安全上の拒否を単なる障害と扱い、制約の弱いモデルへ送ると、組織の利用方針を迂回する可能性があります。拒否理由ごとに、代替を許可するか人へ戻すかを決めます。

APIキーと組織管理

APIキーはソースコード、ブラウザー、共有チャットへ直接書き込まず、秘密管理サービスで保管します。本番、開発、個人検証でキーを分け、最小予算と許可モデルを設定します。漏えいが疑われたら即時失効し、利用履歴と請求を確認できる手順を用意します。

組織アカウントでは、管理者を必要最小限にし、多要素認証を要求します。退職・異動時の削除、休眠キーの棚卸し、緊急時の一括停止を定めます。外部委託先へキーを渡す場合は、専用キーと期限、利用上限を設定し、契約終了時に失効させます。

クライアント側からOpenRouterへ直接アクセスさせる構成では、キーが利用者端末へ露出する可能性があります。自社のバックエンドを経由し、認証、入力検査、レート制限、監査を行う方が制御しやすくなります。

企業向けの設定例

低機密な公開情報の要約では、複数モデルのフォールバックを許可し、厳しい予算上限を置く構成が考えられます。それでも、入出力ログは目的がなければ無効にし、実処理モデルを記録します。

社内限定文書では、ZDRを強制し、承認済みプロバイダーと地域だけを許可します。送信前に個人情報と秘密情報を検出し、全文ログを無効にします。回答は根拠文書へリンクし、人が確認します。

特に機密性の高いソースコード、医療、契約、認証情報では、OpenRouter経由が適切かを先に判断します。直接契約や専用環境、自社ホストモデルの方が責任分界を単純化できる場合があります。便利な統合経路を使うこと自体を目的にせず、データ分類に応じて経路を分けます。

導入前チェックリスト

契約面では、OpenRouterと各モデル提供者の利用規約、保存、学習利用、地域、削除、事故通知を確認します。技術面では、ZDR強制、許可リスト、予算、キー管理、ログ設定、実モデル記録を確認します。

運用面では、設定変更の承認、月次監査、キー失効、フォールバック時の品質確認、インシデント対応を決めます。検証では、主モデル停止、ZDR適合経路なし、予算超過、モデレーション拒否を意図的に発生させ、データ要件を緩めず安全に停止するか確認します。

まとめ

OpenRouterは複数モデルを一つのAPIで利用し、ルーティング、フォールバック、予算を統合できる便利なサービスです。その一方、データはOpenRouterと実際のモデル提供者を通るため、両者の契約と設定を管理する必要があります。

企業利用では、本文ログが既定で無効であることへ安心せず、任意の入出力ロギング、ZDR、プロバイダー、地域、フォールバックを明示的に設定します。条件を満たす経路がないときは安全に停止させ、実処理モデルを記録することが重要です。Accomplirでは、OpenRouterを含むAIゲートウェイの選定、データフロー設計、権限・予算・監査の実装を支援しています。

よくある質問

OpenRouterはプロンプトを保存しますか

公式説明では通常の入出力本文ログは既定で無効です。ただし任意のロギング機能があり、メタデータも処理されます。組織設定と最新のプライバシーポリシーを確認してください。

ZDRはモデルを選ぶだけで自動適用されますか

常に自動とは限りません。ガードレールでZDRを強制し、条件を満たさないプロバイダーへ送らない設定が必要です。

フォールバックは安全性を高めますか

可用性は高まりますが、送信先、価格、品質、データ条件が変わります。事前評価したモデルとプロバイダーだけを候補にし、実際の処理先を記録します。

入出力ロギングは何に注意すべきですか

完全なプロンプトと回答が保存され、公式案内では最低3か月の保持です。機密情報の集中、管理者権限、保存地域、削除手順を確認してから有効にします。

参考資料

• Data collection（OpenRouter）
• Privacy Policy（OpenRouter）
• Guardrails（OpenRouter）
• Input and output logging（OpenRouter）
• Model fallbacks（OpenRouter）