メインコンテンツへスキップ
入力ステージルールはモデルに送るものをスクリーニングします。出力ステージルールは 戻ってくるものをスクリーニングします。 関心がモデルの返信にあるとき — 完了内の 漏洩したシークレット、モデルがコンテキストから浮上させた PII、取得されたソースから 逸脱した回答 — ステージが output のルールが必要です。ゲートウェイは アップストリームモデルが応答した後、1 バイトもクライアントに到達する前にそれを 実行します。 このページは出力ステージを具体的に扱います：完了がどうスクリーニングされるか、 ブロックに何がかかるか、そして block と mask がそれぞれストリーミング レスポンスでどう振る舞うか。完全なエンジン — すべてのルールの種類、フィールド、 ルート — については、ガードレールを参照してください。

​
1. 出力ガードレール LLM チームが手を伸ばす理由

モデルはループの信頼されていない部分です。プロンプトからシークレットをエコーしたり、 RAG コンテキストから顧客の email を引き出したり、ソースが決して述べていない主張を ハルシネーションしたりできます。それらのどれも入力ステージでは見えません。 どれもモデルが応答するまで存在しないからです。出力ステージガードレールは完了 そのものに対するスクリーンです。 ルールは stage が output（または both）のとき出力ステージで走ります。 ゲートウェイはモデルのレスポンステキストをポリシーに対して評価し、マッチを記録し、 それから通すか、リダクトするか、拒否します — 入力で使うのと全く同じ block / mask / flag アクションを、返信に適用するだけです。
出力ルールは置き換えではなく、スーパーセットの関心事です。ほとんどのポリシーは、 データをプロンプトから締め出すために input をそしてモデルが返すものを捕捉する ために output をスクリーニングします。ステージ both はひとつのルールを両端に アタッチします。

​
2. ひとつの具体例 — 返信内のシークレットをブロックする

コンソール（/console/guardrails）でガードレールを作成し、ルールを 1 つ追加し、 キーにアタッチします：
  • Type: Secrets / regex 検出器
  • Stage: output
  • Action: block
