同じ端末で利用者ごとにサーバープロセスを動かすならstdio、ネットワーク越しに複数利用者へ一つのサービスを提供するならStreamable HTTPが基本です。ただし、ローカルかリモートかだけで決めると、秘密情報の保管、障害の広がり、停止方法、旧仕様との互換で行き詰まります。本稿ではMCP 2026-07-28公式仕様を基準に、業務システム担当者が一つの接続方式を採択できるところまで比較します。
MCPのstdioとStreamable HTTPの違いを配置条件で判断する
stdioが第一候補になるのは、AIホストが利用者の端末上でMCPサーバーを起動でき、扱うファイルや開発環境もその端末にあり、利用者間でプロセスを共有する必要がない場合です。例えば、開発者が自分の作業ディレクトリだけを読むコード検索サーバーを使うなら、外部公開用のURL、TLS証明書、ロードバランサーを用意せずに済みます。端末のOSアカウント、実行ファイルの署名、許可した作業ディレクトリが主な境界になります。
Streamable HTTPが適するのは、営業所50拠点から同じ在庫サービスを呼ぶ、サーバー側で監査ログを集中管理する、クライアントを配布せずに業務ロジックを更新する、といった共有運用です。2026-07-28版のTransport概要が定義する通信方式は、公式仕様で確認できる事実です。stdioはクライアントが起動する子プロセスと改行区切りで通信し、Streamable HTTPは単一エンドポイントへメッセージ単位でPOSTします[1]。
一方、50拠点という数値と配置別の推奨は本稿の試算例であり、仕様が採用方式を決めているわけではありません。どちらもJSON-RPCの意味は共通で、選択対象は機能ではなく配置と配送方法です。
「まずstdioで作り、利用者が増えたらURLへ置き換える」では不十分です。共有認証、利用者別権限、同時実行、監査、停止権限まで変わるため、将来の配置が承認済みなら最初の設計票へ反映します。
判断を保留すべき案件もあります。AIホストが対応するMCP仕様版を確認できない、サーバーがローカル資産と社内共有DBを一つの処理で同時に更新する、利用者単位の責任者がいない、という状態ではTransportだけ選んでも運用できません。先にデータ境界を分け、読み取り用途を一件に絞ってから比較へ進みます。
二方式で変わる範囲と変わらない範囲
MCPのTools、Resources、Prompts、JSON-RPCメソッド、入力SchemaはTransportを変えても同じです。`tools/list`で能力を取得し、`tools/call`で実行するという契約を、stdioでは標準ストリームへ、Streamable HTTPではPOST本文へ載せます。MCPのアーキテクチャでは、一つのホストが複数クライアントを管理し、各クライアントは特定の一サーバーと通信します。ホストが接続権限、利用者同意、サーバー間の分離を担う点も方式共通です[6]。
変わるのは、メッセージの区切り、プロセスの所有者、資格情報の渡し方、通信断の検知、停止信号、ネットワーク防御です。stdioは一つの双方向ストリームを共有するため、要求の中止を`notifications/cancelled`で伝えます。Streamable HTTPは要求ごとに応答ストリームが分かれるため、そのストリームを閉じることが中止信号になります。中断試験を片方の手順だけで済ませると、長時間Toolが裏で実行を続ける恐れがあります。
共通: JSON-RPC / Tool定義 / Resource URI / Prompt引数stdio固有: 子プロセス / stdin・stdout / stderr / EOF終了HTTP固有: POST / JSONまたは要求単位SSE / HTTPヘッダー / OAuth方式外: 上流APIの業務仕様 / データ保持期間 / 更新承認者
比較資料では「MCP対応」を一行にせず、共通契約と方式固有条件を分けます。共通部分のテストが失敗したならToolまたはサーバー実装を直し、stdioだけ失敗するなら起動・ストリーム・環境変数を、HTTPだけ失敗するならURL・ヘッダー・Origin・認可を調べます。この切り分けにより、方式変更で直らない欠陥を移行理由にしなくて済みます。
八つの軸でstdioとStreamable HTTPを比べる
比較軸は、機能数ではなく本番運用で差が出る八項目に固定します。在庫照会Toolと入力24件を固定し、タイムアウトは10秒、上流APIは共通として、Transport以外の条件をそろえます。「stdioは無料、HTTPは高価」のような結論は、端末配布や問い合わせ対応を除外していることが多いため、運用担当者の時間も費用へ含めます。
| 比較軸 | stdio | Streamable HTTP | 確認する証拠 |
|---|---|---|---|
| 配置 | ホストが同一端末の子プロセスを起動する | 独立サービスが単一MCPエンドポイントを公開する | 構成図、起動主体、接続先一覧 |
| 利用者分離 | OSアカウントとプロセスごとに分けやすい | トークン、scope、テナント情報で要求ごとに判定する | 権限なし一覧と拒否ログ |
| 秘密情報 | 許可済み環境変数またはOSの秘密保管庫から渡す | Bearerトークンを各HTTP要求へ付ける | 設定票、マスク済み通信記録 |
| 共有性 | 端末ごとに配布・更新する | 複数クライアントが共通サービスを利用する | 対象端末数、利用者数、更新手順 |
| 障害範囲 | 通常は起動した利用者の処理に限定される | 共有サーバーの停止が複数部門へ波及し得る | 影響人数、復旧目標、縮退方法 |
| 観測 | クライアントがstderr、終了コード、起動時間を収集する | HTTP状態、要求ID、遅延、SSE切断を集約する | ダッシュボードと一件の追跡ログ |
| 停止 | stdinを閉じ、待機後にプロセスを終了する | 応答ストリームを閉じ、資格情報や経路を無効化する | 停止試験の時刻と残存処理 |
| 主な防御 | 実行ファイル、引数、作業領域、環境変数を制限する | TLS、Origin検証、認証、レート制限を組み合わせる | 負例のHTTP状態と監査記録 |
表の「共有性」が高くても、ただちにHTTPへ決めません。利用者が三人でも同じ端末の専用オペレーターだけが実行するならstdioで足りる場合があります。反対に利用者が一人でも、処理対象が隔離ネットワーク内にあり端末へ資格情報を置けないなら、管理されたリモートサービスが適切です。人数は代理指標であり、資産の所在と責任分界を優先します。
必須条件を一つでも満たせない方式は、点数計算の前に除外します。stdioで署名済み実行物を配れない、HTTPでTLSまたはOrigin検証を実装できない、どちらの方式でも更新操作を利用者が拒否できない、といった欠落は加点で相殺しません。比較表の目的は好みを数値化することではなく、採用後に説明できる判断記録を残すことです。
stdioを選ぶ案件と実装条件
stdioの公式仕様では、クライアントがMCPサーバーを子プロセスとして起動し、サーバーは`stdin`から読み、`stdout`へ書きます。一つのJSON-RPCメッセージは一行で、埋め込み改行を含められません。ログはUTF-8文字列として`stderr`へ出せますが、`stdout`へMCP以外の文字を出してはいけません[2]。この制約により、起動時の案内文やデバッグ用`console.log`が一つあるだけで、最初の応答を壊すことがあります。
適した例は、開発者のローカルGitリポジトリを検索する、デザイナーが自分の端末にある素材だけを読む、閉じた検証端末で社内CLIを呼ぶ、といった用途です。サーバーの実行権限は利用者を超えないようにし、作業ディレクトリを引数で明示します。環境変数はホストが許可リストから渡し、親プロセスの全環境を無条件に継承しない設計にします。
{ "command": "node", "args": ["C:/approved/mcp/inventory-server.mjs"], "env": { "INVENTORY_MODE": "read-only", "ALLOWED_SITE": "tokyo-01" }}
上の例は構造を示す想定例で、秘密値は載せていません。実ファイルのハッシュと署名者を配布台帳へ記録し、`command`を検索PATH任せにせず承認済みの絶対パスへ固定します。Toolがファイルパスを受け取る場合は、正規化後のパスが許可ルート内に残ることを検査します。`../`を含む入力、シンボリックリンク経由の脱出、巨大ファイル、読み取り中の削除を負例へ含めます。
終了時は、クライアントが子プロセスの入力ストリームを閉じ、終了を待ち、合理的な時間内に止まらなければOSの仕組みで強制終了します。サーバーはEOFを受けたら速やかに終了すべきです。業務上の合格条件は、通常終了が三秒以内、実行中Toolの中止が十秒以内、強制終了後に子プロセスが残らないこととします。数値は想定基準なので、実処理の復旧目標に合わせて承認前に固定します。stdioを見送る条件
利用者端末へ実行物を安全に配れない、端末ごとの更新状況を追跡できない、個人端末へ上流資格情報を置く必要がある、同じ処理を24時間共有サービスとして提供する、という案件には向きません。ローカル通信だから安全だとみなし、実行ファイルと環境変数の管理を省く運用も停止対象です。
Streamable HTTPを選ぶ案件と実装条件
Model Context Protocol公式仕様「Streamable HTTP」2026-07-28版は、サーバーが単一のMCPエンドポイントを公開し、クライアントが各JSON-RPCメッセージを別々のPOSTとして送る方式を定めています。要求への応答は一つのJSONオブジェクト、またはその要求に限定したSSEストリームです。2025系にあった常設GETストリームとプロトコル単位のセッションは現行版で削除されました[3]。そのため、新規実装で`Mcp-Session-Id`やスティッキーセッションを必須にするのは、旧世代との互換要件がある場合だけです。
HTTP要求には`MCP-Protocol-Version`と`Mcp-Method`が必要です。`tools/call`、`resources/read`、`prompts/get`では、対象名またはURIを反映した`Mcp-Name`も要求されます。サーバーはヘッダーと本文の不一致を400で拒否し、未実装メソッドはJSON-RPCの`-32601`を伴う404として返します。ゲートウェイが本文を開かなくてもルーティングや制限を行える一方、ヘッダー生成を古いクライアント実装へ任せると互換エラーが起きます。
POST /mcp HTTP/1.1Content-Type: application/jsonAccept: application/json, text/event-streamMCP-Protocol-Version: 2026-07-28Mcp-Method: tools/callMcp-Name: inventory_lookupAuthorization: Bearer <access-token>{"jsonrpc":"2.0","id":24,"method":"tools/call", "params":{"name":"inventory_lookup","arguments":{"sku":"A-1042"}, "_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28", "io.modelcontextprotocol/clientInfo":{"name":"sales-assist","version":"1.4.0"}, "io.modelcontextprotocol/clientCapabilities":{}}}}
この要求例のホスト名、Tool名、トークンは説明用です。実装では、受信した`Origin`が許可外なら403を返し、ローカルでHTTPサーバーを試す場合も`0.0.0.0`ではなく`127.0.0.1`へbindします。公式仕様が挙げるDNS rebinding対策は、OAuthがあれば不要になるものではありません。認証前の要求、認証済みの要求、ブラウザー由来の不正Originを別々に試験します。
共有運用では、タイムアウトと中止もHTTP方式に合わせます。SSE応答ストリームをクライアントが閉じたら、サーバーは該当要求の中止として扱い、可能な限り処理を止め、その要求へ追加メッセージを送ってはいけません。上流APIが中止を受け付けない場合は、結果を破棄するだけでなく、二重更新を防ぐ冪等キーや補償処理を設計します。切断後も更新が完了する可能性があるToolは、実行前確認と実行結果照会を必須にします。Streamable HTTPを見送る条件
運用者がいない単発の個人検証、ネットワーク公開を許可されていない機密端末、TLS終端とトークン保管を用意できない環境では構成が過大です。また、Origin検証を無効化しなければ接続できない、利用者別の権限を一つの共有APIキーで代用する、監査ログから要求者を特定できない場合は本番移行を止めます。
認証・権限・秘密情報の置き場所を分ける
MCPのAuthorization仕様はHTTPベースTransportを対象とし、stdioではこのOAuthフローを使わず、環境から資格情報を取得するよう示しています[4]。これはstdioなら本人確認が不要という意味ではありません。stdioでは、誰がホストを起動できるか、どの実行ファイルへどの環境変数を渡すか、OSアカウントがどのデータへ届くかを管理します。HTTPでは、利用者を認可サーバーで確認し、MCPサーバー向けのトークンとscopeを要求単位で検証します。
| 対象 | stdioでの管理 | Streamable HTTPでの管理 | 停止条件 |
|---|---|---|---|
| サーバー起動 | ホスト設定とOS実行権限 | サービスデプロイ権限 | 未署名物または未承認版を検出 |
| 上流資格情報 | 秘密保管庫から限定環境変数へ注入 | サーバー側保管庫から上流用トークンを取得 | ログやTool結果への露出 |
| MCP利用者 | 端末ログインとホストの接続許可 | OAuthの主体、audience、scope | 要求者を監査記録で特定不能 |
| 操作単位 | 公開するToolとローカルポリシー | 要求のscopeと業務属性を照合 | 読み取り権限で更新Toolが見える |
特にHTTPで、MCPクライアントから受け取ったトークンを上流の在庫APIへそのまま転送してはいけません。MCPサーバーは自分宛てのトークンを検証し、上流APIへは別の資格情報を使います。stdioでも同じ分離思想を適用し、ホストから受け取った環境変数を子プロセスが別用途へ転用しないよう、渡す変数名と利用先を固定します。
Tool、Resource、Promptの一覧は、接続方式とは別に権限で絞ります。`sales.read`だけの利用者には在庫照会Toolと商品仕様Resourceを見せ、在庫更新Toolは一覧から外します。更新scopeがあっても、数量変更は確認画面でSKU、変更前後、対象拠点を表示し、利用者が拒否できるようにします。Transportの接続成功を権限確認の代用にしないことが、二方式に共通する運用原則です。
方式別の失敗例と停止条件
stdioの失敗例1は、起動ログを`stdout`へ出すことです。JSON-RPCより先に「server started」という文字列が出ると、クライアントは不正メッセージとして扱います。対処はログを`stderr`へ移し、最初の一行から終了まで`stdout`がJSON-RPCだけであることを自動試験することです。同じ障害が二回続いたら配布版を無効化し、ハッシュが一致する修正版だけを再配布します。
stdioの失敗例2は、親プロセスの環境を丸ごと渡すことです。在庫照会には不要なクラウド管理キーや個人用トークンまで子プロセスから読める状態になります。環境変数の許可リストを三項目に絞る想定なら、四項目目が見えた時点で受入試験を不合格にします。秘密値そのものを試験ログへ出さず、変数名と存在有無だけを記録します。
HTTPの失敗例1は、2025系のセッション前提を2026系へ持ち込むことです。ゲートウェイが`Mcp-Session-Id`のない要求を拒否したり、常設GETストリームを待ち続けたりすると、現行クライアントは接続できません。仕様版ごとの入口を分け、2026系は各POSTを自己完結させます。旧世代も必要なら、期限と対象クライアントを台帳化し、自動フォールバックの結果をログへ残します。
HTTPの失敗例2は、ヘッダーと本文の検証をプロキシ任せにすることです。`Mcp-Name: inventory_lookup`なのに本文が`inventory_update`でも通ると、ルーティング制限と実処理が食い違います。サーバー自身が不一致を400で拒否する負例を用意し、一件でも200になれば公開を停止します。Origin未設定の非ブラウザークライアントと、不正Originを送るブラウザー想定要求も混同せず確認します。
共通の失敗例は、接続断を業務取消とみなすことです。利用者が画面を閉じても、上流の注文確定が完了している場合があります。更新Toolは要求IDと業務冪等キーを保存し、再接続後に状態を照会できるようにします。取消不能の処理を結果不明のまま自動再試行する設計、拒否後にscopeを広げて再実行する設計、監査ログに利用者とTool引数が結び付かない設計は、方式を問わず本番候補から外します。
| 検出内容 | 直ちに止める範囲 | 再開に必要な証拠 |
|---|---|---|
| stdoutへ非MCP文字 | 該当stdio配布版の起動 | 全出力行の形式試験と新ハッシュ |
| 秘密値のログ露出 | 両方式の対象資格情報 | 失効記録、ログ削除判断、再発防止試験 |
| 不正Originを許可 | HTTPエンドポイントの外部受付 | 403負例と許可元の棚卸し |
| 権限外Toolを表示 | 該当利用者群の接続 | 一覧と実行の両方が拒否される結果 |
| 中止後も二重更新 | 更新系Toolすべて | 冪等性試験と補償手順の承認 |
24件の負例を含む比較試験
PoCは成功件数だけでなく、正常8件、入力不正6件、権限不正4件、通信・中止4件、復旧2件の計24件で構成します。件数は想定例です。実データを使う場合は個人情報を除き、SKUの存在、在庫ゼロ、上限超過、上流タイムアウトなど業務上の分岐を維持します。二方式で同じToolコードを使えない場合でも、入力と期待する業務結果は同一にします。
| 区分 | 件数 | stdioで追加する確認 | HTTPで追加する確認 | 合格条件 |
|---|---|---|---|---|
| 正常 | 8 | 起動から一覧取得、Tool応答 | JSON応答とSSE応答の双方 | 期待SKUと数量が8件一致 |
| 入力不正 | 6 | 改行混入、許可外パス、巨大入力 | 本文不正、ヘッダー不一致、巨大要求 | 上流処理前に6件拒否 |
| 権限不正 | 4 | 許可外環境と更新Tool | 期限切れ、audience違い、scope不足 | 情報を返さず4件拒否 |
| 通信・中止 | 4 | 子プロセス終了、cancel通知 | SSE切断、不正Origin | 残存処理と追加出力がゼロ |
| 復旧 | 2 | 再起動後の再試行 | 別インスタンスへの再試行 | 二重更新なしで状態確定 |
測定値は、接続成功率だけでなく、p95応答時間、拒否の正確さ、中止完了時間、復旧時の重複更新数、端末またはサーバーへの展開時間を残します。例えば24件を各方式で三周し、計72要求のうち期待結果と一致した数を母数にします。71件成功なら成功率は`71 ÷ 72 × 100 = 98.6%`です。これは想定計算であり、本番実績ではありません。
受入率 = 期待結果と一致した要求数 ÷ 総要求数 × 100拒否精度 = 正しく拒否した負例数 ÷ 拒否すべき負例数 × 100復旧重複率 = 二重処理件数 ÷ 復旧試験件数 × 100月間運用時間 = 定例作業 + 配布・更新 + 障害対応 + 権限変更
合格線の想定例は、受入率100%、拒否精度100%、復旧重複率0%、重大な秘密漏えい0件です。応答時間は業務要件に応じて別に設定します。セキュリティ負例は平均点へ入れず、一件の失敗で不合格とします。クライアント版、サーバー版、仕様版、実行時刻、入力IDを記録し、方式ごとに条件が違っていないか第三者が追跡できる形にします。
乗り換えと併用の費用を見積もる
stdioからStreamable HTTPへ移す際、Tool登録コードだけを再利用できても、認可、利用者識別、同時実行、レート制限、TLS、Origin、監視、デプロイ、障害対応が追加されます。反対方向では、各端末への実行物配布、OS差、秘密情報の注入、バージョン回収、クライアント設定の更新が発生します。Transportのコード差分だけを移行費と呼ばないようにします。
MCP 2026-07-28と旧世代の互換も別費用です。公式のVersioning and Compatibilityは、現行方式と`initialize`を必要とする旧方式の検出・フォールバックを定めています[5]。旧クライアントを残すなら、対象数、終了日、互換試験、障害窓口を見積もります。「当面対応」と期限を置かない併用は、分岐が恒久化するため避けます。
12カ月移行費 = 実装工数 × 社内時間単価 + 基盤・証明書・監視費 + 端末配布またはクライアント更新費 + 互換運用月数 × 月次保守費 + 24件受入試験と切り戻し訓練費
想定例として、HTTP化の実装80時間、基盤構築40時間、試験32時間、時間単価8,000円、基盤費が月4万円なら、初年度は`(80 + 40 + 32) × 8,000 + 40,000 × 12 = 1,696,000円`です。一方、stdioを60端末へ四半期ごとに更新し、一端末15分なら、配布確認だけで`60 × 0.25時間 × 4回 = 60時間`です。実際の採択では、自社の端末数、障害率、単価へ置き換えます。
併用するなら役割を重ねません。個人のローカルリポジトリ検索はstdio、共有在庫照会はHTTPというように、データ所有者と利用者範囲でサーバーを分けます。同じ更新Toolを両方式へ無期限に公開すると、監査と権限の正本が二つになります。併用終了日、正本となる実装、移行中に許す操作、切り戻し先を決定票へ記載します。
100点評価票で採択を確定する
評価票は、候補方式それぞれへ点を付けるのではなく、案件要件がどちらに寄るかを記録します。例えば「共有利用」はHTTPへ15点、「端末内データ」はstdioへ15点です。点数は意思決定の補助であり、必須防御の不足を埋めません。先に失格条件を判定し、両方が残った場合だけ合計を使います。
| 判断項目 | 配点 | stdioへ加点する条件 | HTTPへ加点する条件 |
|---|---|---|---|
| 資産の所在 | 20 | 対象が利用者端末に閉じる | 対象が管理ネットワーク内の共有資産 |
| 利用者と拠点 | 15 | 一端末・一利用者単位で完結 | 複数利用者または複数拠点で共有 |
| 資格情報 | 15 | OSアカウントの範囲で渡せる | 中央保管と利用者別OAuthが必要 |
| 更新頻度 | 10 | 端末配布を低頻度で管理可能 | サーバー側で頻繁に更新したい |
| 障害の許容 | 10 | 利用者単位の停止を優先 | 冗長化と中央復旧を優先 |
| 観測要件 | 10 | 端末ログで追跡できる | 組織横断の監査と指標が必要 |
| ネットワーク制約 | 10 | 外部公開が禁止または不要 | 管理済みHTTPS経路を利用可能 |
| 12カ月費用 | 10 | 端末配布を含めて低い | 基盤運用を含めて低い |
失格条件は、stdioなら実行物の真正性を確認できない、必要以上の環境変数を除けない、終了後に子プロセスが残ることです。HTTPならTLSなし、不正Originを許可、利用者別トークンを検証できない、ヘッダーと本文の不一致を受理することです。共通では、更新Toolを利用者が拒否できない、監査記録から要求者を特定できない、二重更新を防げない場合を失格とします。
合計が70点以上の方式を第一候補、50〜69点を条件付き候補、49点以下を見送りとする想定例を使えます。両方式が70点以上なら、単一方式へ無理に寄せず、資産境界でサーバーを分ける案を検討します。ただし同じ業務能力を二重運用する期間は最長三カ月など期限を設け、終了条件を満たせなければ新規利用者の追加を止めます。
接続方式の選定で残る疑問
ローカルのStreamable HTTPはstdioと等価ですか？
等価ではありません。`127.0.0.1`だけへbindしても、HTTPヘッダー、Origin検証、要求単位のPOST、中止時のストリーム処理が必要です。HTTP対応SDKを同一端末で試験したい目的なら有効ですが、stdioより単純になるとは限りません。
stdioならOAuthを実装しなくてよいので安全ですか？
OAuthフローの対象外でも、子プロセスの実行者、環境変数、作業領域、公開Toolを制限する必要があります。端末へ高権限の共通キーを置くなら、ネットワーク認証がないことより資格情報の配布が大きなリスクになります。
SSEを常時開けば2026-07-28版へ対応できますか？
通常要求のSSEは要求単位で、最終応答後に閉じます。長期通知は`subscriptions/listen`の応答ストリームを使います。2025系の常設GETストリームをそのまま現行方式として扱わず、対応仕様版を明記してください。
最初は両方式を自動フォールバックしてもよいですか？
互換対象が特定され、試行順、タイムアウト、認証情報の送信先、終了期限を管理できる場合に限ります。接続失敗のたびに別URLやローカル実行へ無条件で切り替えると、利用者が意図しないサーバーへデータを送る恐れがあります。
設計会議へ提出する接続方式決定票
次に取る行動は、対象Tool、資産の所在、利用者数、実行主体、必要scope、秘密情報の保管先、仕様版、24件の試験結果、停止操作、12カ月費用、互換終了日を一枚へ集約することです。結論は「stdio採用」「Streamable HTTP採用」「資産境界で分離」「前提不足で保留」の四択にし、採用方式の得点だけでなく失格条件がゼロであることを承認者が確認します。
本番へ進める条件は、負例を含む24件がすべて期待どおり、秘密値の露出がゼロ、中止後の二重更新がゼロ、停止操作を担当者が手順なしで再現できることです。一つでも未達なら「接続できた」という記録を本番承認に使わず、対象を読み取り限定へ戻します。決定票には再試験日と修正所有者を付け、方式を選んだ理由が将来の担当者にも追える状態で保管します。
参考文献・出典
- Model Context Protocol「Transports Overview」（Protocol Revision 2026-07-28、2026年7月30日参照）
- Model Context Protocol「stdio」（Protocol Revision 2026-07-28、2026年7月30日参照）
- Model Context Protocol「Streamable HTTP」（Protocol Revision 2026-07-28、2026年7月30日参照）
- Model Context Protocol「Authorization」（Protocol Revision 2026-07-28、2026年7月30日参照）
- Model Context Protocol「Versioning and Compatibility」（Protocol Revision 2026-07-28、2026年7月30日参照）
- Model Context Protocol「Architecture」（Protocol Revision 2026-07-28、2026年7月30日参照）
本稿の費用、件数、合格線は比較方法を示す想定例です。実績値ではありません。仕様版と採用製品の対応状況は公開直前に再確認してください。
