MCP Appsとは？サンドボックスiframeで動く対話型UI拡張の仕組みと採用判断

MCP Appsは、MCPサーバーが自前のHTML画面をチャット内のサンドボックス化されたiframeへ配信するための拡張仕様です。SEP-1865として2025年11月21日に起案され、2026年1月26日にMCP初の公式拡張としてStableへ到達しました。ツール定義に_meta.uiを添えてui://で始まるリソースを指すと、対応ホストがそのHTMLを事前に取得し、審査を済ませてから描画します。この記事では能力宣言から通信経路、sandbox属性とCSPによる防御、2026-07-28版のステートレス化との関係までを整理し、受託開発で採用する条件と見送る場面を切り分けます。

まとめ：MCP Apps採用の判断軸と実装で先に決める3点

MCP Appsを入れるかどうかは、対象ツールが一度の応答で完結するのか、繰り返し触られるのかで決まります。地図のピン操作、PDFへの注釈付け、条件を変えて再計算するダッシュボードのように同じデータへ何度も手を入れる用途なら効きます。単発の帳票出力を置き換えるだけなら、従来のテキスト応答で足りる。

実装前に決める項目は3つあります。1つ目はUIテンプレートの粒度で、ツール単位に切るか画面単位でまとめるかでui://のURI設計とキャッシュ効率が変わる。2つ目はCSPの申告範囲で、既定値のdefault-src 'none'が外部通信を全て塞ぐため、地図タイルや画像配信を使うなら事前申告が要ります。3つ目が非対応ホスト向けのテキスト応答で、省くとClaude以外で機能が消えます。

結論は、対応ホストがClaudeとChatGPT中心である現状を受け入れられ、かつ反復操作・状態保持・即時の可視化のうち2つ以上が要件に入るなら採用。監査要件が厳しくCSP緩和の申告が通らない案件や、ホストを自前実装している社内エージェント基盤では投資が回収できません。

MCP Appsの定義とSEP-1865が公式拡張になるまでの経緯

MCP Appsは本体プロトコルの一部ではなく、拡張トラック（SEP-1724）に乗った独立仕様です。

テキスト応答では届かない操作とMCP Appsが埋める表現領域

従来のMCPでは、ツールの実行結果はテキストか画像として会話に差し込まれるだけでした。ピンを動かす、表の列を並べ替える、フォームの依存項目を切り替えるといった操作は、そのつど自然言語で指示し直すしかありません。MCP Appsはこの往復を画面側へ移します。

公式ブログは「モデルは会話の輪に残り、ユーザーの操作を見て応答する。UIはテキストにできないもの、つまりライブ更新・状態の保持・直接操作を担う」と役割分担を説明しています。プロトコルの基礎はMCP（Model Context Protocol）の仕組みで解説したtools・resources・promptsの3要素のままで、resourcesの配信形態が1つ増えた構造です。

2025-11-21起案から2026-01-26のStable到達までの経緯

SEP-1865のメタデータでは、Createdが2025年11月21日、Statusは2026年1月26日付でStableです。策定にはAnthropicとOpenAIが共同で入り、MCP-UIコミュニティ、Block（Goose）、Microsoft（Visual Studio Code）、JetBrains、AWS、Google DeepMindが加わりました。競合するモデルベンダーが同じUI仕様に合意した点が、独自UI規格との差になります。

ここは二次情報の誤りが多い箇所で、2026-07-28版で昇格した、と書かれることがあります。実際の2026-07-28版が行ったのは拡張フレームワークそのものの正式化です。同版の告知は「TasksがMCP AppsやEnterprise Managed Authorization（EMA）といった他の拡張に加わる」と記しており、MCP Appsは半年前から先に立っていた側になります。

ui://リソースと_meta.uiによるUIテンプレート宣言の実装手順

実装の流れは、能力宣言、UIリソース登録、ツールとの紐付けの3段です。

io.modelcontextprotocol/ui拡張の能力宣言とMIMEタイプ

クライアントは拡張識別子io.modelcontextprotocol/uiへの対応を宣言し、受け付けるMIMEタイプとしてtext/html;profile=mcp-appを列挙します。サーバーはこの宣言の有無を見て、UI付きの応答を返すかテキストのみで返すかを分岐させる。実装漏れは「Claudeでは動くが他では無反応」という形で表面化するため、対応可否はハンドラの早い段階で確定させます。

ui://スキームで公開するHTMLテンプレートの登録と配信

UI本体は通常のMCPリソースとして登録しますが、URIはui://で始める決まりです。天気サーバーのダッシュボードならui://weather-server/dashboardのように、サーバー名と画面名で階層を作ります。この命名は慣習ではありません。ホストはツール一覧を読んだ時点でURIを知るため、ツールが実行される前にHTMLを取得してキャッシュし、内容を審査できる仕組みです。