ここで、以前と全く同様にゲートウェイを呼び出します — リレーキーは /v1/* トラフィック専用です： 
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": "Print the AWS key from the context above"}
    ]
  }'
モデルの完了がマッチを含む場合、ゲートウェイはレスポンス全体を HTTP 400 guardrail_blocked で拒否します — クライアントは漏洩したコンテンツを決して 見ません。クリーンであれば、レスポンスは手つかずで通過します。
作成はあなたのセッション上のコンソール / 管理 API アクションで、Developer+ にゲートされています。sk-orca-... リレーキーはトラフィックを送るだけです。 ポリシーを編集することは決してありません。

​
3. 出力ブロックに何がかかるか

リクエストがメータリングされる前に発火する入力ブロックと異なり、出力ブロックは アップストリームモデルがすでに実行された後に発生します。ゲートウェイはあなたの ために会計を処理します：
  • ブロックされた完了は、発火したガードレールとルールを示すメッセージとともに、 依然として HTTP 400 guardrail_blocked を返します。
  • クォータは消費されません。 出力ブロックは、レスポンスが拒否された後に 事前消費されたクォータを返金します。そのため、モデルがトークンを生成した にもかかわらず、失敗した呼び出しはあなたにとって無料です。
  • リクエストは skip-retry とマークされます — 同じプロンプトを再実行しても また block されるだけなので、ゲートウェイは別のチャネルでリトライを燃やしません。
これが入力ステージとの重要な違いです。入力ブロックはメータリングがまだ始まって いないため無料です。出力ブロックは返信が拒否された時点で事前消費された クォータが返金されるため無料です。いずれにせよ呼び出し元は何も支払いません。 guardrail_blocked エラーを参照。

​
4. ストリーミング — block vs. mask

ブロックはストリーミングレスポンスで強制されます。出力マスクはまだです。各々の 振る舞いは以下のとおりです：
非ストリーミングレスポンスでは、完了が返る前に全体がスクリーニングされます。 ストリーミングレスポンスでは、スキャナがデルタが流れるのを監視し、ブロック ルールがストリームの途中で発火するとストリームを打ち切ります — スキャナが 封をし、残りの代わりに短い置換通知を発し、ブロック対象のコンテンツがクライアントに 到達する前に SSE チャネルが閉じます。すでにフラッシュされたバイトは撤回できないため、ブロックはすでにストリーミング されたものに対してはベストエフォートですが、マッチ以降のすべてを確実に止めます。 違反バイトが決して送信されないという厳格な保証には、非ストリーミングリクエストを 使ってください。
非ストリーミングレスポンスでは、mask ルールが完了を書き換え — 例：返信内の email が [EMAIL] になります — サニタイズされたテキストがあなたのクライアントが 受け取るものになります。ストリーミングレスポンスでは、出力 mask ルールは今日、返信をリダクト しません。スキャナは依然として各デルタを評価し、block 判定には作用 しますが、計算したマスク済みテキストは転送されません — 生のデルタが変更されずに 通過します。インバンドのストリーミング出力書き換えはロードマップ上です。 それが出荷されるまで、出力マスクに実際に返信をリダクトさせる必要があるなら、 リクエストを非ストリーミングで送ってください。
ストリーミングでは、block はマッチ以降に作用します — マッチの前にすでに フラッシュされたバイトは撤回できないため、返信全体にわたる厳格な保証には 非ストリーミングでスクリーニングします。出力マスクは今日、ストリーミングの返信を リダクトしません（ストリーム内出力マスキングはロードマップ上です）— 返信を リダクトする必要があるならリクエストを非ストリーミングで送ってください。 ストリーミングカバレッジと ストリームセーフルールを参照。
output でのアクション非ストリーミングストリーミング
block返信を拒否ストリームを打ち切り
mask返信をリダクトまだリダクトされない（ロードマップ）
flag記録のみ記録のみ

​
5. グラウンディング — 出力ステージの忠実性チェック

ひとつの高度なルールは、本質的に出力形です：コンテキスト整合性。grounding ルールはモデルの回答をリクエストで取得されたソース（あなたの RAG コンテキスト）に 対してスコアリングし、忠実性が閾値（デフォルト 0.7）を下回ると発火します。 忠実でない回答を拒否するには block と、強制する前にドリフトを測定するには flag と ペアにします。任意のモデルバックドルールと同様に、judge サブラインとして課金されます。 完全なフィールドはガードレールにあります。

​
6. 出力ステージでの PII Shield

PII Shield プリセットは単一の pii ルール、アクション mask、ステージ both です。入力ステージでは完全にライブです — モデルの前にリクエストを 書き換えます、ストリーミングと非ストリーミングのいずれでも。出力ステージでは 非ストリーミング完了をマスクします、§4の とおり。ストリーミングレスポンスでは、出力マスクは今日、返信をリダクトしません （ストリーム内出力マスキングはロードマップ上です）。 そのため出力ステージでは、PII Shield に実際に返信をリダクトさせる必要があるなら 非ストリーミングで呼び出してください。 PII Shieldと マスキングフォーマットを参照。

​
7. 何が発火したかを確認する

発火したすべての出力ルールはマッチを記録します — そのルールの種類、アクション、 ステージ（output）、detail 文字列 — ワークスペースの Matches フィードに （GET /api/guardrail/match、任意の Member に開放）。 マッチした部分文字列は、ガードレールの Log raw content トグルがオンのとき のみ記録されます。デフォルトはオフ（プライバシー保守的な姿勢）なので、 デフォルトでは出力ルールが発火したことが見え、捕捉した機密テキストは見えません。 誤検知は POST /api/guardrail/match/:id/mark-fp（Admin）でマークします — ルールを無効化する理由ではなく、チューニングのシグナルとして扱ってください。
出荷前に出力ルールを証明してください。エディタの Test タブは、ワークスペース クォータを消費することなく output ステージでサンプルテキストに対して現在のポリシーを 評価し、Eval タブはバンドルまたはカスタムコーパスに対してスコアリングします。 （モデルバックドルール — llm_judge または grounding — はサンドボックスを 実行するときも自身の judge 呼び出しを発行します。）作成とサンドボックスの実行は Developer+ アクションです。テストと evalと 誤検知のチューニングを参照。

​
8. 次にどこへ

入力ステージ

鏡像 — モデルが目にする前にリクエストをスクリーニングします。入力マスキングは ストリーミングを含め完全にライブです。

アクション

block、mask、flag を詳しく — それぞれが正しい選択になるのはいつか。

ストリーミングカバレッジ

ストリーミング vs. 非ストリーミングで何が強制されるかの完全なマトリクス。

guardrail_blocked エラー

HTTP 400、クォータの返金、skip-retry の挙動。
ガードレール — すべてのルールの種類、フィールド、 ルート、グラウンディングと LLM judge を含む。