Model Context Protocolとは｜MCPの仕組み・活用事例をエンジニア視点で解説

Model Context Protocol（MCP）とは何か

定義と提供元

Model Context Protocolは、LLMホスト（Claude Desktop等のAIアプリ）と、ツール・データを提供する外部サーバーの間の通信を標準化したオープンプロトコルです。Anthropic社が2024年11月25日に初版仕様を公開し、リファレンス実装・公式SDK・サンプルサーバーを公式リポジトリで配布しています。仕様書・SDK・リファレンス実装はそれぞれのリポジトリで公開されており、詳細なライセンス範囲は各リポジトリで確認してください。設計思想として、特定のベンダーに縛られないことを志向した規格です。

JSON-RPC 2.0をベースにしたメッセージング規格です。執筆時点の公式仕様では、転送層として標準入出力（stdio）とServer-Sent Events（SSE）の2方式が定義されています。クライアントは「どんなツールがあるか」「どんなリソースが読めるか」「どんなプロンプトテンプレートが用意されているか」をサーバーに問い合わせ、結果を取得した上で、LLMにコンテキストとして渡します。仕様バージョンによる差異があるため、実装前に公式仕様で現行情報を確認してください。

なぜ新しいプロトコルが必要だったのか

LLMに外部機能を持たせる試みは、OpenAIのFunction Callingやプラグイン、LangChainのTool抽象、各社独自のエージェントSDKと、すでに何種類も存在しています。それでも別の規格が必要になった背景には、「同じツールを異なるLLM／IDE／エージェントから使い回す」ための共通言語がなかった事情があります。

具体的には、GitHubと連携するための実装をClaude用に書いても、それをCursor向けやChatGPTのエージェント向けに移植する作業は別物でした。MCPは「ツール提供側はサーバーを1本書けば、対応クライアント間で再利用しやすい」状態を目指す規格です。実際にはホスト側の対応機能差・UI差はありますが、共通プロトコルとしての土台を提供します。USB-Cがケーブル形状を統一したように、LLMの外部接続規格を統一する位置付けで語られることが多い領域です。

MCPが扱う3つの構成要素

MCPの仕様では、サーバーが公開できる要素を以下の3つに分けて定義しています。

Function Callingが「関数を呼ぶ形式」を決めるのに対し、MCPは「ツールや参照データをどう公開するか」まで含めて標準化します。 これら3要素を組み合わせることで、単なる関数呼び出しではなく、コンテキスト一式をパッケージとして提供する設計になります。RAG（Retrieval-Augmented Generation）でいう「検索結果＋プロンプト整形」の役割を、プロトコル側で整理した形といえます。RAGそのものについてはRAGとは？仕組み・活用事例・導入メリットをわかりやすく解説で解説しています。

MCPの仕組み

ホスト・クライアント・サーバーの3層構造

MCPの通信は、以下の3層で整理されます。

1. ホスト（Host）：ユーザーがAIと対話する側のアプリ。Claude Desktop・Cursor・自作エージェント等

2. クライアント（Client）：ホスト内に組み込まれ、各MCPサーバーと1対1で接続する通信モジュール

3. サーバー（Server）：ツール・リソース・プロンプトを公開する外部プロセス

ホストは複数のサーバーに対して同時にクライアントを張り、必要に応じてツール一覧やリソース一覧を取得します。ユーザーが「このリポジトリのPRを確認して要約して」と入力すると、ホストはGitHubサーバーに対してツール一覧取得→該当ツール呼び出し、という流れで問い合わせ、結果をLLMに渡します。

通信プロトコルとライフサイクル

メッセージング規格はJSON-RPC 2.0です。クライアント／サーバー間でリクエスト・レスポンス・通知が定義されており、起動時の流れは以下のようになります。

1. initialize：プロトコルバージョン・対応機能を相互交換

2. initialized：初期化完了の通知

3. 一覧取得：ツール一覧・リソース一覧・プロンプト一覧の各要素を取得

4. 呼び出し：必要に応じてツール呼び出し・リソース読み取りを実行

