AIがフロントエンドコードを書く——この兩年間、これはいつも微妙な存在だった。
GPTやClaudeに説明を与えると、HTMLとTailwindが出力され、一見それなりに見える。でもコンポーネント間に状態同期がなく、アクセシビリティもなく、レスポンシブブレークポイントの細かい制御もない。使えるけど、本番環境には置けない。
thesysdev/openuiが解決しようとしているのは「AIがUIを書けるか」ではない。「AIがUIを書くとき、どんなフォーマットを使うべきか」だ。
問題は生成能力じゃない。出力フォーマットだ
現在すべてのAIコーディングツールがUIを生成する方法は、基本的にテキストからテキストへの変換だ。プロンプト → HTML/JSX → レンダリング。このパイプラインには三つの構造的な欠陥がある。
第一に、検証不可能。AIが出力するのはコードの文字列で、動かして確認するしかない。静的チェック、差分比較、ロールバックができる中間表現がない。
第二に、組み合わせ不可能。ツールAが生成したボタンとツールBが生成したフォームを一緒に置くと、スタイルの衝突は日常茶飯事。共有のUI記述層がないからだ。
第三に、反復不可能。AIに「青を赤に変えて」と言うと、コンポーネント全体を再生成する。増分更新？存在しない。
OpenUIのアプローチは、UI記述をコード文字列から分離し、構造化された機械可読の中間層を定義することだ。APIドキュメントにおけるJSON Schemaのように、OpenUIはジェネラティブUIのプロトコル層になりたい。
どんなものか
リポジトリのコアは、コンポーネント、プロパティ、イベント、スタイル制約をASTのような木構造で表現する宣言的UI記述フォーマットだ。AIモデルは直接JSXやHTMLを出力する必要はなく、OpenUI形式の記述を出力し、レンダリングエンジンがターゲットプラットフォームの具体的な実装に変換する。
このプロジェクトはまだ初期段階（4,523スター、309フォーク）で、READMEのデモもまだシンプルだ。しかし、解決しようとしている問題は正しい——AIコーディングツールは「コードを書けるか」から「保守可能なコードを書けるか」の段階に入っており、UI層はこのチェーンの中で最後に標準化されていない領域だ。
誰が気にすべきか
Cursor、Claude Code、Copilotを使ってフロントエンドを書いているなら、この方向は追う価値がある。今日すぐに使えるからではなく、主要なコーディングツールが類似の標準を採用したとき、プロンプトのワークフローが「説明＋試行錯誤」から「説明 → 構造化出力 → 自動レンダリング」に変わるからだ。
フロントエンドエンジニアの役割も変わる：コンポーネントを手書きするのではなく、OpenUI記述層の制約ルールを定義し、AIがその範囲内で生成するようにする。CSSの手書きからTailwind、そしてCSS-in-JSへの移行に似ている——ただし今回の推進力はAIだ。
リスク
プロジェクトはv0段階で、プロトコルは安定しておらず、コミュニティも小さい。最大のリスクは明白だ——OpenAIやAnthropicが独自のクローズドなジェネラティブUIフォーマットを作ったら、オープンスタンダードは迂回される可能性がある。歴史的に、「標準 vs プラットフォーム」の戦いでは、プラットフォームが勝つことが多い。
しかしv0段階において、少なくとも方向性は正しい。
はじめ方
git clone https://github.com/thesysdev/openui.git
cd openui
# サンプルとドキュメントを確認
リポジトリには基本的なCLIツールとレンダリングのサンプルがある。本番環境ですぐに使えるとは思わないでほしいが、AIコーディング関連のツールチェーンを作っているなら、そのプロトコル設計を見るのは参考になる。
主な情報源：