またHTMLの時代が来た? AIが「動くUI」を作るGenerative UIとは

AIに何かを頼むと、これまではだいたい Markdown のテキスト が返ってきていました。整った表、番号付きリスト、コードブロック、太字と斜体。読みやすくはあるけれど、返ってくるのはあくまで「文字」で、動きはしません。

ここが最近、静かに、しかしはっきりと変わりつつあります。Claude Artifacts や ChatGPT Canvas 以降、AIが返してくる成果物のかたちが、HTML/CSS/JavaScript の「動くUI」 へ広がってきました。Google Research の論文では、生成速度を除いて比較すると、約83%のケースで Generative UI が Markdown より選ばれた と報告されています。Google 自身は、新しい高性能モデルほど UI 生成の品質が上がりエラー率も下がることから、Generative UI を「emergent capability(創発的な能力)」と位置づけています。

この流れは、業界では「Generative UI」という言葉で語られるようになりました。前回書いたClaude Artifactsの活用は、まさにこの流れの入口でしたが、話は Artifacts の1機能では収まらないところまで来ています。

この記事では、AIのアウトプットがなぜ Markdown から HTML に広がってきたのか、Generative UIとは何なのか、そしてこの変化が中小企業の業務にどう効いてくるかを整理します。

これまで AI が返してきたのは「動かないテキスト」だった

少し時系列で振り返っておきます。

ChatGPT が世に出た2022年11月から2024年前半くらいまで、AI からの返事はほぼ Markdown 一辺倒 でした。文書、コード、表、リスト、この4種類が、ほぼすべての回答フォーマットでした。ChatGPT にお願いした企画書も、Claude に頼んだ議事録まとめも、返ってくるのは同じ「テキストの塊」です。

Markdown が便利なのは事実です。人間にも読みやすい、コピペで別の場所に持っていける、書式の意味も明確、コードもきれいに囲われる。この時期のAI活用のノウハウはほぼ全部、「Markdown で返ってくる文章をどう業務に持っていくか」の話でした。

一方で、限界もはっきりしていました。返ってきたテキストは、動かない。表は並んでいるけれど並べ替えられない、数字は書いてあるけれど計算しない、リストは項目が並んでいるだけで操作できない。何かをするためには、必ず人間が別のツール(Excel、専用アプリ、業務システム)に転記する工程が必要でした。

Artifacts / Canvas 以降、「動くUI」が新しい選択肢に

ここを大きく変えたのが、Claude Artifacts の登場と、その後の ChatGPT Canvas における React/HTML 描画対応 です。詳しくは前回のArtifacts記事で書いたとおりですが、要点はひとつで、AI が返してくる成果物のかたちに『動く UI』という新しい選択肢が加わった ということです。

• Claude Artifacts では、HTML/CSS/JavaScript や React コンポーネントを、その場で動くページとして右のペインに描画できる
• ChatGPT Canvas は 2024年10月、文章とコードの共同編集ワークスペースとして登場し、その後 React/HTML のサンドボックス描画にも対応
• Anthropic によると、Artifacts は数百万人のユーザーに使われ、累計作成数は5億件を超える 規模に達しています。すべてが動くアプリというわけではなく、文書・コード・図なども含みますが、AIとの会話から独立した成果物を作る使い方が、大規模に定着し始めているのは間違いありません

これは、単純に「新しい機能が付いた」という話ではなくて、AI の答え方の選択肢が広がり始めた サインです。Markdownで返してもいい話に加えて、モデル側が「動くUIで返したほうが良い」と判断できる場面が、着実に増えてきています。

なぜ83%がMarkdownよりAI生成HTMLを好むのか

冒頭に触れた Google Research の論文 の実験は、LMArena 由来の 100 件のプロンプトを使い、Generative UI と Markdown の出力を並べて比較評価するものでした。生成速度を評価から外すと、約83%のケースで Generative UI が選ばれた と報告されています(2人の評価者による比較)。

Google はこの現象を「創発的な能力(emergent capability)」と呼んでいます。新しい世代の Gemini モデルほど UI 生成の品質が上がり、エラー率が下がる、という結果です。UI を書けと直接教え込んだわけではないにもかかわらず、モデル世代を上げるだけで UI の生成品質が伸びていく、という意味合いです(その裏側では、システム指示・画像検索や画像生成などのツール・出力を整えるポストプロセッサーなども組み合わさっています)。

なぜユーザーが Markdown より HTML を好むのか。理由は3つに整理できます。

1. 目に入る情報量が多い

Markdown の表と、HTML+CSS で色分けとアイコンが付いた表とでは、同じデータを見ても頭に入るスピードが違います。人間の目は、テキストより 視覚的に構造化された画面 を速く処理します。

2. 操作できる

グラフが並んで表示されるだけの Markdown と、期間を切り替えられる HTML のダッシュボードでは、後者のほうができることが多い。フィードバックが返ってくる UI は、単なるテキストより情報の使いみちが広い。

3. そのまま業務に持ち込める

Markdown の内容を別の業務ツールにコピペする、という工程が消えるケースが増えます。HTML で返ってきた見積書テンプレは、そのまま社内ポータルに貼れる。動くツールとして返ってきたものは、その場で使い始められる。

「Generative UI」という業界の合言葉

「動くUI」を返すAIの動きは、業界では Generative UI(生成UI) という言葉でひとまとまりに語られるようになってきました。ざっくり言うと、「LLMが、コンテンツだけでなく、UIそのものを生成する」概念です。

具体的なプレイヤーを並べると、生態系の広がりが見えます。

