MCP サーバーとは？ 2026年の MCP と MCP UI の仕組み

2025年4月1日、Invariant Labs は add というツールを公開しました。2つの数値を受け取り、その合計を返すだけのツールです。ところが説明文には IMPORTANT と記されたブロックが仕込まれていました。クライアントの画面には表示されないこのブロックは、~/.cursor/mcp.json と ~/.ssh/id_rsa を読み取り、使われていないパラメーター経由で両方のファイルを外部に送るようモデルに指示していました。モデルは従いました。ユーザーに見えたのは足し算だけです。

このデモは、私が知る限り MCP サーバーへの最も役に立つ入門です。2つの側面を同時に見せてくれるからです。プロトコルは設計どおりに動きました。AI クライアントがツールを発見し、説明文を読み、呼び出しました。まだ誰も作っていなかったのは、信頼モデルのほうです。

MCP サーバーとは

MCP サーバーとは、Model Context Protocol（MCP）を通じて AI アプリケーションにツール、データ、プロンプトを公開するプログラムです。公式ドキュメントは MCP を「AI アプリケーションを外部システムに接続するためのオープンソース標準」と定義しています。Claude、ChatGPT、Visual Studio Code、Cursor などの AI クライアントがサーバーに接続し、何を提供しているかを尋ね、ユーザーに代わってその機能を呼び出します。

Anthropic は2024年11月25日に MCP を発表し、Google Drive、Slack、GitHub、Git、Postgres、Puppeteer の6つの構築済みサーバーを用意しました。OpenAI は2025年3月に採用し、Google DeepMind が4月に続きました。2025年12月、Anthropic はプロトコルを Agentic AI Foundation に寄贈しました。Linux Foundation の傘下にある指定基金で、Anthropic、Block、OpenAI が共同で設立したものです。

問題は接続の組み合わせが増えることです。MCP以前は、GitHubにアクセスしたいAIアプリごとに専用コネクターが必要で、提供側もアプリごとの接続を作っていました。10モデルと10ツールなら最大100件の統合です。MCPでは各クライアントがプロトコルを一度実装し、各システムがサーバーを一つ公開するため、20件に減らせます。

AI 連携における輸送用コンテナだと考えてください。コンテナが登場する前は、どの港でもあらゆる積み荷を手作業で積み込み、港ごとに専用のクレーンと作業員がいました。コンテナが箱を標準化したことで、どの船、クレーン、トラックでもあらゆる貨物を運べるようになりました。ただし、箱の中身までは標準化しませんでしたし、中身を検査することもありませんでした。MCP も同じ取引です。この後半の部分を覚えておいてください。セキュリティの章でまた出てきます。

MCP サーバーの仕組み

現在の仕様（バージョン 2026-07-28）では、3つの役割の間で JSON-RPC 2.0 のメッセージをやり取りします。仕様自身の説明はわずか3行です。ホストは「接続を開始する LLM アプリケーション」、クライアントは「ホストアプリケーション内のコネクター」、サーバーは「コンテキストと機能を提供するサービス」です。

ホスト、クライアント、サーバー

ホストは、あなたが文字を入力するアプリケーションです。Claude Desktop、IDE、自作のエージェントなどがこれにあたります。その中で、サーバー接続ごとに1つのクライアントが動きます。サーバーは反対側にいて、実際のシステムとやり取りします。相手は Postgres データベースのこともあれば、GitHub API やディスク上のフォルダーのこともあります。モデルに何を見せ、ユーザーに何を承認させるかはホストが決めます。基盤となるシステムに何をさせるかはサーバーが決めます。

1. ホスト Claude Desktop · IDE · 自作のエージェント

   モデルにツールを見せ、ユーザーに同意を求める

2. クライアント サーバー接続ごとに1つ

   stdio または Streamable HTTP 上で JSON-RPC を話す

3. MCP サーバー ツール · リソース · プロンプト

   提供内容を記述し、呼び出しを実行する

4. 基盤システム データベース · SaaS API · ローカルファイル

   実際の処理を行う

ツール、リソース、プロンプト

サーバーが提供できるものは3種類あります。

• ツールは、モデルが実行できる関数です。create_issue、query_orders、send_email などがあります。それぞれ名前、説明文、入力用の JSON Schema を持ちます。
• リソースは、ユーザーやモデルが読むためのコンテキストとデータです。ファイル、データベーススキーマ、レコードなどです。
• プロンプトは、ユーザーが選べるテンプレート化されたメッセージやワークフローです。たとえば「このプルリクエストを要約して」のようなものです。

注目を集めるのはツールです。実際に動作するからです。リスクの大半をツールが抱えているのも、同じ理由です。

ツール呼び出しの流れ

