The Bitter Lesson of Tool Calling: AIエージェント実装の詰まりどころ

description: Tool callingがLLMをエージェントへと変える仕組みと、プログラマティックなツール呼び出しが従来のJSON固定スキーマを超える点を整理します。実装上の落とし穴と判断材料を具体的に解説します。

meta description: AIエージェント構築におけるtool use・MCP・プログラマティックtool callingの技術的差分と実装上の注意点を解説。レイテンシ、権限管理、fallback設計まで実務視点でまとめます。

---

何が出たのか

2026年8月上旬時点で、Hacker NewsやRedditのML系コミュニティで「The Bitter Lesson of Tool Calling」というフレーズが注目を集めています。これはRich Suttonの有名な論文「The Bitter Lesson」（汎用的な手法がドメイン特化の工夫を長期的に上回るという主張）をもじったもので、ツール呼び出し設計においても「精巧に設計したスキーマより、モデルに自由度を与えた方が結果的にうまくいく」という経験則が広まりつつあることを指しています。

具体的なきっかけとして、複数のエンジニアが「厳密なJSONスキーマでツールを定義するより、コード生成モデルにPythonスクリプトとして呼び出しを書かせた方が、複数ツールの連鎖や並列実行がうまく機能した」という知見をブログや議論スレッドで共有しています。これはAnthropicのMCP（Model Context Protocol）やOpenAIのfunction callingが普及した後に出てきた「次の一手」として位置づけられており、tool useの実装戦略を見直す動きが静かに広がっています。

---

技術的に面白い点

従来のtool calling（ツール呼び出し）は、LLMに対して「どのツールをどの引数で呼ぶか」をJSONフォーマットで出力させ、それをホスト側がパースして実行するという構造が一般的でした。OpenAIのfunction calling仕様やAnthropicのtool useがこのパターンの代表例です。

プログラマティックtool callingが異なるのは、モデルが「呼び出しの手順そのものをコードとして生成する」点です。たとえば、検索ツールと要約ツールを組み合わせる場合、従来は「まず検索を呼ぶ→結果を受け取る→次に要約を呼ぶ」という逐次的なターン制御をホスト側のオーケストレーターが担っていました。プログラマティックなアプローチでは、モデルが以下のようなスクリプトを生成します。

```python

results = search_tool(query="...")

summaries = [summarize_tool(r) for r in results] # 並列化も可能

```

この方式の技術的な面白さは3点あります。

• 並列実行の自然な表現ループや非同期処理をコードとして書けるため、複数ツールの並列呼び出しをモデル自身が設計できます。従来のJSON呼び出しでは、並列化はオーケストレーター側の実装に依存していました。
• 条件分岐の柔軟性if文やtry/exceptをコード内に書けるため、ツール呼び出しの失敗時のfallback（代替処理）をモデルが自律的に記述できます。
• スキーマ定義コストの削減厳密なJSONスキーマを事前定義しなくても、関数シグネチャとdocstringだけでモデルがツールの使い方を推論できるケースが増えています。

コード実行環境としてはサンドボックス（隔離された実行環境）が必須になりますが、この点は後述します。

---

既存の流れとの違い

MCPはAnthropicが2024年末に公開した、ツールやリソースをLLMに接続するための標準プロトコルです。サーバー側でツールを定義し、クライアント（LLMホスト）がそれを呼び出す構造を標準化しています。MCPはツールの「発見」と「呼び出しインターフェースの統一」に優れており、複数のツールを横断的に管理する場面で有効です。

プログラマティックtool callingはMCPと競合するものではなく、MCPで定義されたツールをコード生成によって呼び出す「実行レイヤーの話」です。整理すると以下のようになります。

LangChainやLlamaIndexといった既存フレームワークは、エージェントのループ制御をホスト側で実装する設計が中心です。プログラマティックなアプローチはこのループをモデル側に委譲する方向性であり、フレームワークの役割が「制御」から「環境提供」にシフトする可能性があります。

---

エージェント実装で詰まりやすい点

実際にプロダクトやPoC（概念実証）でこのアプローチを試す際に、いくつかの落とし穴があります。

サンドボックスの設計

モデルが生成したコードをそのまま実行するため、サンドボックスは必須です。ここで詰まるのは「どこまで制限するか」のバランスです。制限を厳しくしすぎると、ファイルI/OやHTTPリクエストが必要なツールが動かなくなります。E2BやModal、あるいはDockerベースの軽量コンテナが選択肢になりますが、コールドスタート（初回起動時の遅延）によるレイテンシ増加は実測して許容値を確認する必要があります。

権限とシークレット管理

生成されたコードがAPIキーや認証情報にアクセスできる状態は危険です。ツール関数の内部でシークレットを解決し、モデルが生成するコードからは直接参照できない設計が基本です。MCPのサーバー側でシークレットを保持し、ツール関数のインターフェースには渡さないパターンが現時点では安全側の設計です。

