専門家一覧
MCP プロトコルの基礎

個別API連携はもう古い。Claude等AIエージェントの知能を拡張するMCPプロトコル実装とJSON-RPC仕様の全貌

この記事は急速に進化する技術について解説しています。最新情報は公式ドキュメントをご確認ください。

約14分で読めます
文字サイズ:
個別API連携はもう古い。Claude等AIエージェントの知能を拡張するMCPプロトコル実装とJSON-RPC仕様の全貌
目次

この記事の要点

  • AIと社内データを安全かつ効率的に連携させるMCPの仕組み
  • 個別API開発の課題を解決し、開発工数と保守コストを削減
  • AIガバナンスを強化し、シャドーAIや情報漏洩リスクを低減

AIエージェントに社内システムを連携させるために、また新しいAPIラッパーを書いていませんか？

AIモデルが外部データにアクセスする際、ツールごとに個別のAPI連携を作り込むアプローチは、もはやスケールしません。データソースが増えるたびにエンドポイントを設計し、認証フローを実装し、AIモデルが理解しやすい形にプロンプトを調整する。この「N対N」の密結合なアーキテクチャは、開発リソースを枯渇させるだけでなく、セキュリティ上の脆弱性を生み出す温床となります。

ここで注目すべき技術が、AIモデルとデータソースを分離するオープンな標準規格「MCP（Model Context Protocol）」です。

Anthropic社の公式ドキュメントにも記載されている通り、Claude 3ファミリー（Opus、Sonnet、Haiku）をはじめとする最新のAIモデルは、高度なツール利用（Tool use）機能を備えています。MCPは、このツール利用の仕組みを標準化し、AIエージェント（クライアント）とデータソース（サーバー）間の通信を統一的なプロトコルで結びます。

本記事では、単なるツールの使い方にとどまらず、プロトコルのメッセージ仕様（JSON-RPC 2.0）やトランスポート層の定義まで踏み込み、自社独自のMCPサーバーを一から設計・実装するための正攻法を解説します。

MCP（Model Context Protocol）のアーキテクチャ概要と導入メリット

多くの開発現場では、既存のREST APIをそのままAIエージェントに読み込ませようとするケースが珍しくありません。しかし、人間向け・システム向けに設計されたAPIをAIモデルに直接解釈させるのは非効率です。MCPは、この課題を根本から解決するアーキテクチャを持っています。

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

MCPのアーキテクチャは、以下の3つの主要コンポーネントで構成されています。

  1. Host（ホスト）: AIモデルを実行し、ユーザーとのインターフェースを提供するアプリケーション（例：Claude Desktopアプリケーション）。
  2. Client（クライアント）: ホストの内部で動作し、MCPサーバーとの通信を担うモジュール。AIモデルの要求をプロトコルメッセージに変換します。
  3. Server（サーバー）: 実際のデータソースやツール側で動作し、クライアントからの要求を処理して結果を返すバックエンド。

この構造の最大のポイントは、AIモデル（Host）とデータソース（Server）が直接通信しない点です。Clientが仲介役となり、標準化されたプロトコルで通信を行うため、サーバー側は「どのAIモデルから呼び出されるか」を意識する必要がありません。

なぜ従来の個別API連携よりMCPが優れているのか

既存のWeb APIをAIエージェントに統合する際、開発者は「エンドポイントの仕様」「認証方式」「ページネーション」など、ツール固有の仕様に合わせて連携コードを書く必要があります。10個のツールがあれば10通りの実装が求められます。

一方、MCPを採用すると、サーバー側はMCPの仕様に従ってリソースやツールを公開するだけで済みます。クライアント側（AIエージェント）は、MCPという単一のプロトコルを理解できれば、世界中のあらゆるMCPサーバーと即座に通信可能になります。

これは、USB規格が登場したことで、PCがあらゆる周辺機器とドライバなしで接続できるようになった歴史と似ています。エコシステム共通のインターフェースを採用することで、開発コストは劇的に削減され、保守性も飛躍的に向上します。

認証方式と接続確立：トランスポート層の仕様

MCPサーバーがクライアントと通信するためには、まずトランスポート層での接続を確立する必要があります。MCPでは主に2つのトランスポート方式が定義されており、ユースケースに応じて適切なものを選択することが実装の要となります。

stdio（標準入出力）によるローカル接続

