MCP 97M後に開発者が作るべきもの——標準化の次の競争軸

13分で読める
MCP 97M後に開発者が作るべきもの——標準化の次の競争軸

この記事の結論

MCP（Model Context Protocol）が2026年3月に97Mインストール突破。プロトコル戦争は終わった。次の競争は「何を繋ぐか」。社内専用サーバー・業界垂直サーバーの空白地帯と今週からできるアクションを解説。

MCP（Model Context Protocol）が97Mインストールを超えた。プロトコル戦争は終わった。

でも、正直に言う。この数字を見てから、「で、自分は何をすればいいんだ？」と思った開発者は多いんじゃないか。97Mという規模感は確かに重要だが、それは「採用が広がった」という話だ。「あなたが今週やるべきこと」は別の話だ。

この記事では、MCPが標準になったあと、開発者にとって何が変わり、今何を作るべきかを時系列で整理する。

2024年11月: ゼロからのスタート、月間約200万DL

AnthropicがMCPをオープンソースで公開した。当時の反応は、AIコミュニティの一部での「面白そう」程度だった。

技術的な出発点はこうだ。MCPはJSON-RPC 2.0をベースとし、stdioトランスポート（ローカル）とHTTP+SSEトランスポート（リモート）の2つをサポートした。AIアプリケーションが外部ツール・データソースに繋がるための「標準の配線方法」を提案した。

それまでの状況は、開発者なら身に沁みているはずだ。OpenAIのfunction calling、AnthropicのTool Use、GoogleのFunction Declarations——それぞれ仕様が違う。同じツールをマルチプロバイダーで使おうとすると、統合コードをN倍書く必要があった。MCPはその「M×N問題」をM+Nに変えようとした。

2025年Q1〜Q3: エコシステムの急速な充填

MCP採用の初期は主にAnthropicエコシステムの中だった。Claude Desktop、Claude Code、そして公式SDKが整備された。

同時期に、コミュニティがMCPサーバーを大量に作り始めた。GitHubのMCPサーバーリポジトリが乱立し、Filesystem、Git、PostgreSQL、Slack、Notion——よく使うツールの基本的なMCPサーバーが揃った。

この段階での開発者にとっての意味: まだ「アーリーアダプターの実験場」。プロダクションへの採用は時期尚早とされていた。主なリスクは仕様変更への不安と、サーバー品質のばらつきだった。

2025年12月: Linux財団への移管、ゲームチェンジが起きた

AnthropicがMCPをLinux財団傘下のAgentic AI Foundation（AAIF）に寄贈した。このタイミングを境に、MCPの位置づけが「Anthropicのプロトコル」から「業界標準」に変わった。

なぜこれが重要か。Linux財団の傘下に入ることは、特定ベンダーへの依存リスクが実質ゼロになることを意味する。オープンガバナンス下での標準化は、企業のIT部門が採用を承認するための「お墨付き」になる。

実際、この直後からOpenAI、Google、Microsoft、AWS、Cloudflareが順次MCP対応を発表した。競合プロバイダーがMCPに乗ったことで、プロトコルの中立性が証明された。

2026年3月25日: 97Mインストール突破、エンタープライズ本番採用が始まった

97M月間SDKダウンロードという数字は、単なるダウンロード数ではない。企業のCI/CDパイプラインに組み込まれた回数の積み重ねだ。

同時期に起きていたこと：

  • Q1 2026に企業のAIエージェント展開がパイロットから本番に移行し始めた
  • MCP対応サーバーが5,800本以上に（データベース、CRM、クラウド、DevToolsをカバー）
  • OpenAIが旧Assistants APIを非推奨化し、mid-2026のサンセットを発表（MCPへの移行を促進）
  • Fortune 500の28%が本番環境でMCPを採用していると推定

これは「標準の収束」を意味する。新しいツール統合を作るとき、MCP以外の選択肢を選ぶ理由は急激に少なくなった。

時期 里程標 月間DL数 開発者への意味
2024年11月 MCP公開 約200万 実験可能なプロトコル登場
2025年Q2 コミュニティサーバー1000本超え 約1500万 ツールが揃い始めた
2025年12月 Linux財団移管 約3500万 企業採用の心理的障壁消滅
2026年3月 97M突破 97M プロダクション採用が当たり前に

97M突破後: 本当の競争が始まった

