通常のMCP（Model Context Protocol）を使った仕組みでは、ユーザーがAIエージェントに依頼すると、AIエージェントが必要なMCPツールを呼び出す。ツールの実行結果はAIエージェントのコンテキストに戻り、AIエージェントがユーザーへの応答を生成する。

　ローウィン氏によると、MCPサーバはAIエージェントに機能やビジネスロジックを追加する仕組みとして有用だ。一方、ユーザーとMCPサーバの間に直接の接続はなく、基本的にAIエージェントとそのコンテキストを経由すると説明する。

　この構造が問題になり得る例としてローウィン氏が挙げたのがファイルのアップロードだ。

　MCPサーバへファイルを送るツールを用意しても、ユーザーが直接MCPサーバへアップロードする仕組みでなければ、ファイルの内容をAIエージェントに渡し、そこからツールを介してサーバへ送る形になり得る。

　こうした処理をローウィン氏は、「非常に高価なコピー＆ペーストのようなものになる」と指摘する。例えば大量のテキストを含むファイルの場合、その内容をAIエージェントのコンテキストに入れた上で、MCPツールへ渡す必要が生じるためだ。

AIを経由しないデータ転送をどう実現するか

　こうした課題への対応策としてローウィン氏が紹介するのが、MCPを拡張してインタラクティブなUIを表示できる「MCP Apps」だ。

　通常のMCPツールでは、ツールの実行結果がAIエージェントへ戻る。MCP Appsではこれに加え、HTML、CSS、JavaScriptで構成したUIをユーザー側に表示し、ユーザーがその画面を直接操作できる。

　ファイルアップロードの場合、AIエージェントがアップロード用のUIを表示し、ユーザーがそこへファイルをドラッグ＆ドロップする構成を取れる。ローウィン氏は、この方式であればファイル本体をAIエージェントに通さず、バックエンドのサーバへ直接送れると説明する。

　この仕組みでは、ユーザーの要求を受けて適切なツールや画面を呼び出す部分にはAIエージェントを使いつつ、ファイル転送そのものは通常のアプリケーション処理として実行できる。

社内AIを「チャットだけ」で作る必要はない

　MCP Appsで実行できるのは、ファイルアップロードだけではない。ローウィン氏によると、表やフォーム、グラフなどをAIエージェントからユーザーへ提示する使い方もある。

　例えばAIエージェントにチームメンバーの一覧表示を依頼すると、文章で一覧を返すのではなく、検索、フィルター、並べ替え、ページ送りが可能なデータテーブルを表示できるという。

　こうしたUI機能を用意した背景には、ローウィン氏が開発し、Prefectが提供するMCPサーバ構築フレームワーク「FastMCP」のユーザー像がある。ローウィン氏によると、FastMCPの利用者は主にPythonのエンジニアで、企業内で情報を共有したり、フォームを通じて情報を収集したりする用途が多いという。

　そこでPrefectは、表やフォーム、グラフなど、企業内で使われやすいUI部品をPythonから組み合わせて構築できるオープンソースのUIフレームワーク「Prefab」を開発した。自由度の高いWebサイトを一から作るのではなく、用途を絞ったUI部品を組み合わせることで、MCP Apps向けの画面を構築する考え方だ。

　ローウィン氏は、ここで重要なのは「フロントエンドをPythonで一から作る」ことではないと説明する。用途を企業内の情報共有や情報収集に絞り、既存のUI部品を組み合わせることで、Pythonエンジニアが慣れたPythonの環境を離れずに、業務向けのインタラクティブなUIを構築できるようにする考え方だ。

　FastMCPでは、MCPツールが通常のデータを返す代わりにPrefabのUI部品を返すことで、対応するクライアント上にインタラクティブな画面を表示できる。例えばチームメンバーの一覧を返すツールであれば、単なるテキストやデータではなく、検索や絞り込みができる表として提示できる。グラフと表を同じ画面に並べることも可能だという。

　さらに、MCP Appsを単発の画面表示ではなく、バックエンドと連携するアプリケーションとして構築することもできる。例えばフォームへ入力した内容をボタン操作でデータベースへ送るなど、ユーザーの操作を起点にバックエンド処理を実行する構成だ。前述したファイルアップロードもこの仕組みを利用する。

AIに「全部やらせる」のではなく、役割を分ける

　こうした仕組みから見えてくるのは、社内AIのUIを全てチャットに集約する必要はないということだ。

　自然言語で「何をしたいか」を判断したり、どの機能を呼び出すべきかを選択したりする処理はAIエージェントに向いている。一方、大容量ファイルの転送や一覧データの閲覧、フォームへの入力といった処理までAIエージェントのコンテキストを経由させる必然性はない。

　むしろ、こうした処理を従来型のUIやアプリケーション処理に任せることで、AIエージェントへ渡すデータ量を抑えられる。トークン消費だけでなく、処理時間やユーザーの操作性の面でもメリットが生まれる可能性がある。

　ローウィン氏が紹介したPrefabの実装でも、データ表現の大きさはコストや遅延に直結する論点になった。当初はUIをJSON形式でAIエージェントから送信していたが、その後、Pythonによる表現がJSONより約70％小さいことが分かったという。現在はPythonを送信し、サーバ側でJSONへ変換して描画する方式に変更した。ローウィン氏は、これによってトークン効率やコスト、レイテンシを改善できると説明する。

本稿は、2026年9月11日にAI Engineerが公開したGenerative UI... in Python? — Jeremiah Lowin, Prefectを基に作成しました。