MCP Server 深掘り調査レポート

エグゼクティブサマリ

Model Context Protocol Server は、LLM アプリケーションが外部データや外部機能へアクセスするための「標準インターフェース」を提供するサーバであり、MCP 全体は、Anthropicが 2024 年 11 月に公開したオープン規格として始まりました。MCP の狙いは、AI アプリケーションごと・データソースごとに個別実装していた接続を、単一のプロトコルで共通化し、ツール実行・コンテキスト取得・プロンプト配布・認可を統一することにあります。2025 年 12 月には MCP は Agentic AI Foundation に寄贈され、現在は Linux Foundation系のガバナンスで運営されています。最新の安定仕様として参照しやすいのは 2025-11-25 版で、JSON-RPC 2.0、ライフサイクル管理、HTTP ベースの認可、server/client utilities を中心に整理されています。 

技術的に重要なのは、MCP が「単なる RAG の搬送路」ではなく、Prompts / Resources / Tools を分けて定義し、さらに必要に応じて sampling・elicitation・logging・authorization までカバーすることです。公式仕様は、Prompts を user-controlled、Resources を application-controlled、Tools を model-controlled と整理しており、これがエージェント設計上の責務分離を明確にします。実装面では、公式 SDK として TypeScript、Python、C#、Go が Tier 1、Java と Rust が Tier 2、Kotlin は TBD とされており、特に Python / TypeScript / Go / C# は本番導入検討の中心です。 

一方で、MCP は利便性と引き換えに攻撃面も広げます。公式の Security Best Practices は、confused deputy、token passthrough、SSRF、session hijacking、local server compromise、scope minimization failure を具体的な脅威として挙げ、HTTP サーバでは OAuth 2.1 系の認可、audience validation、PKCE、Origin 検証、最小権限スコープ、監査可能な client 識別を求めています。つまり、MCP Server を組み込むことは、単にツールを増やすことではなく、認可・承認 UI・監査ログ・セッション管理を含む “AI 実行面の新しい制御プレーン” を追加することだと理解すべきです。 

導入の実務論としては、最初から「何でもできる MCP Server」を作るのではなく、狭い業務フローに限定した read-only ないし限定 toolset 構成で始めるのが妥当です。PoC の評価軸は、単純な接続成功ではなく、タスク成功率、誤ツール選択率、承認 UI 通過率、平均レイテンシ、権限昇格の頻度、失敗時の可観測性、セキュリティ検証結果まで含めるべきです。導入工数は依頼上 no specific constraint であり、狭い 1 ドメインの PoC なら概ね 4〜12 週間が現実的なレンジですが、これは仕様・認可・テスト・安全策を含む概算であり、対象システム数と認可方式で大きく変動します。 

定義と目的

MCP は、アプリケーションが LLM に「文脈」を提供する方法を標準化するオープンプロトコルです。Anthropic の初出説明では、既存の AI ツールが情報サイロの中に閉じ込められ、データソースごとに個別統合が必要になることを問題視し、MCP をその断片化を置き換える「universal, open standard」と位置づけています。Anthropic のドキュメントでも、MCP は AI アプリケーション向けの USB-C のようなものと説明されており、MCP Server はこの標準インターフェースのサーバ側実装に相当します。 

現在の仕様体系では、MCP は大きく Base Protocol、Lifecycle Management、Authorization、Server Features、Client Features、Utilities で構成され、すべての実装は少なくとも base protocol と lifecycle を実装しなければなりません。送受信メッセージは JSON-RPC 2.0 に従い、request/response/notification を基本単位とします。これにより、MCP は「ある 1 社 API のラッパ」ではなく、ホスト・クライアント・サーバが相互運用可能な共通 wire protocol になります。 

設計思想上の核心は、MCP が “LLM が扱うインターフェースの型” を分離していることです。公式仕様は以下のように整理しています。 

この区分は、RAG・関数呼び出し・エージェント実行をひとまとめにしないために重要です。Resources は「読む文脈」、Tools は「行動」、Prompts は「ワークフローの入り口」を表し、さらに client features として sampling や elicitation があるため、MCP Server は単なるデータ公開サーバではなく、モデル・ユーザー・アプリ間の責務分離を explicit にした対話実行基盤として読むのが正確です。 

