MCPとは？仕組みとAPIとの違い・活用事例解説【2026年版】

MCPとは何か

MCPはModel Context Protocolの略称である。 Anthropicが2024年11月に公開した開放仕様である。 生成AIと外部の情報源や道具をつなぐ共通手順を定める。 Anthropic公式ブログ（https://www.anthropic.com/news/model-context-protocol）で背景と目的が示された。 仕様書は公式仕様（https://spec.modelcontextprotocol.io）に集約された。 実装例は公開保管庫（https://github.com/modelcontextprotocol）に置かれた。

従来、生成AIに社内文書や開発用具を使わせる際は個別連携が必要だった。 接続先ごとに認証方式や応答形式が異なり、開発と保守の負荷が高かった。 MCPはこの差異を吸収する層として設計された。 電源のUSB規格のように、差込口を統一する発想である。 対応した受信側と提供側を組み合わせれば、追加開発なしで連携が成立する。 2026年時点でClaude、Cursor、Cline、Windsurf、GitHub Copilotなどが対応する。

MCPの仕組み：三つの登場要素と通信手順

MCPはホスト、クライアント、サーバーの三要素で構成される。 ホストはClaude Desktopや開発用具など利用者が操作する応用 program である。 クライアントはホスト内部で接続を管理する部品である。 サーバーは外部機能を提供する部品である。 1つのホストが複数のサーバーと並行接続できる点が特徴である。

通信はJSON-RPC 2.0を用いる。 起動直後の方式は標準入出力とStreamable HTTPの二系統である。 標準入出力は同一端末内の高速連携に向く。 Streamable HTTPは遠隔地のサーバー利用に向く。 2025年の改訂で遠隔運用が整理され、HTTP系への一本化が進んだ。

サーバーが提供する能力は四種類に分類される。 第一はツールである。ファイル書込や課題登録など実行を伴う操作を指す。 第二はリソースである。文書や表、画像など参照用の情報を指す。 第三はプロンプトである。定型の指示文や作業手順の雛形を指す。 第四はサンプリングである。サーバー側からモデルに文章生成を求める逆方向の要求を指す。 起動時に能力交渉が行われ、利用可能な機能一覧が共有される。 その後、モデルの判断で必要な機能が呼び出される。

API・Function Callingとの違い

MCPと通常のAPIは目的と利用主体が異なる。 通常のAPIは程序同士の取決めである。 仕様書を人が読み、呼び出し処理を人が書く。 MCPは模型が自律利用するための取決めである。 機能一覧と説明文を機械可読形式で渡し、模型が選択と実行を行う。

違いは次の五点に整理できる。

• 発見性：APIは事前登録が必要だ。MCPは接続時に機能一覧を自動取得する。
• 記述方式：APIはOpenAPIなど形式が分散する。MCPは説明文と型定義が統一される。
• 状態管理：APIは無状態が原則だ。MCPは会話と権限の文脈を保持する。
• 利用主体：APIは開発者が呼び出す。MCPは模型が状況に応じて呼び出す。
• 再利用性：API連携は応用ごとに作り直す。MCP対応は用具を変えても流用できる。

Function Callingとの違いも重要である。 Function Callingは特定モデルの呼び出し機能である。 定義形式や振る舞いが提供者ごとに異なる。 MCPは模型や提供者に依存しない中立層である。 Claude用に作ったGitHub連携を別系統の用具で再利用できる点が実務上の利点である。 現場ではFunction Callingを直接書くより、MCP経由で共通化する事例が増えた。

導入方法と現場での使い方

代表的な導入は既製サーバーの利用から始まる。 Filesystem、GitHub、Postgres、Slack、Playwrightなどが公式と有志から提供される。 Claude Desktopでは設定文書にサーバー起動命令を記述する。 CursorやClineでは用具内のMCP設定画面に同様の項目を登録する。 登録後は用具の再起動で機能一覧が読み込まれる。

