AIゲートウェイでガードレールを設定する方法

なぜゲートウェイにガードレールが必要なのか

モデルのエンドポイントをそのまま利用すると、個人情報が意図せず出力されたり、プロンプトインジェクション攻撃を受けたり、不適切な回答が生成されたりするリスクがあります。ガードレールは、モデルにリクエストが届く前、および回答がユーザーに届く前にトラフィックを検査し、必要に応じて書き換えることで、これらの問題を解決します。

AI Gatewayにガードレールを導入すれば、各チームが個別に安全対策を実装しなくても、すべてのアプリケーションに自動的に同じ保護が適用されます。TrueFoundryは、PIIマスキングとプロンプトインジェクション検知のためのガードレールを標準搭載しており、サードパーティのキー設定なしで完全に管理された状態で利用可能です。

2ステップのモデル：登録とポリシー設定

AI Gatewayでのガードレール適用は、 ガードレールのドキュメント にある通り、2つのステップで行います。

• ガードレールの登録 AI Gatewayの「Guardrails」セクションに移動してガードレールグループを作成し、TrueFoundry標準搭載のもの、外部プロバイダー、または カスタムガードレールを追加します。
  

• ポリシーの設定 AI Gatewayの「Policies」から「Guardrails」へ進み、どのガードレールをどのフックで適用するかを決定するルールを作成します。

ガードレールルールの作成

「Policies」内の「Guardrails」で「Add Rule」をクリックします。各ルールには一意のルールIDがあり、適用対象や実行場所を決定するいくつかのセクションで構成されています。

• リクエストの送信先（ターゲット） 1つ以上のモデル、またはMCPサーバーや特定のツールを指定してマッチングさせます。複数のターゲット条件はORで結合されるため、リストされたモデルやMCPサーバーのいずれかにリクエストが送信されればルールが適用されます。ターゲットを指定しない場合は、すべてのモデルに適用されます。
  

• サブジェクトから選択 ユーザー、チーム、または仮想アカウントをINまたはNOT IN条件でフィルタリングします。サブジェクトフィルタを指定しない場合、ルールはすべての呼び出し元に適用されます。
  

• メタデータを使用 X-TFY-METADATAヘッダーで送信されたキーと値のペア（例: environment production）に基づいてマッチングを行います。
  

• フックに適用 フックを選択し、そのフックで実行するガードレールを選びます。同じフックに複数のガードレールを関連付けることができ、マッチングしたリクエストに対してそれらすべてが実行されます。

4つのフック

• LLM入力 プロンプトがモデルに送信される前に実行されます。
  

• LLM出力 モデルが応答した後、その応答が返される前に実行されます。
  

• MCPツール呼び出し前 MCPツールが実行される前に実行されます。
  

• MCPツール呼び出し後 MCPツールが結果を返した後、その結果がモデルに到達する前に実行されます。

すべてのリクエストに対してすべてのルールが評価され、マッチングしたすべてのルールからガードレールが組み合わされて適用されます。例えば、あるルールでLLM入力に対するPII検出を適用し、別のルールでLLM入力に対するプロンプトインジェクション検出を適用した場合、両方が実行されます。

Want the same safety on every LLM and tool call?

We will configure PII redaction and prompt-injection defense on your gateway, live.

Book a demo

PIIおよびPHIの秘匿化設定

のPIIおよびPHI検出ガードレール は、個人識別情報（PII）および保護対象保健情報（PHI）を特定して秘匿化するTrueFoundryの組み込みガードレールです。内部的にはAzure AI LanguageのPII検出機能を利用しており、完全に管理されているため、サードパーティのAPIキーは不要です。

ミューテート（変更）モードのみをサポートしており、検出されたエンティティは常に編集されます。設定フォームで名前を指定し、PII（個人識別情報）カテゴリを選択するかデフォルトの全カテゴリ設定を維持した上で、適用する戦略を選択します。検出された値はアスタリスクに置き換えられるため、メッセージ内の電話番号やメールアドレスは、モデルがそれらを認識する前にマスクされます。

一般的な構成では、ユーザーメッセージをクリーンにするためのLLM入力、応答をクリーンにするためのLLM出力、そしてツールパラメータやデータベース行などのツール結果からPIIを除去するためのMCPフックに対して、PII編集を適用します。

プロンプトインジェクション防御の設定

のプロンプトインジェクションガードレール は、Azure Prompt Shieldを活用した組み込みのガードレールです。直接的なプロンプトインジェクション、いわゆる「DAN（Do Anything Now）」パターンなどのジェイルブレイク攻撃、およびドキュメントやコンテキスト内に隠された間接的なインジェクションを検出します。ユーザープロンプトとドキュメントの内容を個別に分析します。

バリデーション（検証）モードのみをサポートしており、攻撃の検出とブロックは行いますが、コンテンツの変更は行いません。設定では名前と適用戦略を指定するだけです。ドキュメントでは、まず監査戦略でリクエストトレース内の検出状況を監視し、信頼性が確認できてから適用戦略に切り替えることが推奨されています。

ゲートウェイがリクエストに対してガードレールを実行する仕組み

LLMリクエストが発生すると、まず入力ミューテートガードレールが実行され、完了するまで待機します（例：プロンプトからのPII編集）。その後、モデルへのリクエストが進行している間に、プロンプトインジェクションなどの入力バリデーションがバックグラウンドで実行されます。モデルの実行中にバリデーションが失敗した場合、ゲートウェイは直ちにモデルへのリクエストをキャンセルするため、不要なコストが発生することはありません。

モデルの応答後、出力ミューテートによって機密情報が除去され、出力バリデーションが最終結果をチェックしてからクライアントに送信されます。MCPツールの場合、ツール呼び出しの前にすべての事前ガードレールが実行され、いずれかが失敗した場合はツールは実行されません。ガードレールはツール呼び出しごとに個別に実行されます。

Make guardrails standard across every team

See centralized PII and injection policies applied to all apps, with full tracing, on your infrastructure.

Talk to an Expert