_meta.uiのresourceUriとvisibilityで決まる公開範囲

ツール定義とUIの紐付けは、ツールの_meta配下にuiオブジェクトを置いて行います。フィールドは2つで、resourceUriが対象のUIリソースURI、visibilityが公開範囲の配列です。

visibilityには"model"と"app"を指定できます。前者はモデルからも呼べるツール、後者は画面からのみ呼べるツールを表す。ページ送りや並べ替えのようにモデルへ提案させる意味が薄い操作を["app"]へ絞ると、トークン消費と誤呼び出しの両方が減ります。

postMessage経由のJSON-RPCで動くホストとViewの通信経路

MCP AppsのViewはMCPサーバーと直接つながらず、すべてホストを経由します。この一点が仕様全体の性格を決めています。

View側から呼べるui/message等6種のリクエスト一覧

ViewからHostへ送れるリクエストは6種類で、通信はpostMessage上のJSON-RPC 2.0で行われます。

後半2つは既存のMCPメソッドそのままです。画面からのツール実行が独自APIではなくtools/callである点に、この仕様の設計思想が表れています。

size-changedとrequest-teardownの2通知の使い分け

応答を求めない通知は2系統です。ui/notifications/size-changedはコンテンツ高さが変わったときに寸法を伝えるもので、表を展開すると下が切れる事故はこの実装漏れが原因。もうひとつがSDK 1.3.0（2026年3月23日）で追加されたui/notifications/request-teardownで、app.requestTeardown()としてView側からパネルの終了を要求します。

UI操作がtools/callと同じ監査経路を通る設計の意味

画面上のボタン操作は、モデルが直接ツールを呼んだ場合と同じ経路を通ります。ホストは両者を区別せず検証し、同じ同意フローと監査ログに載せる。UIを足したせいで権限チェックの抜け道ができる事故が、構造的に起きにくい形です。

裏返すと、ツール単位で認可を切っていない実装にUIを載せると、画面から呼べる範囲を絞る手段がありません。MCPでAIエージェントに外部ツールを接続する際のtool定義と認可設計を先に整えてから、UI拡張へ進む順序を勧めます。

sandbox属性とCSPで組み立てるMCP Appsの3層セキュリティ

防御はiframeの隔離、CSPによる通信制限、ホスト側の検証責務の3層です。

allow-scripts指定のsandbox属性が遮断する範囲

Viewはsandbox="allow-scripts allow-same-origin"を付けたiframe内で実行されます。スクリプトは動きますが、親ページ、つまりClaudeやChatGPTの画面のDOMには手が届かない。Cookieの読み取りもlocalStorageの参照も塞がれます。

ログイン状態をストレージに保存する定番の作りが使えないため、セッション相当の情報はサーバー側で持つか、ツール呼び出しの引数で毎回渡す設計に寄せます。既存のWeb管理画面をそのまま移植しようとすると、ここで作り直しが発生する。

default-src ‘none’から始める既定CSPと緩和の申告

ホストは既定で厳しいContent Security Policyを適用します。仕様が示す既定値はdefault-src 'none'を起点に、スクリプトとスタイルを自己ホスト＋インラインのみ、画像を自己ホストとdata URIのみに許し、connect-srcとframe-srcとobject-srcを'none'で閉じる構成です。

外部への通信は原則できません。緩和が必要なら、サーバーが_meta.ui.cspで接続先ドメインを申告し、ホストが審査したうえで許可します。「とりあえず動かしてから絞る」進め方は通らないため、地図タイルや外部フォントを使う画面は申告を設計の初期に確定させる。

ホスト側に課される入力検証・監査・ドメイン許可リスト運用の責務

ホストの義務は5点です。受信したJSON-RPCメッセージの全件検証、ツール実行前のHTML審査、リソースアクセスの監査証跡の生成、ドメイン許可リストと拒否リストの実装、制限的なCSPを既定として申告分だけ緩めること。サーバー側の含意は明快で、防御はホストに任せられる一方、審査に落ちる書き方をすると画面が出ません。

2026-07-28版ステートレス化とTasks拡張との組み合わせ設計

2026-07-28版はMCP史上最大の改訂で、コアがステートレスになりました。

initializeの廃止で変わる能力宣言と_meta自己記述

同版ではinitializeとinitializedの交換とセッションの概念が撤廃され、各リクエストがプロトコル版・クライアント識別子・能力を_metaに自己記述する形へ変わりました。告知の言い方では「どのリクエストも、素のラウンドロビン負荷分散の背後にあるどのインスタンスへ着地してもよい」状態です。

