MCPサーバーとは｜仕組み・接続手順・作り方・一覧【2026年9月】

MCPサーバーとは、AIアプリから呼び出せる形で「道具（tools）」「データ（resources）」「定型の指示（prompts）」を公開する外部プログラムのことです。2026年9月25日時点の現行仕様は2026年7月28日に公開された 2026-07-28 版で、この改訂でMCPは接続を張りっぱなしにする双方向プロトコルから、1リクエストごとに完結する要求・応答型（ステートレス）へ作り替えられました。つまり「MCPサーバーを立てる」は、いまや「普通のHTTPサービスを1本立てる」とほぼ同じ意味になっています。

ところが日本語の解説記事は、初期仕様（2024-11-05〜2025-06-18）の頃に書かれた「initialize でハンドシェイクして、セッションIDを持ち回る」という前提のままのものが少なくありません。設定ファイルの書き方も、Claude・ChatGPT・Cursorでそれぞれ別物です。同じ「MCPサーバーを追加する」でも、手元でやることは3系統でまったく違います。

この記事では、公式ドキュメントと公式レジストリを2026年9月25日に取得したうえで、仕組み・接続手順（設定ファイルの実物つき）・公式サーバーの一覧・自作の最短手順・法人で入れる前の確認点までを1本にまとめました。各論に入りたくなった箇所からは、AIgent Labの個別記事へ進めるようにしてあります。

MCPサーバーとは｜30秒で分かる定義と3つの構成要素

MCP（Model Context Protocol）は、AIアプリケーションを外部システムに接続するためのオープンな標準規格です。公式ドキュメントは「AIアプリにとってのUSB-Cポート」という比喩を使っています。USB-Cが機器ごとの独自端子をなくしたように、MCPは「AIアプリ側の独自連携仕様」をなくすための共通端子だ、という説明です（modelcontextprotocol.io 公式ドキュメント・2026年9月25日取得）。

その規格のうち、機能やデータを差し出す側のプログラムがMCPサーバーです。公式は「標準化されたプロトコルの窓口を通じて、AIアプリに特定の能力を公開するプログラム」と定義しています。よくある例として、ファイル操作のためのファイルシステムサーバー、データ照会のためのデータベースサーバー、コード管理のためのGitHubサーバー、チーム連絡のためのSlackサーバー、予定管理のためのカレンダーサーバーが挙げられています。

サーバーが出せるのは3種類だけ

MCPサーバーが公開できる機能は、公式の整理では次の3つだけです。ここを取り違えると設計がぶれるので、最初に押さえておく価値があります。

種類	中身	例	誰が使うか決めるか
Tools（ツール）	AIモデルが能動的に呼び出せる関数。データベースへの書き込み、外部APIの呼び出し、ファイルの更新などを行える	航空券を検索する／メッセージを送る／予定を作る	モデル
Resources（リソース）	読み取り専用のデータ源。ファイル本文、データベースのスキーマ、API仕様など、文脈として渡す情報	文書を取得する／ナレッジベースを参照する／カレンダーを読む	アプリケーション
Prompts（プロンプト）	ツールやリソースの使い方を型にした指示テンプレート。ユーザーが明示的に呼び出す	旅行の計画を立てる／会議を要約する／メールを下書きする	ユーザー

Toolsはtools/listで一覧を取り、tools/callで実行します。Resourcesはresources/listとresources/read、Promptsはprompts/listとprompts/getです。「MCPサーバーを作る」とは、要するにこの数個のメソッドに応答するHTTPサービス（またはローカルプロセス）を書くことに他なりません。

Claudeを使っている方が最短で全体像をつかみたい場合は、Claude MCP入門：Model Context Protocolの基礎と実装でClaude寄りの実装例まで通して読めます。

MCPの仕組み｜ホスト・クライアント・サーバーの3層と2つの接続方式

仕様書は通信の登場人物を3つに分けています。用語が紛らわしいので、ここは定義のまま覚えるのが早いです。

• ホスト（Hosts）：接続を始めるLLMアプリケーション本体。Claude Code、ChatGPT、Cursorといったアプリがこれにあたります。
• クライアント（Clients）：ホストの中にあるコネクタ。サーバー1本につき1つ、ホスト内部で相手をする担当者だと考えると分かりやすいです。
• サーバー（Servers）：文脈と機能を提供するサービス。これがMCPサーバーです。

メッセージの形式はJSON-RPC 2.0です。仕様書は、プログラミング言語ごとの対応を開発ツール全体で共通化したLanguage Server Protocol（LSP）から着想を得ている、と明記しています。「言語 × エディタ」の組み合わせ爆発をLSPが解いたのと同じことを、「ツール × AIアプリ」でやるのがMCPだという位置づけです。

接続方式（トランスポート）は公式には2つだけ

2026年9月25日時点の公式トランスポートは次の2つです。どちらを選ぶかで、運用の形がほぼ決まります。

