OpenUI を採用すべきか: モデル出力を UI としてストリーミングするための言語とレンダラ

モデルに UI を書かせるときの本当の障害は何か

LLM に画面を出させる方法は大きく二つある。HTML や JSX をそのまま生成させて dangerouslySetInnerHTML などで流し込むか、JSON でウィジェット記述を吐かせてクライアントで解釈するかである。前者は任意のマークアップが通るため、生成物の検証もスタイルの統制も効かない。後者は安全だが、ストリーミングとの相性が悪い。JSON は途中まで届いても閉じ括弧が来るまでパースできず、体感は「待ってから一気に描画」になる。

OpenUI が解こうとしているのはこの二点である。README は OpenUI Lang を「a compact, streaming-first language for structured UI generation」と説明しており、ストリーミングを後付けの機能ではなく言語設計の前提に置いている。対象読者は、アシスタントやコパイロットのようにモデル出力が画面そのものになるプロダクトを作る TypeScript の開発者である。テキストを Markdown として描くだけのチャットなら、この層は不要だ。

コンポーネント定義からシステムプロンプトを生成するという発想

OpenUI の設計で最も特徴的なのは、モデルに渡す指示を手書きしない点である。README のフロー図は Component Library → System Prompt → LLM → OpenUI Lang Stream → Renderer → Live UI という一本の流れを示している。開発者はレンダリング可能なコンポーネントを定義し、そこからシステムプロンプトを生成し、それをモデルに送る。モデルが返すのは OpenUI Lang のストリームで、Renderer が到着順に解釈して React ツリーを更新する。

この順序には実務上の意味がある。プロンプトとレンダラが同じコンポーネント定義を参照するため、モデルが存在しないコンポーネント名を呼ぶ余地が構造的に小さくなる。逆に言えば、コンポーネント集合を絞るほど生成の自由度は下がる。何を許可するかがそのままプロダクトの表現力を決めるので、ライブラリ設計がプロンプト設計と同一の作業になる。

パッケージ分割が示す想定アーキテクチャ

リポジトリは単一の巨大パッケージではなく、責務ごとに切られている。@openuidev/lang-core は React にも Vue にも Svelte にも依存しないパーサ、プロンプト生成、ランタイム評価、型の層である。@openuidev/react-lang が React 側のレンダリングランタイム、@openuidev/react-headless がチャット状態とストリーミングアダプタ、メッセージ形式の変換を担う。@openuidev/react-ui はレイアウトと UI プリミティブ、そして組み込みコンポーネントライブラリ二種を同梱する層で、README はこれを「Fastest path to a full React chat experience」と位置づけている。

サーバ側には @openuidev/langchain があり、LangChain と LangGraph のエージェント向けのトランスフォーマとサーバヘルパーを提供し、AG-UI 経由で OpenUI をストリーミングする。React 以外では @openuidev/vue-lang と @openuidev/svelte-lang が用意されているが、README の表現では React が official support、他は community-supported integrations である。この差はサポート範囲の差として読むべきで、Vue や Svelte を主軸にするなら lang-core の上に自前のランタイムを書く前提で見積もったほうがよい。

動かすまでの手順と、確認しておきたい設定

README の Quick Start は CLI で雛形を作る。npx @openuidev/cli@latest create --name genui-chat-app を実行し、生成されたディレクトリに移動して .env に OPENAI_API_KEY=sk-your-key-here を書き、npm run dev で起動する。この雛形にはストリーミング、組み込み UI、OpenUI Lang のサポートが最初から入っていると README は説明している。

注意したいのは、この手順が OpenAI のキーを前提にしている点である。README には他のプロバイダ向けの設定例も、キー名の一覧も載っていない。別のモデルを使う場合は雛形の中のクライアント初期化を自分で読み替える必要があり、その作業量は手元では確認できていない。また、雛形をそのまま本番に持ち込む前に、生成されたシステムプロンプトがどのコンポーネントを許可しているかを読んでおくべきである。プロンプトはコンポーネント定義から機械的に生成されるので、ライブラリを増やせばプロンプトも黙って長くなる。

