コーディング AI で最初に入れるべき MCP サーバー 5 選【Claude Code・Codex・Gemini CLI 共通】

全般 公開:

Claude Code、Codex、Gemini CLI に共通して効果が高い MCP サーバーを 5 つ厳選し、それぞれの用途、導入コマンド、注意点を解説します。入れすぎによるコンテキスト消費を避ける考え方も紹介します。

検証日 2026年9月7日 仕様変更が早い分野です。最新の公式ドキュメントも併せてご確認ください。
目次
  1. 選定の基準
  2. 1. Playwright:ブラウザを操作して画面を確認する
  3. 2. Context7:ライブラリの最新ドキュメントを参照する
  4. 3. GitHub:Issue と PR を読み書きする
  5. 4. Filesystem:作業ディレクトリ外のファイルを安全に読ませる
  6. 5. Sequential Thinking:複雑な問題を段階的に考えさせる
  7. 入れすぎに注意する
  8. ツールごとの設定方法
  9. まとめ

MCP サーバーは何百種類も公開されていますが、コーディングエージェントの日常作業で「入れて効果を実感できる」ものは限られます。この記事では、Claude Code・Codex・Gemini CLI のどれでも使え、導入直後から役に立つサーバーを 5 つに絞って紹介します。

KEY POINT

この記事で分かること

  • 最初に入れる価値がある 5 つの MCP サーバーと、それぞれの用途
  • 3 ツール共通の導入方法と注意点
  • 入れすぎを避ける考え方

選定の基準

  • AI が自力では得られない情報を提供する(実際のブラウザ表示、最新のライブラリドキュメント)
  • 公式または広く使われているものである(保守が続いている)
  • 読み取り中心で事故が起きにくい(書き込み系は許可設定で絞れる)

1. Playwright:ブラウザを操作して画面を確認する

Web アプリの開発で最も効果が大きいサーバーです。AI が開発サーバーの画面を開き、スクリーンショットを撮り、ボタンを押し、表示内容を読み取れます。「実装したけど画面で確認していない」という状態がなくなります。

# Claude Code
claude mcp add playwright -- npx @playwright/mcp@latest
# Codex (~/.codex/config.toml)
[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]
// Gemini CLI (.gemini/settings.json)
{ "mcpServers": { "playwright": { "command": "npx", "args": ["@playwright/mcp@latest"] } } }

使い方の例:「開発サーバーを起動して、/login を開き、空のフォームで送信したときのエラー表示を確認して」

ブラウザは実際に動く

Playwright は本物のブラウザを操作します。本番環境の URL やログイン済みのセッションを扱わせないよう、開発環境の URL に限定してください。

2. Context7:ライブラリの最新ドキュメントを参照する

AI の学習データにない新しいバージョンのライブラリ、あるいは頻繁に API が変わるライブラリを使うときに、公式ドキュメントの該当部分を取得して読ませられます。「古い書き方でコードを書かれる」問題への対策です。

claude mcp add --scope user context7 -- npx -y @upstash/context7-mcp

使い方の例:「Context7 で Prisma の最新ドキュメントを確認してから、複合ユニーク制約を追加して」

読み取り専用なので、自動許可にしても安全です。

3. GitHub:Issue と PR を読み書きする

Issue の内容を読んで修正方針を立てる、PR の差分とレビューコメントを読む、といった用途です。gh コマンドが使える環境ならそれで代替できますが、コマンド実行を許可したくない環境や、Codex のサンドボックスでネットワークを制限している場合に MCP サーバーが役に立ちます。

claude mcp add github -e GITHUB_PERSONAL_ACCESS_TOKEN=${GITHUB_TOKEN} -- npx -y @modelcontextprotocol/server-github

トークンは環境変数から渡し、設定ファイルに直接書かないでください。Issue や PR を作成するツールは確認(ask)に残し、読み取りだけ自動許可にする運用を勧めます。

用語解説

公式 GitHub MCP サーバー: GitHub 自身がリモート(HTTP)方式の MCP サーバーを提供しています。ローカルで npm パッケージを動かす代わりに、URL を指定して接続し、ブラウザで認証する方式です。対応状況は各ツールのドキュメントで確認してください。

4. Filesystem:作業ディレクトリ外のファイルを安全に読ませる

コーディングエージェントは通常、作業ディレクトリ内のファイルしか扱いません。別リポジトリの実装を参考にさせたい、共有のドキュメントフォルダを読ませたい、という場合に、許可したディレクトリだけを公開できます。

claude mcp add docs-fs -- npx -y @modelcontextprotocol/server-filesystem /Users/me/shared-docs

引数で指定したディレクトリの外にはアクセスできないため、「読ませたい範囲を限定する」用途に向いています。

5. Sequential Thinking:複雑な問題を段階的に考えさせる

外部データではなく「考え方」を提供するサーバーです。設計判断や難しいデバッグで、問題を分解して段階的に検討する手順を AI に踏ませます。モデル自体の推論機能が強化されている現在、効果はモデルとタスクによりますが、軽量で副作用がないため試す価値はあります。

claude mcp add sequential-thinking -- npx -y @modelcontextprotocol/server-sequential-thinking

入れすぎに注意する

接続したサーバーのツール定義は、使わなくてもすべてのリクエストでコンテキストを消費します。10 個以上のサーバーを常時接続すると、それだけで数千〜数万トークンを毎回送ることになります。

  • プロジェクトで常用するものだけ project スコープ(チーム共有)に入れる
  • たまに使うものは local / user スコープに入れ、不要になったら外す
  • Claude Code なら /context でツール定義の占有量を確認できる(コンテキスト管理)

ツールごとの設定方法

導入コマンドと設定ファイルの詳細は、それぞれの記事を参照してください。

まとめ

  • 最初の 1 つは Playwright(画面確認)か Context7(最新ドキュメント)。効果を実感しやすい
  • GitHub は読み取りを自動許可、書き込みは確認に残す。トークンは環境変数から渡す
  • Filesystem は「読ませる範囲を限定する」用途、Sequential Thinking は副作用なしで試せる
  • 使わないサーバーはコンテキストを消費するだけなので、2〜3 個から始めて必要に応じて増やす

よくある質問

MCP サーバーはたくさん入れた方がよいですか?
逆です。接続したサーバーのツール定義は使わなくてもコンテキストを消費します。実際に使う 2〜3 個から始め、必要になったら追加してください。
3 つのツールで同じ MCP サーバーを使えますか?
使えます。起動コマンドと引数は共通で、設定ファイルの形式(JSON / TOML)だけが異なります。
GitHub の MCP サーバーと gh コマンドはどちらを使うべきですか?
gh コマンドが入っていれば、多くの操作はそれで足ります。MCP サーバーは、コマンドの実行を許可したくない環境や、構造化された結果を扱いたいときに有効です。

参考にした一次情報

この記事は公式ドキュメントを基に AI が下書きを作成し、運営者が内容を確認して公開しています。誤りを見つけた場合はお問い合わせからお知らせください。