OpenUIとは？Generative UIを実装するフレームワークの仕組みと選び方【2026年】

AIがチャットの応答の中で、テキストではなくフォームやダッシュボードそのものを生成する「Generative UI」が、実装フェーズに入ってきました。その実現手段として注目されるのが、thesys社が公開するフレームワークOpenUIです。OpenUIはJSONを書かせる代わりに、OpenUI言語という行指向の専用言語をAIに生成させ、登録済みのReactコンポーネントへ安全にマッピングして描画します。この記事では、OpenUIの仕組みと4つの構成要素、JSONを使わない理由とトークン効率、Vercel AI SDK・json-render・A2UI・MCP Appsなど主要フレームワークとの違い、そして自社の開発で採用すべきか・避けるべきかの判断基準までを整理します。

Generative UI基盤OpenUIの結論：採用可否を分ける要点

OpenUIは、AIにOpenUI言語という行指向のDSLを出力させ、自分で登録したコンポーネントだけにマッピングして描画する「フルスタックのGenerative UIフレームワーク」です。公式サイトのベンチマークでは、同じUIをJSONで生成した場合に14.2秒かかる描画が4.9秒で完了し、トークン量は最大67%削減されたと報告されています。結論として、自社のUIコンポーネント資産があり、ユーザーの指示に応じて毎回異なる対話的UIを動的に組み立てたいプロダクトには有力な選択肢です。

逆に、画面構成が固定の管理画面や、入力項目が決まった1画面完結のフォームでは、OpenUIは過剰になります。その場合はカタログ型JSONを使うjson-renderやA2UI、あるいはNext.js前提で手軽なVercel AI SDKのGenerative UI機能で十分です。OpenUIは出力品質の高いLLMを前提とするため、APIのコストとレイテンシ、日本語UIの崩れの検証が導入前の必須項目になります。

まずはnpx @openuidev/cli@latest createでNext.jsの雛形を起動し、自社の代表的な1ユースケースで他方式と比較検証してから本採用を決めるのが安全です。

Generative UIにおけるOpenUIの位置づけと同名プロジェクトの違い

Generative UIとは、AIエージェントがチャットの応答の中でUIそのものを生成し、ユーザーの理解やインタラクションを助ける機能の総称です。OpenUIはその実装を支えるフレームワークにあたります。

Generative UIが従来のテキスト応答と固定UIを置き換える理由

従来のAIチャットは、回答をMarkdownのテキストで返すか、あらかじめ用意した固定UIを表示するかのどちらかでした。テキストは操作できず、固定UIは会話の文脈に合わせて変形できません。Generative UIはこの関係を反転させ、AIが用途に合わせてコンポーネントを選び・設定し・組み合わせて、その場限りの画面を構成します。住宅ローンの金利を尋ねたら段落ではなく調整可能な計算ウィジェットが返る、という体験がわかりやすい例です。OpenUIはこの「AIがインターフェースを構成する」処理を、安全性とトークン効率の面から成立させることを狙っています。

thesys製OpenUI・wandb製open-ui・SAP OpenUI5の混同を避ける整理

「OpenUI」で検索すると、まったく別の3つのプロジェクトが混在します。混同したまま技術選定を進めると要件と実装がずれるため、最初に切り分けておきます。

本記事が扱うのは、ドメインopenui.comで公開され「The Open Standard for Generative UI」を掲げるthesys製のOpenUIです。コアランタイム・UIライブラリ・チャット画面までを含むフルスタック構成で、特定のJSフレームワークに依存しない言語層を別パッケージとして切り出している点が、単なるHTML生成ツールとの大きな違いです。

OpenUIを支える4つの構成要素とOpenUI言語による生成の仕組み

OpenUIは「AIの出力」を「描画されたUI」に変換するまでを、役割の異なる4つの部品で分担します。この分担を理解すると、どこをカスタマイズすれば自社要件に合うかが見えてきます。

ライブラリ・プロンプト生成・パーサー・レンダラーの4要素の分担

