AIエージェントのツール設計:有効なパターンと無効なパターン
本記事では、AIエージェントのツール設計における重要なパターンを分析し、ほとんどのエージェント障害はモデル能力ではなくツール設計の欠陥に起因すると論じています。単一責任ツール、タイトなスキーマ、スコープを定義する説明、構造化エラー返却、冪等性などの効果的な実践を紹介し、未フィルターAPIのラッピング、全ツールのコンテキストへのロード、暗黙的な部分成功などの一般的な落とし穴について警告しています。
AIエージェントシステムにおいて、ツール設計はしばしば軽視されるが、成功を左右する重要な要素である。多くのエージェント障害は一見モデルのミスに見える——間違ったツールの選択、誤った引数の受け渡し、エラー処理の不適切さ——が、実際にはモデルは与えられたインターフェースを処理しているに過ぎない。問題の根源は多くの場合、ツール設計そのものにある。
モデルはツールインターフェースを通じて公開された情報のみから推論できる:ツール名、説明、パラメータスキーマ、パラメータ説明。これらの詳細が、モデルが意図を解釈し、アクションを計画し、タスクを実行する方法を形成する。ツール設計が不明瞭、不完全、または構造が緩い場合、障害は偶然ではなく予測可能になる。
有効な設計パターン
まず、単一責任ツール。ツールは単一の明確な操作を表すべきである。アクションパラメータを通じて複数の動作を処理する場合、モデルは実際のタスクを解決する前にどのモードを呼び出すかを判断しなければならない。単一責任ツールはモデルに明確な機能を提供し、よりクリーンなエラー処理と観測可能性をもたらす。ただし、このルールは絶対ではなく、シェル、ファイルシステム、ブラウザ、カレンダーツールなどの一部の領域では、制約付きのマルチアクションインターフェースが適している場合もある。
次に、タイトなスキーマ。ツール呼び出しエージェントでは、モデルはスキーマから推論して引数を構築する。緩いスキーマはモデルに制約の推測を強いるが、タイトなスキーマは制約をエンコードするため推論は不要になる。特に、有効な値のセットが小さいフィールドには列挙型が有用で、もっともらしく見えるが実際には無効な出力のクラスを排除する。
第三に、範囲を定義する説明。ツール説明はモデル向けのドキュメントであり、いつ使用するかだけでなく、いつ使用しないかも説明する必要がある。弱い説明は機能のみを説明するが、強い説明は目的、範囲、境界、および他ツールとの区別を定義し、モデルが誤った選択をするのを防ぐ。
第四に、構造化されアクション可能なエラー返却。ツールが失敗した場合、モデルはエラーを読み取り次のアクションを決定する。未処理の例外やスタックトレースはノイズ主導の後続動作を引き起こす。構造化エラーは何が失敗したかを報告するだけでなく、エージェントが次に何をすべきかを示す。回復可能フラグと推奨アクションフィールドが重要であり、これらはエージェントの動作を変え、回復不可能なエラーでの再試行や回復可能なエラーの放棄を防ぐ。
第五に、冪等な状態変更操作。状態を変更するすべてのツール(レコード作成、メッセージ送信、資金移動など)は、2回呼び出されても安全でなければならない。エージェントは再試行し、ネットワークは失敗し、LLMループは最初の確認が届かなかったために2回目の呼び出しを発行する可能性がある。すべての書き込み操作に冪等キーを要求することで、重複した副作用を防ぐことができる。
無効な設計パターン
最初の一般的な失敗は、未フィルターのAPIをそのままラップすることである。REST APIをツールとして直接公開することは一般的な近道であるが、本番環境での障害の主要な原因でもある。APIは通常、エージェントが必要とする以上の詳細を公開し、応答には数百のフィールドが含まれ、ページネーションに依存し、意味不明な内部IDを使用し、深いドメイン知識が必要なエラーコードを返す。専用のラッパーはページネーションを内部で処理し、必要なフィールドのみを投射し、APIエラーを構造化エラー形式にマッピングすべきである。ただし、過剰なラッピングも有害であり、ツール表面が断片化する可能性がある。目標は最大の抽象化ではなく、一貫性のあるエージェントフレンドリーな抽象化層である。
2つ目の失敗は、すべてのツールをすべてのコンテキストにロードすることである。ツールカタログが成長するにつれて精度は低下する。128Kコンテキストウィンドウをサポートするモデルでも、ツールカタログのサイズが増加するとパフォーマンスが大幅に低下することが研究で示されている。動的ツールローディングはこの問題を解決する:現在のステップに必要なツールを特定し、それらのみを含めることで、選択精度を向上させ、呼び出しごとのトークンコストを削減する。
3つ目の失敗は、暗黙的な部分成功である。ツールが要求された作業の一部のみを完了し、完全に成功したように見える応答を返す場合に問題が発生する。エージェントは不完全または誤解を招くシステム状態のまま実行を続ける。これは通常、ツールが内部の失敗を抑制し、成功部分のみを返す場合に起こる。正しい方法は、部分成功を明示的に報告し、成功項目と失敗項目を含め、モデルが分岐できるようにすることである。
これらの設計パターンを採用し、一般的な落とし穴を回避することで、AIエージェントシステムの信頼性と効果を大幅に向上させることができる。