Zenn
🐮

Model Context Protocol (MCP)入門：公式ドキュメントベースで牛歩のごとくゆっくり理解する 🐮

に公開
39
AI
Model Context Protocol
LLM
Anthropic
tech

1. イントロダクション

1.1. MCPとは何か - AIのための共通言語

Model Context Protocol（MCP）は、AIアプリケーションとコンテキストソース（ファイルシステム、データベース、外部APIなど）の間をシームレスに接続するための標準化されたプロトコルです。

MCPは「AIのための共通言語」と考えることができます。異なる国の人々が共通言語を通じてコミュニケーションできるように、MCPは異なるAIツールやデータソースが互いに理解し合うための標準化された方法を提供します。この共通言語があることで、様々なAIシステムとコンテキストソースが効率的に情報を交換できるようになります。

MCPは、クライアント-ホスト-サーバーアーキテクチャに基づいており、JSON-RPCを使用してコンテキスト交換やサンプリング調整などの機能を提供します。このアーキテクチャにより、開発者は明確なセキュリティ境界を維持しながら、複数のアプリケーションにAI機能を統合することができます。

1.2. なぜMCPが重要なのか

現在のAI開発環境では、各AIツールベンダーが独自のインターフェースやAPI設計を持っており、異なるシステム間の統合には多大な労力が必要です。これはいわゆる「サイロ化」を引き起こし、ベンダーロックインや互換性の問題を生み出しています。

MCPが提供する標準化の価値として、以下のような点をあげることができます。

価値 説明
相互運用性 異なるAIツールやシステムが共通の言語で通信できる
モジュール性 機能ごとに分離された設計により、必要な機能だけを実装可能
セキュリティ 明確な境界と責任分担によるセキュリティの向上
柔軟性 ベンダーに依存しない設計により、ツールの自由な選択と組み合わせが可能

2. AIツール連携の進化

2.1. LLMの性能向上とツール連携の必要性

大規模言語モデル（LLM）は近年、急速に進化してきました。GPT-4、Claude、Gemini、Llama 3などのモデルは、テキスト生成、コード作成、推論能力において驚異的な性能を示しています。しかし、これらのモデルにも明確な限界があります。具体的には次のような制約が存在します。

  • 最新の情報へのアクセスができない（トレーニングデータのカットオフ日以降の情報）
  • 専門システムやデータベースと直接やり取りできない
  • 複雑な計算や特定のタスクを効率的に処理できない
  • ユーザー固有のデータやコンテキストに直接アクセスできない

これらの限界を克服するため、LLMを外部ツールやシステムと連携させる必要性が高まりました。例えば、最新の気象データを取得するAPI、企業の内部データベース、特定の計算エンジンなどと連携することで、LLMの能力を大幅に拡張できます。

2.2. 初期の解決策とその限界

AI業界は、これらの課題に対して様々なアプローチを試みてきました。

2.2.1. Function Calling（関数呼び出し）

OpenAIやAnthropicなどのAIプロバイダーは、モデルが外部関数を呼び出せる機能を提供しています。これにより、APIリクエストの実行、データベースクエリの送信、特定の計算の実行などが可能になりました。

しかし、Function Callingには以下のような限界があります。

  • 各プロバイダーが独自の実装方法を持っており、互換性がない
  • 主にシングルターンの対話に最適化されており、複雑な文脈維持が難しい
  • ベンダーロックインを引き起こしやすい
  • 提供される機能が限定的

2.2.2. RAG（Retrieval Augmented Generation）

RAGは、外部知識ベースからの情報検索とLLMの生成能力を組み合わせるアプローチです。これにより、モデルの知識を拡張し、より正確な回答を提供できるようになりました。

しかしRAGにも課題があります。

  • 検索と生成のバランスが難しい
  • 複数のデータソースを統合する標準的な方法がない
  • リアルタイムデータの取り扱いが複雑
  • 実装が複雑で、高度なエンジニアリングスキルが必要

2.3. ユーザー + 開発者の抱える課題

これらの初期アプローチは、多くの問題を解決しましたが、ユーザーや開発者は依然として次のような課題に直面しています。

2.3.1. 統合の複雑さ

現在のAIツール連携は、多くの場合「カスタム統合」に依存しています。つまり、各連携ポイントで専用のコードを書く必要があり、以下の問題が生じます。

課題 内容
開発工数の増大 各システムに対して個別のインテグレーションコードを開発する必要がある
保守の複雑さ 多数の独立した連携ポイントを維持管理しなければならない
スケーラビリティの制限 新しいシステムを追加するたびに新たな統合コードが必要になる
エラー処理の一貫性の欠如 各連携先によって異なるエラーハンドリング方法が必要になる

例えば、あるアプリケーションがOpenAIのGPT-4、社内データベース、天気API、カレンダーシステムと連携する場合、それぞれに個別の接続コードを書き、異なるデータ形式や認証方式に対応する必要があります。

2.3.2. ベンダーロックインの問題

特定のAIプロバイダーの独自APIやツールに依存すると、以下のようなリスクが生じます。

リスク 詳細
価格変更や利用条件の変更に対する脆弱性 ベンダーが価格体系や利用条件を変更した場合に代替手段なく影響を受けざるを得ない
他のプロバイダーへの切り替えコストの増大 より適したプロバイダーが出現しても移行に大きな労力とコストがかかる
単一障害点のリスク 選択したプロバイダーに障害が発生するとシステム全体が影響を受ける
イノベーションの制限 特定ベンダーの機能や制約に縛られ、他のイノベーティブな技術を採用しにくくなる

例えば、OpenAIのFunction Callingに最適化されたシステムをAnthropicのClaudeで動作させるには、再設計が必要になる可能性があります。

これらの課題に対応するため、AIエコシステムは標準化されたインターフェースを求めるようになりました。そこで登場したのが、Model Context Protocol（MCP）です。MCPは、異なるAIツールやデータソース間の相互運用性を実現する標準プロトコルとして設計されました。

次のセクションでは、MCPのアーキテクチャと主要コンポーネントについて詳しく見ていきます。

3. MCPのアーキテクチャ概要

3.1. クライアント-ホスト-サーバーモデルの説明

Model Context Protocol（MCP）は、クライアント-ホスト-サーバーアーキテクチャを採用しています。このアーキテクチャでは、各ホストが複数のクライアントインスタンスを実行できるように設計されています。この設計によって、ユーザーはアプリケーション間でAI機能を統合しつつ、明確なセキュリティ境界を維持し、関心事を分離することが可能になります。

この図は、MCPの主要なコンポーネントとその関係を示しています。アプリケーションホストプロセス内のホストが複数のクライアントを管理し、それぞれのクライアントが異なるサーバーと通信しています。サーバーはそれぞれ独自のリソースにアクセスし、ローカルやリモートのデータソースと連携します。

