MCP Serverとは？AIと外部サービスをつなぐ仕組みをClaude in Chromeから理解する

Posted at 2026-08-17

MCPサーバーは何をしているのか？ Claude in Chromeから理解するMCPの仕組みと現在地

こんにちは。neurestXでエンジニアをしている菅です。

最近、Claude CodeやCursorなどのAI開発ツールを触っていると、「MCP」という言葉を目にする機会がかなり増えました。

GitHubを操作するMCP、データベースに接続するMCP、ブラウザを操作するMCPなど、すでにさまざまなMCPサーバーが公開されています。

ただ、実際にMCPを使ってみると、最初に少し分かりにくい部分があります。

「MCPサーバーをインストールする」とは、いったい何をインストールしているのか。

「MCPに接続する」と言うけれど、実際にはどこからどこへ通信しているのか。

そして、AIが「このボタンをクリックして」と判断したとき、その指示はどうやって実際のブラウザ操作になるのか。

このあたりは、MCPを使うだけなら深く理解しなくても困りません。しかし、自分でMCPサーバーを作ったり、Remote MCP Serverを運用したり、AI Agentの仕組みを理解しようとすると、一度は整理しておきたいところです。

そこでこの記事では、MCPの歴史的な変化を追いながら、Claude in Chromeを具体例として、AIから外部サービスまでの通信がどのようにつながっているのかを見ていきます。

最初にMCPが登場する前のAIと外部サービスの接続方法を確認し、その後、ローカルMCP Serverの仕組み、stdioによる通信、Remote MCP ServerとStreamable HTTP、そして現在のMCPエコシステムまで順番に見ていきます。

なお、MCPは現在も仕様が活発に更新されている技術です。

そのため、この記事では「MCPとはこういうもの」と固定的に説明するのではなく、2026年8月17日時点で公開されている公式仕様・公式ドキュメントを基準にしています。

また、Claude in ChromeについてはAnthropicが公開している情報を参照し、MCPそのものの仕様とは分けて説明します。

この記事で扱うこと

この記事では、主に以下の内容を扱います。

MCPが登場する前、AIと外部サービスはどのように接続されていたのか
MCP Serverを「インストールする」とは何を意味するのか
MCP ClientとMCP Serverはどのように通信するのか
stdioでは実際に何が起きているのか
JSON-RPCはどこで使われているのか
Claude in ChromeではAIとブラウザがどのようにつながっているのか
Remote MCP ServerではHTTPがどのように使われるのか
Streamable HTTPとは何なのか
2026年のMCP仕様では何が変わったのか
現在どのようなMCP Serverが存在するのか

特に今回は、「MCP Serverを使ってみた」だけでは見えにくい通信部分を中心に見ていきます。

MCPを単なる「AIに便利なツールを追加する仕組み」としてではなく、AIと外部世界の間にどのような通信経路が作られているのか、という視点から見ていきたいと思います。

1-1. AIはもともと外部サービスを自由に操作できたわけではない

まず前提として、LLMそのものがGitHubやSlackなどの外部サービスへ自由にアクセスしているわけではありません。

例えば、AIに対して、

このリポジトリのIssueを確認して

とお願いしたとします。

LLMがその文章を受け取っただけでは、GitHubのAPIを呼び出してIssueを取得することはできません。

実際にGitHubから情報を取得するためには、AIとGitHub APIの間にプログラムが必要になります。

かなり単純化すると、次のような構成です。

ユーザー
  ↓
AI
  ↓
AIアプリケーション
  ↓
GitHub API
  ↓
GitHub

ここでAIが担当しているのは、ユーザーの入力を理解して、どのような処理が必要なのかを判断する部分です。

実際にHTTPリクエストを送ってGitHubからデータを取得する処理は、AIアプリケーション側のプログラムが担当します。

この「AIが判断する部分」と「実際に外部サービスを操作する部分」を分けて考えることが、MCPを理解する上でかなり重要になります。

1-2. Function Calling / Tool Calling

AIが外部の処理を実行する仕組みとして、以前から使われてきたのがFunction CallingやTool Callingです。

例えば、AIアプリケーション側にGitHubのIssueを取得する関数を用意しておきます。

getGithubIssue(
  repository,
  issueNumber
)

ユーザーが、

Issue #123を確認して

と入力した場合、AIはその場でIssueの内容を適当に生成するのではなく、

「GitHubからIssue #123を取得する必要がある」

と判断します。

そして、利用可能なToolの中から、先ほどの関数を呼び出すための情報を返します。

概念的には、

{
  "name": "getGithubIssue",
  "arguments": {
    "repository": "example/repository",
    "issueNumber": 123
  }
}

のような情報です。

AIアプリケーションはこの情報を受け取り、実際にGitHub APIを呼び出します。

ユーザー
  ↓
AI
  ↓
「getGithubIssueを実行する」
  ↓
AIアプリケーション
  ↓
GitHub API
  ↓
GitHub
  ↓
Issueの情報
  ↓
AIアプリケーション
  ↓
AI
  ↓
ユーザー

ここで一つ重要なのが、

「AIがGitHub APIを直接呼び出しているわけではない」

ということです。

AIは、利用可能なToolの中から「何を実行するか」を判断します。

その後、実際のAPI通信を行うのはAIアプリケーション側のプログラムです。

この考え方自体は、現在のMCPを理解するときにもそのまま出てきます。

1-3. では、Function CallingがあるのになぜMCPが必要なのか

ここまでを見ると、

「それならFunction Callingだけでいいのでは？」

と思うかもしれません。

実際、単純な構成であればそれでも問題ありません。

例えば、1つのAIアプリケーションにGitHubだけを接続するのであれば、

AI
 ↓
Function Calling
 ↓
GitHub API

でも十分です。

問題になるのは、接続するサービスやAIアプリケーションが増えてきたときです。

例えば、AIに次のサービスを使わせたいとします。

GitHub
Slack
Notion
Google Drive
PostgreSQL
Jira
AWS

それぞれにAPIが存在するため、AIアプリケーション側で各サービスとの連携処理を実装することになります。

すると、

AIアプリケーション
 ├── GitHub API用の実装
 ├── Slack API用の実装
 ├── Notion API用の実装
 ├── Google Drive API用の実装
 ├── PostgreSQL用の実装
 ├── Jira API用の実装
 └── AWS API用の実装

という状態になってきます。

さらに、別のAIアプリケーションでも同じサービスを利用したいとなると、また同じような連携処理を作ることになります。

例えば、

AIアプリケーションA ─── GitHub
AIアプリケーションA ─── Slack
AIアプリケーションA ─── Notion

AIアプリケーションB ─── GitHub
AIアプリケーションB ─── Slack
AIアプリケーションB ─── Notion

AIアプリケーションC ─── GitHub
AIアプリケーションC ─── Slack
AIアプリケーションC ─── Notion

という形です。

サービスが増えるほど、AI側に個別の連携処理が増えていきます。

1-4. MCPが作った「共通の接続方法」

そこで登場したのがMCPです。

Anthropicは2024年11月25日にModel Context Protocol（MCP）を発表しました。

MCPは、AIアプリケーションと外部のデータソースやツールを接続するためのオープンなプロトコルとして公開されています。

