GitHub MCP を入れて Claude Code に PR をレビューさせるところまでは試した。けれど「次に何を入れれば開発が楽になるのか」が分からないまま止まっている——そんな声をよく聞きます。あるいは DB やファイルシステムのサーバーを追加したものの、/mcp で failed と表示され、どこをどう直せばいいか手が動かなくなっているケースもあります。
MCP（Model Context Protocol）の入門記事は「とは何か」「おすすめサーバー◯選」で溢れていますが、実際に詰まるのはその先です。2026年6月時点で公式レジストリのサーバーは約9,600件、複数のレジストリを横断すると累計5万件を超えるところまで増えました。この数千〜数万のサーバーの中から自チームに必要なものをどう選ぶか、複数のサーバーをどう束ねれば実務の開発フローが回るか、そして動かなくなったときにどう切り分けるか。さらに「そもそも MCP を使うべきなのか、API を直接叩いたほうが速いのか」という判断も、なかなか言語化されていません。
本記事は、最初の1サーバーを追加し終えた人が「使いこなす」段階へ進むための実践ガイドです。よく使われるサーバーのランキングと選び方、複数サーバーを組み合わせた実装レシピ、接続できないときのデバッグ手順、そして MCP と API 直接呼び出しの使い分けまでを、2026年6月時点の Claude Code の仕様にもとづいて整理します。設定手順そのものを忘れてしまった方のために、最新のコマンド体系も途中で振り返ります。
まず押さえる：2026年6月のMCPエコシステムと最新の設定仕様
選定や組み合わせの話に入る前に、土台となる「いまの MCP がどうなっているか」を短く確認します。すでに把握している方は読み飛ばしてかまいません。
サーバー数は数万規模に達した——だから「選ぶ力」が要る
MCP は Anthropic が2024年11月にオープンソース公開した、AI と外部ツール・データソースをつなぐ標準プロトコルです。2026年に入ってエコシステムは爆発的に拡大しました。公式の MCP Registry に登録された最新サーバーは2026年5月時点で約9,652件（バージョン違いを含むと約2.9万件）、PulseMCP・Smithery・mcp.so など複数のレジストリを横断して集計すると、2026年6月時点で累計5万9千件を超えるとされています（MCP Adoption Statistics 2026 — Digital Applied、PulseMCP: MCP Server Directory）。
レジストリごとに件数が大きく違うのは、収録基準が異なるためです。インストール可能なら何でも載せるレジストリもあれば、品質フィルタをかけるレジストリもあります。一方で、Anthropic 自身がリファレンスとして積極的にメンテナンスしているサーバーは Filesystem・Git・Fetch・Memory など7本程度に絞られています（WorkOS: Everything your team needs to know about MCP in 2026）。つまり「公式が出しているから安全」と言える範囲は意外と狭く、残りの大多数はサードパーティ製です。この状況こそが、本記事の出発点である「数千〜数万の中から何を選ぶか」という課題を生んでいます。
スコープとトランスポートの現在地（2026年仕様）
サーバーを追加するとき、設定の保存場所（スコープ）を選びます。Claude Code の旧バージョンとは呼称が変わっている点に注意してください。
スコープ | 保存場所 | 共有範囲 | 旧称 | 用途 |
|---|---|---|---|---|
local（デフォルト） |
| 自分のみ・現在のプロジェクト | project | 個人的な試験・認証情報を含む設定 |
project |
| チーム全員（git 管理） | — | チームで共有するサーバー設定 |
user |
| 自分のみ・全プロジェクト | global | 個人的にどこでも使うユーティリティ |
同じ名前のサーバーが複数スコープにある場合、local → project → user → プラグイン → claude.ai コネクタ の順で優先され、最も優先度の高い定義が「丸ごと」採用されます（フィールド単位のマージは行われません）。
トランスポート（通信方式）は現在、用途別に4種類あります。
- HTTP（Streamable HTTP）: リモートサーバー接続の推奨。クラウドサービスで最も広くサポートされています。
.mcp.jsonではtypeにstreamable-httpと書いてもhttpのエイリアスとして通ります - stdio: ローカルプロセスとして実行します。DB 接続やカスタムスクリプトなど、マシンへの直接アクセスが必要なツール向けです
- SSE: 非推奨です。HTTP が使えるなら HTTP を選びます
- WebSocket: サーバーからイベントをプッシュさせたい双方向用途向けです。
claude mcp add-jsonでtype: "ws"として設定します（--transportフラグはwsを受け付けません）
設定手順の振り返りとして、追加・確認・削除の基本コマンドを挙げておきます。
# リモート HTTP サーバーを追加（オプションはサーバー名の前、-- でコマンドを分離）
claude mcp add --transport http <name> <url>
# ローカル stdio サーバーを追加
claude mcp add --transport stdio <name> -- <command> [args...]
# 設定済みサーバーの一覧 / 詳細 / 削除
claude mcp list
claude mcp get <name>
claude mcp remove <name>
Claude Code のセッション内では /mcp でステータス確認と OAuth 認証ができます。スコープを明示するときは --scope project のようにサーバー名の前へ置きます（MCP を使用して Claude Code をツールに接続する｜Claude Code Docs）。
Tool Searchが「たくさん入れても重くならない」を実現した
2026年の重要な変化が、デフォルトで有効になった Tool Search（ツール検索）です。従来は接続中の全サーバーのツール定義をセッション開始時にコンテキストへ読み込んでいたため、サーバーを増やすほどコンテキストを圧迫しました。実際、多数の MCP ツールを入れると起動時に2万〜6万トークン以上を消費し、肝心のコーディング用スペースを削っていたという指摘もあります（Anthropic brings MCP tool search to Claude Code — tessl）。
Tool Search は、ツール名とサーバー説明だけを先に読み込み、タスクに応じて必要なツールをオンデマンドで検索・ロードします。これによりコンテキスト消費は大幅に削減され、Anthropic はトークンオーバーヘッドを最大85〜95%減らせるとしています（Scale to many tools with tool search — Claude Code Docs）。
実務上の意味は大きく、「使うか分からないが入れておきたい」サーバーを気兼ねなく追加できるようになりました。挙動は ENABLE_TOOL_SEARCH 環境変数で制御できます。
値 | 動作 |
|---|---|
（未設定） | 全 MCP ツールを遅延し、オンデマンドでロード（デフォルト） |
| コンテキストの10%以内に収まるなら事前ロード、超過分のみ遅延 |
| しきい値を |
| 全ツールを事前ロード（遅延なし） |
ツール数が10本未満で定義がコンテキストに余裕で収まる小規模構成では、false にして検索の往復をなくしたほうが速いこともあります。逆にサーバーをどんどん足していく運用ではデフォルトのままが安全です。常に即座に使いたい少数のサーバーは、.mcp.json で "alwaysLoad": true を指定すると検索ステップを挟まず最初からロードされます。なお Tool Search は tool_reference ブロックに対応したモデル（Sonnet 4 以降 / Opus 4 以降）が必要で、Haiku では使えません。
よく使われるMCPサーバーのランキングと選定の判断軸
ここからが本題です。数千〜数万のサーバーから「自チームに何を足すか」を、利用実態のランキングと判断軸の両面から整理します。
利用実態ランキング：実際に多く使われている定番
2026年の各種ランキングや利用実態の集計を突き合わせると、Claude Code 周辺で繰り返し名前が挙がるサーバーはおおむね固定化してきました。とくに GitHub・Context7・Playwright・Filesystem・Brave Search の5本は、Claude Code だけでなく Cursor・Windsurf を含む主要クライアントすべてで動く「最も汎用的に支持されている」顔ぶれです（Best MCP Servers in 2026 — Vibehackers、15 Best MCP Servers 2026 — TECHSY）。
人気の絶対量で言えば、ドキュメント参照の Context7 が突出しています。Upstash が公開した Context7 は GitHub スター5.4万超、npm の週間ダウンロード89万回（2026年5月時点）とエコシステム全体で最多級で、次いで Microsoft の Playwright MCP が続きます。そして Context7・GitHub・Playwright の3つで Claude Code のワークフローの約8割をカバーできるという整理が、複数の実務系記事で共通して語られています（Best Claude Code MCP Servers in 2026 — Nimbalyst、Best MCP Servers 2026 — shareuhack）。
下表は、これらの定番を「役割・トランスポート・どんなチームに効くか」で並べたものです。導入順を考えるときは、まず上の3本（Context7・GitHub・Playwright）から検討するのが定石です。
順位の目安 | サーバー | 役割 | トランスポート | こんなチームに |
|---|---|---|---|---|
1 | Context7 | ライブラリ最新ドキュメント参照 | HTTP | フレームワークの API ハルシネーションを防ぎたい |
2 | Playwright | ブラウザ自動テスト・操作 | stdio | E2E テストや画面確認を AI に任せたい |
3 | GitHub | PR・Issue・コード検索 | HTTP | コードレビュー・Issue 起点の実装を回したい |
4 | Filesystem | プロジェクト外のディレクトリへの読み書き | stdio | 設計資料やログを別ディレクトリで管理している |
5 | Brave Search | Web 検索 | HTTP | 最新の外部情報を会話の中で取りに行きたい |
－ | PostgreSQL / Supabase | DB スキーマ確認・クエリ | stdio | 仕様確認のたびに DB を覗いている |
－ | Sentry | 本番エラー監視・原因分析 | HTTP | 本番障害の一次調査を速くしたい |
－ | Memory | セッションをまたぐ永続コンテキスト | stdio | 長期プロジェクトで文脈を保持したい |
Notion・Stripe・Cloudflare・Slack・Vercel なども公式 MCP サーバーを提供しており、SaaS 連携の選択肢は広がっています。ただし「ランキング上位だから入れる」では裏テーマの解決になりません。次の判断軸で自チームの必要性に落とし込みます。
判断軸：そのサーバーを「いま入れるべきか」を決める4つの問い
- コピペが発生しているか: 別ツールの画面から Claude Code へ情報を貼り付ける作業が日常的に発生しているなら、そのツールはサーバー化の有力候補です。これは MCP の本質的な価値（外部システムを直接読み書きさせる）と直結します
- 公式・準公式か、ソースを確認できるか: メンテナンス主体が明確で GitHub でソースを確認できるサーバーを優先します。とくに Web 検索のように「信頼できない外部コンテンツを取得する」サーバーはプロンプトインジェクションのリスクがあるため、扱いを慎重にします
- 書き込みが伴うか: DB や本番環境に触れるサーバーは、まず読み取り専用で導入します（後述の DB レシピを参照）。いきなり書き込み権限を渡さないことが、事故を防ぐ最初の一線です
- チームで共有すべきか個人用か: 全員が使うなら
projectスコープで.mcp.jsonを git 管理し、自分専用のユーティリティならuserスコープにします。この切り分けが曖昧だと、後で「自分の環境だけ動かない」という混乱を招きます
他クライアント（GitHub Copilot・Cursor）との違いから見えること
MCP は Claude Code 専用の機能ではなく、複数のコーディング支援ツールが共通して採用する標準プロトコルです。2026年初頭には GitHub Copilot も MCP 対応を VS Code 拡張・JetBrains プラグイン経由で出荷し、Cursor と機能パリティに達しました。Cursor はネイティブの設定パネルから MCP を追加でき、専用の Plugin Marketplace で Figma・Stripe・AWS・Linear・Vercel・Cloudflare などの公式連携を揃えています。一方 Copilot は全 IDE 横断で MCP をサポートし、サードパーティ連携向けの MCP OAuth や、Enterprise 向けのプライベート MCP レジストリを提供しています（Cursor vs GitHub Copilot 2026 — TrueFoundry）。
ここから言えることは2つあります。第一に、サーバー選定の知見はクライアントを移っても流用できるということです。GitHub・Context7・Playwright を中心に組む発想は、Cursor でも Copilot でも通用します。第二に、Claude Code 固有の強みは前述の Tool Search にあり、「多数のサーバーを入れてもコンテキストが膨らみにくい」点です。多くのサーバーを束ねて使う運用ほど、この差は効いてきます。チーム展開を見据えるなら、まずは標準プロトコルとしての共通部分（サーバー選定の軸）を固め、その上で各クライアント固有の最適化を乗せる、という順序が無駄になりません。
複数MCPサーバーを束ねた開発フローの実装レシピ
単体のサーバーを使えるだけでは、開発フローは速くなりません。複数を組み合わせて初めて「Issue から PR まで会話で回る」状態になります。ここでは再現可能な実装レシピを3つ示します。いずれも .mcp.json でチーム共有する前提です。
レシピ1：DBアクセス + ファイルシステムで「仕様準拠の実装」を回す
「DB の実スキーマを確認しながらコードを書く」フローです。Filesystem MCP で設計資料を参照しつつ、PostgreSQL MCP（読み取り専用ユーザー）で実スキーマを突き合わせます。
{
"mcpServers": {
"fs-docs": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "${CLAUDE_PROJECT_DIR:-.}/docs"]
},
"db": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@bytebase/dbhub", "--dsn", "${DATABASE_URL}"]
}
}
}
${DATABASE_URL} には必ず readonly ユーザーの DSN を入れます。会話例は次の通りです。
docs/spec/orders.md の仕様と orders テーブルの実スキーマを突き合わせ、
仕様に存在するが DB にないカラムを一覧してください。
ポイントは、ファイル（設計の意図）と DB（実態）という性質の異なる2つのソースを1つの問いで横断させることです。${CLAUDE_PROJECT_DIR:-.} は project / user スコープの .mcp.json でプロジェクトルートを参照するための記法で、デフォルト値 . を付けるのが安全です。
レシピ2：GitHub + Context7で「Issue起点の実装」を回す
「Issue に書かれた要件を、最新ドキュメントに沿って実装し、PR を作る」フローです。GitHub MCP が課題管理と PR を、Context7 MCP がライブラリの最新 API を担当します。
{
"mcpServers": {
"github": {
"type": "http",
"url": "https://api.githubcopilot.com/mcp/",
"headers": { "Authorization": "Bearer ${GITHUB_PAT}" }
},
"context7": {
"type": "http",
"url": "https://mcp.context7.com/mcp"
}
}
}
Issue #4521 の要件を読み、Next.js 15 の App Router の最新仕様にもとづいて実装し、
feature/issue-4521 ブランチで PR を作成してください。
Context7 を挟むことで、廃止済みメソッドや古い API を使ったハルシネーションを抑えられます。${GITHUB_PAT} は .mcp.json に直書きせず、各メンバーがローカルの環境変数として設定します。これが「設定はチーム共有、認証情報は個人管理」を両立させる定石です。
レシピ3：Sentry + GitHubで「本番エラーの一次調査」を回す
「本番で出ているエラーを調べ、修正方針を立て、Issue 化する」フローです。Sentry MCP で原因を特定し、GitHub MCP で起票します。
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp
# 追加後、Claude Code 内で /mcp を実行し OAuth 認証
過去24時間で最も多いエラーのトップ3を特定し、それぞれの原因仮説と
修正方針をまとめて、優先度の高いものを GitHub Issue として起票してください。
3つのレシピに共通する設計思想は、「データを取りに行くサーバー（Filesystem / DB / Sentry / Context7）」と「成果物を作るサーバー（GitHub）」を組み合わせることです。前者で文脈を集め、後者で PR や Issue という形にする。この役割分担を意識すると、自チームのフローに合わせた独自の組み合わせも設計しやすくなります。たとえば「Brave Search で外部仕様を調べ、Filesystem で社内ドキュメントと突き合わせ、GitHub で Issue 化する」といった応用も、同じ型の延長線上で組めます。
MCPサーバーが接続できないときのデバッグ手順
「設定したのに /mcp で failed になる」は、導入後にもっとも手が止まりやすいポイントです。やみくもに設定を変えるのではなく、切り分けの順番を決めておくと自力で復旧できます。
ステップ1：まず/mcpで状態を読む
Claude Code 内で /mcp を実行し、対象サーバーの表示を確認します。
Pending approval（保留）: project スコープの.mcp.jsonサーバーは、セキュリティ上、初回利用時に承認が必要です。claudeを対話起動して承認します- OAuth が必要:
/mcpから認証フローを開始します。リモートサーバーが401/403を返すと認証要求としてフラグが立ちます failed（失敗）: HTTP / SSE サーバーは切断時に指数バックオフで自動再接続（1秒から開始し最大5回）します。5回失敗するとこの表示になり、/mcpから手動で再試行できます。起動時の初期接続も、5xx・接続拒否・タイムアウトなど一時エラーなら最大3回再試行されます（認証エラーと404は再試行されません）。stdio サーバーはローカルプロセスのため自動再接続しません
ステップ2：よくある原因を上から潰す
実際の接続失敗は、次の少数のパターンに集約されます（stuartmason: Claude Code MCP Server "Failed to Connect"、Claude Code Docs）。
- 設定変更が反映されていない:
~/.claude.jsonを変更しても、起動中の Claude Code には反映されません。いったん完全に終了して再起動します。これが最頻の見落としです - 環境変数の未設定:
.mcp.jsonで${DATABASE_URL}などを参照しているのに、その変数が未設定だと設定の解析自体が失敗します。${VAR:-default}形式でデフォルトを与えるか、変数を確実に export します - stdio サーバーが stdout にログを書いている: stdio はプロトコル通信に stdout を使うため、サーバーがデバッグログを stdout へ出すと通信が壊れて接続が落ちます。ログは stderr へ出すのが鉄則です。自作サーバーで
failedになる場合、まずここを疑います - 起動コマンドが間違っている / Windows の npx: ネイティブ Windows では npm インストールのコマンドが
.cmdシムのため、npxの前にcmd /cが必要です - 認証ヘッダーとサーバーの不一致:
headers.Authorizationを自分で設定していてサーバーがそれを拒否すると、Claude Code は OAuth へフォールバックせず「接続失敗」と報告します。ヘッダーを外して OAuth フローを使うか、トークンの有効性を確認します
ステップ3：最小構成で再現させる
それでも切り分けられないときは、問題のサーバー1本だけを残し、サーバーの起動コマンドを Claude Code と同じシェル・同じ環境変数で手動実行してみます。手動で起動するなら問題は環境変数や起動コマンドにあり、手動でも失敗するならサーバー自体の問題です。タイムアウトが疑わしい場合は MCP_TIMEOUT（起動タイムアウト、例: MCP_TIMEOUT=10000 claude）を、出力が大きすぎて警告が出る場合は MAX_MCP_OUTPUT_TOKENS（デフォルト25,000トークン）を調整します。
MCPとAPI直接呼び出しの使い分け
最後に、導入後の実務者がつまずきやすい判断軸を整理します。「何でも MCP にすればいい」わけではありません。MCP と API 直接呼び出し（あるいは CLI でコマンドを叩く方法）には、はっきりした得意・不得意があります。
コストとレイテンシの違いを理解する
ある外部サービスの値を取得する場合、API 直接呼び出しなら100ミリ秒程度で済むところ、MCP 経由ではモデルがツール説明を読み（数百〜1,000トークン）、呼び出しを判断し、パラメータを組み立て、応答を解釈する、という工程が挟まり、合計で2〜3秒・数千トークンを消費するという試算があります（Toolradar: MCP vs API、modelslab: MCP vs CLI for AI Agents）。つまり MCP は「賢く判断させる」対価としてトークンとレイテンシを払う仕組みです。なお Tool Search を使えば「多数のサーバーを入れる際の起動時コスト」は抑えられますが、これは選定済みのツールを呼ぶときの1回あたりのコストとは別の話です。1回の呼び出しに伴うトークン消費とレイテンシは、Tool Search を使っても基本的に残ります。
判断のための対比表
観点 | MCP が向く | API 直接呼び出し / スクリプトが向く |
|---|---|---|
処理の性質 | 探索的・対話的で、どのツールを使うかをモデルに判断させたい | 手順が固定で、決まった入出力を確実に処理したい |
データ量 | 数件〜中程度の件数 | 大量データのバッチ処理 |
実行主体 | 開発中に人がそばで対話する | スケジュール実行・イベント駆動の自動パイプライン |
重視するもの | 開発速度・柔軟性 | 決定性・低レイテンシ・再現性・コスト |
判断の目安はシンプルです。「Claude Code と対話しながら、状況に応じて柔軟にツールを選ばせたい」なら MCP、「決まった処理を毎晩確実に回したい」なら API を直接叩くスクリプト、と考えます。実際の現場では両者を排他的に選ぶより、対話的な開発には MCP、確定したバッチ処理には直接 API と役割分担する構成が一般的です（atlan: When to Use MCP vs API）。
たとえば「Issue 起点の実装」は探索的なので MCP が適しますが、「毎晩 DB から集計レポートを生成してメール送信する」のような定型処理は、MCP を経由させずスクリプトで直接実装したほうが速く・安く・壊れにくくなります。
まとめ：導入の先にある「使いこなす」段階へ
最初の1サーバーを追加し終えた後の壁は、設定の難しさではなく「選定・組み合わせ・自力デバッグ・使い分け判断」にありました。本記事の要点を振り返ります。
- 選定: 数千〜数万のサーバーから選ぶ軸は「コピペが発生しているか」「ソースを確認できるか」「書き込みを伴うか」「チーム共有か個人か」の4つ。利用実態では Context7・GitHub・Playwright・Filesystem・Brave Search が定番で、なかでも Context7・GitHub・Playwright の3本で多くの開発フローはカバーできる
- 組み合わせ: 「データを取りに行くサーバー」と「成果物を作るサーバー（GitHub）」を束ねると、Issue から PR までが会話で回る。設定は
projectスコープで共有し、認証情報は各自の環境変数で管理する - デバッグ:
/mcpで状態を読み、「再起動忘れ・環境変数未設定・stdout へのログ出力・起動コマンド誤り・認証ヘッダー不一致」を上から潰し、最小構成で再現させる - 使い分け: 対話的な開発は MCP、確定したバッチ処理は API 直接呼び出し。MCP は柔軟性の対価にトークンとレイテンシを払う仕組みと理解する
MCP は Claude Code に閉じた機能ではなく、GitHub Copilot や Cursor も採用する標準プロトコルです。サーバー選定の軸を一度固めれば、クライアントを移っても知見は流用できます。導入後に立ち止まっていた方も、この4つの軸を持てば、自チームの開発フローに合った MCP 構成を自分で設計し、トラブルにも自力で対処できるはずです。
