AI Gatewayガードレールの解説：フック、強制、および失敗時のセマンティクス

ガードレールは単なる安全スイッチではありません。フック、動作モード、強制戦略、スコープ、障害時の挙動、そしてエビデンスによって、システムが実際に何を保証するかが決まります。

前提となる考え方。 本解説は、2026年9月19日時点のTrueFoundryの「AI Gateway Guardrails Overview」および「Configure Guardrail Policies」ドキュメントに基づいています。LLMの入出力およびMCPのプリ/ポストフック、検証および変更モード、3つの強制戦略、ポリシーマッチングの統合、LLM入力の非同期検証、同期的な変更・出力・MCPチェック、LLM出力ガードレールのストリーミング制限、トレーススパンについて記述しています。脅威モデル、ロールアウトゲート、アプリケーション認可パターンは、推奨されるエンジニアリングプラクティスです。

検出器ではなく、フックから始める

「PII（個人情報）検出器がある」というだけでは、システムの挙動についてはほとんど分かりません。それはどこで実行されるのでしょうか？モデルにプロンプトが渡される前か、生成された回答か、ツールの引数か、それともツールの実行結果か？データを書き換えるのか、ブロックするだけか、あるいはログに記録するだけか？検出器がタイムアウトした場合はどうなるのか？ストリーミングは、完全な回答が生成される前にコンテンツを公開してしまうのか？

TrueFoundry AI Gatewayは、LLM入力、LLM出力、MCPツール実行前（Pre-Invoke）、MCPツール実行後（Post-Invoke）という4つのガードレールフックを提供します。このトポロジーが基盤となります。入力の変更（mutate）により、モデルに渡される前にデータを編集できます。出力チェックにより、生成された回答を保留できます。ツール実行前のチェックにより、実行前に操作を停止できます。ツール実行後のチェックにより、機密性の高い結果がモデルに到達するのを防ぐことはできますが、ツールが既に実行してしまった副作用を取り消すことはできません。

フックの図は、時間的な到達範囲を強調しています。操作の後に配置された制御は、その結果の開示を管理することはできますが、操作そのものを遡及的に防ぐことはできません。

検証（Validate）と変更（Mutate）は異なる約束事

検証モードでは、ガードレールはデータを検査し、書き換えずにブロックすることができます。変更モードでは、データを変換し、さらにブロックすることも可能です。変更ガードレールは優先順位に従って順次実行されます。あるガードレールの出力が次のガードレールの入力となるためです。

したがって、順序が重要です。編集ステップによって後の検出器が必要とする証拠が削除される可能性があり、一方で正規化ステップによって後のポリシーの信頼性が高まる可能性があります。順序付けられたチェーン全体をバージョン管理し、テストしてください。各ガードレールがどの状態のデータを評価したかを理解せずに「すべてのガードレールが通過した」と解釈してはいけません。

MCP呼び出しの場合、ツール実行前の変更または検証は、操作前の引数を参照します。ツール実行後の制御は、実行後の結果を参照します。SQLツールが既にデータベースを変更してしまった場合、その応答をブロックしても後続のコンテキストは保護されますが、データベース自体は保護されません。副作用に対する安全性には、コンテンツガードレールに加えて、認可、制約されたツール契約、冪等性、および整合性の確保が必要です。

強制戦略がフェイルオープンとフェイルクローズの挙動を定義する

TrueFoundryは3つの戦略を定義しています。「Enforce（強制）」は違反をブロックし、ガードレール自体がエラーになった場合もブロックします。「Enforce But Ignore On Error（エラー時は無視して強制）」は検出された違反をブロックしますが、ガードレールが失敗した場合はトラフィックを通過させます。「Audit（監査）」はトラフィックを通過させ、検出結果とガードレールのエラーの両方を記録します。

これらの選択は、組織全体で一律に決めるのではなく、フックごと、リスクごとに判断すべきです。破壊的な本番操作に対する厳格なツール実行前の認可チェックには、フェイルクローズの挙動が必要かもしれません。リスクの低い社内アシスタントにおける補助的な関連性スコアラーであれば、機能低下を許容できるかもしれません。この決定には、偽陰性の被害、偽陽性の被害、検出器の信頼性、および利用可能なフォールバックを考慮する必要があります。

動作モードと強制戦略は独立した概念です。データが書き換えられるのか、ブロックされるのか、エラー時に許可されるのか、あるいは監視のみが行われるのかを判断するには、チームはこれら両方の軸を理解する必要があります。

実行順序がレイテンシとコストに与える影響

TrueFoundryでは、入力の書き換えはモデルへのリクエスト前に行われる同期処理として定義されています。入力バリデーションはモデル呼び出しと並行して実行可能です。モデルの実行中にバリデーションが失敗した場合、ゲートウェイはそのリクエストをキャンセルします。出力の書き換えとバリデーションはモデルの応答後に行われるため、そのレイテンシは戻り経路で発生し、モデルのコストはすでに発生している状態となります。