2026-07-28 リビジョンで、MCP はステートレスになりました。initialize ハンドシェイクはもうありません。すべてのリクエストが _meta フィールドにプロトコルバージョンとクライアントの機能を載せて送られます。サーバーは server/discover メソッドを実装しなければならず、クライアントはサーバーが何に対応しているかを最初に確認できます。現在、1回のツール呼び出しは次のように進みます。

1. ユーザーの依頼: このバグのチケットを作成して

2. ステップ1

   発見

   • クライアントは server/discover を呼び出して、バージョンと機能を確認できる
3. ステップ2

   ツールの一覧

   • tools/list が名前、説明文、入力スキーマを返す
4. ステップ3

   モデルがツールを選ぶ

   • ホストがツール定義をモデルに渡す
5. ステップ4

   ユーザーの同意

   • 仕様では、ホストはツールを呼び出す前に明示的な同意を得なければならない
6. ステップ5

   呼び出し

   • 引数付きで tools/call を実行し、プロトコルバージョンは _meta に入れる

7. 入力が足りない場合、サーバーは input_required を返し、クライアントは回答を添えて再試行する

   ステップ6

   結果

8. 結果はコンテキストとしてモデルに戻る

ステップ6はこのリビジョンで新しく加わりました。追加の情報が必要なサーバーは、もうクライアントに独自のリクエストを送り返しません。input_required とマークした結果を返し、クライアントが回答を集めて、元の呼び出しを再試行します。仕様はこれを Multi Round-Trip Request パターンと呼んでいます。

トランスポート：stdio と Streamable HTTP

仕様は2つの標準トランスポートを定義しています。

• stdio：クライアントがサーバーをサブプロセスとして起動し、標準入出力を通じて改行区切りの JSON-RPC をやり取りします。ほとんどのローカルサーバーはこの方式で動きます。つまり、サーバーはあなたのマシン上で、あなたの権限で動くということです。
• Streamable HTTP：各メッセージは単一のエンドポイントへの HTTP POST で、返信は JSON オブジェクトか、リクエスト単位のイベントストリームとして返ってきます。リモートでホストされるサーバーはこの方式で動きます。

古い HTTP+SSE トランスポートは正式に非推奨になりました。2026-07-28 リビジョンでは、プロトコルレベルのセッションと Mcp-Session-Id ヘッダーも削除されました。呼び出しをまたいで状態を保つ必要があるサーバーは、自分でハンドルを発行し、それを通常のツール引数として受け取ります。

認可

MCP の認可は任意で、HTTP にだけ適用されます。stdio の場合、仕様はサーバーが認証情報を環境から取得するよう求めています。HTTP の場合、保護された MCP サーバーは OAuth 2.1 のリソースサーバーとして振る舞います。クライアントが認可サーバーを見つけられるよう、OAuth Protected Resource Metadata（RFC 9728）を公開しなければなりません。クライアントは、トークンの宛先となるサーバーを正確に指定しなければなりません（RFC 8707 のリソースインジケーター）。サーバーは自分宛てに発行されていないトークンをすべて拒否しなければなりません。さらにセキュリティガイダンスは、クライアントのトークンをそのまま下流の API に転送する「トークンパススルー」を明示的に禁止しています。

この最後のルールは見た目以上に重要です。受け取ったトークンを何でも中継するサーバーは、トークンを持つ誰にとってもプロキシになってしまいます。

MCP UI が加えるもの：インターフェースを返すサーバー

ユーザーが40行を比較したり、12項目のフォームを調整したり、一括の変更を1件ずつ承認したりする必要が出た瞬間、テキストの回答は役に立たなくなります。「MCP UI」は、その解決策を探す人が検索する名前です。サーバーがインタラクティブなインターフェースを返し、それが AI クライアントの中、会話のすぐ隣に表示されます。

経緯は正確に押さえておきましょう。発端はコミュニティープロジェクトのMCP-UIです。OpenAIはApps SDKに類似の仕組みを実装しました。MCPプロジェクトは2025年11月21日に両者と共通規格を提案し、2026年1月26日に最初の公式MCP拡張としてMCP Appsを公開しました。MCP-UIのパッケージは現在この仕様を実装し、今後の改善を試す場にもなっています。

つまり、今日の MCP UI とは MCP Apps のことです。公式であり、コアプロトコルではなく拡張です。拡張はオプトインで、クライアントとサーバーの両方が対応している必要があります。ドキュメントもはっきりと「ホストの対応状況はクライアントによって異なる」と書いています。MCP Apps のドキュメントは、対応ホストとして Claude、Claude Desktop、VS Code GitHub Copilot、Microsoft 365 Copilot、Goose、Postman、MCPJam、Archestra.AI を挙げています。ツールが UI を返すサーバーでも、テキストしか表示しないクライアントで動作しなければなりません。

仕組みの面では、MCP 自身の部品を再利用しています。

