APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。

株式会社 エーピーコミュニケーションズの技術ブログです。

MCP Interactive UIを試して見えたもの

こんにちは、エーピーコミュニケーションズ ACS事業部の福井です。
最近、身の回りの非エンジニアの人たち――たとえば妻がスマホに新しいアプリを入れることにわりと抵抗を示すのを見ていて、ずっと考えていることがあります。

「アプリを作っても、使ってもらえなければ意味がない」

業務アプリも同じで、いくら良い機能を作っても「新しいURLを覚える」「新しい画面に慣れる」というハードルで使われないまま終わるケースは珍しくありません。
一方で、LINE のように「もう毎日使っているもの」の中で完結するなら話は別ですよね。

そんなことを考えていたとき、メンバーから Microsoft が GitHub で公開した MCP Interactive UI Samples を教えてもらいました。
MCP(Model Context Protocol)を使って、Microsoft 365 Copilot のチャット内にリッチな業務 UI を描画できるデモです。

「M365 なら既に導入されている企業も多い。チャットの中でアプリが動くなら、新しいアプリを入れてもらう必要がないのでは?」

この期待を検証するために、サンプルをベースに日本語の保険請求管理デモを一から構築してみました。
結果として「Web アプリの代替」にはならなかったのですが、想像以上にアプリっぽいことができたのと、「新しい入口」としての可能性を強く感じています。
今回はその PoC の全容を、実際の操作画面とともに共有します。

作ったもの:日本語保険請求管理 MCP エージェント

Microsoft のサンプル「Zava Insurance」を土台に、日本語化と機能カスタマイズを行った jp-hoken-mcp というデモを構築しました。

技術スタック

要素 技術
バックエンド Node.js + Express + @modelcontextprotocol/sdk
フロントエンド(ウィジェット) React 18 + Fluent UI v9 + Vite
データストア Azure Table Storage(ローカルは Azurite)
ビルド vite-plugin-singlefile(全JS/CSSを1つのHTMLにインライン化)
デプロイ先 Azure App Service
動作環境 Microsoft 365 Copilot(BizChat)/ VS Code GitHub Copilot

できること

  • 保険請求の一覧表示・フィルタリング(ダッシュボードウィジェット)
  • 個別請求の詳細表示(タブ付きウィジェット + クイックアクション)
  • ステータス更新(受付済→審査中→承認済→完了)
  • 点検記録の新規作成
  • 鑑定士の照会

すべてが Microsoft 365 Copilot のチャット画面上で、自然言語から操作できます。

実際の画面:チャットの中にアプリが動く体験

エージェント起動

Microsoft 365 Copilot(BizChat)のサイドバーから jp-hoken-mcp を選択した起動直後の画面です。

「請求一覧を見る」「審査中の請求を確認」「HK202504005 の詳細」といった会話スターターがカード形式で並んでいます。
declarativeAgent.json に定義したプロンプトがそのまま表示されており、クリックするだけで操作が始まります。
ここで大事なのは、ユーザーが「何ができるか」を事前に知る必要がないということです。
選択肢が目の前に提示されているので、そこから始められます。

ダッシュボード:チャット内にテーブルが出現する

「保険請求の一覧をダッシュボードで表示してください」と入力した結果です。

「……これ、チャットの中に本物のテーブルが出てきている」

ステータス別の件数サマリー、検索バー、ソート可能なテーブル。
これは React + Fluent UI v9 で構築したウィジェットが、Copilot のチャット領域内にレンダリングされている状態です。
各行の「詳細」ボタンをクリックすると、裏側で app.callServerTool() が呼ばれ、次のウィジェットに遷移します。

普通に Web アプリっぽい。
この瞬間、「新しいアプリを入れなくても、ここで業務が回るのでは」という最初の期待が形になった気がしました。

詳細画面とクイックアクション

ここが私が一番面白いと感じたポイントです。
上部に「⚡ クイックアクション(Copilot に自動送信)」というパネルがあります。
現在のステータスが「審査中」なので「承認を依頼」「否認を依頼」のボタンが動的に表示されています。

ボタンを押すと app.sendMessage() で Copilot にプロンプトが自動送信されます。
つまり UI のボタンクリック → 自然言語プロンプト → AI がツールを選んで実行、という流れが1クリックで完結します。
ユーザーはプロンプトの書き方を知らなくても、ボタンを押すだけで操作できるわけです。

