MCP(The Model Context Protocol) を理解する - Part1: 概要編

Weights & Biases AI Solution Engineerの鎌田(X: olachinkei)です。MCP(The Model Context Protocol)が業界標準になってきましたね。2025/3/27にはOpenAIもMCPのサポートをリリースしました。

MCPは、大規模言語モデル（LLM）を活用したアプリケーションが、外部のツール、構造化されたデータ、事前定義されたプロンプトと効率的にやり取りするためのオープンな標準規格です。MCPは統一されたインターフェースを提供することで、これまで個別に作り込まれていた非効率な連携処理を不要にし、AIシステムが外部リソースをスムーズに呼び出して利用できるようにします。

従来のLLMアプリケーションでは、外部情報を取得するためにその都度個別の接続方法が使われていました。そのため、開発工数が増えたり、アプリごとの仕様がバラバラになったり、他システムとの連携が困難になったりしていました。MCPは、このような問題を解決するための標準化されたプロトコルを提供します。これにより複数のAIアプリケーションが、外部のデータ取得やタスク実行のための共通のインフラを共有できるようになります。

MCPは、Anthropicが2024年11月に導入した規格で、AIシステムがそれぞれ孤立してしまう問題を打破し、LLMがリアルタイムのコンテキストを安全に取得し、外部システムと簡単に連携できるよう設計されました。MCPは、AIアプリケーションにとっての「USBポート」のようなもので、あらゆるLLMベースのアシスタントが、データソースやAPI、外部ツールなどに対して、サービスごとに個別のコードを書かずに簡単に接続できるようにします。

この記事では、MCPがどのように機能するかを解説し、Claude Desktopに接続するためのMCPサーバーの具体的な構築手順を紹介します！なお、この記事は、Weights & Biases英文記事「The Model Context Protocol (MCP): A guide for AI integration」を元に作成しています。

MCPとは？

LLMを使ったアプリケーション（チャットボットなど）は、正確で動的な回答を生成するために、外部のリソースに依存していることがよくあります。こうしたリソースは、次の3つの基本要素に分類することができます。

• ツール（Tools）：データベースへの問い合わせやメール送信のような「アクション（行動）」をLLMが実行できるようにするものです。

• リソース（Resources）：文書やログ、APIの応答などの構造化された情報を提供し、モデルが回答を生成するときに参照できるようにするものです。

• プロンプト（Prompts）：事前に用意されたテンプレートで、対話の流れを導き、一貫性と効率性を保つために使われます。

このような外部リソースにアクセスするための標準化された仕組みがない場合、それぞれのLLMアプリケーションは独自の方法で外部機能を統合しなければなりません。そのため、開発が複雑になり、無駄な重複作業が生まれてしまいます。そこで、MCPは、LLMアプリケーションが外部リソースとやり取りするための統一されたプロトコル（規格）を提供しています。複数のLLMアプリケーションがMCPを採用すれば、すべてのアプリケーションが同じインフラを通じてツールやリソース、プロンプトに接続できるため、AIを使ったアプリケーション同士の相互運用性が格段に向上します。

MCPのアーキテクチャは、クライアント・サーバーモデルを採用しており、LLMアプリケーションと外部データソースの間で構造化された、状況に応じたやり取りを可能にします。従来のAPI統合のように、関数呼び出しやデータベースクエリに直接依存するのではなく、MCPではインフラを「ホスト」「クライアント」「サーバー」の3つの役割に分け、それぞれがデータ交換を円滑にするための明確な役割を持っています。

• ホスト（Host）
  ホストとは、チャットボットやIDEアシスタントなど、LLMを組み込んだアプリケーションのことです。ホストはデータ取得や実行処理を直接管理するのではなく、それらをクライアントに任せます。ホストは、いつ外部リソースに問い合わせを行うか、ツールを実行するか、または構造化されたプロンプトを使用するかを決定する役割を持っています。

• クライアント（Client）
  クライアントはホストとMCPが提供する外部リソースの間に立ち、データの流れやツールの実行を管理する仲介役です。例えばClaude Desktopでは、MCPクライアントが関連する文書やAPIの結果、データベースのレコードといったコンテキストを選択し、LLMのコンテキストウィンドウに注入します。また、ツールの呼び出しを適切にルーティングし、モデルが要求した処理が正しく実行されるようにします。

