MCPで大事なのは「AIにツールを増やすこと」ではなく「AIと外部世界をつなぐ標準を持つこと」

Last updated at 2026-06-28Posted at 2026-06-28

先に結論

を一通り読んで、一番強く感じたのはこれです。

MCP、つまり Model Context Protocol は、単なる「AIにツールを追加する仕組み」ではありません。

もっと本質的には、

AI アプリケーションが、外部のデータ・ツール・ワークフローに安全かつ標準的に接続するためのプロトコル

です。

公式ドキュメントでは、MCP は AI アプリケーションをローカルファイル、データベース、検索エンジン、計算機、ワークフローなどの外部システムにつなぐためのオープン標準と説明されています。さらに、USB-C が電子機器の接続を標準化するように、MCP は AI アプリケーションと外部システムの接続を標準化すると説明されています。(Model Context Protocol)

短く言うと、

MCP は、AI エージェント用の「外部接続インターフェース標準」

だと思いました。

前回の

が「AI に仕事のやり方を渡す仕組み」だとすると、MCP は「AI に外部世界への安全な接続口を渡す仕組み」です。

MCPとは何か

MCP は、AI アプリケーションと外部システムの間に入る標準プロトコルです。

たとえば、AI に次のようなことをさせたいとします。

GitHub の Issue を読む
Slack にメッセージを送る
ローカルファイルを検索する
データベースに問い合わせる
カレンダーを確認する
社内 API を呼び出す
Figma や Blender のようなツールを操作する

これらを AI アプリごとに独自実装すると、かなりつらいです。

Claude 用の接続。
ChatGPT 用の接続。
VS Code 用の接続。
Cursor 用の接続。
社内エージェント用の接続。

全部がバラバラになると、作る側も使う側も管理できません。

そこで MCP です。

MCP では、外部システム側が MCP server として機能を公開し、AI アプリケーション側が MCP client を通じてそれを利用します。公式ドキュメントでは、MCP host、MCP client、MCP server という構成で説明されており、host は AI アプリケーション本体、client は各 server への接続を管理する部品、server はコンテキストや機能を提供するプログラムです。(Model Context Protocol)

つまり、AI アプリケーションは毎回すべての外部サービスと直接つながる必要がありません。

MCP という共通の接続形式を使えばよい。

ここが大きいです。

MCPの登場人物

MCP を理解するには、まず3つの登場人物を押さえるのがよいです。

MCP Host
  ├── MCP Client 1 ─── MCP Server 1
  ├── MCP Client 2 ─── MCP Server 2
  └── MCP Client 3 ─── MCP Server 3

MCP Host

ユーザーが直接触る AI アプリケーションです。

たとえば、チャットアプリ、IDE、AI エージェント環境などです。

公式仕様では、host は複数の client を作成・管理し、権限、ライフサイクル、ユーザー同意、LLM 連携、コンテキスト集約を管理する存在とされています。(Model Context Protocol)

MCP Client

MCP server との接続を1つ持つプロトコルレベルの部品です。

重要なのは、client は通常 server ごとに作られるという点です。

1つの host が複数の MCP server に接続する場合、host の中に複数の MCP client ができます。公式ドキュメントでも、各 client は特定の server との1対1接続を管理すると説明されています。(Model Context Protocol)

MCP Server

外部システムの機能を MCP 経由で公開するプログラムです。

たとえば、Filesystem server、GitHub server、Slack server、Database server などです。

MCP server は、tools、resources、prompts という形で能力を公開します。公式ドキュメントでは、server はファイルシステム、データベース、GitHub、Slack、カレンダーなどの能力を AI アプリケーションに公開するプログラムだと説明されています。(Model Context Protocol)

大事なのは Tools / Resources / Prompts

MCP を学ぶとき、最初に見るべきなのは Tools / Resources / Prompts です。

この3つが MCP server の基本的な公開単位です。

種類	何か	誰が主に制御するか
Tools	AI が呼び出せる関数	Model
Resources	AI に渡せるデータ	Application
Prompts	ユーザーが使うテンプレート	User

公式ドキュメントでも、Tools はモデルが呼び出せる関数、Resources はコンテキストとして渡せる構造化データ、Prompts はユーザーが明示的に選ぶテンプレートとして整理されています。(Model Context Protocol)

ここはかなり重要です。

MCP は「ツール呼び出しの規格」として語られることが多いですが、実際には Tools だけではありません。

AI に「行動」させる Tools。
AI に「情報」を渡す Resources。
AI に「作業の入り口」を渡す Prompts。

この3つをどう分けるかが、MCP server 設計の中心になります。

Toolsは「AIが実行できる関数」

