MCP（Model Context Protocol）は、AI に「外の世界」を触らせるための共通の差込口です。Slack を読む、社内データベースを検索する、GitHub の課題を更新する——そうしたツール連携を、AI ごと・ツールごとに作り直すのではなく、ひとつの規格でまとめる。「AI 版の USB-C」と呼ばれる理由はそこにあります。この記事では、MCP が何を解決するのか、用語、実際に試す手順、そして 2026 年に大きく変わった点までを、初めての人向けに具体的に整理します。
01MCP が解くのは「N×M の作り直し」問題
AI から外部ツールを使わせようとすると、従来は「AI の数 × ツールの数」だけ専用の繋ぎ込みが必要でした。Claude を Slack に繋ぐ実装、別の AI を Slack に繋ぐ実装、同じ AI を GitHub に繋ぐ実装……と、組み合わせの数だけ車輪を再発明していたわけです。
MCP の発想は単純です。ツール側に「MCP サーバー」を 1 つ用意すれば、MCP に対応した AI クライアントはどれも同じものを使える。Slack 用の MCP サーバーを作れば、Claude でも、ChatGPT でも、Cursor でも、同じサーバーを共有できます。N×M の掛け算が、N＋M の足し算になる——これが MCP の核心です。
FIG.1 組み合わせごとの専用実装（左）を、共通プロトコル 1 枚（右）に置き換える
02登場人物：クライアント・サーバー・3 つの機能
MCP には「AI 側」と「ツール側」という 2 つの役者がいます。呼び名を押さえると、設定ファイルもドキュメントも一気に読めるようになります。
| MCP クライアント（AI 側） | MCP サーバー（ツール側） |
|---|---|
| Claude Desktop / Claude Code、Cursor、VS Code、ChatGPT など | Slack、GitHub、PostgreSQL、社内 API などをラップした小さなプログラム |
| 使えるツール一覧を取得し、AI に呼ばせる | 実際の操作（読む・書く・検索する）を提供する |
サーバーが AI に渡せるものは、おおきく 3 種類に分かれます。この 3 つの区別が MCP 理解の土台です。
Resource（読む対象）
ファイル・テーブル・ドキュメントなど、AI が参照する読み取りデータ。
Tool（実行する関数）
投稿・検索・更新といった動作。副作用を伴うものはここ。
Prompt（定型の型）
再利用できるプロンプトテンプレート。よく使う依頼を部品化する。
ざっくり言えば、Resource は「見せる」、Tool は「やらせる」、Prompt は「型を渡す」。書き込みや外部送信を伴う操作はすべて Tool 側にある、と覚えておくと安全設計の議論がしやすくなります。
03つなぎ方は 2 通り：手元起動とリモート
MCP サーバーには、つなぎ方（トランスポート）が 2 系統あります。これは 2026 年時点で整理が進み、初学者がまず知るべき分岐点になりました。
| stdio（手元で起動） | Streamable HTTP（リモート） |
|---|---|
| 自分の PC でサーバーを子プロセスとして起動。ローカルファイルや手元の開発に向く | ネット越しの URL に接続。チームで共有する SaaS 連携に向く |
設定ファイルに command と args を書く | サーバーの URL を登録。認証は OAuth が主流 |
かつて使われていた HTTP+SSE 方式は廃止予定（deprecated）で、リモート接続は Streamable HTTP に一本化されつつあります。新しくリモートサーバーに繋ぐときは Streamable HTTP を前提にしておけば間違いありません。
FIG.2 手元で動かす stdio と、URL に繋ぐ Streamable HTTP（旧 SSE は廃止予定）
04Claude Desktop で最小構成を試す
いちばん手軽なのは、Claude Desktop に stdio 方式のサーバーを 1 つ足してみることです。手順は 3 ステップです。
設定ファイルを開く
Mac は ~/Library/Application Support/Claude/claude_desktop_config.json、Windows は %APPDATA%\Claude\claude_desktop_config.json。無ければ新規作成します。
サーバーを書き足す
下の例のように mcpServers に追記。npx -y で公式サーバーをその場で取得・起動できます。
Claude Desktop を再起動
「このディレクトリのファイルを一覧して」のように、自然文で頼めば対応するツールが呼ばれます。
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/dir"]
}
}
}
まずは filesystem のように読み取り中心で副作用の小さいサーバーから始めるのが安全です。書き込み系（メッセージ投稿、課題更新など）は、挙動を理解してから足しましょう。アクセス範囲は、上の例の /path/to/dir のように必要なディレクトリだけに絞るのが鉄則です。
05どんなサーバーがあるか（2026 年の実態）
公式のリファレンスサーバーは、学習・検証用に絞り込まれています。現在維持されている代表は次のとおりです。
- Filesystem：アクセス範囲を制御できるローカルファイル操作
- Git：ローカル Git リポジトリの読み取り・検索・操作
- Fetch：Web ページを取得して LLM 向けに変換
- Memory：知識グラフ型の永続メモリ
- Sequential Thinking：段階的な思考プロセスの補助
- Time：時刻・タイムゾーン変換
- Everything：Resource/Tool/Prompt を一通り試せる検証用サーバー
注意したいのは、初期に有名だった一部のサーバー（GitHub・Slack・PostgreSQL・ブラウザ操作など）は、公式リポジトリでは「アーカイブ済み」または提供元への移管が進んでいる点です。たとえば GitHub 連携は、現在はGitHub 社自身がメンテナンスする公式 MCP サーバー（リモート版を含む）を使うのが基本になりました。古い記事のパッケージ名をそのまま貼ると動かないことがあるので、導入時は各サービスの公式ドキュメントや MCP レジストリで最新の入手先を確認してください。
出回っている設定例は古いことがある。入手先は公式とレジストリで確認するのが今のお作法。
06MCP が得意なこと
標準化
一度書いた MCP サーバーを、複数の AI クライアントで使い回せる。
資格情報の隔離
API キーや権限はサーバー側に置き、AI には素のキーを直接渡さない設計にできる。
動的な発見
クライアントは接続時に「使えるツール一覧」を取得する。後から増やしても再配線不要。
もうひとつの利点は移行のしやすさです。AI クライアントを乗り換えても、MCP サーバー側の資産はそのまま再利用できます。特定ツールに縛られにくい、というのが MCP の地味だが効く長所です。
Security & Operations
外の世界に触れる＝リスクも一緒に入ってくる
MCP は便利な反面、AI に実行権を与える仕組みでもあります。導入前に必ず押さえたい注意点を、線画で整理します。
FIG.3 外部データの指示を鵜呑みにさせず、重要操作は承認ゲートと最小権限で守る
- プロンプトインジェクション：MCP 経由で読み込んだデータに悪意ある指示が紛れ込むと、AI がそれに従ってしまう恐れがある。外部由来の内容は「指示」ではなく「データ」として扱わせる設計を意識する。
- 最小権限と承認：書き込み・削除・送金など影響の大きい操作は、AI に自動実行させず承認を挟む。サーバーに渡す権限も必要最小限に。
- 運用と監視：MCP サーバーが落ちると連携が止まる。複数サーバーを呼ぶとレイテンシも増える。死活監視とログを前提に組む。
- ハルシネーション対策：取得した情報を AI が誤って要約・断定することがある。重要な判断は一次情報で裏取りする。
072026 年に起きた大きな変化
MCP はこの 1〜2 年で「Anthropic 発の便利機能」から「業界共通のインフラ」へと位置づけが変わりました。初学者ほど、最新の前提を押さえておく価値があります。
- 中立な標準へ：2025 年末、MCP は Linux Foundation 傘下の Agentic AI Foundation に寄贈されました。特定ベンダーの資産ではなく、オープンな標準として運営されています。
- 採用の広がり：Claude だけでなく、OpenAI（ChatGPT）や主要な開発ツールが MCP に対応。「どの AI でも同じサーバーを使える」という当初の狙いが現実になりました。
- リモート＋認証の整備：Streamable HTTP と OAuth ベースの認可が整い、社内向けのリモート MCP サーバーを実運用しやすくなりました。
- エコシステムの規模：公開されている MCP サーバーは各種レジストリ合計で1 万件超。公式レジストリの登録数だけでも 2026 年半ばで約 1 万件規模に達しています。
数字や仕様は更新が速い領域です。本記事の数値も「2026 年時点のおおよその規模感」として読み、導入判断のときは公式情報で最新を確認してください。
2026年7月6日、MCP に企業向けの新機能「Enterprise-Managed Authorization (EMA) Extension」が安定版として利用可能になったと発表されました（Publickey）。本記事 03 章の「リモート接続の認証は OAuth が主流」を一段進めるもので、社内で複数の MCP サーバー・複数の AI クライアントを運用する組織向けに、アクセス権限を組織単位で一括管理・監査できるようになります。個々の従業員が個別に OAuth 認可するのではなく、IT 管理者が「どの MCP サーバーに、どのチームが、どのスコープでアクセスできるか」をポリシーとして集約できる形で、本記事の Band Dark「外の世界に触れる＝リスクも一緒に入ってくる」で扱った最小権限・承認ゲート・監査ログを、社内 SaaS 管理と同じレベルの粒度で MCP にも適用できます。社内 MCP を本格展開する組織は、07 章の「エコシステム規模 1 万件超」の段階を、「まず数十個の MCP を EMA で一元管理する」という運用面から入るのが 2026 年後半の推奨アプローチになります。
08どこから始めるか
個人開発
Filesystem・Git など読み取り中心の公式サーバーで感覚を掴む。範囲を絞って小さく試す。
社内導入
社内 API を MCP 化すると、AI 経由で同じ操作を全社で共通化できる。認証・権限の設計を最初に。
製品組み込み
自社製品の API をリモート MCP サーバーにすれば、ユーザーの AI クライアントから直接呼べる。
関連ツールとして、サーバーをデバッグする MCP Inspector、TypeScript / Python の 公式 SDK、各サービスの公式 MCP レジストリが揃っています。次の記事「MCP サーバー開発入門」では、実際にサーバーを作る側を扱います。まずは公式サーバーを 1 つ繋いで、AI が外のツールを呼ぶ感覚を体験するところから始めましょう。