MCPを使う場合、AIアプリケーションが各サービスのAPIを直接扱うのではなく、その間にMCP Serverを置くことができます。

例えばGitHubなら、

AI
 ↓
MCP Client
 ↓
GitHub MCP Server
 ↓
GitHub API
 ↓
GitHub

という構成です。

Slackなら、

AI
 ↓
MCP Client
 ↓
Slack MCP Server
 ↓
Slack API
 ↓
Slack

となります。

AI側から見ると、GitHubとSlackで全く違う通信方法を個別に実装するのではなく、MCPという共通のルールを使ってMCP Serverと接続できます。

MCPの公式仕様では、MCP ServerはAIアプリケーションに対してTools、Resources、Promptsなどを提供できます。

例えばToolsなら、

「GitHubのIssueを取得する」
「Slackにメッセージを送る」
「データベースを検索する」

といった処理をAIから呼び出せるようにできます。

ここで重要なのは、MCP Serverが「AIそのもの」ではないということです。

MCP Serverは、AIが利用できる機能を公開しているサーバーです。

1-5. MCPはAPIの代わりになるものなのか

ここはMCPを調べていると少し混乱しやすい部分です。

MCPが登場したからといって、GitHub APIやSlack APIなどが不要になるわけではありません。

例えばGitHub MCP Serverの場合、内部では次のような構成になっていることがあります。

AI
 ↓
MCP Client
 ↓
GitHub MCP Server
 ↓
GitHub API
 ↓
GitHub

つまり、GitHub MCP ServerがGitHub APIを呼び出しているわけです。

この場合、MCP ServerはGitHub APIをAIから扱いやすい形に変換する「接続層」と考えることができます。

従来の構成が、

AIアプリケーション
 ↓
GitHub API

だったとすると、

MCPを利用した構成では、

AIアプリケーション
 ↓
MCP
 ↓
GitHub MCP Server
 ↓
GitHub API

という層が増えます。

一見すると遠回りにも見えます。

しかし、この「MCPという共通の層」があることで、AIアプリケーション側がサービスごとのAPI仕様を直接意識しなくても、MCPの仕組みに沿ってToolを利用できるようになります。

もちろん、すべてのMCP Serverが既存APIを単純にラップしているわけではありません。

例えばローカルファイルを扱うMCP Serverであれば、MCP Server自身がファイルシステムへアクセスすることもあります。

データベース用のMCP Serverであれば、MCP Serverからデータベースへ直接接続する構成も考えられます。

そのため、

「MCP Server = APIラッパー」

と覚えるより、

「AIと外部のツールやデータを接続するためのサーバー」

と考えた方が実態に近いです。

1-6. MCPが登場した当初はどのようなものだったのか

2024年11月にMCPが発表された時点では、現在ほど大きなエコシステムにはなっていませんでした。

Anthropicの発表では、MCPの仕様とSDKに加えて、Claude Desktopから利用できるローカルMCP Serverのサポートが提供されました。

また、GitHub、Google Drive、Slack、Postgres、Puppeteerなどを扱うMCP Serverも紹介されています。

ここからMCPの利用が広がり、現在ではさまざまなAIアプリケーションや開発ツールがMCPに対応しています。

ただ、初期のMCPを理解する上で重要なのは、

「MCP Serverはインターネット上のどこかにあるサーバーへアクセスするもの」

という現在のイメージだけで考えないことです。

初期には、ユーザー自身のPC上でMCP Serverを動かし、AIアプリケーションからローカルプロセスとして接続する使い方が中心でした。

つまり、

自分のPC

┌─────────────────────────┐
│                         │
│  Claude Desktop         │
│       ↓                 │
│  MCP Client             │
│       ↓                 │
│  MCP Server             │
│       ↓                 │
│  ファイル / DB / API     │
│                         │
└─────────────────────────┘

という構成です。

そして、この「MCP Serverを自分のPCで起動する」という仕組みが、後で出てくる「MCP Serverをインストールする」という話につながります。

1-7. ここまでを一度整理する

MCPが登場する前は、AIと外部サービスを接続するために、AIアプリケーション側が各サービスのAPIやToolを個別に扱う必要がありました。

AIアプリケーション
 ├── GitHubとの連携
 ├── Slackとの連携
 ├── Notionとの連携
 ├── DBとの連携
 └── その他サービスとの連携

MCPでは、その間に共通のプロトコルを置きます。

                 ┌── GitHub MCP Server
                 │
AI ── MCP ───────┼── Slack MCP Server
                 │
                 ├── Notion MCP Server
                 │
                 └── Database MCP Server

これによって、AIアプリケーションと外部サービスの接続方法をある程度共通化できます。

ただし、ここまで説明しただけではMCPの仕組みを理解したとは言い切れません。

「MCPという共通のルールを使う」と言っても、

「そのルールは実際にはどうやって通信しているのか？」

という疑問が残ります。

例えばローカルMCP Serverの場合、

Claude Desktop
    ↓
MCP Client
    ↓
？？？
    ↓
MCP Server

この「？？？」の部分では何が起きているのでしょうか。

ネットワークを経由しているのでしょうか。

それとも、同じPCの中で別の方法で通信しているのでしょうか。

また、MCP Serverを「インストールする」と言ったとき、実際には何がPCに入って、何のプロセスが起動しているのでしょうか。

次の章では、ここを実際の通信レベルまで掘り下げていきます。

参考・事実確認

この記事では、MCPの仕様や登場時期について、可能な限り公式情報を基準にしています。

Anthropic

「Introducing the Model Context Protocol」

MCPが2024年11月25日に発表されたこと、および発表時に仕様・SDK・ローカルMCP Serverのサポートや、GitHub、Google Drive、Slack、Postgres、PuppeteerなどのMCP Server実装が公開されたことを確認しています。

Model Context Protocol 公式ドキュメント

「What is the Model Context Protocol?」

MCPがAIアプリケーションと外部システムを接続するためのオープンスタンダードとして定義されていることを確認しています。

Model Context Protocol 公式仕様

MCP ServerがTools、Resources、Promptsなどを提供する仕組み、およびMCPにおけるClient / Serverの関係を確認しています。

2. MCP Serverを「インストールする」とは何なのか

前の章では、MCPが登場する前のAIと外部サービスの接続方法について見てきました。

MCPによって、AIアプリケーションと外部のツールやデータを接続するための共通のプロトコルができました。

ここからは、もう少し実装寄りの話に入ります。

MCPを使ったことがある人なら、

「MCP Serverをインストールする」

という操作をしたことがあると思います。

例えばNode.jsのMCP Serverなら、npmパッケージとしてインストールすることがあります。

npm install @modelcontextprotocol/sdk

ただ、ここで一つ疑問が出てきます。

「MCP Serverをインストールする」とは、実際には何をしているのでしょうか。

MCPというサーバーがPCの中に常駐するのでしょうか。

それとも、AIアプリケーションの中にMCPが組み込まれるのでしょうか。

結論から言うと、ローカルMCPの基本的な構成では、MCP Serverは独立したプロセスとして動作し、MCP Clientとstdin/stdoutを使って通信します。

この部分を順番に見ていきます。

2-1. MCP Serverは「AIの中」にインストールされるわけではない

