メインコンテンツへスキップ
アプリがストリームする場合、コンテンツポリシーを信頼する前に、ひとつの率直な答えが 必要です：SSE レスポンス上で実際に何が強制されるか。 全体のレスポンスを検査する ガードレールは推論しやすく、デルタがブラウザにフラッシュされる際にそれらに対処 しなければならないガードレールはそうではありません。このページはストリーミング ガードレールカバレッジマトリクスです — すべてのアクション、入力と出力のステージに わたって、ストリーミングと非ストリーミングのトラフィック上で — ライブストリーム上で 各セルがどう挙動するかについて正確であるよう書かれています。 完全なエンジン — すべてのルールの種類、フィールド、ルート — については ガードレールを参照してください。ストリームがどう打ち 切られるかのメカニクスについては、ストリームセーフなルールを 参照してください。

​
1. ストリーミングガードレールカバレッジの問い

ガードレールルールは、ステージ（input、output、または both）と アクション — 5 つのうちのひとつ：block、mask、flag、annotate、または spotlight — を持ちます。ステージはゲートウェイがそれをいつ実行するかを決め、 アクションはそれが何をするかを決めます。ストリーミングが答えの形を変える唯一の 場所は出力ステージです — なぜならそれが、ゲートウェイがバイトを到着するそばから クライアントに転送し、ペイロード全体を先に保持する機会のない唯一のステージだから です。 そのためマトリクスには、ストリーミングが重要な 2 つのセルがあり、それらは異なる 挙動をします：出力 block はストリーム上で完全に強制されます（スキャナがそれを 打ち切ります）が、出力 mask は非ストリーミングレスポンスにのみ強制されます。 ストリーミングレスポンスでは、スキャナは依然としてマッチを検出し、block の判断には 対処できますが、今日はマスクされたテキストをストリームに書き換えることはしません — インバンドのストリーミング出力マスキングはロードマップ上にあります。
入力は決して問題ではありません。 入力ステージのルールは、モデルの前に走り ます — ゲートウェイがリクエストをスクリーニングし（mask の場合は書き換え）、 その後サニタイズされたバージョンをアップストリームに転送します。レスポンスが ストリームするかどうかは無関係です。リクエストは、ゲートウェイが完全に保持する 完結したペイロードです。入力スキャンは、すべてのリクエストで完全にライブ、 マスキングを含むです。

​
2. カバレッジマトリクス

