開発者向けModel Context Protocol (MCP)ガイド


AI開発の状況は、スタンドアロンの対話型モデルから、世界と対話できる洗練されたエージェントシステムへと急速に進化しています。この進化における重大なボトルネックは、AIが外部のデータ、ツール、サービスにアクセスするための標準化された方法がなかったことでした。Model Context Protocol (MCP)は、まさにこの問題を解決するために設計されたオープンソースの標準であり、大規模言語モデル（LLM）が複雑なマルチステップのタスクを実行するために必要なコンテキストに接続するための普遍的な言語を提供します。

開発者にとって、MCPはパラダイムシフトを意味します。特注の、一度きりの統合を超えて、強力なAIアプリケーションを構築するための再利用可能で、スケーラブルで、安全なアーキテクチャへと移行します。このガイドでは、MCPのコアアーキテクチャ、高度な概念、セキュリティに関する考慮事項、パフォーマンスの最適化、そしてより広範なAIエコシステムにおけるその位置づけについて、包括的な技術的詳細を解説します。

ホスト、クライアント、サーバーが通信しているModel Context Protocolのアーキテクチャを示す図。

MCPとは？「AIのためのUSB-C」

その核心において、Model Context Protocolは、AIアプリケーションが外部システムと安全かつ確実に通信する方法を定義するオープンスタンダードです。これは、AIツーリングの断片化に対処するためにAnthropicによって導入されました。MCP以前は、LLMをGitHubリポジトリやプロジェクト管理ツールのような新しいデータソースに接続するには、特定のアプリケーションごとにカスタムのコネクタコードを書く必要がありました。このアプローチは非効率で、安全でなく、スケーラブルではありません。

IDEの世界でのLanguage Server Protocol (LSP)の成功に触発されたMCPは、統一されたインターフェースを作成します。開発者は、サービス（例：Jira）用に単一の「MCPサーバー」を構築でき、MCP互換の「ホスト」（AI搭載IDEやチャットアプリケーションなど）は即座にそれを使用できます。この「一度構築すれば、どこでも使える」という哲学が、しばしば「AIのためのUSB-C」と呼ばれる理由です。

コアアーキテクチャ：ホスト、クライアント、サーバー

MCPを理解するには、その3つの主要コンポーネントから始めます。このプロトコルは、JSON-RPC 2.0の上に標準のメッセージベースの通信層を定義し、相互作用が構造化され、曖昧さがないことを保証します。

  • MCPホスト： これは、エンドユーザーが対話する主要なAIアプリケーションです。例としては、Visual Studio Code、Claude for Desktop、またはカスタムビルドのAIエージェントが挙げられます。ホストの役割は、ユーザーインターフェースを管理し、LLMを実行し、MCPクライアントが動作するためのサンドボックス環境を提供することです。
  • MCPクライアント： クライアントは、ホスト内に存在するコネクタまたは仲介者として機能します。1つ以上のMCPサーバーを発見し、接続し、通信する責任があります。クライアントは機能の交渉を処理し、ホストとサーバー間のリクエストとレスポンスをルーティングします。
  • MCPサーバー： これはプロトコルの主力です。MCPサーバーは、外部のデータと機能をMCPホストに公開するスタンドアロンのプロセスまたはサービスです。たとえば、課題を作成するためのツールを公開するGitHub MCPサーバー、リソース（ファイル）を提供するGoogle Driveサーバー、または会社の内部データベースに接続するカスタムサーバーを持つことができます。

このアーキテクチャは、明確なシステム境界を作成します。ホストはサーバーと直接通信することはなく、すべての相互作用はクライアントによって仲介され、クライアントはセキュリティと同意のゲートキーパーとして機能できます。

詳細解説：MCPサーバーの機能

公式MCP仕様で定義されているように、MCPサーバーはクライアントにいくつかのタイプの機能を提供できます。このモジュール性により、開発者は必要な機能を正確に公開できます。

1. ツール (Tools)

