SECTION 01
Claude Code × MCPで何が変わるのか
Claude Code単体でも、ファイルの読み書き・Git操作・サブエージェントによる並列処理など、開発に必要な基本操作は一通りこなせます。ターミナル上で動くCLIツールとして、コード生成からリファクタリングまで完結する場面も多いです。
さらに、Claude Codeはコードベース全体の理解や新しいプロジェクトの探索もサポートしています。単体でもかなりのことができるのが現在のClaude Codeです。
ただし、外部サービスへの読み書きや特化した連携機能となると話が変わります。ブラウザを自動操作してUIテストを回す、GitHubのIssueを参照しながらPRを一気に作る——こうした外部ツールとの深い連携は、MCPを使うと格段に強くなります。
ここで登場するのがMCP（Model Context Protocol）です。MCPはAIと外部システムをつなぐ橋渡し役で、Claude Codeに「目」や「手」を追加するような仕組みです。必要なMCPサーバーを接続すると、AIが自律的に外部ツールを操作できるようになります。
よく混同されるのが、Claude DesktopのMCPとClaude CodeのMCPの違いです。Claude DesktopはGUIベースでチャットしながら使う形ですが、Claude CodeはCLIベースなので自律実行との相性が良く、スクリプトやCI/CDに組み込みやすいのが強みです。
つまりClaude Code × MCPの本質は、CLIの自律性と外部連携の拡張性を掛け合わせるところにあります。ただし「何でも繋げばいい」わけではないことは、このあと詳しく触れます。
SECTION 02
.mcp.jsonの最小構成と設定手順
MCPサーバーの追加方法は大きく2つあります。claude mcp addコマンドで対話的に追加する方法と、.mcp.jsonファイルを直接編集する方法です。
コマンド経由は手軽で、初めてのMCPサーバーを試すときに向いています。一方、チームで設定を共有したい場合やリポジトリに設定を含めたい場合は、プロジェクトルートの.mcp.jsonを手動で書く方が管理しやすいです。
設定ファイルの基本構造は以下のようになっています。最小構成で押さえるべきポイントは3つです。
- mcpServers: 接続するMCPサーバーの定義
- command / args: サーバーの起動コマンドとパス指定
- env: APIキーや認証トークンなどの環境変数
環境変数の渡し方で迷う方が多いですが、認証トークンはenvフィールドに直接書くか、シェルの環境変数を参照させる形になります。.envファイルから読み込む仕組みは標準では用意されていないため、シェル側でexportしておくのが確実です。
設定が終わったのに動かないケースで多いのが、パスの不正・Nodeの未インストール・権限不足の3つです。特にnpxで起動するMCPサーバーはNode.jsが必要なので、事前にNode環境が整っているか確認してください。
エラーが出たときは、まずclaude mcp listでサーバーが認識されているかどうかを確認します。認識されていなければ設定ファイルの書式ミス、認識されているのに動かなければ起動コマンドの問題と切り分けられます。
SECTION 03
パターン1：Playwright MCPでブラウザテストを自動化する
最初に紹介するのは、Playwright MCPです。これはブラウザの自動操作に特化したMCPサーバーで、UIのテストやスクリーンショット取得を自動化できます。
筆者がMCPを使わないと公言していた時期にも、唯一入れていたのがこのPlaywright MCPでした。理由は単純で、「ブラウザテスト用」という用途が完全に明確だったからです。何をするか分かっているMCPは、入れる判断がしやすいのです。
導入はclaude mcp addコマンドで追加するだけです。追加後にClaude Codeから「このページのスクリーンショットを撮って」「フォームに入力してボタンを押して」といった指示を出すと、AIがブラウザを操作して結果を返してくれます。
実務で特に効果があるのは、以下のような場面です。
- UI変更後の見た目確認: CSSの修正が意図通りか、スクリーンショットで即座に確認
- フォームの動作テスト: 入力→送信→結果表示の一連のフローを自動で検証
- レスポンシブ確認: 複数の画面幅でページを開いて表示崩れをチェック
ポイントは、Playwrightは「何をさせるか」が最初から明確なMCPだということです。ブラウザ操作という限定された領域に閉じているので、予期しない破壊操作が起きるリスクが低いのです。
MCPを入れるかどうか迷ったら、まずこのPlaywright MCPから始めるのが最もリスクの低いスタートです。目的が明確で、影響範囲が限定されている——これがMCPを安全に導入するための判断基準になります。
SECTION 04
パターン2：Serena MCPでコンテキスト管理を強化する
2つ目のパターンは、Serena MCPです。これはAIエージェントのコード理解を補助するMCPサーバーで、プロジェクトの構造を賢く把握してくれます。
Claude Codeを使い込んでいくと、コンテキストの渡し方が課題になってきます。大規模なリポジトリでは、AIに必要な情報を過不足なく伝えるのが難しく、「このファイルも見て」と何度も指示するのは非効率です。
Serenaを導入すると、プロジェクト全体の構造を自動で把握し、関連するファイルや依存関係を踏まえた上でコードを理解してくれるようになります。筆者のまわりでも「コンテキストが上手く渡らない」という相談があったとき、Serenaを勧めるようになりました。
導入はuvx経由で追加します。Claude Code向けには、--context claude-codeオプションと--project-from-cwdを指定して起動するのが現在の推奨手順です。
claude mcp add serena -- uvx --from git+https://... serena-mcp-server --context claude-code --project-from-cwdの形式で追加- 初期化はSerena側が自動で行うため、手動でのステップは不要です
- あとは通常通りClaude Codeを使うだけで、コンテキストの精度が変わります
特にファイル数の多いリポジトリや、モノレポ構成のプロジェクトで効果を実感しやすいです。Claude Codeが「何を見ればいいか」を自分で判断できるようになるので、指示の手間が大きく減ります。
SECTION 05
パターン3：GitHub MCPでPR・Issue操作を自動化する
3つ目のパターンは、GitHub MCPです。GitHubのPR作成・Issue参照・差分要約など、リポジトリ運用に関わる操作をClaude Codeから直接行えるようになります。
認証方法はいくつかあります。PAT（Personal Access Token）を使う方法が最も手軽で、トークンを発行してMCPサーバーの設定で環境変数として渡します。環境によってはOAuthやGitHub App認証も利用できます。いずれの場合も、権限のスコープは必要最小限に絞るのが鉄則です。
実務で効果が出やすいのは、以下のような操作です。
- PR作成の自動化: コード変更後に差分を要約してPRのドラフトを生成
- Issue参照: 関連するIssueの内容を読み込んで、修正方針を提案
- 差分レビューの下書き: 変更点をまとめて、レビュアーが確認しやすい形に整理
導入方法としては、npx経由でレジストリサービスから起動する形や、HTTPで追加して認証フローを通す方法があります。セットアップ自体は短時間で終わります。
ただし、GitHub MCPは書き込み権限も持てるMCPです。Playwrightのようにブラウザ操作に閉じているわけではなく、PRのマージやIssueのクローズといった操作も可能になります。
だからこそ、トークンの権限は「読み取り＋PR作成」程度に絞り、マージ権限は含めないという運用設計が大事です。「繋いだら便利」で止まらず、何を許可して何を許可しないかを明確にしてから導入してください。
SECTION 06
MCPを入れる前に決めるべきガードレール
ここまで3つのパターンを紹介しましたが、MCPは「とりあえず繋ぐ」が最も危険です。筆者自身、当初はMCPを使わないと明言していました。勝手にGitにコミットされたり、データベースを消してしまったりという事故が実際に起きていたからです。
その経験から学んだのは、MCPを入れる前に「何を許可し、何を禁止するか」を先に決めることの重要性です。これをガードレールと呼んでいます。
具体的に設計すべきポイントは以下の通りです。
- 権限の最小化: 接続先ごとに、読み取りのみ・書き込みあり・削除禁止を明確に分ける
- 操作の確認フロー: 破壊的な操作（マージ・削除・デプロイ）は人間が確認するステップを残す
/permissionsで権限ルールを設定する: Claude CodeにはAllow / Ask / Denyの3段階の権限ルールが用意されています。ツールごとに「自動許可」「都度確認」「常に拒否」を細かく設定できるので、MCPツールにも適用してください- サンドボックスを活用する: Claude Codeのsandboxing機能と権限ルールは補完関係にあります。両方を組み合わせることで、万が一の誤操作の影響範囲を限定できます
dangerously-skip-permissionsを常用しない: 初回のボイラープレート生成には便利でも、通常の運用で使うのは事故のもとです
特に注意が必要なのは、データベースに接続するMCPです。SELECT文だけのつもりがDROP権限も持っていた、という状況は実際に起こり得ます。DB関連の操作はシステムプロンプトにガードレールを入れて、ユーザーが明示的に判断する設計にしておくのが安全です。
試行錯誤の中で辿り着いたのは、「MCPなしでもできることを先に整理する」というステップです。Claude Code単体でファイル操作・Git操作・サブエージェントの並列処理ができるなら、わざわざMCPを入れる必要はありません。
本当に外部接続が必要な場面だけを見極めて、目的が明確なMCPだけを追加する。これが事故を防ぎながらMCPの恩恵を受けるための基本姿勢です。
SECTION 07
MCPなしでもここまでできる：Claude Code単体の実力
MCPの記事で「MCPなしの話」をするのは矛盾に聞こえるかもしれませんが、MCPの価値を正しく判断するには、まずMCPなしで何ができるかを知る必要があります。
Claude Code単体でも、コードの読み書き・リファクタリング・テスト生成・Git操作はすべてターミナル上で完結します。サブエージェントを使った並列処理もできるので、複雑なタスクも分割して効率よく進められます。
さらに活用度を上げる機能として、以下があります。
- Explore / Plan サブエージェント: コードベースの調査や、複数ファイルにまたがる変更の設計を先に行えます
- 汎用サブエージェントの並列実行: 独立した修正を同時に進められます
- カスタムサブエージェント: 用途に合わせて、コードレビュー用やテスト用など自分でサブエージェントを定義して組み込むこともできます
これらはMCPを入れなくてもClaude Codeの機能として使えます。「AIエージェント的な動き」は、実はMCPなしでもかなりの範囲で実現できるのです。
その上で、ブラウザ操作・外部API連携・リポジトリ管理といった「Claude Codeの外側」に手を伸ばしたい場面だけ、MCPを検討する。この順番を守ることで、不要な接続を増やさずに済みます。
SECTION 08
最初のMCPを選ぶときの判断基準
「MCPを試してみたいけど、何から入れればいいか分からない」という声をよく聞きます。筆者の経験から言えば、最初の1つは「用途が1つに絞れるもの」を選ぶべきです。
たとえばPlaywright MCPは「ブラウザを操作する」という目的が1つに限定されています。何が起きるか予測しやすく、万が一の影響範囲も小さいです。
逆に避けた方がいいのは、以下のようなケースです。
- 接続先の操作範囲が広すぎるMCP: 読み取りも書き込みも削除もできてしまう
- 自分が接続先の仕組みを理解していないMCP: 何が起きるか想定できない
- 「みんな使っているから」という理由だけで入れるMCP: 自分の開発フローに必要かどうかが判断基準
これまでの経験を踏まえると、MCPは「全部入れる」ものではなく「必要なものだけ選ぶ」ものです。1つ入れて運用に慣れたら、次に必要なものを追加する。この段階的なアプローチが結局いちばん安全で、効果も実感しやすいです。
Claude Codeの拡張性は魅力的ですが、拡張するかどうかの判断力こそが、MCPを使いこなす上で最も大事なスキルです。目的を明確にして、小さく始めてください。
SECTION 09
Claude DesktopとClaude CodeのMCP：どちらで使うべきか
MCPはClaude DesktopとClaude Codeの両方で使えますが、開発の自動化という文脈ではClaude Codeが圧倒的に向いています。理由はCLIベースの自律実行にあります。
Claude Desktopはチャット画面を介して操作するため、人間が逐次指示を出す対話型のワークフローに適しています。一方、Claude Codeはターミナルで動くので、スクリプトに組み込んだり、他のCLIツールと連携させたりできます。
使い分けの目安は以下の通りです。
- Claude Desktop + MCP: 調査・情報収集・ドキュメント作成など、対話しながら進める作業
- Claude Code + MCP: コード生成・テスト自動化・PR作成など、自律的に完了させたい開発タスク
- 両方使わない: そもそもMCPが不要な単純なコード修正
特にClaude Codeでは、-pオプションでパイプライン的にJSONアウトプットを取得することもできます。CI/CDとの統合や、バッチ処理的な使い方との相性が良いのはCLIならではです。
ただし、どちらを使う場合でもMCPの権限管理は同じように重要です。GUIだから安全、CLIだから危険ということはなく、接続先で何ができるかを把握しているかどうかが本質です。
SECTION 10
明日から始めるMCP導入の実践ステップ
ここまでの内容を踏まえて、MCPを安全に導入するための実践ステップをまとめます。いきなり複数のMCPを入れるのではなく、段階的に進めるのが成功のコツです。
まず最初にやるべきは、Claude Code単体で自分の開発フローを一通り回してみることです。ファイル操作、Git操作、サブエージェントの活用——ここで十分に感覚を掴んでから、MCPの検討に入ります。
次に、開発フローの中で「ここだけはClaude Code単体では届かない」というポイントを具体的に洗い出します。ブラウザ確認、GitHub操作、コンテキスト管理など、明確に困っている場面を特定してください。
導入の順番は以下がおすすめです。
- ステップ1: Playwright MCPでブラウザ操作を自動化（影響範囲が最小）
- ステップ2: Serena MCPでコンテキスト管理を強化（読み取り中心で安全）
- ステップ3: GitHub MCPで操作を自動化（書き込みあり、権限設計を先に行う）
各ステップで大事なのは、入れた後に「何が変わったか」を自分で確認することです。体感として効果がなければ外す判断も必要です。MCPは入れっぱなしにするものではなく、常に見直す対象です。
MCPは強力な拡張手段ですが、目的なく繋ぐと複雑さとリスクだけが増えます。「このMCPは何のために入れるのか」を言語化できない状態なら、まだ入れるタイミングではありません。必要になったときに、必要なものだけ追加する——それがMCPと上手く付き合う方法です。
