7月29日、Towards Data Scienceが「MCP Explained: How Modern AI Agents Connect to the Real World」と題した記事を公開した。この記事では、AIエージェントが外部ツールと連携する際の統一プロトコル「Model Context Protocol（MCP）」の仕組みと実装方法について詳しく紹介されている。
「M×N問題」：カスタム統合が抱える根本的なスケール問題
AIエージェントに外部ツールを接続する際、従来はモデルとツールの組み合わせごとにカスタム統合コードを書く必要があった。モデルが3つ、ツールが10種類あれば、最大で30本の統合コードが必要になる計算だ。どれか1つの仕様が変われば、関連する統合コードがすべて壊れるリスクがある。
これは「M×N問題」と呼ばれる。M個のモデルとN個のツールが存在する場合、M×N本のカスタム統合が必要になるという構造的な問題だ。
記事ではこれをUSBの普及前のコンピュータ周辺機器に例えている。プリンタや鍵盤がそれぞれ独自のコネクタを持ち、特定のコンピュータにしか繋がらなかった時代と同じ状況だ。USBという統一規格が登場して初めて「どのデバイスでも、どのPCでも繋がる」世界になった。MCPはAIエージェントにおけるそのUSBに相当する。
MCPの基本構造：Host・Client・Server
Model Context Protocol（MCP）はAnthropicが開発し、2024年11月にオープンソースとして公開したプロトコルだ。アーキテクチャは以下の3要素で構成される。
- Host：ユーザーが直接操作するAIアプリケーション（Claude Desktop、VS Code拡張など）。モデルのコンテキストウィンドウを管理し、ツール呼び出しのタイミングを制御する。
- Client：Host内部に存在し、MCPサーバーとの接続を管理するコンポーネント。MCPプロトコルの実装部分にあたる。
- Server：実際のツールやデータが置かれる場所。LLMとは直接通信せず、必ずClientを介して通信する。
MCPサーバーが公開できる「ケイパビリティ」は3種類ある。
- Tools：データベースへのクエリ、メール送信、API呼び出しなど、実行可能な操作。結果をモデルに返す。セキュリティ上の考慮が最も必要な要素でもある。
- Resources：ファイル内容やDBレコードなど、読み取り専用のデータアクセス。状態を変更しない。
- Prompts：コードレビューの多ステップワークフローのように、複数のステップや条件分岐を含む処理を1つのテンプレートとして定義し、繰り返し呼び出せる再利用可能なプロンプトテンプレート。ホストやクライアントがユーザーにサジェストする用途でも使われる。
PythonでのMCPサーバー実装：これだけでいい
記事では、公式MCP SDKを使った最小構成のサーバー実装が紹介されている。天気情報を返すツールを例に、実際のコードを見てみよう。
from mcp.server.fastmcp import FastMCP
import requests
mcp = FastMCP("weather-server")
@mcp.tool()
def get_current_weather(city: str, unit: str = "celsius") -> dict:
"""Get the current weather for a given city using Open-Meteo."""
geo = requests.get(
"https://geocoding-api.open-meteo.com/v1/search",
params={"name": city, "count": 1}
).json()
lat = geo["results"][0]["latitude"]
lon = geo["results"][0]["longitude"]
weather = requests.get(
"https://api.open-meteo.com/v1/forecast",
params={
"latitude": lat,
"longitude": lon,
"current": "temperature_2m,weather_code",
"temperature_unit": unit
}
).json()
return {
"city": city,
"temperature": weather["current"]["temperature_2m"],
"unit": unit
}
if __name__ == "__main__":
mcp.run()
ポイントは@mcp.tool()デコレータだ。型ヒントからJSONスキーマを自動生成し、MCP対応のホストからディスカバリー可能な状態にする。モデル固有のアダプタコードは一切不要だ。
クライアント側は以下のように実装する。実行時にサーバーが公開しているツール一覧を動的に取得できる点が重要だ。
from anthropic import Anthropic
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client
async def run_agent_with_mcp():
server_params = StdioServerParameters(
command="python",
args=["weather_server.py"]
)
async with stdio_client(server_params) as (read, write):
async with ClientSession(read, write) as session:
tools = await session.list_tools()
print(f"Available tools: {[t.name for t in tools.tools]}")
# Available tools: ['get_current_weather']
result = await session.call_tool(
"get_current_weather",
arguments={"city": "Athens", "unit": "celsius"}
)
print(result.content)
# {'city': 'Athens', 'temperature': 29.0, 'unit': 'celsius'}
ハードコードされた統合コードから、動的にディスカバリー可能なケイパビリティへ——これがMCPがもたらす本質的な変化だ。
急速な普及と標準化の流れ
MCPの採用状況は数字が示している。2024年11月のローンチ時は月間SDKダウンロード数が約10万件だったが、2025年3月にOpenAIが公式採用、同年4月にはGoogleがGeminiへのMCPサポートを表明し「AIエージェント時代のオープンスタンダードになりつつある」と述べた。2025年3月時点でPythonとTypeScriptのSDKの合計月間ダウンロード数は9,700万件に達している。
2025年12月にはAnthropicがMCPをAgentic AI Foundation（AAIF）に寄贈した。AAIFはLinux Foundationの傘下に設立された組織だ。KubernetesやPyTorchと同じLinux Foundationのポートフォリオに加わったことで、単一ベンダーのプロジェクトではなくなった。
現在はMCP Registryを通じてGitHub、Slack、PostgreSQL、Docker、Kubernetesなど数百のMCPサーバーが公開されており、既存のものを使う場合は「エンジニアリングの問題」ではなく「設定の問題」になりつつある。
セキュリティ：見落としてはいけない3つのリスク
MCPがツールへのアクセスを広げる分、セキュリティリスクも伴う。記事が挙げる主な懸念点は以下の3つだ。
- プロンプトインジェクション：悪意のあるデータソースがモデルを操作するコンテンツを返し、意図しないツール呼び出しを誘発するリスク。サポートチケットやCRMノートのようなユーザー生成コンテンツを扱う場合に特に注意が必要だ。
- ツールポイズニング：不正なMCPサーバーが信頼されたツール名に似た名前でツールを登録し、モデルが誤ったツールを選択するリスク。
- 過剰な権限付与：読み取りしか必要ないエージェントに読み書き両方のツールを公開することで生じる不要なリスク。
MCPの公式仕様では、HostはツールをInvokeする前に必ずユーザーの明示的な同意を得ることが求められている。本番環境では、外部APIと同等の厳格さ——最小権限の原則、入力検証、ツール出力のサニタイズ——を適用することが推奨されている。
MCPが解いたのは「どうやってエージェントをツールに接続するか」という配管の問題だ。記事の著者が指摘するように、これからの問いは「エージェントに何をさせるべきか」「エージェントの動作をどう評価するか」「人間の監督をどう維持するか」に移っていくとされている。
詳細はMCP Explained: How Modern AI Agents Connect to the Real Worldを参照していただきたい。
