MCP Appsとは？AIとの会話に操作できる画面を組み込む仕組み

MCP Appsとは？AIとの会話に操作できる画面を組み込む仕組み

MCP Appsとは何か

MCP（Model Context Protocol）は、AIアプリが外部のデータや機能を利用するための共通の仕組みです。例えば売上を調べる場合、AIが文章から数字を推測するのではなく、外部の集計機能を呼び出して結果を受け取ります。MCP Appsは、その連携に利用者が直接触れる対話的な画面を組み合わせる拡張です。

文字だけの会話でも、「先月と比べて」「関東だけに絞って」と頼むことはできます。ただし、候補を何度も切り替えて比べる作業では、その都度条件を文章にして、返答を待ち、前の結果を探す手間がかかります。期間の選択欄や地域のボタンがあれば、現在の条件を確かめながら変更できます。

ここでいうUI（ユーザーインターフェース）は、グラフ、表、入力欄、ボタンなど、人が情報を見たり操作したりする部分です。完成したグラフの画像を貼る場合と違い、選択内容に応じて表示を変えるなどの動きを持たせられます。文章は目的や疑問を伝えることに、画面は細かな選択や比較に向いています。

ただし、MCPで接続したすべてのツールに画面が自動で付くわけではありません。画面を提供する側の実装と、それを受け入れるAIアプリ側の対応が必要です。また、画面が付いても集計の正確さが自動的に高まるわけではなく、数値の信頼性は取得元や処理内容に左右されます。

ツールとUIリソースを結び付ける仕組み

仕組みの中心は、処理を行うツールと、結果を表示するUIリソースを関連付けることです。MCPサーバーは、外部のデータ取得や業務処理を提供する側です。売上を集計するツールに対し、その結果をグラフで見せるHTMLのUIリソースを用意し、対応する画面をホストが取得できるようにします。

UIリソースは、画面を組み立てるためのHTMLなどを指します。一方、ツールの結果は、日付、地域、金額といった処理後のデータです。この二つは役割が異なります。同じ画面の構成でも受け取る期間が変われば違うグラフになり、同じ集計結果でも画面の設計によって表やグラフで表現できます。

ホストとは、利用者が会話しているAIアプリなど、MCPの接続や画面の表示を受け持つ側です。基本的な流れは次のように整理できます。実際の取得のタイミングや見せ方はホストの実装によって異なります。

1. 利用者の依頼を受け、ホストを通してMCPサーバーのツールを呼び出します。
2. ホストが、ツールに関連付けられたUIリソースを取得します。
3. ホスト内の表示領域で画面を動かし、ツールの結果を渡してグラフや表を表示します。
4. 利用者が画面を操作し、必要に応じて表示の変更や追加の処理を行います。

役割を分けると、ホストは会話と画面の受け入れ、通信の仲介を担い、UIは情報の表示と入力を担当します。サーバーはデータの取得や集計、保存などの業務処理を担当します。画面が会話の中にあるからといって、AIモデルそのものがボタンやグラフを動かしているわけではありません。

例えば、受け取った表を金額順に並べ替えるだけなら、画面内の処理で済む場合があります。別の月のデータが必要なら、ホストが認める方法で追加のツール呼び出しを行う設計が必要です。どこまで操作できるかは、ホストの許可や実装、サーバーが提供する機能に従います。

また、画面で選んだ条件が、そのまますべてAIに伝わるとは限りません。画面だけで使う状態と、説明のために会話へ渡す情報は区別します。「選んだ地域について説明して」と続けたいなら、地域や期間、対象の集計結果を適切に共有する仕組みを用意します。

売上グラフを操作する具体例

ここでは、理解のために架空の売上分析アプリを考えます。特定のサービスが提供している機能を示すものではありません。利用者が「今月の売上を見せて」と依頼すると、対象期間や閲覧できる範囲を確認したうえで集計ツールが実行され、日別の売上と地域別の内訳が返るとします。

対応する画面には、日別の棒グラフ、期間の選択欄、地域の選択欄が表示されます。初期表示は「今月・全地域」です。画面に対象期間、単位、集計対象を示しておけば、利用者は何の数字を見ているのかを確かめながら条件を変えられます。更新時点も分かると、直近の売上が含まれているか判断できます。

次に、地域を「関東」に切り替えます。すでに受け取ったデータに地域別の内訳が含まれていれば、画面内で絞り込み、グラフを更新できます。全地域の合計値しか受け取っていなければ、関東の数字を正しく表示するには追加の取得が必要です。見た目が同じ選択操作でも、手元のデータで済む処理と再取得が必要な処理があります。

続いて期間を前月に変える場合も、その期間のデータがなければ集計し直します。取得中は読み込み表示を出し、更新に失敗した場合はその状態を示します。選択欄だけが「前月」になり、グラフが今月のまま残ると誤読につながるため、どの条件の結果を表示しているかを明確にすることが大切です。

利用者は期間や地域を切り替えて変化を見比べ、気になる週を選んで「この範囲の売上が落ちた理由を考えて」とAIに尋ねられます。このときは、選択した範囲と、それに対応するデータを会話へ共有する設計が必要です。画面を操作した事実だけで、AIが最新の選択状態を把握しているとは考えないようにします。

