はじめに

こんにちは。クラウドエースの荒木です。

ChatGPT や Claude などの生成 AI が日常生活やビジネスに浸透してきましたが、これらの AI の真価は外部システムと連携したときに発揮されます。しかし、この連携には大きな課題がありました。

これまで AI と外部システムを連携させるには、システムごとに個別の API 統合が必要で、認証方法やデータ形式、エラー処理など、細かな実装を繰り返す必要がありました。このような個別対応は開発効率を下げ、拡張性や保守性の面でも問題がありました。

そこで登場したのが「Model Context Protocol（MCP）」です。2024 年 11 月に Anthropic が発表したこのオープンプロトコルは、AI と外部システムの接続を標準化し、開発者の負担を大幅に軽減します。

この記事では、MCP の基本概念から実装方法、活用事例まで、技術的な専門知識がなくても理解できるよう解説していきます。

MCP とは

かつて日本のガラケー時代を知る人なら懐かしく思い出すでしょう。ドコモ、au、ソフトバンクなど、各キャリアが独自の充電端子を採用していた時代には、友人の家に泊まっても充電器を借りられないという悲劇が日常茶飯事でした。しかし、スマートフォン時代になり、特に USB-C の普及により、現在ではほとんどのデバイスが同じケーブル一本で充電できるようになりました。

Model Context Protocol（MCP）は、まさに AI 界の USB-C なのです。

Anthropic の公式ドキュメントでは、MCP を「AI 用の USB-C ポート」と表現していますが、これは単なる比喩ではありません。USB-C が様々なデバイスを標準化されたインターフェースで接続できるように、MCP は生成 AI モデルと様々なデータソースやツールを標準化された方法で接続します。

例えば、あなたが開発している AI アシスタントに、カレンダー、メール、天気予報、株価情報など 10 種類のサービスと連携させたいとします。従来の方法では、10 種類の API それぞれに対して個別の連携コードを書く必要がありました。しかし、MCP を使えば、一度 MCP クライアントを実装するだけで、MCP に対応した全てのサービスと簡単に連携できるようになります。

これにより、開発者は個別の API 統合を行う代わりに、MCP という単一のプロトコルを通じて多様なシステムと連携できるようになります。まるで、10 種類の異なる充電器を持ち歩く代わりに、USB-C 一本で全てのデバイスを充電できるようになったようなものです。

MCP のアーキテクチャ

クライアント・サーバモデル

MCPのアーキテクチャ図

MCP は基本的にクライアント・サーバモデルに基づいています。このアーキテクチャは以下の主要コンポーネントで構成されています。

MCP ホスト

MCP ホストは、生成 AI モデルを搭載したアプリケーションです。例えば、Claude Desktop、Zed、Cursor などの開発環境が該当します。これらのアプリケーションは、MCP クライアントを通じて外部データやツールにアクセスします。

MCP クライアント

MCP クライアントは、MCP ホスト内に組み込まれたコンポーネントで、MCP サーバとの通信を担当します。クライアントはサーバとの接続を確立し、リソース、ツール、プロンプトなどの機能を利用するためのリクエストを送信します。

MCP サーバ

MCP サーバは、特定のデータソースやツールへのアクセスを提供する軽量サーバです。例えば、ファイルシステム、データベース、API などへのアクセスを提供するサーバがあります。サーバはクライアントからのリクエストを処理し、必要なデータや機能を提供します。

通信プロトコル

MCP の通信は、JSON-RPC 2.0 プロトコルに基づいています^[1]。クライアントとサーバ間の通信は、標準入出力（stdio）または HTTP with Server-Sent Events（SSE）トランスポートを通じて行われます^[2]。

通信の流れは以下のようになります^[3]。

クライアントがサーバに接続し、初期化メッセージを送信
サーバが対応するプロトコルバージョンなどの情報を返信
クライアントがサーバの機能（リソース、ツール、プロンプト）を問い合わせ
サーバが利用可能な機能のリストを返信
クライアントが特定の機能を利用するためのリクエストを送信
サーバがリクエストを処理し、結果を返信

