Claude CodeのMCPとは？外部ツール連携でできることと追加方法の基本

この記事の結論

MCP（Model Context Protocol）は、Claude CodeをGitHubやSlack、データベースといった外部ツールにつなぐための共通規格で、AIと外部ツールの世界におけるUSB端子のような役割を果たします。対応サーバーを追加すれば、Issueの確認・作成やメッセージ検索、データ参照などをClaude Codeから直接行え、手作業のコピー&ペーストを大きく減らせます。追加はclaude mcp addコマンドで行い、local・project・userのスコープを使い分けますが、信頼できるサーバーだけを追加し、認証情報を厳重に扱うといったセキュリティ配慮が欠かせません。

生徒

Claude Codeで『MCP』って単語をよく見るんですけど、これ何ですか？なんだか難しそうで避けてました…。

ペン博士

MCPは、Claude Codeを外部ツールにつなぐ“共通プラグ”みたいなものだよ。GitHubやSlack、データベースに直接アクセスさせられる。何ができるか、追加方法、注意点を、基本からじっくりやさしく紹介するね！

Claude Codeをさらに強力にするのがMCP（Model Context Protocol）です。Claude Codeを、GitHubやSlack、データベースといった外部ツールに直接つなぐための共通の仕組みで、これを使うとAIが扱える情報と操作の幅が一気に広がります。

「コードは書けるけれど、毎回ファイルをコピーして貼り付けるのが面倒」「IssueやSlackの内容をいちいち手で説明している」——そんな手間を、MCPは大きく減らしてくれます。Claude Code自身が外部ツールへアクセスし、必要な情報を取りに行ったり、操作を実行したりできるようになるからです。

この記事では、MCPの仕組み・できること・追加方法・スコープの使い分け・代表的なサーバー例・セキュリティ注意点・トラブル対処・FAQまでを、はじめての方でも順を追って理解できるように、ひとつずつ丁寧に解説します。読み終えるころには、自分の環境に合わせて安全にMCPを導入できる状態を目指します。

MCPとは（Model Context Protocol）

MCPは、AIと外部ツールをつなぐための共通規格です。正式名称は「Model Context Protocol」。Anthropicが提唱したオープンな仕様で、AIアシスタント（ここではClaude Code）と、外部のデータソースやツールの間でやり取りするための“共通言語”を定めています。

なぜ「共通規格」であることが重要なのか

外部ツールはそれぞれ独自の接続方法（API）を持っています。GitHubにはGitHubの、SlackにはSlackの作法があり、本来ならツールごとに別々の連携コードを書く必要があります。これは数が増えるほど大変で、保守も難しくなります。

MCPは、この“バラバラな接続方法”を一つの作法にまとめる役割を持ちます。MCPに対応していれば、どのツールでも同じ枠組みで連携できるため、ツールごとの違いを意識せずに済みます。いわば、いろいろな機器を挿せる“共通プラグ”や、世界中で使える“共通コンセント”のような存在です。

もう少し身近にたとえると、USBの規格に似ています。USBという共通の差し込み口があるおかげで、マウスでもキーボードでもプリンタでも、同じ端子で接続できます。MCPは、AIと外部ツールの世界における“USB端子”のようなものだと考えると分かりやすいでしょう。

MCPの登場人物：ホスト・クライアント・サーバー

MCPの仕組みを理解するうえで、登場する3つの役割を押さえておくと全体像がつかみやすくなります。

ユーザーから見ると意識するのは「Claude Code（ホスト）」と「追加するMCPサーバー」の2つで十分です。MCPサーバーを追加すると、そのサーバーが提供する機能（ツール）をClaude Codeから呼び出せるようになる、という関係を覚えておきましょう。

MCPサーバーが提供する3つの要素

MCPサーバーは、おもに次のような要素をClaude Codeに提供します。すべてのサーバーが全部を備えているわけではなく、サーバーごとに提供する内容は異なります。

• ツール（Tools）：実際に処理を実行する機能。たとえば「Issueを作成する」「クエリを実行する」など、AIが呼び出して動作させるアクション。
• リソース（Resources）：参照できるデータ。ファイルの内容やドキュメントなど、AIが読み取って文脈に使える情報。
• プロンプト（Prompts）：あらかじめ用意された定型の指示テンプレート。よく使う操作を呼び出しやすくする。

