メインコンテンツへスキップ
LLM プロンプトが運ぶ機密データをマスクする必要があるとき — email、 カード番号、国民 ID、シークレット — ゲートウェイはモデルが目にする前に各マッチを その場で書き換えます。マスクされた値は型付きタグ（jane@acme.com → [EMAIL]）になるため、生の値があなたのワークスペースを決して離れない一方で、 モデルは依然として首尾一貫したプロンプトを読みます。 このページは焦点を当てた解説です：マスキングが何をレンダリングするか、タグを どう変えるか、そしてひとつのルールで一部のエンティティをマスクしつつ他をブロック する方法。完全なエンジン — すべてのルールの種類、ステージ、ルート — については ガードレールリファレンスを、リクエストに特化した マスキングについては入力ステージルールを 参照してください。

​
1. 型付きタグで LLM プロンプトが運ぶ機密データをマスクする

mask アクションつきの pii ルールはエンティティを検出し、各マッチを型付き リダクションタグ — 値を明らかにせずに何が取り除かれたかを示す、ブラケットで 囲まれた大文字のラベル — で置換します：
エンティティレンダリングされるタグ
email[EMAIL]
credit_card[CREDIT_CARD]
ssn[SSN]
完全な組み込み検出器セット — email、phone、credit_card、ssn、ip、 iban、mac_address、jwt、aws_access_key、api_key_openai、 bitcoin_address、加えて地域固有の jp_mynumber、kr_rrn、cn_resident_id — は各々が独自のブラケット付きタグ（[PHONE]、[IBAN]、[JP_MYNUMBER] など）を レンダリングします。タグは決定的です：同じエンティティは常に同じラベルを レンダリングするため、ダウンストリームのプロンプトは安定したままで、あなたの ログはクリーンに読めます。
型付きタグは、モデルの品質にとって一律の [REDACTED] にまさります。モデルは 依然として email vs. アカウント番号 vs. 電話番号を見ていることを知っているため、 データの形状について推論を続けられます — 「[EMAIL] に返信」は実行可能な指示の ままです — 実際の値を決して保持することなく。
入力マスキングは完全にライブです — ゲートウェイはプロンプトがモデルに到達する 前に書き換えます、ストリーミングかどうかを問わず。出力マスキングも非ストリーミング レスポンスでライブです：出力ステージの mask ルールは、完了が返る前にそれを 書き換えます。ストリーミング出力マスキングのみがロードマップ上です。 ストリーミングされた返信では、出力ステージで block を選んでください。正確な ステージ/ストリームのマトリクスは ストリーミングカバレッジを参照。

​
2. ひとつの具体例

ルールは、リレーキーではなくあなた自身のセッション下のコンソールで作成します — ガードレール設定には Developer+ が必要です。pii-shield という名前の ガードレールに単一の pii ルールを追加します： 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "ssn"]
}
キーにアタッチし（guardrail_id を設定するか、ワークスペースデフォルトとして マーク — キーにアタッチするを参照）、 その sk-orca-... リレーキーでゲートウェイを呼び出します： 
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": "Reply to jane@acme.com about her SSN 123-45-6789"}
    ]
  }'
ゲートウェイは転送前にプロンプトを “Reply to [EMAIL] about her SSN [SSN]” に 書き換えます。アップストリームモデルはアドレスも番号も決して見ません。正確な レンダリングはまずエディタの Test タブで証明してください（アップストリーム 呼び出しなし、クォータなし）— テストと evalを参照。

​
3. mask_with でタグをオーバーライドする

