MCP は返答を文章だけに縛らなくてよくなった
このノートは原文の代替ではありません。読むべきポイントと実装上の意味を整理し、原典への入口を示します。
要点まとめ
- この話の本質は、AI の返答を毎回文章だけで受け取る必要はない、という点だ。表、グラフ、確認フォームのほうが自然な結果がある。
- MCP Apps は、その場で操作できる画面を会話内へ出すための公式な共通方式で、client ごとに別々の UI を作る負担を減らそうとしている。
- ただし便利になるぶん、承認、記録、実行範囲の制限も一緒に設計する必要がある。原典はそこをかなり重く見ている。
- つまり読みどころは『見た目が派手になった』ではなく、『どの結果を text で返し、どの結果を UI で返すべきか』を決めやすくしたことだ。
何が変わったのか
原典は、MCP Apps を最初の公式 MCP 拡張として示し、tools が interactive UI components、つまり会話内で操作できる画面を返せるようにしています。対象は dashboard、form、visualization、multi-step workflow です。新しいのは『結果を説明文へ潰す前提』を崩したことです。実装では `@modelcontextprotocol/ext-apps` の `App` class を使い、UI と host が `JSON-RPC` over `postMessage` で構造化メッセージをやり取りします。UI は結果を見るだけでなく、必要なら server tool を呼び返したり、model context を更新したりできます。ただし自由な web app をそのまま置くのではなく、`sandboxed iframe`、つまり権限を絞った埋め込み枠で動かします。さらに UI-initiated tool calls には explicit approval を要求できるため、『便利な埋め込み画面』ではなく監査可能な UI 拡張として読むべきです。
なぜ重要か
日本の AI 導入では、chat 上の文章だけで承認、分析、入力補助まで押し込もうとして、結局人間が別画面に写し直すケースが多いです。その往復は遅いだけでなく、数字や設定の読み違いも増やします。MCP Apps は、text と UI の境界を設計対象に戻します。検索結果の要約だけなら text でよい。ですが比較表、レビュー差分、入力フォーム、監査画面は UI のほうが自然です。この判断を最初から持てると、tool 設計と approval 設計がかなり整理されます。
技術的ポイント
- MCP Apps は tools から interactive UI components を返せる official extension で、返却対象は text だけではない。
- `App` class により、UI は tool result の受信、server tool call、model context update を host とやり取りできる。
- UI は `sandboxed iframe` で動き、自由な web app と同じ権限を前提にしていない。実行範囲を狭める意図が明確だ。
- UI-to-host communication は `JSON-RPC` over `postMessage` を通るため、後から監査しやすい形に寄せられている。
- UI-initiated tool calls には host が explicit approval を要求できる。UI が勝手に強い操作を進める前提ではない。
- client support は Claude、Goose、Visual Studio Code Insiders、ChatGPT まで広がっており、client ごとの個別 widget 実装を減らす狙いがある。
英日キーワード
| 英語 | 日本語 | 補足 |
|---|---|---|
| MCP Apps | MCP Apps | MCP 上で文章以外の UI を返せる公式拡張。返答形式と承認境界を一緒に設計する必要がある。 |
| interactive UI components | 対話型 UI コンポーネント | 会話内に埋め込める操作画面。比較、入力、承認のような text だけでは苦しい結果に向く。 |
| sandboxed iframe | 制限付き iframe | 権限を絞って UI を動かす埋め込み枠。自由な web app と同じ実行権限を与えないための境界。 |
| JSON-RPC | 構造化メッセージ通信 | host と UI のやり取り形式をそろえる通信方式。後から監査しやすいログ形に寄せやすい。 |
| UI-initiated tool call | UI 起点のツール呼び出し | 画面操作から始まる tool 実行。会話本文とは別に承認と記録を設計する必要がある。 |
| model context update | モデル文脈更新 | UI 側の選択結果を会話文脈へ反映すること。表示だけの widget と違い会話進行へ影響する。 |
試すなら
- まず自分の tool 一覧から『文章で返すと読みにくい結果』を 1 つ選び、table、chart、form のどれが自然か分ける。
- 次に、その UI が読むだけなのか、tool を再実行するのか、approval が必要なのかを明文化する。
- 監査が必要な操作では、text 要約より先に UI initiated action の記録方法と consent 条件を決める。
注意点
- UI を返せるからといって、何でも画面化すればよいわけではない。単純な一問一答まで UI にすると実装だけ重くなる。
- client support は進んでいるが、各 host の実装差や時期差は残りうる。配布前に対象 client での実機確認が必要だ。