この記事には広告を含む場合があります。
記事内で紹介する商品を購入することで、当サイトに売り上げの一部が還元されることがあります。
MCPを入れたのに、生活があまり変わっていない。
そんな経験はありませんか。
設定はした、サーバーも立てた、でも日常の開発で使う場面がよく分からない。
私も当初、まさにその状態でした。
そもそもMCPって何？からでした。
結論から言うと、MCPは「作業を自動化する魔法」ではありませんでした。
その正体は「説明や切り替えの摩擦を減らす仕組み」です。
そして全部つなぐより、必要なものだけつなぐ方がうまくいくことが分かりました。
- MCPの正体＝「説明や切り替えの摩擦を減らす仕組み」という発見
- 1年使って手放せなくなった便利MCP 3選（Filesystem／GitHub／Fetch）
- 期待外れで使わなくなったMCP（Slack・Notion・Figma／DB常時接続）
- 「全部つなぐ」より「必要なものだけつなぐ」取捨選択の判断軸
記事を書いている人
R（アール）
Web制作の現場で17年（現役進行中）。精密栄養カウンセラー。
個人開発をアプリ6本並行しながら、AIと「作る・届ける」を実験しています。
うまくいったことも、月収2,000円みたいな冴えない数字も、隠さず公開中。
教える人ではなく、少し先で転んで戻ってきた人として、あなたと同じ目線で現在地を観測していけたらと思います。
MCPは「自動化の魔法」ではない
MCPを導入した当初、私は大きな期待を抱いていました。
「Claudeがあらゆるツールと連携して、全部自動でやってくれる」というイメージです。
しかし実際に使ってみると、悩みの正体は設定そのものではありませんでした。「どのツールをいつ使うか」という役割の切り分けができていなかったんです。
MCPをたくさんつないでも、どのツールをいつ使うべきか判断できなければ、かえって混乱します。
肝心なのは「毎回説明している手間」を減らすことです。
Claude Codeに何度も同じことを説明しているなら、そこをMCPでつなぐ。
逆に、たまにしか使わないものは手動で十分です。
結局、MCPって多く入れた方が便利なんじゃないんですか？どれを選べばいいのか…
逆でした。多くつなぐほど「どれをいつ使うか」で迷って、かえって混乱します。僕が1年使って手放せなくなったのは3つだけ。次に、その中身と、逆に切ったものを正直に話します。
本当に便利だったMCPサーバー3選
半年間使い続けて、本当に手放せなくなったものを紹介します。
Filesystem系
最も使用頻度が高いのがFilesystem系のMCPです。
プロジェクトのディレクトリ構造を毎回説明する必要がなくなりました。
特に複数のプロジェクトを行き来する開発では効果的です。
「このプロジェクトは/srcにコードがあって、/docsにドキュメントがあって…」という説明が不要になります。
Claudeが直接ファイルシステムを見られるため、コンテキストの共有がスムーズになりました。
GitHub系
Pull RequestのレビューやIssueの確認で重宝しています。
「このPRの変更内容を見て」と言うだけで、差分を取得して分析してくれます。
以前はGitHubの画面をスクリーンショットで共有したり、差分をコピペしたりしていました。
その手間がゼロになったことで、レビューの質に集中できるようになりました。
Fetch/API系
外部APIのドキュメントを参照しながらコードを書く場面で活躍します。
「このAPIの仕様を確認して」というリクエストに対して、直接ドキュメントを取得して回答してくれます。
ただし、認証が必要なAPIには使えません。
公開されているドキュメントやREST APIの確認に限定して使うのがコツです。
個人的には期待外れだったMCPサーバー
正直に言うと、期待に反して使わなくなったものもあります。
Slack/Notion/Figma
コラボレーションツール系は、つないでみたものの日常的には使いませんでした。
理由は単純で、これらのツールは「人間が見て判断する」場面が多いからです。
Slackのメッセージを要約させても、結局自分で読み直します。
Notionのページを更新させても、レイアウトの微調整が必要になります。
Claudeに任せきれない部分が多く、MCPでつなぐメリットが薄かったのです。
たぶん私ならではのケースもあると思います。一旦個人的な所感という1ケースとして捉えていただけると。
DB系常時接続
データベースへの常時接続も試しましたが、すぐにオフにしました。
セキュリティ面の不安もありますが、それ以上に「文脈汚染」の問題がありました。
常にDB接続があると、関係ない質問をしても「データベースを確認しましょうか」と聞かれます。
必要なときだけ手動で接続する方が、会話がスムーズに進みます。
ワークフローはどう変わったか
MCPを適切に取捨選択した結果、「説明する時間」が「判断する時間」に変わりました。
以前は「このファイルを見て」「この差分を確認して」という前置きに時間を取られていました。
今は「このコードをリファクタリングすべきか判断して」という踏み込んだ質問から始められます。
CLAUDE.mdでプロジェクト設定を育てる方法と組み合わせると、さらに効果的です。
プロジェクト固有のルールはCLAUDE.mdに、外部リソースへのアクセスはMCPに、という役割分担ができます。
/compactと/clearコマンドの使い分けも覚えておくと、MCP経由で取得した大量の情報を整理するときに役立ちます。
MCPの限界と「つながない」選択
MCPは万能ではありません。
私の場合は、むしろ「つながない」選択が正解な場面も多かったです。
まず、セキュリティが重要な情報はつなぐのをまだ躊躇してしまいます。
本番環境のDBやクレデンシャル情報へのアクセスは、どれだけ便利でもリスクが上回る気がします。
次に、常時オンにする必要はありません。
必要なときだけ有効にして、使い終わったら無効にする。その方が文脈がクリーンに保たれます。
Claude Codeでよくある失敗パターンと対策でも触れていますが、「便利そうだから全部入れる」は典型的な罠です。
Claude CodeとCursorの機能比較を読んで、そもそもどのツールを使うか検討するのも良いでしょう。
また、Claude Code拡張機能の役割と使い分けも参考になると思います。
MCPと拡張機能、どちらで解決すべきかを考えることで、無駄な設定を減らせます。
独学で詰まりやすい部分を体系的に学びたい方は、2026年4月から「Claude Codeマスターコース」が追加されたDMM 生成AI CAMP 生成AIエンジニアコース
も選択肢になります。月額制の学び放題なので、必要な期間だけ集中して学べます（新規無料セミナーから試せます）。
まとめ：必要なものだけつなぐ
MCPの価値は「全部つなげる」ことではなく「必要なものだけつなぐ」ことにあります。
便利だったのはFilesystem系、GitHub系、Fetch/API系の3つ。
期待外れだったのはSlack/Notion/Figma、DB系常時接続でした。
まずは自分の作業で「毎回説明しているもの」を1つ見つけてください。
そこだけMCPでつないでみる。それが第一歩です。
全部つなぐ必要はありません。自分のワークフローに合わせて、取捨選択していきましょう。
どのMCPを入れるかは、突き詰めると「自分がどの作業で毎回説明しているか」を知っているかどうかで決まります。
便利そうなサーバーは次々出てきます。でも、自分のワークフローのどこに摩擦があるのかを観測しないまま全部つなぐと、便利な機能ほど文脈を汚して逆効果になる。今の自分の作業のどこで時間を取られているのか——そこを観測することから、つなぐ・つながないの判断は決まっていきます。
参考になれば幸いです。
この記事は「Claude Code 完全ガイド」シリーズの一部です。
→ シリーズ全体を見る
📚 Claude Code・AI開発の全体像は Claude Code・AI開発 完全マスターガイド で関連21記事を整理しています。
📚 シリーズ全体を見る: Claude Code CLI/Desktop 完全ガイド（このシリーズの pillar 記事）
Git/Claude Code 使い込んでる人ほど、止まりがちです。
「もっと勉強しなきゃ」「もっと作らなきゃ」――Claude Code, Cursor, GitLens を試すほど、知識は増えるのに、自分が前に進んでる感覚は薄れていく。
個人開発8本、月収2,000円。Web制作17年のクリエイターが、AI と「作る」「届ける」を honest に実験している過程をメルマガで公開しています。
登録特典:「AI時代に取り残されないための構造整理シート」（PDF 12p / 5ステップ）― スキル棚卸し → AI との組み方 → 自分のポジション設計。
