MCPアプリとタスク：新しいファーストクラスのMCP拡張機能を管理する

同じ MCP 2026-07-28リリース プロトコルをステートレスにしたことで、2つの拡張機能がファーストクラスに昇格しました。MCPアプリは、ツールがサンドボックス化されたiframeでレンダリングされたインタラクティブなUIを返すことを可能にし、タスクは、クライアントがtasks/get、tasks/update、tasks/cancelで駆動する永続的なステートマシンとして長時間実行される作業をモデル化します。これらは非常に有用であり、全く新しいガバナンスとセキュリティの側面です。この記事では、それぞれの仕組み、新たなリスクがどこにあるのか、そしてゲートウェイがそれらを統制する場所である理由を説明します。

プロダクトエンジニアのハナは、 「四半期レポート生成」MCPツールをリリースし、2つの新しい拡張機能を使って使いやすくしました。彼女はMCPアプリ（ユーザーがサンドボックス化されたパネルで調整できるインタラクティブなプレビュー）を返しました。また、生成に数分かかるため、呼び出しがブロックされないようにタスクとしてモデル化しました。デモは素晴らしかったです。問題は翌週に現れました。アプリのレンダリングされたプレビューには、信頼できないレコードから直接取得されたベンダー名が含まれており、同僚は、そのインターフェースにレンダリングされる内容（モデルが読み戻すのと同じコンテンツ）を何もスクリーニングしていないことを指摘しました。そして、あるレポートタスクは18分間実行され、トークンを静かに消費し続け、最終的に結果が返されるまで進捗もコストも表示されませんでした。

どちらもハナのコードのバグではありませんでした。それらは、ツール呼び出しにはガバナンスがあったものの、レンダリングされたUIや長時間実行されるタスクにはガバナンスがなかったシステムにおいて、仕様が許可する通りの動作をする新しいインターフェースでした。2026-07-28リリースは、トランスポートを簡素化しただけでなく、価値とリスクが存在する2つの新たな場所を追加しました。この記事では、ハナが経験したような問題を引き継ぐことなく、これらを活用する方法を説明します。

1. MCPアプリとタスクとは何か、なぜ今ファーストクラスなのか

このリリースでは、拡張機能が本格的なフレームワークとして再編成されました。各拡張機能は、逆引きDNS識別子、独自のリポジトリとメンテナー、そしてコア仕様とは独立して動くバージョンを持ちます。クライアントとサーバーは、その機能内の拡張マップを通じてサポートをネゴシエートします。サーバーはMCPアプリまたは特定のバージョンのタスクに対応していることを広告し、クライアントも同様に広告します。両者が合意すればそれを使用し、合意しない場合でも接続は機能します。MCPアプリとタスクは、最初の2つのファーストクラスの例です。

重要なことに、どちらもツールのプリミティブを置き換えるものではありません。ツールは依然としてJSON引数を受け取り、JSON結果を返します。アプリはツールの最上位にオプションのレンダリングされたインターフェースを追加し、タスクはツール呼び出しの 結果 が、作業が長時間実行される場合に配信される方法を変更します。だからこそ、これらは拡張機能として理解するのが最適であり、ツールにすでに適用しているガバナンスを、置き換えるのではなく、これらもカバーするように拡張する必要がある理由です。

2. MCPアプリ：新しいインターフェースとしてのサーバーレンダリングUI

MCPアプリは、ツールがホストによってサンドボックス化されたiframeでレンダリングされるインタラクティブなUIリソースを返すことを可能にします。仕様の議論からの類推が適切です。ホストされたダッシュボードがAPIを拡張するように、ツールを拡張します。ツールのJSON契約は変更されません。アプリは、ホストがユーザーに表示できるインタラクティブなシェルです。ハナのレポートツールの場合、アプリはプレビューパネルです。

この機能はネゴシエートされるものであり、前提とされるものではありません。サーバーはその機能内でアプリの拡張を宣言し、アプリをサポートしないホストは、単にJSON結果を受け取り、追加の何もレンダリングしません。このような段階的な機能低下は良い設計ですが、それはアプリのインターフェースがオプションであり、それが何をもたらすかを深く考えずに簡単にリリースできることを意味します。これが次のセクションの主題です。

