Anthropicの "Code execution with MCP" にモヤモヤする

Anthropicが発表したModel Context Tool (MCP) はAIアプリケーションのツールコールのインターフェースを標準化するプロトコルとして大ブームになり、今や様々なソフトウェアやWebサービスが競ってMCPサーバーを提供するようになっています。 *1

modelcontextprotocol.io

しかし先日、そのAnthropic自らがMCPを利用したAIエージェントアプリケーションの開発に伴う問題点と、それに対応する新たなアプローチを "Code execution with MCP: Building more efficient agents" というタイトルで発表しました。

www.anthropic.com

上記エントリ自体はやや抽象的なところもあり、分かりにくいところもあるのですが、発表後様々な人が内容を検証、実際にサンプルアプリケーションを作ったりしています。概ね次のような内容です。

1. MCPを使ったAIエージェントはトークン消費量が莫大になるという問題がある
   • MCPサーバーが提供するツールのdescriptionを読み込ませる時点で相当数のトークンを消費する
   • LLMとMCPサーバーのやり取りの過程でもさらにトークンを消費する
2. 1の対応策としてこれまでのLLMが直接MCPツールをコールするスタイルからコード実行 (Code execution) というスタイルに変えることを提案する
   • MCPツール定義は段階的に提示する (Progressive disclosure)
     • 上記エントリではファイルツリーの形にして管理することを提案している
   • MCPサーバーとやり取りを行うプログラムコードを作成しておき、これをツール定義として提示する
   • LLMには 上記ツールを利用するプログラムコードを生成 させ、そのコードをエージェントが実行して結果を取得、LLMに返す
     • これによりトークンの消費量が大幅に抑えられる

1の課題はよく分かります。特にサイズの小さいローカルLLMを使ったAIエージェント開発においては結構深刻な問題で、自分が作ったときにはエージェントコード側でLLMに見せるツール定義を絞ったりしたことがありました。

Anthropicはその対応策として新たに「LLMにはMCPを利用するコードを生成させる」というアプローチを提示してきた *2 わけですが、確かに提案としてはいいと思うものの非常にモヤモヤするものがありました。というのも予め準備したコードからMCPサーバーへ接続するのならば、接続先は別にMCPサーバーである必要はなく従来のAPIで何ら問題ないわけです。Anthropicは自分達が送り出したMCPを否定するようなことを言い出したように自分には見えました。

まあAnthropic自身もMCPを考え出した時はこのようになることが見えていなかったんだろうなあと。このコード実行方式についても主流になるかどうかは不明で、今後も色んなアプローチが模索されるでしょう。新しいテクノロジー周辺の技術は非常に入れ替わりが激しいので、何か決定版のようなものが登場したと思っても少し時間が経てばコロッとひっくり返される可能性があると常に心掛けておいた方が良さそうですね。