what-is-mcp
AI

MCPとは？はじめてのModel Context Protocol入門｜できること・仕組み・導入手順をわかりやすく解説

師田 賢人
22分で読める 0

目次

大規模言語モデル（LLM）が様々なアプリケーションの中核を担うようになり、その能力を最大限に引き出すための「ツール連携」が不可欠となっています。天気予報の取得、データベースへの問い合わせ、社内APIの実行など、LLMが外部の機能やデータソースと連携することで、その応用範囲は飛躍的に拡大します。

しかし、これまでのツール連携は、OpenAIのFunctions Callingや特定のフレームワーク（LangChain, LlamaIndexなど）に依存した「専用SDK方式」が主流でした。これは開発の迅速化に貢献する一方で、特定プラットフォームへのロックイン、異なるモデル間での互換性の欠如、そしてセキュリティ境界の曖昧さといった課題を生み出しています。

こうした背景から、LLMと外部ツール間のやり取りを標準化する動きとしてMCP (Model-Client Protocol) が提唱されました。MCPは、特定のモデルやベンダーに依存しない、オープンなプロトコルです。この記事では、LLMアプリケーション開発の次世代標準となりうるMCPの全体像を、その設計思想から具体的な実装、実運用上の注意点まで、網羅的に解説します。

MCPとは—背景と設計思想

MCPは、LLMアプリケーションにおける「クライアント（LLM側）」と「サーバー（ツール側）」の間のコミュニケーションを標準化するためのプロトコルです。その核心は、乱立する独自仕様のプラグインやSDKから脱却し、誰でも実装可能な共通の「お作法」を定めることにあります。

目的：LLM⇄外部ツール/データ間の標準I/Oと権限境界を定義

MCPの最大の目的は、LLMと外部ツール・データソース間の入出力（I/O）と権限の境界を明確に定義することです。

従来のツール連携では、LLM側のエージェントがツールを直接、あるいは密結合なライブラリ経由で実行することが多く、以下のような問題がありました。

  • セキュリティリスク: LLMが意図せず危険なコマンドを実行したり、アクセスすべきでないデータに触れたりするリスク。
  • 互換性の欠如: あるLLM向けに作ったツールは、別のLLMでは容易に再利用できない。
  • 監査の困難さ: 誰が、いつ、どのツールを、どんなパラメータで呼び出したのかを追跡するのが難しい。

MCPは、この問題を解決するために、LLM（クライアント）とツール（サーバー）をプロトコルレベルで分離します。これにより、両者の間に明確な境界線が引かれ、すべてのやり取りが構造化されたメッセージとして交換されるため、安全性、互換性、監査可能性が飛躍的に向上します。

基本概念：Client / Server / Tools / Resources / Prompts

MCPの世界は、いくつかのシンプルな構成要素で成り立っています。

  • Client（クライアント）: 通常、LLMを内包するエージェントやアプリケーションを指します。外部の機能を使いたいと考えたときに、MCPサーバーに対してリクエストを送信する役割を担います。
  • Server（サーバー）: 外部ツールやデータソースへのアクセスを提供するコンポーネントです。クライアントからのリクエストを受け取り、定義されたツールを実行したり、リソースへのアクセスを仲介したりします。
  • Tools（ツール）: サーバーが提供する具体的な「機能」です。例えば、「send_email」「get_weather」「query_database」といった動的なアクションがツールにあたります。各ツールは、その名前、説明、入力値の形式（スキーマ）が明確に定義されます。
  • Resources（リソース）: サーバーが提供する静的な「データ」です。ドキュメントファイル、設定ファイル、画像など、主に読み取り専用のデータソースを指します。リソースはURI（例: file://./README.md）で一意に識別されます。
  • Prompts（プロンプト）: クライアントが利用できるプロンプトのテンプレートです。サーバー側で定型文を定義しておくことで、クライアントは変数を埋め込むだけで一貫した品質のプロンプトを生成できます。これにより、プロンプトエンジニアリングの成果をサーバー側で管理・再利用しやすくなります。

これらの要素が連携し、LLMは「このツールを使いたい」「このリソースが読みたい」とMCPサーバーに依頼し、サーバーは権限の範囲内でそれを実行・提供するという、秩序だったエコシステムが形成されます。

位置づけ：プラグイン方式や専用SDK依存の統合からプロトコル標準へ

MCPは、これまでのLLMツール連携のあり方を根本から変える可能性を秘めています。

