🧭 MCP新ロードマップが優先するエージェントID、HTTP統一、長時間実行

Model Context Protocol（MCP）のコアメンテナが、2026-08-22 に新しいロードマップを公開しました。仕様改訂 2026-07-28 の先、6〜12 か月の優先領域を 5 つに整理したものです。

この記事では、5 つの優先領域が何を解こうとしているのか、そのうち今日すでに使えるものはどれで、まだ提案段階のものはどれかを、仕様・SEP・RFC の粒度まで落として整理します。読み終えたときに、次のことが判断できる状態を目指します。

• 自分の MCP クライアント / サーバーが、どの呼び出し元類型に当てはまるか
• いま本番へ入れてよい認可経路と、Final を待つべき経路の線引き
• 長時間実行・サーバー起点イベントを、現行仕様の範囲でどう組むか

なお公式ロードマップは、内容を current thinking（現時点の考え）と位置づけています。次リビジョンへの確約ではありません。この記事も同じ前提で読んでください。

この記事の主眼は、2026-03 から 2026-08 への優先領域の組み替えと、いま採用してよいものと待つべきものの線引きです。土台となる 2026-07-28 仕様そのもの（ステートレス化、server/discover、キャッシュ、Tasks）と EMA の詳細フローは、ロードマップを読むのに必要な範囲で本文中に要約し、根拠は各節から公式仕様へ直接リンクしています。

この記事の全体像。以下、順に解説します。

概要

新ロードマップの出発点は、呼び出し元の変化です。現行の MCP 認可は、人がブラウザで同意する対話型フローを中心に組み立てられています。しかし実際の呼び出し元は、クラウド上のワークロード、ユーザー不在の代理実行、親より狭い権限のサブエージェントへ広がりました。新ロードマップは、エージェント ID・委譲・非同期イベント・長時間タスクを優先領域へ引き上げます。

前提として、MCP の認可はプロトコル全体では OPTIONAL です。HTTP ベースのトランスポートは認可仕様に適合すべき（SHOULD）とされ、stdio は環境から資格情報を取得し、この認可仕様には従うべきでない（SHOULD NOT）とされています。

旧ロードマップとの差分

2026-03-09 の旧ロードマップは 4 優先領域で、Horizon に triggers、result types、deeper security、extensions を置いていました。2026-08-22 の新ロードマップは 5 優先領域です。Horizon にあった server-initiated events、result type、agent identity を本線へ上げています。ガバナンス成熟は 2026-07-28 の周期で進捗したため、独立した優先領域からは外れました。

期間内 deliverable と担当

優先領域内の SEP は審査が先行します。領域外の SEP も審査対象ですが、メンテナの時間は領域内へ先に割かれます。

期間内 deliverable の外側（公式ロードマップの「Beyond these」）は次のとおりです。

出荷済みと未出荷の線引き

ロードマップを読むうえで最も実務に効くのは、成熟度の区別です。次の 3 段階で見ると判断を誤りません。

1. コア / Stable: 仕様 2026-07-28 本体、または公式拡張の stable。本番前提で採用できます。
2. 公開済み Draft: 仕様が公開され実装もできますが、互換性の変更があり得ます。受容できる範囲で採用します。
3. 未マージ SEP / 議論中: Open PR、forming の WG、Horizon 項目。ゲートや SDK 制約へ落としません。

Tasks のポーリング（tasks/get）、途中入力（tasks/update）、協調的キャンセル（tasks/cancel）は拡張として出荷済みです。完了をサーバーからプッシュする webhooks / channels は未出荷です。

ID-JAG を使う Enterprise-Managed Authorization（EMA）も拡張として出荷済みです。一方、エージェント自身のワークロード ID（WIF）と、親から子への狭い権限委譲（RFC 8693 の MCP プロファイル）は未出荷です。

採用判断の目安を、GA 相当と見なせる条件として置いておきます。

• SEP-1933: GitHub PR が Merged し、仕様改訂本文に入るまで、本番 MCP AS へ jwt-bearer を投げない
• DPoP: MCP Authorization が token_type=DPoP を MUST / SHOULD と書くまで、全社必須化しない
• Agent Identity WG: community の WG ページが forming から外れるまで、成果物をコア扱いしない
• HTTP over stdio / ETag / webhooks: Transports または Triggers and Events の SEP が Final になるまで、現行パイプラインを維持する

認可方式の比較

比較の軸はグラントと主体です。トークンが JWT か opaque かは Authorization Server（AS）の実装選択なので、プロトコル固有の列とは分けています。RFC 8628 Device Flow は MCP 現行認可の採用グラントではありませんが、関連する OAuth グラントとして併記します。

