MCP は、入れれば入れるほど便利になるものではない。むしろ逆で、雑に増やすと Claude Code の中身が散らかって、何を頼むにも余計な確認が増える。ここを外すと、最初は賑やかでも、そのうち「結局どれを使えばいいんだ」となる。
Claude Code を使っていて本当に効くのは、数を増やすことではなく、仕事に直結する少数を選ぶことだ。ファイル整理でも、コード修正でも、文書作成でも同じで、よく使う保管場所と、よく触るサービスだけをつなぐほうが強い。MCP は武器庫ではなく、工具箱だと思ったほうがいい。
まず前提を揃える。ここでいう MCP は、Claude Code が外部のツールやデータに安全にアクセスするための接続口だ。たとえばファイルシステム、GitHub、Google Drive、Slack、ブラウザ操作系の連携がある。名前が似たものを片っ端から入れる必要はない。むしろ、何をどこまで見せるかを絞るのが先だ。
筆者は最初、便利そうな MCP をまとめて入れたことがある。結果どうなったかというと、Claude Code に頼むたびに「それはローカルファイルなのか、GitHub なのか、Drive なのか」を毎回整理する羽目になった。コンテキストの無駄遣いだし、依頼文も長くなる。しかも、似た機能の MCP が複数あると、どれを使うべきか指示が曖昧になって、差分が妙に大きくなる。あれは地味にだるい。
なので、選び方は単純でいい。次の順で絞る。
最初に入れるのは、ほぼ例外なくファイル系だ。Claude Code の強みは、ローカルのディレクトリをまたいで探したり、整理したり、既存ファイルを前提に作業できることにある。ファイルの移動、不要ファイルの洗い出し、文書の下書き、設定の確認。こういう作業に使うなら、まずはローカルの作業対象にしっかり触れることが第一だ。
次に必要なら、Git 系を入れる。コードや設定ファイルを扱うなら、変更履歴が見えるだけでだいぶ楽になる。レビュー前の差分確認、ブランチ単位の修正、コミットメッセージの整備。こういう使い方をする人には効く。ただし、GitHub 連携まで全部いるとは限らない。ローカルの git だけで足りるなら、それでいい。
三つ目は、日常的に置いてある情報源だけだ。たとえば仕事の資料を Google Drive にまとめているなら、その Drive 系の接続は価値がある。逆に、年に数回しか見ない外部サービスを繋いでも、ほぼ使わないまま管理コストだけ増える。
選び方の基準は、派手さではなく頻度である。毎日触る場所、毎週触る場所だけに絞る。これだけで十分だ。MCP は「入っている」ことに価値があるのではなく、「依頼文を短くできる」ことに価値がある。
実際の考え方はこうだ。
1. まず、Claude Code にやらせたい作業を3つ書き出す
例: ファイル整理 / コード修正 / 社内文書の下書き
2. その作業に必要な場所だけ並べる
例: ローカルフォルダ / Git リポジトリ / Drive
3. その中で、毎週以上使うものだけ残す
4. 迷うものは入れない
必要になってから追加する
依頼文も、最初から「全部見て」にはしないほうがいい。たとえばファイル整理なら、こんなふうに絞る。
このフォルダの中で、重複しているファイル名や明らかな不要ファイルを洗い出してください。
削除はせず、候補だけ一覧にしてください。
文書作成なら、こうだ。
このプロジェクト内の既存の文書を参照して、案件説明の下書きを作ってください。
口調は簡潔にして、社外向けにそのまま使える形に寄せてください。
ここで大事なのは、「Claude Code に何を見せるか」を先に決めることだ。MCP を入れすぎると、見える範囲が広がる。便利そうに見えるが、実際はノイズも増える。特に、似た情報が複数の接続先に散っていると、どれを正とするかが曖昧になる。これが一番まずい。
たとえば、同じ資料がローカル、Drive、別の共有ストレージに重複している状態で、全部をつなぐのは危ない。Claude Code は「どれが最新か」を人間ほど雑に忖度しない。だから、古い版を拾ってしまうことがある。最終的な責任は人間側にある。ここを甘く見ると痛い目を見る。
筆者が一度やらかしたのは、ファイル整理用の接続と、作業ログ置き場、共有フォルダを全部つないだことだ。すると、整理のつもりが「整理対象の説明」ばかり増えた。しかも、保存場所ごとに命名ルールが違うので、Claude Code に渡す前提条件を毎回説明する必要が出た。結局、接続を減らしたほうが速かった。便利さのための接続が、説明の手間を増やしていたわけだ。
もう一つ、入れない判断も重要だ。以下は、よほど理由がないなら後回しでいい。
ブラウザ操作系は、画面を見ながら作業する必要が本当にあるときだけでいい。単なる情報収集なら、資料を手元に置くほうが安定する。社内の公開範囲が厳しいシステムにむやみに繋ぐのもやめたほうがいい。権限の設計が曖昧なまま増やすと、後で整理が面倒になる。
非エンジニアの使い方でも同じだ。たとえば、弁護士が案件ごとのフォルダを整理して書面のたたきを作るなら、必要なのは案件フォルダと文書保管先くらいで足りることが多い。不要ファイルの整理や命名の統一をしたいだけなら、外部サービスを何個も繋ぐ意味は薄い。まずはローカルの整理を固める。それで十分に仕事になる。
MCP を増やすより効くのは、依頼の型を決めることだ。毎回の指示で「どこを見るか」「何をしないか」「成果物をどこに置くか」を短く書く。これだけで手戻りが減る。
対象はこの案件フォルダだけにしてください。
削除はしないでください。
修正案は別ファイルに出してください。
この三つを守るだけでも、事故はかなり減る。入れすぎた接続先より、こういう地味な制約のほうが効く。
最後に、選定の目安をひとことで言う。MCP は「便利そう」ではなく「依頼文を短くできるか」で選ぶ。毎日使う場所が一つ減って、毎回の説明が一段短くなるなら入れる価値がある。逆に、使う場面が思い浮かばないなら、その接続はまだ要らない。
迷ったら、まず最小構成で始める。ファイル系、必要なら Git 系、あとは本当に毎日触る保管先だけ。これで十分だ。増やすのはいつでもできるが、散らかった接続を片づけるのは面倒である。Claude Code を長く使うなら、ここはケチなくらいでちょうどいい。