MCPのツール実行前後のガードレールは同期的に動作します。ツール実行前のレイテンシは実行を遅延させますが、不適切な呼び出しによるコストや副作用を防ぐことができます。ツール実行後のレイテンシは結果の配信を遅延させ、内容の編集や非表示を可能にしますが、ツール自体はすでに呼び出された後となります。

ストリーミングが出力の保証に与える影響

現在のTrueFoundryのドキュメントでは、ストリーミング応答の場合、ゲートウェイがチャンク配信前に完全な応答を評価できないため、LLM出力ガードレールはスキップされると記載されています。入力ガードレールは引き続き適用されます。ゲートウェイ側での出力チェックが必要なユースケースでは、リクエストを非ストリーミングにする必要があります。

これは単なる補足事項ではなく、アーキテクチャ上の重要な決定事項です。ストリーミング出力を組み立てて事後にバリデーションを行うクライアントは問題を検知できますが、すでに表示または実行されたコンテンツを取り消すことはできません。アプリケーションは、トークンの即時配信と完全な応答の強制のどちらかを選択するか、あるいはリリースを遅延させる中間バッファを設計する必要があります。

スコープが検出対象となる証拠を決定する

LLMメッセージに関して、TrueFoundryでは会話全体、最後のメッセージ、または直近のN件のメッセージを対象とするスコープ制御が定義されています。ウィンドウを狭くすればコストと露出を抑えられますが、複数のやり取りにまたがる攻撃を見逃す可能性があります。全履歴のチェックはコストがかかる可能性があり、外部のガードレールプロバイダーにより機密性の高いコンテンツが送信されるリスクもあります。

現在のドキュメントでは、システムプロンプトはデフォルトでガードレールの対象外となっています（CrowdStrike AIDR分析を除く）。MCPの実行前後チェックは、LLMメッセージのスコープを使用するのではなく、ツールへの引数や結果の全体をスキャンします。チームはこれらの可視性の境界を明示的に文書化し、「会話が保護されている」という言葉が、すべての指示やフィールドが検査されていることを意味しないようにする必要があります。

ポリシーマッチングは和集合として構成される

ガードレールは、ヘッダーまたはゲートウェイポリシーを通じてリクエストごとに適用できます。ポリシーはモデル、MCPサーバーとツール、ユーザー、チーム、仮想アカウント、およびリクエストメタデータと照合されます。TrueFoundryのドキュメントによると、すべてのルールが評価され、一致したすべてのルールからのガードレールがフックごとに組み合わされます。

この和集合モデルは加算的に機能します。広範なベースラインでPII（個人情報）検出を適用しつつ、本番環境のメタデータルールでより厳格なインジェクション検出を追加し、特定のMCPツールルールでSQLポリシーを追加するといったことが可能です。ターゲットやサブジェクトの条件を省略すると広範囲に一致してしまうため、不完全なルールを設定すると意図した以上に適用範囲が広がる恐れがあります。

設定ドキュメントによると、リクエストごとのガードレールヘッダーはポリシーをバイパスします。誰がこれらのヘッダーを送信できるか、またアプリケーション側で選択されたガードレールがそのワークロードに対して許容されるかを制御してください。統合名を知っているという理由だけで、リクエストがより弱いポリシーを選択できてはなりません。

ポリシールールは加算的に構成されます。有効な制御とは、特定のルール単体ではなく、そのサブジェクト、ターゲット、ツール、メタデータ、およびフックに対して解決された和集合です。

トレースは実行の証拠であり、安全性の証明ではない

TrueFoundryは、ガードレールの実行をリクエストトレース内のスパンとして記録し、タイミングや結果を含めます。ブロックされたリクエストもトレースされます。これにより、レイテンシ、検出結果、書き換え内容、および強制の結果を検証可能になります。

スパンは、設定されたガードレールが実行され、バージョン管理されたセットアップ下で結果を報告したことを証明するものです。これは、検出器が完璧な網羅性を持っていることや、最終的なビジネス上のアクションが安全であることを証明するものではありません。検出器のバージョン、ポリシーのバージョン、フック、スコープ、入力ダイジェスト、書き換えダイジェスト、強制結果、エラー、およびレイテンシを保持してください。それらの記録を、ツールの試行結果や最終的な権威ある結果と紐付けてください。

ガードレールプロバイダーはデータ処理パスを作成します

一部のガードレールはTrueFoundryが管理するインフラストラクチャ上で実行されますが、外部プロバイダーやカスタムサービスを呼び出すものもあります。選択されたフックとメッセージスコープによって、そのプロセッサが受信できるデータが決まります。プロバイダーを有効にする前に、ドキュメントのフィールド、リージョン、保持期間、暗号化、サブプロセッサ、認証情報、タイムアウト時の動作、およびサービスが入力内容を学習に使用するかどうかを確認してください。