3. アプリのセキュリティインターフェース：ユーザーとモデルの両方がそれを読み取る

アプリにおける新たなリスクは、そのレンダリングされたコンテンツに2つのオーディエンスがいることです。ユーザーがそれを見るため、パネルにレンダリングされる信頼できないものはすべてクライアント側のコンテンツに関する懸念事項となります。サンドボックス化されたiframeは爆発半径を制限します。これがホストがそれをサンドボックス化してレンダリングする理由ですが、「サンドボックス化」はマークアップがホストに対してできることを制限するものであり、 コンテンツ と言えます。ホストの動作によっては、アプリのコンテンツ、バックエンドデータ、またはUIから開始されるアクションがモデルのコンテキストにフィードバックされる可能性があり、そのため、アプリにレンダリングされる信頼できないテキストは、当社の記事で取り上げた間接的なプロンプトインジェクションの別の経路となります。 プロンプトインジェクションに関する記事：最終的にモデルに提示されるフィールドに密かに挿入された指示。

現実的な対応としては、アプリのコンテンツを信頼できない出力として扱い、他のモデル関連コンテンツと同様のスクリーニングが必要であると考えることです。レンダリングされるものをスキャンしてサニタイズし、エスケープせずに生の信頼できないデータを表面に挿入することは決してせず、アプリのサンドボックスを厳格に保つことです。Hanaのベンダー名フィールドは典型的な誤りです。ユーザーとモデルの両方が消費するレンダリングされた表面に、何のガードレールもなく信頼できないデータが挿入されていました。

4. タスク：現在のステートレスプロトコルにおける長時間実行される処理

タスクは2025年11月25日のコアでは実験的な機能でしたが、2026年7月28日のリリースでは、ステートレスな世界向けに設計されたライフサイクルを持つ公式拡張機能として導入されます。このモデルはリクエスター駆動型です。サーバーはtools/callに対して、即座の結果ではなくタスクハンドルで応答でき、クライアントはtasks/get、tasks/update、tasks/cancelを使用して処理を進めます。（以前の2025年11月25日の実験的なインターフェースにはtasks/listとtasks/resultも含まれていましたが、RCではget/update/cancelを中心にライフサイクルを再構築し、プロトコルがステートレスになると安全にスコープできないtasks/listを削除しています。正確なメソッドセットはRC固有のものとして扱い、最終仕様に対して結果の配信を確認してください。）タスクとは、実質的に小さな永続的なステートマシンと、その結果へのポインターです。

サポートはきめ細かくネゴシエートされます。ピアは単に「タスクをサポートします」と言うのではなく、どのリクエストがタスクで拡張可能かを伝えます。機能マップにはそれが明示されています。

2026年7月28日のRCにおけるタスクのネゴシエーション — 例示的なもの。最終仕様に対して正確な拡張IDとスキーマを確認してください。

{
  "capabilities": {
    "extensions": {
      "io.modelcontextprotocol.tasks": {   // reverse-DNS extension identifier
        "requests": {
          "tools": { "call": {} }          // only tools/call may be task-augmented here
        }
      }
    }
  }
}

上記の形式はRCの拡張フレームワークの例示であり、逐語的なスキーマではありません。以前のcapabilities.tasks形式（tasks/listを含む）は2025年11月25日のものに属していました。 実験的な タスクAPIです。RCでは、リバースDNSで識別される拡張マップの下にネゴシエーションを移動します。実装する前に、7月28日の仕様に対して最終的な識別子とフィールドを確認してください。

リクエストの下にリストされていないものはすべて同期的に処理されます。クライアントは、サーバーが通知していないリクエストをタスクで拡張しようとしてはなりません。これは、サイドチャネルを考案することなく並行処理を行うための、クリーンでMCPネイティブな方法です。そして、タスクハンドルはクライアントが引き渡す明示的なサーバー発行の識別子であるため、ステートレスコアと連携します。これはまさにステートレスモデルが推奨する明示的な状態パターンです。

