Gemini API × UIデザイン自動化完全ガイド：Figma Make連携からコード生成まで
背景と前提
UIデザインのワークフロー自動化は、もはや「効率化の一施策」ではなく、プロダクト開発の競争力そのものです。2026年現在、Gemini APIの能力向上により、単なる「デザイン生成」ではなく、企業全体のデザインシステムを自動で構築・維持管理することが可能になりましました。
本記事は、中堅～大規模企業向けのUIデザイン自動化ワークフロー構築法を、すべての段階で徹底解説します。単なる「Figmaプラグイン」ではなく、要件定義→プロトタイピング→デザインシステム化→テスト自動化まで、エンドツーエンドの自動化パイプラインを構築するための知識を提供します。
Part 1：デザイン要件の高度な構造化
1.1 従来のアプローチの問題点
従来のUIデザイン業務では、「要件」という曖昧な入力から始まります：
- PRD（Product Requirements Document）が数十ページ
- デザイン方針が口頭で説明される
- ブランドガイドラインは150ページのPDFで、実運用では30%程度しか参照されない
結果として、デザイナーごとに解釈が異なり、複数のバリエーション修正が発生します。
1.2 Gemini APIを使った「意味的構造化」
Gemini 2.0 Flash の登場により、単なる「テキスト分類」ではなく、文脈を理解した構造化が可能になりましました。
import json
from google import genai
from typing import TypedDict
client = genai.Client(api_key="YOUR_GEMINI_API_KEY")
class DesignRequirement(TypedDict):
"""デザイン要件の統一スキーマ"""
project_id: str
business_context: dict
user_personas: list
design_principles: list
color_system: dict
typography_system: dict
component_library: list
accessibility_requirements: dict
performance_constraints: dict
def structure_design_requirements(prd_text: str, brand_guide: str) -> DesignRequirement:
"""
PRDとブランドガイドラインをGeminiで構造化
戻り値: 統一されたJSON形式のデザイン要件
"""
prompt = f"""
あなたはシニアUIデザイナーです。以下のPRDとブランドガイドラインから、
統一されたデザイン要件を構造化してください。
## 構造化対象
1. **business_context**: ビジネスゴール（売上向上、ユーザー満足度、エンゲージメント等）
2. **user_personas**: ペルソナを3～5つ定義。年齢、職業、課題、願望
3. **design_principles**: UIデザインの5つのコア原則
4. **color_system**:
- Primary色（RGB, Hex, WCAG AA/AAA対応度）
- Secondary色、Neutral色の定義
- ダークモード対応色
5. **typography_system**:
- 見出し（H1～H6）のフォント、サイズ、行高
- 本文のフォント、サイズ、読みやすさスコア（自動測定）
6. **component_library**: 再利用可能なコンポーネント（ボタン、カード、フォーム等）
7. **accessibility_requirements**: WCAG 2.1 AAレベル準拠項目
8. **performance_constraints**: ページロード時間、CLS（Cumulative Layout Shift）等
PRD:
{prd_text}
ブランドガイドライン:
{brand_guide}
JSON形式で返してください。説明は不要です。
各項目の値は配列またはオブジェクトで、プログラム処理可能な形式にしてください。
"""
response = client.models.generate_content(
model="gemini-2.0-flash",
contents=prompt
)
try:
design_req = json.loads(response.text)
return design_req
except json.JSONDecodeError:
print("Failed to parse Gemini response")
return None
1.3 実装例：SaaSアプリケーションの場合
以下はSaaSダッシュボードのPRD抜粋です：
【プロジェクト】 Sales Dashboard v3.0
【ビジネスゴール】
- 営業チームの売上予測精度向上
- レポート生成時間を30分→2分に短縮
- ユーザーエンゲージメント +40%
【ペルソナ】
1. 営業マネージャー（35歳男性、10年営業経験、週40h使用）
2. データアナリスト（28歳女性、可視化重視）
3. C-Level経営層（50代、概要のみ必要、速度重視）
【デザイン方針】
- 信頼感（深い青系）とスピード感（緑系アクセント）
- ダークモード必須
- レスポンシブ対応（iPad Min, MacBook Pro 16"）
これを Gemini で構造化すると：
{
"project_id": "sales-dashboard-v3",
"business_context": {
"primary_goal": "sales_forecast_accuracy",
"kpi_targets": {
"report_generation_time": "30m → 2m",
"engagement_increase": "40%"
}
},
"user_personas": [
{
"name": "Sales Manager",
"age": 35,
"role": "sales_leadership",
"experience_years": 10,
"weekly_usage_hours": 40,
"pain_points": ["manual_report_creation", "data_silos"],
"priority_features": ["forecasting_tools", "team_analytics"]
},
{
"name": "Data Analyst",
"age": 28,
"role": "analytics",
"visualization_priority": "high",
"preferred_chart_types": ["heatmap", "scatter", "time_series"]
},
{
"name": "Executive",
"age": 55,
"role": "leadership",
"information_depth": "summary_only",
"speed_criticality": "extreme"
}
],
"design_principles": [
"Trust through clarity",
"Speed through automation",
"Accessibility first",
"Responsive by default",
"Dark mode native"
],
"color_system": {
"primary": {
"hex": "#003D82",
"rgb": "0, 61, 130",
"wcag_aaa_compliant": true
},
"accent": {
"hex": "#00A86B",
"rgb": "0, 168, 107",
"semantic": "positive_action"
},
"dark_mode_primary": "#1A2A3A"
}
}
この構造化により、デザイナーとエンジニア双方が完全に同じ仕様を理解できるようになります。
1.4 複数ステークホルダーの意見統合
さらに実践的な企業環境では、複数の意見をマージする必要があります。
def merge_stakeholder_requirements(
requirements_list: list,
weight_config: dict
) -> dict:
"""
複数のステークホルダーの意見を、重要度を考慮しながらマージ
Args:
requirements_list: 各ステークホルダーの要件リスト
weight_config: 意見の重み付け設定
例) {"product_manager": 0.4, "designer": 0.3, "engineer": 0.2, "user_research": 0.1}
Returns:
統合された最終要件
"""
stakeholders_json = json.dumps(requirements_list, ensure_ascii=False, indent=2)
prompt = f"""
以下の複数ステークホルダーの要件を統合してください。
重み付け設定: {json.dumps(weight_config)}
優先順位：
1. ユーザーリサーチの意見を最優先（0.1の重みだが、根拠のある意見は尊重）
2. プロダクトマネージャーのビジネスゴール（0.4の重み）
3. デザイナーの美的・UX判断（0.3の重み）
4. エンジニアの技術制約（0.2の重み）
矛盾がある場合は、その矛盾を明記し、解決案を3つ提示してください。
ステークホルダー要件：
{stakeholders_json}
JSON形式で返してください。構造は以下の通り：
{{
"merged_requirements": {{ ... }},
"conflicts": [
{{"stakeholder_a": "...", "stakeholder_b": "...", "conflict_description": "...", "solutions": [...]}}
],
"priority_decisions": [...]
}}
"""
response = client.models.generate_content(
model="gemini-2.0-flash",
contents=prompt
)
return json.loads(response.text)
複数の意見が衝突したとき（例：「派手なデザイン」vs「最小限のデザイン」）、Geminiが自動的に根拠に基づいた統合案を提示します。
Part 2：Figma Make との高度な連携
2.1 Figma Make シナリオの自動生成
手作業でFigma Makeシナリオを構築するのは、スケーラビリティに欠けます。Gemini を使って、構造化データから自動的にFigma Makeシナリオを生成しましょう。
def generate_figma_make_scenario(design_requirement: dict) -> str:
"""
デザイン要件から Figma Make シナリオの定義を自動生成
"""
req_json = json.dumps(design_requirement, ensure_ascii=False, indent=2)
prompt = f"""
以下のデザイン要件に基づいて、Figma Make のシナリオ定義を生成してください。
シナリオ名：
- 命名規則: {{project}}_{{variant}}_v{{version}}
- 例：sales-dashboard_dark-mode_v1
トリガー:
- Webhook受信のJSON スキーマ定義
ステップ（Actions）:
1. フレーム作成
2. コンポーネント挿入
3. カラー適用
4. タイポグラフィ適用
5. レイアウト自動化（アルゴリズムパターンの指定）
6. バリエーション複製
7. Slackへの通知
8. 成果物のクラウドストレージ保存
デザイン要件：
{req_json}
JavaScript/JSON形式で、実際に Figma Make にインポート可能な定義を出力してください。
"""
response = client.models.generate_content(
model="gemini-2.0-flash",
contents=prompt
)
return response.text
2.2 デザイン・バリエーションの自動組み合わせ
単なる「3つのバリエーション」ではなく、より体系的なバリエーション生成：
def generate_design_matrix(
design_req: dict,
dimensions: list = None
) -> dict:
"""
デザイン要件から、複数軸のバリエーションマトリクスを生成
デフォルト軸:
- Color Density: light, normal, dark
- Information Density: minimal, balanced, dense
- Typography: clean, playful, formal
- Animation: none, subtle, prominent
"""
if dimensions is None:
dimensions = ["color_density", "info_density", "typography", "animation"]
prompt = f"""
以下のデザイン要件に基づいて、{len(dimensions)} 軸のバリエーションマトリクスを定義してください。
軸:
{json.dumps(dimensions)}
各軸の値：
- color_density: ["light", "normal", "dark"]
- info_density: ["minimal", "balanced", "dense"]
- typography: ["clean", "playful", "formal"]
- animation: ["none", "subtle", "prominent"]
生成対象：
- 各組み合わせ（全{3**4}=81パターン）に対して、デザインの指針を記述
- 例：(light, minimal, clean, none) → ミニマルな医療アプリに最適
- 実装チェックリスト（どのComponentライブラリの要素を使うか）
デザイン要件：
{json.dumps(design_req, ensure_ascii=False, indent=2)}
JSON形式で返してください。構造：
{{
"matrix": [
{{
"variant_id": "v001",
"dimensions": {{"color_density": "light", "info_density": "minimal", ...}},
"description": "...",
"use_cases": ["..."],
"component_guidelines": [...]
}}
]
}}
"""
response = client.models.generate_content(
model="gemini-2.0-flash",
contents=prompt
)
return json.loads(response.text)
このマトリクスアプローチにより、81パターンのバリエーションから、自社プロダクトに最適な設定を自動選別できます。
2.3 Figma → JSON 双方向同期
Figma に変更があるたびに手動でスキーマを更新するのは非効率です。自動同期を実装しましょう：
import asyncio
from datetime import datetime
async def sync_figma_to_design_tokens(
figma_file_key: str,
gemini_client
) -> dict:
"""
Figma ファイルから Design Tokens を自動抽出・Gemini で分析・JSON化
"""
# Step 1: Figma API から最新のコンポーネント・トークン取得
figma_data = await fetch_figma_api(figma_file_key)
# Step 2: Gemini でトークンを分析・統合
analysis_prompt = f"""
以下の Figma コンポーネント定義から、Design Tokens を自動抽出してください。
Figma Components:
{json.dumps(figma_data['components'], ensure_ascii=False)}
出力:
- Color Tokens: #HEX値から意味的な名前（primary, success, alert）に変換
- Typography Tokens: フォント設定から reusable な定義に
- Spacing Tokens: パディング・マージン値を統一
- Shadow Tokens: シャドウ定義の正規化
JSON形式で返してください。構造：
{{
"colors": {{"primary": "...", "success": "..."}},
"typography": {{"h1": {{"font_family": "...", "size": "..."}}}},
"spacing": {{"xs": "4px", "sm": "8px", ...}},
"shadows": {{...}}
}}
"""
response = await gemini_client.models.generate_content(
model="gemini-2.0-flash",
contents=analysis_prompt
)
design_tokens = json.loads(response.text)
# Step 3: 前回との diff を計算
previous_tokens = load_previous_design_tokens()
diff = calculate_token_diff(previous_tokens, design_tokens)
# Step 4: 変更内容を記録（Git / S3）
save_token_history({
"timestamp": datetime.now().isoformat(),
"figma_file_key": figma_file_key,
"tokens": design_tokens,
"diff": diff,
"changes_summary": generate_changelog(diff)
})
return design_tokens
Part 3：デザインシステムの自動生成と維持管理
3.1 コンポーネント ライブラリの自動インベントリ
企業規模のデザインシステムでは、数百～数千のコンポーネントが存在します。Gemini を使ってこれを自動分類・整理します：
def auto_organize_design_components(
figma_components: list,
design_req: dict
) -> dict:
"""
Figma コンポーネントを自動的に分類・整理
出力：Component Library の構造化定義
"""
components_json = json.dumps(figma_components, ensure_ascii=False)
req_json = json.dumps(design_req, ensure_ascii=False)
prompt = f"""
以下の Figma コンポーネント群を、Atomic Design に基づいて階層化してください。
階層:
1. **Atoms** （基本単位）: Button, Input, Icon, Label等
2. **Molecules** （組み合わせ）: SearchBox (Input + Icon), FormField (Label + Input + Error)
3. **Organisms** （複合体）: Header, Footer, Card, Modal等
4. **Templates** （テンプレート）: Page layouts
各レベルに対して：
- コンポーネント名
- Props 定義（型、デフォルト値）
- バリアント（size, color, state等）
- アクセシビリティ属性（role, aria-label等）
- 使用例
コンポーネント群:
{components_json}
デザイン要件:
{req_json}
JSON形式で返してください。構造：
{{
"atoms": [
{{
"name": "Button",
"props": {{"variant": ["primary", "secondary"], "size": ["sm", "md", "lg"]}},
"accessibility": {{"role": "button"}},
"figma_component_id": "..."
}}
],
"molecules": [...],
"organisms": [...],
"templates": [...]
}}
"""
response = client.models.generate_content(
model="gemini-2.0-flash",
contents=prompt
)
component_library = json.loads(response.text)
# Library を Storybook 形式で出力することも可能
return component_library
3.2 コンポーネントの使用ガイドラインの自動生成
各コンポーネントに対して、「いつ使うべきか」「いつ使わないべきか」を自動生成：
def generate_component_guidelines(
component: dict,
design_system: dict
) -> str:
"""
各コンポーネントの使用ガイドラインを自動生成
"""
prompt = f"""
以下のコンポーネントについて、詳細な使用ガイドラインをMarkdown形式で作成してください。
## ガイドラインの必須セクション
1. **概要（Purpose）**
- このコンポーネントの役割
- 「ボタン」なのか「リンク」なのか、どう使い分けるか
2. **いつ使うべきか（When to Use）**
- 具体的なユースケース 3～5つ
- 図解例
3. **いつ使わないべきか（When Not to Use）**
- よくある間違い
- 代替案
4. **Props リファレンス**
- 全 Props の説明
- 型、デフォルト値、例
5. **状態（States）**
- default, hover, active, disabled, loading, error
- 各状態の見た目と振る舞い
6. **アクセシビリティ**
- スクリーンリーダーへの対応
- キーボード操作
- コントラスト（WCAG AA/AAA）
7. **レスポンシブ対応**
- モバイル（320px）、タブレット（768px）、デスクトップ（1920px）での見た目
- 折り返し、サイズ縮小のルール
8. **パフォーマンス**
- コンポーネント単体でのレンダリング時間
- バンドルサイズ
- 最適化のヒント
9. **よくある質問（FAQ）**
- デザイナーとエンジニアからよく出る質問
コンポーネント定義:
{json.dumps(component, ensure_ascii=False, indent=2)}
デザインシステム全体:
{json.dumps(design_system, ensure_ascii=False, indent=2)}
Markdown形式で詳細ガイドラインを作成してください。
"""
response = client.models.generate_content(
model="gemini-2.0-flash",
contents=prompt
)
return response.text
この自動生成により、「Figmaのコンポーネント更新 → Markdownガイドライン自動更新 → Wiki/Storybook自動反映」というパイプラインが完成します。
Part 4：HTMLコード自動生成と品質管理
4.1 デザイン → コード の完全自動変換
Figma デザインをスクリーンショット化し、Gemini で解析・HTML/CSS自動生成：
async def design_to_code(
figma_file_url: str,
component_name: str,
output_format: str = "react"
) -> dict:
"""
Figma デザイン → HTML/CSS/React JSX 自動生成
Args:
figma_file_url: 対象の Figma ファイル URL
component_name: 変換対象のコンポーネント名
output_format: "html", "react", "vue", "svelte"
Returns:
{"code": "...", "styles": "...", "accessibility_score": 0.85, ...}
"""
# Step 1: Figma デザインのスクリーンショット取得
screenshot_url = await generate_figma_screenshot(figma_file_url, component_name)
screenshot_data = await download_image(screenshot_url)
# Step 2: Gemini で解析・コード生成
if output_format == "react":
code_prompt = f"""
以下の Figma デザイン画像を、React JSX で実装してください。
要件:
- Tailwind CSS を使用
- Responsive design (mobile: 320px, tablet: 768px, desktop: 1920px)
- TypeScript の型定義を含める
- Accessibility（WCAG 2.1 AAA準拠）を最優先
- Props は完全にカスタマイズ可能に
- Storybook との互換性を確保
出力形式:
```tsx
export interface {component_name}Props {{
// Props定義
}}
export const {component_name}: React.FC<{component_name}Props> = (props) => {{
// 実装
}};
不要な説明は不要。コードのみを出力してください。
"""
else:
code_prompt = f"Generate {output_format} code from this Figma design..."
# Gemini へ画像を送信
response = await client.models.generate_content(
model="gemini-2.0-flash-vision", # Vision-capable model
contents=[
{
"type": "image",
"source": {"data": screenshot_data}
},
{
"type": "text",
"text": code_prompt
}
]
)
generated_code = response.text
# Step 3: 生成コードの品質評価
quality_check = await validate_generated_code(generated_code, component_name)
# Step 4: 関連する CSS / Tailwind config の自動生成
style_response = await client.models.generate_content(
model="gemini-2.0-flash",
contents=f"""
以下の React コンポーネントに対して、Tailwind CSS の custom config（if needed）を生成してください。
React Component:
{generated_code}
出力:
module.exports = {{
theme: {{
extend: {{
colors: {{ ... }},
spacing: {{ ... }},
...
}}
}}
}}
"""
)
return {
"component_name": component_name,
"format": output_format,
"code": generated_code,
"styles": style_response.text,
"quality_metrics": quality_check,
"accessibility_score": quality_check.get("a11y_score", 0),
"responsive_score": quality_check.get("responsive_score", 0),
"generated_at": datetime.now().isoformat()
}
### 4.2 コード品質の自動チェック
生成されたコードが本当に「プロダクション品質」かを自動検証：
```python
async def validate_generated_code(code: str, component_name: str) -> dict:
"""
生成コードの品質チェック
- Accessibility（スクリーンリーダー対応）
- TypeScript 型安全性
- パフォーマンス（Bundle size, Render time）
- テストカバレッジの推奨方針
"""
validation_prompt = f"""
以下の React コンポーネントコードについて、品質チェックを実施してください。
チェック項目:
1. **Accessibility（満点100）**
- role 属性の適切性
- aria-label / aria-describedby の実装
- keyboard navigation対応
- color contrast（WCAG AA: 4.5:1, AAA: 7:1）
2. **TypeScript型安全性（満点100）**
- 全てのProps が型定義されているか
- any型を使用していないか
- Generic型の活用
3. **パフォーマンス（満点100）**
- 不要な re-render がないか（useMemo, useCallback）
- 画像は lazy loading か
- CSS-in-JS のバンドルサイズ
4. **Responsive Design（満点100）**
- mobile, tablet, desktop で動作するか
- flex/grid の使い分けは適切か
5. **テスト可能性（満点100）**
- data-testid 属性は十分か
- ロジックは関数で分離されているか
出力JSON形式:
{{
"accessibility_score": 85,
"accessibility_issues": ["aria-labelがない", ...],
"accessibility_fixes": ["<button aria-label='Close'>...</button>"],
"typescript_score": 90,
"typescript_issues": [...],
"performance_score": 88,
"performance_issues": [...],
"responsive_score": 92,
"responsive_issues": [...],
"testability_score": 85,
"testability_issues": [...],
"overall_score": 88,
"critical_issues": [...],
"recommendations": [...]
}}
コンポーネント:
{code}
"""
response = await client.models.generate_content(
model="gemini-2.0-flash",
contents=validation_prompt
)
return json.loads(response.text)
4.3 テストコードの自動生成
コンポーネントコードと同時に、テストコードも自動生成：
async def generate_component_tests(
component_code: str,
component_name: str
) -> dict:
"""
React コンポーネントの自動テスト生成
- Unit Tests (Jest + React Testing Library)
- Visual Regression Tests (Percy等との連携)
- A11y Tests
"""
test_prompt = f"""
以下のReactコンポーネントに対して、包括的なテストスイートを生成してください。
テストフレームワーク: Jest + React Testing Library
A11y Testing: jest-axe
テスト対象:
1. **Props rendering**
- 各Propsの値が正しく反映されるか
- デフォルト値が機能するか
2. **User Interactions**
- クリック時の動作
- フォーム入力時の動作
- キーボード操作（Enter, Tab等）
3. **Accessibility**
- スクリーンリーダー対応（jest-axe）
- キーボード操作可能
- color contrast チェック
4. **Edge Cases**
- empty state
- loading state
- error state
- long text overflow
5. **Responsive Design**
- 異なるスクリーンサイズでの動作
コンポーネント:
{component_code}
出力:
```typescript
import {{ render, screen }} from '@testing-library/react';
import {{ axe, toHaveNoViolations }} from 'jest-axe';
import {component_name} from './{component_name}';
describe('{component_name}', () => {{
// テストケース
}});
"""
response = await client.models.generate_content(
model="gemini-2.0-flash",
contents=test_prompt
)
return {
"unit_tests": response.text,
"test_command": "jest --coverage",
"minimum_coverage_target": 80
}
## Part 5：ユーザビリティテストの自動化
### 5.1 プロトタイプからのA/Bテスト設定自動生成
```python
def generate_ab_test_setup(
design_variants: list,
user_personas: list
) -> dict:
"""
複数のデザイン案から、最適なA/Bテスト構成を自動生成
出力: Analytics segment、Hypothesis、Success metrics
"""
variants_json = json.dumps(design_variants, ensure_ascii=False)
personas_json = json.dumps(user_personas, ensure_ascii=False)
prompt = f"""
以下のデザイン案とペルソナを踏まえて、A/Bテスト計画を立案してください。
デザイン案:
{variants_json}
ペルソナ:
{personas_json}
出力:
{{
"test_name": "Dashboard Color Scheme v3.0",
"test_duration_days": 14,
"sample_size_per_variant": 5000,
"variants": [
{{
"variant_id": "control",
"name": "現在のデザイン",
"hypothesis": "ベースライン",
"audience_segment": "全ユーザー"
}},
{{
"variant_id": "dark_mode",
"name": "ダークモード",
"hypothesis": "ダークモード使用ユーザーの満足度が +15% 向上する",
"audience_segment": "evening_users (18:00~翌6:00)",
"persona_match": ["Sales Manager", "Data Analyst"]
}}
],
"success_metrics": [
{{
"metric_name": "page_load_time",
"baseline": 2.3,
"target": 2.1,
"unit": "seconds"
}},
{{
"metric_name": "task_completion_rate",
"baseline": 0.87,
"target": 0.92
}},
{{
"metric_name": "user_satisfaction",
"baseline": 7.2,
"target": 8.0,
"survey_questions": ["このUIは理解しやすいですか？", "操作は直感的ですか？"]
}}
],
"statistical_confidence_level": 0.95,
"estimated_runtime_hours": 336
}}
"""
response = client.models.generate_content(
model="gemini-2.0-flash",
contents=prompt
)
return json.loads(response.text)
5.2 ユーザーテスト結果の自動分析
async def analyze_user_test_results(
test_results: dict,
design_variants: list
) -> dict:
"""
ユーザーテスト結果（定量 + 定性）を自動分析
→ 改善提案を自動生成
"""
results_json = json.dumps(test_results, ensure_ascii=False)
variants_json = json.dumps(design_variants, ensure_ascii=False)
analysis_prompt = f"""
以下のユーザーテスト結果を分析して、デザイン改善案を提示してください。
テスト結果:
{results_json}
テスト対象デザイン案:
{variants_json}
分析項目:
1. **統計的有意性**
- 各メトリクスで有意差は検出されたか（p < 0.05）
- サンプルサイズは十分だったか
2. **ユーザーセグメント別分析**
- ペルソナごとに結果は異なるか
- 各ペルソナに最適な案は何か
3. **定性フィードバック分析**
- ユーザー音声（user feedback）からの重要な洞察
- Sentiment Analysis（ポジティブ/ネガティブ）
4. **改善提案**
- 統計的に優れた要素を統合
- 弱点を補完する設計変更
5. **次フェーズのテスト計画**
- さらなる改善が必要な箇所
- 次のA/Bテストで検証すべき仮説
出力JSON:
{{
"winning_variant": "dark_mode",
"winning_metrics": ["page_load_time", "task_completion_rate"],
"losing_metrics": ["user_satisfaction"],
"segment_analysis": [
{{
"segment": "evening_users",
"winning_variant": "dark_mode",
"improvement_percentage": 23.5
}}
],
"qualitative_insights": [
{{
"theme": "Navigation complexity",
"sentiment": "negative",
"frequency": 45,
"example_quote": "..."
}}
],
"improvement_recommendations": [
{{
"recommendation": "Merge dark mode colors with current information layout",
"implementation_effort": "high",
"expected_impact": "23% improvement in load time"
}}
],
"next_test_hypothesis": "Dark mode + simplified navigation will improve satisfaction by 15%"
}}
"""
response = await client.models.generate_content(
model="gemini-2.0-flash",
contents=analysis_prompt
)
return json.loads(response.text)
Part 6：エンタープライズレベルの実装パターン
6.1 マルチプロダクト管理
複数プロダクトのデザイン資産を一元管理：
class DesignSystemOrchestrator:
"""
複数プロダクト・複数チームのデザインシステムを一元管理
"""
def __init__(self, gemini_client):
self.client = gemini_client
self.products = {}
async def sync_all_design_systems(self):
"""
全プロダクトのデザインシステムを同期
- Figma から最新コンポーネント抽出
- デザイントークン統合
- コンフリクト検出
"""
# 全プロダクトのFigmaファイルを並列で同期
sync_tasks = [
self.sync_product_design(product_id)
for product_id in self.products.keys()
]
results = await asyncio.gather(*sync_tasks)
# 全プロダクト間での共通コンポーネント検出
common_components = self.detect_shared_components(results)
# 共通コンポーネント化の提案
consolidation_proposal = await self.propose_component_consolidation(
common_components
)
return {
"sync_results": results,
"consolidation_proposal": consolidation_proposal,
"status": "completed"
}
async def detect_consistency_issues(self) -> list:
"""
全プロダクト間での不整合を検出
- カラーシステムの矛盾
- タイポグラフィの違い
- コンポーネント実装の違い
"""
consistency_check_prompt = f"""
以下の複数プロダクトのデザインシステムを比較して、
一貫性を欠く箇所を検出してください。
{json.dumps(self.products, ensure_ascii=False)}
検出対象:
1. Color inconsistencies
2. Typography misalignment
3. Spacing scale differences
4. Component API differences
5. Naming convention violations
出力: [{{
"issue_type": "color_inconsistency",
"products": ["product_a", "product_b"],
"details": "Primary blue is #0066CC in product_a, #0052A3 in product_b",
"recommendation": "Use #0066CC as enterprise standard"
}}]
"""
response = await self.client.models.generate_content(
model="gemini-2.0-flash",
contents=consistency_check_prompt
)
return json.loads(response.text)
Part 7：パフォーマンス最適化
7.1 自動生成コードのバンドルサイズ最適化
async def optimize_bundle_size(
component_code: str,
component_name: str
) -> dict:
"""
生成されたコンポーネントのバンドルサイズを自動最適化
- 不要なDependency削除
- Tree-shaking 対応
- CSS-in-JS → CSS Module化
"""
optimization_prompt = f"""
以下のReactコンポーネントのバンドルサイズを最適化してください。
目標:
- 初期バンドル < 50KB
- Tree-shaking 対応
- Code splitting 候補の提示
最適化手法:
1. 不要なライブラリ削除（lodash → native）
2. 条件付きimport（React.lazy）
3. CSS Module への変換
4. SVG → icons library への統合
コンポーネント:
{component_code}
出力:
{{
"original_size": {{
"minified": "74 KB",
"gzipped": "22 KB"
}},
"optimized_size": {{
"minified": "42 KB",
"gzipped": "13 KB"
}},
"improvements": [
{{
"type": "dependency_removal",
"library": "lodash",
"savings": "12 KB",
"before": "import _ from 'lodash'",
"after": "const keys = (obj) => Object.keys(obj)"
}}
],
"code_splitting_recommendations": [
{{
"split_point": "Modal component",
"estimated_savings": "8 KB",
"usage_pattern": "Low frequency user action"
}}
]
}}
"""
response = await client.models.generate_content(
model="gemini-2.0-flash",
contents=optimization_prompt
)
return json.loads(response.text)
Part 8：よくある実装課題と解決方法
Q1: 「Geminiの出力が毎回異なる」場合は？
解決： Temperature パラメータを 0 に設定し、出力を決定論的にします。
response = client.models.generate_content(
model="gemini-2.0-flash",
contents=prompt,
generation_config=genai.types.GenerationConfig(
temperature=0.0, # 完全に決定論的
top_p=1.0
)
)
Q2: 「生成コードが実際には動作しない」場合は？
解決： 生成後に自動テストを実行し、失敗したら Gemini でリビジョンを要求します。
async def generate_with_verification(design_requirement):
max_retries = 3
for attempt in range(max_retries):
code = await generate_component_code(design_requirement)
test_result = await run_automated_tests(code)
if test_result["passed"]:
return code
# テスト失敗時はGeminiに修正を要求
fix_prompt = f"""
以下のテストが失敗しました:
{test_result['failures']}
コードを修正してください:
{code}
"""
design_requirement["context"] = fix_prompt
Q3: 「複数チームの意見が衝突する」場合は？
解決： Gemini に仲裁をさせ、根拠に基づいた決定を記録します。
def resolve_design_conflict(
opinion_a: dict,
opinion_b: dict,
decision_criteria: list
) -> dict:
"""
チーム間の意見対立を、根拠に基づいて解決
"""
arbitration_prompt = f"""
デザイン意見の対立を解決してください。
Team A: {json.dumps(opinion_a)}
Team B: {json.dumps(opinion_b)}
判断基準:
{json.dumps(decision_criteria)}
判断:
1. どちらの意見が基準を満たしているか
2. 統合案は存在するか
3. 最終決定とその根拠
"""
response = client.models.generate_content(
model="gemini-2.0-flash",
contents=arbitration_prompt
)
# 決定を監査ログに記録
save_decision_log({
"timestamp": datetime.now(),
"conflict": {"opinion_a": opinion_a, "opinion_b": opinion_b},
"resolution": response.text,
"status": "decided"
})
個人開発者の視点から（実体験メモ）
ここまでの要点
Gemini API × UIデザイン自動化は、単なる「デザイン生成」ではなく、企業全体のデザイン戦略を体系化し、実行する仕組みです。
本ガイドで学べた内容：
- 要件の高度な構造化 → ステークホルダー間の完全な理解統一
- Figma Make との連携 → 複数バリエーション自動生成
- デザインシステムの自動化 → 数百～数千コンポーネントの一元管理
- コード生成と品質管理 → プロダクション品質の自動化
- ユーザビリティテストの自動化 → データ駆動型デザイン進化
- エンタープライズ管理 → 複数プロダクト・複数チームの統合
2026年のデザインチームは、「AIとの協働」を前提に組織設計されるべき時代です。このガイドを参考に、あなたのプロダクトに最適な自動化パイプラインを構築してください。