5,961 文字
皆さんはすでにMCPまたはモデルコンテキストプロトコルについての話題を耳にしているかもしれません。このビデオでは、MCPまたはモデルコンテキストプロトコルとは何か、通常のツール呼び出しや関数呼び出しとどう違うのか、そして突然なぜこれほど注目を集めているのかについて詳しく説明したいと思います。
ご存知の通り、MCPはAnthropicから発表されたものですが、OpenAIのCEOであるSam Altmanはこのようにツイートしています：「皆さんはMCPを気に入っており、私たちも製品全体でのサポートを追加することに興奮しています。現在、エージェントSDKで利用可能で、ChatGPT Desktop Plusへのサポートも近日中にレスポンスAPIで提供予定です」
Googleもこれに注目しています。GoogleのCEOであるSundar Pichaiは「MCPか否か、それが問題だ。コメントで教えてください」と投稿しています。興味深いことに、これは新しいものではなく、2024年11月に発表され公開されたものです。つまり、ほぼ4ヶ月前の話です。
こちらがAnthropicの元のブログ投稿で、「モデルコンテキストプロトコルの紹介」というものです。これはAIアシスタントをデータが存在するシステム（コンテンツリポジトリを含む）に接続するための新しい標準とされています。
LLMの最大の問題の一つは、その知識が訓練データのカットオフ日に制限されていることです。では、そのカットオフ日以降の知識をどのように活用できるようにするかという疑問があります。RAGやツール呼び出し、関数呼び出しなどの技術がLLMの能力を拡張する方法としてありますが、一つ大きな問題があります。それは、これらのツール呼び出しや関数呼び出しがどのように実装されているかということです。
例えば、LLMにカレンダーやメールアプリ、特定のデータベースへのアクセスを与えたい場合、それぞれにカスタムAPI統合を実装する必要があります。そして、これらのカスタム統合それぞれが、LLMが外部APIや外部データベースと対話するために使用できるツールになります。これは、エージェントやLLMが外部の世界と対話できるようにする単純な解決策ですが、主に二つの問題があります。
一つ目は、ツールのリストやツールの数が増えると、LLMがどのツールを使用するか決める際に幻覚を起こす可能性があることです。二つ目は、各ツールごとに実装する必要があるカスタム統合があり、標準がないということです。基礎となるAPI実装が変更された場合、ツールやカスタム統合を更新する必要があります。
ここで、モデルコンテキストプロトコル（MCP）が登場します。アイデアは、ツールとLLMの間の相互作用を標準化することです。AIアプリケーション（LLMやエージェントなど）と実際のツール実装の間に、別のカスタム層または標準化層を配置します。ツールを更新しても、MCP標準またはこの標準化層は同じままで、外部ツールの実装を設計する際には、MCPによって定義された標準に従う必要があります。
実際にMCPが何であるかを理解しましょう。これはAnthropicが導入したオープンソースプロトコルで、JSON RPC 2.0メッセージを使用して3つの異なるコンポーネント間の通信を確立します：ホスト、クライアント、サーバーです。
ホストはAIモデルを実行するアプリケーションです。例えば、Claude Desktop、AIドリブンのIDE（カーソルやWindsurfなど）で、外部データやツールへのアクセスが必要なものです。
クライアントはホスト内のモジュールで、サーバーとの通信を担当します。接続を維持し、リクエストを転送するために必要です。クライアントはサーバー内で実行されるモジュールです。
サーバーとは何でしょうか？これらは標準的なモデルコンテキストプロトコルを通じて特定の機能を公開する軽量プログラムです。これにより、ローカルデータソース（ファイル、データベース、コンピュータ上のサービス）や、API経由でインターネットで利用可能な外部システムなどのリモートサービスに接続できます。
特定の機能を公開するサーバーが必要で、サーバーと通信するクライアントがあり、クライアントを通じてサーバーを使用する実際のAIアプリケーションがホストです。
複雑に聞こえるかもしれませんが、詳しく説明します。MCPがどのように機能するかをさらに説明するために、Martinによる「LLMエージェントへのビジュアルガイド」からいくつかの資料を使用します。これは素晴らしいガイドで、リンクはビデオの説明にあります。
彼のブログ投稿にあるこのビジュアルが本当に気に入っています。ホスト、クライアント、サーバーとは何かを明確に説明しています。ホストはカーソル、Claude、OpenAI、WindsurfなどのAIアプリケーションで、自分でホストを作ることもできます。次に、MCPサーバーとMCPホスト間の通信を可能にするクライアントがあります。この通信を可能にする統一されたAPIがあり、MCPサーバーはカスタムAPIやカスタムツールを通じて外部世界と対話しています。
この実装は通常の関数呼び出しやツール使用とは非常に異なります。なぜなら、その場合は異なるツールやAPIに対して独自の通信プロトコルを実装する必要があり、それは標準化されていないからです。MCPクライアントとサーバーを追加することで、プロトコルを標準化し、実際のツールはMCPサーバー上で実行されます。これにより、MCPホストからすべての複雑さが抽象化されます。
さらに詳しく説明するために、同じブログ投稿からこの例を見てみましょう。一般的に、ツールはエージェントフレームワークの重要なコンポーネントであり、LLMが世界と対話して能力を拡張できるようにします。しかし、多くの異なるAPIがある場合にツールの使用を可能にすることは面倒です。ツールを手動で追跡してLLMに供給し、手動で説明し、APIが変更されるたびに手動で更新する必要があるからです。
これが通常のツール使用の様子です。例えば、今日の天気を尋ねるプロンプトがある場合、LLMが利用できる異なるツールのリストを提供する必要があります。LLMはどのツールを使用するかを決定し、その呼び出しを行い、応答を取得し、最終的な応答を生成するためにそれらの結果を供給します。これらすべてがLLMループを通じて発生し、すべてを手動で追跡する必要があります。
MCPの実装と、APIや通信をどのように統一するかを見てきました。ここで簡単な例を紹介します。リポジトリからの最新の5つのコミットを要約するために特定のLLMアプリケーションを使用したいとします。MCPホストはクライアントと共に、最初にMCPサーバーを呼び出して、利用可能なツールを尋ねます。
最初、LLMは特定のサーバーで利用可能なツールについて何も知りません。MCPクライアントが利用できるサーバーのリストだけを持っています。ホストはサーバーにリクエストを送り、ツールのリストを取得します。LLMは情報を受け取り、ツールを使用することを選択するかもしれません。ホストを通じてMCPサーバーにリクエストを送信し、使用したツールを含む結果を受け取ります。
LLMはMCPホストを使用して利用可能なツールのリストを取得し、ツールを使用するかどうかを決定します。ツールを使用すると決めた場合、MCPサーバーはそのツールを実際に使用し、結果を返します。すべてはプロンプトとツールの一部としてLLMにフィードバックされ、LLMはそれらの結果を使用して最終的な出力を生成します。
もう一つ重要なことがあります。MCPサーバーは複数の異なるツールを持つことができるため、複数のMCPサーバーがLLMと対話することができます。その場合、たとえ複数の異なるMCPサーバーを通じて何千もの異なるツールがあっても、LLMはそれらのツールを追跡する必要がありません。
通常、LLMがエージェンティックワークフローでツール呼び出しを行う場合、まず利用可能なツールを確認する必要があります。数千のツールがある場合、LLMがそれらを見ることができるように、システムプロンプトにそれらの数千のツールを含める必要があります。そして、どのツールを使用するかを決定する必要があります。しかし、この場合、利用可能なツールのリストをLLMから分離する別の抽象化層があります。LLMは単に対話しているMCPホストを通じて、どのMCPホストまたはどのMCPサーバーを使用するかを決定でき、これにより複数のツール定義とツール呼び出しが抽象化されます。
次に、MCPサーバーの3つの主要コンポーネントを見てみましょう。これらはリソース、ツール、プロンプトです。リソースはクライアントが読み取ることができるファイルのようなデータで、APIレスポンスやファイルの内容などを考えてください。次に、メール送信やデータクエリなどのアクションを実行するために呼び出すことができるツールまたは関数があります。これがMCPサーバーで利用可能なツールのリストです。そして、すべてを調整するためにプロンプトがあります。これらはLLMとの対話を構造化するためのテンプレートです。
Anthropicのプレゼンテーションからのスライドでは、各サーバーにはツール、リソース、プロンプトがあり、それらすべてがMCPクライアントからMCPホストに公開されています。繰り返しますが、ツールはモデルによって呼び出されるモデル制御関数であり、これには検索ツールや、メッセージ送信やデータベースからのレコード更新などの外部API呼び出しが含まれる場合があります。
リソースはアプリケーションに公開されるデータで、ファイル、データベースレコード、APIレスポンスなどです。これらは取得する出力であり、リソースになります。そしてプロンプトがあり、これらはAI対話のための定義済みテンプレートです。文書の質問応答を考えてみてください。これらはサーバーが使用するプロンプトテンプレートとして考えることができます。
これでMCPとは何か、異なるコンポーネントは何か、それらがどのように相互作用するか、そしてどのように機能するかについて十分な理解が得られたと思います。しかし、なぜ突然これほど注目を集めているのでしょうか？前述したように、これはほぼ4ヶ月前のコンセプトです。
Latent Space PodcastのSeanが挙げた理由のリストがあり、それが非常に共感できると思います。彼は「MCPが注目される理由」として以下を挙げています：
事実上の標準になりつつあるか、完全に同等ではないが、OpenAI、LangChain、LlamaIndexなどの代替アプローチがあります。LangChainにはツール呼び出しのコンセプトがあり、多く使用されていますが、OpenAIや LlamaIndexなどの他のプロバイダーも独自のアプローチを提案しています。彼によると、MCPが注目を集めている理由は、古いアイデアのAIネイティブバージョンであることです。私たちは標準を必要としています。REST APIやHTTPS、TCPSなどの標準を皆が使用しているように、LLMの時代には、LLMと独自のデータソース間のデータ接続を標準化するための標準が必要です。
MCPはバッカーを持つオープンスタンダードであり、この場合バッカーはAnthropicです。Anthropicは実際にこれを更新しており、OpenAIやGoogleのような企業がこの標準を採用することを検討していることも良い兆候です。
AnthropicはAI開発者ブランドとして最高であり、Claudeはレート制限に遭遇しなければ素晴らしいコーディングLLMです。
MCPはLSP（言語サーバープロトコル）に基づいています。これは既存の成功したプロトコルであり、LSPは開発ツールのエコシステム全体でプログラミング言語のサポートを追加する方法を標準化しました。これは基本的に、古いアイデアのネイティブバージョンであり、同様にMCPは、LLMアプリケーションのエコシステムに追加のコンテキストとツールを統合する方法を標準化しようとしています。
AnthropicがMCPを11月に発表した時、すでに多くの異なるクライアント、サーバー、ツールが利用可能であり、それが実際に有用でした。
すでに周りに構築されたコミュニティ全体が見られ、それは非常に素晴らしいことです。例えば、カーソルはMCPサーバーをサポートし、同様にWindsurfもサポートしています。ただし、MCPサーバーを選ぶ際には注意が必要です。利用可能な何千もの異なるサーバーがあるGitHubリポジトリがあります。
次のビデオでは、カーソルやWindsurfなどのAI IDEでこれらのサーバーを使用する方法を紹介しますが、これらのサーバーを選ぶ際には注意が必要です。APIキーやデータをこれらのサーバーを通じて公開しているため、それらが適切に検証されていることを確認したいからです。
他にもいくつかのコメントがあります。現在、MCPは確かに多くの注目を集めており、それらを知ることは本当に良いことです。しかし、将来何が起こるかはわかりません。流動的な状況です。他の企業が独自の標準を提案する可能性もありますが、業界が採用するオープンソース標準を見たいと思います。現時点では、MCPがその標準であるように見えます。
第二に、すべてをMCPサーバーにラップする必要はありません。特に少数のツールがある場合は、この余分な抽象化層を追加するよりも、それらを自分で実装する方が良いでしょう。
これでMCPとは何か、そして異なるコンポーネントは何かが明確になったと思います。より開発者向けのコンテンツを作成する予定で、独自のMCPサーバーを構築する方法の例をいくつか見ていきます。特に今、Geminiもサポートを追加する予定なので、Anthropic、OpenAI、Geminiモデルで使用できるようになるでしょう。そして、オープンソースモデルによるサポートもあることを願っています。
このようなコンテンツに興味がある場合は、チャンネルを購読してください。視聴いただきありがとうございます。次回もお会いしましょう。
コメント