DPoP（RFC 9449）は、これらのグラントの上に載る所持証明です。Agent Identity WG が仕様確定と普及を期間内対象にしています。

ユーザー不在の呼び出し元については、もう 1 つ公式拡張があります。OAuth Client Credentials（io.modelcontextprotocol/oauth-client-credentials）です。バックグラウンドサービス、CI/CD、サーバー間連携、デーモン向けに、OAuth 2.0 client credentials フローを MCP へ持ち込みます。資格情報は client secret か、推奨される署名 JWT アサーション（RFC 7523）です。ext-auth リポジトリ上の成熟度は Draft で、stable の EMA とは段階が違います。実装はできますが、互換性の変更があり得る前提で採用してください。

WIF SEP-1933 と混同しないでください。両者はユーザー不在という点だけが共通です。

つまり「常駐型は WIF が Final になるまで API キーのまま」ではありません。事前登録済みの資格情報で足りるなら、Client Credentials 拡張が貼り付け API キーからの現実的な移行先になります。プラットフォームの federated identity をそのまま使いたい場合に限り、WIF を待つことになります。

ユースケース別の推奨

特徴

• 優先領域の再編成: 2026-03 の 4 領域と Horizon を、2026-08 の 5 領域へ組み替えます。
• 方向の明示: 公式 Note は current thinking として示します。SEP 審査の時間配分の指針になります。
• 対話型からエージェント ID へ: 現行認可はブラウザ同意です。新領域はクラウドワークロード ID、ユーザー代理、サブエージェント委譲を、既存 IETF 規格の組み合わせで扱います。
• 出荷済み EMA と未出荷 WIF の併用: 企業ユーザー経路の ID-JAG は拡張として安定しています。ワークロード自身の JWT-bearer は SEP-1933 として Open PR です。
• 所持証明の追加: DPoP の確定と普及を、forming 中の Agent Identity WG が担います。
• 長時間実行の部品揃え: Tasks 拡張、subscriptions/listen、progress は既に使えます。サーバー起点の webhooks / channels と、ライフサイクル・キャンセル・エラー面の共有が期間内の焦点です。
• 単一トランスポート: リモートは通常の HTTP ワークロードです。ローカル stdio も Streamable HTTP の単一バインディングへ寄せます。
• キャッシュの深化: ttlMs と cacheScope に加え、ETag で primitive 結果の版管理を足します。
• 結果形の一本化: tools/call が content と structuredContent を同時に返す現状を、一つの契約へ寄せます。
• 段階的発見: 巨大なツール一覧を最初からモデルへ渡す代わりに、会話の焦点に合わせてカタログを開きます。
• 認可の適用範囲: 認可は OPTIONAL です。適用対象は HTTP です。stdio は環境の資格情報です。

構造

ここからは、5 つの優先領域を C4 相当の粒度で分解します。対象は OSS 製品ではなく提案フレームワークなので、C4 は論理構造への読み替えです。出荷済みは仕様 2026-07-28 コアまたは公式拡張の stable、未出荷はロードマップ期間の deliverable・Open PR・WG forming・議論中を指します。

システムコンテキスト図

対象システムは MCP Host / Client / Server / AS です。現行認可は対話型ユーザーがブラウザで同意する前提です。ロードマップは、クラウドエージェントとサブエージェントを第一級の呼び出し元にします。

アクターの内訳です。

対象システムの内訳です。

外部システムの内訳です。

コンテナ図

対象システムを 5 つの優先領域へ分解します。この粒度では具体 SEP 名を使わず、役割で表現します。

Messaging の内訳です。

Transport の内訳です。

Identity の内訳です。

Primitives と SDK の内訳です。

コンポーネント図

各コンテナを、SEP と RFC の具体名でドリルダウンします。まず Messaging と Transport です。

続いて Identity、Primitives、SDK です。

Messaging コンポーネントの内訳です。

Transport コンポーネントの内訳です。

Identity コンポーネントの内訳です。

Primitives と SDK コンポーネントの内訳です。

現行サーバーが頼っている貼り付け API キーと長寿命リフレッシュトークンは、標準化対象の反面です。

データ

ロードマップが扱う主体とトークンを、型として並べます。以下の InteractiveClient / CloudWorkloadAgent / SubAgent は、ロードマップが挙げる呼び出し元 3 類型に付けた概念名です。MCP JSON Schema の型名ではありません（仕様未記載）。

概念モデル

呼び出し元 3 類型です。

トークン成果物です。

