Model Context Protocol: 今すぐ最初のMCPサーバーを構築する

Model Context Protocol (MCP) は、AIモデルが外部ツール、データソース、サービスに接続するためのユニバーサルな方法を提供するオープンスタンダードです。モデルとツールの組み合わせごとにカスタム統合コードを書くのではなく、1つのMCPサーバーを作成すれば、互換性のあるすべてのモデルがそれを利用できます。Anthropicが2024年後半にMCPを作成し、現在はLinux Foundationが管理しており、OpenAI、Google、その他のエージェント型AIエコシステム全体がこれを採用しています。ここでは、MCPを理解し、構築し、デプロイするために必要なすべてを解説します。

MCPの概要

詳細な6,000語の記事を読む前に、要点を簡潔にまとめます。

では、MCPとは何か、そしてなぜ必要となったのかという問題から始めて、それぞれを詳しく見ていきましょう。

Model Context Protocolとは？

Model Context Protocol は、AIモデルが外部ツールやデータを発見し、対話する方法を標準化する、オープンなJSON-RPCベースのプロトコルです。AI統合のためのHTTP、つまりあらゆるモデルとあらゆるツールが話せる共通言語だと考えてください。

おそらくUSB-Cの比喩を聞いたことがあるでしょう。これはある程度有用ですが、限界もあります。USB-C以前は、デバイスごとに独自のケーブルが必要でした。MCPもAIに対して同じことを行いますが、この比喩では不十分です。USB-Cはデータと電力のみを伝送しますが、MCPはツールの定義、データアクセスパターン、再利用可能なプロンプトテンプレートを伝送し、さらにサーバーがモデルに対して補完を要求することも可能にします。ケーブルの比喩が示唆するものよりも、はるかに豊かなプロトコルなのです。

MCPが解決する「M x N」の問題

MCPがない場合、M個のモデルをN個のツールに接続するには、M x N回のカスタム統合が必要です。例えば、5つのLLM（Claude, GPT-4, Gemini, Llama, Mistral）をサポートし、それらが10のツール（GitHub, Postgres, Slack, Jiraなど）にアクセスする必要があるとします。すると、それぞれが独自の認証、エラー処理、データフォーマットを持つ50層もの bespoke（特注）統合レイヤーが必要になります。

MCPを使用すれば、各モデルはMCPクライアントプロトコルを1回実装するだけでよく、各ツールはMCPサーバーを1回実装するだけです。これで、50ではなく 5 + 10 = 15の実装で済みます。新しいモデルを追加すれば、すぐにすべての10のツールで動作します。新しいツールを追加すれば、すべての5つのモデルがそれを使用できます。

MCPの簡単な歴史

Anthropicは2024年11月に、PythonとTypeScript用のSDKおよびClaude Desktop用のコネクタと共にMCPをオープンソース化しました。採用は急速に進みました。OpenAIは2025年3月にChatGPTにMCPサポートを追加しました。Googleも2025年4月にGeminiで追随しました。2025年12月までに、AnthropicはBlockとOpenAIと共に共同設立したLinux Foundationの新しいAgentic AI Foundation (AAIF) にMCPを寄贈し、業界横断的なガバナンスを持つベンダーニュートラルなスタンダードとしました。

MCPではないもの:

• モデルやAIフレームワークではありません（HTTPのようなプロトコルです）
• LangChainやLlamaIndexの代替ではありません（これらはオーケストレーション層であり、MCPはその下位に位置します）
• AnthropicやClaudeに限定されません（設計上、モデルに依存しません）
• 関数呼び出し（function calling）と同じものではありません（比較セクションで詳しく説明します）

MCPの仕組み：アーキテクチャ深掘り

MCPには3つの役割があり、これらを混同することが初心者の最も一般的な間違いです。違いを明確にしましょう。

ホスト、クライアント、サーバーの違いは何？

具体的な例を見てみましょう。Claude DesktopにGitHubのオープンなプルリクエストを確認するよう依頼した場合、Claude Desktopがホストです。その組み込みMCPクライアントがGitHub MCPサーバーへの接続を開きます。サーバーはGitHub APIを呼び出し、あなたのPRを取得して結果をクライアントに返し、クライアントがそれをモデルに渡します。

