リクエストのマスキング
業務上流や JEV にメッセージを送る前に機密テキストを隠します。クライアントに元の値を返す必要がある場合は、復元可能な暗号化を利用できます。
解決する課題§
会話、ツール引数、ツール結果には、メールアドレス、電話番号、業務識別子、キーなどが含まれることがあります。マスキングはゲートウェイ内で送信用コピーに正規表現ルールを適用し、上流への露出を減らします。リクエストの違反判定を行うものでも、ログ表示だけを伏せるものでもありません。
| 処理方式 | 上流から見える内容 | 利用場面 |
|---|---|---|
| 固定置換 | 指定した置換テキスト。元の値は復元不可 | 後で元の値を使わず、情報を隠すだけの場合 |
| 復元可能な暗号化 | 元の値の違いを区別できる、安定した暗号文 | 業務上の対象を区別したい場合や、クライアント実行ツールに元の値を渡す場合 |
同じアクセスキーでは同じ元の値が同じ暗号文になり、モデルが参照関係を維持できます。異なるアクセスキー間は分離されます。モデルは暗号文を扱えますが、暗号化前の意味を理解したり、暗号文で元のメールアドレスやアカウントを検索したりすることはできません。
ルールの設定§
- 管理者として「設定 → リクエストのマスキング」を開きます。ルールは全体設定であり、実験機能のスイッチとは独立しています。ルールがなければ、新たなマスキング処理は行いません。
- メール、中国の携帯電話番号、一般的な API キー、秘密鍵のプリセットから始めるか、Go／RE2 の正規表現を追加します。プリセットは出発点なので、実際のデータ形式に合わせて一致範囲を絞ってください。
- 「固定置換」で置換テキストを入力するか、「復元可能な暗号化」を選びます。固定置換は文字どおり適用され、$1 などはキャプチャグループに展開されません。
- 保存後は新しいリクエストに適用されます。実際の通信に適用する前に、架空のデータで一致、応答、ツール呼び出しを検証してください。
元のテキストで重複する一致範囲は結合され、先に並ぶルールで処理されます。前の置換結果に次のルールを再適用する仕組みではありません。メッセージ全体に一致する広いルールを先頭に置くことは避けてください。
リクエストとレスポンスの流れ§
- クライアントが元のメッセージを GPT-Load に送信し、ゲートウェイは従来の権限、モデル、ルーティング設定で送信先を選びます。
- パラメータ上書き後の送信テキストから、一致部分を置換または暗号化します。業務上流と JEV のどちらにも、処理後の内容を送信します。
- 上流が応答またはツール呼び出しを生成します。会話応答内の有効な暗号文は、通常のレスポンス、SSE、Responses WebSocket のいずれでも、クライアントに返す前に復元します。
- クライアント側のツールは復元済みの引数を受け取ります。次のターンに履歴やツール結果を含める際も、ゲートウェイが送信内容を再び保護します。
現在のアクセスキーで認証できる完全な暗号文だけを復元できます。モデルが書き換え、切り詰め、誤記した場合、ゲートウェイは元の値を推測せず、その部分が暗号文のまま表示される場合があります。固定置換は復元できません。
署名付きの思考・履歴ブロックは完全な形で保持してください。ゲートウェイは復元に必要な記録を付け、次のターンで検証して上流の原文と署名を復元します。クライアントは署名や内容を変更せず、ブロックをそのまま保持する必要があります。
検証できる例§
TEST-PROJECT-[0-9]+ というルールを追加し、まず「固定置換」で [PROJECT] を指定します。以下の架空の識別子をそのまま繰り返すようモデルに依頼し、次に「復元可能な暗号化」へ切り替えて新しいリクエストを送信します。
curl http://127.0.0.1:3001/v1/chat/completions \
-H "Authorization: Bearer $GPT_LOAD_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"YOUR_MODEL","messages":[{"role":"user","content":"Repeat exactly: TEST-PROJECT-123"}]}'固定置換では上流には [PROJECT] だけが見えます。復元可能な暗号化では暗号文が見え、そのまま返されればクライアントには TEST-PROJECT-123 が再び表示されます。ルールと復元経路を確かめる例ですが、モデルが毎回復唱の指示に従う保証はありません。
実際の送信内容を確認する場合は、自分で管理するテスト用の上流で架空のデータを観察してください。デバッグのために本番のメッセージや本物のキーを記録しないでください。
対象範囲と制限§
- 対応するメッセージ、ツール引数、ツール結果などのテキストを処理します。すべての JSON フィールドを無差別に置換するものではなく、モデル名、ID、ロール、ツール名などのプロトコル上の意味は維持します。
- 画像、音声、添付ファイル内部、リクエストに含まれないリモート履歴、不透明な暗号化内容は、検査可能な平文の対象外です。数値型のフィールドも文字列ルールでは暗号化しません。
- Chat、Responses、Anthropic、Gemini の会話はレスポンスの復元に対応します。画像生成、埋め込み、リランキングなどの非会話リクエストでは、対応する送信テキストだけを処理し、同様のレスポンス復元は提供しません。
- クライアント実行のツールには復元済みの引数を渡せます。一方、上流の検索、ホスト型 MCP、コード実行などのツールは暗号文を受け取るため、元の値に依存する処理はできません。
- 暗号化でテキストが長くなり、トークン使用量が増える場合があります。完全な暗号文やツールの JSON 断片を待つため、ストリーミング出力が一時的に遅れる場合もあります。
マスキングと AI ガードレールは同時に使えますが、JEV が審査するのはマスキング後の内容です。隠した元の値を平文で JEV に送ることはないため、保護したい目的に合わせてルールを選んでください。
トラブルシューティングと鍵§
request_redaction_failed が出たら、ルールの範囲、テキスト構造、処理サイズの上限を確認します。安全に処理できないリクエストは拒否されます。応答に暗号文が残る場合は、モデルによる変更、アクセスキーの識別情報の変更、プロトコルの復元対応を確認してください。
復元可能な暗号化は、インスタンスの ENCRYPTION_KEY とアクセスキーの識別情報から導出され、セッションごとの対応表には依存しません。ルールを削除しても復号能力は失われませんが、上流の既存履歴を遡って処理することはありません。無効化後も、すべてのストリーミング履歴経路で復元されるとは限りません。
元のアクセスキー識別情報と復号能力を保つには、データベースと元の暗号化マスターキーを保持してください。アクセスキーの作り直しやインスタンスのマスターキー交換では、旧識別情報に属する暗号文を復元できません。