その他のエッセイはこちら
USB-Cは“口”の比喩であり、本文は“列挙手順（エニュメレーション）”の話です。
MCPは、AIアプリが外部機能を「列挙してから呼び出す」ための共通手順を提供します。
USBのエニュメレーション（記述子を読み、機能を把握する流れ）と並べると、MCPの initialize / list_* がどこを標準化しているか見えます。
USB-Cという言い方は本来、コネクタ/ケーブル（加えてUSB PDやAlt Mode）を強く連想させます（仕様配布の起点: https://www.usb.org/documents ）。
一方で本記事の説明軸は、USB“プロトコル一般”の話としてのエニュメレーション（接続後に正体と機能を読み取る手順）です（USB 2.0仕様: https://www.usb.org/document-library/usb-20-specification ）。
つまり「USB-C＝統一された口」という比喩を借りつつ、技術説明はUSBエニュメレーション（プロトコル手順）で行います。
- PC・スマホ体験に見る同一性と乖離
- USBエニュメレーションとMCPライフサイクル
- Streamable HTTP transportと旧HTTP+SSEの差分
- 動的な更新の扱い
- 電文例で見るUSBとMCP
- Authorizationと認証・権限
- MCP Registryとサーバ発見
- USBとMCPの比較表
- それでも乖離するもの
- FAQ
- 参考文献
- まとめ
- USBプロトコル・エニュメレーション（列挙手順の芯）
- USB Type-C / USB PD / Alt Mode（“口”の比喩の世界）
- OS・ドライバ（USBドライバ/デバイスモデルの側）
- API設計（MCPのtools/resourcesを“設計対象”として見る）
- 認証・認可（USB比喩が最も崩れる要因の補強）
- APIセキュリティ（“ツール呼び出し”の安全側）
- サービス発見・レジストリ（“挿したら増える”体験の上位レイヤ）
- ざっくりの読み順（迷ったとき）
PC・スマホ体験に見る同一性と乖離
PCやスマホにUSB機器を挿す体験を軸にすると、「AIにとってのUSB-C」という比喩が何を指すかがつかみやすくなります。MCPの役割分担（Host / Client / Server）は https://modelcontextprotocol.io/docs/learn/architecture にまとまっています。
体験レベルの同一性
USBとMCPには「つないだ後に使えるものが増える」という共通の手触りがあります。
- 接続後の機能増加
- 正体の後追い判定
- 1つの口で多様な相手
USBではOSがデバイスを認識し、記述子を読み、ドライバを当てて使える状態にします。MCPではHostがServerに接続し、初期化して、tools/resources/promptsを列挙してから利用に入ります（Lifecycle: https://modelcontextprotocol.io/specification/2025-06-18/basic/lifecycle ）。
体験レベルの乖離
体験としては、次の違いが分かれ目になります。
- OS標準体験 / アプリ設計依存
- 自動化（ドライバ選択） / 確認・統制（実行許可・監査）
- 静的な機能（記述子） / 動的に変化しうる提供物（list結果）
MCPはOS機能ではなく、基本的にAIアプリ（MCP Host）が主役です。そのため、どこまで自動化するか、どこでユーザー確認を入れるかが実装や運用方針に強く依存します。
USBエニュメレーションとMCPライフサイクル
ここではUSBのエニュメレーション概要を押さえたうえで、MCPの initialize と list_*、そして通知や購読（subscriptions）を対応づけます。
USBエニュメレーション概要
USBではホストが段階的に情報を取得し、デバイスがどんな構成・インターフェース・エンドポイントを持つかを把握します。USB記述子（Device/Configuration/Interface/Endpointなど）の整理は、Microsoft Learnの説明が掴みやすいです。
https://learn.microsoft.com/ja-jp/windows-hardware/drivers/usbcon/standard-usb-descriptors
https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/usb-configuration-descriptors
流れのイメージは次の通りです。
- 接続検知・初期状態確立
- Device Descriptor 取得
- アドレス付与（SET_ADDRESS）
- Configuration/Interface/Endpoint 取得
- 構成選択（SET_CONFIGURATION）
- ドライババインド、通常転送へ
USB 2.0仕様の配布ページは https://www.usb.org/document-library/usb-20-specification です。
MCP初期化・機能発見・運用開始
MCPは接続後に initialize を実施し、プロトコルバージョンやcapabilitiesをすり合わせます（Lifecycle: https://modelcontextprotocol.io/specification/2025-06-18/basic/lifecycle ）。
ポイントは、initialize が成功した後に、クライアントが notifications/initialized を送って「通常運用に入れる」ことを明示する点です（同じくLifecycleに記載があります）。
その後、サーバが提供できるものを列挙して、ホストが利用可能状態にします。
- tools（ツール定義と入力スキーマ）: https://modelcontextprotocol.io/specification/2025-06-18/server/tools
- resources（参照可能なリソース）: https://modelcontextprotocol.io/specification/2025-06-18/server/resources
- prompts（再利用プロンプト）: https://modelcontextprotocol.io/specification/2025-06-18/server/prompts
対応づけ（インターフェースディスクリプタ相当の感覚）
USBでホストが記述子を読んで「どう扱えるか」を決めるのと同様に、MCPでもホストが list_* を通じて「何が呼べるか」を確定していきます。
- GET_DESCRIPTOR（機能の自己申告） / list_*（提供物の自己申告）
- SET_CONFIGURATION → ドライババインド（扱い方の確定） / Hostがツール定義をLLM/tool-callingに接続し、実行制御へ組み込み
- 通常転送（endpoint） / tools/call 等のRPC呼び出し
Streamable HTTP transportと旧HTTP+SSEの差分
MCPのHTTP系transportは、2025-06-18仕様では Streamable HTTP が中心です（Transports: https://modelcontextprotocol.io/specification/2025-06-18/basic/transports ）。
Streamable HTTP は 2024-11-05の HTTP+SSE transport を置き換える位置づけです（同じくTransportsに記載があります）。
差分の要点は次の通りです。
- Streamable HTTP: 単一の “MCP endpoint” がPOST/GETの両方を受ける
- クライアント→サーバ: JSON-RPC 1通につきHTTP POST 1回
- サーバ→クライアント: 応答が application/json の1発返しの場合も、text/event-stream（SSE）でストリームする場合もある
- 旧HTTP+SSE互換: 古い方式は「POST用のエンドポイント」と「SSE用のエンドポイント」が別で、互換のために両方ホストする指針が書かれている
USB比喩で言うなら「物理層の話」ではなく「運搬手段の整理」です。USBのendpointと1対1対応させるより、MCPは“呼び出し規約の上に運搬手段が載る”と捉えたほうが混乱が少ないです。
動的な更新の扱い
MCPで「動的に変わりうる提供物」を説明するなら、2種類に分けると整理しやすいです（resources仕様: https://modelcontextprotocol.io/specification/2025-06-18/server/resources ）。
リストが変わる（listChanged）
tools/resources/promptsの“一覧”が変わる場合、listChangedの宣言と list_changed 通知が軸になります。
toolsのリスト変更通知は tools仕様に記載があります（Tools: https://modelcontextprotocol.io/specification/2025-06-18/server/tools ）。
- リスト変更: notifications/tools/list_changed
個別の対象が更新される（subscribe）
resourcesは、一覧とは別に「個別リソース更新」を購読できます。capabilitiesで subscribe を宣言し、クライアントが resources/subscribe を送ると、更新時に notifications/resources/updated を受け取れます（Resources: https://modelcontextprotocol.io/specification/2025-06-18/server/resources ）。
- 購読: resources/subscribe
- 更新通知: notifications/resources/updated
USB側にも「構成を読む→構成を選ぶ」という意味で選択肢はありますが、MCPのsubscribe/listChangedは“差分を押し出す”設計要素として明示されている点が大きく異なります。
電文例で見るUSBとMCP
「列挙」を手触りに落とすために、超簡単な“電文例”を並べます。USBは制御転送のSetupパケット、MCPはJSON-RPCメッセージとして見ます。
USB電文例（制御転送Setupパケット）
標準デバイス要求の要約としては、Microsoft Open Specificationsの説明も参考になります。
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-gipusb/1d54ceb1-8c6d-4941-ab74-547f1d715add
GET_DESCRIPTOR(Device) の例です。
Setup (8 bytes)
bmRequestType: 80
bRequest: 06
wValue: 0100
wIndex: 0000
wLength: 0012SET_ADDRESS の例です。
Setup (8 bytes)
bmRequestType: 00
bRequest: 05
wValue: 0005
wIndex: 0000
wLength: 0000MCP電文例（JSON-RPC）
初期化は initialize →（成功後）notifications/initialized の順番が明示されています（Lifecycle: https://modelcontextprotocol.io/specification/2025-06-18/basic/lifecycle ）。
initialize の最小イメージです。
{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2025-06-18",
"capabilities": {
"tools": {},
"resources": {},
"prompts": {}
},
"clientInfo": {
"name": "example-host",
"version": "0.1.0"
}
}
}運用開始通知です。
{
"jsonrpc": "2.0",
"method": "notifications/initialized"
}resources購読の例です（Resources: https://modelcontextprotocol.io/specification/2025-06-18/server/resources ）。
{
"jsonrpc": "2.0",
"id": 4,
"method": "resources/subscribe",
"params": {
"uri": "file:///project/src/main.rs"
}
}更新通知の例です。
{
"jsonrpc": "2.0",
"method": "notifications/resources/updated",
"params": {
"uri": "file:///project/src/main.rs"
}
}Authorizationと認証・権限
USB比喩が崩れる最大要因は、認証・権限が体験の中心に出てくる点です。MCPはAuthorizationをtransportレベルの仕様として持ち、HTTP系transport向けの認可フローを定義します（Authorization: https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization ）。
仕様上の整理を最小の表にすると、こうなります。
| transport | 推奨される扱い | 理由の要点 |
|---|---|---|
| HTTP系（Streamable HTTP） | Authorization仕様に従うことを推奨 | 認可フローをHTTPベースで定義 |
| STDIO | Authorization仕様に従うべきではない | 環境から資格情報を取得する方針 |
Authorization仕様は、OAuth 2.1（ドラフト）や関連RFCを前提にしています（仕様内の一覧を参照）。ここはUSBの「挿すだけ体験」と決定的に違うため、比喩を使う場合は早めに釘を刺すほうが誤解が減ります。
MCP Registryとサーバ発見
「機能発見（list_*）」のもう一段上として、そもそも“どのサーバをつなぐか”という発見があります。ここで登場するのが Registry です（概要: https://modelcontextprotocol.io/registry/about ）。
MCP Registryは「公開MCPサーバのメタデータを集約する公式の集中リポジトリ」で、サーバ作者が server.json 形式のメタデータを公開し、REST APIで発見できるようにする位置づけです。
メタデータには、サーバの所在（パッケージ名やURL）や実行手順（引数、環境変数）などが含まれます（同ページに記載があります）。
実装リポジトリは https://github.com/modelcontextprotocol/registry です。
注意点として、公式Registryはホストアプリが直接叩く前提ではなく、下流のマーケットプレイス/集約サービスが消費する想定が書かれています。USB比喩で言うなら、これは「USB機器そのもの」ではなく「周辺機器のカタログ/流通」に近い層です。
USBとMCPの比較表
比較表（全体像）
| 観点 | USB（PC/スマホ ↔ 周辺機器） | MCP（Host ↔ Server ↔ LLM） | 補足 |
|---|---|---|---|
| 目的 | 周辺機器との通信標準化 | 外部ツール/データ接続標準化 | “統一された口”の比喩の射程 |
| 主役 | OS/ホストコントローラ | MCP Host（オーケストレータ） | アプリ設計の影響度 |
| 機能の自己申告 | 記述子（Descriptor） | tools/resources/prompts 定義 | 接続後に機械可読で可視化 |
| 機能の列挙 | GET_DESCRIPTOR | list_*（tools/list等） | インターフェースディスクリプタ相当の感覚 |
| 使い方の確定 | ドライババインド | LLMの選択＋Hostの実行制御 | 意思決定の性格差 |
| 通信路の位置づけ | endpoint/転送方式が中心 | transportは別レイヤ | Streamable HTTPが中心（Transports: https://modelcontextprotocol.io/specification/2025-06-18/basic/transports ） |
| 動的更新 | 再列挙寄り | listChanged/subscribeで差分反映 | resourcesのsubscribeが典型（Resources: https://modelcontextprotocol.io/specification/2025-06-18/server/resources ） |
| 認証・権限 | 体験の中心になりにくい | 比喩が崩れる最大要因 | Authorization仕様（https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization ） |
比較表（ライフサイクル対応）
| フェーズ | USB | MCP | 似る点 | ズレる点 |
|---|---|---|---|---|
| 接続開始 | 物理接続 | transport確立（stdio/Streamable HTTP） | セッション開始 | 物理層 / アプリ層 |
| 初期化 | reset | initialize → notifications/initialized | 前提条件の確立 | 運用開始合図の明示 |
| 機能発見 | GET_DESCRIPTOR | list_*（tools/resources/prompts） | 機能セット列挙 | 入力スキーマという高レベル情報 |
| 動的更新 | 再列挙寄り | list_changed / subscribe | 変化への追従 | 差分通知と購読 |
| 通常運用 | endpoint転送 | tools/call 等 | 実処理往復 | USBは転送方式、MCPは呼び出し規約 |
それでも乖離するもの
USB比喩が便利でも、どうしても対にならない領域があります。
- 意思決定の性格差（決定的 / 確率的）
- 認証・権限の中心性（物理中心 / 外部連携中心）
- 動的更新の押し出し（再列挙寄り / listChanged・subscribe）
- サーバ発見の層（ローカル接続 / Registry・マーケットプレイス）
MCPはツール実行が外部システムに作用しうるため、Host側の許可、検証、監査、出力整形が重要になります。HTTP系ではOrigin検証なども論点になります（Transports: https://modelcontextprotocol.io/specification/2025-06-18/basic/transports ）。
FAQ
USB-Cの話なのにUSBエニュメレーションを中心にする理由
USB-Cは主にコネクタ/ケーブル（加えてUSB PDやAlt Mode）を連想させます（起点: https://www.usb.org/documents ）。一方で「挿したら相手の機能が分かって使える」という体験の芯は、USBプロトコル一般のエニュメレーション（記述子取得）で説明しやすいです（記述子: https://learn.microsoft.com/ja-jp/windows-hardware/drivers/usbcon/standard-usb-descriptors ）。
MCPのinitializeの後に必要な手順
initializeが成功した後、クライアントが notifications/initialized を送って通常運用開始を通知します（Lifecycle: https://modelcontextprotocol.io/specification/2025-06-18/basic/lifecycle ）。
Streamable HTTPと旧HTTP+SSEの関係
2025-06-18仕様ではStreamable HTTPが中心で、2024-11-05仕様のHTTP+SSE transportを置き換える位置づけです（Transports: https://modelcontextprotocol.io/specification/2025-06-18/basic/transports ）。
resourcesの動的更新はlistChangedだけか
listChangedは一覧の変化です。個別リソースの変化は subscribe で購読し、notifications/resources/updated で更新通知を受け取れます（Resources: https://modelcontextprotocol.io/specification/2025-06-18/server/resources ）。
認証・権限がUSB比喩を崩す最大要因なのはなぜか
HTTP系transportではAuthorization仕様に従うことが推奨され、STDIOではAuthorization仕様を使わず環境から資格情報を取得する方針です（Authorization: https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization ）。
参考文献
- Model Context Protocol: Architecture
https://modelcontextprotocol.io/docs/learn/architecture - Model Context Protocol: Lifecycle
https://modelcontextprotocol.io/specification/2025-06-18/basic/lifecycle - Model Context Protocol: Transports（Streamable HTTP、旧HTTP+SSE互換）
https://modelcontextprotocol.io/specification/2025-06-18/basic/transports - Model Context Protocol: Tools
https://modelcontextprotocol.io/specification/2025-06-18/server/tools - Model Context Protocol: Resources（listChanged、subscribe、updated）
https://modelcontextprotocol.io/specification/2025-06-18/server/resources - Model Context Protocol: Authorization（HTTP推奨、STDIO非推奨）
https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization - The MCP Registry（公式概要、server.json、REST API）
https://modelcontextprotocol.io/registry/about - MCP Registry repository
https://github.com/modelcontextprotocol/registry - USB-IF: Document Library（USB-CやUSB PDなど仕様一覧の起点）
https://www.usb.org/documents - USB-IF: USB 2.0 Specification
https://www.usb.org/document-library/usb-20-specification - Microsoft Learn: Standard USB descriptors
https://learn.microsoft.com/ja-jp/windows-hardware/drivers/usbcon/standard-usb-descriptors - Microsoft Learn: USB configuration descriptors
https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/usb-configuration-descriptors - Microsoft Open Specifications: USB Control Endpoints（標準要求の要約）
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-gipusb/1d54ceb1-8c6d-4941-ab74-547f1d715add
まとめ
USB-Cは“口”の比喩であり、本文はUSBエニュメレーション（列挙手順）を軸にMCPのinitialize/list/通知・購読・認可を比較しました。
MCPはStreamable HTTPが中心で、旧HTTP+SSEとの差分を押さえると仕様読み替えが楽になります。
動的更新はlistChangedだけでなくresourcesのsubscribe/updatedも使えるため、USBの再列挙との差がよりはっきりします。
- 比喩の射程: USB-C＝統一された口
- 本文の技術軸: 列挙手順（USB）と機能発見・動的更新（MCP）
- 最大の乖離: 認証・権限とサーバ発見（Registry）
その他のエッセイはこちら
USBプロトコル・エニュメレーション（列挙手順の芯）
USBコンプリート 第3版（Jan Axelson 著／邦訳）
エニュメレーション（コントロール転送）を含め、USBデバイス開発を横断的に整理できる
USB 3.0設計のすべて（CQ出版）
物理層～リンク/プロトコル、バス・エニュメレーションまで含めて「規格の読み方」を鍛えやすい
USB Type-C / USB PD / Alt Mode（“口”の比喩の世界）
USB Type-Cのすべて（CQ出版）
Type-Cのメカニズム、PD、Alternate Modeまでを規格ベースで整理
OS・ドライバ（USBドライバ/デバイスモデルの側）
Linuxデバイスドライバ 第3版（O’Reilly Japan）
カーネル2.6世代の内容だが、USBドライバを含む「デバイスモデルの考え方」を掴む用途で強い
API設計（MCPのtools/resourcesを“設計対象”として見る）
Web APIの設計（翔泳社）
APIのゴール設計、表現、一貫性、進化、ドキュメントまでを設計目線で通せる
APIファースト Postmanで学ぶ効率的かつ柔軟な開発アプローチ（翔泳社）
ライフサイクルに沿って設計・ドキュメント・テスト・公開/ディスカバリまで扱う
認証・認可（USB比喩が最も崩れる要因の補強）
OAuth徹底入門 セキュアな認可システムを適用するための原則と実践（翔泳社）
OAuthを「実装・脆弱性・拡張」まで含めて体系化。MCPのAuthorization章を読む前後に効く
実践 Keycloak（O’Reilly Japan）
OIDC/OAuth 2.0の基礎も押さえつつ、実運用のIAMとしての落とし所が見える
APIセキュリティ（“ツール呼び出し”の安全側）
ハッキングAPI ―Web APIを攻撃から守るためのテスト技法（O’Reilly Japan）
REST中心だが、APIをどう壊されるか→どう守るかを実践で掴める
セキュア・バイ・デザイン―安全なソフトウェア設計（邦訳）
設計にセキュリティを組み込む発想。認可・境界設計の考え方の補強に使える
サービス発見・レジストリ（“挿したら増える”体験の上位レイヤ）
マイクロサービスパターン 実践的システムデザインのためのコード解説（インプレス）
外部API/通信/トランザクション/運用などをパターンで整理。Registry的な話題とも相性が良い
絵で見てわかるマイクロサービスの仕組み（翔泳社）
クラウドネイティブ全体像を掴む用途。サービス発見・メッシュの話に入る前の地ならし
ざっくりの読み順（迷ったとき）
- USB列挙の芯: USBコンプリート → USB 3.0設計のすべて
- “口”の比喩: USB Type-Cのすべて
- MCP側の設計: Web APIの設計 → APIファースト
- 最大の乖離（認証・権限）: OAuth徹底入門 → 実践 Keycloak → ハッキングAPI
コメント