単一のホストは、それぞれが異なるサーバーに接続された複数のクライアントを実行できます。これが、Claude DesktopがGitHub、Postgresデータベース、Slackという3つの別々のMCPサーバーに同時にアクセスできる理由です。3つの別々のクライアント接続、1つのホストということです。

メッセージの流れ（JSON-RPC 2.0）

すべてのMCP通信は、軽量なリクエスト/レスポンスプロトコルである JSON-RPC 2.0 を使用します。以下は、ワイヤー上での tools/list 交換の様子です。

// Client request: "What tools do you have?"
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list"
}

// Server response: one tool available
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "get_weather",
        "description": "Get current weather for a city",
        "inputSchema": {
          "type": "object",
          "properties": {
            "city": { "type": "string" }
          },
          "required": ["city"]
        }
      }
    ]
  }
}

モデルはこれらのツール定義を読み取り、ユーザーのリクエストに基づいていつ呼び出すかを決定し、クライアントは適切な引数とともに tools/call リクエストをサーバーに送り返します。

接続ライフサイクル

すべてのMCPセッションは同じライフサイクルに従います。

1. 初期化: クライアントが機能を送信し、サーバーが自身の機能で応答
2. 機能ネゴシエーション: 両側がサポートされている機能（ツール、リソース、プロンプト、サンプリング）に合意
3. 準備完了: 接続がアクティブになり、双方向にリクエストが流れる
4. リクエスト/レスポンス: tools/call, resources/read など
5. シャットダウン: クリーンな切断

このハンドシェイクにより、前方互換性が確保されます。サーバーが新しいプリミティブを追加しても、古いクライアントはクラッシュせず、それを適切に無視します。

MCPプリミティブ：Tools、Resources、Prompts、Sampling

MCPは4つのプリミティブを定義しており、それぞれを誰が制御するかを理解することが、優れたMCPサーバーを設計する鍵となります。

Tools（モデル制御）

ツールは、モデルが呼び出せる関数です。サーバーは名前、説明、JSON Schema入力定義とともにこれらを宣言します。モデルはこれらの定義を読み取り、ユーザーのリクエストが必要とした場合に、ツールを呼び出すことを決定します。

// Client sends tools/call request
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "city": "Berlin" }
  }
}

OpenAIの関数呼び出しを使用したことがあれば、ツールは馴染み深く感じるでしょう。ただし、これらはすべてのMCP互換モデル間で標準化されています。

Resources（アプリケーション制御）

リソースは読み取り専用のデータエンドポイントです。ツールとは異なり、モデルは独自にリソースを取得することを決定しません。ホストアプリケーションまたはユーザーが明示的にリソースを会話コンテキストに添付します。これらはGETエンドポイントのようなものだと考えてください。例: postgres://mydb/users/schema, file://docs/api-reference.md。

リソースは resources/subscribe を介したサブスクリプションをサポートしており、データが変更されたときにクライアントに通知することができます。

Prompts（ユーザー制御）

プロンプトは、MCPサーバーが公開する再利用可能なテンプレートです。code_review プロンプトはファイルパスを受け取り、構造化されたレビューリクエストを生成するかもしれません。ユーザー（またはホストUI）がプロンプトを明示的にトリガーし、モデルによって自動的に呼び出されることはありません。

Sampling（サーバー主導）、高度な機能

多くのガイドが省略しているプリミティブがこれです。サンプリングにより、サーバーはクライアントにLLMを使用して補完を生成するよう要求できます。これは通常のフローを逆転させます。モデルがツールを呼び出すのではなく、ツールがモデルを呼び出すのです。

なぜでしょうか？エージェントループのためです。サポートチケットを処理するMCPサーバーを想像してください。チケット（リソース）を読み取り、sampling/createMessage を使用してモデルに要約を求め、その要約を使用してツール経由でチケットをルーティングします。サーバーはモデルの知能を使用してマルチステップのワークフローをオーケストレーションします。

サンプリングはホストアプリケーションによって制限されており、ユーザーはそれを承認する必要があり、ホストはサーバーが何を要求できるかを制御します。これにより、暴走ループを防ぎ、人間の監視を維持します。

最初のMCPサーバーを構築する：PythonとTypeScriptの並列比較

理論はここまでです。実際に動作する get_weather ツールを公開するMCPサーバーを構築しましょう。開発者体験を比較し、プロジェクトに適したスタックを選べるよう、PythonとTypeScriptの両方を示します。

