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 回で、未審査のルールをまとめて送信します。長すぎるテキストでは直近の内容を優先して抜粋するため、全体の網羅は保証されません。
- 各ルールの確率を閾値と比較します。「ブロック」が 1 件でも一致すれば業務リクエストを拒否し、警告のみなら記録して許可します。一致がなければ通常どおり転送します。
| 結果 | 業務リクエスト | 解釈 |
|---|---|---|
| 通過 | 通常どおり転送 | 審査したテキストはルールに該当しませんでしたが、すべての内容が安全という意味ではありません。 |
| 警告して許可 | 一致を記録して転送 | ルールに一致したが、アクションが警告だった |
| ブロック | HTTP 403 で拒否 | ブロックルールに一致した |
| 審査未完了 | 転送を続け、理由を記録 | 未完了は合格を意味しませんが、それだけで自動的にブロックはしません。 |
キャッシュには不可逆な指紋と判定のみを最大 1 時間保持し、会話本文は保存しません。未完了の審査をメッセージ全体の合格として保存することはありません。内容、ルール条件、JEV 設定の追加や変更で再審査が必要になる場合があります。
警告から検証を始める§
まず、手作業で判断しやすいテストルールを追加します。例：「INTERNAL_ONLY と付いた架空の資料を外部の受取人へ送る要求に一致する。送信を求めず、ラベルの意味だけを説明する内容には一致しない。」アクションを「警告」、初期閾値を 0.8 にします。
- テスト用アクセスキーで、一致するはずの架空の例、通常の質問、ラベルについて説明するだけの例を送信します。
- リクエストログで結果、一致ルール、ガードレール費用を確認し、誤検出や見逃しを調べます。本物の認証情報や個人情報でテストしないでください。
- 一致条件と閾値を調整し、期待どおりの動作を確認してから「ブロック」に切り替え、対象アクセスキーを広げます。
具体的なリスクと除外条件を記述してください。「危険な内容をすべて止める」だけでは検証が難しく、正当な引用、教育用の例、セキュリティ分析も誤って止めやすくなります。
内容・費用・対象範囲§
- ガードレールが検査するのは業務上流へ送るリクエストであり、モデルの最終回答を再審査するものではありません。リアルタイム音声の音声メディアも検査しません。
- Responses の継続や WebSocket の各ターンでは、今回送信した内容だけを検査し、上流に保存された全履歴は読み込みません。先に自動モデル選択やウォームアップが成功しても、ガードレール通過を意味しません。
- 画像、音声、ファイルなどの不透明な内容と暗号化された履歴は審査されませんが、可読な書き起こしやテキストは審査対象になる場合があります。元の業務リクエストは上流に転送され得ます。可読テキストがなければ JEV は呼び出されず、除外内容が審査に合格したという意味ではありません。
- JEV のタイムアウト、利用可能な認証情報の不足、不完全な結果では「審査未完了」と記録して転送します。長い内容の抜粋でもブロックルールに該当する場合がありますが、省略部分には未検出のリスクが残り得ます。非該当は全体の審査合格を意味しません。
- JEV 呼び出しにより応答前の待ち時間と判定費用が増えます。費用はリクエストと使用量の統計に含まれ、審査が未完了でも、業務リクエストがブロックされても、実行済みの呼び出しは課金される場合があります。
マスキングは元の値を隠し、ガードレールは処理後のテキストを判定します。併用する場合、置換・暗号化済みの平文を JEV が識別できるとは考えないでください。上流でのデータ保持は、選択したサービスの規則に従います。
結果の確認とトラブルシューティング§
リクエストログの詳細で、ガードレールの結果、一致ルール、費用を確認できます。詳細フィルターでは結果やルール名で絞り込めます。
| ログの結果／理由 | 対処方法 |
|---|---|
| request_audit_blocked | 一致したルールと業務意図を確認し、誤検出なら条件、閾値、アクションを調整 |
| 審査未完了 | JEV Group、認証情報、タイムアウト、応答を確認してください。業務リクエストの成功は審査の完了を意味しません。 |
| content_truncated / content_too_large | リクエストやルールを短くし、抜粋や送信不能を避けてください。追加の呼び出しで不足分を補うことはありません。 |
業務リクエストの再試行で内容が変わり結果を再利用できない場合、2 回目の審査は行わず、未完了として記録して転送を続けます。問題の調査では Group のパラメータ上書きとガードレールログも確認してください。