タスク・トランスポート・能力の成果物です。

情報モデル

属性名はハイフンを避けています。対応する HTTP ヘッダ名は、後続の表に書きます。まず呼び出し元とトークンです。

次にトークン交換とタスクです。

最後にトランスポートと能力・メタデータです。

図を読むうえでの注意です。

• InteractiveClient.identityMode などは、3 類型を区別するために置いた識別用スロットです（仕様未記載）。
• CreateTaskResult は仕様上 Result & Task のフラット合成です。継承ではありません。作成応答の resultType は "task"、tasks/get 応答の resultType は "complete" です。
• TokenExchangeRequest は RFC 8693 の token-exchange と RFC 7523 の jwt-bearer を同じフォームに載せた概念クラスです。実際の grant_type はどちらか一方です。
• AuthorizationServerMetadata.authorization_grant_profiles_supported は EMA / ID-JAG の発見キーです。RFC 8414 の MCP AS MUST 集合ではありません。
• AccessToken.cnf はトークン応答の JSON フィールドではありません。DPoP のトークン応答は access_token / token_type / expires_in / refresh_token です。公開鍵との結び付き（cnf.jkt）は、JWT アクセストークンの内部クレーム、または opaque token の introspection 応答に現れます。図では所持証明との関連を示すためだけに並べています。

トークン成果物の主要属性です。

タスクとトランスポートの主要属性です。

構築方法

• Authorization は OPTIONAL です。HTTP 実装は SHOULD、stdio は SHOULD NOT です。
• 現行の TypeScript SDK v2 は @modelcontextprotocol/server と @modelcontextprotocol/client に分割されています。
• Streamable HTTP は単一 POST エンドポイントです。stdio は改行区切り JSON-RPC です。

必須パラメータ

TypeScript SDK v2 の初回セットアップ

v1 の @modelcontextprotocol/sdk 単一パッケージとは import パスが異なります。対象仕様は 2026-07-28 です。

npm install @modelcontextprotocol/server
npm install @modelcontextprotocol/client

サーバー側です。ここが v1 からの最大の落とし穴で、McpServer を StdioServerTransport へ直接 connect した構成は 2025 系プロトコルしか話しません。SDK を上げても wire 上は変わらないため、2026-07-28 を出すには serveStdio(() => buildServer()) を使います。ファクトリは接続ごとに 1 インスタンスへ固定され、接続冒頭のやり取りでその接続の era が決まります。

import { McpServer } from '@modelcontextprotocol/server';
import { serveStdio } from '@modelcontextprotocol/server/stdio';
import * as z from 'zod/v4';

const handle = serveStdio(() => {
  const server = new McpServer({ name: 'greeting-server', version: '1.0.0' });

  server.registerTool(
    'greet',
    {
      description: 'Greet someone by name',
      inputSchema: z.object({ name: z.string() })
    },
    async ({ name }) => ({
      content: [{ type: 'text', text: `Hello, ${name}!` }]
    })
  );

  return server;
});

process.on('SIGINT', () => {
  void handle.close();
});

2025 系の接続を拒否したい場合は serveStdio(factory, { legacy: 'reject' }) を指定します。なお 2026-07-28 に固定された接続では initialize が走らないため、getClientCapabilities() と getClientVersion() は undefined を返し、ハンドラはリクエストごとの識別子を ctx.mcpReq.envelope から読みます。

クライアント側です。既定は legacy の initialize なので、versionNegotiation を明示しないと server/discover 経路になりません。

import { Client } from '@modelcontextprotocol/client';
import { StdioClientTransport } from '@modelcontextprotocol/client/stdio';

const client = new Client(
  { name: 'my-first-client', version: '1.0.0' },
  { versionNegotiation: { mode: 'auto' } }
);
const transport = new StdioClientTransport({
  command: 'npx',
  args: ['tsx', 'src/index.ts']
});
await client.connect(transport);

const { tools } = await client.listTools();
const result = await client.callTool({
  name: 'greet',
  arguments: { name: 'Ada' }
});
await client.close();

mode: 'auto' では、まず server/discover を試し、応答しなければ legacy へフォールバックします。フォールバックには supported-versions のリストに 2025 系リビジョンが残っている必要があり、modern のみのリストでは connect() が reject します。ネゴシエート結果は client.getProtocolEra() で確認できます。

stdio トランスポート（現行）

クライアントがサーバーを subprocess として起動します。1 メッセージは 1 行で、埋め込み改行は禁止です。ヘッダ層はありません。プロトコル版は本文の _meta に載ります。資格情報の環境変数名は公式未記載です。

