MCP は返答を文章だけに縛らなくてよくなった

要点

要点まとめ

この話の本質は、AI の返答を毎回文章だけで受け取る必要はない、という点だ。表、グラフ、確認フォームのほうが自然な結果がある。
MCP Apps は、その場で操作できる画面を会話内へ出すための公式な共通方式で、client ごとに別々の UI を作る負担を減らそうとしている。
ただし便利になるぶん、承認、記録、実行範囲の制限も一緒に設計する必要がある。原典はそこをかなり重く見ている。
つまり読みどころは『見た目が派手になった』ではなく、『どの結果を text で返し、どの結果を UI で返すべきか』を決めやすくしたことだ。

続けて読む

読み終えたら次へ

この1本で終わらせず、同じ目的・同じテーマ・近い原典へ進めます。

同じ目的で読む 仕事で安全に使いたい

権限、秘密情報、監査、失敗時の扱いを確認したい人向け。

同じテーマで読む AIエージェント

ツール利用、MCP、Agent SDK、長時間タスク、実行責任の設計。

次の記事 OpenAPI 3.1 は「JSON が通る」だけでは曖昧な tool 契約を止める

AI に tool を渡す事故は、『JSON の形は合っていたのに、違う接続先へ送った』『読むだけのつもりが更新操作だった』『認証の強さを勘違いした』で起きる。OpenAPI 3.1 の価値は、その曖昧さを引数の形だけでなく接続先と権限まで含めて減らせる点にある。

読解

何が変わったのか

原典は、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 での実機確認が必要だ。

この記事は役に立ちましたか

公益的に続けるため、役に立った点や読みづらかった点だけを短く送れます。メールアドレスは不要です。