Anthropic x DeepLearning.AI : MCPを統合したリッチコンテキストAIアプリケーションの構築

Last updated at 2025-05-15Posted at 2025-05-15

MCP: Build Rich-Context AI Apps with Anthropic
https://www.deeplearning.ai/short-courses/mcp-build-rich-context-ai-apps-with-anthropic/

近年、大規模言語モデル (LLM) の進化は目覚ましく、AIアプリケーションの可能性は日々拡大しています。しかし、これらのモデルが真価を発揮するためには、外部のツールやデータリソースとスムーズに連携し、リッチな「コンテキスト (文脈)」を獲得することが不可欠です。ここで注目されるのが Model Context Protocol (MCP) です。

MCPは、AIアプリケーションがツールやデータリソースといった外部コンテキストへアクセスする方法を標準化するオープンプロトコルです。本記事では、MCPの基本概念から具体的な実装、さらには将来の展望に至るまで、体系的に解説していきます。AI開発の効率化と高度化を目指す全ての方にとって、MCPは強力な武器となるでしょう。

Part 1: Model Context Protocol (MCP) とは？
Part 2: MCPのコアコンセプト建築ブロックを理解する 🧱
Part 3: MCPの実装方法 ⚙️
Part 4: ハンズオン: チャットボットとMCPサーバーの構築 🛠️
Part 5: MCP互換アプリケーションとの連携 🤝
- Chapter 5.1: Cloud Desktop との連携
- Chapter 5.2: その他のMCP互換アプリケーション
Part 6: リモートMCPサーバーの展開 ☁️
- Chapter 6.1: リモートサーバー用の設定
- Chapter 6.2: Render を使用したデプロイ
Part 7: MCPの将来と高度な機能 🚀
Part 8: まとめ ✨

Part 1: Model Context Protocol (MCP) とは？

このパートでは、MCPがどのようなもので、なぜ現代のAI開発において重要なのか、その基本的な理解を深めます。

Chapter 1.1: MCPの誕生背景と目的

コアメッセージ: MCPは、AIモデルが外部情報へアクセスする方法を標準化し、開発の複雑さを軽減するために生まれました。

AIモデル、特に大規模言語モデル (LLM) は、提供されるコンテキスト（文脈情報）の質と量によってその性能が大きく左右されます。例えば、最新のニュース記事について要約させたい場合や、特定の社内データベースに基づいてレポートを作成させたい場合、モデルはこれらの外部情報源にアクセスする必要があります。

しかし、従来は各AIアプリケーションや各データソースごとに個別の連携方法を開発する必要があり、これは非常に手間のかかる作業でした。この「車輪の再発明」を避け、より効率的でスケーラブルな開発を実現するために、Model Context Protocol (MCP) が Anthropic 社によって提唱され、オープンソースコミュニティと共に開発が進められています。

MCPの主な目的は、AIアプリケーションがツールやデータリソースといった外部コンテキストへアクセスするための標準的な方法を提供することです。これにより、開発者は連携の詳細な実装に煩わされることなく、アプリケーションのコア機能の開発に集中できるようになる可能性があります。

Chapter 1.2: MCPが解決する課題

コアメッセージ: MCPは、AI開発における「コンテキストの断片化」と「連携の非効率性」という課題に取り組んでいます。

AIアプリケーションが多様な外部システム（例: GitHub リポジトリ、Google Drive ドキュメント、ローカルファイルシステム、各種API）と連携しようとすると、以下のような課題に直面することがあります。

コンテキストの断片化: 各システムが異なるインターフェースやデータ形式を持つため、統一的なアクセスが困難です。
連携の非効率性: 新しいデータソースを追加するたびに、専用の連携コードを開発・保守する必要があり、時間とコストがかかります。
モデル間の非互換性: 特定のモデルやプラットフォームに依存した連携方法を採ると、他のモデルへの移行が難しくなります。

MCPは、これらの課題に対し、プロトコルレベルでの標準化というアプローチで応えます。これは、ウェブ開発において HTTP がクライアントとサーバー間の通信を標準化したように、AI開発においても同様の基盤を提供しようとする試みと捉えることができます。Microsoft が開発した LSP (Language Server Protocol) が、異なるIDEと言語ツール間の連携を標準化した事例も、MCPの目指す方向性を示唆しています。

Chapter 1.3: MCPのメリット

コアメッセージ: MCPは、アプリケーション開発者、API開発者、AIアプリケーションのユーザー、そして企業に至るまで、様々な関係者にメリットをもたらす可能性があります。

MCPを導入することで、以下のような利点が期待できます。

アプリケーション開発者にとって:
- 様々なツールやデータソースへの接続が容易になり、開発工数を大幅に削減できる可能性があります。
- 「一度書けば、どこでも使える」連携コンポーネントの恩恵を受けられます。
API開発者 (ツールやデータを提供する側) にとって:
- MCP互換のサーバーを一度構築すれば、多くのAIアプリケーションから利用される機会が広がります。
- APIの利用促進に繋がる可能性があります。
AIアプリケーションのユーザーにとって:
- より多くの外部情報にアクセスできる、高機能なAIアプリケーションを利用できるようになるかもしれません。
- MCPサーバーのURLを指定するだけで、必要なデータアクセス機能がアプリケーションに追加されるといった、シンプルな利用体験が期待できます。
企業や大規模組織にとって:
- 関心事の分離（separation of concerns）が促進され、独立した連携モジュールを構築・共有しやすくなります。
- チーム間での再利用性が高まり、開発リソースの最適化に貢献する可能性があります。

Chapter 1.4: MCPエコシステムの成長

コアメッセージ: MCPエコシステムは、Anthropic社だけでなく、オープンソースコミュニティや多くの企業によって急速に成長しています。

MCPは2024年11月にAnthropic社によって発表されて以来、そのエコシステムは急速に拡大しています。

多様なMCPサーバー: GitHub、Google Drive、Asana、Salesforce、HubSpot といった一般的なサービスから、特定のデータベースやバージョン管理システムに至るまで、様々なデータソースに対応するMCPサーバーが、オープンソースコミュニティやAnthropic社のMCPチームによって開発されています。
多言語対応SDK: Python をはじめ、複数のプログラミング言語に対応したSDK (Software Development Kit) が提供されており、開発者は好みの言語でMCPサーバーやクライアントを構築できます。
MCP互換アプリケーションの増加: ウェブアプリケーション、デスクトップアプリケーション、さらにはエージェント技術を活用した製品など、MCPに対応したアプリケーションも増えつつあります。

このような活発な動きは、MCPがAI開発における重要な標準技術として認識され始めていることを示していると言えるでしょう。

Chapter 1.5: MCPに関するよくある質問

コアメッセージ: MCPサーバーは誰でも開発可能で、APIのラッパーとして機能し、ツール利用以上の多様な機能を提供します。

MCPについて学ぶ中で、いくつかの疑問が浮かぶかもしれません。代表的なものを以下に示します。

Q1: MCPサーバー (例: GitHub用、Asana用) は誰が開発するのですか？
- A1: 誰でも開発できます。開発者自身が特定のニーズに合わせて構築することも、コミュニティによって開発・公開されているものを利用することも可能です。このコースの後半では、実際にMCPサーバーを構築する方法を学びます。
Q2: MCPサーバーはAPIとどう違うのですか？
- A2: MCPサーバーは、既存のAPIに対する一種のゲートウェイやラッパーと考えることができます。APIを直接呼び出す代わりに、自然言語を通じてMCPサーバーに指示を出すことで、サーバーがAPIコールを代行してくれるイメージです。これにより、APIの複雑な仕様を意識することなく、機能を利用できる可能性があります。
Q3: MCPサーバーは、LLMの「ツール利用 (Tool Use)」機能を提供するだけですか？
- A3: ツール利用はMCPサーバーが提供する重要な機能の一つですが、それだけではありません。MCPは、関数とそのスキーマを提供するだけでなく、「リソース」や「プロンプトテンプレート」といった、より多様なコンテキスト提供メカニズムを備えています。これらについては、次のパートで詳しく解説します。

