メインコンテンツへスキップ
過度に積極的なガードレールは、ガードレールがないよりも悪いです — あなたのチームは Matches フィードを無視することを学ぶか、ルールを緩めて実際に欲しかった捕捉を 失います。OrcaRouter は精密な中間の道を提供します：単一のマッチを誤検知として マークすると、エンジンがその所見を記憶し、将来のリクエストでそれをスキップ します — ルールに触れたり、パターンを緩めたり、SDK 変更を出荷したりすることなく。 これは誤検知ワークフローに焦点を当てたランディングページです。完全なガードレール エンジン — すべてのルールの種類、フィールド、ルート — については、 ガードレールリファレンスを参照してください。
ここでのすべてのステップは、ホスト型ゲートウェイ（api.orcarouter.ai）上の コンソール アクションです。マッチは自分のセッション下でトリアージします。最後の /v1/* 呼び出しのみが sk-orca-... リレーキーを使います。マッチを誤検知として マークするには、ワークスペース Admin ロールが必要です。Matches フィードと 結果として得られる抑制リストの読み取りは、すべての member に開放されています。

​
1. ルールを弱めずにガードレールの誤検知を減らす

ルールが過剰に発火したときの本能は、それを緩めることです — regex 除外を広げ、 エンティティを落とし、block を flag に反転する。それは 1 つの誤検知を、ポリシーの 穴と引き換えにします。誤検知マークによる抑制は、外科的な代替策です：

ひとつの所見を抑制する

誤作動した正確なマッチ — 特定のルールの下の特定の部分文字列 — をミュートし、 ルール全体ではありません。次の本当に機密性の高いヒットは依然として発火します。

ルール編集なし、再デプロイなし

抑制はワークスペースのメモリとしてゲートウェイに存在します。ルールは書かれた とおりに正確に残ります。あなたのアプリは /v1/* を変更なしで呼び出し続けます。

ワークスペース全体のメモリ

ひとりの Admin が一度マークすれば、抑制はワークスペース全体で重複排除される ため、すべてのメンバーのトラフィックが恩恵を受けます — キーごとのファンアウト なし。

可逆

マッチのマークを解除する（または抑制を削除する）と、所見は次のリクエストで 再び発火します。何も破壊されません。
抑制は、あなたが良性と判断した所見のためのものです。ルール全体が誤調整されている 場合 — 間違った形状、間違ったステージ — マッチを次々とミュートするのではなく、 ルールを修正し、Eval ハーネスでそれを 証明します。

​
2. マッチがどう抑制になるか

発火したすべてのルールは、ワークスペースの Matches フィードにマッチ — ルールの 種類、アクション、ステージ、詳細文字列 — を記録します。それらのマッチのひとつを 誤検知としてマークすると、ゲートウェイは所見に対して安定したフィンガープリントを 導出し、それをワークスペースの抑制リストに書き込みます。すべての将来のリクエストで、 エンジンは各所見のフィンガープリントをそのリストと照合し、block、mask、flag できる 前に、抑制されたものをスキップします。 2 種類の所見がフィンガープリントを生成します：
CVE / SBOM 所見は、すでに安定したアイデンティティを伴って出荷されます — アドバイザリまたはコンポーネントのアイデンティティが所見とともに移動します。 ひとつを抑制すると、その正確な CVE / コンポーネントを、そしてそれだけを ミュートします。これは抑制ストアが構築されたネイティブのケースです。
keyword、regex、PII、その他の決定的なルールの種類は、独自のアイデンティティを 持たないため、ゲートウェイは、書き込み側（あなたの mark-FP クリック）と強制側 （次のリクエスト）で同一なデータからひとつを合成します：ガードレール、ルールの マッチングアイデンティティ、そして — 生キャプチャがオンのとき — マッチした 部分文字列そのもの。
合成フィンガープリントの精度は Log raw content に依存し、これはデフォルトで オフです。キャプチャがオンの場合、フィンガープリントは正確なマッチした 部分文字列をキーにするため、ORD-48291507 を抑制するとその注文番号だけを ミュートし、他には何もしません。キャプチャがオフの場合、キーにする部分文字列が ないため、抑制はルールレベルのミュートにフォールバックします — それはその 1 つの ルール（そのステージで）をワークスペースに対して沈黙させます。フォールバックは、 それが来たルールを決して超えて到達しません。 ロギングとプライバシーを参照してください。

​
3. 具体例 1 つ

ORD- に 8 桁を足した形の内部注文番号をマスクする regex ルールを実行している とします。サポートチケットが ORD-48291507 を、通過させても問題ないと判断した 形で正当に引用しています。あなたはルールを弱めたくありません — ただこの 1 つの 番号が発火を止めることを望みます。
1

Matches フィードを開く

コンソールで Guardrails → Matches を開きます。ガードレールとルールの種類で フィルターして、ORD-48291507 ヒットの行を見つけます。（リテラルな部分文字列を 見るには、マッチが記録されたときにガードレールの Log raw content がオンで なければなりません — デフォルトでオフです。）
2

誤検知としてマークする

マッチ詳細を開き、Mark as false positive を選びます。ワークスペース Admin として、これはマッチにスタンプを押し、所見のフィンガープリントを キーにしたワークスペース抑制をミラーします。
3

抑制されたことを確認する

Suppressions リストを開きます — 新しいエントリが、それが来たガードレールと ルール、そして理由 “Marked as false positive from Matches” でラベル付けされて 表示されます。ワークスペースのすべてのメンバーがこのリストを読めます。
4

同じリクエストを再び送信する

リレーキーを使って、以前と全く同様に OrcaRouter を呼び出します — 新しい ヘッダーなし、SDK 変更なし：
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": "Status of order ORD-48291507?"}
    ]
  }'
抑制された所見はスキップされ — ORD-48291507 は通過します — 一方、他の 注文番号は依然としてマッチし、以前と同様にマスクされます。

​
4. 抑制 vs. 代替策

抑制は、ノイジーなルールを静かにする 4 つの方法のひとつです。適合する最も狭いものを 選びます：
アプローチ何を変えるかいつ手を伸ばすか
Mark FPひとつの所見（またはひとつのルール、キャプチャオフ）特定の良性ヒット；ルールはそれ以外は正しい
ルールを編集マッチングそのもの間違った形状 / ステージ — 修正してから再 eval
flag アクション観察のみ、ブロックなしまだ信頼していない新しいルール
Eval ハーネスライブには何もなし — 測定する出荷前に適合率を証明する
体系的に間違ったルールを、FP を次々マークすることで取り繕わないでください。同じ 形状を繰り返し抑制している場合、ルールは誤調整されています — regexをアンカーし、 キーワードリストを絞り込むか、より厳格な PII エンティティを選び、 eval 実行で検証します。

​
5. 抑制を取り消す

ここでは何も一方通行ではありません：
  • マッチのマークを解除する — 同じ Admin アクションを逆にすると、マッチの FP スタンプを削除し、（他に FP マークされたマッチがそれにマップしない場合）抑制を 落とします。所見は次のリクエストで再び発火します。
  • 抑制を直接削除する — Suppressions リストから、Developer+ アクションが エントリを削除します。同じ効果：所見が再びライブになります。
抑制はワークスペースのメモリであるため、ひとつを取り消すとすべてのメンバーの トラフィックに対して捕捉が一度に復元されます — 全員に対して抑制をマークするのと 同じです。

​
6. API 面

これらはコンソールルートであり、セッションで認証します — リレーキーでは ありません。各アクションをロールゲートします：マッチを FP マークするのは Admin、 抑制の読み取りは Member、抑制の書き込みは Developer+ です。
メソッドとパスロール目的
GET /api/guardrail/matchMemberトリアージするマッチを一覧します。
POST /api/guardrail/match/:id/mark-fpAdminマッチを誤検知としてマークします（抑制をミラーします）。
DELETE /api/guardrail/match/:id/mark-fpAdminマークを解除します — 所見を復元します。
GET /api/guardrail/suppressionsMemberワークスペースのアクティブな抑制を一覧します。
POST /api/guardrail/suppressionsDeveloper+抑制を直接追加します。
DELETE /api/guardrail/suppressions/:idDeveloper+抑制を削除します。
mark-FP エンドポイントはレート制限されています — それらは意図的で低ボリュームの トリアージアクションであり、バルク API ではありません。ポリシー全体をチューニング しているときは、mark-FP 呼び出しのループではなく、Eval ハーネスに手を伸ばします。

​
7. 次に進む先

Matches フィード

発火したすべてのルールが着地する場所 — 何かをマークする前にトリアージする場所。

テストと eval

出荷する前にコーパスに対してルールの適合率を証明します — 抑制が症状を扱っている ときの体系的な修正。

ロギングとプライバシー

Log raw content が、抑制が正確な部分文字列をキーにするか、ルールレベルの ミュートにフォールバックするかをどう制御するか。

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

完全なエンジン — すべてのルールの種類、アクション、ルート。
抑制はコンテンツ所見を統制します。ノイジーなエージェントファイアウォール ルール — 安全と判断したツールマッチ — を静かにするには、それは別個の面です。 ファイアウォールとその 異常フィードを参照してください。 ガードレールとファイアウォールがどこで分かれるかを理解するには、 ガードレール vs. ファイアウォールを 読んでください。