この記事は「AI エージェントのためのツールをどう設計すれば効果的か」について、Anthropic 社のエンジニアが実践的なノウハウをまとめたものです。さらに面白いことに、Claude 自身を使ってツールを改善する方法も紹介しています。
従来のプログラミングでは、関数は 決定論的（deterministic） に動作します。
getWeather("東京") → 常に同じ方法で東京の天気を取得
しかしAIエージェントは**非決定論的（non-deterministic）**です。同じ質問をしても、毎回異なるアプローチを取る可能性があります。
例えば「今日傘を持っていくべき？」と聞かれたとき、エージェントは以下のどれかを選ぶかもしれません。
ツールとは、決定論的なシステム（従来のソフトウェア）と非決定論的なエージェント（AI）の間の「契約」 です。
これは従来の API 設計とは根本的に異なる発想が必要になります。開発者向けに API を書くのではなく、AI エージェント向けに設計する必要があるのです。
まずは素早くプロトタイプを作成します。
ポイント
llms.txt という形式のLLM向けドキュメントがある場合は活用するテスト方法
「どれくらいうまく動くか」を測定するために評価を行います。
良い評価タスクの例
✅ 良い例：
「来週Janeとミーティングを設定して、前回のプロジェクト会議のメモを添付し、
会議室を予約してください」
❌ 悪い例：
「jane@acme.corpと来週ミーティングを設定して」
良い評価タスクの特徴は、複数のツール呼び出しが必要で、現実世界の複雑さを反映していることです。
評価の実行方法
ここが面白いところです。Claudeに評価結果を分析させ、ツール自体を改善させることができます。
実際に Anthropic では、この方法で人間が書いたツールよりも 性能が向上した と報告しています。
「とりあえず全部ツール化」は逆効果です。
例えば「連絡先を検索する」タスクを考えてみましょう。
❌ 悪い設計：
list_contacts → 全連絡先を返す → エージェントが1つずつ読む
✅ 良い設計：
search_contacts("田中") → 該当する連絡先だけを返す
エージェントのコンテキスト（処理できる情報量）は限られています。人間が電話帳を最初から順番に読まないように、エージェントも効率的に情報にアクセスできる設計にすべきです。
実践的なアドバイス
| 悪い設計 | 良い設計 |
|---|---|
list_users + list_events + create_event |
schedule_event（一括で処理） |
read_logs |
search_logs（関連するログだけ返す） |
get_customer_by_id + list_transactions + list_notes |
get_customer_context（全情報をまとめて返す） |
エージェントは何百ものツールにアクセスする可能性があります。似た機能のツールがあると混乱します。
✅ 良い命名：
asana_projects_search
asana_users_search
jira_projects_search
jira_users_search
❌ 曖昧な命名：
search_projects
search_users
project_search
プレフィックス（接頭辞）やサフィックス（接尾辞）を使って、ツールをグループ化しましょう。
ツールの戻り値はエージェントにとって有用な情報に絞りましょう。
❌ 技術的すぎる戻り値：
{
"uuid": "550e8400-e29b-41d4-a716-446655440000",
"256px_image_url": "...",
"mime_type": "image/jpeg"
}
✅ 意味のある戻り値：
{
"name": "田中太郎",
"image_url": "...",
"file_type": "jpeg"
}
また、UUID のような意味不明な ID よりも、人間が読める識別子の方がエージェントの精度が上がるという発見もあります。
エージェントのコンテキストは有限です。大量のデータを返すツールは問題になります。
対策
エラーメッセージも重要です。
❌ 不親切なエラー：
Error: ValidationError
✅ 親切なエラー：
Error: Invalid date format.
Expected: YYYY-MM-DD (e.g., 2025-01-15)
Received: January 15, 2025
ツールの説明文（description）は、エージェントの「システムプロンプト」に読み込まれます。説明文の質がパフォーマンスに直結します。
良い説明文のポイント
userよりuser_id）実際、Claude Sonnet 3.5 が SWE-bench Verified で最高性能を達成したのは、ツールの説明文を精密に調整した結果だそうです。