MCPとREST API・LangChainの違いは？「ただのREST」と見るとハマる理由をLLM視点で解説

Q: MCPとREST APIの違いは何ですか？

REST APIは人間や決め打ちロジックが使うことを前提にしたHTTPインターフェースですが、MCPはクライアントがLLMであることを前提に設計されたプロトコルです。ツール名・引数名・説明文がそのままLLMに読ませるプロンプトになる点が決定的な違いです。

Q: MCPとLangChainはどちらを使えばよいですか？

LangChainはアプリ内でLLMの推論フローやエージェントロジックを組むフレームワーク、MCPはツール群を標準プロトコルで公開するための配線レイヤーです。排他的な選択ではなく、LangChainでエージェントを組みつつ、そのツール実装をMCPサーバとして公開するといった併用が現実的です。

Q: MCP導入の際に気をつけるポイントは何ですか？

最大のポイントは、ツール定義を人間向けのAPI仕様ではなく「LLMに読ませるプロンプト」として設計することです。REST APIと同じ感覚で抽象的な名前や説明を付けると、LLMがツールの意味を誤解し、誤ったツール選択やパラメータ指定につながります。

Q: LangChainとMCPの関係を一言で言うと？

どちらも「LLMにツール利用方針を書かせる」という発想は近いですが、LangChainはアプリ内のロジックレイヤー、MCPはツールを外部に標準化して公開する配線レイヤーという役割の違いがあります。

その他のエッセイはこちら

はじめに：なぜ「MCP＝REST API」という説明にモヤっとするのか
REST と RPC（JSON-RPC）と MCP の位置づけ
LangChain側の世界観：裏側の few-shot でツール利用方針を書かせる
1. LangChain は「ロジック側のフレームワーク」
MCP側の世界観：ツール群を標準プロトコルで公開する「配線側」
1. MCP は「ツール公開のための配線レイヤー」
MCPとLangChainの違いをベン図で整理：発想は近いが、役割とレイヤーは別
なぜ「MCP＝ただのREST API」と見ると危険なのか
MCPとREST API・LangChainの違いまとめ
実務で意識したい設計ポイント
FAQ
まとめ
参考リンク

はじめに：なぜ「MCP＝REST API」という説明にモヤっとするのか

Model Context Protocol（MCP）は、LLMと外部ツールやデータソースをつなぐための新しいプロトコルです。「AIアプリにとってのUSB-C」といった紹介も増えてきました。

一方で、現場でよく聞くのがこんな捉え方です。

「要するに、ChatGPT から叩ける新しい REST API でしょ？」

個人的には、この説明だけで進めるとけっこう危ないと思っています。理由はシンプルで、

クライアントが LLM そのもの であること
ツール定義（名前・説明・引数）が LLMに読ませるプロンプト であること

という、本質的な前提が抜け落ちやすいからです。

この記事では、

LangChain 的なツール利用の世界観をスタートラインにしつつ
MCP を「LLMが読む API 仕様」としてどう捉えるべきか
REST と RPC（JSON-RPC）との関係をざっくり整理しつつ
なぜ「MCP＝RESTっぽいAPI」とだけ見るとハマるのか

を、ベン図的に整理していきます。

REST と RPC（JSON-RPC）と MCP の位置づけ

まず、用語をざっくりそろえておきます。

REST

URL = リソース（/users/123 など）
HTTP メソッド = 意図（GET/POST/PUT/DELETE）
状態表現をやり取りする設計スタイル

「リソース指向の Web API の作り方」が REST です。

RPC / JSON-RPC

「関数（メソッド）を呼ぶ」イメージの設計スタイル
JSON-RPC はその一種で
{"method": "searchUser", "params": {...}}
のような形で「どの処理を、どんな引数で呼びたいか」を送るプロトコル
HTTP 上で運ぶことも多いけど、REST とは別物

MCP

クライアント（ChatGPT アプリなど）と
MCPサーバ（ツール提供側）