これを上から下へ読んでください。すべての block セルはライブで、ストリーミングを 含みます — しかし output + mask + streaming が、ストリーム内でまだ強制 されていない唯一のセルです：mask ルールは非ストリーミングレスポンスをリダクト しますが、ストリーミングレスポンスではデルタを書き換えずにマッチを検出します （ストリーム内出力マスキングはロードマップ上にあります）。
ステージ · アクション非ストリーミングストリーミング
input · blockリクエストを拒否リクエストを拒否
input · maskリクエストを書き換えリクエストを書き換え
output · blockレスポンスを拒否ストリームを打ち切る
output · maskレスポンスをリダクトマッチを検出；ストリーム内ではリダクトしない（ロードマップ）
any · flag記録のみ記録のみ
annotate と spotlight は、トラフィックを拒否することなくノートを添付（または マッチしたテキストを囲む）し、実際には入力ステージのアクションであるため、上記の 出力 / ストリーミングのセルを変えません。それらは他のどのルールとも同様にマッチを 記録します。
入力ステージのルールは、アップストリームモデルが走る前にリクエストをスクリーニング します。block は呼び出しを短絡します（HTTP 400 guardrail_blocked、 メータリングの前なので、クォータを消費しません）。mask はプロンプト内の マッチしたフィールドをその場で書き換えます — サニタイズされたテキストが アップストリームに行くものであり、モデルが元のものを目にすることはありません。 これらのどれも、レスポンスがストリームするかどうかには依存しません。
非ストリーミングレスポンスでは、completion が返る前に完全にスクリーニングされ ます — block は HTTP 400 guardrail_blocked として表に出ます。ストリーミング レスポンスでは、ストリームスキャナがデルタが流れる際にそれを監視します。 block ルールが発火すると、それはストリームを打ち切り — スキャナを封印し、 残りの代わりに短い置換通知を発し、さらなるブロック対象のコンテンツがクライアントに 届く前に SSE チャネルを閉じます。200 SSE ヘッダーはその時点ですでに出ている ため、ストリーミング block は 400 を返せません：block を HTTP エラーではなく、 最終のインバンドデルタとして配信します。
非ストリーミングレスポンスでは、mask ルールが completion を書き換え — 例： email が [EMAIL] になり — サニタイズされたテキストがクライアントが得るものに なります。ストリーミングレスポンスでは、ストリームスキャナは依然として マッチを検出してマスクを計算しますが、マスクされたテキストをデルタに転送 しません — マスクされた出力は破棄され、block の判断のみが実行されます。 そのため、mask ルールは今日ストリーミングレスポンスをリダクトしません。 インバンドのストリーミング出力マスキングはロードマップ上にあります。ストリーム されたレスポンスから今すぐ PII を排除する必要がある場合は、ルールを block として 作成する（スキャナがマッチでストリームを打ち切ります）か、非ストリーミングで スクリーニングしてください。
flag ルールは決してトラフィックを変えません — マッチを記録し、バイトを通します。 ステージとストリームはその挙動を変えません。block にプロモートする前に、ルールの ヒット率を測定するために使います。
覚えるべき 1 行： 出力 block は両方のトランスポート上でライブで強制され ます — ストリーミングを含む — そして入力マスキングは常にライブです。出力 mask は 非ストリーミングレスポンスのみをリダクトします。ストリーム上では、マッチを検出 しますが、まだデルタを書き換えません（ストリーム内出力マスキングはロードマップ上に あります）。ストリームされたレスポンスから今日 PII を排除するには、ルールを block として作成するか、非ストリーミングでスクリーニングします。

​
3. 具体例 1 つ — ストリームされたレスポンスから PII を排除する