5. タスクの監視：ライフサイクル、進捗、コスト

Hanaの18分間の盲点は、タスクの運用上の核心です。完了するまで何も返さない長時間実行タスクはブラックボックスです。進捗状況を表示できず、累積コストも確認できず、停止したタスクと遅いタスクを区別することもできません。ライフサイクルはフックを提供します。クライアントは状態をポーリングし、進捗状況や中間更新を表示できますが、誰かがこれらの遷移を記録し、タスクが実行中に消費するトークンを合計し、それを公開する必要があります。

各ステップでの可視性を伴ってタスクを完了に導く（クライアントループの例）

resp = call_tool("generate_report", args, task_augmented=True)
task_id = resp.task_id                       # server-minted handle

while True:
    state = tasks_get(task_id)                # poll; gateway records each transition
    emit_progress(task_id, state.status, state.progress, state.tokens_so_far)
    if state.status == "input_required":
        tasks_update(task_id, provide_input())
    elif state.status in ("completed", "failed", "cancelled"):
        break
    sleep(backoff())                          # respect the server's polling guidance

result = state.result if state.status == "completed" else None  # final result shape is RC-specific

これは、シリーズの他の部分と同様の可観測性の話であり、新しいオブジェクトに適用されたものです。 トレース 通常のリクエストを捕捉するものは、タスクをそのライフサイクル全体にわたって開いたままになるスパンとして扱い、トークンとコストの会計処理がそれに帰属するようにすべきです。 TrueFoundryのMCPゲートウェイ すでにすべてのMCPサーバーコールをトレースし、ユーザー、ツール、チームごとに使用状況を割り当てています。タスクとは、単一の瞬間に捕捉されるのではなく、時間とともに拡張された同じテレメトリーであり、それこそがHanaのレポートツールに欠けていたものです。

6. ガバナンス：誰が、どのような予算でアプリとタスクを起動できるか

プロトコルはアプリとタスクの動作を決定しますが、誰が、どのような制限の下でそれらを使用できるかは、意図的にあなたに委ねられています。これは具体的な疑問を伴うガバナンスのギャップです。そもそも、どのエージェントまたはユーザーが長時間実行されるタスクを起動することを許可されていますか？タスクが強制キャンセルされるまでのタイムアウトとトークン予算はどのくらいですか？つまり、18分間の実行は偶発的なものではなく、ポリシー上の決定なのですか？どのツールがアプリを返し、どのようなコンテンツがアプリ内にレンダリングされることが許可されていますか？

新しいインターフェース向けのゲートウェイポリシーの例（スキーマはゲートウェイ固有）

tasks:
  allow_launch:
    roles: ["agent:report-writer", "team:finance"]   # default-deny otherwise
  limits:
    max_runtime_seconds: 300                           # force-cancel past this
    max_tokens: 200000                                 # budget ceiling per task
  observability: trace_lifecycle                       # record every state transition

apps:
  output_guardrails: [pii, injection, toxicity]        # scan rendered content
  sandbox: strict                                      # host renders in a locked-down iframe

これらは何も特殊なものではありません。モデル呼び出しやツール呼び出しにすでに適用されているロールベースのアクセス、予算、ガードレール機構と同じものが、2つの新しいオブジェクトに拡張されただけです。これを集中管理する理由は、アプリとタスクが多くのサーバー上の多くのエージェントによって使用されるためであり、サーバーごと、アプリごとの再実装では、18分間のタスクや未審査のパネルがすり抜けてしまうからです。単一のポリシーポイントにより、「誰が、どのくらいの期間タスクを起動でき、アプリに何をレンダリングできるか」という問いに対する答えが、複数ではなく一つになります。

