MCPが変えるインターフェースの未来

「AIに話しかけるたびに、なぜこんなに画面を行き来しないといけないんだろう」

先日、GitHubのIssueを確認しながらSlackで返信し、Notionにメモを貼り、Jiraのチケットを更新する——という一連の作業をしていた。それぞれの画面を4つ開いて、コピペを繰り返しながら、「ClaudeやChatGPTに頼んでいるのに、なぜ私がこんなに手を動かしているんだ？」と感じた瞬間があった。

AIは賢くなっている。でも、AIが賢くなるほど「AIとツールの間の壁」が気になってくる。

Model Context Protocol（MCP）が注目を集めているのは、まさにこの壁を壊そうとしているからだ。

MCPとは何か

MCP（Model Context Protocol） は、2024年11月にAnthropicがオープンソースで公開した標準プロトコルだ。一言で表すなら「AIアプリケーションと外部システムをつなぐための共通言語」である。

公式ドキュメントはこう説明している。

MCP is an open-source standard for connecting AI applications to external systems.

ClaudeやChatGPTのようなAIアプリケーションが、ファイルシステム・データベース・Slack・GitHub・Figmaといった外部システムに、統一された方法でアクセスできるようにする仕組みだ。

2026年4月現在、Claude Desktop、ChatGPT、Visual Studio Code、Cursor、MCPJam など多数のクライアントがMCPをサポートしており、事実上の標準になりつつある。

USB-Cに例えると一発でわかる

公式ドキュメントはMCPを「AIアプリケーションのUSB-Cポート」と形容している。これが絶妙な比喩だと思う。

USB-Cが登場する前、デバイスを繋ぐたびに「このケーブル合う？」と確認していた。MacはMagsafe、iPhoneはLightning、AndroidはMicro-USB、カメラはSDカード…それぞれに専用の変換器が必要だった。USB-Cは「どのデバイスも同じポートで繋がる」という標準化によってこの煩雑さを解消した。

AIの世界も同じ問題を抱えていた。

SlackのボットにはSlack専用のAPI
GitHub Copilotには専用のIDEプラグイン
Notionとの連携には専用のOAuth実装

それぞれが独自実装で、ひとつのAIが複数のツールを使おうとすると、ツールごとに異なるコードを書く必要があった。

MCPは「どのAIアプリケーションも、どのツールも、同じプロトコルで繋がる」という統一規格を提供する。開発者はMCPサーバーを一度作れば、ClaudeでもChatGPTでもCursorでも使えるようになる。

アーキテクチャを理解する：Host・Client・Server

