【ITニュース解説】Rethinking Tool Calling: Towards a Scalable Standard

大規模言語モデル（LLM）は、人間が話すような言葉を理解し、生成する能力を持つ非常に優れた技術である。しかし、LLMが持っている知識は、学習したデータの中にある情報に限られる。例えば、今日の天気や最新のニュース、あるいは特定の企業の在庫情報といった、リアルタイムの情報や外部のシステムにアクセスする能力は元々持っていない。

そこで重要になるのが、「ツール呼び出し」という概念である。これは、LLMが外部のサービスやプログラム（ツール）を利用して、特定のアクションを実行したり、追加の情報を取得したりする仕組みを指す。例えば、天気予報ツールを呼び出して最新の天気情報を取得したり、カレンダーツールを呼び出して会議のスケジュールを設定したり、データベースツールを呼び出してファイルの内容を読み込んだりすることが可能になる。これにより、LLMは自身の学習範囲を超えて、現実世界と連携し、より実用的な「エージェント」として機能できるようになる。

しかし、初期のツール呼び出しの仕組みは、それぞれが個別に開発されており、効率が悪く、スケーラブルではなかった。新しいツールが登場するたびに、LLMがそのツールを使えるようにするための特別な連携コードを書き直す必要があったため、ツールが増えるにつれてシステムは複雑化し、管理が難しくなっていった。

このような課題を解決するため、最初に提案された標準化の試みが「Model Context Protocol（MCP）」である。MCPは、LLM（ここでは「エージェント」と呼ぶ）とツールとの間の通信を標準化するための「プロトコル」（通信規約）として登場した。そのアーキテクチャは、エージェントからの全てのツールリクエストを、中央に配置されたMCPサーバーを経由して処理する、クライアント・サーバーモデルに基づいていた。エージェントはMCPクライアントと通信し、MCPクライアントはリクエストをMCPサーバーへ送る。MCPサーバーは、そのリクエストを実際のツールが理解できる形に変換し、ツールへ転送する。ツールからの応答も、逆の手順でエージェントに届けられる仕組みだ。このアプローチは、ツール連携の標準化という大きな一歩だったものの、新たな複雑さや制約も生み出した。

MCPのアーキテクチャが抱える主な課題はいくつかある。一つ目は「Wrapper Tax（ラッパー税）」と呼ばれるものだ。MCPでは、既存のツールをエージェントに利用可能にするために、ツール提供者がそのツール専用の「ラッパーサーバー」を開発・維持する必要がある。たとえそのツールがすでにHTTP APIのような標準的なインターフェースを持っていたとしても、MCPサーバーを経由させるための追加のコード（ラッパー）が必要となり、開発コストと運用コストが増大してしまうのだ。二つ目は「Security Reinvention（セキュリティの再構築）」の問題である。ツールがMCPサーバーの背後に配置されると、ツールの元々持っている認証、認可（アクセス許可）、レート制限（利用回数制限）といった、すでに確立され、検証済みのセキュリティ機能がバイパスされることがある。その結果、ツール提供者は、MCPサーバー側でこれらのセキュリティ機能を再実装するか、あるいはエージェントが中間にあるMCPラッパーサーバーを信頼して、機密性の高い認証情報などを渡す必要が生じる。これはセキュリティ上のリスクを高める可能性があった。三つ目は「Performance Inefficiency（パフォーマンスの非効率性）」だ。MCPサーバーを経由するという「余分な通信経路（ホップ）」は、通信の遅延（レイテンシ）を増加させ、効率を低下させる。また、ツールから返される複雑なデータ構造が、MCPプロトコルによって簡素化された文字列に変換されてしまうことがあり、これにより豊富なデータが持つ文脈が失われ、情報が不透明になる可能性もあった。四つ目は「Scaling Challenges（スケーリングの課題）」である。利用可能なツールの数が増加するにつれて、MCPプロトコルが扱う「コンテキスト」（ツールの情報や状態）が過負荷になる可能性があった。エージェントが膨大なツールの中から最適なものを選択するために、さらに複雑なロジックを実装する必要が生じることもあり、これは中央集約型のシステムが持つ限界を示唆していた。これらの課題は、MCPエコシステムにおいて変更のコストを高くし、プロトコルの採用や開発への投資をためらわせる要因となっていた。

これらの課題に対し、異なるアプローチを提案したのが「Universal Tool Calling Protocol（UTCP）」である。UTCPは、エージェントとツールの間の「中間者」の役割を見直すことで、より直接的で効率的な通信を目指している。UTCPの提案では、強制的な中間サーバーを置く代わりに、ツールに関する「マニュアル」を提供するという考え方を取る。このマニュアルは、多くの場合、ツールの使い方を記述したシンプルなJSONファイルであり、エージェントクライアントがツールのネイティブなエンドポイントに直接アクセスするために必要な情報を含んでいる。