3.1.1. ホスト

ホストプロセスは、コンテナおよびコーディネーターとして機能します。

役割 説明
クライアント管理 複数のクライアントインスタンスを作成し、それらのライフサイクルを管理する
接続制御 クライアント接続の権限とステータスを監視・制御する
セキュリティ管理 セキュリティポリシーと同意要件を実施し、システム全体の安全性を確保する
認証処理 ユーザー認証決定を処理し、適切なアクセス権を付与する
AI連携調整 AI/LLM統合とサンプリングを調整し、モデルとの効率的な対話を実現する
コンテキスト管理 複数クライアント間でのコンテキスト集約を管理し、一貫した情報フローを維持する

ホストは、アプリケーション全体の中心的な制御ポイントとして、AI機能の統合と管理を担当しています。例えば、ユーザーがLLMを使って質問に答える場合、ホストは必要なコンテキストを集め、適切なLLMにリクエストを送信し、結果を処理するプロセスを調整します。

3.1.2. クライアント

各クライアントはホストによって作成され、サーバーとの分離された接続を維持します。

機能 詳細
セッション確立 サーバーごとに1つのステートフルなセッションを確立し、継続的な通信を可能にする
プロトコル管理 プロトコルネゴシエーションと機能交換を処理し、互換性を確保する
メッセージルーティング プロトコルメッセージを双方向にルーティングし、スムーズな情報交換を実現する
通知管理 サブスクリプションと通知の管理を担当し、リアルタイム更新を可能にする
セキュリティ境界 サーバー間のセキュリティ境界を維持し、情報の分離を確保する

ホストアプリケーションは複数のクライアントを作成・管理し、各クライアントは特定のサーバーと1対1の関係を持ちます。これにより、異なるデータソースやツールとの個別の接続を管理しつつ、セキュリティを確保できます。

3.1.3. サーバー

サーバーは専門的なコンテキストと機能を提供します。

特徴 説明
機能公開 リソース、ツール、プロンプトをMCPプリミティブを通じて公開し、アクセス可能にする
専門性 焦点を絞った責任を持ち、独立して動作することで機能の分離と再利用性を高める
サンプリングリクエスト クライアントインターフェースを通じてAIモデルにサンプリングをリクエストできる
セキュリティ遵守 設定されたセキュリティ制約を遵守し、安全なデータアクセスを保証する
デプロイ柔軟性 ローカルプロセスまたはリモートサービスとして動作可能で、様々な環境に対応する

サーバーは、特定の機能やデータソースへのアクセスを提供する専門化されたコンポーネントです。例えば、あるサーバーはファイルシステムへのアクセスを提供し、別のサーバーはデータベースへのクエリ機能を提供するといった形で、それぞれが明確に定義された役割を持ちます。

3.2. プロトコルの階層構造

MCPは、いくつかの主要コンポーネントで構成されています。

階層 役割 主要コンポーネント 実装要件
基本プロトコル コアメッセージ形式を定義 ・リクエスト
・レスポンス
・通知
・バッチ処理		 すべての実装で必須（MUST）
ライフサイクル管理 セッションの管理を担当 ・初期化
・操作
・シャットダウン		 すべての実装で必須（MUST）
サーバー機能 AIモデルへのコンテキスト提供 ・リソース
・プロンプト
・ツール		 必要に応じて選択実装（MAY）
クライアント機能 サーバーとの連携強化 ・サンプリング
・ルートディレクトリ		 必要に応じて選択実装（MAY）
ユーティリティ 横断的な機能サポート ・ロギング
・引数補完
・進捗報告
・キャンセル		 必要に応じて選択実装（MAY）

3.3. コアコンポーネントの概要

MCPはJSON-RPC（JavaScript Object Notation Remote Procedure Call）をベースとした通信プロトコルを採用しています。JSON-RPCは軽量で言語に依存しないリモートプロシージャコール形式で、クライアントとサーバー間のメッセージ交換の標準化された方法を提供します。

3.3.1. メッセージタイプ

MCPでは、以下の主要なメッセージタイプが定義されています。

3.3.1.1. リクエスト

クライアントからサーバー、またはその逆に送信され、操作を開始します。

{
  "jsonrpc": "2.0",
  "id": "abc123",
  "method": "resources/read",
  "params": {
    "uri": "file:///project/src/main.rs"
  }
}
特性 要件
ID 文字列または整数のIDを含める必要がある
一意性 IDは null であってはならず、セッション内で一意でなければならない
メソッド名 操作を識別する文字列を指定する（例: "resources/read"）
パラメータ オプションのパラメータオブジェクトで操作に必要な引数を提供する
3.3.1.2. レスポンス

リクエストに対する応答として送信され、操作の結果またはエラーを含みます。

{
  "jsonrpc": "2.0",
  "id": "abc123",
  "result": {
    "contents": [
      {
        "uri": "file:///project/src/main.rs",
        "mimeType": "text/x-rust",
        "text": "fn main() {\n    println!(\"Hello world!\");\n}"
      }
    ]
  }
}
特性 要件
対応するID レスポンスには、対応するリクエストと同じIDを含める必要がある
結果分類 レスポンスは「成功結果」または「エラー」のいずれかに分類される
排他的設定 レスポンスにはresultまたはerrorのいずれかを設定する必要があり、両方を設定することはできない
3.3.1.3. 通知

クライアントからサーバー、またはその逆に送信される一方向のメッセージです。受信者は応答を送信してはなりません。

{
  "jsonrpc": "2.0",
  "method": "notifications/resources/updated",
  "params": {
    "uri": "file:///project/src/main.rs"
  }
}
特性 要件
ID不要 通知にはIDを含めてはならない
メソッド名 通知の種類を識別する文字列を指定する（例: "notifications/resources/updated"）
パラメータ オプションのパラメータオブジェクトで通知に関連する情報を提供する
応答不要 通知に対する応答を送信してはならない

3.3.2. バッチ処理

JSON-RPCでは、複数のリクエストと通知を配列として送信することで、それらをバッチ処理することも定義されています。

実装要件 説明
送信サポート MCP実装はJSON-RPCバッチの送信をサポートしてもよい（MAY）
受信サポート MCP実装はJSON-RPCバッチの受信をサポートしなければならない（MUST）
バッチ形式 複数のリクエストや通知をJSON配列としてグループ化して送信する
応答処理 各リクエストに対する応答は、送信時と同じ順序で返される

3.4. トランスポート層

MCPは、クライアントとサーバー間の通信に以下の標準的なトランスポートメカニズムを定義しています。

