MCP：AIの世界とのインターフェース標準化—能力交渉は未解決
Table of Contents
**MCP（Machine Context Provisioning）**はAI時代のキーワードとなっています。開発元AnthropicはMCPを「AIアプリケーションのUSB-Cポート」と説明しています。MCPの目的は、アプリケーションが大規模言語モデル（LLM）にコンテキストを提供する方法を標準化することです。
では、LLMにコンテキストを提供するとはどういう意味でしょうか？そして「コンテキスト」とは何でしょうか？
例えば、航空券を予約する際、スケジュールや希望条件がコンテキストとなります。関連情報がコンテキストであると直感的に理解できます。
しかし、MCPの宣伝はユーザーシナリオの可能性を過度に単純化しがちです。
MCP以前：関数呼び出しは既に強力だった
MCP以前でも、LLMは関数呼び出しを通じてコンテキスト取得やシステムコマンド実行が可能でした。AIエージェントはLinuxシェルでビルドエラーを修正したり、ウェブ検索を行ったりできます。
ただし、関数呼び出しは特定のLLMモデルやSDK（例：LangChain）に依存し、異なるLLMやツール間で共有が困難でした。
MCPは単なるコンテキスト提供ではない
MCPは単なるコンテキスト提供ツールではありません。MCPはLLMが世界とインターフェースする「手」です。
関数呼び出しでできることは、MCPでも可能です。
- AndroidのADBを使った自動テストも可能：Android MCP Server
- AIによるUARTデバイス制御も可能：UART MCP Server
例えば、Androidの知識がなくても、デバイスのバッテリー状態を取得できました。
能力チェックの欠如：MCPの大きな課題
MCPは、利用可能な関数呼び出しを汎用的なJSONリストで包み、標準化されたAPIで簡単にアクセスできるようにすることで、この問題を解決することを目指しています。
しかし、能力交渉の欠如により、真の相互運用性は依然として課題です。ZedとOllamaで試すことができます。Mistralを選択し、Context7のようなMCPツールを有効にして、Zedにそのツールで何かをするように頼んでみてください。Zedがツールを呼び出さないことがわかるでしょう。
MCPはUSB-Cプロトコルのような標準化を目指していますが、LLM間の知識やコンテキストウィンドウの違いは根本的な障壁です。100以上のMCPツールが有効になっている場合は言うまでもありません。単に機能リストの交換を標準化するだけでは十分ではありません。
MCPは最新のクラウドモデル間では普遍的ですが、レガシーや小規模モデルでは普遍的ではありません。これは企業のMCP使用にとって大きな問題となる可能性があります。
次のステップ：互換性のある効率的なツール呼び出し
MCPを確実かつ効率的に動作させるためには、よく計画されたツール呼び出しが必要です。複数のMCPツールが利用できる場合、特にツールが重複する機能を持つ場合や複雑な引数を必要とする場合、LLMは最適なツールを選択するのに苦労する可能性があります。
1つのアプローチは、MCPツールルーターを実装することです。これは、ユーザーの意図とコンテキストを分析し、タスクに最適なツールを選択するミドルウェア層です。このルーターは、サポートされている操作、必要な引数、異なるLLMとの互換性など、各ツールに関するメタデータを使用して、情報に基づいた意思決定を行うことができます。
さらに、ツール呼び出しヘルパーは、LLMが有効な関数呼び出しを構築するのをガイドできます。このヘルパーは、欠落している引数についてLLMにプロンプトを出し、入力形式を検証し、初期の呼び出しが失敗した場合は代替ツールを提案することもできます。ルーターとヘルパーを組み合わせることで、システムはエラーを減らし、相互運用性を向上させ、ユーザーエクスペリエンスを合理化できます。
実験は進行中ですが、これらの拡張により、MCPツール呼び出しはより堅牢で、スケーラブルで、ユーザーフレンドリーになる可能性があります。特に、数十から数百の利用可能なツールがある環境では。
結論
MCPは単なるコンテキストプロバイダーではありません。LLMが外界と接続するためのインターフェースです。関数呼び出しで可能なことは、MCPでも可能です。さらに創造的な用途を見つけることもできるでしょう。
MCPを楽しんでください！