従来方式（専用SDK/プラグイン）MCP (プロトコル標準)
結合度密結合（コードレベルでの依存）疎結合（プロトコルレベルでの通信）
互換性低い（特定のLLMやフレームワークに依存）高い（プロトコルに準拠すれば誰でも実装可能）
セキュリティ曖昧（アプリケーションの権限に依存）明確（サーバー側で厳格な権限管理が可能）
監査性困難（ログ形式がバラバラ）容易（標準化されたメッセージI/Oを記録）
開発言語制限あり（SDKが提供される言語のみ）自由（好きな言語でClient/Serverを実装可能）

Google スプレッドシートにエクスポート

この転換は、Webの世界でHTTPが特定のブラウザやサーバー技術に依存しない共通プロトコルとして普及した歴史と似ています。MCPが目指すのは、LLMアプリケーションにおけるHTTPのような存在、すなわち特定のテクノロジーに縛られない、オープンで普遍的なツール連携の標準となることです。

仕様の要点—プロトコルの話だけ最短で

MCPの仕様は、複雑さを排し、実装しやすさと堅牢性を両立させるように設計されています。ここでは、その技術的な要点を簡潔に解説します。

トランスポート：stdio / WebSocket（JSON-RPC互換メッセージング）

MCPは特定の通信技術に縛られませんが、主なトランスポートとして以下の2つが想定されています。

  1. stdio (標準入出力): 最もシンプルな方法です。クライアントはMCPサーバーをサブプロセスとして起動し、その標準入力（stdin）にリクエストを書き込み、標準出力（stdout）からレスポンスを読み取ります。ローカル環境での開発や、シンプルな構成で済む場合に非常に便利です。
  2. WebSocket: ネットワーク越しの通信にはWebSocketが利用されます。これにより、クライアントとサーバーが異なるマシン上にあっても、双方向かつリアルタイムな通信が可能になります。

メッセージの形式は、広く使われているJSON-RPC 2.0に準拠しています。これにより、既存のライブラリやツールを流用しやすく、開発者が学習すべき新しい概念を最小限に抑えています。

セッション開始：initialize → capability交換

クライアントとサーバー間の通信は、必ずinitializeメッセージから始まります。

  1. クライアント → サーバー: initialize クライアントは、まず自身が持つ能力（capability）などの情報を含むinitializeリクエストをサーバーに送信します。
  2. サーバー → クライアント: initialize応答 サーバーはリクエストを受け取ると、自身が提供するツール、リソース、プロンプトの一覧など、サーバー側の能力を返します。

この最初のやり取り（ハンドシェイク）によって、クライアントとサーバーは互いに何ができるのかを理解し、その後の通信の前提を確立します。

主要メッセージ

セッション確立後、クライアントは主に以下のメッセージを使ってサーバーと対話します。

  • tools:
    • tools/list: 利用可能なツールの一覧とその定義（説明、入力スキーマ）を取得します。
    • tools/call: 特定のツールを、指定したパラメータで実行するよう依頼します。{"toolName": "echo", "params": {"text": "hello"}} のような形式です。
    • tools/result: サーバーからのツール実行結果です。成功した場合はその出力が、失敗した場合はエラー情報が含まれます。
  • resources:
    • resources/list: 利用可能なリソースの一覧を取得します。
    • resources/get: 特定のリソースの内容を取得します。大きなファイルの場合、ストリーミングで段階的にデータを受け取ることも可能です。
  • prompts:
    • prompts/list: 利用可能なプロンプトテンプレートの一覧を取得します。
    • prompts/execute: 特定のテンプレートに、変数を埋め込んで最終的なプロンプト文字列を生成するよう依頼します。

logging/telemetry（任意拡張）

MCP自体はコアな機能に絞られていますが、loggingやtelemetryといったメッセージを任意で拡張することも想定されています。これにより、サーバー側で発生したログや性能メトリクスを、標準化された形式でクライアントに通知する仕組みを構築できます。

セキュリティ前提：最小権限・明示的スコープ・監査可能なI/O

