Model Context Protocol (MCP) 入門、あるいは「API だけではだめなのか？」

もしあなたも僕と同じように「MCP って、結局 API みたいなものでは？」と思ったことがあるなら。この記事では、怠惰な開発者にとって MCP がなぜ便利なのかを整理する。Lorong AI 主催の 🎙️ Chop Chop Talk Shop (Chomp Edition): Model Context Protocol での Gang Rui さんの共有に触発されて、MCP の要点と、エンドユーザーとしての使い方をまとめておく。

TLDR

MCP は、ビジネスロジック（Host）とツール実行（Server）を切り離し、その間を標準化された橋渡しとして Client がつなぐことで、「何をするか」と「どう実行するか」を分離する。Host はユーザーとのやり取りと AI の推論を担い、Server は再利用できるインターフェースとして機能を公開する。標準化によって、MCP はシステムをまたいで機能を動的に発見し、組み合わせ、実行できるエージェント型 AI を可能にする。

問題：開発工数の組み合わせ爆発

病院で医師向けに動く AI アプリケーションからメールを送りたいとする。MCP 以前なら、メール API を呼ぶ統合ロジックを書き、レスポンスを処理し、モデルにつなぎ、そこにビジネスロジックを貼り合わせる必要があった。では同じメール API を使って、患者への予約リマインダーを電話で出したり、EC のセール通知のような別アプリにも広げたりする場面を想像してほしい。MCP がなければ、複数のクライアントとユースケースごとに同じ統合ロジックをまた実装することになる。メール API に破壊的変更が入った？あちこちリファクタリングするのが好きだといいですね。😤

MCP ✨ は、統合の複雑さという二次関数的な問題に対する線形の解法だ。UI における React コンポーネントのようなものでもある。モジュール化され、宣言的で、組み合わせられる。

MCP とは何か？

USB-C がケーブルやポートの乱立を減らしたように、MCP は AI アプリが外部ツールやデータソースとやり取りするための共通の方法を提供する。主要コンポーネントは次のとおり。

💻 MCP Hosts：リクエストを開始し、ユーザーとのやり取りを処理する AI アプリケーション。Claude Desktop のようなもの。Host は Client を通じて複数の MCP Server に接続できる。
🔌 MCP Clients：Host に組み込まれ、Server とのやり取りを受け持つ。各 Client は 1 つの MCP Server に接続する。
⚙️ MCP Servers：Client が利用できるツール、プロンプト、リソースを公開する。

Host、Client、Server は誰でも自分で書ける。あるいは、Smithery.ai に 4200 以上ある既存の機能につなぐだけでもいい。

仕組み

ユーザーがあなたの AI アプリケーションを起動する → リクエストする（例：「誰々に予約のリマインダーを送って」）→ MCP Client が適切なツール（たとえば send_email）と十分なコンテキストがあるか確認する → MCP Server 経由でツールを呼び出す。Server はローカルで動く小さなプロセス（stdio 経由）でも、リモート（HTTP Streamable 経由、あるいは独自方式）でもよい → Server がリクエストを処理して結果を返す → AI がその結果を応答に含める → ユーザーが最終的な返答を見る。

内部の仕組みをもう少し詳しく知りたい場合は、アーキテクチャ仕様をこちらで読める。

なぜ MCP なのか？

MCP は 関心の分離を強制し、再利用性を高め、保守を大幅に楽にする。

魔法の部分：AI ヘルスケアアプリの例

現実の世界では、ユーザーの要求はすぐに増える。そして対応しなければならないプラットフォームも同じ速度で増える。

予約リマインダーを メール、SMS、アプリ内ポータルメッセージで送る、AI 搭載のヘルスケアアプリを作っているとしよう。

MCP で組むなら、構成はこうなる。

プラットフォームごとに Host を 1 つ（例：Web、モバイル）
各 Host の中に Client を 3 つ - メール、SMS、アプリ内通知の各チャネルに 1 つずつ
各 Client は、実際のロジックを処理する MCP Server に 1 対 1 で接続する

次に WhatsApp に対応したくなった？既存のものがあれば再利用すればいいし、なければ新しい Server を書けばいい。それだけで全 Host からすぐ使える。作業の重複は不要。

API を超えて

API は MCP と比べると、主に 2 つの点で限界がある。

関数 vs. アーキテクチャ - API は単一のアプリケーション内で関数を公開する。MCP はアプリケーションをまたいで機能するアーキテクチャを提供する。一度作れば、どこでも使える。
固定 vs. 適応 - API はハードコードされたトリガーで動く。MCP では、AI がコンテキストに応じて使うツールを判断できるため、柔軟で知的なワークフローを作れる。

MCP は API を、エージェントが扱える機能へ変える。必要に応じて、エージェントが API を推論し、組み合わせ、自律的に使えるようにするためだ。これは単にサービスを呼び出すことと、知的で柔軟なワークフローを大規模に編成することの違いでもある。Web 開発者が静的 HTML から再利用可能なコンポーネントへ移っていったように、MCP は AI エンジニアを、壊れやすく固定された統合から、ユーザーの要求にリアルタイムで応える、動的で文脈を理解するエージェント型ソフトウェアへ連れていく。🚀

Anthropic を超えて

Anthropic が導入した MCP は、主要な LLM 企業の支持とコミュニティからの貢献を受けて急速に広がっている。

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 日にリリースされた

エコシステムはまだ初期段階にある。感触をつかむいちばん早い方法は、自分で Host をツールにつないでみることだ。

限界と可能性

LLM につきものの注意点は、ここでもそのまま当てはまる。僕がいくつか Server を入れて試した時点で、Obsidian 用のものはもう壊れていた。MCP はまだ実験的で、ほとんどはローカル向けだ。それでも僕には、これから立ち上がってくる未来の設計図に見える。本当にモジュール化され、再帰的で、自分自身を拡張していける AI ネイティブなアプリケーションを作るための、欠けていたピースだ。

始め方

ユーザーとして MCP を試すなら、僕は次のやり方がいちばん楽だった。

Client を用意する：claude.ai/download から Claude Desktop をダウンロードする。あるいは任意の既存 Hostを使う。
依存関係を片づける：まだ入っていなければ Node.js をインストールする。
Server を探す：smithery.ai を眺めて、セットアップも任せる。

次に何を作る？ 👩🏻‍💻

MCP があれば、今は Claude、Obsidian、ChatGPT の間をデバイスごとに行き来している僕のブログ執筆ワークフローを、ひとつのまとまった体験に統合できる。延々とコンテキストを切り替えなくてよくなる。

次にまた API 統合を書きたくなったら、思い出してほしい。MCP なら一度書けばどこでも使えるし、本当に大事なこと、つまりよい AI アプリケーションを作ることに集中できる。さて、次は何を作る？

Model Context Protocol (MCP) 入門

Table of Contents