5. shutdown：接続終了

ローカル接続では標準入出力（stdio）を使い、リモート接続ではHTTPベースのSSEを使う構成が主流です。stdioは設定が単純で、Claude Desktopのようなローカル中心のホストで多用されます。SSEは長時間接続の維持・複数クライアントからのアクセスに向き、社内サーバーや共有環境で採用されやすい形です。

認可とセキュリティ境界

外部サービスにアクセスするサーバーでは、OAuth 2.0または各サービスの個別認証（APIキー・PAT等）が組み合わさります。仕様では認可フローそのものを規定しているわけではなく、サーバー側の実装に委ねられています。これは「LLMホスト側に資格情報を持たせない」設計思想の現れで、トークンはサーバーの環境変数や認証ストアで管理し、LLMには結果だけを返します。

ローカルファイルや社内DBへのアクセス権を持つサーバーを公開する場合、誤って機密情報をLLMに露出させないよう、書き込み系ツールには明示的な承認フローを噛ませるのが一般的な実装パターンです。Claude DesktopやCursorなど主要ホストは、初回利用時にツール呼び出しの可否をユーザーに確認するUIを備えています。

Function CallingやLangChainとの違い

検索意図として強いのが、「MCPは結局Function Callingと何が違うのか」という疑問です。役割の重心が違うため、置き換えの関係ではなく層が異なる関係として整理するのが分かりやすい構造になります。

Function Callingとの違い

Function Calling（OpenAI／Anthropic／Geminiの各APIで提供）は、LLMが「どの関数を、どんな引数で呼ぶか」を決める仕組みです。具体的な関数の中身や、関数の登録方法はAPIごとに異なります。

MCPはFunction Callingの「呼び出される側」を標準化するプロトコルです。Function Callingで関数を呼ぶ前段階で、ツール一覧・スキーマ・リソース・プロンプトを共通形式で取得できる枠組みを提供します。つまり、Function Callingの「向こう側」にいるツール群を、ホストやLLMを問わず使い回せる状態にするのがMCPの役割です。

要するに、Function Callingは「LLMがどう呼ぶか」の仕組み、MCPは「ツール側がどう公開されるか」の仕組みです。

実装観点では、MCPサーバーの中でFunction Callingに渡すツール定義を生成するような併用構成も成り立ちます。

LangChain・LlamaIndexのToolsとの違い

LangChainやLlamaIndexにもツール抽象（Tool／ToolSpec）があります。これらはアプリケーションコード内で完結する「フレームワーク内のツール定義」であり、ライブラリの世代が変わるとAPIが揺れる点で、移植性に課題がありました。

MCPはプロセス境界を越えてツールを共有する仕様です。LangChain・LlamaIndex側でもMCP連携機能や関連実装が整備されつつあり、現行状況は各公式ドキュメントで確認してください。LangChainの全体像はLangChainとは？できること・活用事例から年収・将来性まで解説、LlamaIndexはLlamaIndexとは｜RAG構築の仕組み・LangChainとの違いを解説で解説しています。

OpenAI Pluginとの違い

OpenAI Pluginは、ChatGPT向けに外部APIをマニフェストで登録する仕組みでした。役割は近いものの、ChatGPTというホストに事実上閉じていた点と、認可フローやマニフェスト形式がOpenAI固有だった点が、MCPと異なります。MCPはオープン規格でリファレンス実装が複数あり、ホストを選びません。

ミニFAQ：MCPは既存資産を捨てる必要があるか

• Q. すでにLangChainで動いているエージェントをMCPに置き換える必要はあるか

• A. 急ぐ理由はなく、社外のクライアントから同じツールを使わせる必要が出てきた段階で導入を検討する形が現実的です。LangChain側のMCPアダプタを経由すれば、既存ツールを段階的にMCP対応にできます

公開されている主要MCPサーバー

Anthropic公式リポジトリと、コミュニティ・ベンダーが配布しているサーバーが揃っており、ゼロから書かずに導入できるケースも多くあります。代表的なものを用途別に整理します。

