そして、15kb のフラット JSON ストリーミングエンジンで「幻覚税」をどう解決したか。
2026 年に AI エージェントを構築しているなら、あなたも私が直面した壁と同じ壁にぶつかっているでしょう。
v0.dev のようなツールは、ジェネレーティブ UI の息をのむ可能性を私たちに示してきました。LLM が Tailwind クラスや Lucide アイコンを完備した美しくスタイリングされた React コンポーネントを難なく吐き出すのを見ると、魔法のように感じます。
しかし、その魔法を 本番 のエージェントに組み込もうとすると—特にローカルモデルを使ったり自律的なワークフローを構築したりする場合—その幻は粉々に砕けます。 「魔法」はすぐに「死の赤い画面」や膨らんだコンテキストウィンドウ、そして莫大なトークン料金の悪夢へと変わります。
大規模言語モデル（LLM）の根本的な性質を考えると、それは線形の逐次予測器です。LLM に深くネストされたコンポーネント階層を生成させること—複数の開始タグ、閉じ括弧、プロパの依存関係を数百行にわたって完璧にバランスさせることを要求する場合—私たちはそのアーキテクチャに対抗して作業しています。AST（抽象構文木）の深さが深くなるほど、モデルの注意喚起（アテンションリコール）は劣化します。このようなアーキテクチャの不一致は、構造的な失敗を不可避に保証します。
実行可能な React コードや深くネストされた JSON コードを Generative UI のために生成することは、未来ではありません。これは壊れやすく、費用のかかる行き止まりです。
ここに、その理由と、エージェント UI を実際に信頼できるものにするために必要なアーキテクチャ的パラダイムシフトがあります。
コード生成の「幻覚税」
LLM にリアルタイムで UI コンポーネント（例: JSX や Vue テンプレート）を生成させると、3 つの重大な方法で失敗させることになります:
1. AST の脆弱性（ひとつの括弧で全てが崩れる）
コードは構造的に容赦がありません。複雑なダッシュボードカードをレンダリングするには、LLM が深くネストされた 300 行の JSX をストリーミングするかもしれません。しかし、モデルがたった 一つ の欠落した閉じタグ </div> やプロパティオブジェクトのカンマを忘れた場合、どうなるでしょうか？
全体の抽象構文木（AST）がクラッシュします。フロントエンドのパーサは致命的なエラーをスローし、画面は白（あるいは赤）に、一瞬でユーザー体験が崩壊します。あなたは文字列補間でロシアンルーレットを演じているようなものです。
2. ネスト化のペナルティ（トークンの無駄遣い）
LLMs は本質的にシーケンス予測器です。深くネストされた構造を生成する際（JSX であっても、あるいは { \"type\": \"row\", \"children\": [ { \"type\": \"col\", \"children\": [...] } ] } のような巨大な JSON ツリーであっても）、モデルは深くなるほど重要な注意喚起を失います。
さらに、閉じタグ、インデントスペース、括弧といった数千もの構造文字に対して実際のお金を払っており、それらは意味的価値をほとんど持ちません。
3. レイテンシのボトルネック
完全なブロックが閉じられて検証されるまで、eval() を安全に使うことや、複雑なネストコードの段階的レンダリングを行うことはできません。これにより、瞬時の返却が完全に台無しになります。