MCPはシンプルな3層構造を持つ。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
┌──────────────────────────────────────────┐
│        MCP Host（AIアプリ）               │
│  ┌──────────┐  ┌──────────┐             │
│  │MCP Client│  │MCP Client│  ...        │
│  └────┬─────┘  └────┬─────┘             │
└───────┼─────────────┼────────────────────┘
        │             │
  ┌─────▼──────┐ ┌────▼──────────┐
  │ MCP Server │ │  MCP Server   │
  │ (Filesystem│ │  (GitHub API) │
  └────────────┘ └───────────────┘

Host：Claude Desktopや VS CodeのようなAIアプリケーション
Client：Hostの中でServerへの接続を管理するコンポーネント
Server：外部ツールやデータソースへのアクセスを提供するプログラム

Hostは複数のClientを持てる。つまり、ClaudeがGitHub・Notion・ローカルファイルシステムの全てに同時にアクセスしながら作業することが、MCPの仕組みの上で実現できる。

接続方式は2種類ある。

方式	特徴	使いどころ
STDIO	ローカル実行、単一クライアント	ファイルシステム、ローカルDB
Streamable HTTP	リモート実行、複数クライアント	SaaS連携、Webサービス

MCPの3つのプリミティブ

MCPがサーバーからクライアントに提供できるものは3種類に分類される。

1. Tools（ツール）

AIが「呼び出せる関数」。検索実行、ファイル作成、コード実行など、AIが能動的にアクションを起こすときに使う。

例：search_github_issues(query="login error")

2. Resources（リソース）

AIが「読み取れるデータ」。ドキュメント、データベースのレコード、ログファイルなど、AIがコンテキストとして参照する情報。

例：file://./README.md、postgres://db/users

3. Prompts（プロンプト）

再利用可能なプロンプトテンプレート。特定の作業パターンを定義し、一貫した指示をAIに与えるための仕組み。

例：コードレビュー用のプロンプトテンプレートをサーバー側で管理

この3つの組み合わせで、AIは「見て・判断して・行動する」という一連のフローをこなせるようになる。

実際に何が変わるのか

抽象的な話が続いたので、具体例で考えてみる。

Before MCP：従来の開発フロー

朝、バグレポートがSlackに届いた。

Slackを開いてメッセージを読む
GitHubのIssueを開いてエラーログを確認する
Sentryを開いてスタックトレースを確認する
ローカルのコードをエディタで開く
ClaudeにURLとスタックトレースをコピペして「原因を調べて」と依頼する
Claudeの回答を受けて、自分でコードを修正する
PRを作成し、Jiraのチケットを更新する

このフロー、AIに依頼しているのに人間がデータの運搬係になっている。

After MCP：MCPがある開発フロー

朝、Slackに届いたバグレポートをClaudeに転送する。

Claude（MCP対応）がSlack MCPサーバー経由で関連スレッドを自動収集
GitHub MCP サーバーで関連Issueとコードを確認
Sentry MCP サーバーでスタックトレースを取得
ローカルファイルシステムサーバーでコードを参照
原因を特定して修正案を提示、OKなら直接PRを作成
Jira MCP サーバーでチケットを自動更新

AIが自律的にツールをまたいで動く。人間は「何をしたいか」を伝えるだけでよくなる。

実際に動いているMCPサーバー

2026年現在、以下のようなMCPサーバーが公式・コミュニティから提供されている。

Filesystem — ローカルファイルの読み書き
GitHub — リポジトリ操作、Issue・PR管理
Sentry — エラーログ・スタックトレース取得
PostgreSQL / SQLite — データベースクエリ実行
Slack — メッセージ送受信、チャンネル管理
Figma — デザインデータ読み取り（Claude Codeと連携してコード生成）
Blender — 3Dモデル操作（3Dプリンター連携まで）
Google Maps — 地図・施設情報取得

Figmaからコードを生成し、Blenderで3Dモデルを操作し、GitHubにPRを出す——これらが会話ひとつでつながる世界が、今まさに動き始めている。

インターフェースの未来：「会話が唯一のUIになる日」

ここからは少し先の話をしたい。

MCPが普及すると、私たちはどんな体験をするのだろう。

フロントエンドの意味が変わる

これまでフロントエンド開発とは「ユーザーが操作するGUI（グラフィカルインターフェース）を作ること」だった。ボタン、フォーム、ナビゲーション——これらは全て「人間が直接操作するもの」として設計されてきた。

MCPが普及した世界では、AIが中間層として機能する。ユーザーはClaude（やその後継）に話しかける。ClaudeはMCPサーバーを通じてアプリケーションを操作する。

つまり、アプリのUIは「AIが操作するAPI」として再設計される可能性がある。GUIは人間向けに残りながら、AIエージェント向けのMCPインターフェースが並列で存在する、という二層構造の時代が来るかもしれない。

「検索する」という行為の消滅

いまのGoogle検索は「キーワードを入れる → リンクリストを見る → ページを開く → 情報を探す」という4ステップだ。

MCPがWebに統合されれば、「旅行先でおすすめのラーメン屋を今いる場所から歩ける距離で探して、空席を確認して予約まで入れておいて」という自然言語の一文で完了する。

検索エンジンのUXが前提にしてきた「ユーザーが情報を探す旅」が、根本から変わる。

コマンドラインの復権

皮肉なことに、MCPが進化するとコマンドラインが最強のインターフェースに戻ってくる可能性がある。

テキストによる命令は、AIにとって最も処理しやすいフォーマットだ。GUIのボタンを認識するより、create issue --title "login error" --repo myapp のようなテキストの方がAIには扱いやすい（そしてMCPのToolsとして定義しやすい）。

「ターミナルが怖い」世代にとっては逆説的だが、会話UIという形の「次世代のコマンドライン」が、エンジニア以外にも開かれていく——そういう未来が見えてくる。

課題と懸念点

もちろん、バラ色の話ばかりではない。

セキュリティが最大の懸念だ。MCPサーバーがローカルファイルやデータベースにアクセスできるということは、悪意あるMCPサーバーをインストールしてしまえば、情報を丸ごと持ち出されるリスクがある。現状、MCPサーバーの「署名・検証」の仕組みは発展途上であり、インストール前のソース確認が必須だ。

標準化の分裂も起きつつある。OpenAIはMCPを採用しているが、Googleの独自エコシステムとの統一はまだ不完全だ。USB-Cも普及まで時間がかかったように、真の「USB-C的統一」が来るのはもう少し先かもしれない。

エージェントの暴走問題もある。MCPでAIが自律的に動けるようになると、「意図と違う操作を勝手にやってしまった」というリスクが上がる。人間の承認を入れるゲートをどこに設けるかは、UX設計の大きな課題になる。

まとめ

MCPを一言で言うなら「AIとツールの間の翻訳コストをゼロにする取り組み」だ。

USB-Cが「デバイスをつなぐ前の煩雑さ」を解消したように、MCPは「AIが使えるものを使う前の煩雑さ」を解消しようとしている。

注目すべきは、これが単なるAIの話ではないということだ。MCPはインターフェース設計の哲学を変える。「ユーザーが操作する」ではなく「AIが代行する」前提でシステムを設計する時代が来ている。

エンジニアとして、この変化をどう活かすか——あるいはどう乗り遅れないか——を考え始めるのに、今がちょうどいいタイミングだと思う。

まずは Claude Desktop に好きなMCPサーバーをひとつ入れてみることから始めてみよう。「AIに話しかけるだけでGitHubのIssueが作れた」という体験が、インターフェースの未来をリアルに感じさせてくれるはずだ。

firebirdテックトーク