【MCP とは？】API の仕様から一つ一つ紐解くMCP 入門

by 杉本和也 | May 30, 2025

こんにちは。CData Software Japan の杉本です。

今月CData でも早速提供を開始したMCP Server（https://jp.cdata.com/ai/）ですが、まだなかなかその仕組みや仕様についてしっかりと理解できていない、LLM やAI エージェントとMCP がどのようにやり取りをしているか、イメージが追いついていないという方は多いのではないでしょうか。

そこで今回の記事ではMCP とはなんぞや？という部分をAPI の仕様に基づきながら解説していきたいと思います。

MCP とは？

MCP（Model Context Protocol）とはAI プラットフォーム「Claude」を提供するAnthropic が開発しオープンソースとして公開した「アプリケーションがLLM（大規模言語モデル）にコンテキストを提供する方法を標準化するオープンプロトコル」です。

https://modelcontextprotocol.io/introduction

https://www.anthropic.com/news/model-context-protocol

この言葉だけ見ると「なんのこっちゃ？」という感じですよね。

「MCPとはLLM・AI アプリケーションにとってのUSB Type-C のようなもの」と表現されています。

通常AI アプリケーションは自身のナレッジに基づいて、何かしらの回答を生成します。
でも、ナレッジに存在しない情報、例えば「私達のデスクトップマシンに存在するファイル」であったり、「普段ビジネス用途で利用するクラウドサービスのデータ」などに基づいた回答を生成することはできません。

しかしながら、AI アプリケーションに対して「ここにこんなデータがあるよ」「このサービスを使うとメールが送付できるよ」という機能（ここではツールと呼びます）を提示してあげることで、AI はユーザーに対する回答を生成するにあたって、そのツールを使って回答やアクションを行ってくれるようになります。

このAI とツールのやり取りを標準化したものが「MCP」です。

実はMCP の登場前からこのような仕組み（Function Calling：https://platform.openai.com/docs/guides/function-calling?api-mode=chat）は存在しました。

でも、その仕組は色んな人が色んな形式で作れてしまうという課題がありました。例えば、同じカレンダーサービスのGoogle Calendar を使った時のように、Microsoft 365のOutlook カレンダーを使いたい、と思っても同じようにAI アプリケーションが活用することはできませんでした。

いわゆるガラケーがたくさん溢れてしまうような、ガラパゴス状態と言っても良いでしょう。

上記はカレンダーを例として上げましたが、世の中には数多くのサービス・プロダクトが存在し、色んなところに私達が活用したいデータやアプリケーションが存在します。でも、それら一つ一つにAI アプリケーションが利用できるようにツールを整備するのは車輪の再発明を繰り返すようなもので、簡単なことではありません。

そこでMCP の出番です。

MCP という共通規格が存在することで、AI アプリケーションはその裏側にどんなサービスやプロダクトが存在しても、同じように利用することができるようになります。

「USB Type-C のようなもの」というのがここでよくわかります。パソコンにとってUSB Type-C の先にあるプロダクトはプリンターであったり、スキャナーであったり、ストレージであったりと多種多様ですが、USB Type-C という規格を通じて同じように接続して、同じように利用することができます。

もうちょっと詳しくMCP の仕様を紐解く

ここまではだいぶ簡略化して紹介してきたので、ここで詳しくMCPの仕組みを成り立たせるための登場人物を整理しましょう。

このMCP の仕組みを成り立たせているのは、実際にAI アプリケーションを利用するユーザーを除くと、まずは「AI Platform」「LLM」、そして「MCP Client」「MCP Server」、そのMCP裏側に存在する「Service」の5種類です。

まずは「AI Platform」です。AI のモデルおよびモデルとやり取りするためのAPI、モデルの開発、チャットインターフェースのクライアントなどを提供しているものです。

代表的なサービスとしてはOpenAI やClaude、Amazon Bedrock などが挙げられます。

続いて「LLM」です。AI プラットフォームと混同しがちですが、私達がユースケースなどに応じて、モデルを選択できるように、AI プラットフォームとLLM は独立した存在です。もちろん、サービスによっては統合された状態で提供されることから、同一のものとみなす場合もありますが。

GPT シリーズやClaude だけでも 3.7 や 3.5 といったバージョンが利用できますね。

ここからMCP 側に入ります。

まずMCPの裏側で利用される「Service」です。あえてService と記載していますが、これは例えばローカルのファイルやRDB、Salesforce などのクラウドサービスなど、AI を通じて利用したいものはどんなものでも対象になります。

MCP は「MCP Client」と「MCP Server」の2種類で成り立っています。

「MCP Client」はMCP の機能をサポートしているチャットインターフェースなどを指します。例えばClaude Desktop やVS Code Copilot などがありますね。

以下のページに利用可能なMCP Client の一覧があります。

https://modelcontextprotocol.io/clients

最後に今回の記事のメインとも言える「MCP Server」です。ここが、スタンダードな規格（MCP）を通じて
Service の機能をAI アプリケーション（MCP Client）に公開するプログラムとなります。