最も基本となるのが、stdio（標準入出力）を利用した通信です。この方式では、クライアントがMCPサーバーのプロセスをサブプロセスとして起動し、標準入力（stdin）と標準出力（stdout）を通じてJSON-RPCメッセージをやり取りします。

  • メリット: ネットワークポートを開く必要がなく、ローカル環境で極めて安全かつシンプルに動作します。Claude Desktopなどのローカルアプリケーションから社内ツールを呼び出す際に最適です。
  • 注意点: サーバー側でログを出力する際、誤って標準出力（stdout）に書き込んでしまうと、JSON-RPCのパケットと混ざり通信エラーを引き起こします。ログ出力は必ず標準エラー出力（stderr）またはファイルに向ける必要があります。

ローカル接続時の認証情報は、クライアントがサーバープロセスを起動する際の環境変数として渡すのがベストプラクティスです。これにより、認証情報のハードコードを防ぐことができます。

SSE（Server-Sent Events）によるリモート接続

社内の共有サーバーやクラウド上にMCPサーバーを配置し、複数のクライアントからアクセスさせる場合は、HTTPベースのリモート接続を使用します。MCPでは、サーバーからクライアントへの非同期メッセージ送信を実現するために、SSE（Server-Sent Events）を利用します。

  1. 接続確立: クライアントがサーバーのSSEエンドポイントに接続し、イベントストリームを開きます。
  2. メッセージ送信: クライアントからサーバーへのリクエストは、通常のHTTP POSTリクエストを使用して送信されます。

リモート接続を実装する際は、ステート管理が複雑になります。SSEの接続が切断された場合の再接続ロジックや、接続ごとのセッション管理（セッションIDの発行と紐付け）を正確に設計しなければなりません。また、HTTPヘッダーを利用したBearerトークン認証など、標準的なWebセキュリティ対策も必須となります。

MCPの3大プリミティブ：Resources, Prompts, Toolsの定義

認証方式と接続確立：トランスポート層の仕様 - Section Image

MCPサーバーは、AIモデルに対して「何ができるか」を提示するために、3つの主要なプリミティブ（基本要素）を提供します。これらの仕様を正確に理解することが、効果的な統合の第一歩です。

Resources：読み取り専用データの公開

Resourcesは、AIモデルに読み取らせたい静的なデータやファイル、APIレスポンスを公開するための機能です。各リソースは一意のURI（例：file:///logs/app.log や postgres://database/schema）で識別されます。

サーバー側は、クライアントからの resources/list リクエストに対して、利用可能なリソースのリスト（名前、URI、MIMEタイプ）を返します。AIモデルはこれを見て、必要なデータを resources/read リクエストで取得します。データベースのスキーマ情報や、社内規定のドキュメントなどをAIにコンテキストとして与える際に非常に有効です。

Prompts：テンプレート化された指示文の提供

Promptsは、ユーザーがAIモデルに指示を出す際のテンプレートを提供する機能です。例えば、「コードレビューを依頼する」「インシデントレポートを作成する」といった定型的なタスクにおいて、サーバー側から最適なプロンプトのひな形を提供できます。

プロンプトには引数（Arguments）を定義することができ、動的に値を埋め込むことが可能です。これにより、プロンプトエンジニアリングのベストプラクティスをサーバー側でカプセル化し、ユーザーに意識させることなく高品質なAI出力を引き出すことができます。

Tools：モデルによる外部アクションの実行

Toolsは、AIモデルが外部システムに対してアクション（状態の変更や複雑な計算）を起こすための機能です。Anthropic APIのTool use機能と直接的に結びつく重要な概念です。

サーバーは tools/list リクエストに対し、ツールの名前、説明、そして引数のJSON Schemaを返します。AIモデルはこのSchemaを解釈し、適切な引数を生成して tools/call リクエストを発行します。

例えば、「Jiraにチケットを作成する」ツールを定義する場合、引数として title（文字列）と priority（列挙型）をSchemaで厳密に定義します。これにより、AIモデルが不正なフォーマットでリクエストを投げてくるリスクを最小限に抑えることができます。

メッセージ交換仕様：JSON-RPC 2.0に基づく通信プロトコル

MCPの低レイヤー通信は、業界標準である「JSON-RPC 2.0」に基づいています。REST APIとは異なり、単一のエンドポイント（またはストリーム）上で、メソッド名とパラメータを含むJSONペイロードを交換することでRPC（リモートプロシージャコール）を実現します。