4要素はそれぞれ独立した責務を持ちます。

• ライブラリ：ZodスキーマとReactコンポーネントで「AIが使ってよい部品とProps」を定義する
• プロンプトジェネレーター：ライブラリからシステムプロンプトを生成し、有効なOpenUI言語だけを出力するようAIに指示する
• パーサー：AIの出力を型付きの要素ツリーに変換し、ライブラリのスキーマで妥当性を検証する
• レンダラー：要素ツリーをReactコンポーネントへマッピングし、ストリーミング中も段階的に描画する

カスタムコンポーネントはdefineComponent()で定義し、createLibrary()でライブラリに束ねます。最短で動かしたいときは<FullScreen>、独自のヘッダーや複数会話の管理など自由度が要るときは描画専任の<Renderer>を直接使う、という使い分けが基本です。

root起点の行指向構文とコンポーネント限定による安全設計

OpenUI言語はidentifier = Expressionという1行1代入の構文を持ち、必ずroot = Stack(...)を起点に組み立てます。引数は名前ではなく順序で渡す位置指定で、定義が届く前に参照された要素はスケルトン表示で待ってから埋まります。テーブルの絞り込みなら@Filter、件数表示なら@Count、バックエンド連携はQuery()とMutation()を@Runで実行する、といった具合に、UIロジックまで言語側で表現できます。安全性の要は「AIが生成できるのは登録済みコンポーネントだけ」という制約です。未登録や名前を取り違えたコンポーネントは描画時に破棄されるため、自由記述のスクリプトを生成させる方式に比べ、ブランド崩れや危険なコード混入のリスクを構造的に抑えられます。

JSONを使わない理由とトークン67%削減を支える行指向設計

OpenUIの設計判断で最も特徴的なのが、UIの表現にJSONを使わない点です。なぜ専用言語を新たに作ったのかは、JSONをLLMでストリーミングしたときの弱点を見ると理解できます。

JSONがLLMのUI生成で抱えるトークン肥大とストリーミング非対応

JSONは"component""props""children"といったキーを要素ごとに繰り返すため、UIが複雑になるほどトークンを浪費します。トークン量はそのままAPIコストとレイテンシに跳ね返ります。さらにJSONは構造全体が閉じて初めて妥当になる形式で、途中まで届いた段階では壊れたオブジェクトにしかならず、ストリーミングで「届いた所から描画する」用途と相性が良くありません。OpenUI言語はこの2つを同時に解くために、キーの繰り返しを排した簡潔な位置指定構文と、1行ごとに意味が確定する行指向構造を採用しています。

公式ベンチの4.9秒対14.2秒が示す行指向＋ストリーミングの効果

公式サイトは、同一UIを毎秒60トークンでストリーミングした比較を公開しています。JSONが14.2秒かかったのに対しOpenUI言語は4.9秒で完了し、トークンは65%少なく、上限では最大67%の削減と報告されています。効果は速度だけではありません。行指向構造のため、AIがroot = Stack(...)を最初の1行に出した瞬間から外枠が描画され、続く行が届くたびにカードや表が埋まっていきます。完成を待つ「待ち時間」が体感上の「組み上がっていく時間」に変わるため、同じ生成時間でも体験が大きく異なります。なお、この効率はOpenAI・Anthropic・Geminiなどモデルを問わず効くよう、言語層がLLM非依存に設計されています。

OpenUIと主要Generative UIフレームワーク5種の方式比較

Generative UIのフレームワークは乱立気味で、名前だけでは違いがわかりません。判断軸は「AIに何を生成させ、どう安全に描画するか」です。代表的な5方式を並べます。

OpenUI・Vercel AI SDK・json-render・A2UI・MCP Appsの方式比較

OpenUIの立ち位置は「自由記述のHTMLほど危険でなく、固定カタログのJSONほど冗長でない」中間です。JSONカタログ型より表現の柔軟性が高く、HTML実行型より安全側に倒れています。

「AIに何を生成させるか」で分かれる3つの設計アプローチ

