← 記事一覧へ

MCP とは

MCP（Model Context Protocol、モデルコンテキストプロトコル）は、AI アシスタントと外部データ・ツールの接続を標準化するオープンプロトコルです。各サービス（GitHub、データベース、CRM、ファイルシステム）ごとに個別統合を書く代わりに MCP サーバーを立て、クライアント - Cursor、Claude Desktop、Zed など - が単一の契約で接続します。以下では MCP とは何か、アーキテクチャの仕組み、本番環境でプロトコルが重要な理由を説明します。

わかりやすい定義

Model Context Protocol は、AI アプリケーション（host）と外部コンテキスト源（server）の間の交換仕様です。サーバーは次を公開できます：

  • Resources - 読み取り可能なデータ：ファイル、DB 行、API ドキュメント
  • Tools - モデルが呼び出せる操作：API リクエスト、SQL、インデックス検索
  • Prompts - 典型的なシナリオ向けのプロンプトテンプレート

プロトコルはオープンで、特定の LLM ベンダーに縛られません。host がモデルを選び、MCP サーバーが提供するデータとツールを決めます。通信は JSON-RPC 2.0 で、stdio、HTTP、SSE でトランスポートします。

Anthropic の考え（2024 年 11 月）：カスタムプラグインの「動物園」をやめ、エージェントにコンテキストを接続する一本の方法を用意する。

アーキテクチャ：host、client、server

典型的な 3 役割の構成：

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│  MCP Host   │────▶│ MCP Client  │────▶│ MCP Server  │
│ (Cursor、   │     │ (アプリ内)  │     │ (GitHub、   │
│  Claude 等) │     │             │     │  Postgres…) │
└─────────────┘     └─────────────┘     └─────────────┘
  • MCP Host - LLM を持つアプリ：IDE、チャットクライアント、エージェント基盤。セッション管理、モデル呼び出し、tool 実行のタイミングを決める。
  • MCP Client - host 内で MCP 経由で 1 つ以上のサーバーと話すコンポーネント。
  • MCP Server - resources、tools、prompts を公開するプロセスまたはサービス。ローカル（ディスク上のファイル）でもリモート（社内 API）でもよい。

1 つの host が複数の client を持てる - MCP サーバーごとに 1 つ。Cursor ではファイルシステム、ブラウザ、GitHub、設定のカスタム MCP が同時に動くことがあります。

MCP が実務でもたらすもの

N 個の統合の代わりに 1 つの契約

MCP 以前は各製品が独自コネクタを書いていました：「ファイルを読む」「API を呼ぶ」それぞれ別形式。MCP は次を固定します：

  • ツールの宣言方法（名前、パラメータ schema、説明）
  • 結果の返し方
  • resources の要求と変更購読

同じ PostgreSQL MCP サーバーは、プロトコル対応の Claude Desktop や他 host で使えます。

セキュリティとアクセス境界

サーバーは別プロセスまたはコンテナで動きます。host はシステム全体に直接触れず - サーバーが明示的に公開したものだけです。エンタープライズでは重要：エージェントにデータマートの read-only を渡し、本番 DB 全権限は与えない、といった運用ができます。

ローカルとクラウドのシナリオ

  • ローカル - stdio トランスポート：host がサーバーバイナリを子プロセスで起動（IDE やデスクトップクライアントで典型）。
  • リモート - HTTP/SSE：チーム全体で VPN やクラウド上の共有 MCP サーバー。

どちらも仕様に含まれます。選択はセキュリティ方針とデータの置き場所次第です。

MCP と function calling

Function calling（tool use）は LLM 側の仕組み：モデルが「関数 X を引数 Y で呼べ」と構造化リクエストを返す。MCP はそれより下で広い層：関数とデータがどこから来るか、どう登録され、host がどう通信するかを標準化します。

相互作用の流れ：

  1. host が MCP サーバーに接続し tool 一覧を取得。
  2. 一覧をプロバイダー形式（OpenAI tools、Anthropic tools など）でモデルに渡す。
  3. モデルが tool を選択；host が MCP client → server で実行。
  4. 結果がモデルコンテキストに戻り次のステップへ。

MCP はモデルの推論を置き換えません - エージェントと外部世界の「配線」を統一します。

MCP が使われている場所

環境 MCP の役割
Cursor 組み込みとカスタム MCP サーバー：ファイル、ターミナル、ブラウザ、第三者 API
Claude Desktop claude_desktop_config.json 経由の公式・コミュニティサーバー
Zed、Continue、Cline エディタでのコンテキスト拡張の MCP 対応
エンタープライズエージェント 社内 API、チケット、wiki 上の自前サーバー

