はじめに

この記事では、Anthropicが提唱したModel Context Protocol (MCP) について、その概要から具体的な使い方、最新の動向までを自身の勉強を兼ねて解説します。

要点:

MCPは、LLM（大規模言語モデル）と外部システム／ツールを、まるでUSB-Cポートのように標準化して接続するためのオープンプロトコルです。
2024年11月25日にAnthropicによってオープンソース化されました。
従来、LLMと各種ツール（データベース、API、CLIなど）を接続するには個別の開発が必要でしたが（N×M統合問題）、MCPはこの問題を解決し、開発コストを大幅に削減します。
チャットボットやAIエージェントが、様々な外部リソースへシームレスにアクセス可能になります。
MCPサーバーはWebAssembly (WASM) モジュールとしても実装可能で、ブラウザやエッジ環境での利用も容易になります。
最新動向: OpenAIやGoogle DeepMindといった主要プレイヤーもMCPサポートを発表し、業界標準化が加速しています（詳細は後述）。

背景：N×M統合問題

LLMの急速な普及に伴い、これらのモデルを社内のデータベース、DevOpsツール、Web APIといった外部システムと連携させたいというニーズが急増しました。しかし、従来の方法では、接続したいLLM（N種類）とツール（M種類）の組み合わせごとに専用のコネクタ（連携プログラム）を開発する必要があり、その組み合わせは N×M となり、開発・保守コストが膨大になるという課題がありました（N×M統合問題）。

MCP登場前の状況 (N x M 統合問題):

各LLMと各ツールを接続するために、個別のコネクタ開発が必要でした。

この問題を解決するため、AnthropicはLLMと外部ツール間の接続を標準化する単一のプロトコルとしてMCPを提案しました。

Model Context Protocol (MCP) とは：LLMの「USB-Cポート」

MCPは、LLMアプリケーションと外部のデータソースやツールを結びつけるためのオープンプロトコルです。Anthropicにより2024年11月25日にオープンソース化されました。
「USB-Cポート」の比喩の拡張:
- なぜ「USB-C」なのか？ USB-Cは、映像出力、電源供給、データ転送、ネットワーク接続など、様々な機能を持つデバイスを単一の標準化されたコネクタで接続可能にします。
- 同様にMCPは、データベースアクセス、API呼び出し、コマンド実行、ファイル操作といった**多種多様な外部機能（ツールやリソース）を、LLMに対して単一の標準化されたプロトコル（通信手順やデータ形式）**で接続可能にすることを目指しています。
- これにより、物理的な接続ではなくソフトウェア的な接続において、「どのLLM」と「どのツール」を繋ぐ場合でも、同じ「接続方法（MCP）」が利用でき、"プラグアンドプレイ"のような開発の簡便さと高い相互運用性を実現しようとしています。

MCPによる解決策:

MCPサーバーがツールへのアクセスを集約し、LLM側のクライアントは標準化されたプロトコルで接続できます。

仕様やSDKは、Anthropicが管理するメインリポジトリや、関連プロジェクトが集まる modelcontextprotocol Organization で公開されており、コミュニティからのコントリビューションも歓迎されています。

アーキテクチャ

MCPはクライアント–サーバー型のアーキテクチャを採用しています。

基本構成図:

MCPサーバー: 外部ツールやデータソースへのアクセスを提供。ツール（実行可能な操作）やリソース（データ）を公開します。
MCPクライアント: LLMアプリケーション側で動作し、MCPサーバーに接続してツール実行やリソース取得をリクエストします。

通信 (Transport): クライアントとサーバー間の通信方法。以下の方法が定義されています。

トランスポート	プロトコル	特徴	主な用途
`stdio`	JSON-RPC 2.0	標準入出力経由、シンプル	ローカルプロセス間通信
`HTTP + Server-Sent Events (SSE)`	JSON-RPC 2.0	サーバーからクライアントへのプッシュ	ストリーミング応答、通知
`HTTP + WebSockets`	JSON-RPC 2.0	双方向通信、低レイテンシ	対話的なセッション、リアルタイム