まず、MCP Serverをインストールするときに一番勘違いしやすいのがここです。

MCP Serverをインストールしたからといって、AIモデルそのものに機能が追加されるわけではありません。

例えば、ローカルで動くMCP Serverを考えると、

Claude Desktop
      ↓
MCP Client
      ↓
MCP Server
      ↓
ファイルシステム / DB / API

というような構造になります。

MCP ServerはClaude Desktopとは別のプログラムです。

Claude DesktopなどのAIアプリケーションの中にはMCP Clientがあり、そのClientがMCP Serverと接続します。

つまり、

AIモデル
   ≠
MCP Server

です。

AIモデルは「どのToolを使うか」を判断する側で、MCP ServerはAIから利用できるToolなどを提供する側です。

2-2. 「インストール」されるものを考える

例えばNode.jsでMCP Serverを作った場合、実体は普通のNode.jsプログラムです。

MCP SDKを利用するなら、

npm install @modelcontextprotocol/sdk

のようにSDKをプロジェクトへ追加できます。

MCP TypeScript SDKでも、MCP Serverを構築するためのパッケージとして @modelcontextprotocol/sdk が提供されています。

そして、そのSDKを利用してMCP Serverを実装します。

例えば非常に単純化すると、

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

const server = new McpServer({
  name: "example-server",
  version: "1.0.0"
});

const transport = new StdioServerTransport();

await server.connect(transport);

というようなプログラムになります。

ここで重要なのは、これが特殊な「MCP専用の実行ファイル」ではないことです。

Node.jsで実行される普通のプログラムに、MCPの仕様に沿った通信処理を組み込んでいるだけです。

Pythonで作ることもできますし、公式SDKにはTypeScript、Python、C#、Rubyなど複数の実装があります。

2-3. Claude DesktopはどうやってMCP Serverを起動するのか

ここからが面白いところです。

ローカルMCP Serverの場合、MCP ClientがMCP Serverを子プロセスとして起動する構成があります。

MCPのTypeScript SDKでも、StdioClientTransport は指定されたコマンドを子プロセスとして起動し、そのプロセスのstdin/stdoutを使ってJSON-RPC通信を行います。

イメージとしては、

Claude Desktop
      │
      │ MCP Client
      │
      │ 「MCP Serverを起動」
      ↓
Node.js MCP Server

です。

OSのプロセスとして見ると、

Claude Desktop
   │
   └── MCP Serverプロセス
           └── node server.js

という親子関係になります。

つまり「MCP Serverを起動する」というのは、ローカルMCPの場合、実際にはNode.jsやPythonなどのプログラムを別プロセスとして起動することです。

2-4. では、プロセス同士はどうやって通信するのか

ここでネットワークの話が出てきます。

MCP Serverが同じPC上で動いているなら、

「localhostにHTTPリクエストを送っているのかな？」

と思うかもしれません。

しかし、ローカルMCPで使われる代表的なTransportはstdioです。

stdioはStandard Input / Standard Outputの略です。

つまり、

Claude Desktop
      │
      │ stdin / stdout
      ↓
MCP Server

という通信になります。

MCPの公式SDKでも、stdioは「ローカル統合向け」で、ClientがMCP Serverを子プロセスとして起動し、そのstdin/stdoutを介して通信する方式として説明されています。

2-5. stdinとstdoutとは何なのか

ここはMCPだけではなく、OSのプロセス間通信を理解する上でも重要です。

通常、ターミナルからプログラムを実行すると、

node server.js

のようになります。

このとき、Node.jsのプログラムには標準入力と標準出力が用意されています。

標準入力がstdin、

標準出力がstdoutです。

例えば、

ターミナル
   ↓ stdin
プログラム
   ↓ stdout
ターミナル

という関係になります。

MCPの場合は、この「ターミナル」の部分をMCP Clientが担当します。

つまり、

MCP Client
   ↓ stdin
MCP Server
   ↓ stdout
MCP Client

という構成です。

2-6. ここでJSON-RPCが登場する

ただし、stdinとstdoutだけでは、

「何を送ったのか」

「何を要求しているのか」

が分かりません。

そこでMCPでは、メッセージの形式としてJSON-RPCが使われます。

JSON-RPCは、JSON形式でRPC（Remote Procedure Call）を行うための仕様です。

MCPの通信をかなり単純化すると、

MCP Client
   ↓
JSON-RPCメッセージ
   ↓
stdin
   ↓
MCP Server
   ↓
処理
   ↓
stdout
   ↓
JSON-RPCレスポンス
   ↓
MCP Client

という流れになります。

例えば、概念的には次のようなJSONが送られます。

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {}
}

これは、

「このMCP Serverが提供しているToolの一覧を教えてください」

という要求として扱われます。

サーバー側からは、

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": []
  }
}

のようなレスポンスが返ってきます。

実際の仕様では、Toolの定義や引数のスキーマなども含まれますが、まずは、

「MCP ClientとServerがJSON-RPC形式のメッセージをやり取りしている」

と考えると分かりやすいです。

2-7. Toolを実行するときはどうなるのか

ここまで来ると、MCP ServerがToolを提供する仕組みも見えてきます。

例えば、MCP Serverが、

get_weather

というToolを提供しているとします。

AIが、

福岡の天気を調べて

と判断した場合、AIアプリケーションはMCP Clientを通してToolを呼び出します。

概念的には、

AI
 ↓
「get_weatherを使う」
 ↓
MCP Client
 ↓
tools/call
 ↓
MCP Server
 ↓
天気情報を取得
 ↓
結果を返す
 ↓
MCP Client
 ↓
AI

となります。

JSON-RPCの要求も概念的には、

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "location": "Fukuoka"
    }
  }
}

のようになります。

MCP Serverはこれを受け取って、実際の処理を行います。

例えば外部APIを呼ぶなら、

MCP Server
    ↓
天気API
    ↓
天気情報

という処理を行い、その結果をMCP Clientへ返します。

2-8. 「AIがToolを使う」という処理を分解すると

ここまでの処理を全部つなげると、かなり複雑に見えてきます。

例えば、

福岡の天気を調べて

という一文だけでも、裏では概念的に次のような処理が行われます。

ユーザー
  │
  │ 「福岡の天気を調べて」
  ↓
AI
  │
  │ Toolを使う必要があると判断
  ↓
MCP Client
  │
  │ tools/call
  ↓
JSON-RPC
  │
  │ stdin
  ↓
MCP Server
  │
  │ 天気APIを呼び出す
  ↓
天気API
  │
  │ 結果
  ↓
MCP Server
  │
  │ JSON-RPC response
  ↓
stdout
  │
  ↓
MCP Client
  │
  ↓
AI
  │
  ↓
ユーザー

普段Claudeなどを使っていると、この部分はほとんど意識することがありません。

しかし、MCP Serverを自分で作る場合には、この通信経路を理解しておくとかなり楽になります。

2-9. 実際のMCP Serverはどうやって起動するのか

ここでは、Node.jsでMCP Serverを実装したケースを考えてみます。

例えば、

node server.js

でサーバーが起動するとします。

通常のWebサーバーなら、

node server.js
      ↓
HTTP Server
      ↓
localhost:3000

のような形になります。

しかしstdioを使うMCP Serverの場合、

node server.js
      ↓
