TL;DR
- ユーザーはその場のノリで要望を出す
- ブラウザに載っているLLM（Web-LLM）は要望をGraphQLのクエリに変換する
- サーバーはJSONを返す
- ハンサムなブLLMは、ユーザーがノリで出した要望に沿うようJSONに色をつける
今回のデモ
こちらで試せます。
それなりのスペック、かつWebGPUが有効なブラウザで開くことをおすすめします。
JSON色付け係のおれら
つまりフロントエンドがやってきたことは
- ボタンプッシュやなんかをトリガーに事前に決めたユーザーの要望にしたがったJSONを投げる
- その結果（JSONです）を受け取る
- 色をつけてユーザーに見せてあげる
これだ。
いうは易しで、「事前に決めたユーザーの要望」っていうのをまともにできる人間は5%にも満たないから美味しいご飯を食べていられたわけだ。あとまぁJSONに色をつけられる人間も少なかった。
時は流れ2026年、小型のLLMが超発達を遂げており、中にはブラウザ上で動くものまで出てきた。
俺らの仕事はもう、ない。（あります）
フロントエンド、死す
これからの時代、UIはもういらなくなる。たぶん。
必要なものは要件のみ。
UIはAIが出す。
クエリもAIが発行する。
集計もAIが。
ビジュアライゼーションもAIがやるんだ。
たぶん。
仕組み
web-llmを使い、適当な軽量LLM（今回はqwen3.5 smallを選択）をロードします。
サーバーはモックであり、ブラウザ上で完結しているためデータが外に漏れることはありません。プロンプトインジェクションされても漏れるデータはありません。そもそもそんな賢くありません。
- ユーザーは欲しいデータを言う（書く）
- （planQueryフェーズ）エッジくんが自然言語からクエリを生成してサーバーに投げ
- （planTransformフェーズ）自然言語から適切な集計（map, filter, reduce...）のDSL構築
- （planVisualizationフェーズ）自然言語から適切な表示を判断し、集計結果を流し込む
- ユーザーは喜ぶ
今回は真面目にやってるけど、全てを度外視してevalを濫用すればあらゆるものが柔軟に表示できますよ（良い子は真似しないでね）。
あるいはServiceWorkerからRSCみたいにある程度ルールで縛ったコンポーネントを返すのでもいいかもしれない。
所感
実際に作る前の予想
いうて小型モデルだからまともなGraphQLやJSON吐ければ御の字やね
実際に作ってみたあと
動くやん！！！！！！！！！！！
なお動きは遅い
実用性について
今回試してみて、全てのフロントエンドを消滅させる計画には程遠いけど、ネタ企画と切り捨てるには惜しいキラメキを感じた。
このデモのように、用途や渡すスキーマを絞って活用する分には面白い用途がでてくるのではないか？
GraphQLや可視化がある種のハーネスとして機能しており、2B程度の小規模モデルが驚くほど賢く働いてくれる。
いまやってるようなことはChatGPTやClaudeにやらせればもっと大規模で賢くて無限に柔軟なものができる。
でもやらない、金が死ぬほどかかるからだ。
その金で要件を固めてアプリをリリースしたほうが安い。
そもそもユーザーが見てるデータを全部サーバーに投げまくるのは色んな観点であまりにも危険すぎる。
しかしエッジLLMはファッキン無料。
しかもプライバシーも完璧。
みんな大規模モデルの進化にだけ注目しがちだけど、UXを変えるのはエッジで動く小型省電力モデルの進歩だと僕は最初からずっとおもっており、少なくともQwen3.5 smallはその目論見に可能性の光をみせてくれた。
その他、実装の細かいところについて
ServiceWorkerを使ってくれとか、Svelteでとか、サーバーはin memoryモックでとか、そういうコンセプトの指示だけしてあとはほぼClaudeCodeに任せたぜ！
自然言語から集計や可視化への繋ぎはDSL構築でやるのがいいだろうなーとおもいつつあえて黙ってたんだけど、ちゃんとDSLを描き始めたのでほんとにえらい。去年のゴミみたいなAIとは別レベルにプログラミングがうまい。
しかしリポジトリのログをみると結構苦労してるのがわかる。
でもいい感じに声かけしつつ軌道修正してあげるとあっという間に解決するのでかわいいね。
最初はGemma2で試し、Qwen3.5に移行したりする中でモデルごとの出力の癖で失敗することがあった。
試す人がいるかどうかは知らないけどアプリに組み込むならモデルは絞っておくといいだろう。
AIと壁打ちする限りまだまだ改善の余地はあり、なかなか面白い実験になったかなとおもう。