下部にはタブ構成があり、「基本情報」「点検」「作業依頼書」「担当者連絡先」「関連情報」を切り替えて表示できます。
普通の業務アプリの詳細画面と遜色ない情報量です。

データ書き込み時の確認ダイアログ

「HK202504003 の初回点検を登録してください。優先度は高で、担当は田中一郎です」と指示した場面です。
Microsoft 365 Copilot がツール実行確認ダイアログを自動表示し、パラメータを一覧で見せてくれます。
「確認」を押すまで実行されないのは、セキュリティ上とても安心感があります。

注目すべきは「担当は田中一郎です」という自然言語を、AI が kanteishiId: kanteishi-001 に自動解決している点です。
ユーザーは ID を知る必要がありません。

登録完了と次のアクション提案

点検登録が完了すると、登録内容のサマリーに加えて「次に行うと便利な操作」を Copilot が提案してくれます。
「予定日の設定」「点検指示の追記」「審査ステータスの更新」――従来のフォーム画面にはなかった「次に何をすべきか」のガイドです。

これは地味ですが、業務フローに慣れていないユーザーにとっては大きな助けになると感じました。

鑑定士一覧の照会

「担当できる鑑定士の一覧を表示してください」で、専門分野・連絡先つきのテーブルが返ってきます。
ここから「地震対応できる人は?」「HK202504005 に合う鑑定士は?」と続けて聞けるのが、チャットベースの強みです。

アーキテクチャの要点:バックエンドは Web App と共有できる

「チャットの中にアプリが出る」と聞くと特殊な技術に見えますが、バックエンド構成は従来と変わりません。

┌────────────────────────────────────────────────┐
│           Express サーバー                       │
│                                                  │
│  ┌─────────────┐      ┌───────────────────┐   │
│  │  REST API    │      │  MCP プロトコル     │   │
│  │  /api/seikyu │      │  /mcp              │   │
│  └──────┬──────┘      └────────┬──────────┘   │
│         └───────────┬──────────┘               │
│               ┌─────▼──────┐                   │
│               │   db.ts    │                   │
│               │ Azure Table │                   │
│               │  Storage   │                   │
│               └────────────┘                   │
└────────────────────────────────────────────────┘
        ▲                        ▲
        │                        │
   Web App                 M365 Copilot
  (従来UI)              (MCP Apps)