トランスポート 特徴 通信方法 ユースケース
stdio ・クライアントがサーバーをサブプロセスとして起動
・改行区切りのメッセージ交換
・埋め込み改行は不可		 ・サーバーは stdin から読み取り
・サーバーは stdout に書き込み
・ログは stderr に出力可能		 ・ローカルツール統合
・コマンドラインアプリケーション
・スクリプト化された環境
Streamable HTTP ・独立プロセスとしてのサーバー
・複数クライアント接続対応
・Server-Sent Events対応		 ・JSONメッセージをHTTP POSTで送信
・Server-Sent Eventsで非同期応答
・単一HTTPエンドポイント		 ・Webアプリケーション
・分散システム
・クラウドサービス

これらのトランスポートメカニズムにより、MCPは様々な環境やアプリケーションで柔軟に動作することができます。

3.5. 設計原則

MCPは次の重要な設計原則に基づいて構築されています。

設計原則 実現方法 利点
サーバーの構築容易性 ・ホストアプリケーションが複雑なオーケストレーションを担当
・サーバーは特定の明確に定義された機能に集中
・シンプルなインターフェース設計		 ・実装オーバーヘッドの最小化
・専門化されたサーバーの迅速な開発
・保守性の向上
高い組み合わせ性 ・各サーバーは独立した集中機能を提供
・共有プロトコルによる相互運用性
・モジュラー設計		 ・複数サーバーの柔軟な組み合わせ
・機能の再利用性
・システム拡張の容易さ
セキュリティ分離 ・サーバーは必要なコンテキスト情報のみ受け取る
・会話履歴はホストに保持
・ホストによるセキュリティ境界の強制		 ・最小権限の原則の実施
・情報漏洩リスクの低減
・コンテキスト分離の確保
段階的拡張性 ・コアプロトコルは最小限の必要機能を提供
・機能は必要に応じてネゴシエーション
・後方互換性の維持		 ・クライアントとサーバーの独立した進化
・将来の拡張に対応
・既存システムとの互換性

これらの設計原則により、MCPは柔軟で拡張性が高く、セキュアなプロトコルとなっています。次のセクションでは、MCPの具体的な機能について詳しく見ていきます。

4. MCPの中核機能

MCPの中核となる機能は、サーバー機能とクライアント機能の2つのカテゴリに分けられます。これらの機能は、AIモデルとコンテキストソースを効果的に接続するための基盤を提供します。

4.1. サーバー機能

サーバーは、コンテキストソースとAIモデル間の橋渡し役として、以下の3つの主要なプリミティブを提供します。

4.1.1. リソース（Resources）

リソースは、サーバーがクライアントに公開する構造化データです。ファイルシステム、データベース、外部APIなど、様々なソースからのデータにアクセスするための標準化された方法を提供します。

操作 説明 例
リスト取得 利用可能なリソースの一覧を取得 プロジェクトファイル一覧、データベースのテーブル一覧など
読み取り 特定のリソースの内容を取得 ファイル内容の読み取り、データベースレコードの取得など
サブスクリプション リソースの変更通知を受け取るためのサブスクライブ ファイル変更の監視、データベース更新の検知など
テンプレート パラメータ化されたリソースURIの利用 ファイルパスのテンプレート、クエリテンプレートなど
4.1.1.1. リソースの識別

各リソースはURIで一意に識別されます。MCPでは以下のような標準URIスキームが定義されています。

URIスキーム 目的 例
file:// ファイルシステムリソースを表現 file:///project/src/main.rs
git:// Gitバージョン管理統合 git:///repo/main/HEAD:src/main.js
https:// Web上のリソース https://example.com/api/data
カスタム 実装固有のリソース database:///users/123, jira:///projects/MCP
4.1.1.2. データ型

リソースは、テキストまたはバイナリデータを含むことができます。

データ型 構造 用途
テキスト UTF-8エンコードされたテキスト ソースコード、設定ファイル、テキストドキュメントなど
バイナリ Base64エンコードされたバイナリデータ 画像、音声、バイナリファイルなど
4.1.1.3. 実装例：ファイルシステムリソース
// リソース一覧リクエスト
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "resources/list"
}

// リソース一覧レスポンス
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resources": [
      {
        "uri": "file:///project/src/main.rs",
        "name": "main.rs",
        "description": "メインエントリポイント",
        "mimeType": "text/x-rust"
      },
      {
        "uri": "file:///project/Cargo.toml",
        "name": "Cargo.toml",
        "description": "プロジェクト設定",
        "mimeType": "text/toml"
      }
    ]
  }
}

// リソース読み取りリクエスト
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "resources/read",
  "params": {
    "uri": "file:///project/src/main.rs"
  }
}

// リソース読み取りレスポンス
{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "contents": [
      {
        "uri": "file:///project/src/main.rs",
        "mimeType": "text/x-rust",
        "text": "fn main() {\n    println!(\"Hello, MCP!\");\n}"
      }
    ]
  }
}

4.1.2. プロンプト（Prompts）

プロンプトは、LLMとの対話を導くためのテンプレートや指示です。サーバーはプロンプトを公開し、クライアントはユーザーの意図に基づいてプロンプトを選択・カスタマイズできます。

操作 説明 例
リスト取得 利用可能なプロンプトの一覧を取得 コード生成、バグ修正、ドキュメント作成など
プロンプト取得 特定のプロンプトの内容を取得（引数適用） 「コード生成」プロンプトに言語とタスクを指定して取得
変更通知 プロンプト一覧の変更通知 新しいプロンプトの追加、既存プロンプトの変更など
4.1.2.1. プロンプトの構造

プロンプトは名前、説明、引数、メッセージなどで構成されます。

要素 目的 特性
名前 プロンプトの一意識別子 単純な文字列、リスト表示用
説明 ユーザー向けの説明 プロンプトの目的や使用方法を説明
引数 カスタマイズパラメータ 名前、説明、必須フラグなどを持つ
メッセージ LLMに送信される実際の内容 ロール（ユーザー/アシスタント）と内容を持つ
4.1.2.2. メッセージ内容タイプ

プロンプトメッセージには、様々な種類の内容を含めることができます。

内容タイプ 形式 用途
テキスト プレーンテキスト 指示、質問、回答など
画像 Base64エンコードデータ 視覚情報の提供（マルチモーダルLLM向け）
音声 Base64エンコードデータ 音声情報の提供
埋め込みリソース リソース参照 サーバー管理リソースの直接参照
4.1.2.3. 実装例：コードレビュープロンプト
// プロンプト一覧リクエスト
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "prompts/list"
}

// プロンプト一覧レスポンス
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "prompts": [
      {
        "name": "code_review",
        "description": "コードの品質を分析し、改善を提案します",
        "arguments": [
          {
            "name": "code",
            "description": "レビュー対象のコード",
            "required": true
          },
          {
            "name": "language",
            "description": "プログラミング言語",
            "required": false
          }
        ]
      }
    ]
  }
}

