Zenn
⚡

なぜ MCP がこれほどまでに革命的なのか？

に公開
Model Context Protocol
tech

はじめに

MCP（ModelContextProtocol)

わずか半年でこれほどエンジニアを魅了した技術はあまりないのではないだろうか。
本年は 間違いなくAIエージェント元年になる と言われ久しいが、その礎となる始皇帝こそまさにこのMCPである（個人差あり）

しかし半年前、私はこのMCPが出現した時は、その凄まじさを全く理解できず 「？？？」 を脳内に生やした後スルーした。やはり凡人は１を聞いても１しかわからないらしい。そしてちょうど２ヶ月ほど前に遅ればせながら、この時代の寵児たるMCPの威力に愕然とした。

本記事は「なぜMCPがこれほどまでに革命的なのか？」を私なりに独自解釈し、私と同じように「？？？」な人や、未だにMCPの実力を疑っている方に届くことを願って書いたものである。無論独自解釈なので、間違いや認識の違いも往々にしてあることはご容赦願いたい。

なぜパッとしないんだろう問題

かつての私はドキュメントを読んだ。
こんな絵があった。

この絵を見た瞬間、身体に稲妻が走ったあなたには、もはや何も言うことはない。
しかし、ほんのりわかった気がするだけの方はもう少しお付き合いいただこう。

私はこの絵を見た時の正直な感想としては「RAG や Function Calling と何が違うねん」である。
もちろん違う

公式ドキュメントの冒頭には以下のように過不足なく纏まっている。

The Model Context Protocol (MCP) is an open protocol that enables seamless integration between LLM applications and external data sources and tools. Whether you're building an AI-powered IDE, enhancing a chat interface, or creating custom AI workflows, MCP provides a standardized way to connect LLMs with the context they need.

MCP は、LLMアプリケーションと外部データソースやツールとのシームレスな統合を可能にするオープンプロトコルです。AIを活用したIDEの構築、チャットインターフェースの強化、カスタムAIワークフローの作成など、どのような場合でも、MCPはLLMが必要とするコンテキストを接続するための標準化された方法を提供します。

ただ、これだけでは到底理解できない。理解できない理由は明白である。MCPに至る経緯がわかっていないのと、日々雨後の筍の如く出現する生成AIサービスに翻弄されているからである。

では、LLMアプリと外部リソースやツールを統合するプロトコルという概念をぼんやり頭の片隅においた状態で、その実像を見ていきましょう。

今より遥か昔（A.D.2022)

人類最後の発明であるAIを、庶民にまで普及させた ChatGPT が出現します。
もはや語るまでもないその威力たるや凄まじく、我々の日常を一変させました。
語るまでもないのですが、一応ChatGPTの当時できたことを確認しましょう。

  • Chatベースで気軽にやり取りできる
  • その回答精度は当時でも非常に高い
  • Codingなどの特定分野における問題解決能力は、かつてのAIとは比べ物にならないくらい正確

しかし、もちろんできないことも存在します。典型的な回答できないケースは以下です。

  • 社内や研究室内にしか存在しない、極秘データは学習されていない
  • 学習時点以降の最新情報は持っていない
  • 高度な数的処理は、当時のGPTでは難題であった

極秘データに関してはすでにRAGという手法が確立されていたのである程度解決できましたが、問題はその他のものです。そして、この問題を解決するためにある解決策が世間を騒がせました。

それが Function Calling です。

鬼に金棒(A.D. 2023)

人々は思いました。
この最高の僕（しもべ）に道具を持たせたいと。
Function Calling は、この願いを叶えるべくOpenAI社によって実現されました。
これまでは、最新情報を取得できなかったり、高度な計算ができなかったりしましたが、これからは違います。Function Calling で定義した道具たちをLLMが解釈します。これによってLLMは適時、必要な道具を選定し、行使することが可能になりました。

しかしこの出来レースは果たして許されるでしょうか？

否

我らが雄Anthropic社や帝王Googleが許すわけありません。
OpenAI社に負けじと、それぞれ独自の Function Calling を実装し始めます。
争いが苛烈になればなるほど、独自進化を遂げるのは必然です。

世はモデル戦国時代

OpenAI、Google、Anthropic その他各社、骨肉の争いを繰り広げています。記憶に新しいのはOpenAI社の12 Days of OpenAIのあとに、GoogleがGemini2.0を発表し、OpenAI社を殺しにかかっていたことでしょうか。

開発者にとって、モデルのアップデートというのは 3度の飯より大事なことです。そんなモデルアップデートが考えられないスピードでやってきます。そして先ほども触れましたが、各社の独自進化は止まりません。

Function Calling を筆頭に、各社のAPI呼び出しなどは、バラバラに定義しているので、自分が開発中のAIアプリでのモデル切り替えは面倒です。そしてそのモデルがイマイチだということがわかった時には殺意すら湧きます。

もちろんライブラリレベルでは、ある程度共通化できます。
救世主LangChainは、この戦争中において最も偉大な功労者の一人です。しかし英雄は万能ではありません。例えば、GoやRust、ひいてはLisp...などは到底サポートしていませんし、本当に出来たてほやほやの新しいモデルは、LangChainが対応するまで待たないといけません。

