メインコンテンツへスキップ
ガードレールをアタッチし、今度は何を捕捉したか確認したい。Matches フィードは OrcaRouter のガードレールマッチログです — ルールが発火するたびに（block、mask、 flag、annotate、または spotlight）、ゲートウェイは、コンソールでレビューしたり API で取得したりできるマッチを記録します。これが「昨日 PII ルールが何をリダクト したか？」、「どのキーがシークレットブロッカーを引っかけるか？」、「このルールは 実際のトラフィックで発火しているのか、それとも単なるノイズか？」に答える方法です。 このページはマッチの読み取りとトリアージに焦点を当てたガイドです。ルールがどう 作成され、各アクションが何をするかについては、 ガードレールリファレンスを参照してください。

​
1. ガードレールマッチログが記録するもの

発火したすべてのルールは、ワークスペーススコープのフィード （GET /api/guardrail/match、任意の Member に開放）に 1 つのマッチを 書き込みます。フィードはリクエストログとは別個です — ガードレールが何をしたかだけ を保存し、完全なリクエストボディは保存しません。各マッチが記録するもの：
rule_type（keyword、regex、pii、max_chars、external、 llm_judge、grounding）、有効な action（block / mask / flag / annotate / spotlight）、そして stage（input または output） — これに より、何が発火し何をしたかを即座に判別できます。
guardrail_name、発火した rule_label、加えてリクエストコンテキスト： model_name、それが乗ってきた token、呼び出し元の ip、そして リクエストログに結合し直す request_id。
detail — 違反に対するエンジンの短い人間可読のノート（例：どのエンティティ またはパターンが引っかかったか）、常に記録されます。
matched は、ガードレールの Log raw content トグルがオンのときに のみ埋められます。デフォルトでオフのため、デフォルトではフィードは ルールが発火したこととその理由を教えますが、機密文字列そのものは決して 保存しません。
生コンテンツはオプトインで非遡及的です。 Log raw content がオフ （デフォルト）の場合、matched フィールドは空のままです — フィードは判定と detail を記録し、ルールを引っかけた email アドレス、シークレット、PII は決して 記録しません。トリアージのために部分文字列が必要なときにのみ、ガードレールごとに オンにします。それは、有効化した後に記録されたマッチに適用されます。 ロギングとプライバシーを参照してください。

​
2. マッチログを一覧してフィルターする

デフォルトの一覧ビューは、カーソルページネーション、新しい順、そして ワークスペースにスコープされています。クエリパラメータで絞り込みます — コンソールは これらをフィルターチップとして公開します：
パラメータフィルター対象
guardrail_id、rule_type、action、stage判定
token_id、model_name、request_idリクエストコンテキスト
days / start_at + end_at、hide_fpウィンドウと誤検知の状態
「今週シークレットガードレールがブロックしたものをすべて見せて」という典型的な 読み取り、コンソールセッショントークンを使用： 
curl "https://api.orcarouter.ai/api/guardrail/match?guardrail_id=42&action=block&days=7" \
  -H "Authorization: Bearer <your-session-token>" \
  -H "X-Workspace-Id: <workspace-id>"