ツールは、AIモデルがアクションを実行するために呼び出すことができる実行可能な関数です。これは、エージェント的なワークフローを作成するための最も強力な機能です。ツールは、名前、人間が読める説明、および入力パラメータのJSONスキーマで定義されます。

  • 仕組み： ホストのLLMは、ツールの説明を使用して、ユーザーの要求を満たすためにどの関数を呼び出すかを推論します。たとえば、ユーザーが「ログイン失敗についてトラッカーにバグレポートを作成して」と言った場合、LLMはJira MCPサーバーからcreate_issueツールを特定し、必要なパラメータ（title、description）を抽出し、その実行を要求できます。
  • セキュリティ： ユーザーの同意は中心的な原則です。ホストは、ツールが実行される前に、特に書き込み操作を実行したり機密データを扱ったりするツールについては、ユーザーの明示的な承認を得る必要があります。

2. リソース (Resources)

リソースは、LLMに提供できるファイルのようなデータまたはコンテキストを表します。これは、ローカルディスク上のファイルの内容、Google Driveのドキュメント、データベーススキーマ、API呼び出しの出力など、何でもかまいません。

  • 仕組み： リソースにより、LLMは通常アクセスできないデータを「見る」ことができます。開発者は、file_system MCPサーバーを使用して、特定のソースコードファイルの内容をモデルに提供し、コードのリファクタリングを依頼することができます。リソースはコンテキストとして提供され、ユーザーが手動でコピー＆ペーストする必要なくプロンプトを充実させます。

3. プロンプト (Prompts)

プロンプトは、ユーザーがスラッシュコマンド（例：/generateApiRoute）を介して呼び出すことができる、事前定義された再利用可能なテンプレートです。これらは、対話のための構造化された開始点を提供することにより、一般的なタスクを効率化します。

  • 仕組み： サーバーは、filePathをパラメータとして取るperformSecurityReviewのようなプロンプトを登録できます。ユーザーがそれを呼び出すと、ホストはテンプレートを使用して、ユーザーの入力と事前定義された指示を組み合わせて、LLMへの詳細なリクエストを構築できます。

4. 高度な機能：サンプリング (Sampling)

サンプリングは、MCPサーバーがクライアントにモデルの補完を要求できるようにする高度な機能です。これは通常のフローを逆転させ、サーバーが独自の内部ロジックのためにホストのLLMを活用できるようにし、強力で協調的なマルチエージェントワークフローを作成します。たとえば、サーバーは大きなドキュメントを取得し、サンプリングを使用してLLMに要約を依頼し、その簡潔な要約を最終結果として返すことができます。

最初のMCPサーバーの構築：実践的な例

MCPを理解する最良の方法は、サーバーを構築することです。公式ドキュメントには、TypeScript、Python、C#など、いくつかの言語用のSDKが提供されています。Python SDKを使用して、ツールを公開する簡単なサーバーを構築するプロセスを概説しましょう。

公式クイックスタートガイドでは、天気サーバーの作成を順を追って説明しており、これは優れた出発点です。主な手順は次のとおりです。

  1. 環境のセットアップ： 必要なSDKをインストールします。Pythonの場合、これは通常パッケージマネージャーを介して行われます。

    bash
    # 公式ドキュメントで推奨されているuvを使用
uv pip install "mcp[cli]"

  2. サーバーの初期化： SDKからサーバークラスをインスタンス化します。Python SDKのFastMCPクラスは、型ヒントとdocstringを使用してツール定義を自動的に生成します。

    python
    from mcp.server.fastmcp import FastMCP

# FastMCPサーバーを初期化
mcp = FastMCP("my_awesome_server")

  3. ツールの定義： 関数を作成し、@mcp.tool()でデコレートします。関数のdocstringは、LLMがツールの機能を理解するために使用する説明になるため、非常に重要です。関数のシグネチャと型ヒントは、ツールのパラメータを定義します。

    python
    @mcp.tool()
async def get_github_issue(repo: str, issue_number: int) -> str:
    """
    GitHubリポジトリから特定の課題の詳細を取得します。

    Args:
        repo: 'owner/repo'形式のリポジトリ名。
        issue_number: 取得する課題の番号。
    """
    # GitHub APIを呼び出すロジックはここに記述します。
    # この例では、モックのレスポンスを返します。
    if repo == "owner/repo" and issue_number == 123:
        return "課題123：ログインボタンが機能しません。ステータス：オープン。"
    return f"{repo}に課題{issue_number}が見つかりません。"

  4. サーバーの実行： サーバープロセスを開始するためのエントリポイントを追加します。MCPサーバーは、ローカル実行の場合は標準I/O（stdio）を介して、リモートアクセスの場合はHTTPを介して通信できます。

    python
    if __name__ == "__main__":
    # 標準入出力を介して通信するサーバーを実行
    mcp.run(transport='stdio')

