Claude Code × MCP完全ガイド——外部ツールと連携してできることが激変する

はじめに

Claude Codeを使い込んでいくと、ある限界に気づく。GitHubのIssueを参照させたい、最新のフレームワークドキュメントを読ませたい、Slackのメッセージを踏まえてコードを設計させたい——これらはデフォルトのClaudeには不可能だ。

MCPはその限界を突破する仕組みだ。 Model Context Protocol（MCP）はAnthropicが提唱するオープン標準プロトコルで、Claude Codeを外部ツールやデータソースに接続できる。2026年現在、主要なAIプロバイダーに広く採用され、エコシステムが急拡大している。

ただし、MCPは使い方を誤るとコンテキストウィンドウを圧迫してパフォーマンスが低下するという落とし穴もある。本記事では「何ができるか」と「コストをどう管理するか」の両方を解説する。

MCPとは何か——なぜビルトインツールが足りないのか

実はClaude Codeのビルトインツール（Edit、Read、Write等）は内部的に全てMCPサーバーとして実装されている。MCPは「外部連携のための仕組み」であると同時に、Claude Code全体のツール基盤でもある。

ビルトインツールはローカルファイルシステムの操作に特化している。「GitHubのPRを読む」「最新のReactドキュメントを参照する」「Slackの会話を検索する」といった操作は外部APIが必要で、MCPサーバーがその橋渡しをする。

Claude Code ←→ MCPサーバー ←→ 外部ツール・API
（プロトコルで通信）       （GitHub/Slack/DB等）

設定方法：2種類のスコープを使い分ける

設定の場所はスコープによって2種類に分かれる。

注意点として、MCP設定は ~/.claude/ ではなく ~/.claude.json（ホームディレクトリ直下）に記載する。

# ユーザースコープで追加（個人設定）
claude mcp add context7 -s user -- npx -y @upstash/context7-mcp

# ユーザースコープ＋環境変数付き
claude mcp add github -s user -e GITHUB_TOKEN=ghp_xxxxx -- npx -y @modelcontextprotocol/server-github

# プロジェクトスコープで追加（.mcp.jsonに書き込まれる）
claude mcp add slack -- npx -y @anthropic/mcp-server-slack

セキュリティの注意：APIキーやトークンは settings.local.json（.gitignore対象）に分離し、.mcp.json には環境変数参照のみを記載してバージョン管理に載せる。

厳選MCPサーバー4選

Context7（最優先で導入すべきサーバー）

最新のフレームワーク・ライブラリドキュメントをClaudeのコンテキストに直接注入する。React、Next.js、Tailwind CSS、Prismaなど50以上のフレームワークに対応。Upstashが開発し、MCP対応ツールの中でも採用率が突出して高い。

claude mcp add context7 -s user -- npx -y @upstash/context7-mcp

なぜ最優先か：Claude Codeの最大の弱点は「学習データのカットオフ以降の変更を知らない」ことだ。最新のAPI仕様変更、破壊的変更、新しいベストプラクティスをClaudeが知らないまま実装してしまうのが、最も多い「見えない手戻り」の原因になる。Context7を入れて /use context7 を付けるだけで、その問題が解消される。他のどのサーバーよりも即座にROIを実感しやすい。

GitHub

IssueやPRの参照・作成、リポジトリ検索をClaude Codeから直接操作できる。

claude mcp add github -s user -e GITHUB_TOKEN=ghp_xxxxx -- npx -y @modelcontextprotocol/server-github

- Before: 「このIssue番号の実装をして」→ Claudeがissueの内容を知らないため追加の説明が必要

- After: ClaudeがIssueを直接読み、背景・要件・関連PRを把握した上で実装する。「#1234を実装して」の一言で完結

Playwright

Claudeがブラウザを操作してUIスクリーンショットを撮影・テストできるようになる。

- Before: UIを実装 → 人間がブラウザで確認 → 「ここが崩れてる」とスクリーンショットをClaudeに送る → 修正

- After: 実装後にClaudeが自分でブラウザを開いてスクリーンショットを撮り、「左カラムが2pxずれています」と自己報告して修正まで完結

Slack

Claudeからチャンネル検索・メッセージ投稿が可能。Claude Code開発者のBoris Cherny（Anthropic）が日常的に使っているMCPの1つだ。

- Before: Slackの仕様議論を参照しながらコードを書くには、Slackとエディタを行き来する必要があった

- After: 「#dev-apiチャンネルの先週の議論を踏まえてAPIを設計して」という指示だけで、Slackの文脈ごと実装できる

コンテキスト問題：MCPの最大の落とし穴

MCPサーバーは存在するだけでツール定義をシステムプロンプトに追加し、コンテキストを消費し続ける。

個人エンジニアMario Zechnerによる調査（参考値）では、コンテキスト消費の実態が明らかになっている。

MCPとCLIの間には最大43倍の差がある。コンテキストウィンドウが200,000トークンあっても、MCPサーバーを多用すると実質70,000トークン程度まで縮小することがある。

プロジェクトごとに有効化するサーバーは10個以下、ツール総数は80以下を目安にしておくと安心だ。

Tool Search：コンテキスト問題の解決策

MCPツールの記述がコンテキストの10%を超えると、Claude Codeは自動的に「Tool Searchモード」に切り替える。全ツール定義を事前ロードするのではなく、必要なツールのみを動的にロードする仕組みだ。/context で確認して「MCP tools · /mcp (loaded on-demand)」と表示されれば有効になっている。

Tool Searchが有効なとき、Claudeはserver instructionsを元にツールを検索する。記述が貧弱だとClaudeが必要なツールを見つけられない。

# 良い例
GitHub MCP Server
GitHubリポジトリのissue、PR、コードを操作するツール。
Use when: GitHub、repo、issue、pull request、code review について聞かれたとき
Keywords: github, repository, issue, PR, merge, branch, commit

# 悪い例
GitHub tools（これだけでは検索ヒット率が大幅に低下）

MCP vs CLI：正しい使い分け

MCPが万能というわけではない。ClaudeはBashコマンドの使い方をトレーニングで学習済みのため、CLIツールで代替できる場合はCLIの方がいい。

判断基準はシンプルだ——「自然言語でツールを操作させたいか」→ MCP。「コマンドを実行させたいだけ」→ CLI。

チームでの活用：.mcp.jsonをgit管理する

.mcp.json をバージョン管理に含めると、チーム全員が同じMCP環境を共有できる。

プロジェクトルート/
├── .mcp.json               ← git管理（サーバー設定）
└── .claude/
└── settings.local.json  ← .gitignore（APIキー等の秘密情報）

新メンバーがリポジトリをクローンするだけで、チームが使っているMCPサーバーが即座に利用可能になる。

まとめ：3つのルール

結局、覚えることは3つだけだ。

1. 必要最小限のサーバーのみ有効化：使わないサーバーは /mcp disable で停止（コスト削減効果が大きい）

2. チーム共有は .mcp.json で：個人設定は ~/.claude.json に分離

3. APIキーは settings.local.json に：絶対にgit管理に含めない

まず試すなら、Context7を1つ導入するところから始めてほしい。コマンド1行で設定でき、「最新ドキュメントを知らないまま実装する」という見えない手戻りが消える体験をすぐに得られる。