MCPとは — AIと外部ツールをつなぐ標準プロトコルの仕組み・採用状況・Claudeでの使い方
MCPとは、AIと外部ツール・データをつなぐオープン標準です。仕組みからClaude.ai / Claude Code / APIでの使い方、認証、セキュリティ、代表的なサーバーまでをまとめます。
MCPとは、AIアプリケーションを外部のデータソースやツールに接続するためのオープン標準プロトコル(Model Context Protocol)です。Anthropicが2024年11月に公開し、現在はOpenAIのChatGPTやGoogleのGemini、VS CodeやCursorといった開発ツールまで、主要なAIプロダクトが横断的に採用しています。VS Code本体(GitHub Copilot Chat)のMCPサーバー設定はVS Code MCP設定ガイドにまとめています。2025年12月にはLinux Foundation傘下の中立組織へ管理が移管され、一企業の規格から業界標準へと立場を変えました。
本記事では、MCPの仕組みと最新仕様、業界での採用状況、そしてClaude.ai・Claude Code・Claude APIという3つの利用面での使い方までを扱います。
MCPで何ができるのか — 具体例から掴む
抽象的な定義よりも、実際に動く例を見るほうが早く全体像を掴めます。MCP対応のAIアプリケーションでは、次のような依頼が自然文で成立します。
- 「JIRAの
ENG-4521に書かれた機能を実装して、GitHubにPRを作成して」— 課題管理とリポジトリを1つの会話で横断する - 「PostgreSQLの
ordersテーブルから、この機能を使ったユーザー10人のメールアドレスを取得して」— DBへの問い合わせを自然文で実行する - 「Sentryの直近24時間のエラーを調べて、どのデプロイが原因か推定して」— 監視ツールのデータをそのまま調査に使う
- 「Slackに投稿された最新のFigmaデザインをもとに、メールテンプレートを更新して」— デザインツールとチャットの内容をコードに反映する
共通するのは、AIが複数の外部システムを同じ流儀で読み書きしていることです。サービスごとに連携コードを書くか、人間が画面間でコピー&ペーストしていた作業が、MCPサーバーを接続するだけで会話の射程に入ります。この「接続するだけ」を支えているのが、次に見るプロトコルの構造です。
MCPの仕組み — ホスト・クライアント・サーバーの3層構造
MCPはクライアント・サーバー型のアーキテクチャです。登場人物は3者で、役割は明確に分かれています。
| 参加者 | 役割 | 具体例 |
|---|---|---|
| MCPホスト | 役割AIアプリケーション本体。複数のMCPクライアントを管理する | 具体例Claude Code、Claude Desktop、VS Code、ChatGPT |
| MCPクライアント | 役割サーバー1つにつき1つ生成され、専用の接続を維持する部品 | 具体例ホスト内部のコネクタ |
| MCPサーバー | 役割外部システムの機能・データをMCP仕様で公開するプログラム | 具体例GitHubサーバー、Sentryサーバー、自作の社内APIサーバー |
ホストはサーバーごとにクライアントを1つずつ持ちます。Claude CodeがGitHubサーバーとSentryサーバーの両方に接続すると、内部では2つのMCPクライアントが生成され、それぞれが専用の接続を維持します。サーバーは1度作れば、Claude CodeでもVS CodeでもChatGPTでも同じものを使い回せます。
データ層とトランスポート層
プロトコルの中身は2つの層に分かれます。内側のデータ層はJSON-RPC 2.0ベースの交換プロトコルで、機能の発見・実行・通知の形式を定めます。外側のトランスポート層は、そのメッセージをどう運ぶかを定める通信路です。ローカルで完結する処理はstdio(標準入出力)、リモートのSaaS連携はStreamable HTTPが基本の使い分けになります。具体的な選び方は後述の「接続方式」で扱います。
サーバーの3要素 — Tools・Resources・Prompts
MCPサーバーがクライアントに公開できる機能は、3つの基本要素として定義されています。
| 種別 | 内容 | Claude Codeでの使い方 |
|---|---|---|
| Tools | 内容AIが呼び出せる実行可能な関数(API呼び出し、DB照会等) | Claude Codeでの使い方通常のツール呼び出し。ユーザー承認あり |
| Resources | 内容コンテキストとして読み取れるデータ(ファイル内容、レコード等) | Claude Codeでの使い方@server:scheme://path の@メンションで参照 |
| Prompts | 内容再利用できるテンプレート(定型ワークフロー等) | Claude Codeでの使い方/mcp__server__prompt のコマンドで実行 |
サーバー側のツール一覧が変わると、クライアントが購読していれば(subscriptions/listen)変更通知が届き、再接続なしで機能が更新されます。サーバーがユーザーに確認や追加入力を求められる仕組みもあります(Elicitation)。
2026-07-28版で仕様はどう変わったか
MCPの仕様は日付形式のバージョンで管理され、最新版は2026-07-28版です。この改訂の眼目は、接続の作法をステートレスなWeb APIの設計に寄せたことです。従来のクライアント・サーバー間で毎回やり取りしていたinitialize/initializedのハンドシェイクが廃止され、各リクエストが自分のプロトコルバージョンと対応機能をメタ情報として持ち歩く形になりました。サーバーの対応バージョンや機能を先に確認したいクライアントは、任意のタイミングでserver/discoverを呼べます。
ステートレス化はハンドシェイクだけにとどまりません。プロトコルレベルのセッションとMcp-Session-IdヘッダーもStreamable HTTPトランスポートから削除され、tools/listのような一覧系エンドポイントは接続ごとに内容が変わらなくなりました。呼び出しをまたいで状態を保ちたいサーバーは、通常のツール引数として渡すサーバー発行のハンドルを使う設計に切り替える必要があります。
サーバーからクライアントへの逆方向のやり取りも作法が変わりました。従来roots/listやsampling/createMessageのようにサーバーが割り込みでリクエストを送っていた部分は、Multi Round-Trip Requests(MRTR)というパターンに一本化されました。サーバーはresultType: "input_required"を持つ結果を返して必要な情報をinputRequestsで伝え、クライアントはinputResponsesを添えて元のリクエストをリトライします。
同じ改訂で、Roots・Sampling・Loggingの3機能とOAuth 2.0のDynamic Client Registration(DCR、クライアントの動的登録)が非推奨になりました。移行先は、Rootsがツールの引数やリソースURIでディレクトリを渡す方法に、Samplingがサーバーからのプロバイダー直接呼び出しに、Loggingが標準エラー出力かOpenTelemetryへのログ出力に、それぞれ替わります。DCRはClient ID Metadata Documentsでの登録に置き換わり、対応していない認可サーバーとの後方互換では引き続き使えます。いずれも既存のサーバーがすぐ動かなくなるわけではありません。仕様は12か月以上の廃止猶予期間を設けており、2025-11-25版以前のハンドシェイク方式のクライアント・サーバーとも下位互換で通信できます。
なぜMCPが必要なのか — M×N問題とAPI統合との違い
MCP以前のAIアプリケーション開発では、外部サービスとの接続は「M×N問題」を抱えていました。M個のAIアプリケーションとN個の外部サービスをつなぐにはM×N通りの個別統合が必要で、AIアプリ側はサービスごとのAPI仕様を、サービス側はAIアプリごとの呼び出し方を作り込む必要がありました。
MCPはこの構図をM+Nに変えます。AIアプリはMCPクライアントを1度実装すれば任意のMCPサーバーに接続でき、サービス側はMCPサーバーを1度書けば任意のMCP対応アプリから使われます。プログラミング言語の補完・診断機能をエディタ横断で共通化したLanguage Server Protocol(LSP)と同じ発想で、MCPの仕様自体もLSPから着想を得たと明記されています。
従来の統合方法との違いを並べると次のとおりです。
| 観点 | 個別API統合 | 各社の関数呼び出し機能 | MCP |
|---|---|---|---|
| 接続の単位 | 個別API統合サービスごとに個別実装 | 各社の関数呼び出し機能モデルベンダーごとに定義 | MCP共通プロトコルで標準化 |
| 再利用性 | 個別API統合低い(アプリ固有) | 各社の関数呼び出し機能ベンダー内に限定 | MCPクライアント横断で再利用可 |
| 機能の発見 | 個別API統合ドキュメントを人が読む | 各社の関数呼び出し機能開発者が事前定義 | MCP動的に発見できる |
| 双方向性 | 個別API統合なし | 各社の関数呼び出し機能原則なし | MCP通知・Elicitationあり |
注意したいのは、MCPが各モデルの関数呼び出し(Function Calling / Tool Use)を置き換えるものではない点です。LLMが「どのツールをどの引数で呼ぶか」を決める部分は引き続き各モデルの機能で、MCPはその外側にある「ツールの定義・発見・実行・データ授受」を標準化します。両者は競合ではなく階層が違います。
MCPのエコシステム全体像 — 採用状況とガバナンス
MCPの現在地を理解するうえで重要なのは、これがもはや「Anthropicのプロトコル」ではないという点です。公開から約2年で、競合を含む主要AIベンダーが横並びで採用する業界標準になりました。
採用のタイムライン
| 時期 | 出来事 |
|---|---|
| 2024年11月 | 出来事AnthropicがMCPをオープンソース標準として公開 |
| 2025年3月 | 出来事OpenAIが採用を表明(Agents SDK、ChatGPTデスクトップアプリ等) |
| 2025年4月 | 出来事GoogleがGeminiでの対応方針を表明 |
| 2025年6月 | 出来事仕様2025-06-18版(Elicitation追加など) |
| 2025年11月 | 出来事仕様2025-11-25版(OpenID Connect対応、Tasks実験導入など) |
| 2025年12月9日 | 出来事Linux Foundation傘下のAgentic AI Foundationへ移管 |
| 2026年7月28日 | 出来事仕様2026-07-28版(ステートレス化、Roots/Sampling/Loggingの非推奨化) |
OpenAIの採用は、MCPの性格を決定づけた転換点でした。最大の競合がAnthropic発のプロトコルをそのまま取り込んだことで、特定ベンダーの囲い込み規格になるという初期の懸念は薄れていきました。現在はChatGPT、Gemini、Microsoft Copilot系の製品群、VS Code、Cursorなど、AIを組み込む主要プロダクトの多くがMCPクライアントとして動作します。Cursor側のmcp.json設定はCursor MCP設定ガイドにまとめています。
ガバナンスの中立化 — Agentic AI Foundation
2025年12月9日、AnthropicはMCPをLinux Foundation傘下の新組織Agentic AI Foundation(AAIF)に寄贈しました。AAIFはAnthropic・Block・OpenAIの3社が共同設立し、Google・Microsoft・AWS・Cloudflare・Bloombergが支援に名を連ねています。競合同士が同じ財団に出資する形で、プロトコルの将来が一企業の経営判断に左右されない体制が整いました。
寄贈時点で公表された規模感は、アクティブな公開MCPサーバーが1万件超、Claude内で使える公式コネクタが75超、PythonとTypeScriptのSDK合計で月間9,700万ダウンロード超というものです。仕様の改訂はGitHub上のSEP(仕様改善提案)プロセスとワーキンググループで進められています。
つながる先はどう広がっているか — サーバーの供給源と代表例
接続先のMCPサーバーには、大きく3つの供給源があります。
1つ目はサービス事業者自身が運営する公開リモートサーバーです。GitHub、Sentry、Notion、Stripe、Slackなどが代表例で、多くがOAuth認証を採用しています。2つ目はオープンソースのリファレンス実装やコミュニティ製サーバーで、ファイルシステム操作や、ブラウザ自動化のPlaywrightサーバーのような汎用機能をローカルで提供します(導入手順はPlaywright MCPサーバーの使い方にまとめています)。3つ目が自作サーバーで、社内APIや独自データベースをAIに開放する用途です。
Claude.aiのディレクトリでは、コネクタの信頼度が3段階で示されます。Verifiedは品質とセキュリティをAnthropicが個別にレビュー済み、Communityは自動チェックのみを通過、Customはユーザー自身が追加した未レビューのコネクタです。信頼するかどうかの最終判断は、Verified以外では接続する側に委ねられます(詳細は後述の「セキュリティ」)。GitHub・Sentry・Notion・Slackなど代表的なサーバーを用途別に取り上げた早見はおすすめMCPサーバー10選にまとめています。
Claudeでの3つの使い方 — 何ができるかの早見表
Claudeエコシステムには、MCPにつながる面が3つあります。同じMCPサーバーでも、面によって接続方法・認証・対応トランスポートが異なります。
| 利用面 | 主な用途 | 接続方法 | 対応トランスポート | 認証 |
|---|---|---|---|---|
| Claude.ai / Desktop | 主な用途日常のチャットでSaaS連携・ローカル連携 | 接続方法コネクタ追加(claude.ai) / 拡張機能インストール(Desktop) | 対応トランスポートStreamable HTTP(リモート)、stdio(Desktopの拡張機能) | 認証OAuthが中心 |
| Claude Code | 主な用途開発フローに外部ツールを組み込む | 接続方法claude mcp add | 対応トランスポートstdio、HTTP、SSE(非推奨)、WebSocket | 認証OAuth・ヘッダー・環境変数 |
| Claude API | 主な用途自社アプリにサーバー側で組み込む | 接続方法Messages APIのmcp_servers | 対応トランスポートHTTP(Streamable HTTP / SSE)のみ | 認証取得済みOAuthトークンを自前で付与 |
Claude.aiとClaude Desktop — コネクタと拡張機能
claude.aiでは、Google Drive・Gmail・Google Calendar・GitHub・Slack・Microsoft 365などの一次連携がAnthropic自身によって提供され、認証を済ませるだけで使えます。Team / Enterpriseプランの組織は、コネクタのツールごとに許可・確認・拒否を設定でき、Claude Codeはこの設定を起動時に読み込んでローカルで強制します。自分でMCPサーバーをつなぎたい場合は、サードパーティのリモートMCPサーバーを追加します。
Claude Desktopは、これに加えて.mcpb(MCP Bundle)形式のローカル拡張機能に対応しています。手元のファイルやローカルツールに触れる連携はDesktopの拡張機能を入れて初めて使え、Web版やモバイルにはこの仕組みがありません。プラットフォームごとの対応範囲や導入手順はClaudeアプリの入手方法と使い方で扱っています。ディレクトリ未収録の自作サーバーを直接つなぐ場合は、claude_desktop_config.jsonを手書きする方法もあります。書き方はClaude Desktop MCP設定ガイドにまとめています。
Claude Code — claude mcp addで接続する
Claude Codeへのリモートサーバー追加はclaude mcp addの1行です。SentryのようにOAuth対応のサーバーは、追加後に/mcpを実行し、ブラウザでログインすれば認証が完了します。
claude mcp add --transport http sentry https://mcp.sentry.dev/mcpローカルプロセスとして動かすstdioサーバーは、--区切りで起動コマンドを渡します。
claude mcp add --transport stdio playwright -- npx -y @playwright/mcp@latest設定の保存場所はlocal(既定、自分のみ・現在のプロジェクトのみ)、project(.mcp.jsonにチーム共有)、user(自分のみ・全プロジェクト)の3スコープから選べます。claude mcp addの全オプション、.mcp.jsonの書式、OAuth認証の詳細、出力トークンの上限調整まではClaude Code MCP設定ガイドにまとめてあります。Claude Code自体の全体像はClaude Code完全ガイドを参照してください。
Claude API — Messages APIのmcp_servers
自社アプリにサーバー側でMCPを組み込みたい場合は、Messages APIのmcp_serversパラメータを使うと、MCPクライアントを自前実装せずにリモートMCPサーバーへ接続できます。ベータヘッダーmcp-client-2025-11-20を付けて呼び出します。
curl https://api.anthropic.com/v1/messages \
-H "X-API-Key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "anthropic-beta: mcp-client-2025-11-20" \
-d '{
"model": "claude-opus-5",
"max_tokens": 1000,
"messages": [{"role": "user", "content": "What tools do you have available?"}],
"mcp_servers": [{"type": "url", "url": "https://example-server.example.com/mcp",
"name": "example-mcp", "authorization_token": "YOUR_TOKEN"}],
"tools": [{"type": "mcp_toolset", "mcp_server_name": "example-mcp"}]
}'このコネクタが対応するのはツール呼び出しのみで、Resources・Promptsは含みません。接続先はHTTPで公開されたリモートサーバーに限られ、ローカルのstdioサーバーは直接つなげません。データ保持もゼロデータ保持(ZDR)の対象外で、標準の保持ポリシーが適用されます。ローカルのstdioサーバーやMCPのプロンプト・リソースまで扱いたい場合は、Anthropic SDKが提供するMCPヘルパー関数を使って自前のMCPクライアントと組み合わせます。API・SDK全体の構成はAnthropic API完全ガイド、Agent SDKでの実装はAgent SDKクイックスタートを参照してください。
接続方式とRemote MCPの認証
トランスポートの選択は、接続先がローカルかリモートかでほぼ決まります。
| トランスポート | 通信方式 | 主な用途 | Claude Codeでの指定 |
|---|---|---|---|
| stdio | 通信方式標準入出力によるプロセス間通信 | 主な用途ローカル完結処理(ファイル操作・自作スクリプト) | Claude Codeでの指定--transport stdio |
| Streamable HTTP | 通信方式HTTP POST+必要に応じてSSEストリーミング | 主な用途リモートのSaaS連携(推奨) | Claude Codeでの指定--transport http |
| SSE | 通信方式HTTP GET中心のイベントストリーム | 主な用途旧式のリモート接続。仕様上は非推奨 | Claude Codeでの指定--transport sse |
| WebSocket | 通信方式持続的な双方向接続 | 主な用途サーバー起点でイベントをpushしたい場合 | Claude Codeでの指定add-jsonでtype: wsを指定 |
stdioはクライアントがサーバーを子プロセスとして起動する方式で、ネットワークを介さないぶん高速です。Streamable HTTPはリモートの常駐サーバーと通信する方式で、BearerトークンやAPIキーといったHTTP標準の認証が使え、仕様はOAuthでの認証トークン取得を推奨しています。SSEは2025-03-26版から非推奨扱いで、後方互換のためだけに残っています。
OAuthでの認証は、サーバーが対応していればDynamic Client Registrationで自動的に進みます。対応していないサーバーでは、開発者ポータルで事前にクライアントIDを発行し、コールバックポートを固定して手動で登録する必要があります。認証トークンの保存先はOSによって異なり、Claude CodeではmacOSが暗号化されたキーチェーン、Linux/Windowsはパーミッションで保護されたファイルという構成です。いずれの環境でも、期限が切れると自動で更新されます。401応答起点の認可サーバー発見からPKCE付きトークン取得までの一連の流れはリモートMCPのOAuth認証で扱っています。
セキュリティ — 何を許可すべきか
MCPは外部システムへの強力なアクセス経路であると同時に、攻撃の入口にもなり得ます。仕様自体が「ユーザーの明示的な同意と制御」「データプライバシー」「ツールの安全性」を実装者への基本原則として掲げており、プロトコルレベルで強制できない部分を各クライアントの承認フローが補う構造です。
実際に指摘されてきたリスクは、外部コンテンツ経由のプロンプトインジェクション、信頼済みツールに偽装した同名ツールのすり替え、複数ツールの組み合わせによるデータ持ち出しなどです。Anthropicのレビューが及ぶのはVerified表示のあるコネクタだけで、Community(自動チェックのみ)やCustom(未レビュー)は掲載されていても安全性が保証されるわけではありません。利用側でできる対策をまとめます。
| 観点 | 対応 |
|---|---|
| サーバーの信頼性 | 対応サードパーティ製サーバーは導入前に提供元とソースコードを確認する |
| 認証情報の管理 | 対応OAuthトークンの保存先はOS依存。設定ファイルにキーを直書きせず環境変数展開で逃がす |
| 接続の統制 | 対応チームは承認ダイアログ、組織は許可リスト・拒否リストで接続先を絞る |
| 出力の検査 | 対応外部コンテンツを取り込むツール(Webスクレイパー等)はインジェクションの媒介になり得る前提で扱う |
| 権限の最小化 | 対応APIトークンはfine-grainedで対象範囲を限定するなど、権限を絞る |
「どのサーバーを信頼するか」の判断はクライアントが肩代わりしてくれません。特に書き込み系のツール(Issue作成、メッセージ投稿、DB更新)を持つサーバーは、読み取り専用のものと分けて段階的に導入すると、事故時の影響範囲を限定できます。組織として接続先を統制したい場合は、Claude Codeなら管理者が配布する設定ファイルと許可・拒否リストによる集中管理も用意されています。接続前の信頼確認・権限ルール・組織管理の3層で許可範囲を決める基準はMCPセキュリティガイドにまとめています。
自作の入口 — SDKでサーバーを作るには
MCPサーバーはTypeScript・Pythonを筆頭に複数言語のSDKが提供されており、どの言語でも数十行から書き始められます。作るものはToolsかResourcesかPromptsの組み合わせで、テストにはMCP Inspectorという公式ツールが使えます。Claude Codeには、/plugin install mcp-server-dev@claude-plugins-officialで導入できる公式プラグインもあり、対話形式でリモートHTTPサーバーかローカルstdioサーバーの雛形を生成できます。
TypeScript SDKでのツール定義から、MCP Inspectorでのテスト、Claude Codeへの接続、npmとMCPレジストリでの配布までは、MCPサーバを自作してClaude Codeにつなぐで実装コードつきに扱っています。
つまずいたときの切り分け方
MCPサーバーがうまく動かないときの原因は、大きく4層に分けられます。設定ファイルが読まれていない、サーバーのプロセスが起動していない、認証が通っていない、接続済みなのにツールが呼ばれない、のいずれかです。stdioとリモートでは症状の出方も違い、stdioは起動時のエラーがそのまま見えるのに対し、リモートは接続の途中で止まっているように見えることが多くなります。
もう1つよくあるつまずきが、MCPツールの出力が大きすぎて警告が出るケースです。Claude Codeは1万トークンを超えると警告を表示し、既定では2万5,000トークンで打ち切ります。上限は環境変数MAX_MCP_OUTPUT_TOKENSで引き上げられます。大量のツールを持つサーバーを複数つなぐとコンテキスト消費も増えるため、ツール定義を必要になるまで読み込まないツール検索の仕組みが既定で有効になっています。ツール呼び出しそのものをコード実行に置き換えて消費を抑える設計論はMCPでコード実行する設計が参考になります。
設定・起動・認証・ツール表示の4層を順に潰す具体的な手順はMCPサーバーに接続できないときの切り分け手順にまとめてあります。
よくある質問
MCPと通常のAPIは何が違いますか?
通常のAPIは、人間の開発者が仕様書を読んで呼び出しコードを書く前提の接続方法です。MCPはAIアプリケーションが接続先の機能を動的に発見し、共通のメッセージ形式で呼び出せるように標準化した点が異なります。多くのMCPサーバーは内部で既存のAPIを呼んでおり、APIを置き換えるのではなく「AIから使いやすくする変換層」と捉えるのが正確です。
MCPの利用にお金はかかりますか?
プロトコル仕様とSDKはオープンソースで、利用自体は無料です。費用が発生するのは、MCPサーバーが接続する先のサービス(SaaSの利用料、LLMのトークン課金など)で、MCPはその間の通信規格に過ぎません。
ChatGPTやGeminiでもMCPは使えますか?
使えます。OpenAIは2025年3月に採用を表明し、ChatGPTやAgents SDKでMCPサーバーへの接続に対応しています。Googleも2025年4月にGeminiでの対応方針を示しました。同じMCPサーバーがClaude・ChatGPT・Gemini・VS Code・Cursorなど複数のクライアントから使い回せるのが、標準プロトコルであることの実利です。
MCPサーバーとMCPクライアントはどちらを作ればよいですか?
自分のデータやツールをAIに使わせたい場合はサーバー、AIアプリケーション自体を開発している場合はクライアントです。大半の開発者が作るのはサーバー側で、Claude CodeやChatGPTのような既存ホストをクライアントとしてそのまま使います。
Function Calling(ツール呼び出し)があればMCPは不要では?
役割が違います。Function CallingはLLMが「どの関数をどの引数で呼ぶか」を決める各モデルの機能で、関数の実装と接続は開発者がモデルごとに用意する必要があります。MCPはその関数群を、どのアプリからも同じ方法で発見・実行できる形で配布するための規格です。MCP対応ホストは受け取ったツール定義を内部でFunction Callingに渡しており、両者は組み合わせて動きます。
MCPは今、誰が管理していますか?
2025年12月以降、Linux Foundation傘下のAgentic AI Foundation(AAIF)が管理しています。Anthropic・Block・OpenAIが共同設立した中立組織で、仕様の改訂は公開のSEPプロセスとワーキンググループを通じて行われます。
Claude.aiとClaude CodeでMCPサーバーの設定は共通ですか?
共通ではありません。claude.aiで追加したコネクタはログイン中のClaude Codeセッションに自動で見えますが、Claude Codeのlocalスコープで追加したサーバーはそのプロジェクト・その端末に閉じます。両方で同じサーバーを使いたい場合は、projectスコープの.mcp.jsonをリポジトリにコミットするか、claude.ai側でコネクタとして追加します。
リモートMCPサーバーとローカルMCPサーバーはどちらを使うべきですか?
接続先次第です。GitHubやSentryのようなSaaSはリモート(Streamable HTTP)一択で、インストール不要ですぐ使えます。手元のファイルや社内限定のデータベースに触れる用途はローカル(stdio)が向いており、ネットワークを介さないぶん構成も単純です。
MCPサーバーが増えるとコンテキストを圧迫しませんか?
素朴に全ツールを読み込むと圧迫します。Claude Codeは既定でツール検索の仕組みが有効になっており、セッション開始時にはサーバー名と簡単な説明だけを読み込み、実際に必要になったツールだけを都度探して呼び出します。サーバーの数を増やしてもコンテキストへの影響は最小限に抑えられます。
2026-07-28の仕様変更で、既存のMCPサーバーは動かなくなりますか?
なりません。プロトコルバージョンはリクエストごとにネゴシエーションされ、旧来のハンドシェイク方式のクライアント・サーバーとも下位互換で通信できます。Roots・Sampling・Loggingの非推奨化も猶予期間つきで、すぐに機能が使えなくなるわけではありません。
まとめ
MCPとは、AIと外部システムの接続をM×Nの個別統合からM+Nの標準接続に変えるオープンプロトコルです。2024年11月の公開から、OpenAI・Googleを含む業界横断の採用、Linux Foundation傘下への移管、そして2026年7月のステートレス化改訂と進み、AIエージェントにツールをつなぐ事実上の標準という立場を固めつつあります。
Claude.ai・Claude Code・Claude APIのどこから触るかは、目的次第です。日常のSaaS連携ならclaude.aiのコネクタ、開発フローに組み込むならclaude mcp add、自社アプリにサーバー側で埋め込むならMessages APIのmcp_serversが、それぞれ最短の入り口になります。そこから先は、接続の設計判断を深めるか(Claude Code MCPサーバー完全ガイド)、サーバーの自作に進むか(MCPサーバを自作してClaude Codeにつなぐ)、目的に合わせて選んでください。