MCP の仕組み・MCP を使ったメッセージの生成プロセスを詳しく見てみる

それでは、実際にMCP を使って、LLM がどのようにユーザーに解答を返すのか？そのプロセスを細かく追ってみたいと思います。

ここではGoogle Calendar などのスケジュール管理サービスのMCP Server を利用するという想定で進めたいと思います。

最初のステップはMCP Client の起動とツールの確認です。ここでMCP Client は現在どんなツールが利用できるのか？をMCP Server に問い合わせします。ここでMCP Server は自身が持つツールの一覧を提供します。

使えるツールが把握できた状態で、MCP Client はユーザーとの対話を開始します。ここでユーザーから「来週の空いている予定を教えて」と質問が来たとします。

ユーザーからの質問を受け取ったあと、MCP Client はAI Platform に対して、ユーザーからの質問と現在利用できるツールの情報を送ります。このツールの情報というのが、MCP Server から事前に把握したツール一覧になります。

AI Platform はユーザーからのメッセージとツールの情報をLLM に与えます。イメージとしては、この質問に解答してください、でももし解答が難しい場合はこんなツールでサポートできるよ、という補足を送ってあげている感じですね。

LLM は自身のナレッジに無いデータについては解答することができません。ですので、通常であれば「うーん、わからないから自分でカレンダーアプリを立ち上げて調べてみてね」みたいな解答で終わらせてしまいます。

しかし、今回は利用できそうなツールがあるということを、事前に受け取ったツールの一覧から把握して、「このツールを使えば解答できそう！ちょっとこのツール使ってみてくれる？」という返信をMCP Client 側に返します。

MCP Client はAI Platform からの解答で「このツールを利用してくれ」という解答を受け取ったので、その解答に基づいてMCP Server に問い合わせをかけます。

ここでポイントなのが「LLM」と「MCP Server」が直接コミュニケーションを取っているわけではない、ということですね。あくまでMCP Client が介在して、やり取りを補足しています。

このMCP Client からのリクエストを受け取って、MCP Server は利用できるツールや条件を把握し、裏側のサービス、いわゆるWeb API などに問い合わせを行います。

このMCP Server からService の問い合わせ結果に基づいて、MCP Server からMCP Client に予定データの結果を返します。

これでMCP Client としてデータは取得できましたが、この結果をさらにLLM 側に渡してあげます。過去のメッセージのやり取りと共に、ツールから取得した結果を渡してあげているイメージです。

ここでようやくLLM はユーザーの予定というものをコンテキストとして把握できます。ここではユーザーの予定が2件ある、ということが把握できたので、その情報を元にメッセージを生成し、MCP Client に返却、ユーザーへ結果を表示します。

このようなプロセスでMCP というやり取りが成り立っているんですね。

Claude Desktop を使ってMCP Server を動かしてみる

それでは一つシンプルなMCP Server を動かしてみましょう。

今回はファイルシステムにアクセスできるMCP Server を利用します。

https://github.com/modelcontextprotocol/servers/tree/main/src/filesystem

このMCP Server はNode.js で動くので、あらかじめローカルにNode.js、npx コマンドが通るように設定しておきましょう。

https://nodejs.org/ja

対象のフォルダは「C:\MCP」で作成しました。

それではClaude でMCP Server を使う設定を追加していきましょう。

Claude を立ち上げて「設定」に移動し

「構成を編集」をクリックします。

「claude_desktop_config.json」というファイルを編集することで、MCP Server の機能を追加できます。

デフォルトでは以下のようになっているので

このように書き換えます。

書き換えたあと、Claude を再起動することで、以下のようにチャットメニューにfilesystem のMCP Server が追加されます。

中身を詳しく見てみると、read_file やwrite_file といった機能・ツールが利用できることが確認できますね。

では、簡単ですが「MCP フォルダにあるファイルの一覧を教えて」と打ってみます。

質問に対して、MCP Server を利用する必要がある場合は、あらかじめ利用希望の許諾画面が表示されます。これを許可することで、MCP Server の機能が利用されるようになります。

これで以下のようにMCP Server の機能を使いながらファイルの一覧の取得が達成できました。

実際のMCP の仕様を紐解く

前置きが随分長かったですが、ここからは実際のMCP Server とどんなやり取りをしているのか、API 仕様の側面から確認していきたいと思います。ちょっとここから技術的に深くなりますので要注意。

MCP Server ですが、通信方法は標準入出力を使った方式の「Stdio」と「HTTP・SSE（Server Sent-Event、いわゆるHTTP POST リクエスト）」の2種類がサポートされています。HTTP の仕組みは現在リモートMCP とも呼ばれていますが、基本的な仕組みはどちらも同じです。今回の記事ではStdio をメインに解説します。

https://modelcontextprotocol.io/docs/concepts/architecture#best-practices

やり取りするデータのフォーマットとしては「JSON-RPC 2.0」を採用しています。