// プロンプト取得リクエスト
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "prompts/get",
  "params": {
    "name": "code_review",
    "arguments": {
      "code": "function add(a, b) {\n  return a + b;\n}",
      "language": "javascript"
    }
  }
}

// プロンプト取得レスポンス
{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "description": "コードレビュープロンプト",
    "messages": [
      {
        "role": "user",
        "content": {
          "type": "text",
          "text": "以下のJavaScriptコードをレビューしてください。品質、可読性、バグの可能性について分析してください。\n\nfunction add(a, b) {\n  return a + b;\n}"
        }
      }
    ]
  }
}

4.1.3. ツール（Tools）

ツールは、LLMが外部システムと対話するための実行可能な関数です。APIリクエストの送信、データベースクエリの実行、計算の実行など、様々なアクションを実行できます。

操作 説明 例
リスト取得 利用可能なツールの一覧を取得 APIリクエスト、天気情報取得、計算実行など
ツール呼び出し 特定のツールを実行 天気APIの呼び出し、データベースクエリの実行など
変更通知 ツール一覧の変更通知 新しいツールの追加、既存ツールの変更など
4.1.3.1. ツールの構造

ツールは名前、説明、入力スキーマなどで構成されます。

要素 目的 特性
名前 ツールの一意識別子 呼び出し時に使用される単純な文字列
説明 ツールの機能説明 LLMがツールの用途を理解するための情報
入力スキーマ 引数の定義 JSONスキーマ形式での引数定義
アノテーション ツールの動作に関する追加情報 安全性レベル、副作用の有無など
4.1.3.2. ツール実行結果

ツールの実行結果は、様々な形式で返すことができます。

結果タイプ 形式 用途
テキスト プレーンテキスト 情報提供、計算結果など
画像 Base64エンコードデータ グラフ、図表、ビジュアルデータなど
埋め込みリソース リソース参照 後で参照できるリソースとして結果を保存
エラー情報 エラーフラグとメッセージ ツール実行中のエラーを報告
4.1.3.3. 実装例：天気情報ツール
// ツール一覧リクエスト
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list"
}

// ツール一覧レスポンス
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "get_weather",
        "description": "指定した場所の現在の天気情報を取得します",
        "inputSchema": {
          "type": "object",
          "properties": {
            "location": {
              "type": "string",
              "description": "都市名または郵便番号"
            },
            "units": {
              "type": "string",
              "enum": ["metric", "imperial"],
              "description": "温度単位（metric=摂氏、imperial=華氏）"
            }
          },
          "required": ["location"]
        }
      }
    ]
  }
}

// ツール呼び出しリクエスト
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "location": "東京",
      "units": "metric"
    }
  }
}

// ツール呼び出しレスポンス
{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "東京の現在の天気:\n気温: 22°C\n湿度: 65%\n状態: 晴れ"
      }
    ],
    "isError": false
  }
}

4.2. クライアント機能

クライアントは、AIモデルとの連携や、サーバーへのリソース提供を行うための機能を提供します。

4.2.1. サンプリング（Sampling）

サンプリングは、サーバーがクライアントを介してLLMからテキスト生成（「サンプリング」または「補完」）をリクエストする機能です。これにより、サーバーは独自のAPI鍵なしにAI機能を利用できます。

機能 説明 用途
メッセージ作成 LLMからテキスト生成を取得 シンプルな質問応答、複雑な文章生成など
モデル選択 使用するLLMの選択ヒントを提供 タスクに最適なモデルを示唆
ユーザー承認 サンプリングリクエストの承認をユーザーに要求 セキュリティとプライバシーの確保
4.2.1.1. メッセージ内容

サンプリングメッセージには様々な種類の内容を含めることができます。

内容タイプ 形式 用途
テキスト プレーンテキスト テキストベースの会話、質問応答など
画像 Base64エンコードデータ 画像分析、マルチモーダル対話など
音声 Base64エンコードデータ 音声入力、音声分析など
4.2.1.2. モデル選択

MCPでは、モデル選択に抽象化されたプリファレンスシステムを採用しています。

選択方法 説明 例
モデルヒント 希望するモデルやファミリーを示唆 "hints": [{"name": "claude-3-sonnet"}]
能力優先度 重視する特性の優先度を指定 コスト、速度、知能などの優先度を0〜1で指定
4.2.1.3. 実装例：簡単な質問
// サンプリングリクエスト
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "sampling/createMessage",
  "params": {
    "messages": [
      {
        "role": "user",
        "content": {
          "type": "text",
          "text": "フランスの首都は何ですか？"
        }
      }
    ],
    "modelPreferences": {
      "hints": [
        {
          "name": "claude-3-sonnet"
        }
      ],
      "intelligencePriority": 0.8,
      "speedPriority": 0.5
    },
    "systemPrompt": "あなたは役立つアシスタントです。",
    "maxTokens": 100
  }
}

// サンプリングレスポンス
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "role": "assistant",
    "content": {
      "type": "text",
      "text": "フランスの首都はパリです。"
    },
    "model": "claude-3-sonnet-20240307",
    "stopReason": "endTurn"
  }
}

4.2.2. ルート（Roots）

ルートは、クライアントがサーバーにファイルシステムへのアクセスポイントを提供する機能です。サーバーは与えられたルート内のファイルにアクセスできますが、それ以外の場所にはアクセスできません。

機能 説明 例
ルート一覧取得 利用可能なファイルシステムアクセスポイントを取得 プロジェクトディレクトリ、リポジトリなど
変更通知 ルート一覧の変更を通知 新しいプロジェクトの追加、ルートの削除など
4.2.2.1. ルートの構造

各ルートは、URIと名前で構成されます。

要素 目的 特性
URI ルートの一意識別子 file:// URIでアクセスポイントを指定
名前 表示用の人間可読な名前 プロジェクト名やリポジトリ名など
4.2.2.2. 実装例：プロジェクトディレクトリ
// ルート一覧リクエスト
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "roots/list"
}

// ルート一覧レスポンス
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "roots": [
      {
        "uri": "file:///home/user/projects/myproject",
        "name": "マイプロジェクト"
      },
      {
        "uri": "file:///home/user/projects/another-project",
        "name": "別のプロジェクト"
      }
    ]
  }
}

4.3. 機能の相互作用

サーバー機能とクライアント機能は互いに連携し、AIモデルとコンテキストソースを効果的に接続します。

