Claude CodeにMCPを繋いだら開発効率が激変したー実務で使った3つのMCPサーバー
「MCPって最近よく聞くけど、実際どう使えばいいの？」
そう思っていらっしゃる開発者の方は多いのではないでしょうか。
私もそうでした。ChatGPTやClaude Codeでコーディングを効率化しているうちに、「MCP」という言葉が目に入るようになってきました。しかし調べてみると英語の情報が多く、「で、実際に何が便利になるの？」がイマイチ掴めずにいました。
この記事では、そんな疑問をお持ちの方に向けて、実際の業務プロジェクトで3つのMCPサーバーを使ってみた体験をもとに、MCPの実務での使い方と効果をお伝えします。
こんな方に読んでいただきたい記事です。
- MCPという言葉は知っているが、実務での使い方がわからない
- Claude CodeなどAIコーディングツールをすでに活用している
- 設計書管理・テスト・UI確認などの確認作業を効率化したい
MCPを使うことで、「人間が手でやっていた確認作業をAIに委譲できる」という体験ができるようになります。設計書とコードのズレ検知、E2Eテストの自動生成、UI動作確認まで、AIが"目と手"を持って動いてくれる感覚は、実際に使ってみると大変驚かされます。
MCPとは？「AIに目と手を与える」仕組み
MCPとは「Model Context Protocol」の略で、LLM（大規模言語モデル）が外部のツールやサービスと連携するための標準プロトコルです。
2024年末にAnthropicが公開したこのプロトコルは、急速にエコシステムが広がっており、Google Drive・GitHub・Playwright・ブラウザ操作など、さまざまなMCPサーバーが登場しています。
少しわかりにくい概念ですので、もう少し噛み砕いてご説明します。
通常のAIコーディングアシスタントは、コードや文章を貼り付けると「それに対して回答する」という形で動作します。一方でMCPを使うと、AIが自分で外部のファイルを読みに行ったり、ブラウザを操作したりできるようになります。
人間が「ここを見て確認して」と教えなくても、AIが自分でアクセスして確認できるようになる、というイメージです。
これが「AIに目と手を与える」と表現される理由です。
実務で使った3つのMCPサーバー
私が業務プロジェクトで実際に繋いで使ったMCPサーバーは以下の3つです。
- Google Drive MCP ― 設計書を読んでコードを書く
- Playwright MCP ― E2Eテストの実行と検証
- Chrome DevTools MCP ― 実機でのUI検証
それぞれ、どんな課題があってどのように解決したか、実例とともにご紹介します。
1. Google Drive MCP ― 設計書とコードのズレをAIが検知
【2025年12月 最新情報】 Googleが公式にMCPサポートを発表し、Google Driveをはじめとする各種Googleサービスへのリモート接続が可能になりました。以前はAnthropicが提供するコミュニティ製のリファレンス実装を利用する必要がありましたが、現在はGoogle公式の管理されたMCPサーバーを利用できます。詳細はGoogle Cloud公式ブログをご参照ください。
Before：設計書とコードの乖離が頻発していた
開発においてよくあることかと思いますが、設計書（スプレッドシート等）とコードの実装が少しずつズレていく問題を経験されたことはないでしょうか。
「あれ、このカラム、スプレッドシートにはあるけど実装に入っていない？」
「DBのカラム名、設計書と実装で微妙に違う…」
このようなミスは、コードだけを見ていると気づきにくいものです。設計書と突き合わせる作業は地味に時間がかかりますし、疲れてくると見落としも発生しやすくなります。
After：AIがスプレッドシートを直接読んで差分を出す
Google Drive MCPを使うと、AIがGoogleスプレッドシートに直接アクセスできるようになります。
たとえば、以下のような指示が通るようになります。
「Google Driveの設計書とSQLAlchemyモデルを比較して差分を出して」
すると、AIが自分でスプレッドシートを開いてテーブル定義を読み取り、実装コードと照合して「このカラムが未反映です」「カラム名が一致していません」という差分を一覧化してくれます。
この「突合作業」は、これまで人間が手作業で行っていたものです。それをAIに委譲できたことは、非常に大きな効果がありました。
得られた効果
- 設計書のコピペミスによるバグが減少
- 要件定義書を参照しながらの実装指示が可能に
- 人間がやっていた突合作業をAIに委譲できた
2. Playwright MCP ― AIが画面を操作しながらテストコードを書く
Before：E2Eテストの作成・デバッグに時間がかかる
E2Eテストの作成は、なかなか手間のかかる作業です。
「この画面でこのボタンを押して、次の画面に遷移したら、このテキストが表示されていることを確認する」という手順をコードに落とし込む作業は、画面を手で操作しながらセレクタを探し、失敗したらまた画面を確認して…というループが続き、多くの時間を要します。
After：AIが画面を実際に操作しながらテストコードを生成
Playwright MCPを使うと、AIがブラウザを直接操作できるようになります。
AIが実際に画面を動かしながらテストコードを作成してくれますので、テスト失敗時も「現在この画面はこのような状態になっています。エラーの原因はここだと思われます」と即座に報告してくれます。
「画面を見ながらテストを書く」という作業をAIが代行してくれる、という感覚です。
得られた効果
- テストコードの初稿作成が大幅に効率化
- デバッグ時の原因特定が早くなった
- 「今この画面はどういう状態か」にAIが即答できる
3. Chrome DevTools MCP ― 「この画面でAPIエラーが出ていないか」をAIに確認させられる
Before：UI実装後の目視確認・動作検証が手動で非効率
「実装した機能を一通り手で動かして確認する」という作業は、かなりの時間を要します。
ログインして、目的の画面まで遷移して、正しく表示されているか確認して、コンソールエラーが出ていないか確認して…。これを毎回手動で行うのは時間がかかりますし、確認漏れも発生しやすい状況でした。
After：AIがブラウザを操作して検証・報告してくれる
Chrome DevTools MCPを使うと、AIが開発中のアプリにブラウザ経由でアクセスし、動作を確認してくれます。
「ログインして、この画面に遷移して、表示内容を確認してください。あわせてコンソールログとAPIエラーも確認してください」という指示を出すと、AIがそのまま実行して結果を報告してくれます。
スクリーンショットベースでUIレビューができる点も非常に便利で、「この見た目で問題ないか」という確認も行えるようになりました。
得られた効果
- 「この画面でAPIエラーが出ていないか」をAIに確認させられる
- 実装→確認のサイクルが短縮
- スクリーンショットベースのUIレビューが可能に
MCP導入でワークフローがこう変わった
3つのMCPサーバーを導入したことで、開発フローが大きく変わりました。
工程 | Before | After（MCP導入後） |
|---|---|---|
設計書確認 | 手動でシートを開いて目視 | AIが直接読み取って比較 |
UI検証 | 手動ブラウザ操作 | AIがブラウザ操作して報告 |
E2Eテスト | 手動で画面確認しながら記述 | AIが画面操作しながら生成 |
バグ調査 | ログ確認→画面確認→原因推定 | AIがログ＋画面を同時に見て推定 |
共通して言えるのは、「人間が目で見て確認する作業をAIに委譲できた」ということです。
これがMCPの一番の価値だと感じています。
ハマったポイント・使う前に知っておきたいこと
便利なMCPですが、導入してみてハマったポイントもいくつかありましたので、正直にお伝えします。
認証周りが一番の壁
Google DriveのOAuth設定や、ブラウザのセッション管理など、認証周りの設定でつまずくことがありました。最初の設定さえ乗り越えればスムーズに動作しますが、ここは少し時間を確保しておくことをおすすめします。
MCPサーバーの接続が切れることがある
長時間作業していると接続が不安定になることもあります。タイムアウトの設定を調整したり、接続が切れた際は再接続する習慣をつけておくとよいでしょう。
AIの出力を過信しないこと
これが最も重要な点かもしれません。AIが「画面は正常です」「設計書と一致しています」と報告した場合でも、最終確認は必ず人間の目で行うようにしていました。
セキュリティの範囲は明示的に制限する
AIにどこまでアクセスさせるかは、事前にしっかり決めておくことをおすすめします。私のプロジェクトでは、CLAUDE.mdに以下のルールを明記しました。
「ファイル・ディレクトリの削除は絶対に行わない」
AIの行動範囲を明示的に制限しておくことで、意図しない操作を防ぐことができます。
MCP導入を検討している方へ：最初の一歩
「よし、やってみよう」と思ったとき、何から始めればよいか迷う方も多いかと思います。
私がおすすめする順番をご紹介します。
まずはPlaywright MCPから始める
3つの中で最もわかりやすく効果を実感しやすいのがPlaywright MCPです。「AIがブラウザを動かす」という体験は直感的にわかりやすく、最初の成功体験を積むのに適しています。
小さな成功体験を積んでから拡張する
「まずは1つのMCPで効果を確かめてから、次のMCPを追加する」という流れをおすすめします。最初から全部一気に導入しようとすると、設定でつまずいた際に原因の特定が難しくなります。
CLAUDE.mdで操作制限を明記してから運用開始
MCPを使い始める前に、AIにやってほしくないこと（削除操作の禁止など）をCLAUDE.mdに記載しておきましょう。後から追加するよりも、最初から設定しておくほうが安心です。
向いているケース
- 外部ドキュメントとコードの整合性管理が多い
- E2Eテストや画面検証の工数が大きい
- 1人または少人数で広い範囲をカバーしている
まとめ：MCPは「AIに外部ツールの目と手を与える」仕組み
この記事でお伝えしたかったことをまとめます。
MCPを使うと、AIが外部のツール（Googleスプレッドシート、ブラウザ、DevToolsなど）に直接アクセスして操作できるようになります。
実務での価値は「人間が手でやっていた確認作業の委譲」にあります。
- 設計書↔コードの突合 → Google Drive MCPで自動化
- 画面操作↔テストコード → Playwright MCPで効率化
- 実機動作↔エラー確認 → Chrome DevTools MCPで短縮
まだ発展途上のプロトコルではありますが、開発ワークフローを大きく変えるポテンシャルがあることは間違いなく感じています。
「設計書の確認やUI検証に時間がかかっている」「1人でカバーしている範囲が広い」という方には、特におすすめできます。
まずは1つのMCPから、小さく試してみてください。思っていた以上に、AIが"動いてくれる"体験は新鮮で面白いものです。
