MCP Appsで、AIチャット+UIのハイブリッドを作る
AIチャットに業務を任せようとすると、必ずぶつかる壁があります。「在庫はいくつですか」のような一問一答は自然文で十分ですが、「承認待ちの申請を一覧で見て、まとめてチェックしたい」のような操作は、文章のやり取りだけでは非効率です。この課題に対する現実的な解が、2026年1月にMCP(Model Context Protocol)の公式拡張として公開された「MCP Apps」です。チャットの会話の流れを保ったまま、必要な場面だけミニUIを差し込めるようにする仕組みで、ChatGPT・Claude・Goose・VS Codeなど主要なAIクライアントが対応を始めています。
MCP Appsとは何か
MCP Appsは、MCPサーバーが「UIリソース」を定義し、それをツールと紐づけて公開できるようにする拡張仕様です。仕組みは大きく3つの要素から成ります。
- UIリソース(
ui://スキーム): HTMLベースの小さな画面部品を、MCPサーバー側があらかじめ用意しておきます - ツールとUIの紐づけ: 「承認一覧を表示する」ツールを呼び出すと、対応するUIリソースが結果として返され、チャット内にそのまま描画されます
- 双方向通信: 描画されたUI(サンドボックス化されたiframe内で動作)とホストアプリケーションが、標準のMCP JSON-RPCでメッセージをやり取りできます。ユーザーがUI上でボタンを押すと、その操作が新たなツール呼び出しとしてAI側に伝わります
つまりMCP Appsは、AIが「文章で説明する」代わりに「操作可能な画面を差し出す」ための標準的な方法だと捉えると分かりやすいです。
「画面をなくす」こととは逆の発想
画面という概念をなくすAIネイティブなUIで紹介したように、AIネイティブな設計では固定画面を作り込まない方向性が語られることが多くあります。MCP Appsはこれと矛盾するようですが、実際には補完関係にあります。
- 単純な照会・依頼は自然文のまま完結させる(画面を作らない)
- 一覧確認・複数選択・数値の細かい入力など、文章より画面の方が誤解なく扱える操作だけ、その場でミニUIを呼び出す
つまり「画面を全廃する」のではなく、「画面が必要な瞬間にだけ、必要な分だけ画面を差し込む」という折衷案がMCP Appsの立ち位置です。要件定義の段階では、業務ごとに「自然文で足りるか」「画面がないと誤操作・見落としのリスクがあるか」を仕分けることが最初の作業になります。
業務システムでの構築イメージ
たとえば経費精算の承認業務を、MCP Appsで組む場合を想定します。
- 承認待ち一覧を表示するツールを用意する:「未承認の経費申請を見せて」という指示に対し、通常のテキスト応答ではなく、チェックボックス付きの一覧UIをMCPサーバーが返す
- UI上でユーザーが選択操作を行う:担当者は一覧から複数件を選び、「承認」ボタンを押す。この時点ではまだ何もAIとやり取りしていない、UI単体での操作
- UIからホストへ操作内容が送られる:「承認」ボタンの押下が、選択された申請IDの一覧とともにホスト側に伝わる
- ホストが対応するツールを呼び出す:承認処理を行うMCPツールが、選択されたIDを引数として実行される
- 結果がチャットに反映される:「3件承認しました」といった結果が、通常のチャット応答として返る
同様に、日程調整エージェントが空き時間をカレンダー形式のUIで提示し、ユーザーがクリックで候補を選ぶ、といった構成にも応用できます。共通しているのは、「選ぶ・チェックする・並び替える」といった、自然文で説明すると回りくどくなる操作をUIに任せている点です。
要件定義で決めておくべきこと
MCP Appsを使った設計では、次の点を事前に整理しておくとスムーズです。
- どの操作をUI化するか:一覧からの複数選択、数値の一括入力、承認のような「取り消しが利きにくい操作」は、UI化して誤操作のリスクを下げる候補になります
- UIに渡すデータの範囲:UIはサンドボックス化されたiframeで動作しますが、そこに表示するデータ自体は最小限に絞る必要があります。承認一覧に個人情報を含む項目をどこまで出すかは、権限設計とあわせて決めておきます
- UI側の実装をどこが担当するか:UIリソースはMCPサーバー側で用意するため、既存のWeb UIのコンポーネントを流用できるか、新規に作る必要があるかで、開発コストの見積もりが変わります
- UI非対応のクライアントへの配慮:MCP Apps未対応のAIクライアントから使われた場合、UIなしでも自然文だけで業務が完結する代替経路を用意しておく必要があります
まとめ
MCP Appsは、AIチャットの手軽さと、従来型UIの正確さを両立させるための標準的な仕組みです。「画面を全部なくす」のでも「全部従来通りの画面に頼る」のでもなく、承認・一覧確認・複数選択のような、文章では扱いにくい操作だけを狙ってUI化する、というのが実務的な使い方になります。要件定義の段階でどの操作をUI化するかを見極めておくことが、使い勝手と開発コストのバランスを取る鍵になります。