原典と提案元について整理すると、MCP そのものは 2024 年 11 月に Anthropic が公開し、その後 2025 年 12 月に Agentic AI Foundation へ寄贈されました。現在のガバナンス文書では、Model Context Protocol は LF Projects, LLC 配下の formal governance model で運営され、主要な仕様変更は SEP（Specification Enhancement Proposal）を通じて進みます。したがって、歴史的提案元は Anthropic、現行のオープンガバナンス先は Linux Foundation 系のプロジェクトと整理するのが妥当です。共同設立メンバーとしては、Block や OpenAI を含む複数企業が Anthropic の寄贈発表で挙げられています。 

主要実装とエコシステム

公式の SDK ページでは、MCP SDK は tier 制で整理されており、TypeScript / Python / C# / Go が Tier 1、Java / Rust が Tier 2、Swift / Ruby / PHP が Tier 3、Kotlin は TBD とされています。Tier の定義自体も公式化されており、Tier 1 は非実験機能を含む完全実装、100% conformance、明確な保守コミットメントを要求します。したがって、実装選定では「GitHub の star 数」だけでなく、SDK tier・安定ブランチ・認可対応・サンプル/テスト資産を重視すべきです。 

また、Go SDK は Google、C# SDK は Microsoft、Kotlin SDK は JetBrains、Java SDK は Spring AI との協業がリポジトリで明記されています。これは企業内の既存ランタイムへ MCP を載せるうえで重要なシグナルです。 

公式 SDK の比較

以下の「成熟度」は、公式 tier、README の安定性表記、最新 release、機能記述をもとにした実務評価です。導入難易度は筆者評価であり、既存言語資産・HTTP 認可・運用要件で上下します。

公式 OSS プロジェクトの比較

SDK 以外にも、MCP 実装・検証・配布に関わる公式 OSS が重要です。特に reference servers / inspector / registry / conformance は、PoC と本番ガードレールの双方で実用価値があります。 

実務的な読み方としては、SDK は Tier と安定ブランチを見る、servers は参考実装として読む、inspector/conformance は必須の開発基盤として使う、registry は流通面の成熟を観察しながら使う、が妥当です。特に reference servers は人気が高くても、そのまま本番採用の根拠にはなりません。公式 README 自身がそれを明確に警告しています。 

アーキテクチャと通信フロー

MCP の基本アーキテクチャは Host → Client → Server の三層です。公式アーキテクチャ解説では、Host は Claude Code や Claude Desktop のような AI アプリケーション全体、Client は Host 内でサーバとの 1 対 1 接続を維持する通信コンポーネント、Server は外部システムへの安全なラッパとされます。ローカルの stdio サーバは通常 1 クライアント前提、リモートの Streamable HTTP サーバは複数クライアントを扱う想定です。 

MCP が標準で定義する transport は stdio と Streamable HTTP の 2 つです。stdio はサブプロセス起動・標準入出力による単純なローカル接続に向き、JSON-RPC メッセージを newline 区切りで流します。Streamable HTTP は 1 本の MCP endpoint に対する POST/GET を使い、必要に応じて SSE をメッセージ配信に使います。なお、2024-11-05 版の旧 HTTP+SSE transport は deprecated であり、2025-11-25 版では Streamable HTTP が置き換え先です。 

サーバ接続の lifecycle は、initialize → normal operation → shutdown が基本です。初期化では protocol version、capabilities、implementation info を交換し、その後に tools/list、resources/list、prompts/list、tools/call など通常通信に移ります。HTTP ベースの保護サーバでは、この前後に OAuth 2.1 ベースの認可 discovery と token 取得が入ります。 

上図の要点は、Host が UX・承認・ポリシーを司り、Client がプロトコル実装を担い、Server が外部系統の安全な表現層になることです。重要なのは、Server が直接 LLM と話すのではなく、常に Host/Client 経由で能力公開されることです。これにより、人間の承認、ポリシー適用、監査が Host 側に置けます。 

