MCPアーキテクチャを図解で理解する初心者向けガイド

著者

0 分で読めます

Model Context Protocol（MCP）は、大規模言語モデルの可能性を大きく広げました。一方で、少し分かりにくい部分も生まれています。そこで、図などを使ってMCPアーキテクチャの仕組みを視覚的に理解できる、初心者向けのガイドを作ることにしました。

開発者であれば、CursorやWindsurf、さらにはVS Codeの新しいエージェント型ワークフローなどで、MCP Serverがエージェント型ソフトウェア開発をけん引していることを耳にしたことがあるでしょう。しかし、MCP Serverの用途はソフトウェア開発にとどまりません。モデルが学習データ以外の情報も活用し、推論能力を使ってアクションを実行できるようにすることで、エンドユーザーにシームレスで豊かなLLM体験を提供します。

MCPを理解する

LLMは基本的に、学習に使われたあらゆるデータを圧縮した知識ベースです。人間の脳の働きから少し着想を得て、ニューラルネットワークという類似の概念を通じて学習します。これにより、知性を感じさせる推論や大きな論理的飛躍が可能になります。大規模言語モデルは非常に優れていますが、それでも自身のデータの範囲に制約されます。

MCPは、LLMが持つ知識や能力の範囲を超えた情報やアクションへとつなぐ橋渡し役です。OpenAIが少し前に導入した関数呼び出しやツール呼び出し機能ですでに実現していたと言う人もいるでしょう。しかしMCPは、その概念を発展させ、オープンな通信標準と、構造化されたインターフェースを基盤とし、分散型かつ動的なツールのデプロイと検出を可能にしました。MCPと関数呼び出しの違いについては、後ほど詳しく説明します。

MCP Host、MCP Client、MCP Server

MCPの目的を説明したところで、次はMCPを構成する要素を詳しく見ていきましょう。MCPは、基本的に次の3つの要素で構成されます。

MCP Hostは、MCPと連携するAI搭載アプリケーションです。Claude Desktop、Cursor、Windsurf、VS Codeなどが具体例です。これらのアプリケーションは、MCP Clientを実装することでMCPと連携します。
MCP Client：MCP Clientは、AI搭載の高機能なアプリケーションやエージェント型フレームワークなどに組み込まれる、基盤となる実装レイヤーです。MCP Serverと通信するためのインターフェースです。
MCP Server：MCP Serverは、「外の世界」の機能を提供する要素です。LLMはローカルファイルを持っていませんよね。しかし、MCP Serverがファイルを利用可能にすれば、LLMはファイルの一覧表示、読み取り、操作ができるようになります。MCP Serverは、LLMが利用できるようになる拡張機能、知識、アクションを実装します。

MCPサーバーは、コンテキストの拡張とツール呼び出しにRAGを活用する例を示しています

注：MCP Hostは、MCP Clientが実質的にAI搭載アプリケーションを指すように、その呼び名が1つ上のレイヤーを表す用語として使われるようになったため、単にMCP Clientと呼ばれることもよくあります。

関数呼び出しとツールの概要

MCP Serverは通常、MCP Clientが利用できるツールを提供します。たとえば、「ファイルを読み取る」や「リモートGitリポジトリのブランチをすべて一覧表示する」といったツールがあります。

どのように実現するのでしょうか。LLMに、「利用できるツールはこちらです。たとえばread_fileというツールがあります」と伝えます。するとLLMは、Model Context Protocolを介してそのツールを具体的に呼び出せます。その呼び出しは、MCP Serverのコード内にある実際の関数実装へとつながります。

function tool_read_file(filepath) {
   // implementation
}

しかし、ツール自体は新しいものではありません。ツール呼び出しは、別名関数呼び出しとも呼ばれ、OpenAIによって2023年後半に導入されました。その後、関数呼び出しは各AI搭載アプリケーションに実装され、アプリケーションがLLM向けに個別に調整する必要がありました。さらに重要なのは、すべてのモデルが関数呼び出しに対応していたわけではないことです。

後ほど、MCPが関数呼び出しよりも包括的なソリューションを提供する理由を説明します。

MCP Serverのトランスポート方式：STDIOとHTTP

MCP Serverと聞くと、実際のネットワークサーバーを思い浮かべるかもしれません。しかし、MCPが広く使われるようになった背景には、標準入力と標準出力を介して通信するローカルプロセスがあります。

