8月27日、Towards Data Scienceが「Stop Giving Your AI Agent a Search Box and Start Giving It Typed Tools, Hard Bounds, and a Gate It Cannot Talk Past」と題した記事を公開した。AIエージェントに汎用検索ではなく型付きツール・ハードバウンド・ガバナンスゲートを与えることで、固定パイプラインでは解けない多段推論を実現できるかを実験で検証した内容だ。本稿はシリーズ第3弾にあたり、Part 1・Part 2で構築したナレッジレイヤーの上にエージェントループを乗せた場合に何が変わるかを、同一コーパス・同一Azureスタックで測定した実践報告である。
「エージェントに検索ボックスを渡す」のが間違いな理由
AIエージェントの実装において、「ツールとしてベクトル検索を渡してループさせる」というパターンが広まっている。しかしこのアプローチには根本的な問題がある。エージェントの推論は、与えられたツールの語彙によって上限が決まるからだ。
vector_search(query) しかツールがなければ、クエリをどれだけ言い換えて再試行しても、毎回フラットなベクトル空間への類似度検索にすぎない。反復がもたらすのは「別の言葉で書かれた同じ推測」であって、新しい知識の獲得ではない。
固定パイプラインの「天井」を具体的に示す
前回（Part 2）では、すべての質問に対して同じ順序で同じステージが走る固定パイプラインを構築した。ハイブリッド検索（キーワード検索とベクトル検索の融合）と2ホップの型付きグラフ走査を組み合わせ、外部リランカーで並べ替える設計だ。エンティティの断片化は同一文書で149概念から120概念へ削減され、矛盾検出器はシード時に自動で発火した。
ただし、この固定パイプラインには構造的な限界がある。検索計画は推論が始まる前に凍結される点だ。
記事ではこれを保険の査定業務を題材に具体化している。屋根点検の基準が「2025年6月時点で20年超」→「2026年3月から新規H3案件は15年超」へと段階的に変更された状況で、次の質問を投げる。
「記録された保険請求の中に、3月の新基準では引っかかっていたが、実際に請求が申請された時点の旧基準では通過していた物件はあるか？」
これに答えるには順序が必要だ。まず二つの基準と有効期間を把握し、次に各請求ファイルから物件属性を抽出し、旧基準が適用されていた請求に3月の新基準を反実仮想的に適用して比較する。第2の検索（どの請求ファイルを引くか）は、第1の検索結果を理解した後でないと決まらない。 固定パイプラインではこの依存関係を表現できず、不完全なグラウンディングのまま「答えが出たように見える」回答を生成してしまう。
図1：固定パイプラインの天井。検索十分性は推論前に一度だけ判定される。赤の破線矢印がアーキテクチャ上できない操作。（画像：元記事より）
研究文献ではこの「推論と行動を交互に実行する」アプローチをReActと呼ぶ。エージェントブームの核心にあるアイデアだが、記事はその「使える部分」と「ノイズ」を分けることに慎重だ。
8つの型付きツール、1つのコントラクト
記事の主張の核心は「エージェントに渡すツールが推論の上限を決める」という点にある。そのため設計では、汎用の検索ボックスではなく8つの型付きツールをエージェントに与えた。各ツールは以下のように、ナレッジレイヤーの語彙をそのままツールとして公開したものだ。
- ハイブリッド検索：キーワードとベクトルを統合したドキュメント検索
- 2ホップグラフ走査：エンティティ間の関係を2段階でたどるグラフ走査
- タイムライン取得：特定エンティティに関する時系列イベントの抽出
- 差分（Diff）比較：ポリシーや基準の新旧バージョン間の変更点抽出
- エンティティ解決：表記ゆれ・断片化された同一エンティティの統合
- 矛盾レジスタ参照：登録済みの矛盾・フラグ情報へのアクセス
各ツールは入力・出力の型が明示されたコントラクトを持ち、エージェントが「何をどう呼ぶか」を推論できる構造になっている。
エージェントのループ自体は意図的に80行程度で実装されており、フレームワークの複雑さに頼らず、境界（ハードバウンド）が可読な状態に保たれている。反復回数の上限やコスト上限などのハードバウンドはコードレベルで強制され、モデルが「トークン生成によって迂回できない」設計になっている。
最大の問いは「ガバナンスゲートはエージェントに突破されるか」
記事がもっとも重きを置いているのは、「エージェントが自律的にループを回すとき、矛盾ゲートは生き残るか？」という問いだ。
便利なエージェントは、ガバナンスが邪魔になった瞬間に都合よくルーティングをすり抜けようとする可能性がある。実験（refusal test）では、矛盾が登録された情報を含む質問を投げ、エージェントがゲートを無視して回答を生成するかどうかを検証した。結果として、矛盾ゲートはエージェントループを通じても機能し、モデルが「役に立とうとする」ために回答を生成してしまう現象は防がれた。
また同一システムで4つのモデルを使って比較実験も実施されており、モデルによるツール呼び出しの違いと精度への影響も測定している。
アブレーション実験の結果と「使ってはいけない場面」
同一コーパスで3種類の検索バックエンド（純ベクトル、グラフ付き固定パイプライン、エージェントループ）を比較するアブレーション実験も実施された。重要なのは、エージェントループが常に優れているわけではないという点を記事が明示していることだ。
なお、元記事におけるアブレーション実験の比較はいずれも定性的な評価にとどまっており、「純ベクトル比でF1が◯%向上」といった定量的な数値の記載はない。条件間の優劣はシナリオ別の動作観察と誤答パターンの分析によって示されている。
記事ではエージェントを使うべきでない場面として、以下を挙げている。
- 単純なファクト検索：1回の検索で答えが得られる質問
- 低レイテンシが必要なケース：ループのオーバーヘッドがSLAを超える場合
- コスト制約が厳しいケース：多段ループによるトークン消費が許容できない場合
固定パイプラインは「速く、安く、監査可能で、予測可能」であり、多段推論が不要な大多数の質問ではその方が適切だとする。エージェントが価値を発揮するのは、「最初の検索結果を見てから、次に何を取りに行くかが決まる」種類の質問に限られる。
インフラは既存スタックのみ、コストは「コードとトークン」
実装上の特徴として、新しいAzureリソースは一切追加されていない点が強調されている。エージェントはコードとトークン消費であって、インフラリソースではない。Azure AI Foundry上のFoundry Agent Serviceを利用しており、Part 2までのスタックにそのまま追加コミットとして乗っている。
コスト面については各エージェント実行あたりのトークン消費量も測定されており、固定パイプラインとの比較コストが報告されている（具体的な数値は元記事を参照）。
「エージェントに何を渡すか」という設計の問いを、実装と実験で検証した構成は、RAGの次の一手を探しているエンジニアにとって参照価値が高い。詳細はStop Giving Your AI Agent a Search Box and Start Giving It Typed Tools, Hard Bounds, and a Gate It Cannot Talk Pastを参照していただきたい。