MCPの設計は、セキュリティを最優先に考えています。

  • 最小権限の原則: サーバーは、クライアントに必要最小限のツールとリソースのみを公開すべきです。initializeの時点で、そのクライアントに許可された機能だけを通知します。
  • 明示的なスコープ: 「どのクライアントが、どのツールを使えるか」という権限設定（スコープ）を、サーバー側で厳格に管理します。
  • 監査可能なI/O: 全てのやり取りはJSON-RPCメッセージとして構造化されているため、そのままログとして保存すれば、完全な監査証跡となります。これにより、インシデント発生時の追跡やコンプライアンス要件への対応が容易になります。

最小実装ガイド—5分で動くMCPサーバ

理論だけでなく、実際にMCPサーバーがどれほど簡単に構築できるかを見てみましょう。ここでは、公式に提供されているライブラリmcp-kitを使ったNode.js (TypeScript)とPythonの例を紹介します。

Node（TypeScript）例：ツールechoとリソース読み出し

この例では、受け取ったテキストをそのまま返すechoツールと、カレントディレクトリのREADME.mdを公開するリソースを持つサーバーを起動します。

TypeScript

// mcp-server.ts（概略）
import { createServer, Tool, Resource } from "mcp-kit";

// 1. ツールの定義
const echoTool: Tool = {
  name: "echo",
  description: "Echo back the input string.",
  // 入力値の形式をJSON Schemaで厳密に定義
  inputSchema: {
    type: "object",
    properties: {
      text: { type: "string", description: "The text to echo back." },
    },
    required: ["text"],
  },
  // ツールの本体処理
  handler: async ({ text }) => {
    return { content: `You said: ${text}` };
  },
};

// 2. リソースの定義
const readmeResource: Resource = {
  uri: "file://./README.md", // ファイルパスを指定
  mimeType: "text/markdown",
};

// 3. サーバーの作成と起動
createServer({
  tools: [echoTool],
  resources: [readmeResource],
}).listenStdio(); // 標準入出力で待機

console.error("MCP server started on stdio");

Python例（概略）

同じ機能をPythonで実装すると以下のようになります。デコレータを使うことで、より直感的に記述できます。

Python

# mcp_server.py（概略）
from mcpkit import Server, tool, resource

# サーバーインスタンスを作成
srv = Server()

# 1. ツールの定義（デコレータを使用）
@tool(name="echo", description="Echo back the input string.")
def echo(text: str):
    """
    Args:
        text (str): The text to echo back.
    """
    return {"content": f"You said: {text}"}

# サーバーにツールを登録
srv.add_tool(echo)

# 2. リソースの登録
readme = resource(uri="file://./README.md", mime_type="text/markdown")
srv.add_resource(readme)

# 3. サーバーの起動
if __name__ == "__main__":
    srv.listen_stdio() # 標準入出力で待機

クライアント接続（擬似コード）

このサーバーに接続するクライアントは、以下のような流れでツールを呼び出します。

TypeScript

// mcp-client.ts（擬似コード）
import { StdioClient } from "mcp-kit";

async function main() {
  // サーバープロセスを起動し、クライアントを初期化
  const client = new StdioClient({ cmd: "node", args: ["mcp-server.js"] });

  // 1. セッション開始とcapability交換
  await client.initialize();

  // 2. 'echo'ツールを呼び出し
  const result = await client.callTool("echo", { text: "Hello MCP!" });

  // 3. 結果を表示
  console.log(result.content); // "You said: Hello MCP!" と出力される

  await client.exit();
}

main();

実装ポイント

  • 入力バリデーションをスキーマで固定: inputSchemaを定義するだけで、サーバーが自動で入力値の検証を行います。これにより、ツール本体のコードは正常なデータだけを扱えばよくなり、堅牢性が増します。
  • ツールは副作用を明示: ツールの説明（description）には、そのツールが何をするのか（例：「メールを送信する」「データベースを更新する」）を正確に記述することが重要です。LLMは、この説明を読んでどのツールを使うべきかを判断します。
  • I/Oはログ保存: クライアントからのリクエストとサーバーからのレスポンスは、すべてログに記録することを強く推奨します。これが後の監査やデバッグで非常に役立ちます。

実運用設計—セキュリティ・デプロイ・監視

プロトタイプを卒業し、MCPサーバーを本番環境で運用するには、いくつかの重要な設計上の考慮点があります。

アイソレーション：サーバはDocker等で分離、シークレット管理

