AI時代、エンジニアの役割は大きく変わりつつあります。かつては「コードを書くこと」が主な仕事でしたが、今は「AIが迷わないように秩序を整えること」へシフトしています。

特にFlutterのUI開発では、Figmaのデザインデータを渡すだけで、AIがコードを自動生成できる時代になりました。一方で、こんな会話を耳にしませんか？

「AIにFigmaを渡せば、一瞬でコードが出るよね」

「いや、まずはデザインシステムを整備しないと、AIも迷っちゃうよ」

「結局、レイヤーをちゃんと構造化しないと使い物にならないよ」

この記事では、Material Design 3（以下MD3）を例に、デザインシステムの「秩序」がAIの出力品質に実際どの程度影響するのかを検証した結果を共有します。そしてそこから得た、実務的な設計・運用の指針をお伝えします。

プロダクト開発では、デザインシステムの整備にかかる工数が無視できません。特にこのような課題があります

• 完璧さへの圧力：完璧に構造化されたデザインデータを用意しないと、AIも出力できないと思い込みやすい
• 工数の不確実性：デザインデータを整えることにかけるべき工数がわからない
• 品質と工数のトレードオフ：整備にどこまで時間をかけるべきか、判断基準がない

具体的な例として、デザインシステムを整備する際に以下のような作業を行うことがあります

• コンポーネント機能による構造化
• レイヤー名の統一
• デザイントークンの設定
• Auto Layoutによる自動レイアウト

これらはいずれも重要に見えますが、本当にすべて必要なのでしょうか？

この問題を解くために、以下の検証を実施しました。

検証の設計

テスト対象

• 検索バーと商品カードの2つのUI要素
• Figma Material Design 3 UI Kitを使用

デザインの構造レベルを少しずつ変化させる

• Figmaデザインの整備度を4段階に変更しながら、同一のプロンプトでAIに出力させる

使用技術

• Flutter 3.41.6 / Dart 3.11.4
• VS Code GitHub Copilot Agent mode
• Claude 4.6 Sonnet
• Figma Remote Server（get_design_contextで取得）

検証結果：構造化度と出力品質の関係

Case 1: 検索バー

構造レベル	MD3準拠のWidget選定	見た目の再現度
高	SearchBarが使用されている✅️	デザインとほぼ同じ見た目
中	SearchBarが使用されている✅️	デザインとほぼ同じ見た目
低	SearchBarが使用されている✅️	デザインとほぼ同じ見た目
0	SearchBarが使用されている✅️	デザインとほぼ同じ見た目

構造レベル0の場合、出力されたコード

SearchBar(
  hintText: 'Hinted search text',
  hintStyle: WidgetStatePropertyAll(
    Theme.of(context).textTheme.bodyLarge?.copyWith(color: colorScheme.onSurfaceVariant),
  ),
  textStyle: WidgetStatePropertyAll(
    Theme.of(context).textTheme.bodyLarge?.copyWith(color: colorScheme.onSurface),
  ),
  backgroundColor: WidgetStatePropertyAll(colorScheme.surfaceContainerHigh),
  shadowColor: const WidgetStatePropertyAll(Colors.transparent),
  leading: Icon(Icons.menu, color: colorScheme.onSurface),
  trailing: [Icon(Icons.search, color: colorScheme.onSurfaceVariant)],
);

Case 2: 商品カード

構造レベル	MD3準拠のWidget選定	見た目の再現度
高	Card / OutlinedButton / FilledButtonが使用されている✅️	デザインとほぼ同じ見た目
中	Card / OutlinedButton / FilledButtonが使用されている✅️	デザインとほぼ同じ見た目
低	Card / OutlinedButton / FilledButtonが使用されている✅️	デザインとほぼ同じ見た目
0	Card / OutlinedButton / FilledButtonが使用されている✅️	デザインとほぼ同じ見た目

重要な気づき

予想と異なる結果：デザインデータの構造を大幅に崩しても、MD3準拠のWidget選定がされ、見た目通りのコードが出力されていました。

これはなぜでしょうか

検証中に気づいたことが1つあります。AIがget_design_context（構造化されたデザインデータ）だけでなく、スクリーンショットの視覚情報も活用していたということです。

つまり、AIは以下のように推論していた可能性があります

1. 視覚情報から判断：スクリーンショットを見て「これは検索バーだ」と認識
2. 学習済みパターンを適用：Flutter × MD3という世界中で公開されているパターンから、最適なWidgetを選定
3. 構造情報での微調整：構造化されたデータがあれば、より精密な実装に

つまり、構造化されていないデザインデータが必ずしも品質を下げるわけではないということです。

視覚情報（スクリーンショット）
  ↓
「これは何か」の認識
  ↓
学習済みパターン（MD3など公開デザインシステム）
  ↓
最適なWidget選定
  ↓
構造化データがあれば、プロパティの微調整