この標準化された通信プロトコルにより、異なるシステム間でもシームレスな連携が可能になります。

MCP の主要機能

MCP サーバは、クライアントに対して以下の 3 つの主要機能を提供します。

リソース

リソースは、AI モデルが参照できるデータやコンテンツを提供します。例えば、ファイルシステム、データベース、ドキュメントなどがリソースとして提供されます。

例：

ファイルシステム上のファイル
データベース内のデータ
Google Drive 上のドキュメント
Git リポジトリのコード

リソースは、AI モデルが現実世界のデータに基づいて回答を生成するための基盤となります。

ツール

ツールは、AI モデルが実行できる関数やアクションを提供します。単純なテキスト生成だけでは不十分な場合に、外部システムと対話するための機能を提供します。

例：

計算の実行
外部 API の呼び出し
データベースクエリの実行
ファイル操作の実行

プロンプト

プロンプトは、AI モデルの応答を形作るテンプレートです。適切なプロンプトは、汎用的なテキストではなく、正確で有用な結果を得るための鍵となります。

例：

システム指示：「あなたはプログラミング教師です。初心者にも分かりやすく説明してください」のように、AI の役割や応答スタイルを定義
コンテキスト付きの質問：「このコードの問題点を見つけて」という質問に、実際のコードファイルを添付して具体的な回答を得る
マルチモーダル入力：「この画像に写っている料理のレシピを教えて」のように、テキストと画像を組み合わせた質問を行う

公開されている MCP サーバー

GitHub 上には、すでに様々な MCP サーバーが公開されています。これらを活用することで、ゼロから開発することなく、AI アプリケーションを簡単に拡張することが可能です。ここでは、実際に試用して有用性を確認したいくつかのサーバーを紹介します。

Brave Search MCP サーバー^[4]

このサーバーは Brave 検索の API を活用し、AI モデルにウェブ検索機能を提供します。生成 AI モデルは学習データに時間的制約があるため、最新情報へのアクセスにはウェブ検索との連携が不可欠です。

提供されるツール：

brave_web_search：一般的なウェブ検索を実行
brave_local_search：飲食店やサービスなどの地域情報を検索

Fetch MCP サーバー^[5]

このサーバーを利用することで、AI モデルが直接ウェブページの内容を取得・参照することが可能になります。

HTML を Markdown に変換する機能によって、生の HTML では AI による解析が難しい場合でも、Markdown への変換により本文コンテンツを効率的に処理できます。

提供されるツールはfetchのみで、以下のようなパラメータがあります。

url：取得する URL を指定（必須）
max_length：取得する最大文字数（デフォルト：5000 文字）
start_index：読み始める位置
raw：生の HTML を取得するかどうか

AI に参照してほしいページが決まっている場合は、前述の Brave Search よりこちらを使用すると便利です。

Filesystem MCP サーバー^[6]

このサーバーは、AI がローカルのファイルを操作するための機能を提供します。

ローカルのファイルを操作されることを不安に感じるかもしれませんが、アクセスできる範囲を設定可能ですので、安全に利用することができます。

提供されるツール：

read_file：ファイル内容の読み取り
read_multiple_files：複数ファイルの同時読み取り
write_file：ファイルの作成
edit_file：ファイルの編集
create_directory：新規ディレクトリ作成
list_directory：ディレクトリ内容の一覧表示
move_file：ファイルやディレクトリの移動
search_files：ファイルやディレクトリの検索
get_file_info：ファイル詳細情報の取得
list_allowed_directories：アクセス可能なディレクトリの表示

例えば、「このプロジェクトの構造を分析して」というリクエストに対して、AI がファイル一覧を取得し、主要なファイルの内容を読み取った上で分析結果を返すことが可能になります。特に大規模プロジェクトの全体像を把握する際に有効です。

MCP サーバーの実装方法

