← ブログに戻る

MCP サーバーとは何か — 開発者のための入門

· 7 分で読めます

一文で定義するなら

MCP (Model Context Protocol) サーバーとは、ツール・リソース・プロンプトを標準化された JSON-RPC 形式で LLM クライアントに公開するローカルプログラムであり、双方が独自の連携を作らずに、モデルがユーザー自身のマシン上でデータを読み取ったり操作を実行したりできるようにするものです。

定義は以上です。残りの節で中身をほどいていきます。

Anthropic はなぜ MCP を作ったのか

MCP 以前、LLM と外部システムをつなぐ実装はすべて独自の接着剤でした。ChatGPT プラグインにはプラグインのやり方があり、Copilot のツール呼び出しは別のやり方で、Cursor は自前のファイル編集連携を出していました。どのベンダーも「一覧する・読む・実行する・ツールを説明する」の同じ 4 つのプリミティブを再発明していたのです。結果として、ベンダーごとに囲い込みが生まれ、ツール作者にはメンテナンス負荷が残りました。

Anthropic は 2024 年末に MCP を、どの LLM クライアントでも話せてどのツール作者でも実装できる、小さくて地味なプロトコルとして発表しました。選んだトランスポート (stdio か HTTP) の上に JSON-RPC を載せ、探索と呼び出しのメソッドは固定です。凝ったところは意図的にありません。それが狙いです。

18 か月ほどで、ニッチな Anthropic の規格から、Claude Desktop・Cursor・GitHub Copilot のエージェントモード・Continue・Windsurf・Zed が揃って対応する存在になりました。クライアントはどれも同じサーバーに対して同じ MCP のハンドシェイクを行います。つまり、HTTP トラフィックを読むツールなどを一度書けば、どの IDE でも動くわけです。

stdio と HTTP トランスポートの違い

MCP は 2 種類のトランスポートをサポートします。stdio (クライアントがサーバーを子プロセスとして起動し、標準入出力で話す) と HTTP (サーバーがポートで待機し、クライアントが接続する)。選択には実際的な意味があります。

stdio トランスポート はクライアントと同じマシンで動くツール向けです。MCP サーバーはクライアントが起動するバイナリかスクリプト。ネットワークポートなし、認証レイヤーなし。プロセス境界がセキュリティ境界です。ローカル用途 — ファイルシステム、ノート PC 上のデータベース、Rockxy のような HTTP プロキシ、ほかにも「モデルがあなたのマシンを触ること自体が目的」というツール — には、これが妥当なデフォルトになります。

HTTP トランスポート は別の場所で動くツール向けです。リモートのデータベース、MCP アダプター付きの SaaS API、チーム共有のサーバーなど。サーバーは長時間有効な HTTP エンドポイントを公開し、時間のかかるツール呼び出しはストリーミングで返すのが一般的です。認証、TLS、その他 HTTP として当然やるべきセキュリティ対策が必要になりますが、そのぶん複数クライアントが 1 台のサーバーを共有できます。

目安としては、ツールがユーザー自身のマシンやユーザー自身のデータに関するものなら stdio。共有システムに関するものなら HTTP。stdio で足りる場面で HTTP を使わないこと。localhost で待ち受ける HTTP サーバーも依然として攻撃面です。

MCP の面 — tools、resources、prompts

MCP サーバーは 3 種類のものを公開できます。それぞれ用途が違います。

Tools

ツールはモデルが呼び出せる関数です。名前、説明、入力の JSON Schema、戻り値の形を持ちます。モデルから見ると、ほかの関数呼び出しインターフェースと区別がつきません。

{
  "name": "list_flows",
  "description": "List recent HTTP flows captured by the proxy.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "host": { "type": "string" },
      "method": { "type": "string" },
      "status": { "type": "integer" },
      "limit": { "type": "integer", "default": 20 }
    }
  }
}

Resources

リソースは、サーバーがモデルに参考資料として渡せるコンテンツです。ファイル、URL、データベースからの抜粋など。リソースは URI でアドレス指定されます。「モデルが呼び出す関数」より「モデルが読むコンテキスト」に近い位置付けです。

ファイルシステムの MCP サーバーは、あらゆるファイルをリソースとして公開するかもしれません。HTTP デバッグ用サーバーは、キャプチャした各フローのレスポンスボディをリソースとして公開することがあります。

Prompts

プロンプトは、サーバーがクライアントに提示する再利用可能なテンプレートです。「このフローの脆弱性サマリーを作って」といった保存済みクエリにパラメーターをつけたもの、と考えればよいでしょう。クライアント側ではスラッシュコマンドやクイックアクションとして表示されます。プロンプトまで用意するサーバーは多くありません。3 つのプリミティブの中では一番使われていません。

良い MCP サーバーの条件

長く生き残る MCP サーバーとデモ止まりのサーバーを分けるのは、次の 4 点です。

ツール面が狭い。 Rockxy の MCP サーバーはツール 4 つを公開します。Linear の MCP サーバーならチケット・チーム・プロジェクト・サイクル・ラベル・コメントで 40 個公開もできますが、面が狭いほどモデルが扱いやすく、監査もしやすくなります。ツールが少なければ、他の MCP サーバーと名前が衝突する可能性も下がります。

可能な限り冪等。 読み取り系は副作用なしで繰り返せるべきです。書き込み系は冪等キーを受け取るか、自身で重複排除する設計に。LLM はリトライします。応答が遅いとき、ネットワークが途切れたとき、最初の試行が間違っていたとモデルが判断したとき、必ずリトライします。モデルが一度しか試していないのに重複リクエストを 3 つ作ってしまう再送信ツールはバグです。

