この1つの技でAIエージェントのトークンを98%節約する

AIエージェント
この記事は約11分で読めます。

この動画は、MCPサーバーやAIエージェントが大量のツール定義によってコンテキストウィンドウを消費してしまう問題に対し、トークン使用量を大幅に削減するための実践的な手法を解説する内容である。コード実行、ツール検索、スコープ読み込み、動的コンテキスト読み込み、プログラム的ツール呼び出し、TOON形式など、複数のアプローチを組み合わせることで、エージェントをより安く、速く、正確に動かす設計思想が紹介されている。

Save 98% on AI Agent Tokens With This One Trick
Thanks to BrightData for sponsoring this video. Checkout their new MCP server here: servers can burn through ...

MCPサーバーがコンテキストを食い尽くす問題

さて、MCPサーバーは、あなたがまだ1つのメッセージも送っていない段階で、コンテキストウィンドウを食い尽くしてしまうことがあります。場合によっては、その半分がツール定義だけで埋まってしまうことすらあります。

そこでこの動画では、数値を大幅に下げるための10個のテクニックを見ていきます。中には単純な設定変更で済むものもありますし、コード実行やプログラム的ツール呼び出しのような、より高度なパターンもあります。

特に優れた手法では、トークン使用量を最大98%削減できます。つまり、より安く、より速く、より正確なエージェントを作れるということです。

コード実行でツール定義を読み込まない

最初のアプローチはコード実行です。

すべてのツールの定義をすべて読み込む代わりに、エージェントにサンドボックス環境を与え、そこでMCPサーバーをファイルシステムのように扱わせます。

これはAnthropicによって紹介された方法で、Cloudflareもその数週間前に、同じ考え方をcode modeという名前で公開していました。つまり、主要なAIインフラ企業2社が、それぞれ独立に同じパターンへ到達したということです。

仕組みとしては、それぞれのツールが1つのファイルに対応します。Google DriveとSalesforceをMCPサーバーとして使っている場合、それぞれにフォルダがあり、ツールごとにTypeScriptファイルが置かれているような形になります。

エージェントはファイルシステムを探索することで、何が利用可能なのかを発見し、目の前のタスクに必要な特定のファイルだけを読みます。

これによって段階的な開示が行われ、コンテキストウィンドウ内のトークン数が大幅に減ります。

Anthropicの投稿にある例では、Google DriveのドキュメントをSalesforceへ移動するタスクが紹介されています。従来の直接的なツール呼び出しのアプローチでは、コンテキスト内で約15万トークンがやり取りされていました。

しかしコード実行を使うと、モデルに届くのはコードの実行結果だけで、約2,000トークンになります。これはおよそ98%の削減です。

コード実行の副次的な利点

副次的にも、いくつか良い利点があります。

エージェントは、大きなデータセットがモデルに届く前に、コード内でフィルタリングできます。毎ステップごとにモデルへ戻る代わりに、ループや条件分岐をコードとして書くこともできます。

さらに機密データについては、中間結果を実行環境内に留めておけます。メールアドレスや電話番号のような情報がワークフローの中を流れても、コンテキストウィンドウに入らないようにできるのです。

これはこの動画の中で最も強力なアプローチですが、最も複雑でもあります。なぜなら、適切な隔離とリソース制限を備えた本物のサンドボックスが必要になるからです。

Anthropicのツール検索を使う

これに似たアプローチとして、Anthropicのツール検索ツールを使う方法があります。

この場合、エージェントはいくつかの基本ツールと検索ツールにアクセスできます。そして追加のツールが必要になったときに、カタログを検索します。これは、Claude Codeがファイル検索を行うのとかなり近い形です。

これにより、エージェントは何千ものツールを扱えるようになります。必要に応じて動的にツールを発見し、読み込めるからです。

ドキュメントには2つのバリエーションが記載されています。1つは正規表現を使うもので、もう1つはBM25を使うものです。BM25とは、簡単に言えば自然言語のランキング手法です。

有効化するには、ツールリストに検索ツールを追加します。そして、すぐには読み込みたくない各ツールに対して、デフォルト読み込みをtrueに設定します。

ここでAnthropicが公開した数字は、かなり大きなものでした。

一般的なマルチサーバー構成では、作業が始まる前からツール定義だけで約55,000トークンになります。ツール検索を使うと、これを85%以上削減できます。

また、選択精度の向上にも役立ちます。ドキュメントでは、ツール数が30から50を超えると選択精度が低下すると説明されています。

