最初に MCP サーバーを Claude Code に接続したとき、「これは別物だ」と思いました。
それまでの Claude との対話は、テキストを送ってテキストを受け取る往復でしかありませんでした。しかし MCP（Model Context Protocol）でツールを繋いだ瞬間、Claude が自分のプロジェクトのコード、データベース、外部サービスを「直接触れるもの」として扱い始めた感覚があります。今回は、その体験を具体的な設定手順と実例で共有したいと思います。
MCP サーバーとは（改めて整理する
MCP は Anthropic が策定したオープンプロトコルで、LLM が外部ツールやデータソースと安全にやり取りするための仕様です。Claude Code では .claude/settings.json に MCP サーバーの接続情報を書くだけで、Claude がそのツールを使えるようになります。
重要なのは「Claude 自身がツールを選び、呼び出す」という点です。あなたが「このファイルを読んで」と言わなくても、Claude は文脈からそれが必要だと判断して実行します。ここが従来の「会話で指示する」アプローチと根本的に異なります。
公式ドキュメントには載っていませんが、実際に使ってみて気づいたのは、MCP ツールの呼び出しログが Claude の思考プロセスをそのまま可視化してくれるという点です。何をどの順に調べているかが手に取るようにわかり、デバッグ時の手がかりとして非常に役立ちます。
実際に役立つ MCP サーバーの選び方
すでに数十の公式 MCP サーバーが公開されていますが、全部入れれば良いというものではありません。私が実際に使い続けているのは次の 4 つです。
filesystem — ローカルファイルへのアクセス。「今の状態を確認してから提案する」という作業スタイルを支えてくれます。許可するパスを絞ることでセキュリティリスクも抑えられます。
github — リポジトリ操作。PR のコメント参照、イシュー検索、ブランチ管理などを Claude が直接実行できます。「この PR に関連するイシューを全部洗い出して」という依頼が現実のものになります。
sqlite — ローカルデータベースとの対話。スキーマを調べながらクエリを最適化する作業が、会話だけで完結します。
fetch — Web コンテンツの取得。公式ドキュメントや API リファレンスを直接参照しながらコードを書いてもらえます。
逆に、最初から入れすぎると Claude のコンテキストが分散してしまいます。プロジェクトごとに必要なツールだけを有効化する設定管理が、長期的には重要になります。
.claude/settings.json の実践的な書き方
基本的な設定はシンプルです。
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/Users/yourname/projects/myapp"
]
},
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "YOUR_GITHUB_TOKEN"
}
},
"fetch": {
"command": "uvx",
"args": ["mcp-server-fetch"]
}
}
}トークンの扱いについて一言: 上の例では env に直接書いていますが、本番プロジェクトでは .env ファイルか OS のキーチェーンを使い、.gitignore に settings.json を追加することを強くお勧めします。誤って GitHub にプッシュしたトークンは即座に無効化されるので、プレースホルダー形式（YOUR_GITHUB_TOKEN）で管理するのが安全です。
設定後、Claude Code を起動して /mcp コマンドを実行すると接続済みサーバーの一覧が表示されます。ここに緑のチェックマークが並んでいれば準備完了です。
よくあるエラーと対処法
実際に使い始めると、次のエラーによく遭遇します。
Error: spawn npx ENOENT
Node.js が PATH に入っていないか、バージョンが古い場合に発生します。node --version で 18 以上を確認し、nvm や fnm でバージョン管理している場合はシェルの設定ファイルで PATH を明示的に通してください。
Permission denied (filesystem サーバー)
許可パスの外のファイルにアクセスしようとしたときに出ます。エラーそのものは問題ありませんが、Claude が繰り返し同じエラーを出す場合は、許可パスの設定を見直すのが早いです。
ツールは表示されるが実行されない
これが一番厄介なパターンで、たいていは MCP サーバーが起動時にクラッシュしています。claude --mcp-debug オプションで起動するとサーバーの stdout/stderr がそのまま見えるので、問題の特定が早くなります。
実際のプロジェクトで使った構成例
私が個人アプリ開発で使っている構成を紹介します。Next.js + Cloudflare Workers のプロジェクトで、以下の 3 つを組み合わせています。
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/Users/masaki/projects/myapp/src",
"/Users/masaki/projects/myapp/content"
]
},
"fetch": {
"command": "uvx",
"args": ["mcp-server-fetch"]
},
"sqlite": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-sqlite",
"--db-path",
"/Users/masaki/projects/myapp/local.db"
]
}
}
}この構成で特に便利なのは、「この記事のスラッグが DB に入っているか確認して、もし未登録なら content/ フォルダのどのカテゴリに置くべきか提案して」のような複合的な作業を一度の指示で完結できることです。これを手動でやると 3〜4 ステップかかる作業が、会話 1 往復で済みます。
次のステップ
まずは filesystem サーバー 1 つだけで試してみてください。許可パスをプロジェクトフォルダ 1 つに絞り、Claude に「このプロジェクトの構造を把握して、改善できそうな点を教えて」と依頼してみます。サーバーの有無でどれほど回答の質が変わるか、すぐに実感できるはずです。
MCP は仕様として成熟しつつあり、サードパーティのサーバーも広がりつつあります。公式レジストリ（MCP Servers Registry）をときどき眺めておくと、思わぬツールが見つかることがあります。