【Flutter × AI】 AI は Material Design 3 を使って Widget を実装できるのか 〜Figmaデータの整備度がAIの出力に与える影響〜

イベント名：AI時代のFlutter開発スペシャル by クラスメソッド
日時：2026/05/11
形式：オンラインウェビナー
概要：
Flutter開発におけるFigmaデザインデータ構造がAIのコード生成に与える影響を検証した結果、Matetrial Designのような普及したシステムではデザインデータが未整備でもAIは視覚情報から適切にUIを推論し正確なコードを出力できることが判明しました。過度なデータ整備よりも実装の完遂にリソースを配分すべきであると結論づけています。

Transcript

1. AI 時代の Flutter 開発スペシャル by クラスメソッド 【Flutter × AI】 AI は Material Design 3 を使って Widget を実装できるのか 〜Figmaデータの整備度がAIの出力に与える影響〜 2026.5.11 hott3 X @hott3_ © 2026 hott3 1
2. 自己紹介 堀田 誠 （ X : @hott3_ ） モバイルエンジニア（ Flutter ） ドコドア株式会社 関心： モバイル、デザイン、人が作るもの、ネコ © 2026 hott3 2
3. TL;DR 最近の AI モデルは MD3 を理解している デザインデータが整っていなくても、ほぼ見た目通りのコードを出力することができる エンジニアは、 AI に何を期待するかを理解し、戦略を立てる必要がある どんな情報が AI の出力に影響を与えるのか その情報を整えるためにどこまで工数をかけるべきか © 2026 hott3 3
4. こんなこと聞いたことありませんか？ 「 AI に Figma を渡せば、もう一瞬でコードが出るよね」 「いや、まずはデザインシステムを整備しないと、 AI も迷っちゃうよ」 「結局、レイヤーをちゃんと構造化（ Auto Layout など）してないと使い物にならないよ」 「これからは AI への指示書として『 DESIGN.md 』を同梱するのが当たり前になりそう」 © 2026 hott3 4
5. 「どこまでデザインデータを整備するか？」 AI が出力したコードに対して、人間の手直しが発生する可能性 デザインデータを整えるための工数が確保できない可能性 デザインデータの構造が、出力される Flutter のコードの品質に与える影響が不明確 → どこまでデザインデータを整備するべきか、明確な指針がない © 2026 hott3 5
6. 検証 Figma の UI Kit を使ったデザインデータで Material Design 3 のコンテキストを渡せば、 AI は MD3 準拠の Widget を選定しやすくなるのではないか？ → Widget が選定されやすい条件と、そうでない条件を発見することで、どこまでデザインデ ータを整えるべきかの指針を探る Material 3 Design Kit | Figma https://www.figma.com/community/file/1035203688168086460 6
7. 検証 検証手順 1. Figma の UI Kit を使って、 2 つのケースのデザインデータを用意 2. 見た目を維持しつつ、デザインデータを 4 つの構造レベルに変更する 3. AI に同一プロンプトを与え、それぞれのデザインの Flutter コードを出力させる 4. 出力されたコードを、 MD3 準拠の Widget 選定、見た目の再現度の観点で評価する © 2026 hott3 7
8. 検証で固定した条件 検証 Flutter: 3.41.6 / Dart: 3.11.4 VS Code GitHub Copilot Agent mode を使用 Claude 4.6 Sonnet を使用 Figma Remote Server を利用 get_design_context でデザイン情報を取得 get_screenshot は指定しない Skills の影響を除外するため Agent Skills は未使用 同一プロンプトを使用 © 2026 hott3 8
9. 検証 検証で変更した条件 Figma のデザインデータの整備度を 4 段階で変更 構造レベ ル 高 中 低 0 コンポーネント機 能 維持 レイヤー 名 維持 スタイル / バリアブル機 能 維持 維持 オートレイアウト機 能 維持 維持 レイヤー構 造 維持 維持 維持 → この構造レベルの変化をもって、デザインデータが AI の出力に与える影響を検証する © 2026 hott3 見た 目 維持 維持 維持 維持 9
10. Case 1: 検索バー 構造レベル：高 UI Kit そのままのデザイン 構造レベ ル 高 コンポーネント機 能 維持 レイヤー 名 維持 スタイル / バリアブル機 能 維持 © 2026 hott3 オートレイアウト機 能 維持 レイヤー構 造 維持 見た 目 維持 10
11. Case 1: 検索バー 構造レベル：中 コンポーネントを切り離しレイヤー名を変更したデザイン 構造レベ ル 中 コンポーネント機 能 レイヤー 名 スタイル / バリアブル機 能 維持 © 2026 hott3 オートレイアウト機 能 維持 レイヤー構 造 維持 見た 目 維持 11
12. Case 1: 検索バー 構造レベル：低 デザイントークンとオートレイアウトを削除したデザイン 構造レベ ル 低 コンポーネント機 能 レイヤー 名 スタイル / バリアブル機 能 © 2026 hott3 オートレイアウト機 能 レイヤー構 造 維持 見た 目 維持 12
13. Case 1: 検索バー 構造レベル： 0 見た目が保てる最低限のレイヤー構造を残したデザイン 構造レベ ル 0 コンポーネント機 能 レイヤー 名 スタイル / バリアブル機 能 © 2026 hott3 オートレイアウト機 能 レイヤー構 造 見た 目 維持 13
14. Case 1: 検索バー 結果：構造レベル0 のデザインデータをAIに渡して出力されたコード 見た目しか維持されていないデザインデータでも、 MD3 準拠の Widget 選定はされている © 2026 hott3 14
15. Case 1: 検索バー MD3準拠のWidget選定、見た目の再現度 構造レベル MD3 準拠の Widget 選定 見た目の再現度 高 SearchBar が使用されている 中 SearchBar が使用されている 低 SearchBar が使用されている 0 SearchBar が使用されている → MD3 準拠の Widget が選定され、見た目通りのコードが出力されている © 2026 hott3 15
16. Case 2: 商品カード Case 2: 商品カード 構造レベル：高 UI Kit そのままのデザイン 構造レベル：中 コンポーネントを切り離しレイヤー名を変更したデザイン 構造レベル：低 デザイントークンとオートレイアウトを削除したデザイン 構造レベル： 0 見た目が保てる最低限のレイヤー構造を残したデザイン © 2026 hott3 16
17. Case 2: 商品カード 構造レベル：0 のデザインデータをAIに渡して出力されたコード 見た目しか維持されていないデザインデータでも、 MD3 準拠の Widget 選定はされている © 2026 hott3 17
18. 構造レベル Case 2: 商品カード MD3 準拠の Widget 選定 高 Card / OutlinedButton / FilledButton が使用されている 中 Card / OutlinedButton / FilledButton が使用されている 低 Card / OutlinedButton / FilledButton が使用されている 0 Card / OutlinedButton / FilledButton が使用されている 見た目の再現度 → MD3 準拠の Widget が選定され、見た目通りのコードが出力されている © 2026 hott3 18
19. 考察 検証結果 構造レベルを下げても、 MD3 準拠の Widget 選定はされ、見た目通りのコードが出力されて いる つまり、 AI は「これが SearchBar だ」と推論できている → MD3 の UI Kit を使うことが、 AI に対して「このデザインは MD3 のコンポーネントだ」とい う強い文脈を与られると予想していたが、デザインデータを破壊しても Widget を選定できて いた © 2026 hott3 19
20. 検証中に気づいたこと 考察 なぜ構造レベル 0 のデザインデータでも、 MD3 準拠の Widget 選定がされていたのか？ Case 1 の構造レベル低でスクリーンショットを取得していた FIgma MCP Server の get_design_context のみ指定し、デザインデータを利用する想 定だった → つまり、 AI がスクリーンショットも取得して視覚情報をもとに見た目の実装を行っていた 20 © 2026 hott3
21. 考察 新しい仮説とそこからわかること 事実として、 AI はレイヤー構造が崩れていても、視覚情報から UI デザインを推論している （ Flutter と MD3 という世界中で広く公開されているパターンで学習されているために、 AI が必要な Widget を推論しやすかった可能性がある） → つまり、 構造化されていないデザインデータが AI の出力の品質を、必ず下げるわけではない ※ LLMの性質上、毎回同一結果にはならないことに注意 21
22. 提案 これからの行動指針 「なぜ注力するかで使い分ける」 デザインデータを整えることにこだわる Auto Layout を完璧に整えることにこだわる レイヤー名をすべて正式名称に統一することを必須とする すべてのデザイン知識を AI に与えられると思い込む 目的に応じた必要なデザインから戦略的に整える 公開パターン（ MD3 など） AI は学習済みなので、完璧な構造化は不要 デザインデータを用意するか目的に応じて取捨選択し、余分な中間成果物の作成に工数 をかけない 独自ブランドデザイン 戦略的に AI に情報を与える必要がある DESIGN.md やデザイントークンで、必要な知識を優先度高く伝える すべてを完璧に整えるのではなく、「何を伝えるか」を選別する © 2026 hott3 22
23. TL;DR（Again） 最近の AI モデルは MD3 を理解している デザインデータが整っていなくても、ほぼ見た目通りのコードを出力することができる エンジニアは、 AI に何を期待するかを理解し、戦略を立てる必要がある どんな情報が AI の出力に影響を与えるのか その情報を整えるためにどこまで工数をかけるべきか → 中核的なブランドデザインの実装は、人間と AI がどちらも利用できるように設計し、戦略 的に進めることが重要だと考えます！ © 2026 hott3 23
24. 参考資料 Material 3 Design Kit | Figma https://www.figma.com/community/file/1035203688168086460 Figma MCP の get_design_context は何を返すのか — 実データで読み解く中間表現 https://zenn.dev/yokkomystery/articles/932cacd7728188 Set up the remote server (recommended) | Developer Docs https://developers.figma.com/docs/figma-mcp-server/remote-server-installation/ © 2026 hott3 24