この記事は、記事が「ハルシネーションによる操作成功」と呼ぶ失敗を取り上げる。これは、実際にはビジネスルールに違反した操作を、エージェントが完了したと報告するものである。具体例は、ホテルの予約を確定するよう依頼された旅行予約エージェントである。このエージェントは confirm_booking(booking_id="BK001") を呼び出し、支払いが検証されていないにもかかわらず「SUCCESS」を返す。ツール自身の docstring には支払いを先に検証しなければならないと書かれており、モデルはそれを読んだうえでそのまま処理を進めたのである。
記事の診断は、プロンプトの質の問題ではなくアーキテクチャの問題だというものである。プロンプトはモデルが解釈するテキストであるため、docstring やシステムプロンプトで述べられたビジネスルールは、モデルが呼び出しのたびに判断し直す提案になってしまう。記事が提案する対策は、強制をモデルの外に移すことである。エージェントフレームワークに登録されたフックが、ツールの実行前に決定論的なルールを評価し、ルールが満たされなければ呼び出しをキャンセルする。そのためモデルは、覆す手段のないキャンセルを受け取ることになる。記事はこの組み合わせを、ニューラルな LLM の推論と決定論的な記号的ルールを組み合わせたニューロシンボリックなものとして位置づけ、この枠組みを引用している研究に帰している。
デモでは Strands Agents とその BeforeToolCallEvent フックを使っており、フックだけが唯一の変数になるように構成されている。すなわち、ツール・モデル・プロンプトが同一で、hooks=[hook] という引数 1 つだけが異なる 2 つのエージェントである。記事は、同等のインターセプトが他のエージェントフレームワークにも存在することを指摘し、LangGraph のノードガードと AutoGen のリプライ関数を挙げている。
要点
- エージェントは、ビジネスルールに違反した操作について成功を報告することがあり、デモのベースラインのエージェントには、そうしたことを検知する仕組みがない。完全な確信をもって成功を返すのである。
- docstring やシステムプロンプトに置かれたビジネスルールは、モデルが解釈するコンテキストであって制約ではない。モデルは呼び出しのたびにそれに従うかどうかを決める。
- 記事は、プロンプトエンジニアリングでは防げないとする 3 つのハルシネーションのパターンを挙げている。パラメータの誤り（docstring が禁じている値でツールを呼び出す）、完全性の誤り（必要な前提ステップを経ずに実行する）、そしてツール迂回の振る舞い（必須の検証ツールを呼び出さずに成功を主張する）である。
- 実行前のフックに置かれた強制は、フックがモデルの外で動作するため、モデルが覆すことはできない。記事が述べる対比は、プロンプトは LLM への入力であるのに対し、フックはフレームワークレベルのインターセプターだというものである。
- 実行前にキャンセルするということは、ロールバックすべき完了済みの操作がなく、補償トランザクションも不要だということである。
- 素の関数として書かれたルールは、エージェントやモデルの呼び出しとは独立にテスト・監査でき、検証をツール定義のあちこちに散らばらせる代わりに、1 つのフックですべてのツールを検証できる。
- 記事は、このアプローチの限界を自らの言葉で挙げている。保護する操作ごとにルールを書く必要があること、ルールはブール値であり曖昧なロジックや確率的なロジックを表現できないこと、エッジケースには明示的な対処が必要なこと、そしてビジネスロジックの変化に合わせてルールを保守する必要があることである。
- 記事の中心的な結果は「無効な操作 3/3 をブロック」、偽陽性ゼロ・偽陰性ゼロと述べられている。具体的なシナリオは 3 つだが、その内訳は 2 つの無効なケース（支払いのない確定と、宿泊人数の上限を超える予約）と、両方のエージェントが実行する 1 つの有効な予約である。フック付きのエージェントは無効なケースを両方ともブロックし、有効なケースには何の摩擦も加えない。
背景
この記事は、エージェントのハルシネーションに関するシリーズの Part 3 と位置づけられており、DEV Community の AWS 組織の下で公開され、元は AWS のビルダー向けサイトに掲載されたものである。その推奨は一般的なものではなく範囲が限定されている。予約・支払い・キャンセルといった重要でリスクの高い操作に対してフックを定義し、監査のためにルール違反のたびにツール名・パラメータ・理由を記録するよう勧めている。デモと推奨は同じ著者によるものであり、本番のワークロードではなく専用に作られた例に基づいているため、報告された結果は、このパターンを裏付ける独立した証拠というよりも、パターンの具体的な例示として読むべきものである。