AI駆動なデザイン開発 〜Figma Make でまるっとつくるか、 HTML でシンプルにつくるか〜

Figma Makeが登場したことでデザイン -> 開発のフローは大きく変化すると思います。そんな中、「Tailwind cdnとhtmlで作成するモックアップがとても良い」という噂を見かけました。気になった私は両者について比較してみることに。

#デザインモックアップ
# Project as Code
# PaC
# Claude Code

Transcript

1.  AI 駆動なデザイン開発 Figma Make でまるっとつくるか、 HTML でシンプルにつくるか 株式会社Digeon 東 知哉 2025年7月12日 1
2.  AI 時代のデザイン開発手法の変化 旧来の手法 1. デザイナーがFigmaで手動デザイン 2. 開発者がデザインを見て実装 3. 手戻りや認識齟齬が発生 4. デザインと実装の同期が困難 AI 駆動デザイン開発!!  即座にデザイン確認 数秒でモックアップ生成  高速な反復改善 対話的に修正・調整  意図の正確な理解 自然言語での指示が可能  非デザイナーも参加 専門知識不要でアイデア具現化  コードに落とし込みやすい デザインから実装への橋渡し 2
3.  FIGMA MAKE とは AI を活用したプロトタイプ作成ツール  プロンプトからデザインを生成 - アイデアを数分で編集可能なデザインに変換  インタラクティブなプロトタイプを作れる - 静的なデザインをクリック可能な デモに変換  Webアプリとして公開可能 - React + shadcn/uiを使用してアプリケーションと して動かせる  Claude Sonnet 4 も使える - モデルの精度として申し分なし 3
4.  デモ：同じプロンプトで2 つのツールを比較 同一の要件定義プロンプトを両ツールに投入し、生成されるデザインの精度と特性を比較する  Figma Make プロダクション志向の コンポーネント生成  Claude Code + HTML アーキテクチャ非依存の モックアップ生成 React + shadcn/ui を使用 コンポーネントライブラリベース Tailwind CDN を使用 シンプルなHTML/CSS 4
5.  デモ：実際に指示したプロンプト 以下の要件を満たすデザインモックアップを作ってください [全体のレイアウト] * primaryカラーは緑で、色合いはシンプル。 * 左にサイドバー * 選択している画面がなにかわかるように * 左上にアプリのロゴ * ヘッダーは左側にパンくずリスト、右側にユーザ情報が記載している。 * クリックしたらログアウトやパスワード変更のメニューが表示される [マスタ管理] ユーザ一覧画面 * 全体のレイアウトをつかう * 表示する内容は「ユーザ名、登録日時、メールアドレス、ユーザ種別（管理者 or 一般ユーザ）」 * カード形式とテーブルを切り替えられる。 * ページネーション付き。 * テーブルビューはヘッダークリックでソートできる * 上部にフィルターがついていてユーザ種別で表示を出し分けられる * 行やカードをクリックしたらユーザ詳細に遷移する * カード、行ごとに3点リーダーがついており、クリックするとアクションを選べる。 * その中の削除を選択すると画面手前に削除モーダルが出てくる ユーザ詳細 * ユーザの詳細情報を表示する * 表示する内容は「ユーザ名、登録日時、メールアドレス、ユーザ種別（管理者 or 一般ユーザ）」 5
6.  実際の生成結果 - テーブル表示  CLAUDE CODE + HTML  FIGMA MAKE 6
7.  実際の生成結果 - カード表示  CLAUDE CODE + HTML  FIGMA MAKE 7
8.  実際の生成結果 - 詳細画面  CLAUDE CODE + HTML  FIGMA MAKE 8
9.  実験結果：両者とも同じくらい  指定した緑のプライマリカラーの適用 △ サイドバー付きレイアウトの実現  カード/テーブル表示の切り替え機能 △ ページネーション、ソート、フィルター機能  削除モーダルなどのインタラクション  両者とも内部でLLMを使用しており、インターフェースが違うだけ 結局のところ、投げるプロンプトやコンテキストが重要って話な気がする 9
10.  ではどちらを今後使っていきたいか 単純な優劣ではなく、目的による使い分けが重要  アーキテクチャ非依存 Claude Code + HTML フレームワークに依存しない どんな環境でも使える Project as Codeで一元管理  プロトタイプ・顧客会議 Figma Make 動作するコンポーネント リアルタイム修正 共有が容易 10
11.  デザインを元に実装する上で考えておきたいこと  PROJECT AS CODE 要件定義・デザイン・実装を一つのリ ポジトリで管理  E2E テスト デザイン段階で確保したユーザビリテ ィをプロダクトコードに容易に反映で きるか  フレームワーク選定 Next.js、Vite + Tanstack Routerなど既 存アーキテクチャとの整合性  デザインと実装の同期 要件変更時の反映フローの確立 他にもたくさん... 11
12.  デザインと実装の境界線 デザインモックにアーキテクチャを含めると、デザインの領域を超える  デザインフェーズ ユーザー体験に集中   実装フェーズ アーキテクチャに最適化 関心の分離（Separation of Concerns）の徹底 12
13.  HTML デザインからE2E テストまでの実践フロー   2. data-testid付与 テスト用の セレクタを配置   3. E2Eテスト作成 Playwrightで テストコード生成   4. テスト実行 デザインの 動作確認 このフローにより、デザイン段階でテスタビリティを確保  1. HTML生成 Claude Codeで モックアップ作成 13
14.  HTML モックアップからE2E テストへ  ローカルHTMLファイルでテスト実行 PlaywrightがローカルのHTMLファイルにアクセスしてテストと動画撮影を 実行  デザイン駆動のテスト開発 デザインモック段階で作成されたテストが落ちないようにReactコードを 実装する → UXを維持できる HTMLのdata-testid属性を使用してテストを実装 デザインと同じリポジトリでテストコードを管理 視覚的なレポートで結果を確認 14
15.  PROJECT AS CODE の実践 一つのリポジトリで全てを管理  要件定義  DB設計  API設計  デザインモック  E2Eテスト  実装コード  議事録  コーディングルール  要件定義の更新が各要素に波及し、相互に連携 デザインを含む全要素をリポジトリで一元管理することで、真の価値を発 揮 Single Source of Truth の実現 - AIは全ての文脈を理解し、一貫性を保つ 15
16.  まとめ  FIGMA MAKE 顧客会議でその場で修正できる威力 React + shadcn/uiで即座に実装可能 リリース直前まで持っていってくれる  CLAUDE CODE + HTML アーキテクチャと疎結合 Project as Codeで全体の整合性が保て る どちらが良いという優劣は実際やってみないと分からない 色々試してみよう！ 16
17. ご清聴ありがとうございました  質問やご意見なんでもどうぞ 17