プロトコルが標準化された後、何が起きるか。インターネットの歴史を参照すると分かる。TCP/IPが標準になった後、競争はHTTPサーバーに移り、その後Webアプリケーション、さらにクラウドに移った。

MCPも同じ構造だ。プロトコル自体は標準化された。これからの競争は「何を繋ぐか」に移る。

現在の空白地帯は明確だ:

  • 社内プロプライエタリシステム向けサーバー: デプロイパイプライン、フィーチャーフラグ管理、内部ナレッジベース——公開されているサーバーでは対応できない、各企業固有のシステムのMCPサーバーはほぼ存在しない
  • 業界垂直向けサーバー: 医療の電子カルテシステム、法律の判例データベース、金融の規制データ——汎用サーバーでは対応できない業界固有の接続
  • 複合サーバー: 複数のデータソースを束ねてコンテキストを構成するアグリゲーション層

既存のFunction Callingコードをどうやってすぐ活かすか

「MCPが標準になったなら、今まで書いたFunction Callingコードは捨てるのか？」という声をよく聞く。答えはNoだ。

MCPサーバーの内部でFunction Callingの仕組みを再利用できる。以下は既存のFunction Calling実装をMCPサーバーとして薄くラップする例だ：

# 既存のFunction Calling実装をMCPサーバーとして公開する
# 動作環境: Python 3.11+, mcp>=1.0
# pip install mcp

from mcp.server import Server
from mcp.server.stdio import stdio_server
from mcp.types import Tool, TextContent
import asyncio
import json

server = Server("legacy-tools-bridge")

# ===== 既存コード（変更なし）=====
def search_knowledge_base(query: str, top_k: int = 5) -> list[dict]:
    """既存のベクトル検索実装（変更不要）"""
    # 実際は既存の検索ロジックをそのまま使う
    return [{"doc": f"結果{i}: {query}に関する情報", "score": 0.9 - i*0.1} for i in range(top_k)]

def create_ticket(title: str, priority: str, assignee: str) -> dict:
    """既存のチケット作成処理（変更不要）"""
    return {"ticket_id": "TICKET-001", "status": "created", "title": title}
# ===== 既存コードここまで =====

# MCPアダプター層（追加するだけでよい）
@server.list_tools()
async def list_tools():
    return [
        Tool(
            name="search_knowledge_base",
            description="社内ナレッジベースを検索する",
            inputSchema={
                "type": "object",
                "properties": {
                    "query": {"type": "string", "description": "検索クエリ"},
                    "top_k": {"type": "integer", "description": "取得件数", "default": 5}
                },
                "required": ["query"]
            }
        ),
        Tool(
            name="create_ticket",
            description="サポートチケットを作成する",
            inputSchema={
                "type": "object",
                "properties": {
                    "title": {"type": "string"},
                    "priority": {"type": "string", "enum": ["low", "medium", "high"]},
                    "assignee": {"type": "string"}
                },
                "required": ["title", "priority", "assignee"]
            }
        )
    ]

@server.call_tool()
async def call_tool(name: str, arguments: dict):
    if name == "search_knowledge_base":
        results = search_knowledge_base(**arguments)
        return [TextContent(type="text", text=json.dumps(results, ensure_ascii=False))]
    elif name == "create_ticket":
        ticket = create_ticket(**arguments)
        return [TextContent(type="text", text=json.dumps(ticket, ensure_ascii=False))]
    raise ValueError(f"未知のツール: {name}")

async def main():
    async with stdio_server() as (read_stream, write_stream):
        await server.run(read_stream, write_stream, server.create_initialization_options())

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

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

このアプローチの利点は、既存のビジネスロジックを一切変更せずにMCP対応にできる点だ。MCPサーバーは「薄いアダプター」として機能し、Claude Desktop・Claude Code・OpenAIエージェントSDKなど、あらゆるMCPクライアントから同じツールを使えるようになる。

今週やるべき3つのこと

抽象的な話はここまでにする。具体的なアクションに落とす。

1. 既存の統合コードをインベントリ化する（2時間）

現在のプロジェクトで「AIがツールにアクセスするために書いたカスタムコード」をリストアップする。provider固有のfunction calling定義、カスタムAPIラッパー、ツール実行のグルーコード——これらがMCPサーバーへの移行候補だ。

2. 自分のスタックに該当するMCPサーバーを探す（1時間）