このサーバーが実行されたら、VS CodeやClaude for DesktopなどのMCPホストを構成して接続できます。その後、AIに「owner/repoの課題123のステータスは何ですか？」と尋ねると、AIはインテリジェントにget_github_issueツールを呼び出すことを決定できます。

開発者にとっての重要なセキュリティ上の考慮事項

MCPは安全な対話のためのフレームワークを提供しますが、実装の責任は開発者にあります。プロトコル自体は万能薬ではありません。公式のセキュリティベストプラクティスで詳述されているように、開発者はいくつかの主要なリスクに注意を払う必要があります。

  • 過剰な権限： よくある落とし穴は、MCPサーバーにバックエンドサービスへの過度に広範なアクセス権を付与することです。販売データを読み取るために設計されたサーバーは、企業全体のデータストアへの書き込みアクセス権を持つべきではありません。常に最小権限の原則を遵守し、サーバーの意図された機能に必要な最小限の権限にスコープを限定してください。
  • 間接的なプロンプトインジェクション： 攻撃者は、MCPサーバーが後で取得するデータソース（ドキュメントやデータベースエントリなど）を汚染する可能性があります。このデータに悪意のある指示が含まれている場合、それがLLMに渡され、意図しないアクションを実行させる可能性があります。入力のサニタイズと出力のエンコーディングは、重要な緩和策です。
  • セッションハイジャック： ステートフルなHTTP実装では、攻撃者がセッションIDを取得し、それを使用して正当なユーザーになりすます可能性があります。仕様では、サーバーは認証にセッションを使用してはならず、セッションIDを安全なトークンから派生したユーザー固有の情報にバインドする必要があると規定されています。
  • Confused Deputy問題： この古典的な脆弱性は、MCPサーバーが別のサービスへのプロキシとして機能する場合に発生する可能性があります。攻撃者は、サーバーをだまして、その昇格された権限を使用して不正なアクションを実行させることができます。適切な検証とユーザーの同意フローが不可欠です。

MCPサーバーのパフォーマンス最適化

MCPサーバーは、従来のWeb APIとは異なるパフォーマンス制約の下で動作します。主に、大量の並列リクエストを生成できるAIモデルにサービスを提供します。このユニークなプロファイルに合わせて最適化することは、応答性が高く費用対効果の高いアプリケーションを構築するために重要です。

  • トークン効率が最重要： サーバーから返されるすべての文字が、LLMの貴重なコンテキストウィンドウを消費します。不要なフィールド、長い説明、メタデータを含む冗長なJSONレスポンスは、コンテキストをすぐに使い果たし、モデルの推論能力を低下させる可能性があります。
    • ベストプラクティス： JSONペイロードを必須要素に絞り込みます。AIが現在のタスクに必要なものだけを返します。大規模なデータセットの場合は、オーバーヘッドをなくすためにJSONの代わりに構造化されたプレーンテキストを返すことを検討してください。
  • ツール定義のオーバーヘッドを最小化： 利用可能なすべてのツールの定義は、セッションの開始時にモデルのコンテキストにロードされます。冗長な説明を持つ複雑なスキーマは、ユーザーがプロンプトを入力する前に何千ものトークンを消費する可能性があります。
    • ベストプラクティス： 簡潔で明確なツールの説明を記述します。スキーマ自体に長い説明を埋め込む代わりに、外部ドキュメントへの参照を使用します。
  • 地理的な近接性が重要： ネットワーク遅延は、MCPに典型的な対話型のマルチターンインタラクションで増幅されます。AIプロバイダーのインフラストラクチャから地理的に遠くでホストされているサーバーは、大幅な遅延を引き起こします。
    • ベストプラクティス： ターゲットとするAIモデルの主要なインフラストラクチャに地理的に近いデータセンターでMCPサーバーをホストします（例：AnthropicのClaudeの場合は米国のデータセンター）。

