Model Context Protocol (MCP) 入門、あるいはなぜただの API ではないのか?
私と同じように、MCP って API と同じようなものでは?と思ったことがあるなら、この投稿は MCP が怠け者の開発者にとってなぜ役に立つのかを明らかにする。Lorong AI が主催した 🎙️ Chop Chop Talk Shop (Chomp Edition): Model Context Protocol での Gang Rui の共有に触発され、主要な要点とエンドユーザーが MCP を使う方法を整理した。
TLDR
MCP はビジネスロジック(ホスト)とツール実行(サーバー)を分離し、クライアントを標準化された橋渡しとして置くことで、「何をするか」と「どうするか」を切り分ける。ホストはユーザーとのやり取りと AI 推論を管理し、サーバーは機能を再利用可能なインターフェースとして公開する。標準化によって、MCP はエージェント型 AI がシステムを横断して機能を動的に発見し、編成し、組み合わせることを可能にする。
問題:開発工数が組み合わせ爆発する
病院の医師向け AI アプリケーションからメールを送信したいとしよう。MCP 以前なら、メール API を呼び出す統合ロジックを書き、レスポンスを処理し、それをモデルに接続し、ビジネスロジックを貼り合わせる必要があった。今度は同じメール API を使って、患者への電話での予約リマインダーや、EC セール通知のような別のアプリにも対応すると想像してほしい。MCP がなければ、複数のクライアントと用途で同じ統合ロジックを再実装することになる。メール API に破壊的変更が入ったら?あちこちをリファクタリングするのを楽しめるといい。😤
MCP ✨ は、統合の複雑さが二次関数的に膨らむ問題に対する線形の解法だ。ユーザーインターフェースに対して React コンポーネントがしたことに似ている。モジュール式で、宣言的で、組み合わせ可能だ。
MCP とは?
USB-C が複数のケーブルやポートの必要性をなくしたように、MCP は AI アプリケーションが外部ツールやデータソースとやり取りするための普遍的な方法を提供する。主要な構成要素 は次の通り:
- 💻 MCP ホスト:リクエストを開始し、ユーザーとのやり取りを処理する AI アプリケーション。たとえば Claude Desktop。ホストはクライアントを通じて複数の MCP サーバーに接続できる。
- 🔌 MCP クライアント:ホストに組み込まれており、サーバーとのやり取りを担う。各クライアントは単一の MCP サーバーに接続する。
- ⚙️ MCP サーバー:クライアントが使うツール、プロンプト、リソースを公開する。
誰でも自分のホスト、クライアント、サーバーを書けるし、Smithery.ai にある 4200 以上の既存機能にそのまま接続することもできる。
仕組み
ユーザーが AI アプリケーションを起動する → リクエストを出す(例:「誰々に予約を思い出させて」)→ MCP クライアントが適切なツール(send_email など)と十分な文脈を持っているか確認する → MCP サーバー経由でツールを呼び出す。このサーバーはローカルで動く小さなプロセス(stdio 経由)でも、リモート(HTTP Streamable 経由、あるいは独自方式)でもよい → サーバーがリクエストを処理して結果を返す → AI がそれを応答に含める → ユーザーが最終的な返答を見る。
内部の仕組みをより詳しく知りたい場合は、アーキテクチャ仕様を参照。
なぜ MCP?
MCP は関心の分離を強制し、再利用性を促進し、保守を大幅に簡単にする。
魔法:AI 医療アプリケーションの例
現実世界では、ユーザーの需要はすぐに増え、サポートすべきプラットフォームも増えていく。
メール、SMS、アプリ内ポータルメッセージで予約リマインダーを送る AI 駆動の医療アプリケーションを作っているとしよう。
MCP なら次のように構成できる:
- プラットフォームごとに 1 つのホスト(例:ウェブ、モバイル)
- 各ホストの中に 3 つのクライアント - チャネルごとに 1 つ:メール、SMS、アプリ内メッセージ
- 各クライアントは実際のロジックを扱う MCP サーバーに 1:1 で接続
次に WhatsApp をサポートしたい?既存のものがあれば再利用し、なければ新しいサーバーを書けばよい。それはすぐにすべてのホストで利用可能になり、重複した作業は不要だ。
API を超えて
API は MCP と比べると、主に 2 つの点で制限されている:
- 機能 vs. アーキテクチャ - API は単一アプリケーション内で機能を公開する。MCP はアプリケーションを横断して機能するアーキテクチャを提供する。一度作ればどこでも使える。
- 固定型 vs. 適応型 - API はハードコードされたトリガーを使う。MCP は AI が文脈に基づいてどのツールを使うか判断できるため、柔軟で知的なワークフローを可能にする。
MCP は API をエージェントがすぐ使える機能へ変える。エージェントが必要に応じて API の上で自律的に推論し、組み合わせられるようにするのだ。これはサービスを呼ぶことと、スケールした環境で知的で柔軟なワークフローを編成することの違いだ。ウェブ開発者が静的 HTML から再利用可能なコンポーネントへ移ったように、MCP は AI エンジニアが脆く固定された統合から、ユーザーのニーズにリアルタイムで応答する動的で文脈を理解するエージェント型ソフトウェアへ移ることを助ける。🚀
Anthropic を超えて
Anthropic によって導入された MCP は、主要な大規模言語モデル企業とコミュニティの貢献に支えられて急速に成長している。
- OpenAI は Agents SDK で MCP を公式サポートしており、OpenAI API と ChatGPT デスクトップアプリも近日対応予定
- Microsoft は MCP の公式 C# SDK を開発し、このプロトコルを Copilot Studio、VS Code の GitHub Copilot エージェントモード、Semantic Kernel に統合した
- GitHub、Slack、Cloudflare などの主要プラットフォームも公式 MCP 接続を追加した
- 多くの公式言語 SDK がある:Python (Anthropic)、TypeScript (Anthropic)、Java (Spring AI)、C# (Microsoft)、Kotlin (JetBrains)、Swift (Loopwork AI)、Rust (Anthropic)
- OAuth 2.1 を使う認可仕様が 3 月 26 日にリリースされた
エコシステムはまだ初期段階にあり、最速で試す方法はホストをツールに自分で接続してみることだ。
制約と可能性
通常の大規模言語モデルに関する注意点は当てはまる。いくつかサーバーをインストールして試した時点で、Obsidian のものは失敗していた。MCP はまだ実験的で、ほとんどはローカルで動くものだが、私はこれを浮かび上がりつつある未来の設計図と見ている。本当にモジュール式で、再帰的で、自己拡張できる AI ネイティブアプリケーションを作るための欠けていたピースだ。
始め方
ユーザーとして MCP を試すなら、次が一番簡単だった:
-
クライアントを入手する:Claude Desktop をダウンロードする:claude.ai/download、または任意の既存ホストを使う。
-
依存関係を入れる:まだ持っていなければ Node.js をインストールする。
-
サーバーを探す:smithery.ai を見て、設定を任せる。
次に何を作る?👩🏻💻
MCP があれば、私のブログ執筆ワークフロー(現在は異なるデバイス上の Claude、Obsidian、ChatGPT に分散している)を、常に文脈を切り替える代わりに、単一で一貫した体験へ統合できる。
次にまた API 統合を書きたくなったら思い出してほしい。MCP は一度書けばどこでも使えるようにし、本当に重要なこと、つまり優れた AI アプリケーションを作ることに集中させてくれる。では、あなたは次に何を作るだろうか?