MCPとは？仕組み・Function Callingとの違いを図解

MCP（Model Context Protocol）は、AIアプリケーションと外部のデータやツールを接続するためのオープンな通信規約です。

重要なのは、MCPがAIモデルそのものでも、AIエージェントの思考方法でもないことです。モデルの外側で、どの機能が利用でき、どの形式で呼び出し、どの形式で結果を返すかをそろえます。

この記事は、2026年9月8日時点の最新安定仕様である2026-07-28を基準にしています。古い解説にあるinitialize、Mcp-Session-Id、HTTP+SSEを、そのまま現行仕様としては扱いません。

先に結論をまとめます。

MCPは、AIアプリケーションと外部機能の間を標準化する
Host、Client、Serverは接続構造、Tools、Resources、PromptsはServerが公開する機能
MCPを使っても、認可、実行前承認、入力・出力検証は自動的に完成しない
Function CallingとMCPは競合せず、異なる層で併用できる

MCPとは何か

MCP公式仕様は、MCPをLLMアプリケーションと外部データソース・ツールを統合するためのオープンプロトコルと位置づけています。通信にはJSON-RPC 2.0（リモート処理の呼び出し方をJSONで表す規格）を使います。

たとえば、チャット型AIへ「来週の空き時間を確認して」と依頼したとします。AIモデルだけでは、利用者のカレンダーへ直接アクセスできません。MCP対応のカレンダーServerが機能を公開し、AIアプリケーションがMCP Clientを通じてその機能を発見・呼び出すことで、外部情報を使った処理が可能になります。

ただし、カレンダーの内容がモデルへ追加学習されるわけではありません。必要なリクエストの間だけ、Hostが許可した情報や操作結果がモデルの入力（コンテキスト）へ渡ります。

なぜMCPが必要なのか

MCPがない場合でも、AIアプリケーションから外部APIを直接呼び出せます。1つのアプリと1つのAPIをつなぐだけなら、その方が単純なこともあります。

問題は、AIアプリケーションと外部サービスの組み合わせが増えたときです。チャット、IDE、業務Agentのそれぞれが、ファイル、データベース、カレンダー、社内APIへ独自に接続すると、認証、tool定義、引数schema、error、結果形式の接着codeが接続ごとに必要になります。

MCPは、このapplication側とcapability提供側の境界を共通化します。ServerがToolsやResourcesを一定形式で公開し、対応Hostが同じprotocolで発見・呼び出せるようにします。

ただし「一度作れば全Hostで無修正」とは限りません。Hostが対応する仕様version、feature、認可方式、表示UI、実行policyには差があり得ます。MCPが減らすのは接続形式の差であり、業務上の権限設計まで消すわけではありません。

Host・Client・Serverの役割

MCP Architecture 2026-07-28では、MCPをHost、Client、Serverの構成として説明しています。

1つのHostが複数Clientを管理し、各Clientが1つのServerへ接続する構成

構成要素	主な役割	具体例	セキュリティ上の責任
Host	AIモデルとの連携、複数Clientの管理、context集約、policy適用	チャットアプリ、IDE、業務Agent	接続許可、利用者への説明、実行承認、Server間の分離
Client	1つのServerとprotocol messageを交換するconnector	Host内のMCP接続部	version・capabilityの提示、message routing、結果検証
Server	特定のデータや機能をMCP形式で公開する	ファイル検索、Git、カレンダー、DB	入力検証、access control、最小限の情報返却

1つのHostは複数Clientを作れますが、各Clientは特定の1 Serverと1対1で通信します。この分離により、あるServerが会話全体や別Serverの内容を直接読める構造を避けます。どのcontextをどのServerへ渡すかはHost側が管理します。

ここで「MCP Client＝AIモデル」ではありません。モデルの出力を受け取り、Serverとの通信を管理するのはHostとClientです。

Tools・Resources・Promptsの違い

