Spring AI 2.0・Mastra — AIエージェントの「ツールダイエット」でトークンを削減する

AIエージェントに有用な機能を増やそうと様々なツールを持たせると、突然エージェントの反応が鈍くなったり、速度が極端に遅くなったりする経験をしたことはないでしょうか。数十ものAPI定義がプロンプトを埋め尽くし、エージェントが思考するためのスペースが不足してしまうからです。最近、AIフレームワークや研究コミュニティがこの問題を解決するために注力している「ツールダイエット」、すなわちダイナミック・ツール・プルーニング（動的ツール剪定）技術について解説します。

認識しているのになぜ使えないのか：「見ること」と「選ぶこと」の違い

飲食店に入ってメニュー表が数十ページもあったらどうでしょう。最初から最後まで丁寧に読んだとしても、いざ注文する段階になると迷ってしまい、結局的外れな料理を選んだり、注文を諦めたりしがちです。AIエージェントに過剰なツールを与えた際に発生する問題も、これと非常によく似ています。

これまで私たちは、エージェントがツールをうまく使えないのは、長いプロンプトの中間にある情報を忘れてしまう「Lost in the Middle（中間失念）」現象が原因だと考えがちでした。しかし、2026年6月に発表された研究論文『Looking Is Not Picking』は興味深い逆説を示しています。実験の結果、大規模言語モデルは正解となるツールの定義を、実際に約80%という高い確率で正確に注視していました。

結局のところ、本当の問題は情報を読めていないことではなく、最終的な意思決定段階において、あまりにも多い候補の中から何を選ぶべきか迷ってしまうことにありました。プロンプトの順序を入れ替えるような一時しのぎよりも、そもそも使わない不要なツールをメニューから排除する「ツールダイエット」の方が、はるかに強力な効果を発揮する所以です。

必要な時にのみ検索して取り出す：Spring AIとRAG-MCP

数十ものAPI定義を最初からプロンプトに詰め込むのではなく、最近のトレンドは「入力段階でのフィルタリング」へと急速に移行しています。エージェントに最初からすべての武器を渡すのではなく、必要な時に自らツールボックスから検索して取り出させる手法です。

この手法を最も洗練された形で実現した例が、Spring AI 2.0の「ToolSearchToolCallingAdvisor」です。エージェントに数十のツールを丸ごと渡す代わりに、ツールを検索するための唯一のメタツールのみを持たせます。エージェントが作業中に特定の機能が必要になった場合、この検索ツールを呼び出します。するとシステムは内部のベクトルインデックスから最適なツールの定義を動的に抽出し、プロンプトに追加します。

その効果は絶大です。Spring AIの公式ベンチマークによると、この手法を適用することで、トークン使用量を最小34%から最大64%削減できました。エージェントが不要なツール定義に惑わされないため、推論の精度と処理速度が同時に向上します。

こうしたフレームワークの進化は、学術的な研究の流れとも一致しています。実際に「RAG-MCP」の研究チームがModel Context Protocol（MCP）環境で必要なツールのみを検索して注入したところ、プロンプトトークンが50%以上削減されました。驚くべきことに、正しいツールを選び出す確率は、従来の約13%から43%へと3倍以上に跳ね上がりました。

実行ログのダイエット：MastraとLangGraphによるコンテキスト整理法

前述したSpring AIの手法が、そもそもエージェントに見せるメニュー自体を減らす「入力段階のフィルタリング」だとすれば、ツール実行後に発生するトークンの浪費を防ぐ「実行段階のフィルタリング」も非常に重要です。

エージェントがデータベースを照会したり外部APIを呼び出したりすると、数百から数千行に及ぶ生データが会話履歴にそのまま蓄積されます。この重たく雑多なログがコンテキストに残り続けると、エージェントはすぐに賢さを失い、処理が遅くなります。

オープンソースフレームワークのMastraは、この問題を「ToolCallFilter」という機能で鮮やかに解決します。ツールの実行終了後、次の会話に移行する際、不要に長く複雑な元の引数やゴミデータを会話履歴から即座に整理する技術です。

以下の例のような、ごく簡単な設定だけでエージェントのコンテキストを常にクリーンに保つことができます。

import { Agent } from '@mastra/core/agent';
import { ToolCallFilter } from '@mastra/core/processors';

const agent = new Agent({
  id: 'lightweight-agent',
  name: 'Slim Agent',
  model: 'openai/gpt-4o',
  inputProcessors: [
    new ToolCallFilter({
      filterAfterToolSteps: 2, // 최근 2단계의 도구 실행 내역만 유지합니다.
      preserveModelOutput: true, // 원본 로우 데이터 대신 핵심 요약 정보만 남깁니다.
    })
  ]
});

こうすることで、エージェントは直前に何を行ったかを記憶しつつも、脳内が整理されているおかげで、次の行動をより迅速かつ正確に決定できるようになります。

一方、LangGraphはワークフローの各ステップ（ノード）ごとに必要なツールのみを動的に連結する手法を提案しています。エージェントが全体の会話フローの中で今まさに処理すべきことに集中できるよう、特定の瞬間にのみ最小限のツールセットを持たせる構造です。入力を軽くし、実行記録を掃除するこうした実戦的なパターンは、今や大規模なAIサービスを安定的に運用するための必須の定石となりつつあります。

賢いエージェントは武器を軽く持つ

強力なAIエージェントを作ることは、もはや単に数百ものツールを詰め込んで連携させる作業ではありません。エージェントが複雑な推論を続けられるよう、脳の容量であるコンテキストをいかに軽く、快適に保つかが、実運用でのエージェントのパフォーマンスを決定づけます。

今後、大規模なエージェントシステムを設計する計画があるなら、実行時にツールを動的に選別し、会話履歴を整理するダイエットパターンを設計図にぜひ追加してください。武器を軽く持つエージェントこそが、結果としてより鋭く、賢く動けるようになるのです。