AIエージェントとツール／データをつなぐ事実上の標準、MCP（Model Context Protocol）の新仕様が 2026年7月28日に確定 しました（MCP公式ブログ）。本ブログでは以前、確定前の段階で「MCPが『ステートレス』になる」として、セッション廃止によるスケールと統制の論点を整理しました。今回はその続報にとどまりません。確定版が連れてきた 2つの公式拡張——MCP Apps（埋め込みUI）と Tasks（非同期の長時間処理） に焦点を当てます。
なぜこの2つかというと、これらは「MCPで何ができるか」の輪郭を大きく広げるからです。これまでツール呼び出しは基本的に「テキストを渡してテキストが返る」一往復でした。Apps はエージェントに 画面（インタラクティブなUI） を、Tasks はエージェントに 数分〜数時間かかる持続的な仕事 を与えます。homula はエンタープライズ向けの AIエージェント・インテグレーターとして、日本企業の MCP 活用を「PoCから本番・全社へ」日々支援しています。本稿は仕様の技術解説にとどまらず、エージェントがUIと長時間の仕事を持ったとき、企業の制御点がどこへ動くか を実務の観点で読み解きます。
まず、確定した2026-07-28のおさらい
新仕様の土台は前回書いたとおり ステートレス化 です。initialize／initialized のハンドシェイクと Mcp-Session-Id ヘッダーが廃止され、各リクエストが自己記述的になりました。結果として、リモートのMCPサーバーは 素のラウンドロビン負荷分散の背後で水平スケール できます（MCP公式ブログ）。サーバー起点の双方向ストリームは MRTR（Multi Round-Trip Requests） に置き換わり、サーバーは追加入力が要るとき resultType: 'input_required' を返して往復を続ける形になりました。
このステートレスな土台の上に、今回 公式の「拡張（extension）」 という仕組みが整いました。中核仕様を薄く保ちつつ、機能はバージョン付き拡張として足していく——その最初の主役が MCP Apps と Tasks です。あわせて仕様には 機能ライフサイクル方針（Active → Deprecated → Removed、廃止から削除まで最低12か月）が導入され、Roots・Sampling・Logging などは非推奨として少なくとも1仕様年は動作します（MCP公式ブログ）。企業にとっては「壊れる変更が、いつ・どれだけの猶予で来るか」が明文化された点も見逃せません。
MCP Apps——エージェントが『画面』を持つ
MCP Apps は、サーバーが返すインタラクティブなHTMLを、ホスト側がサンドボックス化されたiframe内で描画する 公式拡張です（MCP公式ブログ）。ダッシュボード、フォーム、可視化、承認画面などを、プレーンなテキスト応答の代わりに 会話の中に直接 表示できます。ツールは自分のUIを ui:// スキームのリソースとして参照し（_meta にUIリソースを宣言）、ホストはそれをレンダリングします。
エンタープライズにとって重要なのは、この拡張が セキュリティを設計に織り込んでいる ことです。
- テンプレートの事前宣言: ツールはUIテンプレートを 前もって宣言 します。ホストは実行前にそれを プリフェッチ・キャッシュし、セキュリティレビュー できます。「何が描画されるか」を、描画前に検証できる設計です。
- 厳格なサンドボックス: すべてのUIは制限付きの サンドボックスiframe で動き、親DOM・ホストのCookie・localStorage にアクセスできません。
- 監査可能な通信: UIとホストの通信は
postMessage上の JSON-RPC に限定されます。つまり UI起点のアクションも、直接のツール呼び出しと同じ監査・同意の経路 を通ります。ホストはUI発のツール呼び出しに 明示的な承認 を要求できます。
埋め込みUIは、便利さと同時に 新しい攻撃面 を持ち込みます。会話に描画されるHTMLは、見た目上「エージェントが出したもの」に見えますが、実体は 外部サーバー由来のコード です。仕様がサンドボックス・テンプレート事前レビュー・同意経路を標準化したのは、まさに「UIを通じたインジェクションや、なりすまし操作」を封じるため。企業側の含意は明確です——どのサーバーのAppsを、どのホストで、どの承認要件で許すか を、機能を配る前に決めておく必要があります。
なお、MCP Apps は OpenAI や MCP-UI コミュニティと共同で策定された 最初の公式拡張 で、確定と前後して複数の主要ホスト（Claude Desktop、VS Code の GitHub Copilot、Microsoft 365 Copilot など）が対応を表明したと報じられています（MCP Servers 分析）。UIが特定クライアント固有の作り込みではなく、ホスト横断の共通規格 になりつつあることが要点です。
Tasks——エージェントが『長時間の仕事』を持つ
もう一つの主役 Tasks は、実運用での実績を経て、実験的機能から公式拡張（io.modelcontextprotocol/tasks）に昇格 しました（MCP公式ブログ）。狙いは、数分〜数時間かかる非同期の仕事 を、ステートレスな世界で正しく扱うことです。
新しいライフサイクルはこう動きます。tools/call は結果そのものではなく タスクのハンドル を返し、クライアントが tasks/get（ポーリングで進捗取得）・tasks/update・tasks/cancel で 明示的に駆動 します。セッションに状態を貼り付けず、どのサーバーインスタンスに当たっても継続できるのがポイントです。
これはエージェントの仕事の質を変えます。「レポート生成」「大規模データの照合」「他システムのバッチ完了待ち」といった その場で返せない仕事 を、エージェントが正式なプロトコルの枠内で扱えるようになる。同時に、統制の観点では新しい問いが生まれます。
長時間タスクは、監査とライフサイクルの新しい対象 です。「誰が・いつ・どのタスクを起票し、どのパラメータで走り、いつ完了・キャンセルされたか」——一往復のツール呼び出しなら1行のログで済んだ事実が、開始から完了までの持続的な証跡 になります。無人で長く走る処理ほど、途中の権限昇格やパラメータ改変に気づきにくい。Tasks を本番に載せるなら、タスク単位の監査ログとキャンセル権限 を制御層の要件として先に置くべきです。
認可のハードニング——EntraやOktaに『素直に』つながる
3つ目の地味だが重い変更が 認可（Authorization）の実運用対応 です。2026-07-28 では、MCPサーバーを OAuth 2.1 のリソースサーバー として位置づけ、要件を大幅に締めました。仕様は認可レスポンスの iss（発行者）検証（RFC 9207）や、動的クライアント登録時の OIDC application_type 宣言などを求めます（MCP公式ブログ）。移行分析によれば、クライアントが正しい認可サーバーを自動発見できるよう OAuth 2.0 Protected Resource Metadata（RFC 9728） の実装も必須化されています（Stacktree 移行分析）。
実務的な意味はシンプルです。これまで各社の独自運用でつないでいたところを、Microsoft Entra ID や Okta といった企業の既存IDプロバイダに、余計な回避策なしで接続できる ようになります（WorkOS）。エージェントのアクセスが、社員のシングルサインオンや条件付きアクセス、失効ポリシーと 同じ土俵 に乗る——これはガバナンスの前提を大きく整えます。
| 変更点 | 何が変わるか | 企業への含意 |
|---|---|---|
| OAuth 2.1 リソースサーバー化 | サーバーが標準的な認可の作法に準拠 | 独自運用の廃止、監査の統一 |
| Protected Resource Metadata（RFC 9728） | 認可サーバーの自動発見 | 手動設定の削減、接続の再現性 |
iss 検証（RFC 9207） | 発行者のなりすまし防止 | トークン取り違えリスクの低減 |
| Entra / Okta への素直な接続 | 既存IDに統合 | SSO・条件付きアクセス・失効と一体運用 |
企業の制御点はどこへ動くか
Apps・Tasks・認可ハードニングを重ねると、制御点の移動が見えてきます。エージェントが「テキストを返す道具」から「画面を持ち、長く走り、企業IDでつながる実行主体」になった以上、統制も1点集中では足りません。
| 新しい能力 | 生まれる制御点 | 実務で置くべき要件 |
|---|---|---|
| MCP Apps（埋め込みUI） | UI起点アクションの 同意・レビュー | 許可するサーバー／ホスト、UI発ツール呼び出しの承認要件 |
| Tasks（非同期処理） | タスクの 監査・ライフサイクル | タスク単位ログ、キャンセル権限、長時間実行の可視化 |
| 認可ハードニング | ID・アクセス の一元化 | Entra/Okta連携、最小権限、トークン失効 |
| ステートレス core | どこでも当たる 接続の一貫性 | サーバー横断の統一ポリシー適用 |
ポイントは、これらが バラバラのツールで後付けされると破れる ことです。UIの同意はホスト任せ、タスクのログはサーバー任せ、認可はIDチーム任せ——と分散すれば、「誰が・何を・なぜ実行してよいか」を横断で説明できません。逆に言えば、確定した2026-07-28は、これらを一つの制御層に束ねる前提 を初めて標準の側で整えた、とも読めます。
homulaの観点——標準の追い風を、制御層の設計に変える
homula は、エージェント導入を「便利な機能を足す」話ではなく、制御層を先に組んでから機能を載せる 順序で設計します。2026-07-28 の3つの変化は、その制御層に落とし込むべき具体的な要件です。
- まず接続を一元的に把握する: Agens は MCP を活用し、200以上のツールと構築ゼロで接続 します。どのサーバーの Apps を許し、どのツールが Tasks を起票しうるかは、接続を一望できてはじめて設計できます。ステートレス化で「どこでも当たる」ようになったからこそ、入口の把握が効きます。
- 承認・DLP・監査を一枚岩で持つ: Agens Control は、承認フロー・DLP・5年分の監査ログ・RBAC を提供します。UI起点アクションの承認、長時間タスクの証跡、企業IDと連動した最小権限——今回生まれた制御点を、部門ごとにバラさず 組織横断の一つの層 で持てるのが要点です。
- 適所適ツールで実装する: n8n / Dify / LangGraph を組み合わせ、参照系は素通し、実行系（送信・更新・支払い・長時間バッチ）にだけ承認と監査を重ねる強弱設計を作り込みます。Tasks の非同期処理は、この「重要度に応じた作り分け」と特に相性が良い領域です。
- 移行の順序を決めてから動く: 主要SDK（TypeScript・Python・Go・C#）が確定日に新仕様へ追随したと報じられていますが（MCP Servers 分析）、壊れる変更（セッション廃止・認可の厳格化） を抱える以上、本番の移行は棚卸しが先です。AIエージェント・ブートキャンプ では、業務棚卸し・プロトタイプ構築・ROI試算を3〜5日 で完結し、「どのサーバーを、どの制御要件で、どの順に載せるか」を最初の要件として固めます。
なお、ホストの対応状況やSDKの成熟度は執筆時点のもので、今後動きます。特定製品をそのまま本番に当てはめる話ではなく、Apps・Tasks・認可ハードニングという方向性を、自社の制御層にどう織り込むか を先に決めておくことが肝要です。
まとめ——「道具」から「実行主体」へ、統制も一段上げる
2026年7月28日のMCP確定は、ステートレス化という土台の完成であると同時に、エージェントの能力が一段広がった節目 でした。MCP Apps は画面を、Tasks は長時間の仕事を、認可ハードニングは企業IDとの素直な接続を、それぞれ標準の側から与えます。エージェントは「テキストを返す道具」から、UIを持ち、持続的に走り、社員と同じIDでつながる実行主体 へと近づきました。
企業がいま準備すべきは、機能を追いかけることではなく、新しく生まれた制御点——UIの同意、タスクの監査、IDの一元化——を一つの制御層に束ねる設計 です。標準が前提を整えた今こそ、「どのサーバーの画面を許すか」「どの長時間タスクを証跡に残すか」「どのIDでアクセスを縛るか」を先に決める。そうすればエージェントの自律性は、怖いものではなく、安心して広げていけるものになります。
MCPの確定版を「便利な接続」で終わらせず、「統制された実行基盤」に変えませんか。homula は、Apps・Tasks・認可を見据えたエージェント制御層の設計を、業務棚卸しからROI試算まで一気通貫で支援します。