AIエージェントの道具呼び出しを守る、3カ所の検査ポイント

AIエージェントがツールやMCPを使う場合、検査ポイントはモデル投入前、ツール実行前、ツール結果の取り込み前の3カ所に置く。Strands Agents SDKでは、BeforeInvocationEvent、BeforeToolCallEvent、AfterToolCallEventを使い、各境界のデータをAmazon Bedrock Guardrailsまたはローカルルールで判定できる。

3カ所へ同じ検査を一律にかける必要はない。受信した自然言語には包括的なGuardrail、実行直前の引数にはスキーマ・許可リスト・正規表現、外部から戻る結果にはPIIや禁止内容の評価を割り当てると、未検査のデータを次の境界へ渡さず、不要な遅延も抑えやすい。

モデル境界だけでは残る空白

モデル呼び出しに設定したGuardrailsは、モデルへ渡すプロンプトとモデルが生成する応答を保護する。一方、エージェントはモデルの判断からツール引数を組み立て、外部システムへ送り、API、データストア、MCPサーバーなどから結果を受け取る。モデルの入出力だけを対象にすると、このツール層を直接検査する地点が残らない。

2026年8月27日付の AWS Security Blogの実装例 は、その空白に3つの検査地点を置き、地点ごとに検査強度を変える構成を示している。対応関係は次の通りだ。

• BeforeInvocationEvent：呼び出し開始時の受信データを、モデル推論やツール実行が始まる前に検査する。
• BeforeToolCallEvent：選択されたツールと引数を、実処理へ渡す前に検査する。
• AfterToolCallEvent：ツールの返却値を、モデルへ戻す前に検査して必要なら置換する。

Strands Agentsのフック仕様 でも、BeforeInvocationEventは新しい呼び出しの開始時、BeforeToolCallEventはツール実行前、AfterToolCallEventは実行完了後に発火すると定義されている。後者ではcancel_toolによる取消やresultの変更が可能であり、検出だけでなく境界通過の阻止に使える。

検査点1：受信内容をモデルに見せる前に止める

BeforeInvocationEventには、推論やツール選択より前に拒否すべきデータを集める。ユーザーの依頼に加え、呼び出し開始前に会話へ組み込んだ別エージェントの出力、RAGの取得文、MCP由来の内容があれば、それらも由来を識別したまま対象にする。

ここでは、禁止トピック、コンテンツフィルター、PII検出などを含む包括的なGuardrailが向いている。違反時は呼び出しを取り消すか、未検査の内容を除いた固定メッセージへ置き換える。警告だけを記録して原文を残せば、その後のモデルやツールが問題のデータを参照できるため、入口の防御にはならない。

ただし、AWSのサンプルコードが直接調べるのは、履歴を逆順にたどって見つけた直近のuserメッセージ内のテキストブロックである。独自に追加したRAG文書や別エージェントのデータが別の構造に入る実装では、サンプルをそのまま使わず、実際の格納場所から検査対象を収集しなければならない。

会話履歴全体を毎回評価すると同じ文章を繰り返し送ることになる。新たに加わった外部データを識別し、検査済みの範囲とポリシーの版を監査記録へ残す設計なら、重複評価を避けながら判定経路を追跡しやすい。これはSDKの必須機能ではなく、運用上の推奨である。

検査点2：副作用の前に引数を確定する

BeforeToolCallEventは、外部への副作用を起こす直前の防波堤になる。メール送信、ファイル更新、顧客情報の検索、決済操作などでは、引数に禁止された宛先、想定外のパス、過大な金額、用途外のPIIが含まれていないかを判定し、問題があればcancel_toolへ理由を設定して実行を取り消す。

最初に適用するのは、結果が決定的で処理の軽い検査だ。必須フィールドと型を確認するJSON Schema、操作可能なツール・ドメイン・列挙値の許可リスト、数値の範囲、固定形式のIDやメールアドレスを捉える正規表現が該当する。構造上は正しいものの、自然言語として禁止トピックや機密情報を含む値だけをApplyGuardrailへ送ればよい。

正規表現だけでPII全般を判定するのは難しい。電話番号や識別子には表記揺れがあり、自由記述では文字列の文脈も影響する。反対に、整数の範囲や列挙値まで外部評価へ送る合理性は乏しいため、構造と既知の形式はローカル、自然言語と文脈依存の方針はGuardrailsと分担する。