/api/guardrail/* のような管理ルートは、リレーキーではなくコンソール セッション / アクセストークンで認証します。sk-orca-... キーは /v1/* モデル呼び出し専用です。日々の使用では、Guardrails ページの Matches タブから フィードを直接読みます。

​
3. リクエストでグループ化する

単一のリクエストが一度に複数のルールを引っかけることがあります — 入力 PII マスク と最大長上限、というように。グループ化されたビュー （GET /api/guardrail/match/grouped、Member）は、マッチを request_id で折りたたむ ため、同じ呼び出しに対して 5 行をスクロールする代わりに、違反するリクエストごとに 1 行を、そのマッチをインラインで折りたたんで見られます。グループごとにインラインで 表示するマッチ数は inline_limit（デフォルト 5）でチューニングします。

​
4. 統計とトレンドストリップ

統計エンドポイント（GET /api/guardrail/match/stats、Member）は、Matches タブの カウントストリップとチャートを支えます — days ウィンドウ内の合計を、オプションで group_by で内訳します：
group_by内訳
(省略)合計のみ
rule_typeどのルールの種類が最も発火するか
guardrail_idどのガードレールがアクティビティを占めるか
request_id を渡すと、1 つのリクエストに対する定数時間のマッチカウントが得られます （リクエストログのクロスリンクで使用）。ここにガードレールごとの使用量、アクションの 構成、誤検知率が存在します — 生の一覧をページングするのではなく、これをスライス します。

​
5. 監査証跡のためにエクスポートする

コンソールの外でマッチが必要なとき — エビデンスパック、スプレッドシート、下流の SIEM — GET /api/guardrail/match/export（Member）は、現在のフィルターセットを CSV または JSON としてストリームします： 
curl "https://api.orcarouter.ai/api/guardrail/match/export?format=csv&guardrail_id=42&days=30" \
  -H "Authorization: Bearer <your-session-token>" \
  -H "X-Workspace-Id: <workspace-id>" \
  -o guardrail-matches.csv
エクスポートは、フィードが記録するのと同じカラムを持ちます — 時刻、ガードレール、 ルールの種類とラベル、ステージ、アクション、モデル、トークン、詳細、マッチした 部分文字列（記録時に生コンテンツキャプチャがオンだった場合のみ）、リクエスト ID、 ip、そして誤検知のタイムスタンプ。
CSV は数式インジェクションに対して安全です：スプレッドシート数式として読み取られる 可能性のあるセルは中和されるため、Excel や Sheets でエクスポートを開いても、 マッチした部分文字列を通じて密輸されたペイロードが実行されることはありません。

​
6. 誤検知をトリアージする

すべてのマッチが本物のヒットというわけではありません。ルールが良性のトラフィックで 発火したとき、ワークスペース Admin はマッチを誤検知としてマークできます （POST /api/guardrail/match/:id/mark-fp）。逆の DELETE /api/guardrail/match/:id/mark-fp はそれを解除します。マークは、フィードの 残りが Member 読み取り可能であっても Admin 専用です — トリアージは特権アクション です。 誤検知をマークすると 2 つのことが起こります：マッチにタグを付け（そのため hide_fp=true がそれをフィードから除外します）、そして所見を記憶するため、同じ コンテンツに対する同じルールが将来のリクエストでスキップされます。強制を復元するには マークを解除します。ノイジーなルールのチューニングのより広いワークフローについては、 誤検知のチューニングを参照してください。
マッチは診断データであり、強制の判断ではありません。 リクエストがブロック、 マスク、または単にフラグされたかは、リクエスト時のアクションで すでに決着しています — フィードは事後の記録です。誤検知をマークすると将来の 挙動が変わり、すでに発生した呼び出しは決して変わりません。

​
7. マッチがどこから来るか

マッチは、リレーパス上のガードレールエンジンによって生成されるため、フィードは アタッチされたポリシーが行ったことを正確に反映します：
  • 入力ステージのマッチは、モデルが目にする前にゲートウェイが スクリーニングしたものを記録します — 入力ステージを 参照してください。
  • 出力ステージのマッチは、レスポンス上でスクリーニングしたものを記録します — 出力ステージを参照してください。
  • ブロックされたリクエストは、呼び出し元への HTTP 400 guardrail_blocked としても表に出ます。マッチはそのサーバーサイドの記録です。
リクエストでガードレールが解決されなければ、何もスクリーニングされず、何も フィードに着地しません — 挙動は、この機能を一度も有効化していないワークスペースと 同一です。ポリシーがそもそもどうトラフィックの前に立つかについては、 キーにアタッチと アカウントデフォルトを参照してください。

​
8. 関連

ガードレールリファレンス

完全なエンジン：ルールの種類、ステージ、アクション、プリセット、eval ハーネス。

ロギングとプライバシー

Log raw content トグルと、フィードが保存するもの — そして保存しないもの。

誤検知のチューニング

フィードを使ってノイジーなルールを見つけ、ポリシーを弱めることなく静かに します。

バージョニング

フィードが変更の誤作動を示したとき、ガードレールを diff して revert します。
ゲートウェイがトラフィックをどう検査するかのより大きな全体像については、 OrcaRouter がどう検査するかと ガードレール vs. ファイアウォールを 参照してください。