OpenUI：LLMがUIを生成するオープン標準OSS。OpenUI LangとReact/Vue/Svelteランタイム
OpenUI は LLM が UI を生成するための“オープン標準”。JSONより少ないトークンで構造化UIを表現する。

OpenUI は、LLM（大規模言語モデル）に 「テキスト」ではなく「UI（ユーザーインターフェース）」を生成させる ためのオープンソースのフレームワーク／標準です。 リポジトリの旗印はずばり「The Open Standard for Generative UI（生成UIのオープン標準）」。 LLMがチャートやフォーム、表といったUI部品を構造化して出力し、それが トークンの到着に合わせてリアルタイムにレンダリング されます。

OpenUI — The Open Standard for Generative UI（公式バナー）
「The Open Standard for Generative UI」を掲げるOpenUI。出典：thesysdev/openui（公式リポジトリ）

開発元は、生成UI（C1など）に取り組む Thesys。ライセンスは MIT で、誰でも自由に使い・改変・組み込みができます。 本稿は 2026年6月25日（JST）時点 で、公式GitHubリポジトリ（thesysdev/openui）をもとに、仕組み・特徴・導入・他ツール比較を整理します。

「開発時にAIでアプリを生成する」AIアプリビルダーとの違いは、本文と Retool新AIアプリビルダー（R2）徹底解説 を併読すると掴みやすくなります。

この記事のポイント
  • ・LLMに「UIを生成」させるためのオープン標準OSS（MIT・by Thesys）。
  • ・OpenUI Lang＝UI生成特化のストリーミング言語。JSONより最大67%少ないトークン。
  • ・React/Vue/Svelte等のランタイムと、チャート/フォーム/表の組み込み部品。
  • ・トークン到着に合わせてUIが段階的に組み上がる（ストリーミングレンダリング）。
  • ・部品ライブラリからシステムプロンプトを自動生成。「実行時」の動的UI生成のためのインフラ。

1. OpenUIとは — 「AIの応答をUIにする」

LLMは文章の生成が得意です。 しかし、ユーザーが本当に欲しいのは文章ではなく、操作できるUI であることが多々あります。 「先月の売上は？」に対して、長い文章で説明されるより、棒グラフと表 がパッと出てくる方が圧倒的に分かりやすい——これが「生成UI（Generative UI）」の発想です。 人は文章を読むより、図や表を“見る”方が速く理解できる場面が多く、特に数値・比較・選択を伴う情報ではその差が顕著です。 AIがいくら賢く答えても、それが読みづらい文章の塊では、価値が半減してしまいます。

OpenUIは、この 「AIの応答そのものをUIにする」 ためのフレームワークです。 LLMにUI部品を構造化して出力させ、それを実際のコンポーネントとしてレンダリングします。

「The Open Standard」を名乗ることにも意味があります。 生成UIは各社が独自方式で実装しがちな領域ですが、出力形式（言語）がバラバラだと、モデルもツールも相互運用できません。 OpenUIは、LLMがUIを表現するための共通の語彙（OpenUI Lang）を“開いた標準”として提供 することで、特定ベンダーに縛られない生成UIの土台を目指しています。 オープンソース（MIT）であることは、この「標準を皆で使える状態にする」という姿勢の表れでもあります。

OpenUIが提供する主な要素は次のとおりです。

・OpenUI Lang：UI生成に特化した、コンパクトでストリーミング前提の言語
・ランタイム：React（およびVue/Svelte等）で動く、組み込み部品ライブラリ付きの実行環境
・組み込み部品：チャート・フォーム・表・レイアウトなど
・ストリーミングレンダラ：モデル出力が届くたびにUIを段階的に更新（待ち時間の体感を短縮）
・プロンプト自動生成：部品ライブラリから、LLMに渡すシステムプロンプトを生成
・すぐ使えるチャットUI：生成UIを組み込んだ、そのまま動かせるチャットインターフェース（ゼロから作らなくてよい）

要するにOpenUIは、「LLMが正しいUIを、安く・速く・段階的に吐き出せるようにする」 ための言語とランタイムの組み合わせです。

