MCPはゲームチェンジャーになるのか

近年、Model Context Protocol (MCP)が脚光を浴びています。これは、大規模言語モデル（LLM）などのAIエージェントが、外部のツールやデータソースと安全に双方向接続するためのopenなプロトコルです。そして、MCPサーバーとは、そのプロトコルに従って外部サービスの機能やデータを公開するサーバーのことを指します。AIモデルとあらゆるデータ源との間の「橋渡し」を標準化しようという試みです。

例えるなら、MCPはAIアプリケーションにおけるUSB-Cポートのような存在です。USB-Cが機器と周辺機器を標準化された方法で接続するように、MCPはAIモデルと各種ツール・データ源を標準化された方法で連携させます。この画像がとてもわかりやすかったです。

今回は、MCPの仕組みと目的、そして生成AIの未来に与えるインパクトについて詳しく解説していきます。

MCPとは何か？

MCPの基本アーキテクチャは、クライアント-サーバー方式です。AIを組み込んだホストアプリケーションがMCPクライアント（エージェント側）となり、用意されたMCPサーバーに接続します。MCPサーバーは、標準化プロトコルに従って「Tool」や「Resource」を提供します。開発者は自社のデータやサービスをMCPサーバー経由で公開するか、あるいはAIアプリ側でMCPクライアントを実装してそれらサーバーに接続する形で、この仕組みを利用できるのです。通信にはJSON-RPC 2.0を使い、AIエージェントと各サーバーがやりとりします。

MCPを通じて、AIモデルは外部システムから情報を取得するだけでなく、必要に応じて外部システムへ書き込みや操作を行うこともできます（例えばファイルの更新やレコードの追加など）。これにより、モデルは単なるテキスト生成だけでなく実世界への働きかけが可能となります。

Anthropic社はMCPの仕様とSDKを公開し、PythonやTypeScriptをはじめ、複数言語で実装を提供しています。これにより開発者は、自前の環境にMCPサーバーを簡単に開発できるようになっています。

閉ざされた生成AIが抱えた課題

これまでの生成AIは基本的に閉じた環境の中で動作していました。大規模言語モデルは膨大なテキストデータで訓練されていますが、その知識範囲は学習時点までのものに限られます。例えば、最新ニュースやリアルタイムのデータを知ることはできません。これはつまり、LLMのナレッジカットオフによる問題です。

また、「社内データベースを検索して最新の売上数字を取得し、それをメールで報告する」ような「実行的タスク」は、モデル単体では完結できません。このようなタスクを実行するには、モデルが外部システムとやりとりして、外部システムを動かす必要があります。LLMは、追加の実装なしでは外部システムとインタラクションができません。今まではユーザーとのメッセージングというインタラクションにとどまっていました。

加えて、企業や開発者視点では、統合の手間という課題も顕在化していました。AIを実業務で活用しようとすると、モデルを自社の様々なデータソース（ファイルサーバ、クラウドストレージ、Database、SaaSツール等）に繋ぎ込む必要があります。しかし従来は標準化された方法がなかったため、サービス毎に異なるAPIや認証方式に合わせた実装を個別に書く必要がありました。例えば「Google Drive上の文書を読み込み、さらに社内SQLデータベースをselectして回答を生成するAI」を作る場合、Google Drive APIとデータベースをそれぞれ扱い、データ形式の変換など煩雑な処理を実装しなければなりません。これによってシステム構成は複雑化し、モデルやツールを差し替える柔軟性も損なわれていました。

要するに、生成AIは長らく「知識が閉じている」「外部システムとインタラクションできない」「統合コストが高い」という三重苦を抱えていたと言えます。

乱立する生成AIアプローチ

現在、このような課題を解決するために、様々なアプローチが模索されています。その結果、いくつもの手法やフレームワークが乱立しており、カオスな状況になっています。

プラグイン型のアプローチ

2023年頃には、OpenAIのChatGPTプラグインのように、LLMにプラグインを介して外部APIを呼ばせる仕組みが登場しました。これはモデルにOpenAPIで記述されたツール仕様を与え、ユーザの質問に応じて適切な外部APIを呼び出せるようにするものです。アイディアとしてはMCPと近いものの、各プラグインはモデルやプラットフォームごとに個別に構築・ホストする必要があり、ChatGPTやBing Chatなど特定のサービス内でしか利用できないクローズドな仕組みでした。また多くのプラグインは「モデルがAPIから情報を一回取得して終わり」という片方向の呼び出しに留まり、セッションを通じた継続的な対話や操作には不向きでした。これらの制約から、プラグイン方式は用途限定的でスケーラビリティにも欠け、スタンダードとはなり得ませんでした。

フレームワーク型のアプローチ

LangChainなど、LLMにツール使用を組み込むフレームワークも数多く提案されています。しかし、裏側では、依然として各ツール毎に固有の実装や接続コードを開発者が用意する必要がありました。つまりLangChainは、外部ツールごとの統合の標準化を叶えていませんでした。

RAG（Retrieval Augmented Generation）型のアプローチ

VectorDBなどを用いて関連文書を検索し、そのテキスト断片をプロンプトに組み込んで回答精度を上げるRAGも広く使われています。知識検索によって、モデルのナレッジカットオフやコンテキスト不足を補う方法でした。しかしRAGはあくまで静的な情報提供に留まり、モデル自身が外部システムに能動的に問い合わせたり、データベースへクエリを発行したりといったアクションを実行することはできません。言わば受動的にコンテキストを「渡す」だけで、モデルから「取りに行く」ことはできないのです。

以上のように、生成AIを取り巻くアプローチは多岐にわたります。しかし現状ではそれぞれが部分的な解決策に留まっており、統一的なスタンダートとは言えません。

MCPが標準になりうる理由

MCPがこれらの課題を解決する可能性を秘めています。

MCPを利用することで、AIが自発的に外部のデータを取得できるようになり、外部システムを動かすこともできます。また、これはllmによらずあらかじめ決められたプロトコルに従っているため、統合コストが低いです。MCPは今までの三重苦を解消しているのです。

また、MCPはopenなprotocolであり、Anthropicという大手AI企業の強力な後押しがあります。オープンでモデル非依存という性質上、ClaudeやGPT-4からオープンソースLLMまでどのモデルでも利用可能で、企業や開発者は許可を求めることなく自由にMCP統合を作成できます。 また、MCPはLSPにヒントを得ており(ref)、過去の成功事例を参考にした設計です。

MCPはゲームチェンジャーになるのか

我々が幼少期の頃に思い描いたAIの姿は、ドラえもん、あるいはマトリックスのエージェントのように能動的に活動し、外部とインタラクションするものです。本当に欲しいのは、自分の質問に対して限りなく正確で明快に答えるだけのAIではないはずです。そのようなAIの姿を実現するためには、AIが自ら考え、必要に応じて外部のシステムとやりとりできるようになることが必要不可欠です。MCPサーバーはそのための基盤となりえます。必要な情報を即座に引き出して問題解決に当たる、AIがあらゆるリソースをシームレスに活用できるようになります。そういった点で、MCPサーバーは「閉ざされた生成AI」から「能動的な生成AI」への転換の鍵となり、生成AI業界のゲームチェンジャーとなりうると考えています。