APIとMCPの違い - 人間向けUI vs モデル向けUI 実践ガイド 2025
APIとMPCが最近ごっちゃになることが多いときくので整理してみた。
TL;DR
APIは人間の開発者が主体（自由度・網羅性・双方向の操作）
MCPはLLM/エージェントが主体（“発見できる文脈＋行為”を標準化）
MCPの中核はResources（読取文脈）／Tools（実行）／Prompts（指示テンプレート）
「APIをそのままMCP化」＝過剰な詳細・危険な権限・意味不足で使いづらく、危険になりがち
1. 背景と定義
APIはエンドポイント・HTTP動詞・認証・エラーモデルなどを通じて、人間の開発者がプログラムを制御するための汎用インターフェースです（読取・書込の両方が前提）
MCPは「LLMアプリと外部のデータ源・ツールをつなぐオープンプロトコル」。よく“AIのUSB-C”に喩えられ、モデルが必要な文脈（データ）と実行手段（ツール）を“発見→理解→利用”できるよう標準化します。
MicrosoftがWindowsへのMCP対応を示したことからも、エージェントがOSやアプリ機能を横断的に利用する未来像が強化されています。
2. MCPのコア抽象：Resources / Tools / Prompts
Resources：モデルに与える読取専用の文脈データ（ファイル、DBレコード、アプリ状態、画像など）。URI・説明・MIME等のメタデータで自己記述され、“何を読むか”を明示します。
Tools：LLMが外部システムを操作する行為（DB照会、API呼び出し、計算、ファイル生成など）。名前・説明・入力スキーマを持ち、読取だけでなく書込も可能です。
Prompts：サーバ側が公開する指示テンプレート。クライアント（LLM側）が一覧取得・内容取得・引数適用でき、適切な使い方をガイドします。
重要：MCP全体が“読取特化”ではありません。Resourcesは読取ですが、Toolsは実行（書込含む）です。ここを取り違えると設計も評価もズレます。
3. 設計思想の違い: 人間主体 vs モデル主体
1. 主体
API: 人間の開発者（ドキュメントを読み、実装して制御する）
MCP: モデル／エージェント（自動で「発見 → 選択 → 実行」する）
2. 目的
API: 網羅的な操作と細かな制御を提供する
MCP: タスク達成のための文脈（データ）＋行為（ツール）を即時に利用可能にする
3. 形態
API: 多数のエンドポイント群（詳細・オプションが多い）
MCP: 自己記述メタデータの列挙と発見（Resources / Tools / Prompts）
4. 操作モデル
API: 読み取り＋書き込みの両方を前提
MCP: 読み取り＝Resources、実行（書き込み含む）＝Tools
5. ドキュメント前提
API: 人間が読むことを前提に記述（文章中心の仕様）
MCP: モデルが機械的に解釈できる記述（説明＋入出力スキーマで誘導）
補足
本質: MCPは「モデルが自力で扱えるUI」
これまで開発者が選定していた操作やパラメータを、モデルがメタデータから発見・判断できる形に並べ替えることが肝
4. 「APIをそのままMCP化」の何が危ないか
4.1 過剰な詳細・不適切な粒度
APIの豊富なパラメータや多態的なレスポンスは、モデルにとっては探索空間を過剰に広げるノイズになりがち。MCPでは目的別にToolを小さく切る／Resourceを意味単位で切るなど、モデルが選びやすい粒度へ再設計が必要です
4.2 書込権限の露出
APIの「強力な書込操作」をToolに無差別に公開すると、副作用の大きい誤実行を招きます。最小権限・確認プロンプト・人間承認などのガード設計が必須
4.3 意味（メタデータ）の欠落
APIドキュメントは人に優しいが、モデルには意味が伝わらないことがあります。Tool/Resource/Promptの説明・スキーマをモデル向けに明確化しないと、誤用・過探索・非効率が起きます
4.4 セキュリティ面（Prompt Injection / Tool Poisoning）
Toolの説明文や外部データに仕込まれた指示で、モデルが意図せぬ実行をする新種の攻撃（Tool Poisoning）が報告されています。説明文・メタデータ自体が攻撃面になり得るため、検証・同意UI・レジストリ管理・監査が必要です
5. 実務での設計パターン（チェックリスト）
(A) スコープ定義
解決するタスクを列挙し、Toolをタスク単位に設計（最小権限・限定的な副作用）
(B) Resource設計
安定URI・説明・MIME/型・サイズ上限・更新頻度を明示
可能なら決定性・再現性を担保（キャッシュ戦略も）
(C) Tool設計
入力スキーマ（型・必須/任意・制約）と出力スキーマ（構造化）を厳密化
副作用ラベル・確認プロンプト・ロールバック・レート制御
(D) Prompt設計
よく使う手順はPromptテンプレート化し、引数で可変に
(E) 発見性・バージョニング
一覧API（list）と詳細取得を揃え、非互換変更はversioning
(F) セキュリティ
MCPレジストリ/許可リストで信頼済みサーバのみを公開
説明文の検疫・出力のサニタイズ・人間承認・監査ログを実装。Windowsの導入方針（レジストリ・同意プロンプト）も参考に
(G) 運用（観測性）
Tool呼び出しのトレース・入力/出力の要約ログ・失敗時の原因分析を整備
位置づけのまとめ：APIとMCPは代替ではなく“層”
APIは引き続き基盤です
MCPはAPI群の上にモデルが使いやすい面”を規格化して載せるアダプタ層
実際、企業導入例・ニュースは「既存ソフトとの接続を速く・安全に・横断的に」という方向で拡大しています（Windows対応、業界記事、仕様更新）
7. 失敗しない移行の最短ルート（サンプル方針）
最重要タスクTOP5を選び、各タスクに1つのTool＋必要なResourceを設計。
各Toolに入力/出力スキーマと副作用ラベル、確認プロンプトを付与
Resourceは小さく決定的に（巨大データはURI＋部分取得に）
Promptテンプレートで“正しい使い方”を明示
許可リスト＋監査ログ＋人間承認を用意してパイロット運用
結論
APIは人間主体の制御IF、MCPはモデル主体の“文脈＋行為”の標準化。
成功するMCP化のカギは、意味の再設計（自己記述メタデータ）と、最小権限・確認・監査を前提にした安全なTool設計です。
「そのままMCP化」はほぼ失敗パターン。粒度・意味・安全を作り直してこそ、MCPは“AIのUSB-C”として威力を発揮します
さらにセキュアに利用したい人はこちらも参考に