Tools は、AI モデルが必要に応じて呼び出せる関数です。

たとえば、

searchFlights(origin, destination, date)
createCalendarEvent(title, startDate, endDate)
sendEmail(to, subject, body)

のようなものです。

公式ドキュメントでは、Tools は schema-defined interface で、LLM が呼び出せるものと説明されています。各 tool は単一の操作を持ち、入力と出力を明確に定義し、MCP は JSON Schema を使って検証すると説明されています。(Model Context Protocol)

ここで大事なのは、Tools は強いということです。

読むだけではなく、書けます。
検索だけではなく、更新できます。
提案だけではなく、実行できます。

だからこそ危険でもあります。

公式ドキュメントでも、Tools は model-controlled、つまりモデルが文脈に基づいて自動的に発見・呼び出しできるものとされています。一方で、信頼性と安全性のために、ユーザーが tool 実行を拒否できる human-in-the-loop を設けるべきだとされています。(Model Context Protocol)

つまり、MCP server を作るときに一番雑に作ってはいけないのが Tools です。

関数名。
description。
input schema。
副作用。
権限。
確認ダイアログ。
監査ログ。

このあたりを設計しないと、「便利なAI」ではなく「何をするか分からない自動実行装置」になります。

Resourcesは「AIに渡す文脈」

Resources は、AI に読ませるためのデータです。

たとえば、

file:///project/README.md
calendar://events/2026-06
db://schema/users
api://docs/payment

のようなものです。

公式仕様では、Resources は server が client に公開する標準的なデータ共有の仕組みであり、ファイル、DB schema、アプリケーション固有情報などを language model のコンテキストとして渡せるものとされています。各 resource は URI で一意に識別されます。(Model Context Protocol)

ここで面白いのは、Resources は Tools と違って application-driven だという点です。

つまり、AI モデルが勝手に実行するというより、host アプリケーション側が「どの context をモデルに渡すか」を決める設計です。

MCP は UI を強制しません。
リスト表示でもいい。
検索でもいい。
添付ファイルのように選ばせてもいい。
ヒューリスティックで自動選択してもいい。

公式仕様でも、resources のユーザー操作モデルは application-driven で、どのように context を取り込むかは host application が決めるとされています。(Model Context Protocol)

これは RAG と相性がよいです。

ただし、MCP の Resources は単なる RAG ではありません。

RAG は「検索して渡す」ことが中心ですが、MCP Resources は「外部システムが、AI に渡せる文脈を標準形式で公開する」ことに主眼があります。

Promptsは「再利用できる作業の入り口」

Prompts は、server が client に公開できるテンプレートです。

たとえば、

/plan-vacation
/summarize-meetings
/draft-email
/review-pull-request

のようなものです。

公式仕様では、Prompts は language model とのやり取りを構造化するメッセージや指示を client に公開する仕組みで、client は prompt を発見し、取得し、引数を渡してカスタマイズできると説明されています。(Model Context Protocol)

ここで重要なのは、Prompts は user-controlled だということです。

Tools はモデルが選ぶ。
Resources はアプリが選ぶ。
Prompts はユーザーが明示的に選ぶ。

この分担はとてもよくできています。

AI に何でも自動判断させるのではなく、

行動は Tools
文脈は Resources
作業開始の型は Prompts

として分ける。

MCP を使いやすくするには、この3つをごちゃ混ぜにしないことが大事だと思います。

MCPの通信はJSON-RPCベース

MCP の中身は、かなり普通のプロトコルです。

魔法ではありません。

公式ドキュメントでは、MCP は JSON-RPC 2.0 ベースの交換プロトコルで、client と server が request、response、notification をやり取りすると説明されています。(Model Context Protocol)

たとえば、tool を探すときは tools/list。
tool を実行するときは tools/call。
resource を読むときは resources/read。
prompt を取るときは prompts/get。

かなり素直です。

MCP は最初に initialize を行い、protocol version、capabilities、client/server 情報を交換します。公式の lifecycle 仕様では、初期化は client と server の最初のやり取りであり、protocol version の互換性、capability、実装情報を交換するとされています。(Model Context Protocol)

この「capability negotiation」が MCP ではかなり重要です。

なぜなら、server によってできることが違うからです。

ある server は tools だけ持っている。
ある server は resources も持っている。
ある client は sampling に対応している。
ある client は elicitation に対応していない。

こういう差分を、最初に明示的に交渉する。

ここが標準プロトコルらしいところです。

Transportは大きく2種類ある

MCP の transport は主に2つです。

1つは stdio。
もう1つは Streamable HTTP。