方式	仕組み	動く場所	向いている用途
stdio	クライアントが起動した子プロセスの標準入出力に、改行区切りのJSON-RPCを流す	利用者のマシン上（ローカル）	ローカルのファイル・Git・ブラウザ操作など、手元の環境に触る必要があるもの
Streamable HTTP	1メッセージ＝単一MCPエンドポイントへのHTTP POST。応答はJSONオブジェクトか、そのリクエストに紐づくSSEストリーム	クラウド・エッジ・社内サーバー	SaaS連携、複数人で共有するサーバー、OAuth認証が必要なもの

加えて、仕様は「双方向のバイト列を運べる経路ならカスタムトランスポートを実装してよい」としています。ただしUnixドメインソケットやTCPのような信頼できる双方向ストリームの上で動かすなら、新しい枠組みを作らずstdioのフレーミング（改行区切りJSON-RPC）を再利用することを推奨しています。

Streamable HTTPの実装を自分で書く段になったら、MCP Streamable HTTP完全実装ガイド｜Python/TypeScriptにクライアント・サーバー両側の実装手順があります。

2026年7月28日の仕様改訂で変わった5点と、非推奨になった機能

ここがこの記事でいちばん鮮度の高い部分です。2026-07-28は公式ブログによればMCPにとって5回目の仕様リリースで、変更のうち複数が破壊的変更を含みます。既存の解説記事や社内資料が古いままだと、設計を丸ごとやり直すことになります。

変わった5点

項目	2025-11-25まで	2026-07-28
接続の開始	initialize／notifications/initialized のハンドシェイクが必要	ハンドシェイクを廃止。各リクエストが自分の_metaにプロトコル版とクライアント能力を載せて自己完結する
セッション	Streamable HTTPに Mcp-Session-Id ヘッダーがあり、一覧結果が接続ごとに変わり得た	プロトコル層のセッションを撤去。状態が必要なサーバーは、自前で発行したハンドルをツール引数として受け渡す
能力の確認	ハンドシェイクの応答で受け取る	server/discover というRPCをサーバーが必ず実装する。クライアントは必要なときだけ呼ぶ
サーバーからの問い合わせ	elicitation/create・sampling/createMessage・roots/list をサーバー側から発行（ストリームを開きっぱなしにする必要があった）	Multi Round-Trip Requests（MRTR）へ。サーバーはresultType: "input_required"を返し、クライアントが答えを添えて同じ呼び出しを再送する
一覧の取り回し	毎回取り直し	tools/list等の結果にttlMsとcacheScopeが必須化。順序も決定的にすることが推奨され、クライアント側でキャッシュできる

加えて、Streamable HTTPのPOSTにはMcp-MethodとMcp-Nameという標準ヘッダーが必須になりました。ゲートウェイやレート制限、WAFがJSON本文を解析せずにヘッダーだけで経路制御・計量できる、という狙いです。公式ブログが載せている最小のリクエスト例は次の形です。

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
 "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

公式ブログはこの変更の意図を「どのリクエストも、素のラウンドロビン負荷分散の後ろにあるどのインスタンスに着地してもよくなる」と説明しています。共有ストレージなしで水平に並べられるので、サーバーレスやエッジでの実行が現実的になりました。

非推奨になった機能

公式は同時に「機能ライフサイクルと非推奨ポリシー」を定めました。Active・Deprecated・Removed の3状態を持ち、非推奨になってから最低12か月は仕様に残す（迅速撤去の例外でも最低90日）というルールです。2026-07-28で非推奨になったのは次のとおりです。

• Roots・Sampling・Logging：当面は動くが、新規実装では採用しない。移行先として公式は、Rootsの代わりにツール引数・リソースURI・サーバー設定でディレクトリを渡すこと、Samplingの代わりにLLMプロバイダーのAPIを直接使うこと、Loggingの代わりにstderr（stdioの場合）かOpenTelemetryを使うことを挙げています。
• HTTP＋SSEトランスポート：2025-03-26以降ずっと非推奨扱いでしたが、今回ライフサイクル上の Deprecated として正式に位置づけられました。移行先はStreamable HTTPです。
• OAuth 2.0 の動的クライアント登録（DCR）：Client ID Metadata Documents（CIMD）へ寄せる方針が示されました。CIMDに対応していない認可サーバー向けに、後方互換としては残ります。

この改訂の技術的な背景をもう一段掘りたい場合は、MCP次期仕様解説｜ステートレスコアとTasks拡張化が変更提案（SEP）単位で追っています。

MCPサーバーの接続手順｜Claude・ChatGPT・Cursorの3系統

ここからは実際の追加手順です。クライアントは3系統（Claude・ChatGPT/Codex・Cursor）で、Claudeだけはコマンドで入れるClaude Codeと、管理画面で入れるclaude.aiのコネクタの2つの入口があります。いずれも公式ドキュメントに載っている形だけを載せます。自分で動かしていない環境の話は書いていないので、コマンドやキー名は各公式ページで最終確認してから使ってください。

Claude Code：コマンドで追加する

Claude Codeはclaude mcp addで追加します。リモートサーバーはHTTPが推奨で、ローカルのstdioサーバーは--のあとに起動コマンドを書きます。

