メインコンテンツへスキップ
モデルに決して到達してはならない、またはモデルから決して戻ってきてはならない 用語のリストがあるとします — 競合他社の名前、内部コードネーム、禁止された中傷語、 まだ発表されていない製品。それに対する最速の制御はキーワード拒否リストです： ゲートウェイがすべての呼び出しでスキャンし、それからブロック、マスク、 またはフラグする、リテラル用語のリストです。 これは禁止用語のユースケースに焦点を当てた着地ページです。完全なガードレール エンジン — すべてのルールの種類、フィールド、ルート — については、 ガードレールリファレンスを参照してください。

​
1. AI 機密ワードフィルターのユースケース

keyword ルールはエンジン内で最もシンプルなルールです：用語のリストを与えると、 ゲートウェイはそのいずれかをあるステージのテキストに対してマッチします。マッチングは 大文字小文字を区別しない部分文字列です — BadWord、badword、BADWORD は すべてマッチし、用語がより長い単語に埋め込まれていてもマッチします（そのため class は classic にもマッチします）。各用語はパターンではなくリテラル文字列 として扱われます。正規表現メタ文字をエスケープする必要はありません。 ルールをコンソールで一度保存し、ガードレールを任意の API キーにアタッチ（または ワークスペースデフォルトに）すれば、そのキーでのすべての呼び出しが SDK 変更なし、 再デプロイなしでスクリーニングされます。ポリシーはアプリケーションではなく ゲートウェイに存在します — あなたのアプリは以前と全く同様に /v1/chat/completions を呼び出し続けます。
拒否リストがリテラル用語の有限集合のときは keyword ルールに手を伸ばします。 ワイルドカード、単語境界、または構造（SKU フォーマット、注文番号の形）が必要なときは、 代わりに正規表現検出器を使います。

​
2. コンソールでルールを作成する