グラフの数値は取得データに基づきますが、売上が落ちた理由についての文章はAIの解釈を含みます。売上の数字だけでは、天候、在庫不足、販促の終了などの原因を確定できません。画面から確認できる事実と、追加データで確かめるべき仮説を分けると、分析結果を過信せずに使えます。

会話内の画面が役立つ場面

この仕組みが役立つのは、目的を文章で伝えた後、複数の条件や候補を見ながら細かく選びたい場面です。AIに大まかな依頼をし、返ってきた画面で調整し、気になった点をまた会話で尋ねる、という流れを組み立てられます。

• 分析：期間や分類を切り替え、グラフや表を見比べます。数値を読むだけでなく、条件を反復して調整する作業に向いています。
• 候補選定：条件に合う候補を一覧にし、詳細を開いて比較します。候補名を何度も入力せずに、選んだ対象について質問できます。
• 入力作業：日付や数量などをフォームで指定し、送信前に内容を確認します。入力欄や選択肢があると、どの項目を埋めるべきかも伝わります。

一方、「昨日の売上はいくら？」のように一つの値を答えれば済む照会では、文章だけで十分な場合があります。画面の読み込みや操作が増えると、かえって手間になることもあります。長時間の文書編集や、多数の表を並べる仕事では、広い独立した画面の方が扱いやすいでしょう。

選ぶ基準は、画面を付けられるかどうかではなく、直接選ぶことで利用者の手順が分かりやすくなるかです。導入を検討するときは、現在の作業で何度条件を書き直しているか、どこで見比べにくくなっているかを確認すると、画面の必要性を判断しやすくなります。

操作のしやすさも確認が必要です。キーボードだけで選択や実行ができるか、読み上げで項目名やエラーを理解できるか、スマートフォンの狭い領域でも内容を追えるかを確かめます。グラフだけで伝わりにくい場合は数値の表を添え、読み込み中や失敗時にも次にできる操作を案内します。

サンドボックス・接続先・権限の注意点

外部から受け取った画面をホスト内で動かす場合、見た目だけでなく、どこまで動作を許すかが重要になります。サンドボックスは、画面を隔離された実行領域に置き、ホストのほかの部分へ不用意に干渉しないようにするための仕組みです。ただし、隔離されていることと、その利用者に業務データを見せてよいことは別の問題です。

画面の隔離、外部通信の制限、業務処理の認可は、それぞれ確認する必要があります。認可とは、誰がどのデータを読み、どの処理を実行してよいかを判断することです。売上グラフを安全な領域に表示していても、本来閲覧できない部門の数値を渡してしまえば、データへのアクセス制御は適切ではありません。

画面が通信する相手や、読み込む外部の画像・スクリプトなどの資源も管理対象です。必要な接続先を整理し、ホストの制限に沿って構成します。画面へ渡す情報は用途に必要な範囲に絞り、集計値で足りるなら顧客ごとの明細を含めない、といった設計が考えられます。

データベースの認証情報や強い権限を持つ秘密鍵を、画面のHTMLや処理結果に不用意に含めることも避けます。画面は利用者の操作を受け付ける場所であり、秘密を隠すための保管場所には向きません。外部サービスへの認証や業務上の権限確認は、接続構成に応じて適切な側で扱います。

閲覧と、更新・送信を伴う操作も分けて考えます。例えば集計結果を見ているだけの段階と、その結果を社外へ送る段階では、操作の影響が異なります。送信先と内容を実行前に確認できるようにし、サーバー側でもその利用者に送信権限があるかを確かめ、実行後には成功・失敗を表示します。ボタンを隠すだけでは権限の保証になりません。

さらに、MCPへの対応とMCP Appsへの対応は同じではありません。採用するホストが拡張を受け入れるか、どの通信や操作を許すか、非対応時にテキストや表で返せるかを確認します。導入時には公式拡張文書の版と各ホストの提供状況を照合し、実際の環境で表示と操作を確かめる必要があります。

通常のMCP連携・Webアプリ・Elicitationとの違い

関連する仕組みは、どれが新しいかではなく、何を担当するかで区別すると分かりやすくなります。通常のMCPツール連携は処理の呼び出しと結果の受け取りが中心です。MCP Appsはその連携を土台に、会話内で結果に触れるUIを加える関係にあります。

通常のWebアプリは、画面の広さやページ間の移動を含め、独立した作業の流れを設計しやすい形です。MCP Appsでは会話を続けながら結果を操作できる一方、表示領域や許可される操作はホストの影響を受けます。どちらかにすべてを置き換える必要はなく、短い比較は会話内で行い、複雑な編集は専用画面へ移す構成も考えられます。

Elicitationは、MCPの処理で足りない情報などを利用者に求めるための仕組みです。例えば処理に必要な条件を尋ねることが主目的であり、グラフを繰り返し操作する画面を提供することとは狙いが異なります。両方で入力を扱う場合があっても、それだけで同じ仕組みとはいえません。入力方式の詳細は、採用する仕様の版とホストの対応で確認します。

企画の判断軸は、会話の文脈を保って、視覚的に選ぶ必要があるかです。文章で答えが得られるなら通常の連携で足りるかもしれません。結果を見ながら何度も条件を変え、その選択についてAIと話したいなら、会話内に操作画面を組み込む価値が見えてきます。

更新履歴