# リモート（Streamable HTTP）を追加する
claude mcp add --transport http notion https://mcp.notion.com/mcp

# Bearer トークンを添える場合
claude mcp add --transport http secure-api https://api.example.com/mcp \
  --header "Authorization: Bearer your-token"

# ローカルの stdio サーバーを追加する（-- のあとが起動コマンド）
claude mcp add --env AIRTABLE_API_KEY=YOUR_KEY --transport stdio airtable \
  -- npx -y airtable-mcp-server

# 確認・削除
claude mcp list
claude mcp get notion
claude mcp remove notion

ポイントは--の意味です。公式ドキュメントは「stdioサーバーでは--がClaude自身のオプションとサーバーの起動コマンドを分ける。--より後ろはそのままサーバーへ渡される」と明記しています。これを省くと、サーバー側の--portなどをClaude Codeが自分のオプションとして読もうとして失敗します。

チームで共有するなら、プロジェクト直下の.mcp.jsonに書いてリポジトリに入れます。形式は標準化されたもので、他クライアント向けのmcpServersブロックをそのまま持ち込めます。

{
  "mcpServers": {
    "shared-server": {
      "type": "http",
      "url": "https://example.com/mcp"
    }
  }
}

ここで落とし穴が1つあります。公式ドキュメントは「urlがあるのにtypeがないエントリは設定エラー」と明記しています。typeがないとstdioサーバーとして読まれるため、そのサーバーは読み込まれずスキップされます。typeにはhttpのほか、MCP仕様側の名前であるstreamable-httpも別名として受け付けます。サーバー提供元のドキュメントからコピーした設定がそのまま通るようにするための配慮です。

保存先は3つのスコープに分かれます。

スコープ	読み込まれる範囲	チーム共有	保存先
Local（既定）	追加したプロジェクトだけ	しない	~/.claude.json
Project	そのプロジェクトだけ	する（バージョン管理経由）	プロジェクト直下の.mcp.json
User	自分の全プロジェクト	しない	~/.claude.json

同じ名前のサーバーが複数の場所にあるときは、Local・Project・User・プラグイン提供・claude.aiコネクタの順で優先され、勝った定義がまるごと使われます（フィールドの継ぎ足しはしません）。

Claude（claude.ai）：コネクタとして追加する

ブラウザやデスクトップのClaudeで使う場合は、Anthropicのディレクトリから選ぶか、claude.ai/customize/connectorsで追加します。ここで重要なのが権限の話で、公式ドキュメントは「TeamおよびEnterpriseプランでは、管理者だけがサーバーを追加できる」と明記しています。法人で勝手な追加を防ぎたい場合、この仕様がそのまま統制点になります。

claude.aiで追加したコネクタは、同じアカウントでログインしたClaude Codeにも自動で現れます。組織はコネクタのツール単位でask（毎回確認）／blocked（そもそも見せない）を設定でき、Claude Codeは起動時にこの設定を読んで手元で適用します。blockedにしたツールはモデルから見えなくなります。

ChatGPT・Codex：開発者モードとconfig.toml

ChatGPT側は、OpenAIの公式ドキュメントによれば次の手順です。

1. ChatGPTのSettingsを開く
2. Security and loginを選ぶ
3. Developer modeを有効にする
4. ChatGPT Pluginsを開き、プラスボタンから名前・説明を入力する
5. Connectionで接続方法を選ぶ。公開エンドポイントなら/mcpを含むURLを入れる
6. 接続を作成し、サーバーから検出されたツールとメタデータを確認する

公式は「開発者モードの利用可否はアカウントやワークスペースのポリシーによる」と注記しています。またOpenAI側の互換要件として、ChatGPTのdeep researchやcompany knowledgeで使うなら、読み取り専用のsearchとfetchの2ツールを実装しておくことが求められています。

ローカルのCodex（CLI・IDE拡張・ChatGPTデスクトップアプリ）は設定を共有し、~/.codex/config.toml（プロジェクト単位なら.codex/config.toml）にMCP設定を持ちます。

# CLI から追加する
codex mcp add context7 -- npx -y @upstash/context7-mcp

# 一覧・OAuth ログイン
codex mcp list
codex mcp login <server-name>

TOMLを直接書く場合は[mcp_servers.<server-name>]というテーブルを作ります。stdioサーバーではcommandが必須で、args・env・env_vars・cwdが任意。Streamable HTTPサーバーではurlが必須で、auth・bearer_token_env_var・http_headers・env_http_headers・http_headers_helperが任意です。トークンを平文で置かずに済むbearer_token_env_varがあるのは、地味ですが運用上ありがたい設計です。

Cursor：mcp.jsonに書く

Cursorはmcp.jsonで設定します。プロジェクト単位なら.cursor/mcp.json、全体で使うなら~/.cursor/mcp.jsonです。

// ローカル（stdio）
{
  "mcpServers": {
    "server-name": {
      "command": "npx",
      "args": ["-y", "mcp-server"],
      "env": { "API_KEY": "value" }
    }
  }
}

