Model Context Protocol（MCP）は、AIモデルが外部システムやデータソースに安全かつ標準化された方法でアクセスするためのオープンプロトコルです。 これにより、AIアプリケーションは、Gmailでの文章作成やSlackでのメッセージ送信など、AI単体ではできない外部サービスの機能を活用できるようになります。 MCPは、AIアプリケーションに拡張機能を提供し、開発者が連携機能を個別に開発する労力を削減するメリットがあります。
Model Context Protocol（MCP）の作り方
1. 概要
2. MCPのアーキテクチャ
MCPのアーキテクチャは主に以下の3つのコンポーネントで構成されます。
2.1. MCPサーバー
AIモデルが利用できるツールやリソースを提供し、機能を構造化されたリクエストを通じて公開します。
2.1.1. Model Context Protocol (MCP) サーバーの作製方法
2.1.2. 1. はじめに
本ドキュメントは、Model Context Protocol (MCP) に準拠したサーバーの作製方法について解説します。MCPサーバーは、機械学習モデルの管理、特定のコンテキストに応じたモデルの提供、およびモデルの状態管理を目的とします。
2.1.3. 2. Model Context Protocol (MCP) とは
2.1.3.1. 2.1. MCPの概要と目的
MCPは、モデルのバージョン、関連するコンテキスト情報、およびモデルのライフサイクルを管理するためのプロトコルです。複数のサービスやアプリケーションが共通のモデルリソースを効率的かつ整合性の取れた方法で利用することを可能にします。
2.1.3.2. 2.2. 主要な概念
- モデル (Model): 機械学習モデルのバイナリデータとそのメタデータ（バージョン、種類、訓練データなど）。
- コンテキスト (Context): モデルが適用される特定の状況や環境を定義する情報（ユーザーID、セッション情報、デバイス情報、ビジネスロジック固有のパラメータなど）。
- プロトコル (Protocol): クライアントとサーバー間でモデルやコンテキスト情報をやり取りするための通信規約とデータフォーマット。
2.1.4. 3. アーキテクチャ概要
MCPサーバーは、以下の主要コンポーネントで構成されます。
2.1.4.1. 3.1. コンポーネント
- APIゲートウェイ: クライアントからのリクエストを受け付け、内部サービスにルーティングします。
- コンテキスト管理サービス: 各リクエストのコンテキスト情報を処理・検証し、モデル選択の基準を提供します。
- モデルリポジトリサービス: 登録されたモデルの保存、取得、バージョン管理を行います。
- モデルロードモジュール: 必要に応じてモデルをメモリにロードし、利用可能な状態にします。
- データストア: モデルデータ、メタデータ、コンテキスト情報を永続的に保存します（例: データベース、オブジェクトストレージ）。
2.1.4.2. 3.2. 技術スタックの検討
- プログラミング言語: Python, Go, Javaなど
- フレームワーク: Flask, FastAPI, Gin, Spring Bootなど
- 通信プロトコル: RESTful API, gRPCなど
- データベース: PostgreSQL, MongoDB, Redisなど
- モデルストレージ: S3, GCS, Azure Blob Storageなど
2.1.5. 4. 開発環境の準備
2.1.5.1. 4.1. 前提条件
- 選択したプログラミング言語の基本的な知識
- ネットワークプロトコル (HTTP/gRPC) の基本的な理解
2.1.5.2. 4.2. 必要なツールのインストール
- 選択した言語のSDK/ランタイム
- パッケージマネージャー (pip, go mod, npm, Mavenなど)
- コンテナ化ツール (Dockerなど)
- APIテストツール (Postman, curlなど)
2.1.5.3. 4.3. プロジェクトの初期設定
- プロジェクトディレクトリの作成
- 仮想環境の構築と依存関係のインストール
- バージョン管理システム (Git) のセットアップ
2.1.6. 5. MCPサーバーの実装
2.1.6.1. 5.1. データモデルの設計
- モデルメタデータスキーマ: モデルID, バージョン, 名前, 種類, パス, ステータスなど。
- コンテキストスキーマ: コンテキストID, ユーザーID, セッションID, 地域, デバイスタイプ, その他のカスタム属性。
- 関連付けスキーマ: どのコンテキストがどのモデルバージョンと関連付けられるか。
2.1.6.2. 5.2. APIエンドポイントの設計
MCPプロトコルに基づき、以下の主要なAPIエンドポイントを実装します。
- モデル管理API
POST /models: 新しいモデルの登録GET /models/{model_id}: 特定モデルのメタデータ取得GET /models/{model_id}/versions: モデルの全バージョン取得PUT /models/{model_id}/{version_id}: モデルバージョンの更新（例: ステータスの変更）
- コンテキスト管理API
POST /contexts: コンテキストの登録GET /contexts/{context_id}: 特定コンテキストの取得PUT /contexts/{context_id}: コンテキストの更新
- モデル提供API
GET /serve_model: 特定のコンテキストに基づいて最適なモデルを取得- リクエストパラメータ:
context_idまたは直接コンテキスト情報 - レスポンス: モデルの参照情報 (URI, バージョンなど) または直接モデルバイナリ (設定による)
- リクエストパラメータ:
POST /predict: モデル推論（サーバー側で推論を実行する場合）- リクエストパラメータ:
context_id, 入力データ - レスポンス: 推論結果
- リクエストパラメータ:
2.1.6.3. 5.3. コアロジックの実装
- コンテキスト処理モジュール: 入力コンテキストの正規化、検証、最適なモデルバージョンの検索ロジック。
- モデルロードモジュール: モデルリポジトリから指定されたモデルバイナリをロードし、実行環境に準備します。効率的なキャッシュ機構の導入を検討します。
- データストア連携: 設計したデータモデルに基づき、データベースとのCRUD操作を実装します。
2.1.7. 6. MCPクライアントとの連携
2.1.7.1. 6.1. プロトコル準拠
クライアントとサーバー間のデータフォーマット、認証、エラーハンドリングなど、MCPプロトコルに厳密に準拠します。
2.1.7.2. 6.2. クライアントライブラリの検討 (オプション)
利便性向上のため、サーバーAPIをラップするクライアントライブラリ（SDK）を提供することも検討します。
2.1.8. 7. テストとデバッグ
2.1.8.1. 7.1. 単体テスト
各モジュールやAPIエンドポイントの機能を個別にテストします。
2.1.8.2. 7.2. 結合テスト
複数のコンポーネントが連携して正しく動作するかを確認します。特に、コンテキストに基づいたモデル提供ロジックを重点的にテストします。
2.1.8.3. 7.3. 負荷テスト
サーバーが多数の同時リクエストや高負荷な推論リクエストに耐えられるかを確認します。
2.1.9. 8. デプロイメント
2.1.9.1. 8.1. コンテナ化
Dockerなどのコンテナ技術を用いてアプリケーションをパッケージ化し、環境依存性を低減します。
2.1.9.2. 8.2. 環境設定
本番環境と開発環境で異なる設定（データベース接続情報、APIキーなど）を環境変数や設定ファイルで管理します。
2.1.9.3. 8.3. デプロイ戦略
クラウド環境（AWS, GCP, Azureなど）やオンプレミス環境へのデプロイ手順を確立します。Kubernetesのようなコンテナオーケストレーションツールも検討します。
2.1.10. 9. 運用と保守
2.1.10.1. 9.1. 監視とロギング
サーバーの稼働状況、APIリクエスト数、エラー率などを監視し、異常検知やパフォーマンス分析に役立てます。詳細なログを記録し、問題発生時のデバッグに利用します。
2.1.10.2. 9.2. スケーラビリティ
高負荷時に対応できるよう、オートスケーリングやロードバランシングの仕組みを導入します。
2.1.10.3. 9.3. セキュリティ
API認証・認可、データ暗号化、ネットワークセキュリティグループの設定など、セキュリティ対策を講じます。
2.1.10.4. 9.4. モデルの更新とバージョン管理
新しいモデルバージョンがリリースされた際のデプロイ、既存モデルからの切り替え、ロールバック手順を定義します。
2.1.11. 10. 関連リソース
- [MCP仕様書へのリンク (もしあれば)]
- [GitHubリポジトリへのリンク (もしあれば)]
- [APIドキュメントへのリンク (もしあれば)]
2.2. MCPクライアント
サーバーと1対1の接続を維持するプロトコルクライアントです。
2.2.1. 1. はじめに
Model Context Protocol (MCP) クライアントの作製方法に関する本ドキュメントは、MCPを利用してモデルのコンテキスト情報を効率的に管理・連携するためのクライアントアプリケーション開発を支援することを目的とします。
2.2.1.1. 1.1. MCPとは
Model Context Protocol (MCP) は、異なるシステムやサービス間でモデルの「コンテキスト」（状態、データ、メタデータなど）を交換・同期するためのプロトコルです。これにより、複数のコンポーネントが同一のモデル情報を共有し、一貫性のある動作を保証します。
2.2.1.2. 1.2. 対象読者
本ドキュメントは、ネットワークプログラミング、データシリアライゼーション、および非同期処理の基本的な知識を持つ開発者を対象としています。
2.2.1.3. 1.3. 前提条件
- 選択するプログラミング言語（例: Python, Java, C#, Go）に関する基本的な知識
- TCP/IPまたはWebSocketなどのネットワーク通信プロトコルに関する基本的な理解
- JSONやProtocol Buffersなどのデータシリアライゼーション形式に関する基本的な理解
2.2.2. 2. MCPプロトコルの概要
MCPは、モデルのコンテキスト情報を送受信するための規約を定義します。クライアントは、このプロトコル仕様に従ってメッセージを構築し、サーバーとの間で通信を行います。
2.2.2.1. 2.1. コンテキストの定義
MCPにおけるコンテキストは、特定のモデルインスタンスの状態や関連データを表現する構造化された情報です。これは、モデルID、バージョン、属性、タイムスタンプなどを含むことができます。
2.2.2.2. 2.2. メッセージ構造
MCPメッセージは、通常、ヘッダーとペイロードで構成されます。ヘッダーにはメッセージタイプ、送信元/送信先IDなどのメタデータが含まれ、ペイロードには実際のコンテキストデータ（例: JSONオブジェクト）が格納されます。
2.2.2.3. 2.3. 主要な操作タイプ
- Context Update: モデルのコンテキスト情報の更新を通知する。
- Context Request: 特定のモデルのコンテキスト情報を要求する。
- Context Response: Context Requestに対する応答としてコンテキスト情報を提供する。
- Context Subscribe: 特定のモデルのコンテキスト変更通知の購読。
- Context Notify: 購読者へコンテキスト変更を通知する。
2.2.3. 3. 開発環境の準備
MCPクライアント開発を始める前に、適切な開発環境をセットアップします。
2.2.3.1. 3.1. プログラミング言語の選択
プロジェクトの要件や開発者のスキルセットに基づいて、適切なプログラミング言語を選択します（例: Python, Java, C#, Go）。
2.2.3.2. 3.2. 必要なライブラリとSDK
選択した言語に応じて、以下の機能を提供するライブラリを導入します。
- ネットワーク通信ライブラリ: TCP/IPソケット、WebSocketクライアントの実装（例: Pythonの
socket,websocket-client、Javaのjava.net.Socket,OkHttp）。 - データシリアライゼーションライブラリ: JSON、Protocol Buffersなどのデータのエンコード/デコード（例: Pythonの
json,protobuf、JavaのJackson,Gson）。 - 非同期処理ライブラリ: ノンブロッキングI/Oやイベントループをサポートするフレームワーク（例: Pythonの
asyncio, JavaのCompletableFuture）。
2.2.3.3. 3.3. 開発ツールのインストール
統合開発環境（IDE）、バージョン管理システム（Git）、およびビルドツール（Maven, Gradle, pip, Poetryなど）を準備します。
2.2.4. 4. MCPクライアントの基本アーキテクチャ
MCPクライアントは、通常、以下の主要なコンポーネントで構成されます。
2.2.4.1. 4.1. コネクションマネージャ
MCPサーバーとのネットワーク接続の確立、維持、および切断を管理します。再接続ロジックやハートビート機構を含む場合があります。
2.2.4.2. 4.2. メッセージパーサー/シリアライザ
MCPメッセージの送受信時に、プロトコル仕様に従ってデータをシリアライズ（オブジェクトからバイト列へ変換）およびデシリアライズ（バイト列からオブジェクトへ変換）します。
2.2.4.3. 4.3. コンテキストストア
受信したコンテキスト情報を内部的に保持し、管理するコンポーネントです。モデルIDごとにコンテキストをキャッシュし、更新や取得の要求に応じます。
2.2.4.4. 4.4. APIインターフェース
クライアントアプリケーションがMCPクライアントを利用するための高レベルなインターフェースを提供します。コンテキストの送信、要求、購読などのメソッドを公開します。
2.2.5. 5. 通信モジュールの実装
MCPクライアントの中核となるネットワーク通信部分を実装します。
2.2.5.1. 5.1. サーバーへの接続確立
選択したプロトコル（TCP/IP、WebSocketなど）を使用してMCPサーバーへの接続を確立します。接続確立失敗時のエラーハンドリングを含めます。
2.2.5.2. 5.2. メッセージの送信
MCPメッセージオブジェクトをバイト列にシリアライズし、ネットワークを通じてサーバーへ送信します。送信キューやレートリミットを考慮することが推奨されます。
2.2.5.3. 5.3. メッセージの受信と処理
ネットワークから受信したバイト列をMCPメッセージオブジェクトにデシリアライズし、メッセージタイプに基づいて適切なハンドラにディスパッチします。
2.2.5.4. 5.4. 非同期処理とイベントループ
複数のコンテキスト更新を効率的に処理するため、非同期I/Oとイベントループパターンを適用し、ノンブロッキングな通信を実現します。
2.2.6. 6. コンテキスト管理の実装
クライアント内部でのコンテキスト情報の管理ロジックを実装します。
2.2.6.1. 6.1. コンテキストデータの内部表現
受信したコンテキストデータを格納するためのデータ構造（例: クラス、辞書、ハッシュマップ）を設計します。
2.2.6.2. 6.2. コンテキストの更新と同期
サーバーからContext Updateメッセージを受信した場合、内部のコンテキストストアを更新します。必要に応じて、バージョン管理や競合解決ロジックを実装します。
2.2.6.3. 6.3. コンテキストの取得
クライアントアプリケーションからの要求に応じて、コンテキストストアから最新のコンテキスト情報を提供します。
2.2.6.4. 6.4. コンテキスト変更通知の購読と配信
Context Subscribeにより特定のコンテキストの変更を購読し、Context Notifyメッセージを受信した場合、内部のイベントシステムを通じて購読者に変更を通知する仕組みを実装します。
2.2.7. 7. クライアントAPIの設計
開発したMCPクライアントを他のアプリケーションから利用するための、使いやすいAPIを設計します。
2.2.7.1. 7.1. 初期化と接続/切断
クライアントインスタンスの生成、サーバーへの接続、および切断を行うメソッド（例: connect(), disconnect()）。
2.2.7.2. 7.2. コンテキスト操作
コンテキストの更新送信、要求、購読、購読解除を行うメソッド（例: send_context_update(model_id, context_data), request_context(model_id), subscribe_context(model_id, callback), unsubscribe_context(model_id)）。
2.2.7.3. 7.3. イベントハンドリング
コンテキストの変更、接続状態の変更、エラー発生時などにコールバックを登録できるメカニズム（例: on_context_updated, on_connected, on_error）。
2.2.8. 8. エラーハンドリングとロギング
堅牢なMCPクライアントを構築するための重要な側面です。
2.2.8.1. 8.1. ネットワークエラーハンドリング
接続の切断、タイムアウト、通信エラーなど、ネットワーク関連のエラーを適切に検出し、再接続試行などのリカバリロジックを実装します。
2.2.8.2. 8.2. プロトコルエラーハンドリング
不正なメッセージフォーマット、予期しないメッセージタイプなど、MCPプロトコル違反を検出し、適切なエラー応答または処理を行います。
2.2.8.3. 8.3. ロギング
開発、デバッグ、および運用中の問題を特定するために、適切なレベル（DEBUG, INFO, WARNING, ERROR）でイベントやエラー情報をログに出力します。
2.2.9. 9. テスト
開発したMCPクライアントの信頼性と正確性を確保するためにテストを実施します。
2.2.9.1. 9.1. 単体テスト
各コンポーネント（コネクションマネージャ、メッセージパーサー、コンテキストストアなど）が期待通りに動作するかを検証します。
2.2.9.2. 9.2. 結合テスト
MCPサーバーと連携して、メッセージの送受信、コンテキストの更新、購読などが正しく機能するかを検証します。モックサーバーやテスト用サーバーを使用することが有効です。
2.2.9.3. 9.3. パフォーマンステスト
多数のコンテキスト更新や高負荷な通信条件下でのクライアントのスループット、レイテンシ、リソース使用量を評価します。
2.2.10. 10. デプロイと運用
クライアントを本番環境にデプロイし、安定して運用するための考慮事項です。
2.2.10.1. 10.1. パッケージングと配布
クライアントをスタンドアロンアプリケーション、ライブラリ、またはサービスとしてパッケージングし、配布します。
2.2.10.2. 10.2. 監視とメンテナンス
クライアントの状態、パフォーマンス、およびエラーを監視する仕組みを導入し、必要に応じてアップデートやメンテナンスを行います。
2.2.10.3. 10.3. セキュリティ
通信の暗号化（TLS/SSL）、認証、認可メカニズムの適用を検討します。
2.3. MCPホスト
クライアントとサーバー間の通信を管理するランタイム環境を提供します。Claude DesktopやMCPをサポートするIDE拡張機能などが該当します。
2.3.1. Model Context Protocol (MCP) ホストの作製方法
2.3.1.1. 1. はじめに
このドキュメントは、Model Context Protocol (MCP) ホストを構築するための手順と考慮事項を記述します。MCPホストは、MCPクライアントからのリクエストを受け付け、コンテキストモデルのライフサイクルを管理し、定義されたプロトコルに従ってコンテキストデータを交換する役割を担います。
2.3.1.2. 2. MCPホストの役割とアーキテクチャ概要
2.3.1.2.1. 2.1 MCPホストの役割
MCPホストは以下の主要な役割を担います。
- MCPクライアントからのコンテキストデータ操作リクエスト（登録、更新、取得、削除）の受付と処理。
- コンテキストデータの整合性と永続性の維持。
- MCP仕様に準拠したメッセージの送受信。
- コンテキストモデルの状態管理。
2.3.1.2.2. 2.2 アーキテクチャ概要
一般的なMCPホストは以下のコンポーネントで構成されます。
- プロトコルインターフェース: MCPメッセージの送受信を処理する層。TCP/IP, HTTP/WebSocketなど、基盤となる通信プロトコルを抽象化します。
- MCPエンジン: MCP仕様に基づき、コンテキストモデルのライフサイクル管理やデータ操作ロジックを実装します。
- コンテキストストア: コンテキストデータを永続的に保存するデータベースまたはストレージシステム。
- APIレイヤー: 必要に応じて、MCP以外の外部システムやアプリケーションがコンテキストデータにアクセスするためのAPIを提供します。
- 認証・認可モジュール: クライアントのアクセス制御を行います。
2.3.1.3. 3. 前提条件
MCPホストの開発には、以下の知識と環境が必要です。
2.3.1.3.1. 3.1 必要な知識
- MCP仕様に関する深い理解。
- 選択するプログラミング言語（例: Python, Java, Go, C#）とフレームワークの知識。
- データベース（RDBMS, NoSQL）の基本的な知識。
- ネットワークプロトコル（TCP/IP, HTTP/WebSocket）の基本的な知識。
2.3.1.3.2. 3.2 必要なツールと環境
- 選択するプログラミング言語の実行環境とSDK。
- 開発統合環境 (IDE)。
- バージョン管理システム (例: Git)。
- ビルドツールと依存関係管理ツール。
- テストフレームワーク。
- デプロイ対象のサーバー環境（オンプレミス、クラウド）。
2.3.1.4. 4. MCPホストの開発手順
2.3.1.4.1. 4.1 開発環境のセットアップ
選択したプログラミング言語の環境を構築し、必要なライブラリやフレームワークをインストールします。
2.3.1.4.2. 4.2 MCPライブラリ/SDKの選定と導入
既存のMCP関連ライブラリやSDKがある場合は、それを導入し、プロジェクトに組み込みます。これにより、MCPメッセージのパース、シリアライズ、基本プロトコルハンドリングの大部分を効率化できます。
2.3.1.4.3. 4.3 コンテキストデータモデルの定義
MCP仕様に基づき、ホストが管理する具体的なコンテキストデータモデルを定義します。これは通常、JSON Schema, Protocol Buffers, Avroなどのスキーマ定義言語で記述されます。
2.3.1.4.4. 4.4 プロトコルインターフェースの実装
- 通信基盤の選択: MCPメッセージを交換するための通信プロトコル（例: WebSocket, gRPC over HTTP/2, MQTT）を選択します。
- メッセージハンドラの実装: クライアントからの各MCPメッセージタイプ（例:
RegisterContextRequest,UpdateContextRequest,GetContextRequest）に対応するハンドラを実装します。 - 応答メッセージの生成: 処理結果に応じて、適切なMCP応答メッセージ（例:
RegisterContextResponse,ContextUpdatedEvent,GetContextResponse）を生成し、クライアントに返信します。
2.3.1.4.5. 4.5 MCPエンジンの実装
- コンテキストデータのCRUD操作: 定義したデータモデルに基づき、コンテキストストアへの登録 (Create)、取得 (Read)、更新 (Update)、削除 (Delete) のロジックを実装します。
- コンテキスト状態管理: コンテキストの有効期限、依存関係、バージョン管理など、MCP仕様で定義される状態管理機能を実装します。
- イベント発行: コンテキストが変更された際（例: 更新、削除）に、MCP仕様で定義されたイベントメッセージ（例:
ContextUpdatedEvent,ContextDeletedEvent）を生成し、関連するクライアントにブロードキャストするメカニズムを実装します。
2.3.1.4.6. 4.6 コンテキストストアの連携
選定したデータベース（RDBMS, NoSQLなど）との連携を実装します。コンテキストデータモデルをデータベースのスキーマにマッピングし、永続化レイヤーを提供します。データの整合性、トランザクション処理、スケーラビリティを考慮します。
2.3.1.4.7. 4.7 認証・認可機能の実装 (任意)
MCPホストへのアクセスを制限するために、クライアントの認証（例: APIキー、OAuth2.0）および認可（例: ロールベースアクセス制御）機能を実装します。
2.3.1.4.8. 4.8 エラーハンドリングとロギング
堅牢なシステムのために、適切なエラー処理メカニズムと詳細なロギング機能を実装します。これにより、問題発生時の診断とデバッグが容易になります。
2.3.1.5. 5. テストと検証
2.3.1.5.1. 5.1 単体テスト
各コンポーネント（プロトコルハンドラ、MCPエンジン、データストア連携モジュールなど）が期待通りに動作することを確認します。
2.3.1.5.2. 5.2 結合テスト
MCPクライアントシミュレータなどを用いて、ホストとクライアント間のメッセージ交換がMCP仕様に準拠しているか、エンドツーエンドのシナリオで検証します。
2.3.1.5.3. 5.3 性能テスト
高負荷時のレスポンスタイム、スループット、リソース消費量を測定し、性能要件を満たしているか確認します。
2.3.1.5.4. 5.4 セキュリティテスト (任意)
認証・認可機能が正しく動作するか、脆弱性がないかなどをテストします。
2.3.1.6. 6. デプロイと運用
2.3.1.6.1. 6.1 デプロイメント
ビルドしたMCPホストアプリケーションを、選定したサーバー環境にデプロイします。コンテナ技術（Docker, Kubernetes）やクラウドプラットフォームのマネージドサービスを活用することで、デプロイとスケーリングを容易にできます。
2.3.1.6.2. 6.2 監視とロギング
ホストの稼働状況、パフォーマンスメトリクス、エラーログを継続的に監視するためのツール（Prometheus, Grafana, ELK Stackなど）を設定します。
2.3.1.6.3. 6.3 メンテナンスとアップグレード
MCP仕様の変更や機能追加に対応するためのメンテナンス計画を立て、定期的なアップデートとアップグレードを行います。
2.3.1.7. 7. 参照資料
- Model Context Protocol (MCP) 最新仕様書
- 選択したプログラミング言語およびフレームワークの公式ドキュメント
- 選定したデータベースの公式ドキュメント
3. MCPサーバーの主要機能
MCPサーバーは、主に以下の3つの機能を提供します。
3.1. ツール
AIモデルが呼び出すことができる実行可能な関数です。外部APIの呼び出し、データベース操作、ファイルの作成や編集などが含まれます。
3.2. リソース
ユーザーやLLMが利用する文脈やデータ（テキスト、画像、動画など）です。
3.3. プロンプト
引数で受け取った値を使ってプロンプトを生成する、定義済みのプロンプトテンプレートです。
4. MCPサーバー構築の一般的な手順
MCPサーバーを構築する一般的な手順は以下の通りです。
4.1. 環境セットアップ
Pythonなどのプログラミング言語と、FastMCPなどのMCPサーバーフレームワーク、必要なパッケージをインストールします。
4.2. サーバーインスタンスの生成
選択したフレームワークを使用して、MCPサーバーの基本的なインスタンスを生成します。
4.3. ツール（機能）の定義
AIモデルに公開したい機能をツールとして定義します。ツールは、入力パラメータと出力の型ヒント、およびLLMがツールの用途を理解するためのドキュメント文字列（docstring）を持つ関数として実装されます。
4.4. リソース（データ）の公開
AIモデルがアクセスできるデータソース（例: ベクターストア、ローカルファイル、データベース）を設定し、リソースとして公開します。
4.5. 設定ファイルの構成と接続
MCPサーバーの設定ファイルを構成し、Claude DesktopなどのMCPホストからサーバーに接続します。設定ファイルの場所はOSによって異なる場合があります。
5. 構築時の考慮事項
- 言語とフレームワーク: PythonやTypeScriptなど、複数の言語でMCPサーバーを構築できます。FastMCPなどのフレームワークが利用可能です。
- データソース: プライベートデータソース（ベクターストアなど）や外部サービスAPIと連携して、AIモデルに利用させるデータや機能を提供できます。
- デバッグ: MCP Inspectorなどのツールを使用して、構築したMCPサーバーのデバッグを行うことができます。
- セキュリティ: 本番環境での運用を考慮し、認証や安全な秘密情報の管理などのセキュリティ対策を講じることが重要です。 検索ソース:
5.1. JavaMCPサーバー
「25年はAIエージェントが流行る」という観測が多く聞かれましたが、昨今開発界隈で話題のModel Context Protocol (MCP)により、現実味が増してきたように思います。 既に多くの方が記事化されていますが、Claudeと開発ツール系のMCPサーバーを組み合わせるパターンが多く見受けられます。またPythonのサンプルコードは多いですが、Javaは少数派です。 そこで当記事では「業務データを扱うMCP」をイメージして、どんなことが実現できるのかを体験していきたいと思います。プラットフォームは業務システムで広く利用されているJavaを使用します。
5.2. 実現すること
JavaのOpenLiberty上で動作するサービスをSSEのMCPサーバーとして実行し、AIアプリケーションと組み合わせて動作を確認します。
- 1:つくる編(当記事)
- 2:うごかす編 当記事ではMCPサーバーを準備するところまでを紹介し、別の記事でMCPサーバーの動作を確認していきます。
5.3. 環境
Pythonとnode.jsはMCPサーバーの動作検証ツールを使用するために使いますが、検証ツール使用をスキップしてもMCPサーバーは動かすことができます。
5.4. MCPについて
5.4.1. MCPとは
本家サイトでは「Think of MCP like a USB-C port for AI applications.」と紹介されています。これは、USB-Cのように「簡単に接続でき」「設定なしですぐに機能する」という利便性をAIアプリケーションにもたらすことを意図した表現です。 「プロトコル」と名付けられていますが、ネットワークプロトコルとは異なります。RESTやGraphQLといったAPI設計のパラダイムと同様の粒度で、AIアプリケーションとその外部との対話における共通のルールを定めたものです。各種プログラミング言語向けのSDKも提供されており、開発者は容易にMCPを組み込むことができます MCPでは、様々な機能が定義されており、MCPクライアントの種類によって利用できる機能が異なります。公開されている各MCPクライアントの実装対応を見ると、Toolsが中心的な役割を担っていることがわかります。 Toolsに相当する外部連携の仕組みは、従来より「ファンクションコーリング」などの名称で存在していました。しかし、これまではAIアプリケーション側での実装が必要となる場面も少なくありませんでした。MCPは、このような外部連携機能をより簡便に利用できるようにすることを目指しています。 MCPについては、既に多くの参考記事が公開されていますので、本章ではその概要を紹介するに留めます。 各技術要素を深掘りしたい場合は、上記ページから始まる「Concepts」を確認してみてください。
5.4.2. MCPサーバーとは
MCPサーバーは、AIから見た外部リソースのプロキシのような役割を担います。主な機能は以下の通りです。
- MCPクライアントと通信するためのインターフェースを提供します
- ツールなどの提供する機能の定義をMCPクライアントに通知します
- バックエンドのサービスを呼び出します MCPクライアントとの接続方式として、標準実装では「STDIO」（標準入出力）と「SSE」（Server-Sent Events）の2つが用意されています。STDIOは、MCPクライアントとMCPサーバーを同一マシン上で動作させる場合に適しています。一方、SSEはHTTPベースで動作するため、リモートにあるMCPサーバーとの接続が可能です。 実行環境のネットワーク構成やセキュリティ要件などを考慮して、適切な接続方式を選択することになります。 記事作成時点では、Pythonで記述されたMCPサーバーを mv や npx コマンドで起動するケースが多いようですが、実際のビジネス環境においては、クライアント端末にPython環境を組み込んだり、動的にMCPサーバーをインストールしたりすることは、保守やセキュリティの観点から難しい場合があります。そのため、実用的な運用を見据えると、リモート接続が可能なSSEの利用も検討すべきでしょう。
5.5. 今回作成するMCPサーバー
5.5.1. 実装技術
Javaの実行フレームワーク（APサーバー）であるOpenLibertyを利用してMCPサーバーを構築し、MCPクライアントとの接続にはSSE（Server-Sent Events）を採用します。 公式サイトにはいくつかの実装パターンが示されていますが、今回はそのうち赤枠で示されているパターンに相当する構成となります。 JavaのSSEの実装は3パターンありますが、Springを使用しないシンプルなHttpServletSseServerTransportを使用します。
5.5.2. Toolの仕様
今回提供するToolは、「火星の天気を取得する」機能です。火星の大陸名を指定すると、対応する天気と気温の情報を返します。このToolが提供するデータは、アプリケーション内に固定で記述された以下の結果に基づきます。 いずれの大陸名も、火星の大陸名として現実世界で定義されているものです。 火星は太陽から遠く大気も薄いため、気温は地球に比べて低めです。
5.6. セットアップ
5.6.1. JDK
MCPサーバーの実行にはJDK（Java Development Kit）が必要です。既にJDK 17以降がインストールされている環境であれば、そのままご利用いただけます。 もしJDKのインストールが必要な場合は、こちらのQiita記事をご参照いただき、記事内のJDKをインストールする手順に従って環境構築をお願いいたします。
5.6.2. MCPサーバープログラムのダウンロード
GitHubからサンプルプログラムをcloneしてください。Gitが必要ですが、Gitのインストール手順は割愛します。