メインコンテンツへスキップ
すべてのガードレールルールは 3 つの質問に答えます — 何を探すか（種類）、どこを 探すか（ステージ）、そしてそれにどう対処するか（アクション）。このページは その 3 つ目の選択についてです。ルールのアクションはその上で最も重大な単一の フィールドです：マッチがリクエストを止めるか、静かに書き換えるか、単にパンくずを 残すかを決定します。 ルールビルダーには全部で5 つのアクションが現れます — block、mask、 flag、annotate、spotlight。このページは、最初に手を伸ばす 3 つの強制選択を 扱います：block、mask、flag。ルールごとに 1 つ選びます（あるいは、PII ルールでは異なるエンティティを異なるアクションにルーティングします。 §5を参照）。他の 2 つは プロンプト形成型の非ブロッキングアクションです：annotate はアップストリームへ セキュリティノートを注入し（コードセキュリティ を参照）、spotlight はマッチした信頼されていない入力をデリミタで囲み、モデルが それを指示ではなくデータとして扱うようにします。完全な一覧は ガードレール概要にあります。 より広いエンジン — ルールの種類、ステージ、ポリシーをキーにアタッチすること — については、ガードレール概要または完全な ガードレールリファレンスから始めてください。

​
1. ガードレール block mask flag の判断を一行で

block

HTTP 400 guardrail_blocked で呼び出しを拒否します。モデルは実行されない （入力ステージ）か、その回答が決して返らない（出力ステージ）かのいずれかです。

mask

各マッチをリダクトし — 例：jane@acme.com → [EMAIL] — サニタイズされた テキストを通します。リクエストは継続します。

flag