// リモート（HTTP / SSE）
{
  "mcpServers": {
    "server-name": {
      "url": "http://localhost:3000/mcp",
      "headers": { "API_KEY": "value" }
    }
  }
}

Cursorの公式ドキュメントは、対応している機能として Tools・Prompts・Resources・Roots・Elicitation・Apps拡張 を挙げています。OAuthを使うサーバーでは、動的クライアント登録の代わりに固定のクライアントIDをauthオブジェクトで渡せます。FigmaやLinearのようにリダイレクトURLの事前登録を求める提供元向けの逃げ道です。

なお.cursor/mcp.jsonと.mcp.jsonは別物で、互換はありません。他クライアント向けの設定をコピーするときは、キーの入れ子とtypeの有無を必ず見比べてください。

公式・主要なMCPサーバー一覧（2026年9月25日時点）

「おすすめ」を名乗る一覧記事は多いのですが、出どころが不明なサーバーを混ぜると危険です。ここでは公式レジストリ（registry.modelcontextprotocol.io）に提供元自身の名前空間で登録されている、または提供元の公式ドキュメントに記載があるものだけを載せます。すべて2026年9月25日に取得して確認しました。

提供元が運営しているMCPサーバー

サーバー	提供元	主な用途	接続方式
Notion MCP	Notion	ページ・データベースの検索と更新	Streamable HTTP（mcp.notion.com/mcp）
Stripe MCP	Stripe	決済・顧客・請求データの参照と操作	Streamable HTTP（mcp.stripe.com）
Figma MCP	Figma	デザインファイルの参照、生成物のキャンバス取り込み	Streamable HTTP（mcp.figma.com/mcp）
Linear MCP	Linear	課題・プロジェクト・サイクルの操作	Streamable HTTP／SSE（mcp.linear.app/mcp）
Cloudflare MCP	Cloudflare	ドキュメント検索・可観測性・Workersビルドなど用途別に複数本	Streamable HTTP（用途ごとに別ホスト）
Atlassian Rovo MCP	Atlassian	Jira・Confluenceの課題とページ	SSE（mcp.atlassian.com/v1/sse）
Supabase MCP	Supabase	プロジェクト・データベース操作	Streamable HTTP／npmパッケージ
PayPal MCP	PayPal	請求書・取引・支払い	Streamable HTTP／SSE（mcp.paypal.com/mcp）
Canva MCP	Canva	デザインの生成・編集・書き出し	Streamable HTTP（mcp.canva.com/mcp）
HubSpot MCP	HubSpot	CRMのレコード参照・更新	Streamable HTTP（mcp.hubspot.com/anthropic）
Asana MCP	Asana	タスク・プロジェクト管理	SSE（mcp.asana.com/sse）
GitHub MCP Server	GitHub	リポジトリ・Issue・プルリクエスト	stdio（コンテナイメージ）
Playwright MCP	Microsoft	ブラウザ操作の自動化・E2E検証	stdio（npm @playwright/mcp）
Sentry MCP	Sentry	エラー・パフォーマンス問題の調査	stdio（npm @sentry/mcp-server）
Chrome DevTools MCP	Chrome DevTools	ブラウザの計測・デバッグ	stdio（npm chrome-devtools-mcp）

公式リファレンス実装（学習用・7本）

modelcontextprotocol/servers に置かれている、MCPの機能と公式SDKを示すための実装です。2026年9月25日時点で7本あります。

名前	内容
Everything	prompts・resources・toolsを一通り備えた参照・テスト用サーバー
Fetch	Web上の内容を取得してLLM向けに変換する
Filesystem	アクセス制御を設定できる安全なファイル操作
Git	Gitリポジトリの読み取り・検索・操作
Memory	ナレッジグラフ方式の永続メモリ
Sequential Thinking	思考の連鎖による動的な問題解決
Time	時刻とタイムゾーンの変換

GitHub・GitLab・Google Drive・Google Maps・PostgreSQL・Puppeteer・Redis・Sentry・Slack・SQLite・Brave Search・AWS KB Retrieval・EverArtの各リファレンス実装はすでにアーカイブ済みで、servers-archivedリポジトリへ移されています。Brave Searchは提供元の公式サーバーへ、Slackは別組織へ引き継がれました。古い記事が「公式サーバーとしてSlackがある」と書いているのはこの時点で止まった情報です。

どれを選ぶか：5つの判断軸

1. 提供元が運営しているか。OpenAIの公式ドキュメントは「Stripeにつなぐなら、第三者がホストする非公式サーバーではなくStripe自身がホストするmcp.stripe.comを選ぶ」と具体名で推奨しています。
2. 書き込み系のツールを含むか。読み取りだけなら事故の幅は限定されます。書き込みを含むなら、承認の仕組みと監査ログの有無を先に確認します。
3. 接続方式が用途と合っているか。手元のファイルに触るならstdio、チームで共有するならStreamable HTTP。ローカル用途に無理やりリモートを使うと権限設計が複雑になります。
4. 認証がOAuthか、トークン直渡しか。OAuthのほうが失効・再同意の手当てがしやすく、トークンを設定ファイルに書かずに済みます。
5. 仕様版への追従状況。2026-07-28に対応済みか、旧セッション前提のままかで、今後12か月の手直し量が変わります。