待つ...？
待てますか？
この時代に？

答えはNoです。
待つくらいなら直接APIを叩いて検証します。
となるとその代償として、最先端を走っている会社の様式に従う必要があります。

もうええでしょう(A.D.2024)

そんな中、この争いに一石を投じる者がいました。
Anthropic社です。

この地獄の苦しみからエンジニアを救うべく ModelContextProtocol を提唱しました。

ModelContextProtocolというのはその名の通り、プロトコルです。
これはHTTPやTCP/IPと同レベルの根源的な取り決めです。
つまり「AIシステムでの接続では、この約束に従ってくださいね」ってことです。

先ほど述べたように、Function Calling などは OpenAI社と Anthropic社では呼び出し方が違います。入出力の規格が（もちろんですが）独自に定義しています。当然の帰結として、統合はできません。その入出力を各社合わせましょうよ というのがMCPの本質です。

これは詰まるところ、先ほどのLangChainのようにライブラリレベルで共通して便利ということをはるかに超えてきます。jsonrpcという規格に則るので、もはや言語に依存しなくなるのです。これによって、アプリケーションでモデルを変える時、それに付随する実装を変えるという死ぬほど怠い手間から解放されます。これはブラウザ戦争の時のJavaScriptの問題と酷似しています。（これを解決したのがEcmaScriptですね。）

そしてついに、時代の寵児OpneAI社がこの革命的プロトコルに共鳴し、明確に時代が動き始めました。

Function Calling （Tools)のリクエストの一例

OpneAI社
{
    "type": "function",
    "id": "call_12345xyz",
    "function": {
    "name": "get_weather",
    "arguments": "{\"location\":\"Paris, France\"}"
}

↑↓で規格が異なっている。

Anthropic社
{
  "type": "tool_use",
  "id": "toolu_01A09q90qw90lq917835lq9",
  "name": "get_weather",
  "input": {"location": "San Francisco, CA"}
}

その違いを吸収し、↓ の形でやり取りしましょうや。というのを提案した。

ModelContextProtocol
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "location": "New York"
    }
  }
}

統一後(A.D.2025~)

Function Calling に限らず、これら道具の呼び出し規格が統一されたことによって、モデル毎に呼び出し手法を変えなくてよくなりました。つまり、MCPという規格ができたことによって、非常に簡単に便利な道具を呼び出せるようになったと言うことです。さて、便利な道具ってなんでしょうか👀

以下のユースケースを想定してみましょう。

  1. Google Meetでミーティングなどを録画する。
  2. 録画したものは今は自動で文字起こしされるので、それをGdriveまで見に行く。
  3. 文字起こしのまとめがあまり良くないので、再度ChatGptに要約を依頼します。
  4. そしてそれをコピーしてNotionなどに貼り付ける。

面倒ですね...

しかし、実は便利な道具の存在によって、これらの工程が１つに集約されます。
例えば Claude Desktopはアプリ内部で Gdrive連携やNotion連携ができるようになりました。このGdrive連携やNotion連携と言っているものの正体が便利な道具、つまりMCPサーバーといわれるものです。

便利な道具は何もこれだけではありません。Google Spread Sheet, Gmail, 各Database, Google Calender, Slack...と挙げればキリがありません。

お分かりでしょうか。MCPというプロトコルが策定され、それを使って便利道具（MCPサーバー）を今、各社公式で必死で作っています。なぜか？ 便利道具（MCPサーバー）を提供できなければ各社のサービスが使われず、これはサービスにとって死を意味するからです。

便利道具の普及によって、意味のあるデータのHost先に選ばれるかそうでないかの岐路に、各社が立たされています。

Notionというサービスを考えてみましょう。

Notionは大変便利です。もし便利道具（公式MCPサーバー）を提供していないとしましょう。ビジネスを取り行っている人間は、Slackの何気ないやり取りやHintsを保存したくなるでしょう。そんな折、便利道具がなければ、いちいちコピペしないといけない現実があります。
そこに便利道具が対応している類似サービスが登場すればどうでしょうか？

１つのChatアプリで完結できるため、そのサービスに移行しNotionは瞬く間にシェアを奪われ、この世から消えるでしょう。無論Notionの経営陣及び開発者は、天才集団なのでそんな無能は晒しません。既に対応しています。

上記例のような統合作業を今までは我々人間が行い、その上で意思決定を行なっていました。
統合作業の工程は単純作業であり、時間もかかります。

生成AIが便利道具を使えるようになり、データの孤立化が見事解消されたわけです。

さいごに

OpenAI社がMCPを受け入れたことによって、これまでバラバラだった足並みが揃いました。
今後エンジニアにとどまらず、非エンジニアの方々にもデータの統一化が浸透するでしょう。
そうなった場合、視座高くビジネスを展開している方は、意思決定が比類ない速度で加速しますし、そうでない方も、今まで見落としていた些細な欠片が、データの統合によって重要な示唆を与えてくれる局面が来ると確信しています。

MCPという単語それ自体や、初見で理解することは難解ですが、必ずやあなたを幸福へと導く代物です。

是非この機会に、あなたのお側においてみるのはいかがでしょうか。

Discussion