Part 1 まとめ

このパートでは、Model Context Protocol (MCP) の基本的な概念と、それがAI開発にもたらす可能性について概観しました。
MCPは、AIアプリケーションが外部のツールやデータリソースと連携する方法を標準化するオープンプロトコルです。
これにより、開発の断片化を防ぎ、効率性とスケーラビリティを高めることを目指しています。
アプリケーション開発者、API提供者、エンドユーザー、そして企業に至るまで、多くの関係者にメリットをもたらす可能性を秘めており、そのエコシステムは急速に成長しています。

次のパートでは、MCPの心臓部とも言えるコアコンセプト、特にクライアント/サーバーアーキテクチャと、MCPを構成する基本要素（ツール、リソース、プロンプトテンプレート）について詳しく見ていきましょう。

Part 2: MCPのコアコンセプト建築ブロックを理解する 🧱

このパートでは、MCPがどのように機能するのか、その基本的な構造と主要な構成要素について掘り下げていきます。これらの「建築ブロック」を理解することが、MCPを効果的に活用するための第一歩となります。

Chapter 2.1: クライアント/サーバーアーキテクチャ

コアメッセージ: MCPは、クライアントとサーバーが1対1で接続し、定義されたメッセージを通じて通信するクライアント/サーバーアーキテクチャを採用しています。

MCPは、他の多くのプロトコルと同様に、クライアント/サーバーアーキテクチャに基づいています。このモデルでは、主要な登場人物として「ホスト」「クライアント」「サーバー」が存在します。

MCPサーバー (MCP Server):
- 特定のツールやデータリソースへのアクセスを提供する軽量なプログラムです。例えば、SQLite データベースを操作するためのMCPサーバーや、GitHub APIと連携するためのMCPサーバーなどが考えられます。
- サーバーは、プロトコルを通じてその機能を公開します。
MCPクライアント (MCP Client):
- MCPサーバーと1対1の接続を維持し、通信を行います。
- クライアントは、サーバーが公開するツールやリソースを発見し、利用する役割を担います。
ホスト (Host):
- MCPクライアントを内部に保持し、管理するアプリケーションです。Claude Desktop や Claude AI のようなLLMアプリケーションがホストの例として挙げられます。
- ホストは、複数のMCPクライアントを管理し、それぞれが異なるMCPサーバーとの接続を維持することができます。

クライアントとサーバー間の通信は、MCPによって定義されたメッセージ形式で行われます。これにより、異なる開発者や組織によって作られたクライアントとサーバーであっても、標準化された方法で相互運用が可能になります。

このアーキテクチャにより、関心事が明確に分離されます。ホストアプリケーションはMCPクライアントを通じて必要な機能を利用し、MCPサーバーは特定のデータソースやツールへのアクセスロジックをカプセル化します。

Chapter 2.2: MCPの基本要素 (Primitives)

コアメッセージ: MCPは、「ツール」「リソース」「プロンプトテンプレート」という3つの基本的な要素 (Primitives) を通じて、AIアプリケーションにコンテキストを提供します。

MCPプロトコルの中核を成すのは、以下の3つの「基本要素」です。これらは、サーバーがクライアントに対してどのような機能やデータを提供できるかを定義します。

ツール (Tools) 🛠️
- クライアントによって呼び出すことができる関数です。LLMの「ツール利用 (Tool Use)」機能に馴染みがあれば、MCPのツールも同様の概念と理解しやすいでしょう。
- データの取得、検索、メッセージ送信、データベースレコードの更新など、能動的な操作を伴う場合に用いられます。
- 一般的に、HTTPリクエストにおける POST や PUT のような、何らかの変更や処理を伴う操作に適しています。
- 例: 「指定されたリポジトリのIssueを作成するツール」「ユーザー情報をデータベースに登録するツール」
リソース (Resources) 📄
- サーバーによって公開される読み取り専用のデータやコンテキストです。
- アプリケーションはこれらのリソースを利用するかどうかを選択できますが、必ずしもコンテキストに取り込む必要はありません。
- HTTPリクエストにおける GET のように、情報を取得する操作に適しています。
- 例: データベースのレコード、APIのレスポンス、ファイル (PDF など)、特定のディレクトリ内のファイル一覧。リソースは動的に更新されることもあります。
プロンプトテンプレート (Prompt Templates) 📝
- ユーザーからプロンプトエンジニアリングの負担を取り除くことを目的とした、事前定義されたプロンプトの雛形です。
- 例えば、Google Drive のドキュメントを検索し、要約する機能を持つMCPサーバーがあったとします。ユーザーが毎回最適なプロンプトを考えるのは大変です。そこで、サーバー側で効果的なプロンプトテンプレートを用意し、クライアントはそれをユーザーに提示できます。ユーザーは、テンプレート内の可変部分（例: 検索キーワード）を指定するだけで、高度なプロンプトを利用できます。
- これにより、プロンプトの品質を担保し、ユーザー体験を向上させることが期待できます。

これらの基本要素を組み合わせることで、MCPサーバーはAIアプリケーションに対して柔軟かつ強力なコンテキスト提供能力を持つことができます。

Chapter 2.3: デモンストレーション: `Cloud Desktop` と `SQLite` MCPサーバー

コアメッセージ: Cloud Desktop のようなホストアプリケーションは、MCPサーバーが提供するツール、リソース、プロンプトテンプレートを活用して、自然言語によるデータ操作やタスク実行を実現します。

ここでは、Cloud Desktop (ホストアプリケーションの一例) が、SQLite データベースを操作するためのMCPサーバーと連携するデモンストレーションを通じて、これらの基本要素が実際にどのように機能するかを見てみましょう。

シナリオ: ユーザーは Cloud Desktop を通じて、SQLite データベース内の製品情報について自然言語で問い合わせを行います。

接続とツール利用 (Tool Use):
- Cloud Desktop (内のMCPクライアント) が SQLite MCPサーバーに接続します。
- ユーザーが「どのテーブルがありますか？各テーブルのレコード数は？」と尋ねると、Cloud Desktop はMCPサーバーが提供する「テーブル一覧取得ツール (List Tables)」や「レコード数取得ツール」を利用します。
- MCPサーバーはこれらのツールを実行し、結果 (テーブル名やレコード数) をクライアントに返します。Cloud Desktop はその情報をユーザーに表示します。
- さらにユーザーが「製品テーブルのデータに基づいて面白い可視化を生成して」と依頼すると、関連するツールが呼び出され、価格分布などのグラフが生成されるかもしれません。

プロンプトテンプレート利用 (Prompt Template Use):
- SQLite MCPサーバーは、「データベースに初期データを投入するプロンプトテンプレート」を提供しているとします。
- ユーザーは Cloud Desktop 上でこのテンプレートを選択し、動的なデータ（例: 「惑星に関するデータ」）を指定します。
- Cloud Desktop は、この情報を使って完成したプロンプトを生成し、LLMに送信します。LLMは、そのプロンプトとMCPサーバーが提供するツール（例: テーブル作成ツール、データ挿入ツール）を組み合わせて、データベースに新しいデータを投入する一連の処理を実行するかもしれません。
リソース利用 (Resource Use):
- SQLite MCPサーバーは、「現在のデータベースに関するビジネスインサイトメモ」というリソースを公開しているとします。
- このリソースは、データベースの内容が変更されると動的に更新されます。
- Cloud Desktop はこのリソースを定期的に取得し、ユーザーに表示することができます。ユーザーは、ツールを明示的に呼び出すことなく、常に最新のインサイトを把握できる可能性があります。

このように、MCPの基本要素は連携して機能し、AIアプリケーションが外部データと効果的に対話するための強力な基盤を提供します。

Part 2 まとめ

このパートでは、MCPの根幹を成すクライアント/サーバーアーキテクチャと、その主要な構成要素である「ツール」「リソース」「プロンプトテンプレート」について学びました。
MCPは、ホストアプリケーション内のクライアントが、外部のデータや機能を提供するサーバーと標準化されたメッセージで通信する仕組みです。
ツールは能動的な操作、リソースは読み取り専用のデータ、プロンプトテンプレートは効率的なプロンプト作成を支援します。
これらの要素が組み合わさることで、AIアプリケーションはよりリッチなコンテキストを獲得し、高度なタスクを実行できるようになる可能性が示されました。

