AI 2026年4月24日

MCPとは何か——AIエージェントの「USB-C」が業界標準になるまで

MCPって何の話？　30秒で掴む全体像

MCP（Model Context Protocol）は、LLM（大規模言語モデル）とデータソース・外部ツールを標準化された方法で接続するためのオープンプロトコルだ。

2024年末にAnthropicが発表した。一言で言えば「AIエージェントのための共通の差し込み口」。記事内では「AIのためのUSB-C」という表現が使われており、これが一番わかりやすい。

「プロトコル」と聞くと難しそうだが、やっていることはシンプルだ。AIがGitHubを操作したい、データベースを読みたい、ファイルを開きたい——そういった外部連携を、毎回アプリごとにゼロから実装しなくて済むようにする仕組み、それがMCPだ。

なぜ今これが重要なのか

2026年現在、OpenAI・Google・Microsoftの3社がMCPの採用を表明している。Anthropicが出したプロトコルに競合他社が乗っかった——これは珍しい動きで、それだけ「標準化への需要」が業界全体で切実だったことを示している。

従来はこんな状況だった。

LLM → [独自API実装A] → ファイルシステム
LLM → [独自API実装B] → データベース
LLM → [独自API実装C] → GitHub

アプリが増えるたびに独自実装が増え、保守コストが膨らむ。どこかの実装が変われば連鎖的に壊れる。AIエージェント開発の現場で「配線工事」に時間を取られてきた人間には刺さる構図だ。

MCPはこれを次の形に変える。

LLM（ホスト） ←→ MCPクライアント ←→ MCPサーバー ←→ データソース
                    （標準プロトコル）

一度MCPサーバーを作れば、それに対応したどのホストアプリからでも使える。Claude Desktopで動いたMCPサーバーは、CursorでもCopilotでも再利用できる。これが「USB-C」の比喩が指している本質だ。

MCPの構造を整理する

MCPには3つの登場人物がいる。

概念	役割
MCPホスト	LLMを実行するアプリ（Claude Desktop、Cursor等）
MCPクライアント	ホスト内でサーバーと通信するコンポーネント
MCPサーバー	データソースへのアクセスを提供する軽量プログラム

そしてMCPサーバーが提供できる機能は、3種類のプリミティブに整理されている。

① Tools（ツール）

LLMが呼び出せる関数。副作用がある（データ変更・API呼び出しなど）。たとえばGitHubにIssueを作成する処理がこれにあたる。

② Resources（リソース）

LLMが読み取るデータ。副作用なし。ファイルの内容、DBのレコード、APIレスポンスなど「参照するだけ」のもの。

③ Prompts（プロンプト）

再利用可能なプロンプトテンプレート。コードレビューのプロンプトをサーバー側で管理しておき、複数のクライアントから呼び出す、といった使い方ができる。

この3分類はよく考えられている。「副作用あり／なし」で責務が明確に分かれており、LLMが何をしようとしているかをシステム側が把握しやすい設計だ。

AIおじさんの見方：「標準化」が本当に意味すること

USB-Cの比喩は巧みだが、もう少し掘り下げたい。

USB-Cが本当に価値を発揮したのは、「規格が普及した後」だ。対応デバイスが増えて初めて「どこでも使える」になった。MCPも同じで、OpenAI・Google・Microsoftが乗った今、対応サーバーを作ることの価値が急激に上がっている。

裏返して言うと、MCPサーバーを持つサービスはあらゆるAIエージェントから呼び出し可能になる。SaaS企業にとっては「MCPサーバーを公式提供しているか否か」がAIエージェント時代の接続性を左右する、とも言える。

もう一つ気になる点がある。プロトコルの標準化は、ツールの「コモディティ化」を加速させる。差し込み口が共通になれば、どのMCPサーバーを使うかは「機能と品質」で選ばれる。ここで競争の軸がずれる。標準化は開発者にとって福音だが、特定のベンダーロックインで食べていた企業には圧力になる。

実務的な示唆：開発者は何をすべきか

実装のハードルは低い。Python SDKはpip install mcpの一行で入る。

シンプルなMCPサーバーの骨格はこんな形だ。

from mcp.server import Server
from mcp.server.stdio import stdio_server
import mcp.types as types

app = Server("my-mcp-server")

@app.list_tools()
async def list_tools() -> list[types.Tool]:
    return [
        types.Tool(
            name="get_weather",
            description="指定した都市の天気を取得する",
            inputSchema={
                "type": "object",
                "properties": {
                    "city": {"type": "string", "description": "都市名"}
                },
                "required": ["city"]
            }
        )
    ]

@app.list_tools()でツールを定義し、@app.call_tool()で実際の処理を書く。構造は単純で、既存のAPIラッパーをMCPサーバーとして包み直すだけでも実用になる。

通信方式（トランスポート）はstdio・SSE・HTTPの3種類。ローカル開発はstdioで十分で、リモートサービスに公開するならHTTPベースを選ぶ形になる。

実務上の論点は「どのMCPサーバーを選ぶか」の目利きだ。エコシステムが広がるほど玉石混交になる。セキュリティ面（外部サーバーにどこまでアクセスを渡すか）の設計判断は、導入前に一度きちんと考えておく必要がある。ツールが副作用を持つ以上、誤った呼び出しの影響範囲は想定しておきたい。