MCP用語集【2026年版】設計・トランスポート・セキュリティの頻出用語まとめ
この記事は、note本編「MCPはなぜ2026年の必須技術になったのか」の補足用語集です。 本編で登場するMCP関連用語を、初学者でも追えるよう体系立ててまとめました。本編とあわせて読むと理解が深まります。
▶ note本編：MCPはなぜ2026年の必須技術になったのか（※公開後にURLを挿入）
この用語集は、MCP関連用語を初学者でも読み進められるよう体系立てて整理したものです。各カテゴリは「基礎 → プリミティブ → トランスポート → 2025–2026の新概念 → 設計・運用 → セキュリティ → エコシステム」の順に並べ、note本編の論旨（標準が確定し、設計の重心がプロトコルから"使う側"へ移った）を追えるようにしています。要所には 設計上の勘所 として、2026年の文脈で各概念がなぜ効くのかを添えました。
全体像：MCP設計はこの2年でどう成熟したか
下図は仕様バージョンの変遷です。プロトコルの土台（認可・トランスポート・非同期処理・ステートレス化）が段階的に固まっていく流れが、note本編の主題「設計の重心がプロトコルから"使う側"へ移った」の背景になります。
1. 基礎・全体像
MCP（Model Context Protocol）
LLMアプリと外部ツール・データを繋ぐためのオープン標準プロトコル。2024年11月にAnthropicが公開した。ツールごとの独自統合を、ひとつの共通規格に置き換えることを狙う。「AI版のUSB-C」と例えられることが多い。
Host（ホスト）
MCPクライアントを内包し、AIタスクを実行するアプリケーション本体。Claude Desktop、Cursor、VS Codeなどが該当する。AIと外部リソースの間に立ち、すべてのやり取りを仲介する「セキュリティ・ブローカー」の役割を担う。
Client（クライアント）
ホスト内に置かれ、1つのサーバーと1対1で接続する管理役。能力の発見（discovery）やプリミティブの呼び出しを担当する。
Server（サーバー）
外部システム（DB、API、ファイルなど）へのアクセスや操作を提供する側。Tools・Resources・Promptsの3機能を公開する。HTTPサーバーである必要はなく、stdioで動くローカルプロセスも「サーバー」と呼ぶ点に注意。
JSON-RPC 2.0
MCPのメッセージ形式の土台となる軽量なRPC仕様。リクエスト／レスポンス／通知（notification）／エラーを規定する。
Capability negotiation（能力ネゴシエーション）
接続確立時（initialize）に、サーバーとクライアントが互いの対応機能を宣言し合う仕組み。「サーバーが何をできるか宣言し、ホストが何を許すか決める」という能力ベース設計の中核をなす。
LSP（Language Server Protocol）
MCPの設計上の着想元。「エディタ × プログラミング言語」のM×N問題を共通プロトコルで解いた前例で、MCPは同じ発想を「AIアプリ × ツール」に適用した。
M×N問題（N×M integration problem）
M個のAIアプリとN個のツールを個別に繋ぐと、組み合わせ（M×N）が爆発する課題。MCPはこれを「M+N」に畳み込むことを目指す。
Mediated Access Pattern（仲介アクセスパターン）
AIが外部リソースに直接触れず、必ずホストを介してアクセスするMCPの基本構造。セキュリティ境界を一箇所に集約する設計思想。
下図がMCPの基本構造です。LLMは外部リソースに直接触れず、Host（ブローカー）を介します。リソース種別ごとにClientとServerが1対1で対応し、各Serverが3つのプリミティブ（Tools / Resources / Prompts）を公開します。
2. サーバーが提供する3つのプリミティブ
Tools（ツール）
AIモデルが実行できる関数。外部APIの呼び出しやデータ操作を行う。従来のfunction callingと異なり、モデルが文脈に応じて自律的に選択・実行する点が特徴。
Resources（リソース）
モデルやユーザーが参照するための読み取り専用データ。ファイル内容、DBレコード、APIレスポンスなどを含む。
Prompts（プロンプト）
再利用可能なテンプレートやワークフロー。定型タスクの一貫性と効率を高める。
Tool annotations（ツールアノテーション）
ツールの性質をクライアントに伝えるメタ情報。readOnlyHint（読み取り専用）、destructiveHint（破壊的変更を伴う）など。クライアントが安全ポリシー（承認フローなど）を適用する判断材料になる。なお仕様上、アノテーションは信頼できるサーバー由来でない限り信用すべきでないとされる。
3. クライアントが提供する3つのプリミティブ
Sampling（サンプリング）
サーバーがクライアント（ホスト）側のLLMに推論を依頼する仕組み。サーバー起点での再帰的なエージェント動作を可能にする。2025-11-25でツール呼び出しにも対応した。
Roots（ルーツ）
サーバーが操作してよいURIやファイルシステムの境界を、クライアント側が示す仕組み。
Elicitation（エリシテーション）
サーバーが処理の途中でユーザーに追加情報を求める仕組み。
URL mode elicitation
認証情報を直接クライアントに渡さず、ブラウザでOAuthフローなどを完了させる方式（2025-11-25）。APIキーやパスワードがMCPクライアントを通過しないため、外部API連携や決済（PCI準拠）を安全に扱える。
4. トランスポートと接続
トランスポート層
実際の通信を担う層。MCPは同じJSON-RPCメッセージを異なる通信方式で運べる（トランスポート非依存）。
stdio
標準入出力を使うローカル向けトランスポート。ネットワークを介さず高速で、プロセス分離による安全性（認証ハンドシェイクもファイアウォール問題も不要）が得られる。クライアントは可能な限りstdio対応が推奨される。
Streamable HTTP
リモート向けの標準トランスポート（2025-03-26で導入）。単一エンドポイント（例 /mcp）がPOST/GETの両方を扱い、必要に応じてSSEでストリーミングする。
HTTP+SSE（旧トランスポート）
2024-11-05版の方式。Streamable HTTPに置き換えられ非推奨（deprecated）だが、一部ツールでなお利用される。
Stateful / Stateless（ステートフル／ステートレス）
接続がセッション状態を保持するか否か。MCPは当初ステートフルだったが、サーバーがメモリ内に状態を抱えると水平スケールを阻む。
設計上の勘所：2026年最大の設計テーマがこのステートレス化。ロードバランサ背後での水平スケール、プロキシ越しの運用、サーバー再起動への耐性が、ステートフル前提では得にくいことが本番運用で判明した。
下図は2つの標準トランスポートの対比です。ローカルで動かすか、リモートでスケールさせるかで選びます。
5. 認可・認証
OAuth 2.1 / 認可フレームワーク
2025-03-26で標準化されたMCPの認可方式。リモート（HTTP系）トランスポートにのみ適用され、stdioは環境変数由来の認証情報を使う。
OAuth Resource Server
2025-06-18でMCPサーバーが正式にこの位置づけになった。セキュリティと発見性（discovery）の観点で意味を持つ。
Dynamic Client Registration（DCR）
クライアントが認可サーバーへ自己登録する仕組み。MCPでは無数のクライアント／サーバーが存在するため必要とされたが、認可サーバー側の対応が要り、OAuthプロキシ構築が煩雑になる課題があった。
Client ID Metadata Documents（CIMD）
DCRの課題に対する解決策（SEP-991、2025-11-25）。クライアントが自分で管理するJSON文書のURLを、クライアントIDとして使うURLベースの登録方式。
6. 2025–2026の新概念（設計の重心移動）
ここがnote本編の核。「ツールを公開する」段階から、「エージェントが効率よく扱える形に設計する」段階へ、"良い設計"の定義そのものが変わった。
Tasks（タスク）
長時間処理を「call-now / fetch-later（今呼んで、後で取りに行く）」で扱う非同期プリミティブ。working / input_required / completed / failed / cancelled の状態を持つ。
設計上の勘所：2025-11-25で実験投入されたが、本番運用での再設計を経て、2026-07-28 RCでは仕様本体ではなく拡張（extension）へ移された。「コアに入れる前に実験で揉む」という統治設計の好例。
Extensions（拡張）
コア仕様の外で機能を追加する仕組み。原則は「任意・追加的・合成可能・独立バージョン」。
設計上の勘所：コアを最小・安定に保ちつつ、UIや独自認証などを正式昇格の前に実験できる。MCP AppsやTasksがこの経路を辿った。「単純さ vs 拡張要求」の緊張を制度で解いている。
MCP Apps
サーバーがReactなどの対話的UI（ダッシュボード、フォーム、データ可視化など）をホストに届ける公式拡張（SEP-1865、旧mcp-ui）。テキスト／構造化データに限られていたMCPにUI機能を持ち込む。
Code Execution with MCP
ツールを「直接呼び出す」のではなく、コードAPIとして提示してエージェントにコードを書かせる設計パターン（Anthropic、2025年11月）。公式が挙げた一例では、150,000トークンが約2,000トークンへ（98.7%削減）と報告された。
設計上の勘所：note本編の山場。ただしこの「98.7%」は特定ワークフローの一例であって普遍値ではない（実装報告では条件により振れる）。鵜呑みにせず自分の環境で測る価値が高い。またエージェント生成コードの実行には、安全なサンドボックス・リソース制限・監視という運用コストが伴う点も誠実に押さえたい。
下図が「従来の直接ツール呼び出し」と「Code Execution」の違いです。note本編の山場となる対比です。
Progressive disclosure（プログレッシブ・ディスクロージャー）
全ツール定義を前載せせず、エージェントがファイルシステム探索や search_tools で必要な定義だけを必要時に読み込む考え方。トークン肥大の主因（定義の前載せ）への直接的な処方箋。
Code Mode
Cloudflareが提唱した同趣旨の概念。「LLMはMCPを直接呼ぶより、MCPを呼ぶコードを書く方が得意」という洞察。AppleのCodeAct、Dockerの動的MCPとも収斂した、業界横断の潮流。
Skills / SKILL.md
再利用可能な手順・スクリプト・リソースをまとめたフォルダ。エージェントが一度書いた有効なコードを保存し、より高次の能力として蓄積していく仕組みに繋がる。
7. サーバー／ツール設計の実務用語
Tool Budget（ツール予算）
エージェントが効果的に扱えるツール数には上限がある、という考え方（Docker）。ツールを盛りすぎるとサーバーが複雑・高コストになり、ツール選択の精度も落ちる。
Token budget pagination（トークン予算ページネーション）
レコード数ではなく、消費トークン量で区切るページング方式（Datadog）。巨大なレスポンス1件で文脈が枯渇する事故を防ぐ。
Tool poisoning / toolflow hijacking（ツール汚染／ツールフロー乗っ取り）
ツール説明文に「このツールを優先せよ」などの誘導を埋め込み、エージェントのツール選択を操作する攻撃。機能が劣るツールでも選ばせられてしまう。
薄いラッパー（thin API wrapper）アンチパターン
既存APIをそのままツール化しただけの設計。エージェント向けには不十分で、人間向けAPIとは別物として設計し直す必要がある、という実務的教訓。
8. 運用・エンタープライズ
MCP Gateway（MCPゲートウェイ）
エージェントとサーバー群の間に立つ制御プレーン。認証情報管理・ルーティング・ポリシー強制・可観測性・RBACを集約する。本番運用での標準パターン。
MCP Registry（MCPレジストリ）
利用可能なMCPサーバーを発見・検証するための索引。2025年に公式版が登場した。企業が自前のレジストリを持つ構想も進む。
Server allowlist / Tool allowlist（サーバー／ツール許可リスト）
接続してよいサーバー、呼び出してよいツールを明示列挙する「デフォルト拒否」型の統制。エンタープライズの基本制御。
可観測性 / 監査証跡（Observability / Audit trail）
ツール呼び出しの記録・追跡。プロトコル本体には未標準で、各社がOpenTelemetryなどで自前実装しているのが現状。2026年ロードマップの重点領域の一つ。
9. セキュリティ
Prompt injection（プロンプトインジェクション）
信頼できるコンテンツと信頼できないコンテンツを同じ文脈に混ぜることで起きる攻撃。SQLインジェクションに倣ってSimon Willisonが命名した。
Indirect prompt injection（間接プロンプトインジェクション）
メールやWebページなど、エージェントが読み込む外部コンテンツに悪意ある指示を仕込む手法。
Lethal Trifecta（致命的な三要素）
①プライベートデータへのアクセス、②信頼できないコンテンツへの曝露、③外部通信能力——この3つが1つのエージェントに揃うと、プロンプトインジェクションによるデータ窃取に構造的に脆弱になる、というSimon Willisonの枠組み（2025年6月）。
設計上の勘所：MCPで複数ツールを繋ぐと、当初無害だったエージェントが無自覚に三要素を揃えてしまいやすい。「メールを要約するエージェント」と「メールを送るエージェント」を分けるなど、設計でしか解けない。
下図がLethal Trifectaの構図です。3要素が1つのエージェントに集まった瞬間に攻撃が成立します。
Agents Rule of Two（エージェントの2つの法則）
Lethal Trifectaを踏まえてMetaが提案した実務指針。3要素のうち、同時に持たせるのは2つまでにする、という発想（GoogleのRule of 2に着想）。
Name collision（名前衝突）
正規サーバーに酷似した名前で偽サーバーを登録し、インストール時にユーザーを欺く攻撃。
Sandbox escape（サンドボックス脱出）
ツール実行の隔離環境の脆弱性を突き、ホスト権限を奪う攻撃。Code Executionを採用する際に特に重要な論点になる。
Capability attestation（能力の証明）の欠如
サーバーが任意の権限を主張できてしまう、プロトコルレベルの構造的弱点として学術研究で指摘される論点。動的発見の利便性が、そのまま信頼の隙にもなりうる。
10. エコシステム・ガバナンス
Agentic AI Foundation（AAIF）
MCPの中立的統治を担う、Linux Foundation傘下の基金。2025年12月9日にAnthropic・Block・OpenAIが共同設立し、Google・Microsoft・AWS・Cloudflare・Bloombergが支援。
設計上の勘所：MCPがここに寄贈されたことで、特定ベンダーの資産ではなく中立標準として確定した。「標準が固まった＝設計責任が下流（使う側）に降りてきた」というnote本編の主張の土台。
SEP（Specification Enhancement Proposal）
仕様変更の提案。コミュニティが提出し、Working Groupが審議する。MCP進化の駆動装置。
Working Group / Interest Group
機能領域ごとに仕様策定を進めるコミュニティ組織。2026年は、日付ベースのリリースからWG主導の優先領域へと統治が移行した。
goose
BlockによるローカルファーストのオープンソースAIエージェントフレームワーク。AAIFの創設プロジェクトの一つ。
AGENTS.md
OpenAIによる、AIコーディングエージェントにリポジトリ固有の指針を与える共通規約。AAIFの創設プロジェクトの一つ。
11. 比較されるプロトコル
A2A（Agent-to-Agent Protocol）
Google発。Agent Cardによるエージェント間のタスク委譲・協調を担う。MCP（ツール接続）の上位レイヤーに位置づけられることが多い。
ACP（Agent Communication Protocol）
RESTネイティブでマルチモーダルなメッセージング。同期・非同期の両方に対応する。
ANP（Agent Network Protocol）
W3C DID（分散識別子）による、オープンなエージェント発見と分散協調。
段階的採用ロードマップ
サーベイ論文が示す積層モデル：MCP（ツールアクセス）→ ACP（多モーダルメッセージング）→ A2A（協調的タスク実行）→ ANP（分散マーケットプレイス）。MCPはこの最下層＝土台に位置づけられる。
この記事の位置づけ：本編と全体像への動線
この用語集は、note本編 「MCPはなぜ2026年の必須技術になったのか」 の補足です。本編が「なぜ2026年にMCPが必須なのか（標準化の確定・トークン経済・セキュリティ設計）」を論じ、この用語集がその語彙を裏側で支える、という関係になっています。用語の定義を確認したらぜひ本編へ。
▶ note本編：MCPはなぜ2026年の必須技術になったのか（※公開後にURLを挿入）
さらに広い文脈として、MCP設計を 「AIエージェント設計の3層構造（Prompt → Context → Harness）」 の中に位置づけた記事もあります。MCPはこのうち、Context層（何を渡すか＝トークン経済）と Harness層（どんな環境で動かすか＝ツール定義と制約）にまたがります。
▶ AIエージェント設計を支える3つのエンジニアリング：Prompt・Context・Harness
https://note.com/ebe0911/n/n9ee5dbd40546
筆者の発信媒体
クラウド × 生成AI × キャリアを、各プラットフォームで発信しています。実装ベースの検証ログや設計の話が中心です。よければフォローしてください。
- note｜@ebe0911（思考と設計の深掘り。本編・関連記事もこちら）：https://note.com/ebe0911
- Zenn｜@ebe_ryuki（技術記事・検証ログ）：https://zenn.dev/ebe_ryuki
- Qiita｜@ryukiebe0911（技術Tips・実装メモ）：https://qiita.com/ryukiebe0911
- X（旧Twitter）｜@EBE_Ryuki（日々の検証メモ・最新トピックの速報）：https://x.com/EBE_Ryuki
- LinkedIn（クラウド／キャリアのB2B発信）：https://www.linkedin.com/in/ryuki-ebe-4783373b3
- Instagram｜@ryuk.i0911（生成AIの実践的な使い方をやさしく）：https://www.instagram.com/ryuk.i0911/
12. 主要な一次情報源（参考リンク）
- 公式仕様（最新）：https://modelcontextprotocol.io/specification/2025-11-25
- Anthropic「Code execution with MCP」：https://www.anthropic.com/engineering/code-execution-with-mcp
- AAIF設立・MCP寄贈（Anthropic）：https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation
- Simon Willison「The lethal trifecta」：https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
- 学術サーベイ（Landscape, Security Threats）：arXiv:2503.23278
- 学術サーベイ（プロトコル比較 MCP/ACP/A2A/ANP）：arXiv:2505.02279
※ 用語の定義は2026年6月時点の情報に基づく。仕様は活発に更新されているため、引用時は一次情報の最新版を確認することを推奨します。