2026年7月28日、AIエージェントの共通接続規格である MCP（Model Context Protocol）の確定仕様 2026-07-28 が公開されました。発足以来最大の改訂です。見出しを飾ったのは「ステートレス化」——セッションを廃止し、素のロードバランサーで水平スケールできるようにする変更でした。これについては前稿「MCPが『ステートレス』になる」で詳しく扱っています。
homula はエンタープライズ向けの AIエージェント・インテグレーターとして、日本企業の MCP 活用を「PoCから本番・全社へ」日々支援しています。その現場から見ると、今回の確定仕様で実務を最も変えるのはステートレス化ではありません。同時に導入された拡張フレームワークと、その上で正式化された Tasks（非同期の長時間実行） と MCP Apps（サーバー製のUI） です。これらは、MCPを「同期的なツール呼び出しの規格」から「作業とアプリを載せる実行プラットフォーム」へと押し上げます。本稿はその意味を、企業の統制設計の視点で読み解きます。
拡張フレームワーク——MCPが「一枚岩の仕様」をやめた
まず土台となる設計思想の変化です。従来のMCPは、機能を追加するたびに本体仕様を改訂する必要がありました。新仕様は拡張フレームワーク（SEP-2133）を正式化し、この前提を捨てます。
- 各拡張は
io.modelcontextprotocol/tasksのような逆引きDNS形式のIDで識別される。 - クライアントとサーバーのケイパビリティ内の「拡張マップ」で相互ネゴシエーションされ、双方が対応していなければ有効化されない。
- 拡張は
ext-*の独立したリポジトリで、委任されたメンテナが管理し、本体仕様とは別のペースでバージョン更新される。 - SEPプロセスに新設された「Extensions Track」により、拡張はexperimental（実験的）→ official（正式）へ昇格する経路を持つ（MCP公式ブログ・確定仕様解説）。
意味するところはシンプルです。MCPは「巨大なリリースで一括更新」ではなく、「必要な機能をオプトインで少しずつ足せる」プロトコルになりました。企業にとっては、採用する機能を選び、対応SDKの成熟を見ながら段階的に取り込めるということです。そして、その拡張フレームワークが最初に載せた2つの目玉が Tasks と MCP Apps です。
Tasks——エージェントに「非同期の長時間仕事」を与える
Tasks 拡張（SEP-2663、ID: io.modelcontextprotocol/tasks）は、長時間実行をブロッキングしない非同期モデルに置き換えます。仕組みはこうです。
- クライアントが
io.modelcontextprotocol/tasksへの対応をリクエスト単位のケイパビリティで宣言する。 - サーバーは結果を待たず、
resultType: "task"のCreateTaskResultを返す。これには一意のtaskId（耐久性のあるタスクハンドル）、初期ステータス、ポーリング間隔、TTL が含まれる。タスクはレスポンス送出前に永続化されて生成されるため、接続が切れても失われない。 - クライアントは
tasks/get（全状態を取得。冪等でキャッシュ可能）で進捗をポーリングし、サーバーが入力を求めればtasks/updateで応答を返す。
ステータスは working / input_required / completed / failed / cancelled の5種で、後ろの3つが終端です。タスクストアが接続やワーカーとは独立に状態を保持するため、モバイルや不安定なネットワークでも、taskId さえあれば切断後に再取得できます。想定される用途は明快です。
| 用途 | Tasks が効く理由 |
|---|---|
| CI/CD・ビルド | 数分〜数時間の実行を待たずにハンドルで追跡 |
| 人間の承認ゲート | input_required で人の応答までブロックせず保留 |
| 外部ジョブ連携 | クラウドデプロイなど非同期APIをそのまま橋渡し |
| 不安定な接続 | 切断されても taskId で状態を再取得 |
エージェントが「押して、離れて、あとで結果を取りに行く」——つまり長時間の実務タスクを任せられるようになった、というのが本質です。
MCP Apps——サーバーが「画面」を配る、ただし同じ同意・監査経路で
もう一つの目玉が MCP Apps（SEP-1865）です。これはサーバーが対話的なHTMLインターフェースを配布し、ホスト（クライアント）がサンドボックス化されたiframeの中で描画する仕組みです。
重要なのは安全側の設計です。ツールはUIテンプレートを事前に宣言するため、ホストは実行前にプリフェッチ・キャッシュ・セキュリティレビューを行えます。そして描画されたUIは、MCPの他のすべてで使われるのと同じJSON-RPCの基盤プロトコルでホストと通信します。結果として、
UI起点のすべての操作が、直接のツール呼び出しとまったく同じ監査・同意（consent）の経路を通る
という性質が保証されます（MCP公式ブログ・RC解説）。「エージェントが画面を出す」と聞くと統制が緩みそうに感じますが、設計はむしろ逆で、UI経由でも承認・監査を回避する抜け道を作らないことを最優先にしています。これは企業導入において決定的に重要な設計判断です。
認証・非推奨——「本番運用の前提」も同時に固めた
Tasks と MCP Apps に隠れがちですが、確定仕様は運用の足回りも締めています。認証面では、動的クライアント登録（DCR）が非推奨となり、Client ID Metadata Documents（CIMD）へ移行（後方互換は当面維持）。加えて認可サーバーの取り違え攻撃を塞ぐ iss 検証（RFC 9207、SEP-2468）や、クレデンシャルを発行元イシュアに束ねる変更（SEP-2352）が入りました。通知は個別の HTTP GET から、種別ごとにオプトインする subscriptions/listen ストリームへ集約されます。
非推奨管理も明文化されました。Roots・Sampling・Logging が非推奨化（SEP-2577）、旧来の HTTP+SSE トランスポートも非推奨に。そのうえで**「最低12か月」の廃止猶予ポリシー**が定められ、企業は場当たり的でなく計画的に移行できます。対応SDKは TypeScript・Python・Go・C# の Tier 1 が確定仕様に対応済み、Rust はベータで追随します。
統制の論点はどう変わるか——homulaの観点
Tasks と MCP Apps は、統制側の「見るべき対象」を増やします。従来は「どのツールを、誰が、どの権限で呼んだか」を押さえれば足りました。これからは、それに加えて——
- 走り続けるタスクの可視化（誰が起点で、いま何が
workingで、どれが承認待ちinput_requiredか、いつ終わるか）。 - UI起点の操作の証跡（画面のボタン一つが、直接のツール呼び出しと同格の監査対象になる）。
——を横断的に記録・制御する必要があります。ここが homula の勝ち筋です。Agens は、MCPを活用したエンタープライズ向け統合プラットフォームとして、200以上のツールと構築ゼロで接続します。新しい拡張が乗っても、接続の共通化はプラットフォーム側で吸収できます。
そして、増えた統制対象を引き受けるのが Agens Control です。承認フロー・DLP・5年分の監査ログ・RBAC を備え、非同期のタスクが長時間走っても、UI経由の操作が挟まっても、「誰が・何を・どの権限で」を一貫して記録・制御します。MCP Apps が仕様レベルで「UI操作も同じ同意・監査経路を通す」と決めたことは、まさに Agens Control のような統制レイヤーと綺麗にかみ合います。仕様が敷いたレールの上に、企業固有のポリシーを載せる——これが実務の順序です。
導入の道筋は無理のない三段です。(1) 1業務で PoC（最短5日）→ (2) 価値が出る接続を Agens で共通化し、承認・監査の境界を Agens Control で設計 → (3) Tasks / MCP Apps 対応SDKをテスト環境で検証しつつ横展開。AIエージェント・ブートキャンプでは、業務棚卸しとあわせて「どの接続を、どの統制境界で、どこまで非同期・UI化して本番化するか」を3〜5日で設計します。
まとめ
2026-07-28 確定仕様の本当のニュースは、ステートレス化そのものよりも、拡張フレームワークがMCPを「作業とアプリの実行基盤」に変えたことです。Tasks は同期的なツール呼び出しを超えて「長時間の仕事を任せる」道を開き、MCP Apps は「サーバーが画面を配る」新しい体験を、同意・監査を犠牲にせずに実現します。
日本企業にとっての含意は、「新機能を急いで追う／追わない」の二択ではありません。接続の共通化・非同期タスクの可視化・UI操作の監査を、同じ統制設計図の上で一緒に描くことです。拡張はオプトインで少しずつ足せる——だからこそ、自社のどの業務から、どの拡張を、どの承認・監査境界で本番化するかを、今から言語化しておくことが本番・全社展開への近道になります。
MCPの進化は、接続の速さと同じくらい「非同期でもUI経由でも、統制して任せられるか」で差がつきます。自社のどの業務から、どの接続と作業を、どんな承認・監査の境界で本番化するか——その最初の線引きを早めに整理しておきましょう。