FastMCPを使用したPython

FastMCP は公式のハイレベルPython SDKです。すべてのプロトコルの配管処理を行うため、ツールロジックに集中できます。

# Install FastMCP
pip install fastmcp

# weather_server.py
from fastmcp import FastMCP

mcp = FastMCP("Weather Server")

@mcp.tool()
def get_weather(city: str) -> str:
    """Get the current weather for a city."""
    # In production, call a real weather API here
    weather_data = {
        "Berlin": "Cloudy, 12°C",
        "Tokyo": "Sunny, 22°C",
        "New York": "Rainy, 8°C",
    }
    return weather_data.get(city, f"No data for {city}")

if __name__ == "__main__":
    mcp.run()

これだけです――15行。FastMCP は、Pythonの型ヒントとdocstringからツールの入力スキーマを推論します。JSON Schemaのボイラープレートは不要です。

公式SDKを使用したTypeScript

TypeScript SDK (@modelcontextprotocol/sdk) はやや明示的ですが、スキーマ定義を完全に制御できます。

# Install the SDK and Zod for schema validation
npm install @modelcontextprotocol/sdk zod

// weather-server.ts
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({
  name: "Weather Server",
  version: "1.0.0",
});

server.tool(
  "get_weather",
  "Get the current weather for a city",
  { city: z.string() },
  async ({ city }) => {
    const weatherData: Record<string, string> = {
      Berlin: "Cloudy, 12°C",
      Tokyo: "Sunny, 22°C",
      "New York": "Rainy, 8°C",
    };
    return {
      content: [
        { type: "text", text: weatherData[city] ?? `No data for ${city}` },
      ],
    };
  }
);

const transport = new StdioServerTransport();
await server.connect(transport);

TypeScriptバージョンは型ヒントの代わりにZodスキーマを使用し、構造化されたコンテンツブロックを返します。より冗長ですが、型安全性は優れています。

Claude Desktopに接続する

どちらかのサーバーをClaude Desktopに接続するには、claude_desktop_config.json に追加します。

{
  "mcpServers": {
    "weather-python": {
      "command": "python",
      "args": ["weather_server.py"],
      "cwd": "/path/to/your/project"
    },
    "weather-typescript": {
      "command": "npx",
      "args": ["tsx", "weather-server.ts"],
      "cwd": "/path/to/your/project"
    }
  }
}

Claude Desktopを再起動すると、両方の天気サーバーがツールリストに表示されます。「ベルリンの天気はどう？」と尋ねると、モデルは自動的にあなたの get_weather ツールを呼び出します。

MCP Inspectorでテストする

サーバーをホストに接続する前に、MCP Inspector で孤立してテストします。

npx @modelcontextprotocol/inspector python weather_server.py

InspectorはブラウザUIを開き、検出されたツールを確認したり、手動で呼び出したり、行き来するJSON-RPCメッセージを検査したりできます。これはMCPエコシステムで最高のデバッグツールであり、早期かつ頻繁に使用すべきです。

MCPトランスポート：開発にはstdio、本番にはStreamable HTTP

MCPメッセージはクライアントとサーバー間を移動する必要があります。それがトランスポート層であり、正しいものを選ぶことが重要です。

stdio は、MCPサーバーをサブプロセスとして起動し、stdin/stdoutを介して通信することで動作します。上記のチュートリアルで使用したもので、ポート、TLS、認証は不要です。開発およびシングルユーザーのローカルツールに最適です。

Streamable HTTP は本番環境用のトランスポートで、2025年の仕様更新で追加されました。クライアントは標準的なHTTP POSTリクエストをサーバーに送信します。サーバーは同期的に応答するか、長時間の操作のためにSSEストリームを開くことができます。ステートレス親和性があり、ロードバランサーの背後で動作し、標準的なHTTP認証をサポートします。

古いチュートリアルで「HTTP+SSE」を2つの別々のトランスポート（送信用と受信用）として言及している場合、それは非推奨のアプローチです。Streamable HTTP は両方を単一の、よりクリーンなメカニズムに統合します。

決定は単純です。ローカルで開発する際は stdio を使用し、他の人向けにデプロイする際は streamable-http に切り替えます。

// Switching from stdio to Streamable HTTP in TypeScript
import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js";

const transport = new StreamableHTTPServerTransport({ port: 3001 });
await server.connect(transport);