UI拡張の能力宣言も、接続開始時に一度だけ交わす前提からリクエストごとに載る前提へ移りました。あわせて注意したいのがUIリソースの配信で、インスタンスごとにビルド成果物が違うと同じui://URIから別のHTMLが返る。SDK側の対応状況は言語ごとに差があるため、MCP TypeScript SDK v2のパッケージ分割とステートレス化で版の対応表を確認してから着手します。

io.modelcontextprotocol/tasks併用時の長時間処理UI

時間のかかる処理はio.modelcontextprotocol/tasks拡張と組み合わせます。Tasksはポーリング型のtasks/getと新設のtasks/updateを備え、通知はsubscriptions/listenのストリームに寄りました。

画面側はtools/callでタスクハンドルを受け取り、一定間隔でtasks/getを叩いて進捗を描き直す。数十秒を超えるバッチ処理をUI付きで見せるなら、この2拡張はセットで検討する対象になります。

対応ホストの実装差とテキストフォールバックを含む配布設計の制約

仕様が固まっていても、動く場所は限られます。

Claude・ChatGPT・Goose・VS Codeの対応状況の差

公開時点で表明されたホストの状況は次の通りです。

社内配布ならホストを1つに寄せられますが、外部公開のMCPサーバーでは非対応ホストからのアクセスが一定割合で残ります。

非対応ホスト向けテキストフォールバックに要る二重実装のコスト

非対応ホストへは従来通りのテキスト応答を返す段階的強化が推奨されますが、見落とされがちなのが二重実装の維持費です。UI側に列を1つ足したらテキスト側にも足す、という同期を怠ると環境ごとに情報が食い違う。実務ではツールの戻り値を構造化データに一本化し、UI用の描画とテキスト用の整形を同じデータから派生させます。

単一HTMLに束ねる制約と外部CDN参照が通らない仕組みの理由

UIリソースはHTMLテンプレートとして配信するため、実質的に単一ファイルへ束ねる形になります。外部CDNからReactやチャートライブラリを読む書き方は、既定CSPのscript-srcが自己ホストとインラインに限られる以上そのままでは通らず、バンドラでJSとCSSをインライン化する構成が標準。ファイルサイズが膨らむと事前取得が遅れて描画待ちに跳ね返るため、実装側で自主的な上限を決めます。

受託開発でMCP Appsを採用する条件と見送るべき3つの場面

技術的に可能かではなく、案件として引き受ける価値があるかで切ります。

採用が成立するのは反復操作・状態保持・即時可視化のうち2つ以上

採用が成立するのは次の3要件のうち2つ以上が当てはまる場合で、1つだけならテキスト応答の改善で足ります。

• 反復操作：同じデータに対してユーザーが3回以上の操作を繰り返す（絞り込み、並べ替え、注釈付け）
• 状態保持：会話をまたいで画面上の選択や編集途中の内容を保ちたい
• 即時可視化：数値やグラフの変化を、モデルの応答を待たずに描き直したい

いちばん効くのは反復操作です。1回の会話で同じツールを何度も呼ぶ設計なら、その往復がUIへ置き換わります。

見送るべき場面1：単発の参照系ツールと帳票出力だけの置き換え

社内文書の全文照合、在庫数の問い合わせ、月次帳票のPDF生成といった単発の参照・出力は、UIにしても操作が増えません。結果を1回読んで終わりで、iframeの描画待ちが増えるぶん体感は悪化する。UI化の価値が出るのは「この行だけ再計算」「この期間で絞る」といった二次操作が発生してからです。

見送るべき場面2：対応ホストが揃わない社内向けエージェント基盤

自社でホスト側を実装している場合、MCP Appsに対応するには、iframeの生成、sandbox属性の付与、CSPの適用と申告審査、JSON-RPCメッセージの検証、監査ログの生成、ドメイン許可リストの運用を自前で作ることになります。仕様がホストに課す義務は、そのまま実装工数です。ユーザーが数十人規模の社内基盤でこれを作り込む判断はまず通りません。ホスト側の対応を待ち、サーバー側はツールの戻り値を構造化する作業に投資したほうが、後からのUI対応が安く済みます。

見送るべき場面3：監査要件が厳しくCSP緩和の申告が通らない案件

金融・医療・公共系では、外部ドメインへの通信申告そのものが審査対象になります。地図タイル、外部フォント、画像配信のいずれも申告が要るため、審査に数週間かかる組織ではUIの仕様変更ごとに待ちが出る。改修サイクルが月次より速い案件では、この待ち時間が開発を止めます。

