メインコンテンツへスキップ
組み込みの pii 検出器は一般的なエンティティ — email、phone、クレジットカード、 SSN、IBAN、JWT、クラウドキー — をカバーします。しかしあなたの機密データは あなたのものです：従業員 ID、内部ケース番号、顧客アカウント参照、パートナーの 注文フォーマット。カスタム PII エンティティは、同じマスキングルールにそれらの 形状を認識させ、ゲートウェイがモデル — または任意のダウンストリームツール — が 目にする前にそれらをリダクトできるようにします。 このページは、カスタムエンティティが PII 検出ルールに加えるひとつのこと：あなた 独自の検出器を扱います。完全なエンジン — すべてのルールの種類、ステージ、ルート — については、ガードレールリファレンスを参照してください。
ここでのすべてのステップは、ホスト型ゲートウェイ（api.orcarouter.ai）上の コンソールアクションです。ガードレールはあなた自身のセッション下で作成します。 最後の /v1/* 呼び出しのみが sk-orca-... リレーキーを使います。ガードレールの 作成と編集にはワークスペースで Developer+ が必要です。

​
1. カスタム PII 検出器 LLM ガードレールが必要なとき

組み込みエンティティセットはクローズドで、エンジン、バリデータ、ルールビルダーで 共有されます。標準的な識別子には適切なツールです。リダクトしたいデータが どの組み込みもカバーしない予測可能な形状を持つときに、カスタムエンティティに 手を伸ばします：

内部識別子

従業員 ID（EMP482915）、ケース番号、チケット参照、内部 SKU — 固定された プレフィックスと数字の連なりを持つ任意のもの。

アカウント番号と注文番号

サードパーティモデルに逐語で決して到達すべきでない、顧客アカウント参照または パートナーの注文フォーマット。

チェックサム付き番号

Luhn チェックを通過するカード状または会員番号 — チェックサムを追加して、 似た数字の連なりでの誤検知を減らします。

ドメイン固有のコード

保険証券番号、請求 ID、デバイスシリアル — あなたの業界が機密として扱うが ジェネリックな検出器が知らない任意のトークン。
カスタムエンティティはひとつの pii ルール内で組み込みセットの上に重なります。 マッチを検出し、ルールのアクション — mask、block、flag — を、組み込み エンティティと全く同様に適用します。

​
2. カスタムエンティティの構造

カスタムエンティティは 3 つの小さなフィールドに、オプションのマスクタグを加えた ものです。pii ルールエディタの Custom entities の下で追加します：
フィールド必須何をするか
nameはい安定した ID、例：employee_id。小文字 ASCII / 数字 / _、文字で始まる必要があります。Matches フィードと監査ログに流れます。
patternはいGo RE2 正規表現（線形時間、後方参照なし）。コンパイルできる必要があります。
checksumいいえluhn は各マッチを Luhn アルゴリズムで検証します。""（なし）または "luhn" のみが受理されます。
mask_withいいえmask アクション時の逐語置換。デフォルトは [<UPPERCASE_NAME>]。
name はゲートウェイの他の部分と同じキー規約に従います — 小文字、文字で始まり、 スペースやハイフンなし。明確なもの（case_number、partner_order_id）を選んで ください。ルールが発火したときにマッチフィードで 目にするものです。

​
オプションの Luhn チェックサム

多くの「番号形」識別子 — 決済カード、一部の会員番号やアカウント番号 — は Luhn （mod-10）チェックディジットを持ちます。\d{16} のような素の正規表現は、電話番号、 タイムスタンプ、注文合計を含む任意の 16 桁の連なりにマッチします。 checksum: "luhn" を設定すると、マッチした数字も Luhn チェックを通過するとき のみ検出器が発火するため、似た連なりはクリーンにすり抜け、誤検知率は低く 保たれます。従業員 ID のようなチェックサムのないトークンでは空のままにします。

​
独自のマスクタグ

mask アクションでは、組み込みの email は [EMAIL] にレンダリングされます。 カスタムエンティティはデフォルトで [<UPPERCASE_NAME>] にレンダリングされます — employee_id のマッチは [EMPLOYEE_ID] になります。モデルが受け取るテキストに 特定の置換トークンが欲しいときは、mask_with を設定してそれを逐語でオーバーライド します（例：<id> または ***）。エンティティ種別間のレンダリングルールについては、 マスキングフォーマットを参照してください。

​
3. ひとつの具体例

プロンプトが EMP の後に 6 桁が続く形式で従業員 ID を運び、アップストリーム モデルが実際の ID を決して見ないように入力ステージでそれらをマスクしたいと します。pii ルールに単一のカスタムエンティティを追加します： 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email"],
  "custom_entities": [
    {
      "name": "employee_id",
      "pattern": "EMP\\d{6}",
      "mask_with": "[EMPLOYEE_ID]"
    }
  ]
}
そのルールは標準的な email とあなたの従業員 ID を同じパスでマスクします。 キーをアタッチする前に Test タブでテストします： 
Forward EMP482915's note to jane@acme.com

Forward [EMPLOYEE_ID]'s note to [EMAIL]
アップストリームには何も送信されず、何もメータリングされません。それから ガードレールをキーにアタッチし（キーにアタッチする を参照）、以前と全く同様に /v1/chat/completions を呼び出します — ゲートウェイは SDK 変更なしで転送前にリクエストをマスクします。
マスキングは両ステージで走ります：input ルールはモデルが目にする前に リクエストをリダクトし、output ルールはモデルの返信をリダクトします — スキャナが インバンドでマッチを書き換えるストリーミングレスポンスを含みます。ブロックアクションも 両ステージで強制されます。モデルのレスポンスをゲートするには、 出力ステージルールを参照。

​
チェックサム付きの例

カード状の会員番号には、有効な番号でない 16 桁の連なりがマッチしないように Luhn チェックを追加します： 
{
  "name": "member_card",
  "pattern": "\\d{16}",
  "checksum": "luhn",
  "mask_with": "[MEMBER_CARD]"
}

​
4. 上限と検証

ルールビルダーは保存時にすべてのカスタムエンティティを検証します — 不正な検出器が ホットパスに到達することは決してありません。
各カスタムエンティティはテキスト全体に対する正規表現スキャンであるため、 ルールごとの上限は 25 です。この上限がホットパスを線形に保ちます。 コンパイルされたパターンはリクエスト間でキャッシュされます。より多くの形状が 必要ですか？同じガードレール内の複数の pii ルールに分割します。
pattern は Go RE2 正規表現です — 線形時間、後方参照なし。バリデータは コンパイルできないパターンを、エラー内に違反エンティティ名を示して拒否します。
""（チェックなし）と "luhn" のみが受理されます。それ以外 — "sha256"、 "mod10"、さらには "LUHN" — は保存時に拒否されます。
name は文字で始まり、小文字 ASCII、数字、アンダースコアのみを使う必要が あります。ひとつのルール内の 2 つのカスタムエンティティが名前を共有することは できません。

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

カスタムエンティティは、組み込みエンティティと同じ entity_actions マップに 参加します。ひとつの pii ルールはほとんどのものをマスクしつつ、高感度の カスタム検出器ではブロックできます — エンティティをその name で参照します： 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone"],
  "custom_entities": [
    { "name": "ssn_internal", "pattern": "ID-\\d{9}", "checksum": "luhn" }
  ],
  "entity_actions": {
    "ssn_internal": "block"
  }
}
entity_actions のキーは、ルールで有効な組み込みエンティティまたはカスタム エンティティの name を参照しなければなりません。値は block、mask、flag、 annotate でなければなりません。バリデータはそれ以外のものを拒否します。

​
6. 次にどこへ

PII Shield

カスタムエンティティが重なる単一のマスキングルール — 組み込み検出器セットと 型付きマスクタグ。

マスキングフォーマット

mask アクションで各エンティティがどうレンダリングされるか、そして mask_with がどうオーバーライドするか。

正規表現検出器

型付き PII エンティティより素の regex ルールのほうがフィットするとき。

誤検知のチューニング

Matches フィードとチェックサムを使って精度を調整します。
完全な PII ルール — すべてのフィールド、eval ハーネス、フル API — については ガードレールリファレンスを、 エンドツーエンドのループを一から辿るには 最初のガードレールを作成するを読んでください。