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

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と1対1で通信します。この分離により、あるServerが会話全体や別Serverの内容を直接読める構造を避けます。どのcontextをどのServerへ渡すかはHost側が管理します。

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

Tools・Resources・Promptsの違い

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

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を呼ぶ流れ

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

1. HostがClientを通じてCalendar Serverへ接続し、必要ならserver/discoverで提供機能を確認する
2. Clientがtools/listを送り、利用可能なToolと引数schemaを取得する
3. HostがTool定義をAIモデルのcontextへ渡す
4. 利用者の依頼に対し、モデルがfind_available_slotsの呼び出しを提案する
5. Hostが入力、権限、実行policyを検証する
6. ClientがServerへtools/callを送る
7. Serverが外部calendar APIを呼び、結果を返す
8. 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": {}
    }
  }
}

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

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

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

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

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

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

詳しい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解説も、信頼できないコンテンツがモデルを誤誘導し得ると説明しています。

1. Serverの提供元を確認する

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

1. 最小権限で接続する

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

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

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

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

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

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

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

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

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

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

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

1. 結果検証とaudit logを残す

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

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

MCPを導入するか判断する

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の作り方で整理しています。

参考資料

• Model Context Protocol Specification 2026-07-28
• MCP Architecture 2026-07-28
• MCP Base Protocol 2026-07-28
• MCP Tools 2026-07-28
• MCP Resources 2026-07-28
• MCP Transports 2026-07-28
• MCP Authorization 2026-07-28
• The 2026-07-28 Specification
• modelcontextprotocol/modelcontextprotocol
• Understanding prompt injections