MCPとAPIは何が違う？使い分けを整理

MCPとAPIは同じものではありません。APIはサービスが機能やデータを提供するための接点で、MCPはAIアプリが外部の機能やcontextへ接続する際の共通protocolです。MCP Serverが内部で既存APIを呼ぶこともあります。どちらか一方が常に優れているのではなく、接続する相手と再利用したい範囲で選びます。

まず何を比較しているか

「API」は広い言葉で、HTTP API、SDK、OS APIなど複数の形を指します。ここでは、あるサービスが自分の機能を外部programへ公開するinterfaceとして説明します。呼び出し側はendpoint、operation、認証、request / response形式をサービスごとに扱います。

MCP（Model Context Protocol）は、AI Hostと外部Serverの間で機能を発見し、やりとりするためのprotocolです。AIアプリ側はClientを介してServerと通信し、ServerはTools、Resources、Promptsなどを公開できます。MCP自体は業務dataを保持するdatabaseでも、特定のservice APIの代替でもありません。

表は横にスクロールできます

観点	Service API	MCP
主な相手	特定のserviceやbackend	対応するAI Host / ClientとMCP Server
interface	service固有のendpoint、operation、SDK等	protocolで定める共通のmessageとcapability
機能定義	serviceごとに確認	Serverが公開するTools / Resources / Prompts
変更責任	API提供者とintegration実装者	MCP Server、Host、接続設定の各担当
向く場面	特定systemを決まった形で直接操作	複数AI Hostへ共通の機能を公開したい

APIにRESTが必須というわけではありません。serviceによってGraphQL、RPC、SDK等もあります。MCPもAPIと対立する方式ではなく、別の層として組み合わせられます。

CRMを例にした構成

顧客管理serviceに、顧客を検索するAPIとrecordを更新するAPIがあるとします。固定の社内batchが夜間に同期するだけなら、batch programがAPIを直接呼ぶ構成が分かりやすいでしょう。認証、入力validation、retry、error handlingをそのprogramが担当します。

一方、複数のAIアプリから「顧客を探す」「契約状況を読む」といった機能を使わせたいなら、MCP Serverを介す設計を検討できます。Serverは既存APIを呼び出し、Hostには「顧客を検索するTool」「契約概要を読むResource」などの形で公開します。

構成イメージ：

AI Host → MCP Client → MCP Server → CRM API → CRM

この場合でもCRM APIは残っています。MCP ServerがAPIを包み、AI向けの機能名・入力・結果・権限境界を設計しているためです。APIの利用先が一つ増えるのではなく、AIアプリ向けの中継面が加わります。

どちらから始めるかの判断

表は横にスクロールできます

条件	第一候補	理由
決まったsystemから一定の処理を実行	API直接連携	処理順や入力が固定なら構成を小さくできる
複数のAI Hostから同じ機能を使う	MCPを検討	HostとServer間の接続形式を共通化できる
AIに候補を提示させ、都度異なるtoolを選ばせる	MCPを検討	公開機能をAI Hostが扱う形にできる
独自の高頻度処理、厳密なtransactionが中心	API直接連携を先に評価	業務serviceが保証する挙動を直接使いやすい
APIが存在しない、または権限が過剰	先に境界を設計	MCPを置いても安全なAPIや権限は自動で生まれない

「AIから使うならMCP」と決める必要はありません。単一Host・単一処理であれば、Host固有のAPI連携や既存connectorで十分な場合もあります。反対に、一つのMCP Serverを複数Hostで使えるかは、それぞれが同じtransport、認証、capabilityを実装しているかで決まります。

interfaceを設計するときの確認項目

APIを直接呼ぶ場合は、利用するoperationとHTTP method、authentication scope、request schema、responseとerror形式、rate limit、retry条件を確認します。成功応答だけでなく、timeout、権限不足、対象recordなし、重複requestのときに業務状態がどうなるかを決めます。

MCP Serverを置く場合は、これに加えて、AI Hostへ公開するTool / Resourceの単位、AIに渡す説明、実行時の承認、利用者別の権限を決めます。特に更新や送信を行うToolは、APIの権限が読取だけか書込可能かを分け、previewと確定操作を別にできるか検討します。AIがtoolを呼べることと、利用者がその操作を許可したことは同じではありません。

認証と権限は別々に確認する

MCP経由でも、最終的にbackendへ接続する認証と権限の範囲は設計が必要です。Serverが一つの共有credentialを全利用者に使うのか、利用者のidentityを引き継ぐのかで、誤操作や監査の影響が変わります。Host上のpermission表示だけを見て、CRM側のrecord-level accessまで適用されると推測しないでください。

API keyやOAuth tokenをどこに保存するか、退職・異動時に誰が失効させるか、操作logに何を記録するかも決めます。request / responseへ顧客本文やsecretが含まれるなら、debug logやerror reportへそのまま出さない設計にします。認証が成功しても、想定外のdataを読めないかは別のtestで確認します。

例：問い合わせの確認から返信まで

問い合わせの内容とCRM記録を照合する作業では、最初に「検索」「読取」「返信送信」を別operationとして分けます。API直接連携なら、programの処理順を固定し、CRMから取得した情報を規則で判定してから返信案を作成できます。結果が一定で再現性を優先する業務では、この構成が扱いやすい場合があります。

MCPを使う構成では、AI Hostへread-onlyの検索Toolを公開し、関連recordを読むResourceを渡します。返信案の作成まではAIへ任せても、外部送信は別Toolとし、送信先・本文・添付を担当者が確認した後に実行します。MCPを選ぶ理由はAIが自由に動けることではなく、AI向けに公開する機能を明確に定義し、接続先を整理することです。

どちらを採用しても、問い合わせID、利用したrecord、作成した案、承認者、送信結果を追跡できるようにします。APIやMCPの標準対応だけで、業務承認や監査が自動的に完成するわけではありません。

よくある取り違え

• APIを使えばAIは使えない： AI Hostやアプリが直接APIを呼ぶ構成もあります。

• MCPならAPI不要： Serverの内部で既存service APIを呼ぶ構成があります。

• MCP Serverは別のdata store： 多くの場合、既存serviceへの接続面やadapterとして機能します。

• MCP対応なら全Hostで動く： Host側の対応capability、transport、認証、versionを確認します。

• APIは低水準、MCPは高水準と固定できる： interfaceの粒度は個別設計によって異なります。

• MCPを通せば権限が安全になる： Server・Host・backendで必要なaccess controlを設計し、テストする必要があります。

導入前に小さく確かめる

本番CRMへつなぐ前に、テストworkspaceで一つの読取処理を選び、API直接呼び出しとMCP経由のそれぞれについて、返るrecord、permission、error、監査logを比較します。更新・削除・外部送信を最初のtestへ含めないでください。複数Hostで再利用する計画がある場合は、各Hostの接続設定と認証の差も記録します。

仕様の細部は更新されます。MCPの実装ではclientとserver双方の対応version、transport、認証方式を公式資料で確認し、service API側も利用するversionとdeprecation条件を確認してください。記事の概念比較だけを根拠に実装を決めず、導入時点の契約と仕様を照合します。

AIものさしの判断

APIはserviceの機能を呼ぶ接点、MCPはAI Hostと外部機能をつなぐ共通protocolとして捉えると、比較対象の層が見えます。処理が固定された一つの連携ならAPI直接利用から始め、複数Hostへ同じAI向け機能を公開する必要があればMCP Serverを評価します。どちらの場合も、認証、最小権限、実行確認、失敗時の扱いは個別に設計してください。