リクエスト・レスポンスの基本構造

クライアントからサーバーへのリクエストは、以下のような構造を持ちます。

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "create_ticket",
    "arguments": {
      "title": "DB接続エラーの調査",
      "priority": "high"
    }
  }
}

これに対するサーバーからの正常なレスポンスは、リクエストと同じ id を持ち、result フィールドを含みます。

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "チケットを作成しました。ID: TICKET-1234"
      }
    ]
  }
}

通知（Notifications）とエラーハンドリング

JSON-RPCでは、レスポンスを必要としない「通知（Notifications）」もサポートされています。通知の場合は id フィールドを含めずに送信されます。MCPでは、プログレスの報告やリソースの更新通知などに利用されます。

エラーが発生した場合、サーバーは result の代わりに error オブジェクトを返します。標準的なエラーコード（例：-32601 メソッドが見つからない、-32602 無効なパラメータ）に加え、アプリケーション固有のエラーメッセージを含めることで、クライアント側のデバッグを容易にします。実装者は、予期せぬ例外が発生した際にも必ず有効なJSON-RPCエラーレスポンスを返すようハンドリングを徹底する必要があります。

【実践】TypeScript/PythonによるMCPサーバーの構築ステップ

メッセージ交換仕様：JSON-RPC 2.0に基づく通信プロトコル - Section Image

理論を理解したところで、実際にMCPサーバーを構築する手順を見ていきましょう。Anthropicは公式のSDKを提供しており、これを利用することでプロトコルの低レイヤーな処理を隠蔽し、ビジネスロジックに集中できます。

公式SDKを利用したボイラープレートの作成

TypeScript環境の場合、@modelcontextprotocol/sdk パッケージを使用します。以下は、最小構成のMCPサーバーを立ち上げるためのボイラープレートです。

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

// サーバーの初期化
const server = new Server({
  name: "my-internal-tools",
  version: "1.0.0"
}, {
  capabilities: {
    tools: {}
  }
});

// トランスポートの接続（stdioを使用）
const transport = new StdioServerTransport();
await server.connect(transport);
console.error("MCP Server is running on stdio");

ここで重要なのは、ログ出力を console.error で行っている点です。前述の通り、stdio通信では console.log（標準出力）を使うと通信が破壊されるため、必ず標準エラー出力を使用します。

カスタムリソース・ツールの登録手順

サーバーを初期化したら、ツールを登録するためのハンドラーを実装します。SDKの setRequestHandler メソッドを使用して、tools/list と tools/call に対する処理を定義します。

import { ListToolsRequestSchema, CallToolRequestSchema } from "@modelcontextprotocol/sdk/types.js";

// ツールの定義を返す
server.setRequestHandler(ListToolsRequestSchema, async () => {
  return {
    tools: [{
      name: "get_customer_data",
      description: "顧客IDから顧客の詳細情報を取得します",
      inputSchema: {
        type: "object",
        properties: {
          customerId: { type: "string" }
        },
        required: ["customerId"]
      }
    }]
  };
});

// ツールの実行処理
server.setRequestHandler(CallToolRequestSchema, async (request) => {
  if (request.params.name === "get_customer_data") {
    const { customerId } = request.params.arguments;
    // 実際のデータ取得ロジック（DBクエリなど）
    const data = await fetchCustomerFromDB(customerId);
    
    return {
      content: [{ type: "text", text: JSON.stringify(data) }]
    };
  }
  throw new Error("Tool not found");
});

このように、JSON Schemaを用いて引数の型を明示することで、AIモデルは正確なリクエストを生成できるようになります。

セキュリティとガバナンス：社内リソースを保護する設計指針

セキュリティとガバナンス：社内リソースを保護する設計指針 - Section Image 3

AIエージェントに社内データを操作させる際、最も懸念されるのがセキュリティです。MCPサーバーをエンタープライズ環境に導入する場合、単にAPIを開放するのではなく、厳密なガバナンスモデルを設計する必要があります。

実行権限の制御（ユーザー承認フロー）

「Tools」を用いて状態を変更する操作（データベースの更新、メールの送信、インフラの変更など）をAIに許可する場合、完全な自動実行は非常に危険です。AIモデルのハルシネーション（幻覚）によって、意図しない破壊的な操作が行われる可能性があるからです。