組み込みエンティティは固定されたタグをレンダリングします。カスタムエンティティ — 組み込みセットの上に重ねるあなた独自の正規表現検出器 — では、mask_with で 置換テキストを自分で設定できます： 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "custom_entities": [
    {
      "name": "employee_id",
      "pattern": "EMP-[0-9]{6}",
      "mask_with": "[STAFF_ID]"
    }
  ]
}
mask_with はそのエンティティのマッチに対する逐語の置換文字列です。 EMP-004217 は [STAFF_ID] になります。空のままにすると、マッチはデフォルト タグ [<UPPERCASE_NAME>] — ここでは [EMPLOYEE_ID] — をレンダリングするため、 カスタム検出器はオーバーライドなしでも常に読みやすい型付きリダクションを 生成します。
name（小文字 ASCII / 数字 / アンダースコア、文字で始まる必要があります）、 pattern（Go RE2 正規表現 — 線形時間、後方参照なし）、オプションの checksum （luhn はカード形の番号を検証します）、オプションの mask_with。ルールごとに 最大 25 個のカスタムエンティティ — 各々がテキスト全体に対するスキャンで あるため、この上限がホットパスを線形に保ちます。 カスタム PII エンティティを参照。
name は引用符なしで監査ログと Matches フィードに流れるため、文字で始まる小文字 ASCII の文字、数字、アンダースコアに留めてください（例：employee_id、 internal_ticket）。バリデータはそれ以外のものを拒否します。

​
4. 一部のエンティティをマスク、他をブロック — entity_actions

単一の pii ルールは、重なり合う 3 つのルールを積み重ねる代わりに、 entity_actions を介して異なるエンティティに異なるアクションを適用できます。 典型的な形：低感度の連絡先データをマスクし、高感度のフィールドを完全に ブロックします。 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "ip", "credit_card", "ssn"],
  "entity_actions": {
    "credit_card": "block",
    "ssn": "block"
  }
}
ここで email、phone、ip はルールのトップレベルの mask に従い [EMAIL] / [PHONE] / [IP] をレンダリングします。credit_card または ssn のマッチは 代わりにリクエスト全体を HTTP 400 guardrail_blockedでブロックします。
フィールドルール
キールールで宣言されたエンティティ（組み込みまたはカスタム）でなければなりません。
値block、mask、flag、または annotate。
ブロックされたリクエストはクォータを消費しません — 入力ステージのブロックは メータリングの前に発火します。マスクされたリクエストはサニタイズされたテキストで 通過します。そのため、ひとつのルールが、ひとつのアタッチメントとアプリケーション 変更なしで、ルーティンのフィールドを静かにリダクトし、規制対象のフィールドを ハードストップできます。

​
5. mask vs. block vs. flag

マスキングは、ルール（またはエンティティごとのオーバーライド）が取れるアクションの ひとつです。トラフィックをどれだけ乱したいかで選びます：

mask

マッチを型付きタグにリダクトし、サニタイズされたテキストでリクエストを通します。 モデルは生の値を決して見ません。

block

リクエスト全体を HTTP 400 guardrail_blocked で拒否します。何もモデルに 到達しません。決して通過してはならないデータに使います。

flag

トラフィックについて何も変えません — マッチを記録するだけです。強制する前に、 ルールがどれくらいの頻度で発火するかを測定します。
良い展開は flag → mask → block です：影響を測るために flag し、検出器を信頼 できたら mask し、まったく通過させられないフィールドのために block を取っておきます。 アクションと 誤検知のチューニングを参照。

​
6. 何がマスクされたかを検証する

発火したすべてのルールは、ワークスペースの マッチフィードにマッチを記録します — ルールの種類、アクション、ステージ、detail 文字列。マッチした部分文字列そのもの （生の email、実際のカード番号）は、Log raw content がオンのときのみ 記録され、それはデフォルトでオフです — 全体の要点が生の値をログから締め出す ことなので、プライバシー保守的な姿勢です。
トリアージのために部分文字列が本当に必要なときだけ、そしてガードレールごとにだけ、 Log raw content をオンにします。オフのままなら、フィードは番号を一切保存 せずに [CREDIT_CARD] がマスクされたことを証明します。トグルは非遡及的です。 ロギングとプライバシーを参照。

​
7. 次にどこへ

完全なエンジンについてはガードレールリファレンスを、 マスキングが封じ込めるために作られた脅威については PII 露出と シークレット漏洩を読んでください。