つまりMCPは、「AIが使える道具（ツール）」と「AIが読める資料（リソース）」を外部から追加する仕組みだとイメージすると理解しやすいです。

MCPが解決する「N×Mの組み合わせ問題」

少しだけ仕組みの背景に触れておきます。MCPが生まれた理由を知ると、「なぜ共通規格なのか」がより腑に落ちます。

もしMCPのような共通規格がなければ、AIアプリの数 × ツールの数だけ、個別の連携をそれぞれ作る必要があります。AIアプリがN個、つなぎたいツールがM個あれば、最悪でN×M通りの連携を一つひとつ実装することになります。これは作る側にとっても、使う側にとっても大きな負担です。

MCPは、この「N×Mの組み合わせ問題」を「N＋M」に近づけます。各AIアプリがMCPに対応し、各ツールがMCPサーバーを用意すれば、あいだは共通の作法でつながるからです。新しいツールが増えても、MCPサーバーを一つ用意すれば、MCP対応のさまざまなAIアプリから使えるようになります。

この「一度作れば、いろいろなところで使える」という性質が、MCPが共通規格として広がっている理由です。

MCPと、ただのAPIの違い

「外部ツールにつなぐなら、普通のAPIでもいいのでは？」と思うかもしれません。違いは、MCPはAIが扱いやすい形に標準化されている点にあります。

APIそのものが不要になるわけではありません。MCPサーバーは、内部では各ツールのAPIを呼び出していることが多いです。MCPは、その手前に「AIが共通の作法で使える窓口」を一枚かぶせる役割だと考えると分かりやすいでしょう。

MCPでできること

対応サーバーを追加すると、Claude Codeから次のような操作ができるようになります。ここでは代表的な活用例を、具体的なシーンとあわせて紹介します。

• GitHub連携：Issueやプルリクエストの確認・操作。
• Slack連携：メッセージの検索・投稿。
• データベース連携：データの参照やクエリの実行。
• デザインツール連携：Figmaのデザイン情報の取得。
• ドキュメント連携：Notionなどのナレッジへのアクセス。

具体例①：GitHubと連携して開発を加速する

GitHub向けのMCPサーバーを追加すると、Claude Codeから直接リポジトリの情報を扱えるようになります。たとえば次のような会話が成立します。

• 「今オープンになっているIssueを一覧で見せて」と頼むと、Claude CodeがIssueを取得して要約する。
• 「このバグのIssueに対応するコードを直して、内容をプルリクの説明文にまとめて」と一気通貫で依頼できる。
• プルリクエストの差分を読み込ませ、レビュー観点のコメント案を出させる。

「Issueの内容を手でコピーして貼り付ける」という手間がなくなるのが大きな利点です。AIが自分でリポジトリの状態を確認できるため、文脈を共有する手間が減り、作業がスムーズになります。

具体例②：Slackと連携してやり取りを取り込む

Slack向けのMCPサーバーを使うと、チャンネルのメッセージ検索や投稿が可能になります。

• 「#dev チャンネルで先週話題になった不具合の経緯をまとめて」と依頼し、議論の流れを整理させる。
• 作業が完了したら、指定チャンネルへ完了報告を投稿させる。

チームのやり取りがSlackに集まっている場合、会話の文脈をAIに取り込ませやすくなるため、調査や報告の自動化に役立ちます。

具体例③：データベースと連携して状態を確認する

データベース向けのMCPサーバーを追加すると、データの参照やクエリの実行ができるようになります。

• 「ユーザーテーブルの件数と、直近の登録傾向を教えて」とデータの確認を依頼する。
• アプリの不具合調査時に、該当レコードの状態をその場で確認する。

ただしデータベース連携は影響が大きいため、まずは参照（読み取り）中心の権限から始めるのが安全です。更新や削除を許す場合は、後述するセキュリティの注意点を必ず守りましょう。

具体例④：デザイン・ドキュメントと連携する

Figma向けのサーバーでデザイン情報を取得すれば、デザインの仕様をもとにコードを書かせるといった連携ができます。Notionなどのドキュメント向けサーバーを使えば、社内ナレッジや仕様書を参照させながら作業を進められます。

