AIエージェント向けツール設計の好ましい方法

AIと人間の回答の差は、多くの場合、知能ではなく詳細さに起因する。実際のデータに基づく明確で具体的な回答は、流暢な推測よりもはるかに優れている。よりスマートなモデルも役立つが、適切に設計されたツールこそがその差を埋める鍵である。

本稿では、エージェント向けツール設計において私が効果的だと考えるアプローチを概説する。唯一の方法ではないが、さまざまなエージェントで有効性が確認されており、私の好む方法である。

ツールが重要な理由

エージェントは生データをそのまま処理するのではなく、提供されたデータインターフェースを通じて動作する。ツール名、説明、パラメータは毎回モデルの判断を形成する。以下に、発生しうる具体的な失敗モードをいくつか挙げる：

• 曖昧なツールは不明瞭な判断を招く。同じ質問に答えられるツールが2つあると、エージェントは推測せざるを得ず、かなりの頻度で誤った選択をする。

• 説明が不十分だとツールが使用されない。説明はエージェントがツールを呼び出す唯一のガイダンスである。

• 粒度はトレードオフである。生のSQLを受け入れるツールは、モデルに精度の負担をかけ、不良なクエリを誘発する。オブジェクトタイプごとに1つのツールを持つのは良いが、50タイプを超えると、エージェントは毎回非常に類似したオプションから選択せねばならなくなる。万能の粒度はなく、特定のドメインに依存する。

例えば、get_opportunityとget_opportunity_healthというツールを考える。データモデルを理解している人間には明確な違いでも、モデルには同じように見える。これにより予測不能な呼び出しが発生し、ユーザーが要求したヘルス更新が欠落することもある。通常の修正方法は、2つのツールを統合するか、明確に名前を変更することである。

ツールが多ければ良いとは限らない

エージェントが何かを見落とすと、新しいツールを追加したくなる。しかし、この本能には限界がある。Anthropicのツール使用ドキュメントによると、Claudeのツール選択精度は、ツール数が約30～50を超えると低下する。それを超えると、新しいツールはエージェントの注意を奪い合い、能力を拡張するどころか妨げる。目標は、実際の質問に効果的に対処できる最小限のツールセットを持つことである。

ツール設計は、意図的かどうかにかかわらず、エージェントの実際の知能の大部分が存在する場所である。

ツールの前にシステムプロンプトから始める

強力なシステムプロンプトなしに効果的なツールを作成することはできない。プロンプトは、エージェントの役割、操作するドメイン、想定される質問を定義する。ツールはこの目的に奉仕するものであり、その逆ではない。

このステップを省略すると、肥大化を招く。「Salesforceデータのユーザーを支援する」のような曖昧なプロンプトは、スキーマ内のすべてが関連しているように見せる。具体的なプロンプト、例えば「収益チームがリスクのあるパイプラインを特定し、アカウントの変更を説明するのを支援する」は、何が重要かを即座に明確にする——リスクシグナルと変更履歴であり、汎用的なCRUD操作ではない。適切に定義されたプロンプトは、ほぼ自動的にツールの境界を設定するが、それが具体的でなければ効果はない。

ツールが存在すべきかを判断する方法

技術的な詳細は脇に置こう。目標は単純である：ユーザーの質問に対して、エージェントがどのツールを使うべきかを正確に知っていることだ。

有用なテストはこれである：このツールが答える質問で、他のツールが同じように答えられないものは特定できるか？ できないなら、まだ追加すべきではない。実際の質問が必要性を示すのを待つ。「スキーマにあるから」や「エンドポイントがあるから」といった理由は十分ではない。そのような理由で追加されたツールは、結局使われないか、後で衝突する。

エージェントを使ってツールを設計する

私たちのプロセスで驚くべき点は、エージェントのツールを構築するためにエージェントを使っていることだ。

しっかりしたシステムプロンプトと適切な例示質問ができたら、それらをデータ構造（JSONスキーマ、DBスキーマ、API仕様など）とともにLLMに提供し、それらの質問に答えられるツールを提案するよう依頼する。

これが有効なのは、設計を行うモデルが最終的にツールを使用するエージェントと同じように考えるからである。意思決定プロセスをシミュレートするため、人間がスキーマだけから設計する際に見落としがちな曖昧さやギャップを特定しやすい。

簡単な例。

Salesforceを扱うRevOpsエージェントがあり、プロンプトはパイプラインの健全性とアカウントリスクに関するもの、質問は「今四半期リスクのある取引は？」「Acme Corpで最近何が変わった？」「このオポチュニティのステージが変わった理由は？」とする。妥当な初回ドラフトは以下を含む：

• get_pipeline_risk_signals(owner, quarter) — 停滞時間、ステージ後退、または次のステップの欠落によりフラグが立てられた取引

• get_account_activity(account_id, since_date) — フィールド変更、メール、会議のタイムライン

• get_field_change_history(object_id, field_name) — 特定フィールドの監査証跡

特に、3番目の質問はフィールドレベルの履歴の必要性を強調しており、アカウントレベルのアクティビティとは異なるルックアップである。スキーマのみから設計すると、get_account_activityがこれもカバーすると誤って仮定するかもしれないが、テストでそうでないことが明らかになる。

実装し、実際にテストする

2種類の質問を使用する：ツールが設計された質問（即座に動作するはず）と、エージェントが未経験の新しい質問（これが本当のテストであり、ツールが汎化できるか、単なるルックアップテーブルを構築したに過ぎないかを明らかにする）。

エージェントがどのように答えにたどり着くかに注目し、単に正しいかどうかだけではない。3つの潜在的なエラーがある：誤ったツールを使用、正しいツールだがパラメータが誤り、または1つの適切に設計されたツールで十分なのに複数のツールを連鎖させる。各エラーは異なる修正（説明、パラメータ、粒度）を示すので、すべてを「エージェントが間違えた」とひとくくりにしない。

間違ったときは、エージェントに理由を聞く

ツールを修正して先に進むのではなく、エージェントに何が正しい答えを導く助けになったかを尋ねる。エージェントは、隣接するツールの説明が不明瞭、パラメータに例が必要、2つのツールを統合すべきなど、問題を正確に特定できることが多い。エージェントは意思決定プロセスに対する直接的な洞察を持っており、後でトランスクリプトを読むだけでは得られない。

性能が安定するまで反復する

サイクル（実装、既知および新しい質問のテスト、エージェントの支援による診断、改良）を、単なる感覚ではなく実際の基準に達するまで繰り返す。各ラウンドで新しい質問セットに対する「正しいツール、正しいパラメータ、正しい答え」の割合を追跡する。その割合が安定したら、完了である——エージェントが完璧だからではなく、ツール設計の問題に遭遇しなくなり、孤立したエッジケースだけが残るからだ。これはより小さな問題である。

このプロセスは一度きりの設計ではない。API仕様を書くよりも製品の反復に似ている：リリースし、実際の動作を観察し、改良する。重要な違いは、そのプロセスにおける最も価値ある設計パートナーがエージェント自身であることだ。