対策として、ツール実行時に「Human-in-the-loop（ユーザー承認）」のフローを組み込むことが不可欠です。MCPプロトコル自体には承認フローの概念は組み込まれていませんが、ホストアプリケーション（Claude Desktopなど）側で、ツール呼び出しのリクエスト（tools/call）が発生した際にUI上でユーザーにプロンプトを表示し、承認された場合のみサーバーにリクエストを転送する仕組みを構築する必要があります。サーバー側でも、破壊的な操作を行うツールの利用を、特定の認証トークンを持つクライアントに限定するなどの権限分離（PoLP: 最小権限の原則）を適用します。

入力バリデーションとプロンプトインジェクション対策

AIモデルから渡される引数（Arguments）は、外部からの信頼できない入力として扱うのが鉄則です。JSON Schemaで型を定義していても、SQLインジェクションやOSコマンドインジェクションのリスクは残ります。

MCPサーバー側で受け取ったパラメータは、必ず厳格なサニタイズとバリデーションを行ってください。また、悪意のあるユーザーがAIモデルを騙して不正なツール実行を引き起こす「プロンプトインジェクション」のリスクを軽減するため、ツールがアクセスできるデータ範囲をサンドボックス化し、影響範囲を最小限に留める設計が求められます。

実運用に向けたトラブルシューティングとレート制限

開発環境で動いたMCPサーバーも、実運用環境（本番環境）では様々な課題に直面します。安定した稼働を維持するための戦略を解説します。

デバッグツールの活用（MCP Inspector）

MCPサーバーの開発中、AIモデルを介してテストを行うと、エラーの原因がプロンプトにあるのか、サーバーの実装にあるのか切り分けが困難になります。ここで活躍するのが、Anthropicが提供する公式のデバッグツール「MCP Inspector」です。

MCP Inspectorを使用すると、ブラウザベースのUIからMCPサーバーに直接接続し、リソースのリスト取得やツールの手動実行を試すことができます。JSON-RPCの生のメッセージログも確認できるため、パケット構造のミスやフォーマットエラーを迅速に特定することが可能です。

接続タイムアウトとリトライ戦略

リモート接続（SSE）を利用する場合や、バックエンドの処理に時間がかかるツールを実装する場合、タイムアウトの設計が重要になります。AIモデルは一定時間レスポンスがないと処理をタイムアウトさせるため、重い処理は非同期化し、MCPの通知（Notifications）機能を使って進捗を返すなどの工夫が必要です。

また、AIモデルが短時間に大量のツール呼び出しを行うケースを想定し、MCPサーバー側で適切なクォータ制限（レートリミット）を実装してください。これにより、社内APIやデータベースへの過剰な負荷（DDoS状態）を防ぐことができます。

まとめ

MCP（Model Context Protocol）は、AIエージェントと社内ツールを連携させるための強力な標準規格です。従来の個別API連携の限界を打破し、JSON-RPC 2.0に基づく統一されたインターフェースを提供することで、拡張性と保守性の高いAI統合を実現します。

本記事で解説したトランスポート層の設計、3大プリミティブ（Resources, Prompts, Tools）の仕様、そしてセキュリティとガバナンスの指針を基に、自社独自のMCPサーバー構築に挑戦してみてください。AIの知能と社内の独自データが安全に結びつくことで、業務効率化の次元は確実に次のレベルへと進むはずです。

より高度な実装や、最新のプロトコル仕様については、公式ドキュメントを定期的に確認し、継続的な学習を進めることをおすすめします。

参考リンク

個別API連携はもう古い。Claude等AIエージェントの知能を拡張するMCPプロトコル実装とJSON-RPC仕様の全貌 - Conclusion Image

参考文献

  1. https://dxmagazine.jp/news/2616uk54/
  2. https://ai.zenken.co.jp/post/claude-beginner-guide/
  3. https://app-liv.jp/articles/155944/
  4. https://onetech.jp/blog/what-is-claude-ai-25282
  5. https://uravation.com/media/claude-code-guide/
  6. https://note.com/kazu_t/n/nef4729e12306
  7. https://japan.zdnet.com/article/35247263/
  8. https://www.sbbit.jp/article/cont1/185346
  9. https://www.youtube.com/watch?v=zOtDiXqUkiI
  10. https://www.eigent.ai/ja/blog/claude-live-artifacts-guide

コメント

コメントは1週間で消えます
0 / 150
コメントを読み込み中...