実運用ではさらに、Streamable HTTP の session ID、再接続、redelivery、そして 2025-11-25 で experimental とされた tasks をどう使うかが設計論点になります。仕様上、サーバは MCP-Session-Id を返せ、クライアントは後続リクエストに付与し、404 を受けたら再初期化することが求められます。長時間処理は tasks で表現可能ですが、tasks はまだ experimental であるため、PoC では通常 request と明示的なタイムアウト/再試行で始める方が安全です。 

セキュリティ・認可・監査と運用

MCP Server のセキュリティは、通常の API セキュリティに「LLM 特有の自律性」と「外部サーバ混在」を加えたものとして考えるべきです。公式の Security Best Practices は、confused deputy、token passthrough、SSRF、session hijacking、local MCP server compromise、scope minimization failure を典型脅威として整理しています。これは、MCP が“モデルに外部権限を与える標準化層”である以上、どの権限を、どの UI で、どのトークンで、どのログに残すかを最初から設計に埋め込む必要があることを意味します。 

脅威モデルと推奨策

上表の要点は、MCP が提供する「使いやすさ」をそのまま許可してしまうと、モデルが便利になるほど事故半径も広がるということです。特に token passthrough は仕様・セキュリティ文書の両方で明確に禁止されています。ここは一般的な API proxy 設計の延長で済ませず、MCP の trust boundary と audit boundary を維持することが重要です。 

認可については、HTTP ベース transport では OAuth 2.1 準拠が推奨され、Protected Resource Metadata（RFC 9728）、Authorization Server Metadata（RFC 8414）または OIDC Discovery、PKCE、Resource Indicators（RFC 8707）、audience validation が中核です。仕様上、MCP client は resource パラメータを実装し、server は「自分向けに発行された token のみ」受理しなければなりません。逆に stdio transport では authorization spec をそのまま使うのではなく、環境変数などローカル実行文脈で資格情報を扱うべきとされています。 

監査ログについては、公式 security docs が token passthrough を監査面の観点からも否定しており、さらに scope minimization の節では elevation event を correlation ID 付きで記録することが推奨されています。実務上は、少なくとも client ID / user ID / server name / tool name / arguments hash / approval outcome / downstream request ID / scope elevation / final status を紐づける設計にすべきです。Slack は audit logs を明示し、GitHub は read-only mode や toolset 最小化を前提にできるため、実装上の参考になります。 

運用課題と対策

この表のうち、スケーリングは Streamable HTTP の session 管理・再接続仕様に加え、公式 feature reference server が Redis-backed session management による horizontal scalability を例示している点が参考になります。つまり、複数インスタンス配下で MCP Server を運用する場合、stateless HTTP API のつもりで扱わず、session/event delivery 層を先に設計する必要があるということです。 

RAGやAPI連携との違いとエージェント設計への影響

MCP はしばしば「RAG の標準化版」や「function calling の共通化」と説明されがちですが、厳密にはどちらとも一致しません。MCP は 取得・操作・対話補助をまとめて扱うプロトコルであり、RAG は 知識検索と文脈注入のアプリケーション・パターンです。したがって、MCP は RAG を包含し得ますが、RAG に還元はできません。仕様上、Resources は文脈注入に向いていますが、Tools は外部作用を持ち、さらに sampling/elicitation により server 側が人やモデルへ逆問い合わせすることもできます。 

また、従来 API 連携との差も大きいです。Slack の公式解説は、API が deterministic な software-to-software integration であるのに対し、MCP は AI model-to-data / agent interactions 向けで、クライアントが runtime に「どんな tools を提供できるか」を問い合わせられる点を強調しています。つまり API は開発者が先にエンドポイントごとの手書きコードを書く世界、MCP は 実行時 discoverability と schema-driven interaction を前提にした世界です。 

比較整理

この違いはエージェント設計に直接効きます。第一に、MCP では tool 数を増やすほど賢くなるわけではありません。GitHub の公式 MCP server は、toolsets を必要最小限に絞る方が tool selection accuracy と security に有利だと明言しています。第二に、MCP の control hierarchy を守ると、読むものは Resources、変えるものは Tools、定型起点は Prompts と設計でき、責務が整理されます。第三に、sampling/elicitation を使うと server 側からモデル呼び出しやユーザー入力要求が発生しうるため、agent loop はより強力になりますが、その分 HIL と iteration limit が不可欠になります。 