同一の Express サーバーが REST API(/api/*)と MCP エンドポイント(/mcp)の両方を提供し、データ層を完全に共有しています。
つまり「既存の Web アプリのバックエンドに MCP の口を追加する」だけで、Copilot からアクセスできるようになります。

ウィジェットの仕組み

ウィジェットは React アプリを vite-plugin-singlefile で1つの HTML ファイルにまとめたものです。
MCP サーバーがレスポンスにこの HTML を含め、Copilot がチャット内にレンダリングします。
「画面遷移」は app.callServerTool() で次のツールを呼び出すことで擬似的に実現しています。

ウィジェットが表示される環境と制約

環境 ウィジェット表示 必要ライセンス
VS Code GitHub Copilot GitHub Copilot サブスクリプション
Microsoft 365 Copilot(Teams / BizChat) M365 E3/E5 + Copilot アドオン
Copilot Studio ❌ テキストのみ Copilot Studio ライセンス
Power Automate ❌ テキストのみ Power Automate ライセンス

ウィジェットが動作するのは VS Code と M365 Copilot のみです。
Copilot Studio や Power Automate ではテキストのみの応答になります。
この制約は導入を検討する際に重要なポイントだと思います。

PoC で分かったこと:MCP Apps は何に向いていて、何に向いていないか

ここからが一番伝えたい内容です。
実際に構築して操作した上での所感なので、一次情報として共有します。

MCP が得意なこと

カテゴリ なぜ得意か
自然言語での検索・閲覧 「審査中の請求を見せて」で即座にフィルタできる。フォーム設計が不要
ツールチェーン(連鎖実行) 「一覧を出して、最高額の詳細も開いて」が1プロンプトで完結する
アプリへの動線づくり アプリの存在を知らない人が、Copilot 経由でたどり着ける
定型外の問い合わせ 画面に用意されていない切り口の質問にも柔軟に対応
次のアクション提案 業務フローに不慣れなユーザーへのガイドが自然に生まれる

MCP が苦手なこと

カテゴリ なぜ苦手か
複雑なデータ入力 フォームのバリデーションがない。自由記述でミスが起きやすい
破壊的操作 確認ステップはあるが、Web App のモーダルダイアログほど明示的ではない
操作結果の視認性 チャットは流れていく。「さっき何をしたか」を振り返りにくい
ファイル操作 写真アップロード・PDF出力は MCP 単体では不可

私の結論:ハイブリッド構成が現実解

MCP Apps → 「発見・閲覧・誘導」のレイヤー
Web App  → 「操作・更新・削除・入力」のレイヤー

バックエンドは共有し、MCP は「普段 M365 を使っている人が、新しいアプリを意識せずに業務情報にアクセスする入口」として機能させます。
本格的な入力や操作が必要な場面では Web App に誘導する。
この役割分担が最も現実的だと感じています。

プロンプト制御:従来 UI とは根本的に違う世界

もう1つ、触ってみて「これは新しい課題だ」と強く感じたのがプロンプト制御です。

比較項目 従来 UI(Web App) MCP + Copilot
入力方法 ボタン・フォーム(確定的) 自然言語(確率的)
呼ばれる API 開発者が完全に制御 AI が判断(意図と異なる場合あり)
セキュリティ境界 UI 層で遮断できる プロンプトで制御が必要

ユーザーが「URL を教えて」と聞けば、制御していなければバックエンドの情報を答えてしまいます。
「そんなボタンは画面にない」で済んでいた従来とは、セキュリティの境界が根本的に異なります。

本デモでは多層防御で対処しています。

  1. サーバー側でレスポンスから機密データを除外(最も確実)
  2. instruction.txt に禁止事項・スコープを明記(効果大・ただし100%ではない)
  3. ツール description を明確に記述(誤用防止)
  4. ツールアノテーション(destructiveHint 等)で慎重処理を促す

設計原則:「Copilot に渡すデータに、見せてはいけない情報を入れない」

これは従来の API 設計で「フロントエンドに渡すデータに機密情報を含めない」のと同じ考え方です。
MCP だからといって特別なことをしているわけではなく、情報の出口を制御するという基本に立ち返る――この気づきが、技術的に一番の収穫でした。

まとめ

MCP Apps を触って最初に感じたのは「想像以上にアプリっぽい」でした。
チャットの中にテーブルが出てきて、ボタンで遷移して、データの更新もできる。

一方で「Web アプリの代替」にはなりません。
フォーム入力、ファイル操作、操作の確証――これらは従来の UI が圧倒的に強いです。

でも、最初の動機に立ち返ると答えが見えます。
「新しいアプリを入れたくない人」にとって、いつも使っている M365 の中で業務情報に自然言語でアクセスできる――それだけで大きな価値があると思います。

MCP Apps は「アプリの代替」ではなく「アプリへの新しい入口」。

既存のバックエンドに MCP の口を追加し、M365 を日常的に使っている人たちへの動線を増やす。
技術的には大きなジャンプではないですが、「誰が・どこからアプリに辿り着くか」のデザインを変える発想だと私は捉えています。

身の回りの「新しいアプリを入れたくない人たち」の顔を思い浮かべると、この方向性には可能性があると感じました。

お知らせ

ACS 事業部のご紹介

私の所属する ACS 事業部では、開発者ポータル Backstage、Azure AI Service などを活用し、Platform Engineering + AI の推進・内製化を支援しています。

www.ap-com.co.jp www.ap-com.co.jp www.ap-com.co.jp

また、GitHub パートナーとしてお客様に GitHub ソリューションの導入支援を行っています。 GitHub Copilot などのトレーニングなども行っておりますので、ご興味を持っていただけましたらぜひお声がけいただけますと幸いです。

一緒に働いていただける仲間も募集中です! ご興味持っていただけましたらぜひお声がけください。 ※求人名の冒頭に【ACSD】と入っている求人が当事業部の求人です。

www.ap-com.co.jp www.ap-com.co.jp

本記事の投稿者: 福井
本記事は GitHub Copilot に伴走してもらいながら書き上げました。構成・表現の整理にAIを活用しつつ、体験談・検証・最終判断はすべて著者本人によるものです。