1. ツールの説明文に、ui:// リソースを指す _meta.ui.resourceUri を含めます。
2. ホストはそのリソース（スクリプト付きの HTML ページ）を取得します。ツールが呼び出される前に先読みしておくこともできます。
3. ホストはそれをサンドボックス化された iframe で表示します。この iframe は親ページにも、その Cookie やストレージにもアクセスできません。
4. アプリとホストは、MCP の JSON-RPC 方言を使い postMessage で通信します。アプリはツール呼び出しを要求でき、どれを許可するかはホストが決めます。

コストは現実のものです。他社のアプリケーションの中に Web フロントエンドを出荷することになり、宣言が必要なコンテンツセキュリティポリシー、自分では制御できない表示ルール、UI を無視するすべてのホスト向けのテキストのフォールバックがついてきます。その代わりに、承認作業がチャットの書き起こしではなくなります。ドキュメント自身が挙げる適した用途の一覧は、「経費精算の承認、コード変更のレビュー、課題のトリアージ」で締めくくられています。これこそが本質を正直に表しています。MCP UI が力を発揮するのは意思決定で、装飾ではありません。

読み取り専用のTajo例

TajoのAlto MCPには、接続済みワークスペースに保存された連絡先を検索するquery_contactsがあります。既存の連絡先をメールアドレスで検索し、返されたID、メール同意の状態、最終確認時刻を調べます。別のget_contact_topic_statusは、その連絡先のトピック別購読状況を読み取ります。

これらはワークスペース内の読み取りです。提供元から最新スナップショットを取得したり、同期を開始したり、メッセージを送ったりしません。すべての提供元コネクターが稼働している証拠にもなりません。欠落や古いデータは元のシステムで調べてください。空の結果は、その人がBrevoに存在しない証明ではありません。

Tajo MCPドキュメントを使って対応クライアントを接続し、許可されたワークスペースが実際に公開するツールを確認してください。ホストがMCP Appsに対応していれば対話パネルが役立ちますが、テキスト結果にも結論を示す必要があります。

ツール呼び出しは継続的な同期ではない

定期同期には、実行予定、安定したレコードID、保存された進捗、再試行の判断、完了した書き込みの記録も必要です。これらは実行アプリの責任です。MCPが標準化するのはツールへのアクセスであり、一覧表示だけで業務上の規則は生まれません。

タイムアウト後の読み取りは通常再試行できます。一方、送信や決済は既に実行済みかもしれません。再試行前に実行記録を保持し、結果を照合してください。モデルの確信度は操作の許可にも、再試行の安全性にもなりません。

具体的な連絡先の宛先書き込みはBrevo APIガイドをご覧ください。計算項目を独立した管理対象の同期にする判断はreverse ETLで説明します。

セキュリティのコストはプロトコルについてくる

まず反論を省略せずに紹介します。「MCP は、データを削除したりメールを送信したりできる関数の一覧を確率的なモデルに渡し、その説明を見知らぬ他人が書いたテキストに任せている。これは連携の標準ではない。仕様書付きのサプライチェーン攻撃だ」。その大部分は正しい指摘です。仕様も前提には同意しています。セキュリティの章には、ツールは「任意のコード実行に相当し、適切な注意をもって扱わなければならない」こと、ツールの説明文は「信頼できるサーバーから取得したものでない限り、信頼できないものと見なすべき」こと、そして MCP は「これらのセキュリティ原則をプロトコルレベルで強制できない」ことが書かれています。

これまでの記録は次のとおりです。

• ツールポイズニング。 2025年4月の Invariant Labs による公表で、冒頭で紹介した add ツールの件です。同じ記事では、承認後にサーバーがツールの説明文を書き換える「ラグプル」と、悪意あるサーバーが信頼済みの別のサーバーに対するモデルの振る舞いを書き換える「シャドウイング」も説明されています。
• ローカルサーバーの侵害。 2025年7月、JFrog は mcp-remote のバージョン 0.0.5 から 0.1.15 に存在する CVE-2025-6514 を公表しました。悪意あるサーバーがユーザーのマシン上でコマンドを実行できる脆弱性です。同じ夏には、Anthropic 自身の MCP Inspector で CVE-2025-49596 が見つかりました。MCP Inspector は、デフォルトで認証なしの状態で配布されていました。
• スコープの肥大化。 公式のセキュリティのベストプラクティスは、このパターンを名指ししています。サーバーがすべてのスコープを列挙し、クライアントがそれを全部要求した結果、最初から files:* や admin:* を付与されたトークンです。
• 公的機関の懸念。 2026年5月、米国家安全保障局（NSA）は、MCP の「急速な普及が、そのセキュリティモデルの発展を追い越している」と述べました。

反論が誤っているのは結論です。解決策は、モデルをシステムにつなぐのをやめることではありませんでした。チームはすでに、生の API キーをプロンプトやスクリプトに貼り付け、監査証跡もまったくない状態で同じことをしていました。解決策は、MCP サーバーをほかの特権的な依存関係と同じように扱うことです。

