MCP Appsとは？ui://・sandbox iframe・postMessageの安全設計

結論：MCP Appsはtoolの結果を、会話内のinteractive UIへ広げるextension

MCP Appsは、MCP serverのtoolがtextやstructured dataだけでなく、dashboard、form、chart、media viewer、multi-step workflowのようなUIをhostへ渡せるようにするextensionです。tool descriptionにUI resourceへの参照を置き、hostがそのHTMLをconversation内でsandboxed iframeへ表示します。ユーザーは別のWebページへ移らず、UIを操作し、その結果をhostやmodelへ返せます。

ただし、MCP Appsは通常のWebアプリを置き換えるものではありません。会話の文脈、hostの既存tool、ユーザーconsent、sandbox、監査が必要な体験に向きます。公開ページ、複雑な認証、独立したSEO、長い設定画面が中心なら、通常のWebアプリと役割を分けた方が保守しやすい場合があります。

MCP Appsの基本フロー：tool・resource・host・UI

• tool descriptionが、interactive UIへ対応するUI metadataとui:// resourceの参照を宣言する
• hostはtoolが呼ばれる前にUI resourceをpreloadできる。入力をUIへ先に流す設計もある
• modelがtoolを呼ぶと、serverが通常のdataとUIで必要な情報を返す
• hostはresourceのHTMLを取得し、sandboxed iframeへ隔離して表示する
• UIとhostはpostMessageを使うJSON-RPCベースの通信で、tool call、結果、context更新などをやり取りする
• hostはCSP、permissions、tool allowlist、user consent、open linkなどを環境のポリシーで制御する

{
  "name": "visualize_data",
  "description": "Interactive data visualization",
  "_meta": {
    "ui": {
      "resourceUri": "ui://charts/interactive"
    }
  }
}

ここでのui://は、ユーザーのbrowserが自由に開く通常の公開URLではありません。MCP hostがserverからresourceを取得し、MCP AppsのUIプロトコルと自分の安全ポリシーに従って表示します。resourceUriがあるから自動的に安全、または全hostで同じように表示される、という意味ではありません。

sandbox iframeの安全境界：できることと、できないことを分ける

公式overviewでは、MCP AppsのUIはsandboxed iframeで動き、親ページのDOM、cookie、local storage、親ページのnavigation、親contextのscriptへ直接触れない設計として説明されています。UIとhostの間はpostMessageの通信路になり、hostが利用可能なcapabilityを制御します。

postMessageとUI dialect：文字列を投げるだけではない

MCP AppsのUIとhostは、core MCPのstdioやHTTPをそのまま共有するのではなく、postMessageを使ったJSON-RPCベースのUI向け通信を持ちます。tool callのproxy、ui/initialize、tool result、model context更新など、共通する概念とUI専用のmethodが混在します。通信できることだけを確認せず、どの方向のmessageが何を起こすかを表にします。

CSP・permissions・consentを別々に設計する

MCP Appsでは、UIをiframeへ入れた後も、外部scriptやresourceをどこから読むか、browser capabilityを何に使うか、UIからtoolを呼べるかを別々に制御します。CSPは読み込み先を制限する仕組み、permissionsはbrowserやhost capabilityへの要求、consentはユーザーが意味を理解して許可する境界です。一つを設定しただけで他の二つが自動的に安全になるわけではありません。

MCP Appsが向く4つのUI体験

• 複雑なdata exploration：filter、drill down、sort、chartを会話の横で操作する
• 設定wizard：多くの選択肢と依存関係を一つのformで確認してからtoolを呼ぶ
• rich media：PDF、画像、3D、音声などをtext要約だけでなくviewerで確認する
• multi-step workflow：review、approval、triageを一覧とactionで進め、選択をmodelへ返す

リアルタイム監視や長いjobの表示では、MCP AppsのUIとMCP Tasksを組み合わせる設計も考えられます。ただし、UI表示とtaskの状態更新は別の機能です。TasksのtaskId、認可、取消、TTLをUIの見た目へ隠さず、再読み込み・切断・host未対応時の状態も説明できるようにします。

client support：公式extensionでも対応は一律ではない

MCP Appsはofficial extensionですが、hostがどのUI method、sandbox、resource、tool proxy、permissionを実装しているかはclientごとに変わります。公式のExtension Support Matrixは対応確認の入口ですが、community-maintainedの表でもあるため、更新日、hostのversion、接続先の実装差を自分の環境で確認します。MCP Appsが使えない場合に、同じtoolがtextやstructured dataで読めるfallbackを残しておくと、対応差でworkflow全体が止まりません。

MCP Appsの脅威モデル：UIの見た目に権限を与えない

SDKやframeworkは手段で、security boundaryではない

公式のMCP Apps documentationには、UI側のApp classやhost向けApp Bridge、ReactやVueなどの例があります。SDKは通信や表示の実装を楽にしますが、どのtoolを呼べるか、どのoriginを読むか、どの情報をmodelへ返すかを自動で正しく決めるものではありません。frameworkの選択、CSP、permissions、consent、監査は別レイヤーでレビューします。

導入前の最小チェックリスト

• MCP Appsでなければ解けないUI上の課題を一文で説明できる
• tool metadata、ui:// resource、host fetch、sandbox iframe、postMessageの流れを図にできる
• CSPのscript・style・image・connect先を必要なoriginだけに絞った
• permissions、tool call、open link、model context updateを別々のcapabilityとして確認した
• UI未対応hostでもtextやstructured dataで結果を読めるfallbackを作った
• UIからwrite、delete、deployを呼ぶ場合、対象・差分・scope・承認者を再表示する
• messageのschema、origin、source、request id、古いstateを検証する
• serverの出所、更新、外部送信、tool権限をUI表示とは別にレビューした
• cookie、token、秘密、個人情報をUIやmodel contextへ不要に渡さない

まとめ：MCP AppsはUIの追加ではなく、hostとの信頼境界の追加

MCP Appsは、toolとui:// resourceをhostのsandbox iframeへつなぎ、postMessageでUIと会話を双方向にするofficial extensionです。導入では、resourceの取得、sandbox、CSP、permissions、tool allowlist、consent、context update、client support、text fallbackを分けて確認します。見た目がリッチになるほど、UIの誘導を権限と混同せず、read-only・最小scope・監査可能な操作から段階的に広げてください。