Engineering · アーキテクチャ

プログラマティック・ツール呼び出し — ラウンドトリップを脱してエージェントパイプラインを軽くする

プログラマティック・ツール呼び出しとは、モデルがPythonスクリプトを生成してツールを束ね、中間結果をコンテキスト外で処理してから最終結果だけを返す設計。多ツールのパイプラインで入力トークンを大幅に削減します。

効くケース・逆効果なケース

Anthropic公式ドキュメントが示す計測値は、どんな処理で効果が出てどんな処理で逆効果かを明確にしています（いずれもAnthropicが公開したベンチマーク結果であり、agens の実績値ではありません）。

• 効くケース（複数ツール・集計・並列）: 75ツール構成のプロジェクト管理エージェントで入力トークン約38%削減・タスク精度変化なし。本番APIトラフィック（10〜49ツール定義）での代表的な削減幅は20〜40%。BrowseCompおよびDeepSearchQAでベンチマーク性能+11%・入力トークン24%削減。
• 逆効果なケース（逐次・1〜2呼び出し）: τ²-bench（航空・小売・通信の逐次1〜2呼び出し）ではスコア変化なし、コストが約8%増加。スクリプト生成のオーバーヘッドがシンプルな処理では帳消しになるため、1〜2回の単純な呼び出しチェーンには向かない。

判断基準は「ツール呼び出しの深さと中間処理の量」です。複数ツールを組み合わせる・中間データを絞り込む・並列で走らせるパイプラインほど恩恵が大きくなります。

Tool Search との組み合わせ — 発見と実行の両方を効率化する

プログラマティック型の「実行の効率化」は、ツール発見の課題（tool-scaling）と補完関係にあります。

（B）ツール発見の問題: 多数のツール定義を事前にコンテキストへ全ロードすると、何かを実行する前から数万トークンを消費します。Anthropicの例では典型的なマルチサーバー構成（GitHub・Slack・Sentry・Grafana・Splunk）で約5万5,000トークン。Tool Searchによるオンデマンド発見はこれを85%以上削減します（Anthropic公式ドキュメント）。

そしてプログラマティック型は「実行フェーズ」のコストを削減します。必要なツールを見つけた後、それをどう動かすかが次の問いです。

2つを組み合わせると、「定義のロード前」と「実行中」の両フェーズでトークンを大幅に削減できます。複雑なエージェントパイプラインの設計では、この2つをセットで考えることが効率の面で重要です。

関連