• Anthropic Artifacts / ChatGPT Canvas: 大手LLMの標準機能として組み込み済み
• Vercel v0: 自然言語プロンプトから React/Tailwind のUIコンポーネントを生成する専用サービス
• Bolt / Lovable / Cursor Composer: フルスタックのWebアプリを会話から生成
• MCP Apps extension / AG-UI / Google A2UI: AI エージェント同士やユーザーとの間で「動くUI」をやり取りするためのプロトコル標準化

特に注目したいのが、標準化の動きです。すでに複数のプロトコルが正式に走り始めています。

• MCP Apps: 2026年1月、Anthropic の MCP の最初の公式拡張として一般提供開始。MCP サーバーがテキストやJSONだけでなく、操作できるダッシュボード・フォーム・可視化を、会話の中に返せます。HTML/JavaScript は サンドボックス化された iframe の中で実行され、Claude / ChatGPT / VS Code などが対応
• A2UI(Agent-to-UI): Google が 2025年12月に公開、2026年4月に v0.9 が発表。HTMLやJavaScriptを送らずに、UIの構造データを送る方式です。受け取ったクライアント側は、自社の React / Flutter / Angular などの部品で描画します
• AG-UI: エージェントと画面のあいだの、ストリーミング・状態同期・双方向通信を扱うプロトコル

「モデルが1回答として HTML をその場で吐く」段階から、「エコシステム全体で動く UI をやり取りする」段階へ、業界は進もうとしています。ここで重要なのは、動く UI の実体が 必ずしも HTML そのものとは限らない という点です。A2UI のように「UI の構造データ」を送るアプローチも本命候補のひとつで、Generative UI の話は「HTML 復権」より一段広い、動的な UI のやり取りの標準化、と捉えるのが正確です。

HTMLになる代償 コスト・速度・エラー

もちろん、AI アウトプットが HTML に寄っていくことには、代償もあります。無視できない3つ。

1. トークンコスト

HTML / CSS / JavaScript を丸ごと生成する方式は、静的な Markdown より出力量が増えやすく、API 利用ではトークンコストの上昇につながります。ただし、増加幅は UI の複雑さ、CSS をインラインで持つか、既存コンポーネントを呼ぶか、A2UI のような構造化データを使うか、といった実装方式によって大きく変わります。すべての場面で大きく高くなるわけではありませんが、業務で回すなら念のためコスト観測は必要です。

2. 生成速度

見た目のある UI を生成するのは、テキストだけの返答より時間がかかります。前述の Google Research の論文でも、実装上の課題として 生成に 1〜2 分かかる場合がある ことが挙げられています。「10秒で返ってくるはずの回答が、動く UI の生成に切り替わった瞬間に1分待ち」というのは、業務の中では地味に効いてきます。

3. HTML / CSS / JS エラー

コードの生成ですから、時々エラーが混じります。CSS の記述ミス、JS の変数エラー、HTML の閉じタグ抜け。動くはずの UI が白い画面のまま、というのは、Markdown の誤字とは違うレベルのフラストレーションになります。

このあたりは、「テキストで済むならテキストで、動く必要があるなら動く UI で」 という当たり前の使い分けに戻ってくる話です。全部が全部、動く UI で返ってくるべきではありません。

中小企業の業務にどう効くか

さて、この Generative UI の流れは、中小企業の業務にどう効いてくるでしょうか。前回のArtifacts記事で触れた話と重なりますが、Generative UI 全体の視点で見直すと、こう整理できます。

• 提案書のインタラクティブ化: 静的な PDF ではなく、シミュレーションのスライダーが動く HTML 資料を、Claude や ChatGPT に投げるだけで作れる。営業の場での通り方が変わる
• 社内ダッシュボード試作: 「うちの案件、この切り口で見てみたい」を言葉で頼むと、動くダッシュボード試作が返ってくる。IT担当がいなくても、経営者や現場が自分で作り始められる
• 業務ミニツールの量産: CSVをドラッグ&ドロップして即分析、料金の即試算、スケジュールの自動組み立て。前回書いたような「使い捨てツール」が、Markdown 時代よりずっと自然に量産できる
• 顧客向けデモ・提案: 「うちのサービスをこう使うイメージです」を、動くUIとして数分でこしらえて、その場で共有できる

私たちも、社内で「まず動くもので返して」とAIに頼む場面が確実に増えてきています。会話の中で下書きが動く形になってくると、テキストで議論するより判断が早い。「頼む → テキストが返る → 別のツールで動かす」の3ステップが、「頼む → 動くものが返る」の1ステップに縮まる、というのがこの変化の本質だと思っています。

さいごに 「頼む」から「動く形で返してもらう」へ

Markdown から HTMLへ、テキストから動くUIへ。この移行は、まだ全部の場面で起きているわけではありません。長文の説明や、機械可読なデータの受け渡しは、まだテキストの Markdown で受け取ったほうが便利な場面が多いです。ただ、業務のなかで「見せる」「試す」「触ってもらう」が絡む場面では、動くUIで返してもらったほうが早い時代 に、確実に入りました。

過去記事の流れでいうと、15本目非エンジニアが自社システムを直すまでは「業務システムを AI で作る」話、16本目バイブコーディングは「AIと自然言語で会話してコードを書く」話、23本目Artifacts記事は「使い捨てツールを秒で作る」話でした。今回は、その全部に通底する 「AIが返してくる成果物のかたち」そのものが動くUIへ広がっている、という上位の話になります。

中小企業として、今すぐやれることは、たとえば普段の依頼に一言足すことです。「表で返して」ではなく、「HTMLの動く表で返して」。「議事録を要約して」ではなく、「インタラクティブな議事録ハブとして返して」。この一言で、返ってくる成果物のかたちが変わり、その先の使いみちも変わります。「頼む形」の粒度を、Markdownから「動く形」に上げていく。それが、Generative UI 時代の中小企業のちょっとした習慣になっていくはずです。