MCP vs 関数呼び出し vs REST API、それぞれの使い時

これはすべてのMCP議論で出てくる質問なので、直接比較して決着をつけましょう。

関数呼び出しで十分な場合

ツールが5つ未満で、1つのモデルを使用している場合、関数呼び出しの方がシンプルです。 ツールスキーマを各API呼び出しと一緒にインラインで定義し、モデルが関数名と引数を返し、アプリケーションコードでそれらを実行します。実行するサーバーもなく、学ぶべきプロトコルもありません。注文状況を確認し、FAQを検索するチャットボットの場合、関数呼び出しで全く問題ありません。

MCPが価値を発揮する場合

以下の状況でMCPはその複雑さに見合う価値があります。

• 複数のLLM をサポートしており、プロバイダーごとにツール定義を書き直したくない場合
• ツール発見 が必要な場合。モデルがハードコードされたスキーマではなく、利用可能なものをクエリできる
• リソースとプロンプト を必要とする場合。単なるツール呼び出しだけでなく
• 自律的に協調するAIエージェントを構築しており、標準化された統合層が必要な場合
• チームが成長しており、異なるエンジニアが異なるツールを構築している場合。MCPにより、彼らは独立して作業できる

結論：標準化されたマルチモデルのツールアクセスが必要な場合はMCPが勝ちます。シンプルなシングルモデルのユースケースでは関数呼び出しが勝ちます。 LLMを伴わない従来のサービス間通信には、REST APIが依然として正しい選択肢です。

2026年のMCPエコシステム：支持者と利用可能なもの

MCPは18ヶ月足らずでAnthropicのサイドプロジェクトから業界標準へと進化しました。現状は以下の通りです。

どのLLMがMCPをサポートしているか？

知っておくべき人気のあるMCPサーバー

Linux FoundationのAAIF発表では、2025年12月のMCP寄贈時点で、10,000以上のアクティブサーバーと9,700万回の月間SDKダウンロードが引用されました。エコシステムは実験的なものではなくなり、本番環境対応グレードとなっています。

MCP Apps は2026年1月に導入された新しいプリミティブです。サーバーがホストアプリケーション内でレンダリングされるインタラクティブなUIコンポーネントを提供できるようにします。まだ初期段階ですが、MCPがデータプロトコルから完全なエージェント-アプリケーションフレームワークへ進化することを示唆しています。注目すべきです。

ガバナンス：AnthropicからLinux Foundationへ

MCPは、Anthropic、Block、OpenAIによって共同設立されたLinux Foundation傘下の Agentic AI Foundation (AAIF) によって管理されています。これはエンタープライズ導入にとって重要です。MCPは1つのベンダーのロードマップに縛られていません。2026年ロードマップ の優先事項は、トランスポートの進化、エージェント間通信（新しい「Tasks」プリミティブ）、ガバナンスの成熟、およびエンタープライズレディネスです。

本番環境のAIシステムを構築するチームにとって、OpenClawのような自律型AIエージェントフレームワーク などのフレームワークは、すでにMCPサーバーと統合されており、エージェントに現実世界の能力を与えています。

MCPセキュリティ：OAuth 2.1、脅威、実用的なチェックリスト

セキュリティは、MCPエコシステムが最もカバーすべき領域です。そして数字は厳しい現実を描いています。

88%の問題：なぜほとんどのMCPサーバーが安全でないか

Astrix Securityは5,200以上のオープンソースMCPサーバー実装を分析し、88% が何らかの資格情報を必要とするものの、53% が設定ファイルにハードコードされたAPIキーやパーソナルアクセストークンなどの安全でない長期静的シークレットに依存していることを発見しました。OAuthを実装しているのはわずか 8.5% です。

これは、野外の圧倒的多数のMCPサーバーが、家の鍵を玄関ドアにテープで貼るのと同等の認証を使用していることを意味します。

MCPサーバー用のOAuth 2.1

MCP仕様は2025年6月の更新以降、すべてのHTTPベースのサーバーにOAuth 2.1を要求しています。フローは次のように動作します。MCPクライアントはサーバーとのOAuth 2.1認可フローを開始し、スコープ付きのアクセストークンを取得し、その後続するすべてのリクエストにそれを含めます。PKCE（Proof Key for Code Exchange）はすべてのクライアントに必須であり、例外はありません。