5方式は突き詰めると3つの思想に整理できます。第一に、UI構造をフロントエンド側で持ちAIはツールを選ぶだけのアプローチ。第二に、AIにカタログ準拠のJSONや専用言語を出させてクライアントが組み立てるアプローチで、json-render・A2UI・OpenUIがここに入ります。第三に、MCPサーバーが用意したHTMLをiframeで埋め込むオープンエンド型です。Vercelの方式はReact Server Componentsをストリーミング配信する独自路線で、Next.jsとの統合が深いぶん他環境への持ち出しは難しくなります。どの思想を採るかは、UIの自由度をどこまでAIに委ねるかという要件で決まります。

iframe実行型CopilotKitとの表現力・安全性トレードオフ

CopilotKitのOpen Generative UIは、AIにHTML・CSS・JavaScript一式を生成させ、サンドボックス化したiframeの中で実行します。アルゴリズムの可視化や3Dアニメーションまで作れる表現力が魅力ですが、公式も「高性能なモデルが必須」と明言しており、弱いモデルでは破綻しやすいのが弱点です。対してOpenUIは出力を登録部品に限定するぶん表現の上限は下がりますが、その制約こそがモデル依存度を下げ、出力の予測可能性を高めます。「何でも描けるが不安定」か「描ける範囲は決めるが安定」か、というのが両者の本質的なトレードオフです。

OpenUIを採用すべき開発と過剰になる開発の判断基準

ここからは立場を明確にします。OpenUIは万能ではなく、効く開発とそうでない開発がはっきり分かれます。

自社UIライブラリと動的UI量産が前提のときOpenUIが効く条件

OpenUIが投資に見合うのは、次の条件が重なるときです。デザインシステムやコンポーネント資産が既にあり、それをAIに「制約付きの部品パレット」として渡したい。会話の文脈に応じて、フォーム・表・ダッシュボードなど構成の異なるUIを毎回その場で出し分けたい。そしてストリーミングによる体感速度がプロダクト価値に直結する。社内コパイロットや、問い合わせ内容に応じて操作画面が変わるサポートアシスタントなどが典型です。逆に言えば、これらが揃わないなら他方式の方が費用対効果は高くなります。

静的管理画面や単一フォームでOpenUIが過剰になる理由

採用を見送るべき場面も明確です。画面構成が固定で、AIに変形させる必要がない管理画面やランディングページ。入力項目が決まっていて分岐の少ない単一フォーム。これらにOpenUIを使うと、DSLの学習コスト・LLMのAPI料金・生成のばらつきという三重の負担だけが残り、得るものがほとんどありません。固定UIは普通にReactで実装すればよく、フォーム程度の動的化なら@openuidev/react-uiのプリセットや、より軽量なVercel AI SDKで足ります。「AIに毎回作らせる必要が本当にあるか」を最初に問うのが、過剰投資を避ける分岐点です。

高性能LLM前提と日本語UI崩れなど潰すべき失敗パターン

導入前に潰しておくべき失敗パターンが3つあります。1つ目は、安価で低性能なモデルを使い、生成されるOpenUI言語の品質が安定しないケース。OpenUIは自由HTML型より頑健とはいえ、複雑なUIでは出力品質の高いモデルが前提です。2つ目は、英語想定のコンポーネントに日本語の長いラベルを流し込み、レイアウトが崩れるケースです。日本語UIでは折り返しと列幅を実機で確認し、英語前提の固定幅を上書きしておきます。3つ目は、生成のたびに微妙に異なるUIが出てユーザーが混乱するケースで、rootの固定やコンポーネントのグループ化で出力を制約しておく必要があります。

OpenUI導入の始め方と業務システム開発で押さえる前提

最後に、実際に評価・導入する際の手順と、受託や業務システム開発で見落としやすい前提を押さえます。

CLIによるNext.js雛形生成からローカル起動までの手順

評価環境はCLIで数分です。