以下は執筆時点で確認しやすい代表例です。追加・移管・非推奨化の可能性があるため、最新一覧は公式GitHub組織で確認してください。

公式リファレンス実装（Anthropic）

公式リポジトリで配布されているリファレンスサーバーには、以下のようなものがあります。

• filesystem：ローカルファイル・ディレクトリの読み書き

• github：リポジトリ操作・Issue／PR管理

• postgres：SQL実行・スキーマ参照

• slack：チャンネル投稿・メッセージ取得

• google-drive：ドキュメント検索・本文取得

• brave-search：Web検索

• memory：会話横断の知識保管

• puppeteer：ブラウザ操作によるスクレイピング

これらはTypeScript／Python実装が多く、npmやPyPIなどで配布されているものがあります。Claude Desktopの設定ファイルにコマンドと環境変数を書くだけで、すぐに接続可能なケースが大半です。

コミュニティ・ベンダー実装

公式以外にも、Notion・Linear・Figma・Sentry・Jira・Atlassian・Cloudflare・Stripe等のサービスを扱うサーバーが、公式の公開リポジトリやベンダー自身の配布で広がっています。サーバーの品質・更新頻度・認可方式はバラつきがあるため、本番採用前にメンテナンス状況を確認するのが安全な進め方です。

自分のサービスで採用するときの考え方

社内ナレッジ・社内SaaSをLLMから扱いたい場合、既存APIをMCPサーバーでラップする形が定番になりつつあります。OpenAPIスキーマからMCPサーバーを生成するツールも登場しており、ゼロから書かなくても済むケースが増えています。

自作MCPサーバーの作り方

最短ルート：公式SDKでHello World

PythonとTypeScript用の公式SDKが配布されています。Pythonの場合、最短手順は以下です。

1. uvまたはpipで公式SDK（mcpパッケージ）を導入

2. ツール・リソース・プロンプトを宣言する小さなサーバーをスクリプトとして書く

3. Claude Desktopの設定ファイル（claude_desktop_config.json）に起動コマンドと環境変数を記述

4. Claude Desktopを再起動し、ツール一覧に表示されれば接続成功

公式リポジトリには、ファイル検索・天気取得・SQLite問い合わせなどのサンプルが揃っています。最初は副作用のない読み取り系から実装し、書き込み系は承認フローを挟んで後から追加する流れが安全です。

スキーマ設計の勘所

ツールのスキーマは、LLMがどの関数をどんな引数で呼ぶかを判断する材料になります。設計時の指針は以下のようになります。

• ツール名は動詞＋目的語で、機能を端的に表す（search_files・create_issue等）

• 引数は型と説明文を必ず添える（LLMが意図を取り違える主因）

• 戻り値はLLMが解釈しやすい形式にする（JSONで構造化、長文は要約とリンクに分ける）

• 副作用の有無を説明文で明示する（書き込み系・課金が発生する系は特に）

ツール数を増やしすぎるとLLMが選び切れず精度が落ちるため、実務上は10〜20ツール程度に絞ると扱いやすいケースが多く、用途が異なるなら別サーバーに分ける構成が無理なく回ります。

開発・デバッグの環境

公式が提供するMCP Inspectorを使うと、サーバーの起動・ツール一覧の確認・実引数での呼び出しテストをブラウザ上で行えます。Claude DesktopやCursorに繋ぐ前に、Inspectorで動作を切り分けるとデバッグ工数を抑えられます。

開発支援エディタとしては、Cursorとは？AIコードエディタの特徴・使い方・料金とGitHub Copilotとの違いを解説で解説しているCursorがMCPに対応しており、自作サーバーをエディタ内のAIから直接呼び出せます。

ミニFAQ：開発時の典型的なつまずき

• Q. ツール一覧に出てこない

• A. 多くの場合、claude_desktop_config.jsonのJSON記法エラーか、起動コマンドのパスが通っていないのが原因です。設定ファイルを保存後、ホストを完全終了して再起動してください

MCP活用事例

