Claude Code MCPおすすめ10選 2026——フリーランスエンジニアが本当に使っているサーバーと設定
Claude CodeのMCPを何を入れるべきか迷っている人向け。実際に使い続けている10本を選定基準・設定コード付きで解説。Serena MCPやFigma+Playwright連携など競合記事が書かないギャップも網羅。
エンジニアのゆとです。
MCPを入れるだけでClaude Codeの能力が激変する。
ただし「とりあえず全部入れる」はコンテキストを食い潰すだけだ。MCPを10本alwaysLoadにしたら、それだけでセッション開始時に使えるコンテキストウィンドウが数千トークン削られる。結果として長めのタスクで途中の記憶が抜けやすくなる、という本末転倒が起きる。
この記事では、自分がフリーランスの業務で実際に使い続けているMCPを10本に絞り、「設定コード」「なぜこれを選んだか」「向いている人/向いていない人」の判断基準まで書いた。
「MCPとは何か」から知りたい場合は先にこっちを読んでほしい。
MCPを入れる前に知っておくべきこと
alwaysLoad と prefer の違い
MCPサーバーには読み込みタイミングの設定がある。
alwaysAllow（常時ロード）はセッション開始時から全MCPが読み込まれる。即使えるが、全MCPのツール定義がシステムプロンプトに追加されてコンテキストを消費する。
prefer（必要時ロード）は現状のClaude Code仕様では基本的にalwaysLoadと同等だが、将来的に「必要になった時点で動的ロード」に変わる可能性が示唆されている。現在の使い分けは「必ず毎回使うか」という観点でalwaysLoadに含めるものを選ぶ、という判断が現実的だ。
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_TOKEN": "${GITHUB_TOKEN}"
}
},
"context7": {
"command": "npx",
"args": ["-y", "@upstash/context7-mcp"]
}
}
}alwaysLoad: true キーを追加すると、Claude Code起動時から必ず読み込まれる。
コンテキスト消費の実態
自分が試した感触で言うと、MCPを5本alwaysLoadした状態のセッション開始時のシステムプロンプトは、0本の場合と比べて体感で1,000〜3,000トークン程度膨らんでいる。
Claudeの200Kトークンウィンドウからすると微小な差だが、長時間セッションでコンテキストが詰まってきたとき、この差が「もう少し続けられたかもしれない」になることがある。
実用的な判断基準は「週に5回以上使うかどうか」だ。それより少ない頻度のMCPは、必要なときだけ claude mcp add でその場で追加して使い終わったら外す運用でも十分間に合う。
/plugin install と claude mcp add の使い分け
混乱しやすいポイントなので整理しておく。
claude mcp add は「MCPサーバー単体」を追加するコマンドだ。設定は ~/.claude/settings.json または .claude/settings.json に書かれる。
/plugin install は「プラグイン（スキル+MCP+フック等をひとまとめにしたパッケージ）」をインストールするコマンドだ。プラグインの中にMCPが含まれている場合、インストール時に自動でMCPも追加される。
Figma MCPは現在、公式プラグイン経由でのインストールが推奨されている（後述）。こういった「プラグインの一部としてMCPがバンドルされているケース」では /plugin install を使う。それ以外のコミュニティMCPやセルフホスティングするサーバーは claude mcp add が基本だ。
プラグインの詳細はこちら：
開発必須MCP 5選——全員入れるべき
業種やプロジェクトを問わず、エンジニアなら入れて損がないMCPを5本選んだ。
① GitHub MCP——コードレビュー・PR作成・Issue管理を直接操作
claude mcp add github npx -y @modelcontextprotocol/server-github環境変数に GITHUB_TOKEN が必要。
export GITHUB_TOKEN=ghp_xxxxxxxxxxxxまたは ~/.claude/settings.json に環境変数として埋め込む場合：
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_TOKEN": "ghp_xxxxxxxxxxxx"
}
}
}
}GitHub MCPが入ると何が変わるかを具体的に言うと、「ブラウザでGitHubを開かなくてもよくなる」という一言に尽きる。
実際に自分がよくやっている使い方：
- 「このリポジトリのopenなIssueを全部読んで、実装難度と影響範囲で優先度マトリクスを作って」
- 「先週のPR差分を読んで、コードレビューのコメント案を作って。特にパフォーマンスとセキュリティ観点で」
- 「mainブランチの最新コミット10本のdiffを読んで、今月のChangelog下書きを作って」
フリーランスで複数クライアントのリポジトリを掛け持ちしている場合、このMCPがあるとGitHubのブラウザ操作がかなり減る。IssueのURLをターミナルにペーストするだけで、Claude Codeが内容を読んで実装方針まで提案してくれるようになる。
向いていない人：GitHubを使っていない（GitLabやBitbucket環境）。GitLabはサードパーティ製の代替MCPがある。
② Context7 MCP——ライブラリのドキュメントをリアルタイム参照
claude mcp add context7 npx -y @upstash/context7-mcp追加設定不要。インストールだけで動く。
Context7を入れる理由はシンプルで「ハルシネーションを減らすため」だ。
Claude Codeの学習データには2025年頃までの情報しかない。Next.js 15やReact 19、最新のTanStack Query等、学習データ以降にリリースされたバージョンのAPIを使おうとすると、存在しないメソッドを自信満々で書いてくることがある。
Context7はプロンプト内で /use context7 と書くと、使用するライブラリの最新ドキュメントを自動取得して参照しながら実装する仕組みだ。
Next.js 15 の App Router で動的ルーティングを実装して /use context7こう書くだけで、Context7がNext.js公式ドキュメントを取得して、最新のAPIに合った実装を返してくれる。
ライブラリのバージョンアップが多い案件や、最新フレームワークを使っているプロジェクトでは特に効果が出やすい。
向いていない人：社内フレームワークやドキュメントが非公開な環境では恩恵が薄い（Context7はパブリックなドキュメントを参照する）。
③ Playwright MCP——ブラウザを直接操作してE2Eテストも書ける
claude mcp add playwright npx -y @playwright/mcp@latestPlaywright MCPはClaude Codeにブラウザ操作能力を与える。PuppeteerベースのMCPと比較して、Playwright MCPの方がCDPプロトコルを通じた操作が安定しており、自分はこちらを本番で使っている。
実際の使い方でよくやるのは「UIを見ながらテストを書かせる」パターンだ。
localhost:3000 を開いて、ログインフォームに [email protected] / password123 を入れてログインして。
ログイン後のダッシュボードが表示されたら、その操作手順全体をPlaywright E2Eテストとして書いて。こう指示すると、Playwright MCPが実際にブラウザを動かしながら要素セレクターを確認して、正確なE2Eテストコードを吐き出す。手書きのE2Eテストと比べて、セレクターの誤りがほぼなくなるのが体感的に大きい。
Figma MCPとの連携については後の章で詳しく書く。「デザイン → コード → テスト」の一気通貫ワークフローはこのMCPが中心になる。
向いていない人：E2Eテストを書かない、UIがないバックエンド専業の人にはメリットが薄い。
④ Serena MCP——LSPでコードベースをシンボルレベルで解析（差別化の核心）
競合記事でほぼ触れられていないが、自分が最近で一番インパクトを感じているのがこれだ。
claude mcp add serena uvx --from git+https://github.com/oraios/serena serena-mcp-server --project-dir /path/to/your/project前提として uv（Python製のパッケージマネージャ）が必要。
# uvのインストール
curl -LsSf https://astral.sh/uv/install.sh | shSerena MCPはLSP（Language Server Protocol）をClaude Codeから使えるようにするサーバーだ。
LSPは元々「IDEがコード補完や定義ジャンプをするときに内部で使っているプロトコル」だ。VS Codeでファイルを開いたときに関数定義にジャンプできるのも、「参照先を全部表示」できるのも、LSPがプロジェクト全体を解析しているから可能になっている。
Serena MCPはこのLSP解析をClaude Codeから直接呼べるようにする。対応言語はTypeScript/JavaScript/Python/Go/Rust/Java/C++/Ruby など30言語以上。
何が変わるかを具体例で説明する。
「この handlePayment 関数を呼んでいる箇所を全部見つけて」
MCPなしの場合、Claude Codeはgrepかfindを使って文字列検索する。これは関数名が変数に代入されていたり、引数として渡されていたりする「動的な呼び出し」を見落とす可能性がある。
Serena MCPがある場合、LSP経由で「シンボルの参照先」を検索する。これはIDEの「Find All References」と同じ精度だ。型情報も含めて解析するので、動的呼び出しや継承経由の参照も正確に取れる。
大規模なリファクタリング（関数名変更・インターフェースの変更・依存関係の整理）をClaude Codeにやらせるときの精度が、Serena MCPあり/なしで明らかに違う。
設定例（プロジェクトディレクトリを指定する）：
{
"mcpServers": {
"serena": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/oraios/serena",
"serena-mcp-server",
"--project-dir",
"/Users/yourname/projects/my-app"
]
}
}
}--project-dir には解析対象のプロジェクトのルートを指定する。複数プロジェクトを横断する場合は、MCPサーバーを複数登録する（serena-frontend/serena-backend のように名前を変えて）。
注意点が2つある。
1つ目、初回起動時にLSPのセットアップで少し時間がかかる。TypeScriptプロジェクトの場合、初回は30秒〜1分程度待つことがある。
2つ目、--project-dir が正確に指定されていないと動かない。.git があるディレクトリか、package.json/pyproject.toml があるルートを指定する。
向いていない人：小規模な1ファイルスクリプト中心の作業、またはLSPが対応していない独自言語。
⑤ Sequential Thinking MCP——複雑な問題の思考チェーンを構造化
claude mcp add sequential-thinking npx -y @modelcontextprotocol/server-sequential-thinkingSequential Thinking MCPはClaude Codeが「段階的に思考する」プロセスを構造化してくれるMCPだ。
複雑なアーキテクチャ設計、バグの根本原因分析、複数の技術的選択肢の比較といった「一手では答えが出ない問い」に対して、思考ステップを明示しながら進むことができる。
自分がよく使うパターンは「設計レビュー」だ。
この新機能の設計を再考してほしい。
現状の課題: ユーザーテーブルとオーダーテーブルの結合が複数箇所で重複している
要件: N+1クエリを解消しながら、既存APIのインターフェースは変えない
思考チェーンで整理してこう頼むと、Sequential Thinking MCPが「課題の整理 → 選択肢の列挙 → 各選択肢のトレードオフ → 推奨案の提示」という順で明示的に思考プロセスを出力する。ありがちな「なんとなく良さそうな案」ではなく、「なぜその設計を選ぶか」が追えるようになる。
向いていない人：単純なコード補完・ファイル操作には過剰。「これどうコード書けばいい？」レベルには不要。設計検討や複雑なデバッグに限定して使うのがよい。
用途別おすすめMCP 5選——使う人を選ぶが強力
全員に勧めるわけではないが、該当する人には効果が大きいMCPを5本選んだ。
⑥ Figma MCP——デザインをコードに直接変換
Figma MCPは公式プラグイン経由のインストールが現時点での推奨だ。
/plugin install figmaClaude Codeのセッション内で上記コマンドを実行すると、Figma公式プラグインがインストールされる。インストール後はFigma Dev Modeとの接続設定が必要になる。
接続の流れ：
- FigmaでDev Modeを有効化（有料プラン必要、Figma Professional以上）
- Figmaの「プラグイン」メニューから「Claude Code」プラグインを起動
- ローカルポートが開くので、Claude Codeがそこに接続する
接続が完了すると、FigmaのデザインファイルをClaude Codeから直接参照できるようになる。
実際の使い方：
このFigmaフレーム（URL: https://www.figma.com/file/xxx）のコンポーネントを
React + Tailwind CSSで実装して。
モバイル（375px）とデスクトップ（1280px）の両対応で。Figmaのフレームを指定するだけで、コンポーネントの構造・色・スペーシング・タイポグラフィをそのままコードに落としてくれる。自分でデザインを読み取ってpxに変換する作業がなくなる。
Playwright MCPとの連携ワークフロー：
Figma MCP + Playwright MCPを組み合わせると「デザイン → 実装 → テスト」を連続して実行できる。
【ステップ1】このFigmaフレームのUIを実装して（Figma MCPが参照）
【ステップ2】実装が終わったら localhost:3000 でブラウザを開いてデザインと見比べて（Playwright MCPが操作）
【ステップ3】ずれている部分を指摘して修正後、E2Eテストを書いて1つのプロンプトで3ステップ全部やらせることもできるし、段階的に確認しながらやることもできる。デザイン実装の工数が体感で40〜50%削減できている（自分の感触だが）。
向いていない人：Figmaを使っていないチーム、デザイナーがいなくて実装者がデザインも全部決める場合はメリットが薄い。FigmaのDev Modeは有料プランが必要なので、個人開発の無料プランユーザーは使えない。
⑦ Obsidian MCP——ナレッジベースをClaude Codeのコンテキストに
claude mcp add obsidian npx -y mcp-obsidian /path/to/your/vaultObsidianのvaultのパスを指定する。
これを入れると、Obsidianで管理しているノート群をClaude Codeから参照できるようになる。
自分の使い方は「プロジェクトのコンテキストをObsidianに貯めておいて、Claude Codeに参照させながら作業する」だ。
Obsidianの「クライアントA」フォルダを読んで、今月の開発仕様書に沿った実装をして。
特に「API設計.md」と「データモデル.md」を重視して。クライアントごとの仕様・制約・背景情報をObsidianに整理しておけば、毎回ロングプロンプトでコンテキストを渡す必要がなくなる。
Obsidianで書いたドキュメントをClaude Codeに読ませながら、README・API仕様書・CHANGELOG等を自動生成するのも定番の使い方だ。
Obsidianを使ったナレッジベース活用の詳細はこちらで書いている：
向いていない人：Obsidianを使っていない。NotionやConfluence派はそれぞれ専用MCPがある（後述）。
⑧ Notion MCP——タスク・ドキュメント管理の自動化
claude mcp add notion npx -y @notionhq/notion-mcp-server環境変数に NOTION_API_KEY が必要。Notionのインテグレーション設定画面でAPIキーを発行する。
export NOTION_API_KEY=secret_xxxxxxxxxxxx自分がやっているのは「会議メモ → タスク自動生成」だ。
「2026-06-17 キックオフMTG」ページを読んで、
決定事項と担当者ベースのタスクをNotionのプロジェクトデータベースに追加して。
ステータスは「未着手」、締切は言及があったものだけ入れて。議事録を書いた後、Claude Codeにこれを頼むと、ページを読んでタスク分解してデータベースに追加まで完結する。手動でチェックしてタスクに落とし込む作業が消える。
他には「このPRの差分を要約してNotionのSprintレポートページに追記して」「先週のタスク一覧を読んで、完了率と残タスクの集計を作って」といった使い方もある。
向いていない人：プロジェクト管理にNotionを使っていない人、Jira/Linear/Asana環境はそれぞれ別のMCPが必要。
⑨ Slack MCP——過去の会話を参照してコンテキスト補完
claude mcp add slack npx -y @modelcontextprotocol/server-slack環境変数に SLACK_BOT_TOKEN と SLACK_TEAM_ID が必要。Slack APIのApp設定で取得する。
Slackに過去の意思決定や仕様議論が流れていくのはどのチームでも起きる。「あの件どうなったっけ」をSlack上で検索するのは時間がかかる上、見つからないことも多い。
Slack MCPがあると、Claude Codeにこういう指示ができる：
#dev-general チャンネルの今週の会話を読んで、
「認証システムのリファクタリング」に関する決定事項と
担当者への割り振りを整理してまたは：
@田中さんとの先月のDMを読んで、
APIの仕様変更についての合意事項をまとめて「実装する前に過去の議論で何か決まってなかったか確認する」という作業が自動化できる。
注意点：Slack MCPが読めるのはBotに権限を付与したチャンネルのみ。プライベートチャンネルはBot招待が必要。
向いていない人：チームでSlackを使っていない、または社内情報のセキュリティポリシー上、外部サービスのAPIに情報を流せない環境。
⑩ AWS MCP——AWSリソース管理とデプロイの自動化
AWSは公式から54本ものMCPサーバーを提供している。全部入れる必要はない。自分が使っているのは以下の3本だ。
# コアツール（AWS CLI操作の基盤）
claude mcp add aws-core uvx awslabs.core-mcp-server@latest
# Lambda関連
claude mcp add aws-lambda uvx awslabs.lambda-mcp-server@latest
# CloudFormation / CDK
claude mcp add aws-cfn uvx awslabs.cfn-mcp-server@latest前提として uv と AWS CLI の設定（~/.aws/credentials）が必要。
AWS MCPを入れると、AWSコンソールを開かなくてもClaude Codeからリソースの確認・操作ができる。
実際によくやること：
us-east-1のLambda関数一覧を取得して、
最終更新が90日以上前のものを洗い出してこのCDKスタックのdiffを確認して、
変更点とその影響を説明してからdeployを実行して後者のように「説明してから実行」という形にしておくと、意図しないデプロイを防げる。
向いていない人：AWSを使っていないインフラ環境（GCP・Azureはそれぞれ別のMCPがある）、AWSは使っているが操作が少なく毎回コンソールで十分という人。
settings.json 完全設定例——コピペで動く構成
上で紹介したMCPを実際にどう設定しているかを公開する。これは自分の ~/.claude/settings.json（グローバル設定）の抜粋だ。
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_TOKEN": "${GITHUB_TOKEN}"
},
"alwaysLoad": true
},
"context7": {
"command": "npx",
"args": ["-y", "@upstash/context7-mcp"],
"alwaysLoad": true
},
"playwright": {
"command": "npx",
"args": ["-y", "@playwright/mcp@latest"],
"alwaysLoad": false
},
"sequential-thinking": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-sequential-thinking"],
"alwaysLoad": false
},
"slack": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-slack"],
"env": {
"SLACK_BOT_TOKEN": "${SLACK_BOT_TOKEN}",
"SLACK_TEAM_ID": "${SLACK_TEAM_ID}"
},
"alwaysLoad": false
}
}
}alwaysLoad: true にしているのはGitHubとContext7だけだ。この2本は毎日ほぼ全セッションで使う。
PlaywrightはE2Eテストを書くときだけ、Sequential Thinkingは設計や複雑なデバッグのときだけ使うのでfalseにしている。必要なタイミングで claude mcp add する手間より、コンテキストを節約する方が自分には合っている。
Serena MCPはプロジェクトディレクトリを指定する必要があるため、グローバル設定には入れず、プロジェクト単位の .claude/settings.json に書いている：
{
"mcpServers": {
"serena": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/oraios/serena",
"serena-mcp-server",
"--project-dir",
"/Users/yourname/projects/current-project"
],
"alwaysLoad": true
}
}
}環境変数は ${VAR_NAME} の形式でsettings.jsonに書くと、実行時にシェルの環境変数から読み込まれる。APIキーをJSONに直書きするのは避けて、.env や ~/.zshrc に設定しておく方がセキュリティ上よい。
settings.jsonの詳細はこちら：
MCPのセキュリティ注意点
MCPを入れる前に知っておくべきセキュリティの話をする。
どのMCPに何の権限があるか把握する
MCPサーバーはClaude Codeから呼び出されるが、実際には「ローカルで動くプロセス」か「リモートのAPIを叩くサービス」かで性質が変わる。
GitHub MCPはGitHub APIを叩く。Slack MCPはSlack APIを叩く。どちらも「発行したトークンの権限範囲内」で動く。だからトークン発行時の権限設定が重要だ。
GitHubトークンはread-onlyスコープで始めて、PRのコメント書き込みが必要になったら pull_requests:write を追加、という段階的な権限拡大が安全だ。
# 現在のMCPと使用しているツールを確認
claude mcp listclaude mcp list で登録済みのMCPを確認できる。定期的に見直して「使ってないMCP」は削除しておく。
信頼できないMCPを入れるリスク
MCPはオープンプロトコルなので、誰でもサーバーを公開できる。コミュニティ製MCPを入れる場合は、以下を確認してから使う：
- GitHubのStarが十分ついているか（最低でも数十スター以上）
- 最終更新がアクティブか（6ヶ月以上更新なしは要注意）
- コードが公開されていてレビューできるか（バイナリ配布のみのものは避ける）
- npmパッケージの場合、ダウンロード数と公開者の信頼性を確認
特にセキュリティ上注意が必要なのは「ファイルシステムへの広範なアクセスを求めるMCP」だ。/ や ~ 全体を渡すのは、そのMCPが何をするかを完全に把握していない限り避けるべきだ。
FAQ
Q: MCPを何本入れると重くなる？
alwaysLoadにする本数が問題で、インストール数自体はパフォーマンスに影響しない。自分の経験では5本を超えてalwaysLoadにするとセッション開始時のコンテキスト消費が体感できるようになってきた。日常使いは2〜3本alwaysLoad、残りは必要時追加、というバランスがちょうどよい。
Q: チームで同じMCP設定を共有できる？
できる。プロジェクトの .claude/settings.json にMCPの設定を書いてGitにコミットすれば、チームメンバー全員が git pull するだけで同じ構成になる。
ただしAPIキー等の認証情報は絶対にコミットしない。環境変数参照（${GITHUB_TOKEN}）の形式にして、各自の環境変数またはdotenvで管理する。
Q: MCPのバージョンアップはどうやる？
npx -y を使っている場合、npxが自動的に最新バージョンを取得する。固定バージョンを使いたい場合は @バージョン を指定する。
# 常に最新を使う（npx -y）
claude mcp add playwright npx -y @playwright/mcp@latest
# バージョンを固定する
claude mcp add playwright npx -y @playwright/[email protected]本番環境や複数人での共有環境ではバージョン固定が安全だ。
Q: Windowsでも同じ設定で動く？
基本的には動く。npx が動く環境（Node.jsが入っている）であれば、設定JSONはOS問わず同じ書き方でよい。
ただしパスの指定（/Users/yourname/）はWindowsでは C:\Users\yourname\ になるので、パスを含む設定は書き換えが必要。Serena MCPの --project-dir 等が該当する。WSL2環境ならLinux形式のパスで通るケースが多い。
Q: 無料プランでMCPは使える？
MCPの機能自体はClaude CodeのプランによってON/OFFされるものではない。Claude CodeはどのプランでもMCPを使える。
ただし個別のMCPが要求するAPIの課金は別。Brave Search（月2,000クエリまで無料）、Figma Dev Mode（有料プランが必要）、AWSリソース操作（AWS課金が発生）等はMCP経由で操作しても同じコストがかかる。
まとめ
MCPは「何を入れるか」より「何をalwaysLoadにするか」の方が重要だ。全部入れて全部常時読み込みにすると、コンテキストが削られてClaude Code本来の能力を発揮しにくくなる。
自分のまとめ：
- 毎日使う→ GitHub MCP / Context7 MCP をalwaysLoad
- フロントエンドを書く日→ Playwright MCP を追加
- 大規模リファクタリング→ Serena MCP をプロジェクト設定に追加
- 設計検討・複雑デバッグ→ Sequential Thinking MCP を追加
- デザイン実装→ Figma MCP + Playwright MCP の組み合わせ
最初は「開発必須5選」から始めて、自分の作業パターンに合わせて追加していくのが無難だ。