MCPサーバーは外部システムへのゲートウェイとなるため、厳重な隔離が不可欠です。

  • コンテナ化: サーバープロセスはDockerなどのコンテナ技術を用いてホスト環境から隔離します。ファイルシステムやネットワークへのアクセスも、コンテナの設定で必要最小限に絞ります。
  • シークレット管理: APIキーやデータベースのパスワードなどの機密情報は、コードや環境変数に直接埋め込むのではなく、HashiCorp VaultやAWS Secrets Managerのような専用のシークレット管理ツールを使って動的に注入します。これにより、機密情報漏洩のリスクを大幅に低減できます。

権限管理：ツール単位のスコープ＋レート制限

全てのクライアントに全てのツールを使わせるのは危険です。

  • ツール単位のスコープ: クライアントごとに、アクセス可能なツールを細かく制御します。例えば、「CRM参照クライアント」にはread_customerツールのみを許可し、update_customerツールは許可しない、といった設定をサーバー側で行います。
  • レート制限: 特定のクライアントやツールが高頻度で呼び出され、システム全体に負荷をかけることを防ぐため、APIゲートウェイやサーバー自身にレート制限（例：1分あたり100回まで）を導入します。

監査ログ：request_idでツール呼出し→外部API→応答を相関付け

問題発生時に迅速な原因究明を行うためには、詳細な監査ログが不可欠です。

  • 相関ID (Correlation ID): クライアントからの最初のリクエストにユニークなrequest_idを付与し、そのIDをMCPサーバー内の処理、さらにはサーバーが呼び出す外部APIへのリクエストにまで引き継ぎます。
  • 構造化ロギング: ログはJSONなどの構造化された形式で出力し、request_id, timestamp, client_id, tool_name, params, resultといった情報を含めます。これにより、特定の処理フローを横断的に追跡・分析することが容易になります。

可観測性：メトリクス、構成例：OpenTelemetry導入

システムの健全性を常に把握するために、可観測性（Observability）の確保が重要です。

  • 主要メトリクス: 最低限、以下のメトリクスを収集・監視します。
    • リクエスト数: ツールごとの呼び出し回数。
    • 成功率/エラー率: ツールごとの成功・失敗の割合。
    • レイテンシ: リクエストを受けてから応答を返すまでの時間（p50, p90, p99など）。
    • タイムアウト数: タイムアウトしたリクエストの数。
  • OpenTelemetryの導入: これらのメトリクス、ログ、そして前述のトレース（request_idによる追跡）を統合的に扱うための標準仕様としてOpenTelemetryの導入を推奨します。これにより、特定のベンダーにロックインされることなく、DatadogやPrometheus/Grafanaといった様々な監視ツールにデータを送信できます。

デプロイ：小規模は単一MCPサーバ、拡張はサービスごとにServer分割＋リバプロ

  • 小規模構成: はじめは、関連するツール群をまとめた単一のMCPサーバーをデプロイするのがシンプルで良いでしょう。
  • 大規模構成: アプリケーションが成長し、ツールの数や種類が増えてきたら、サービスごとにMCPサーバーを分割するマイクロサービス的なアプローチが有効です。例えば、「CRM連携サーバー」「決済サーバー」「情報検索サーバー」のように分割し、その前にリバースプロキシ（APIゲートウェイ）を配置して、リクエストを適切なサーバーに振り分けます。

失敗設計：ツールは再試行ポリシーと冪等性、外部APIはサーキットブレーカ

ネットワークは不安定なものです。失敗を前提とした設計を組み込みましょう。

  • 再試行ポリシー (Retry Policy): ツールが呼び出す外部APIが一時的なエラーで失敗した場合に備え、指数バックオフ（Exponential Backoff）などの戦略で自動的に再試行するロジックをツール内に実装します。
  • 冪等性 (Idempotency): 再試行しても安全なように、ツールは可能な限り冪等に設計します。冪等とは、「同じ操作を何回繰り返しても、結果が同じになる」性質のことです。例えば、「決済を実行する」ツールにユニークな取引IDを必須とすることで、重複決済を防ぎます。
  • サーキットブレーカー (Circuit Breaker): 外部APIで障害が継続している場合、無駄なリクエストを送り続けないように、一時的にそのAPIへのリクエストを遮断する「サーキットブレーカー」パターンを導入します。これにより、連鎖的な障害を防ぎます。

導入パターン／アンチパターン—他方式との使い分け

MCPは銀の弾丸ではありません。その特性を理解し、適材適所で活用することが重要です。