公開されている MCP サーバーを使うことで多くのことが実現できますが、ビジネスやプロジェクト特有のニーズに合わせたカスタム MCP サーバーを開発することも可能です。ここでは、簡単な MCP サーバーとクライアントの実装例を通して、その方法を見ていきましょう。

簡単な MCP サーバーの実装（Python）

Python を使った最もシンプルな MCP サーバーの例を紹介します。このサーバーは「挨拶を返す」という単純な機能を提供しますが、MCP サーバー開発の基本的な流れを理解するのに役立ちます。

hello_mcp_server.py

from mcp.server.fastmcp import FastMCP, tool

# MCPサーバーのインスタンスを作成
server = FastMCP()

# ツールの定義
@tool
def greeting(name: str) -> str:
    """
    ユーザー名を受け取り、挨拶を返す簡単なツール

    Args:
        name: 挨拶する相手の名前

    Returns:
        挨拶文
    """
    return f"こんにちは、{name}さん！MCPの世界へようこそ。"

# ツールをサーバーに登録
server.add_tool(greeting)

# サーバーの起動（標準入出力を使用）
if __name__ == "__main__":
    server.start()

このコードでは、Python SDK のFastMCPクラスを使って、たった数行で MCP サーバーを実装しています。

@toolデコレータを使って通常の関数を MCP ツールとして定義
型ヒントを使ってパラメータと戻り値の型を明示的に宣言
ドキュメント文字列（docstring）を通じてツールの説明を提供

クライアント側の実装（Python）

次に、このサーバーと通信するクライアントの実装例を見てみましょう。

hello_mcp_client.py

import asyncio
from mcp.client import MCPClient
from mcp.transports import StdioClientTransport
import subprocess

async def main():
    # サーバープロセスを起動
    server_process = subprocess.Popen(
        ["python", "hello_mcp_server.py"],
        stdin=subprocess.PIPE,
        stdout=subprocess.PIPE,
        stderr=subprocess.PIPE,
        text=True
    )

    # クライアントの作成と接続
    transport = StdioClientTransport(server_process.stdin, server_process.stdout)
    client = MCPClient(transport)
    await client.initialize()

    # 利用可能なツールを取得
    tools = await client.get_tools()
    print(f"利用可能なツール: {[tool['name'] for tool in tools]}")

    # greetingツールを呼び出す
    result = await client.call_tool("greeting", {"name": "クラウドエース"})
    print(f"サーバーからの応答: {result}")

    # 切断
    await client.shutdown()
    server_process.terminate()

if __name__ == "__main__":
    asyncio.run(main())

このクライアントは以下のステップでサーバーと通信しています。

サーバープロセスを起動
標準入出力を通じてサーバーと接続
初期化を行い、利用可能なツールのリストを取得
greetingツールを呼び出し、結果を表示

実行すると以下のような出力が得られます。

利用可能なツール: ['greeting']
サーバーからの応答: こんにちは、クラウドエースさん！MCPの世界へようこそ。

実際のアプリケーションでは、より複雑なツールを実装したり、複数のサーバーと連携したりすることになりますが、基本的な概念はこの例と同じです。

MCP サーバー開発用 SDK

MCP の実装を容易にするために、以下の SDK が公式に提供されています^[7]。

TypeScript SDK^[8]：JavaScript および TypeScript アプリケーション向け
Python SDK^[9]：Python アプリケーション向け
Kotlin/Java SDK^[10]：Kotlin/Java/Android 向け

これらの SDK を使えば、数十行のコードで基本的な MCP サーバーを実装できます。例えば、社内データベースへのアクセスを提供するサーバーや、特定の業務システムと連携するサーバーなど、ニーズに合わせたカスタムサーバーを開発することが可能です。

より詳しい実装方法については、それぞれの公式ドキュメントのチュートリアルや GitHub 上のサンプルコードを参照してください。

MCP の活用事例

開発環境での活用（IDE 統合）