自作する場合、Python用開発キットとTypeScript用開発キットが用意される。 ファイル検索や社内基盤照会など用途を絞った小規模実装が適する。 説明文は模型への指示書の役割を果たす。 引数の意味、制約、失敗時の挙動を具体的に書くことが精度を左右する。 曖昧な説明は誤った呼び出しを招くため、検証が欠かせない。

現場運用では権限設定が要点になる。 読み取り専用と書き込み可能を明確に分ける。 削除や送信など不可逆操作は承認制にする。 作業記録を残し、誰がどの道具で何を実行したか追跡できる構成にする。 検証環境で挙動を確認した後に本番へ移す手順が定石である。

活用事例5選

第一は開発支援である。 GitHub連携で未解決課題の一覧取得や差分要約を行う。 Postgres連携で表定義の確認や集計文の試行を行う。 Playwright連携で画面操作の自動検証を行う。 符号補完と結合し、調査から修正案作成まで一連化する事例が多い。

第二は社内情報検索である。 Google DriveやNotion、Confluenceの文書を資源として参照する。 生成AIが関連文書を横断して要約し、出典を示す運用が有効である。 従来型の検索拡張生成と併用し、最新情報の参照層として使う構成が見られる。

第三は業務自動化である。 SlackやJira、顧客管理基盤と接続し、定型報告を作成する。 問い合わせ文の分類、優先度付け、下書き作成を連続実行する。 人が最終確認する半自動運用が品質と速度の均衡点になる。

第四は資料作成支援である。 表計算や文書保管庫から数値を集め、月次報告の素案を作る。 数式や引用元の所在を明示させることで点検が容易になる。

第五は検証と監視である。 記録保管庫から異常記録を抽出し、原因仮説を整理する。 復旧手順書と照合し、対応漏れを検出する用途が報告された。 BlockやReplitなど初期導入企業の事例は公式発表（https://www.anthropic.com/news/model-context-protocol）で紹介された。

利点と課題・注意点

利点は三点ある。 第一に開発工数の削減である。共通手順に寄せることで個別実装が減る。 第二に用具間の移植性である。一度作った連携を使い回せる。 第三に模型の交代への耐性である。基盤模型を替えても接続層を維持できる。

一方で課題も明確である。 最大の懸念は安全設計である。 外部文書を参照する際、文書内に紛れた悪意ある指示に従う恐れがある。 指示混入と呼ばれる攻撃であり、参照と命令の分離が求められる。 権限の過剰付与も事故原因になる。 全ファイル書込許可など広範な権限は避けるべきである。

運用面の課題も残る。 応答遅延の切り分けが難しい。模型、接続層、外部基盤のどこに原因があるか特定しにくい。 障害時の再試行や打切り条件を事前に定める必要がある。 認証情報の保管も要点である。遠隔型ではOAuthによる代理認可が推奨される。 機密情報を扱う場合は記録の保持期間と閲覧範囲を定めることが不可欠である。

編集部の見解

比較時の評価軸は機能数ではなく権限設計と監査可能性を重視すべきと見る。読み取り専用と書き込み実行を分離できるか、操作記録を残せるかが選定基準になると評価する。仕様更新への追随負荷と開発用具の対応状況も確認すべきと考える。 現場での落とし穴は過剰な権限付与と外部文書経由の指示混入であると評価する。利便性を優先した全ファイルへの接続許可は事故の温床になると見る。検証環境で挙動を記録し、許可範囲を最小化すべきと考える。 今後の方向性は遠隔運用と認証標準化への収束と言えそうだ。Streamable HTTPへの一本化とOAuth連携が進み、企業導入の障壁は下がると見る。モデル間の相互運用が進み、独自接続手順は淘汰されると見る。

参考

• Model Context Protocol - Anthropic公式発表
• MCP公式仕様書
• modelcontextprotocol - GitHub
• Model Context Protocol入門 - Anthropic公式文書