Streamable HTTP上で実行されるMCPサーバーを構築している場合、OAuth 2.1は任意ではありません。仕様で義務付けられています。

脅威モデル：何が起こり得るか

MCP展開において注意すべき4つの脅威があります。

• ツール経由のプロンプトインジェクション: 悪意のある、または侵害されたデータソースが、モデルを操作するように設計されたコンテンツを返します。ツールがウェブページを取得し、そのページに隠された指示が含まれている場合、モデルはそれを実行する可能性があります。
• 混乱した代理人攻撃: モデルが、ユーザーが意図したものよりも広範な権限を持つツールを呼び出します。MCPサーバーがデータベースへの管理者アクセスを持っている場合、モデルは理論的にテーブルを削除できます。
• トークン集中リスク: GitHub、Slack、本番環境データベースのAPIキーを保持するMCPサーバーは、単一の高価値ターゲットです。1つのサーバーを侵害されると、それが接続するすべてが侵害されます。
• 安全でないトランスポート: TLSなしでHTTP MCPサーバーを実行すると、OAuthトークンや機密データを含むすべてのリクエストがプレーンテキストで露出します。

本番環境MCP用のセキュリティチェックリスト

1. HTTP経由で公開されるサーバーには OAuth 2.1を実装 します。設定ファイルに静的APIキーを入れないでください。
2. 最小権限のスコーピングを適用 します。ツールがデータを読み取るだけの場合、サーバーの資格情報は読み取り専用であるべきです。レポートツールに書き込みアクセスを与えないでください。
3. 資格情報を分離 します。各MCPサーバーは独自のスコープ付きトークンを持つべきです。サーバー間で単一の「神トークン」を共有しないでください。
4. あらゆる場所でTLSを強制 します。HTTPSなしのStreamable HTTPは、本番環境では自動的なNGです。
5. ツール出力を検証およびサニタイズ します。ツールによって返されるデータは、ユーザー入力と同じように扱い、盲目的に信頼しないでください。
6. ツール呼び出しをレート制限 します。暴走したエージェントループがツールを数千回呼び出すと、APIクォータを使い果たしたり、意図しない副作用を引き起こしたりする可能性があります。
7. すべてのツール呼び出しを監査およびログ記録 します。リクエストID、タイムスタンプ、呼び出し元モデル、ツール引数を含めます。デバッグおよびセキュリティインシデント対応のためにこれが必要です。

MCPのデバッグ：Inspector、ログ、一般的なエラー

エラーに遭遇します。すべての開発者がそうです。ここでは、それらを迅速に修正する方法を説明します。

MCP Inspector は公式のデバッグツールであり、最初の防御線です。任意のMCPサーバーに接続し、そのツール/リソース/プロンプトを発見し、生のJSON-RPCトラフィックを表示しながら手動でそれらを呼び出すことができます。

# Launch Inspector against your Python server
npx @modelcontextprotocol/inspector python weather_server.py

# Or against a TypeScript server
npx @modelcontextprotocol/inspector npx tsx weather-server.ts

Inspectorは、Tools、Resources、Prompts用のタブと通知ペインを備えたブラウザベースのUIを開きます。カスタム引数で任意のツールを呼び出し、ワイヤー上を流れるJSONを正確に確認できます。ホストアプリケーションに接続する前に使用してください。サーバーを孤立してデバッグする方がはるかに簡単です。

一般的なエラーと修正

• Claude Desktopでの「Server not found」: ほぼ常に claude_desktop_config.json のパスの問題です。command が実際のバイナリに解決され、cwd が正しいディレクトリを指していることを再確認してください。macOSでは絶対パスを使用してください。
• ツールスキーマ検証失敗: モデルがツールの inputSchema と一致しない引数を送信した場合、サーバーは呼び出しを拒否します。スキーマタイプがモデルの期待と一致しているか確認してください。Zod（TypeScript）と型ヒント（Python）は、定義時にこれらのほとんどを検出します。
• トランスポート接続ドロップ: stdio の場合、これは通常サーバープロセスがクラッシュしたことを意味します。stderr出力を確認してください。Streamable HTTPの場合、タイムアウト設定を確認してください。長時間実行されるツールは、デフォルトのHTTPタイムアウトを超える可能性があります。
• 「Permission denied」または401エラー: OAuthスコープが狭すぎます。サーバーは、必要な権限がないためトークンを拒否しています。スコープを広げますが、ツールが実際に必要とする分だけにしてください。