ここでのすべてのステップは、あなた自身のセッション下のコンソールアクションです。 ガードレールの作成と編集にはワークスペースで Developer+ が必要です。最後の /v1/* 呼び出しのみが sk-orca-... リレーキーを使います。
1

ガードレールを作成する

コンソールで Guardrails を開き、New guardrail をクリックします。 名前（≤ 64 文字）を付けます、例：banned-terms。
2

キーワードルールを追加する

ルールを 1 つ追加します：
  • Type: Keyword denylist（keyword）
  • Stage: Both（リクエストとレスポンス）
  • Action: Block
  • Keywords: あなたの禁止用語、1 行に 1 つ
保存します。
3

テストする

Test タブを開き、禁止用語を含むサンプルを貼り付け、ステージを選び、 ポリシーをローカルで実行します — アップストリーム呼び出しなし、クォータなし （§5を参照）。
4

キーをアタッチする

API キーを編集し、Guardrail ドロップダウンから banned-terms を選ぶ （キー上に guardrail_id を設定）か、ガードレールをワークスペース デフォルトとしてマークします。 キーにアタッチすると アカウントデフォルトを参照。
ルールの JSON は期待どおりです： 
{
  "type": "keyword",
  "stage": "both",
  "action": "block",
  "keywords": ["project-orca", "competitor-name", "unannounced-sku"]
}

​
3. アクションを選ぶ

キーワードルールはルールごとにひとつのアクションを選びます：
いずれかのマッチがリクエストを HTTP 400 guardrail_blocked で拒否します。 ブロックされたリクエストはクォータを消費せず（入力ステージのブロックは メータリングの前に発火し、出力ステージのブロックは事前消費されたクォータを 返金）、skip-retry とマークされます。どちらの方向にも決して通過しては ならない用語に使います。 guardrail_blocked エラーを参照。
各マッチがその場でリダクションタグに置換され、リクエストはサニタイズされた テキストで継続します — アップストリームモデルは元の用語を決して見ません。 アクションを参照。
マッチを記録し、トラフィックについて何も変えません。強制に切り替える前に、 用語がどれくらいの頻度で現れるかを測定するために使います。
マッチしたテキストをデリミタ（例：⟦UNTRUSTED⟧…⟦/UNTRUSTED⟧）で囲み、 モデルがそれを指示ではなくデータとして扱うようにします — 入力ステージの プロンプトインジェクション防御。テキストは依然としてモデルに到達しますが、 囲われています。アクションを参照。
ステージが重要です。 input は呼び出し元のリクエストを、output はモデルの レスポンスを、both は各側を独立してスキャンします。ユーザーがタイプする禁止用語と モデルが発し得るものは異なる問題です — フィットするステージを選んでください。 入力ステージルールと 出力ステージルールを参照。

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

選ぶアクションは、レスポンスがストリームするかどうかと相互作用します：
アクション非ストリーミングストリーミング
block（出力）強制される強制される — スキャナがストリームを打ち切り
mask（出力）強制されるまだ — block 判定は尊重されるが、マスク済みテキストは転送されない（ロードマップ）
入力ステージルールはアップストリーム呼び出しの前に走るため、ストリーミングの 影響を受けません — 入力 mask は、レスポンスがストリームするかどうかに関わらず リクエストをサニタイズします。禁止用語の block はいずれにせよ完全なカバレッジを 得ます。しかし出力 mask は今日、非ストリーミングレスポンスのみで リダクトします：ストリーミングの返信では、スキャナは依然として block 判定に作用 しますが、ストリーミングされたテキストのインバンド書き換えはライブではなく ロードマップ上です。 ストリーミングカバレッジを参照。

​
5. アタッチする前にテストする

いずれかのキーがそれを指す前に、ルールが期待どおりに動作することを証明します。 エディタ内の Test タブを開き、サンプルを貼り付け、ステージを選んで実行します： 
Tell me about Project-Orca and our competitor-name
サンドボックスは現在のポリシーをローカルで評価し、判定を返します — アップストリーム には何も送信されず、何もメータリングされません。block アクションではサンプルが 拒否され、mask ではレンダリングされたテキストが各用語をリダクトして戻ってきます。 コーパスに対する A/B グリッド — 拒否リストが良性トラフィックをフラグせずに捕捉 すべきものを捕捉することを確認するため — については、 Eval ハーネスが隣のタブにあります。

​
6. リクエストを送信する

banned-terms にバインドされたキーを使って、以前と全く同様に 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": "Summarize Project-Orca for me"}
    ]
  }'
block アクションでは、呼び出しはモデルに到達する前に HTTP 400 guardrail_blocked で拒否されます。アクションを mask に切り替えると、用語は 代わりに転送前にその場でリダクトされます。

​
7. 何が発火したかを確認する

発火したすべてのルールはマッチを記録します — ルールの種類、アクション、 ステージ、detail 文字列（キーワードルールでは、いくつの用語がマッチしたか）— ワークスペースの Matches フィードに現れます。
マッチした用語そのものは、Log raw content がオンのときのみ記録され、 それはデフォルトでオフです — プライバシー保守的な姿勢。オフでも、キーワード ルールが発火したこととその頻度は依然として見えますが、リテラルの用語は見えません。 トリアージのために部分文字列が必要なときはガードレールごとにオンにします。設定は 非遡及的です。マッチフィードと ロギングとプライバシーを参照。
良性の用語がマッチし続ける場合（一般的な単語の部分文字列である拒否リストエントリ）、 Matches フィードからそれを誤検知としてマークし、エントリを引き締めます。 誤検知のチューニングを参照。

​
8. 次にどこへ

正規表現検出器

リテラルの拒否リストでは不十分なとき、構造化されたパターン — SKU、注文番号、 フォーマット — にマッチします。

ブランドセーフティ

キーワードルールの上に構築された、冒涜的表現、競合他社への言及、児童安全の プリセット。

アクション

block、mask、flag がどう異なり、それぞれをいつ使うか。

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

完全なエンジン — すべてのルールの種類、フィールド、ルート。
キーワード拒否リストはコンテンツを統制します。エージェントのツール呼び出しを 統制するには — 破壊的アクションを deny し、ツール呼び出し引数をリダクトし、承認を 要求する — ファイアウォールを使います。リテラルなリストでは 表現できない曖昧なポリシー（有害性、トピック外れ、インジェクションの意図）には、 llm_judge ルールがワークスペースモデルに対して セマンティックチェックを実行します。