AIがUIを作る時代に、フロントエンドエンジニアは何を設計するのか

ZennのURL： https://zenn.dev/lv/articles/0adaf33f6fc672

AIにUIを作らせると、カード、テーブル、検索フォーム、ステータスバッジ、モーダルはすぐに並びます。

でも、そのUIを実装しようとした瞬間に、「この状態は何種類あるのか」「誰がこの操作をできるのか」「この画面はURLで直接開けるのか」「DBには何を保存するのか」といった問いが出てきます。

AIが作ったUIは、完成品ではありません。
それは、AIが勝手に補った仕様の仮説です。

この資料では、AI生成UIをそのまま受け入れるのではなく、対象、状態、操作、URL、state、DB schemaの観点から読み解く方法を整理します。

Transcript

1. oga_aiichiroと申します。 今日は、AIがUIを作る時代に、フロントエンドエンジニアは何を設計するのか、というお話をします。 よろしくお願いします。
2. まず自己紹介から。 KENTEMという会社で働いている24卒の新卒3年目です。 趣味はピアノとゲームと技術記事執筆で、Claude CodeのZenn本とか書いてます。
3. 今日の主旨なんですけど、 バイブコーディングですぐ画面ができるし フロントエンドエンジニアいらん😂 AIに職奪われるやろ ←これ イッチ：ほんまか？ --- という話をしたいです
4. さて、はじめに。 個人開発や社内ツールやPoCなどで、AIにUIを作らせると、画面はかなり速く出てきます。 たとえば、こう頼みます。経費申請システムを作ってください、と。
5. すると、こういういろんなパーツがぱっと並んだ画面が返ってきます。 画面は実際に作らせた例です。
6. すごすぎ～～～ これはフロントエンドエンジニアはもう要りませんね……
7. はい、AIは、画面の「それっぽい形」をすぐ作れます。 一覧、検索、バッジ、ボタンまで並び、とても「それっぽい」です。
8. でも、それっぽい形ができただけで完成なのでしょうか？
9. 画面の形はあるんです。 でも、実装に必要な判断は、まだ残っていますよね。
10. たとえば、ステータスのバッジがいま4種類画面にあるけど、これだけでいいの？
11. 却下された申請は、再提出できるの？
12. 承認済みの申請は、編集できるの？誰が承認できるの？
13. この詳細画面はURLで直接開けるべきなの？
14. この情報はDBに保存するの？表示時に計算するの？ さっきの画面だけだと、これらが決まりませんよね。
15. ここで起きているのは、AIが見た目を作るために、裏側の仕様を勝手に補っている、ということです。 状態、権限、URL、API、DB schema。 見えていないところで、これら全部に仮定が入っているんですよね。 つまり、 AIが作ったUIは、完成した仕様ではない。 あくまで、仕様の仮説です。
16. つまり、 AIが作ったUIは、完成した仕様ではない。 あくまで、仕様の仮説段階です。
17. 例えば、経費申請一覧によく出てくる、承認しましたよーという、たかがこのApprovedバッジ1個。
18. たかが一個と思いきや、採用した瞬間に、これだけのことを聞いてきます。 このApprovedは最終状態なのか。取り消せるのか。承認日時を保存するのか。却下や差し戻しと何が違うのか。誰が承認できるのか。 バッジ1個で、これだけあるんですよね。
19. しかも、この判断はUIの中だけでは閉じません。
20. Approvedという状態を採用するなら、 UIではバッジを出す。 APIでは、誰がその状態に変えられるのかを決める必要がある。 DBには、status や approved_at を保存するかもしれない。 承認後に編集できるのかも決めないといけない。
21. うーん、考えることが多くなってきましたね。 どうやったらAIが作ったUIを採用できるようになるんでしょう？
22. タイトルの問いに立ち返りましょう。 AIがUIを作る時代に、フロントエンドエンジニアは何を設計するんでしょうか。
23. あくまで私個人の試行錯誤の答えですが、
24. 僕の中での答えはこうです。 AIが勝手に置いたUIパーツを、実装可能な問いに変換することで、画面の意味を設計する。
25. ここでいう“意味を設計する”は、フロントエンドが全部を一人で決めるという意味ではありません。 画面に現れた未決定の仕様を、関係者と決められる問いに変換する、という意味です。
26. ここで、画面の意味とは、画面を - 対象 - 業務状態 - 操作 - 表現 の4つの角度からの問いに分解したときの答え, とおきます ひとつひとつ見ていきます。
27. まず1つ目、対象。 何を識別・変更の単位にするか？ つまり、 そのアプリが何を「モノ」として扱うのか？を決めます。
28. 経費申請アプリを例にしましょう。 ExpenseReportは経費申請そのもの。 ExpenseItemは明細。 Employeeは申請者と承認者、みたいな感じです。
29. 3番の操作の先取りをしちゃうんですけど、ここで言いたいのは、こうやって対象を先に決めると、操作の置き場所が自然に見えてくるよね、ということです ExpenseReport を作成する、提出する、承認する、却下する。 ExpenseItem を編集する、削除する、領収書を添付する など。 操作が、対象の上にきれいにぶら下がります。 --- (飛ばす) なぜEmployeeは操作がないのか 承認者を選ぶ時にリストから選択する、申請者として自動的にセットされる、これは全部、ExpenseReportの操作の一部としてEmployeeを「使ってる」だけで、Employee自体に何かをしてるわけじゃない。 なぜそうなるかというと、Employeeは経費申請アプリの中で作成も削除もされる対象じゃないんです。HR(人事)システムから連携される従業員マスタで、経費申請アプリは参照する側。この区別が、対象起点で並べると一発で見えてくる。
30. 2つ目、業務状態。 対象はどんな状態を取りうるか？ ここでいう状態は、Reactのstateのことではないです。 対象がドメイン上どういうステータスを持つのか、という話です。
31. 左が業務状態。例えば経費申請が取りうる状態は、draft、pending、approved、rejected。これはDBにも、APIにも、認可にも出てくる状態です。 右がReact state。selectedReportId、isDetailOpen、filterStatus、formDraft。UI側で扱うための表現の一形態です。
32. 3つ目、操作。 これは、業務状態「 × 誰が、何をできる？」　です
33. Draftなら、申請者が編集して提出できる。Pendingなら、承認者がApproveかRejectできる。 では、表形式にしたときに、Rejectedなら、再提出(resubmit)できるのか、ここで終わりなのか。 Approvedなら、取り消し(revoke)可能なのか、完全に終端なのか。 こうして表形式で、対象、業務状態、誰がなにをできる、と表したとき、操作が表されます そして、分からない部分が、そのまま仕様判断のポイントになります。
34. 4つ目、表現です。 これ今日、けっこう強く言いたかったどころです。 対象が決まると、その対象は、いろんなレイヤーに別の形で現れます。 文字列は違っても、指している概念は同じ。 各レイヤーの文法に合わせつつ、同じ概念として追えるようにする、同じドメインモデルを共有すべき、という話です。
35. ただ、ごめんなさい、 ここを説明しだすと時間が足りないので、 Zennで記事を書いてこないだトレンドに載ったので、こちらを見ていただければと思います
36. まずURLです。 URLは、直接開ける対象を表します。 ExpenseReportを主役にすると、URLは /expense-reports とその子になります。 一方、承認者のタスクを主役にすると、/approval-tasks という別のURL設計もありえます。
37. ここで言いたいのは、URLは画面遷移の都合ではなくて、アプリのドメインモデルとつながっている必要がある、ということです。 ブックマークできるか、戻るボタンで戻れるか、共有できるか。 そこに、アプリが何を対象として扱うかが出てきます。
38. 次にstateです。 stateは、矛盾しない最小表現で持ちます。 たとえば左のように、status、isApproved、approvedAtを別フィールドで持つと、approvedなのにisApprovedがfalse、というような矛盾が起きうる状態になります。 UIが、どれを信じればいいか分からなくなります。
39. そこで右のように、判別可能なユニオン型で持ちます。 approvedのときだけapprovedAtを持つ、rejectedのときだけreasonを持つ、と型で表現できる。
40. state設計は、useStateをどう分けるかの話ではなくて、画面が信じるべき事実をどこにどう持つか、という設計の話だと考えています。
41. 最後にUIとDBです。 これも形を揃える話ではありません。 DBのexpense_itemsは、画面では「明細」と呼んでいい。 employeesとdepartmentsが別テーブルでも、画面では「申請者名と部署名」と1行で見せていい。 監査ログが細かく保存されていても、画面では「承認履歴」として必要な情報だけ見せていい。 形は違っていいです。 ただし、同じものを話している言葉が揃っていることが大事です。 ここがずれると、画面ごとに解釈が割れていきます。 共通の言葉を作るのはユビキタス言語に近い話だと思います。
42. 4つの問いができたので、最初に見たApprovedバッジを、もう一度読み直してみます。 対象は ExpenseReport(経費申請) 業務状態は draft から pending を経て approved か rejected に至る遷移 操作は pending のときに承認者が approve できる 表現は /expense-reports/:id みたいに UI・URL・state・API・DB で同じ言葉で追える。 この4つの答えが、見た目の裏で僕らが決めていることです。
43. 昔はAIが勝手に置いた、たかがバッジ1個でした。 ↓ ですが今は、ただの見た目ではなく、アプリ全体の仕様の入口になりましたね。
44. 駆け足でしたが、まとめです。 AIがUIを作る時代のフロントエンドエンジニアの仕事とは？
45. 僕なりの答えは AIが作るUIの仕様の曖昧さを、画面の意味に分解することで PdM・デザイナー・BEと会話できるに変換して、実装すること。 これがAIがUIを作る時代にも変わらないフロントエンドエンジニアの仕事だと思っています。
46. というわけで駆け足でしたが以上です。 ありがとうございました！
47. ここからQ&Aです。
48. 目次です。
49. フロントエンドが全部の仕様を一人で決める、という意味ではないです。 僕が言いたいのは、AIが作った画面に現れた「未決の仕様」を見つけて、関係者が決められる問いに変換する役割は、フロントエンドがかなり担いやすい、ということです。 画面はユーザーが仕様に触れる場所なので、そこに出ているバッジ、ボタン、URL、入力欄を見れば、「この状態は誰が変えられるのか」「これは保存されるのか」「直接開ける対象なのか」といった未決定事項が見えてきます。 なので、決定権を独占するというより、仕様の曖昧さを発見して、PdM・デザイナー・バックエンドと会話できる形にするのがフロントエンドの仕事だと思っています。
50. 不要になるというより、むしろレビュー対象が増えると思っています。 AIがUIだけでなく、状態遷移、API、DBスキーマまで提案できるようになるほど、「それを採用するのか」「今回の業務に合っているのか」「作らない範囲はどこか」を判断する必要があります。 AIが出したものは叩き台としては優秀ですが、たとえば「支払い済み」ステータスを勝手に足したときに、それが経費申請の責務なのか、経理処理まで含むのかは人間が決める必要があります。 なので、AIに任せる時代ほど、AIの仮説を読むための設計語彙が必要になる、という立場です。
51. かなり近いです。新しい理論を発明した、というよりは、DDDやOOUI的な考え方を、AI生成UIのレビューに使いやすい形に落とした話だと思っています。 特に「対象を先に見る」という話はOOUIに近いですし、「同じ言葉で追えるようにする」という話はDDDのユビキタス言語に近いです。Martin Fowlerもユビキタス言語を、開発者とユーザーの間で共有される厳密な言葉として説明しています。 ただ、今日の話のポイントは、AIがそれっぽいUIを高速に出すようになったことで、こういう設計観点を「UIレビューの初手」として使う必要が増えた、というところです。
52. 同じ形にする、という意味ではないです。むしろ形は違っていいと思っています。 UIには見やすさがありますし、DBには正規化や履歴、インデックスの都合があります。なので、UIのコンポーネント構造とDBテーブル構造を一致させる必要はありません。 ただ、同じ概念について話していると分かる言葉は必要です。画面では「申請」、URLでは report、APIでは request、DBでは application みたいに揺れると、後から「これ同じものですか？」となります。 なので、密結合ではなく、概念の対応関係を追えるようにする、という意味です。
53. 僕は「その状態がドメイン上の事実か、UI上の都合か」で見ます。 approvedやrejectedは、DBにもAPIにも認可にも関係するので業務状態です。一方で isDetailOpen や selectedReportId や filterStatus は、画面操作のための状態なので React state 寄りです。 もちろん境界が曖昧なこともありますが、Reactのstate設計でも、矛盾するstateや冗長なstateを避けることが重要、と公式ドキュメントで説明されています。 なので、まず業務状態を整理して、そのうえでUIに必要な最小のReact stateへ写す、という順番で考えると崩れにくいと思っています。
54. その通りで、全部を重厚にモデリングする必要はないと思っています。 ただ、今回の話は「大きな設計書を書こう」ではなく、「AIが勝手に置いた仕様をそのまま飲み込まないようにしよう」という話です。 小規模ならなおさら、最小限でいいので「対象は何か」「状態は何種類か」「誰が何をできるか」「今回は何を作らないか」だけ決めると、AIの出力を削りやすくなります。 重くするための設計ではなく、むしろ作りすぎないための設計です。
55. これはAIに限った話ではなく、人間が作った画面にも同じことが言えます。 ただ、AIの場合はそれっぽいUIがすごい速度で出てくるので、未決の仕様もすごい速度で混ざります。 人間が作ったワイヤーなら、作った人に「このボタンの意図は？」と聞けますが、AIが出したものは、誰も本当に決めていない仕様が画面に出ていることがあります。 だからAI時代には、UIを「完成物」ではなく「仕様仮説の集合」として読む姿勢がより重要になる、という話です。
56. ただの装飾なら大げさに考えなくていいです。 でも、そのバッジが業務上の状態を表しているなら、途端に話が変わります。 Approvedがただの表示ラベルなのか、申請の最終状態なのか、承認日時や承認者と結びつくのか、編集ロックに関係するのかで、必要な実装がかなり変わります。 僕が言いたいのは、すべてのUIパーツを重く扱おうということではなく、「このパーツは業務状態なのか、単なる表示なのか」を見分けよう、ということです。
57. 成果物としては、たとえば4つあります。 1つ目は、対象の一覧です。ExpenseReport、ExpenseItem、Employee のような、その画面で扱うモノです。 2つ目は、状態遷移です。draftから pending、そこから approved / rejected に進む、みたいなものです。 3つ目は、操作マトリクスです。どの状態で、誰が、何をできるか。 4つ目は、UI・URL・state・API・DBで同じ概念をどう表すかの対応表です。 これらがあると、AI生成UIをそのまま実装するのではなく、実装可能な仕様に変換できます。
58. ユーザーのやりたいことから考えるのは大事です。そこは否定していません。 ただ、実装に落とすときに操作だけを見ていると、画面が「申請する画面」「承認する画面」「検索する画面」のように動詞単位で散らばりやすいと思っています。 そこで一度、「その操作は何に対する操作なのか？」を見る。 ExpenseReportを提出する、ExpenseReportを承認する、ExpenseItemを追加する、というふうに対象へ結びつけると、画面、URL、状態、APIが整理しやすくなります。 なので、ユーザーのタスクを無視するのではなく、タスクを実装可能な対象に結びつけるために「対象」を見る、という考え方です。
59. 最終的なDB設計や認可設計をFEだけで決める、という意味ではないです。 ただ、画面に Approve ボタンがあるなら、「誰が押せるのか」「押した後に編集できるのか」「承認日時は必要なのか」という問いは、フロントエンド実装にも必ず返ってきます。 その問いを見ないまま画面だけ作ると、あとでAPIやDBと噛み合わなくなります。 なので、FEが全部を設計するというより、画面から見えた仕様の波及先を認識して、必要な人と会話するための問いにする、という意味です。
60. はい、そこはかなり大事です。7分LTなので深掘りはZenn側に逃がしましたが、実務ではむしろ「表現」がかなり効いてくると思っています。 対象や状態を決めても、それがURL、state、API、DBで別々の名前になっていると、画面ごとに解釈が割れます。 なので今日の発表では詳しく話しきれませんでしたが、最低限「同じ概念を各レイヤーで追えるようにする」という観点だけ持って帰ってもらえればと思っています。
61. AIにその4つを渡すのはすごく良い使い方だと思っています。 ただ、その4つを何にするかを言語化するところが設計です。対象は何か、状態は何か、誰が何をできるか、今回は何を作らないか。ここは業務やチームの判断が入ります。 さらに、AIが返してきた結果がその判断に沿っているかをレビューする必要もあります。 なので、AIに任せるためにも、人間側が「問いの立て方」を持っている必要がある、という話です。
62. そこはむしろ狙っていて、AI時代でも変わらないフロントエンドの仕事を話したかったです。 AIによって、画面の形を作るコストはかなり下がっています。Reactの公式ドキュメントでも、UIをコンポーネント階層に分け、データモデルと対応させ、最小のstateを見つけるという流れが説明されていますが、AIが見た目を出してくれる時代でも、その「何を状態として持つか」「何を対象として扱うか」の判断は残ります。 だから、AIで変わったことを話しつつ、最後は「変わらない仕事」に着地させています。