• MCP の外でも同じ認証情報を任せられる提供元からだけ、サーバーをインストールする。
• 長期間有効なキーを抱えたローカルのバイナリより、OAuth と狭いスコープを使うリモートサーバーを選ぶ。
• すべての書き込みに人間の承認を必須にし、誰が何を承認したかを記録する。
• サーバーのバージョンを固定し、ツールの説明文が変わったら再レビューする。
• API 全体ではなく、タスクに合わせたツールを公開する。公開されていない削除エンドポイントは、モデルにも悪用できない。

プロトコルは箱を標準化しました。積み荷の検査は、今もあなたの仕事です。

MCP サーバーを自作するか、既存のものを使うか

mcp.so のような公開ディレクトリはコミュニティ製のサーバーを集めており、多くの SaaS ベンダーも独自のサーバーを公開しています。たとえば Brevo は MCP サーバーを提供しており、これは個別のサーバーにも分割されています。そのため、エージェントにキャンペーンは渡さず、コンタクトだけを渡すこともできます。判断の分かれ目は手間よりも、ツールの形を誰が決めるべきかです。

エージェントはどの MCP サーバーを使うべきか？

1. ベンダーがタスクをカバーするサーバーを公開している

   ベンダーのサーバーを使う

   API の変更に追随し、ベンダーが保守している。

2. システムは1つだが、操作を減らしたい、または安全にしたい

   スコープを絞って使う

   スコープを最小限にし、エージェントに必要なツールグループだけを公開する。

3. 社内データ、またはサーバーのないシステム

   小さなサーバーを作る

   自社の API の上に、自社の認証で、タスクに合わせた少数のツールを置く。

4. タスクが2つ以上のシステムにまたがる

   統制されたレイヤーを構築または導入する

   すべてのシステムに共通する、1組のツール、同意ルール、監査履歴。

基本的なサーバーを作るのは簡単な部分です。公式 SDK を使えば、ツールを1つ持つ動作する stdio サーバーは午後のうちに完成します。コストは後からやってきます。HTTP 版のための OAuth、非推奨化への対応（2026-07-28 リビジョンでは Roots、Sampling、Logging、Dynamic Client Registration が非推奨になりました）、そしてモデルが正しく読めるツールの説明文を書き続ける仕事です。最もよくある失敗は、API をエンドポイントごとに1つのツールとしてラップすることです。ツールの説明文はどれも、モデルが読んで比較検討しなければならないテキストです。だからこそ、タスクに合わせた短いツールの一覧のほうが、API の全体よりも優れています。

MCP、API、インテグレーション、iPaaS

MCP は API を置き換えません。ほぼすべての MCP サーバーは API のラッパーです。実際の処理は今も API で行われ、API には独自のレート制限、データモデル、癖があります。MCP が変えるのは、誰が API を呼び出せるかです。開発者があらかじめハードコードするのではなく、モデルが実行時に説明文を読んで呼び出しを選びます。

この違いによって、MCP とよく混同される他の2つのものとの間に、はっきりと線を引けます。

• インテグレーションと iPaaS（主なプラットフォームの比較はこちら）は、チャットに誰かがいるかどうかに関係なく、スケジュールやトリガーに基づいて決定論的にデータを移動します。40,000件の注文を毎晩 CRM に同期する処理が、モデルが40,000回のツール呼び出しを決めるかどうかに左右されるべきではありません。
• リバース ETL は、データウェアハウスで整形したデータを業務ツールに書き戻します。リバース ETL とは何か、どんな場面に合うかはそれ自体が1つのテーマであり、会話ではなくパイプラインです。
• MCP は、人やエージェントがそれらのシステムをまたいで、必要なときに質問し、確認し、操作するための仕組みです。

間違いは両方向で起きています。MCP サーバーで一括同期をしようとするチームは、遅く、高コストで、再現性のないパイプラインを手にします。丁寧にインテグレーションを構築したのに、それを照会するために AI アシスタントに生の API キーを渡すチームは、統制のない裏口を手にします。

対応する統合では、継続ジョブとその確認ツールで明確な権限境界を共有すべきです。対象の作業についてコネクター、許可された操作、記録された結果を確認してください。統合ドキュメントは設定方法と本番での実証がまだ必要な経路を区別しています。MCPで承認済みのツールを個別に公開できても、一覧だけでは定期同期や必要な制御が有効だとは分かりません。

22か月で、MCP は6つのリファレンスサーバーから、Claude、ChatGPT、VS Code、Cursor のすべてが話す Linux Foundation のプロジェクトになりました。モデルをシステムにつなぐことは、今や安い部分です。そこで何をしてよいかを決めることこそが、本当の仕事です。