クラウド提供元がまとめて出しているものを俯瞰したい場合はGoogle マネージドMCPサーバーとは？50超を解説、レジストリから探す方法はSmithery完全ガイド｜MCP Serverレジストリ・発見・管理が詳しいです。国内業務に寄せた選び方は、姉妹メディアの日本特化MCPサーバー8選｜法令・税務・労務・助成金にまとまっています。個別のサーバーがどんな粒度でツールを出すのかを見たい場合は、TradingView MCPとは｜接続手順と35ツールのように1本を掘った記事が参考になります。

MCPサーバーの作り方｜公式SDKで最短の手順

自作は思ったより短く始められます。公式SDKはツール定義・スキーマ検証・トランスポートの面倒を見てくれるので、書くのは「関数」と「その説明」だけです。

公式SDKの言語とTier

公式SDKは機能の網羅度・プロトコル対応・保守方針でTierが分かれています。2026年9月25日時点の公式ページの一覧は次のとおりです。

Tier	言語
Tier 1	TypeScript、Python、C#、Go、Rust
Tier 2	Java、Ruby
Tier 3	Swift、PHP、Kotlin

2026年7月28日の公式ブログ公開時点では、TypeScript・Python・Go・C#の4つがTier 1で、Rustはベータとして新仕様に対応、という記載でした。2026年9月25日時点の公式SDKページではRustもTier 1として掲載されています。

Pythonで最小のMCPサーバーを書く

以下は公式のサーバー構築ガイドに載っている手順の抜粋です。ここで注意したいのが、公式Python SDKの入口クラスがMCPServerである点です。「FastMCPを使う」と書かれた解説を見かけますが、2026年9月25日時点の公式ガイドはfrom mcp.server import MCPServerで始まります。

# プロジェクトを用意する（macOS / Linux）
uv init weather
cd weather
uv venv
source .venv/bin/activate
uv add "mcp[cli]"
touch weather.py

from typing import Any

import httpx2
from mcp.server import MCPServer

# サーバーの実体を作る（引数はサーバー名）
mcp = MCPServer("weather")

NWS_API_BASE = "https://api.weather.gov"
USER_AGENT = "weather-app/1.0"


@mcp.tool()
async def get_alerts(state: str) -> str:
    """Get weather alerts for a US state.

    Args:
        state: Two-letter US state code (e.g. CA, NY)
    """
    url = f"{NWS_API_BASE}/alerts/active/area/{state}"
    data = await make_nws_request(url)
    if not data or "features" not in data:
        return "Unable to fetch alerts or no alerts found."
    if not data["features"]:
        return "No active alerts for this state."
    return "\n---\n".join(format_alert(f) for f in data["features"])


if __name__ == "__main__":
    # stdio で待ち受ける（ローカルサーバーの基本形）
    mcp.run(transport="stdio")

動作環境：Python（uvでプロジェクト作成）、公式Python SDKのmcp[cli]。HTTPクライアントのhttpx2はSDKが依存しているため、mcpを入れた時点で入ります。注意：本番環境で使用する前に、必ずテスト環境で動作確認してください。

押さえるポイントは3つです。

• docstringが仕様書になる：関数の説明文と引数の型がそのままツールのスキーマになり、モデルが「いつ使うか」を判断する材料になります。ここを雑に書くと、呼ばれない／誤って呼ばれるツールができます。
• 1ツール1操作：公式は「各ツールは入出力が明確な単一の操作を行う」としています。1つのツールに分岐を詰め込むと精度が落ちます。
• stdioかHTTPかは最後に決める：mcp.run(transport=...)を変えるだけで切り替わります。まずstdioで動かし、共有段階でHTTPへ移すのが安全です。

動作確認と公開

書いたサーバーは、公式のMCP Inspectorでツール一覧の取得と呼び出しを直接試せます。OpenAIの公式ドキュメントもこの手順を案内しています。

npx @modelcontextprotocol/inspector@latest

Claude Codeを使っているなら、公式プラグインmcp-server-devに雛形を作らせる方法もあります。/plugin install mcp-server-dev@claude-plugins-officialで導入し、/mcp-server-dev:build-mcp-serverを実行すると、用途を聞いたうえでリモートHTTP版かローカルstdio版の骨組みを生成します。

Pythonでの自作をもう一段詳しく追う場合はFastMCPでMCPサーバーを自作するPython完全ガイド、つながらないときの切り分けはMCPサーバーのデバッグ方法｜接続エラーの切り分け手順、作ったものを公開する手順はMCP Registry完全ガイド｜公開手順6ステップにあります。

MCPとAPI・関数呼び出しは何が違うのか

検索で最も多い疑問のひとつです。結論から言うと、MCPはAPIの置き換えではなく、APIの前に1枚かぶせる共通の話し方です。