AWSのサンプルは、ツール引数の直下にある文字列値を順に評価する簡潔な実装である。配列やオブジェクトの中に自由文が入るツールでは、再帰的に値を取り出すか、ツールごとに検査対象のフィールドを明示する必要がある。JSON全体を文字列化するだけでは、フィールドの意味に応じた許可条件を表現しにくい。

検査点3：外部の結果を後段へ渡す前に処理する

AfterToolCallEventでは、ウェブ検索、MCPサーバー、外部API、データストアから戻る結果を調べる。ツールが正常終了したことと、返却内容を安全に利用できることは別だ。外部データにPIIや禁止内容が含まれていれば、モデルの次の推論へ入る前に遮断する。

実装では対象ツールを名前で絞り、返却値からテキストブロックを抽出してOUTPUTとして評価する。違反時は元の結果を残さず、同じtoolUseIdを持つエラー結果や安全な代替文へevent.resultを置き換える。「無視するように」と指示しながら原文も渡す方法では、未検査の内容をモデルのコンテキストから排除できない。

検索結果や文書が大きい場合は、取得件数と本文サイズをツール側で制限し、スクリプトやナビゲーションなど利用しない部分を除いてから検査する。ただし、要約してから安全性を調べる構成では、要約器が未検査の原文へ先に触れる。原文を扱えるコンポーネントを限定し、その処理自体を信頼境界の内側に置く必要がある。

テキスト以外の返却値も見落とせない。画像、ファイル、構造化データを使うツールでは、テキストブロックだけを対象とするサンプルでは保護範囲が不足する。対応するGuardrailポリシーで評価できない形式は、ファイル種別、サイズ、保存先、スキーマなどを別のローカル検査で制限する。

ApplyGuardrailの共通関数で判定をそろえる

3つのフックから呼ぶ共通関数には、guardrailIdentifier、guardrailVersion、source、contentを渡す。Amazon BedrockのApplyGuardrail解説 によると、このAPIは基盤モデルを呼び出さずに任意のテキストを評価し、拒否トピック、コンテンツフィルター、PIIディテクター、単語ブロックリストと照合できる。受信内容やツール引数にはINPUT、ツール結果にはOUTPUTを指定し、利用するGuardrailのIDとバージョンを明示する。

レスポンスのactionはNONEまたはGUARDRAIL_INTERVENEDになる。ただし、介入は常に全面ブロックを意味しない。PIIを匿名化する設定ではマスク済みテキストがoutputsに返り、ブロックした場合は設定済みの定型文が返るため、actionだけを真偽値へ変換せず、assessmentsとoutputsを方針に沿って処理する。

入口、引数、結果で同じ関数を使っても、同じGuardrail設定を共有する必要はない。外部検索の結果には禁止内容とPIIを調べる出力用設定、特定ツールの引数には送信を認めない情報を定義した入力用設定というように、ツール名とデータの方向でGuardrailを割り当てる。対象外のツールはAPIを呼ばずに早期終了できる。

遅延を抑える配置表と失敗時の方針

実装順は、検査の重さではなく、データが越える境界と失敗時の影響から決める。外部へ変更を加えるツールではBeforeToolCallEventを優先し、信頼できない内容を返すツールにはAfterToolCallEventを加える。呼び出し前から外部データが会話へ入る構成では、BeforeInvocationEventも最初から必要になる。

• 受信内容：禁止トピック、PII、コンテンツ方針をGuardrailsで評価し、違反時は呼び出しを取消または安全な入力へ置換する。
• ツール引数：スキーマ、型、範囲、許可リスト、正規表現を先に実行し、文脈依存の文字列だけをGuardrailsへ送る。違反時はツールを取り消す。
• ツール結果：外部由来のテキストをGuardrailsで評価し、違反時は元データを残さないエラー結果または匿名化済み出力へ置換する。

複数のコールバックを同じイベントへ登録する場合、After系イベントは既定で登録順と逆に実行される。正規化、検査、置換、監査の順序に依存するなら、優先度を明示するか、一つのコールバック内で処理順を固定し、後段が未検査の値を利用しないようにする。

最後に、通常入力だけでなく、ネストした引数、複数のテキストブロック、空の結果、ツール例外、ApplyGuardrailのタイムアウトも試験する。外部評価に失敗した際に処理を止めるか、読み取り専用など限定機能で継続するかは、ツールの副作用とデータ機密性に応じて先に決める。3地点の目的は検査回数を増やすことではなく、危険なデータが次の信頼境界を越える前に止めることだ。