Writing effective tools for agents — with agents
Writing effective tools for agents — with agents
エージェントを使って、エージェントのためのツールを作る
ツールのプロトタイプを構築してテストする
エージェントと協力してツールの包括的な評価を作成し、実行する
Claude Codeのようなエージェントと連携して、ツールのパフォーマンスを自動的に向上させます。
高品質なツールを作成するための重要な原則
実装する（または実装しない）適切なツールを選択する
機能の明確な境界を定義する名前空間ツール
ツールからエージェントに意味のあるコンテキストを返す
トークン効率のためのツール応答の最適化
プロンプトエンジニアリングツールの説明と仕様
https://scrapbox.io/files/68f48a7b1e6ef84fdce0cdc9.png
ツールとは
コンピューティングでは
決定論的システム
同じ入力なら同じ出力
非決定論的システム
エージェントなど
同じ開始条件でも様々な応答
従来
決定論的なシステム
今
ツールは、決定論的なシステムと非決定論的なエージェント間の契約を反映する新しい種類のソフトウェア
根本を考え直す
プロトタイプの構築
API, SDK, ドキュメントをClaude Codeに渡すのは良さげ
評価の実行
結果を分析してツールの改善点を見極める
参考
評価タスクの生成
強力な評価タスクをやろう
例
来週、ジェーンとのミーティングを予定し、Acme Corpの最新プロジェクトについて話し合いましょう。前回のプロジェクト計画ミーティングのメモを添付し、会議室を予約してください。
顧客ID 9182から、1回の購入試行に対して3回請求されたという報告がありました。関連するログエントリをすべて確認し、他の顧客も同じ問題の影響を受けているかどうかを確認してください。
顧客のSarah Chenが解約リクエストを送信しました。リテンションオファーを準備してください。(1) 顧客が退会する理由、(2) 最も魅力的なリテンションオファー、(3) オファーを出す前に考慮すべきリスク要因を検討してください。
以下は、それほど強力ではないタスクです。
来週、jane@acme.corp との会議をスケジュールします。
支払いログでpurchase_completeおよびを検索しますcustomer_id=9182。
顧客 ID 45892 でキャンセルリクエストを見つけます。
各評価プロンプトには、検証可能な回答または結果が組み合わされている必要があります。
検証方法は様々
正解とサンプル回答の文字列を正確に比較するだけのシンプルなものから、
Claudeに回答の判断を依頼する高度なものまで
過度に厳格な検証方法は避けてください。
書式、句読点、有効な代替表現といった不自然な違いを理由に正しい回答を拒否するなど
各プロンプトとレスポンスのペアについて
想定されるツールをオプション指定する
これによって、正しく理解されてるかを測定できる
ただし、解決の有効なパスが複数存在する可能性もある
評価の実行
評価はLLM APIを直接呼び出してプログラム的に実行すると良い
シンプルなループwhileのようなもの
評価タスク一つごとに１ループ
単一のタスクプロンプトとツールを渡す
評価エージェント
これ自体のシステムプロンプト
構造化された応答ブロック（検証用）
こっちも出力するよう指示しよう
推論ブロック
フィードバックブロック
Interleaved thinking を使うと
ツールの使用理由、使用しない理由を探って、
ツールの説明や仕様における改善点を特定しやすくなる
測定しよう
精度だけでなく
個々のツール呼び出し、
タスクの合計実行時間、
ツールの呼び出し合計回数
トークン消費量の合計
ツールエラー
結果の分析
エージェントとの連携
結果の分析自体もエージェントにやらせる
以上から学んだ原則
エージェントに適したツールの選択
コンテキストは限られている
例
アドレス帳で連絡先を検索するタスク
従来のソフトウェアは連絡先リストを舐めれる
LLMはコンテキストを食うので良くない
総当りは良くない
人間と同様に、アルファベット順でスキップする
思慮深いツールをいくつか構築するとよい、
評価タスクに適した、
影響の大きい特定のワークフローを対象としたもの
そこからスケールアップしていくことをお勧めします。
アドレス帳のケースでは、
ツールではなく、
search_contactsや
message_contactlist_contactsを実装することを選択するかもしれません。
例
list_users、、list_eventsおよびcreate_eventツールを実装する代わりに、schedule_event空き時間を見つけてイベントをスケジュールするツールを実装することを検討してください。
ツールを実装する代わりにread_logs、search_logs関連するログ行と周囲のコンテキストのみを返すツールを実装することを検討してください。
get_customer_by_id、、list_transactionsおよびlist_notesツールを実装する代わりに、get_customer_context顧客の最新の関連情報をすべて一度にまとめたツールを実装します。
ツールの名前空間
名前の重複よくない
prefix,suffixも影響する
例えば、ツールをサービス別（例：asana_search、jira_search）やリソース別（例：asana_projects_search、asana_users_search）に名前空間を設定すると、エージェントは適切なタイミングで適切なツールを選択できるようになります
ツールから意味のあるコンテキストを返す
低レベルの技術識別子（例：uuid、、 ）は避けるべきです。 256px_image_url、、などmime_typeのフィールドはname、エージェントの下流のアクションやレスポンスに直接影響を与える可能性がはるかに高くなります。image_urlfile_type
xml,json, markdownも評価パフォーマンスに影響する
万能の解決策はない
LLMによる
トークン効率のためのツール応答の最適化
大量のコンテキストを消費する応答は
デフォルトパラメータでページ区切り
範囲選択、フィルタリング
ツールの説明をプロンプトエンジニアリングする