観点	通常のWeb API	関数呼び出し（Function calling）	MCP
仕様の決まり方	提供元ごとに独自	AIモデル提供元ごとに独自の書式	オープンな共通仕様（JSON-RPC 2.0ベース）
誰が実装するか	サービス提供元	アプリ開発者が毎回定義	サーバー側が1回実装すれば、対応する全クライアントから使える
提供できるもの	エンドポイント	関数（ツール）	tools・resources・promptsの3種
発見の仕組み	ドキュメントを人が読む	アプリ側に事前定義	tools/list等でクライアントが実行時に取得する
権限・同意	APIキー／OAuth	アプリ側の作り込み次第	仕様として「ツール実行前にホストが利用者の明示的な同意を得る」ことを求めている

MCPサーバーの中身は、多くの場合そのサービスのAPIを呼んでいます。違うのは「AIアプリがそれを見つけて、使い方を理解して、同意を取って呼ぶまでの流れ」が標準化されている点です。公式が「一度作れば、どこにでも統合できる」と表現しているのはこの部分を指します。

法人でMCPサーバーを入れる前に確認する5点

MCPは「任意のデータアクセスとコード実行の経路」を開く仕組みです。仕様書自身が冒頭で、実装者が必ず向き合うべき事項として安全性と信頼を挙げています。導入前に社内で押さえるべき点を、公式のセキュリティ文書から5つに絞りました。

1. 権限（スコープ）を最小から始める

公式のセキュリティ文書は「スコープ最小化」を独立した攻撃・緩和策の項目として扱っています。files:*・db:*・admin:*のような広いスコープを最初にまとめて要求すると、トークンが1本漏れただけで横方向の情報アクセスと権限の連鎖が起きる、という整理です。推奨されているのは、読み取り中心の最小スコープから始め、必要になった時点で個別に引き上げる段階的なモデルです。

2. 認証情報を設定ファイルに直書きしない

Claude Codeの.mcp.jsonは環境変数の展開に対応しています（${VAR}と${VAR:-default}）。Codexのconfig.tomlにはbearer_token_env_varやenv_http_headers、接続時にヘッダーを生成するhttp_headers_helperがあります。Cursorのmcp.jsonもcommand・args・env・url・headersで変数を解決します。リポジトリに入る設定ファイルに実値を書く理由はありません。

3. ログと監査の出どころを決める

2026-07-28でLoggingは非推奨になり、公式はstderr（stdioの場合）またはOpenTelemetryへの移行を推奨しています。あわせて、_metaのキーとしてOpenTelemetryのトレース文脈（traceparent・tracestate・baggage）を伝搬する慣行が文書化されました。「誰の指示で、どのツールが、いつ呼ばれたか」を後から追えるかどうかは、この段階で決まります。

4. 攻撃の型を知っておく

公式セキュリティ文書が挙げる主な攻撃には、混乱した代理（Confused Deputy）、トークンのすり抜け（Token Passthrough）、サーバー側リクエストフォージェリ（SSRF）、状態ハンドルの乗っ取り、ローカルMCPサーバーの侵害、OAuth認可URLの検証不備、mix-up攻撃などがあります。ローカルサーバーについては「クライアント設定に悪意ある起動コマンドを仕込む」「サーバー本体に悪意あるペイロードを同梱する」「localhostに放置された安全でないサーバーへDNSリバインディングで到達する」という3つの具体的な手口が明記されています。

OpenAI側の文書はさらに踏み込んで、「MCPの開発元を信頼していても安全にはならない」ケースを表で列挙しています。たとえば顧客サポート用MCPには、攻撃者が問い合わせという形でプロンプトインジェクションを送り込めるため、「信頼できない入力が含まれ得るMCPは、開発元を信頼していても使わない」ことを推奨しています。防御の具体的な実装はMCPサーバーの脆弱性とは？リスクと防御7選にまとめてあります。

5. 誰が追加できるかを決める

技術より先に効くのがここです。Claudeでは、TeamおよびEnterpriseプランのコネクタ追加は管理者に限定されています。組織はコネクタのツール単位でask／blockedを設定でき、blockedにしたツールはモデルから見えなくなります。Claude Codeのプロジェクトスコープ（.mcp.json）は対話セッションでの承認が必要で、承認の可否は設定ファイル側でも制御できます。「個人が勝手に足せる状態のまま全社展開しない」というのが、いちばん安上がりな統制です。

認可そのものの実装を追う場合はMCP認可の実装ガイド｜OAuth 2.1対応を参照してください。なお2026-07-28では、認可サーバーがRFC 9207のissパラメータを返し、クライアントが認可コード引き換え前に検証することが求められるようになりました。

よくある失敗パターンと回避策

失敗1：urlだけ書いてtypeを書かない

❌ {"mcpServers": {"example": {"url": "https://mcp.example.com/mcp"}}}
⭕ {"mcpServers": {"example": {"type": "http", "url": "https://mcp.example.com/mcp"}}}

なぜ重要か：Claude Codeはtypeがないエントリをstdioサーバーとして読むため、そのサーバーは読み込まれずスキップされます。他クライアント向けの設定ブロックをコピーしたときに最も起きやすい失敗です。

失敗2：設定ファイルにAPIキーを直書きしてコミットする