STDIOとは？

STDIO（標準入力、標準出力、標準エラー出力）は、システムプロセス間でテキストベースの通信を行う基本的な仕組みです。ここでいうプロセスとは、コマンドやプログラムのことで、たとえばコマンドプロンプトでgitを実行する場合などが該当します。

プログラムが実行されると、オペレーティングシステムによって3つの既定のチャネルが確立されます。入力を受け取るstdin（通常はキーボードまたは別のプログラムの出力）、通常の出力を行うstdout（通常はターミナルまたはファイル）、そしてエラーや診断メッセージを出力するstderr（通常はターミナルですが、別に出力されることもあります）です。

つまり、STDIOを使うと、プログラムはオペレーティングシステムや他のプログラムとやり取りできます。たとえば、あるコマンドの出力（stdout）を別のコマンドの入力（stdin）にパイプで渡せます。同様に、プログラムのstdoutやstderrをファイルにリダイレクトして、記録や後からの確認に使うこともできます。多くのコマンドラインツールは、データ処理パイプラインや基本的なやり取りにSTDIOを多用しています。

MCP Serverのようなクライアント・サーバー型のシステムでは、STDIOをシンプルな通信手段として利用できます。MCP Serverを、リクエストを受け取り（stdin経由）、テキスト形式の応答をMCP Clientに返す（stdout経由）プロセスとして動作させます。

LLM、MCPクライアント、およびSTDIOとHTTP/SSRを介したModel Context Protocolを示す、MCPアーキテクチャの図

ローカルSTDIO MCP Server

通信にSTDIOを使用するMCP Serverは、実行中のプロセスに依存します。そのため、ほとんどの場合、ローカルで実行し、ローカルにインストールするMCP Serverとして構成されていました。

そのため、多くのAI搭載アプリケーション（別名MCP Host）では、プロセスの実行方法を指定するMCP Serverの定義をユーザーに求めていました。以下は、Cursorのmcp.jsonにあるMCP Server定義の簡単な例です。

// This example demonstrated an MCP server using the stdio format
// Cursor automatically runs this process for you
// This uses a Node.js server, ran with `npx`
{
  "mcpServers": {
    "server-name": {
      "command": "npx",
      "args": ["-y", "mcp-server"],
      "env": {
        "API_KEY": "value"
      }
    }
  }
}

MCP Serverをクラウドでスケールさせる

AIアプリケーションでHTTPトランスポート方式が広く採用され、MCP ServerをホストするVercelやCloudflareなどのクラウドインフラがサポートされるようになったことで、MCP Serverは本来期待されていた力を発揮できるようになりました。

当初、MCP ServerはネットワークベースのHTTPトランスポートを導入し、SSE（Server-Sent Events）という仕組みでLLMとMCP Server間のメッセージを同期・調整していました。しかし、WebSocketと同様に、SSEには長時間稼働するサーバーが必要です。Vercel FunctionsやAWS Lambdaなど、最新のデプロイプラットフォームでは、こうしたサーバーを利用しにくい場合があります。そこで、新しいStreamable HTTP仕様が登場し、MCP ServerでサーバーレスHTTPを実現できるようになりました。

HTTPベースのMCP Serverは、複雑なコマンドライン引数の指定が不要で、リモートホストのアドレスだけで設定できるため、構成が簡単です。また、特定の開発環境を用意してローカルでセットアップ・実行する必要がなくなり、MCP Serverを共有して利用しやすくなりました。

たとえばCursorでは、HTTP経由のリモートMCP Serverを次のように簡単に定義できます。

// This example demonstrated an MCP server using the SSE format
// The user should manually setup and run the server
// This could be networked, to allow others to access it too
{
  "mcpServers": {
    "server-name": {
      "url": "http://example.com/sse",
      "env": {
        "API_KEY": "value"
      }
    }
  }
}

MCPアーキテクチャの全体像

ここまで、MCP Client、MCP Server、それらの通信に使うトランスポート方式、そして各要素の具体例を見てきました。これらを踏まえると、MCPのデプロイモデルと全体的なアーキテクチャをより深く理解できます。

