メインコンテンツへスキップ
ガードレールは OrcaRouter ゲートウェイのコンテンツポリシーレイヤーです。 ワークスペースで名前付きのポリシーを 1 つ作成し、API キーにアタッチすれば、 そのキーが行うすべての /v1/* 呼び出しがスクリーニングされます — モデルが プロンプトを目にする前と、モデルが応答した後に — 再デプロイなし、SDK 変更なしで。 このページは Guardrails セクションのハブです：ガードレールとは何か、ルールの 種類、ステージとアクション、そしてポリシーがキーにどうアタッチされるか。 各スポークがさらに深く掘り下げます。完全なエンジンリファレンスについては、 ガードレールを参照してください。

​
1. ゲートウェイ上で AI ガードレールが行うこと

ほとんどのチームはガードレールを、機密データをプロンプトから締め出すため （PII、シークレット）、安全でないコンテンツをゲートするため（jailbreak、 プロンプトインジェクションの意図）、あるいはコンプライアンス制御を満たすために 使います。ガードレールはゲートウェイの答えです：ワークスペーススコープの 名前付きポリシー — ゲートウェイがリクエスト入力とモデル出力に対して実行する、 順序付けられたルールのリストです。 バインディングはアプリケーションではなくゲートウェイの API キー上に存在する ため、ガードレールを編集するとアタッチされたすべてのキーが次の呼び出しで 反映されます。あなたのコードは以前と全く同様に /v1/chat/completions を 呼び出し続けます。
ガードレールはコンテンツポリシーです（テキスト入力、テキスト出力）。 対をなすエージェントファイアウォールはツール ポリシーです — エージェントがどのツール呼び出しを行えるかを統制します。 両者は組み合わさります。ガードレール vs. ファイアウォールを参照。

​
2. ひとつの具体例

コンソール（/console/guardrails）で pii-shield という名前のガードレールを 作成し、単一の PII ルール — ステージ input、アクション mask、エンティティ email、ssn — を追加し、キーにアタッチします。それ以降： 
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 please"}
    ]
  }'
ゲートウェイは転送前にプロンプトを Reply to [EMAIL] please に書き換えます — アップストリームモデルがアドレスを目にすることはありません。その ssn エンティティを block に切り替えると、SSN を含む次のリクエストは HTTP 400 で 拒否されます。アプリケーションの変更は不要です。
作成はあなたのセッション上のコンソール / 管理 API アクションです — sk-orca-... リレーキーは /v1/* トラフィック専用であり、ポリシーの編集には 決して使いません。ガードレールの作成または編集には Developer+ ロールが 必要です。

​
3. ルール：type、stage、action

すべてのルールは 3 つの質問に答えます。エンジンは適用可能なすべてのルールを 実行し、それらをひとつの判定にまとめます。
7 つのルールの種類。組み込みは決定的（純粋な文字列/正規表現、ネットワーク なし）で、高度なものはモデルまたはベンダーを呼び出し、並行して実行されます。
  • keyword — リテラルの拒否リスト、大文字小文字を区別しない部分文字列マッチ。
  • regex — RE2 パターン（線形時間、後方参照なし）。
  • pii — 組み込みエンティティ検出器に加え独自のもの。§5を参照。
  • max_chars — あるステージで文字数を制限します。
  • external — 接続済みベンダー（Aporia、Averta、または独自 webhook）に委譲します。
  • llm_judge — ワークスペース内のモデルに対するセマンティックチェック。
  • grounding — リクエストで取得されたソース（RAG）に対して回答の忠実性をスコアリングします。
input（リクエスト）、output（モデルのレスポンス）、または both。 入力ルールはアップストリーム呼び出しの前に、出力ルールはモデルが応答した後に 走ります。入力ステージと 出力ステージを参照。
ルールビルダーには 5 つのアクションが現れます：
  • block — HTTP 400 で呼び出しを拒否します。
  • mask — マッチをリダクトし、サニタイズされたテキストを通します。
  • flag — トラフィックについて何も変えません。マッチを記録するだけです。
  • annotate — テキストはそのままに、アップストリームへセキュリティノートを 注入します（例：モデルが応答する前の CVE アドバイザリ）。
  • spotlight — マッチした信頼されていないテキストをデリミタで囲み、それを 指示ではなくデータとして扱うようモデルに伝えます。
アクションを参照。強制する前にライブ トラフィックでルールを測定するには flag を使います。

​
4. ガードレールのアタッチと解決の仕組み

ガードレールは guardrail_id を介してキーにバインドされるか、ワークスペースが ひとつのガードレールをデフォルトとしてマークできます。任意のリクエストについて、 ゲートウェイは次の順序で解決します：
  1. 明示的アタッチメント — キーの guardrail_id が、存在し有効である ガードレールを指している場合、それが適用されます。明示的アタッチメントは 決してフォールバックしません：無効化することがオフスイッチです。
  2. ワークスペースデフォルト — キーにアタッチメントがない場合、有効な デフォルトガードレールが適用されます。
  3. どちらもなし — 強制なし。リクエストはこの機能を一度も有効化していない ワークスペースとバイト単位で同一です。
これはファイアウォールと異なります。無効化されたアタッチ済みファイアウォール ポリシーはワークスペースデフォルトにフォールバックしますが、無効化された アタッチ済みガードレールは none に解決されます。ガードレールではオフスイッチが 文字どおりです。
ウォークスルー：最初のガードレールを作成する、 キーにアタッチする、 アカウントデフォルトを設定する。

​
5. PII 検出器

pii ルールはクローズドな組み込み検出器セットを同梱します： 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。 mask アクションでは各マッチが型付きタグになります — email は [EMAIL] に、 SSN は [SSN] にレンダリングされます。ルールごとに最大 25 個のカスタム エンティティ（オプションの Luhn チェックサムつき正規表現）を重ねることができ、 エンティティごとのオーバーライドでひとつのルール内で異なるエンティティを異なる アクションにルーティングできます。
ターンキーの出発点は PII Shield プリセットです — 単一の pii ルール、mask、 ステージ both。入力ステージのマスキングはモデルの前にリクエストを書き換えます （ストリーミングかどうかを問わず）。出力マスキングは非ストリーミング レスポンスのみで書き換えます — ストリーム内出力書き換えはロードマップ上です。 PII Shield、 カスタムエンティティ、 マスキングフォーマットを参照。

​
6. プリセットピッカー

New guardrail はテンプレートに開きます。プリセットはサーバーサイドで 作成されているため、コンソール、サンドボックス、そしてこのドキュメントは同じ 挙動を記述します。ピッカーはそれらをカテゴリにグループ化します：
カテゴリプリセット例スポーク
pii / secretsPII Shield、シークレットクレデンシャルブロッカーシークレットをブロック
safetyプロンプトインジェクション、jailbreak、自傷プロンプトインジェクション
complianceGDPR、PCI、HIPAA、コンプライアンスロガーコンプライアンスロガー
brand / cost冒涜的表現、競合他社への言及、サイズ上限ブランドセーフティ · コスト
agentURL / シェルツール / 出力内 SQL フィルターエージェント
code_securityシークレットファイルブロック、コピーレフトライセンスレビューコードセキュリティ
プリセットはシードであり、ロックではありません — 適用してから自由に編集します。 さらなる出発点はテンプレートにあります。

​
7. ガードレールがブロックするとき

ブロックされたリクエストは、エラーコード guardrail_blocked と、発火した ガードレールおよびルールを示すメッセージとともに HTTP 400 を返します。
  • クォータは消費されません。 入力ステージのブロックはメータリングの前に 発火し、出力ステージのブロックは事前消費されたクォータを返金します。
  • リクエストは skip-retry とマークされます — 同じプロンプトを再実行しても また block されるだけなので、ゲートウェイは別のチャネルでリトライを無駄にしません。
ストリーミングでは、block はベストエフォートで強制されます — スキャナが 小さな先読みをバッファし、ルールが発火するとストリームを打ち切るため、すでに フラッシュされたバイトは撤回できません。出力に対する mask は非ストリーミング レスポンスのみに適用されます — ストリーミングレスポンスではゲートウェイがマスクを 計算しますがリダクトされたテキストを転送しません。ストリーム内出力書き換えは ロードマップ上です。（入力ステージのマスキングはストリーミングと非ストリーミングの いずれでもライブです。） guardrail_blocked エラーと ストリーミングカバレッジを参照。

​
8. ライブになった後

マッチフィード

発火したすべてのルールは type、action、stage、detail を記録します。 グループ化、フィルター、エクスポート、単一マッチへのドリルダウンができます。

ロギングとプライバシー

マッチした部分文字列は Log raw content がオンのときのみ記録されます — デフォルトはオフ、プライバシー保守的な姿勢です。

バージョニング

すべての変更は履歴行を書き込みます。任意の 2 バージョンを diff し、新しい バージョンとして revert します — 履歴は決して変更されません。

テストと eval

サンドボックス Test タブはアップストリーム呼び出しなしで現在のポリシーを 評価し、eval ハーネスはバンドルまたはカスタムコーパスに対してスコアリングします。
誤検知はチューニングのシグナルであって、ルールを無効化する理由ではありません。 Matches フィードでマークし、パターンを絞り込みます — 誤検知のチューニングを参照。

​
9. 次にどこへ

ガードレール — すべてのフィールド、すべての ルート、LLM judge とグラウンディングルール、そして外部ベンダーを詳しく。