ゲートウェイはすでに、文書化された一連のフックでコンテンツをスクリーニングしているため、ガードレールによってこれが具体化されます。TrueFoundryのゲートウェイは、モデルトラフィック上のllm_inputとllm_output、ツールトラフィック上のmcp_pre_toolとmcp_post_toolの4つを公開しており、任意の数のバリデーター（PII検出、シークレットスキャン、プロンプトインジェクションおよび有害性分類器、SQLサニタイザー、CedarまたはOPAを介したポリシーチェック）がそれぞれにアタッチされます。それらは同じリクエスト上で並行して展開されるため、入力レールはモデル呼び出しと同時に実行され、ブロックされた場合はトークンが課金される前にキャンセルできます。これを本番環境で安全に保つ運用上の規律は、段階的なロールアウトです。まず監査（違反をログに記録し、トラフィックを通過させる）、次に強制（失敗時にブロックし、プロバイダーエラー時にはフェイルオープンする）、そして厳格化という段階を踏むことで、ガードレールプロバイダーの停止が初日からシステム全体を停止させることはありません。

7. 移行：実験的なタスクから新しいライフサイクルへ

2025-11-25コアの実験的なタスクAPIを採用していた場合、拡張機能への移行は、名前の変更ではなく、実際の移行です。ライフサイクルとメソッドは、tasks/get、tasks/update、tasks/cancelを中心に再編成されており、機能ネゴシエーションは、より明示的かつ詳細になりました。朗報は、このリリースで採用された非推奨ポリシーにより、非推奨化と削除の間に最低12か月の重複期間が保証されることです。そのため、移行中に古いインターフェースが機能し続け、特定の日付で突然使えなくなることはありません。

リスクの低いパスは、ステートレス移行がすでに推奨しているものです。つまり、明示的なハンドルを生成し、それを要求するツールを作成し、タスク拡張機能を前提とするのではなく、ネゴシエートし、リリース候補を暫定的なものとして扱います。これは2026年5月21日にロックされ、7月28日に最終決定される予定ですが、検証期間中は仕様テキストが変更される可能性があります。重複期間中に実験版と拡張版の両方の形式に対応できるゲートウェイは、ステートレスなトランスポート移行全体であなたを保護するのと同じように、ここで非常に役立ちます。

8. これが属する場所：ガバナンスポイントとしてのゲートウェイ

アプリとタスクは、このシリーズが繰り返し到達するパターンを強化します。プロトコルはメカニズムを定義し、ゲートウェイはプロトコルが未定義のままにしているガバナンスを提供します。MCPゲートウェイはすでに、すべての登録済みMCPサーバーの前に、検出、認証、RBAC、およびリクエストレベルのトレースのポイントとして存在しており、それこそが、アプリのコンテンツをスクリーニングし、タスクのライフサイクルを監視および制限できるインターフェースです。

具体的には、アプリでレンダリングされたコンテンツは、他のモデル関連の出力と同様に、同じ出力ガードレールを通過し、タスクは、そのトークンとコストが起動エージェントに帰属する長寿命のスパンとして、検出、RBAC、および可観測性を使用してトレースされます。 MCPゲートウェイ すでに提供しているものに、各サーバーに別のガバナンスシステムを後付けするのではなく、ゲートウェイが提供します。役割分担はよく知られたものです。サーバーはAppまたはTaskを実装し、ゲートウェイは誰がそれを使用できるか、何をレンダリングできるか、どのくらいの期間実行できるか、そしてそのコストを管理します。

9. よくある質問

MCP Appは単にHTMLを返すだけのものですか？

より正確には、Appは、ホストがサンドボックス化されたiframeでレンダリングするインタラクティブなUIリソースでツールを拡張するものです。ツールは引き続きJSONを受け取り、JSONを返し、Appはその上にオプションのシェルとして機能します。ガバナンスにとって重要なのは、レンダリングされたコンテンツが、多くの場合信頼できない入力から生成され、ホストの動作、ツールの出力、またはUIによって開始されるアクションを通じてモデルのコンテキストにフィードバックされる可能性がある点です。これにより、不活性なプレゼンテーションとして扱うのではなく、出力ガードレールを適用する範囲に入ります。

ステートレスプロトコルはTaskを不要にしますか？

いいえ、それぞれ異なる問題を解決します。ステートレスな転送は、リクエストが特定のインスタンスに固定されないことを意味します。Taskは、どのインスタンスが各ポーリングを処理するかに関わらず、単一のリクエスト・レスポンスよりも時間がかかる作業をモデル化します。実際、タスクハンドルは、ステートレスモデルが推奨する明示的な状態パターンそのものです。つまり、クライアントがスレッドバックするサーバー発行の識別子であり、どのインスタンスでもタスクについて報告できます。

