MCP(Model Context Protocol)は、AIアシスタントと外部のツールやデータを繋ぐための共通規格です。
2024年11月にAnthropicが公開したオープンな仕様で、Claude Codeだけでなく、ChatGPT・Cursor・VS Code(GitHub Copilot)など主要なAIコーディングツールの多くが対応しています。
GitHubの操作やブラウザ操作、Web検索など、AI単体ではできない作業を「MCPサーバー」経由でできるようにする仕組みです(参照: Anthropic公式発表)。
仕組みをたとえるなら、Claude Codeが「本体」、MCPサーバーは後から挿す「拡張パーツ」のようなものです。
GitHub用のMCPサーバーを挿せばGitHubの操作ができるようになり、Playwright用のMCPサーバーを挿せばブラウザ操作ができるようになる、というイメージです。
普段は仕組みを意識しなくても使えますが、知っておくと、後述するトークン消費やセキュリティの話も理解しやすくなります。
筆者はGit/GitHub、Playwright、Tavily、Context7など12個のMCPサーバーを日常的に接続して作業しています。
この記事では、それぞれのMCPが何をするものか、どれが役立っているか、トークン消費は実測でどれくらい増えるのか、そして情報漏洩の不安とどう折り合いをつけているかをまとめました。
まず結論
- 筆者の運用では、毎回使うのはGit/GitHub系とPlaywright系。
TavilyやContext7は常時接続しているが、出番はタスクの性質次第。 - Claude Codeには「Tool Search」という遅延ロードの仕組みが標準搭載されており、MCPを繋いでもトークン消費は大きくは増えない(実測データは②で紹介)。
- 情報漏洩への不安はゼロではないが、仕組みを理解した上で、筆者は気にしすぎずに使っている。
以下、順番に解説します。
①実際に使っているMCPの特徴と使用感
Git/GitHub MCP
Git/GitHub MCPは、GitHubが公式に公開しているMCPサーバー(github/github-mcp-server)で、Claude CodeにGitHub上の操作をツールとして追加します(参照: GitHub公式リポジトリ)。
リポジトリのコード検索・閲覧、Issue・プルリクエストの作成や管理、コミット履歴の確認、GitHub Actionsのワークフロー監視など、GitHub上で行う一通りの作業を自然言語の指示でこなせるようになります。
Gitはファイルの変更履歴を記録し、必要に応じて過去の状態に戻したり、複数人で同時に作業したりできるバージョン管理システムです。add／commit／push／branch／mergeといった独特のコマンド体系があり、非エンジニアやGit初心者にとってはハードルになりがちです。
Git/GitHub MCPを使うと、こうしたコマンドを直接打つ代わりに、「変更をコミットして」「プルリクエストを作って」といった自然言語の指示でGit操作をAIに任せられます。
筆者の場合、Time Machineやクラウド・HDDへのバックアップで足りると考えていました。
それに加えて、プロジェクトごとにGitで管理するという発想自体が頭になく、コマンド操作も複雑に見えて敬遠していました。
Git/GitHub MCPを導入してからは、基本的な用語さえ分かればあとの操作をAIに任せられるようになり、日常的に使うようになりました。
AIとGitの組み合わせは、特にGit未経験者にとって相性が良いと感じています。
Playwright MCP
Playwright MCPは、Microsoftが公開している公式のMCPサーバーで、ブラウザ操作を自動化するPlaywrightというフレームワークをベースにしています(参照: GitHub: microsoft/playwright-mcp)。
Chrome・Firefox・WebKit・Edgeに対応し、ページの内容をスクリーンショット(画像)ではなく「アクセシビリティツリー」という構造化データとして取得するため、画像ベースの方式より高速かつ低コストという特徴があります。
実運用では、コードを書くだけでなく、実際にブラウザでボタンを押して動作を確認したり、見た目をスクリーンショットで確認したりする作業まで、AI自身が完結できる点を活用しています。
TavilyとContext7
Tavilyは、AIエージェント向けに設計されたWeb検索・クロール・情報抽出のAPIサービスです。
自然言語での検索リクエストに対応し、検索結果を要約付きの構造化データで返します。
Context7は、ライブラリやフレームワークの最新かつバージョンに対応したドキュメント・コード例を取得できるMCPサーバーで、9,000以上のライブラリに対応しています(参照: GitHub: upstash/context7)。
AIの学習データが古いことによって「存在しないはずの関数を使ってしまう」といった誤りを減らす目的で使われます。
この2つは常時接続していますが、実際に使われるのは該当する作業のときだけで、Git/GitHub・Playwrightほど毎回出番があるわけではありません。
Git/GitHub・Playwrightは毎回使う主力級のMCP、Tavily・Context7は専門用途で待機しているMCP、という住み分けです。
この使用頻度の濃淡は、次に紹介するトークン消費の実測データとも関係しています。
②MCPはトークンを食うのか｜実測してみた
「MCPを繋ぐとトークンを大量に消費する」という話を聞いたことがある方も多いと思います。
これは半分正解で、半分は既に過去の話になっています。
Claude Code 2.1.221(執筆時点の最新は2.1.233で、これよりやや古いバージョンでの測定です。バージョンが変わると数値が変動する可能性があります)で、以下のコマンドを実行した際の入力トークン合計を、MCP構成別に比較しました。
claude -p "hi" --model haiku
| 構成 | 遅延ロード (現行デフォルト) | 一括読み込み (旧方式) |
|---|---|---|
| MCPなし (基準) | 29,582 | 42,798 |
| Playwright単体 (24ツール) | +244 | +4,580 |
| Playwright+Context7 (26ツール) | +462 | +6,529 |
| 実運用構成 (12サーバー・81ツール) | +2,003 | +72,562 |
※旧方式の実運用構成「+72,562」には組み込みツール側のスキーマ増加分(約13,216、単体実験の基準差から推定)を含みます。
MCP純粋分は約59,000です。
この差を生んでいるのが、Claude Codeの「Tool Search」という仕組みです。
公式ドキュメント(Scale with MCP tool search)によれば、Tool Searchはデフォルトで有効になっており、起動時にはツール名とサーバーの説明文だけを読み込み、実際にそのツールを使う場面になって初めて詳細なスキーマを読み込みます。
旧方式に戻したい場合は環境変数 ENABLE_TOOL_SEARCH=false、コンテキストの使用量が10%を超えたら自動的に切り替えたい場合は auto を指定できます。
つまり「MCPはトークンを食う」というのは、この遅延ロードが導入される前の旧方式の話であり、現行のデフォルト設定ではほぼ解決済みの問題です。
12サーバー・81ツールを繋いでいても、増加分は基準の1%程度に収まります。
③情報漏洩のリスクとどう向き合っているか
トークン消費の不安は実測データで解消できましたが、もう一つの不安である「情報漏洩」については、実測で白黒つけられる話ではありません。
ここから先は、筆者の運用上の考え方として書きます。
MCPは便利だが、意図しない情報が外部に送られていないか、という心配はゼロではありません。
ただし、その心配を理由に使うのをやめることはなく、気にしすぎずに使っています。
案件やプロジェクトごとにMCPの接続を絞る、といった対策も特にしていません。
ただし一つだけ、実際に運用していて気をつけるようになったことがあります。
それはMCP側の問題というより、AIエージェント自身のミスです。
作業を進めている途中で、パスワードや認証情報が入ったファイルをAIがうっかり開いてしまい、画面にそのまま平文で表示してしまう、ということが実際に起きました。
一度表示されてしまった認証情報はログや履歴に残ってしまうため、取り消しがきかず、結局パスワードを変更する羽目になります。
MCPという仕組みそのものが外部に情報を漏らすというより、AIが「このファイルは今回のタスクに本当に必要か」を確認せずに開いてしまう、という凡ミスの方が実害は大きいと考えています。
この経験から、今では「機密ファイルを開く前に、そのタスクで本当に必要かを先に確定させる」「APIキーなどの認証情報はプロジェクトディレクトリに直接置かず、macOSのKeychainで管理する」というルールを運用に組み込んでいます。
MCPを安全に使うには、MCP自体を疑うことよりも、AIエージェントの挙動をどう制御するかの方が重要です。
筆者が気にしているのはトークン消費と情報漏洩の2点ですが、MCP全般については、セキュリティ専門機関から他にも一般的な懸念が指摘されています。
例えば、MCPサーバーには一元的に審査された公式リポジトリが存在しないため悪意のあるサーバーが紛れ込む可能性、最初は問題なかったサーバーが後のアップデートで悪意ある挙動に変わる「Rug pull」と呼ばれる手口、許可を何度も求められるうちに内容を確認せず承認してしまう「許可疲れ」などです(参照: Checkmarx: MCP Security Risks)。
導入元がはっきりしているMCPサーバー(公式リポジトリ、著名な開発元)を選ぶ、アップデート内容を都度確認する、といった基本的な用心は、筆者も心がけています。
④MCPとSkillsは何が違うのか
MCPと合わせてよく話題に上がるのが「Skills」です。
名前が並んで語られることが多いためか、「どちらを使えばいいのか」と混同されがちですが、役割はまったく異なります。
- MCP: Claude Codeの「外」にある道具やデータに繋ぐための仕組みです。
GitHub・Playwright・データベースなど、外部のツールやサービスを、Claude Codeが呼び出せる「ツール」として追加します。
いわば接続先を増やす仕組みです。 - Skills: Claude Code自身に「特定の作業の手順」を教え込む仕組みです。
よく使う作業の進め方をMarkdownファイルにまとめておき、必要な場面でClaudeがそれを読み込んで手順通りに動きます。
いわば振る舞い方を増やす仕組みです。
たとえるなら、MCPは「新しい工具を工具箱に追加すること」、Skillsは「その工具の使い方が書かれた作業手順書を用意すること」に近いイメージです。
両方を組み合わせることで、外部ツールに繋ぎつつ、決まった手順で正確に作業を進められるようになります。
SkillsとHooksの詳しい仕組みは、別記事「Claude CodeのSkillsとHooksを徹底解説」で解説しているので、そちらも参考にしてください。
まとめ
MCPは、Claude Codeに外部の機能を追加する「拡張パーツ」のような仕組みです。
実際に12サーバーを運用してみると、便利さも不安も、思い込みだけで判断すると実態とズレることが分かりました。
- 筆者の運用で毎回効いているのはGit/GitHub・Playwrightで、Tavily・Context7は専門用途で出番を待つ道具。
- 「MCPはトークンを食う」は旧方式の話で、現行のTool Search(遅延ロード)なら12サーバーでも増加は1%程度。
- 情報漏洩の不安に対してMCP側の対策は特にしていないが、気をつけるべきはAIエージェントが機密ファイルを不用意に開いてしまう凡ミスの方だった。
- サプライチェーンリスクや許可疲れなど、トークン・情報漏洩以外にも一般的に指摘されている懸念があり、導入元の分かるMCPサーバーを選ぶといった用心は引き続き必要。
「繋ぐと重い・怖い」というイメージだけでMCPを敬遠しているなら、まずは自分が使う場面を思い浮かべて、必要なMCPサーバーから少しずつ試してみることをおすすめします。
コメント