サーバー機能 クライアント機能 連携例
リソース ルート サーバーはクライアントが提供するルート内のファイルにアクセス
プロンプト サンプリング サーバーのプロンプトを使用してクライアントからサンプリングをリクエスト
ツール サンプリング サーバーのツール実行結果をサンプリング結果に基づいて生成

4.4. セキュリティ考慮事項

MCPの機能を実装する際には、以下のセキュリティ考慮事項に注意する必要があります。

機能 リスク 緩和策
リソース 不正アクセス ・URIのバリデーション
・明示的なアクセス制御
・ルート内のみへのアクセス制限
プロンプト プロンプトインジェクション ・入力のサニタイズ
・プロンプトとユーザー入力の分離
・テンプレートのエスケープ処理
ツール 不正使用 ・ユーザー承認の実装
・ツール入力のバリデーション
・実行結果のサニタイズ
サンプリング プライバシー侵害 ・ユーザー同意の確保
・センシティブ情報のフィルタリング
・リクエスト内容のレビュー
ルート パストラバーサル ・パスの正規化
・シンボリックリンクの解決
・絶対パスの検証

これらの機能を理解し適切に実装することで、AIシステムとコンテキストソースの間の効果的な連携が可能になります。次のセクションでは、Function CallingとMCPを比較し、それぞれのアプローチの違いについて詳しく見ていきます。

5. Function CallingとMCPの比較

大規模言語モデル（LLM）と外部ツールを連携させる方法として、Function CallingとModel Context Protocol（MCP）は、それぞれ異なるアプローチを提供しています。この章では、両者を詳細に比較し、それぞれの特徴、利点、課題について理解を深めていきます。

5.1. アーキテクチャの違い

Function CallingとMCPは、根本的なアーキテクチャ設計において大きく異なります。

Function CallingとMCPは、AIツールの統合に対して根本的に異なるアプローチを取っています。

Function Callingは中央集権的なAPIを中心とした設計であるのに対し、MCPは分散型で責任分担を明確にした設計を採用しています。これらの設計上の違いは、システムの柔軟性、拡張性、管理のしやすさに大きな影響を与えます。以下の表では、両アプローチの主要な設計上の違いとその実用的な影響を比較しています。

特徴 Function Calling MCP 影響
中心的制御 AIプロバイダーAPI アプリケーションホスト MCPでは制御がより分散され、ユーザー側に主導権がある
アーキテクチャ 中央集権型 分散型 MCPではより柔軟なコンポーネント組み合わせが可能
AI連携方法 モデル内蔵機能 プロトコルレベルの抽象化 MCPではAIプロバイダー切り替えがより容易
拡張性 プロバイダー依存 プロトコル仕様に基づく MCPでは標準化により相互運用性が向上
接続トポロジー スター型（APIを中心に放射状） メッシュ型（複数のサーバーとクライアント） MCPではより複雑な連携が可能

5.2. ベンダー依存性からの解放

Function CallingとMCPの重要な違いの一つは、ベンダー依存性の程度です。

AI開発環境においてベンダー依存性は重要な検討事項です。

Function CallingはAPIプロバイダーに強く紐付いた実装になりがちですが、MCPはプロトコルレベルで抽象化することで、特定のベンダーへの依存を減らし、より柔軟な構成を可能にします。両アプローチのベンダー依存性における主要な違いを以下の表にまとめました。

側面 Function Calling MCP 意義
API依存性 ベンダー固有のAPI依存 プロトコルレベルの抽象化 MCPでは異なるAIプロバイダー間の切り替えが容易
ベンダー切り替え 実装変更が必要 透過的に切り替え可能 MCPではホストの設定変更のみで切り替え可能
マルチベンダー対応 複数実装の維持が必要 単一のプロトコル実装 MCPでは一度の実装で複数ベンダーに対応可能
機能差異の取り扱い 個別に対応が必要 機能ネゴシエーションで自動対応 MCPでは機能の差異を明示的に処理できる

5.3. どちらを選ぶか

Function CallingとMCPは、異なるニーズに対応する補完的なアプローチと考えることができます。

シナリオ 推奨アプローチ 理由
プロトタイピング Function Calling 実装が簡単で迅速に開発可能
単一ベンダー環境 Function Calling 直接統合のシンプルさを活かせる
マルチベンダー環境 MCP ベンダー切り替えの容易さと抽象化の恩恵が大きい
エンタープライズ統合 MCP 分離された責任とセキュリティ境界が重要
複雑なエコシステム MCP 多様なシステム間の標準化された通信が価値を発揮
長期的なプロジェクト MCP 標準化と拡張性が将来の変化に対応しやすい

両アプローチは排他的ではなく、状況に応じて使い分けることも可能です。例えば、短期的にはFunction Callingでプロトタイプを素早く開発し、長期的にはMCPへの移行を計画するといった戦略も考えられます。

最終的には、プロジェクトの要件、規模、将来の拡張性、ベンダー依存のリスク許容度などを考慮して、最適なアプローチを選択することになるでしょう。

6. 実装チュートリアル（リファレンス実装）

前章までで、MCPの概念と特徴について理解を深めました。この章では、公式リポジトリで公開されている実際のMCP実装例を通じて、実装方法を具体的に見ていきます。今回取り上げるのは、Model Context Protocolの公式リポジトリからのBrave Search APIを活用したMCPサーバーの実装例です。

6.1. MCP SDKを使った実装例

MCPの公式リポジトリには、様々なリファレンス実装が公開されています。

今回はその中からBrave検索APIをラップしたMCPサーバーを取り上げます。この実装は、MCPのSDKを使用して構築されています。このサーバーは、MCPプロトコルを通じて以下の2つの検索機能を提供します。

  1. ウェブ検索 - 一般的なウェブ検索機能
  2. ローカル検索 - 位置情報を考慮したビジネス・場所検索機能

6.2. リファレンス実装の解説

リファレンス実装を段階的に解説します。まず、全体的な構造を見てみましょう。

#!/usr/bin/env node

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import {
  CallToolRequestSchema,
  ListToolsRequestSchema,
  Tool,
} from "@modelcontextprotocol/sdk/types.js";

// ツール定義
// ...

// サーバー実装
// ...

// リクエストハンドラー
// ...

// サーバー起動
// ...

このコードは、MCPサーバーの基本的な構成要素を示しています。SDKをインポートし、ツールを定義し、サーバーを構築し、リクエストハンドラーを設定した後、サーバーを起動します。

6.2.1. ツールの定義

MCPサーバーは「ツール」を定義することで、LLMが呼び出せる機能を提供します。リファレンス実装では、2つのツールが定義されています。