次のパートでは、これらの概念を実際にコードに落とし込む方法、つまりMCPの実装について詳しく見ていきます。

Part 3: MCPの実装方法 ⚙️

MCPの概念を理解したところで、次はその実装方法について見ていきましょう。このパートでは、SDKの利用方法、ツール・リソース・プロンプトテンプレートの具体的な宣言方法、クライアントとサーバー間の通信フロー、そして通信の足回りとなるトランスポートメカニズムについて解説します。

Chapter 3.1: SDK (Software Development Kit) の活用

コアメッセージ: MCPは、Python をはじめとする複数の言語に対応したSDKを提供しており、これを利用することでサーバーやクライアントの開発が容易になります。

MCPサーバーやクライアントを効率的に開発するために、公式およびコミュニティからSDK (Software Development Kit) が提供されています。本稿で主に参照するのは Python MCP SDK ですが、他の言語向けのSDKも存在します。

これらのSDKは、MCPプロトコルの詳細な仕様を抽象化し、開発者がより高レベルなインターフェースでツール、リソース、プロンプトテンプレートを定義・利用できるように設計されています。例えば、関数のデコレータを使って簡単にMCPの要素を宣言できるなど、直感的な開発体験を提供するものが多いです。

Chapter 3.2: 「ツール」の宣言

コアメッセージ: SDKのデコレータを使用することで、既存の関数を簡単にMCPツールとして公開できます。

Python MCP SDK (特に FastMCP のような高レベルライブラリ) を使用する場合、通常のPython関数に @mcp.tool のようなデコレータを付与するだけで、その関数をMCPツールとしてサーバーに登録できます。

SDKは、関数の引数や返り値の型ヒントから、ツールのスキーマ（どのような入力が必要で、どのような出力が返されるかの定義）を自動的に生成してくれることが多いです。開発者は、ツールのロジックそのものの実装に集中できます。

Chapter 3.3: 「リソース」の宣言

コアメッセージ: リソースもデコレータとURIを用いて宣言し、サーバーから読み取り専用データを提供します。

リソースを宣言する場合も、ツールと同様にデコレータ (例: @mcp.resource) を使用します。リソースには、クライアントがそのリソースを一意に識別するための URI (Uniform Resource Identifier) を指定します。例えば、papers://available_folders のようなURIが考えられます。

また、リソースがどのようなデータ形式であるかを示す MIMEタイプ (例: application/json, text/plain) を指定することも一般的です。デコレートされた関数は、そのURIにアクセスがあった際に返すべきデータを生成するロジックを持ちます。

リソースには、固定的なURIを持つものと、URIの一部が可変（テンプレート化）になっているものがあります。例えば、papers://topic/{topic_name}/details のように、{topic_name} の部分に具体的なトピック名が入ることで、特定のトピックに関する詳細情報を取得できるリソースなどが考えられます。

Chapter 3.4: 「プロンプトテンプレート」の宣言

コアメッセージ: プロンプトテンプレートもデコレータで宣言し、ユーザーが容易に高品質なプロンプトを利用できるようにします。

プロンプトテンプレートをサーバーに追加する場合も、デコレータ (例: @mcp.prompt) を使用します。テンプレートには、名前 (例: summarize_research_paper) や説明を付与できます。

デコレートされた関数は、プロンプトテンプレートの構造（通常はユーザーメッセージとアシスタントメッセージのリスト、または単なるテキスト）を返します。テンプレート内には、ユーザーが入力する動的なプレースホルダー（例: {paper_title}）を含めることができます。クライアントはこれらのテンプレートを取得し、ユーザーに提示することで、ユーザーは複雑なプロンプトエンジニアリングを行うことなく、効果的な指示をLLMに与えることが可能になります。

Chapter 3.5: クライアントとサーバー間の通信フロー

コアメッセージ: MCPクライアントとサーバー間の通信は、初期化、メッセージ交換、終了という明確なステップで行われます。

MCPクライアントがMCPサーバーと通信する際には、一般的に以下の3つのフェーズがあります。

初期化 (Initialization):
- クライアントがサーバーへの接続を開くと、まず初期化プロセスが開始されます。
- クライアントからサーバーへ初期化リクエストが送信されます。
- サーバーは初期化レスポンスを返します。このレスポンスには、サーバーの能力（例: サポートするMCPのバージョン、提供する基本要素の概要など）に関する情報が含まれることがあります。
- 最後に、初期化が成功したことを確認するための通知 (Notification) が送受信される場合があります。
- この「ハンドシェイク」が成功すると、クライアントとサーバーはメッセージを交換できる状態になります。
メッセージ交換 (Message Exchange):
- 初期化後、クライアントとサーバーは様々なメッセージを交換します。
  - リクエスト (Request): クライアントはサーバーにツール実行リクエスト (例: tool/execute) やリソース取得リクエスト (例: resource/get) を送信できます。サーバーも、場合によってはクライアントにリクエストを送信することがあります (例: サンプリング機能)。
  - レスポンス (Response): リクエストを受信した側は、処理結果を含むレスポンスを返します。
  - 通知 (Notification): 一方的な情報伝達のために使用されます。レスポンスを必要としないメッセージです (例: 状態変化の通知)。
終了 (Termination):
- 通信が不要になった場合、クライアントまたはサーバーは接続の終了を要求します。
- 適切なシャットダウン処理が行われ、接続が閉じられます。

Chapter 3.6: トランスポートメカニズム

コアメッセージ: MCPは、ローカル実行用のStandard I/Oやリモート実行用のHTTPベースのトランスポートなど、複数の通信手段をサポートしています。

クライアントとサーバー間で実際にメッセージを送受信する方法は、トランスポートメカニズムによって定義されます。MCPは、実行環境や要件に応じて選択できるいくつかのトランスポートをサポートしています。

Standard I/O (標準入出力):
- 主に、クライアントとサーバーが同じマシン上でローカルに実行される場合に使用されます。
- クライアントはサーバーをサブプロセスとして起動し、サーバーは標準入力 (stdin) からメッセージを読み取り、標準出力 (stdout) へメッセージを書き込みます。
- セットアップが比較的簡単で、ローカル開発やテストに適しています。
HTTP with Server-Sent Events (SSE):
- リモートサーバーとの通信に使用されるトランスポートの一つです。
- クライアントとサーバー間でステートフルな接続を維持します。つまり、一度接続が確立されると、その接続上で双方向のメッセージ交換が継続的に行われます。
- SSEは、サーバーからクライアントへのプッシュ通知（イベント送信）を効率的に行うための技術です。
- リクエストは通常のHTTP POST で送信され、サーバーからのレスポンスや通知はSSEストリームを通じて送信されます。
Streamable HTTP:
- より新しいバージョンのMCP仕様で導入された、推奨されるリモートトランスポートです。
- ステートフルな接続（HTTP with SSEを利用）とステートレスな接続（通常のHTTP GET/POST のみ）の両方をサポートする柔軟性があります。
- ステートレスな接続は、サーバーがリクエスト間で状態を保持しないため、スケーラビリティや負荷分散の観点から有利な場合があります。
- クライアントは、初期化時にSSEへのアップグレードを要求することでステートフルな通信を選択できます。要求しない場合はステートレスな通信となります。
- 将来的には、このStreamable HTTPトランスポートが主流になると予想されています。

開発者は、アプリケーションのデプロイ戦略やパフォーマンス要件に応じて、これらのトランスポートから最適なものを選択します。

Part 3 まとめ

このパートでは、MCPの実装面に焦点を当て、SDKの利用、ツール・リソース・プロンプトテンプレートの宣言方法、クライアントとサーバー間の通信フロー、そして様々なトランスポートメカニズムについて解説しました。
SDKを活用することで、開発者はプロトコルの詳細を意識することなく、直感的にMCPの各要素をアプリケーションに組み込むことができます。
通信は初期化、メッセージ交換、終了という明確なステップで行われ、ローカル実行からリモート実行まで対応可能な複数のトランスポートが用意されています。

