第4章 — AIエージェントとツール呼び出し

LLM Primer V: 実運用のLLMアプリケーションを設計する を章ごとに紹介していくウォークスルー、第4回。エージェントを、スキーマ・メモリ層・マルチエージェント配線を工学的に組み立てられて初めて信頼して現実に触れさせられる「ツールに対してループする言語モデル」として扱う回です。

なぜこの章があるのか

テキストを入れてテキストを出すだけの状態を持たないモデルは電卓です。本番の仕事では、それを複数ステップにわたって目標を追う行為者に変える必要があります — このツールを呼び、次にあのツールを呼び、どの結果をユーザーに要約するかを決めて、タスクが終わったら止まる。図の上では簡単そうに見えて、現実では簡単ではありません。エージェントはさまよい、ループし、間違ったツールを呼び、ツールが受け付けない引数を捏造し、すでに取ってきたものを忘れ、権限外に手を出します。第4章は、そのループを可読で、境界の効いた状態に保つ工学 — スキーマ、メモリ規律、マルチエージェント構造 — の話です。もっともらしく見えるデモを、本番の行為者に変えるものは、これらです。

4.1 選択ではなく構成としてのエージェントアーキテクチャ

ベースのループはReActです — 状況を推論し、ツールを呼んで行為し、結果を観察し、目標達成か手数予算尽きまで繰り返す。本番システムは、その上に3つの拡張を、選ぶのではなく重ねます。ネイティブなファンクションコーリング — プロバイダがデコード時にツール引数をJSON Schemaに合わせる — はI/O契約を硬化させ、ループは不正な呼び出しから復旧する必要がなくなります。明示的な計画立案、Plan-and-Executeスタイルは、長い時間軸のタスクに対して先に計画を出しておき、世界が変わったときだけプランナを再実行します。ワークフロー編成は、タスクの既知の遷移をグラフとして書き下し、フェーズ内の判断だけをモデルに任せます。これはエンタープライズ配備が最も収束する形で、既知なものと判断が要るものを分離するからです。反省ループ、コスト階層のフリートを跨ぐマルチモデルルーティング、専門特化のサブエージェントも、そのさらなる拡張として並びます。

4.2 ツール呼び出しのメカニクス — スキーマは契約である

すべてのツールにはスキーマがあり、そのスキーマがループがモデルに強制する契約です。プロパティレベルの説明は人間の読み手のためではなく、モデルへのドキュメントです。ドメインが許すところではenumで引数空間を閉じ、冪等性キーはループがツール呼び出しをリトライしても効果を二重に出さないためのものであり、構造化されたリトライ可能エラーは、モデルが推測ではなく綺麗に復旧できるようにするためのものです。ツールは最小に保つべきです — 1つのツールに1つの明確な仕事 — なぜなら10個のオプションフラグを持つ肥ったツールは、モデルが間違えるツールだからです。ask_user ツールは明示的にカタログに入れておくべきです。エージェントには曖昧さを引数の捏造ではなくエスカレーションで解消する正規の道が必要だからです。並行実行が安全なのはツールが独立性を宣言しているときだけで、ループは独立を宣言されたツールだけを並列化可能に、それ以外は厳密に逐次として扱います。「エージェントが間違ったことをした」に辿り着くほぼすべての本番障害は、引数の意味を書いていないツールスキーマに帰着します。

4.3 メモリの3層 — 短期・長期・意味

エージェントにはメモリが要ります。タスクが1ターンで収まることは稀だからです。短期メモリは最近の会話の上の滑走窓に、その滑走を生き延びるピン止めメッセージ — システムプロンプト、現在の目標、進行中の計画 — と、窓から落ちた実行の定期的な要約が組み合わさったものです。長期メモリは、あらゆる観察ではなく確認された事実に対して書き出される、キュレーションされた事実のベクタストアで、開始時だけでなくループの複数点で参照されます。意味メモリは、類似ではなく構造的な合成が必要なクエリ — 「誰が誰に報告するか」「どの製品がどのカテゴリに属するか」、ベクタストアが平坦化してしまう関係 — 向けのトリプルの知識グラフです。3つが別々に保存されているのは、別々に使われるからです。規律は、書き込みと読み出しを適切な層にルーティングすることで、すべてを一つの埋め込みインデックスに畳み込まないことです。

この章を踏まえて

エージェントもRAGも、確率的なトレースを生みます。ユーザーが苦情を上げ、ログには3つのツールと8つのモデル呼び出しに広がる100個のスパンが並び、チームはその失敗が検索の回帰なのか、プロンプトのドリフトなのか、ツールスキーマの問題なのか、それとも壊れた下流システムに対してエージェントが正しく判断した結果なのかを決めなければなりません。その問いは、トレースを測定可能な合否シグナルに変える規律なしには答えられません。第5章はその規律です — LLM-as-judge、RAG Triad、エージェント向けの軌跡テスト、そして本番のトレースが次リリースを門番する評価セットを養う継続的なループ。

次回 — 第5章: LLMアプリケーションの評価。 確率的なトレースを、チームがそれを目安に出荷できる合否シグナルに変える評価の規律。