❌ "env": {"API_KEY": "sk-live-xxxxxxxx"} を.mcp.jsonに書いてリポジトリへ入れる
⭕ "env": {"API_KEY": "${MY_SERVICE_TOKEN}"} と書き、実値は環境変数やシークレット管理側に置く

なぜ重要か：プロジェクトスコープの設定ファイルはチーム共有が前提で、バージョン管理に入ります。公式が環境変数展開を用意しているのは、ここで事故が起きるからです。

失敗3：非公式サーバーを本番の業務データにつなぐ

❌ 検索で上位に出た第三者ホストの「Stripe MCP」をそのまま業務アカウントに接続する
⭕ 提供元自身がホストする公式エンドポイントを使い、公式レジストリの名前空間で提供元を確認する

なぜ重要か：OpenAIの公式ドキュメントは「カスタムMCPサーバーはOpenAIが開発・検証したものではなく、第三者サービスである」と明記したうえで、提供元ホストのサーバーを選ぶよう具体名つきで推奨しています。

失敗4：旧仕様のセッション前提で設計する

❌ Mcp-Session-Idで会話の状態を持ち回る設計にする
⭕ 状態が必要なら、サーバーが発行したハンドルをツールの引数として明示的に受け渡す

なぜ重要か：2026-07-28でプロトコル層のセッションは撤去されました。公式ブログは「トランスポートに隠れたセッション状態より、モデルから見えるハンドルを渡すほうがうまくいく」と説明しています。旧設計のままだと、負荷分散の後ろに複数インスタンスを並べた瞬間に壊れます。

失敗5：ツールを増やしすぎる

❌ 1つのサーバーに40も50もツールを載せて全部を常時有効にする
⭕ 用途ごとにサーバーを分け、クライアント側で必要なものだけ有効にする

なぜ重要か：ツール定義はすべてモデルの文脈を消費します。2026-07-28で一覧結果にキャッシュのヒント（ttlMs・cacheScope）と決定的な順序が導入されたのも、クライアント側のキャッシュと上流のプロンプトキャッシュを安定させるためです。数が増えるほど選択精度は下がります。

よくある質問

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

標準化されたプロトコルの窓口を通じて、AIアプリケーションに特定の機能やデータを公開するプログラムです。公開できるのはtools（モデルが呼ぶ関数）、resources（読み取り専用のデータ）、prompts（指示テンプレート）の3種類です。

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

MCPはAPIの置き換えではなく、AIアプリとツールの間の共通の話し方を決めた規格です。MCPサーバーの内部では多くの場合そのサービスのAPIを呼んでいます。違いは、発見（tools/list）・呼び出し（tools/call）・同意の取り方が標準化されていて、対応クライアントならどれからでも同じように使える点です。

無料のMCPサーバーはありますか？

あります。公式リファレンス実装7本（Everything・Fetch・Filesystem・Git・Memory・Sequential Thinking・Time）はオープンソースで公開されています。ベンダー提供のサーバーは、その元サービスの契約条件に従います。MCPサーバーの利用自体に追加料金がかかるかは提供元ごとに異なり、2026年9月25日時点でMCPの公式サイトに統一的な料金の記載はありません。

MCPサーバーは自作できますか？

できます。公式SDKはTier 1がTypeScript・Python・C#・Go・Rust、Tier 2がJava・Ruby、Tier 3がSwift・PHP・Kotlinです。Pythonならmcp[cli]を入れてMCPServerのインスタンスを作り、関数に@mcp.tool()を付けてmcp.run(transport="stdio")で待ち受ければ動きます。

Claudeでの設定方法は？

Claude Codeならclaude mcp add --transport http <name> <url>、ローカルのstdioサーバーならclaude mcp add <name> -- <起動コマンド>です。チーム共有はプロジェクト直下の.mcp.json。ブラウザ版Claudeはclaude.ai/customize/connectorsから追加しますが、TeamとEnterpriseでは管理者のみが追加できます。

ChatGPTはMCPに対応していますか？

対応しています。OpenAIの公式ドキュメントによれば、ChatGPTのSettingsからSecurity and loginでDeveloper modeを有効にし、ChatGPT Pluginsの画面でサーバーURL（/mcpを含む）を登録します。開発者モードの利用可否はアカウントやワークスペースのポリシーによる、と注記されています。ローカルのCodexは~/.codex/config.tomlの[mcp_servers.<name>]で設定します。

MCPサーバーの接続方式は？

公式の標準トランスポートはstdioとStreamable HTTPの2つです。stdioはクライアントが起動した子プロセスの標準入出力、Streamable HTTPは単一エンドポイントへのHTTP POSTです。旧HTTP＋SSEは非推奨で、最低12か月の猶予期間ののち撤去対象になります。

MCPサーバーの何がすごいのですか？

「一度作れば、対応する全クライアントから使える」点です。AIアプリごとに連携を作り分ける必要がなくなります。2026-07-28でステートレスになったことで、リモートMCPサーバーは普通のHTTPワークロードと変わらなくなり、既存のAPI基盤やサーバーレスにそのまま載せられるようになりました。

