UI生成AIにどこまで任せていいか、設計判断は誰が持つか

プロンプトを打って数十秒待つと、それらしいランディングページやダッシュボードがブラウザに現れる。ボタンも配色もレイアウトも一通り整っていて、最初の数分は「もうアプリができた」とすら感じる。だがそこから先、たとえば「このステータスは保存するのか、それとも別の値から都度計算するのか」「同じユーザーが2つの画面を同時に開いたらどちらを正としてどう反映するのか」といった問いに差し掛かった瞬間、手が止まる。画面は速いのに、その先が動かない。この落差にどこかで心当たりのある人は多いはずだ。

速いのは画面、詰まるのは決めごと

v0やbolt.new、Lovableのようなツールは、プロンプトから見た目のあるUIを生成することに特化している。ここでいう「UI生成」というのは、要件を伝えるとレイアウトや配色、コンポーネントの並びまで含めた画面そのものを一気に組み立ててくれる仕組みのことだ。この作業自体は驚くほど速い。だが実務でつまずくのは、たいていUIの見た目ではなく、その裏側にある決めごとの方である。

何をデータとして保存し、何を都度計算して導き出すのか。ある状態が変わったとき、他のどの画面や値まで連動して更新されるべきなのか。ユーザーが取れる操作の境界はどこまでで、それを超えた入力はどう扱うのか——これらは要件定義やデータモデル設計、状態設計と呼ばれる領域の話で、プロンプトを重ねれば重ねるほど固まっていくものではない。むしろ逆のことが起きやすい。AIは指示があいまいな部分を「それらしい値」で埋めてしまう性質があるため、本来なら人が決めるべきだった箇所が、一見動くコードの中に紛れて見えなくなる。決めていないことが可視化されないまま先に進み、後になって画面同士のつじつまが合わなくなって初めて、実は何も決めていなかったことに気づく。速さの代償は、詰まりの先送りという形でやってくる。

何を人が握り、何をAIに預けるか

ここから見えてくる線引きは、「AIにどこまで作らせるか」という作業量の話ではない。「どの決定を人が握るか」という決定の所在の話だ。要件・データモデル・状態設計・更新の境界——この4つは、実装の前に人の頭の中で一度言語化しておく必要がある領域で、ここをAIに丸ごと委ねると、後から直すコストの方が最初に浮いた時間より大きくなりやすい。逆に、決定さえ済んでいれば、その先の実装の反復——フォームを1つ増やす、配色を調整する、コンポーネントを分割し直す、といった作業——はUI生成AIが最も力を発揮する領域になる。何を作るべきかがはっきりしている状態でこそ、プロンプトの速さは純粋な武器になる。

AI開発ツールは、コードを横断的に書き換える「エージェント型」、エディタに統合された「AIエディタ型」、書いている最中の続きを提案する「補完型」、対話で相談する「チャット型」、そしてプロンプトから画面やアプリをまるごと生成する「UI生成型」というふうに、役割で分けて捉えると輪郭がはっきりする。v0やbolt.new、Lovableはこの最後の型に属し、他の型とは担う工程がそもそも違う。エージェント型やAIエディタ型が「決まったロジックの実装」を助けるのに対し、UI生成型は「決まった要件の画面化」を助ける道具として位置づけると、任せていい範囲がぐっと具体的になる。

決定を先に、実装反復をあとに

だから次にUI生成AIを使うときは、プロンプトを書く前に一度、紙でもメモでもいいので「このデータはどこで生まれてどこで消えるのか」「この画面の値はどの状態から導かれているのか」を自分の言葉で書き出してみたい。そこまで済んでいれば、あとの反復はAIに存分に任せてよい。画面の配置をやり直す、入力欄を1つ増やす、コンポーネントを分割し直す——こうした変更は決定そのものを揺らさない範囲の反復なので、何度プロンプトを重ねても崩れにくい。逆に、決めごとが曖昧なままプロンプトを重ねても、できあがるのは見た目のきれいな画面と、その裏で先送りにされた決めごとの山だけだ。あとになって「AIが作った画面なのに、なぜか合わない」と感じるとき、原因の多くは生成の精度ではなく、そもそも人が決めていなかった部分にある。

なお、tasklogは技術記事の中でAI開発ツールがどれだけ引用されているかをこの型ごとに集計しているサービスで、UI生成型が実際どう語られているかはLovableの被引用まとめ、他の型との違いを一望したいときはAI開発ツールの型別ランキングで確かめられる。

任せる範囲を決めるのは、結局のところツールではなく、その前に済ませておく決めごとの方だ。