ここからが重要な示唆です。検証結果は、デザインシステムの整備に対する考え方を変える必要があることを示唆しています。

従来のアプローチ（非効率）

• Auto Layoutを完璧に整える
• レイヤー名をすべて正式名称に統一
• すべてのデザイン知識をAIに与えられると思い込む

推奨される新しいアプローチ

目的に応じた戦略的な整備：

• 公開パターン（MD3など）を使う場合
  • AIは学習済みなので、完璧な構造化は不要
  • 視覚情報（スクリーンショット）が提供できれば、Widget選定はほぼ自動
  • デザインデータを用意するか、ラフなスケッチで十分な場合も多い
• 独自ブランドデザインを使う場合
  • 構造化だけでは不十分
  • 自然言語による文脈情報が必要
  • DESIGN.mdなどで、AIが推論しやすい形で情報を与える必要がある

なぜMD3は効率的か

MD3は以下の特徴があります。

• 世界的な標準：Google公式、広く学習されている
• パターンが豊富：ボタン、カード、ナビゲーションなど、ほぼすべてのUIパターンが定義されている
• AIにとって「推論しやすい」：視覚的な特徴が一貫しており、AIが学習パターンを活用しやすい

推奨フロー

1. 要件定義→プロトタイプ検証の段階

この段階では、完璧なデザインシステム整備は不要です。

ラフなスケッチ or 簡単なFigmaデザイン
  ↓
「これはMD3の何に当たるか」をAIに確認
  ↓
簡易的なFlutterコードをAIで生成
  ↓
動作確認・デザイン調整

具体的な実装例

## 要件
- ユーザーが商品を検索できるUI
- 検索結果をリスト表示

## 期待するコンポーネント
- MD3 SearchBar
- MD3 ListTile
- MD3 Card

このレベルの情報で十分です。AIはこれから「MD3の SearchBar と ListTile を組み合わせたUI」を推論できます。

2. プロダクトコードへの実装段階

ここからが本番です。

MD3 UI Kitで、選定したコンポーネントをFigmaで作成
  ↓
デザイントークン（色・タイポグラフィ）をプロダクト用に調整
  ↓
AIに「このFigmaデータからコードを生成」と指示
  ↓
出力されたコード + カスタマイズ

この段階で初めてデザインシステムの整備が活躍します。

理由は以下のとおりです。

• 品質基準が高い：プロダクション環境での使用を想定
• 修正に備える：後々のメンテナンスを考えると、構造化されたデータが有利
• チーム全体で活用：複数のエンジニアが同じコンポーネントを実装する場合、一貫性が必要

効率化のポイント

• 段階に応じた整備度を変える：初期段階では「見た目だけ」、本番段階では「構造化」
• MD3の学習資産を活用：デザイナーやAIも学習済みなので、説明コストが低い
• スクリーンショットを活用：構造化データがなくても、ラフなデザインなら視覚情報で十分

独自ブランドが直面する課題

独自ブランドの場合、MD3とは大きく異なります。

• AIが学習していない：ブランド固有の配色・タイポグラフィ・インタラクションパターン
• 視覚情報だけでは不足：「なぜこの色を選んだのか」「このコンポーネントの使用場面は」という背景が見えない
• チーム内でも認識にばらつき：暗黙知が多く、形式知化されていない

解決策：DESIGN.md の作成

DESIGN.md とは

# Brand Design System Guidelines

## Color Philosophy
このカラーパレットは、ブランドの「親密感」と「信頼性」を表現しています。
- Primary: #2563EB（信頼を表す深い青）
- Accent: #F97316（親密性を表す温かいオレンジ）

## Typography Strategy
- Heading: 大胆で視認性高い
- Body: 読みやすさを優先した適切な行間

## Component Patterns
SearchBar の使用場面：
- 商品検索：フォーカス時にサジェスション表示
- ナビゲーション検索：即座に結果を返す

## Interaction Design
- タップしてから反応するまで：200ms
- アニメーション：easing_out を基本

DESIGN.md が効果的な理由

1. 構造化データでは表現しきれない、設計背景を記述できる
   • なぜこの色か
   • どの場面でこのコンポーネントを使うか
   • ユーザー体験上の制約
2. AIが自然言語で推論しやすい
   • 「親密感」「信頼性」といった感覚的な言葉から、AIは色選定の根拠を理解
   • デザイナーの意図がコード化されやすい
3. チーム全体の認識を統一
   • 構造化されたデータより、自然言語の方が読みやすく理解しやすい
   • 新しいチームメンバーのオンボーディングが容易

実装フロー

1. DESIGN.md の作成

# MYAPP Design System
## Design Philosophy
ユーザーが「安心して、迷わずに」操作できることを目指しています。
## Color Palette
- Primary: プロダクトの核となる信頼性の色
  使用場面：主要なCTA、ナビゲーション
