WebUI実装の自動化を_試して見えたこと

Transcript

1. #雑LT_study WebUI実装の自動化を 試して見えたこと @uuki_dev 2026.7.27
2. 自己紹介 uuki （ユウキ） Web制作会社勤務 主にフロントエンドを中心に業務に携わっています X @uuki_dev Zenn: @uuki GitHub: uuki
3. 今日話すこと / おことわり WebUI 実装の自動化の難しさを分解し、 向き合ったラフな試みについてです。 新規的な技術の話ではありません 🙏
4. 現状の選択肢と、今回の前提 現状の選択肢 今回の前提 デザインと実装の対応関係を 定義できる場合に強力なツール 受託制作のように、案件ごとに プロセスや設計が異なる環境 • Figma Code Connect • コンポーネントの単位を都度 判断する場合
5. 課題：自動化の難しさ① - ワークフロー デザイン ⇔ 実装を直線的に目指すほど 「構造の単位」「バリアントの設計」など、 実装の関心が一定デザイン側にも求められる
6. 課題：自動化の難しさ ② - コンテキスト 間に存在する知識の依存構造 コンポーネント粒度やHTML構造の関係、CSS設計、 アーキテクチャの仕様、開発環境など、様々な判断要素を含む
7. 方針：業務知識を制御点に分けて接続する 人が作業する場合と同様に、業務ごとにAIへタスクを振り出す。 その手段として、JSON による中間表現を使い、 業務を3段階に分解 コンポーネントの粒度 • LinkButton • PostCard • ProductCard • RelatedSection デザインパターン 開発環境 Component Composition • Next.js • Nuxt • CSS Architecture • Astro • Utility-first CSS • etc… •
8. アプローチ ：デザインから分類して意味づけ コンポーネントの単位を、様々なデザインパターンに対応でき るよう、中間的な「抽象、意味、構造 + 機能」 の4分類に整理。 今回は、分類作業の手段としてアノテーションツールを作成。 構造（ Layout） 意味（ Component） 抽象（ Primitive） 機能（ feature） 1/3
9. アプローチ： デザインから分類して意味づけ ※ 個人的なサンプルデザインで検証した時の画面 1/3
10. アプローチ：UI モデル 分類化済のJSONをもとに、 node構造、スタイルトークン、 基底スタイルに任意の設計方針を反映。 この段階で、セマンティクスや スタイル設計についての指示を差し込む。 2/3
11. アプローチ： コード生成 最後に、基盤となる技術スタックに Plop や、Stylelint といった、 Scaffolding、Linterを定義。 これをもとにスクリプトによる コンポーネント展開を実施 3/3
12. 結果 デザイン側 実用観点の結果 小さなコンポーネント単位では、 構造と基底スタイルの生成は可能そう。 一方、複雑なレイアウト再現は課題。 生成結果 試作で得たこと Structured OutputによるAI 出力の構造化 と、フィードバックループの要点を掴めた。
13. まとめ 中間表現は、AIの判断を分けて調整する 制御点になり得る • 工程を分けることで、設計判断や再現度の精度のブレを 切り分け、個別に調整しやすくなる • 次の段階では、中間表現による分解を 独自の手段に依存しない形で再現できるか検証したい