{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"greet","arguments":{"name":"Ada"},"_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28","io.modelcontextprotocol/clientInfo":{"name":"ExampleClient","version":"1.0.0"},"io.modelcontextprotocol/clientCapabilities":{}}}}

利用方法

• 対話型は Protected Resource Metadata から CIMD と PKCE へ進みます。
• 常駐型の jwt-bearer は実装案です。SEP-1933 は Open PR です。
• 長時間 tools/call は Tasks 拡張の CreateTaskResult を扱います。

Streamable HTTP の必須ヘッダ付き POST

サーバーは単一 MCP エンドポイントを POST で公開します。Origin 検証は MUST です。ローカルは 127.0.0.1 bind が SHOULD です。ヘッダと本文の不一致は HTTP 400 と JSON-RPC -32020（HeaderMismatch）です。

POST /mcp HTTP/1.1
Host: mcp.example.com
Content-Type: application/json
Accept: application/json, text/event-stream
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Origin: https://app.example.com
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_weather

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "location": "Seattle, WA"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "ExampleClient",
        "version": "1.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

Streamable HTTP では、キャンセルは SSE 応答ストリームを閉じることです。notifications/cancelled は stdio 用です。

対話型クライアント: PRM から CIMD と PKCE へ

まず未認可アクセスに対する 401 応答です。

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
                         scope="files:read"

指された Protected Resource Metadata です。

{
  "resource": "https://mcp.example.com/mcp",
  "authorization_servers": ["https://auth.example.com"],
  "scopes_supported": ["files:read", "files:write"]
}

トークンリクエストです。

POST /token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=http%3A%2F%2F127.0.0.1%3A3000%2Fcallback
&client_id=https%3A%2F%2Fapp.example.com%2Foauth%2Fclient-metadata.json
&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
&resource=https%3A%2F%2Fmcp.example.com%2Fmcp

resource は認可リクエストとトークンリクエストの両方で MUST です。アクセストークンを URI クエリに含めてはなりません。

常駐型クライアント: SEP-1933 の jwt-bearer（実装案）

以下は SEP-1933 PR（Status: Draft）と RFC 7523 §2.1 から組み立てた実装案です。2026-07-28 のコア Authorization には含まれません。スコープは、エージェントが自分自身として動く場合です。

POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&assertion=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJpc3MiOiJodHRwczovL2t1YmVybmV0ZXMuZXhhbXBsZS8iLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6ZGVmYXVsdDptY3AtYWdlbnQiLCJhdWQiOiJodHRwczovL2FzLmV4YW1wbGUuY29tIiwiaWF0IjoxNzg3NzQwMDAwLCJleHAiOjE3ODc3NDAzNjB9.signature
&resource=https%3A%2F%2Fmcp.example.com%2Fmcp

assertion の中身は次のとおりです（署名部分のみ signature に置き換えています）。RFC 7523 §3 は iss / sub / aud / exp を MUST としているので、これらを削ってはいけません。

{"alg":"ES256","kid":"16"}
{
  "iss": "https://kubernetes.example/",
  "sub": "system:serviceaccount:default:mcp-agent",
  "aud": "https://as.example.com",
  "iat": 1787740000,
  "exp": 1787740360
}

AS は iss が trusted issuer か判定し、OIDC Discovery の jwks_uri で JWT を検証して、MCP アクセストークンを発行します。WIT（jwt+wit）を RFC 7523 の assertion にすることは、SEP 作者コメントで対象外とされています。

対話型エンタープライズ: EMA の ID-JAG

EMA は公式拡張の stable です。ユーザーを MCP AS の authorization endpoint へリダイレクトしてはなりません。AS が ID-JAG を受け付けるかは、metadata の authorization_grant_profiles_supported に urn:ietf:params:oauth:grant-profile:id-jag があるかで判定します。

第 1 段は IdP での ID-JAG 取得です。

POST /oauth2/token HTTP/1.1
Host: acme.idp.example
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&requested_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aid-jag
&audience=https%3A%2F%2Fauth.chat.example%2F
&resource=https%3A%2F%2Fmcp.chat.example%2F
&scope=chat.read+chat.history
&subject_token=eyJraWQiOiJzMTZ0cVNtODhwREo4VGZCXzdrSEtQ...
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aid_token

第 2 段は MCP AS でのアクセストークン取得です。

POST /oauth2/token HTTP/1.1
Host: auth.chat.example
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&assertion=eyJhbGciOiJIUzI1NiIsI...
&client_id=https%3A%2F%2Fclient.example.com%2Fclient.json

