MCP Apps は、MCPサーバーがチャートやフォームのようなインタラクティブUIをチャットの中に描画させるための拡張仕様です。日本語の紹介はすでに複数出ていますが、その多くは公式サンプルを動かした体験記で、「結局どのクライアントで見えるのか」「ライセンスはどうなっているのか」といった、採用判断に必要な部分が抜けています。本記事では公式リポジトリと実行バイナリを直接調べ、対応ホストの実態と4か所で食い違うライセンス表示を一次ソースで確定させました。
30秒でわかる MCP Apps
・MCPの拡張仕様。サーバーがUIリソースを宣言し、ホストがサンドボックス化iframeで描画する
・公式リポジトリは modelcontextprotocol/ext-apps（★2,771）。仕様の版は 2026-01-26 と draft
・ターミナルのCLIには描画の実装が無い。Claude Code v2.1.241 のバイナリに ui:// は0件
・非対応ホストでも壊れない。段階的強化の設計で、UIが無ければテキストが返る
・ライセンス表示が4か所で食い違う。NOASSERTION／Apache 2.0／MIT／移行期の3系統
MCPサーバーそのものの作り方はMCPサーバーの作り方2026年完全ガイド：TypeScript・Python両対応チュートリアルにまとめてあります。プロトコルの仕組みから押さえたい場合はMCPとは何か？仕組み・3プリミティブ・仕様改訂の流れを図解で理解するが入口です。本記事はその上に乗る拡張仕様の話に絞ります。
MCP Apps とは——テキストしか返せなかったMCPにUIを足す
MCPは、AIアシスタントに対してツールとリソースを公開する仕組みです。ただし応答はテキストと構造化データに限られていました。公式ドキュメントは、それでは足りない用途を4つ挙げています。
・データ可視化 — チャート、グラフ、更新され続けるダッシュボード
・リッチメディア — 動画プレイヤー、音声波形、3Dモデル
・対話フォーム — 複数ステップのウィザード、設定パネル、承認フロー
・リアルタイム表示 — ライブログ、進捗表示、ストリーミング
MCP Apps が解こうとしているのは、これらをホストごとにバラバラに実装していた状況です。公式ドキュメントの説明は率直です。
Before MCP Apps, each host implemented UI support differently. MCP-UI, OpenAI’s Apps SDK, and custom implementations all solved similar problems with incompatible approaches.
サーバー開発者はホストごとにアダプタを保守する必要があり、セキュリティモデルもまちまちでした。MCP Apps はそこを1つに揃えるという位置づけです。
リポジトリの実測値も確認しました。
| 項目 | 実測値（2026-08-30 時点） |
|---|---|
| リポジトリ | modelcontextprotocol/ext-apps |
| star / fork | 2,771 / 369 |
| オープンIssue | 208件 |
| 作成 | 2025-11-21 |
| 最終push | 2026-08-12 |
| 仕様のバージョン | 2026-01-26 と draft の2ディレクトリ |
| npm パッケージ | @modelcontextprotocol/ext-apps |
| 最新バージョン | v1.7.5（2026-07-23 公開）／公開32バージョン |
| 直接依存 | 1個（@standard-schema/spec） |
| 配布物 | 40ファイル・1.4MB。エントリポイント7種（./react / ./server / ./app-bridge 等） |
依存が1個というのは仕様SDKとしては潔い構成です。React向けのエントリポイントが分かれているので、UI側の実装言語は事実上Webフロントエンドになります。
MCP Apps は結局どこで見えるのか
ここが最初に確定させるべき点です。公式READMEの「Supported Clients」に並んでいるのは次の8つでした。
| ホスト | リンク先のドキュメント |
|---|---|
| ChatGPT | OpenAI の Apps SDK ドキュメント |
| Claude | claude.com のコネクタ向けドキュメント |
| VS Code | 2026-01-26 付のMCP Apps対応ブログ |
| Goose | Block の MCP Apps チュートリアル |
| Postman | MCPリクエストの操作ドキュメント |
| MCPJam | MCP Apps のサンプル記事 |
| mcp-use | インスペクタ |
| Alpic | プレイグラウンド |
注目したいのは「Claude」のリンク先が claude.com/docs/connectors/… である点です。これは Claude のコネクタ（デスクトップ／Web）向けのドキュメントで、ターミナルで動く Claude Code CLI ではありません。
そこで、手元の Claude Code v2.1.241 の実行バイナリを直接検索しました。
| 検索した文字列 | ヒット数 | 意味 |
|---|---|---|
ui:// |
0 | MCP Apps のUIリソーススキームが存在しない |
MCP Apps |
3 | 後述。いずれも設定の説明文 |
iframe（対照群） |
139 | iframe という語自体は存在する |
widget（対照群） |
29 | widget という語自体は存在する |
ui:// が0件というのが決定的です。MCP Apps はUIリソースを ui:// スキームで宣言する設計なので、これを解釈するコードが無ければウィジェットは描画できません。対照群として iframe や widget が3桁・2桁ヒットすることを確認しているので、「検索方法が悪くて見つからない」わけではありません。
では残る3件の「MCP Apps」は何かというと、すべて設定の説明文でした。非必須トラフィックを無効化する設定について、こう書かれています。
connectors that return MCP Apps show the text tool result instead of the widget
ウィジェットの代わりにテキストのツール結果が出る——これは次節の「段階的強化」がそのまま現れた記述です。CLI側は、その挙動を説明するテキストを持っているだけで、描画の実装は持っていません。
したがって、試すならホストを選ぶところから始めます。
ターミナルで claude を起動して「MCP Apps のUIが出ない」と悩んでも、それは仕様どおりです。手軽に確認したいなら、READMEが挙げるインスペクタ系（MCPJam / mcp-use / Alpic のプレイグラウンド）か、VS Code を使うのが早道です。
なお本記事はバイナリ内の文字列検索と公式ドキュメントの読解までを実測範囲としており、各ホストで実際にウィジェットが描画されるところまでは検証していません。
MCP Apps の設計——壊れない仕組みとサンドボックスの前提
MCP Apps の設計で実務上いちばん効くのが、この性質です。公式ドキュメントの記述はこうです。
MCP Apps is designed for graceful degradation. Hosts advertise their UI support when connecting to servers; servers check these capabilities before registering UI-enabled tools. If a host doesn’t support MCP Apps, tools still work — they just return text instead of UI.
流れを整理すると3段階です。
- ホストが接続時にUI対応の有無を通知する（capability negotiation）
- サーバーがそれを見て、UI付きツールを登録するか決める
- 非対応なら、ツールはテキストを返す
そして公式ドキュメントは「UIは要件ではなく段階的強化である」と明言しています。サーバー実装者から見れば、MCP Apps に対応しても既存のホストを壊さないということです。これは「対応クライアントが限られている拡張仕様」を採用する際の最大の懸念に、仕様側が最初から答えている形になります。
ui:// のリソースを宣言"] C -->|"対応しない"| E["通常のツールとして登録"] D --> F["サンドボックスiframeで描画
AppBridge 経由で通信"] E --> G["テキストのツール結果
（壊れない）"]
セキュリティ設計——同一オリジンを持たないiframeという前提
MCP Apps のUIは、通常のWebアプリとは前提が違います。公式ドキュメント（CSP & CORS）の記述が端的です。
Unlike regular web apps, MCP Apps HTML is served as an MCP resource and runs in a sandboxed iframe with no same-origin server.
HTMLがMCPのリソースとして配られ、同一オリジンのサーバーを持たないサンドボックスiframeで動くということです。この前提から、2つの設定が必要になります。
| 仕組み | 何を制御するか | 宣言する場所 |
|---|---|---|
| CSP | ブラウザが何を許すか。fetch/XHR/WebSocket の宛先は connectDomains、スクリプト・スタイル・画像・フォントは resourceDomains |
_meta.ui.csp |
| CORS | API側が何を許すか。オリジンをallowlistするAPIには安定したオリジンが要る | _meta.ui.domain |
開発時の localhost も宣言が要る点は、公式ドキュメントがわざわざ明記しています。「ローカルでは動いたのに配ったら通信が止まる」の逆——ローカル開発の時点で宣言漏れに気づける設計です。
また _meta.ui.domain のフォーマットはホスト依存とされており、「各ホストのドキュメントで対応形式を確認せよ」と書かれています。ここは仕様が統一しきれていない部分で、複数ホストへ配る場合は個別確認が必要になります。
SDKの中身——39定義のプロトコルスキーマ
「拡張仕様」と言われても、実際に何が増えるのかは中身を見ないと分かりません。npm パッケージを展開すると、生成済みのJSONスキーマが同梱されていました（dist/src/generated/schema.json）。
npm pack @modelcontextprotocol/[email protected]
tar xzf modelcontextprotocol-ext-apps-*.tgz
スキーマのタイトルは 「MCP Apps Protocol」、説明は「JSON Schema for MCP Apps UI protocol messages」で、定義は39個ありました。名前から役割が読み取れます。
| 定義のグループ | 代表的な型 | 役割 |
|---|---|---|
| 能力交渉 | McpUiHostCapabilities / McpUiClientCapabilities / McpUiAppCapabilities |
ホスト・クライアント・アプリそれぞれが何をできるかを宣言する |
| 初期化 | McpUiInitializeRequest / McpUiInitializeResult / McpUiInitializedNotification |
iframe側とホスト側のハンドシェイク |
| 表示制御 | McpUiDisplayMode / McpUiRequestDisplayModeRequest |
表示モード（インライン／拡大など）の要求 |
| ホスト環境 | McpUiHostContext / McpUiHostCss / McpUiHostStyles / McpUiHostContextChangedNotification |
ホスト側のテーマやCSSをUIへ渡し、変化を通知する |
| 操作 | McpUiOpenLinkRequest / McpUiDownloadFileRequest |
リンクを開く・ファイルを落とすといった、iframeが単独ではできない操作の委譲 |
| 後始末 | McpUiRequestTeardownNotification / McpUiResourceTeardownRequest |
UIの破棄 |
| サンドボックス | McpUiSandboxProxyReadyNotification / McpUiSandboxResourceReadyNotification |
サンドボックス側の準備完了通知 |
McpUiHostCss と McpUiHostStyles が定義されているのが目を引きます。サンドボックスiframeの中身はサーバーが配ったHTMLですが、ホスト側のテーマを受け取って見た目を合わせられるということです。ダークモードのチャットに真っ白なウィジェットが出る、という事態を仕様レベルで回避しにいっています。
McpUiOpenLinkRequest / McpUiDownloadFileRequest の存在も設計を物語ります。 サンドボックス化されたiframeは、自力で新しいタブを開いたりファイルを保存したりできません。それらをホストへ委譲するリクエストが用意されているということは、逆に言えばそれ以外の危険な操作は委譲されないということでもあります。許される操作が列挙されている形です。
ライセンスは4か所で違う表示になっている
採用判断で見落としやすい点です。同じリポジトリのライセンスが、見る場所によって4通りに表示されます。
| 見る場所 | 表示 |
|---|---|
GitHub API の license.spdx_id |
NOASSERTION |
| README のバッジ | Apache 2.0 |
npm の package.json |
MIT |
| LICENSE ファイル本文 | 移行期の3系統（下記） |
LICENSE ファイルの冒頭は、状況をこう説明しています。
The MCP project is undergoing a licensing transition from the MIT License to the Apache License, Version 2.0 (“Apache-2.0”). All new code and specification contributions to the project are licensed under Apache-2.0. Documentation contributions (excluding specifications) are licensed under CC-BY-4.0.
さらに続けて、再ライセンスの同意が取れていない寄与はMITのままであり、それらについては元のライセンスを超える権利は付与されないと明記されています。整理すると3系統です。
・新規コードと仕様 → Apache-2.0
・ドキュメント（仕様を除く） → CC-BY-4.0
・再ライセンス同意が未取得の寄与 → MIT のまま
GitHub が NOASSERTION を返すのは「ライセンス情報が無い」という意味ではなく、標準のSPDX識別子1つに当てはめられないという意味です。バッジの「Apache 2.0」も嘘ではありませんが、リポジトリ全体が一律Apache-2.0だと読むと不正確になります。
社内でライセンス審査を通す場合は、本文を読む前提で臨んでください。
自動収集ツールはバッジかAPIの値を拾います。バッジを拾えば「Apache-2.0」、APIを拾えば「不明」、npmを拾えば「MIT」と、どの経路で集めたかによって審査結果が変わりうる状態です。
実務上は、使う対象がコードか仕様かドキュメントかを切り分けたうえで、該当部分の条件を確認するのが正しい手順になります。SDK（npmパッケージ）だけを使うなら、同梱の LICENSE が判断材料になります。
OpenAI の Apps SDK との関係
MCP Apps は OpenAI の Apps SDK と競合するものではなく、統合を意図した標準化として位置づけられています。公式ドキュメントが挙げた「互換性のない実装」の例に、MCP-UI と OpenAI の Apps SDK が並んでいるとおりです。
実際、リポジトリには docs/migrate_from_openai_apps.md という移行ドキュメントが置かれています。既に OpenAI の Apps SDK でUIを作っているなら、そこから MCP Apps へ寄せる道筋が用意されている、ということです。
対応ホストの一覧に ChatGPT が入っていることも、この読み方を裏づけます。同じUIリソースを ChatGPT と Claude の両方に配れるのが、この仕様が狙っている状態です。
ブラウザ側からAIエージェントへツールを生やすCloudflare WebMCPとは｜サイトにAIエージェント用ツールを1スイッチで生やす仕組みを解説とは向きが逆で、MCP Apps はサーバーからホストへUIを送る方向を担います。MCPサーバー側の作り方全般はMCPサーバーとは｜仕組み・一覧・おすすめ・作り方・設定を2026年最新で解説にまとめてあります。
まとめ
・MCP Apps はMCPの拡張仕様。サーバーがUIリソースを宣言し、ホストがサンドボックスiframeで描画する
・公式リポジトリは modelcontextprotocol/ext-apps（★2,771・208 Issue）。仕様の版は 2026-01-26 と draft
・SDKは @modelcontextprotocol/ext-apps v1.7.5、直接依存1個・40ファイル・1.4MB
・対応ホストは8つ（ChatGPT / Claude のコネクタ / VS Code / Goose / Postman / MCPJam / mcp-use / Alpic）
・ターミナルのCLIには描画実装が無い。Claude Code v2.1.241 に ui:// は0件（対照の iframe は139件）
・非対応ホストでも壊れない。段階的強化の設計で、UIが無ければテキストが返る
・ライセンス表示は4通り。NOASSERTION／Apache 2.0／MIT／移行期の3系統
「対応クライアントが限られる拡張仕様」を採用するかどうかは、普通なら悩みどころです。ただし MCP Apps は非対応でも壊れないことを仕様の中心に据えているので、サーバー側で先に対応しておいて、ホストが追いつくのを待つという選択が取れます。判断に必要なのは「どこで見えるか」を誤解しないことだけです。
参照ソース
- modelcontextprotocol/ext-apps — GitHub（公式リポジトリ。star・Issue数・ツリー構成は2026-08-30 にAPIで取得）
- MCP Apps 公式ドキュメント（Overview・CSP/CORS の記述。2026-08-30 確認）
- @modelcontextprotocol/ext-apps — npm（バージョン・依存・ライセンス欄。2026-08-30 に
npm packで配布物も確認） - 本記事の実測環境: Claude Code v2.1.241（バイナリ内の文字列検索）/ Node.js v22.13.1 / macOS (Darwin 23.5.0, arm64)