なぜいま「生成UI」が注目されるのかも押さえておきましょう。 2023〜2025年は「チャット」がAIのインターフェースの主役でした。 しかし、文章のやり取りだけでは限界があります。 数値を比べるなら表やグラフ、入力を求めるならフォーム、選択肢を示すならボタン——人間にとって最適な情報の受け取り方は、内容によって変わるからです。 従来のチャットボットは、どんな質問にも「文章の壁」で答えるしかありませんでした。 生成UIは、この制約を取り払い、「内容に最適な見せ方をAIが選んで描画する」 段階へ進めます。 これは、AIのUXが「会話」から「動的に組み上がるインターフェース」へと進化する流れであり、OpenUIはその基盤レイヤを“オープン標準”として提供しようとしている、と位置づけられます。 ChatGPTやClaudeのようなアシスタントが普及し、人々が「AIに頼んで何かをやってもらう」ことに慣れた今、次の課題は「その結果をどう返すか」です。 文章で返すだけの時代から、最適なUIで返す時代 へ——OpenUIは、その移行を支える道具立てを揃えようとしているのです。

2. なぜJSONではなく専用言語なのか（OpenUI Langの狙い）

LLMにUIを出力させる素朴な方法は、「JSONで部品ツリーを書かせる」ことです。 たとえば、こんな具合です（イメージ）。

{
  "type": "card",
  "children": [
    { "type": "heading", "text": "今月の売上" },
    { "type": "barChart", "data": [/* ... */] },
    { "type": "table", "columns": [/* ... */], "rows": [/* ... */] }
  ]
}

これは動きますが、3つの問題があります。

・トークンを大量に消費する："type" や括弧、引用符などの構文がかさみ、コストとレイテンシが増える
・ストリーミングと相性が悪い：JSONは途中まで送ると壊れた状態になり、「届いた分だけ描画」が難しい
・壊れやすい：LLMが括弧やカンマを1つ間違えるだけでパースに失敗する

3つ目の「壊れやすさ」は、ストリーミングと組み合わさると特に厄介です。 JSONは構造が閉じて初めて妥当になるため、生成の途中段階は常に“不完全＝壊れた”状態です。 そのため「届いた分から描画する」ことが難しく、結局すべて揃うまで待つことになります。 一方、ストリーミング前提に設計された言語は、途中の状態でも意味が取れる ように作られているため、部分的に描画を進められます。 この「設計思想の違い」が、体験の差として効いてくるわけです。

OpenUI Langは、この課題を 「UI生成専用の、コンパクトでストリーミング前提の言語」 で解きます。 公式によれば、JSONより最大67%少ないトークン で同じUIを表現できます。 トークンが減ればコストとレイテンシが下がり、ストリーミング前提なので 「トークンが届くたびにUIが少しずつ組み上がる」 体験を実現できます。

トークン効率が効くのは、コストだけではありません。 生成UIでは、LLMが出力するトークン数がそのまま 「UIが完成するまでの待ち時間」 に直結します。 JSONで冗長に書かせれば、それだけ多くのトークンを生成する必要があり、ユーザーは長く待たされます。 OpenUI Langのように表現を圧縮できれば、同じUIをより少ない生成で・より速く 返せます。 さらに「ストリーミング前提」という設計は、体感速度に大きく寄与します。 全部が揃うまで真っ白な画面を見せるのではなく、見出しが出て、次にグラフの枠が現れ、データが流れ込む——という 段階的な描画 は、実際の完了時間が同じでも「速い」と感じさせます。 チャットの文章がストリーミングで少しずつ表示されると速く感じるのと同じ原理を、UI全体に適用したものだと考えると分かりやすいでしょう。

（OpenUI Lang のイメージ：JSONより簡潔・ストリーミング前提）
card
  heading "今月の売上"
  barChart data=@sales
  table cols=@cols rows=@rows

※ 上記は概念を示すための簡略イメージで、実際の構文は公式の仕様に従ってください。 ポイントは「冗長なJSONを避け、UI生成に最適化した表現でトークンを節約しつつ、ストリーミングで段階描画する」という設計思想です。

3. 仕組み：LLMがLangを吐き、ランタイムが段階描画する

全体像を図にすると次のようになります。