の間をつなぐLLM向け RPC プロトコルで、中身のメッセージ形式に JSON-RPC を採用しているイメージです。

つまり
「REST の中に JSON-RPC がいる」ではなく、
API という大きな箱の中に REST と RPC が並んでいて、 MCP は JSON-RPC ベースの “LLM特化 RPC”
という整理がしっくり来ます。

この上で、「REST 的な API 設計の癖で MCP を見るとズレるよね」という話に入っていきます。

LangChain側の世界観：裏側の few-shot でツール利用方針を書かせる

先に、LangChain がやっていることを簡単に整理します。

LangChain は「ロジック側のフレームワーク」

LangChain は LLM アプリを組むためのフレームワークで、特に Agents は次のようなことをしています。

利用可能なツール一覧（名前・引数・説明）を LLM に渡す
裏側で few-shot プロンプト（ReAct っぽい書式など）を仕込む
LLM に「どのツールをどう呼ぶか」を書かせる
ホスト側がその出力をパースして実際の関数を呼ぶ

ユーザからは見えませんが、ライブラリ側では

Thought:
Action:
Observation:

のようなフォーマットや、tool calling 用 JSON スキーマなどを few-shot として渡していて、LLM のツール利用方針を“裏側のプロンプト”で制御しているイメージです。

ここから言えるのは：

LangChain =「LLMにツール利用方針を書かせるロジック側のフレームワーク」

ということです。
ツール実装（DB 検索、外部 API 呼び出し…）はアプリ内の関数で書かれ、LangChain は「どの関数を、いつ、どんな引数で呼ぶか」を LLM に決めさせる役割を担います。

MCP側の世界観：ツール群を標準プロトコルで公開する「配線側」

一方、MCP は立っているレイヤーがまったく違います。

MCP は「ツール公開のための配線レイヤー」

MCP は、次のようなやり取りをJSON-RPCで標準化したプロトコルです。

どんな MCP サーバがあるか
そのサーバがどんなツール／リソースを提供しているか
特定のツールをどの引数で実行するか

MCP サーバは、クライアントに対して次の情報を広告します。

ツール名（name）
引数の JSON Schema（型・必須／任意・説明文）
ツールの説明（description）

クライアント側（ChatGPT アプリなど）は、このメタデータを LLM に見せて、

「こういうツールがあるから、必要なら使っていいよ」

と指示できます。

ここから導ける整理は、

MCP = LLM向けツール群を「どのクライアントからも同じやり方で呼べるようにする配線レイヤー」
（中身のプロトコルとして JSON-RPC を使う）

ということです。
LangChainのようにエージェントロジックを提供するのではなく、「ツールの出し口」を標準化する役割にフォーカスしています。

MCPとLangChainの違いをベン図で整理：発想は近いが、役割とレイヤーは別

ここまでをベン図で文章化すると、だいたい次のようになります。

MCPとLangChainの違いをベン図で整理し、差と共通部分を明確化し、MCPを「ただのREST API」と見ると、LLMが読む前提（名前・説明＝プロンプト）を落としがちという指摘を示す図。 — MCPとLangChainの違いと共通項をベン図で整理

LangChain（左の円）

LLMアプリのロジック（チェーン／エージェント）
裏側で few-shot プロンプトを使って
「どのツールをどう使うか」を LLM に書かせる

MCP（右の円）

LLM向けツール群を標準プロトコルで公開する「配線」
JSON-RPC ＋ JSON Schema でツールの入出力や説明を定義する

共通部分（重なり）

LLMにツール利用方針を書かせるという発想
ツール名・説明文・スキーマを LLM が読み、「どのツールを、どんな引数で呼ぶか」を出力する

つまり、

アイデアの部分はかなり近いけれど、
LangChain = ロジック側、MCP = 配線側
なので、実務上は「別物」として扱った方が良い

という整理になります。

なぜ「MCP＝ただのREST API」と見ると危険なのか