次のパートでは、いよいよハンズオン形式で、簡単なチャットボットとMCPサーバーを実際に構築し、これらの概念がどのように連携して動作するのかを体験します。

Part 4: ハンズオン: チャットボットとMCPサーバーの構築 🛠️

これまでのパートでMCPの概念と実装の基礎を学びました。このパートでは、実際に手を動かして、簡単なチャットボットアプリケーションと、それと連携するMCPサーバーを構築していきます。これにより、MCPがどのように機能するのかをより深く理解することができるでしょう。

このハンズオンでは、主に Python と Anthropic のモデル、そして arxiv (学術論文リポジトリ) APIを利用する例を扱います。基本的な Python の知識と、ターミナル操作に慣れていることを前提とします。

Chapter 4.1: チャットボットの基本構築 (MCP導入前)

コアメッセージ: まず、MCPを導入する前に、基本的な機能を持つチャットボットを作成し、ツール利用の概念に慣れます。

目的:
arxiv から論文を検索し、その情報を抽出する機能を持つチャットボットを作成します。この時点ではMCPは使用せず、Anthropic Claude モデルの標準的なツール利用機能を使います。

ステップ:

必要なライブラリのインストール:
anthropic (Anthropicモデル用SDK)、arxiv (arXiv API用ライブラリ) などをインストールします。
```
pip install anthropic arxiv
```
機能関数の実装:
- search_papers(topic: str, num_results: int = 5) -> list: 指定されたトピックで論文を検索し、論文IDなどの基本情報をリストで返します。結果はローカルに papers_info.json として保存することも考えられます。
- extract_info(paper_id: str) -> dict: 指定された論文IDに基づいて、保存された情報 (タイトル、URL、要約など) を返します。
ツール定義の作成:
これらの関数を Anthropic Claude モデルがツールとして認識できるように、ツールの名前、説明、入力スキーマを定義したJSONライクな構造を作成します。
チャットループの実装:
- ユーザーからの入力を受け付けます。
- モデルにメッセージとツール定義を渡して応答をリクエストします。
- モデルがツールの使用を要求した場合 (レスポンスに tool_use が含まれる場合):
  - 対応する関数 (例: search_papers) を呼び出します。
  - 関数の実行結果をモデルに再度送信し、最終的な応答を得ます。
- モデルが通常のテキスト応答を返した場合、それを表示します。
- ユーザーが "quit" と入力するまでループします。

チャットボットの初期アーキテクチャ:

この段階では、ツール定義や実行ロジックはチャットボットアプリケーション内に直接記述されています。

Chapter 4.2: 最初のMCPサーバー構築 (Standard I/O)

コアメッセージ: 前のステップで作成した関数を、FastMCP ライブラリを使って簡単にMCPツールとして公開するサーバーを作成します。

目的:
search_papers と extract_info 関数をMCPツールとして提供するMCPサーバー (research_server.py) を作成します。トランスポートには Standard I/O を使用します。

ステップ:

FastMCP のインストール:
mcp-server パッケージの一部として提供されることが多いです。
```
pip install mcp-server # (uv pip install mcp-server など環境に応じて)
```
MCPサーバーの実装 (research_server.py):
- FastMCP をインポートします。
- FastMCP インスタンスを作成します (例: mcp = FastMCP(name="ResearchServer"))。
- 既存の search_papers および extract_info 関数に @mcp.tool デコレータを付与します。SDKが型ヒントやdocstringからスキーマを推測します。
- スクリプトの最後に、サーバーを起動するコードを追加します: mcp.run(transport="stdio")。
research_server.py の構造 (概念図):

MCP Inspector を使用したサーバーテスト:
- ターミナルで research_server.py を実行可能な状態にします (例: uv run python research_server.py または直接 python research_server.py)。
- 別のターミナルで MCP Inspector を起動します。MCP Inspector は、MCPサーバーと対話し、提供されるツール、リソース、プロンプトをテストするためのウェブベースのUIツールです。
```
npx @model-context-protocol/inspector --cmd "python research_server.py"
# (環境やサーバーの起動方法に応じて --cmd の内容は調整)
```
- ブラウザで MCP Inspector を開き、Standard I/O トランスポートを選択し、サーバーコマンドを指定して接続します。
- "Tools" タブで、search_papers と extract_info がリストされていることを確認します。
- 各ツールに必要な引数を入力し、実行して結果が正しく返されるかテストします。
MCP Inspector でのテストシーケンス (概念図):

Chapter 4.3: MCPクライアントをチャットボットに統合

コアメッセージ: チャットボットアプリケーション内にMCPクライアントを実装し、先ほど作成したMCPサーバーと通信できるようにします。ツール定義と実行はサーバー側にオフロードされます。

目的:
チャットボットが research_server.py と通信し、そこからツール定義を取得し、ツール実行をサーバーに依頼するように変更します。

ステップ:

MCPクライアントライブラリの利用:
mcp-client のようなライブラリ、またはSDKの低レベルAPIを利用します。
```
pip install mcp-client # (または関連パッケージ)
```
MCPクライアントのセットアップ:
- チャットボットのコード内で、MCPクライアントセッションを確立するロジックを追加します。
- Standard I/O を使用する場合、クライアントはサーバープロセス (research_server.py) をサブプロセスとして起動します。
- サーバーとの間で読み書き用のストリームを確立します。
ツール定義の取得と利用:
- クライアントセッションを通じて、サーバーに tool/list リクエストを送信し、利用可能なツールのリスト (スキーマを含む) を取得します。
- 取得したツール定義を Anthropic Claude モデルに渡します。
ツール実行の委任:
- モデルがツールの使用を要求した場合、チャットボットは自ら関数を実行するのではなく、MCPクライアントを通じてサーバーに tool/execute リクエストを送信します。リクエストにはツール名と引数を含めます。
- サーバーがツールを実行し、結果を返します。クライアントはその結果をモデルに渡します。

MCPクライアント統合後のチャットボットアーキテクチャ (概念図):

MCPクライアントの低レベルな実装 (サブプロセスの起動、ストリーム管理など) は複雑になることがあります。SDKやライブラリが提供する高レベルな抽象化を利用することが推奨されますが、ここでは仕組みを理解するために概念的に触れています。非同期処理 (async/await) が必要になる場合も多いです。

Chapter 4.4: 複数サーバーへの接続

コアメッセージ: チャットボットを拡張し、設定ファイルに基づいて複数の異なるMCPサーバーに接続できるようにします。

目的:
チャットボットが、自作の ResearchServer に加えて、Anthropicが提供する参照サーバー (例: FetchServer - URLからコンテンツを取得、FileSystemServer - ローカルファイルを操作) にも接続できるようにします。

ステップ:

参照サーバーの理解:
- FetchServer: 指定されたURLのウェブページコンテンツを取得するツールなどを提供します。
- FileSystemServer: ファイルの読み書き、ディレクトリ一覧表示などのツールを提供します。
- これらのサーバーは、それぞれ異なる起動コマンドや設定を持つ場合があります (例: FetchServer は uv run mcp-server-fetch、FileSystemServer は npx @model-context-protocol/server-filesystem --allow-path .)。

サーバー設定用JSONファイルの作成 (servers_config.json):
接続したい各MCPサーバーの名前、起動コマンド、必要な引数などをJSONファイルに記述します。

{
  "servers": [
    {
      "name": "ResearchServer",
      "command": ["python", "research_server.py"],
      "transport": "stdio",
      "env_vars": {}
    },
    {
      "name": "FetchServer",
      "command": ["uv", "run", "mcp-server-fetch"],
      "transport": "stdio",
      "env_vars": {}
    },
    {
      "name": "FileSystemServer",
      "command": ["npx", "@model-context-protocol/server-filesystem", "--allow-path", "."],
      "transport": "stdio",
      "env_vars": {}
    }
  ]
}