トークン削減という主張をどう扱うか

README は OpenUI Lang が JSON より最大 67% 少ないトークンで済むと述べている。ただしこれがどのモデルのトークナイザで、どの程度の複雑さの UI を、どのコンポーネント集合で測ったのかは与えられた資料からは分からない。削減率はスキーマの冗長さに強く依存するので、自分のコンポーネント集合で測り直すまで採用判断の根拠にはしないほうがよい。

とはいえ方向性自体は筋が通っている。JSON はキー名を毎回繰り返し、ストリーミング途中の中間状態が不正な構文になる。専用のコンパクトな記法なら、キーの反復を減らせるうえ、途中まで届いた断片をそのまま部分的な UI として解釈できる。削減率の数字よりも、途中状態が意味を持つという性質のほうが実務では効く。

向かない場面と、代わりの選択肢

OpenUI が不要になるのは、生成 UI の見た目を完全に固定したい場合である。モデルに選ばせる余地を残す設計なので、レイアウトの揺れは原理的に残る。また、モデル出力をテキストとして読ませるだけの用途では、パーサもレンダラも持ち込む理由がない。

代替として素直なのは Vercel AI SDK のストリーミングと、JSON Schema による構造化出力の組み合わせである。違いは明確で、あちらはモデルに JSON を吐かせてアプリ側で解釈する。スキーマ検証は強力だが、ストリーミング中は完全な JSON が揃うまで描画できないため、部分描画を自分で組み立てる必要がある。OpenUI は部分描画を言語仕様の側に寄せ、プロンプト生成までを一つのパッケージ群で賄う。既存の JSON ベースのパイプラインがすでに安定していて、途中描画を諦めているなら、乗り換える動機は薄い。

ライセンスと維持コストの見取り図

ライセンスは MIT で、リポジトリの LICENSE ファイルへのバッジが README に貼られている。MIT であれば改変と再配布の条件は緩く、商用プロダクトへの組み込みを妨げる条項は通常含まれない。ただしこれは法的助言ではなく、実際の条項は各自で LICENSE を読む必要がある。

維持コストの面で気に留めておきたいのは、パッケージが 8 つ以上に分かれていることだ。lang-core の型に追従する必要があるのは react-lang、react-headless、react-ui、そして Vue と Svelte のバインディングである。コアの言語仕様が動けば複数のバインディングが追随する構図なので、依存するパッケージのバージョンを揃えて更新する運用が要る。README にはリリースノートが添付されておらず、破壊的変更の頻度は手元の資料からは判断できない。採用前に、利用するパッケージのバージョンを固定し、lang-core の更新を追う担当を決めておくのが現実的である。

編集部の結論

React でチャットやコパイロットを組んでおり、モデルに自由な HTML を書かせるのではなく、許可したコンポーネント集合の中だけで UI を生成させたいチームに向く。逆に、生成 UI の見た目を完全に固定したい場合や、React 以外を主軸にしていて Vue / Svelte バインディングの成熟度を前提にしたい場合は、@openuidev/lang-core だけを使って自前レンダラを書く覚悟が必要になる。採用前に確認すべきは 3 点で、第一に npx @openuidev/cli@latest create で生成される雛形が自分のモデルプロバイダで動くか、第二に OpenUI Lang の「up to 67% fewer tokens than JSON」という主張が自分のコンポーネント集合でも成立するか、第三に @openuidev/langchain の AG-UI 経由ストリーミングが既存のサーバ構成に収まるかである。README にリリースノートが添付されていないため、バージョン間の破壊的変更の履歴は手元では確認できていない。

公式情報源

1. Issues
2. License: MIT
3. Project website
4. README
5. thesysdev/openui on GitHub