MCPのTasksは切断しても同じIDで再開。MCP Appsは会話内に操作画面を出す

MCP Apps は、MCPサーバーが会話の中に操作可能な画面を表示できるようにする拡張仕様で、長時間処理をタスクIDで扱う Tasks とあわせて、標準仕様の周辺に置かれた拡張として整理されています。

📖 この記事で分かること

• Tasks は長い処理をIDで扱うMCPの拡張仕様
• 切断や再起動をまたいで結果を取得できる理由
• MCP Apps はサーバーが会話内に画面を出す仕組み
• 画面は隔離された枠内で動き親ページに触れない

💡 知っておきたい用語

• ポーリング:「終わりましたか」と定期的に聞きに行く方式。宅配便の配送状況を自分で確認しに行くのに近い
• サンドボックス:プログラムを隔離された箱の中だけで動かし、箱の外に手を出させない仕組み

最終更新日: 2026年7月29日

▶ 公式ページ

• Tasks 拡張仕様(Model Context Protocol)
• MCP Apps 拡張仕様(Model Context Protocol)
• MCP Apps 公式ドキュメント(Model Context Protocol)

TasksとMCP Appsは何を足す拡張か

この記事のポイント

• MCP【エムシーピー】には、長時間処理を扱う Tasks と会話内UI【ユーアイ】を扱う MCP Apps という2つの拡張仕様があります(2026年7月時点)。
• Tasks はタスクIDという永続的な手がかりを返すため、通信断や再起動をまたいで結果を取得できます。
• MCP Apps の対応クライアントは Claude や VS Code GitHub Copilot など8種類が公式に明示されています(2026年7月時点)。

MCP はAIエージェントを外部のアプリやデータにつなぐための標準プロトコルです。中心となる仕様の周辺には「拡張(Extensions)」という枠組みがあり、Tasks と MCP Apps はそのうちの2つにあたります。

両者が埋めようとしている穴は別物です。Tasks は「処理が終わるまで待てない」という時間の問題を、MCP Apps は「テキストでは伝えきれない」という表現の問題を扱います。どちらも導入にはクライアントとサーバー双方の対応が必要で、標準仕様に含まれる機能とは扱いが異なります。

Tasksは結果の代わりに「受付番号」を返す

Tasks は、サーバーが結果の代わりにタスクIDを返し、クライアントが後からそのIDで状態を確認する仕組みです。

なぜ接続をつないだまま待たないのか。公式ドキュメントはこれを明確に否定しています。接続を長時間占有すると、クライアントや途中の通信機器が課すタイムアウトに引っかかり、数秒を超える処理では現実的でなくなるためです。

サーバーが返す応答には、タスクIDに加えて初期ステータス、有効期限、推奨されるポーリング間隔が含まれます。クライアントは tasks/get にIDを渡して状態を問い合わせ、完了していれば本来返るはずだった結果をそのまま受け取ります。

タスクIDは永続的な手がかりとして扱われます。そのため通信が切れてもクライアントが再起動しても、同じIDで問い合わせを再開できます。モバイル環境や不安定な回線を明確に想定した設計です。

処理の途中で確認が必要になった場合、状態は input_required に変わり、応答に確認要求が含まれます。クライアントは tasks/update で応答します。サーバー側から接続を張り直す必要がない点が特徴です。

状態は working(処理中)、input_required(入力待ち)、completed(完了)、failed(失敗)、cancelled(キャンセル)の5種類で、後ろの3つは終端状態です(2026年7月時点)。一度到達すると変化しません。

なお tasks/cancel によるキャンセルは「協調的」と説明されています。サーバーはキャンセルの意思を受け取りますが、処理を止める義務はないとされています。確認方法は既定ではポーリングですが、サーバーが notifications/tasks に対応していれば状態変化をプッシュで受け取ることもできます。

MCP Appsは隔離された枠内に画面を描く

MCP Apps は、ツールの応答としてHTML【エイチティーエムエル】の画面を返し、会話の中で描画させる拡張です。仕組みは大きく4段階に分かれます。

まず、ツールの説明文に _meta.ui.resourceUri という項目があり、ui:// で始まるUIリソースの場所を指します。ホストはツールが呼ばれる前にこれを先読みできます。

次にホストがそのリソースを取得します。中身はHTMLページで、JavaScriptやCSSを同梱するのが一般的です。外部のスクリプトを読み込む場合は _meta.ui.csp で許可するオリジンを指定し、マイクやカメラなど追加の権限が必要なら permissions で要求します。

描画はサンドボックス化された枠内で行われます。アプリは親ページのDOMに触れず、ホストのCookieやローカルストレージも読めず、親ページを別のURLへ遷移させることもできません。この隔離があるため、ホストはサーバー作者を全面的に信頼しなくても第三者のアプリを表示できる、というのが公式の説明です。