- Secondary: 補完的な情報提示
  使用場面：セカンダリアクション、ハイライト
## Typography
- Title: 情報の階層を明確に
- Body: 最適な読みやすさを実現
## Component Library
### Buttons
- Primary Button：最も重要なアクション
- Secondary Button：補足的なアクション
### Cards
- 商品カード：画像 + 説明 + 価格 + ボタン
  スペーシング：16dp
## Interaction Guidelines
- すべてのアニメーション：cubic-bezier(0.4, 0, 0.2, 1)
- Feedback timing：即座に反応

2. Figmaデザインの構造化

DESIGN.md に沿ってFigmaを整備します。

• コンポーネント化：Guidelines に記載したコンポーネントをすべてコンポーネント化
• レイヤー名：DESIGN.md の用語と一致させる
• デザイントークン：DESIGN.md で定義した色・サイズ・タイポグラフィを使用

3. AIへのプロンプト

たとえば商品検索画面の実装を依頼するときは、次のような骨子でプロンプトを組みます。

依頼内容:商品検索画面を実装してください。
参考資料:DESIGN.md(プロジェクトルートに同梱／ブランドの色哲学・タイポグラフィ戦略・コンポーネント使用場面)、Figma のデザインファイル。
指示:DESIGN.md で定義されたコンポーネントを優先的に使用し、色は Primary / Secondary を基本に、アニメーションは「Interaction Guidelines」に従う。

DESIGN.md のメリット

実装のコツ

DESIGN.md の粒度

• 細かすぎない:より詳細で具体的な表現はコードレベルに落とし込むため
• 理由を含める:「なぜこの色か」という背景を書く
• ユースケースを明記:どの場面で何を使うか具体的に

Figmaとの同期

• DESIGN.md を「唯一の真実」として扱う ※チームで導入しているエージェントツールが参照しやすい箇所を目安に
• Figmaはそれを可視化したもの
• 変更時は必ずDESIGN.md を先に更新し、上流から下流へ反映を進める

AIとの協力

• プロンプトに常にDESIGN.md へのリンクを含める
• 「このDESIGN.md に沿ってください」と明示的に指示
• 出力コードの検証時も「DESIGN.md に照らし合わせて」と確認

これまでの検証と考察から、以下が明らかになりました：

発見

1. AIは視覚情報から推論できる
   • 完璧な構造化がなくても、スクリーンショットがあれば、ある程度のWidget選定は可能
2. 公開パターンは学習済み
   • MD3などの標準デザインシステムはAIが広く学習している
   • したがって、初期段階での完璧な整備は不要
3. 独自ブランドには別の戦略が必要
   • 視覚情報だけでは不足
   • 自然言語によるコンテキスト共有（DESIGN.md）が有効

推奨される実装方法

Material Design 3を使う場合

段階1：要件定義・プロトタイプ
  ├─ ラフなスケッチ or 簡易Figma
  ├─ AIに「何のコンポーネントか」を指示
  └─ 簡易コード生成 → 確認

段階2:プロダクション実装
  ├─ MD3 UI Kitで本格デザイン
  ├─ デザイントークン・Auto Layout を整備
  ├─ AIにコード生成 → 品質の高いコード出力
  └─ プロダクション環境へ

独自ブランドを使う場合

段階1：DESIGN.md の作成
  ├─ ブランド哲学の記述
  ├─ コンポーネント定義
  └─ インタラクションガイドライン

段階2:Figmaの構造化
  ├─ DESIGN.md に沿ったコンポーネント化
  ├─ レイヤー名の統一
  └─ デザイントークン設定

段階3：AIを活用した実装
  ├─ プロンプトに DESIGN.md を参照させる
  ├─ コード生成
  └─ DESIGN.md に照らし合わせた検証

エンジニアの新しい役割

AI時代、エンジニアの役割は変わります：

• NG 「コードをすべて手書きする」
• OK 「AIが迷わないように秩序を整える」
• OK 「出力されたコードを戦略的に検証・調整する」
• OK 「デザイナーとAIの間に立ち、双方を理解する」

これは単なる効率化ではなく、中核的なブランド体験の品質を保ちながら、開発速度を上げるための戦略です。

まとめ

デザインシステムの整備は、「完璧さ」を求める活動ではなく、「目的に応じた必要十分な秩序を作る活動」に転換すべきです。

• 公開パターンを活用する場合：段階的に、必要に応じて整備
• 独自ブランドを開発する場合：DESIGN.md で背景情報を共有し、AIが推論しやすい環境を整備

この戦略によって、デザイナー・エンジニア・AIが協力し、高速にして高品質なプロダクト開発が実現できるようになるはずです。

• Material 3 Design Kit | Figma
• Figma MCP の get_design_context は何を返すのか — 実データで読み解く中間表現
• Set up the remote server (recommended) | Developer Docs