チャットボットの更新:
- 起動時に servers_config.json を読み込みます。
- 設定されている各サーバーに対して、個別のMCPクライアントセッションを確立します。
  - 複数のサブプロセスを管理する必要が出てきます。非同期処理 (asyncio) とコンテキストマネージャ (async ExitStack) を使うと便利です。
- 各サーバーからツール定義を取得し、それらを統合してLLMに渡します。
  - 異なるサーバーが同じ名前のツールを提供する場合の衝突を考慮する必要が出てくるかもしれません (このハンズオンでは単純化のため深くは扱いません)。
- LLMがツール使用を要求した際、どのサーバーのツールかを特定し、対応するクライアントセッションを通じてツール実行を依頼します。

複数サーバー接続時のアーキテクチャ (概念図):

これで、チャットボットは複数のMCPサーバーの能力を組み合わせて利用できるようになり、より複雑なタスク (例: ウェブページから情報を取得し、それをローカルファイルに保存し、さらにその内容について論文を検索する) を実行できる可能性が生まれます。

Chapter 4.5: リソースとプロンプトテンプレートの追加

コアメッセージ: ResearchServer にリソースとプロンプトテンプレートを追加し、チャットボット側でそれらを利用できるようにします。

目的:
ResearchServer が、保存された論文情報のあるフォルダ一覧を「リソース」として、また、特定の形式で論文検索を指示する「プロンプトテンプレート」を提供できるようにし、チャットボットがこれらを利用できるようにします。

ステップ (サーバー側 - research_server.py の更新):