可能な限り、データがゲートウェイから送信される前に最小化してください。ローカルでの変更ステップにより、広範な外部分類器が実行される前に機密情報を削除できますが、編集によって検出に必要なシグナルが損なわれないよう、順序をテストする必要があります。プロバイダーの選択は環境を意識したものにしてください。TrueFoundryのドキュメントでは、管理対象の組み込み機能のいくつかがSaaS専用であると明記されており、セルフホスト環境向けには代替手段が案内されています。

解決されたコントロールプランをバージョン管理する

1つのリクエストが複数のポリシールールに一致する場合があり、各ルールは複数のフックに複数のガードレールを関連付けることができます。したがって、有効なプランは単なるポリシー名ではなく、解決されたセットとなります。リクエストに適用されたルールID、ポリシーバージョン、統合バージョン、優先順位、強制戦略、スコープ、およびカスタムエラー動作を記録してください。

ガードレールの変更はソフトウェアリリースのように推進してください。候補となるプランを監査またはシャドウ分析でテストし、キャプチャされた代表的な入力に基づいて現在のプランと比較し、誤検知や見逃しを確認してから、限定的なトラフィックに展開します。ロールバック時には、順序や失敗時のセマンティクスを含め、解決済みの構成全体を復元できるようにしてください。

運用メトリクスには分母が必要

評価されたリクエスト数、スキップされたフック、ガードレールのエラー、タイムアウト、違反、変更、ブロック、キャンセル、およびレイテンシを、統合およびポリシーバージョンごとに集計してください。ブロックの総数ではなく、対象となるトラフィックに対する割合で報告します。検出結果がゼロであることは、意図したスコープで実際に実行された場合にのみ健全であると言えます。

MCPコントロールについては、ツール実行前のブロックとツール呼び出しの試行、およびツール実行後の結果とツール実行後の判定を関連付けてください。LLMコントロールについては、入力のキャンセル、出力の拒否、および出力チェックがスキップされたストリーミング応答を区別してください。許可されたトラフィックをサンプリングして人間がレビューすることで、見逃されていた誤検知が可視化される機会を作ります。

監視から強制へと段階的に展開する

監査モードは、ブロックせずに潜在的な検出結果を表示できるため、キャリブレーションに役立ちます。推進する前に、サンプリングしたトラフィックにラベルを付け、誤検知や見逃しを測定し、プロバイダーのタイムアウトをテストし、レイテンシとコストを見積もってください。組織が失敗時の動作を選択し、運用担当者が証拠を解釈できるようになってから、強制戦略へ移行します。

ブロック率の低下がシステムの改善を意味すると判断しないでください。それは、検出器の停止、スコープの縮小、トラフィックの変化、あるいはユーザーがコントロールを回避する方法を学習したことを意味している可能性もあります。違反だけでなく、カバレッジとエラー率も監視してください。

実際のギャップを露呈させる障害テスト

• 出力ガードレールを設定した状態で応答をストリーミングし、ドキュメント化されたスキップが運用担当者に表示されることを確認してください。
• すべての強制戦略において、各ガードレールのタイムアウトをテストしてください。
• 一致する複数のポリシーを適用し、それらのガードレールがフックごとに統合されていることを確認してください。
• ターゲットおよびサブジェクトフィルターを省略し、ルールの広範な一致が意図通りであることを確認してください。
• プロンプトインジェクションを複数のメッセージに分散させ、最後、最後からN番目、および全メッセージのスコープを比較してください。
• 変更ツールが成功した後にツール実行後の結果をブロックし、外部への影響が依然として調整されていることを確認してください。
• 変更の優先順位を変更し、後続の検出器が実質的に異なるコンテンツを認識するかどうかをテストしてください。

運用ルール

ガードレールの真の契約とは、フック、可視性、モード、順序、強制戦略、ポリシーマッチ、および失敗時の動作の組み合わせです。検出器の名前を指定するだけでは、システムの大部分が未定義のままになってしまいます。

TrueFoundry AI Gatewayは、モデルとMCPの両方のトラフィックにおいてこれらの決定を明示し、その実行をトレースに記録します。ビジネス上の認可、副作用の正確性、および結果の証拠については、引き続きアプリケーション側が責任を負います。この境界線は弱点ではなく、コンテンツの検査がエージェントの完全な安全性と混同されるのを防ぐためのものです。

参考文献

1. TrueFoundry — AI Gatewayガードレールの概要。
2. TrueFoundry — ガードレールポリシーの設定。
3. TrueFoundry — リクエストログ：トレース検査。

編集上の開示 本記事は、2026年9月19日時点における、引用された公開資料に対するTrueFoundryのエンジニアリング上の解釈を反映したものです。製品の機能はリンク先のドキュメントの範囲内に限定されます。例やデフォルトの動作はあくまで説明を目的としたものであり、法的助言、監査意見、独立したベンチマーク、あるいはセキュリティ、安全性、コンプライアンスの保証を構成するものではありません。

‍