本記事は MCP が解決する実務上の課題と、AI アプリケーションを構築する開発者にもたらす具体的なメリットに焦点を当てます。セットアップ手順は別記事で扱います。
AI は賢いが、孤立している
現在の AI は推論、コード生成、データ分析をかなりの水準でこなせます。しかし明確な制約があります。AI は自ら外部システムに接続できないという点です。
簡単な例：社内データベースから数値を取得し、今週のレポートファイルを読み、要約を Slack に送る——推論の面では AI は十分可能ですが、実行するには開発者がモデルごと・ツールごとにコネクタを自前で書く必要があります。モデルとツールの数が増えると、これはアーキテクチャ層で解くべき問題になります。
M×N 問題
5 つのシステムに接続する AI アシスタントを構築するとします：
- Redmine
- Slack
- PostgreSQL
- 社内 Wiki
- Google Drive
会社で 3 種類の AI モデルを使っている場合、従来のアプローチでは各 (モデル, ツール) の組み合わせごとに専用コネクタが必要です：
Model A ──── Redmine connector
Model A ──── Slack connector
Model A ──── PostgreSQL connector
...
Model B ──── Redmine connector
Model B ──── Slack connector
...
→ 3 × 5 = 15 コネクタ、15 の独立したコードベース
ツールが変わるたび——関数名の変更、パラメータ追加、API のリファクタ——次の作業が発生します：
- ロジックのコード修正
- 各 AI 向けのツール定義の書き直し
- 対応するプロンプトの更新
- アプリケーションの再起動
これが M×N 問題です：M モデル × N ツール = M×N コネクタ。規模が大きくなるほど、保守コストは乗算的に増えます。
MCP はプロトコルの標準化で解決する
Model Context Protocol (MCP) は Anthropic が開発したオープンプロトコルで、モデルとツールの間に標準化されたレイヤーを置きます。各ペアが独自に通信方法を決めるのではなく、すべてが共通プロトコルに従います。
┌── Redmine MCP Server
├── Slack MCP Server
Model A ──┐ ├── PostgreSQL MCP Server
Model B ──┼── MCP ┼── 社内 Wiki MCP Server
Model C ──┘ └── Google Drive MCP Server
→ 15 ではなく 3 + 5 = 8 回の統合
新しいモデルを追加 → モデル側で MCP を一度統合するだけ。
新しいツールを追加 → そのツール用の MCP Server を一度書くだけ。
双方は相手の実装の詳細を知る必要がありません。
3 つの構成要素からなるアーキテクチャ
MCP はクライアント・サーバーモデルで、次の 3 要素で動作します：
MCP Host
ユーザーが操作する AI アプリケーション——Claude Desktop、Cursor、VS Code、自前のチャットボットなど。Host は接続を初期化し、アクセス権を制御し、処理フロー全体を調整します。
MCP Client
Host 内部のプロトコル層で、1 対 1 で単一の MCP Server との接続を維持します。Host が 5 つのツールと連携する場合、5 つの独立した Client を作成し、それぞれが 1 本の接続を管理します。
MCP Server
ツールまたはデータソースの能力をパッケージ化し、MCP 標準に沿って公開するプログラムです。Server はローカル（stdio）またはリモート（HTTP）で実行できます。
MCP エコシステムの例：
-
Redmine MCP Server →
get_issue(id),get_issue_context(id),search_issues(query) -
Slack MCP Server →
post_message(channel, text)
MCP Server が提供する 3 種類のリソース
MCP Server は primitives と呼ばれる 3 種類のリソースを提供します。各 primitive には異なる制御主体があり、システム内の責務分離が明確になります：
| Primitive | 制御主体 | 意味 |
|---|---|---|
| Tools | Model (AI) | AI がいつどのツールを呼ぶかを自律的に決定 |
| Resources | Application (Host) | アプリが取得するデータとコンテキストへの投入タイミングを決定 |
| Prompts | User (ユーザー) | ユーザーが使うテンプレートを能動的に選択 |
Tools
Tools は実行可能な関数で、AI が外部システムと対話し状態を変更できます：チケットの更新、Slack への投稿、ファイル作成、データベース更新など。Resources と異なり、Tools は読み取りだけでなく書き込みも行います。
ユーザーはツール名や呼び出し構文を知る必要はありません。自然言語で要求を述べるだけで、AI がどのツールをどの引数で使うかを決めます。
例： Redmine MCP Server と Slack MCP Server に接続した AI アシスタントの場合：
「Redmine の #1234 を確認して、担当者・ブロッカー・受け入れ条件を要約し、#dev チャンネルに投稿して。」
AI は自動的に次を呼び出します：
get_issue_context(id: 1234)post_message(channel: "#dev", text: "…")
Redmine を開いてチケットを読み直したり、Slack に手でコピペしたりする必要はありません。
Resources
Resources は Host が取得して AI のコンテキストに渡す読み取り専用データ——ファイル、DB レコード、ログ、ドキュメントなどです。各リソースは URI で識別されます：
redmine://issues/1234 → Redmine のチケット本文・カスタムフィールド
redmine://projects/backend-api → プロジェクトのトラッカー・説明
db://orders/schema → データベーステーブルのスキーマ
Resources は取得時に変更されません——Tools との明確な境界です。
Prompts
Prompts はサーバー上に定義された対話用テンプレートです。ユーザーが必要なときに選択・起動し、毎回ゼロから入力する必要はありません。サーバーに保存されるため、一箇所で更新すればすべてのクライアントがすぐに反映されます。
具体的なメリット
一度書けば複数の AI で使える
MCP Server を書き終えれば、MCP をサポートする任意の LLM で利用できます——モデルを変えてもコネクタを書き直す必要はありません。
ツール更新時にアプリを再起動しなくてよい
MCP 以前：関数シグネチャを変更 → コード修正 → 各 AI 向けツール定義の書き直し → プロンプト更新 → アプリ再起動。
MCP では：MCP Server だけを修正すればよい。接続中のすべての Host が tools/list 経由で新しい定義を自動取得——モデル側の変更や再起動は不要です。
ユーザーが AI の行動を制御できる
Slack への投稿、チケットのステータス変更、ファイル削除など、実際に影響のあるツールを AI が呼ぶとき、Host が事前に確認を求めます：
AI がツールを使用しようとしています: post_message
Input: { "channel": "#dev", "text": "Issue #1234: …" }
[常に許可] [今回のみ許可] [拒否]
ユーザーは AI が何をしているか正確に把握し、拒否できます。
Roots でアクセス範囲を制限
Roots メカニズムにより、クライアントはサーバーが作業すべきデータ領域を指定できます：
{
"roots": [
{ "uri": "file:///home/user/projects/myapp", "name": "Project Directory" }
]
}
注意：公式ドキュメントによると、Roots は 調整メカニズム (coordination mechanism) であり、厳格なセキュリティ境界ではありません。サーバーは従うことが推奨 (SHOULD) されますが、必須 (MUST) ではありません。実際のセキュリティは OS レベルの権限に依存する必要があります。Roots は作業スコープの制限や誤アクセス防止に適しています——セキュリティレイヤーの代替には使うべきではありません。
MCP Server が LLM を自前統合なしで利用できる
Sampling 機能により、MCP Server は必要に応じてクライアント側の LLM を逆方向に呼び出せます——データの要約、分析、テキスト生成——モデルを自前で統合したり、追加の API コストを負担したりする必要がありません：
Server がデータ取得完了
→ 要約が必要 → Client に Sampling リクエスト送信
→ Client が既存の LLM を使用 → 結果を Server に返却
→ Server が処理を継続
これによりマルチエージェントアーキテクチャが可能になります：複数のエージェントが MCP 経由で連携し、どのエージェントも独自の LLM をデプロイする必要がありません。
従来の Function Calling との比較
| 観点 | Function Calling | MCP |
|---|---|---|
| ツールの実装場所 | AI アプリケーションに埋め込み | 独立した MCP Server |
| ツール変更時 | アプリ全体を再起動 | MCP Server のみ修正 |
| 複数 AI での再利用 | 最初から書き直し | 同一サーバーを共有 |
| 統合の規模 | M×N コネクタ | M+N コネクタ |
| ユーザー制御 | 自前実装 | elicitation で標準提供 |
| 範囲制限 | 自前実装 | Roots で標準提供 |
まとめ
MCP はアーキテクチャ層で AI 統合の問題を解決します。ケースごとに個別対応するのではなく、開発者は MCP 標準に一度従って実装する——モデル側かツール側か——だけで、双方が自動的につながります。
その結果、コネクタ数は M×N から M+N に減り、ツールは複数モデルで再利用でき、更新に再起動は不要で、ユーザーは AI の各アクションを制御できます。
実データや実システムに接続する AI アプリケーションでは、後から ad-hoc に対処するより、最初から MCP をアーキテクチャとして検討する価値があります。