リソースの追加:
- @mcp.resource デコレータを使って、論文が保存されているフォルダの一覧を返す関数を定義します。URIは例えば papers://folders とします。
- 特定のトピックに関する保存済み論文情報を返すリソースも追加できます (例: papers://topic/{topic_name}/saved)。
プロンプトテンプレートの追加:
- @mcp.prompt デコレータを使って、論文検索用のプロンプトテンプレートを定義します。例えば、「トピック {topic} について最新の論文を {num_papers} 件検索し、要約してください」といったテンプレートです。

ステップ (クライアント側 - チャットボットの更新):

リソースとプロンプトテンプレートの取得:
- MCPクライアントセッションを通じて、サーバーから利用可能なリソースのURIリスト (resource/list) とプロンプトテンプレートのリスト (prompt/list) を取得します。
リソースの利用:
- ユーザーが特定のリソースにアクセスしたい場合 (例: @papers://folders と入力)、クライアントは対応するURIで resource/get リクエストをサーバーに送信し、結果を表示します。
プロンプトテンプレートの利用:
- ユーザーが利用可能なプロンプトテンプレート一覧を表示するコマンド (例: /prompts) を実装します。
- ユーザーが特定のプロンプトテンプレートを使用したい場合 (例: /prompt generate_search_prompt topic="量子コンピューティング" num_papers=3)、クライアントはテンプレートを取得し、ユーザーが指定した値でプレースホルダーを埋め、完成したプロンプトをLLMに送信します。

リソース/プロンプトテンプレート利用時のシーケンス (概念図 - プロンプトテンプレート利用例):

このハンズオンを通じて、MCPの主要な概念が実際にどのようにコードに落とし込まれ、連携して動作するのかを体験できたはずです。ツール、リソース、プロンプトテンプレートを組み合わせることで、より柔軟で強力なAIアプリケーションを構築できる可能性が見えてきます。

Part 4 まとめ

このパートでは、実践的なハンズオンを通じて、チャットボットとMCPサーバーの構築プロセスを体験しました。
まず、MCP導入前の基本的なチャットボットを作成し、次にその機能をMCPサーバーとして切り出し、FastMCP と Standard I/O を利用して実装しました。
MCP Inspector でのテスト方法も確認しました。
その後、チャットボトにMCPクライアントを統合し、サーバーからツール定義を取得してツール実行を委任する形に変更しました。
さらに、設定ファイルを用いて複数のMCPサーバー（自作サーバーと参照サーバー）に接続する拡張を行い、最後にリソースとプロンプトテンプレートをサーバーに追加し、クライアント側でそれらを利用する方法を学びました。
これにより、MCPの基本要素が実際にどのように連携し、AIアプリケーションの機能を拡張するかが具体的に理解できたことでしょう。

次のパートでは、Cloud Desktop のような既存のMCP互換アプリケーションと自作サーバーを連携させる方法について見ていきます。

Part 5: MCP互換アプリケーションとの連携 🤝

これまでに自作のMCPサーバーを構築する方法を学びました。MCPの強力な点の一つは、一度サーバーを構築すれば、様々なMCP互換アプリケーションでそのサーバーを再利用できる可能性があることです。このパートでは、代表的なMCP互換アプリケーションである Cloud Desktop を例に、自作サーバーとの連携方法を見ていきます。

Chapter 5.1: `Cloud Desktop` との連携

コアメッセージ: Cloud Desktop のようなMCP互換アプリケーションは、簡単な設定で外部のMCPサーバーに接続し、その機能を利用することができます。

Cloud Desktop は、Anthropic社が提供する開発者向けのAI搭載デスクトップ環境の一つで、MCPをサポートしています。これにより、ユーザーは Cloud Desktop 内から様々なMCPサーバーに接続し、それらが提供するツール、リソース、プロンプトテンプレートを自然言語インターフェースを通じて利用できます。

連携手順:

MCPサーバーの準備:
- Part 4で作成した research_server.py (または他の自作MCPサーバー) がローカルで実行可能な状態であることを確認します。
- 必要に応じて、サーバーが使用する依存関係 (例: arxiv, mcp-server) がインストールされた仮想環境を準備します。
```
# 例: MCPプロジェクトディレクトリで仮想環境を作成・有効化
cd /path/to/your/mcp_project
uv venv # または python -m venv .venv
source .venv/bin/activate # または source .venv/Scripts/activate
uv pip install arxiv mcp-server # または pip install arxiv mcp-server
```

Cloud Desktop の設定ファイル編集:

Cloud Desktop の設定メニューから、MCPサーバー設定用のJSONファイル (mcp_servers.json やそれに類する名前) を開きます。
このJSONファイルに、接続したいMCPサーバーの情報を追記します。設定には、サーバー名、起動コマンド、トランスポートタイプ (通常は stdio でローカルサーバーに接続)、作業ディレクトリ、必要な環境変数などが含まれます。

設定JSONファイルの例 (mcp_servers.json):

{
  "servers": [
    // ... 他の既存サーバー設定 ...
    {
      "name": "MyResearchServerLocal",
      "command": ["/path/to/your/mcp_project/.venv/bin/python", "/path/to/your/mcp_project/research_server.py"],
      "transport": "stdio",
      "workingDirectory": "/path/to/your/mcp_project",
      "environment": {
        // "ANTHROPIC_API_KEY": "sk-...", // サーバーがAPIキーを必要とする場合など
      }
    },
    {
      "name": "FetchServerOfficial",
      "command": ["uv", "run", "mcp-server-fetch"], // uvがパスにあれば
      "transport": "stdio"
    },
    {
      "name": "FileSystemServerOfficial",
      "command": ["npx", "@model-context-protocol/server-filesystem", "--allow-path", "."],
      "transport": "stdio",
      "workingDirectory": "/path/to/your/default_workspace" // npxの実行場所やアクセス許可パスに応じて
    }
  ]
}

command 内のPython実行ファイルのパスは、ご自身の仮想環境内のものを正しく指定してください。uv run python research_server.py のように uv 経由で実行する場合は、Cloud Desktop が uv コマンドを見つけられるようにパスが通っているか、絶対パスで指定する必要があるかもしれません。

Cloud Desktop の再起動:
設定ファイルを保存した後、Cloud Desktop を再起動します。これにより、新しいサーバー設定が読み込まれます。
動作確認:
- Cloud Desktop が再起動したら、利用可能なツールやリソースの一覧に、追加したサーバー (例: MyResearchServerLocal) とその機能が表示されるか確認します。
- Cloud Desktop のチャットインターフェースで、自作サーバーのツールを使うような指示を出してみます (例: 「MyResearchServerLocal を使ってAIに関する論文を検索して」)。
- Cloud Desktop がMCPクライアントとして機能し、ローカルの research_server.py を起動・通信し、結果を取得・表示できれば成功です。

Cloud Desktop とMCPサーバーの連携アーキテクチャ (概念図):

Cloud Desktop のようなアプリケーションを利用することで、開発者はMCPクライアント側の複雑な実装 (複数プロセスの管理、非同期通信、UI連携など) を意識することなく、サーバー側の機能開発に集中できます。また、Cloud Desktop が提供する高度な機能 (例: Artifacts 機能によるリッチな出力生成) と自作サーバーのツールを組み合わせることで、より洗練されたAIアプリケーション体験を構築できる可能性があります。

Chapter 5.2: その他のMCP互換アプリケーション

コアメッセージ: Cloud Desktop 以外にも、様々な種類のアプリケーションがMCPをサポートし始めており、エコシステムの広がりを示しています。

MCPはオープンなプロトコルであるため、Cloud Desktop 以外にも、様々なアプリケーションがMCPのサポートを表明したり、実装したりしています。これには以下のようなものが含まれる可能性があります。

他のIDEやコードエディタの拡張機能: 開発者がコーディング中に直接MCPサーバーの機能を利用できるようにするもの。
ウェブベースのAIアシスタントツール: ブラウザ上で動作し、MCPサーバーと連携して情報収集やタスク実行を支援するもの。
コマンドラインインターフェース (CLI) ツール: スクリプトや自動化処理の中でMCPサーバーを利用するためのツール。
AIエージェントフレームワーク: 自律的にタスクを実行するAIエージェントが、MCPを通じて外部ツールやデータにアクセスするための基盤。

MCPの公式ドキュメントやコミュニティリソースを参照することで、最新のMCP互換アプリケーションのリストや情報を得ることができます。これらのアプリケーションを活用することで、自作のMCPサーバーの価値をさらに高めることができるでしょう。

Part 5 まとめ

このパートでは、自作のMCPサーバーを Cloud Desktop のような既存のMCP互換アプリケーションと連携させる方法を学びました。
簡単なJSON設定ファイルを通じて、Cloud Desktop にローカルで実行されている自作サーバーや公式の参照サーバーを認識させ、それらの機能を Cloud Desktop のリッチなインターフェースから利用できることを確認しました。
これにより、MCPサーバー開発者はクライアント側の実装負担を軽減しつつ、強力なAIアプリケーションの恩恵を受けることができます。
また、Cloud Desktop 以外にもMCPエコシステムが広がっていることにも触れました。

次のパートでは、作成したMCPサーバーをローカル環境だけでなく、リモートサーバーとしてデプロイする方法について解説します。

Part 6: リモートMCPサーバーの展開 ☁️

これまでは主にローカル環境でMCPサーバーを実行・利用する方法を見てきました。しかし、AIアプリケーションが常にローカルでサーバーを実行できるとは限りません。このパートでは、作成したMCPサーバーをリモート環境にデプロイし、ネットワーク経由でアクセスできるようにする方法を学びます。

Chapter 6.1: リモートサーバー用の設定

コアメッセージ: リモートでMCPサーバーを実行する場合、トランスポートメカニズムを Standard I/O から HTTP with SSE や Streamable HTTP に変更する必要があります。

ローカルで Standard I/O を使用していたMCPサーバーをリモートで動作させるためには、いくつかの変更が必要です。

トランスポートの変更:
- research_server.py (または他の自作サーバー) の mcp.run() メソッドで指定するトランスポートを、リモートアクセスに適したものに変更します。
- Python MCP SDK のバージョンや対応状況によりますが、一般的には HTTP with Server-Sent Events (SSE) や、より新しい Streamable HTTP を使用します。
```
# research_server.py の変更例 (SSE を使用する場合)
# ... (他のコードは同じ) ...
if __name__ == "__main__":
    # ポート番号などを環境変数や引数で設定できるようにすると良い
    # 例: server_port = int(os.getenv("PORT", 8080))
    mcp.run(transport="sse", host="0.0.0.0", port=8080) # hostとportを指定
```
- Streamable HTTP がSDKでサポートされていれば、そちらの利用が推奨されます。
ポートの開放:
サーバーが動作するマシンやコンテナで、指定したポート (例: 8080) が外部からのTCP接続を受け付けられるように、ファイアウォールやネットワーク設定を構成する必要があります。
依存関係の管理:
デプロイ環境でサーバーが正しく動作するように、必要なPythonパッケージとそのバージョンを requirements.txt ファイルにまとめておきます。
```
# 仮想環境が有効な状態で
pip freeze > requirements.txt
# uv を使っている場合は uv pip freeze > requirements.txt や
# uv pip compile pyproject.toml -o requirements.txt など
```
Pythonバージョンの指定:
デプロイプラットフォームによっては、使用するPythonのバージョンを指定するファイル (例: runtime.txt に python-3.11.4 と記述) が必要な場合があります。

リモートサーバー展開のアーキテクチャ (概念図):

MCP Inspector でのリモートサーバーテスト:
サーバーをリモートで起動した後、MCP Inspector を使って接続テストができます。

MCP Inspector を起動します。
トランスポートタイプを SSE (または Streamable HTTP) に設定します。
サーバーのURL (例: http://your-remote-server-address:8080/mcp) を入力して接続します。
ツールやリソースが正しくリストされ、実行できるか確認します。

Chapter 6.2: `Render` を使用したデプロイ

コアメッセージ: Render のようなPaaS (Platform as a Service) を利用すると、比較的簡単にMCPサーバーをウェブにデプロイできます。

ここでは、Render を使って research_server.py をデプロイする手順の概要を説明します。Render は Git リポジトリからのデプロイをサポートしており、小規模なウェブサービスやバックエンドアプリケーションを手軽に公開できます。

デプロイ手順の概要:

Git リポジトリの準備:
- プロジェクト (research_server.py, requirements.txt, runtime.txt などを含む) を Git で管理します。
- 不要なファイル (例: .venv フォルダ) がコミットされないように .gitignore ファイルを作成します。
```
.venv/
__pycache__/
*.pyc
papers_info.json # 生成されるデータファイルなども除外検討
```
- 変更をコミットし、GitHub や GitLab などのリモートリポジトリにプッシュします。
Render でのサービス作成:
- Render (render.com) にサインアップ/ログインします。
- ダッシュボードから新しい "Web Service" を作成します。
- デプロイする Git リポジトリを連携させます。
サービス設定:
- Name: サービスの名前 (例: my-research-mcp-server)。
- Region: サーバーをデプロイするリージョン。
- Branch: デプロイするブランチ (例: main や master)。
- Root Directory: リポジトリのルート (通常は空欄)。
- Runtime: Python 3 などを選択 (runtime.txt があれば自動で認識されることも)。
- Build Command: 依存関係のインストールコマンド (例: pip install -r requirements.txt)。Render は requirements.txt を検知して自動で実行してくれることが多いです。
- Start Command: サーバーを起動するコマンド (例: python research_server.py)。
  - research_server.py 内でポートを環境変数 PORT から読み取るようにしている場合、Render は自動的に PORT 環境変数を設定してくれるので便利です。
- Instance Type: 無料プランまたは有料プランを選択。
デプロイの実行:
設定を保存すると、Render がビルドとデプロイを開始します。ログで進行状況を確認できます。
動作確認:
- デプロイが完了すると、サービスに公開URL (例: https://my-research-mcp-server.onrender.com) が割り当てられます。
- このURL (とMCPのエンドポイント、通常は /mcp や /sse) を使って、MCP Inspector や自作クライアントから接続テストを行います。
  - 例: https://my-research-mcp-server.onrender.com/sse (SSEの場合)
- Render の無料枠では、一定時間アクセスがないとスリープすることがあるため、初回のアクセスに時間がかかる場合があります。

デプロイプロセスのWBS図 (概念):

これで、あなたのMCPサーバーはインターネット経由でアクセス可能になり、より広範なアプリケーションから利用される準備が整いました。

Part 6 まとめ

このパートでは、自作のMCPサーバーをリモート環境にデプロイする方法について学びました。
リモート実行のためには、トランスポートメカニズムを HTTP with SSE や Streamable HTTP に変更し、ポート設定や依存関係管理を行う必要があることを確認しました。
具体的なデプロイプラットフォームとして Render を取り上げ、Git リポジトリから簡単にウェブサービスとして公開する手順の概要を説明しました。
これにより、MCPサーバーをローカルだけでなく、広くアクセス可能な形で提供する道筋が見えたことでしょう。

次の最終パートでは、MCPのさらに高度な機能や、認証、エージェント連携、そして将来の展望について探求します。

Part 7: MCPの将来と高度な機能 🚀

これまでにMCPの基本概念から実装、デプロイまでを学んできました。MCPはまだ進化を続けているプロトコルであり、より高度なユースケースや将来的な拡張に対応するための機能が議論・開発されています。この最終パートでは、MCPの認証メカニズム、クライアント側が公開する基本要素、エージェント機能との連携、そしてMCPの将来の展望について触れます。

Chapter 7.1: 認証 (Authentication)

コアメッセージ: リモートMCPサーバーのセキュリティを確保するため、OAuth 2.1 をベースとした認証メカニズムがMCP仕様に追加されています。

リモートでMCPサーバーを公開する場合、不正なアクセスを防ぎ、データや機能を保護するための認証が不可欠です。MCP仕様では、特にリモートサーバー向けに OAuth 2.1 を利用した認証フローが導入されています。

認証の概要:

目的: クライアントが正当なユーザーやアプリケーションであることをサーバーが確認し、サーバーが信頼できるクライアントからのリクエストのみを受け付けるようにします。
フロー (簡略版):
1. クライアントが保護されたリソース (MCPサーバーの機能) にアクセスしようとします。
2. サーバーはクライアントに認証を要求します (例: 認証サーバーへのリダイレクト)。
3. ユーザーは認証サーバーで認証を行います (例: ログイン)。
4. 認証が成功すると、認証サーバーはアクセストークンを発行し、クライアントに渡します。
5. クライアントは、以降のリクエストにこのアクセストークンを付与してMCPサーバーに送信します。
6. MCPサーバーはアクセストークンを検証し、正当であればリクエストを処理します。
対象: 主にリモートサーバー (HTTPベースのトランスポートを使用する場合)。Standard I/O を使用するローカルサーバーでは、通常、環境変数など他の手段でアクセス制御が行われます。
標準準拠: OAuth 2.1 は業界標準の認証フレームワークであり、これに基づいていることで、既存の認証システムとの連携や、堅牢なセキュリティ実装が期待できます。

この認証メカニズムはMCPのオプション機能ですが、特に機密性の高いデータを扱うサーバーや、商用サービスとして提供されるサーバーにとっては非常に重要です。

Chapter 7.2: クライアントが公開する基本要素: ルートとサンプリング

コアメッセージ: MCPでは、サーバーだけでなくクライアントも「ルート」や「サンプリング」といった基本要素を公開し、より双方向的で高度な連携を実現できます。

これまでは主にサーバーがツール、リソース、プロンプトテンプレートを公開するケースを見てきましたが、MCPではクライアント側も特定の情報をサーバーに提案・提供できます。

ルート (Routes) 🗺️
- クライアントがサーバーに対して「この範囲で操作してほしい」と提案するURIの集合です。
- 例えば、ファイルシステムサーバーに対して、「/users/me/documents フォルダ内のみを検索対象としてほしい」といった具体的なパスを指定できます。HTTP URLを指定することも可能です。
- メリット:
  - セキュリティ: サーバーの操作範囲を限定し、意図しないファイルへのアクセスを防ぎます。
  - フォーカス: サーバーが関連性の高いファイルパスや場所に集中できるようにします。
  - 汎用性: ファイルパスだけでなく、任意の有効なURI (HTTP URLなど) にも適用できます。
- クライアントはサーバーへの接続時に、これらのルートを宣言することができます。
サンプリング (Sampling) 🔄
- サーバーがクライアント (通常はLLMと連携している) に対して、LLMによる推論をリクエストできるようにする機能です。これは、通信の方向性が通常とは逆になる点が特徴です。
- ユースケース例:
  1. ユーザーが「ウェブサイトが遅い」と報告します。
  2. MCPサーバーは、サーバーログ、パフォーマンスメトリクス、エラーログなどを収集します。
  3. サーバーはこれらの情報を直接クライアントに全て渡してLLMに処理させるのではなく、サンプリング機能を使ってクライアントに「これらのデータに基づいてパフォーマンス問題を診断してください」とLLMへの推論をリクエストします。
  4. クライアント側のLLMがデータを分析し、診断結果をサーバーに返します。
  5. サーバーはその診断結果に基づいて、ウェブサイトの改善策を生成したり、ユーザーに報告したりします。
- メリット:
  - セキュリティ/プライバシー: 大量の生ログや機密情報を含む可能性のあるデータを、全てクライアント側のコンテキストウィンドウに入れる必要がなくなります。サーバー側で必要な情報のみをLLMに処理させることができます。
  - 効率性: サーバー側で複雑なデータ処理や分析が必要な場合に、LLMの能力を直接活用できます。
  - エージェント機能の強化: サーバーが自律的に判断し、LLMの知能を借りて問題を解決するような、より高度なエージェント的振る舞いを実現するのに役立ちます。

これらのクライアント側が公開する基本要素は、MCPの柔軟性と表現力をさらに高め、より洗練されたインタラクションを可能にします。

Chapter 7.3: エージェント機能とMCP

コアメッセージ: MCPは、複数のAIエージェントが協調してタスクを遂行するための共通言語として機能する可能性を秘めています。

自律的にタスクを計画・実行するAIエージェントの開発が活発になっています。これらのエージェントが外部ツールやデータソースと連携したり、他のエージェントと協調したりする際に、MCPは非常に有効な基盤となり得ます。

MCPとエージェントアーキテクチャ:

構成可能性 (Composability): MCPでは、クライアントがサーバーになることも、サーバーがクライアントになることも可能です。この再帰的な性質を利用して、階層的または分散的なマルチエージェントシステムを構築できます。
例:
1. ユーザーがメインのAIエージェント (MCPクライアント兼サーバーとして機能) に複雑なタスクを依頼します。
2. メインエージェントはタスクを分解し、特定のサブタスクを専門とする他のエージェント (例: 分析エージェント、コーディングエージェント、リサーチエージェント) にMCPを通じて依頼します。これらの専門エージェントもMCPサーバーとして機能します。
3. 各専門エージェントは、必要に応じてさらに下位のMCPサーバー (例: データベースサーバー、APIサーバー) にアクセスして情報を収集・処理します。
4. 結果はMCPを通じて上位のエージェントに集約され、最終的にユーザーに提示されます。

MCPを共通プロトコルとして使用することで、異なる目的や能力を持つエージェント群が、標準化された方法で互いに通信し、協力してより複雑な問題を解決できるようになることが期待されます。

Chapter 7.4: 統合レジストリ (Unified Registry)

コアメッセージ: MCPサーバーの発見、検証、バージョニングを標準化するための「統合レジストリ」の構想があります。

MCPエコシステムが成長し、多種多様なサーバーが開発されるようになると、以下のような課題が生じる可能性があります。

発見の困難性: 目的の機能を持つMCPサーバーをどのように見つければよいか？
信頼性: 公開されているMCPサーバーが安全で、意図した通りに動作するかどうかの保証は？ (悪意のあるサーバーの可能性)
バージョニング: 特定のバージョンのMCPサーバーに依存したい場合、どう管理するか？

これらの課題に対応するため、統合レジストリ (Unified Registry) のAPIというアイデアが議論されています。これは、NPM (Node.jsのパッケージ管理) や PyPI (Pythonのパッケージインデックス) のような役割をMCPサーバーに対して果たすものです。

統合レジストリの目的と機能:

サーバーの発見: 開発者やAIエージェントが、キーワードや機能に基づいてMCPサーバーを検索できるようにします。
検証と信頼性: コミュニティや企業によって信頼性が確認されたサーバーに「検証済み」マークを付与するなどして、安全なサーバー選択を支援します。
バージョニング管理: MCPサーバーのバージョン情報を管理し、アプリケーションが特定のバージョンに依存できるようにします。
動的なサーバー発見と利用: AIエージェントが、タスク実行中に必要なMCPサーバーをレジストリで検索し、動的に接続・利用するシナリオを可能にします。
- 例: ユーザーが「Shopifyストアの注文を管理して」と依頼 → エージェントがレジストリで公式のShopify MCPサーバーを検索 → サーバー情報を取得し、認証を経て接続 → タスク実行。

動的発見のユースケース (概念図):

Shopifyのようなサービスが、自社のドメインの特定のパス (例: /.well-known/mcp.json) にMCPサーバーのエンドポイントや認証情報を記述したJSONファイルを公開することで、エージェントがそれを発見し、レジストリを介さずに直接接続するという方法も考えられています。統合レジストリは、このような情報を集約・検証する役割も担うかもしれません。

Chapter 7.5: 今後の展望

コアメッセージ: MCPは、HTTP Streamableの普及、リモートサーバーエコシステムの拡大、ツール名の衝突回避、サンプリング機能の強化、認証・認可のさらなる洗練など、多くの進化の可能性を秘めています。

MCPは活発に開発が続けられており、今後も以下のような点が進化していくと考えられます。

HTTP Streamable の普及: より多くのクライアントSDKやサーバー実装が Streamable HTTP トランスポートを完全にサポートし、ステートフルとステートレスの間のシームレスな移行が実現されるでしょう。
リモートMCPサーバーエコシステムの拡大: 様々なSaaSプロバイダーやデータソースが公式のMCPサーバーを提供するようになり、利用可能なサーバーの種類が大幅に増えることが期待されます。
ツール名の衝突回避: 複数のMCPサーバーを利用する際に、異なるサーバーが同じような名前のツール (例: fetch_user_data) を提供し、モデルが混乱する可能性があります。これを防ぐため、サーバーごとや論理的なグループごとにツール名を修飾する仕組みなどが検討されるかもしれません。
サンプリング機能の強化: サーバーからクライアントへの推論リクエスト (サンプリング) のユースケースがさらに探求され、プロトコルレベルでのサポートが強化される可能性があります。
認証・認可の強化: OAuth 2.1 をベースとしつつも、より大規模な環境や複雑な権限管理に対応するための拡張やベストプラクティスが整備されていくでしょう。

MCPは、AIアプリケーションが外部世界とより深く、より安全に、そしてより標準化された方法で対話するための重要な鍵となる可能性を秘めています。その進化から目が離せません。

Part 7 まとめ

この最終パートでは、MCPのより高度な側面と将来の展望について探求しました。
リモートサーバーのセキュリティを確保するための OAuth 2.1 ベースの認証メカニズム、クライアント側がサーバーに操作範囲を提案する「ルート」やLLM推論をリクエストする「サンプリング」といった高度な基本要素を紹介しました。
また、MCPがマルチエージェントシステムにおける共通言語として機能する可能性や、MCPサーバーの発見・検証・バージョニングを標準化する「統合レジストリ」の構想についても触れました。
最後に、HTTP Streamable の普及やエコシステムの拡大、認証・認可の強化など、MCPが今後どのように進化していくかの展望を示しました。
MCPは、AI開発の未来を形作る上で重要な役割を担うプロトコルとして、その発展が期待されます。

Part 8: まとめ ✨

本記事では、Model Context Protocol (MCP) について、その基本概念から具体的な実装、応用例、そして将来の展望に至るまで、包括的に解説してきました。

MCPの核心:

AIアプリケーションが外部のツールやデータリソースへアクセスする方法を標準化するオープンプロトコルです。
クライアント/サーバーアーキテクチャを採用し、「ツール」「リソース」「プロンプトテンプレート」という基本要素を通じてコンテキストを提供します。
開発者はSDKを利用して比較的容易にMCPサーバーやクライアントを構築でき、様々なトランスポートメカニズム（ローカル用のStandard I/O、リモート用のHTTPベースのもの）を選択できます。

学んだことの振り返り:

MCPがAI開発におけるコンテキストの断片化や連携の非効率性といった課題をどのように解決しようとしているか。
実際にチャットボットとMCPサーバーを構築し、ツール、リソース、プロンプトテンプレートが連携して動作する様子。
Cloud Desktop のような既存のMCP互換アプリケーションと自作サーバーを連携させる方法。
MCPサーバーをリモート環境にデプロイする手順。
認証、サンプリング、統合レジストリといったMCPの高度な機能や将来の構想。

MCPは、AIモデルがその能力を最大限に発揮するために不可欠な「コンテキスト」を、より効率的かつスケーラブルに提供するための強力な枠組みです。エコシステムはまだ成長段階にありますが、Anthropic社をはじめとする多くの開発者や企業の努力により、その可能性は日々広がっています。

この記事が、読者の皆様にとってMCPへの理解を深め、ご自身のAIアプリケーション開発に役立つヒントとなれば幸いです。MCPの世界は奥深く、探求すべきことはまだたくさんあります。ぜひ公式ドキュメントやコミュニティに参加し、このエキサイティングな技術の最前線に触れてみてください。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

Anthropic x DeepLearning.AI : MCPを統合したリッチコンテキストAIアプリケーションの構築

目次

Part 1: Model Context Protocol (MCP) とは？

Chapter 1.1: MCPの誕生背景と目的

Chapter 1.2: MCPが解決する課題

Chapter 1.3: MCPのメリット

Chapter 1.4: MCPエコシステムの成長

Chapter 1.5: MCPに関するよくある質問

Part 1 まとめ

Part 2: MCPのコアコンセプト 建築ブロックを理解する 🧱

Chapter 2.1: クライアント/サーバーアーキテクチャ

Chapter 2.2: MCPの基本要素 (Primitives)

Chapter 2.3: デモンストレーション: Cloud Desktop と SQLite MCPサーバー

Part 2 まとめ

Part 3: MCPの実装方法 ⚙️

Chapter 3.1: SDK (Software Development Kit) の活用

Chapter 3.2: 「ツール」の宣言

Chapter 3.3: 「リソース」の宣言

Chapter 3.4: 「プロンプトテンプレート」の宣言

Chapter 3.5: クライアントとサーバー間の通信フロー

Chapter 3.6: トランスポートメカニズム

Part 3 まとめ

Part 4: ハンズオン: チャットボットとMCPサーバーの構築 🛠️

Chapter 4.1: チャットボットの基本構築 (MCP導入前)

Chapter 4.2: 最初のMCPサーバー構築 (Standard I/O)

Chapter 4.3: MCPクライアントをチャットボットに統合

Chapter 4.4: 複数サーバーへの接続

Chapter 4.5: リソースとプロンプトテンプレートの追加

Part 4 まとめ

Part 5: MCP互換アプリケーションとの連携 🤝

Chapter 5.1: Cloud Desktop との連携

Chapter 5.2: その他のMCP互換アプリケーション

Part 5 まとめ

Part 6: リモートMCPサーバーの展開 ☁️

Chapter 6.1: リモートサーバー用の設定

Chapter 6.2: Render を使用したデプロイ

Part 6 まとめ

Part 7: MCPの将来と高度な機能 🚀

Chapter 7.1: 認証 (Authentication)

Chapter 7.2: クライアントが公開する基本要素: ルートとサンプリング

Chapter 7.3: エージェント機能とMCP

Chapter 7.4: 統合レジストリ (Unified Registry)

Chapter 7.5: 今後の展望

Part 7 まとめ

Part 8: まとめ ✨

Part 2: MCPのコアコンセプト建築ブロックを理解する 🧱

Chapter 2.3: デモンストレーション: `Cloud Desktop` と `SQLite` MCPサーバー

Chapter 5.1: `Cloud Desktop` との連携

Chapter 6.2: `Render` を使用したデプロイ