実務での使われ方は、開発支援系と業務系の2系統に大別できます。

開発支援エージェント

エンジニアの作業環境からMCPを通じて以下のような操作を行うパターンです。

• コードベース横断検索：grep系サーバーでローカルコードを検索し、要約させる

• GitHub操作：Issue起票・PR作成・コードレビュー要約

• CI／ログ確認：CIサーバー・観測基盤からエラーログを取得して原因仮説を立てる

• DB調査：Postgres・MySQLサーバー経由でクエリ実行と結果サマリ

Cursorのような開発エディタにMCPサーバーを組み合わせると、コード補完だけでなく、エディタの外側のシステムまで含めた作業エージェントに近い動きが可能になります。

社内ナレッジ・業務システム連携

• 社内Wiki／Drive横断検索：Google Drive・Notion・Confluenceサーバーから関連文書を取得して回答に組み込む

• 問い合わせ自動応答：Zendesk・Intercom等のサーバーから過去チケットを参照し、ドラフトを生成

• データ可視化：BIツール・データウェアハウス（DWH）サーバー経由で社内データに直接問い合わせ

このパターンはRAGの実装と重なる領域です。MCPはRAGを置き換える技術ではなく、RAGの「データ取得層」を共通プロトコル化する位置付けで使われます。

マルチエージェント・パイプライン

複数のMCPサーバーを束ねて、計画立案→情報収集→実行→検証を自動化する構成も登場しています。エージェント自体の概念はAIエージェントとは？仕組み・種類・活用事例をわかりやすく解説で解説しています。MCPはエージェント側に「ツール群への共通アクセス手段」を与える役割を担います。

このページにしかない整理：採用判断の早見表

フリーランス案件の動向

募集される肩書きと業務内容

公開求人・案件サイトの観測ベースでは、MCPを明示的に挙げる案件はまだ少なく、「AIエージェント開発」「Claude／Cursor活用支援」「社内ナレッジ×LLM」といった文脈の中で、関連スキルとして要件に含まれるケースが目立ちます。職種としては以下のような形で募集される傾向があります。

• AIエンジニア／生成AIエンジニア

• LLMエンジニア

• AIエージェントエンジニア

• 社内DX／PoC支援（生成AI領域）

詳しくはAIエージェントとは？仕組み・種類・活用事例をわかりやすく解説と生成AIエンジニアとは？仕事内容・必要スキル・年収とAIエンジニアとの違いを解説で、職種ごとの違いを整理しています。

単価相場の目安

2026年6月時点で、主要フリーランスエージェント（大手総合型・生成AI特化型）の公開案件（週3〜5日・業務委託）を確認すると、MCPそのものではなく、生成AI・AIエージェント関連案件全体の公開案件ベースでは、月額60〜100万円台の募集が目立ちます。職種・稼働率・上流比率で上下する点には注意が必要です。上流設計、社内SaaS連携、認可設計、PoCから本番導入まで担える人材では、より高単価の募集も見られます。MCP単体の経験が単価を決めるというより、Python／TypeScript＋LLM API＋OAuth実装＋ベクトルDB周辺といった、周辺技術込みの実装経験全体が評価される傾向です。市場の動きは速いため、最新の単価は公開案件で確認してください。

求められるスキルセット

LLM API周辺の知識については、Claude APIの使い方｜料金・モデル選定・実装例をフリーランスエンジニア向けに解説も参考になります。

学習ロードマップ

MCPだけを学べば案件に直結する状況ではなく、LLM API周辺の実装経験とセットで広げるのが現実的なルートです。学習の順番例は以下のようになります。

ステップ1：LLM APIの基本

Claude APIまたはOpenAI APIで、テキスト生成・Function Callingを動かせる状態を作ります。API呼び出し・ストリーミング・料金見積もりの感覚を持っていると、MCPの設計判断（どこまでLLMに任せるか）の精度が上がります。

ステップ2：MCPの公式SDK

Python／TypeScriptどちらかの公式SDKで、自前のサーバーを1本作ります。読み取り専用のシンプルなツールから始め、徐々にリソース・プロンプトまで広げる流れが進めやすい順番です。

