この記事は、エージェントのためのツールは関数や API とは種類の異なるソフトウェア成果物であり、それに応じて設計すべきだと論じている。従来のソフトウェアは決定論的なシステム同士の契約を確立する — 記事の例では、ある都市を指定した getWeather の呼び出しは毎回同じ方法で天気を取得する — のに対し、ツールは決定論的なシステムと非決定論的なシステムとの間の契約である。傘を持っていくべきかと尋ねられたエージェントは、天気ツールを呼び出すかもしれないし、一般知識から答えるかもしれないし、まず場所について確認の質問をするかもしれないし、ハルシネーションを起こしたりツールの使い方を理解できなかったりするかもしれない。そこから導かれる帰結として、ツールや Model Context Protocol サーバーは、他の開発者やシステム向けに関数や API を書くのと同じやり方で書くべきではなく、エージェント向けに設計する必要があると述べられている。
記事が提案する方法は、評価駆動かつ協働的なものである。ツールのプロトタイプを作って自分で使ってみる、現実的なタスクから評価を構築する、そして評価のトランスクリプトを Claude Code に貼り付けて分析させ、ツールをリファクタリングさせる。著者らによれば、記事の助言の大半は、Anthropic 社内のワークスペース上に構築した評価に対して、自社の内部ツールをこの方法で繰り返し最適化する中から得られたものであり、ホールドアウトのテストセットでは、研究者が手作業で書いたものであれ Claude 自身が生成したものであれ、「エキスパート」による実装を上回る性能が明らかになったという。
後半では 5 つの原則が抽出される。どのツールを作るかの選定、ツールの名前空間化、意味のあるコンテキストを返すこと、トークン効率のためのレスポンス最適化、そして説明文のプロンプトエンジニアリングである。
要点
- ツールは決定論的なシステムと非決定論的なエージェントとの間の契約として位置づけられ、記事はこれを、エージェント向けツールを他の開発者やシステム向けに書かれた関数や API とは異なる形で設計する必要がある理由としている。
- 掲げられている目標は、エージェントが幅広いタスクを効果的に解決できる領域を広げることであり、著者らは、エージェントにとって最も使いやすいツールは、人間にとっても驚くほど直感的に理解しやすいものになると報告している。
- 評価タスクは、単純なサンドボックス環境ではなく、実際の利用と現実的なデータソースに基づくべきである。記事によれば、良いタスクは複数の、場合によっては数十回のツール呼び出しを必要とすることがある。良い例として挙げられているのは、解約しようとしている特定の顧客への引き留めオファーを用意するタスク — その顧客が離れる理由、どのようなオファーが魅力的か、どのようなリスク要因があるかを突き止める — であり、悪い例として顧客 ID で解約リクエストを検索するようなタスクが対比されている。
- 各評価プロンプトには検証可能な回答または結果を対にすべきであり、その方法は文字列の完全一致比較から Claude を判定役として用いるものまで幅がある。記事は、書式、句読点、あるいは妥当な別の言い回しを理由に正しい回答を不正解とする厳しすぎる検証器や、複数の妥当な経路がありうるにもかかわらずエージェントが呼び出すべきツールを過度に指定することに注意を促している。
- 評価は、LLM API 呼び出しとツール呼び出しを交互に行う while ループという単純なエージェントループとして、タスクごとに 1 ループでプログラム的に実行することが推奨されている。また、エージェントにはツール呼び出しの前に推論とフィードバックのブロックを出力させるよう指示する。記事は、これが Chain-of-Thought 的な振る舞いを引き起こすことで実効的な知能を高める可能性があると示唆している。
- 最上位の正答率以外にも、ツール呼び出しとタスクの実行時間、ツール呼び出しの総数、トークン消費量、ツールエラーを収集することが推奨され、そこに現れるパターンが設計上のシグナルとして読み解かれる。冗長な呼び出しはページネーションやトークン上限パラメータの適正化を、不正なパラメータによるエラーはより明確な説明やより良い例を示唆する。
- エージェントのフィードバックに頼ることへの注意も述べられている。エージェントが省いたことのほうが、含めたことよりも重要な場合がある。記事は、エージェントが述べる推論だけでなく、生のトランスクリプト — ツール呼び出しとレスポンス — を読むよう勧め、評価エージェント自身が必ずしも正解を知っているわけではないと指摘している。
- ツールを増やせば常に良い結果になるわけではないとされ、よくある誤りとして、既存のソフトウェア機能や API エンドポイントを単にラップしただけのツールが挙げられている。その理由は、エージェントには従来のソフトウェアとは異なるアフォーダンスがあることである。エージェントのコンテキストは限られているため、すべての連絡先を返すツールはエージェントに無関係な連絡先まで読ませることになる。自然なやり方は関連する項目へ直接飛ぶことである。
- 推奨される代替策は、影響の大きいワークフローを対象とした、よく考えられた少数のツールと、複数の下位操作を統合したツールである。ユーザー一覧、イベント一覧、イベント作成を別々のツールにするのではなく、空き時間を探してイベントを予約するスケジューリングツール。生のログを読むツールではなく、関連する行だけを前後の文脈とともに返すログ検索ツール。3 つの別々の検索ではなく、単一の顧客コンテキストツール、といった例が挙げられている。
- ツールの名前空間化 — 関連するツールを、サービス単位やリソース単位で共通の接頭辞のもとにまとめること — は、エージェントが数十の MCP サーバーと数百のツールにアクセスできる場合に境界を明確に保つ方法として提示されている。記事によれば、接頭辞ベースと接尾辞ベースのどちらの名前空間化を選ぶかはツール利用の評価に無視できない影響を与え、その影響は LLM によって異なる。そのため、規則ではなく評価によって決めることが推奨されている。
- ツールのレスポンスはシグナルの強い情報だけを返し、柔軟性よりも文脈上の関連性を優先すべきであり、低レベルの技術的な識別子は避けて、エージェントの次の行動の判断材料になりやすいフィールドを選ぶべきだとされる。著者らは、任意の英数字からなる UUID を意味のある言葉に変換するだけで、あるいは 0 始まりの ID 体系にするだけでも、ハルシネーションが減ることで検索タスクにおける Claude の精度が大幅に向上したと報告している。
- 自然言語の出力と技術的な出力の両方が必要な場合、記事はエージェントが簡潔なレスポンスと詳細なレスポンスを選べるレスポンス形式パラメータを公開することを提案している。Slack の例では、詳細なレスポンスが 206 トークンであるのに対し簡潔なレスポンスは 72 トークンであり、簡潔なレスポンスでは後続の呼び出しに必要な識別子が省かれる。
- レスポンスの構造そのもの — XML、JSON、Markdown — も評価の性能に影響するとされ、万能の答えはないという。その理由として、次トークン予測で訓練されたモデルは訓練データに合致する形式でより良い結果を出す傾向があることが挙げられている。
- トークン効率のために、記事は妥当なデフォルト値を伴うページネーション、範囲選択、フィルタリング、切り詰めを推奨し、Claude Code はデフォルトでツールのレスポンスを 25,000 トークンに制限していると述べている。切り詰めやエラーのレスポンスはエージェントを誘導する機会として扱われ、エラーテキストは不透明なエラーコードやトレースバックではなく、具体的で実行可能な改善点を伝えるように書くべきだとされる。
- ツールの説明と仕様のプロンプトエンジニアリングは、ツールを改善する最も効果的な方法の 1 つとされている。推奨される姿勢は、チームの新人に説明するようにツールを説明すること — 暗黙のコンテキストを明示すること — と、入力パラメータに曖昧さのない名前を付けることである。
- 説明文の変更について、具体的な結果が 2 つ報告されている。1 つは、ツール説明を精密に改善した後に Claude Sonnet 3.5 が SWE-Bench Verified で最先端の性能を達成したことで、記事はこれによりエラー率が劇的に下がったとしている。もう 1 つは、Claude が Web 検索ツールのクエリパラメータに不必要に年を付け加え、それが結果に偏りを生じさせて性能を低下させていることにチームが気づいた後の修正である。
背景
この記事の根拠は Anthropic 自身の社内ツール — 社内ワークスペース上で評価された Slack と Asana の MCP サーバー — であり、ホールドアウトのテストセットで人間が書いた実装と Claude が最適化した実装を比較している。それらの比較は本文中に数値のないグラフとして示されているため、報告された改善の大きさはここでは確認できない。本文が述べているのは改善の方向性と、訓練用評価への過学習を防ぐためにホールドアウトのセットが使われたという事実である。
記事の推奨事項は、測定された知見としてではなく、著者らにとってうまくいったプラクティスとして述べられている。例外は具体的な結果を伴う 2 つで、ツール説明の改善に帰された SWE-bench Verified の結果と、UUID の変換が検索精度に与えた効果である。名前空間化に関する指針でさえ意図的に結論が開かれたままにされており、記事は接頭辞と接尾辞のどちらも推奨せず、読者自身の評価に従って選ぶよう伝えている。
締めくくりの論点は、ソフトウェア開発のプラクティスは予測可能で決定論的なパターンから非決定論的なパターンへと向きを変えなければならないこと、そしてエージェントが世界と関わる仕組み — MCP プロトコルや基盤となるモデル — は今後も変わり続けるということである。したがって著者らが永続的なものとして提示しているのは、特定のツール設計ではなく評価駆動のループである。