ただし、これら2つのアプローチはどちらも優れていますが、MCPそのものが当初持っていた約束からは少し離れていきます。MCPの本来の約束は、サーバーがクライアントに、どのツールが利用可能かを伝えるというものだからです。

スコープ読み込みで必要なツール群だけを使う

別のアプローチとして、スコープ読み込みがあります。これは、類似性に基づいてツールのグループを作る方法です。

たとえば、さまざまな種類のデータへアクセスできるMCPサーバーがあるとします。EC、金融、ソーシャルメディアなどです。

その場合、これらのツールをグループ化し、必要な特定のグループだけを動的に読み込みます。

このアプローチは、Bright Dataが自社のMCPサーバーで導入したものです。

これはBright Dataが提供しているオープンソースのMCPサーバーです。そして、この動画をスポンサーとして実現してくれたBright Dataに大きく感謝します。

Bright Dataはウェブデータアクセスを可能にする企業であり、そのMCPサーバーには11個のグループにまたがる60以上のツールがあります。

使い方としては、接続を設定するときに、どのグループまたは複数のグループを使いたいかを指定します。

これはURLのgroupsパラメータで指定することもできますし、ローカル設定の環境変数として指定することもできます。複数のグループを同じセッション内で組み合わせることも可能です。

これにより、非常に効率的なトークン利用ができます。実際に必要なツール分だけを支払うことになるからです。

しかも実装はオープンソースなので、自分自身のMCPサーバーでも同じパターンを使えます。

特定のツールだけをセッションに読み込む

さらに、これを一歩進めることもできます。

グループを定義する代わりに、特定のセッションで利用可能にしたい具体的なツールそのものを定義できます。

Bright Dataの構成では、これはtools環境変数です。使いたい正確なツール名を列挙すると、そのツールだけが読み込まれます。

これにより、さらに大きなトークン削減ができます。

アプリケーションが利用可能な60個のツールのうち4個だけを必要としているなら、4個だけを読み込み、4個分だけのコストで済みます。

注意点は、選択するためには、そのサーバーにどのツールが存在しているのかを事前に知っている必要があるということです。

そのためこれは、すでに発見作業を終えていて、本番環境のエージェントを特定の仕事に固定したい場合に向いています。

動的コンテキスト読み込み

別のアプローチは、動的コンテキスト読み込みです。

これはClaude Skillsに着想を得たもので、Claude Skillsは情報を動的に読み込み、必要なときだけエージェントに提示します。

考え方としては、3段階の開示があります。エージェントは、自分に何が必要かを判断しながら、その段階を下っていきます。

第1段階では、単純に、どのMCPサーバーが利用可能かをエージェントに伝えます。

第2段階では、エージェントがあるサーバーを関連性のあるものだと判断した時点で、そのサーバー内のツール一覧と1行の要約を受け取ります。

第3段階では、実際に特定のツールについて、名前、説明、入力スキーマを取得します。

このアプローチは、トークンを節約できるだけではありません。実際に関連する情報だけがコンテキストに入ることになります。

そして良い点は、この手法をグループツールやカスタムツールのアプローチと組み合わせられることです。それぞれ異なるレイヤーで機能するからです。

Bright DataのSkillパッケージ

Skillsといえば、Bright DataもAnthropicが導入したskill.md形式を使った独自のSkillパッケージを提供しています。

そこには5つのSkillがあります。それぞれのSkillはフォルダになっていて、その中にskill.mdファイルがあります。このファイルにはYAMLフォーマッタと通常のMarkdownによる指示が含まれています。

これはOpen Agent Skill Ecosystemと呼ばれる仕組みによって、40以上のコーディングエージェントで動作します。

プログラム的ツール呼び出し

別のアプローチは、プログラム的ツール呼び出しです。

これはAnthropic APIの別機能であり、ドキュメント上ではコード実行の隣に置かれています。

考え方としては、Claudeにコードを書かせ、そのコードがあなたのツールをPython関数として呼び出すようにします。そして重要なのは、それらのツール呼び出しから得られる中間結果が、モデルのコンテキストウィンドウに入らないことです。

入るのは最終的なコード出力だけです。

モデルは、数百キロバイトに及ぶ情報を推論する代わりに、数行だけを推論することになります。

有効化するには、ツールリストにコード実行ツールを追加し、呼び出し可能にしたい各ツールに対して、allowed callersをcode executionに設定します。

Anthropicのドキュメントでは、browse、comp、deep search QAのようなエージェント型検索ベンチマークにおいて、基本的な検索の上にプログラム的ツール呼び出しを追加することが、エージェント性能を完全に引き出す鍵だったと説明されています。