ステップ3：既存サーバーの読解

公式サーバー（github・filesystem・postgres等）のソースコードを読み、認可境界の引き方・エラー処理・テスト構成を学びます。業務で書くサーバーの品質は、公式サーバーのスタイルを参考にするのが手っ取り早い基準になります。

ステップ4：周辺技術との結合

RAG・LangChain／LlamaIndex・ベクトルDBと組み合わせ、社内ナレッジ検索エージェントのような実用例まで作ります。本番運用ではログ・モニタリング・コスト管理が必要になるため、観測基盤（OpenTelemetry等）との接続も視野に入れます。

よくある失敗と対策

実装・運用の段階で詰まりやすいポイントを整理します。

全てのツールを1サーバーに詰め込む

GitHub・Slack・社内DB・ファイルシステムを1サーバーに集約すると、ツール数が膨れてLLMが正しく選べなくなります。機能ドメインごとにサーバーを分け、ホスト側で必要なサーバーだけを有効化する設計が扱いやすくなります。

書き込み系を承認なしで公開する

書き込み・削除・課金発生系のツールを承認フローなしで公開すると、LLMの誤動作で実害が出る可能性があります。書き込み系は確認プロンプトを必ず噛ませるか、ドライランモードを既定にして本番反映は明示的に切り替える形が安全です。

認可情報をLLM経由でやり取りする

OAuthトークン・APIキーをLLMに渡すコンテキストへ含めないよう注意します。MCPの設計思想として、資格情報はサーバー側に閉じ込め、LLMには結果だけ返すのが原則です。デバッグ目的で一時的に露出させた場合も、検証後に必ずローテーションします。

ツール説明文を省略する

ツールのdescription（説明文）を1行で済ませると、LLMが呼び出し意図を誤ります。いつ呼ぶべきか／何を返すか／副作用の有無を、サーバー側の説明文に丁寧に書くと、ホスト側の指示を簡潔にできます。

仕様の更新に追従しない

MCPは更新が早い領域です。プロトコルバージョン・SDKのメジャー更新で挙動が変わることがあるため、本番環境のサーバーは公式リリースノートを定期確認する運用を組み込みます。

まとめ

MCPは「LLMと外部ツール・データを安全に接続するための共通プロトコル」で、Function Callingの下流にあるツール公開層を標準化する技術として整理できます。要点は以下です。

• MCPはツール側の規格：LLMホストとサーバーをJSON-RPCでつなぎ、ツール・リソース・プロンプトを共通形式で公開する

• Function Callingとは層が違う：呼ぶ側ではなく呼ばれる側の標準化。併用可能で置き換え関係ではない

• 公式サーバーが揃いつつある：GitHub・Slack・Postgres等の業務系コネクタを公式・コミュニティが配布している

• 採用判断のポイント：複数ホストで同じツールを使う／社内SaaSの認可境界を集約したい場合に向く

• 案件動向：MCP単体ではなく、AIエージェント・社内ナレッジ・Claude／Cursor活用支援の文脈で要件化される

• 学習の進め方：LLM API→公式SDK→既存サーバー読解→周辺技術結合の順で広げると詰まりにくい

LLMと外部システムをつなぐ実装は、Function Calling登場以降も標準が揺れ続けてきた領域です。MCPが定着するかは今後の動向次第ですが、「ツール側を整理する規格」が出てきたこと自体は、AIエージェント実装の本番運用を進める上で意味の大きい一歩といえます。フリーランスとして案件に対応するなら、LLM API＋RAG＋ベクトルDBの土台にMCPを重ねる学習順序が、無理なく市場価値につながりやすい構成です。まずは公式SDKで読み取り専用サーバーを1本作り、Claude DesktopやCursorから動かしてみるのが最短ルートです。

参考リンク

• Model Context Protocol 公式サイト

• Model Context Protocol 仕様書

• Model Context Protocol GitHub組織

• Anthropic 公式（Model Context Protocol発表）