考慮すべき最大の新たなリスクは何ですか？

2つあります。Appについては、表面にレンダリングされる信頼できないコンテンツです。これを無害なマークアップとしてではなく、インジェクションやPII（個人識別情報）についてスクリーニングされるべき出力として扱ってください。Taskについては、無制限に長時間実行される作業です。暴走したタスクがポリシーによって強制的にキャンセルされるようにタイムアウトとトークン予算を設定し、ブラックボックスにならないようにライフサイクルを追跡してください。どちらも仕様が提供する動作ではなく、仕様の周りに付加するガバナンスです。

今すぐ移行する必要がありますか？

今すぐ計画を立ててください。リリース候補は2026年5月21日にロックされ、7月28日に最終決定される予定です。実験的なTasks APIを使用していた場合、破壊的変更があります。12ヶ月間の非推奨期間の重複があるため、その日に何も壊れることはありませんが、新しい作業は拡張ライフサイクルをターゲットとし、機能を明示的に交渉する必要があります。承認されるまでは、RC（リリース候補）を暫定的なものとして扱ってください。

AppまたはTaskのガバナンス — ゲートウェイか、それともアプリケーションか？

ゲートウェイは、どのエージェントがAppやTaskを起動できるか、タイムアウトと予算の上限、レンダリングされたコンテンツに対する出力ガードレール、ライフサイクルの追跡といった横断的な制御を、すべてのMCPサーバーに一様に適用します。アプリケーションは、Appが何を表示し、Taskが何を行うかというドメインロジックを依然として所有します。なぜなら、それにはゲートウェイが持たない知識が必要だからです。

2026年7月28日のリリースはステートレス化で記憶されていますが、AppとTaskは構築するものを変える部分です。これらはレンダリングされる表面と長時間実行されるものをもたらし、仕様はメカニズムを提供しますが、ガバナンスは未解決のままです。そのギャップをゲートウェイで埋めてください。レンダリングされるものをスクリーニングし、実行されるものを制限し、両方を追跡することで、Hanaの優れたデモは優れた本番システムになります。

これらの表面をゲートウェイで管理する場合、それらを使用するエージェントが実行されるのも同じコントロールプレーンであることは役立ちます。TrueFoundryの AIゲートウェイ は、モデル、MCP、ツールトラフィックの統合されたエントリーポイントであり、その エージェントハーネス は、エージェントの計画-実行-観察ループ、サンドボックス化、承認、およびその上の追跡をオーケストレーションするランタイムです。これにより、エージェントがレンダリングするAppコンテンツや起動するTaskは、後付けのガバナンスレイヤーではなく、エージェントを実行するのと同じプレーンによってスクリーニングされ、制限され、追跡されます。

参照

• Model Context Protocol — 2026年7月28日リリース候補版 (拡張機能、MCPアプリ、タスク)
• MCP 2025-11-25 — 実験的タスクAPI (以前のインターフェース。2026年7月28日RC版では拡張機能として再構築)
• TrueFoundry — MCP Gateway (ディスカバリ、RBAC、可観測性)
• 当社の プロンプトインジェクション および LLM向けOpenTelemetry 記事 — 新しいインターフェースに適用される出力ガードレールとトレース。

NorthwindとHanaは例示です。MCPアプリとタスクの詳細は、2026年5月下旬時点のModel Context Protocol 2026年7月28日リリース候補版の公式資料および関連文書から引用されています。リリース候補版は5月21日に確定し、2026年7月28日に承認される予定です。仕様書の内容は変更される可能性があるため、プロトコルの詳細（メソッド名、機能の形式、ライフサイクル状態など）は暫定的なものとして扱い、最終仕様で確認してください。コードサンプルは、文書化されたパターンを例示するものであり、参照実装からコピーされたものではありません。TrueFoundryの機能は、公開されている製品ドキュメントから要約されており、今後変更される可能性があります。

‍