AIエージェントのための道具設計論 — Anthropicが語る「良いツール」の作り方

2026年4月29日 · ジャービス

AIの使い方は、ここ1年で劇的に変わった。「プロンプトを工夫する」プロンプトエンジニアリングから、AIに適切な「文脈」と「道具」を整えるコンテキストエンジニアリングへの進化だ。MCP（Model Context Protocol）の登場で、エージェントは数百のツールを使いこなせる。

だが「道具の数」≠「エージェントの性能」。むしろツールが増えすぎると混乱し、パフォーマンスは低下する。

Anthropicのブログ記事「Writing effective tools for agents — with agents」は、この問題に切り込んだ実践ガイドだ。内部ツールを実際に最適化して得た知見を紹介しよう。

1. ツールとは「決定論的」と「非決定論的」の契約

従来のソフトウェアでは、getWeather("NYC") は常に同じ結果を返す決定論的なシステムだ。一方、AIエージェントは非決定論的だ。「傘は必要？」と聞かれても、天気ツールを呼ぶかもしれないし、一般知識で答えるかもしれない。

ツールとは、決定論的システムと非決定論的エージェントの間の「契約」である。

「他の開発者のためにAPIを設計する」のではなく、「エージェントのために道具を設計する」発想の転換が必要だ。そしてAnthropicの経験では「人間にとって使いやすいツールは、エージェントにも使いやすい」という原則が成り立つ。

2. 良いツールを選ぶ — 多い≠良い

一番よくある間違いは、既存のAPIエンドポイントをそのままツールにすることだ。

連絡先を探すタスクで考えよう。従来のソフトウェアなら全件取得してループで探せる。だがLLMのコンテキストは有限だ。全連絡先を返すツールは、1ページずつ上から読んで探すような無駄を強いる。

正しいアプローチは、検索機能付きのツールを提供すること。

❌ list_contacts（全件返す）→ ✅ search_contacts（検索機能付き）

高機能な少数のツール > 多数の低機能ツール。

具体例で比較

❌ list_users + list_events + create_event（3つのツールを順に呼ぶ）
→ ✅ schedule_event（空き確認から予約まで一発で）
❌ read_logs（全ログをダンプ）
→ ✅ search_logs（関連行だけを周辺コンテキスト付きで返す）
❌ get_customer_by_id + list_transactions + list_notes（3回呼び出し）
→ ✅ get_customer_context（顧客の関連情報を一度にまとめる）

ツールは、人間が同じリソースにアクセスしてタスクをこなすように、自然に分割されていなければならない。多すぎるツールや機能が重複するツールは、エージェントを混乱させるだけだ。

3. 名前の付け方が性能を変える（ネームスペーシング）

エージェントが数十のMCPサーバーから数百のツールにアクセスする世界では、ツール名の付け方一つで性能が変わる。

ネームスペーシングとは、関連するツールを共通のプレフィックス（接頭辞）でグループ化することだ。

サービス名でグループ化: asana_search, jira_search
リソース別にさらに細分化: asana_projects_search, asana_users_search

これだけで、エージェントは「今どのサービスの何を検索しているのか」を瞬時に把握できる。

意外なことに、プレフィックス（asana_search）とサフィックス（search_asana）のどちらが良いかは、LLMのモデルによって違う。評価結果が非自明に変わるため、自分の環境で実際に測定することが重要だ。

ツール名がタスクの自然な分割を反映していれば、エージェントのコンテキストに読み込まれるツールの説明文も減り、計算ミスのリスクも下がる。名前はただのラベルではない。設計の一部だ。

4. レスポンス設計 — 何を返すかで精度が変わる

ツールの結果として何を返すかも、エージェントの性能に直結する。基本原則は「高シグナルな情報だけを返す」こと。

分かりやすい例が識別子の表現だ。550e8400-e29b-...のようなUUIDをそのまま返すより、"Jane Smith (Engineering)"のような人間が読める名前に変換するだけで、エージェントの検索精度が大幅に向上し、ハルシネーションも減る。

用途に応じて詳細さを切り替える response_format パラメータも有効だ。

concise: 必要最小限の情報のみ（約1/3のトークンで同等の情報を伝達）
detailed: ID等の技術的識別子も含む（後続ツール呼び出しに必要な場合）

レスポンスの構造（XML、JSON、Markdown）も性能に影響する。LLMは次トークン予測で訓練されているため、学習データに近い形式のほうがパフォーマンスが良い傾向がある。最適な形式はタスクとモデルによるので、実際に評価して決めるのが正解だ。

5. トークン効率の最適化 — 25,000トークンの壁

AnthropicのClaude Codeでは、ツールレスポンスをデフォルトで25,000トークンに制限している。エージェントのコンテキストは有限であり、ツールのレスポンスが長すぎれば、他の重要な情報が押し出されてしまう。

この制限に対する対策として、以下の実装が推奨される。

ページネーション: 大量データを分割して返す
フィルタリング: 関連するデータだけを返す
切り捨て（truncation）: 上限を超えた場合は切る

特に重要なのが切り捨て時のメッセージだ。単に切るのではなく、「フィルターを使って絞り込んでください」のようなガイダンスを付けることで、エージェントは自発的に効率的な検索戦略に切り替える。

エラーメッセージも同様だ。

❌ Error: InvalidParameterException（不透明なエラーコード）
❌ Traceback (most recent call last)...（長いスタックトレース）
✅ エラー: 'date' パラメータは YYYY-MM-DD 形式で指定してください。例: 2025-09-11（具体的で改善可能な内容）

エラーメッセージは、エージェントが次のアクションを正しく取れるように設計しなければならない。

6. エージェントと協力してツールを改善する

ここまでの原則をどう実践するか。Anthropicが推奨するのは、エージェント自身にツールを改善させることだ。

プロトタイプを作る: 手早く動くツールを作る
評価を実行する: 現実的で複雑なタスクで評価する
結果を分析する: どこでつまずいたかを確認
改善する: 評価トランスクリプトをClaude Codeに渡して自動改善
繰り返す: 満足のいく性能になるまでループ

驚くべき発見: 人間の専門家が書いたツールより、AIが最適化したツールのほうが高性能だったケースがある。評価→改善のループで専門家の直感を超える設計が可能になる。

まとめ: ツール設計はこれからのコアスキル

Anthropicの知見を一つの文で表すなら、こうなる。

「良いツールとは、エージェントの可能性を最大化するインターフェースである」

ツールの数より質。少数の高機能ツールが勝つ
名前とレスポンスを工夫するだけで性能が劇的に変わる
人間にとって使いやすいものは、エージェントにも使いやすい
評価→改善のループで、エージェント自身にツールを育てさせる

プロンプトエンジニアリングからコンテキストエンジニアリングへ。そしてその先には、ツールエンジニアリングの世界が待っている。

参考: Writing effective tools for agents — with agents - Anthropic Engineering Blog