const WEB_SEARCH_TOOL: Tool = {
  name: "brave_web_search",
  description:
    "Performs a web search using the Brave Search API, ideal for general queries, news, articles, and online content. " +
    "Use this for broad information gathering, recent events, or when you need diverse web sources. " +
    "Supports pagination, content filtering, and freshness controls. " +
    "Maximum 20 results per request, with offset for pagination. ",
  inputSchema: {
    type: "object",
    properties: {
      query: {
        type: "string",
        description: "Search query (max 400 chars, 50 words)"
      },
      count: {
        type: "number",
        description: "Number of results (1-20, default 10)",
        default: 10
      },
      offset: {
        type: "number",
        description: "Pagination offset (max 9, default 0)",
        default: 0
      },
    },
    required: ["query"],
  },
};

const LOCAL_SEARCH_TOOL: Tool = {
  name: "brave_local_search",
  description:
    "Searches for local businesses and places using Brave's Local Search API. " +
    "Best for queries related to physical locations, businesses, restaurants, services, etc. " +
    "Returns detailed information including:\n" +
    "- Business names and addresses\n" +
    "- Ratings and review counts\n" +
    "- Phone numbers and opening hours\n" +
    "Use this when the query implies 'near me' or mentions specific locations. " +
    "Automatically falls back to web search if no local results are found.",
  inputSchema: {
    type: "object",
    properties: {
      query: {
        type: "string",
        description: "Local search query (e.g. 'pizza near Central Park')"
      },
      count: {
        type: "number",
        description: "Number of results (1-20, default 5)",
        default: 5
      },
    },
    required: ["query"]
  }
};

各ツールの定義には、以下の要素が含まれています。

要素 目的 例
name ツールの一意識別子 brave_web_search
description ツールの詳細な説明 Braveウェブ検索の機能説明
inputSchema JSONスキーマ形式での引数定義 クエリや結果数などのパラメータ定義

ここでの実装上の工夫点として、以下が挙げられます。

  1. 詳細な説明文 - LLMがツールを適切に選択できるよう、用途や機能制限を詳しく記述しています
  2. マークダウン形式の使用 - 箇条書きを使って情報を整理し、読みやすくしています
  3. デフォルト値の提供 - 任意パラメータにはデフォルト値を設定し、ユーザーの入力を簡素化しています

6.2.2. サーバーの初期化

次に、MCPサーバーを初期化する部分を見てみましょう。

// Server implementation
const server = new Server(
  {
    name: "example-servers/brave-search",
    version: "0.1.0",
  },
  {
    capabilities: {
      tools: {},
    },
  },
);

// Check for API key
const BRAVE_API_KEY = process.env.BRAVE_API_KEY!;
if (!BRAVE_API_KEY) {
  console.error("Error: BRAVE_API_KEY environment variable is required");
  process.exit(1);
}

const RATE_LIMIT = {
  perSecond: 1,
  perMonth: 15000
};

let requestCount = {
  second: 0,
  month: 0,
  lastReset: Date.now()
};

function checkRateLimit() {
  const now = Date.now();
  if (now - requestCount.lastReset > 1000) {
    requestCount.second = 0;
    requestCount.lastReset = now;
  }
  if (requestCount.second >= RATE_LIMIT.perSecond ||
    requestCount.month >= RATE_LIMIT.perMonth) {
    throw new Error('Rate limit exceeded');
  }
  requestCount.second++;
  requestCount.month++;
}

このコードでは、以下のことを行っています。

  1. MCPサーバーのインスタンスを作成し、サーバー情報と機能を定義
  2. 環境変数からBrave Search APIキーを取得し、存在チェック
  3. APIの利用制限（レートリミット）を定義
  4. レートリミットをチェックする関数を実装

サーバーの初期化時には、サーバー名とバージョン、対応する機能（capabilities）を指定します。このサーバーは「tools」機能のみをサポートしていることを宣言しています。

6.2.3. API通信の実装

次に、Brave SearchのAPIとの通信を実装している部分を見てみましょう。

async function performWebSearch(query: string, count: number = 10, offset: number = 0) {
  checkRateLimit();
  const url = new URL('https://api.search.brave.com/res/v1/web/search');
  url.searchParams.set('q', query);
  url.searchParams.set('count', Math.min(count, 20).toString()); // API limit
  url.searchParams.set('offset', offset.toString());

  const response = await fetch(url, {
    headers: {
      'Accept': 'application/json',
      'Accept-Encoding': 'gzip',
      'X-Subscription-Token': BRAVE_API_KEY
    }
  });

  if (!response.ok) {
    throw new Error(`Brave API error: ${response.status} ${response.statusText}\n${await response.text()}`);
  }

  const data = await response.json() as BraveWeb;

  // Extract just web results
  const results = (data.web?.results || []).map(result => ({
    title: result.title || '',
    description: result.description || '',
    url: result.url || ''
  }));

  return results.map(r =>
    `Title: ${r.title}\nDescription: ${r.description}\nURL: ${r.url}`
  ).join('\n\n');
}

この関数は、Brave Search APIを使用してWeb検索を実行します。実装のポイントは以下の通りです。

  1. API制限の尊重 - リクエスト前にレートリミットをチェック
  2. パラメータのバリデーション - 上限チェック（Math.min(count, 20)）
  3. 適切なエラーハンドリング - HTTPステータスコードの確認とエラーメッセージの生成
  4. レスポンス整形 - 結果を整理して読みやすいフォーマットに変換
  5. 堅牢なデータ処理 - Optional Chainingと空値チェックによる堅牢性の確保

同様に、より複雑なローカル検索（位置情報検索）のAPI通信も実装されています。こちらは複数のAPIエンドポイントを呼び出し、結果を組み合わせる処理を含んでいます。

6.2.4. リクエストハンドラーの設定

MCPサーバーがクライアントからのリクエストに応答するために、リクエストハンドラーを設定します。

// Tool handlers
server.setRequestHandler(ListToolsRequestSchema, async () => ({
  tools: [WEB_SEARCH_TOOL, LOCAL_SEARCH_TOOL],
}));

server.setRequestHandler(CallToolRequestSchema, async (request) => {
  try {
    const { name, arguments: args } = request.params;

    if (!args) {
      throw new Error("No arguments provided");
    }

    switch (name) {
      case "brave_web_search": {
        if (!isBraveWebSearchArgs(args)) {
          throw new Error("Invalid arguments for brave_web_search");
        }
        const { query, count = 10 } = args;
        const results = await performWebSearch(query, count);
        return {
          content: [{ type: "text", text: results }],
          isError: false,
        };
      }

      case "brave_local_search": {
        if (!isBraveLocalSearchArgs(args)) {
          throw new Error("Invalid arguments for brave_local_search");
        }
        const { query, count = 5 } = args;
        const results = await performLocalSearch(query, count);
        return {
          content: [{ type: "text", text: results }],
          isError: false,
        };
      }

      default:
        return {
          content: [{ type: "text", text: `Unknown tool: ${name}` }],
          isError: true,
        };
    }
  } catch (error) {
    return {
      content: [
        {
          type: "text",
          text: `Error: ${error instanceof Error ? error.message : String(error)}`,
        },
      ],
      isError: true,
    };
  }
});