公式ドキュメントでは、stdio transport は同じマシン上のローカルプロセス間で標準入出力を使って通信する方式、Streamable HTTP transport は HTTP POST と必要に応じた Server-Sent Events を使う方式と説明されています。(Model Context Protocol)

stdio

ローカルで MCP server を起動する方式です。

たとえば、Claude Desktop がローカルの filesystem server を subprocess として起動するようなケースです。

開発や個人利用では簡単です。
ただし、server はローカルで実行されるので、ユーザーのファイルや環境に触れる可能性があります。

公式のローカル server 接続ガイドでも、Filesystem Server に許可するディレクトリを設定し、file operation の前にユーザー承認を行う例が説明されています。(Model Context Protocol)

また、stdio server では stdout にログを書いてはいけません。

これは地味に重要です。

stdio の stdout は JSON-RPC メッセージ用なので、そこに print() するとプロトコルが壊れます。公式の server build ガイドでも、stdio ベースの server では stdout に書くと JSON-RPC メッセージが壊れるため、stderr や logging library を使うべきだと説明されています。(Model Context Protocol)

Streamable HTTP

リモート MCP server で使う方式です。

クラウド API、SaaS、社内サービスなどを MCP server として公開したい場合はこちらが自然です。

公式ドキュメントでは、remote MCP server はインターネット上にホストされ、プロジェクト管理ツール、ドキュメントシステム、コードリポジトリ、API ベースのサービスなどに統合できると説明されています。(Model Context Protocol)

リモート server では認証が重要になります。

OAuth。
API key。
権限設定。
tool permission。
connector 管理。

このあたりをきちんと作らないと、かなり危ないです。

MCPは「全部のツールを常にLLMに渡す」設計ではない

MCP server が増えると、ツールも増えます。

最初は5個。
次に20個。
気づくと200個。
大企業だと1000個。

ここで素朴に全部の tool definition を LLM の context に入れると、すぐに破綻します。

公式の Client Best Practices でも、host が多くの MCP server に接続し、数百から数千の tools にアクセスできるようになると、すべての tool definition を upfront で context に入れるやり方は token を浪費し、latency を増やし、model performance を落とすと説明されています。(Model Context Protocol)

そこで出てくるのが Progressive Tool Discovery です。

考え方はシンプルです。

最初は軽い tool catalog だけ持つ
必要になったら tool を検索する
候補だけ詳細 schema を読む
最後に実行する

公式ドキュメントでも、Catalog、Inspect、Execute の3層パターンが紹介されており、モデルはまず軽量な search_tools を使って候補を探し、必要な tool の完全な schema だけを取得して実行すると説明されています。(Model Context Protocol)

これは Agent Skills の Progressive Disclosure にかなり近いです。

全部を最初から渡さない。
必要なときに必要なものだけ渡す。

MCP でも、結局ここが大事になります。

セキュリティは後付けではない

MCP は外部システムに接続します。

つまり、セキュリティはおまけではありません。

特に注意すべきなのは以下です。

tool 実行の承認
local server の権限
OAuth の実装
token passthrough
SSRF
session hijacking
prompt injection
logging による機密情報漏えい
registry から入れる server の信頼性

公式の Security Best Practices では、MCP 実装に特有のリスク、攻撃ベクトル、対策が整理されています。対象読者として、MCP authorization flow を実装する開発者、MCP server operator、MCP-based system を評価する security professional が挙げられています。(Model Context Protocol)

たとえば token passthrough は明確に危険です。

公式ドキュメントでは、MCP server が client から受け取った token を、その token が MCP server 向けに発行されたものか検証せず downstream API に渡すことを anti-pattern として説明し、MCP server は MCP server 向けに明示的に発行されていない token を受け取ってはいけないとしています。(Model Context Protocol)

local MCP server も危険です。

ローカル server はユーザーのマシン上で実行されるため、不適切な sandboxing や同意なしの実行があると、任意コマンド実行、データ流出、データ損失につながります。公式ドキュメントでも、local MCP server はユーザーの system に直接アクセスできる可能性があり、攻撃対象になりやすいと説明されています。(Model Context Protocol)

なので、MCP server を入れるときは npm package を入れる感覚より慎重でよいと思います。

AI に接続する tool は、普通のライブラリより強いです。

なぜなら、モデルが状況に応じて呼び出せるからです。

Registryは「MCP serverのメタデータ置き場」

MCP には公式 Registry もあります。

ただし、ここも少し誤解しやすいです。

MCP Registry は、MCP server のコードそのものをホストする場所ではありません。

公式ドキュメントでは、MCP Registry は公開 MCP server の公式な集中メタデータリポジトリであり、server creator が metadata を公開する場所、DNS verification による namespace 管理、MCP client や aggregator が server を発見するための REST API、標準化された install/config 情報を提供すると説明されています。(Model Context Protocol)