stdin / stdout

です。

つまり、HTTPポートを開いて待ち受ける必要がありません。

MCP Clientが、

node server.js

というプロセスを起動し、そのプロセスのstdin/stdoutにつなぎます。

そのため、ローカルMCPでは、

「MCP Serverをインストールしたけど、localhostのポートが見つからない」

ということがあっても不思議ではありません。

そもそもHTTP Serverとして動いていないからです。

2-10. 現在のClaude Desktopでは「インストール」自体も変わってきている

ここまで説明したのは、MCP Serverを手動で設定する昔ながらの方法に近い考え方です。

現在は、Claude Desktop向けにDesktop Extensionsという仕組みも用意されています。

Anthropicは2025年6月にDesktop Extensionsを発表し、ローカルMCP Serverをワンクリックでインストールできるパッケージとして提供しました。後に拡張子は.dxtから.mcpbへ変更されています。

現在のClaude Desktopでは、設定画面から拡張機能をインストールしたり、.dxt / .mcpb形式のパッケージを読み込んだりできます。

つまり、ユーザーから見ると、

拡張機能をインストール
        ↓
設定
        ↓
すぐ使える

というかなり簡単な操作になっています。

しかし、その裏側にある考え方は変わりません。

最終的にはローカルMCP Serverのプロセスが動き、MCP Clientと通信することになります。

つまり、

見えている部分

「MCP Serverをインストールする」
        ↓
「使えるようになった」


実際に起きていること

パッケージをインストール
        ↓
MCP Serverを実行可能な状態にする
        ↓
Claude Desktopがプロセスを起動
        ↓
stdin / stdoutで通信
        ↓
JSON-RPCでMCPのメッセージを交換

ということです。

2-11. ここまでが「ローカルMCP」

ここまで説明してきた構成を一枚にまとめると、こうなります。

┌──────────────────────────────────────┐
│             Claude Desktop            │
│                                      │
│  ┌──────────────┐                    │
│  │  AI / Host   │                    │
│  └──────┬───────┘                    │
│         │                             │
│  ┌──────▼───────┐                    │
│  │  MCP Client  │                    │
│  └──────┬───────┘                    │
└─────────┼────────────────────────────┘
          │
          │ stdin / stdout
          │ JSON-RPC
          ↓
┌─────────────────────────────┐
│      MCP Server Process     │
│                             │
│      Node.js / Python       │
│                             │
└──────────────┬──────────────┘
               │
               ↓
       外部API / DB / Files

ここで重要なのは、Claude DesktopとMCP Serverの間に、必ずしもHTTP通信が存在するわけではないことです。

ローカルMCPでは、プロセス間のstdin/stdoutをTransportとして使えます。

そして、その上にJSON-RPC形式のMCPメッセージが乗っています。

2-12. では、インターネット上のMCP Serverはどうするのか

ここで最初の疑問に戻ります。

ローカルなら、

MCP Client
 ↓
stdin / stdout
 ↓
MCP Server

でいい。

では、

MCP Client
 ↓
インターネット
 ↓
MCP Server

の場合はどうするのでしょうか。

当然、stdin/stdoutをそのまま使うことはできません。

そこで登場するのがHTTPベースのTransportです。

現在のMCPでは、Remote MCP Server向けの主要なTransportとしてStreamable HTTPが使われています。

MCPのTypeScript SDKでも、Remote ServerにはStreamable HTTPを推奨し、stdioはローカルでプロセスを起動する用途として位置付けています。HTTP + SSEは現在、後方互換性のためのレガシーTransportという扱いです。

構成は大きく変わります。

ローカルMCP

MCP Client
    ↓
stdin / stdout
    ↓
MCP Server


Remote MCP

MCP Client
    ↓
HTTP / HTTPS
    ↓
MCP Server

ここから先は、MCP Serverが単なるローカルプロセスではなく、普通のWebサービスに近い存在になってきます。

そして、ここで出てくるのが「Streamable HTTP」です。

2-13. ローカルMCPからRemote MCPへ

ここまでの話を一度整理します。

MCP Serverには、大きく分けて次のような使い方があります。

ローカル

AI
 ↓
MCP Client
 ↓
子プロセス
 ↓
MCP Server
 ↓
ローカルファイル / DB / API

一方、Remote MCPでは、

リモート

AI
 ↓
MCP Client
 ↓
HTTP / HTTPS
 ↓
Remote MCP Server
 ↓
API / DB / SaaS

となります。

つまり、MCP Serverは「自分のPCにインストールして使うもの」だけではありません。

インターネット上にサーバーとして公開して、複数のクライアントから利用することもできます。

ここまで来ると、MCP Serverはかなり普通のWebサービスに近く見えてきます。

実際、現在のMCP仕様はこのRemote MCPの利用をかなり意識した方向へ進んでいます。

2026年7月28日の仕様更新では、MCPのプロトコルレイヤーをステートレス化する変更が行われ、ロードバランサーの背後で複数のMCP Serverインスタンスを動かしやすくする方向へ進んでいます。

つまりMCPは、

ローカルの便利ツール
        ↓
AIと外部サービスをつなぐプロトコル
        ↓
Remote MCP Server
        ↓
Webインフラ上でスケールするサービス

という方向へ広がっています。

2-14. 次は「通信そのもの」を見る

ここまでで、MCP Serverを「インストールする」という操作の裏側が少し見えてきました。

ローカルMCPでは、

MCP Client
    ↓
MCP Serverを子プロセスとして起動
    ↓
stdin / stdout
    ↓
JSON-RPC
    ↓
Tool / Resource / Prompt

という通信が行われています。

一方、Remote MCPでは、

MCP Client
    ↓
HTTP / HTTPS
    ↓
Streamable HTTP
    ↓
Remote MCP Server

という構成になります。

ここから先は、単に「HTTPを使います」で終わらせず、実際にHTTPリクエストがどのようにMCP Serverへ送られるのかを見ていきます。

特に、

HTTP POST
JSON-RPC
SSE
Streamable HTTP
セッション
ステートレス化
ロードバランサー

あたりを追っていくと、現在のMCPがなぜ普通のWebインフラに近づいているのかが見えてきます。

次の章では、Remote MCP Serverへの通信を実際のHTTPレベルまで落として見ていきます。

参考・事実確認

Model Context Protocol公式SDK

MCP TypeScript SDKのServerドキュメントを確認し、現在の主要なTransportがstdioとStreamable HTTPであること、stdioがローカルでプロセスを起動する用途、Streamable HTTPがRemote Server向けの推奨方式であることを確認しています。

Model Context Protocol公式SDK「Connect to a server」

StdioClientTransportによってMCP Serverを子プロセスとして起動し、そのstdin/stdoutを使ってJSON-RPC通信を行う実装を確認しています。

Anthropic「Getting Started with Local MCP Servers on Claude Desktop」

Claude DesktopにおけるローカルMCP Serverの利用方法と、Desktop ExtensionsによるMCP Serverのインストール・管理方法を確認しています。

Anthropic「Desktop Extensions」

Desktop Extensionsが2025年6月に発表されたこと、およびローカルMCP Serverをパッケージ化してインストールしやすくする仕組みであることを確認しています。

