はじめに
Figma Makeは、Figmaが提供するAI搭載の新しいデザイン支援サービスです。
従来のFigmaの操作性を活かしつつ、AIチャットを通じてプロンプト（指示文）を入力するだけで、UIデザインやプロトタイピングを自動生成できるのが最大の特徴です。
Figma Makeの良いところ
ブラウザ完結で作業できる
ビルド環境を作らずとも画面イメージを見ながら修正を加えられるので、初期画面イメージへの到達が速いです。
モックの特定位置を指定して修正することができる
プロンプトを入力だけでなく、モックの特定位置を指定してスタイルを調整することもできます。
特定位置を指定して、プロンプトで修正指示することもできます。
ソースコードをDLできる
画面イメージと共にソースコードが作成されます。ソースコード一式はDL可能です。
コードを見ながら修正指示を出せるので、モック作成にとじず、普通にAIコーディングの体験です。
試しにつくったもの
今後の開発現場への示唆
AIツール統合の最適解
Figma Makeの本質的な価値は、1つのツールで全機能を完結させることではなく、開発フローに沿ってAIツールを適材適所で組み合わせることにあります。
Figma Makeはあくまで「プロト実装」を担う位置づけであり、そのままプロダクションコードとして利用するものではありません。
Figma Makeのアウトプットをどのように実装フローへ受け渡し、実装チームがスムーズに引き継げる状態にするかを整理しておくことが重要です。
プロンプト集
使用したプロンプト（指示文）をメモしていきます📝
機能の作成
機能の作成
BtoBSaaSのログインフォームとログイン後のトップページを作成して。
- メールアドレス・パスワード認証
- **デモアカウント**:管理者: `admin@company.com` / `password123`
- **認証状態管理**: Zustandによる永続化
機能の追加
管理者用の機能を実装しましょう。BtoB SaaSを想定し、メニューパネルを追加
技術スタックを指定する
BtoBSaaSのログインフォームとログイン後のトップページを作成して。
| インフラ | AWS |
| フレームワーク| Next.js 14, TypeScript |
| ルーティング | App Router |
| ディレクトリ設計 | Feature-based Architecture |
| スタイリング | Tailwind CSS|
| 状態管理 | Zustand |
| フォーム管理 | React Hook Form |
| HTTP通信 | Axios |
| API モック | Mock Service Worker |
| エラー処理 | react-error-boundary |
| バリデーション | Zod, Yup |
| 日付処理 | Day.js |
| UI コンポーネント | Radix UI |
| アニメーション | Framer Motion|
| アイコン | Lucide React |
| 型生成 | OpenAPI Generator |
| 認証 | NextAuth.js|
| 国際化 | next-i18next |
| 通知 | React Hot Toast|
| ドラッグ&ドロップ | React DnD, dnd kit |
| チャート/グラフ | Recharts|
| テーブル | TanStack Table |
| ファイルアップロード | React Dropzone, Uppy |
バックエンドの動作を考慮させる
ログイン認証は以下の挙動とします。
rect rgba(255, 182, 193, 0.3)
Note over User, Social: 1. ユーザー登録フロー - 新規アカウント作成とメール確認
User->>React: 1.1 新規登録画面アクセス
React->>User: 1.2 登録フォーム表示
User->>React: 1.3 ユーザー情報入力・送信
React->>Spring: 1.4 POST /api/register
Spring->>Cognito: 1.5 adminCreateUser()
Cognito-->>Spring: 1.6 ユーザー作成完了
Spring->>RDS: 1.7 ユーザープロファイル情報保存<br/>(INSERT INTO users)
RDS-->>Spring: 1.8 DB保存完了
Spring->>KC: 1.9 ユーザー情報同期<br/>(REST API)
KC-->>Spring: 1.10 同期完了
Spring-->>React: 1.11 登録成功レスポンス
React->>User: 1.12 確認メール送信案内
end
rect rgba(176, 224, 230, 0.3)
Note over User, Social: 2. メール確認フロー - アカウント有効化
Cognito->>SES: 2.1 確認メール送信要求
SES->>User: 2.2 確認メール送信
User->>Cognito: 2.3 確認リンククリック
Cognito->>Spring: 2.4 アカウント有効化通知<br/>(Webhook)
Spring->>RDS: 2.5 ユーザーステータス更新<br/>(UPDATE users SET status='ACTIVE')
RDS-->>Spring: 2.6 DB更新完了
Cognito-->>User: 2.7 アカウント有効化完了画面
end
国際化対応を施す(i18n)
i18nを用いた、メッセージ管理としてください。
# ディレクトリ構成
/i18n
/locales
/ja/*.json
/en/*.json
/schema
messages.schema.json # JSON構造バリデーション
keys.map.json # サーバcode→i18nキーのマップ（単一真実）
i18n.config.ts # i18next 設定
extract.config.mjs # 抽出ルール
実装→ドキュメントにまとめる
機能一覧を作成
提供される業務要求書・業務フローから実装すべきシステム機能を体系的に抽出し、
機能一覧をmdファイルにまとめてください。
## 出力形式
以下のテーブル構造で出力：
| 機能分類(L1) | 機能分類(L2) | システム機能ID | システム機能名 | 処理方式 | 関連業務ID | システム機能概要 |
## 抽出基準
1. 機能粒度: 1つのユーザー操作で完結する最小単位
2. 処理方式: 画面/バッチ/API/連携処理を明確に分類
3. 機能ID: [機能分類L1のアルファベット頭文字2文字][連番2桁]形式
4. 概要記述: 「何を」「どう処理し」「何を出力するか」の3要素必須
コンポーネント一覧を作成
カテゴリ別にUIコンポーネントを一覧をmdファイルにまとめて。
API一覧を作成
API一覧をmdファイルにまとめて。
全画面から呼ばれるAPIを漏れなく一覧にして、mdファイルにまとめて。
## 出力形式
以下のテーブル構造で出力：
| 画面名| 呼び出しイベント| API種別|API名|
OPENAPI定義書を作成して。
OpenAPI定義ファイルが大きくなりすぎる問題は
大規模システム開発でAPI設計をする際によく直面する課題です。
この問題に対処するための方法を紹介します。
- ファイルの分割OpenAPI定義を複数のファイルに分割する
- 外部参照の`$ref`を使用して外部ファイルを参照する
- 繰り返し使用される要素をcomponentsセクションで別ファイルに切り出し
## ディレクトリ構造のサンプル
api-docs/
├── main.yaml # メインのOpenAPI定義ファイル
├── paths/ # エンドポイントの定義
### PJごとに定義される業務領域
│ ├── users.yaml # ユーザー関連のパス
│ ├── products.yaml # 製品関連のパス
│ └── orders.yaml # 注文関連のパス
│
│
├── components/ # 再利用可能なコンポーネント
### PJごとに定義される業務領域
├── schemas/ # データモデルのスキーマ
│ ├── user.yaml # ユーザースキーマ
│ ├── product.yaml # 製品スキーマ
│ └── order.yaml # 注文スキーマ
### 方式設計である程度共通化 + 一部 PJごとに定義変更/追加
├── parameters/ # 共通パラメータ
│ ├── pagination.yaml # ページネーションパラメータ
│ └── filters.yaml # フィルタリングパラメータ
### 方式設計である程度共通化 + 一部 PJごとに定義変更/追加
├── responses/ # 共通レスポンス
│ └── errors.yaml # エラーレスポンス
### 方式設計である程度共通化 + 一部 PJごとに定義変更/追加
└── security-schemes/ # セキュリティスキーム
└── oauth2.yaml # OAuth2設定
画面遷移図を作成
画面遷移図をmermaidでmdファイルにして
機能俯瞰図を作成
システム機能一覧を基に、論理的なサブシステム分割とシステム全体の情報フローを可視化したシステム機能俯瞰図をmdファイルにまとめてください。
## 出力形式
graph TD
subgraph "外部システム"
[外部システム定義]
end
subgraph "システム利用者"
[利用者定義]
end
subgraph "メインシステム"
[サブシステム構成]
end
[関連線と情報フロー]
### システムフロー図を作成
```md
業務フロー・システム機能一覧・業務階層定義を基に、システム処理の流れを可視化したシステムフローをmdファイルに作成してください。
## 出力形式
### 1. フロー概要
- **対象業務**: [業務階層定義レベル3名]
- **処理概要**: [処理の目的と全体像]
- **関連アクター**: [利用者・外部システム一覧]
### 2. Sequence Diagram
sequenceDiagram
participant [アクター名]
participant [システム名]
[処理シーケンス]
画面機能設計書の作成
あなたは熟練したUI/UX設計者兼システムアナリストです。包括的な画面機能要件定義をmdファイルで作成してください。出力は本文のみ（Markdown）。解説や前置きは不要。
対象画面：S009 | ユーザー管理画面
## 出力形式
├── 1. 概要
├── 2. Props定義
│ ├── Props一覧表
│ └── 型定義
├── 3. State定義
├── 4. 状態遷移図
├── 5. イベント一覧
│ ├── 5.1 ユーザー操作イベント
│ ├── 5.2 検索・フィルタリングイベント
│ ├── 5.3 データ管理イベント
│ ├── 5.4 UI状態変更イベント
│ └── 5.5 エラー・警告イベント
│
├── 6. エラーハンドリング
└── 7. メッセージ設計
├── 7.1 情報メッセージ
├── 7.2 警告メッセージ
├── 7.3 エラーメッセージ
├── 7.4 成功メッセージ
├── 7.5 操作ガイドメッセージ
├── 7.6 システムメッセージ
└── 7.7 メッセージ表示仕様（表示位置/表示時間）
データモデルを作成
論理データモデル定義の作成
あなたはシニアデータアーキテクトです。
与えられた業務要件・機能要件から、論理データモデル定義（ER図／エンティティ一覧／ドメイン定義／エンティティ定義／コード定義）をmdファイルに作成してください。
曖昧な点は最後に「要確認事項」として列挙し、必要なら仮定を明示して進めてください。
出力形式（Markdown厳守）
1. 見出し構成
- 1. ER図
- 2. エンティティ一覧
- 3. エンティティ定義
- 4. 要確認事項
2. 記述フォーマット
- ER図: Mermaid（erDiagram）を使用。IE表記、PK/FK明示、1:1/1:N の多重度ラベルを日本語で付与。
- エンティティ一覧: 表（列: エンティティID, エンティティ名, エンティティ種別[リソース/イベント/サマリ], エンティティ説明）。
- ドメイン定義: 表（列: ドメインID, ドメイン名, ドメイン説明, データ型, 長さ, 精度, その他定義）。
- エンティティ定義: エンティティごとに表（列: No, 属性名, 属性説明, ドメイン名, データ型, 長さ, 精度, 必須[Y/空], 主キー[番号/空]）。FKは属性名に「(FK)」を付記。
作成ルール
- 一貫性
- すべてのFKは参照先PKと型・粒度を一致させる。
- エンティティ定義の「ドメイン名」「データ型/長さ/精度」は必ずドメイン定義に整合。
- ER図のエンティティ/属性は表の内容と完全一致させる。
- 命名・採番
- エンティティID: EC0001, EC0002, …（欠番なし）。
- 日本語名称を基本。技術的略称が必要なら補足で記載。
- 型ガイド（例）
- ID系: 整数値（長さ: 10, 精度: 0）またはUUID（混在英数字, 長さ: 36）。
- 金額/数量: 整数値または小数値（精度を明示）。
- 日付/日時: 日付, 日時。文字列として表現する場合はフォーマットを「その他定義」に明記。
- フラグ/コード: 半角数字や半角英数字。取り得る値はコード定義に集約。
- 関連・多重度
- 1:1, 1:N, N:M（N:Mは中間エンティティで表現）。
- 任意/必須はFKの必須列で表現（例: 任意関連はFKの必須空欄）。
- 非機能配慮
- 検索キー候補（索引）や一意キーがあればエンティティ定義の備考欄に「[索引候補]」として付記。
- 不確実な属性は「[要確認]」を属性説明に付記し、4. 要確認事項に質問として列挙。
テスト
状態網羅観点のテストケースの作成
状態網羅のテストケースをmdファイルで作成して
## Instructions
1. 提供された情報に基づいて状態図を生成します
2. すべての可能な遷移パスを特定します
3. 各遷移に対するテストケースを生成します
4. エッジケースとエラーケースを含めます
5. テスト優先順位を設定します
## Test Coverage Requirements
- 全状態網羅（すべての状態をカバー）
- 全遷移網羅（すべての遷移をカバー）
- エラー条件網羅（すべてのエラーケースをカバー）
- 境界値テスト（適用可能な場合）
## Expected Outputs
1. Mermaid State Diagram
- すべての状態を表現
- すべての遷移パスを表現
- 条件や注釈の明記
- エラー状態とリカバリーパス
2. テストケース表
- テストケースID
- テスト条件（前提条件）
- テストステップ
- 入力値
- 期待される状態遷移
- 期待される結果
- 検証ポイント
## Example Response
[State Diagram]
stateDiagram-v2
[*] --> OrderEntry
OrderEntry --> StockCheck: submit
StockCheck --> Payment: in stock
StockCheck --> OrderEntry: out of stock
Payment --> OrderComplete: success
Payment --> OrderEntry: failure
OrderComplete --> [*]
note right of StockCheck
Check inventory level
Verify shipping availability
end note
[Test Cases]
| ID | 条件 | ステップ | 入力 | 期待遷移 | 期待結果 | 検証ポイント |
|----|------|----------|------|-----------|-----------|--------------|
| TC01 | 初期状態 | 1. 注文情報入力<br>2. 送信 | 有効な注文情報 | 注文入力 → 在庫確認 | 在庫確認画面表示 | - 入力値の保持<br>- 画面遷移の完了 |
| TC02 | 在庫確認状態 | 在庫チェック実行 | 在庫あり | 在庫確認 → 支払処理 | 支払画面表示 | - 在庫数の更新<br>- 在庫確保状態 |
ホワイトボックステストケースの作成
プログラム構造分析とホワイトボックステスト設計し、mdファイルを作成して
## Expected Analysis Outputs
1. プログラム要素分析
1. 制御構造
- 分岐条件（if-else, switch-case）
- ループ構造（for, while）
- 例外処理（try-catch）
2. データフロー
- 入力パラメータ
- ローカル変数
- グローバル変数
- 戻り値
3. 外部依存
- 外部関数呼び出し
- ファイルI/O
- データベースアクセス
- ネットワーク通信
4. 境界値・制約条件
- パラメータの有効範囲
- null/undefined許容
- 型制約
- サイズ制限
2. カバレッジ基準
1. 命令網羅（C0）
- すべての実行可能な命令を少なくとも1回は実行
2. 分岐網羅（C1）
- すべての判定結果（真/偽）を少なくとも1回は実行
3. 条件網羅（C2）
- 複合条件の各要素の真/偽の組み合わせを網羅
4. 複数条件網羅（C3）
- すべての条件の組み合わせを網羅
## Expected Test Case Table
以下の形式でテストケース表を生成：
| ID | テスト対象 | 条件 | 入力値 | 期待値 | 検証観点 | カバレッジ |
|----|------------|------|---------|---------|------------|------------|
| TC-001 | [メソッド/分岐] | [前提条件] | [入力データ] | [期待される結果] | [検証すべきポイント] | [C0/C1/C2/C3] |
## Example Response
1. プログラム要素分析
1. 制御構造
- 入力値チェック (price <= 0 or quantity <= 0)
- 会員判定 (is_member)
- 金額判定 (total >= 10000, total >= 5000)
2. データフロー
入力:
- price: float (正の数)
- quantity: int (正の整数)
- is_member: bool
内部変数:
- total: float
- discount: float
出力:
- 割引後金額: float
3. 境界値・制約条件
- price > 0
- quantity > 0
- total の境界値: 5000, 10000
2. テストケース表
| ID | テスト対象 | 条件 | 入力値 | 期待値 | 検証観点 | カバレッジ |
|------|------------|------|---------|---------|------------|------------|
| TC01 | 入力値チェック | 無効な価格 | price=-100<br>quantity=1<br>is_member=true | ValueError | エラー処理の動作確認 | C0, C1 |
| TC02 | 入力値チェック | 無効な数量 | price=100<br>quantity=0<br>is_member=true | ValueError | エラー処理の動作確認 | C0, C1 |
| TC03 | 会員割引(大) | 会員、10000円以上 | price=2000<br>quantity=5<br>is_member=true | 8000 | 20%割引の計算 | C0, C1, C2 |
| TC04 | 会員割引(小) | 会員、10000円未満 | price=1000<br>quantity=5<br>is_member=true | 4500 | 10%割引の計算 | C0, C1, C2 |
| TC05 | 非会員割引 | 非会員、5000円以上 | price=1000<br>quantity=6<br>is_member=false | 5700 | 5%割引の計算 | C0, C1, C2 |
| TC06 | 非会員無割引 | 非会員、5000円未満 | price=1000<br>quantity=4<br>is_member=false | 4000 | 割引なしの計算 | C0, C1, C2 |
フロントエンド単体テスト計画の作成
フロントエンド単体テスト計画書をmdファイルにまとめてください。
## テストレベル
| テストレベル | 目的 | テスト対象 | 使用ツール | 特徴・アプローチ |
| --- | --- | --- | --- | --- |
| コンポーネント単体テスト | 個々のコンポーネントの機能を検証 | ・UIコンポーネント（見た目、props、state）・カスタムHooks・Utilities・ビジネスロジック | Jest + React Testing Library | 外部依存をすべてモック化 |
| UIインタラクションテスト | ユーザー操作による振る舞いを検証 | ・フォーム入力・イベントハンドリング・状態変更 | React Testing Library + user-event | 実際のユーザー操作をシミュレート |
| フロントエンド結合テスト | コンポーネント間の連携を検証 | ・ページコンポーネント・機能（Feature）コンポーネント・レイアウトコンポーネント | Jest + React Testing Library + MSW | APIはモック化するが、コンポーネント間は実連携 |
## テストデータ設計要素一覧
| 設計要素 | 目的・役割 | 実装ファイル | 提供機能 | 使用技術 |
| --- | --- | --- | --- | --- |
| フィクスチャ設計 | 固定のテストデータを定義する基本データセット<br>特定のテストシナリオで繰り返し使用される代表的なデータ | `fixtures/users.ts` | ・定型的なテストケース用データ・予測可能な固定値<br>・ベースラインデータセット | TypeScript・JSON |
| テストデータファクトリ設計 | 動的にテストデータを生成するファクトリパターン<br>現実的なデータを生成 | `factories/userFactory.ts` | ・create()メソッド・createMany()メソッド | faker.js |
| モックデータ管理設計 | APIレスポンスなどのモックを管理<br>外部依存の排除 | `mocks/userMock.ts` | ・特定エンドポイントのレスポンス定義・HTTP状態コード制御・リクエスト/レスポンス検証 | MSW(Mock Service Worker) |
| バリエーション設計 | エッジケースや特殊なケース用のデータパターン<br>境界値・異常系テスト対応 | テストヘルパー内 `createVariations()` | ・長い文字列パターン・無効なデータパターン<br>・境界値データセット・エラーケース生成 | Custom Generators |
| データ生成ヘルパー設計 | 複雑なテストデータセットアップを簡略化<br>関連データの一括生成 | `helpers/testDataHelpers.ts` | ・関連データの自動生成・複合オブジェクト作成・テストシナリオ用セットアップ<br>・データリレーション管理 | TypeScript<br>Composition Pattern |
実実装へ移行する
Figma Makeで作成されたコード一式をDLし、GitHub Copilot側で画面機能単位にコンポーネント分離をリファクタリングします。
以降は、GitHub Copilotで実施したものです。
コンポーネント分離の設計の再設計
UIが一つの大きなコンポーネントに集約されている。
細分化したコンポーネント構成をtree形式に整理し、
#コメントを付与して、コンポーネントの責務設計書を作成して
まとめ
Figma Make は、従来のFigmaワークフローに“AIによる設計〜コード生成”を直結させます。
特に、要件定義 → デザイン → プロト → 実装 という従来の分断されたフェーズを、1つの連続体として扱えることによりインパクトを生みます。です。
-
Figma Make は「プロト実装＋コード生成」のAI専用環境であり、デザインチャットの新しい中心になる。
-
プロダクションコードへの直結は目的ではなく、開発生産性の立ち上がり速度を最大化する装置。 企画段階から「実装を見越した画面・コンポーネント構成」が即時生成されるため、初動の数日分を削減できる。
-
Make → Copilot/Calude Code への流れは、フロントエンドの“新しい黄金パターン”になる。 プロト段階で構造化されたUIを出力し、Copilotが責務分離と最適化を行うことで、実装段階の認知負荷が激減する。
-
開発現場では、Makeを“設計ドリブン生成AI”として位置付ける。 生成されたコードは完璧ではないが、UI仕様・API仕様・状態設計のドラフト生成器として極めて優秀。