通信は postMessage という標準的なブラウザ機能の上でJSON-RPCをやり取りします。tools/call のように通常のMCPと共通のものもあれば、ui/initialize のように ui/ で始まるアプリ専用のものもあります。

特徴的なのが、ホストの機能への「委譲」です。アプリが自前でメールサービスなどとの連携を作り込む代わりに、「この予定を登録して」といった結果をホストに依頼し、ホストがユーザーの同意のもとで既に接続済みの機能を使って実行します。実装フレームワークは自由で、公式の App クラスは便利なラッパーであり必須ではありません。

どんな処理・画面が向くか

Tasks が向くのは、時間が読めない処理と、途中で人が挟まる処理です。公式はCIパイプライン、バッチデータ処理、モデル学習といった数分から数時間かかる処理に加えて、承認ゲートやレビュー工程のような人の確認が入る処理を適合例として挙げています。

すでにジョブIDを発行する外部APIをMCPサーバーで包んでいる場合も適合します。ジョブ作成時にタスクを返し、完了時に解決する、という素直な対応で済みます。大量データの一括取り込みのように部分的な進捗が意味を持つ処理も、状態メッセージで進み具合を伝えられます。

MCP Apps が向くのは、テキストの往復では効率が悪い場面です。地域別売上を地図上で掘り下げるようなデータ探索、選択肢が多く相互に依存する設定フォーム、PDFや3Dモデルの閲覧、稼働状況の常時監視、経費申請の承認のように一件ずつ処理していく多段階の作業が挙げられています。

逆に、こうした性質の恩恵がない用途なら通常のWebアプリのほうが簡単だ、と公式ドキュメント自身が明記しています。

編集部の見方

編集部は、いま自社のMCPサーバーで着手するなら、MCP Apps より Tasks を先に検討すべきだと考えます。

• 根拠1: 実装の追加量が小さい。すでにジョブID方式の外部APIを包んでいるサーバーなら、ジョブ作成時にタスクを返し完了時に解決するだけで乗ります。公式も外部ジョブシステムのラッパーを適合例として明記しています。
• 根拠2: 解決するのが運用上の実害です。公式は数秒を超える処理でのブロッキングを現実的でないと明言しており、タイムアウトで処理が落ちる問題に標準的な解を与えます。
• 根拠3: MCP Apps は画面そのものを設計・実装する必要があり、恩恵もダッシュボードや設定フォームのようにUIが価値になるサービスに偏ります。投資と回収の見積もりが要ります。

この見方が変わる条件は、Tasks の仕様の安定度です。Tasks の仕様リポジトリ名には現時点で experimental が付いており、破壊的な変更が入れば実装のやり直しが生じます。安定版の位置づけが明示されるか、逆に MCP Apps 側の対応クライアントがさらに広がれば、優先順位は入れ替わります。

よくある質問

Q: Tasks を使うと、ずっとポーリングし続ける必要がありますか?

A: 既定はポーリングです。ただしサーバーが notifications/tasks に対応していれば、状態変化をプッシュで受け取れます。

Q: タスクをキャンセルすれば必ず処理は止まりますか?

A: いいえ。仕様上キャンセルは協調的なもので、サーバーは意思を受け取りますが停止する義務はないとされています。

Q: MCP Apps では自由にHTMLを動かせますか?

A: サンドボックス化された枠内に限られます。親ページのDOM・Cookie・ローカルストレージへのアクセスはできず、親ページの遷移もできません。

まとめ

Tasks は長時間処理を接続の維持ではなく永続的なIDで扱う拡張で、切断や再起動をまたいで結果を取得できます。MCP Apps はサーバーが用意した画面をサンドボックス内で会話に埋め込む拡張で、ホストの他機能への委譲もできます。いずれもクライアントとサーバー双方の明示的な対応が前提となるため、導入前に利用中のクライアントの対応状況を確認する必要があります。

【用語解説】

• Tasks: 長時間かかる処理に対し、結果の代わりにタスクIDを返し、後から進捗確認・入力応答・結果取得を行うMCPの拡張機能
• MCP Apps: MCPサーバーが会話内に、隔離された操作可能なHTML画面を表示できるようにするMCPの拡張機能
• postMessage: 異なるページの間で安全にメッセージをやり取りするための、ブラウザ標準の仕組み

引用元:

• [1] Tasks 拡張仕様(Model Context Protocol 公式)
• [2] MCP Apps 拡張仕様(Model Context Protocol 公式)
• [3] MCP Apps 公式ドキュメント(Model Context Protocol 公式)

この記事について: AI 支援で執筆、編集部が事実確認・編集しています。誤りや追加情報があれば Contact よりお知らせください。