例えばツールの一覧を取得するためのリクエストは以下のような内容になっています。

ちなみに「Stdio」ということは、そうですコマンドプロンプトからもMCP Server は検証できます。

例として、以下のようにコマンドプロンプトから実行してみましょう。

> npx @modelcontextprotocol/server-filesystem C:\MCP

そして、ツール一覧を取得するためのJSON-RPC のリクエストを貼り付けます。

> {"jsonrpc": "2.0","id": "request-123","method": "tools/list","params": {}}

すると、以下のように結果が表示されます。これがツールの一覧に関するMCP Server からのレスポンスです。

フォーマットすると見やすいですね。

とはいえ、JSON-RPC のテキストを毎回作り込むのは大変なので、MCP Inspector もしくはPostman を使うのがおすすめです。これらのツールを利用するとUIベースでわかりやすく、MCP Server の操作、動作検証が可能です。

https://github.com/modelcontextprotocol/inspector

https://qiita.com/nagix/items/712672a7bc741eef03aa

今回はPostman を使って検証してみましょう。

動作確認に使うのはFilesystem を探索するMCP Server です。

https://github.com/modelcontextprotocol/servers/tree/main/src/filesystem

あらかじめ「C:\MCP」というディレクトリを作っておきました。

Postman を立ち上げて、新しいリクエストとして「MCP」を選択します。

STDIO を選択し、「npx @modelcontextprotocol/server-filesystem C:\MCP」と入力します。

すると、以下のようにツールの一覧が表示されます。これがイニシャライズプロセスですね。

例えばツールの一覧から対象のディレクトリに存在するファイルの一覧を取得するツールである「list_directory」を使ってみます。パラメータのPath には「C:\MCP」を指定します。

これで「Run」ボタンを実行すると「[FILE] Sample1.txt\n[FILE] Sample2.txt\n[DIR] SampleFolder」というテキストデータが取得できました！

Timeline タブを見てみると、実際のJSON-RPC のやり取りが確認できます。

最初に以下のリクエストを送っていて、methodとして「tools/call」で、パラメータとしてツールの名称である「list_directory」、引数にディレクトリのパスが指定されていることがわかります。

そして、レスポンスとして、以下のような結果を受け取ります。

これがMCP Server のインターフェースの基本的な仕様、流れになります。

これを見てもらえば分かる通り、MCP Server というのはシンプルなAPI の一種のようなものであることがわかりますね。

AI Platform とのプロセスを確認してみる

それでは今度は逆にMCP Client がどのようにAI Platform・LLM に対してメッセージを送信しているのかを確認してみましょう。

今回はAI Platform として「Claude API」、LLM は「claude-3-7-sonnet-20250219」を利用します。

https://docs.anthropic.com/en/docs/build-with-claude/tool-use/overview

Postman ではClaude API のCollection が公開されているのでこれを利用しました。

https://www.postman.com/postman/anthropic-apis/documentation/dhus72s/claude-api

Claude API を利用するための開発者アカウントにサインアップして、あらかじめSecret key を取得しておきます。

これを元に「Messages」のエンドポイントに、URLやModelのバージョン、SecretKey を変数として設定し、リクエストしてやりとりを進めます。

まず最初のリクエストです。先程MCP Server を利用した時と同様に「list_directory」のツールを利用するケースを想定して進めます。

すでにMCP Client はMCP Server から利用できるツールの情報を受け取っており、その情報を元にユーザーから「MCPフォルダにあるファイルの一覧を教えて」という質問を受け取ったタイミングでのリクエストです。

MCP Client からAI Platform・LLM に以下のようなリクエストを送ります。messages のオブジェクトにユーザーから受け取った質問が入っているのがわかりますね。

このリクエストの結果が以下の通りとなります。LLMの返信メッセージと共に、ツールを使いたいというリクエスト「tool_use」と対象のツール名、パラメータが指定されていることがわかります。

MCP Client はこのツールを使いたいというリクエストをMCP Server に送り、結果を受け取ります。その後、改めてLLM側にMCP Server からの結果を含めて、最終的な回答をください、とリクエストを送ります。

このプロセスを経て、最終的な回答が以下のようになります。MCP Server からの結果に基づきながら、LLMが文章を生成していることがわかりますね。

このプロセスを見ると、LLMが直接MCP Server とやり取りして、何かを学習しているのではなく、あくまでMCP Client を介したテキストに基づきながら、メッセージを生成していることがわかります。

おわりに

どうしてもMCPというプロトコルは登場人物が多く、理解するのに混乱してしまいがちです。

でも、こうやって一つ一つのリクエスト・レスポンスを分解すると、それぞれの責務やセキュリティ的に何に注意しなければいけないのかがわかってきますね。

とはいえ、文章だけだとわかりにくいなーという方は、以下のイベントでデモなども含めながら解説する予定なので、ぜひ参加してみてください！

https://jp.cdata.com/resources/cdatamcpservers-20250617/

Blog