• サーバー（Server）
  サーバーは、リソース（構造化データ）、ツール（外部アクション）、プロンプト（標準化されたインタラクションテンプレート）へのアクセスを提供します。例えば、MCPサーバーは、LLMがローカルファイルシステムにアクセスできるようにする仕組みや、クラウド上のリアルタイム金融データ取得サービス、業務アプリケーションを通じたワークフロー自動化機能などを提供することができます。サーバーは複雑なクエリを必要とせず、必要なときに構造化された形式で情報を提供する役割を担います。

MCPはこのように役割ごとに処理を明確に分離することで、LLMの統合において抽象化のレイヤーを提供し、複雑さを軽減します。個々のアプリケーションがデータ取得や外部アクションのための独自ロジックを実装する必要がなくなり、異なるツールや環境にまたがった拡張が容易になります。また、この役割分離により、クライアント側でアクセス制限を適切に行ったり、LLMに必要な情報だけを提供したりすることが可能になるため、セキュリティや制御性も向上します。

MCPのプリミティブ（基本要素）

MCPでは、クライアントとサーバーがやり取りする際の構造を決めるためのいくつかの「プリミティブ（基本要素）」を定義しています。この記事では主にサーバー側の使い方について説明していますが、まずは簡単にクライアント側の重要な要素を紹介します。

クライアント側のプリミティブ：

• ルート（Roots）
  Rootsは、どのファイルやデータベース、サービスにMCPサーバーがアクセスできるかを制限し、管理する入り口のような役割を果たします。これにより、アプリケーションが必要なデータソースだけを提供し、LLMがアクセス可能な情報を安全かつ適切に管理できます。

• サンプリング（Sampling）
  Samplingは繰り返し型の応答生成を可能にします。一度だけ静的な回答を生成するのではなく、MCPクライアントは複数回の生成を行い、その都度追加のコンテキストや条件によって回答を洗練させます。これにより、応答の質や柔軟性、関連性が向上します。

サーバー側のプリミティブ：

サーバー側では、MCPは主に以下の3つのプリミティブを導入しています。これらによりLLMアプリケーションが外部システムと構造的で予測可能な方法でやり取りできるようになります。

• ツール（Tools）
  ツールはLLMが外部の機能を実行するための仕組みで、テキストだけの処理を超えたアクションを可能にする主要な手段です。単にデータを提供するだけの「リソース」や、対話を構造化する「プロンプト」と異なり、ツールを使えばリアルタイムのデータ取得やデータベースの更新、計算処理の実行ができます。例えば、LLMベースのコーディングアシスタントがテストケースを実行したり、カスタマーサポート用チャットボットが新規チケットを作成したりする場合は、ツールを利用します。ツールはシステムに実際の影響を与えるため、AIアプリケーションの機能を広げる役割を果たします。

• リソース（Resources）
  リソースは、ファイル、ログ、APIからの応答など、LLMが回答生成時に参照可能な構造化されたデータを提供します。リソースはツールと違い、外部の処理を引き起こしません。その代わり、モデルのコンテキスト内にスムーズに統合される情報を提供し、最新かつ一貫した情報へのアクセスを容易にします。例えば財務レポートやシステムのログなどをリソースとして提供すると、モデルの回答内容に自然に影響を与えることができます。

• プロンプト（Prompts）
  プロンプトは外部のアクションを引き起こさずに、対話をあらかじめ決められたテンプレートで構造化する役割を持っています。「空欄を埋める」テンプレートのような仕組みで、特定のタスクにおいて一貫性を保つための枠組みを提供します。例えば要約のプロンプトには、あらかじめ決まった指示があり、その中にユーザーの入力が入る仕組みです。また、チャットボットの性格や話し方、振る舞いを動的に指定することも可能で、外部システムに変更を加えなくてもモデルの応答の方向性を調整できます。

これらのプリミティブを標準化することによって、MCPはLLMを活用したアプリケーションが外部ツールやデータソースと効率よく、安全かつ予測可能な方法で相互作用できるようにしています。

全体の動作イメージ（Putting it all together）

MCPを使ったアプリケーションが、ユーザーの質問に対して外部データや処理が必要な場合、具体的には次のような手順で動作します。

① 機能の発見（Capability discovery）
MCPクライアントがまずサーバーに「どのようなツール、リソース、プロンプトが使えるのか」を問い合わせます。この結果、AIモデル（ホスト側のアプリ経由）はサーバーが提供できる機能を把握します。