ログのベストプラクティス

MCPクライアント、サーバー、および下流のAPI全体で単一のユーザーリクエストを追跡できるよう、リクエストIDを使用してログを構造化します。すべての tools/call 呼び出しを、ツール名、引数、応答時間、結果ステータスとともにログに記録します。本番環境では、これらのログを観測性プラットフォームに送信してください。午前3時に何か問題が発生した場合、そうしておいてよかったと思うでしょう。

TechsyがMCPで構築する方法

私たちは2025年初頭からクライアントプロジェクトにMCPを統合しており、最も頻繁に見られるパターンはこれです。チームには、1つのモデルと handful のツールで動作するAI機能がありますが、拡張を計画しています。より多くのモデル、より多くのデータソース、より多くのエージェント機能。それがMCPが収益を生み始めるところです。

私たちのアプローチは3つのステップに従います。

1. 適合性の評価。すべてのプロジェクトがMCPを必要とするわけではありません。単一のモデルから2つのツールを呼び出している場合、関数呼び出しの方がシンプルであり、そう伝えます。MCPは、3つ以上のデータソースを接続する場合、複数のモデルをサポートする場合、またはツールが発見可能である必要があるエージェントワークフローを構築する場合に意味を持ちます。
2. サーバーを孤立して構築およびテスト。各データソース、内部データベース、SaaS API、独自サービス用にカスタムMCPサーバーを開発し、ホストに接続する前にMCP Inspectorで検証します。
3. Streamable HTTPとOAuth 2.1でデプロイ。本番環境では、MCPサーバーをTLSの背後でコンテナ化されたサービスとして実行し、初日からスコープ付きOAuthトークンと構造化ログを使用します。静的シークレットは使用しません。

私たちが構築する最も一般的な統合は、AIアシスタントを内部Postgresデータベースに接続すること、クライアントSaaSプラットフォーム用のカスタムMCPサーバーを構築すること、そして散在する関数呼び出しセットアップから標準化されたMCPアーキテクチャへのチームの移行です。

インフラストラクチャに接続する必要があるAI駆動ツールを構築していますか？私たちはチームがMCP統合を設計および実装するのを支援します。無料相談を受ける

MCPに関するよくある質問

Model Context Protocol (MCP) とは何ですか？

MCPは、もともとAnthropicによって作成され、現在はLinux Foundationによって管理されているオープンスタンダードで、AIモデルが外部ツール、データソース、サービスに接続する方法を定義します。統合層を標準化し、1つのMCPサーバーが互換性のあるすべてのモデルで動作するようにします。AIのためのユニバーサルプラグのようなものです。

MCPはどのように動作しますか？

MCPは3部構成のアーキテクチャを使用します。ホスト アプリケーション（Claude DesktopやCursorなど）、接続を管理するホスト内のMCP クライアント、そしてツールとデータを公開するMCP サーバー です。すべての通信は、stdio（ローカル）またはStreamable HTTP（リモート）を介したJSON-RPC 2.0メッセージを使用します。

MCPは何に使われますか？

一般的なユースケースには、AIアシスタントをデータベース（Postgres、MySQL）に接続すること、コードプラットフォーム（GitHub、GitLab）との統合、SaaSツール（Slack、Notion、Google Drive）へのアクセス、および現実世界のサービスと対話する必要がある自律型AIエージェントの構築が含まれます。

MCPは関数呼び出しと同じですか？

いいえ。関数呼び出しはモデル固有であり（OpenAIの形式はAnthropicのものとは異なります）、リクエストごとに行われます。すべてのAPI呼び出しでツールスキーマを送信します。MCPはモデル間で動作する標準化されたプロトコルであり、ツール発見をサポートし、関数実行だけでなくリソースとプロンプトも含みます。

MCPサーバーとは何ですか？

MCPサーバーは、MCPプロトコルを介してAIモデルにツール、リソース、プロンプトを公開するプログラムです。外部APIとデータソースを標準化されたインターフェースでラップします。例としては、GitHub MCPサーバー（PRおよびイシュー管理用）やPostgres MCPサーバー（データベースクエリ用）があります。

MCPサーバーを構築するにはどうすればよいですか？