コードアシスタント：ファイルシステム、バージョン管理、パッケージマネージャー、ドキュメントなどと連携し、より高度なコード補完や提案を提供
デバッグアシスタント：エラーログやデバッグ情報にアクセスし、問題解決をサポート
ドキュメント生成：コードベースを分析し、自動的にドキュメントを生成

実際に、Zed、Replit、Codeium、Sourcegraph などの開発ツール企業が MCP を活用して、より高度な AI 支援機能を提供しています。

ビジネスツールとの連携

データ分析プラットフォーム：複数のデータベースや可視化ツールと連携し、自然言語でのデータ分析を可能に
プロジェクト管理ツール：Slack、GitHub、Linear、Todoist などと連携し、タスク管理や進捗報告を自動化

データ分析・検索の強化

MCP はデータ分析や検索の分野でも活用されています。

複合データ分析：複数のデータベースや分析ツールと連携し、より包括的な分析を提供
知識ベース検索：社内文書、ナレッジベース、外部情報源などを横断的に検索し、より正確な情報を提供
セマンティック検索：Qdrant などのベクトル検索エンジンと連携し、意味ベースの高度な検索を実現

MCP と従来の API 連携の比較

開発効率の違い

MCP と従来の API 連携の最も大きな違いは、開発効率にあります。

特徴	MCP	従来の API
統合の簡単さ	単一の標準化された統合	API ごとに個別の統合が必要
リアルタイム通信	✅ 対応	❌ 基本的に非対応
動的な検出	✅ 対応	❌ 非対応
スケーラビリティ	容易（プラグアンドプレイ）	追加の統合が必要
セキュリティと制御	ツール間で一貫	API によって異なる

MCP では、一度実装すれば多くのツールやデータソースと連携できるため、開発効率が大幅に向上します。

拡張性と柔軟性

MCP は拡張性と柔軟性においても優れています。

単一プロトコル：MCP は標準化された「コネクタ」として機能し、1 つの MCP を統合するだけで複数のツールやサービスにアクセス可能。
動的な検出：MCP は AI モデルが各統合のハードコードされた知識なしに、利用可能なツールを動的に検出して対話することが可能。
双方向通信：MCP は WebSocket に似た永続的なリアルタイムの双方向通信をサポート。AI モデルは情報を取得し、動的にアクションをトリガーの両方が可能。

セキュリティの考慮点

MCP の設計では、利便性だけでなくセキュリティも重要な柱となっています。AI に外部システムへのアクセス権を与えることは諸刃の剣であり、適切な安全対策が不可欠です。

MCP はこの課題に対して、「明示的な同意」という原則を中心に据えています。例えば、あなたが Claude Desktop で「私の GitHub リポジトリを分析して」と依頼した場合、AI がいきなりリポジトリにアクセスするのではなく、まず「GitHub リポジトリへのアクセスを許可しますか？」という確認が表示されます。この仕組みにより、ユーザーは常に何が起きているかを把握し、コントロールできます。

データプライバシーの面でも、MCP は慎重なアプローチを取っています。ホストアプリケーションは、ユーザーの明示的な許可なしにデータをサーバに送信することはできません。これは特に企業の機密情報や個人データを扱う場合に重要な保護層となります。

また、ツールの実行に関しても安全性が考慮されています。AI が「このコードを実行して」と提案した場合、そのコードが何をするのかをユーザーが確認し、承認するステップが組み込まれています。これにより、悪意のあるコード実行のリスクを大幅に軽減できます。

さらに興味深いのは、LLM サンプリング制御の仕組みです。AI モデルが新しいテキストを生成する際（サンプリング）、MCP はこのプロセスをユーザーの管理下に置きます。例えば、AI が外部 API を使って天気予報を取得しようとする場合、ユーザーはその操作を承認するかどうかを選択できます。

こうした多層的なセキュリティ対策により、MCP は便利さと安全性のバランスを取りながら、信頼性の高い AI 統合を実現しています。

MCP の今後の展望

MCP は比較的新しい技術標準ですが、今後の AI 開発において非常に重要な技術です。そこで今後の展望を考えてみました。

