1. 2 つのクラスのチェック
すべてのガードレールルールとすべてのファイアウォール評価は 2 つのクラスのうちの ひとつに分類されます。組み込み / 決定的チェック
キーワード拒否リスト（keyword）、正規表現（regex）、PII 検出（pii）、
最大長（max_chars）のガードレールルールは純粋なローカルの文字列と正規表現
操作です — モデル呼び出しなし、ネットワークホップなし、タイムアウトする可能性のある
ものは何もありません。ファイアウォールルール評価（ツール名グロブマッチング、
引数述語、egress スコープ）も同様です：決定的でローカルです。
実際的な目的では、これらのチェックはリクエストに無視できるレイテンシを追加します。
ホットパスで実行しても安全であり、組み込みのガードレールテンプレートが作られている
ものです。
高度 / セマンティックチェック
llm_judge、grounding、external ベンダールールはチェックをモデルまたは
ベンダーに委譲します。それらはラウンドトリップのコストがかかります。3 つの特性が
そのコストを有界にします：
- 並行ディスパッチ。 ポリシーに複数の高度なルールがある場合、それらは並行して ディスパッチされます — ひとつの遅いチェックが別のチェックの背後で直列化することは ありません。
- ルールごとのタイムアウト。 各高度なルールにはタイムアウト
（
judge_timeout_ms/grounding_timeout_ms/timeout_ms）があります。 grounding チェックはデフォルトで約 3,000 ms；judge は設定可能な値（0 → エンジン デフォルト）を使用します。ルールは有界です — 無期限にハングすることはできません。 - デフォルトでフェイルオープン。 ルールがタイムアウトするかベンダーがエラーを
返す場合、イベントが記録されますがリクエストは継続します。見逃されたチェックが
ポリシーにとって許容できない場合、
judge_fail_open: false（judge）またはfail_open: false（external）を設定してフェイルクローズに切り替えます。
2. 一目でわかる概要
| チェックタイプ | レイテンシを追加するか？ | 有界にする方法 |
|---|---|---|
keyword 拒否リスト | 無視できる — ローカル文字列スキャン | ネットワークなし；タイムアウト不要 |
regex | 無視できる — RE2 ローカルマッチ | ネットワークなし；タイムアウト不要 |
pii 検出 | 無視できる — ローカル正規表現/エンティティスキャン | ネットワークなし；タイムアウト不要 |
max_chars | 無視できる — 文字数カウント | ネットワークなし；タイムアウト不要 |
| ファイアウォールルール評価 | 無視できる — グロブ + 述語マッチング | ネットワークなし；タイムアウト不要 |
llm_judge | ひとつの有界なモデル呼び出し | judge_timeout_ms；デフォルトでフェイルオープン |
grounding | ひとつの有界なモデル呼び出し | grounding_timeout_ms（デフォルト約 3,000 ms）；デフォルトでフェイルオープン |
external ベンダー | ひとつの有界なベンダー呼び出し | timeout_ms；デフォルトで fail_open |
| 複数の高度なルール | ひとつの有界なラウンドトリップ（並行ディスパッチ） | 最悪ケース = 最大単一タイムアウト、合計ではない |
3. リクエストライフサイクルでチェックが実行される場所
強制はすべて同じポイントで発生するわけではありません。入力と出力のスクリーニングは 異なる場所で時間を追加します：llm_judge）はメインモデル呼び出しが
開始される前に有界なモデル呼び出しを追加します。
出力ガードレールはモデルが応答した後に実行されます。組み込みの出力ルールは
末尾にわずかなオーバーヘッドを追加します。高度な出力ルール（例：RAG の忠実性を
チェックする grounding）はすでにモデルの回答を持った後に有界な呼び出しを
追加します。
ファイアウォールルール評価は決定的で、ツール呼び出しルーティングでインラインに
発生します — 上記のように無視できます。
ブロックされたリクエストは入力ステージのブロックに対してモデルトークンを
消費せず、アップストリームのレイテンシを追加しません。入力ブロックはメータリングと
アップストリーム呼び出しの前に発火するため、クォータもアップストリームのラウンド
トリップ時間も支払いません。出力ステージのブロックはレスポンスが拒否された後に
事前消費されたクォータを返金します。
4. タイムアウトとフェイルオープンが最悪ケースを有界にする方法
高度なルールには 2 つのダイヤルがあります： タイムアウト — チェックが許可される最大ウォール時間。リクエストはそのルールに 対してせいぜいこの長さだけ待ちます。並行ディスパッチはこの上限がポリシーごとではなく ルールごとに適用されることを意味します。それぞれ 2,000 ms タイムアウトの 3 つのllm_judge ルールがある場合、3 つすべてが同時に実行され、合計待機時間は
約 2,000 ms であり、約 6,000 ms ではありません。
フェイルオープン vs フェイルクローズ — ルールが時間内に完了しない（またはベンダーが
エラーを返す）場合の対処方法：
| 設定 | タイムアウト / エラー時の動作 |
|---|---|
fail_open: true（デフォルト） | イベントを記録；チェックが通過したかのようにリクエストを継続する |
fail_open: false | タイムアウト / エラーをブロックとして扱う；HTTP 400 guardrail_blocked を返す |
5. 実践的なガイダンス
ホットパスのルールは組み込みのままにしてください。 PII、クレデンシャル漏洩、 プロンプト長、またはキーワード拒否リストが主な懸念事項の場合 — これらはすべて 組み込みルールです。測定可能なレイテンシを追加せず、テキストマッチングが処理できる すべてのチェックのデフォルト選択肢であるべきです。 セマンティクスが必要な場合にllm_judge と grounding を使用してください。
有害性、ハラスメント、トピック外検出、プロンプトインジェクションの意図、RAG の忠実性
は本当に曖昧です — 正規表現では確実に捉えられません。これらが高度なルールの適切な
ケースです。それぞれが有界な追加モデル呼び出しを追加することを受け入れてください。
レイテンシバジェットにタイムアウトをチューニングしてください。 エンドツーエンドの
ターゲットが 1,000 ms の場合、judge_timeout_ms: 800（またはそれ以下）を設定して、
judge があなたの予算全体を消費できないようにします。エンジンのデフォルトタイムアウトは
安全な出発点です；厳しい要件がある場合は下げてください。
出力 grounding では、モデル呼び出しはすでに完了しています。 grounding チェックは
アップストリームモデルが応答した後に実行されます — 追加レイテンシは末尾のみにあり、
最初のトークンまでの時間のクリティカルパスにはありません。これにより、セマンティック
強制を追加するリスクの低い場所になります。
複数の高度なルール？作業を分散させてください。 高度なルールは並行して実行される
ため、3 つの llm_judge ルールをスタックしても 1 つとほぼ同じコストがかかります —
最も長い個別のタイムアウトがウォール時間を決定し、数ではありません。追加コストなしに
セマンティックチェックを重ねるためにこれを使用してください。
強制モード
フェイルオープン vs フェイルクローズ — タイムアウトとエラー条件下でポリシーの
動作をチューニングするための完全なリファレンス。
ガードレール
ルールタイプ、judge フィールド、grounding しきい値、完全なガードレール設定
リファレンス。