Host・Client・Serverが「誰が接続するか」を表すのに対し、Tools・Resources・Promptsは「Serverが何を提供するか」を表します。別の粒度なので、同じ表へ混ぜない方が理解しやすくなります。

Primitive	何を提供するか	主な制御主体	例
Tools	外部systemで実行できる関数	Modelが候補を選び、Hostが許可・実行を管理	予定作成、issue登録、計算、検索
Resources	contextとして読めるデータ	Applicationが選択・追加方法を管理	file、database schema、社内規程
Prompts	利用者が選べる定型message・workflow	User-oriented	code review用template、議事録整理template

MCP Tools仕様では、Toolをmodel-controlledとして扱います。Serverはtool名、説明、inputSchema、必要ならoutputSchemaを公開し、Clientはtools/listで一覧を取得し、tools/callで実行を依頼します。

MCP Resources仕様では、Resourceをapplication-drivenとして扱います。各ResourceはURIで識別され、Clientはresources/listやresources/readを使います。

Promptsは、Serverが利用者向けに公開するmessage templateです。単なる内部system promptと同一とは限らず、HostがどのようなUIで見せるかもprotocolは固定しません。

MCPでToolを呼ぶ流れ

カレンダーから空き時間を調べる例で、処理を追ってみます。

HostがClientを通じてCalendar Serverへ接続し、必要ならserver/discoverで提供機能を確認する
Clientがtools/listを送り、利用可能なToolと引数schemaを取得する
HostがTool定義をAIモデルのcontextへ渡す
利用者の依頼に対し、モデルがfind_available_slotsの呼び出しを提案する
Hostが入力、権限、実行policyを検証する
ClientがServerへtools/callを送る
Serverが外部calendar APIを呼び、結果を返す
Hostが結果を検証してモデルへ渡し、利用者向けの回答を生成する

この流れでは、どのToolを使うか考えるのはモデル側、MCP messageへ変換して送るのはClient、実行を許可するか決めるのはHostと利用者、実処理を担うのはServerと外部APIです。

Function Callingを使うHostなら、手順4でモデルが構造化したTool呼び出しを出し、HostがそれをMCPのtools/callへ変換できます。両者は同じ処理の異なる境界を担当します。

JSON-RPC messageで見るMCP