JSON-RPCとは？ JSON形式のデータを使って、ネットワーク越しに関数やメソッド（手続き）を呼び出すためのシンプルなルールのことです。MCPでは、これらのトランスポート上でクライアントがサーバーのツールを呼び出す際の標準的なメッセージ形式として採用されています。詳細は公式のJSON-RPC 2.0 Specificationをご参照ください。

MCPサーバーが公開する主な要素の例：

Tools: 外部の機能を呼び出すための定義（例: add_numbers, get_weather, run_sql_query）。
Resources: LLMのコンテキストとして提供できるデータ（例: ドキュメントチャンク、データベースのテーブルスキーマ）。
Prompts: サーバー側で定義された、特定のタスクを実行するためのプロンプトテンプレート。

簡単なコード例 (Python SDK: mcp-sdk)

MCPを利用するためのPython SDKとして、公式から mcp-sdk が提供されています。まずはこれをインストールしましょう。

pip install mcp-sdk

以下は、mcp-sdk を使用し、2つの数値を加算するツールをサーバーが提供し、クライアントがそれを呼び出す簡単な例です。コメントは日本語で追記しています。
※注意: 以下のimport文 (from modelcontext import ...) は、本記事執筆時点（2025年4月）の mcp-sdk パッケージに基づいています。SDKのバージョンアップによりパスが変更される可能性もあるため、実際に使用する際は最新の公式ドキュメントも合わせてご確認ください。

python simple_server.py

# --- サーバー側 (例: simple_server.py) ---
# mcp-sdk パッケージから必要なモジュールを import
from modelcontext import Protocol, Server, Tool, tool
import asyncio

# ツールを提供するクラス
class MyTools:
    # @tool デコレータでMCPツールとして公開
    @tool(description="Adds two numbers together.") # ツールの説明
    def add(self, a: int, b: int) -> int:
        """Adds two integers.""" # 関数のDocstringも説明に使われることがある
        print(f"[サーバー] ツール 'add' を実行中: a={a}, b={b}") # サーバー側のログ
        return a + b

async def run_server():
    # 'MyTools' クラスのツールをプロトコルに登録
    protocol = Protocol(tools=[Tool(MyTools())])
    # 標準入出力で通信するサーバーをインスタンス化
    server = Server(protocol)
    print("[サーバー] MCPサーバーを標準入出力(stdio)で起動します...")
    # サーバーを起動し、クライアントからの接続を待機
    await server.serve_stdio()

if __name__ == "__main__":
    asyncio.run(run_server())

python client.py

# --- クライアント側 (例: client.py) ---
# mcp-sdk パッケージのクライアントモジュールを import
from modelcontext.client import Client
import asyncio

async def run_client():
    # サーバープロセスをコマンドで起動し、標準入出力で接続
    # 実際にはHTTP(s)経由での接続 (Client.from_http) なども一般的
    print("[クライアント] MCPクライアントを起動し、サーバーにstdioで接続します...")
    # Client.from_command はサブプロセスとしてサーバーを起動
    client = await Client.from_command(["python", "simple_server.py"])

    try:
        # サーバーが提供するツールの一覧を取得
        tools = await client.list_tools()
        print("\n[クライアント] 利用可能なツール:", tools)

        # 'add' ツールを引数 a=5, b=7 で実行
        print("\n[クライアント] ツール 'add' を実行します (a=5, b=7)...")
        result = await client.run_tool("add", {"a": 5, "b": 7})
        print("[クライアント] 実行結果:", result)

    finally:
        # クライアントとサーバープロセスを閉じる
        await client.close()
        print("\n[クライアント] クライアントを終了しました。")

if __name__ == "__main__":
    asyncio.run(run_client())

高速なサーバー実装 (FastMCP)

よりパフォーマンスが求められる場合や、既存のWebフレームワークとの統合を考える場合、FastAPIベースの fastmcp パッケージを利用することもできます。

pip install fastmcp "uvicorn[standard]" # fastmcp と ASGIサーバー (uvicorn) をインストール

fastmcp を使うと、FastAPIアプリケーションとしてMCPサーバーを簡単に構築できます。以下に簡単な例を示します。

python fastmcp_server.py

# --- fastmcp を使ったサーバー例 (例: fastmcp_server.py) ---
# fastmcp と FastAPI を import
from fastmcp import McpRouter, tool, Tool
from fastapi import FastAPI
import uvicorn