いずれも共通しているのは、「人が手で情報を運ぶ」工程をAIが肩代わりするという点です。情報の置き場所とAIを直接つなぐことで、コピー＆ペーストのような単純作業が減っていきます。

具体例⑤：複数ツールをまたいだ作業をひとつながりにする

MCPの本当の威力は、複数のツールを一度の依頼の中で横断できるところにあります。たとえば次のような一連の流れを、人が手で各ツールを行き来せずに進められます。

1. Slackで報告された不具合の内容を読み取る。
2. 対応するGitHubのIssueを確認し、関連コードを調べる。
3. 修正案をまとめ、プルリクエストの説明文として整える。
4. 完了したらSlackの該当チャンネルに報告を投稿する。

これらを別々のツールで手作業すると、画面の行き来とコピペが何度も発生します。MCPで連携しておけば、「Slackの不具合をGitHubで直して報告まで」と一息で頼めるため、作業の分断が大きく減ります。

追加方法：claude mcp add の基本

MCPサーバーの追加は、基本的に claude mcp add コマンドで行います。まずは現在の状態を確認し、必要なサーバーを追加し、接続状態を見る、という流れが基本です。

# 登録済みのMCPサーバー一覧を確認
claude mcp list

# サーバーを追加（例：HTTP接続のサーバー）
claude mcp add --transport http <name> <url>

# 追加後は /mcp で接続状態や認証を管理

ここで <name> は自分でつける分かりやすい名前、<url> は接続先のサーバーURLです。追加後、Claude Codeの対話中に /mcp と入力すると、接続状態の確認や、必要な認証（ログイン）の操作ができます。

コマンドの基本的な流れ

1. 確認：claude mcp list で、いま何が登録されているかを見る。
2. 追加：claude mcp add でサーバーを登録する。
3. 認証：必要なら /mcp から認証を済ませる。
4. 利用：Claude Codeに「〜して」と頼むと、追加したツールが使われる。

transport（接続方式）の種類

MCPサーバーへの接続方式は「transport（トランスポート）」と呼ばれ、いくつかの種類があります。追加するサーバーがどの方式に対応しているかによって、コマンドの指定が変わります。配布元のドキュメントに従って選びましょう。

どれを使うかは、「ローカルで動かすか、リモートに接続するか」と「配布元が指定する方式」で決まります。多くの場合、サーバーの公式ドキュメントに追加コマンドの例が載っているので、それをそのまま使うのが確実です。

登録したサーバーを管理する

追加したサーバーは、後から確認・整理できます。基本となるのは一覧表示と接続管理の2つです。

• 一覧で確認：claude mcp list で、いま登録されているサーバーを見渡せる。
• 接続を管理：対話中の /mcp で、接続状態や認証の状況を確認できる。
• 使わないものは整理：不要になったサーバーは登録したままにせず、整理しておくと管理が楽になる。

特に複数のサーバーを使い始めると、どれが何のためのサーバーかが分かりづらくなりがちです。追加するときの名前（<name>）は、後から見て用途が分かるものにしておくと管理しやすくなります。

ローカル型とリモート型の違い

MCPサーバーは大きく分けて2種類あります。それぞれ長所と注意点が異なるため、目的に合わせて選びます。

• ローカル型（stdioなど）：自分のマシン上でサーバーのプログラムを起動して使う。手元の環境やファイルにアクセスしやすい一方、各自で実行環境を用意する必要がある。
• リモート型（http／sseなど）：すでに公開・運用されているサーバーに接続して使う。環境構築が不要なことが多いが、接続先を信頼できるかの確認がより重要になる。

スコープの使い分け：local・project・user

MCPサーバーの設定を「どこに保存するか」はスコープで選びます。チームで共有したいか、自分だけで使うか、全プロジェクトで使い回したいかによって使い分けます。これはMCPを実務で使ううえで最も大切な考え方のひとつです。

local スコープ：その場かぎりで試したいとき

localスコープは、自分だけ・そのプロジェクトの中だけで使う設定です。個人設定として保存され、他の人やほかのプロジェクトには影響しません。「まずこのサーバーを試してみたい」というときの第一候補になります。