MCP公式ブログ「The 2026-07-28 MCP Specification Release Candidate」

2026年7月28日の仕様更新で、MCPのプロトコルレイヤーをステートレス化する方向へ進んだこと、複数のMCP Serverインスタンスへロードバランシングしやすくする変更が行われたことを確認しています。

3. MCPでは実際にどのような通信が行われているのか

前章では、ローカルで動作するMCP Serverについて見てきました。

ローカルMCPでは、MCP ClientがMCP Serverをプロセスとして起動し、stdinとstdoutを使ってJSON-RPC形式のメッセージをやり取りします。

では、MCP Serverが自分のPCではなく、インターネット上にある場合はどうなるのでしょうか。

ここからはRemote MCP Serverについて見ていきます。

3-1. Remote MCPではHTTPを使う

Remote MCP Serverの場合、基本的な考え方はかなり普通のWebサービスに近くなります。

MCP Client
    ↓
HTTP / HTTPS
    ↓
Remote MCP Server
    ↓
外部API / DB / SaaS

ローカルMCPではstdin/stdoutを使っていましたが、Remote MCPではHTTPを利用してネットワーク越しに通信します。

現在のMCP仕様では、Remote Serverとの通信にはStreamable HTTPが推奨されています。

以前はHTTP + SSE（Server-Sent Events）という方式も使われていましたが、現在はStreamable HTTPが後継のTransportとして位置付けられています。

ここで大事なのは、MCPそのものとHTTPは別物だということです。

MCP
 ↓
「どのようなメッセージをやり取りするか」

Transport
 ↓
「そのメッセージをどうやって届けるか」

HTTP / HTTPS
 ↓
「ネットワーク上で実際に届ける」

という関係です。

3-2. HTTPの上にJSON-RPCが乗る

MCPでは、通信するメッセージにJSON-RPCが使われます。

例えば、MCP ClientがServerにToolの一覧を要求するとします。

概念的には、

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {}
}

というJSON-RPCメッセージになります。

これをHTTPで送ると、

POST /mcp HTTP/1.1
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {}
}

という形になります。

つまり、

MCP Client
    ↓
JSON-RPC
    ↓
HTTP POST
    ↓
インターネット
    ↓
MCP Server

という構造です。

このように見ると、MCPは「HTTPの代わりになる通信規格」ではありません。

HTTPなどのTransportの上で、MCPのメッセージをやり取りしています。

3-3. Toolを呼び出すとき

例えばMCP Serverが search というToolを提供しているとします。

AIが、

MCPについて検索して

と判断すると、MCP ClientからTool呼び出しが行われます。

概念的には、

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": {
      "query": "MCP"
    }
  }
}

というメッセージです。

MCP Serverはこの要求を受け取って、実際の処理を行います。

例えば検索APIを利用するMCP Serverなら、

MCP Server
    ↓
検索API
    ↓
検索結果

となります。

その結果をMCP Clientへ返し、最終的にAIが検索結果を解釈します。

ユーザー
  ↓
AI
  ↓
Toolを選択
  ↓
MCP Client
  ↓
HTTP
  ↓
MCP Server
  ↓
検索API
  ↓
MCP Server
  ↓
MCP Client
  ↓
AI
  ↓
回答

普段AIを使っていると一瞬で終わっているように見える処理ですが、実際にはこのような複数の層を通っています。

3-4. Streamable HTTPとは何なのか

ここで現在のMCPを理解する上で重要になるのがStreamable HTTPです。

名前の通り、HTTPを使いながら、必要に応じてサーバーからクライアントへデータをストリーミングできます。

例えばToolの処理に時間がかかる場合、

Client
  ↓
HTTP POST
  ↓
MCP Server
  ↓
処理開始
  ↓
結果を順次送信
  ↓
Client

という通信が可能になります。

従来のHTTP + SSE方式では、クライアントからのリクエストとサーバーからのイベントストリームを別々に扱う必要がありました。

Streamable HTTPでは、MCPの通信をよりシンプルにHTTPベースで扱えるようになっています。

MCP公式SDKでも、Streamable HTTPはRemote MCP Server向けの推奨Transportとして扱われています。

3-5. なぜRemote MCPが重要なのか

ローカルMCPだけなら、自分のPCでMCP Serverを起動すれば済みます。

しかし、例えば企業が、

「自社サービスをAI Agentから利用できるようにしたい」

と考えた場合、利用者全員にMCP Serverをインストールしてもらうのは大変です。

そこで、

ユーザー
   ↓
AI
   ↓
MCP Client
   ↓
HTTPS
   ↓
企業が運用するRemote MCP Server
   ↓
自社API / DB

という構成にできます。

こうするとユーザー側は、ローカルにMCP Serverをインストールする必要がありません。

認証や権限管理もサーバー側で行えるため、MCPをサービスとして提供することもできます。

この変化は、MCPが単なる「ローカルAIツール」から、Webサービスの一部として使われる技術へ広がっていることを意味します。

3-6. MCP Serverが増えていく理由

ここまで来ると、現在なぜMCP Serverが大量に作られているのかも分かりやすくなります。

例えば、

GitHub
   ↓
GitHub MCP Server

Slack
   ↓
Slack MCP Server

PostgreSQL
   ↓
PostgreSQL MCP Server

ブラウザ
   ↓
Browser MCP Server

というように、既存のサービスとAIの間にMCPのインターフェースを置くことができます。

AI側からすると、サービスごとのAPI仕様を直接扱うのではなく、MCP Serverが提供するToolを利用すればよい。

この構造が、MCP Serverのエコシステムが広がる理由の一つです。

3-7. そしてClaude in Chromeへ

ここまでで、

AI
 ↓
MCP Client
 ↓
MCP Server
 ↓
外部サービス

という基本的な構造が分かりました。

では、外部サービスがWebブラウザだったらどうなるのでしょうか。

例えば、

このページを開いて、商品を検索して、価格を比較して

という指示をAIに出した場合です。

ここで登場するのがClaude in Chromeです。

Claude in Chromeでは、Chrome拡張機能を通じてClaudeがWebページを操作できるようになっています。

例えば、

Webページを読む
リンクをクリックする
テキストを入力する
ページを移動する

といったブラウザ操作をClaudeから行えます。

ただし、ここで一つ注意が必要です。

Claude in Chromeそのものを単純に「MCP Server」と考えるのは正確ではありません。

Anthropicの公式ドキュメントでは、Claude in ChromeはChrome拡張機能として説明されており、Claude CodeからChromeへ接続する場合には claude-in-chrome というMCPサーバーとの接続も確認できます。

つまり、Claude in Chromeを理解するときには、

Claude
 ↓
ブラウザ操作のためのTool
 ↓
Chrome拡張
 ↓
Chrome
 ↓
Webページ

という複数の層に分けて考える必要があります。

この部分が、今回の記事で一番見ておきたいところです。

次章ではClaude in Chromeを例にして、

「AIがクリックするとき、実際には何が起きているのか？」

を追っていきます。

参考・事実確認

Model Context Protocol 公式SDK

Remote MCP ServerではStreamable HTTPが推奨され、stdioはローカルプロセスとの通信に利用されることを確認しています。

Model Context Protocol 公式仕様

MCPのTransport、JSON-RPC、Toolsなどの仕様を確認しています。

