メインコンテンツへスキップ
捕捉したいもののいくつかは、リテラルな単語でも型付き PII エンティティでも ありません — それは形状です。SKU フォーマット、注文番号のレイアウト、内部 URL パターン、クーポンコード、契約参照番号。regex ルールを使えば、 すべての呼び出しでその形状にマッチし、プロンプトがモデルに届く前、そして レスポンスがユーザーに届く前に、それを block、mask、flag できます。 これは構造化パターンのユースケースに焦点を当てたランディングページです。完全な ガードレールエンジン — すべてのルールの種類、フィールド、ルート — については ガードレールリファレンスを参照してください。
ここでのすべてのステップは、ホスト型ゲートウェイ（api.orcarouter.ai）上の コンソール アクションです。ガードレールは自分のセッション下で作成します。 最後の /v1/* 呼び出しのみが sk-orca-... リレーキーを使います。ガードレールの 作成と編集にはワークスペースで Developer+ が必要です。

​
1. regex ガードレール LLM 制御が必要なとき

regex ルールは、捕捉したいものがリテラル拒否リストでは表現できない構造を 持つが、pii 検出器がすでにカバーしている 標準的なアイデンティティではない場合に、適切なツールです。

構造化されたコード

SKU、クーポンコード、契約参照番号、内部チケット ID — 固定プレフィックスに 加えて数字または英数字の連なり。

フォーマット形状のトークン

有限の単語リストではなく形状でマッチするもの — 注文番号のレイアウト、 シリアルフォーマット、内部 URL パターン。

出力漏洩パターン

内部ホスト名、ファイルパス、レコード ID フォーマットを表に出すべきでない レスポンス — モデルの出力をその形状でスキャンします。

安価で決定的なチェック

純粋なパターンマッチング、モデル呼び出しなし、ネットワークなし — どちらの 方向のすべてのリクエスト上で実行しても安全です。
最も軽量で適合するツールを選びましょう。リテラル用語の有限リスト → キーワード拒否リスト。型付きマスクタグ （[EMAIL]、[SSN]）または Luhn チェックを求める名前付きアイデンティティ形状 → PII / カスタムエンティティ。エンティティ ごとの型付けが不要な構造的パターン → regex ルール（ここでカバーします）。

​
2. RE2 — 線形時間、後方参照なし

regex ルールの pattern は Go RE2 正規表現です。RE2 は regex ルールを すべてのリクエスト上で実行しても安全にするエンジンです：
RE2 は、パターンに関わらず、入力の長さに対して線形なマッチング時間を保証 します。バックトラックエンジンは敵対的な入力に対して指数的に膨れ上がる 可能性があります（「ReDoS」）が、RE2 はそうなりません。だからこそ、あなたの パターンはすべての呼び出しでホットパス上で評価しても安全なのです。
RE2 は後方参照（\1）、先読み、後読みをサポートしません。それらに依存する PCRE パターンを移植している場合は、それらなしで書き直してください。文字 クラス、アンカー、量指定子、選択、非キャプチャグループはすべて期待どおりに 動作します。
別個の「大文字小文字を無視」スイッチはありません — フラグをインラインで 設定します。大文字小文字を区別しないには (?i) を、複数行には (?m) を プレフィックスします。例：(?i)\bproject-orca\b。
ルールビルダーは、ガードレールを保存するときにパターンをコンパイルします。 コンパイルできないパターンは、エラー内にルールインデックスを添えて拒否 されるため、不正な検出器がリレーパスに到達することはありません。
RE2 パターンは PCRE ではありません。最も一般的な移植時の驚きは後方参照または 先読みです — どちらもサポートされていません。代わりにマッチを文字クラス / 選択 パターンとして書き、キーをアタッチする前に Test タブで検証してください。

​
3. regex ルールの構造

regex ルールは、keyword に次いでエンジン内で最も小さなルールです：パターン、 ステージ、アクション。
フィールド何をするか
patternGo RE2 正規表現（線形時間、後方参照なし）。コンパイルできなければなりません。
stageinput（リクエスト）、output（レスポンス）、または both。
actionblock、mask、または flag。
mask アクションでは、各マッチがその場で単一のリテラル [REDACTED] タグに 置換されます — regex ルールは型付けされていないため、[EMAIL] のような エンティティごとのタグはレンダリングしません。型付きタグやカスタム置換トークンが 欲しい場合は、代わりに形状をカスタム PII エンティティとして モデル化してください。

​
4. 具体例 1 つ

社内の注文番号が ORD- の後に 8 桁の数字という形をしており、モデルの レスポンスにそれが返ってくることを決して望まないとします。output ステージに単一の regex ルールを追加します： 
{
  "type": "regex",
  "stage": "output",
  "action": "mask",
  "pattern": "ORD-\\d{8}"
}
コンソールで作成します：
1

ガードレールを作成する

Guardrails を開き、New guardrail をクリックし、名前（≤ 64 文字）を 付けます。例：order-id-filter。
2

regex ルールを追加する

ルールを 1 つ追加します — Type: Regular expression、Stage: Output、 Action: Mask — そしてパターン ORD-\d{8} を貼り付けます。保存します。
3

サンドボックスでテストする

Test タブを開き、サンプルを貼り付け、output ステージを選び、現在の ポリシーをローカルで実行します — アップストリーム呼び出しなし、クォータなし：
Your order ORD-48291507 has shipped.

Your order [REDACTED] has shipped.
4

キーをアタッチする

API キーを編集し、Guardrail ドロップダウンから order-id-filter を選びます （キーに guardrail_id を設定します）か、ガードレールをワークスペース デフォルトにマークします。キーにアタッチと アカウントデフォルトを参照してください。
その後、以前と全く同様に 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": "What is the status of my order?"}
    ]
  }'
注文番号は、ユーザーに届く前にレスポンス内でリダクトされます。

​
5. ステージとストリーミングカバレッジ

選んだアクションは、レスポンスがストリーミングするかどうかと相互作用します：
アクション非ストリーミングストリーミング
block（output）強制強制 — スキャナがストリームを打ち切る
mask（output）強制強制 — スキャナがバッファを書き換える
入力ステージのルールはアップストリーム呼び出しの前に走るため、ストリーミングの 影響を受けません — モデルが目にする前にリクエストをマスクすることは稼働中です。 出力 mask と出力 block は、ストリーミングと非ストリーミングのいずれの レスポンスでも強制されます。ストリーミングカバレッジを 参照してください。

​
6. アクションを選ぶ

regex ルールは、ルールごとに 1 つのアクションを選びます：
マッチがあれば、リクエストを HTTP 400 guardrail_blocked で拒否します。 ブロックされたリクエストはクォータを消費しません — 入力ステージのブロックは メータリングの前に発火し、出力ステージのブロックは事前消費されたクォータを 返金します — そして skip-retry とマークされます。 guardrail_blocked エラーを 参照してください。
各マッチがその場で [REDACTED] に置換され、リクエストはサニタイズされた テキストで継続します — アップストリームモデル（入力ステージ）またはユーザー （出力ステージ）が元のものを目にすることはありません。 アクションを参照してください。
マッチを記録し、トラフィックについて何も変えません。新しいパターンに適切な 出発点です：flag として出荷し、Matches フィードを観察し、信頼できるように なったら mask/block にプロモートします。
マッチを記録し、トラフィックを変えることなくノート（例：トリアージで表に 出す所見）を添付します。アクションを 参照してください。
入力ステージの防御：各マッチが区切り文字（例： ⟦UNTRUSTED⟧…⟦/UNTRUSTED⟧）で囲まれ、そのテキストを指示ではなくデータ として扱うようモデルに伝えます — プロンプトインジェクションの緩和策です。 アクションを参照してください。

​
7. 何が発火したか確認する — そして精度をチューニングする

発火したすべてのルールは、ワークスペースの Matches フィードにマッチ — ルールの種類、アクション、ステージ、詳細文字列 — を記録します。
マッチした部分文字列は、Log raw content がオンのときにのみ記録され、 これはデフォルトでオフです — プライバシー保守的な姿勢です。オフの場合でも、 regex ルールが発火したこととその頻度は確認できますが、捕捉したリテラルな テキストは確認できません。トリアージのために部分文字列が必要なときは、 ガードレールごとにオンにします。設定は非遡及的です。 Matches フィードと ロギングとプライバシーを参照してください。
広すぎるパターンは古典的な regex の落とし穴です — \d{8} はあなたの注文番号 だけでなく、すべての 8 桁の連なりにマッチします。それをアンカーし（ORD- の ような固定プレフィックス、単語境界 \b）、Matches フィードを観察し、進めながら 誤検知をマークして絞り込みます。コーパスに対する A/B グリッド — パターンが、 良性のトラフィックをフラグせずに捕捉すべきものを捕捉することを証明する — については、Eval ハーネスが隣のタブに あります。誤検知のチューニングを 参照してください。

​
8. 次に進む先

カスタム PII エンティティ

形状が、ただの [REDACTED] ではなく、型付きマスクタグや Luhn チェックサムを 求めるアイデンティティであるとき。

機密語

リテラル用語の有限リスト — 構造が不要なときはパターンよりシンプルです。

アクション

block、mask、flag がどう異なり、いつ各々を使うか。

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

完全なエンジン — すべてのルールの種類、フィールド、ルート。
regex ルールはコンテンツを統制します。エージェントのツール呼び出しを 統制する — 破壊的アクションを拒否し、ツール呼び出し引数をリダクトし、承認を 要求する — には、ファイアウォールとその ルールマッチャーを使います。どのパターンでも 表現できない曖昧なポリシー（有害性、トピック外れ、インジェクションの意図）には、 llm_judge ルールがワークスペースモデルに対してセマンティックチェックを実行 します。regex が全体設計のどこに位置づけられるかを確認するには、 ガードレール vs. ファイアウォールを 読んでください。