FastMCP (pip install fastmcp) を使用したPython、または公式SDK (npm install @modelcontextprotocol/sdk) を使用したTypeScriptを使用します。ツールをデコレートされた関数（Python）または登録されたハンドラー（TypeScript）として定義し、サーバーを実行します。完全な動作コードについては上記のチュートリアルセクションを参照するか、ゼロからMCPサーバーを構築するための ステップバイステップガイド に従ってください。

MCPは安全ですか？

プロトコル自体は認証とスコープ付き権限のためにOAuth 2.1をサポートしています。しかし、Astrix Securityの研究によると、既存のMCPサーバー実装の88%がOAuthではなく静的シークレットに依存しています。プロトコルは設計上安全ですが、ほとんどの実世界での展開はまだ追いついていません。

どのLLMがMCPをサポートしていますか？

Claudeは2024年11月の作成以来、ネイティブなMCPサポートを持っています。ChatGPTは2025年3月にサポートを追加し、Geminiは2025年4月に追随しました。オープンソースモデルは、LangChainおよびLlamaIndexのアダプターを介してMCPを使用できます。

MCPとREST APIの違いは何ですか？

REST APIは一般的なサービス間通信のために設計されています。MCPはAIモデルの対話のために特別に設計されており、RESTにはないツール発見、スキーマネゴシエーション、リソースアクセス、プロンプトテンプレートを含みます。REST APIをMCPに置き換えることはありません。これらは異なる層を提供します。

現在MCPを維持しているのは誰ですか？

2025年12月に設立されたLinux FoundationのAgentic AI Foundation (AAIF) がMCPを管理しています。これはAnthropic、Block、OpenAIによって共同設立されました。このベンダーニュートラルなガバナンスは、企業がMCPを採用する主な理由です。

MCPにおけるStreamable HTTPとは何ですか？

Streamable HTTPは、2025年のMCP仕様更新で追加された本番環境用トランスポートメカニズムです。よりクリーンな設計で古いHTTP+SSEトランスポートを置き換えます。クライアントはHTTP POSTリクエストを送信し、サーバーは同期的に応答するか、SSEストリーミングを介して応答できます。ロードバランサーの背後で動作し、標準的なHTTP認証をサポートします。

いくつのMCPサーバーが存在しますか？

Linux Foundationは、2025年12月にMCPがAAIFに寄贈された際、10,000以上のアクティブサーバーと9,700万回の月間SDKダウンロードを引用しました。エコシステムは、データベース、コードツール、SaaS統合、検索エンジン、クラウドインフラプロバイダーに広がっています。

結論

MCPは、Anthropicのオープンソース実験から、わずか1年余りでAIモデルをツールに接続するための業界標準プロトコルへと進化しました。重要な点は以下の通りです。

• MCPはM x Nの問題を解決します。1つのサーバーはすべての互換性のあるモデルで動作し、1つのクライアントはすべてのサーバーで動作します
• Python (FastMCP) またはTypeScriptで50行未満で動作するMCPサーバーを構築できます
• 開発にはstdio、本番環境にはStreamable HTTPを使用します。トランスポートの選択は単純です
• OAuth 2.1でサーバーを保護します。現在の実装の88%が行っておらず、それは実際のリスクです
• エコシステムは本番環境対応です。10,000以上のサーバー、すべての主要LLM、Linux Foundation傘下のベンダーニュートラルなガバナンス

将来を見ると、2026年のロードマップは、新しいTasksプリミティブを介したエージェント間通信、強化されたエンタープライズセキュリティ、およびインタラクティブなサーバー駆動UIのためのMCP Appsに焦点を当てています。MCPはもはやツールアクセスのためのプロトコルだけでなく、エージェント型AIのためのインフラストラクチャ層になりつつあります。

上記のチュートリアルコードから始め、MCP Inspectorでテストし、Claude Desktopに接続してください。1時間以内に動作するMCP統合ができあがるでしょう。

ソース

• MCP Specification (2025-11-25)
• MCP Authorization Specification
• MCP Transports Specification
• MCP Inspector Documentation
• Introducing the Model Context Protocol, Anthropic
• Donating MCP to the Linux Foundation, Anthropic
• Linux Foundation AAIF Announcement
• Google Cloud MCP Support
• FastMCP Python SDK
• MCP TypeScript SDK
• Astrix Security: State of MCP Server Security 2025
• MCP 2026 Roadmap