メインコンテンツへスキップ
ガードレールルールが発火すると、OrcaRouter はマッチを記録するため、あなたは 何が引っかかりどのくらいの頻度でかを確認できます。このページが答えるプライバシーの 問いはこれです：その記録は実際の機密テキスト — 本物の email、SSN、API キー — を 含むのか、それともルールがマッチしたという事実だけなのか？ デフォルトでは事実だけを含みます。ホスト型ゲートウェイ上のガードレールの プライバシーロギングは、意図的に保守的です：マッチした部分文字列は、そのガードレールに 対して Log raw content を明示的にオンにしない限り保存されず、トグルを反転 しても、すでにログした過去のデータには決して遡りません。 これは Matches フィードのプライバシー姿勢に焦点を当てたランディングページです。 フィードそのもの — ブラウズ、グループ化、エクスポート — については、 Matches フィードを参照してください。完全な エンジンについては、ガードレールリファレンスを参照してください。

​
1. ガードレールのプライバシーロギング：デフォルトでオフ

すべてのガードレールは、ポリシーごとの単一のトグル Log raw content を持ち、 それはオフで出荷されます。それがオフの場合、マッチは発火したもののメタデータを 記録しますが、違反するテキストをフィードにコピーすることは決してありません：

トグルがオフのときに記録される

ルールの種類、アクション、ステージ、そして短い詳細文字列 — pii ルールが リクエスト上で email をマスクしたことを、アドレスを保存せずに知るのに十分です。

オンのときにのみ追加される

マッチした部分文字列 — ルールが捕捉したリテラルなテキスト。トグルを 有効化した後に記録されたマッチに対してのみキャプチャされます。
その根拠は、ほとんどのコンプライアンスチームがデフォルトで望むものです：SSN が トラフィック内に現れたこととポリシーがそれをどう処理したかを、規制対象データを リクエストから自分の診断ストアにコピーして戻すことなく学べます。
デフォルトでオフがプライバシー保守的な姿勢です。 マッチした部分文字列は、 ガードレールがログしうる最も機密性の高いものです — それは定義上、ルールが捕捉 するために存在するデータです。OrcaRouter は、ガードレールごとにオプトインしない 限り、それを保存しません。

​
2. マッチ記録が保持するもの

マッチは、小さなワークスペーススコープの診断記録です。Log raw content が オフの場合、メタデータのみを保持します：
フィールド例トグルがオフのとき存在するか？
ルールの種類pii、regex、keywordはい
アクションblock、mask、flagはい
ステージinput、outputはい
詳細短い分類文字列（例：エンティティ）はい
マッチした部分文字列jane@acme.comオンのときのみ
マッチした部分文字列フィールドが、トグルがゲートする唯一のものです。それ以外の すべてはどちらにせよ記録されるため、生コンテンツがオフでも、フィードは量、トレンド、 アクション構成の分析に役立ちます。
PII がどこに入るか、どのルールが最も発火するか、ポリシーがノイジーかどうか — 観察または強制のプログラム全体を、純粋にメタデータ上で実行できます。トリアージ中に 正確に何がマッチしたかを目視する必要がある狭いウィンドウに対してのみ、部分文字列を オンにします。

​
3. 具体例 1 つ

リクエスト上で email をマスクする pii ルールを持つガードレールを取り上げ、 キーにアタッチします。呼び出し元が送信します： 
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [
      {"role": "user", "content": "Reply to jane@acme.com please"}
    ]
  }'
ルールは、モデルが目にする前にアドレスを [EMAIL] にマスクし、マッチがフィードに 着地します。そのマッチが何を含むかは、完全にトグルに依存します：
マッチは記録します：ルールの種類 pii、アクション mask、ステージ input、 そして email エンティティを示す詳細文字列。それは jane@acme.com を 保存しません。email がリクエスト上でマスクされたことは分かりますが、 フィードから email を読み戻すことはできません。
同じマッチが、加えてマッチした部分文字列 — jane@acme.com — を持つため、 トリアージパス中にルールが捕捉したものを正確に確認できます。
リクエストそのものは、いずれの場合も同一です。トグルは、診断フィードが 保持するものだけを変え、呼び出し元やアップストリームモデルが経験するものは決して 変えません。

​
4. それをオンにする（そして非遡及的保証）