Anthropic「Get started with Claude in Chrome」

Claude in Chromeの機能やChrome拡張としての構成を確認しています。

Anthropic「Use Claude Code with Chrome」

Claude Codeから claude-in-chrome を利用してChromeへ接続できることを確認しています。

4. Claude in Chromeでは何が起きているのか

ここまでMCPの基本的な通信について見てきました。

ここからは、実際の利用イメージに近い例としてClaude in Chromeを見ていきます。

Claude in Chromeを使うと、ClaudeからChromeを操作して、Webページを開いたり、ページの内容を読んだり、クリックしたりできます。

例えば、

Googleで「MCP Server」について検索して

と指示した場合を考えてみます。

一見すると、Claudeが直接Chromeを操作しているように見えます。

しかし実際には、AIがブラウザを直接操作しているわけではありません。

大まかには、次のような複数の層に分けて考えることができます。

ユーザー
   ↓
Claude
   ↓
ブラウザ操作のTool
   ↓
Claude in Chrome
   ↓
Chrome
   ↓
Webページ

この「ブラウザ操作のTool」があることで、AIはChromeに対して操作を要求できます。

4-1. AIは「クリック」という操作をどうやって実行するのか

例えば、Webページ上に、

MCP Serverについて検索する

という検索ボタンがあったとします。

人間なら、そのボタンをマウスでクリックするだけです。

AIの場合はそうはいきません。

AI自身にはマウスカーソルが存在するわけではないからです。

そこで、ブラウザを操作するためのToolを用意します。

例えば概念的には、

click
type
navigate
read_page

のようなToolです。

AIはWebページを見て、

「検索ボタンをクリックする必要がある」

と判断します。

そして、

click(...)

のようなToolを呼び出します。

すると、そのToolを実際に処理する側がChromeへ操作を伝えます。

4-2. Claude in ChromeをMCPとして考える

Claude CodeからChromeを操作する場合、Anthropicはclaude-in-chromeというMCP Serverを利用する仕組みを提供しています。

この場合、概念的には、

Claude Code
    ↓
MCP Client
    ↓
claude-in-chrome
    ↓
Chrome Extension
    ↓
Chrome
    ↓
Webページ

という構成になります。

ここで面白いのは、MCP Serverの先にさらに別のプログラムが存在していることです。

つまり、

MCP Server
   ↓
ブラウザ操作
   ↓
Chrome Extension
   ↓
Chrome

という形になっています。

MCP Server自身がWebページを描画しているわけではありません。

あくまで、AIから受け取った操作要求をChrome側へ渡す役割を担っています。

4-3. 「ページを読む」ときも同じ

例えばClaudeに、

このページに何が書いてある？

と聞いたとします。

人間ならChromeに表示された文字を読むだけです。

Claudeの場合は、ページの情報を何らかの形で取得する必要があります。

概念的には、

Claude
  ↓
「現在のページを読みたい」
  ↓
read_page Tool
  ↓
Chrome側
  ↓
Webページの情報を取得
  ↓
Claude

という流れになります。

つまり、

「Webページを読む」

という行為も、AIにとってはToolの実行です。

4-4. AI Agentでは、このTool呼び出しが何度も繰り返される

ここが、最近のAI Agentを理解する上で重要な部分です。

例えば、

AmazonでMCP Serverについて調べて、いくつか候補を比較して

という指示を出したとします。

人間なら、

Amazonを開く
検索欄を探す
MCP Serverと入力する
検索する
商品を見る
次の商品を見る
比較する

という作業をします。

AI Agentの場合も、本質的には似ています。

AI
 ↓
ページを確認
 ↓
Toolを実行
 ↓
結果を確認
 ↓
次のToolを選択
 ↓
Toolを実行
 ↓
結果を確認
 ↓
……

というループになります。

つまりAI Agentとは、

「一回Toolを呼び出して終わり」

ではなく、

「Toolを使う → 結果を見る → 次の行動を決める」

という処理を繰り返す仕組みとして考えると分かりやすいです。

4-5. ここでMCPが効いてくる

このようなAgentを作る場合、ブラウザ操作のためのToolをAIアプリケーションに直接組み込むこともできます。

しかしMCPを利用すれば、

AI
 ↓
MCP Client
 ↓
Browser MCP Server
 ↓
Browser

という形で、ブラウザ操作を外部のMCP Serverとして切り離せます。

これには大きなメリットがあります。

例えば同じブラウザ操作Toolを、

Claude Code
Cursor
その他のAI Agent

から利用できるようにできます。

AIアプリケーション側がブラウザ操作の実装をそれぞれ持つ必要がなくなります。

4-6. MCP Serverは「AIに機能を追加するプラグイン」と考えると分かりやすい

ここまでを実際の利用者目線で考えると、MCP Serverはかなり「AIのプラグイン」に近い存在に見えてきます。

例えば、

Claude
 ├── GitHub MCP
 ├── Slack MCP
 ├── Database MCP
 ├── Browser MCP
 └── Filesystem MCP

という形です。

Claude自身がすべてのサービスの操作方法を知っているのではありません。

必要な機能をMCP Serverから取得して、

「GitHubを操作する」
「Slackを操作する」
「DBを検索する」
「ブラウザを操作する」

といったToolを利用します。

この仕組みがあることで、AIの能力を後から拡張できます。

4-7. ただし、MCP Serverがすべてをやっているわけではない

ここは誤解されやすいところです。

例えばGitHub MCP Serverなら、

Claude
 ↓
MCP Client
 ↓
GitHub MCP Server
 ↓
GitHub API

です。

ブラウザ操作なら、

Claude
 ↓
MCP Client
 ↓
Browser MCP Server
 ↓
Chrome Extension
 ↓
Chrome

となります。

つまり、MCP Serverは「最終的な操作対象」とは限りません。

MCP Serverの後ろに、

API
データベース
ファイルシステム
ブラウザ
別のサービス

などが存在することがあります。

そのためMCP Serverを理解するときは、

AI
 ↓
MCP Client
 ↓
MCP Server
 ↓
実際のサービス

という4層くらいに分けて考えると整理しやすいです。

4-8. Claude in Chromeから見るMCPの面白さ

Claude in Chromeを例にすると、MCPの考え方がかなり分かりやすくなります。

AIがWebページを操作するためには、ブラウザに対する操作手段が必要です。

そこで、

「クリックする」
「入力する」
「ページを読む」
「ページを移動する」

といった操作をToolとして提供します。

そして、そのToolをAIから利用できるようにするための共通インターフェースとしてMCPを利用できます。

結果として、

AI
 ↓
Tool
 ↓
MCP
 ↓
Browser

という構造が作れます。

この考え方はブラウザに限りません。

例えばデータベースなら、

AI
 ↓
MCP
 ↓
Database MCP Server
 ↓
PostgreSQL

GitHubなら、

AI
 ↓
MCP
 ↓
GitHub MCP Server
 ↓
GitHub API

Slackなら、

AI
 ↓
MCP
 ↓
Slack MCP Server
 ↓
Slack API

となります。

4-9. MCPは「AIに手足を与える」ための仕組みなのか

MCPを説明するときに、

「MCPはAIに手足を与える」

という表現を見かけることがあります。