いよいよ本題です。

REST脳で設計すると、クライアントを「人間 or 固定ロジック」とみなしがち

REST 的な Web API を設計していると、次のような前提でエンドポイントを作りがちです。

クライアントは仕様書を読む人間 or 手書きロジック
パラメータ名はチーム内で分かればOK
説明文はざっくりでも、実装側で何とかする

しかし MCP ツールの「クライアント」は LLM 本体 です。

ツール定義＝ LLM に読ませるプロンプト

MCP のツール定義に含まれる要素は、すべて LLM に読ませるテキスト＝プロンプト になります。

ツール名
引数名
description
JSON Schema 内の description

にもかかわらず、RESTノリで

ツール名：doProcessV2
引数名：param1, param2
説明：処理を実行します

みたいに定義すると、LLM は

何の処理なのか分からない
類似ツールとの使い分けができない
引数の意味が想像できず、常に同じ値を入れてしまう

といった、「モデル側から見て使いづらい API」 としてしか扱えません。

結果として、

「MCP サーバは作ったのに、エージェントが全然うまく使ってくれない」

という状態になります。
原因はロジックではなく、ツール定義を「人間向けの REST API」として扱ってしまったことだったりします。

MCPツール設計のよくあるアンチパターン

MCPをREST API的に扱うと、次のようなアンチパターンが出がちです。

ツール名・引数名が抽象的（doProcessV2, param1, param2 など）
description が「処理を実行します」レベルで情報量ゼロ
類似ツールの使い分けが説明文から読み取れない
事前条件を満たさないとすぐエラーを返すだけで、LLMがリカバーしづらい
レスポンス形式が人間向けメッセージのままで、LLMから見るとパースしづらい

このあたりは、「人間に優しいAPI」と「LLMに優しいAPI」の設計ポイントがズレている例だと思っておくと整理しやすいです。

MCPとREST API・LangChainの違いまとめ

「違い」が知りたい人向けに、ここまでの内容をざっくり表にします。

観点	MCP	REST API	LangChain
想定クライアント	LLM（＋それをホストするクライアント）	人間／固定ロジック	LLM（アプリ内でホストされる）
主な役割	LLM向けツール群を標準プロトコルで公開する「配線」	汎用的なWebサービスを公開するためのHTTPインターフェース	LLMアプリ内のロジック（チェーン／エージェント）
通信スタイル	JSON-RPC ベースの RPC	HTTP＋RESTスタイル（リソース指向）	プロセス内呼び出し／HTTP など実装依存
LLMとの関わり方	ツール定義がそのままLLMに読ませるプロンプト	通常はLLMを意識しない	LLMにツール利用方針を書かせる中心的レイヤー
典型的な使い方	ChatGPT・IDE拡張・社内LLMクライアントからの共通ツール利用	SPA/モバイルアプリ／社内システムからのHTTP API呼び出し	外部ツール・APIをラップしてエージェントに使わせる

ポイントだけ抜き出すと：

MCP … LLM向けツール群を公開するためのRPC配線。ツール定義＝プロンプト。
REST API … 汎用Webサービス向け。人間／固定ロジック前提。
LangChain … アプリ内でLLM＋ツールのロジックを組むフレームワーク。

この「三者の立ち位置」を頭に置いておくと、設計時の混乱がかなり減ります。

実務で意識したい設計ポイント

LangChain 的な世界観から逆算すると、MCP を実装するときに意識したいポイントは次の3つです。

1. ツール名・引数名・説明文を「LLM向けプロンプト」として設計する

ツール名は用途が伝わるものにする（例：search_customer_by_email）
引数名も意味のあるものにする（id ではなく customer_id、q ではなく query など）
description には「何をするツールか」「どんなときに使うべきか」を具体的に書く

2. LangChain の Tool 設計と同じ感覚で名前と説明を決める

LangChain で Agent を組むときは、

このツールはどのシナリオで使わせたいか
どのツールを優先的に選ばせたいか／fallbackにしたいか