次は、現行仕様のfieldを理解するために作った簡略例です。実在serviceのpayloadではありません。

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "find_available_slots",
    "arguments": {
      "date": "2026-09-15"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "calendar-assistant",
        "version": "1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

Field	意味
`jsonrpc`	JSON-RPCのversion
`id`	requestとresponseを対応づける識別子
`method`	実行するMCP operation
`params.name`	呼び出すTool名
`params.arguments`	Toolへ渡す引数
`params._meta`	protocol versionやClient capability

2026-07-28仕様では、requestごとにprotocol versionとClient capabilityを渡します。Serverは「同じconnectionから来たから、前回と同じClientだろう」と推測してはいけません。

Tool引数へJSON Schemaを使えることは、型や必須項目を機械検証する助けになります。ただし、schemaに通った値が業務上許可された操作とは限りません。たとえばcalendar_idが文字列として正しくても、その利用者が対象calendarを更新してよいかは別のauthorization checkが必要です。

stdioとStreamable HTTP

MCP Transports 2026-07-28が定める標準transportは、stdioとStreamable HTTPです。

比較軸	stdio	Streamable HTTP
接続先	Clientが起動するlocal subprocess	network上のMCP endpoint
message delivery	標準入力・標準出力の改行区切り	HTTP POSTとJSON responseまたはrequest単位のSSE
向く場面	local fileや開発toolとの接続	共有service、remote data、複数利用者
credential	environmentなどprocess起動時の管理	HTTP authorization frameworkを利用可能
主な注意	subprocess権限、environment secret、local file access	TLS、OAuth、token audience、network境界、rate limit

stdioだから安全、remoteだから危険と単純には決まりません。stdio Serverへhome directory全体やshell実行権限を渡せば影響は大きくなります。Streamable HTTPでも、scopeとServer側authorizationを適切に制限すれば操作範囲を狭められます。

2026-07-28仕様で変わった点

2025年以前の解説を読むときは、対象versionを確認してください。2026-07-28 release noteによると、現行仕様はprotocol coreをstatelessへ変更しました。

観点	2025-11-25以前の説明	2026-07-28
初期化	`initialize` / `initialized`で事前交換	必須handshakeを廃止
session	`Mcp-Session-Id`でtransport sessionを識別	protocol-level sessionを廃止
version・capability	初期化時の情報へ依存	requestごとの`_meta`へ含める
Serverから追加入力	Server-initiated request	MRTR（Multi Round-Trip Requests）でinput_requiredを返す
HTTP	Streamable HTTP、旧HTTP+SSEの説明が混在	legacy HTTP+SSEはdeprecated

statelessとは、業務dataを一切保存できないという意味ではありません。shopping cartや長時間taskの状態が必要なら、Serverが明示的なhandleを返し、次のrequestでClientがそのhandleを引数として渡します。connectionそのものを会話sessionの代わりにしない、という変更です。

API・Function Calling・AIエージェントとの違い

MCPを理解しづらい理由の1つは、異なるレイヤーの用語が「外部Toolを使う仕組み」としてまとめて語られることです。

用語	主に標準化・担当する範囲	単独では決めないこと	MCPとの関係
API	service固有のendpoint、data、operation	AIがいつ呼ぶか	MCP Serverの内部でAPIを呼べる
Function Calling / Tool Calling	modelがtool名と引数を構造化して提案する境界	外部service共通の接続protocol	Hostが提案をMCP callへ変換できる
MCP	HostとServer間の発見、呼び出し、結果、context交換	modelの推論、業務policy、最終承認	複数Host・Serverで共通接続を作る
AIエージェント	目標に向けた計画、model call、tool利用、状態管理	特定の接続形式	外部capability接続にMCPを選べる

詳しいmodel側のloopはFunction Callingとは？Tool Useの仕組み・実装・安全設計で解説しています。

APIはMCPに置き換えられて消えるわけではありません。MCP Serverが既存APIを呼び、API固有のrequestとresponseをMCP形式へ変換できます。

MCPでできること・できないこと

MCPで共通化しやすいこと

Tool、Resource、Promptの発見方法
Tool引数と結果のschema
request、response、errorの基本形式
local processとremote endpointへのtransport
capabilityの宣言
progress、cancellation、notificationなどのprotocol utility

MCPだけでは自動的に解決しないこと

AIモデルが正しいToolを必ず選ぶこと
誤った引数やhallucinationをゼロにすること
利用者ごとのbusiness authorization
Toolが返した内容の正しさ・安全性
prompt injectionへの完全な防御
外部APIのavailability、latency、cost
破壊的操作の承認とrollback

MCPは配線を共通化しますが、接続先を信頼してよいか、何を許可するか、結果をどう検証するかは残ります。

MCPを安全に使うための8項目

MCP仕様のSecurity and Trust & Safetyは、利用者の同意、data privacy、Tool safetyを重要原則として挙げています。

外部データに命令を紛れ込ませる危険については、OpenAIのprompt injection解説も、信頼できないコンテンツがモデルを誤誘導し得ると説明しています。

Serverの提供元を確認する

名前が似たServerやToolを同一とみなさず、配布元、repository、package、更新履歴を確認します。

最小権限で接続する

読み取りだけで足りる処理へ書き込みscopeを渡さず、対象folder、repository、accountを絞ります。

secretをpromptやTool引数へ埋め込まない

stdioはenvironment、HTTPは適切なauthorization flowを使い、modelへcredentialを見せません。

Tool descriptionとannotationを信頼し過ぎない

仕様も、trusted Server由来でないannotationをuntrustedとして扱うよう求めています。

入力をschemaと業務ruleの両方で検証する

型だけでなく、resource ownership、許可範囲、金額や件数の上限を確認します。

外部dataを命令として扱わない

Webページ、issue、文書にはprompt injection（外部データに紛れた命令でモデルを誤誘導する攻撃）が含まれる可能性があります。データと信頼済みの命令を分離します。

副作用のある操作は実行直前に確認する

送信、公開、購入、削除、権限変更では、実際の対象・差分・金額を利用者に示します。

結果検証とaudit logを残す

output schema、許可した操作、実行者、対象、結果、errorを記録し、失敗時の再試行とrollbackを設計します。

MCP Authorization仕様は、HTTP transport向けの認可frameworkを定めています。ただしauthorizationはMCP実装でoptionalです。「MCP対応」と表示されているだけでOAuthや最小権限が完成しているとは判断できません。

MCPを導入するか判断する

条件	Direct API integration	MCP
1つのapplicationと1つのinternal APIだけを接続	構成が単純	protocol layerが増える場合がある
複数のAI Hostから同じcapabilityを再利用	Hostごとのadapterが必要	Server側の共通化が効きやすい
外部利用者へcapabilityを配布	独自SDK・documentが必要	対応Hostから発見・接続しやすい
細かな独自stream・transaction	API固有機能を直接使いやすい	MCP schemaへ合わせる設計が必要
local開発tool	subprocessを直接管理	stdio Serverとして分離しやすい

MCPが向くのは、同じToolやResourceを複数のAI applicationから使いたい場合、接続先を部品として交換したい場合、外部へ標準形式で提供したい場合です。

単一の内部処理で再利用予定がなく、APIの低level featureを細かく使うなら、Direct APIの方が保守しやすいことがあります。MCPを採用すること自体を目的にせず、接続先の数、再利用範囲、security boundaryで判断します。

よくある質問

MCP ServerはAIモデルですか？

いいえ。MCP ServerはTool、Resource、Promptを公開するserviceです。AIモデルとの連携や、どの情報をcontextへ入れるかの調整は主にHostが担います。

MCPを使えばAPIは不要ですか？

不要にはなりません。MCP Serverが既存API、database、file systemを呼び出し、MCP形式へ変換する構成が可能です。MCPは外部system固有のbusiness APIを置き換えるというより、AI application側の接続境界をそろえます。

MCP Serverへ接続するとデータが学習されますか？

接続しただけでmodel weightへ追加学習されるわけではありません。ただし、ResourceやTool resultがmodel contextへ送られる可能性はあります。どのdataがどのmodelやserviceへ送信されるかは、利用するHostとServerのprivacy policy、設定、実際のdata flowを確認してください。

Remote MCP ServerならOAuthが必須ですか？

MCP protocol全体ではauthorizationはoptionalです。一方、HTTP-based transportで認可を実装する場合は、現行仕様のauthorization frameworkへ従うことが推奨されます。機密dataや副作用のあるToolを無認証で公開してよい、という意味ではありません。

まとめ

MCPは、AIアプリケーションが外部のTool、Resource、Promptを発見し、一定形式で利用するためのprotocolです。Hostがpolicyとmodel integrationを担い、Clientが1つのServerと通信し、Serverが特定capabilityを提供します。

2026-07-28仕様ではrequestが自己完結するstateless coreへ変わりました。古いinitialize、transport session、HTTP+SSE前提のtutorialを読むときは、対象versionを確認してください。

導入で最も重要なのは、Serverへ接続できることではありません。どのdataと権限を渡し、どの操作で人間の承認を取り、返された結果をどう検証するかを設計することです。

Codexで手順そのものを再利用する方法や、MCPとの役割差はCodex Skillsの作り方で整理しています。

MCPとは？AIエージェントと外部ツールをつなぐ仕組みを図解