project スコープ：チーム全員で共有したいとき

projectスコープは、リポジトリ内の .mcp.json という設定ファイルに保存されます。このファイルをGitで共有すれば、チーム全員が同じMCP構成を使えるようになります。新しくプロジェクトに参加したメンバーも、リポジトリを取得するだけで同じ連携環境を整えられるのが大きな利点です。

「このプロジェクトでは、このサーバーをみんなで使う」と決まっているものは、projectスコープにしておくと導入の手間が減ります。

user スコープ：自分の全プロジェクトで使いたいとき

userスコープは、自分のすべてのプロジェクトで共通して使える設定です。プロジェクトをまたいで「いつも使うサーバー」がある場合に向いています。個人設定として保存されるため、ほかの人には共有されません。

迷ったときの選び方

1. お試しで一時的に使う → local
2. チーム全員で同じ環境にしたい → project（.mcp.json をGitで共有）
3. 自分だけ・どのプロジェクトでも使う → user

最初はlocalで試し、「チームで標準化したい」と判断できたタイミングでprojectへ移すという進め方が、安全で分かりやすい流れです。

代表的なMCPサーバーの例と用途

MCPサーバーは多くの種類が公開されています。ここでは、よく名前が挙がる代表的な分類と用途を紹介します。具体的なサーバーごとの細かな仕様や手順は、必ず各サーバーの公式ドキュメントを確認してください（バージョンや提供形態によって挙動が変わるためです）。

どのサーバーから始めるか迷ったら、「いま自分が一番手作業でコピペしている情報源」を選ぶのがおすすめです。日々の手間が大きいものほど、連携した効果を実感しやすいからです。

最初の一つは「普段使うツール」から

いきなり多くのサーバーを追加すると、設定や認証の管理が複雑になり、トラブルの原因も切り分けづらくなります。まずは普段よく使うツールを一つだけ連携し、慣れてから増やしていくのが堅実です。

導入手順を段階的に（はじめての一台）

ここでは、はじめてMCPサーバーを追加するときの流れを、つまずきにくい順番で整理します。具体的なURLやサーバー名は、追加したいサーバーの公式ドキュメントに置き換えて読んでください。

ステップ1：追加したいサーバーを決める

まずは「何を連携したいか」を決めます。GitHubのIssueを扱いたいのか、Slackのやり取りを取り込みたいのか、目的を一つに絞ります。目的が一つだと、うまくいったかどうかの確認がしやすいためです。

ステップ2：公式ドキュメントで追加方法を確認する

サーバーごとに、transportの種類（stdio／http／sse）や、必要な認証情報が異なります。配布元の公式ドキュメントで、推奨される claude mcp add の書き方を確認しましょう。多くの場合、コピーして使えるコマンド例が用意されています。

ステップ3：スコープを決めて追加する

最初はお試しのため、localスコープで追加するのが無難です。たとえばHTTP接続のサーバーなら、次のような形になります（<name> と <url> は実際の値に置き換えます）。

# まずは確認
claude mcp list

# localスコープでHTTP接続のサーバーを追加
claude mcp add --transport http <name> <url>

追加が終わったら、もう一度 claude mcp list で、ちゃんと登録されたかを確認します。

ステップ4：接続状態と認証を確認する

Claude Codeの対話中に /mcp と入力し、接続状態（つながっているか）と、認証が必要かどうかを確認します。認証が必要なサーバーの場合は、ここから案内に従ってログイン操作を行います。

ステップ5：小さな操作で動作を確かめる

いきなり大きな作業を任せず、まずは「一覧を見せて」など影響の小さい操作で試します。期待どおりに情報が取れたら、連携は成功です。問題があれば、後述のトラブル対処を参照してください。

ステップ6：必要に応じてチーム共有へ

個人で問題なく使えることを確認できたら、チームで標準化したいものはprojectスコープへ移し、.mcp.json をGitで共有します。これで、メンバー全員が同じ連携環境をすぐに使えるようになります。

セキュリティの注意点（外部とつなぐからこそ大切）

MCPは便利な反面、Claude Codeを外部のツールやデータにつなぐ仕組みです。だからこそ、安全面への配慮が欠かせません。ここは特に丁寧に確認しておきましょう。