1つ注意点があります。MCPコネクタ経由で提供されるツールは、現時点ではプログラム的に呼び出すことができません。

そのため、この方法はアプリケーション内で直接定義したツールとはうまく組み合わせられますが、現在のMCPとの間にはギャップがあります。Anthropicも今後の課題として、この点を示しています。

レイヤー化されたMCPサーバー設計

別のアプローチは、レイヤー化されたMCPサーバー設計です。

この場合、LLMと実際の基盤となるMCP実装の間に3つのレイヤーがあります。発見、計画、実行の3レイヤーです。

これは、ほとんどのアクションがサブエージェント内部で起こる、サブエージェント設計のようなものだと考えるとよいです。

そのため、オーケストレーター、つまり元のエージェントのコンテキストはきれいなまま保たれます。入力を生成し、結果だけを受け取るのです。

これは、オンにすれば使える機能というより、アーキテクチャ上のパターンです。そして本当に意味があるのは、大規模な場合です。

つまり、下層に多くのMCPサーバーがある場合や、異なるチームが異なるツールを所有していて、その前面にきれいなインターフェースを置きたい場合です。

ほとんどの構成では、先ほどまでに紹介したよりシンプルなアプローチで十分です。

入力と出力の両方を最適化する

入力トークンと出力トークンの両方を最適化することもできます。

グループツールで見たように、入力データについてはすでに多くの最適化が可能です。

ただし、ウェブデータや、何らかのフォーマットを持つデータを扱う場合、通常、それらのツールやウェブ検索結果はフォーマット付きで返ってきます。

今ではこうしたシステムはかなり賢くなっています。

そのため、Markdownやその他の形式情報を取り除き、プレーンテキストの結果だけを渡すことができる可能性があります。

このアプローチだけでも、各レスポンスで意味のある量のトークンを節約できます。

さらにGoogle検索結果に対して軽いパースを行い、上位のオーガニック検索結果だけを取り出して、広告や関連検索を落とせば、さらに節約できます。

正確な数値はページによって異なりますが、原則は変わりません。

したがって、ドキュメントやウェブページなど、フォーマットを含むデータとやり取りするツールを多数持つMCPサーバーを実装しているなら、これは実践的に検討すべきことです。

TOONによる出力最適化

もう1つ、単独で取り上げる価値のある出力最適化があります。これは少し違う種類の節約だからです。

それはTOON、Token Oriented Object Notationと呼ばれるものです。

TOONが解決する問題は、JSONが各レコードでフィールド名を毎回繰り返すことです。

たとえば3つの商品リストがある場合、ID、名前、価格がそれぞれ3回ずつ出てきます。

TOONでは、フィールド名を最初に一度だけ宣言し、その後はCSVのように行を流します。

つまり、キーを繰り返す代わりに、値だけを持つのです。

一般的な主張としては、標準的なJSONと比べて30%から60%のトークン削減ができるとされています。

ただし注意点として、TOONはフラットで均一なデータに向いています。

LinkedInプロフィールのように、経験、学歴、スキルなどがネストされた深い構造を持つデータでは、TOONの強みは薄れます。表形式のレイアウトがうまく当てはまらないからです。

複数の手法を組み合わせる

一般的に、単一のアプローチだけに頼るべきではありません。

理想的には、これらを積み重ねて使い、コンテキストウィンドウを最大限に活用するべきです。

実務上は、接続レイヤーではツールグループを使って読み込む範囲を制限します。

グループにうまく収まらないツールにはツール検索を使います。

複数ステップのワークフローにはプログラム的ツール呼び出しを使います。

フォーマットされたデータを返すすべてのツールでは、出力の不要な形式を削ります。

そして、フラットな表形式のレスポンスには、その上でTOONエンコーディングを使います。

さらに意欲があるなら、MCPを使ったコード実行によって、直接的なツール呼び出しを完全に置き換えることもできます。

素晴らしいのは、これらがすべてオープンソースであることです。

特にBright DataのMCPサーバーは、MITライセンスでGitHubに公開されています。

無料枠でも月5,000リクエストを利用できます。プロトタイピングにはかなり寛大です。

まとめ

自分のMCPサーバーツールで、どのアプローチを使っているのか、ぜひ教えてください。

また、何かコツがあれば共有してください。

この動画が役に立ったなら幸いです。

ご視聴ありがとうございました。いつものように、また次回お会いしましょう。

コメント

タイトルとURLをコピーしました