② プロンプト拡張（Augmented prompting）
ユーザーの質問とその周辺情報が、サーバーから得られたツールやリソースの説明と共にAIモデルに送られます。これによりモデルは「サーバー経由でどのようなことが可能か」を認識します。例えば「明日の天気は？」という質問があれば、「Weather APIツール」の説明がプロンプトに含まれます。

③ ツール・リソースの選択（Tool/resource selection）
AIモデルは質問と利用可能なツールやリソースを分析し、それらの使用が必要かどうかを判断します。必要と判断した場合、MCP仕様に基づいて、どのツールやリソースを使いたいかを構造化された形で返します。例えば天気の例であれば、「Weather API」の呼び出しを選択します。

④ サーバーでの実行（Server execution）
MCPクライアントがモデルのリクエストを受け取り、MCPサーバーの該当する機能を呼び出します（例：Weather APIの実行）。サーバーが実際に外部APIやデータベースを呼び出し、その結果をクライアントに返します。

⑤ 回答生成（Response generation）
サーバーから得られた結果（天気情報など）がクライアントを通じてAIモデルに渡され、モデルはそのデータを自身の回答に組み込みます。最終的にユーザーには「明日の天気は15度、弱い雨の予報です」のような外部情報を活用した回答が返されます。

こうした一連の流れは、実際にはクライアントとサーバー間のJSONメッセージのやり取りで実現されていますが、MCPは開発者がその詳細を気にしなくてよいように抽象化しています。開発者は単にMCP仕様に従ってサーバーを実装（または既存のサーバーを利用）し、それに対応したクライアントを備えたAIアプリを用意するだけで済みます。Anthropicは開発を簡単にするため、Python、TypeScript、Java/Kotlinなど複数言語のSDKを提供しています。例えば独自のSQLデータベース用コネクターの開発も、小さなMCPサーバーを実装するだけで可能になります。複雑な通信処理はMCPのプロトコルが引き受けてくれるため、開発者はサーバーが提供する機能を定義することに集中できます。

MCPが単なるインターフェースではない理由：従来の課題への独自の解決策

MCPの最大の強みは、AIのワークフローに自然に溶け込む設計にあります。これは、もともとLLMエージェントが情報を取得し、推論し、行動を実行する仕組みに最適化されているためです。また、MCPは標準規格であるため、AIとの連携をコミュニティ主導で進めることができます。開発者がMCPに対応したツールやデータソースを一度作れば、同じ規格に従うあらゆるAIシステムで即座に利用可能になるのです。これは、従来のAPI連携とは大きく異なります。これまではAIツールごとに、外部サービスとの連携を個別にカスタム構築する必要がありました。

MCPは、AIアプリケーションが外部データやツールとやり取りする方法を統一することで、開発作業の重複をなくします。個別に何度も同じような連携機能をゼロから作る必要がなくなり、開発者は共有されたエコシステムの一員として、すでに構築済みの再利用可能なコンポーネントを活用できるようになります。

従来のAPIベースの統合では、開発者は連携したい外部システムごとに個別のコネクターを構築しなければなりませんでした。また、サービスごとにAPIの設計が異なるため、それぞれで認証処理、リクエスト形式、エラー処理などを個別に作り込む必要があります。その結果、統合ソリューションは個々のサービスごとにバラバラに作られ、他のAIアプリケーションでは再利用が困難でした。

MCPは、こうした非効率さを解消するために、AIモデルが外部ツールやデータとやり取りする方法を標準化しています。開発者は新しいシステムと接続するためのコードをその都度書く必要がなくなり、代わりにMCP互換のツールが豊富に揃ったエコシステムを利用できます。一度AIシステムがMCPに対応すれば、同じ規格に準拠したどのサービスともすぐに連携可能になり、追加のカスタムコードは不要になります。

MCPの概要についてみてきました。実際の実装イメージがあるとより深く理解できると思うので、次のブログ「MCP(The Model Context Protocol) を理解する - Part2: 実装編」では実装した例を見ていきます。

採用情報

W&Bでは、AIカスタマーサポートエンジニアを募集しています！ご関心のある方は是非、W&B AIソリューションエンジニア鎌田  (keisuke.kamata@wandb.com) までご連絡ください！