信頼できるサーバーだけを追加する

MCPサーバーは、Claude Codeに対してツールやデータへのアクセスを提供します。つまり、出どころの不明なサーバーを追加することは、知らない相手に作業環境への入り口を渡すのと同じです。

• 配布元を確認：公式・公的に信頼されている提供元かを確かめる。
• 不明なサーバーは追加しない：出どころが分からないものは接続しない。
• 必要なものだけ：使う予定のないサーバーは追加したままにしない。

認証情報（APIキー・トークン）は厳重に扱う

外部ツールへの接続には、APIキーやアクセストークンといった認証情報が必要になることがあります。これらは漏れると不正アクセスにつながる極めて重要な情報です。

• 設定ファイルに直書きしない：キーやトークンをそのままファイルに書き込まない。環境変数など、安全な方法で渡す。
• リポジトリに含めない：.mcp.json をGitで共有する場合は特に注意。認証情報がコミットされないようにする。
• 最小限の権限で：可能なら、読み取りだけなど必要最小限の権限を持つキーを使う。
• 漏れたら即無効化：万一外部に出てしまったキーは、すぐに無効化・再発行する。

.mcp.json をチームで共有するときの注意

projectスコープは導入を楽にしてくれますが、共有するファイルに認証情報が混ざらないよう注意が必要です。「接続先の設定」と「秘密の認証情報」は分けて管理するのが原則です。認証情報は各自の環境変数などで渡し、リポジトリには含めない運用にしましょう。

権限の与えすぎに注意する

特にデータベースのように、操作の影響が大きい連携では、最初から書き込みや削除まで許可するのは危険です。まずは参照中心の権限から始め、必要になってから段階的に広げるという考え方が安全です。

うまくいかないときのトラブル対処

MCPの連携でつまずいたときは、いきなり全部を疑うのではなく、「登録 → 接続 → 認証 → 実行」の順に一つずつ切り分けるのがコツです。

まず登録状態を確認する

claude mcp list で、目的のサーバーがそもそも登録されているかを確認します。一覧に出てこない場合は、追加コマンドが正しく実行できていない可能性があります。

接続状態を /mcp で確認する

Claude Codeの対話中に /mcp を実行し、サーバーがつながっているか、認証待ちになっていないかを確認します。接続できていない場合は、URLやtransportの指定が正しいか、サーバー側が起動しているかを見直します。

一度に変えすぎない

設定を一気に変更すると、何が原因か分からなくなります。変更は一つずつ行い、そのつど動作を確認することで、原因の切り分けがぐっと楽になります。

豆知識・運用のコツ

最後に、日々MCPを使ううえで役立つ小さな知恵をまとめます。

• 最初の一つは普段使うツールから：手作業のコピペが多いツールほど、連携の効果を実感しやすい。
• スコープを意識して整理する：お試しはlocal、チーム標準はproject、自分の定番はuser。
• チーム共有は .mcp.json で：projectスコープにすると、Gitで設定を配れて導入が楽になる。
• 認証情報は分けて管理：共有ファイルに秘密情報を混ぜない。
• 接続は /mcp で見える化：困ったらまず接続状態と認証を確認する。

MCPは「一度きりの設定」ではなく、チームの運用ルールとセットで育てていくものです。誰が・どのサーバーを・どのスコープで使うかを揃えておくと、後から参加するメンバーも迷いません。

MCP導入前と導入後の違い

MCPを入れると日々の作業がどう変わるのか、典型的な場面で比べてみます。

差は一つひとつは小さく見えますが、「画面を行き来してコピペする」回数が積み重なるほど、連携の効果は大きくなります。

運用を安定させるチェックリスト

1. 追加するサーバーは信頼できるかを、配布元で確認した。
2. スコープ（local／project／user）を目的に合わせて選んだ。
3. 認証情報を設定ファイルに直書きしていないことを確認した。
4. チーム共有なら .mcp.json に秘密情報が混ざっていないことを確認した。
5. まず小さな操作で動作確認をしてから本格利用に移した。
6. 使わないサーバーは追加したままにしていない。

導入のたびにこのチェックを一巡しておくと、便利さと安全性のバランスを保ちやすくなります。