MCPアーキテクチャでは、MCPをローカルにもリモートにもデプロイできるため、さまざまな構成やデプロイ戦略が可能です。たとえば、MCPに対応したAIアプリケーション全体をローカルで実行できます。実際の例を見てみましょう。RaycastのようなローカルAIアプリケーションやCursor IDEをインストールし、Ollamaを通じてローカルで実行するLLMをRaycastまたはCursorに指定します。RaycastやCursorはローカルのMCP Clientを実行し、そこにSQLite MCP Serverなど、ファイルベースのデータベースレコードを参照するローカルMCP Serverを設定します。

これは、クラウドやネットワークへの接続が不要で、ノートパソコン上のローカル環境だけで完結するAI搭載アプリケーションの例です。

また、構成を組み合わせることもできます。MCP Serverをクラウドインフラにデプロイし、HTTPトランスポートで利用可能にできます。仕様に従い、MCP ClientとMCP ServerはModel Context Protocolを介して通信するため、両者を完全に切り離すことができます。

さらに、ほとんどのAI搭載アプリケーションでは、MCP Clientの実装をAIアプリケーション自体に組み込んでいますが、これは必須ではありません。MCP ClientをAIアプリケーションから切り離すこともできます。

MCPと関数呼び出しの違い：MCPは単なるAPIラッパーではない理由

MCPを「単なるREST APIラッパー」と見なす人は少なくありません。しかし、それは視野の狭い矮小化した捉え方です。MCPには、AIアプリケーションに適した、より複雑で繊細な仕組みがあります。その理由を見ていきましょう。

MCPとREST APIの混同という大きなテーマに入る前に、2023年以降、OpenAIとそのSDKが提供してきた従来の関数呼び出しとMCPがどのように異なるのか、詳しく知りたい開発者もいるでしょう。

MCPと関数呼び出しの比較

関数呼び出しでは、AI搭載アプリケーションが各ツールを実装する必要がありました。たとえば、CursorのようなAI搭載アプリケーションが「リモートブランチを一覧表示する」Gitツールを実装するケースを考えてみましょう。Cursorのようなアプリケーションはgit ls-remoteコマンドを実行する方法を選ぶかもしれません。一方、Windsurfのような別のAIアプリケーションは、GitHub APIを使うかもしれません。この2つの方法では、開発者体験もエラー処理も異なるものになります。

関数呼び出しのこのような整理不足と標準化の欠如は、異なるAI搭載アプリケーション間でコードやロジックの無用な重複を招きました。

まとめると、従来の関数呼び出しと比べたMCPの違いは、次のとおりです。

関数呼び出しSDKのツールはLLMとの連携にハードコードされていたため、次のような課題がありました。
そのままではスケールできません。一方、MCPではMCP Serverをデプロイし、AIアプリケーションとは独立してスケールできます。
ツールのAIアプリケーションへの実装と、その他のAIアプリケーションロジックとの間に、明確な関心の分離がありません。両者は一体化しています。技術的には、両者の間にラッパーやインターフェースを構築し、JSON-RPC経由で公開することもできます。しかし、それは実質的にMCPを再構築することになります。MCPが提供するのは、まさにそれに加えた機能です。
LLM連携を利用するユーザーが、ツールを簡単に拡張できる方法もありません。関数呼び出しの実装はLLM連携に組み込まれているため、サードパーティ製ツールを拡張できるようにするには、またMCPを一から作り直すことになります。

従来の関数呼び出しは、もともとツールを定義するために導入されたものですが、そのハードコードされた性質はセキュリティ上の懸念も招きます。ツールが実装する危険性のある機密操作が、それらを提供するAIアプリケーションの一部になってしまいます。ツールレベルで安全でないコーディング規約や不適切なセキュリティ対策があれば、AIアプリケーション全体が危険にさらされるおそれがあります。

MCPは、仕様の標準化による課題解決に加え、制御の反転（IoC）に似た仕組みを提供します。これにより、関数呼び出しや拡張機能を個別のサービスに分離できます。

MCPは単なるREST APIラッパーなのか？

MCPを従来のREST APIと同じものと見なすと、AIアプリケーションの構築に伴う複雑さを見落とします。MCPにはREST APIと共通する特徴も多くあります。HTTPで通信し、プロトコルの基盤となる形式にはJSON-RPCを使用します。また、クライアント・サーバーモデルを採用しています。従来のWebアプリケーションと同様に、クライアント側のブラウザーや、APIを利用する他のクライアントに機能を提供するものです。