# (simple_server.py と同様のツールクラスを定義)
class MyTools:
    @tool(description="Adds two numbers together.")
    def add(self, a: int, b: int) -> int:
        """Adds two integers."""
        print(f"[FastMCPサーバー] ツール 'add' を実行中: a={a}, b={b}")
        return a + b

# FastAPIアプリケーションを作成
app = FastAPI(title="My FastMCP Server")

# MCPルーターを作成し、ツールを登録
# 注意: fastmcp を使用する場合、import文は from fastmcp import ... となります。
mcp_router = McpRouter(tools=[Tool(MyTools())])

# FastAPIアプリにMCPルーターを組み込む (デフォルトパスは /mcp)
app.include_router(mcp_router)

# (おまけ: ルートパスに簡単なメッセージを表示)
@app.get("/")
async def root():
    return {"message": "FastMCP server is running. Access tools via /mcp endpoint using an HTTP MCP client."}

# サーバーを起動する場合:
# ターミナルから `uvicorn fastmcp_server:app --reload` コマンドなどで実行します。
# 以下のブロックは、ファイルを直接 `python fastmcp_server.py` で実行した場合の動作です。
if __name__ == "__main__":
    uvicorn.run(app, host="127.0.0.1", port=8000)

このように fastmcp を使うことで、非同期WebフレームワークであるFastAPIの機能を活用しつつ、MCPサーバーを構築できます。クライアント側からは、Client.from_http("http://localhost:8000/mcp") のようにHTTP経由で接続します（mcp-sdkのクライアントがHTTPトランスポートをサポートしている必要があります）。

主な機能とメリット

N×M統合の簡素化: 一度MCPサーバーを構築すれば、どのMCPクライアントからでも標準化された方法でアクセス可能。開発者はLLMやツールの組み合わせごとに接続ロジックを実装する必要がなくなります。
多言語SDK: Python、TypeScript、C#など、主要な言語向けのSDKが提供（または計画）されており、使い慣れた言語で開発できます。
セキュアな実行: ツール実行の権限管理や認証は、外部ツールに直接アクセスするMCPサーバー側で一元的に行うことができます。
再利用性とモジュール性: 作成したMCPサーバー（ツール群）は、様々なLLMアプリケーションやエージェントから再利用可能な独立したコンポーネントとなります。

具体的なユースケース

MCPは、LLMが外部の世界と対話する必要がある様々なシナリオで活用できます。

エンタープライズ:
- 社内ナレッジ検索: 社内ドキュメント（Confluence, Google Driveなど）やデータベース（SQL, NoSQL）をMCPサーバー経由で検索可能にし、LLMが質問応答や要約を生成。
- CRM連携: SalesforceやHubSpotなどの顧客データをMCP Resourceとして提供し、LLMが顧客対応履歴の分析やメール下書き作成を支援。
- DevOps自動化: GitHub APIやJira、CI/CDツール（Jenkins, GitLab CI）をMCP Toolとして公開し、LLMエージェントがコードレビュー依頼の自動作成、チケット起票、デプロイ状況の報告を実行。
個人開発・研究:
- ローカルファイル操作: ローカルのファイルシステムを操作するツールをMCPサーバー化し、LLMに文書整理、データ抽出、コード生成などを指示。
- Web API連携ボット: 天気予報、ニュース、株価、翻訳などの公開APIをMCP Toolにし、定型的な情報収集やタスク実行を自動化。
- スマートホーム連携: 自宅のIoTデバイス（スマートライト、センサーなど）を操作するAPIをMCP Tool化し、自然言語で家電をコントロール。
データ分析:
- データベース接続（run_sqlなど）やデータ分析ライブラリ（Pandas, NumPy）の関数をMCP Toolとして提供し、LLMが自然言語でのデータ抽出・加工・分析・可視化を実行。

既存技術との比較 (LangChainなど)

LLMと外部ツールを連携させる技術として、LangChainやLlamaIndexといったフレームワークも広く使われています。MCPはこれらとどう違うのでしょうか？