コミュニティは GitHub、Google Drive、Slack、Puppeteer、SQLite、Postgres、Brave Search などを提供。GitHub の modelcontextprotocol/servers などのレジストリに数百あります。

MCP サーバーの作成・接続

開発者向け最小手順：

  1. SDK を選ぶ：公式ライブラリは TypeScript、Python、C#、Java など。
  2. サーバーコードで tools と resources を記述（名前、inputSchema、handler）。
  3. stdio または HTTP トランスポートでサーバーを起動。
  4. host に設定を追加（Cursor では .cursor/mcp.json または IDE 設定）。

Python の tool ロジック例（簡略）：

@server.tool()
async def get_weather(city: str) -> str:
    """都市の現在の天気。"""
    return await weather_api.fetch(city)

セッション開始時に host がサーバーの capabilities を要求；モデルは city パラメータの JSON schema 付きで get_weather を見ます。

自前開発がないチームは、レジストリの既存サーバー + 設定とシークレット（API キーは env、リポジトリに入れない）で足りることが多いです。

限界と注意点

MCP が解くのは接続の標準化であり、次ではありません：

  • モデル推論の品質
  • 複雑な多段ワークフローのオーケストレーション（エージェントフレームワークの領域）
  • ユーザー間の認可（サーバー上に別途 OAuth/RBAC が必要）

実務では次を考慮：

  • レイテンシ - 各 tool call は往復；10 回超の連鎖には時間とトークン予算が要る。
  • バージョン - サーバーと host は仕様版（2025-03 以降が活発に進化）を揃える。
  • 信頼性 - MCP サーバー障害でデータアクセスが途切れる；本番ではヘルスチェックとフォールバックが必要。

MCP と RAG、カスタム API の比較

方式 強み 弱み
MCP 任意 host 向け標準 tools/resources クライアントの MCP 対応が必要
RAG 全文をコンテキストに載せず大規模コーパスを検索 任意操作（書き込み、API 変更）は不可
カスタム API 完全制御 AI クライアントごとに重複作業

成熟した構成では MCP + RAG が多い：RAG で文書知識、MCP tools で DB・チケット・デプロイへのライブ問い合わせ。

まとめ

MCP は AI エージェント向けのオープンコンテキストプロトコルです。host がサーバーに接続し resources と tools を得て、モデルが単一契約でそれらを呼び出します。統合コストを下げ、Cursor、Claude Desktop など間でのシナリオ移植を楽にし、データアクセス境界を明確にします。

開発者の実用順序：まずスタック向けのコミュニティサーバーから始め、同じ tools を複数 host アプリで使うなら社内 API を自前 MCP サーバーに包む。

よくある質問

MCP は通常の REST API と何が違いますか？

REST API は特定サービスへの HTTP 呼び出しのインターフェースです。MCP は AI host とそのようなサービスへの「アダプター」間のプロトコル：host が tools を発見・呼び出し、resources をエージェント向け形式で読む方法を定めます。1 つの MCP サーバーが GitHub や Jira の REST API を包めます；host は製品ごとに別統合を書く必要がありません。

1 つのチャット（例：ChatGPT）だけ使うなら MCP は必要ですか？

ワークフロー全体が組み込みプラグイン付きの閉じた製品内だけなら - 必ずしも不要です。MCP が効くのは 複数 host（IDE + デスクトップ + 自前エージェント）、同じ tools の再利用、機密データを明示的アクセス制御付きで自サーバーに置く場合です。

業務データに MCP サーバーを接続するのは安全ですか？

サーバーと設定次第です。信頼できるオープンソースのコミュニティサーバー、read-only、環境変数でのシークレットが最低ライン。本番では：別プロセス、最小権限、tool 呼び出しの監査、人の承認なしのエージェント書き込みは避ける。

ローカルモデル（Ollama、LM Studio）で MCP は使えますか？

host が MCP とローカルプロバイダーの両方をサポートすれば はい。MCP はクラウド API に縛られません - コンテキストと tools を供給し、モデルはローカルでよい。制限は host 側：すべてのクライアントがローカル LLM とフル MCP tools を同程度に組み合わせられるわけではありません。

Cursor で MCP 設定をどこから始めますか？

  1. Cursor の MCP 設定（またはプロジェクトの .cursor/mcp.json）を開く。
  2. ドキュメントの既存サーバー（例：filesystem、GitHub）を起動コマンドとトークン用 env で追加。
  3. Cursor を再起動し、サーバーが connected か確認。
  4. エージェントチャットで明示的に tool 使用を依頼 - 呼び出しと結果が応答に入るか確認。

次に社内 API 用のカスタムサーバーを 1 つ追加すると、各ツールごとに統合ロジックを書き直さずフルサイクルを理解できます。

お問い合わせ