これは厳密な技術用語ではありませんが、イメージとしてはかなり分かりやすい表現だと思います。

AIモデルだけなら、

考える
↓
文章を生成する

ことが中心です。

そこにToolを追加すると、

考える
 ↓
Toolを選ぶ
 ↓
外部サービスを操作する
 ↓
結果を見る
 ↓
もう一度考える

ということができるようになります。

さらにMCPを利用することで、そのToolをAIアプリケーションから共通の方法で提供できます。

その意味では、

LLM
 ↓
MCP
 ↓
Tools
 ↓
外部世界

という構造が、現在のAI Agentを支える重要な要素の一つになっています。

4-10. ここまででMCPの全体像が見えてくる

ここまでの内容をまとめると、

                    ┌── GitHub
                    │
                    ├── Slack
                    │
AI ── MCP Client ───┼── Database
                    │
                    ├── Browser
                    │
                    └── Files

という構造を作れるのがMCPです。

そして、MCP Serverとの接続方法には、

ローカル

MCP Client
    ↓
stdio
    ↓
MCP Server

と、

リモート

MCP Client
    ↓
HTTP / HTTPS
    ↓
MCP Server

があります。

さらにMCP Serverの先には、実際に操作する対象があります。

MCP Server
    ↓
API
DB
ファイル
ブラウザ
SaaS

です。

ここまで理解すると、MCP Serverがなぜ単なる「AI用API」とは少し違うのかも見えてきます。

MCPは、AIが外部世界とやり取りするための共通の「接続口」を作っているわけです。

5. では、現在どんなMCP Serverが存在するのか

ここまで仕組みを説明してきました。

最後に気になるのが、

「実際に今、どんなMCP Serverがあるのか？」

というところです。

現在は非常に多くのMCP Serverが存在するため、次章では単純に羅列するのではなく、

開発・GitHub系
データベース系
ファイル・ローカル環境系
ブラウザ操作系
SaaS・業務ツール系
クラウド・インフラ系
検索・情報取得系

のように分類して紹介していきます。

さらに、「有名なMCP Serverを紹介する」だけではなく、

「どういう用途ならMCP Serverを使う価値があるのか」

「自分でMCP Serverを作った方がいいケースは何なのか」

というところまで考えてみます。

参考・事実確認
Anthropic「Get started with Claude in Chrome」

Claude in Chromeの機能、Chrome拡張機能としての利用方法について確認しています。

Anthropic「Use Claude Code with Chrome」

Claude CodeからChromeを操作するためのclaude-in-chrome MCP Serverについて確認しています。

Model Context Protocol 公式仕様

MCP Client / Serverの関係、Tools、Transportなどの仕様を確認しています。

5. 現在どんなMCP Serverが存在するのか

ここまで、MCPがなぜ登場したのか、MCP Serverがどのように動いているのか、そしてClaude in Chromeを例にAIと外部サービスがどのようにつながるのかを見てきました。

ここからは、実際にどのようなMCP Serverが存在するのかを見ていきます。

MCPはオープンなプロトコルなので、特定のサービスだけに限定されているわけではありません。

GitHubのような開発ツールから、データベース、ブラウザ、クラウド、ファイルシステムまで、かなり幅広いMCP Serverが存在します。

ただ、数が非常に多いため、ここでは用途ごとに分類して見ていきます。

5-1. 開発・GitHub系

MCP Serverの中でも特に分かりやすいのが、開発ツールとの連携です。

例えばGitHub MCP Serverを利用すると、AIからGitHub上のリポジトリやIssue、Pull Requestなどを扱えるようになります。

イメージとしては、

Claude
  ↓
MCP Client
  ↓
GitHub MCP Server
  ↓
GitHub API
  ↓
GitHub

という構成です。

例えば、

このリポジトリで未対応のIssueを探して

と指示すると、MCP ServerがGitHubから情報を取得し、その結果をAIへ返すことができます。

さらに、Issueの作成やPull Requestの操作など、書き込み系のToolを提供することもできます。

開発者にとってMCPが面白いのは、このように「コードを書く」だけではなく、開発環境そのものをAIから操作できるようになるところです。

GitHubだけでなく、GitLabやJiraなど、開発・プロジェクト管理に関係するサービスにもMCPの利用が広がっています。

5-2. データベース系

次に分かりやすいのがデータベースです。

例えばPostgreSQLをMCP Server経由で利用すると、

AI
 ↓
MCP Client
 ↓
PostgreSQL MCP Server
 ↓
PostgreSQL

という構成にできます。

これによってAIからデータベースの情報を検索できます。

例えば、

先月登録されたユーザー数を調べて

という質問に対して、MCP Serverがデータベースへ問い合わせることができます。

概念的には、

AI
 ↓
「ユーザー数を調べたい」
 ↓
MCP Tool
 ↓
SQL
 ↓
PostgreSQL
 ↓
検索結果
 ↓
AI

という流れです。

ただし、データベースへの書き込みや任意のSQL実行をAIに許可する場合には注意が必要です。

例えば、

SELECT

だけを許可するのと、

INSERT
UPDATE
DELETE

まで許可するのでは、リスクが大きく違います。

MCP Serverは「AIに何でも操作させる仕組み」ではなく、どのToolを公開するのか、どの権限を与えるのかを設計する必要があります。

これはMCPを実際のシステムに導入するときにかなり重要なポイントです。

5-3. ファイル・ローカル環境系

MCPの初期から存在する代表的な用途の一つが、ローカルファイルへのアクセスです。

例えば、

AI
 ↓
Filesystem MCP Server
 ↓
PC上のファイル

という構成です。

これによってAIから指定したディレクトリのファイルを読み込んだり、場合によってはファイルを操作したりできます。

例えば、

このプロジェクトのREADMEを読んで概要を説明して

といった指示が可能になります。

一見すると単純ですが、AIにローカルファイルへのアクセス権を与えるということは、それだけ権限管理が重要になります。

例えば、

~/project

だけにアクセスできるようにするのと、

のようにPC全体へアクセスできるようにするのでは、意味が全く違います。

そのため、Filesystem系のMCP Serverでは「どのディレクトリを公開するか」という設計が重要になります。

5-4. ブラウザ操作系

ここまでの記事でも扱ってきたのがブラウザ操作です。

代表的な例として、

AI
 ↓
MCP Client
 ↓
Browser MCP Server
 ↓
Browser
 ↓
Webページ

という構成があります。

ブラウザ操作系のMCP Serverでは、

ページを開く
ページを読む
ボタンをクリックする
フォームへ入力する
ページを移動する

などの操作をAIから実行できるようにします。

この分野はAI Agentとの相性がかなり良いです。

例えば、

Webサイトから情報を集めて表にまとめて

という作業では、

ページを開く
 ↓
ページを読む
 ↓
必要な情報を探す
 ↓
リンクをクリック
 ↓
別ページを読む
 ↓
情報を整理

という複数の操作が必要になります。

こうした「何回もToolを使いながら作業する」タイプの処理は、AI AgentとMCPの組み合わせが特に分かりやすい例です。

5-5. SaaS・業務ツール系

MCP Serverは開発ツールだけのものでもありません。

Slack、Notion、Google Driveなどの業務ツールにもMCPを利用できます。

