AirJellyのGenUIエンジンを構築した記録 — そしてLLMに自由度を与えるほど結果が悪化した理由。
Translated by AIこのブログは、AirJellyプロジェクトにおけるGenUIエンジンの実践的な探求から生まれたものです。私たちは理論から始めたわけではありません。正直かなりもどかしい実験から始めました。なぜLLMにUI生成の自由度を高く与えるほど、結果が悪くなったのか？
詳細に入る前に、GenUIが単なるデモの小技ではなく、真剣なエンジニアリング課題である理由を明確にしておく価値があります。Generative Interfaces for Language Modelsでは、SALT-NLP / StanfordのチームがGenUIと従来のテキストベースチャットの間でユーザー選好を比較しました。結論は明快です。AIシステムが構造化された情報密度の高いコンテンツを伝える必要がある場合、動的に生成されたインターフェースはテキストの壁よりもはるかに優れている可能性があります。
GenUIの波は2023年から2025年の間に加速しました。なぜなら二つの条件が同時に成熟したからです。LLMのコード生成能力が大幅に向上し、shadcn/uiやRadixのようなコンポーネントエコシステムがその上に構築できるほど安定したのです。これらの条件が整うと、ツールが自然に登場しました — Vercel v0は最も代表的な業界実装の一つです。
feat/genui-real-content-experimentブランチで一連の比較を行いました。従来のアプローチは固定レイアウトと統一されたコンポーネントで、洗練され予測可能でした。新しいアプローチはレイアウトをより柔軟にしましたが、見た目は乱雑になり、コンポーネントのスタイルは不統一になりました。
これは私たちの直感に反していました。モデルに自由度を与えるほど、制御を失い、視覚的な一貫性が悪化したのです。Gen-UI-Langの論文も同じ点を指摘しています。LLMに生のHTMLやJSXを要求すると、出力は冗長で脆く、壊れやすくなります。これはプロンプト品質の問題ではなく、LLMを最も得意ではない粒度まで押し上げてしまったことを意味します。
実験を通じて、ほぼすべてのGenUIシステムに当てはまる内的矛盾を特定しました。
LLMの自由度が高いほど、視覚的一貫性を保証するのが難しくなります。制約が強いほど、GenUIの意味は薄れます。
これはパラダイムに内在する構造的緊張であり、ある実装のバグではありません。すべてのGenUIシステムは、これら二つの力の間のどこかに足場を見つけなければなりません。そこで問いは非常に具体的になります。LLMの生成境界はどこで止めるべきか？
自分たちの答えを決める前に、他の人々が同じ問いにどうアプローチしてきたかを見るのは有益です。
v0はLLMを最深部まで進ませ、完全なReactコンポーネントコードを生成させます。その視覚的一貫性はshadcn/uiのセマンティックトークンシステムに由来します — 一貫性をライブラリのテーマに外注しているのです。コストは、生成ロジックがコンポーネントエコシステムと密結合になるため、shadcn/ui + Next.js + Vercelスタックから離れると実際の摩擦が生じることです。
<Card className={cn("flex flex-col",
plan.recommended && "border-primary shadow-lg scale-105"
)}>SALT-NLP / Stanfordのアプローチは、自然言語とUIコードの間に構造化された中間表現を挿入します。二つのレベルがあります。高レベルのインタラクションフロー（ユーザーパスとタスク段階の有向グラフ）と、低レベルの有限状態機械（各コンポーネントの状態とイベント応答）です。最終出力は依然としてHTML、CSS、JavaScriptです — 表現はガイドレールであり、目的地ではありません。
Gen-UI-Langは専用のDSLを設計し、LLMが構造化されたノード記述のみを出力するようにします。ノード構造は明示的で浅く、一貫しています — まさにLLMが確実に生成できるものです。HTMLを直接生成する場合と比べて、トークン使用量が65.3%削減され、安定性が向上し、同じ記述からHTML、React JSX、またはGradioにレンダリングできます。
genui(
row(
text("Sales Overview"),
btn("Load", on_load=lambda: get_graph(2001, 2002))
),
chart(type="line", data="sales_q4"),
)三つのアプローチはすべてLLMをレンダリング層から遠ざけ、上へと押し上げます。違いはどこで止めるかだけです。私たちはそれらすべてよりも高く止めることを選びました。プロダクトセマンティクス層です。
LLMはrowやbtnのような汎用UIノードを出力しません。プロダクトの概念を出力します — 「これはタスクサマリーカードで、情報密度が高く、今日のカレンダーをソースとしている」。どのコンポーネントをレンダリングし、どうレイアウトするかは、完全にコンポーネントライブラリが決定します — LLMではありません。
LLMの生成自由度を緩めると、視覚的な結果は悪化しました。LLMがレンダリング層に近づくほど、そのランダム性のコストは高くなります。
ブラウザはページのJavaScriptにピクセルを直接制御させません。制御されたDOM記述を受け入れ、エンジンがピクセルを決定します。GenUIエンジンも同じように動作すべきです。
OpenAIは2024年にStructured Outputsを出荷し、特にフォーマットのドリフトと戦いました。出力がレンダリング層に近いほど、フォーマットエラーのコストは高くなります。
プロダクトセマンティクス層で止めれば、コンポーネントライブラリはプラグ可能なレンダリングバックエンドになります — セマンティック層に触れることなく、明日デザインシステムを交換できます。
複雑なGenUIPagerコンポーネントをデバッグする中で、単一のLLMパスではコンテンツ品質とレイアウト品質を同時に最適化するのが難しいことが分かりました。そこから二ラウンドアーキテクチャという仮説に至りました。
First-round LLM: content orchestration + page-structure decisions
(product semantics layer)
↓
Second-round LLM / component library: concrete rendering decisions動機は合理的です。コンテンツオーケストレーションとレンダリングは二つの異なる認知タスクであり、それらを単一パスに押し込めると互いに干渉する可能性があります。
しかし正直に言わなければなりません。これは単なる仮説であり、十分に検証されていません。
ここに載せているのは、探求する価値のある方向性を示しているからであり、確定した結論だからではありません。
普遍的に正しい粒度の選択はありません。製品の視覚的不一貫性への許容度、コンポーネントライブラリの想定ライフサイクル、生成コンテンツの構造化度合いに依存します。
| アプローチ | LLMの出力先 | 一貫性の保証方法 | ライブラリ交換可能？ | 適したシナリオ |
|---|---|---|---|---|
| Vercel v0 | コンポーネントコード層 | shadcn/uiセマンティックトークン | 不可、密結合 | Vercelエコシステム内での迅速なプロトタイピング |
| Gen-UI-Lang | 汎用UIインテント層 | マルチターゲットレンダラー | 可、フレームワーク非依存 | クロスフレームワークのプロトタイピング、効率優先のワークフロー |
| arXivのアプローチ | HTML / CSS / JS | 構造化中間表現をガイドレールとして | 場合による | インタラクションの複雑度が高いシナリオ |
| AirJelly | プロダクトセマンティクス層 | コンポーネントライブラリがレンダリングを完全に所有 | 可、プラグ可能 | プロダクトUIの一貫性への要求が高いアプリケーション |
製品の視覚的不一貫性への許容度が低い場合、粒度は高く、プロダクトセマンティクスに近づけるべきです。コンポーネントライブラリが進化または交換される可能性が高い場合も、さらに高くします。そして生成コンテンツが高度に構造化されている場合、より高いレベルでセマンティックに記述する方が適しています。
最大の学びは、正しい答えが見つかったことではありません。問いを明確にできたことです。GenUIとは、LLMにインターフェースを描かせることではありません。LLMとレンダリングシステムの間で、責任を明確に分担する設計を行うことです。
粒度の選択がその境界線をどこに引くかを決め、境界線をどこに引くかがシステムの保守性、視覚的安定性、長期的な進化能力を決めます。
2025年10月、W3C Design Tokens Community Groupは安定版のDesign Tokens 2025.10仕様を公開しました。これは、セマンティクスとビジュアルを分離することがエンジニアリングの標準になりつつある兆しです。GenUIにおける粒度の問題は、その同じトレンドがAI生成インターフェースの内部に現れているものです。
私たちはまだ道の途中です。似たようなことを探求している方がいれば、ぜひ話しましょう。
AirJellyチームからの続き →