デザインレビューは自動化できるのか？─ Flutter × Figma で UI 品質保証を考える

AI で PR が増える中、Figma と Flutter 実装の見比べを、PR ごとに CI で確かめる仕組みを試作しました。どこまで自動化できたのか、どこからは人の判断が必要なのかを紹介します。最後に、照合を仕組みに任せて生まれた時間で、エンジニアとして事業・ユーザー・技術の重なりにどう向き合うかをお話しします。

Transcript

1. FlutterKaigi 2026 デザインレビューは 自動化できるのか？ Flutter × Figma で UI 品質保証を考える Hirokazu Tanaka 2026.10.30
2. 自己紹介 Hirokazu Tanaka 株式会社 WinTicket モバイルアプリエンジニア techiro FlutterKaigi 2026 appgrape 2 / 61
3. AIでアウトプットは増えた でも施策の成果につなげるのは難しい レビュー・QA PR PR PR リリース PR PR PR AIで増えたPR QAの時間 約4倍 月間インシデント 約2.3倍 Faros AI「The Speed Trap」（2026年9月）開発者22,000人・相関分析 faros.ai/blog/ai-speed-trap-takeaways FlutterKaigi 2026 3 / 61
4. 施策開発は、2025年比で約2倍 画像：公式ページ掲載の機能・改善 · WINTICKET公式 FlutterKaigi 2026 4 / 61
5. 2倍を実現した4つのポイント 増えた開発量を、利用者に役立つ成果へつなげる 1. AI を開発のどこで活用するか 2. レビューの知見を次の開発へどう戻すか 3. 品質をどのように確認するか 4. デザインレビューは自動化できるのか FlutterKaigi 2026 5 / 61
6. PART 1 AI で、 作る速さを上げる AI を開発のどこで活用するか FlutterKaigi 2026
7. WinTicket の施策開発の流れ ① ② ③ ④ ⑤ 企画・仕様 デザイン 設計・実装 QA/QC 修正・ リリース 施策全体 デザイン 開発 表示・操作を確認 デザイン・開発 AIと開発するには、まず「何を作るか」を磨く FlutterKaigi 2026 7 / 61
8. 仕様書と Figma を、議論で育てる 1. 仕様書 2. Figma 議論を仕様書に反映する 表示や操作の議論をデザインに反映 Slack から Devin に作成を依頼 画面案にコメントして議論 仕様とデザインを磨き上げ、人とAIが実装しやすい形に落とし込む 仕様書作成の画像：長田卓馬「WINTICKETで仕様書作成にAIが定着するまでにやったこと」 https://developers.cyberagent.co.jp/blog/archives/62048/（画像は一部抜粋） FlutterKaigi 2026 8 / 61
9. ③設計・実装：PR でレビューする GitHub の PR 上 仕様書と デザインを参照 CI 機械チェック テスト・Lint など 人／ Devin Greptile 実装・PR 作成 FlutterKaigi 2026 🧑‍💻 人間の レビュー main へマージ AI レビュー 9 / 61
10. AI との共著と、1 人あたりの PR が増えた AI と共著したコミット 2025 年 1 人あたりの PR · 約27%増 8% 2026 年 131 件 36% 166 件 作る量が増えると、確認する量も増える 最終チェックを担うのは、人 2025・2026年の各1〜9月を比較 FlutterKaigi 2026 10 / 61
11. 人の最終チェックが、ボトルネックになる 📄 🐛 📄 PR PR 🧑‍💻 人の最終チェック 確認・意思決定 マージ PR 🐛 バグが混入しているリスクのあるPRも増える 増えた確認と意思決定を、どう支えるか？ FlutterKaigi 2026 11 / 61
12. PART 2 人の確認を減らし、 機械に任せる 繰り返す指摘を、自動チェックに変える FlutterKaigi 2026
13. 繰り返す指摘を、独自チェックに変える DART の CUSTOM LINT · 定義数 CI で実行する独自チェック wt_lint · 40 ルール wt_cli · 9 種類 未使用の引数を _ に 例：UIの表示例（Story）があるか // Before onChanged: (value) => refresh(), // After onChanged: (_) => refresh(), FlutterKaigi 2026 sample_tile.dart sample_tile.story.dart ← 必要 なければ PR の自動チェックで知らせる 13 / 61
14. レビューの知見を、次の開発に戻す 💻 💬 開発・PR レビュー 人と AI で進める 人と Greptile で確かめる 📝 🧑‍💻 人が採否・内容を判断する 📚 ルールを更新 指摘を知見に整理 次の開発・レビューで使う Devin が整理する 一つのPRで得た知見を残し、次の開発でも使う FlutterKaigi 2026 14 / 61
15. 蓄積した164ルールは、どの観点を支えるか 主に確かめる観点 ルール数 仕様・意図 14件 UI 19件 コード・設計・安全性 131件 ルール化が進んだのは、コードの確認 UIの確認は、人がFigmaと見比べる部分が残っている 164ルールの分析（2026-10-27） FlutterKaigi 2026 15 / 61
16. PART 3 PRレビューで、 品質をどう高めるか 何を確かめると、品質につながるか FlutterKaigi 2026
17. 人の確認だけに頼らず、重ねて確かめる problems in verification required CI AI review security review human approval merge queue + flags fast rollback 1つの確認が見逃しても、次の確認が拾える Anthropic, “How the Claude Code team does code review” · Fig B “Layers, not one gate” https://claude.dev/blog/solving-code-review-at-anthropic/ （2026-10-15） FlutterKaigi 2026 17 / 61
18. PRレビューで何を、どこを正として確かめるか 観点 確かめたいことの例 正とする場所（SSoT） 仕様・意図 その変更は必要か、目的に合っているか 仕様書 コード・設計・安全性 正しく動くか、壊れないか、安全か リポジトリ CI・Lint UI 仕様に合うか、読みやすく操作できるか Figma 観点ごとに正とする場所を決めると、人もAIも同じ基準で確かめられる FlutterKaigi 2026 18 / 61
19. UIのレビューには、まだ改善の余地がある 観点 主に関わる人 自動化 今の確かめ方 仕様・意図 PdM・プランナー ✕ 難しい 企画の背景を知る人が判断 デザイナー エンジニア コード・設計・安全性 エンジニア ◯ できている Lintなどの自動チェック UI デザイナー △ 余地がある Figmaと実装を エンジニア 人の目で見比べている では、UIのレビューには、どれくらいの作業が発生しているか？ FlutterKaigi 2026 19 / 61
20. 新しいUI実装は、マージまでに時間がかかる マージまで（中央値） 新しい UI 実装 人の指摘（平均） 24.4 時間 7.5 件 既存 UI の変更 15.5 時間 1.7 件 UI 以外 13.2 時間 1.7 件 2026年4〜9月・778 PR FlutterKaigi 2026 20 / 61
21. WinTicketでは、PRの見た目の変化を可視化する Playbook 撮影 📷 reg-suit 人の確認 基準とPRの 画像を比較 意図した 変更か判断 🧑‍💻 playbook_snapshot 画面の状態 を用意 実装を画像に 「変わったか」だけでは、UIの品質は守れない 最初から余白が違えば、それが基準の画像になり、指摘されない 😥 ツールの役割：公式資料 ロゴ：github.com/playbook-ui/mediakit ／ github.com/reg-viz/reg-suit FlutterKaigi 2026 21 / 61
22. 全体から細部まで、一つずつ見比べる Figma：確認する範囲を変える Flutter：実装と見比べる 外側の余白：16 → 24 - Padding(padding: EdgeInsets.all(16), + Padding(padding: EdgeInsets.all(24), 全体：外側余白24 番号と名前の間：16 → 8 - Padding(padding: EdgeInsets.only(left: 16), + Padding(padding: EdgeInsets.only(left: 8), 項目内：番号と名前の間8 FlutterKaigi 2026 この往復を減らせないか？ 22 / 61
23. PART 4 · QUESTION デザインレビューは 自動化できるのか？ Figmaと実装の違いを見つける試作ツール FlutterKaigi 2026
24. Figmaどおりかを、PRごとに確かめるツール 目的 Figmaとの見比べを、 人の目からCIの自動チェックへ できること PRのたびに、GitHub Actionsで動く Figmaと実装の画像を並べて投稿 figma-vrt-review 色・文字・余白などの値を比べる 監査役のAIが、直す箇所と直し方を示す FlutterKaigi 2026 24 / 61
25. どこが、どう違うかをまとめて返す 比べた場所を、 番号の枠で示す 下の表に、 値と判定を並べる FlutterKaigi 2026 25 / 61
26. 投稿をそのまま渡すだけで、Devinが直せる figma-vrt-reviewの投稿 どこがどう違うかを、画像と値で示す この投稿を、比較材料にして 🧑‍💻 人は一言で頼むだけ Devinが投稿を読んで修正し、報告 修正の正しさを検証した結果ではない FlutterKaigi 2026 26 / 61
27. PRの中で、照合と修正が回る GitHub の PR 上 差分を投稿 🧑‍💻 人が依頼 OKなら Devinが修正 マージ 修正後、もう一度照合 Figmaを開かずに、PR上で修正からマージまで 何を直すかは人が決める FlutterKaigi 2026 27 / 61
28. 難しかったのは「どれとどれを比べるか」 コードから比較 違うものを選ぶ AIのゲートを入れる FigmaもFlutterも Frame ≠ Widget AIが対応を選ぶ コンポーネントの入れ子 違う要素の値を比較 答えを機械的に確かめる 構造から比べられるはず 親の余白と内側の余白… 機械で決めきれない対応だけ 機械で決めきれないとき、「同じコンポーネントか」を選ぶAIのゲートを入れた Figmaを整えきれば機械的にも照合できる。整っていなくても動くように設計した FlutterKaigi 2026 28 / 61
29. 情報を集めて比べ、PRで修正につなぐ Flutterのコード Widget・Story FigmaのURL・表示画像 figma-vrt-review Claude：対応を選ぶ どれとどれを比べるか PRコメント 違い・比べた値 比較画像 合わなければ一度だけ聞き直す Figma API 構造・設定値 表示画像 機械的に検証 値・外側と内側の関係 🧑‍💻 人：判断・結果確認 依頼 ↓ ↑ 報告 Devin：修正 FlutterKaigi 2026 29 / 61
30. Widgetの上のコメントで、比べるコンポーネントを指定する Widget の上のコードコメントに FigmaLink を書く · URL は例 /// FigmaLink: https://www.figma.com/design/xxxx/yyyy?node-id=zzzz class HogeHoge extends HookWidget { // ... } URL がファイルとコンポーネント（node-id）を示す。これを Figma から取得して比べる FlutterKaigi 2026 30 / 61
31. Figmaに設定された数値を読み取る 画像（PNG） 設定値（数値） コンポーネントの構造と設定値 paddingLeft: 24 Frame itemSpacing: 8 fontSize: 14 fills: #1A1A1A レース結果 padding: 24 1行 itemSpacing: 8 Text 番号 fontSize: 14 #1A1A1A Text 選手名 fontSize: 14 #1A1A1A Frame 画像からの推測ではなく、設定された値を比べる Figma REST API：ノードと画像の取得／図は概念図 https://developers.figma.com/docs/rest-api/file-endpoints/ FlutterKaigi 2026 31 / 61
32. Flutterのコードから、値と定義を読み取る URLを付けたコード importを辿る 名前を数値に置き換え WidgetとStory 定義を集める AIに渡す 対象のWidgetとStoryの全文 テーマ・色・角丸などの定義 トークン名 → 定義の値 上限80ファイル 名前からは推測しない 定義の場所も添える AIは検索しない。ツールが集めた入力だけで判断する 上限はコンテキストの大きさとコストで決めた。共通コンポーネントの中身や親の画面は渡さない FlutterKaigi 2026 32 / 61
33. AIが選んだ対応と値を、機械的に確かめる 01 02 03 04 先に確定 AIが選ぶ 機械的に確かめる 結果を返す ✓ Figmaの値が実在する 違い：8 と 16 値を定義から解決 対応が明らかなら Figma Flutter 親フレーム：余白24 親Widget ✓ 判定が実装の値と合う 機械で判定 残りだけAIへ 子フレーム：余白8 Padding(16) ✓ 外側の余白を借りない 確かめられない → 未確認 問題点を添えて、一度だけ聞き直す 機械で確定 → AIが選ぶ → 機械で確かめる → 人が直すか決める FlutterKaigi 2026 33 / 61
34. 比べるのは、余白・サイズ・文字・色 比べるもの Figma ↔ Flutter 確認する値 余白・間隔 各辺の余白・間隔 ↔ Padding・spacing 辺ごとの余白・要素間隔 固定サイズ 固定寸法 ↔ 幅・高さの指定 幅・高さの値 文字 文字の設定 ↔ コードのスタイル サイズ・太さ・行高 色 塗りのRGB ↔ コードの色 同じ役割の色の値 場所と値を返し、人が直すかどうかを決める FlutterKaigi 2026 34 / 61
35. ツールの限界 できること：UIの数値 できないこと：UIに見えないUX 余白・文字サイズ・色などの差 例：「続ける」ボタン。余白や色は Figma と一致 比べた値と画像を添える Figma：8 実装：16 続ける 正しい画面へ進む？ 動きは Widget Test、触り心地は人が確かめる 同じ場所の値が違うと分かる FlutterKaigi 2026 35 / 61
36. デザインレビューは、一部を自動化できる Widgetの異なるPR 10件に、余白・サイズ・文字・色の違いを作り、3回検証 120件中89件を検出。主な失敗要因は、StoryとFigmaの対応付け（Storyの網羅性） 今回、支援できたこと 人の判断が必要なこと Figmaとの数値の照合 その違いを、どう扱うか 余白・サイズ・文字・色を比べる 指摘の根拠を確かめる 違う場所と、比べた値を知らせる 意図を踏まえ、直すかを決める 数値の照合は仕組みに、直すかの判断は人に FlutterKaigi 2026 36 / 61
37. SUMMARY まとめ 照合の先で、何を考えるか FlutterKaigi 2026
38. 開発の流れに、Figmaとの照合が加わった デザインを参照 人／ Devin 実装・PR 作成 CI · 機械チェック テスト・Lint・VRT など Greptile AI レビュー 人が 最終チェック main へマージ figma-vrt-review Figma との違いを知らせる 候補は機械が出し、直すかは人が決める FlutterKaigi 2026 38 / 61
39. データがないとき、何を伝えるか 競輪のレース結果がないとき ここに、 何を表示しますか？ ？ FlutterKaigi 2026 39 / 61
40. データがないとき、何を伝えるか 実際のFigmaの表示 「結果は まだありません」 0件・読み込み中・取得の失敗で、 伝えたいことは変わる FlutterKaigi 2026 40 / 61
41. UXは、見た目だけで決まらない Garrettの五層モデル（要約） 具体 表層 Surface 見た目の仕上げ 私の考察 骨格 Skeleton 画面の配置・導線 エンジニアも、 構造 Structure 操作や情報のつながり プロダクトの価値を 考える議論へ 抽象 要件 Scope 必要な機能・内容 戦略 Strategy 利用者の望み・事業の目的 Jesse James Garrett, The Elements of User Experience（2002）, Chapters 2–7 を要約・作図 https://www.oreilly.com/library/view/the-elements-of/9780321684486/ch03.html FlutterKaigi 2026 41 / 61
42. 事業・ユーザー・技術に、向き合う 事業 ユーザー 目的・成果 利用体験 技術 設計・実装 どこに向き合うべきか？ Martin Eriksson「What, exactly, is a Product Manager?」（2011）· Business・Technology・UX mindtheproduct.com/what-exactly-is-a-product-manager/ FlutterKaigi 2026 42 / 61
43. 事業・ユーザー・技術に、向き合う 事業 ユーザー 目的・成果 利用体験 向き合う ところ 技術 設計・実装 どれか一つではなく、三つの重なりで考える Martin Eriksson「What, exactly, is a Product Manager?」（2011）· Business・Technology・UX mindtheproduct.com/what-exactly-is-a-product-manager/ FlutterKaigi 2026 43 / 61
44. 自動化の先で、プロダクトづくりに深く関わる 照合を仕組みへ 考える範囲を広げる いま：人が見比べる 仕様の背景 確認の時間 仕組みに任せた後 Figma 実装 仕組みが確認 確認 デザインの意図 生まれる時間 利用者の目的 デザイナー・PdMと、何を作るかを磨く 使う人にとって、よりよいプロダクトへ FlutterKaigi 2026 44 / 61
45. 最後に 面倒は仕組みに、 時間はプロダクトに FlutterKaigi 2026