特徴	MCP (Model Context Protocol)	LangChain / LlamaIndex
目的	LLMと外部ツールの通信プロトコル標準化	LLMアプリケーション構築フレームワーク
スコープ	ツール/リソース接続のインターフェース定義	データ連携、エージェント、メモリ管理など広範
役割	接続の「規格」「インターフェース」	アプリ開発の「ツールキット」「ライブラリ群」
相互関係	フレームワーク内で利用される基盤技術になりうる	MCPをツール接続の選択肢の一つとして利用可能
強制力	標準プロトコルに従うことを要求	多様な接続方法を許容 (アダプタを提供)
焦点	サーバーとクライアント間の相互運用性	アプリケーション全体の開発効率

簡単に言うと、LangChainなどはLLMアプリを作るための包括的な道具箱（フレームワーク）であり、ツール連携はその機能の一部です。様々なツールへの接続方法（APIクライアント、カスタムコードなど）を提供します。
一方、MCPはそのツール連携部分の**接続方法（プロトコル）**を標準化することに特化しています。「どのようにツールサーバーと通信するか」のルールを定めることで、異なるLLMやアプリケーションが同じツールサーバーを再利用できるようにします。

将来的には、LangChainのようなフレームワークが、多様なツール接続方法の一つとしてMCPをネイティブにサポートし、開発者は標準化されたMCPサーバーをフレームワークから簡単に利用できるようになる可能性があります。MCPは既存のフレームワークと競合するというよりは、エコシステムの一部として共存し、補完し合う関係になることが期待されます。

WebAssembly (WASM) との連携

MCPはWebAssemblyとの親和性も考慮されており、以下のような応用が可能です。

ブラウザ内サーバー実装例: コミュニティによるWASM実装として beekmarks/mcp-wasm などがあります（リポジトリ参照）。これにより、ブラウザ上でローカルファイルアクセスなどのツールを提供するMCPサーバーを動かすことが可能になります。
Servlets (WASMバイナリ): 特定ツール機能をカプセル化した軽量なWASMバイナリとして配布・実行する構想。詳細はmcp.run ブログ参照。
プラグインによる拡張: Rustなどで実装されたMCPサーバーがWASMプラグインをロードして機能を拡張する例（例: tuananh/hyper-mcp）。

ブラウザでの起動例（Vite使用 - mcp-wasm）

# リポジトリをクローン
git clone https://github.com/beekmarks/mcp-wasm.git
cd mcp-wasm
# 依存関係をインストール
npm install
# 開発サーバーを起動
npm run dev

MCPエコシステムの展望

MCPが普及することで、以下のようなエコシステムの形成が期待されます。

AIプラットフォームやフレームワークがMCPをサポートし、開発者は標準化されたサーバーを構築・利用することで、アプリケーション開発が加速します。

MCPの最新動向と今後の展望：主要プレイヤーも採用開始 (2025年4月時点)

MCPは登場から急速に注目を集め、エコシステムの拡大が具体化しています。

認証・プライバシー強化: 今後、OAuth連携やよりきめ細やかなアクセス制御、ゼロトラスト・アーキテクチャに基づく標準化が進む可能性があります。
エッジ環境への展開: WASM化により、スマートフォン、IoTデバイス、ブラウザ拡張機能など、リソースが限られたエッジ環境へのMCPサーバー/クライアントの展開が進む可能性があります。
エコシステムの拡大と業界標準化の加速:
- 当初の「期待される」段階から、実際に主要プレイヤーによる採用が始まっています。
- OpenAI: 2025年3月26日、OpenAIはAssistants API v2においてMCPサポートを発表しました。これにより、開発者はOpenAIのプラットフォーム上でMCP準拠のツールをより標準的な方法で連携できるようになります（発表詳細はOpenAIの公式情報をご確認ください）。
- Google DeepMind: OpenAIの発表に追随する形で、Google DeepMindもMCPのサポートを表明しており、Vertex AIなどのサービスへの統合が進むと考えられます。
- これらの動きにより、MCPは単なる提案に留まらず、LLMと外部ツール連携における業界標準プロトコルとしての地位を確立しつつあります。今後、さらに多くのAI企業、フレームワーク、ツール開発者がMCPに対応していくことが予想され、相互運用性が飛躍的に向上するでしょう。

MCPは、LLMアプリケーション開発における連携の複雑さを解消し、より高度で信頼性の高いAIエージェントやツールの開発を加速させる、非常に重要なプロトコルとなっています。

参考

以上