最初の失敗はだいたい決まっている。いきなり何個も MCP サーバを足して、どれが何をしているのか分からなくなるやつだ。これをやると、Claude Code の便利さより先に、設定の面倒くささだけが残る。まずは 1 つだけ足す。これがいちばん速い。
MCP は Model Context Protocol のことだが、名前を覚える必要は薄い。要するに、Claude Code に外部の道具を 1 つずつつなぐ仕組みだ。たとえばファイルを読む、ディレクトリをたどる、特定の情報源に触る、といった作業を Claude Code に任せやすくなる。開発用の道具だと思われがちだが、実際はファイル整理や文書作成にも効く。むしろ最初の 1 個は、コード補完より「手元の資料をどう扱うか」で入れるほうが失敗しにくい。
たとえば「このフォルダの中から古い重複書類を見つけたい」「案件ごとの資料を見ながら要約を書かせたい」「作業用ディレクトリだけ見せて、そこから整理させたい」といった用途だ。Claude Code 単体でもできることはあるが、見える範囲を絞って外部の情報源をつなぐと、やり取りがかなり楽になる。
まずは、追加したい MCP サーバの入れ方を押さえる。Claude Code は設定に MCP サーバを登録して使う。登録方法は、Claude Code の設定で行うやり方と、コマンドで追加するやり方がある。実際のコマンド名や設定ファイルの場所は環境で差が出るので、ここでは考え方を外さずに書く。基本は「サーバ名」「起動コマンド」「引数」を登録するだけだ。公式ドキュメントの案内に従うのが確実である。
たとえば、ローカルで動くファイル系の MCP サーバを 1 つ足す場面を想像すると分かりやすい。考え方はこうだ。
# 例: Claude Code の MCP サーバ追加コマンドのイメージ
# 実際のコマンド名や書式は公式ドキュメントで確認すること
claude mcp add <サーバ名> <起動コマンド> [引数...]
ここで大事なのは、最初から「全部見せる」構成にしないことだ。筆者は昔、資料置き場をまるごと見せようとして、途中で Claude Code の返す候補が多すぎて逆に扱いづらくしたことがある。検索対象を広げたつもりが、ノイズまで増えた。1 つ目の MCP サーバは、むしろ小さく切るほうがいい。
登録したら、すぐに動作確認を入れる。ここを飛ばすと、あとで「連携したつもりだった」が起きる。ありがちなのは、サーバ自体は起動しているのに、Claude Code から見たときの名前や権限がずれているケースだ。確認のしかたは、Claude Code 側で利用可能な MCP サーバ一覧を見たり、そのサーバが提供する機能を呼べるか試したりする。これも正確な確認コマンドは環境と設定で変わるので、公式の手順に合わせるのが安全だ。
実際の依頼文は、曖昧にしないほうがいい。たとえばファイル整理なら、こんな言い方が効く。
この作業用フォルダだけを対象にして、重複していそうなファイル名を拾ってください。
中身が同じかまでは断定しなくていいので、候補を一覧にして、怪しい順に並べてください。
勝手に削除はしないで、削除候補として止めてください。
文書作成なら、こういう頼み方がやりやすい。
この案件フォルダの中だけを参照して、打ち合わせメモの下書きを作ってください。
読み取った事実と推測を分けて書いてください。
足りない情報があれば、先に質問を出してください。
ここで意地悪なくらい大事なのは、「何を見てよくて、何を見てはいけないか」を先に縛ることだ。MCP サーバを足すと、Claude Code は便利になるが、同時に見える範囲も増える。便利さだけ見て雑に広げると、関係ないファイルまで拾ってしまい、出力が散る。筆者は一度、作業フォルダの外にあるテンプレートまで読ませてしまい、下書きが妙に他人行儀になった。参照範囲を限定したら、すぐに落ち着いた。ここは素直に制御したほうがいい。
もう一つ、地味だが効く注意がある。最初の 1 個は、できれば「読み取り中心」のサーバにすることだ。書き込みや削除までいきなり許すと、確認が面倒になる。ファイル整理系でも、最初は検索・一覧化・候補抽出に止めるのが安全だ。Claude Code に判断材料を渡すのはいいが、実行権限を急いで広げる必要はない。
非エンジニアなら、こう考えると分かりやすい。MCP サーバは、Claude Code に渡す「専門の作業台」だ。書類箱の中身を勝手に全部いじらせるのではなく、「この箱だけ開けてよし」「この棚だけ見てよし」と決める。弁護士が案件ごとにフォルダを分けるのと同じで、境界を最初に作ったほうが後が楽になる。ディスク削減を狙うなら、重複候補の洗い出しや不要キャッシュの候補収集から始めるといい。ただし削除実行は別段階に分ける。ここを混ぜると、確認のための確認が増えてだるい。
応用を考えるなら、次は「1 個の MCP サーバで何をさせるか」を詰める番だ。サーバを増やす前に、今ある 1 個で十分に仕事が回るかを見る。1 個で扱える範囲が固まると、次に足すべきサーバも自然に見えてくる。たとえばファイル系が安定してきたら、次は社内メモや外部情報源につなぐ、という順番だ。最初から全部つなぐ必要はない。むしろ、1 つずつ足したほうが、あとで外しやすい。
最後に、迷ったらこの基準で決めるといい。
MCP は、足した数で勝負する仕組みではない。最初の 1 個を雑に入れないこと、そのほうが圧倒的に効く。公式ドキュメントを見ながら、小さく始める。そこからで十分だ。