結論として、MCP は「API をプロトコル化したもの」ではなく、エージェントにとっての実行環境を標準化したものです。RAG 基盤、GraphQL、REST、ファイル、DB、ブラウザ automation は、その背後実装として MCP Server の内側に入り得ます。したがってアーキテクトの論点は「RAG か MCP か」ではなく、RAG / API / DB / browser / SaaS をどの責務単位で MCP の tools/resources/prompts に写像するかです。 

導入手順の骨子

導入の現実解は、いきなり全社共通コントロールプレーンを目指すのではなく、狭い 1 業務フローで “価値と危険” を同時に計測する PoC から始めることです。公式ドキュメント群から見ても、最初に用意すべきものは、MCP client が動く host、対象となる 1 つか 2 つの system、認可方式、そして Inspector / Conformance を含むテスト導線です。HTTP で出すなら OAuth 2.1 と metadata discovery、ローカル限定なら stdio と明示承認で始めるのが無難です。 

PoC ステップと想定レンジ

以下の工数は 推定であり、依頼上は no specific constraint、すなわち具体制約は未指定です。対象システムが 1 つで、専任 1〜2 名のエンジニアとセキュリティ/業務オーナーのレビューを前提にした実務レンジです。

合計の概算としては、狭い 1 ドメインの PoC でおおむね 4〜12 週間が目安です。SSO/OAuth、監査、複数 downstream、承認 UI、multi-instance 運用まで含めると上振れしやすく、逆にローカル stdio のみ・read-only・簡易 host なら下振れします。これは公式仕様が lifecycle・authorization・conformance・security を比較的しっかり要求していることの裏返しです。 

評価指標

PoC の評価指標は、接続成功だけでは不十分です。最低でも以下を取るべきです。

• 有効性: タスク成功率、回答品質、再試行率、human handoff 率
• 効率: 平均レイテンシ、tool call 回数、token 消費、失敗回復時間
• 安全性: 承認 UI の拒否率、scope 昇格頻度、read-only 逸脱検知、セキュリティテスト所見
• 運用性: 再接続成功率、session 失効影響、ログ相関可能性、CI conformance pass rate

これらは公式仕様のメッセージライフサイクル、認可、scope、conformance、security guidance を PoC の KPI に翻訳したものです。特に「モデルが便利に使えたか」だけでなく、「どのくらい安全に拒否・縮退できたか」を評価軸に入れるべきです。 

事例・ユースケース

エコシステムの成熟度を見るうえで重要なのは、MCP が既に 開発ツール・コラボレーション・ナレッジ・API orchestration にまたがって使われていることです。Anthropic の 2025 年末発表では、MCP は 10,000 超の public server を持ち、ChatGPT、Cursor、Gemini、Microsoft Copilot、Visual Studio Code などに採用されたとされています。これは、MCP が単一ベンダAPIではなく、実際に cross-platform な接続層として受け入れられ始めていることを示します。 

主要カテゴリ別のユースケース

開発領域では、GitHub Docs が GitHub MCP Server の主要機能を、リポジトリ/コード閲覧、issue/PR 管理、workflow 監視、code scanning などとして説明しており、さらに toolset の絞り込みと read-only mode を推奨しています。ブラウザ用途では、Microsoft の Playwright MCP が accessibility snapshot を活用した deterministic な web interaction を提供します。Filesystem の公式 reference server は、read/write、ディレクトリ管理、検索、metadata、Roots による動的 directory access control を備えます。 

コラボレーション領域では、Slack の公式 MCP server が、検索、メッセージ送信、チャンネル/スレッド読取、canvas 操作、user 管理を提供し、admin approval と audit log を前提にしています。Notion MCP はホスト型 server として、OAuth 接続、ページ read/write、タスク管理、レポート生成、workspace 横断検索といった業務知識系の用途を前面に出しています。これらは「RAG 用にデータを index する」よりも、SaaS の live state を AI が権限付きで扱うユースケースです。 