5,800本以上のサーバーがある。MCP公式サーバーリストを確認し、現在のツールスタック（データベース、Slack、GitHub等）でMCPサーバーが存在するか確認する。あれば、カスタム実装は不要だ。

3. 社内固有システムへの接続を1本作ってみる（1日）

既存サーバーで対応できない社内システムを1つ選び、MCPサーバーを作ってみる。Python SDKなら以下が最小構成だ：

# Python MCPサーバー最小実装例
# 動作環境: Python 3.11+, mcp>=1.0
# pip install mcp

from mcp.server import Server
from mcp.server.stdio import stdio_server
from mcp.types import Tool, TextContent
import asyncio

server = Server("my-internal-tool")

@server.list_tools()
async def list_tools():
    return [
        Tool(
            name="get_deployment_status",
            description="社内デプロイパイプラインの状態を取得",
            inputSchema={
                "type": "object",
                "properties": {
                    "environment": {"type": "string", "enum": ["staging", "production"]}
                },
                "required": ["environment"]
            }
        )
    ]

@server.call_tool()
async def call_tool(name: str, arguments: dict):
    if name == "get_deployment_status":
        env = arguments["environment"]
        # ここに実際の内部API呼び出しを書く
        # result = internal_api.get_status(env)
        return [TextContent(type="text", text=f"{env}環境: デプロイ正常")]

async def main():
    async with stdio_server() as (read_stream, write_stream):
        await server.run(read_stream, write_stream, server.create_initialization_options())

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

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

【要注意】MCPを採用するときの落とし穴

失敗1: 既存のREST APIをそのままMCPサーバーでラップする

❌ 全APIエンドポイントを機械的にMCPツールに変換する
⭕ AIが実際に使う可能性のある操作だけをツールとして定義する

なぜ重要か: ツールが多すぎると、AIがどのツールを使えばいいか判断できなくなる。30ツールを超えるMCPサーバーはツールサーチが必要になる。「何でもできる」より「明確に何かに特化している」方が使いやすいサーバーになる。

失敗2: 認証と権限管理を後回しにする

❌ 開発用のAPIキーをMCPサーバーにハードコードしたままにする
⭕ 環境変数とシークレットマネージャーを使い、最小権限原則に従って認証を設計する

なぜ重要か: MCPサーバーはAIが呼び出す。AIが「本来アクセスすべきでないデータ」にアクセスできる状態は、プロンプトインジェクション攻撃への直接的な脆弱性になる。

失敗3: ローカルstdioだけで完結させる

❌ stdioトランスポートのみで実装し、チーム共有を想定しない
⭕ 早期からHTTP+SSEトランスポートを視野に入れて設計する

なぜ重要か: チームが同じMCPサーバーを使う場合、各マシンにサーバーをインストールするか、中央サーバーとして運用するかを選択する必要がある。後者の場合はHTTPトランスポートが必要だ。

参考・出典

MCPの基本概念から始めたい方は、AIエージェント構築完全ガイドで全体像を確認してください。

あわせて読みたい:

この記事はAIgent Lab編集部がお届けしました。

Need help moving from reading to rollout?

この記事を読んで導入イメージが固まってきた方へ

Uravationでは、AIエージェントの要件整理、PoC設計、社内導入、研修まで一気通貫で支援しています。

30分無料相談を予約 支援実績を見る

この記事をシェア

X Facebook LINE

※ 本記事の情報は2026年4月時点のものです。サービスの料金・仕様は変更される可能性があります。最新情報は各サービスの公式サイトをご確認ください。

関連記事

CoreWeave株が11%急騰——AnthropicとのAIインフラ契約が示す構造変化 ニュース

CoreWeave株が11%急騰——AnthropicとのAIインフラ契約が示す構造変化

2026年4月10日のCoreWeave-Anthropic契約発表で株価は11...

7分で読める
AnthropicはなぜキリストにClaudeの道徳を聞いたのか ニュース

AnthropicはなぜキリストにClaudeの道徳を聞いたのか

Anthropicが15人のキリスト教指導者を招いた2日間のサミットを開催。Cl...

6分で読める
物理AIエージェントの夜明け——Figure AIが90分で1台体制、商用稼働を本格化 ニュース

物理AIエージェントの夜明け——Figure AIが90分で1台体制、商用稼働を本格化

Figure AIが評価額390億ドルで90分/台の量産体制を確立。BMW工場で...

7分で読める