1. npx @openuidev/cli@latest create --name my-openui-appでNext.jsベースの雛形を生成する
2. 生成された.envにOPENAI_API_KEYなどLLMのAPIキーを設定する
3. npm run devで起動し、http://localhost:3000で「お問い合わせフォームを表示して」と入力して動作を確認する

雛形には@openuidev/react-lang（コアランタイム）、@openuidev/react-headless（チャット状態管理）、@openuidev/react-ui（プリセット部品）が含まれます。Reactを使わない場合でも、フレームワーク非依存の@openuidev/lang-coreや、Vue・Svelte向けのランタイム、ビルド不要で読み込めるbrowser-bundleが用意されており、既存スタックに後付けで載せやすい構成になっています。

対応LLM・APIコスト・保守性で決まる業務開発の前提条件

受託・業務システムに組み込む判断では、技術以外の前提が効いてきます。コスト面では、UIを生成するたびにLLMのトークンを消費するため、月間の生成回数からAPI料金を試算しておくべきです。OpenUIのトークン効率はこの試算を有利にしますが、ゼロにはなりません。セキュリティ面では、登録部品への限定で危険コードは抑えられる一方、Query()やMutation()でバックエンドを叩く以上、認可とレート制限はアプリ側の責任です。保守面では、OpenUI言語のバージョン（記事時点で仕様はv0.5系）に追従するメンテナンス体制が要ります。これらを満たせる体制があるかが、業務開発で採るべきかどうかの最終的な分かれ目です。

OpenUIとGenerative UIに関するよくある質問

OpenUIの検討時に検索されやすい疑問を、混同しやすい点を中心にまとめます。

OpenUIはwandbのopen-uiやSAPのOpenUI5と同じものですか？

いずれも別物です。本記事のOpenUI（openui.com）はthesys製のGenerative UIフレームワーク、wandbのopen-uiは説明文からHTMLを作る開発補助ツール、OpenUI5はSAPの業務アプリ向けUI5フレームワークです。Generative UIの文脈で語られるのはthesys製のOpenUIだけなので、リポジトリやドメインで取り違えないよう確認してください。

OpenUIは無料で使えますか？費用はどこにかかりますか？

OpenUI自体はオープンソースとして公開されており、ライブラリの利用料はかかりません。実費が発生するのはUI生成に使うLLMのAPI料金で、生成回数とモデルの単価に比例します。OpenUI言語はJSONよりトークン消費が少ないため、同じUIでもAPIコストを抑えやすい設計です。

OpenUIはどのLLMで使えますか？特定のモデルが必要ですか？

LLM非依存に設計されており、OpenAI・Anthropic・Gemini・Mistralなど主要プロバイダで利用できます。ただし複雑なUIを安定生成するには出力品質の高いモデルが前提で、低性能モデルでは生成のばらつきが増えます。プロバイダの切り替えはストリーミングアダプターの差し替えで対応します。

Vercel AI SDKのGenerative UIやv0と何が違いますか？

役割が異なります。v0は設計・実装時にプロンプトからUIコードを生成する開発支援ツール、Vercel AI SDKは実行時にReact Server Componentsをストリーミングする方式、OpenUIは実行時に専用言語をAIに出させて登録部品へマッピングする方式です。Next.jsに寄せるならVercel系、UIライブラリを問わず制約付きで安全に生成したいならOpenUIが向きます。

Reactを使っていなくてもOpenUIは導入できますか？

導入できます。コア機能はフレームワーク非依存の@openuidev/lang-coreに切り出されており、Vue向けのvue-lang、Svelte向けのsvelte-lang、ビルド不要でscriptタグから読み込むbrowser-bundleが提供されています。既存のReact以外のフロントエンドにも後付けで組み込めます。

関連記事

• コード生成AIの解説記事：実行時にUIを生成するOpenUIと、実装段階でコードを生成するAIの違いを理解する助けになります
• Figma MCPの解説記事：デザインからコードへつなぐMCP活用の観点で、AIとUIの関わり方を比較できます
• Vercelの解説記事：v0やAI SDKなどVercelのGenerative UI関連サービスの全体像を把握できます