メインコンテンツへスキップ
トラブルシューティングのためにリクエストログ捕捉をオンにすると、プロンプトと レスポンスのボディ — まさにプライバシー規制が必要以上に長く保持しないよう求める データ — を保存することになります。OrcaRouter はそのためにワークスペースごとの 単一のダイヤルを提供します：健全なデフォルトと、サーバーが強制するハード上限を 持つ保持ウィンドウです。そのため、忘れた捕捉が永遠に蓄積する代わりにエイジアウト します。 このページは、そのダイヤルがどう機能し、消去にどう結びつくかをカバーします。 より広いエビデンスのストーリーについては、 コンプライアンス概要から始めてください。

​
1. なぜゲートウェイで LLM ログ保持が重要なのか

リクエストログ捕捉はオプトインで、明示的に有効化するまでオフであり、記録 された同意確認の背後にゲートされています — なぜなら、それをオンにすると完全な プロンプトとレスポンスのテキストが永続化されるからです。一度オンになると、監査人 が尋ねる質問は、あなたがログを取るかどうかではなく、それをどれくらい長く保持 するかです。30 日デフォルトは有用なトラブルシューティング証跡を保ちます；サーバー 強制の 180 日上限は、どんなに改ざんされたクライアントリクエストでも、コンプライ アンス上限を超えてボディを保持できないことを意味します。
保持は捕捉されたリクエストログ（オプトインのプロンプト/レスポンスボディ）に 適用されます。メータリングと課金のレコード、そして 署名付きレポートで説明される署名付き コンプライアンスレポートは、それぞれ独自のライフサイクルに従います — この ページは捕捉ログの時計についてです。

​
2. 2 つの数字

デフォルト：30 日

新しく有効化された捕捉はボディを 30 日保持します。保持フィールドを未設定 のままにすると、すべてのワークスペースがこれを継承します。

ハード最大値：180 日

サーバーは要求された保持を 180 日にクランプします。それ以上を求めると、 値は密かに上限まで減らされます — エラーではなく、上限です。
ハード上限は 180 日です：180 を超える値は 180 でキャップされ、0 の値 （または未設定）はデフォルトを継承を意味します — それは 30 日に解決します。 デフォルトとライブの上限は、設定パネルが正しい境界をレンダリングできるよう、 公開ステータスペイロードから読めます： 
GET /api/status
レスポンスは request_log_default_retention_days、 request_log_max_retention_days、request_log_default_enabled を運びます — 入力を表示する前にコンソールが読む有効な境界です。

​
3. 保持を設定する（ひとつの具体的なフロー）

保持はワークスペース設定で、コンソールの Settings → Privacy の下で設定 します。どのメンバーも読めます；それを変更するにはワークスペース管理者 ロールが必要です。コンソールがあなたのセッションでこの管理ルートを駆動します （リレーキーではなく UserAuth ルート）、そのため設定呼び出しに sk-orca-... キーを入れることは決してありません： 
PUT /api/workspaces/:id/request-log-settings
Authorization: Bearer <your console session>

{
  "request_log_enabled": true,
  "request_log_retention_days": 60
}
この呼び出しでサーバーが強制するいくつかのルール：
request_log_enabled はポインタトグルです。省略すると保存された値はそのまま 残ります；true/false を送って遷移させます。捕捉をオンにするには、現在の 取り消されていない同意確認が必要です — 同意レコードはサーバーが権威を持ち、 クライアント JSON から決して読まれません。 同意を参照。
request_log_retention_days は丸一日の整数で、[1, 180] にクランプされます。 0 は「既存の値のまま」（または下流でシステムデフォルトを継承）を意味します； 200 は 180 になります。
スケジュールで実行するものは何もありません。保持ウィンドウを超えた捕捉された ボディはゲートウェイによって削除されます；あなたはウィンドウを設定し、ゲート ウェイがそれを強制します。
最もリスクの低い姿勢は明白なものです：積極的にトラブルシューティングしていない 限り捕捉をオフにしておき、有効化するときは、デバッグループをまだカバーする 最短の保持を設定します。30 日デフォルトは既に保守的です。

​
4. 保持 vs 消去

保持は通常の流れで捕捉ログをエイジアウトします。消去は、データ主体リクエスト （DSAR）またはアカウントクローズのためのオンデマンドパスです — そしてそれはログの 時計よりも遠くに届きます：
トリガーウィンドウその後
保持を過ぎた捕捉ログ最大 180 日ログ削除
アカウントのセルフ削除30 日猶予PII スクラブ + カスケードパージ
セルフ削除はアカウントを即座にソフト削除し、30 日後の不可逆な PII スクラブを スケジュールします。その猶予ウィンドウの間、アカウントはまだ復元でき、そのデータ はエクスポートできます；ウィンドウが閉じると、スクラブが実行され、カスケードが リクエストログ、ガードレールマッチ、ファイアウォールイベント、エージェントトレース ノードを、対象に結びついたものをパージします。消去権はしたがって別の保持設定 ではありません — それは時間ベースのウィンドウに優先する、より強力な、対象が 開始するパージです。
30 日削除猶予は復元ウィンドウであり、追加のログ保持ではありません。その中の データはソフト削除されエクスポート可能ですが、スクラブへの一方通行のパス上に あります。ウィンドウが閉じる前にエクスポートを計画してください。
完全な DSAR の仕組み — 猶予、スクラブ、カスケードが触れるもの — については 消去権を参照。

​
5. これがフレームワークをどう満たすか

ほとんどのプライバシー規制は、2 つの実証可能なものを求めます：定義された保持 期間と動作する消去パスです。保持ダイヤルと削除カスケードはまさにその 2 つの コントロールであり、コンプライアンスパックはそれらをフレームワークのエビデンス にマッピングするため、レポートがその状態を読めます。パックをインストールすると、 同じ保持と消去の挙動が準備状況ビューで参照されます — 別の設定は不要です。

パックをインストールする

フレームワークのコントロールを実体化；保持と消去はそれが期待するプライバシーの ストーリーの一部です。

フレームワーク

ライブのカタログ — GDPR、CCPA、HIPAA、そして保持を固定する地域プライバシー 規制。

​
6. これがどう位置づけられるか

消去権

セルフ削除、30 日猶予、PII スクラブ、パージカスケード。

同意

リクエストログ捕捉がオンになる前に必要な記録された確認。

データレジデンシー

署名付きコンプライアンスエビデンスが保存され配信される場所 — 保持とは別の リージョンコントロール。

責任共有

ゲートウェイは設定した保持を強制します；ウィンドウと消去ケイデンスの選択は あなたのものです。
OrcaRouter 上の保持は、デフォルトとハード上限を持つひとつの正直なダイヤルです： 必要なときだけ捕捉を有効化し、ウィンドウを短く保ち、ゲートウェイにボディを エイジアウトさせます — 主体が完全に忘れるよう求めた瞬間のために消去を待機させて。