向いているケース

  • 多数ツールの横断実行: 複数の異なるドメインのツール（例：営業、マーケティング、開発）を、単一のLLMエージェントから安全に呼び出したい場合。プロトコルが標準化されているため、ツールごとの個別実装の手間が省けます。
  • 透明な権限境界と監査が必須の業務: 金融、医療、法務など、セキュリティとコンプライアンス要件が厳しいエンタープライズ領域。誰が何をしたかを正確に記録し、権限を厳密に管理できるMCPのアーキテクチャは非常に有効です。
  • 多言語・多チームでの開発: Pythonチームが作ったツールを、TypeScriptで書かれたLLMアプリから利用する、といったシナリオ。プロトコルさえ守れば、互いの実装言語を気にする必要がありません。

RAG連携：ドキュメント取得をresourcesで標準化

RAG (Retrieval-Augmented Generation) は、LLMが外部ドキュメントを参照して回答を生成する人気の技術です。MCPはRAGと非常に相性が良いです。

  • resourcesの活用: 社内規定、製品マニュアル、過去の議事録といったドキュメント群をMCPサーバーのresourcesとして公開します。
  • 役割分担: MCPサーバーは「安全なドキュメント取得」に専念します。LLMクライアントはresources/getで取得したドキュメントを、既存のベクトルデータベースや検索エンジン（Elasticsearch, Pineconeなど）に投入して埋め込みや検索を行います。このように、データアクセス層の標準化としてMCPを活用することで、RAGパイプライン全体の見通しが良くなります。

既存Bot/プラグイン：専用SDK依存を避け、プロトコル準拠で拡張性確保

すでに特定のチャットプラットフォーム（Slack, Teamsなど）向けにBotやプラグインを開発している場合、そのコアロジックをMCPサーバーとして切り出すことを検討できます。

これにより、コア機能はプラットフォーム非依存となり、将来的に別のLLMやフロントエンドからも再利用できるようになります。専用SDKへの依存を排除し、システムの疎結合性と将来の拡張性を確保するための有効なアーキテクチャパターンです。

アンチパターン：避けるべき使い方

  • 巨大モノリスの“なんでもサーバ”: 関連性のないツールを何十個も詰め込んだ、単一の巨大なMCPサーバーは避けるべきです。メンテナンス性が低下し、障害時の影響範囲も大きくなります。前述の通り、ドメインごとにサーバーを分割しましょう。
  • 無制限ツール: OSコマンドを直接実行できるような、強力すぎる、あるいはスコープが広すぎるツール（例：execute_shell_command）を安易に公開してはいけません。これはLLMにサーバーを乗っ取る権限を与えるに等しい行為です。
  • ノーログ運用: 「動いているから大丈夫」と、監査ログやメトリクスを一切取得しない運用は非常に危険です。問題が発生した際に原因究明が不可能になり、セキュリティインシデントを見逃す原因にもなります。

まとめ

MCP (Model-Client Protocol) は、LLMと外部ツール連携の未来を形作る、重要でオープンな標準です。特定の企業やフレームワークへの依存から脱却し、プロトコルに基づいた疎結合なアーキテクチャへと移行することで、私たちはより安全で、相互運用性が高く、監査可能なLLMアプリケーションを構築できます。

その核心は、クライアント（LLM）とサーバー（ツール）の間に明確な境界を引き、標準化されたメッセージで対話させるというシンプルなアイデアにあります。

本記事で解説したように、MCPは単なる理論ではなく、すぐに試せるライブラリが提供されており、本番運用を見据えたセキュリティや監視のベストプラクティスも確立されつつあります。LLMを活用した次世代のアプリケーション開発に携わるすべてのエンジニアにとって、MCPは今、学ぶべき最も重要な技術の一つと言えるでしょう。

#AI#MCP

ビジネスの成長をサポートします

Harmonic Societyは、最新のテクノロジーとクリエイティブな発想で、
お客様のビジネス課題を解決します。

豊富な実績と経験
最新技術への対応
親身なサポート体制
無料相談を申し込む サービスを見る

師田 賢人

Harmonic Society株式会社 代表取締役。一橋大学（商学部）卒業後、Accenture Japanに入社。ITコンサルタントとして働いた後、Webエンジニアを経て2016年に独立。ブロックチェーン技術を専門に200名以上の専門家に取材をし記事を執筆する。2023年にHarmonic Society株式会社を設立後、AI駆動開発によるWebサイト・アプリ制作を行っている。

関連記事

コメントを残す