AIに新しい機能を追加する設定画面を開くと、「MCP」「API」「JSON」というアルファベットの言葉が並んでいることがあります。どれも同じようなIT用語に見えるため、どれを選べばいいのか、あるいはどう使い分けるのかと混乱してしまうかもしれません。
しかし、これらは同列に並べて選ぶような言葉ではありません。AIがデータを受け取り、道具を使う仕組みの中で、それぞれ全く違う技術的な役割を担当しています。ただのイメージや例え話で終わらせず、実際の通信において何をしているのかを区別することが大切です。
それらの違いを分かりやすく紐解くために、ここでは「図書検索」という一つの動作を例にします。検索の主体が誰で、どのような形でデータを受け渡していくのか、その裏側の手順を順番に追ってみましょう。
MCP・API・JSONは同じ種類の言葉ではありません
AIの設定画面や説明書を読んでいると、「MCP」「API」「JSON」という三つの言葉が並んで出てくることがあります。これらは似たような技術の名前のようにも見えますが、実は同じ種類の言葉ではありません。入口での混同を防ぐために、まずはそれぞれの役割を大きく三つに分けます。
一つ目のJSON（ジェイソン）は、データの表現形式です。プログラムの中で使うデータについて、構造化データを直列化（連続した文字に変換）する軽量なテキスト形式であり、オブジェクト（データの塊）や配列（データの並び）などを表します。
二つ目のAPI（エーピーアイ）は、ソフトウェア同士が要求と応答をやり取りするための接点です。あるソフトウェアが、別のソフトウェアやハードウェアと対話するための機能と規則の集合を指します。
三つ目のMCP（エムシーピー）は、AIが資料を見つけたり道具を使ったりするための接続規約（プロトコル）です。大規模言語モデル（LLM）と呼ばれるAIのアプリケーションと、外部のデータ源や道具（ツール）を統合するオープンプロトコル（公開された手順）です。
JSONはデータ形式、APIは接点、MCPはAI用接続規約を担当します。役割は異なりますが、一つの処理で組み合わせて使う場合があります。
例えば、AIが外部のシステムから情報を取り出す場面を考えます。AIアプリはMCPの規約に従って、使える道具や資料を発見できます。MCPサーバーが外部APIを使う構成では、APIへ要求を送り、応答を受け取ります。要求や応答にはJSONがよく使われますが、APIによっては別の形式も使います。
つまり、MCPがAPIの上位互換になるわけではなく、それぞれが違う階層で役割を担当し、連携して動いています。次の項目からは、まずデータの形であるJSONについて、さらに詳しく見ていきましょう。
JSONは値を表しますが、通信や操作はしません
JSONは、データを文字で書き表すためのルールです。たとえば、図書のデータをJSON形式で書くと次のようになります。
{
"書名": "銀河鉄道の夜",
"著者": "宮沢賢治",
"初版年": 1934,
"主題": ["童話", "ファンタジー"]
}この例の全体を囲む波括弧 { } の部分は、名前と値の組をまとめた「object」と呼ばれる形式です。また、角括弧 [ ] で囲まれた主題の部分は、順序付きのリストである「array」を表します。JSONはこのようにして、文字列や数値、objectやarrayなどを表すことができます。
しかし、JSONはデータの書き方を定めるだけです。ECMA-404によると、JSONの構文自体はデータの意味や動作を決めるものではありません。
図書データをJSON形式で保存しても、システムは図書の検索、貸出予約、外部送信を自動では始めません。JSONは値を表現します。送受信や操作には別の仕組みが必要です。
JSONはAPIそのものではありません。APIの要求や応答にはJSONがよく使われますが、別の形式も選べます。
例えば、Open Library RESTful APIはJSONのほかにRDFでも資料を返します。JSONはデータ形式で、APIは通信や操作の接点です。
APIはソフトウェア同士が要求と応答を交わす接点です
JSONというデータ形式だけでは通信や操作ができないと説明しましたが、ここで活躍するのがAPIです。APIとは、別ソフトウェアと対話する機能と規則を定めた接点のことです。私たちが普段使うアプリ内のプログラムは、このAPIに向かって要求を送り、その結果として応答を受け取ります。
Open LibraryのSearch APIを例にします。プログラムはhttps://openlibrary.org/search.jsonへ要求を送ります。
Search APIではq、fields、limitなどを指定できます。qは検索語、fieldsは受け取る項目、limitは取得件数の上限を表します。
アプリ内のプログラムが要求を送ると、APIは条件に合う本を探し、JSON形式で結果を返します。
AIの言語モデルがURL文字列を作るだけでは、通信は始まりません。アプリのプログラムが要求を送信して、初めてJSONデータを受け取れます。
APIが正常にJSONを返しても、検索内容が妥当とは限りません。Open Libraryのsubjectタグには完全な一覧がなく、異なるタグが使われる場合があります。
APIの応答成功と、検索漏れや分類の妥当性は分けて確認します。
MCPはAIが資料や道具を見つけて使う手順をそろえます
これまでに、JSONはデータ形式であり、APIはソフトウェア同士がやり取りする接点だと説明しました。では、AIアプリからさまざまなAPIを利用するにはどうすればよいでしょうか。そこで登場するのが、AIが資料や道具を見つけて使う共通の手順である「MCP」です。
MCPの仕組みは、「ホスト」「クライアント」「サーバー」という役割に分かれています。まず、AIアプリ全体の責任者となるのが「ホスト」です。ホストは、AIが外部の機能に接続してよいかという許可と、利用者がその機能を使う権限を持っているかという認可を管理します。そして、ホストの中で実際に通信を行う「クライアント」は、目的となる各サーバーと一対一で接続を持ちます。
クライアントからの接続を受ける「サーバー」は、主に3つの要素をAIへ公開します。
「resource（リソース）」は会話の文脈として読む資料です。「tool（ツール）」は外部APIの呼び出し、ローカル資料の検索、計算などを実行する機能です。「prompt（プロンプト）」はAIへの指示のひな形です。 サーバーがこれらを整理して公開することで、AIは自分が使える資料や道具を簡単に把握できます。
さらに、MCPの中で交わされるクライアントとサーバーのメッセージは、「JSON-RPC 2.0」というルールに従います。前に説明したJSON形式を使って、「このツールを使って」という要求や「これが結果です」という応答を統一された手順で交わす仕組みです。
このように、MCPはAIに分かりやすい形でresource（文脈データ）やtool（実行機能）をそろえ、決まった手順で通信できるようにします。次は、この手順を使うと図書検索がどう変わるのか、直接APIを使う場合と比べてみましょう。
図書検索を直接APIとMCP経由で比べます
前節までに確認したそれぞれの役割が、実際のやり取りでどう繋がるのかを見ていきましょう。ここでは、利用者がAIに「宮沢賢治の本を3冊探して」と依頼する場面を起点に、直接APIを使う場合とMCPを経由する場合の動作を比べます。
まず、直接APIを利用する場合です。AIのアプリがOpen Library APIなどの外部サービスを直接利用するには、アプリ自身があらかじめそのサービスの仕様を組み込んでいる必要があります。アプリの開発者は、q、fields、limitを指定して検索できるといった個別の決まりごとを調べ、専用の通信手順を一つひとつ設定しておかなければなりません。
一方、MCPを経由する場合は、AIアプリのホストがOpen Library APIのURLや引数を直接組み込まずに済みます。その代わり、図書検索MCPサーバーの開発者がAPI仕様、応答の読み方、エラー処理を実装します。処理の流れは、「利用者→ホスト→クライアント→MCPサーバー→Open Library API→JSON応答→利用者」の順番です。
利用者が「宮沢賢治の本を3冊探して」と入力すると、ホストはMCPクライアントに指示を渡します。クライアントはtools/listで一覧を得て、図書検索toolを発見します。
ホストは接続許可と利用者の認可を管理します。確認画面はAIアプリごとに異なります。利用者はtool名、入力、外部送信、変更の有無を確かめます。
実行が許可されると、クライアントは入力条件を渡し、tools/callで呼び出すことでサーバーの道具を実行させます。今回の例では、MCPサーバーがOpen Library APIへ検索要求を送信します。ただし、MCPサーバーが外部APIを呼ばず、手元のデータベースやファイルから結果を返す構成もあります。
Open Library APIは検索要求を受けると、本の情報をJSONでMCPサーバーへ返します。JSONはクライアントを経由してホストへ渡ります。
最後に、ホストのAIが書名などを読み取り、利用者向けの文章へ整えます。
追加する前に認証・権限・送信先を確認します
前節までで、直接API経路とMCP経路の比較を見てきました。ここからは、仕組みの理解を実際の接続可否の判断へと移します。AIへJSONファイル、APIキー、MCPサーバーを追加した時点で、まだ設定が終わっていないことや残る確認事項を整理します。
まず、チャット画面などにJSONファイルを添付しただけの場合です。JSON自体には、外部サービスから最新値を取得したり、元のファイルへ変更を書き戻したりする機能がありません。添付先のAIアプリが別のtoolやAPIを使える場合は操作できるため、JSONの役割とアプリの権限を分けて確認します。
次に、APIキーを追加する場合です。キーを設定しただけでは、対象と読み書きの権限は確定しません。利用上限、データ保存、操作ログも別に確認します。
API提供元の認証資料、料金・利用上限ページ、データ保持方針、キー管理画面を開きます。現在のキーに許可された範囲を確認できない場合は登録しません。
MCPサーバーを追加しただけでは、toolの安全性、認証、実行許可は整いません。利用者はデータアクセスとtool実行を理解し、拒否できる必要があります。
信頼済みサーバー由来でないtool注釈は未信頼として扱います。提供元のtool一覧、権限、送信先、認証方法、ログ方針を確認します。不明な項目があれば接続を拒否し、管理者または提供元へ確認します。
接続を許可する条件は、「認証情報」「アクセス権」「送信データ」「ログ」「外部操作」の五項目を説明できることです。とくに削除、購入、投稿など外部の状態を変えるtoolは、実行前の確認を外しません。確認先がない、必要以上の権限を求める、送信先や保存期間が不明という場合は拒否します。
同じ設定画面にはconnectorやfunction callingも現れます。connectorは製品が用意した接続部品で、内部でAPIやMCPを使う場合があります。function callingでは、モデルが関数名と引数を返し、アプリが関数を実行します。
SDKは特定の環境向けソフトウェアを作る道具の集合です。databaseはデータの保存先です。名称だけで接続方式を判断せず、実際に使うAPIまたはMCPと権限を確認します。
五項目の確認は、危険を自動でなくすものではありません。許可範囲を必要な操作へ絞り、変更操作を実行前に確認し、実行後にログと結果を照合できる場合にだけ接続します。
よくある質問
Q1. MCPはAPIを置き換えるものですか？
いいえ、置き換えるものではありません。MCPはあくまでAIに対して「どのような道具があり、どう使えばよいか」を教えるための共通の手順やルールです。
MCPサーバーが外部APIを呼ぶ構成では、システム同士の要求と応答にAPIが使われます。一方、MCPサーバーがローカルファイルやデータベースを直接読む場合もあり、MCPが常にAPIの上に置かれるわけではありません。
Q2. APIは必ずJSONでデータを返すのですか？
必ずしもJSONとは限りません。現在多くのAPIがデータのやり取りにJSONを使っていますが、目的やシステムによっては別の形式が選ばれることもあります。
たとえば、図書検索の例に出たOpen LibraryのAPIでは、JSONのほかにRDFと呼ばれる別のデータ形式で結果を返すこともできます。APIの設計に合わせて様々な形式が使われます。
Q3. MCPサーバーは必ず外部のAPIと通信するのですか？
外部のAPIをまったく呼ばないMCPサーバーもあります。MCPはAIに道具の存在と使い方を教える仕組みなので、その道具がインターネット上にあるとは限りません。
MCP公式仕様では、サーバーがresources、tools、promptsを公開できます。外部APIではなく、ローカルの資料、データベース、計算処理をtoolやresourceとして提供する構成も考えられます。
Q4. 一度接続できたら、提供されるツール（tool）はすべて安全ですか？
接続できたからといって、無条件に安全とは言えません。素性のわからないMCPサーバーの場合、AIに想定外の操作をさせるツールが含まれている可能性があります。
そのため、提供元の公式資料とAIアプリのtool一覧を開きます。入力と送信先を確認し、読み書きの権限と変更内容も確かめます。確認画面がない、提供元を特定できない、要求権限が目的より広い場合は接続または実行を拒否します。
Q5. JSONファイルだけあれば最新情報を取得できますか？
JSONファイル単体では最新情報は取得できません。JSONはデータが決められた書き方で並んでいるだけの「値のまとまり」であり、自ら通信して情報を更新する機能は持っていないからです。
天気やニュースなどの新しい情報が必要な場合は、APIに対して新しく要求を送り、その時点での最新データが書かれたJSONを返してもらう必要があります。
調査手法について
こちらの記事はグラフAIリサーチプラットフォームのSnorbeを使って作られています。Snorbeは研究開発・新規事業向けの調査テーマに応じた幅広い項目のオートリサーチや、ナレッジグラフの構築、構造化レポートの生成ができるAIリサーチツールです。
Screenshot
調査したいテーマを入力するだけで、AIが深堀りすべき観点や広げるべき調査項目をレコメンドしながら、自動でリサーチを進めます。収集した情報はナレッジグラフとして蓄積され、未調査領域（ホワイトスペース）を可視化しながら調査の網羅性を高めていけます。
また、観点マトリクスを30秒・構造化レポートを10分で自動生成する機能があり、出典付きのレポートをMarkdown/PDF形式でエクスポートできます。調査の元データも保存されるため、ファクトチェックや社内共有も容易です。
ご利用をご希望の方は、こちらよりお申し込みください。
また、グラフAIを活用した社内ナレッジ管理や、研究開発・新規事業のリサーチ支援、セルフホスト導入のご相談も受け付けています。お困りの方はお気軽にご連絡ください。
市場調査やデスクリサーチの生成AIエージェントを作っています 仲間探し中 / Founder of AI Desk Research Agent @deskrex , https://deskrex.ai
コメント