開発者のワークフローにMCPツールがどのように統合されるかを示す、利用可能なMCPツールのリストを表示するコードエディタの画像。

エージェントクライアントとの統合：Jenova

サーバーの構築は戦いの半分ですが、開発者とユーザーはそれらを消費するための強力なクライアントを必要としています。**Jenova**は、MCPエコシステムのためにゼロから構築された最初のAIエージェントです。リモートのMCPサーバーに簡単に接続し、大規模に活用できるエージェントクライアントとして機能します。

MCPサーバーを構築する開発者にとって、Jenovaは完璧なテストおよび展開ターゲットを提供します。エンドユーザーにとっては、プロトコルの可能性を最大限に引き出します。Jenovaはいくつかの主要な分野で優れています。

  • シームレスなサーバー統合： JenovaをリモートのMCPサーバーに接続するだけで、そのツールが複雑なワークフローで即座に利用可能になります。
  • マルチステップのエージェントワークフロー： Jenovaは高レベルの目標を理解し、異なるMCPサーバーのツールを連鎖させることでマルチステップのタスクを計画および実行できます。たとえば、GitHubサーバーを使用して新製品の機能を見つけ、レポートサーバーで要約を生成し、Slackサーバーで製品チームにメッセージを送信することができます。
  • スケーラブルで信頼性の高いツーリング： マルチエージェントアーキテクチャ上に構築されたJenovaは、パフォーマンスを低下させることなく膨大な数のツールをサポートするように設計されています。これにより、Cursorの50ツールという上限のようなツール容量に厳しい制限があるクライアントに対して大きな利点があり、Jenovaはツールを大規模かつ確実に統合するための最も有能なエージェントとなっています。
  • マルチモデルインテリジェンス： Jenovaはモデルに依存せず、GPT-4、Claude 3、Geminiなどの主要なLLMと連携し、ユーザーが常にタスクに最適な結果を得られるようにします。
  • 一般の人々向けに設計： Jenovaは、技術者でないユーザーがカレンダーの招待状を送信したり、ドキュメントを編集したりするなどのタスクでMCPエコシステムの利点を享受できるように構築されています。また、モバイル（iOSおよびAndroid）でもMCPを完全にサポートしています。

より広範なエコシステムにおけるMCP：vs. A2Aおよびフレームワーク

MCPは真空中に存在するわけではありません。他の新しい標準やフレームワークとどのように関連しているかを理解することが重要です。

  • MCP vs. A2A (Agent-to-Agent Protocol)： これらのプロトコルは競合するものではなく、補完的なものです。このLogtoのブログ投稿で説明されているように、MCPは「垂直」統合（エージェントがツールにどのように接続するか）を処理し、GoogleのA2Aプロトコルは「水平」統合（異なるエージェントが互いにどのように通信するか）を処理します。システムは、エージェントがタスクを委任するためにA2Aを使用し、それらの個々のエージェントはタスクを完了するために必要なツールにアクセスするためにMCPを使用するかもしれません。
  • MCP vs. フレームワーク (LangChain, Semantic Kernel)： LangChainやMicrosoftのSemantic Kernelのようなフレームワークは、エージェントロジックを構築するためのものです。これらはMCPホストまたはクライアントを作成するために使用できます。これらのフレームワークは、エコシステム内でMCPサーバーをツールとして消費し、フレームワークのオーケストレーション能力とMCPの標準化された接続性を組み合わせることができます。

未来は構成可能

Model Context Protocolは、単なる別のAPI標準ではありません。次世代のAIソフトウェアの基盤となる層です。AIモデルを使用するツールから切り離すことで、MCPは開発者が強力な機能を構築し共有できる、活気に満ちた相互運用可能なエコシステムを育みます。Jenovaのようなクライアントやサーバーなど、より多くのホストがプロトコルを採用するにつれて、真に構成可能でコンテキストを認識するAIのビジョンが現実のものに近づきます。開発者にとって、今こそこのエキサイティングな新しいフロンティアで構築を始める時です。

出典

  1. Model Context Protocol 公式ウェブサイト: https://modelcontextprotocol.io/
  2. MCP セキュリティベストプラクティス: https://modelcontextprotocol.io/specification/draft/basic/security_best_practices
  3. Protect AI - MCP Security 101: https://protectai.com/blog/mcp-security-101