flowchart TD LIB["部品ライブラリ
チャート/フォーム/表/レイアウト"] --> SP["システムプロンプト自動生成
（何を出力してよいかをLLMに教える）"] U["ユーザーの質問
例: 今月の指標を可視化して"] --> LLM["LLM"] SP --> LLM LLM -->|OpenUI Lang をストリーミング出力| RT["OpenUI ランタイム
（React / Vue / Svelte）"] RT -->|トークン到着ごとに段階描画| UI["操作できるUI
グラフ・表・フォーム"] UI --> USER["ユーザー"]

流れはこうです。

第一に、部品ライブラリからシステムプロンプトを自動生成 します。 これにより、LLMは「自分が出力してよいUI部品は何か」「どう書けばよいか」を正しく理解します。 この自動生成があるおかげで、開発者は「LLMに何を許可するか」を部品ライブラリの定義として一元管理でき、プロンプトを手書きで保守する負担から解放されます。

第二に、ユーザーの質問を受けたLLMが、OpenUI Langをストリーミングで出力 します。 JSONのように「全部揃ってから描画」ではなく、トークンが届くたびにランタイムがUIを段階的に組み上げます。

第三に、結果として 操作できるUI（グラフ・表・フォーム）がユーザーに返ります。 文章で説明する代わりに、その場でダッシュボードが生成される、というわけです。 しかも返ってくるのは静止画像ではなく、実際に操作できるUI部品 です。 生成された表をソートしたり、フォームに入力して送信したり、グラフのフィルタを切り替えたり——AIが作ったUIに対して、ユーザーがそのままインタラクションできます。 ここが「AIに画像を生成させる」のとも「スクリーンショットを見せる」のとも決定的に違う点で、生成UIが“次のインターフェース”と呼ばれる理由です。 AIの出力が、読むだけのものから、触って使えるもの へと変わるわけです。

この「プロンプト自動生成 → Lang出力 → 段階描画」のループが、OpenUIの核心です。

ここで「システムプロンプトの自動生成」の重要性を補足します。 LLMにUIを出力させるとき、最大の難所は「モデルが、存在しない部品や、間違った書式を出力してしまう」ことです。 たとえば、用意していない pieChart3D のような部品を勝手に出してきたり、引数の名前を間違えたりすると、描画は失敗します。 OpenUIは、開発者が定義した部品ライブラリから 「使える部品の一覧と、その正しい書き方」をシステムプロンプトとして自動で組み立てる ため、LLMが“出してよいもの”の範囲を正確に把握できます。 これは、自由すぎるLLMの出力を、レンダリング可能な範囲にガードレールで収める仕組みでもあります。 部品ライブラリを更新すれば、プロンプトも自動で追従するため、「部品を足したのにプロンプトの更新を忘れて壊れる」といった事故も防げます。

4. 導入とコード（最小イメージ）

OpenUIはJavaScript/TypeScriptエコシステムのライブラリ群として提供されます。 インストールはnpm系で行います（パッケージ名はリポジトリの指定に従ってください）。

# 例: ランタイムとコア言語パッケージを導入
npm install @openui/react @openui/lang

Reactでの利用イメージは、概ね次のような形です。

// 概念イメージ：LLMの出力（OpenUI Lang）をストリーミング描画する
import { OpenUIRenderer, useGenerativeUI } from "@openui/react";

function Assistant() {
  const { stream } = useGenerativeUI({ endpoint: "/api/generate" });
  // stream: LLMが吐く OpenUI Lang のトークン列
  return <OpenUIRenderer stream={stream} />;  // 届くたびに段階描画
}

上記のように、クライアント側は「ストリームを受け取って描画する」だけのシンプルな構成になります。 LLMが何を返すか・どう描画するかという複雑さは、ランタイムと部品ライブラリが吸収してくれるため、アプリ開発者は“器”を置くだけで生成UIを組み込めます。

サーバ側では、部品ライブラリから生成したシステムプロンプト をLLMに渡し、OpenUI Langで応答させます。

// 概念イメージ：部品ライブラリ → システムプロンプト → LLM
import { buildSystemPrompt } from "@openui/lang";
const system = buildSystemPrompt(componentLibrary); // 何を出力してよいかを定義
// この system を付けて LLM に問い合わせ、OpenUI Lang をストリーミングで受け取る

※ パッケージ名・API名は概念を示すイメージです。実際の名前・使い方は公式リポジトリのREADMEとドキュメントを確認してください。 重要なのは「部品ライブラリを定義 → そこからプロンプトを自動生成 → LLMがLangで応答 → ランタイムが段階描画」という一連の流れです。

OpenUIが「マルチフレームワーク」である意義も補足しておきます。 公式によれば、Reactを中心に、Vue・Svelte、さらにメール用やブラウザバンドルにも対応するとされています。 これは、同じOpenUI Langの出力を、異なる描画ターゲットで再利用できる ことを意味します。 たとえば、Webアプリ（React）でもモバイル相当でも、あるいはAIが生成した内容をメールHTMLとして送る場合でも、LLM側の出力（Lang）は共通にできます。 「UIの意味（何を見せたいか）」と「描画の実装（どのフレームワークか）」を分離するこの設計は、生成UIを長く使ううえで効いてきます。 モデルが吐く“UIの設計図”を一度きりの使い捨てにせず、複数の出力先で活かせるからです。 さらに、メール対応があるのは実務的に大きく、AIが生成したダッシュボードを定期レポートとしてメール配信する、といったワークフローも視野に入ります。

5. 他ツールとの違い（AIアプリビルダー / 素のJSON）

立ち位置を整理します。

アプローチいつUIが決まるか出力形式用途
OpenUI実行時（毎回LLMが生成）OpenUI Lang（ストリーミング）AIの応答をUIで返す動的生成UI
Retool / v0 等のAIアプリビルダー開発時（生成後は固定）React等のコードアプリ/画面をAIで作る
素のJSON → 部品マッピング実行時JSON（冗長）自前実装（トークン非効率）
LLMのテキスト/Markdown実行時文章説明・会話（UIではない）

ここがOpenUIを理解する鍵です。 Retool やv0のようなAIアプリビルダーは「開発時に」UIを生成 し、その後は普通のアプリとして動きます。 一方 OpenUIは「実行時に」LLMがその場でUIを生成し続ける ためのインフラです。 ユーザーの質問に応じて、AIが毎回UIを組み立てて返す——この動的な生成UIを実装するのがOpenUIの役割です。

もう一つ重要な対比が、「素のJSON → 部品マッピング」を自前実装する方法との違いです。 実は、生成UIは専用言語なしでも作れます。 LLMにJSONで部品ツリーを書かせ、それを自分のコードで各コンポーネントにマッピングすればよいのです。 多くのチームが最初にこの方法に手を出しますが、すぐにトークンコスト、ストリーミングの難しさ、壊れた出力のハンドリング、プロンプト管理といった“地味だが重い”課題にぶつかります。 OpenUIは、この 「誰もが自前で再発明しがちな部分」を、最適化済みの言語・ランタイム・プロンプト生成としてまとめて提供 します。 つまりOpenUIの価値は、「JSONでもできることを、安く・速く・壊れにくく・標準的にできるようにした」ところにあります。 車輪の再発明を避けたい開発者にとって、これは大きな時間の節約になります。

「URLからサイトを生成する」OSSの Open Lovable なども“生成”という点で近縁ですが、OpenUIは AIアシスタントの応答そのものをUI化する という、より実行時寄りのレイヤを担います。

この「開発時」と「実行時」の違いは、何度強調してもしすぎることはありません。 AIアプリビルダーで作ったダッシュボードは、生成された瞬間に“完成品”として固定され、以後はそのまま動きます。 対してOpenUIで作るのは、「ユーザーが何を聞くか分からない」前提で、その都度AIが画面を組み立てる仕組みです。 たとえば社内データ分析アシスタントなら、ある社員は「地域別売上」を聞き、別の社員は「在庫の推移」を聞くかもしれません。 事前に全画面を用意するのは不可能ですが、生成UIなら、質問に応じてその場で最適な可視化を返せます。 この「事前に画面を設計しきれない、無限のバリエーションを持つUX」こそ、生成UIが本領を発揮する領域です。 逆に、画面のパターンが決まっているなら、わざわざ実行時生成にする必要はなく、AIアプリビルダーや通常の開発で十分です。 OpenUIを採用すべきかは、「UIのバリエーションが、事前に列挙できるか否か」で判断するのが実用的な指針になります。 言い換えれば、ユーザーの要求が型にはまらず、毎回違う見せ方が必要な“探索的”なプロダクトほど、生成UIの恩恵が大きくなります。 分析ツール、リサーチアシスタント、複雑なデータを扱う社内ツールなどが、その典型例です。 逆に、決まったフォームの入力画面や、固定レイアウトの管理画面のように“答えの形”があらかじめ決まっているものは、生成UIにする必要はありません。 適材適所を見極めることが、生成UIを過剰に使って複雑化させないコツになります。

6. 向き不向きと注意点

OpenUIは強力ですが、向き不向きがあります。

・向いている：AIアシスタント／社内ダッシュボード／データ探索ツールなど、AIの応答を操作可能なUIで返したい場面
・向いていない：単純なテキスト回答で十分なチャットボット（生成UIはオーバースペックになりがち）

導入時の注意点も押さえておきましょう。

・部品ライブラリの設計が肝：LLMが出力できるUIは、用意した部品の範囲。何を出させたいかを先に設計する
・プロンプトと検証：自動生成プロンプトに任せきりにせず、想定外のUIや壊れた出力への対処（フォールバック）を用意する
・セキュリティ：LLMが生成した内容をUIとして描画する以上、入力のサニタイズや権限の扱いに注意
・仕様の成熟度：新しい標準のため、APIや言語仕様は変わり得る。バージョン追従が必要
・モデル依存：生成UIの品質はLLMの能力に左右される。複雑なUIほど上位モデルが安定
・UI一貫性の担保：毎回生成するため、デザインの統一は部品ライブラリ側で固める必要がある

特に「UIの一貫性」は、生成UI特有の論点です。 人間がデザインした画面は、ボタンの形も余白も統一されています。 ところが、UIをLLMに毎回生成させると、放っておけば見た目が揺らぐ恐れがあります。 OpenUIが「部品ライブラリ」を中心に据えているのは、この問題への答えでもあります。 LLMが選べるのは“あらかじめデザインされた部品”だけ にしておけば、AIがどう組み合わせても、見た目とアクセシビリティの水準は部品側で担保されます。 つまり、生成の自由度（何を組み合わせるか）はLLMに、品質の保証（個々の部品の質）は開発者に、と責任を分担する設計です。 このあたりは、設計トークンやコンポーネント仕様で品質を固める考え方と共通しており、生成UIを実運用に乗せるうえで欠かせない発想になります。

まずは1画面の“生成ダッシュボード”から
いきなり全画面を生成UIにせず、「1つの質問に、グラフ＋表で答える」小さな生成ダッシュボードから作るのがおすすめ。部品ライブラリを最小構成で定義し、プロンプト自動生成→Lang出力→段階描画の一連を体験してから、対応部品とフレームワークを広げると、設計がぶれない。

まとめ

OpenUIは、LLMに「テキスト」ではなく「UI」を生成させる ための、MITライセンスのオープンソース標準です。

要点を整理すると次のようになります。

・「生成UI（Generative UI）」のオープン標準を掲げる（by Thesys）
・OpenUI Lang＝UI生成特化のストリーミング言語。JSONより最大67%少ないトークン
・React/Vue/Svelte等のランタイムと、チャート/フォーム/表の組み込み部品
・部品ライブラリからシステムプロンプトを自動生成し、LLMに正しく出力させる
・「開発時に作る」AIアプリビルダーと違い、「実行時に生成し続ける」インフラ
・採用判断の指針は「UIのバリエーションを事前に列挙できるか否か」。無限ならOpenUI、有限なら通常開発

結論
OpenUIの本質は「AIの応答そのものをUIにする」ことだ。チャットの次は、文章ではなく操作できるUIをその場で生成するUX——その実装を、トークン効率の良い専用言語とストリーミングランタイムで支える。まずは『1つの質問にグラフと表で答える』小さな生成ダッシュボードから試し、部品ライブラリの設計勘を掴むのが近道だ。AIネイティブなプロダクトを作る開発者にとって、押さえておく価値のある標準である。チャットUIの“次”を考えているなら、いま触れておいて損はない。

なお、生成UIはまだ発展途上の領域であり、OpenUIもその標準化を狙う有力な一手という段階です。 今後、対応モデルや部品エコシステム、ツールチェーンがどこまで広がるかが、この分野の本格普及を左右します。 本サイトでは引き続き、生成UIやAIネイティブなフロントエンドの動向を追っていきます。OpenUIに興味を持ったら、まず公式リポジトリのデモとサンプルに触れ、「LLMがUIを吐く」感覚を一度味わってみることをおすすめします。

参照ソース

・thesysdev/openui（公式GitHubリポジトリ）
・Thesys（OpenUI開発元）
・Retool新AIアプリビルダー（R2）徹底解説（本サイト）
・AIエージェントとは？仕組み・種類・代表的OSSフレームワーク【2026年版】（本サイト・ピラー）