本記事は、2026年7月13日時点で最新と表示されているMCP Specification 2025-11-25を基準に解説しています。
ChatGPT、Claude、Codex、Cursorなどを使っていると、「MCP」という言葉を目にする機会が増えました。しかし、AIに外部機能を使わせるだけなら、REST APIやFunction Callingでも実現できそうに見えます。
では、MCPは新しいAPIなのでしょうか。それともFunction Callingの代替なのでしょうか。
先に結論を示すと、3つは別のレイヤーを担当しています。
REST APIはシステムの機能を公開する仕組み、Function Callingはモデルが使う機能を選ぶ仕組み、MCPはAIアプリケーションと外部システムを接続する共通ルールです。
MCPはAPIやFunction Callingを置き換えるものではありません。この記事では、GitHub Issueを検索・作成する機能を例に、3つの関係とMCP Serverが必要になる条件を整理します。
MCPが解決しようとしている問題
AIはそのままでは外部システムを操作できない
LLMは入力された文章をもとに回答を生成できます。しかし、モデル単体ではデータベースを検索したり、GitHub Issueを作成したり、社内カレンダーを更新したりできません。
そのため、AIアプリケーション側には、モデルと外部システムをつなぐ処理が必要です。GitHubを例にすると、認証情報を管理し、GitHub APIへリクエストを送り、レスポンスをモデルが扱いやすい形式へ変換しなければなりません。
AIアプリと接続先が増えると専用実装も増える
AIチャット、コーディングエージェント、社内アシスタントのそれぞれから、GitHub、データベース、社内API、ローカルファイルを使う状況を考えてみましょう。
共通規格がなければ、ツールの定義、接続処理、結果の変換、エラー処理などを組み合わせごとに実装することになります。
MCPがない場合
AIアプリA ── 専用実装 ── GitHub
AIアプリA ── 専用実装 ── Database
AIアプリB ── 専用実装 ── GitHub
AIアプリB ── 専用実装 ── DatabaseMCPが解決しようとしているのは、この接続部分の断片化です。AIアプリケーションと外部システムの間に共通の約束を設けることで、同じ機能を複数のMCP対応アプリから利用しやすくします。
MCPとは何か
MCP（Model Context Protocol）は、AIアプリケーションを外部のデータ、ツール、ワークフローへ接続するためのオープンなプロトコルです。公式ドキュメントでは、異なる機器を共通端子で接続するUSB-Cに例えられています。MCP公式イントロダクション
初心者向けに言い換えると、次のようになります。
MCPは、AIが利用できるデータや機能を、決められた形式で公開・利用するための共通ルールです。
MCPの通信はJSON-RPC 2.0を基礎とし、接続の初期化、プロトコルバージョンと能力のネゴシエーション、機能の発見、呼び出し、通知などを定義します。Serverは主に次の機能を公開できます。MCP Specification 2025-11-25
- Tools：Issueの作成やデータベース検索など、AIが呼び出せる処理
- Resources：ファイルやレコードなど、コンテキストとして利用できるデータ
- Prompts：再利用可能なメッセージやワークフローのテンプレート
MCP自体はAIモデルでも業務APIでもありません。既存のAPI、データベース、ローカルプログラムを、AI向けの共通インターフェースとして公開するためのレイヤーです。
MCP Host・Client・Serverの関係
MCPでは、Host、Client、Serverという3つの役割を分けて考えます。公式アーキテクチャでは、Hostが接続先ごとにMCP Clientを作り、各Clientが対応するServerとの接続を維持します。MCPアーキテクチャ概要
MCP Host
MCP Hostは、ユーザーが操作するAIアプリケーションです。AIチャット、IDE、コーディングエージェントなどが該当します。
Hostはユーザーとの対話やLLMの呼び出しに加え、複数のMCP Clientの管理、Serverから取得した情報のモデルへの受け渡し、ツール実行の承認などを担当します。
MCP Client
MCP Clientは、Hostの内部で特定のMCP Serverとの通信を担当するコンポーネントです。
「ユーザーが操作するアプリ全体がClient」と考えると混乱しやすい点に注意してください。アプリ全体がHostであり、その中でServerとの接続を維持するコネクターがClientです。基本的には、1つのClientが1つのServerとの専用接続を担当します。
MCP Server
MCP Serverは、AIへ提供したいデータや機能をMCP形式で公開するプログラムです。
例えば、GitHub Issueを検索・作成するServer、社内データベースを検索するServer、ローカルファイルを読み取るServerなどを用意できます。Serverの裏側では、既存のREST APIやデータベースクライアントをそのまま利用できます。
ユーザー
↓
MCP Host
├── MCP Client A ── MCP Server A ── GitHub API
├── MCP Client B ── MCP Server B ── Database
└── MCP Client C ── MCP Server C ── Local FilesMCP Serverという名前でも、インターネット上の独立したWebサーバーとは限りません。ローカルプロセスとして動作するServerと、ネットワーク越しに接続するリモートServerの両方があります。
MCPとREST APIの違い
REST APIはシステムの機能を公開する
REST APIは、Web、モバイル、バックエンドなどのアプリケーションに、システムのデータや処理を提供するインターフェースです。
GitHub APIを利用するプログラムは、エンドポイント、HTTPメソッド、認証方法、リクエストとレスポンスの形式を理解して呼び出します。これはAI専用の仕組みではありません。
MCPはAI向けの接続方法を共通化する
MCP Serverは、AIアプリケーションが利用できるToolsやResourcesを共通形式で公開します。ClientはServerへ接続した後、tools/listなどのメソッドを使って利用可能な機能を取得できます。
MCP Serverが実際の業務処理をすべて持つ必要はありません。次のように、既存のREST APIを呼び出すアダプターとして実装できます。
AIアプリケーション
↓ MCP
MCP Server
↓ HTTP
GitHub REST API観点 | REST API | MCP |
|---|---|---|
主な目的 | システムのデータや処理を公開する | AIへコンテキストやツールを提供する |
主な利用者 | Web、モバイル、バックエンドなど | MCP Host、AIエージェント |
機能の把握 | APIドキュメントやOpenAPIなど | ServerからToolsなどを取得 |
通信 | 一般的にはHTTP | STDIOやStreamable HTTPなど |
相互関係 | MCP Serverから呼び出せる | REST APIをラップできる |
したがって、MCPはREST APIの代替ではありません。REST APIが業務機能を公開し、MCP ServerがそれをAIから利用しやすい形へ変換する構成を取れます。
MCPとFunction Callingの違い
Function Callingが担当すること
Function CallingまたはTool Callingは、利用可能な関数の名前、説明、引数スキーマをモデルへ渡し、モデルに必要な関数と引数を出力させる仕組みです。
モデル自身が関数を実行するわけではありません。通常はアプリケーションがモデルの出力を受け取り、対象の処理を実行し、その結果を再びモデルへ渡します。OpenAI Function Callingガイド
GitHubの例なら、モデルは「Issueを検索するべきだ」と判断し、search_issuesと検索条件を返します。その後のGitHub API呼び出しはアプリケーション側の役割です。
MCPが担当すること
MCPは、ツールを提供するServerとの接続、初期化、能力の確認、Tools・Resources・Promptsの発見、呼び出し、結果の返却を共通化します。
最も重要な違いは次の一文です。
Function Callingはモデルがどの機能を使うかを決める仕組み、MCPはその機能をAIアプリケーションへ提供するための接続規格です。
両者は競合せず、同じ処理の流れで組み合わせられます。
ユーザーの依頼
↓
LLMがツールと引数を選択
↓ Function Calling／Tool Calling
HostがMCP Clientを通じて呼び出す
↓ MCP
MCP Serverが処理し、結果を返すHostはMCP Serverから取得したToolの定義をモデルへ提示できます。モデルがそのToolを選択したら、HostがClientを通じてServerへ実行を依頼します。OpenAIのツール機能でも、Function CallingとRemote MCPは利用可能な別々のツール方式として掲載されています。OpenAI Toolsガイド
AIに直接API仕様を教える方法との違い
MCPを使わず、OpenAPIや独自のJSON SchemaをFunction Calling用のツール定義へ変換する方法もあります。
API仕様
↓ 変換
Function Callingのツール定義
↓
AIアプリ固有の実行処理
↓ HTTP
REST APIAIアプリが1つだけで、接続するAPIや関数も少ない場合、この方法はシンプルです。既存の仕組みが短いコードで安定しているなら、MCP Serverを追加しても得られる効果が小さい可能性があります。
一方、AIアプリや接続先が増えると、ツール定義の生成、API呼び出し、認証情報の管理、エラー変換、モデル向けの結果整形などを各アプリが抱えやすくなります。MCPを使えば、AI向けのインターフェースをServer側へまとめ、複数の対応Hostから再利用できます。
OpenAI CookbookにもOpenAPI仕様をFunction Calling定義へ変換する例がありますが、現在はアーカイブ済みで、古いモデルやAPIを参照する可能性があると明記されています。OpenAPIとFunction Callingの例
MCPが向いているケース・向いていないケース
MCPが向いているケース
次の条件に当てはまるほど、MCPを採用する意義が大きくなります。
- 同じ機能を複数のAIアプリケーションから利用したい
- 社内データや業務ツールをAIエージェントへ公開したい
- 利用可能なツールをServerから取得し、変更にも追従したい
- ローカルツールとリモートサービスを共通の考え方で接続したい
- AIクライアントごとの専用統合を減らしたい
- 将来、MCP対応Hostを追加する予定がある
例えば、GitHub Issueの検索・作成機能を社内チャット、IDE、コーディングエージェントから共通利用したいなら、MCP Serverとして切り出す価値があります。
MCPを使わなくてもよいケース
次のような場合は、Function Callingと通常の関数実装だけで十分なことがあります。
- AIアプリケーションが1つだけ
- 使用する関数が2〜3個程度で固定されている
- 既存のFunction Calling実装が単純で安定している
- AI以外の通常システム同士を接続したい
- 他のMCP Hostから再利用する予定がない
- LLMの選択を介さない決定的な処理を実装したい
判断基準は「MCPが流行しているか」ではなく、AI向け接続の標準化と再利用が必要かどうかです。小さな単一アプリでは直接実装が簡単で、統合先が増えるほどMCPの価値が高まりやすくなります。
よくある誤解
MCPは新しいAPIですか？
APIそのものというより、AIアプリケーションと外部システムの接続方法を定めたプロトコルです。MCP Serverの内部でAPIを呼ぶこともできます。
MCPがあればREST APIは不要ですか？
不要にはなりません。既存のREST APIをMCP Serverでラップする構成は、代表的な組み合わせ方の一つです。
MCPとFunction Callingはどちらを使うべきですか？
二者択一ではありません。MCPから取得したToolをモデルに提示し、その選択にFunction CallingやTool Callingを利用できます。
MCP Serverは必ずインターネット上に置きますか？
必ずしもそうではありません。MCP Serverはローカルでもリモートでも実行できます。どちらを選ぶかは、利用するHost、共有範囲、運用方法などによって決まります。
REST API・Function Calling・MCPの比較
項目 | REST API | Function Calling | MCP |
|---|---|---|---|
分類 | システムインターフェース | モデルAPIの機能 | AI統合プロトコル |
主な目的 | データや処理を外部公開する | モデルにツールと引数を選ばせる | AIと外部システムを標準接続する |
ツールの定義 | API仕様・OpenAPIなど | JSON Schemaなど | ServerがToolsとして公開 |
実行主体 | 呼び出し元アプリ | アプリケーション | Host・Client・Serverが連携 |
主な再利用先 | あらゆるアプリ | 基本的に実装したAIアプリ | MCP対応Host |
相互関係 | MCP Serverから呼べる | MCP Toolの選択に使える | APIとFunction Callingを組み合わせられる |
GitHub Issueの例に置き換えると、REST APIはGitHubの機能をHTTPで公開し、Function CallingはIssue検索ツールを使うかモデルに判断させ、MCPはそのツールをAIアプリへ共通形式で提供します。
まとめ
3つの違いは、次のように整理できます。
- REST API：システムのデータや機能を公開する
- Function Calling：モデルが使用する機能と引数を決める
- MCP：AIアプリケーションと外部システムの接続方法を標準化する
MCPを理解するときは、APIの代替技術ではなく、既存APIやデータソースをAIへ接続するための共通レイヤーとして考えると整理しやすくなります。
MCP Serverを作るべきか迷ったら、「同じAI向け機能を複数のHostで再利用したいか」「接続先の増加に備えて統合方法を共通化したいか」を確認してください。答えがどちらも「いいえ」なら、まずは通常のFunction Callingから始めても問題ありません。
次の記事では、最小構成のMCP Serverを作り、AIクライアントからToolを呼び出すまでの実装を解説します。