サブエージェント: RFC 8693（実装案）

狭い権限の委譲はロードマップ項目であり、MCP 固有のメソッド名は公式未記載です。以下は RFC 8693 §2.1 / §2.3 に沿った形です。EMA の ID-JAG は従業員 SSO 経路であり、この節のサブエージェント委譲とは別物です。

POST /as/token.oauth2 HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&resource=https%3A%2F%2Fmcp.example.com%2Fmcp
&scope=files%3Aread
&subject_token=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token
&actor_token=eyJhbGciOiJFUzI1NiIsInN1YiI6InN1Yi1hZ2VudCJ9...
&actor_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt

actor_token を省略すると impersonation 寄りになります。RFC 8693 の act claim が委譲チェーンを表現します。

DPoP（実装案。RFC 9449、MCP 仕様としては未 finalize）

2026-07-28 の MCP Authorization では、保護リソース要求は Authorization: Bearer です。以下は RFC 9449 側のヘッダ例です。

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6IkVDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCRnMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JEQSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiItQndDM0VTYzZhY2MybFRjIiwiaHRtIjoiUE9TVCIsImh0dSI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIiwiaWF0IjoxNTYyMjYyNjE2fQ.2-GxA6T8lP4vfrg8v-FdWP0A0zdrj8igiMLvqRMUvwnQg4PtFLbdLXiOSsX0x7NVY-FNyJK70nfbV37xRZT3Lg

grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA

DPoP proof は header に typ / alg と公開鍵 jwk、payload に jti / htm / htu / iat が必須です（RFC 9449 §4.2）。短縮する場合もこれらを削らないでください。

成功時の token_type は RFC 9449 では DPoP です。保護リソースでは Authorization: DPoP と DPoP ヘッダを併用します。MCP へ適用するのは finalize 後です。

Tasks 拡張

拡張 ID は io.modelcontextprotocol/tasks です。サーバーは、クライアントが宣言していない要求に CreateTaskResult を返してはなりません。タスク化するかどうかは、サーバーがリクエスト単位で決めます。フィールド名は ext-tasks の schema/2026-07-28/schema.ts に従います（ttlMs / pollIntervalMs であり、旧 experimental の ttl / tasks/result ではありません）。

まずクライアントが拡張をオプトインして呼び出します。

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "run_pipeline",
    "arguments": { "repo": "example/app" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": {
        "extensions": {
          "io.modelcontextprotocol/tasks": {}
        }
      }
    }
  }
}

サーバーは同期結果の代わりに CreateTaskResult を返します。

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "task",
    "taskId": "786512e2-9e0d-44bd-8f29-789f320fe840",
    "status": "working",
    "createdAt": "2026-07-28T10:30:00Z",
    "lastUpdatedAt": "2026-07-28T10:30:00Z",
    "ttlMs": 3600000,
    "pollIntervalMs": 5000
  }
}

以降はクライアントがポーリングします。なお 2026-07-28 では _meta（protocolVersion と clientCapabilities）が全リクエストで必須で、サーバーは過去のリクエストから能力を推測してはなりません。以下の tasks/get / tasks/update / tasks/cancel / subscriptions/listen の例は紙幅の都合で共通の _meta を省略しているため、そのままでは送信できません。実装では上の tools/call と同じ _meta を毎回付けてください。

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tasks/get",
  "params": {
    "taskId": "786512e2-9e0d-44bd-8f29-789f320fe840"
  }
}

tasks/get の resultType は "complete" です。Streamable HTTP では Mcp-Name ヘッダに taskId を載せます。

途中入力は、status: "input_required" の inputRequests に対して tasks/update の inputResponses で返します。キーはタスク寿命中に再利用してはなりません。

{
  "jsonrpc": "2.0",
  "id": 6,
  "method": "tasks/update",
  "params": {
    "taskId": "786512e2-9e0d-44bd-8f29-789f320fe840",
    "inputResponses": {
      "name": {
        "action": "accept",
        "content": {
          "input": "Luca"
        }
      }
    }
  }
}

キャンセルは協調的です。

{
  "jsonrpc": "2.0",
  "id": 5,
  "method": "tasks/cancel",
  "params": {
    "taskId": "786512e2-9e0d-44bd-8f29-789f320fe840"
  }
}

ack しても最終状態が cancelled 以外になり得ます。なお tasks/list は SEP-2663 で削除済みです。

通知は subscriptions/listen の params.notifications.taskIds です（SEP-2663）。

