⛳
MCPとAPIの違いを説明できますか？
はじめに
API（Application Programming Interface）とMCP（Model Context Protocol）はどちらもシステム間のデータ連携を扱うものですが、その目的や設計哲学、適用範囲が大きく異なります。本記事では、両者の違いについて詳しく解説します。
1. 役割と目的の違い
API
- サービスやライブラリが持つ機能を外部プログラムから呼び出すための「関数群」や「エンドポイント」の集合
- 典型的には HTTP（REST/RPC/GraphQL）や言語別SDKで提供
- 汎用的にあらゆるデータ操作・業務ロジック呼び出しを実現
以下の表は、API の主要な進化フェーズと特徴をコンパクトにまとめたものです。
| 時期 | 主要トピック | キーワード |
|---|---|---|
| 1990年代後半〜2000年代前半（黎明期） | SOAP / XML-RPC / WSDL | XML, RPC, エンタープライズ |
| 2000年代後半（転換期） | REST / JSON / リソース指向 | HTTP, CRUD, URI |
| 2010年代（成熟期） | GraphQL / OpenAPI / Cloud‑native | 型安全, Client Driven, Self‑Docs |
| 2020年代（現代） | API Gateway / 自動生成 / ガバナンス強化 | セキュリティ, DX, APIエコノミー |
API進化からの学び
APIの歴史を俯瞰すると、複雑さ → シンプルさ → 標準化 → DX（Developer eXperience） という振り子運動が見て取れます。
この流れはMCPの誕生と普及を理解する上で極めて示唆に富みます。
-
複雑さとの闘い
- SOAP/WSDL が提示した “何でもできる” インターフェースは強力でしたが、実運用では XML スキーマの巨大化と相互運用性の壁が課題となりました。
- MCPにおける教訓: プロンプトの肥大化や独自ツール仕様の乱立を放置すると同じ悲劇が起こる。
-
シンプルさが駆動する普及
- REST は HTTP の語彙だけで表現し、ベースラインを絞り込むことで爆発的に普及しました。
- MCP の鍵: LLM に渡すメタデータを最小限のプリミティブに絞り、実装者の思考コストを劇的に下げる。
-
標準化とエコシステム
- OpenAPI により “仕様” と “ドキュメント／SDK生成” が一体化し、API エコシステムが拡大しました。
- MCP の示唆: 共通 YAML/JSON スキーマで相互運用性を確保し、ツール・プラットフォーム横断の再利用性を高める。
-
DX（Developer eXperience）の強調
- GraphQL は “開発者が欲しいデータを１リクエストで得られる” 体験を提供し、圧倒的支持を得ました。
- MCP のチャレンジ: プロンプト設計の DX を高め、失敗しにくい LLM 連携を提供すること。
このように、API の進化で得られた学びは MCP が向かうべき北極星 を示しています。
| 視点 | API | MCP |
|---|---|---|
| 主目的 | 機能を「呼び出す」 | コンテキストを「渡す／調停する」 |
| 抽象レベル | 関数呼び出し（I/O） | 会話フローと外部知識 |
| 対象 | 任意のサービス・メソッド | LLM（テキスト生成モデル） |
| デザイン原則 | リソース指向 / RPC / GraphQL | プロンプトエンジニアリング、ツール呼び出し、ステート管理 |
| 典型的な失敗 | バージョニング欠如、レート制限誤設計 | コンテキスト肥大化、プロンプトインジェクション |
重要な視点: 連続体として捉える
API と MCP は二項対立ではなく レイヤーで共存 します。MCP は API を “ツール” として内包し、LLM が取り得る行動を外部サービスに委譲するための “調停者” です。そのため 「API 設計力 × プロンプト設計力」 が未来の開発者に必須のスキルセットになるでしょう。
2. 抽象レイヤーの違い
| レイヤー | API | MCP |
|---|---|---|
| 抽象度 | 低〜中：具体的な関数呼び出し、HTTPリクエスト単位 | 高：LLMへのプロンプト設計・外部データ注入の仕様 |
| 呼び出し手順 | クライアント→サーバへリクエストを投げてレスポンスを得る | プロンプト中の"ツール呼び出し指示"として宣言し、モデル実行時に解釈 |
3. データ交換の流れ
APIの場合
- アプリケーション側がエンドポイント（例：GET /users/{id}）を呼び、JSONやXMLのペイロードを受け取る
- 明示的に「いつ・何を呼ぶか」をコード内で記述する必要がある
MCPの場合
- LLMへの入力（プロンプト）に「MCP形式のメタデータ」を含めて送信
- モデルが「メタデータに基づいて必要なツール（外部API）を呼び出すべきか」を判断
- 返り値をプロンプトに差し込みながら対話を進行
4. 実装上の違い
API
- 実装者が直接エンドポイント定義 → クライアントでURL/パラメータを組み立て
- リトライ、認証、スキーマ変更対応などはそれぞれのAPI仕様に従う
MCP
- 「どの属性にどの情報を詰めるか」「ツール呼び出し時にどのメッセージ形式を使うか」をMCP仕様で統一
- LLMプラットフォーム側でMCP対応の"プラグイン"や"ツールランチャー"を実装
- モデル出力から自動的に外部連携
まとめ
- API は「機能呼び出しのためのインターフェース」の総称で、あらゆるシステム連携に使われる汎用ツール
- MCP は「LLMに対して"いつ・どのように"外部APIを呼ぶか」を規定する『プロンプト／メタデータ標準』
- LLM連携の文脈では、APIをMCPの"ツール"として定義し、MCP仕様に沿って呼び出すことで、モデルとのインタラクションをよりシームレスに標準化できます
Discussion