1. はじめに
最近、業務でMCPサーバーを触れる機会がありました。
ただ、触ってみると
- 「できることは分かるけど、概念がイマイチ理解できない」
- 「Host/Client/Serverなど用語が多くて整理できない」
と感じる場面がありました。
この記事では、
- ✅ MCPの概要（何か／なぜ必要か）
- ✅ ツール連携でよく出る「N×M問題（USB-Cの例え）」
- ✅ 混乱しやすい Host / Client / Server の関係
- ✅ Tools / Resources / Prompts といった周辺概念
まで、全体像がつながるように整理したいと思います。少しでも参考になったら幸いです。
2. MCPって何？
MCP（Model Context Protocol）は、LLM（大規模言語モデル）が外部ツールやデータを扱うための共通規格 です。
そして、その規格に従ってツール（機能）を提供する実装が MCPサーバー です。
MCPサーバーは、LLMが単体ではできない操作（検索、ファイル操作、外部サービス連携など）を“呼び出せる形”で提供する、いわば橋渡し役になります。
主な特徴は次の通りです：
- 標準化されたプロトコル：LLMとツール間の通信方法を統一し、どのモデルでも同じ形式でツールを利用できる。
- 安全な接続：APIキー等をモデルに直接渡さずに済むように、サーバー側で管理する設計にしやすい。
- 拡張性：検索、ファイル操作、データベース照会など、さまざまなツールを追加可能。
- ローカル・クラウド両対応：開発者が自分の環境で動かすことも、クラウド上で提供することもできる。
3. MCPがあると何ができる？（“AIに機能を追加できる”）
MCPを使うと、LLMは「会話で答えるだけ」から一歩進んで、目的達成のために外部の機能を呼び出せる“作業できるAI” に近づきます。
ここでは、MCPによって実現しやすくなる代表的なメリットを3つ紹介します。
3-1. 必要なツールを“後付け”できる（拡張しやすい）
MCPでは、検索・ファイル操作・社内システム連携など、欲しい機能をモジュールのように追加できます。
既製のサーバー（ツール）があれば採用し、なければ自分の用途に合わせて用意するという形が取りやすくなります。
たとえば、
- 社内ドキュメントを参照して回答してほしい
- Slackの特定チャンネルを検索して要約してほしい
- 特定APIの結果を取り込んでレポートを書いてほしい
といった用途でも、必要な“道具”を揃えることでAIの守備範囲が広がります。
3-2. AIが「今はこのツールを使うべき」を自立して判断してくれる
MCPの良さは「ツールが増える」だけではなく、状況に応じて どのツールを使うと目的に近づくかをAIが選びやすくなる点にもあります。
たとえばユーザーが「この仕様、どこに書いてある？」と聞いたときに、AIが
- まずドキュメント検索を試す
- 見つからなければ別ソース（Wiki/Drive/チケット）を当たる
のように、道具の使い分けを前提に行動しやすくなります。
※これはMCP単体の効果というより、MCPでツールが標準化されることで「ツールを使う前提のエージェント設計」がしやすくなる、という話です。
3-3. 失敗しても立て直しやすい（再試行・代替ルート）
外部連携は、APIの制限・権限不足・ネットワークエラーなどで失敗することがあります。
MCPでツール実行が組み込まれていると、AIがエラー内容を手がかりにして
- 入力条件を調整してもう一度試す
- 別のツール/別の手段に切り替える
- ユーザーに必要な追加情報だけ確認する
といった形で、結果が出るまでの“立て直し” がしやすくなります。
「一発で成功しない現実」を前提にした作りに寄せられるのは、実務ではかなりありがたいポイントです。
MCPで“答えるAI”から“進めるAI”へ
整理すると、MCPは
- 機能を増やせる（拡張性）
- 状況に応じて使い分けられる（判断）
- 失敗からリカバリしやすい（再試行）
という3点で、AIを実務タスク向けに進化させる土台になります。
4. MCPが登場した背景（なぜ“統一規格”が必要だったのか）
AIエージェント（＝調べる・まとめる・作る・連絡するなどのタスクを自律的に進める仕組み）を実務で使おうとすると、必ず「外部ツール連携」が必要になります。
MCPが一般化する前はこの連携がホスト（AIアプリ）ごとに作り方が違うことが多く、ツールを増やすほど開発・運用の負担が膨らむ問題がありました。
そこで登場したのが MCP（Model Context Protocol） です。
MCPは新しい魔法を増やすというより、「LLMとツールをつなぐ作法を揃える（規格を作る）」ことで、AIエージェント開発を加速するための土台として広がっていきました。
4-1. AIエージェント開発を加速したかった
AIエージェントは、ユーザーが細かい手順を全部指示しなくても、ゴールに向かって必要な作業を進めてくれる設計を目指します。
そのためには「検索」「ファイル」「DB」「チャット」「社内SaaS」など、複数ツールを組み合わせる前提 になります。
- 調べ物 → 参照元を集める
- まとめる → 文章を生成する
- 作業する → ファイル編集や投稿をする
- 連絡する → チャットやメールを送る
つまり、エージェントが賢くなるほど、裏側のツール連携が重要になります。
4-2. 個別対応（ホスト別の連携）が大変だった
MCP以前にも、LLMに外部機能を持たせる発想自体はありました。
ただ、実際に運用しようとすると「このAIアプリではこう実装」「別のAIアプリでは別の実装」となりがちで、ツール提供側も利用側も大変だという課題がありました。
たとえば、同じ“Slack連携”を作るにしても
- AのAIアプリ向けに実装
- BのAIアプリ向けに実装
- CのAIアプリ向けに実装
のように増え、ツールが増えるほど“組み合わせ爆発”が起きます。
ここで出てくるのが、ツール連携の N×M問題 となります。
- N：ホスト（AIアプリ/エディタ）が増える
- M：ツール（検索/ファイル/DB…）が増える
→ 個別対応を続けると、実装・保守・テストが増え続ける
4-3. だから“みんなで揃えた共通規格”が必要になった
この問題に対して、「ツールとホストの接続を共通化しよう」という流れが強くなりました。
共通規格があると、ツール提供側は MCPで一度作れば、複数ホストで使われやすく なり、利用側も ツールを差し替え・組み合わせしやすく なります。
4-4. 普及が進んだ理由：提唱＋SDK
- MCPは「思想」だけでなく、開発しやすくするためのSDKやリファレンス実装が整備されたことで、一気に採用が進んだそうです。
- 結果として、企業公式やコミュニティからサーバーが公開され、使う側も「まず試してみる」がやりやすくなったと言われています。
5. 例えで理解する：MCPは「AIアプリのUSB-C」
MCPが「AIアプリのUSB-C」と例えられるのは、まさにN×M問題を解決する発想だからだそうです。
共通規格があると接続コストが一気に下がるという本質を、説明するための例です。
5-1. USB-Cの世界で起きたこと
少し前まで、デバイス同士をつなぐ端子やケーブルはバラバラでした。
- PC：USB-A / USB-C
- スマホ：Micro-USB / Lightning
- 周辺機器：HDMI / USB-B / Mini-USB / MIDI …
この状態だと「つなぎたい組み合わせ」が増えるほど、必要なケーブルや変換アダプタが増えていきます。
つまり、接続のたびに“相手に合わせて準備する”必要があります。
一方で、USB-Cに統一されると話が変わります。
端子（規格）が揃うことで、ケーブル1種類で、いろんな機器をつなげるようになります。
ここで重要なのは「USB-Cがすごい」のではなく、
“共通規格に揃った”ことがすごい、という点
5-2. MCPがやっていること＝「つなぎ方」をUSB-Cみたいに揃える
MCPは、AIアプリとツールの間にある「接続の作法」を共通化します。
これによって、ツール側はMCPに対応していれば、複数ホストから使われやすくなります。
イメージとしてはこうです：
- Before（個別対応）：ホスト×ツールの組み合わせ分、つなぎ方が必要（N×M）
- After（共通化）：ホストはMCPでつなぐ、ツールもMCPで提供する（だいたいN+Mに近づく）
もちろん現実の実装はもう少し複雑ですが、ポイントはシンプルで、
“接続の口を揃えることで再利用しやすくする” のがMCPの価値です。
6. MCPの用語を整理する（Host / Client / Server）
ここでは、最低限おさえたい登場人物を 3つ（Host / Client / Server） に絞って整理します。
6-1. MCPホスト（Host）＝LLMを使う“アプリ側”
MCPホストは、LLM（ChatGPT/Claude など）を利用するための アプリやエディタのことです。
たとえば、次のようなものがHostにあたります。
- Claude Desktop
- Cursor / VS Code
- Cline（VS Code拡張）など
イメージとしては 「LLMを使って作業するための窓口」が良いと思います。
ユーザーは基本的にホストを触ります。
6-2. MCPクライアント（Client）＝Hostの中にいる“通信係”
MCPクライアントは、ホストの中に含まれている要素で、
MCPサーバーとやり取りするための 通信担当です。
役割としては以下の通りです：
- ツール呼び出し（サーバーの機能を実行する）
- ログや実行状況の管理
- 許可（permission）の制御 など
※ 基本的にホストを使うだけならクライアントは勝手に入っていて、意識する場面が少ないため、あまり理解を深める必要はなし
6-3. MCPサーバー（Server）＝“機能をまとめた軽量プログラム”
MCPサーバーは、LLMが使える機能（ツール）を提供するための 軽量プログラムです。
ここで注意したいのが「サーバー」という言葉の罠で、物理的なサーバー機器のことではありません 。
MCPの文脈でいうサーバーは、
- 「この機能はどう呼び出すか」
- 「どんな引数を渡すか」
- 「どういう結果が返るか」
…といった “機能の使い方をまとめたプログラム” になります。
6-4. MCPサーバーの例
図にある例は、「こういう種類のサーバーがあるよ」という紹介になっています。
- filesystem：PC内のファイル操作（検索、読み書き、一覧表示など）
- brave-search：Brave Search APIでWeb検索
- slack：Slackの検索・送信・最近のメッセージ参照など
- gdrive：Google Driveの参照・ファイル取得など
ここで大事なのは、どれも “LLM単体ではできないこと” を、サーバー経由でできるようにしている点です。
6-5. どこまでがローカル？
- MCPホスト：PCにインストールされたアプリ（ローカルにある）
- MCPサーバー：PC上で動かすプログラムとして置ける（ローカルにある）
- ファイル操作など：当然PCの中（ローカル）
つまり、MCPはクラウド前提の仕組みというより、まずはローカルPC上にツールを追加して拡張できる世界観として捉えると理解しやすいと思います。
※ もちろん、サーバー自体をクラウドで提供する形もありますが、概念理解では一旦「ローカルに置ける」くらいでOKです
7. MCPサーバーが提供するもの（Tools / Resources / Prompts）
MCPサーバーが提供できるものは、大きく分けて次の3つです。
- Tools（ツール）
- Resources（リソース）
- Prompts（プロンプト）
ただ、実務で「MCPサーバー」と言うと、9割以上が Tools を指すそうです。
7-1. Tools：LLMに“外部の操作”をさせる（MCPの主役）
Tools は、LLMが外部の機能を実行できるようにする仕組み です。
イメージとしては「LLMがボタンを押して、外部の処理を動かせるようになる」感じです。
例えば、Toolsでできることはこんなイメージです。
- ファイル検索・読み書き（ローカル/共有フォルダなど）
- Web検索（Brave Searchなど）
- 開発ツール操作（CLI実行、CI/CD、Lintなど）
- 外部サービス連携（Slack、GitHub、Google Drive…）
7-2. Resources：LLMが参照できる“読み取り専用データ”を渡す
Resources は、LLMに渡すための「参照用データ」 です。
「必要な情報を読ませたい」場面で使われます。
イメージとしては次の通りです。
- 社内ドキュメント
- 商品DBやFAQ
- 仕様書、設計資料、規約
- ナレッジベース（検索結果や固定の参照情報）
Toolsとの違いとしては次の通りです。
- Tools：外部に“操作”しに行く（実行する）
- Resources：情報を“読ませる”ために渡す（参照する）
7-3. Prompts：よく使う指示を“テンプレ化”して再利用する
Prompts は、プロンプト（指示文）のテンプレート です。
毎回ゼロから指示を書くのではなく、「定型の形」を用意しておくことで、指示の品質を安定させられます。
例えば、こんな用途が考えられます。
- レビュー依頼の型（「観点」「前提」「期待する出力」まで埋める）
- 障害調査の型（「再現条件」「ログ」「切り分け手順」を固定化）
- 議事録要約の型（「結論→論点→次アクション」のフォーマット）
テンプレの中に変数（例：{issue_url} や {log}）を用意しておけば、必要な情報だけ差し替えて使い回せるのが強みです。
8. MCPサーバーはどこで探す？
MCP公式ドキュメント:
MCP Registry:
GitHub:
SDK（例：Python SDK）:
9. おわりに
MCPは、LLMに外部機能（ツール）を持たせるための共通規格で、例えるなら「AIアプリのUSB Type-C」だと理解しました。
規格が揃うことでツール連携の N×M問題 を緩和でき、一度作ったツールを複数のAIアプリで使い回しやすくなる──この点がいちばんの価値だと感じています。
用語は最初とっつきにくいですが、まずは Host（AIアプリ） と Server（ツール提供プログラム） の関係を押さえると、全体像がスッと入ってくると思います。
私はまだ勉強中ですが、今後は用途に合わせてMCPサーバーを選び、少しずつ自分の作業環境を便利にしていきたいです。
ここまで読んでいただき、ありがとうございました。
もしこの記事が役に立ったら、ストック／いいねしてもらえると嬉しいです！