といったことを意識しながら、ツール名や説明を書きます。

MCP でもまったく同じで、

「このツール定義を LLM に見せたとき、どう解釈されるか」

を意識して設計すると、REST 的な落とし穴を避けやすくなります。

3. 「LangChain vs MCP」ではなく「LangChain × MCP」で考える

LangChain と MCP は、選択肢として対立しているわけではありません。

アプリ内ロジックは LangChain の Agent / Chain で組みつつ
そのツールの一部を MCP サーバとして外出しし
ChatGPT や IDE プラグインなど、別クライアントからも同じツールを利用する

といった構成が取りやすくなります。

このときのメンタルモデルは、

「LangChainで扱っていた“ツール側”を、標準化して外出ししたのが MCP」

くらいに考えると、設計のブレが減るはずです。

MCPツール定義チェックリスト

最後に、設計レビュー用のチェックリストを置いておきます。

ツール名から「何を・何で」するかが推測できるか？
引数名にドメインの意味（customer / order / email など）が含まれているか？
description に「どんなときに使うべきか」が書いてあるか？
類似ツールの使い分けがdescriptionから分かるか？
LLMが読んだだけで安全なデフォルト挙動を選べるか？

この辺りを満たしていれば、「REST脳でそのまま定義したMCPツール」からはかなり卒業できているはずです。

FAQ

MCPとREST APIの違いは何ですか？

A. REST API は主に人間や固定ロジックからの利用を前提とした汎用 Web API で、リソース指向・HTTP メソッド中心の設計スタイルです。一方 MCP は、クライアントが LLM であることを前提に設計された RPC プロトコルで、ツール名・引数名・説明文といったメタデータが、そのまま LLMに読ませるプロンプト として扱われます。

MCPとLangChainはどちらを使えばよいですか？

A. 「どちらか一方」ではなく、役割の違うレイヤーとして併用するのが自然です。

LangChain：アプリ内での LLM 推論フローやエージェントロジックを組むフレームワーク
MCP：そのツール実装を標準プロトコルで外出しし、ChatGPT や IDE などからも再利用できるようにする配線レイヤー

たとえば「LangChain でエージェントを組みつつ、その一部のツール実装を MCP サーバとして公開する」といった構成が取りやすくなります。

MCP導入の際に気をつけるポイントは何ですか？

A. 最大のポイントは、ツール定義を「LLM向けプロンプト」として設計することです。

ツール名・引数名・description に用途や前提条件をきちんと埋め込む
REST API のつもりで抽象的な名前や雑な説明を付けない
類似ツールの使い分けを LLM が判断できるようにする

といった観点で設計・レビューすると、「MCPサーバはあるのにエージェントが使いこなしてくれない」という状態をかなり防げます。

LangChainとMCPの関係を一言で言うと？

A. 一言でまとめると、

LangChain＝ロジック、MCP＝配線

です。どちらも「LLMにツール利用方針を書かせる」という発想は近いものの、LangChain はアプリ内の推論フロー、MCP は外部ツール公開の標準プロトコルという、レイヤーと責務の違うコンポーネントとして捉えるのがポイントです。

まとめ

MCP・REST API・LangChainは、どれも「外部とのインターフェース」という意味では似た顔をしていますが、想定しているクライアントと役割のレイヤーはかなり違います。
特にMCPは「LLMが一番最初のユーザーであるAPI」であり、ツール名・引数名・説明文といったメタデータがそのままLLMに読ませるプロンプトになります。

一方で、LangChainはアプリケーション内でLLMとツールの使い方（チェーン／エージェント）を組み立てるロジックレイヤー、REST APIは人間や固定ロジック向けの汎用Webインターフェースという位置づけです。
このレイヤーの違いを押さえたうえで、「LangChainでのツール設計感覚をMCPツール定義に持ち込む」ことで、LLMファーストなAPI設計に寄せていくことができます。

最後に3行でまとめると：