しかし、MCPは通常のREST APIとは異なる細かさで利用されることが多く、REST APIにはないAIネイティブな機能が求められます。

MCPは運用ではなくユースケースを推進する：つまり、MCPは課題の解決を目指すユースケースを実現するものと考えてください。REST APIエンドポイントは、多くの場合、エンティティとその世界を細かく表現したものです。MCPでは、1つの公開ツール実装が複数のREST APIエンドポイントに対応する、TxE（ツール×エンドポイント）マトリクスが作られることになります。たとえば、Gitリポジトリ用に「get_open_issues」ツールを公開するMCPサーバーは、複数のREST APIエンドポイントを呼び出す必要があるでしょう。1）すべてのオープンイシューを一覧表示する。2）各オープンイシューの参照IDについて、すべてのデータとメタデータを取得する。MCPサーバーは、RESTful APIよりも粒度が粗いことがよくあります。
MCPはWebにとどまらないアクションを実行する：すべてがWebにつながっていると考えがちですが、優れたMCPのデモの多くは、WebやREST API以外との連携を実現しています。たとえば、Claude AIアプリケーションで完全な3Dシーンを作成できる、話題を呼んだBlender MCPのデモは、BlenderのPython APIをベースにしていました。言語固有のAPIを通じてBlenderのユースケースに対応することで、LLMのコーディング推論能力を活用し、より良い結果を得られます。
MCPはLLMをネイティブに活用するが、REST APIは活用しない：MCP仕様では、samplingと呼ばれる機能が定義されています。これにより、MCPサーバーは特定の操作についてLLMに問い合わせることができます。先ほどのGitの例を発展させ、MCPでは可能でも既存のAPIでは実現できない実践的な例を見てみましょう。「セキュリティへの影響が最も大きいオープンイシューを取得する」というものです。REST APIで「セキュリティへの影響が最も大きい」という要件にどう対応できるでしょうか。イシューにセキュリティ-関連のフィルターやタグがなければ、関連情報を取得する方法はありません。一方MCPでは、ツールの実装でオープンイシューの一覧を取得し、「以下のオープンイシューから、セキュリティへの影響が最も大きいものを順に並べたリストをJSON形式で返してください」といったプロンプトでLLMにサンプリングをリクエストできます。すると、LLMは得意分野を活かして詳細な分析結果を提示できます。MCPでは、処理の一環としてLLMを活用できますが、既存のREST API実装にはこの機能がネイティブに備わっていません。サンプリングと双方向のLLM通信は、単なる類似性分析や感情分析にとどまらず、LLMのマルチモデル能力や反復的な改善も活用できます。

MCPに関するセキュリティ上の懸念

MCPにはセキュリティ上の懸念もあります。MCPサーバーが広く利用されることで、次のようなサプライチェーンセキュリティ上の懸念が生じています。

悪意のあるMCPサーバー - MCPサーバーの信頼性をどう確保しますか？MCPサーバーが密かにローカル環境やデプロイ済み環境から機密情報を実行・持ち出した場合、どうなりますか？MCPサーバーにバックドアが仕込まれている可能性はありますか？こうしたセキュリティ上の懸念を、どのように検証すればよいでしょうか？
脆弱なMCPサーバー - MCPサーバーが期待どおりに動作しても、セキュリティの脆弱性や安全でないコーディング上の問題がないとは限りません。MCPサーバーにおける安全でないコーディング手法は、利用側に悪用され、セキュリティ侵害やデータ漏えいにつながる可能性があります。

これらはMCPを取り巻くセキュリティ上の懸念の一例にすぎません。MCPとAIに関するセキュリティリスクは、実践的なバイブコーディングのセキュリティ脆弱性や、プロンプトインジェクションによるLLMの悪用、さらにはChatGPTコーディングのセキュリティリスクにも広がっています。

こうしたAIセキュリティ上の懸念には、ほかにもさまざまなものがあり、AIセキュリティのガードレールとAI生成コードの保護が必要です。Snykはこれらのリスクを軽減します。

AIを活用した開発を安全に進めるためのベストプラクティス

AIを活用した開発のメリットを最大限に生かしながら、潜在的なリスクを効果的に軽減するための、開発者やセキュリティ担当者向けの10のヒントをご紹介します。

詳しく見る

実際に試してみませんか？