{
  "jsonrpc": "2.0",
  "id": 6,
  "method": "subscriptions/listen",
  "params": {
    "notifications": {
      "taskIds": ["786512e2-9e0d-44bd-8f29-789f320fe840"]
    }
  }
}

ただしコア仕様ページの Notification Filter 表は toolsListChanged 等の 4 キーだけを列挙しており、TypeScript SDK v2.0.0 はフィルタを閉じたオブジェクトにしているため、taskIds がパースで落ちる既知の隙間があります（typescript-sdk#2569）。実装上はポーリングを既定にしておくのが安全です。

能力不足時のプロトコルエラーは -32021（Missing Required Client Capability）です。正本はコア schema と SEP-2663 です。

HTTP over stdio（未出荷）

現行の stdio は改行区切り JSON-RPC です。ロードマップは Streamable HTTP を stdin/stdout 上の単一バインディングにする方向を示していますが、HTTP/2 のフレームレイアウトを含め公式仕様は未出荷です。推測でフレーム実装を先回りしないでください。

運用

長時間タスク

ブロッキングな tools/call は、プロキシ・LB・クライアントのアイドルタイムアウトで切れます。Tasks は耐久ハンドルを返し、結果を接続の生死から切り離します。コアはリクエスト単位 SSE の再開（Last-Event-ID）を削除済みです。

運用ルールは次のとおりです。

• クライアントは pollIntervalMs を尊重します。
• 通知を使う場合も、欠落時のフォールバックとしてポーリングを残します。
• subscriptions/listen の長寿命 SSE では、サーバーが SSE コメント行（:）を定期送出します。
• HTTP では X-Accel-Buffering: no を付与します（SHOULD）。
• クライアントはクラッシュ耐性のため taskId を耐久ストアへ書きます。
• HTTP でリクエスト SSE を閉じると、そのリクエストはキャンセル扱い（MUST）になります。Tasks の作業はストリーム切断では止まりません。

クライアント側の最小実装です。

import json
import time
from pathlib import Path

STATE = Path("/var/lib/mcp/task-state.json")

def persist_task(task: dict) -> None:
    STATE.write_text(json.dumps({
        "taskId": task["taskId"],
        "createdAt": task["createdAt"],
        "ttlMs": task.get("ttlMs"),
    }))

def resume_or_poll(rpc, task: dict) -> dict:
    persist_task(task)
    interval_ms = task.get("pollIntervalMs") or 5000
    while True:
        current = rpc("tasks/get", {"taskId": task["taskId"]})
        status = current["status"]
        if status in ("completed", "failed", "cancelled"):
            STATE.unlink(missing_ok=True)
            return current
        if status == "input_required":
            return current
        time.sleep(max(interval_ms, 1000) / 1000)
        interval_ms = current.get("pollIntervalMs") or interval_ms

HTTP 統一とゲートウェイ

2026-07-28 以降、リモート MCP は通常の HTTP サービスと同じ運用面を持ちます。ゲートウェイは本文をパースせず、ヘッダでルーティングできます。一方、本文を処理するサーバーはヘッダと本文の不一致を MUST で検出し、-32020 HeaderMismatch を返します。

次は Mcp-Method の照合だけを抜き出した断片です。これ単体では仕様を満たしません。実装では MCP-Protocol-Version、Mcp-Method、対象メソッドの Mcp-Name、および自分が解釈する Mcp-Param-* のすべてについて、欠落・Base64 デコード失敗・本文との不一致を同じ -32020 として拒否します。

function assertMethodMatches(headers, body) {
  const method = headers["mcp-method"];
  if (method !== body.method) {
    return {
      http: 400,
      error: {
        code: -32020,
        message: `Header mismatch: Mcp-Method '${method}' does not match body '${body.method}'`,
      },
    };
  }
  return null;
}

非 ASCII の Mcp-Name は =?base64?...?= センチネルです。サーバーはデコードしてから本文と比較します。中間装置がポリシーをヘッダに依存する場合は、MCP-Protocol-Version がヘッダ検証を要求する版であることを確認します。

エージェント ID の移行準備

監査ログに残す主体は次のとおりです。

EMA の IdP 監査はトークン発行までです。実際の tools/call は Resource Server 側のログです。両方を残さないと委譲連鎖が途切れます。

移行準備の手順です。