例えばSlackなら、

AI
 ↓
Slack MCP Server
 ↓
Slack API
 ↓
Slack

という構成です。

これによって、

今日のSlackで重要そうなメッセージをまとめて

といった処理をAIにさせることができます。

Notionなら、

このプロジェクトの議事録を探して

Google Driveなら、

先月の売上資料を探して

といった使い方が考えられます。

ここまで来ると、MCPは単なる開発者向けツールというより、

「AIから社内の情報や業務システムへアクセスするための共通インターフェース」

として利用できることが分かります。

5-6. クラウド・インフラ系

さらに、AWSなどのクラウドサービスをAIから操作するためのMCP Serverもあります。

例えば、

AI
 ↓
MCP Client
 ↓
Cloud MCP Server
 ↓
AWS API
 ↓
AWS

という構成です。

これを利用すれば、

現在動いているEC2インスタンスを確認して

といった情報取得をAIから行える可能性があります。

さらに権限を与えれば、リソースの操作までできる場合もあります。

ただし、この分野は特に注意が必要です。

例えば、

EC2を停止して

という指示をAIが実行できる状態にすると、AIの判断ミスがそのままインフラへの変更につながります。

そのため、

AI
 ↓
MCP
 ↓
AWS

という構成を作るだけではなく、

認証
権限
Toolの制限
確認フロー
監査ログ

まで含めて考える必要があります。

MCPは便利ですが、Toolの権限が強くなるほど、その分だけ安全性について考えなければなりません。

5-7. 検索・情報取得系

検索エンジンや外部APIと接続するMCP Serverもあります。

例えば、

AI
 ↓
Search MCP Server
 ↓
検索API
 ↓
検索結果

という構成です。

これによってAIが外部の情報を検索し、その結果をもとに回答できます。

LLM単体では、基本的に学習時点までの情報しか持っていません。

そこへ検索Toolを追加すると、

LLM
 ↓
検索
 ↓
最新情報
 ↓
LLM

という処理が可能になります。

このように考えると、MCPはAIに「外部の世界を見るための窓」を追加する仕組みとしても利用できます。

5-8. MCP Serverは「何を接続するか」より「何をToolとして公開するか」が重要

ここまでいくつかの種類を紹介しましたが、MCP Serverを考えるときに重要なのは、

「何のサービスと接続するか」

だけではありません。

むしろ、

「AIに何をさせるのか」

を考えることが重要です。

例えばGitHubを接続するとしても、

GitHubの情報を読む

だけなのか、

Issueを作成する

のか、

Pull Requestを作成する

のか、

コードを変更してPull Requestまで作成する

のかでは、必要な権限が全く違います。

つまりMCP Serverを設計するときには、

サービス
 ↓
API
 ↓
MCP Server
 ↓
Tool
 ↓
AI

という逆方向から考えることも重要です。

「このサービスをAIにつなぎたい」ではなく、

「AIにこの作業をしてほしい。そのためにはどんなToolが必要なのか」

と考えるわけです。

5-9. MCP Serverを使うのか、自分で作るのか

ここまで読んでいると、

「既にMCP Serverがあるなら、自分で作る必要はないのでは？」

と思うかもしれません。

もちろん、既存のMCP Serverで目的を達成できるのであれば、それを使った方が早いです。

一方で、自社サービスや個人開発のサービスをAIから操作したい場合は、自分でMCP Serverを作る意味があります。

例えば自分でWebサービスを開発しているなら、

自分のサービス
 ↓
API
 ↓
MCP Server
 ↓
AI

という構成にすることができます。

そうすると、ユーザーがAIに、

自分のアカウントの今月のデータを確認して

のような指示を出して、AIから自分のサービスを利用できるようになります。

これからAI Agentが普及していくことを考えると、

「人間がWebサイトを操作するためのUI」

だけではなく、

「AIがサービスを操作するためのインターフェース」

を用意するという考え方も重要になってきそうです。

5-10. MCP Serverの現在地

ここまでMCPについて調べてみると、MCP Serverは単純な「AI用プラグイン」という言葉だけでは説明しきれないことが分かります。

最初は、

AI
 ↓
ローカルMCP Server
 ↓
ファイル / DB / API

という使い方が中心でした。

そこから、

AI
 ↓
Remote MCP Server
 ↓
Web API / SaaS

という構成へ広がっています。

さらにブラウザ操作などのAgent的な用途も加わり、

AI
 ↓
MCP
 ↓
Tool
 ↓
外部世界
 ↓
結果
 ↓
AI

というループを作るための基盤としても使われています。

個人的には、MCPの面白さは「新しいAIを作ったこと」ではなく、「AIと外部サービスの接続部分を共通化しようとしたこと」にあると思っています。

AIモデルそのものは今後も変わっていくはずです。

Claudeを使っていたものが、別のモデルに変わることもあります。

しかし、

GitHubを操作する
Slackを読む
DBを検索する
ブラウザを操作する

といった「AIにやってほしい仕事」自体は残ります。

その間に共通のインターフェースを置くことができれば、AIモデルやAIアプリケーションが変わっても、外部サービスとの接続部分を再利用できます。

これがMCPがここまで注目されている理由の一つではないでしょうか。

5-11. まとめ

今回の記事では、MCPが登場する前のAIと外部サービスの接続方法から始めて、MCP Serverの仕組み、ローカルとRemote MCPの通信、そしてClaude in Chromeを例にしたブラウザ操作まで見てきました。

全体をまとめると、MCPは次のような位置にあります。

AI
 ↓
MCP Client
 ↓
MCP Server
 ↓
┌───────────────┬───────────────┬───────────────┐
│ GitHub        │ Slack         │ Database      │
│ API           │ API           │ DB            │
├───────────────┼───────────────┼───────────────┤
│ Browser       │ Files         │ SaaS          │
└───────────────┴───────────────┴───────────────┘

ローカルでは、

MCP Client
 ↓
stdio
 ↓
MCP Server

Remoteでは、

MCP Client
 ↓
HTTP / HTTPS
 ↓
MCP Server

という通信が使われます。

そしてMCP Serverは、AI自身ではありません。

AIが利用できるToolやResourceなどを提供し、その先にあるAPIやデータベース、ブラウザなどを操作する役割を持っています。

MCPを理解するときは、

「AIに何ができるのか」

だけを見るのではなく、

「AIがどのようなToolを選び、そのToolがどこへ通信し、最終的に何を操作しているのか」

まで見ると、かなり仕組みが分かりやすくなります。

今後AI Agentがさらに普及していけば、AIから外部サービスを操作する機会も増えていくはずです。

そのとき、MCPがどこまで標準的なインターフェースとして定着していくのかは、個人的にもかなり注目しています。

参考・事実確認

Model Context Protocol 公式ドキュメント

MCPの基本概念、Tools、Resources、Prompts、Client / Server構成について確認しています。

Model Context Protocol 公式仕様

MCPのプロトコル、Transport、JSON-RPCなどの仕様について確認しています。

Anthropic

Claude in ChromeおよびClaude CodeからChromeを利用する仕組みについて確認しています。

MCP公式SDK

stdioおよびStreamable HTTPによるMCP Serverとの接続方法について確認しています。

事実確認日

2026年8月17日

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up