JEV AI ガードレール
業務リクエストを上流へ送る前に、JEV が自然言語のルールでテキストを審査し、一致時に警告して許可するか、その場でブロックします。
検査する内容§
AI ガードレールは、認証情報の漏えい、個人情報、プロンプトインジェクション、独自の業務リスクなどの検出に利用できます。ルールで一致条件を記述し、JEV が判定確率を返します。GPT-Load は閾値とアクションに基づいてリクエストを許可するか決定します。
既定では無効の実験機能です。業務メッセージを書き換えるものでも、マスキングでもなく、すべてのリスクの検出を保証するものでもありません。テキストを隠す場合はマスキングを、意味に基づいてリクエストを止める場合は AI ガードレールを使います。
JEV とルールの設定§
- Jev チャネルのグループを作成するか、Decisions に対応した OpenRouter グループを用意します。API キーと、そのサービスで実際に利用可能な JEV 決定モデルを追加します。
- 「設定 → 実験機能 → JEV 共通設定」で、決定用のグループ、モデル、タイムアウトを明示的に選びます。ガードレールではグループの指定が必須で、「利用可能なグループを自動選択」だけでは使えません。この設定は自動モデル選択でも共有します。
- 「AI ガードレール」を有効にし、対象のアクセスキーを選びます。未選択の場合はすべてのアクセスキーが対象です。一度に全アプリへ影響させないよう、専用のテストキーから始めてください。
- プリセットまたは独自ルールを追加し、名前、一致条件、閾値、アクションを入力して保存します。認証情報漏えい、個人情報、プロンプトインジェクションの組み込みプリセットは、すべて既定で「警告」です。一致しただけではブロックしません。
閾値は 0 より大きく 1 以下で、判定確率がその値に達したときにアクションを実行します。0.8 は確率 0.8 以上で一致とする意味であり、実際の精度が 80% という意味ではありません。閾値を下げると検出しやすくなりますが、誤検出も増える場合があります。
検査対象のテキスト、ルール、必要な文脈を選択した JEV サービスへ送るため、遅延や費用が発生します。有効化する前に、そのサービスへデータを送ってよいか確認してください。マスキングが有効な場合、JEV が受け取るのは処理後の内容です。
審査とブロックの流れ§
- 認証と権限の確認後、ゲートウェイが業務送信内容を準備し、マスキングが有効なら先に処理します。
- 今回のリクエストに含まれるメッセージ、システムプロンプト、ツール関連テキストを抽出し、有効な審査結果を再利用しながら、新規・変更内容を JEV で審査します。
- 長い内容やルールは予算に応じて分割審査します。検査対象は全体をカバーしますが、補助的な前文は抜粋する場合があります。必要な検査がすべて終わるまで、回答モデルに業務リクエストを送りません。
- 各ルールの確率を閾値と比較します。「ブロック」が 1 件でも一致すれば業務リクエストを拒否し、警告のみなら記録して許可します。一致がなければ通常どおり転送します。
| 結果 | 業務リクエスト | 解釈 |
|---|---|---|
| 通過 | 通常どおり転送 | 必要な審査が完了し、ルールに一致しなかった |
| 警告して許可 | 一致を記録して転送 | ルールに一致したが、アクションが警告だった |
| ブロック | HTTP 403 で拒否 | ブロックルールに一致した |
| 審査未完了 | 通常は HTTP 503 で拒否し、総予算超過では 413 | 検査を完了できず、通過として扱わない |
結果キャッシュには不可逆の指紋と判定だけを保存し、会話本文全体は保存しません。再利用は最大 1 時間です。新規・変更内容は再検査が必要で、ルール条件や JEV 設定の変更でも再利用できなくなる場合があります。
警告から検証を始める§
まず、手作業で判断しやすいテストルールを追加します。例：「INTERNAL_ONLY と付いた架空の資料を外部の受取人へ送る要求に一致する。送信を求めず、ラベルの意味だけを説明する内容には一致しない。」アクションを「警告」、初期閾値を 0.8 にします。
- テスト用アクセスキーで、一致するはずの架空の例、通常の質問、ラベルについて説明するだけの例を送信します。
- リクエストログで結果、一致ルール、ガードレール費用を確認し、誤検出や見逃しを調べます。本物の認証情報や個人情報でテストしないでください。
- 一致条件と閾値を調整し、期待どおりの動作を確認してから「ブロック」に切り替え、対象アクセスキーを広げます。
具体的なリスクと除外条件を記述してください。「危険な内容をすべて止める」だけでは検証が難しく、正当な引用、教育用の例、セキュリティ分析も誤って止めやすくなります。
内容・費用・対象範囲§
- ガードレールが検査するのは業務上流へ送るリクエストであり、モデルの最終回答を再審査するものではありません。リアルタイム音声の音声メディアも検査しません。
- Responses の継続や WebSocket の各ターンでは、今回送信した内容だけを検査し、上流に保存された全履歴は読み込みません。先に自動モデル選択やウォームアップが成功しても、ガードレール通過を意味しません。
- 審査できない非テキスト内容、総予算の超過、JEV のタイムアウト、利用可能な認証情報がない場合、不完全な結果では、検査を省略せずリクエストを拒否します。画像や添付ファイルを使うアプリは、先にテストキーで互換性を確認してください。
- 警告とは「一致しても許可する」という意味です。すべてのルールを警告にしても、審査サービスが失敗した場合は業務リクエストを拒否します。
- JEV 呼び出しにより応答前の待ち時間と決定費用が増え、長い内容では複数バッチになる場合があります。費用はリクエストと使用量統計に計上され、業務リクエストが最終的にブロックされても、実行済みの審査には費用が発生し得ます。
マスキングは元の値を隠し、ガードレールは処理後のテキストを判定します。併用する場合、置換・暗号化済みの平文を JEV が識別できるとは考えないでください。上流でのデータ保持は、選択したサービスの規則に従います。
結果の確認とトラブルシューティング§
リクエストログの詳細で、ガードレールの結果、一致ルール、費用を確認できます。詳細フィルターでは結果やルール名で絞り込めます。
| エラーコード | 対処方法 |
|---|---|
| request_audit_blocked | 一致したルールと業務意図を確認し、誤検出なら条件、閾値、アクションを調整 |
| request_audit_incomplete | 理由に応じて JEV グループ、認証情報、タイムアウト、結果、非テキスト内容を確認 |
| request_audit_too_large | リクエストやルールを短くする。分割審査には対応済みで、このエラーは総審査予算が不足していることを示す |
業務の再試行で検査対象が変わり、今回の審査を再利用できない場合も、続行を拒否します。グループのパラメータ上書きも確認し、審査失敗を回答モデルの利用不可と取り違えないようにしてください。