「画像生成 → Figmaでデザイン → AIがコード化」というワークフローは、記事や動画では完璧に見えます。実際に自分の手で回すと、どこに価値があり、どこが足りないかがはっきりします。
この検証では、そのフローを再現しました。動くものが早く出る価値は確かにある。ただしレスポンシブは全く対応できていない——というのが率直な結果です。
この検証の概要
検証時期 | 2026年5月19日〜（検証中） |
|---|---|
ワークフロー | 画像生成 → Figmaでデザインおこし → Figma MCP経由でClaude Codeがコード化 |
実装 | React 19 + Vite 6 + TypeScript |
作ったもの | LPのヘッダーメニューとファーストビュー（Header / Hero / StatsBar、生成画像6点） |
条件 | エージェントスキルなしで実施（素の状態での実力を見るため） |
状況 | 進行中 |
結論：価値は「動くものを見ながら作れる」こと
この検証で最も明確に感じた価値です。
従来はFigmaやMiroで「こんなイメージ」とポチポチしていた認識合わせを、実際に動く成果物を見せながら進められます。
企画の初期段階で効きます。静止画で合意したつもりでも、動かしてみると認識がずれていることは頻繁にあります。動くものを起点にすれば、そのズレを早い段階で潰せます。
想定される使いどころは次のとおりです。
- デザイナー → エンジニアへのラフ受け渡し（「ファーストビューでこんなの作りたい、どうできそう？」）
- 非エンジニア・デザイナー・ディレクターが顧客に「こんなのどうですか」と渡す用途
何を画像にし、何を再構築するか
実装方針として明確な線引きをしています。
要素 | 扱い |
|---|---|
生成画像系（背景・見出し・ダッシュボードUI・ロゴ・アイコン・統計バー） | 画像アセットとして忠実配置 |
ナビ・ボタン・CTA | 実テキスト/実ボタンで再構築 |
「stylizedな部分は画像、テキスト/インタラクションは再構築」という切り分けです。
これは実用的な判断です。装飾的な部分を画像で置けば見た目が早く出ますが、押せるべきものは実装しないと動きません。全部を画像にすると、見た目だけのモックになります。
Figma変数がなくても実装できた
技術的な発見です。
Figma変数が未定義（全て生成ラスター画像）の状態でも、スクリーンショットのネイティブ解像度PNGをアセットとして使えば実装可能でした。
Figma MCPのread系（メタデータ取得 / スクリーンショット取得 / 変数定義取得）でデザイン構造とアセットを取得できることを確認しています。
デザインデータが整っていなくても、見た目の情報さえ渡せば形にはなります。ただしこれは、後述する品質の問題にもつながります。
できていないこと
この検証の価値は、限界を明確にした点にあります。
- 出来上がったコードはほぼベタ書きで、コンポーネント分割が甘い（エンジニア目線では要改善）
- レスポンシブデザインに全く対応しきれていない——画面縮小時に強く感じる
- 素材の作り込み不足により違和感のある箇所が残る
2つ目が最大の課題です。PCで見た目が完成していても、スマホで崩れます。実務のLPではモバイルのほうが重要なことが多く、これは致命的です。
対策として挙げられているのは次の2点です。
- PC/スマホなど各サイズのバージョンを作り分けて読み込めるようにする
- 画面縮小時にメニューが見切れる場合、ハンバーガーメニューで開閉できるようにする
レスポンシブは後から足すものではなく、設計初期から組み込む必要があります。画像ベースで作ると、この設計が抜けやすくなります。
Figmaを経由しないほうが速い場面がある
ワークフロー全体を見直す発見です。
わかりやすい定型部分は、最初にFigmaでデザインを作るより、AIにプロンプトで指示して作らせた方が早い場面があります。
ヘッダーやフッター、よくあるセクション構成など、「よくある形」が決まっているものはデザインを起こす工程自体が無駄になります。
一方、ファーストビューは「ラフ画像 → 生成 → コード化ツールに持ち込み → Figmaにデザイン投入」の順が機能したと記録されています。
全部を同じフローに乗せる必要はありません。要素によって最短ルートが違います。
差別化は「デザインの言語化力」に移る
この検証で得た所感として、最も本質的な部分です。
Figmaの作り方・使い方も含めた単純作業はAIに代替され得る。デザイン未経験者でも少し学べば一定品質のものを作れる可能性がある。
そのうえで、残る価値はこう整理されています。
「良いデザインとは何か」を言語化し、AIに伝えられる力（デザイン原則の理解）を磨くことが重要。
ツールを操作する技能ではなく、出てきたものを評価し、どう直すかを言葉にできることが差別化要素になる——という見立てです。
次の検証：別ツールでの再現
この検証では、次の比較検証も計画されています。
現状フロー | 検証案フロー | |
|---|---|---|
画像生成 | ブラウザ版で生成 | 別ツール内で生成 |
デザイン | Figmaにインポートして調整 | 可能なら画像を逆輸入して調整 |
実装 | MCP接続して書き出し | 同一ツール内で実装 |
微調整 | — | プレビューを見ながらパディング/マージン等を指示 |
検証の焦点は明確です。「プレビュー連動の見た目調整によって、今回課題となったレスポンシブ問題がどこまで解決できるか」です。
画面を見ながら直せる環境なら、崩れに気づいて修正できるのではないか——という仮説の検証になります。
よくある質問
このワークフローの価値はどこにありますか？
企画初期の認識合わせです。静止画ではなく動く成果物を見せながら合意形成できるため、齟齬を早い段階で潰せます。ラフの受け渡しや、顧客への初期提示に向いています。
出力されたコードはそのまま使えますか？
使えません。ベタ書きでコンポーネント分割が甘く、レスポンシブにも対応していません。ラフ確認用途と割り切るのが現実的です。
Figmaは必ず必要ですか？
定型部分は不要な場合があります。よくある形が決まっているセクションは、デザインを起こすよりプロンプトで直接作らせた方が早いことがあります。
デザインスキルは不要になりますか？
ツール操作のスキルは代替されますが、判断力は残ります。「良いデザインとは何か」を言語化してAIに伝えられる力が、差別化要素になります。
まとめ
- 価値は「動くものを見ながら作れる」こと。企画初期の認識合わせで効く
- 実装方針は「装飾は画像、テキスト/インタラクションは再構築」の切り分け
- Figma変数が未定義でも、スクリーンショットをアセットとして使えば実装できる
- 課題はベタ書きのコードとレスポンシブ未対応。特に後者は設計初期から組み込む必要がある
- 定型部分はFigmaを経由せず直接プロンプトで作らせた方が早い場面がある
- 単純作業は代替されるため、差別化は「デザインの言語化力」に移る
新しいワークフローは、実際に回してみるまで何が足りないか分かりません。ラフ確認用途と本番実装は別物と割り切ると、使いどころが見えてきます。
株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のWeb制作へのAI導入を支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。