1. API キーと無期限 refresh token の在庫を台帳化します。
2. 対話型は CIMD と短命アクセストークンへ寄せます。refresh token の発行を前提にしません。
3. 常駐型のうち事前登録できるものは、OAuth Client Credentials 拡張（署名 JWT アサーション推奨）へ寄せます。基盤の workload ID を使いたいものは、プラットフォーム JWT の issuer を AS の allowlist 候補として棚卸ししたうえで、SEP-1933 が Final になるまで jwt-bearer を本番 MCP AS へ投げません。
4. サブエージェントには親トークンのコピーを禁止します。
5. アクセストークンの形式（JWT か opaque か）は AS 実装依存として扱います。

認可経路の分離

1 本の OAuth クライアント設定で 3 経路を兼ねないでください。EMA は従業員 SSO の対話型エンタープライズ経路であり、ユーザー不在の常駐型の代替ではありません。human-presence attestation は議論項目にとどまるため、現行では「このトークンが対話セッション由来か」をプロトコルが保証しません。

ベストプラクティス

接続可否ではなく主体識別・委譲連鎖・非同期状態で統制する

セッションは廃止済みです。認可はリクエストごと、タスク状態は Task Store、業務状態は明示ハンドルで持ちます。

プロトコル固有と実装選択を分ける

「MCP は JWT を使う」は誤りです。Bearer の中身は AS 依存です。

認可が任意なサーバーと必須なサーバーの混在に備える

クライアントは 401 と WWW-Authenticate の resource_metadata を見てからフローを始めます。無認可サーバーに Bearer を付けません。Resource Server は自分宛てのトークンだけ受理します。cacheScope: "public" は認可の代替ではありません。

stdio ローカルサーバーに HTTP 認可仕様を適用しない

stdio にはヘッダ層がありません。資格情報は環境から取ります。キャンセルは notifications/cancelled です。ローカル HTTP（127.0.0.1 の Streamable HTTP）と stdio を混同しないでください。

Tasks のキャンセルは協調的として扱う

tasks/cancel は意図の通知です。クライアントは ack を停止完了とみなしません。HTTP の SSE 切断によるリクエストキャンセルと、Tasks の協調的キャンセルを同一ハンドラにまとめないでください。

ロードマップ項目を現行 GA として扱わない

次を「仕様になった」としてゲートや SDK 制約に落とさないでください。

• HTTP over stdio / HTTP/2 over stdio
• ETag による tool call の版管理
• DPoP の MCP 必須化
• SEP-1933 WIF
• RFC 8693 の MCP 委譲プロファイル
• webhooks / channels
• tools/call の結果形の一本化
• progressive discovery
• Agent Identity WG の成果（WG 自体が forming）

WIMSE は workload の実行時 ID、伝播、マルチホップ委譲を扱う IETF WG です。MCP が WIMSE トークンをそのまま受け取る仕様ではありません。SEP-1933 のメンテナコメントは、WIT を RFC 7523 の JWT として使わないことを明示しています。

よくある誤解と反証

長時間実行はどれか 1 つのプリミティブで足りる

• 誤解: Tasks が出たので listen も同期 SSE も不要です。
• 反証: ロードマップは、3 つの答えがライフサイクルを共有しないリスクを明示しています。Tasks は拡張、listen はコア、webhooks は未出荷です。
• 推奨: 長時間の結果は Tasks、カタログ変更は listen、数秒の進捗はリクエスト SSE と使い分けます。

リモートが HTTP になったのでローカルも同じ認可である

• 誤解: stdio にも Bearer が要ります。
• 反証: Authorization は HTTP で SHOULD、stdio で SHOULD NOT です。
• 推奨: リモート HTTP にだけ認可仕様を適用します。

ヘッダがあればゲートウェイは本文を信じなくてよい

• 誤解: Mcp-Method で振り分ければサーバー側の method チェックは不要です。
• 反証: 仕様は本文を処理するサーバーにクロスバリデーションを MUST で課します。
• 推奨: LB はヘッダでルーティングし、オリジンは必ず照合します。

EMA でエージェント ID は解決済みである

• 誤解: エンタープライズなら ID-JAG でワークロードもサブエージェントもカバーできます。
• 反証: EMA は従業員 SSO と IdP ポリシーです。ロードマップのエージェント ID は WIF + ID-JAG + token exchange + DPoP の組み合わせです。
• 推奨: 対話型エンタープライズは EMA、常駐型は WIF 待ち、委譲は RFC 8693 の act を監査項目に予約します。

jwt-bearer はどの AS でも通る

• 誤解: RFC 7523 は古い標準なので、既存 MCP AS は受け付けます。
• 反証: SEP-1933 は Open PR です。EMA の jwt-bearer は ID-JAG 用です。Kubernetes の ServiceAccount JWT をそのまま投げても typ / aud が合いません。
• 推奨: AS がグラントと issuer allowlist を広告するまで使いません。