UTCPのアーキテクチャは次のように機能する。まず「Discovery（発見）」の段階で、UTCPクライアントはツールの「マニュアル」を入手する。このマニュアルは、ツール自体が提供することもできるし、コミュニティの誰かが作成することも可能だ。さらに、既存のOpenAPIドキュメントのような標準形式からLLMが自動的に生成することもできる。次に「Direct Communication（直接通信）」の段階では、UTCPクライアントはマニュアルに記述された指示に基づいて、ツールのネイティブなAPIエンドポイントに直接アクセスする。このプロセスにおいて、UTCPプロトコルは最初の発見フェーズ以降は「邪魔にならない」形で機能し、エージェントとツールが直接やり取りすることを可能にする。そして「Leveraging Existing Infrastructure（既存インフラの活用）」が重要な点だ。この直接呼び出しモデルにより、エージェントはツールの元々持っている、すでに堅牢性が確認されたセキュリティ、認証、課金、レート制限といったシステムをそのまま活用できる。ツール提供者がこれらの重要なサービスを再構築する必要はなくなるのだ。

このUTCPのアプローチは、MCPの主要な課題を見事に解決する。まず「Wrapper Tax」は不要となる。ツール提供者は、既存のAPIをエージェントに公開するためだけに、別途サーバーを構築・維持する必要がなくなる。次に「Enhanced Security（セキュリティの強化）」が図られる。UTCPは、デフォルトでツールのネイティブAPIが持つセキュリティ機能を利用するため、悪意のある、またはセキュリティ対策が不十分な中間サーバーを介するリスクがなくなる。さらに「Improved Efficiency（効率性の向上）」も実現する。余分なネットワークホップがなくなることで、通信遅延が減少し、リッチで構造化されたデータがスムーズに転送されるようになる。

UTCPは、MCPと排他的なプロトコルではない。UTCPクライアントは、必要に応じてMCPサーバーを呼び出すように設定することも可能だ。これにより、例えば複雑な双方向通信が必要な場合など、MCPの強みを活用できるハイブリッドなアプローチも可能となる。

MCPとUTCPの実装を比較すると、両者の根本的な思想の違いが明確になる。クライアント側のコードは、どちらのプロトコルもツール呼び出しプロセスを抽象化するため、機能的には似ている。しかし、ツール提供者側の実装には大きな違いがある。MCPの場合、ツール提供者はAPIをMCP経由で公開するために、プロキシサーバーを実装する必要がある。これは、MCPリクエストを受け取り、それをネイティブAPI呼び出しに変換し、さらにネイティブな応答をMCPプロトコル形式に変換して返すコードを書くことを意味する。例えば、簡単なジョブAPIの場合でも、このプロキシサーバーを常に動作させ、維持し、セキュリティを確保し、スケーリングに対応する必要がある。一方でUTCPの場合、ツール提供者はシンプルに「マニュアル」を提供するだけでよい。これは、既存のAPIを呼び出す方法を記述したJSONファイルであり、静的にホスティングすることも、エージェントに直接提供することも可能だ。このマニュアルには、クライアントが自身でAPIを呼び出すために必要な情報がすべて含まれている。このアプローチは、ツール提供者からインフラの負担を取り除き、ネイティブAPIが追加のインフラなしで直接利用されることを可能にする、という点で「邪魔にならない」設計思想を反映している。

MCPのような「特定の意見を持った」、中央集権的なプロトコルと、UTCPのような柔軟な直接呼び出しアプローチのどちらが良いかという議論は、ソフトウェアアーキテクチャにおける古典的な対立を反映している。MCPの標準化されたサーバーベースのモデルは、企業環境において明確で安全な境界を提供できる。企業全体にわたる利用制限、セキュリティポリシー、監査機能を一元的に実装できるため、特定の企業では非常に価値が高い。この「意見を持った」アプローチは、Kubernetesのような厳格だが非常に機能的なフレームワークと同様に、むしろ利点となる場合もある。しかし、UTCPの持つ柔軟性は、既存の膨大なAPIエコシステムを統合する上で非常に魅力的である。エージェントが開発者と同じ方法でツールと対話すべきだという基本的な考え方は、直感的で実用的だ。認証や課金のために既存のセキュリティインフラを活用できることは、採用の大きな障壁を取り除くという点で重要な利点となる。

どちらのプロトコルにとっても、今後の大きな課題は「スケーラビリティ」だ。UTCPはタグや埋め込みに基づくネイティブ検索機能でこの課題に対応すると主張しているが、その実用性がどこまで効果的かはまだ検証が必要だ。数百、あるいは数千ものツールを効率的に扱い、エージェントのコンテキストウィンドウを圧倒することなく利用できるかどうかが、どのようなツール呼び出し標準にとっても最終的な成功を左右するだろう。過去にChatGPTで類似のOpenAPIベースのアプローチが大きな普及に至らなかったことを考えると、単に標準があるだけでは不十分で、プロトコルが基盤となるエージェントシステムと密接に統合されていることが、真に有用なシステムには不可欠である。