ログと監視

コードが動的に生成されるため、「どのツールが何回呼ばれたか」の追跡が従来より難しくなります。生成されたコードをそのまま保存するだけでなく、ツール関数の呼び出し側にインターセプター（横断的に処理を挟む仕組み）を入れて実行ログを取る設計が必要です。OpenTelemetryのトレーシングをツール関数にラップする実装が現実的な選択肢です。

モデル依存性とfallback

コード生成の品質はモデルに強く依存します。GPT-4oやClaude 3.5 Sonnet以上のクラスであれば安定しますが、コスト削減のために小型モデルに切り替えた途端に生成コードの品質が落ちるケースがあります。モデルのバージョンアップや切り替え時に、ツール呼び出しの成功率を評価するベンチマークを事前に用意しておくことが重要です。単純なJSONスキーマ呼び出しへのfallbackパスを残しておくことも、本番運用では保険になります。

ツール定義の粒度

「何でもできる汎用ツール」を1つ定義するより、「単機能のツールを複数定義する」方がモデルの選択精度が上がる傾向があります。ただし、ツール数が増えすぎるとコンテキストウィンドウを圧迫します。現時点では20〜30ツール程度が実用上の上限として議論されており、それ以上になる場合はツールの動的ロード（必要なものだけをコンテキストに追加する仕組み）を検討する必要があります。

評価の難しさ

エージェントの評価は「最終出力の正しさ」だけでなく「ツール呼び出しの経路が適切か」も見る必要があります。プログラマティックなアプローチでは生成コードのパスが毎回変わりうるため、決定論的なテストが書きにくくなります。LLM-as-a-judge（別のLLMが評価する手法）やトレースの比較評価を組み合わせる設計が現実的です。

---

Spectralの見解

1. 技術的な読み

「The Bitter Lesson of Tool Calling」が示す方向性は、エージェント設計の重心がオーケストレーター側からモデル側に移りつつあるという変化です。これはモデルの推論能力が上がったことで初めて成立する設計であり、2年前であれば非現実的でした。ただし「モデルに任せれば楽になる」という単純な話ではなく、サンドボックス・権限・ログという運用インフラの整備コストが従来より高くなる点は見落とされがちです。MCPとの組み合わせは相性がよく、ツール定義の標準化はMCPに任せつつ、実行戦略をプログラマティックにするという分担が現時点では合理的な構成です。

2. PoCで確認すべき点

まず確認すべきは「自社のユースケースでコード生成の安定性が許容範囲に入るか」です。具体的には、想定するツールセットを用意し、代表的なタスク20〜30件に対して成功率・レイテンシ・コストを計測することを推奨します。特にサンドボックスのコールドスタート遅延は体感に直結するため、E2BやDockerの選択肢を並べて実測してください。また、モデルを変えたときの成功率の変化も早い段階で把握しておくと、後の意思決定が楽になります。

3. 業務・プロダクト実装に移す時のリスク

最大のリスクは「生成コードの予測不能な動作」です。サンドボックスで封じ込めていても、外部APIへの過剰なリクエストやデータの意図しない参照が起きる可能性はゼロではありません。本番移行前に、ツール関数ごとのレート制限・アクセス制御・監査ログの3点を実装することを最低ラインとして設定してください。また、プログラマティックなアプローチは現時点では標準化が進んでいないため、フレームワークの選定や実装パターンが1〜2年で変わる可能性があります。コアロジックをツール関数側に閉じ込め、呼び出しレイヤーを薄く保つ設計が、将来の変更コストを下げます。

---

まとめ

Tool callingはLLMを「知識を持つ存在」から「行動できる存在」に変える中心的な仕組みです。プログラマティックなtool callingは、その実行戦略をモデル自身に委譲することで、並列化・条件分岐・fallbackをより自然に扱えるようにします。一方で、サンドボックス設計・権限管理・ログ・評価という運用面の複雑さは増します。

MCPによるツール定義の標準化と、プログラマティックな実行戦略の組み合わせは、現時点で最も現実的なエージェント構成の一つです。「The Bitter Lesson」が示す教訓は、精巧な制御ロジックを積み上げるより、モデルの能力を引き出す環境を整える方が長期的に効く、という点にあります。ただし、その環境整備こそが実装の本丸であることは変わりません。

関連論点として Is Spec Driven Development with AI agents the: AIエージェント実装の詰まりどころ もあわせて読むと、この技術動向の背景を追いやすくなります。

Spectralでは、技術調査からPoC設計、プロダクト実装まで支援しています。実現性の確認や事業活用の相談は サービス詳細 と お問い合わせ をご覧ください。