MCPサーバーはなぜ必要なのですか？

AIアプリが増え、つなぎたいツールも増えると、組み合わせの数だけ独自連携を書くことになるためです。公式仕様はこの問題を、プログラミング言語とエディタの組み合わせ爆発を解いたLanguage Server Protocolになぞらえて説明しています。

セキュリティ上の注意点は？

公式セキュリティ文書は混乱した代理、トークンのすり抜け、SSRF、状態ハンドルの乗っ取り、ローカルサーバーの侵害などを挙げています。実務では、提供元公式のサーバーだけを使う、スコープを最小から始める、設定ファイルにトークンを直書きしない、書き込み系ツールの承認を必須にする、の4点が効きます。

MCPサーバーの数はどれくらいありますか？

Anthropicは2026年7月28日の発表時点で、Claudeのコネクタディレクトリに950本超のMCPサーバーが掲載されていると公表しています。公式レジストリ（registry.modelcontextprotocol.io）にはこれとは別にコミュニティ登録分が多数ありますが、2026年9月25日時点で総数を示す公式の記載はありません。

運営元 Uravation よりAIエージェントを構想から本番運用まで進める順番と、体制・KPIの決め方をまとめた資料を無料で公開しています。 AIエージェント導入ロードマップを受け取る（無料）

参考・出典

• What is the Model Context Protocol (MCP)? — Model Context Protocol 公式ドキュメント（参照日: 2026-09-25）
• Specification 2026-07-28 — Model Context Protocol 公式仕様（参照日: 2026-09-25）
• Key Changes（2025-11-25からの変更点） — Model Context Protocol 公式仕様（参照日: 2026-09-25）
• Understanding MCP servers — Model Context Protocol 公式ドキュメント（参照日: 2026-09-25）
• Transports Overview — Model Context Protocol 公式仕様（参照日: 2026-09-25）
• Security Best Practices — Model Context Protocol 公式ドキュメント（参照日: 2026-09-25）
• SDKs — Model Context Protocol 公式ドキュメント（参照日: 2026-09-25）
• The 2026-07-28 Specification — Model Context Protocol 公式ブログ（2026年7月28日公開・参照日: 2026-09-25）
• Bringing MCP 2026-07-28 to Claude — Anthropic 公式ブログ（2026年7月28日公開・参照日: 2026-09-25）
• Connect Claude Code to tools via MCP — Anthropic 公式ドキュメント（参照日: 2026-09-25）
• Building MCP servers for plugins and API integrations — OpenAI 公式ドキュメント（参照日: 2026-09-25）
• Model Context Protocol（Codex） — OpenAI 公式ドキュメント（参照日: 2026-09-25）
• Model Context Protocol (MCP) — Cursor 公式ドキュメント（参照日: 2026-09-25）
• modelcontextprotocol/servers — 公式リファレンス実装リポジトリ（参照日: 2026-09-25）
• Official MCP Registry — 公式レジストリ（提供元名前空間の確認に使用・参照日: 2026-09-25）

まとめ：今日から始める3つのアクション

MCPサーバーは「AIアプリに機能とデータを渡すための標準の窓口」です。2026年9月25日時点の前提は、仕様 2026-07-28 によるステートレス化、公式トランスポートはstdioとStreamable HTTPの2つ、Roots・Sampling・Logging・HTTP＋SSE・DCRは非推奨、の3点に集約されます。

1. 今日やること：使っているクライアントを1つ決め、提供元公式のリモートMCPサーバーを1本だけ追加して、読み取り系のツールを1回呼んでみる。typeの書き忘れとトークンの直書きだけ気をつければ、ここで詰まることはほとんどありません。
2. 今週中：チームで使うものはプロジェクトスコープ（Claude Codeなら.mcp.json、Cursorなら.cursor/mcp.json）に移し、認証情報を環境変数へ追い出す。書き込み系ツールを含むサーバーは、承認の扱いを決めてから共有する。
3. 今月中：社内で「誰がサーバーを追加できるか」を決める。ClaudeのTeam・Enterpriseなら管理者限定の仕様をそのまま統制点に使えます。並行して、自社データを出す小さなサーバーを1本、読み取り専用で作ってみると判断材料が一気に増えます。

あわせて読みたい

• MCP次期仕様解説｜ステートレスコアとTasks拡張化 — 2026-07-28の変更を提案単位で追う
• MCPサーバーの脆弱性とは？リスクと防御7選 — 導入前のリスク評価に使う

著者：佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。著書『AIエージェント仕事術』。100社以上の企業向けAI研修・導入支援に携わる。

あわせて読みたい

• ▸ Claude Sonnet 5.5 API｜料金・変更点と移行【2026年9月】
• ▸ CodexにGPT-6 SolとLuna｜切替と制限時の対処【2026年9月】
• ▸ Claude CodeがAGENTS.md対応｜優先順位と設定【2026年9月】
• ▸ RAGとは｜仕組み・作り方・精度を上げる順番【2026年9月】
• ▸ AIエージェントとは｜仕組み・種類・作り方の最短手順【2026年9月】