ローカルファースト。 MCP サーバーは、ベンダーのクラウドではなくユーザーのマシン上で動くのがデフォルトであるべきです。データがもともとクラウドにある場合 (Notion の MCP サーバーのように本質的にクラウド前提のもの) はクラウドで問題ありませんが、ローカルのツールにクラウドの MCP ラッパーを被せるのは情報漏洩です。

監査可能。 ユーザーはツール呼び出しを自分のクライアントですべて見られるべきです。MCP 対応クライアントは既定でそのように作られています。サーバーの作者は、ツールの意味を名前から素直に読み取れるように保つべきです。隠れた副作用や、名前から推測できる以上のことをするツールは避けます。

エコシステムの具体例

MCP サーバーが公開しているものの具体例を挙げます。

  • Filesystem MCP。 read_file、list_directory、write_file のツール。設定したルート配下のファイルをリソースとして公開。アシスタントにコードベースをコピペなしで読ませるのに便利です。
  • GitHub MCP。 issue 一覧、PR 作成、リポジトリメタデータの取得のためのツール。ユーザーが用意したトークンを使い、GitHub API に対して HTTP トランスポートで叩くのが一般的です。認証付きのリモートですが、多くのクライアントではローカルの stdio 経由の薄いシムを挟みます。
  • Postgres MCP。 読み取り専用クエリを実行するツール。スキーマをリソースとして。面が狭く、冪等で、ローカル (ローカル DB を指す) という条件に収まります。
  • Rockxy MCP。 ツールは 4 つ: list_flows、get_flow_detail、replay_request、diff_flows。stdio トランスポート、ローカル専用、ソースは AGPL-3.0 で公開。Claude Desktop (およびその他の MCP クライアント) に HTTP トラフィックを読ませ、リクエストを再送信させられます。

どれも単一ドメインに絞られた小さなツール面です。どれも「すべてを扱う AI 連携レイヤー」にはなろうとしていません。この自制心がエコシステムを組み合わせ可能にします — クライアントは小さなサーバー 5 つを読み込んで、1 つずつ 1 つのことを任せます。巨大なサーバーに何もかもを詰め込むより、ずっと筋が良いのです。

2026 年の開発者が MCP を日常的にどう使うか

現実的な 2026 年の構成はこうです。リサーチとデバッグ用に Claude Desktop を立ち上げ、MCP サーバーを 3 つ読み込みます — ファイルシステム (作業ディレクトリに限定)、GitHub、Rockxy。claude_desktop_config.json はたぶん 30 行ほどです。

コード編集には Cursor を併用し、プロジェクト単位の .cursor/mcp.json でファイルシステムサーバーに加えて、プロジェクト固有のサーバー (例えば自社内製の MCP ゲートウェイ) を 1 つか 2 つ読み込みます。

2 つのクライアントはサーバーのバイナリを共有します。Rockxy を一度インストールすれば、Claude Desktop でも Cursor でも使えるようになります。設定ファイルの場所はクライアントごとに違いますが、つながる先のサーバーは同じです。共通プロトコルのご利益はここにあります。クライアントごとに連携を作り直さなくてよくなる。

日常の使い方はこんな感じです。Claude Desktop に「さっき失敗した API 呼び出しの中身は？」と聞けば、Rockxy に問い合わせに行きます。Cursor に「この関数をテストが通るように書き直して」と頼めば、ファイルシステムサーバーを呼んで読み書きします。クライアントにツールを教え込むためのボイラープレートは、もう書きません。

この先どこに向かうか

2026 年初頭の時点で、いくつかの傾向が見えています。

マルチエージェントの受け渡し。 MCP サーバーは対話型チャットクライアントだけでなく、お互いを呼び出し合うバックグラウンドエージェントにも使われ始めています。あるエージェントが受信 issue のトリアージを行い、見込みがあるものを別のエージェントに渡し、コードベースを読ませ、3 番目のエージェントに PR ドラフトを渡してテストを走らせる。どの受け渡しも MCP 呼び出しです。プロトコルはこれを目的に設計されたわけではありませんが、問題なく機能しています。

ファーストパーティの IDE 連携。 Xcode、Visual Studio、JetBrains 系 IDE などが MCP クライアントの対応を出荷済みまたは試作中です。1 年以内に、LSP を話すのと同じくらい当たり前に主要な IDE が MCP を話すようになるはずです。

サーバーのマーケットプレイス。 配布はまだ弱点です。ほとんどの MCP サーバーは JSON ファイルを手で編集してインストールします。マーケットプレイス層 — MCP サーバー版のアプリストアのようなもの — は自然な次の一歩で、いくつかのクライアントはその方向で開発を進めています。

認可とケイパビリティモデル。 現行の MCP 仕様は認可の扱いが軽めです。MCP サーバーを信頼するか、読み込まないかの二択に近い状態です。エコシステムが広がれば、ツール単位のケイパビリティ付与 (モデルは list_flows は呼べるが replay_request は呼べない、など) が標準になっていくでしょう。

小さくてスコープのきれいな MCP サーバーが実際に動くところを見たければ、Rockxy のセットアップガイド が 3 分で終わり、4 つのプリミティブが実際のデバッグワークフローに組み込まれる例をたどれます。

Rockxy をダウンロード MCP ツールを見る