Log raw content はガードレールごとの設定です。ガードレールの編集は、自分の セッション下のコンソール アクションであり、ワークスペースで Developer+ が 必要です — 最後の /v1/* 呼び出しのみが sk-orca-... リレーキーを使います。
1

ガードレールを開く

コンソールで Guardrails を開き、部分文字列をキャプチャしたいポリシーを 編集します。
2

Log raw content を有効化する

Log raw content トグルをオンにして保存します。保存はバージョン付きの履歴行を 書き込むため、変更は監査可能で revert 可能です — バージョニングを参照してください。
3

キャプチャは前進方向で始まる

次のリクエスト以降、このガードレールでのマッチはマッチした部分文字列を含みます。 トグルを反転する前に記録されたマッチは、メタデータのみのままです。
トグルは非遡及的です — 両方向に。 それをオンにしても、すでにログした マッチに部分文字列を後追いで埋めることはありません。それらの古い記録は永遠に メタデータのみのままです。それをオフにすると、新しい部分文字列のキャプチャを 停止しますが、過去のマッチにすでに保存された部分文字列を消すことはありません。 それらを消す必要がある場合は、§6 を 参照してください。

​
5. オンのときに何がキャプチャされるか

Log raw content がオンのとき、エンジンは各違反にリテラルなマッチテキストを 添付しますが、ひとつの病的な入力が単一のマッチ記録を膨れ上がらせないよう、2 つの ハードキャップがあります：
  • 違反ごとに最大 32 のマッチエントリ。
  • 各エントリは 256 文字に制限されます。
そのため、巨大なドキュメント上で発火するガードレールは、本文全体ではなく、マッチした ものの境界のある代表的なサンプルを保存します。詳細文字列も独立して長さがクランプ されます。これらのキャップはストレージ衛生のために存在します。キャプチャされた セットは、リクエスト全体の逐語的トランスクリプトではなく、何がマッチしたかの エビデンスとして扱ってください。
トグルがオンでも、ガードレールはルールが実際にマッチしたテキストしか決して 記録しません。周囲のプロンプトとレスポンスの残りは、決して Matches フィードに コピーされません。完全なリクエスト / レスポンスのペイロードは、ガードレール診断とは 別個の関心事です。

​
6. すでにキャプチャした部分文字列を削除する

トグルが非遡及的であるため、それをオフにしても、以前の部分文字列はそのままです。 2 つの面がそれらをクリアします：
削除したいもの方法
ノイジーなマッチ 1 つそれを誤検知としてマークします — POST /api/guardrail/match/:id/mark-fp（ワークスペース Admin）、またはフィードの Mark false positive アクション。
あるユーザーのすべてのガードレールマッチユーザーの自己削除は 30 日間の猶予ウィンドウをトリガーし、その後、ガードレールマッチ、リクエストログ、ファイアウォールイベントを通じてカスケードする PII スクラブを行います。コンプライアンスを参照してください。
データをスクラブするのではなく、おしゃべりなルールをチューニングするには、 誤検知のチューニングフローが、 マッチのマークと絞り込みを案内します。

​
7. 誰が何を読めるか

Matches フィードは、ワークスペーススコープの診断データです。読み取りアクセスは、 すべてのアクティブな member に開放されています。破壊的な誤検知アクションは、 より高くゲートされています：
アクションルートロール
マッチの一覧 / グループ化 / 統計 / エクスポートGET /api/guardrail/match*Member
単一マッチ詳細GET /api/guardrail/match/:idMember
誤検知のマーク / マーク解除POST / DELETE /api/guardrail/match/:id/mark-fpAdmin
ガードレールの編集（Log raw content を含む）PUT /api/guardrail/Developer+
これらの管理ルートは、リレーキーではなくコンソールセッションで認証します。 読み取りは、トグルがキャプチャしなかった部分文字列を決して公開しません — 読み取り時に リダクトする追加のものはありません。なぜなら追加のものは保存されなかったからです。

​
8. 実用的なプライバシーデフォルト

ほとんどのワークスペースにとって適切な形はこうです：Log raw content をオフのまま にし、ガードレールをメタデータ上で実行し、ルールがなぜその挙動で発火するかを 能動的にデバッグしているときに、単一のポリシーに対してトグルを一時的にオンに します。それからオフに戻します — 新しいマッチは即座に部分文字列を運ばなくなります。
これは observe-only のロールアウトと自然に組み合わさります。 Compliance Logger（flag のみ）から 始め、メタデータ上で Matches フィードを 観察し、特定のマッチがより詳しい確認を必要とする場合にのみ生コンテンツに手を 伸ばします。

​
9. 次に進む先

Matches フィード

記録されたすべてのマッチをブラウズ、グループ化、フィルター、エクスポートします。

誤検知のチューニング

マッチをマークして絞り込み、ノイジーなルールを静かにします。

バージョニング

すべてのトグルの反転は、バージョン付きで revert 可能な変更です。

コンプライアンス

保持、データ主体の消去、署名付きレポート。
これがより広いコントロールスタックにどう適合するかについては、 ガードレール vs. ファイアウォールと データ持ち出しを参照してください。完全な エンジン — ステージ、高度なルール、ルート — については、 ガードレールリファレンスを読んでください。