API orchestration 領域では、Apollo MCP Server が GraphQL operations を MCP tools として公開し、persisted query や policy enforcement を通じて AI への公開面を絞る設計を打ち出しています。これは「MCP を最前線に置き、背後の複数 REST/GraphQL API を graph で統制する」構成に向いています。企業内で多数の既存 API を抱える場合、個別の function calling schema を乱立させるより、この方向の方がガバナンスしやすい可能性があります。 

データベース用途については注意が必要です。公式の servers リポジトリでは PostgreSQL reference server は archived 扱いで「read-only database access with schema inspection」と要約されていますが、reference server は production-ready とされていません。したがって、本番の DB 接続は read-only user、query 制限、statement timeout、監査、場合によっては allow-listed persisted query を備えた独自実装、または十分にレビューしたコミュニティ実装に寄せるのが無難です。 

参考資料と優先参照ソース

本調査で優先したのは、Anthropic 公式、modelcontextprotocol.io の仕様・ガバナンス文書、主要 OSS リポジトリ、関連企業の公式ドキュメントです。特に、仕様解釈の基準は modelcontextprotocol.io の versioned spec、ガバナンスと来歴は Anthropic と governance 文書、実装成熟度は SDK tier と各 repo README/release 情報に置きました。Registry は依然として preview / API freeze v0.1 フェーズ、reference servers は教育用、TypeScript/Python は stable branch と次期 main branch が分かれている点に注意が必要です。 

優先参照ソース

Anthropic / 来歴
https://www.anthropic.com/news/model-context-protocol
https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation
https://docs.anthropic.com/en/docs/mcp

MCP 公式仕様・ガバナンス
https://modelcontextprotocol.io/specification/2025-11-25/basic
https://modelcontextprotocol.io/specification/2025-11-25/basic/lifecycle
https://modelcontextprotocol.io/specification/2025-11-25/basic/transports
https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization
https://modelcontextprotocol.io/specification/2025-11-25/server/index
https://modelcontextprotocol.io/specification/2025-11-25/server/tools
https://modelcontextprotocol.io/specification/2025-11-25/client/sampling
https://modelcontextprotocol.io/community/governance
https://modelcontextprotocol.io/community/seps/index
https://modelcontextprotocol.io/docs/sdk
https://modelcontextprotocol.io/community/sdk-tiers

主要 OSS リポジトリ
https://github.com/modelcontextprotocol/typescript-sdk
https://github.com/modelcontextprotocol/python-sdk
https://github.com/modelcontextprotocol/go-sdk
https://github.com/modelcontextprotocol/csharp-sdk
https://github.com/modelcontextprotocol/java-sdk
https://github.com/modelcontextprotocol/kotlin-sdk
https://github.com/modelcontextprotocol/servers
https://github.com/modelcontextprotocol/inspector
https://github.com/modelcontextprotocol/conformance
https://github.com/modelcontextprotocol/registry

関連企業の公式ドキュメント
https://docs.github.com/en/copilot/concepts/context/mcp
https://github.com/github/github-mcp-server
https://docs.slack.dev/ai/slack-mcp-server/
https://slack.com/help/articles/48855576908307-Guide-to-the-Slack-MCP-server
https://developers.notion.com/guides/mcp/overview
https://github.com/microsoft/playwright-mcp
https://www.apollographql.com/docs/apollo-mcp-server

学術・標準周辺で合わせて見るべき資料

OAuth 2.1 draft
RFC 8414: OAuth 2.0 Authorization Server Metadata
RFC 8707: Resource Indicators for OAuth 2.0
RFC 9728: OAuth 2.0 Protected Resource Metadata
OWASP SSRF Prevention Cheat Sheet

Open questions / limitations

• MCP のエコシステム変化は速く、公式 SDK や hosted servers の成熟度は四半期単位で動いています。とくに Registry は preview 系の性格が残り、将来の GA 仕様で運用前提が変わる余地があります。 
• 公式 reference servers の多くは「見本」であって、そのまま本番採用を推奨していません。安全性・監査・SLO を要する環境では独自 hardening が前提です。 
• 公開事例の多くは機能説明や採用表明が中心で、定量 ROI は未指定または限定的でした。そのため本レポートの「期待効果」は、公開機能と運用特性からの保守的な推定を含みます。