開発ツールとの統合拡大

現在、Zed や Cursor などの一部の IDE が MCP をサポートし始めていますが、今後はより多くの開発ツールがこの標準を採用すると予想されます。特に、GitHub や GitLab などのコード管理プラットフォーム、JIRA などのプロジェクト管理ツールとの連携が進めば、開発ワークフローの効率化が期待できます。

例えば、「この PR のコードレビューをして」と指示するだけで、AI がリポジトリの内容を分析し、適切なフィードバックを提供する。あるいは「このバグの原因を特定して」と言えば、エラーログとコードベースを参照して問題箇所を指摘する。こうした機能が標準化されることで、開発者の日常業務が大きく変わる可能性があります。

企業内システムとの連携

多くの企業では、社内文書、ナレッジベース、チケット管理システム、CRM など、様々な独自システムが存在します。これらのシステムと MCP を連携させることで、企業特有のコンテキストを理解した AI アシスタントの構築が容易になるでしょう。

特に注目すべきは、セキュリティの観点です。MCP の標準化されたアクセス制御メカニズムにより、機密情報へのアクセスを適切に管理しながら AI を活用できる点は、企業にとって大きなメリットとなります。

相互運用性の向上

現在の AI エコシステムでは、各プラットフォームやツールが独自のインターフェースを持っており、連携が難しい状況です。MCP が広く採用されれば、異なる AI モデルやツール間の相互運用性が向上し、開発者はより柔軟にシステムを構築できるようになります。

例えば、特定のタスクには Claude が優れており、別のタスクには GPT-4 が適している場合、両方のモデルを同じ MCP インターフェースで利用できれば、最適な AI を選択しやすくなります。これは、かつてのブラウザ互換性の問題が標準化によって解決されてきたことに似ています。

現実的な課題

もちろん、MCP の普及には課題もあります。新しい技術標準の採用には時間がかかりますし、既存システムとの統合にはコストがかかります。また、大手 AI 企業がそれぞれ独自の標準を推進する可能性もあり、業界全体での合意形成が必要です。

さらに、MCP を活用するためには、開発者がプロトコルの仕様を理解し、適切に実装する必要があります。この学習コストも、普及の速度に影響するでしょう。

このように MCP にも当然課題はありますが、AI と既存システムの連携を効率化する実用的なツールとして、今後のソフトウェア開発において重要な役割を果たすことが期待されます。

所感

実際に私は、Fetch や Filesystem などの MCP サーバーを Cursor の Agent モードと連携して利用していますが、「本当の意味で AI が人間の代替として動いてくれるようになったな」という印象です。これまでの生成 AI チャットやコードアシスタントは、人間が情報を与える → 人間が指示する → AI が応答する → 応答を基に人間が作業する、という繰り返し作業が必要でした。それでも十分に便利でしたが、MCP によって AI が自律的に外部システムと連携し、情報を取得・操作することが可能になるため、これまで以上に人間の単純作業は減少し、人間にしかできない作業に集中することができるようになりました。

また実際に試してみて特に魅力的に感じたのは、その低い導入障壁です。公開されている MCP サーバーの GitHub リポジトリに書かれているサーバー起動コマンドを実行するだけですぐに利用することができます。しかも導入後は AI が自律的にツールの選択や操作を行うため、特に開発者が意識的に操作する必要がないのも大きな利点に感じました。

今後、大手のサービスやツールが MCP 連携を提供してくれることを期待しています。特に Google Cloud を使っている身としては、Google Drive や Google Cloud リソースを直接操作できる MCP サーバーを公式に提供してくれたらいいな（チラッ）と思っています。

なお、8 月 5 日と 8 月 6 日に開催される Google Cloud Next では、A2A や Gemini CLI などの新サービスと絡めた形で MCP に関する発表があるかもしれません。弊社 CTO も「AI と人間の協調」というテーマで MCP 技術を取り上げるセッションに登壇予定で、どのような議論が展開されるのか今から楽しみです。

Discussion