このコードでは、2種類のリクエストハンドラーを設定しています。

  1. ツール一覧ハンドラー (ListToolsRequestSchema)

    • サーバーが提供する全ツールのリストを返す
    • MCP規約に従って、tools配列を含むレスポンスを生成

  2. ツール呼び出しハンドラー (CallToolRequestSchema)

    • リクエストからツール名と引数を取得
    • 引数の存在確認と型チェック
    • 適切なツール実行関数への振り分け
    • エラーハンドリングとMCP形式のレスポンス生成

6.2.5. サーバーの起動

最後に、サーバーを起動する部分を見てみましょう。

async function runServer() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
  console.error("Brave Search MCP Server running on stdio");
}

runServer().catch((error) => {
  console.error("Fatal error running server:", error);
  process.exit(1);
});

このコードでは以下の処理を行っていることが読み取れます。

  1. StdioServerTransportを使用して、標準入出力経由で通信するトランスポートを作成
  2. トランスポートをサーバーに接続
  3. サーバー起動メッセージをログに出力
  4. エラーハンドリングを設定（致命的エラー時に適切に終了）

MCPサーバーの起動は非常にシンプルです。SDKがプロトコルの複雑さを抽象化しているため、トランスポートの選択と接続だけで済みます。本実装では標準入出力（stdio）を使用していますが、必要に応じてHTTPトランスポートに変更することも可能です。

6.3. MCPフロー全体の解説

このサーバーを通じたMCPフローの全体像を見てみましょう。

この図はMCPを使った検索機能の全体フローを示しています。

  1. 初期化フェーズ

    • ユーザーがIDEでスラッシュコマンドを入力
    • MCPホストがサーバーと初期化・機能交渉を行う
    • ホストがサーバーからツール一覧を取得

  2. 実行フェーズ

    • ユーザーがツール（brave_web_search）を選択
    • ホストがサーバーにツール呼び出しリクエストを送信
    • サーバーが外部APIを呼び出し、結果を取得
    • サーバーが結果を整形してホストに返す
    • IDEが結果をユーザーの文脈に挿入

6.4. 実装のポイントと学び

なんか意外と実装できそう？と思えてきましたね。

7. MCPの将来と展望

私たちはこれまで、Model Context Protocol（MCP）の概念、アーキテクチャ、機能、そして実装について詳しく見てきました。この最終章では、MCPの将来像と、AIツールの統合に与える潜在的な影響について展望します。

7.1. プロトコルの進化予測

MCPはまだ比較的新しいプロトコルですが、その設計原則と拡張性から、今後どのように進化していくかを予測することができます。

7.1.1. 標準化の進展

MCPは現在、オープンスタンダードとして進化の初期段階にあります。今後数年間で、以下のような発展が予想されます。

段階 特徴 時期
初期採用期 先進的な開発者やツールが採用
実装の試行錯誤
フィードバックループの確立		 現在～1年以内
主流化期 主要IDEやツールチェーンへの組み込み
サードパーティサーバーの増加
デファクトスタンダード化		 1～2年
成熟期 企業環境での広範な採用
豊かなエコシステムの形成
公式標準化の可能性		 2～3年

この進化の過程で、プロトコル自体も機能拡張や改良が行われるでしょう。現在のプロトコル仕様は、将来の拡張性を念頭に置いて設計されています。実際のユースケースからのフィードバックに基づいて、既存の機能が強化され、新しい機能が追加されていくことが予想されます。

7.1.2. 技術的な進化の方向性

MCPの将来的な技術進化は、以下の方向に向かう可能性があります。

  1. マルチモーダル対応の強化

    現在のMCPは、テキスト、画像、音声などの基本的なマルチモーダルコンテンツをサポートしています。しかし、AIモデルの能力が進化するにつれて、より高度なマルチモーダル相互作用が求められるようになるでしょう。3Dデータ、インタラクティブコンテンツ、リアルタイムストリーミングなどのサポートが追加される可能性があります。

    例えば、以下のような拡張が考えられます。

    // 将来的な3D/ARコンテンツのサポート例
{
  "type": "3d_scene",
  "format": "glb",
  "data": "base64-encoded-data",
  "interaction": {
    "allowNavigation": true,
    "highlightObjects": ["object1", "object2"]
  }
}

  2. リアルタイム協調機能

    現在のMCPは、主に要求-応答パターンに基づいています。将来的には、複数のAIエージェントが協力して問題を解決するための協調プロトコルが追加される可能性があります。これにより、専門知識を持つ複数のAIサービスが協力して、より複雑なタスクを解決できるようになります。

  3. セキュリティとプライバシーの強化

    AIの活用が企業やプライバシーに敏感な領域に拡大するにつれて、MCPにもより強力なセキュリティ機能が求められるようになるでしょう。暗号化通信、アクセス制御、監査ログなどの機能が標準化される可能性があります。

    想定される機能には以下のようなものがあります。

    • エンドツーエンドの暗号化通信
    • 細粒度のアクセス権限制御
    • サーバーの署名と検証メカニズム
    • データの使用目的と保持ポリシーの宣言
    • プライバシー保護処理（匿名化、サニタイゼーション）

  4. 機能ネゴシエーションの高度化

    現在のMCPでは、機能のサポート有無を示す単純な機能ネゴシエーションがサポートされています。将来的には、より詳細なバージョン互換性や部分的機能サポートなど、より柔軟な機能ネゴシエーションが導入される可能性があります。

    // 将来的な機能ネゴシエーションの例
{
  "capabilities": {
    "tools": {
      "version": "2.0",
      "features": {
        "streaming": {
          "supported": true,
          "modes": ["incremental", "chunked"]
        },
        "cancellation": {
          "supported": true,
          "timeout": 30000
        }
      }
    }
  }
}

7.2. AIツールエコシステムへの影響

MCPの普及は、AIツールのエコシステム全体に広範な影響を与える可能性があります。その影響は技術的側面だけでなく、ビジネスモデルやユーザー体験にも及ぶでしょう。

7.2.1. エコシステムの多様化と専門化