つまり、

npm / PyPI / Docker Hub はコードやバイナリを置く
MCP Registry は server metadata を置く
marketplace や aggregator がそれを使う

という関係です。

公式ドキュメントでも、package registry は code/binary をホストし、MCP Registry はそれらを指す metadata をホストすると説明されています。(Model Context Protocol)

ここも現実的です。

MCP server が増えると、発見・インストール・信頼性確認が問題になります。

Registry はその入口になります。

ただし、Registry に載っているから何でも安全、という話ではありません。

公式 Registry 自体も、security scanning は package registry や downstream aggregator に委ね、Registry は namespace authentication と metadata hosting に重点を置くと説明しています。(Model Context Protocol)

なので、使う側はちゃんと確認が必要です。

Agent Skillsとの違い

前回の Agent Skills と並べると、違いが分かりやすいです。

観点	MCP	Agent Skills
本質	外部システム接続の標準プロトコル	AIに作業手順を渡すスキルパッケージ
渡すもの	tools, resources, prompts	手順、判断基準、scripts、references
主な目的	AI が外部データや操作にアクセスできるようにする	AI が特定タスクを正しい手順で実行できるようにする
例	GitHubを読む、DBを検索する、Slackへ投稿する	PRレビュー手順、PDF処理手順、提案書作成手順
近い比喩	AI用USB-C / 外部接続API	AI用runbook / 作業マニュアル

MCP は「何に接続できるか」を増やします。
Agent Skills は「どう作業するか」を良くします。

この2つは競合しません。

むしろ組み合わせるものです。

公式の MCP ドキュメントにも、Agent Skills を使って MCP server 設計・実装をガイドする説明があります。MCP 開発向けの skills は、deployment model、tool pattern、auth などの設計判断をエンコードし、AI coding assistant が use case を確認しながら server を scaffold できるようにするものと説明されています。(Model Context Protocol)

個人的には、次のような使い方が一番自然だと思います。

MCP:
  AIがGitHub、DB、Slack、社内APIに接続する

Agent Skills:
  接続した情報を使って、どうレビューするか、どう報告書を書くかを決める

つまり、

MCP は道具を渡す
Agent Skills は仕事のやり方を渡す

という関係です。

今からMCPを触るなら、どこから始めるか

最初から本格的な remote MCP server を作る必要はありません。

まずは小さく始めるのがよいです。

1. 既存の reference server を触る

公式の example server には、Everything、Fetch、Filesystem、Git、Memory、Sequential Thinking、Time などの reference server が載っています。これらは MCP の機能や SDK の使い方を学ぶための実装です。(Model Context Protocol)

まずは filesystem や git のような分かりやすいものを動かすのがよいと思います。

2. MCP Inspector を使う

MCP server を作るなら、Inspector はかなり重要です。

公式ドキュメントでは、MCP Inspector は MCP server をテスト・デバッグするための interactive developer tool で、resources、prompts、tools、notifications を確認できると説明されています。(Model Context Protocol)

AI client に接続する前に、Inspector で確認する。

これは必須に近いです。

3. 小さい tool から作る

いきなり巨大 API を全部ラップしない方がいいです。

最初は1つか2つの tool で十分です。

たとえば、

get_ticket_status
search_internal_docs
create_release_note
lookup_customer_config
summarize_recent_errors

のような小さい操作です。

公式の build server tutorial でも、最初に weather server を作り、get_alerts と get_forecast という2つの tools を公開する例になっています。(Model Context Protocol)

小さく作る。
schema を丁寧に書く。
description を改善する。
Inspector で試す。
client に接続する。
ログと承認フローを見る。

この順番がよいと思います。

まとめ

MCP は、AI エージェント時代のかなり重要な基盤です。

ただし、本質は「AI に便利なツールをいっぱい追加すること」ではありません。

本当に大事なのは、

AI と外部システムの接続を標準化する
Tools / Resources / Prompts を分けて設計する
Capability negotiation でできることを明示する
local / remote transport を使い分ける
全 tool を context に入れず progressive に発見する
OAuth、権限、承認、監査ログを最初から考える
Agent Skills と組み合わせて、接続と作業手順を分離する

という点です。

MCP は、AI に「手」を与えます。
Agent Skills は、AI に「仕事の型」を与えます。

これから AI エージェントを実務で使うなら、どちらも必要になります。

モデル単体の賢さだけでは足りません。

これから重要になるのは、

AI が何に接続できるか
その接続をどう安全に制御するか
接続したあと、どんな手順で仕事をさせるか

を設計する力だと思います。

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