DPoP を入れれば refresh token は無期限でよい

• 誤解: sender-constraining があるので長期の refresh token は安全です。
• 反証: ロードマップは、貼り付け API キーと長寿命 refresh token を問題として挙げています。DPoP は XSS 文脈での鍵使用までは防げません（RFC 9449）。
• 推奨: refresh token は短寿命かつローテーションにします。常駐型はプラットフォーム JWT の再提示へ寄せます。

content と structuredContent の両方を出せば互換である

• 誤解: 両方返せば、どのクライアントも正しくモデルへ渡します。
• 反証: ロードマップは「どの形をモデルの前に出すかがクライアントで分かれる」と明記しています。
• 推奨: structured content を返すツールは、互換のため TextContent にも JSON を載せる SHOULD です。structured が無い場合まで両方必須ではありません。単一契約を GA として書かないでください。

Tasks の cancel は即停止である

• 誤解: tasks/cancel の成功応答でワーカーは止まります。
• 反証: 公式は協調的であるとしており、cancelled 以外の終端状態もあり得ます。
• 推奨: 課金や副作用のあるジョブは、ワーカー側で cancel フラグを見ます。

トークン形式は MCP が JWT に決めた

• 誤解: audience 検証があるのでアクセストークンは JWT です。
• 反証: audience 検証は RFC 8707 の意図先チェックです。形式は AS の実装です。
• 推奨: クライアントはトークン応答の token_type（RFC 6749 §5.1）に従って提示方式を選びます。Resource Server は Authorization scheme と、AS との間で設定した署名鍵（jwks_uri）または introspection 経路に基づいて検証します。token_type は AS メタデータ（RFC 8414）の項目ではありません。

トラブルシューティング

典型的な失敗は 3 つに集約されます。ヘッドレス実行に対話型フローを載せると 401 のあとブラウザ同意で止まります。長時間処理を同期 tools/call に載せるとプロキシが 504 を返します。stdio に Bearer 検証を適用するとローカルサーバーが落ちます。

コアの隣接エラーコードです。

まとめ

• 新ロードマップは、MCP の呼び出し元が「ブラウザの前にいる人」から「クラウドワークロードとサブエージェント」へ広がった事実に、仕様を追いつかせる計画です。
• 今日使えるのは、認可コード + PKCE、CIMD 優先、EMA の ID-JAG、OAuth Client Credentials 拡張（Draft）、Streamable HTTP、server/discover、TTL キャッシュ、Tasks 拡張です。
• 待つべきなのは、WIF（SEP-1933 は Open PR）、DPoP の MCP 必須化、RFC 8693 の MCP 委譲プロファイル、webhooks / channels、HTTP over stdio、ETag、結果形の一本化です。
• 移行準備としてすぐ着手できるのは、API キーと無期限 refresh token の棚卸し、対話型と常駐型でのクライアント分離、委譲の監査項目（act、親の sub）の予約、taskId の永続化です。
• ロードマップは current thinking です。ゲートや SDK 制約へ落とす前に、対応する SEP が Final か、WG が forming を抜けたかを必ず確認してください。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

参考リンク

ロードマップ本体です。

• The New MCP Roadmap（blog, 2026-08-22）
• Official roadmap
• The 2026 MCP Roadmap（旧, 2026-03-09）

仕様 2026-07-28 です。

• Authorization
• Streamable HTTP
• stdio
• subscriptions/listen
• Tools
• 2026-07-28 changelog

拡張と SEP です。

• Tasks overview
• SEP-2663: Tasks Extension
• ext-tasks
• ext-tasks schema 2026-07-28
• Enterprise-Managed Authorization
• OAuth Client Credentials
• ext-auth（拡張の成熟度一覧）
• EMA stable specification MDX
• SEP-990
• SEP-1933 PR
• SEP-2549 TTL for list results
• SEP-2575 Stateless MCP
• SEP-2567 Sessionless MCP
• SEP-2322 MRTR
• SEP-2133 Extensions
• Triggers and Events WG

IETF の一次資料です。

• RFC 9449 DPoP
• RFC 8693 Token Exchange
• RFC 7523 JWT Bearer
• RFC 9728 Protected Resource Metadata
• RFC 8707 Resource Indicators
• RFC 9207 Authorization Server Issuer Identification
• RFC 8414 Authorization Server Metadata
• Identity Assertion Authorization Grant draft
• WIMSE WG

SDK と実装の隙間です。

• TypeScript SDK（v2）
• typescript-sdk#2569: subscriptions/listen が extension notifications を運べない