特定のAIプロバイダーに依存しない標準プロトコルが普及することで、以下のような変化が予想されます。

  1. 専門化されたAIサービスの増加

    MCPを通じて様々なAIサービスに接続できるようになると、特定の領域に特化した専門的なAIサービスが増えていくでしょう。例えば、法律文書分析、科学論文の検索と要約、特定業界向けの専門知識を提供するAIサービスなどが考えられます。これらのサービスは、自社でLLMを開発・運用する必要なく、MCPを通じて既存のLLMとシームレスに統合できます。

  2. スモールプレイヤーの参入障壁低下

    現在のAI市場は、主要なプロバイダー（OpenAI、Anthropic、Google、Microsoftなど）が大きなシェアを占めています。MCPの標準化により、小規模な企業やスタートアップでも、特定の分野に特化したAIツールやサービスを提供して市場参入することが容易になるでしょう。これは、エコシステムの多様性と革新を促進します。

  3. AIツールのマーケットプレイス形成

    MCPの普及に伴い、多様なAIツールやサービスを提供するマーケットプレイスが形成される可能性があります。ユーザーは自分のニーズに合わせて様々なAIツールを選び、MCPを通じて自分の環境に統合できるようになるでしょう。

7.2.2. ビジネスモデルの変化

MCPは、AIサービスのビジネスモデルにも影響を与えるでしょう。

  1. 価値創出の分散化

    現在のAIサービスでは、大規模なLLMプロバイダーが価値の大部分を創出しています。MCPを通じた統合が進むと、価値創出が分散化し、特定の領域に特化したAIサービスやツールがより大きな役割を果たすようになるでしょう。

  2. API経済からプロトコル経済へ

    現在のAIサービスは主にAPIベースのビジネスモデルに依存していますが、MCPの普及により、より広範なプロトコルベースのエコシステムが形成される可能性があります。これは、APIプロバイダーから特定のサービスを購入するのではなく、共通プロトコルを通じて様々なサービスにアクセスする形態への移行を意味します。

  3. オープンソースモデルとの統合

    MCPはオープンソースのLLMとの統合も容易になります。企業は自社のニーズに応じて、商用APIと自社ホスティングのオープンソースモデルを併用する「ハイブリッドAI戦略」を採用しやすくなるでしょう。

7.3. 開発者/企業が今すべきこと

MCPの発展に備えて、開発者や企業が今から取り組むべきことを考えてみましょう。

7.3.1. 開発者向けの推奨事項

  1. MCPプロトコルの学習と実験

    開発者は、MCPの基本概念と実装方法を学び、小規模なプロジェクトでの実験から始めることが推奨されます。この記事で紹介したリファレンス実装や公式ドキュメントを参照して、MCPサーバーの構築方法を理解しましょう。

  2. 既存ツールのMCP対応化の検討

    既存のツールやAPIを持つ開発者は、それらをMCPサーバーとして公開することを検討すべきです。これにより、ツールの利用範囲が拡大し、新たなユーザー層にアクセスできる可能性があります。

    // 既存APIをMCPサーバーとして公開する例
import { Server } from "@modelcontextprotocol/sdk/server";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio";
import { CallToolRequestSchema, ListToolsRequestSchema, Tool } from "@modelcontextprotocol/sdk/types";

const server = new Server(
  {
    name: "my-existing-api",
    version: "1.0.0",
  },
  {
    capabilities: {
      tools: {},
    },
  }
);

// 既存APIをMCPツールとして定義
server.setRequestHandler(ListToolsRequestSchema, async () => ({
  tools: [
    {
      name: "my_api_function",
      description: "Calls my existing API function",
      inputSchema: {
        // 既存APIのパラメータに対応するスキーマ
      }
    }
  ]
}));

server.setRequestHandler(CallToolRequestSchema, async (request) => {
  // 既存APIの呼び出しロジックをここに実装
});

  3. 複合的なツール連携の設計

    MCPの強みは複数のツールやサービスの連携にあります。開発者は、単独のツールだけでなく、複数のツールを組み合わせたワークフローを設計することで、より高度な価値を提供できるでしょう。

7.3.2. 企業向けの推奨事項

  1. 社内AIツール統合戦略の策定

    企業は、社内で使用するAIツールや独自開発したAI機能の統合戦略を検討すべきです。MCPを中心とした統合フレームワークを採用することで、将来的なベンダーロックインのリスクを低減し、柔軟な拡張が可能になります。

  2. プライバシーとセキュリティポリシーの確立

    AIツールの統合に際して、プライバシーとセキュリティを確保するためのポリシーを確立することが重要です。MCPの分離アーキテクチャを活用して、センシティブなデータへのアクセスを制御し、必要な情報のみをAIツールに提供する仕組みを設計しましょう。

  3. パイロットプロジェクトの実施

    MCPを全社的に導入する前に、特定の部門や限定されたユーザーグループでパイロットプロジェクトを実施することが推奨されます。これにより、導入に伴う課題の洗い出しと、組織に適した導入戦略の策定が可能になります。

7.4. 標準化の今後

MCPの標準化プロセスは、技術的な側面だけでなく、業界全体の協力と合意形成も必要とします。今後の標準化の展望について考えてみましょう。

7.4.1. 標準化のマイルストーン

MCPの標準化は、以下のようなマイルストーンを経て進展する可能性があります。

マイルストーン 内容 重要性
参照実装の充実 様々なユースケースに対応した参照実装の拡充 実装の一貫性確保と採用促進
テストスイートの整備 互換性の検証のためのテストツールの開発 相互運用性の保証
業界グループの形成 MCPの発展を主導する業界団体の設立 継続的な発展と管理の体制確立
ISO/IECなどの公式標準化 国際標準化機関による認定 企業採用の正当性確保

7.4.2. 将来像：インテリジェントコンピューティングの共通言語として

長期的には、MCPはAIツールの統合を超えて、様々な「インテリジェントコンピューティング」コンポーネント間の標準的な通信プロトコルとなる可能性があります。

このビジョンでは、MCPは言語処理、マルチモーダル認識、データシステム、物理世界とのインターフェースなど、多様なインテリジェントシステムコンポーネント間の情報交換を可能にする「共通言語」として機能します。これにより、様々な技術が連携して、より高度で統合されたAIエコシステムが形成されるでしょう。

8. 結論：MCPがもたらす可能性

MCPは、単なる技術的なプロトコルを超えて、AIツールのエコシステム全体の変革をもたらす可能性を秘めています。標準化された方法でコンテキストと機能を交換できるようになることで、より多様で特化したAIツールの発展が促進され、ユーザーはより柔軟にそれらのツールを組み合わせて活用できるようになるでしょう。

開発者や企業がMCPの可能性を理解し、早期から採用を検討することで、AIツールの統合に関する多くの現在の課題を解決し、より効果的なAIの活用が可能になります。MCPが目指す「AIのための共通言語」という理念が実現すれば、AIが私たちの生活や仕事により自然に、そしてシームレスに統合される未来が近づくでしょう。

9. 参考文献

39

Discussion

ログインするとコメントできます