トラフィックについて何も変えません。フィードにマッチを記録して進みます。 観察専用。
これらが 3 つの強制アクションです。設定したものは、ルールが走るあらゆる場所で 尊重されます — コンソールのルールビルダー、Test サンドボックス、 そしてライブ /v1/* リレーパスはすべて同じ block / mask / flag の値を 読みます。

​
2. ひとつの具体例 — 3 つのルール、3 つのアクション

3 つのルールがそれぞれ異なるアクションを選ぶ単一のガードレールです。これは あなたのセッション上のコンソール（/console/guardrails）で作成します — sk-orca-... リレーキーは /v1/* 呼び出し専用で、ポリシーの編集には決して 使いません。ガードレールの作成または編集には Developer+ ロールが必要です。 
{
  "rules": [
    { "type": "keyword", "stage": "input",  "action": "block",
      "keywords": ["internal-only", "do-not-share"] },
    { "type": "pii",     "stage": "input",  "action": "mask",
      "entities": ["email", "phone"] },
    { "type": "regex",   "stage": "output", "action": "flag",
      "pattern": "(?i)acme\\s+confidential" }
  ]
}
各ルールがリクエストに対して行うこと：
  • block ルールは、それらのリテラル用語のいずれかを含む任意のプロンプトを 拒否します — HTTP 400、モデルは実行されません。
  • mask ルールは、モデルが目にする前にプロンプト内の email と電話番号を [EMAIL] / [PHONE] に書き換えます。
  • flag ルールは、機密マーカーについてモデルの出力を監視し、レスポンスを 変えずにマッチを記録します — 強制を決定する前に、それがどれくらいの頻度で 現れるかを測定できます。
エンジンは適用可能なすべてのルールを実行し、結果をひとつの判定にまとめます。 いずれかのルールがブロックすれば、リクエストはブロックされます。

​
3. block — HTTP 400 で拒否する

block アクションは呼び出し全体を拒否します。呼び出し元は、発火したガードレールと ルールを示すメッセージとともに、エラーコード guardrail_blocked の HTTP 400 を 受け取ります。
入力ステージのブロックはメータリングの前に発火するため、何も消費されません。 出力ステージのブロックは回答を拒否した後に事前消費されたクォータを返金します。 いずれにせよ呼び出し元はブロックされた呼び出しに何も支払いません。
guardrail_blocked の結果は skip-retry です — 同じプロンプトを別の チャネルに対して再実行してもまたブロックされるだけなので、ゲートウェイは リトライを無駄にしません。 guardrail_blocked エラーを参照。
非ストリーミングレスポンスでは回答が返る前にスクリーニングされます。 ストリーミングレスポンスではスキャナが飛行中のストリームを打ち切り、ブロック 対象のコンテンツがクライアントに到達する前に置換メッセージを発します。 ストリーミングカバレッジを参照。
マッチがリクエストの続行を許してはならないことを意味するとき block に手を 伸ばします — プロンプト内のシークレット、jailbreak 試行、厳格なコンプライアンス ライン。

​
4. mask — リダクトして継続する

mask アクションは各マッチをリダクトし、サニタイズされたテキストでリクエストを 通します。アップストリームモデルが元のものを目にすることはありません。PII ルール では、各マッチがエンティティから導出された型付きタグで置換されます — email は [EMAIL] に、SSN は [SSN] に、クレジットカードは [CREDIT_CARD] に、といった 具合です。（カスタムエンティティごとに置換文字列をオーバーライドできます。 マスキングフォーマットを参照。）
入力ステージのマスキングはすべてのストリームでライブです。 モデルが実行される 前にリクエストを書き換えます、ストリーミングかどうかを問わず。出力ステージの マスキングは非ストリーミングレスポンスのみに適用されます — マスク済みテキストは 完全な回答がスクリーニングされた後に転送されます。ストリーミングレスポンスでは ゲートウェイがマスクを計算しますがリダクトされたテキストをまだ転送しないため、 mask ルールは今日、ストリーミングの返信をリダクトしません。ストリーム内出力 マスキングはロードマップ上です。（出力 block は依然として飛行中のストリームを 打ち切ります — §3 を参照。）正確なステージ/ストリームの組み合わせをまずサンド ボックスで証明してください。 ストリーミングカバレッジを参照。
コンテンツは問題ないが部分文字列がモデルに到達すべきでないとき mask に手を 伸ばします — PII リダクションが正典的なケースです。ターンキーの出発点は PII Shield プリセットです。PII Shieldを参照。

​
5. flag — ログのみ、何も変えない

flag アクションは観察専用です：リクエストは、マッチが マッチフィードに記録されることを除き、 ルールが全くないものとバイト単位で同一です。何もブロックされず、何もリダクト されません。
flag は強制する前にルールを測定する方法です。新しい keyword または regex を flag として出荷し、Matches フィードを数日間見て実トラフィックでの真陽性 vs 偽陽性 の割合を確認し、信頼できたら mask または block にプロモートします。flag を オンにしてノイジーなパターンをチューニングするほうが、block をオンにして本番で 誤検知を発見するよりまさります。 誤検知のチューニングを参照。
フラグされたマッチは、ルールの種類、アクション、ステージ、detail 文字列を記録します — そしてマッチした部分文字列は、そのガードレールで Log raw content がオンの 場合のみ（デフォルトはオフ、プライバシー保守的な姿勢）。 ロギングとプライバシーを参照。

​
6. エンティティごとのアクションオーバーライド

単一の PII ルールは、重なり合うルールを積み重ねる代わりに、entity_actions を 介して異なるエンティティを異なるアクションにルーティングできます。各オーバーライド 値は block / mask / flag / annotate のいずれかでなければならず、ルールが すでに宣言しているエンティティを参照しなければなりません — バリデータはそれ以外の ものを拒否します。 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "ip", "credit_card", "ssn"],
  "entity_actions": {
    "credit_card": "block",
    "ssn": "block"
  }
}
このひとつのルールは email、phone、IP をマスクしますが、カード番号または SSN ではリクエストを完全にブロックします。同じオーバーライドモデルの下に独自の 検出器を重ねることについては、 カスタム PII エンティティを参照 してください。

​
7. 適切なアクションを選ぶ

…したい場合使う効果
リクエストを完全に止めるblockHTTP 400、クォータなし、skip-retry
部分文字列を取り除き、呼び出しを保持するmaskリダクトされたテキストを転送
トラフィックに触れずに監視するflagマッチを記録するだけ
アクションはステージと組み合わさります。同じアクションが入力 vs 出力で わずかに異なる振る舞いをします — 入力ブロックは前もってクォータを節約し、出力 ブロックはそれを返金します。出力マスキングは非ストリーミングレスポンスのみに適用 されますが、出力ブロックはストリーミングと非ストリーミングのレスポンスのいずれも 打ち切ります。このページと並べて入力ステージと 出力ステージを読んでください。

​
8. 次にどこへ

guardrail_blocked エラー

400 がどう見えるか、なぜクォータを消費しないか、skip-retry がどう機能するか。

マスキングフォーマット

型付きタグ、カスタム置換文字列、そしてマスクされたプロンプトがモデルにどう 読まれるか。

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

今日どの アクション × ステージ × ストリーム の組み合わせが強制されるか正確に。

強制モード

block / mask / flag が、ファイアウォールの audit 判定を含むゲートウェイの より広い強制モデルにどうマッピングされるか。
ファイアウォールはツールポリシー向けに独自の判定語彙（allow、audit、deny、 sanitize、その他）を持ちます — これらのコンテンツアクションとは区別されます。 ガードレール vs. ファイアウォールを参照。