よくある質問（FAQ）

Q. MCPを使うには、難しいプログラミングが必要ですか？

いいえ、基本的な利用には複雑なコードは不要です。用意されたMCPサーバーを claude mcp add で追加し、/mcp で接続を確認するという流れが中心です。多くのサーバーは公式ドキュメントにコピーして使えるコマンド例を載せているため、それに従えば始められます。

Q. local・project・user の違いがまだ曖昧です。どう選べばいい？

迷ったら次の基準で十分です。お試しはlocal、チーム全員で同じにしたいならproject（.mcp.json をGitで共有）、自分のどのプロジェクトでも使うならuser。最初はlocalで試し、標準化したくなったらprojectへ移すのが分かりやすい進め方です。

Q. transport（stdio／http／sse）はどれを選べばいいですか？

基本は追加したいサーバーの公式ドキュメントが指定する方式に従ってください。ざっくりとは、手元で動かすローカル型はstdio、Web上のリモート型はhttpやsseが使われることが多い、という目安があります。配布元のコマンド例どおりに指定するのが確実です。

Q. どのMCPサーバーから始めるのがおすすめですか？

「いま一番、手作業で情報をコピペしているツール」から始めるのがおすすめです。効果を実感しやすく、続けるモチベーションにもつながります。最初は一つだけにして、慣れてから増やしましょう。

Q. セキュリティが心配です。気をつける点は？

大きく2つです。信頼できるサーバーだけを追加することと、APIキー・トークンなどの認証情報を厳重に扱うこと。認証情報は設定ファイルに直書きせず、リポジトリにも含めないようにします。データベースなど影響の大きい連携は、参照中心の権限から始めると安全です。

Q. 追加したサーバーがうまく動きません。どこを見ればいい？

「登録 → 接続 → 認証 → 実行」の順に切り分けます。まず claude mcp list で登録を確認し、次に /mcp で接続状態と認証を確認します。変更は一つずつ行い、そのたびに動作を確かめると原因を特定しやすくなります。

用語集（この記事に出てきた言葉）

まとめ

MCPは、Claude Codeを外部ツールにつなぐ共通規格です。claude mcp add でサーバーを追加し、スコープ（local／project／user）でチーム共有か個人利用かを選べば、GitHubやSlack、データベースなどをAIから直接扱えるようになります。

大切なのは、普段よく使うツールを一つだけ連携してみることから始め、慣れたら少しずつ増やすことです。そして外部とつなぐ仕組みだからこそ、信頼できるサーバーだけを追加し、認証情報を厳重に扱うという基本を守りましょう。

・正体：AIと外部ツールをつなぐ共通の仕組み
・追加：claude mcp add ＋ スコープ選択（local／project／user）
・注意：信頼できるサーバーだけ・認証情報は厳重に

連携を使いこなすほど、APIやセキュリティの基礎理解が効いてきます。WithCodeで体系的に学べば、MCPの活用も一段深くなります。

関連記事

• AI時代の働き方｜フリーランスが「使われる側」から「使う側」になるための極意を徹底解説
• OWASP Top 10 for LLM Applications 解説｜生成AIアプリの代表的リスクと対策
• Google Gemini 公式情報まとめ｜モデル・できること・料金をやさしく解説
• Claude公式ドキュメントで見るモデル仕様と料金｜業務活用の基礎ガイド
• OpenAI公式で学ぶモデル・料金・利用規約｜ChatGPT/API活用の基礎

参考リンク（公式・一次情報）

• MDN Web Docs — HTML
• MDN Web Docs — CSS
• Git 公式ドキュメント
• Figma 公式ヘルプ

WithCodeを体験できる初級コース公開中！

初級コース(¥49,800)が完全無料に！

• 期間：1週間
• 学習内容：
  ロードマップ/基礎知識/環境構築/HTML/CSS/LP・ポートフォリオ作成
  → 正しい学習方法で「確かな成長」を実感できるカリキュラム。

副業・フリーランスが主流になっている今こそ、自らのスキルで稼げる人材を目指してみませんか？

未経験でも心配することはありません。初級コースを受講される方の大多数はプログラミング未経験です。まずは無料カウンセリングで、悩みや不安をお聞かせください！