判断の目安は、必要な外部ドメインをゼロにできるかどうか。すべてをインラインとdata URIで完結できるならCSP緩和は不要で、審査の壁は消えます。切り分けは案件ごとに条件が変わるため、生成AI開発・AI受託開発のように設計段階から入る形で詰めるほうが早い。前提を整理する段階なら、MCPが何を標準化した規格なのかから確認します。

保守コストを左右するUIテンプレートの版管理と監査ログの運用

公開後に効いてくるのは、仕様の理解より運用の設計です。

UIテンプレートの版番号とprefetchキャッシュの整合設計

ホストの事前取得は初回描画を速くする一方、更新の反映を遅らせます。URIを固定したままHTMLだけ差し替えると、キャッシュを持つクライアントは古い画面を出し続けます。

運用しやすいのはui://のパス末尾にビルド識別子を含める方式です。画面を更新するたびURIが変わり、ツール定義のresourceUriも一緒に更新されるため、ホストは新しいリソースとして取り直します。障害調査では画面操作もtools/callとして届く点に注意。visibilityを["app"]に絞ればUI専用と分かり、モデル起点の呼び出しと判別できます。

MCP Apps SDKの版上げとホスト更新に伴う回帰テストの範囲

実装にはnpmの@modelcontextprotocol/ext-appsを使います。2026年8月時点のlatestは1.7.5で、更新頻度は高め。2026年3月23日の1.3.0で終了要求の通知が入り、同月中に1.3.1と1.3.2で不具合修正が続きました。

回帰テストの対象は、SDKの版上げ時が寸法通知と表示モード変更まわり、ホストの更新時がCSP適用とサンドボックスの挙動まわりです。ホスト側の変更は事前告知なしに入るため、主要ホストごとに描画確認の手順を用意し、リリースのたびに機械的に回します。

よくある質問

導入検討でよく挙がる論点を5つ取り上げます。

MCP AppsとMCP-UIはどう違いますか？

MCP-UIはMCPにUIを載せる先行のコミュニティ実装で、MCP Appsはその流れを公式仕様として標準化したものです。策定にはMCP-UIコミュニティも参加しており、先行実装が仕様へ収れんした関係にある。新規に作るならio.modelcontextprotocol/ui拡張に寄せ、既存実装はui://スキームと_meta.uiへの置き換えが移行の主作業です。

MCP Appsに対応していないクライアントではどう表示されますか？

UIは描画されません。クライアントがio.modelcontextprotocol/uiへの対応を宣言しない場合、サーバー側でテキスト応答へ分岐させる段階的強化が推奨されています。分岐がないと非対応ホストでは何も返らないか、HTMLの生テキストが出る。テキスト応答を常に返せる状態にしてから対応ホストにUIを足します。

MCP Appsの実装に必要なSDKのバージョンはどれですか？

npmの@modelcontextprotocol/ext-appsを使い、2026年8月10日時点のlatestは1.7.5です。終了要求の通知を使うなら1.3.0以降、自動リサイズの水平スクロール不具合を避けるなら1.3.2以降が下限。仕様本体のリビジョンはリポジトリ上で2026-01-26とdraftの2本のみで、SDKの版が上がっても仕様の日付は変わりません。両者は分けて記録します。

UIから外部APIを直接呼び出せますか？

既定では呼べません。ホストが適用するCSPはconnect-srcを'none'に閉じており、申告のないドメインへの接続は拒否されます。外部通信が要るなら_meta.ui.cspでドメインを申告し、ホストの審査を通す必要がある。外部APIの呼び出しはサーバー側のツールへ寄せ、UIはtools/callで結果を受け取る形のほうが審査も監査も通ります。

MCP Tasks拡張と組み合わせる必要はありますか？

短時間で終わる処理なら不要で、tools/callの応答をそのまま画面に描けば済みます。要るのは実行に数十秒以上かかり、途中経過をUIに出したい場合。Tasks拡張は2026-07-28版でio.modelcontextprotocol/tasksとして正式化され、tasks/getによるポーリングとtasks/updateを備えます。UI側はタスクハンドルで進捗を描き直す実装になり、両拡張に対応したホストが前提です。

関連記事

• MCPとRAGの違いとは？役割の違いと使い分け：どの機能をMCP側へ寄せるかの判断材料です。
• FastMCP 4とは？sessionless対応と移行判断：Python実装でステートレス化に追随する際の移行項目です。
• Streamable HTTPとは？SSEとの違い：UIリソースの配信が乗るトランスポート層の仕組みです。
• GitHub Remote MCP Serverとは？認証の設計：リモート配置のMCPサーバーでの認証設計の実例です。
• Windows Performance Analyzer MCPとは？：個別MCPサーバーの導入判断を対応範囲の差から比較した事例です。