MCP（Model Context Protocol）の企業活用に関する包括的な知識ポイント --- 基礎編

本編では、プロトコルの原理、アーキテクチャ設計、中核機能、トランスポート層、通信プロトコル、Server/Clientのエンジニアリング実装およびセキュリティモデルについて解説します。

上級者向けの内容については、「MCPの企業活用に関する包括的な知識ポイント - 上級編」をご覧ください。

---

目次

1. [MCPの概要と核心的な課題](#MCPの概要と核心的な課題)
2. プロトコルアーキテクチャと核心概念
3. 3つのコア機能モデル
4. トランスポート層の詳細解説
5. 通信プロトコルとライフサイクル
6. [MCPサーバーのエンジニアリング実装](#MCPサーバーのエンジニアリング実装)
7. [MCPクライアントの開発](#MCPクライアントの開発)
8. セキュリティモデルと認証・認可

---

1. MCPの概要と核心的な課題

1.1 MCPとは

MCP（Model Context Protocol、モデルコンテキストプロトコル）は、Anthropic社が2024年11月に提唱したオープンスタンダードプロトコルであり、大規模言語モデル（LLM）と外部ツール／データソースとの接続方法を標準化することを目的としています。

一言で定義すると：すべてのAIアプリケーションが、各システムごとに独自の統合方法を記述するのではなく、同一の「プラグアンドプレイ式インターフェース」を使用してツール、データ、コンテキストにアクセスできるようにすることです。

公式定義：MCPは、アプリケーションがLLMにコンテキストやツールを提供するための標準化された方法を提供するオープンプロトコルです。これは、AIアプリケーションの「USB-Cインターフェース」と捉えることができます――モデルがさまざまなデータソースやツールに統一された方法で接続できるようにする汎用規格です。

1.2 なぜMCPが必要なのか（核心的な課題）

MCPが登場する以前、大規模モデルが外部機能と連携する際には、深刻な断片化の問題に直面していました：

問題	説明
統合コストが高い（N×M）	N個のモデル × M個のツール、各組み合わせごとに個別に適合させる必要がある
インターフェースが統一されていない	各ツールごとに独自の SDK と呼び出し方法がある
コンテキストの引き継ぎが混乱している	プロンプトの連結／関数呼び出し／プラグインの形式がまちまち
再利用が困難	LangChain 用に作成されたツールは AutoGPT で使用できない
セキュリティ制御の欠如	標準化された権限およびセキュリティ制御メカニズムの欠如
ツールがモデル間で移行しにくい	GPT向けの関数呼び出しをClaudeで直接使用できない

1.3 MCPの設計目標

MCPは以下の3点を統一する：

1. ツール呼び出しプロトコルの統一 --- モデルがツールにアクセスする際、各ベンダー固有の関数呼び出し形式ではなく、標準的な構造に従うようにする
2. コンテキストへのアクセス方法の統一 --- モデルが標準的な方法でファイル、データベース、API、ローカルリソースにアクセスできるようにする
3. サービス記述方法の統一 --- すべての機能を機械で記述可能にする （OpenAPIに類似しているが、より汎用的）

1.4 MCPの設計哲学

• ローカル優先（Local-first）：分散型サービス呼び出しではなく、ローカルツールのオーケストレーションを最適化する
• モデル非依存：特定のLLM（GPT/Claude/Llama/ ローカルモデルもすべて接続可能）
• 組み合わせ可能性：ツールはCLIツールと同様に組み合わせ可能であるべき
• 標準化：一度開発すれば、どこでも実行可能

---

2. プロトコルアーキテクチャと中核概念

2.1 全体アーキテクチャ

┌──────────────────────────┐
│ MCP Host（ホスト） │ ← Claude Desktop / IDE プラグイン / Agent フレームワーク
│ ┌────────────────────┐ │
│ │ MCP Client │ │ ← Serverへの接続、セッション管理、リクエストの発行
│ └────────┬───────────┘ │
│ │ トランスポート │ ← stdio / Streamable HTTP / WebSocket
│ ┌────────▼───────────┐ │
│ │ MCPサーバー │ │ ← ツール / リソース / プロンプトの公開
│ └──── ────┬───────────┘ │
│ │ │
│ 外部システム / API / DB │
└──────────────────────────┘

2.2 3つの主要コンポーネント

コンポーネント	役割	例
MCP Host	LLMの実行、MCP Clientの管理、ユーザーインターフェースの提供	Claude Desktop、VS Code プラグイン、 IDE Agent
MCP Client	MCP Serverへの接続、リクエストの発行、セッションおよびプロトコルネゴシエーションの管理	Hostに組み込まれたプロトコルアダプター層
MCP Server	ツール／リソース／プロンプトテンプレートの公開、呼び出しロジックの実行	あらゆる外部機能を標準APIとしてラッピングするアダプテーション層

重要なポイント：MCP Server ≠ アプリケーションであり、単なる「機能アダプテーション層」である。

2.3 MCP の階層型アーキテクチャ

┌─────────────────────────┐
│ Application Layer │ ← ツール / リソース / プロンプト
├─────────────────── ──────┤
│ プロトコル層 │ ← JSON-RPC 2.0 メッセージ仕様
├─────────────────────────┤
│ トランスポート層 │ ← stdio / Streamable HTTP / WebSocket
└─────────────────────────┘

階層	役割
MCPプロトコル	tools/resources/prompts 仕様
JSON-RPC	メッセージ構造 （リクエスト／レスポンス／通知）
Transport	伝送方式（stdio／HTTP／WS）
MCP Server	実行ロジック

---

3. 3つのコア能力モデル

MCPが統一するのは「ツール」ではなく、3つの抽象化カテゴリである：

3.1 Tools（ツール）

実行可能関数 --- モデルによってトリガーされる操作

特徴：

• 入出力がある
• モデルによって呼び出しがトリガーされる
• 関数呼び出しに類似
• 副作用がある場合がある（データベースへの書き込み、メール送信など）

構造例：

{
  「name」: 「get_weather」,
  「description」: 「指定した都市の天気情報を取得する」,
  「inputSchema」: {
    「type」: 「object」,
    「properties」: {
      「city」: { 「type」: 「string」, 「description」: 「都市名」 }
    },
    『required』: [「city」]
  
}
}

呼び出し例：

{
  「name」: 「get_weather」,
  「arguments」: { 『city』: 「Beijing」 }
}

返り値の例：

{
  「content」: [
    { 「type」: 「text」, 『text』: 「Beijing: 28°C, sunny」 }
  ]
}

3.2 リソース（Resources）

読み取り可能なコンテキストデータ --- ロジックは実行せず、データのみを提供

特徴：

• ロジックは実行せず、データのみを提供
• URI形式でのアクセスをサポート
• アクセス制御が可能
• モデルへの提供の可否はアプリケーションによって制御される

例：

file:///project/readme.md
db://users/123
github://repo/owner/name/issues/42

リソース宣言：

{
  「uri」: 「file:///project/readme.md」,
  「name」: 「Project README」,
  「mimeType」: 「text/plain」,
  『description』: 「プロジェクトの説明ドキュメント」
}

3.3 Prompts（プロンプトテンプレート）

再利用可能なプロンプトテンプレート -- - プロンプトの標準化

特徴：

• プロンプトをクライアント側に固定せず、標準化
• パラメータ化されたテンプレートをサポート
• 動的なリソースの埋め込みをサポート

例：

{
  「name」: 「code_review」,
  『description』: 「コードレビュー用プロンプトテンプレート」,
  
「arguments」: [
    {
      「name」: 「code」,
      「description」: 「レビュー対象のコード」,
      「required」: true
    },
    {
      「name」: 「language」,
      「description」: 『プログラミング言語』,
      「required」: false
    
}
  ]
}

3.4 3つの能力の比較

次元	ツール	リソース	プロンプト
本質	実行可能な関数	読み取り可能なデータ	再利用可能なテンプレート
トリガー元	モデル	アプリケーション	ユーザー
副作用	あり	なし	なし
動的性	動的検出	動的サブスクリプション	動的組み合わせ
類推	API呼び出し	ファイル読み取り	テンプレートエンジン

---

4. トランスポート層の詳細

MCPのトランスポート層は、プロトコル全体において最も重要な部分の一つであり、MCPの動作形態、性能の限界、セキュリティモデル、および展開方法を決定します。

4.
1 トランスポート層の本質

MCP トランスポート層 = JSON-RPC 2.0 メッセージを「プロセス間／ネットワーク間で確実に伝達する」メカニズムの抽象化層

これは以下の3つの問題を解決します：

1. メッセージの送信方法（stdin / HTTP / WebSocket）
2. メッセージをどのようにシリアライズするか？（JSON-RPC）
3. セッションとストリーム型インタラクションをどのように維持するか？

4.2 3つの伝送方式

4.2.1 stdio Transport（ローカルプロセス間通信）

最も一般的で、デフォルトの方式

クライアント → MCPサーバープロセスを起動
       ↓ stdin
     JSON-RPCリクエスト
       ↑ stdout
     サーバーが応答

特徴	説明
ネットワーク不要	純粋なプロセス間通信
極めて低い遅延	HTTPオーバーヘッドゼロ
高いセキュリティ	ポートを公開しない
ライフサイクルバインディング	クライアントがサーバープロセスを制御

メッセージ形式：1行につき1つのJSON

{「jsonrpc」:「2.0」,「id」:1,『method』:「tools/list」}

プロジェクトの要点：

• 行ごとに解析する必要があり、JSON全体をバッファに格納することはできない
• stdoutをフラッシュする必要がある。そうしないとクライアントが受信できない
• IDの厳密なマッピングにより、並行呼び出し時の順序が乱れないことを保証

適用シナリオ：IDEプラグイン、デスクトップAIツール、ローカルエージェントランタイム

4.2.2 Streamable HTTP Transport（リモートサービス通信）

2025年3月のバージョンで導入され、従来のSSE Transportを完全に置き換えた

リクエストモデル：

POST /mcp
Content-Type: application/json
Accept: application/json, text/event-stream

{
  「jsonrpc」: 「2.0」,
  『method』: 「tools/call」,
  
「params」: { ... },  「id」: 1}

機能	説明
リモート展開可能	クラウド上の MCP サーバー
水平スケーラビリティ対応	ステートレス設計
SSE ストリームに対応	長時間タスクのストリーム形式での返却が可能
認証が必要	JWT / OAuth 2.1

主な改善点（旧 SSE Transport との比較）：

• 単一のエンドポイント（/mcp）により、デプロイが簡素化
• ステートレスなリクエストにより、水平スケーリングに対応
• SSE ストリーミング応答のオプション
• 組み込みのセッション管理（Mcp-Session-Id）

適用シナリオ：SaaSツール、エンタープライズAPIゲートウェイ、マルチユーザーMCPサーバー

4.2.3 旧SSEトランスポート（非推奨）

2024年11月5日版で定義され、2025年3月版で非推奨とマーク済み

2つのHTTPエンドポイントを使用：/sse（サーバー→クライアント）および /messages（クライアント→サーバー）。ステートフルであることや水平スケーラビリティに欠けるなどの問題により、Streamable HTTPに置き換えられました。

4.2.4 トランスポート方式の選択ガイド

ユースケース	推奨トランスポート	理由
ローカル IDE プラグイン	stdio	遅延ゼロ、ネットワークへの露出なし
個人用 AI デスクトップツール	stdio	プロセスレベルの分離、セキュリティ
チーム共有 MCP サービス	Streamable HTTP	リモートアクセス可能、マルチユーザー対応
エンタープライズ向け MCP プラットフォーム	Streamable HTTP	拡張性あり、認証対応
リアルタイム双方向インタラクション	Streamable HTTP + SSE	進行状況のプッシュ通知に対応

4.3 MCPがHTTP/2やgRPCを選ばない理由

MCPが、より「高度な」プロトコルではなくstdio + JSON-RPCを選択したのは、以下のトレードオフに基づくものである：

観点	MCPの選択	理由
ランタイムの結合度	結合度が低い	HTTP/2 は TLS との強固な結合 + 接続管理
ツールモデル	実行可能プロセス	ツールは「サービス」ではなく「関数」であるべき
呼び出しパターン	高頻度・短ライフサイクル	HTTP/2のオーバーヘッドがかえって重くなる
セキュリティモデル	プロセスレベルの分離	stdio は天然のサンドボックスエントリ
導入コスト	極めて低い	ネットワークインフラが不要

中核となる哲学：MCPは「ローカルツールのオーケストレーション」を優先的に最適化し、リモートデプロイはStreamable HTTPを通じてサポートされる。

---

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

5.1 JSON-RPC 2.0

MCPはJSON-RPC 2.0に基づいており、すべての通信は標準的なJSON構造を採用しています。

リクエスト：

{
  「jsonrpc」: 「2.0」,
  「id」: 1,
  「method」: 「tools/call」,
  「params」: { 「name」: 「get_weather」, 「arguments」: { 『city』: 「Beijing」 } }
} 

レスポンス：

{
  「jsonrpc」: 「2.0」,
  「id」: 1,
  「result」: {
    『content』: [{ 「type」: 「text」, 『text』: 「Beijing: 28°C, sunny」 }]
  }
}

通知（Notification、返り値なし）：

{
  「jsonrpc」: 「2.0」,
  「method」: 「notifications/progress」,
  「params」: { 「progressToken」: 「job-123」, 『progress』: 40, 「total」: 100 }
}

5.2 MCPプロトコルのライフサイクル

1. 接続の初期化
   Client → Server: initialize (機能のネゴシエーション + バージョンハンドシェイク)
   Server → Client: 機能の応答

2. ツールの検出（Discovery）
   Client → Server: tools/list
   Server → Client: 利用可能なすべてのツールを返す

3. ツールの呼び出し
   Client → Server: tools/call
   Server → Client: 結果を返す

4. （オプション）リソースへのアクセス
   Client → Server: resources/list
   Client → Server: resources/read

5. （オプション）プロンプトテンプレート
   Client → Server: prompts/list
   Client → Server: prompts/get

6. 接続の切断
   Client → Server: 切断通知

5.3 機能ネゴシエーション（Capability Negotiation）

初期化時に、ClientとServerはそれぞれがサポートする機能を交換します：

{
  「protocolVersion」: 「2025-03-26」 ,
  「capabilities」: {
    「tools」: { 「listChanged」: true },
    「resources」: { 「subscribe」: true, 「listChanged」: true },
    「prompts」: { 『listChanged』: true },
    「logging」: {}
  }
}

5.4 ストリーム通信と進捗通知

MCPは、Notificationを介したストリーム型インタラクションをサポートしています：

進捗通知：

{
  「jsonrpc」: 「2.0」,
  
「method」: 「notifications/progress」,
  「params」: {
    「progressToken」: 「task-123」,
    『progress』: 50,
    「total」: 100
  }
}

ログ通知：

{
  「jsonrpc」: 「2.0」,
  「method」: 「notifications/message」,
  「params」: {
    「level」: 「info」,
    『data』: 「クエリを処理中...」
  }
}

---

6. MCP Server の実装

6.1 MCP Server の最小インターフェースセット

「動作可能な」MCP Server には、少なくとも以下を実装する必要があります：

メソッド	必要性	説明
initialize	必須	ハンドシェイクおよび機能ネゴシエーション
tools/list	必須	ツール一覧を返す
tools/call	必須	ツール呼び出しを実行する
resources/list	オプション	リソース一覧を返す
resources/read	オプション	リソースの内容を読み込む
prompts/list	オプション	プロンプトテンプレートのリストを返す
prompts/get	オプション	プロンプトテンプレートを取得する

6.2 Node.js での実装（公式 SDK を使用）

import { McpServer } from 「@modelcontextprotocol/sdk/server/mcp.js」;
import { StdioServerTransport } from 「@modelcontextprotocol/sdk/server/stdio.js」;
import { z } from 「zod」;

const server = new McpServer({
  name: 「my-server」,
  version: 「1.0.0」,
});

// ツールの登録
server.tool(
  「add」,
  『2つの数字の加算』,
  { a: z.number(), b: z.number() },
  async ({ a, b }) => ({
    content: [{ type: 「text」, text: String(a + b) }],
  })
);

// リソースの登録
server.resource(「config」, 「config://app」, async (uri) => ({
  contents: [{ uri: uri.href, text: 「app config content」 }],
}));

// プロンプトテンプレートの登録
server.prompt(「code_review」, { code: z.string() }, async ({ code }) => ({
  messages: [{ role: 『user』, content: { type: 「text」, text: `コードレビュー:\\n${code}` } }],
}));

// 起動
const transport = new StdioServerTransport();
await server.connect(transport);

6.3 Python 実装（FastMCP を使用）

from fastmcp import FastMCP

mcp = FastMCP(「my-server」)

@mcp.tool()
def add(a: int, b: int) -> int:
    「」『2つの整数を足し合わせる』「」
    
return a + b

@mcp.resource(「config://app」)
def get_config() -> str:
    「」「アプリケーションの設定を取得する」「」
    return 「app config content」

@mcp.prompt()
def code_review(code: str) -> str:
    「」『コードレビューのヒントテンプレート』「」
    
return f「コードレビュー:\\n{code}」

if __name__ == 「__main__」:    mcp.run() # デフォルトでは stdio 経由で出力

6.4 高度な設計のポイント

6.4.1 ツールレジストリ（Tool Registry）

const toolRegistry = {  add: ({ a, b }) => a + b,  multiply: ({ a, b }) => a * b,  search: async ({ query }) => await searchAPI(query),};

6.4.2 スキーマ検証（必須）

import { z } from 「zod」;const AddSchema = z.object({  a: z.number(),  b: z.number(),});

6.4.3 非同期ツール（実際のシナリオでよく見られる）

async function fetchWeather(city: string) {  const res = await fetch(`https://api.weather.com/${city}`);  return res.json();}

6.4.4 エラーの標準化

{  「jsonrpc」: 「2.0」,  「id」: 1,  「error」: {    「code」: -32603,    『message』: 「Internal error」  }}

標準エラーコード：

エラーコード	意味
-32700	Parse error（解析エラー）
-32600	Invalid Request（無効なリクエスト）
-32601	Method not found（メソッドが見つかりません）
-32602	Invalid params（無効なパラメータ）
-32603	Internal error（内部エラー）

6.5 重要な設計原則

1. MCP Server ≠ アプリケーション --- これは単なる「機能適応層」である
2. ツールは純粋関数型でなければならない --- 入力 → 出力、暗黙的な状態を回避
3. すべての I/O は明示的に宣言しなければならない --- データベース／ファイル／API はすべて tools/resources
4. schema-first --- ツールには厳格な inputSchema

が必要

5. 幂等性設計 --- 繰り返し呼び出しでも同じ結果が得られるよう最大限保証する

6.6 推奨されるプロジェクト構造

mcp-server/
  src/
    index.ts # エントリポイント
    transport/
      stdio.ts # stdio 転送
      http.ts # HTTP 転送
    tools/
      add.ts # ツールの実装
      weather.ts
    
resources/
      files.ts # リソースの実装
    prompts/
      review.ts # プロンプトテンプレート
    registry.ts # ツールレジストリ

---

7. MCP Client の開発

7.1 Client の主要な役割

• MCP Server への接続
• リクエストの発行（tools/call など）
• セッションとライフサイクルの管理
• 通知とストリーミング応答の処理

7.2 公式 SDK を使用した Client の開発

import { Client } from 「@modelcontextprotocol/sdk/client/index.js」;
import { StdioClientTransport } from 「@modelcontextprotocol/sdk/client/stdio.js」;

const transport = new StdioClientTransport({
  command: 「node」,
  args: [「my-mcp-server.js」],
});

const client = new Client({
  name: 「my-client」,
  version: 「1.0.0」,
});

await client.connect(transport);

// 利用可能なツールの一覧を表示
const tools = await client.listTools();

// ツールを呼び出す
const result = await client.callTool({
  name: 「add」,
  arguments: { a: 1, b: 2 },
});

// リソースの一覧を表示
const resources = await client.listResources();

// リソースを読み込む
const content = await client.readResource({ uri: 「file:///readme.md」 });

7.3 Client の設定（MCP Host 内）

stdio モード：

{
  「mcpServers」: {
    「my-local-server」: {
      「command」: 「node」,
      「args」: [「./mcp-server/index.js」],
      「env」: { 『API_KEY』: 「xxx」 }
    }
  }
}

リモート HTTP モード：

{
  「mcpServers」: {
    「my-remote-server」: {
      「url」: 「https://api.my-mcp.com/mcp」,
      「headers」: {
        『Authorization』: 「Bearer xxx」
      }
    }
  }
}

---

8. セキュリティモデルと認証・認可

8.1 セキュリティ上の課題

MCP ツールの本質は「システムの権限を LLM に公開すること」であるため、セキュリティは本番環境導入における核心的な課題となる：

• MCP サーバーは、シェル実行、ファイル読み取り、DB 操作、外部 API 呼び出しが可能
• LLM がプロンプトインジェクション攻撃によって操作される可能性がある
• ツールの呼び出しチェーンにより、連鎖的なセキュリティリスクが発生する可能性がある

8.2 3層セキュリティモデル

Layer 1: Process Sandbox（プロセス隔離）
   ↕
レイヤー2：Capability Sandbox（ツールレベルの権限）
   ↕
レイヤー3：Data Sandbox（データレベルの隔離）

レイヤー1：プロセス隔離

方式	説明
Docker / gVisor	コンテナレベルの隔離
seccomp	システムコールの制限
namespace	ネームスペースによる隔離
WASM（今後のトレンド）	サンドボックスランタイム

制限：ルートファイルシステムへのアクセス不可、制限付きネットワーク出口、CPU/メモリのクォータ

レイヤー2：ツールレベルの権限

{
  「name」: 「read_file」,
  「annotations」: {
    『permissions』: [「fs:read」]
  }
}

if (!ctx.permissions.includes(「fs:read」)) {
  throw new Error(「forbidden」);
}

ツールアノテーション（Tool Annotations） は、MCP 仕様においてツールのセキュリティ属性を定義するための標準的なメカニズムです：

{
  「name」: 「delete_database」,
  「annotations」: {
    「title」: 「データベースの削除」,
    「readOnlyHint」: false,
    「destructiveHint」: true,
    『idempotentHint』: false,
    「openWorldHint」: false
  }
}

レイヤー 3: データレベルの分離

• 行レベルセキュリティ（Row-level security）
• データマスキング（Redaction）
• フィルタリング（Filtering）

SELECT * FROM orders WHERE tenant_id = current_tenant

8.3 OAuth 2.1 認証（リモート MCP サーバーの標準）

MCP 2025-03 バージョンでは、OAuth 2.1 + PKCE に基づく認証フレームワークが導入されました。これは、リモート MCP サーバーの必須標準です。

認証フロー：

1. クライアントがサーバーの認証要件を確認する
2. クライアントがユーザーを認証ページにリダイレクトする
3. ユーザーが認証を行う
4. サーバーがアクセス・トークンを返す
5. クライアントが以降のリクエストにトークンを添付する

リクエスト例：

POST /mcp
Authorization: Bearer eyJhbGciOiJSUzI1NiIs.. .
Content-Type: application/json

8.4 エンタープライズ級認証管理（EMA 拡張）

バージョン 2026 では EMA（Enterprise MCP Authorization）拡張が導入され、以下をサポートしています：

• 集中型認証管理
• 企業ポリシーの配布
• 統一ID認証の統合
• きめ細かな権限制御

8.5 セキュリティ実践チェックリスト

チェック項目	説明
リモートサーバーでは OAuth 2.1 を有効にする必要があります	不正アクセスを防止
Tool Annotations を使用してセキュリティ属性を注釈付け	クライアントのセキュリティ判断を支援
プロセスレベルのサンドボックス隔離	ツールの権限逸脱を防止
データレベルのテナント分離	テナント間でのデータ漏洩を防止
プロンプトインジェクション対策	入力検証 + 出力フィルタリング
ツール呼び出し監査ログ	追跡可能性

8.6 学術研究による発見（セキュリティの現状）

• 約 40.55% のリモート MCP サーバーに認証が一切ない
• 約 96.6% の OAuth サーバーに動的クライアント登録の欠陥が存在する
• 一般的な攻撃：Tool Poisoning、Shadowing、Rug Pull

---

基礎編は以上です。応用編（ソリューション比較、企業導入、エージェントアーキテクチャ、高度なシステム設計、エコシステムツールチェーン、プロトコルの進化、クイックリファレンス）については、「MCP企業活用の包括的知識ポイント－応用編」をご覧ください。