モデルが RAG コンテキストから顧客の email を表に出しうる場合で、あなたのアプリが ストリームするとします。出力 mask は今日ストリーム内でリダクトしません （ストリーム内出力マスキングはロードマップ上にあります） — そのため、ストリーム されたレスポンスから PII を排除するには、出力ルールを block として作成します： スキャナはマッチが現れた瞬間にストリームを kill します。（出力 mask は非ストリーミング レスポンスではリダクトします。） ポリシー編集は、コンソールセッション上の管理アクションです（Developer+ に ゲート）。sk-orca-... リレーキーは /v1/* トラフィックのみを送信し、ポリシーを 決して編集しません。
  • /console/guardrails を開き、New guardrail、stream-pii-out と名付けます。
  • ルールを 1 つ追加します：
    • Type: PII detection
    • Stage: output
    • Action: block ← マッチでストリームを打ち切る；ストリーム上では mask は検出のみ（非ストリーミングレスポンスをリダクトします）
  • 保存し、その後 /console/token でキーの Guardrail ドロップダウンから アタッチします。
これで stream: true でゲートウェイを呼び出します、以前と全く同様に： 
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "stream": true,
    "messages": [
      {"role": "user", "content": "Email the customer from the record above"}
    ]
  }'
デルタがマッチすると、スキャナはストリームを打ち切り、置換通知を発し、チャネルを 閉じます — クライアントは残りを決して受け取りません。レスポンスがクリーンであれば、 すべてのデルタは手つかずで通過します。
ストリーミング block はマッチの後のすべてを止めますが、マッチが着地する前に すでにフラッシュされたバイトを送信解除することはできません。1 バイトの違反する バイトも決してクライアントに届かないことをポリシーが要求する場合は、リクエストを 非ストリーミングでスクリーニングしてください。そこでは、ポリシーがクリアする まで completion 全体が保持されます。

​
4. マトリクス全体での PII Shield

PII Shield プリセットは、単一の pii ルール、アクション mask、ステージ both です。それをマトリクスにマッピングすると、カバレッジは §2 から期待される とおりです：
  • 入力ステージ — 完全にライブ、ストリーミングであるかどうか。リクエストは モデルが目にする前にマスクされます（入力マスキングの見出しとなる価値）。
  • 出力ステージ、非ストリーミング — completion が返る前にマスクされます。
  • 出力ステージ、ストリーミング — ストリームスキャナはマッチを検出しますが、 今日はデルタを書き換えません。そのため、マスクされた形はストリームされた クライアントに届きません（ストリーム内出力マスキングはロードマップ上にあります）。
そのため、mask プリセットはそれ自体ではストリームされたレスポンスからの PII を カバーしません。ストリームされたレスポンスから PII を排除するには、そのルールを block として作成（または非ストリーミングで呼び出し）し、マッチでストリームが 打ち切られるようにします。PII Shieldと マスキングフォーマットを参照してください。

​
5. ストリーミング block が何を消費するか

ストリーミング block は、どの出力 block とも同じ会計を持ちます — モデルはすでに 走っているため、ゲートウェイが返金を処理します：
  • 非ストリーミングレスポンスでは、呼び出しは発火したガードレールとルールを示す HTTP 400 guardrail_blocked を返します。ストリーミングレスポンスでは、 200 SSE ヘッダーがすでにワイヤー上にあるため、block は 400 の代わりに、最終の インバンド置換デルタとクリーンなチャネルクローズとして到着します。
  • クォータは課金されません。 入力 block はメータリングの前に発火します。出力 block（ストリーミングであるかどうか）は、レスポンスが拒否されると事前消費された クォータを返金します。いずれにせよ呼び出し元は何も支払いません。
  • リクエストは skip-retry とマークされます — 同じプロンプトを再実行しても またブロックされるだけなので、ゲートウェイは別のチャネルでのリトライを燃やしません。
発火したすべての出力ルールは、ワークスペースの Matches フィード （GET /api/guardrail/match、任意の Member に開放）にマッチも記録します。 マッチした部分文字列は、ガードレールの Log raw content トグルがオンのときに のみキャプチャされます（デフォルトでオフ）。完全な詳細は guardrail_blocked エラーと Matches フィードに存在します。

​
6. 出荷前にステージ / アクションの組み合わせを証明する

どのマトリクスのセルがポリシーに適用されるか推測しないでください — それを検証 します。どちらのツールも、管理 API を介してコンソールセッション上で実行されます：

Test タブ

各ガードレールエディタには Test タブがあります：サンプルを貼り付け、 ステージを選び、アップストリーム呼び出しなし、クォータなしで現在のポリシーを 実行します。判定と、mask ルールの場合はレンダリングされたテキストを確認します。 Test サンドボックスは Developer+ にゲートされています（有料の judge / grounding 呼び出しとアウトバウンド統合リクエストを発火しうるため）。

Eval タブ

Eval タブは、バンドルまたはカスタムの JSONL コーパスに対してガードレールを スコアリングします — キーをアタッチする前に、block ルールが既知の漏洩を捕捉する ことを確認するのに役立ちます。eval の実行には読み取りアクセス（viewer+）のみが 必要です。
詳しくはテストと evalと 誤検知のチューニングを参照してください。

​
7. 次に進む先

ストリームセーフなルール

スキャナが SSE ストリームを途中で打ち切る方法、そしてストリーミングトラフィック上で 保たれるポリシーを作成する方法。

出力ステージ

モデルのレスポンスをスクリーニングする — block vs. mask、クォータ返金、そして グラウンディング。

入力ステージ

モデルの前にリクエストをスクリーニングする — マスキングを含む、ストリーミングで あるかどうか。

アクション

block、mask、flag、annotate、spotlight を詳しく — どれがいつ正しい選択か。
ガードレール — グラウンディングと LLM judge を含む、 すべてのルールの種類、フィールド、ルート。