2025年7月23日·1 分
AIはどのようにレイアウトと意図を読み取りデザインをUIコードに変換するか
AIがデザインからレイアウト、階層、ユーザーの意図を推測してUIコードを生成する仕組み、制約、ベストプラクティス、レビューのコツを学びます。
AIがデザインからレイアウト、階層、ユーザーの意図を推測してUIコードを生成する仕組み、制約、ベストプラクティス、レビューのコツを学びます。
「デザイン→コード」AIは、ビジュアルなデザイン（通常はFigmaのフレームやスクリーンショット）を実行可能なUIコードに翻訳します。目的は「完璧なコード」ではなく、構造、スタイリング、基本的な振る舞いを捉えた使えるファーストドラフトを出して、そこから人が仕上げることです。
基本的には、観察できるもの を UIが通常どのように構成されるか にマッピングします。
AIは一般的なパターンを推測できます：アイコンの列はツールバーらしい、ラベル＋入力の積み重ねはフォームフィールドらしい、スタイルの一貫性は再利用コンポーネントを示唆します。制約やスペーシングからレスポンシブ挙動を推測することもあります。
しかし、ピクセルだけでは保証できない実務的な事柄は通常指定が必要です：実際のコンポーネント名、デザイントークン（色/タイポスケール）、状態（hover/disabled/error）、ブレークポイント、データルール、検証やナビゲーション先、アナリティクス設定など。
出力は出発点として扱ってください。構造を確認し、場当たり的なスタイルはトークンに置き換え、チームのコンポーネントライブラリに合わせて調整し、反復します。「デザイン→コード」は加速手段であり、設計とエンジニアリングの判断を不要にする自動化ではありません。
AIは「きれいな画面」からプロダクトルールを推測できるわけではありません。与えた証拠に基づいて動作します—ある入力はピクセルを記述し、別の入力は構造を伝えます。この差がクリーンなUIコードか脆い絶対配置かを左右します。
スクリーンショットは最も情報が薄い入力で、色や形は含みますが何がボタンで何がラベルか、何が再利用可能か、どのようにレイアウトが適応すべきかといった明示的事実はありません。
ピクセルだけからは要素境界、テキストスタイル、スペーシングルール、あるいは「カード」が一つのコンポーネントか複数かも推測しなければなりません。制約が分からないため、レスポンシブ挙動は大部分が憶測になります。
デザインファイル（または構造を保持したエクスポート）にアクセスできると、AIは重要なメタデータを得られます：フレーム、グループ、レイヤー名、Auto Layout設定、制約、テキスト/スタイル定義。
これによりレイアウトは幾何以上の意味を持ちます。例えばFigmaのAuto Layoutは「これらの項目を縦に積んで16pxの間隔を保つ」といった意図をスクリーンショットよりはるかに明確に伝えます。レイヤー名の一貫性は要素をUIの役割（例：「Primary Button」「Nav Item」「Input/Error」）にマッピングするのに役立ちます。
デザインシステムに接続されていると当て推量が減ります。トークン（色、スペーシング、タイポ）はAIにハードコーディングされた値ではなく共通の真実を参照させるのでコードの一貫性が上がります。公開済みのコンポーネントは既製のビルディングブロックと再利用境界を提供します。
小さな慣習でも効果があります—バリアントの命名（Button/Primary, Button/Secondary）やセマンティックトークン（text/primary）といった運用はコンポーネントマッピングを改善します。
仕様はUIの「なぜ」を加えます：ホバー動作、ローディングや空状態、検証ルール、キーボード挙動、エラーメッセージ。
これらが無いとAIは静的なスナップショットを生成しがちです。仕様があるとインタラクションフックや状態処理、より実用的なコンポーネントAPIを含む出力が得られ、チームが出荷可能なコードに近づきます。
デザイン→コードツールは人間の見方で画面を認識するのではなく、各レイヤーをレイアウトルール（行、列、コンテナ、スペーシング）として説明しようとします。ルールが明確であるほど、出力は脆い位置決めに頼らずに済みます。
多くのモデルは繰り返しの整列や等間隔を探します。複数の要素が同じ左端・ベースライン・センターラインを共有していれば、カラムやグリッドトラックとして扱われることが多いです。一定のスペーシング（例：8/16/24px）はスタックギャップ、グリッドガター、トークン化されたスペーシングとして表現できるというヒントになります。
スペーシングがわずかにばらつく（ここは15px、あそこは17px）場合、AIはレイアウトを「手動」だと結論づけ、ピクセル精度を保つために絶対座標にフォールバックするかもしれません。
AIはまた視覚的な“囲い”を探します：背景、ボーダー、シャドウ、内側のパディングに見える隙間がコンテナを示唆します。背景があり内部に余白が見えるカードは親要素と子要素を持つ明確なシグナルです。
そこから垂直スタック（リスト、フォーム）、水平行（ツールバー、ナビ）、ネストグループ（card → header → actions）といったプリミティブにマッピングすることが多いです。デザインファイル上でのクリーンなグルーピングは親子の区別をしやすくします。
デザインにピン留めやハグ、フィルなどの制約があれば、AIは何が伸縮するべきか、何が固定かを判断します。fillに相当する要素は通常柔軟な幅（例：flex: 1）に、hugはコンテンツサイズにフィットする要素にマップされます。
絶対配置は、フロー型レイアウトで関係性を自信を持って表現できないときに現れます—不整合なスペーシング、重なり、整列ミスが原因です。ある画面サイズでは正しく見えても、レスポンシブやテキストサイズ変更で破綻します。
小さなスペーシングスケールと明確なグリッドへの揃えは、AIが座標ではなくflex/gridコードを出す可能性を飛躍的に高めます。一貫性は単なる美観ではなく、機械が読み取れるパターンです。
AIは“理解”しているわけではなく、通常それを示すパターンから重要度を推測します。デザインがその信号を明確に出すほど、生成されたUIは意図に合いやすくなります。
タイポグラフィは最も強力な手がかりの一つです。大きい文字、太いウエイト、高いコントラスト、広い行間は通常より重要と解釈されます。
例：32pxの太字タイトルの上に16pxの通常段落があれば「見出し＋本文」のパターンが明確です。スタイル差が1–2pxしかない場合や同じウェイトで色だけ違う場合、AIは両方をプレーンテキスト扱いにしたり間違った見出しレベルを選んだりすることがあります。
要素が近接して整列し、他のコンテンツから余白で区切られているとグループと判断されます。共通の背景（カード、パネル、色付きセクション）は視覚的な括弧のように働き、AIはそれをsectionやaside、コンポーネントラッパーとして解釈することが多いです。不均一なパディングやスペーシングの不整合は誤った再グルーピング（ボタンが別のカードに接続される等）を生みます。
同一のカード、リストアイテム、行、フォームフィールドの繰り返しは再利用可能コンポーネントの強い証拠です。わずかな違い（アイコンサイズ、角丸、テキストスタイル）があるとAIは単一コンポーネントではなく複数の使い捨てバージョンを生成することがあります。
ボタンはサイズ、塗り、コントラスト、位置で意図を示します。塗りつぶしで高コントラストのボタンは通常プライマリアクション、アウトラインやテキストボタンはセカンダリに扱われます。二つのアクションが同等に強調されているとAIはどちらが「主要」かを誤判断することがあります。
最終的にAIは階層を見出し（h1–h6）、グルーピング（section）や意味のあるクラスタ（例：「商品詳細」対「購入アクション」）にマッピングしようとします。明確なタイポグラフィ階段と一貫したグルーピングがあればこの翻訳はずっと信頼できるものになります。
モデルは見た目を多くのUIから学んだパターンに照らし合わせて意図を予測します：一般的な形状、ラベル、アイコン、配置の慣習です。
特定の配列は特定のコンポーネントを強く示唆します。左にロゴ、右にテキストがある横帯はナビバー。幅等しい項目が並び一つがハイライトされていればタブ。画像＋タイトル＋短いテキストの繰り返しはカード。整列されたヘッダと行の密なグリッドはテーブルと見なされます。
これらの推測は構造に影響します：タブは選択状態やキーボード操作が伴うべきであり、単なるボタン列とは異なる扱いになります。
次のような合図を探します：
ここからクリック、メニュー開閉、ナビゲーション、送信、展開／折りたたみなどの振る舞いを割り当てます。デザインでインタラクティブと静的要素がはっきりしていれば、より正確になります。
ホバーやアクティブ、無効、エラー、ローディングなど複数のバリアントが示されていれば、AIは状態を持つコンポーネントにマップできます。状態が明示されていないと生成物には含まれないことが多いです。
曖昧な場合（カードがクリック可能か情報表示かなど）は命名や注釈、あるいはインタラクションを示す別フレームで明示しておくと良いです。
AIがレイアウトを妥当と判断すると、「見た目」から「それが何か」への変換を行います：セマンティックなHTML、再利用コンポーネント、一貫したスタイリング。
多くのツールはデザインレイヤーとグループをDOMツリーにマッピングします：フレーム→コンテナ、テキストレイヤー→見出し/段落、繰り返しアイテム→リストやグリッド。
意図が明確ならより良いセマンティクスを付与することがあります（例：トップバー→<header>、ロゴとリンク→<nav>、クリック可能なカード→<a>や<button>）。ARIAロール（例：role="dialog"）はパターンが明白な場合にのみ推測され、そうでないときは安全策としてプレーンHTMLとアクセシビリティレビューのTODOが付けられます。
巨大なファイルを避けるため、AIはUIをプリミティブに切り分けようとします：
繰り返し、一貫したパディングやタイポグラフィ、グルーピングされたクリック領域はコンポーネントの信号です。失敗モードは過剰断片化（小さすぎるコンポーネント）や未分割（全てハードコード）です。
生成器はターゲットスタックやデフォルトに基づいてアプローチを選びます：
高品質な出力はデザイントークン（色、スペーシング、半径、シャドウ）に依拠します。厳密なピクセル一致は13pxのような一-off 値を生み、保守が難しくなります。
実務的には：階層とスペーシングのリズムを保ちつつ、トークンに正規化して繰り返し使えるコンポーネントを抽出する（その後レビューでさらにリファクタリング）というバランスが現実的です（参照：/blog/how-to-review-and-refactor-generated-ui-code）。
デザインファイルは数個の固定フレームサイズで「完成」して見えます（例：1440と375）。コードはそれを前提にしてはならず、画面幅の間も含めてどう振る舞うか決めねばなりません。ツールは手がかりとデフォルトの組合せで挙動を決めます。
同じ画面のデスクトップ/タブレット/モバイル版があると、AIはそれらを整列させてレイアウトルールの切り替わり箇所を推定できます。バリアントが無い場合は一般的なブレークポイントにフォールバックし、ぎこちないジャンプを生むことがあります。
AIは繰り返しカードや等間隔、整列を見て、例えば3カラムを2カラム、1カラムへと変える判断をします。手作業で微調整されたレイアウトは意図か偶発か区別できないため苦手です。
多くのデザインは短く整ったコピーを使いますが、実際のプロダクトはそうとは限りません。AI生成コードは固定幅/高さを設定したり過度に省略（truncation）することがあります。
簡単なサニティチェック：
AIはデザインのピクセルクロップを保持しがちですが、レスポンシブUIにはルールが必要です：アスペクト比を維持する、どのようにクロップするか、縮小時にどう振る舞うか。指定がないと「fill」挙動で重要な部分が切れることがあります。
出力を信用する前に、極小幅、極大モニタ、中間サイズでプレビューしてください。重なり、切れ、読めない箇所があれば、通常はレイアウト意図の不足が原因であり「悪いコード」ではなく設計上の手がかり不足のサインです。
AIはピクセルをUIコードに変換するのが得意ですが、「見た目が正しい」と「誰にとっても使える」は違います。多くのアクセシビリティ要件は静的フレームだけでは見えないため、明示的な信号が必要です。
視覚的に現れるアクセシビリティ対応はある程度マッピングできます：
label/forの欠落divh1→→）モーダル、ドロワー、複雑なフォーム、カスタムウィジェット、ドラッグ＆ドロップなど、状態やフォーカス管理が必要な場合は短い仕様を付けてください。例えば「モーダルでフォーカスをトラップ」「Escで閉じる」「インラインエラーをアナウンス」といった数行の注記で生成品質が劇的に改善します。
AIは見た目は近づけられても、解釈の小さなズレが積み重なって問題になります。多くはデザインがルールを明確にエンコードしていないための「妥当な推測」に起因します。
divに分解されるAIは構造化されたファイル（レイヤー、制約、スタイル、コンポーネントインスタンス）を読んでいるので、その構造がクリーンであるほど推測が減り、後で解決すべき奇妙なdivが少なくなります。
レイヤー名は意図とコンポーネントマッピングの強力な信号です。UIで使う命名パターンに合わせて一貫した名前を付けてください：
Button/Primary, Button/SecondaryCard/Product, Card/ArticleForm/Input/Text, Form/Checkbox「Rectangle 12」や「Group 5」のままにしないでください—AIは汎用のラッパーにして再利用可能なコンポーネントを見つけにくくなります。
手動配置はコード化すると絶対座標に変わりがちです。flex/grid出力を望むなら、デザイン自体をflex/gridのように振る舞わせてください：
ツール上でデザインが反応するようになれば、生成UIもデフォルトでレスポンシブになりやすいです。
ワンオフの色やフォントサイズ、スペーシングはワンオフCSSを生みます。代わりに：
これにより一貫性が高まり、後でデザインシステムへリファクタする際も楽になります。
AIは見つけられないものを想像しません。ホバー/押下/無効、入力のエラー状態、ローディング、空状態といった主要バリアントを追加してください。
動作が重要な箇所には短い注釈を付けるとよいです：「モーダルを開く」「サーバ検証」「成功時にトースト表示」など。一行の注釈で誤ったインタラクションコードを防げます。
チームの標準ワークフローとしてチェックリストを作り、内部にリンク（例：/blog/design-to-code-checklist）しておくと品質が向上します。
AI生成UIコードは最初の下書きとして扱い、人の手で整えると大きな時間短縮になります。
まずマークアップをスクリーンリーダーの視点で読みます。
h1は1つ、論理的にh2/h3）ul/ol）かセマンティクスが間違っているなら、CSSで誤魔化してもアクセシビリティや使いやすさは救えません。
多くのジェネレータはスクリーンショットを合わせるため絶対配置や深いラッパーに頼ります。これはコンテンツ変更で壊れやすくなります。
座標ベースのスタイルを見つけたらまずflex/gridに書き換え、ネストを減らして目的のあるラッパーだけ残します。
繰り返しパターンを見つけてコンポーネント化し、ハードコード値をトークンへ置換します。既存のチームトークンに合わせるか、最小限のセットを作って段階的に拡張してください（参考：/blog/design-tokens）。
重いテストスイートは不要です。
ジェネレータは推測します。行った編集や決定（インタラクションルール、ブレークポイント、コンポーネントマッピング）を記録して、次回以降や別の開発者が誤って元に戻すのを防いでください。
AIの「design to code」は加速材として最も役立ちます。最速のチームはデザインシステムの成熟度と画面リスクに合ったワークフローを選びます。
1) デザインツール内でのAI支援（例：Figmaプラグイン）：ソースファイルに近いまま素早いスキャフォルドが得られ、名前付けやコンポーネント、トークンの整合を保ちやすい。
2) 外部コンバータ（アップロード/エクスポート → コード）：多数ファイルの一括変換やチーム横断のパイプラインに有用。構造の掃除やインタラクション配線に時間がかかることがある。
多くのチームはdesign-to-codeを「仕様から出荷する」フローに組み込み、生成を下書きとして手作業で整える運用に落ち着きます。例えば Koder.ai のようなプラットフォームはフロントエンド（React）とバックエンド（Go/PostgreSQL）、モバイル（Flutter）をチャットで生成し、プランニングやスナップショット、ロールバック、ソースコードのエクスポートまで対応する例です。
各生成を下書きとして扱い、出力をレビューして繰り返し課題（命名規則、欠落する状態、誤ったセマンティクス）を記録し、プロンプト／仕様やデザイン規約を更新してください。数回の反復で品質は大きく向上します。
コミットする前に小さなパイロットを回し、次の観点で評価してください：レイアウトの忠実度、コンポーネント再利用、レスポンシブ性、アクセシビリティ基本、リファクタリング所要時間。ツールやプランを比較する際は /pricing を確認してください。
AI支援による、ビジュアルなUI（Figmaフレーム、デザイン書き出し、またはスクリーンショット）を実行可能なUIコードに変換するプロセスです。目的は「完璧なコード」ではなく、レイアウト、スタイルのリズム、基本的な構造を備えた堅実なファーストドラフトを出し、開発者がトークンやコンポーネント、プロダクション品質のセマンティクスにリファクタリングできるようにすることです。
通常、次の要素を翻訳できます：
ピクセルだけでは全ては表現できません。通常、あなたが指定するか別途提供する必要があるのは：
スクリーンショットは最も情報が薄い入力です：色や形は分かりますが、レイヤーや制約、コンポーネントといった構造的な事実が欠けます。したがって推測が多くなり、絶対配置が増え、再利用可能なコードは得にくくなります。
Figma/Sketchのファイルや構造を保った書き出しは、フレーム、レイヤー名、Auto Layout、制約、スタイルといったメタデータを提供します。これらはフレキシブルなレイアウトや正確なコンポーネント境界を作るうえで重要な信号になります。
繰り返しの整列や等しい間隔を探して、UIをflex/gridルールとして表現しようとします。明確なスペーシングのリズム（例：8/16/24）が見つかれば、安定したスタックやグリッドを生成できます。
逆にスペーシングが不揃いだったり要素がわずかにズレていると、モデルは精密な見た目を保つために絶対座標に頼ることが多く、その代償としてレスポンシブ性が損なわれます。
次のような“囲い込み”のビジュアル信号を探します：
デザインツール上でフレームやAuto Layoutなどのきれいなグルーピングがあると、親子関係をコード上で再現しやすくなります。
関係性が曖昧なとき（重なり、不揃いのスペーシング、手動での微調整が混在している場合）に絶対配置が出やすくなります。絶対配置は一つの画面サイズでは見た目が正しくても、次のようなときに崩れやすいです：
柔軟な出力を望むなら、Auto Layoutや制約でデザインをフレックス／グリッド的に振る舞わせてください。
タイポグラフィは優先度を示す最も強い手がかりの一つです。大きなサイズ、太いウェイト、高いコントラスト、広い行間は一般に高い優先度を示します。
例えば32pxの太字タイトルと16pxの通常の段落があれば「見出し＋本文」と判別しやすいです。スタイル差が1～2pxしかない、または同じウェイトで色だけ違う、というようなケースではAIが見出しレベルを誤って判定することがあります。
AIは学習した多くのUIパターンに基づいて意図を推測します。例えば：
これらの判定は構造に影響します：タブなら選択状態やキーボードナビゲーションが必要だと推測されますが、単なるボタン列だとそうしたふるまいは期待されません。
インタラクティブであることを示す手がかりを探します：
そこからクリック、メニュー開閉、ナビゲート、送信、展開/折りたたみなどの振る舞いを割り当てます。要素がインタラクティブかどうかを明確に区別しておくほど、正確さが上がります。
状態（ホバー、アクティブ、無効、エラー、ローディング）が複数示されていれば、AIはそれらを状態を持つコンポーネントにマップできます。状態が明示されていない場合、多くは省略されます。
曖昧なケースはよくあります：カードはクリック可能なのか情報表示だけなのか？矢印は装飾なのかディスクロージャコントロールなのか？こうした場合は命名、注釈、あるいは別フレームでインタラクションのバリアントを示しておくと良いです。
ツールはデザインレイヤーやグループをDOMツリーにマッピングします：フレーム→コンテナ、テキストレイヤー→見出し/段落、繰り返しアイテム→リストやグリッド。
意図が明確ならより適切なセマンティクスを付ける場合があります（例：トップバー→<header>、ロゴとリンク→<nav>、クリック可能なカード→<a>や<button>）。ARIAロール（例：role="dialog"）はパターンが明白な場合に限り推測されます。多くは安全策としてプレーンなHTMLとアクセシビリティ確認のTODOを出すことが多いです。
コンポーネント化のためにUIをプリミティブに切り分けようとします：
繰り返しや一貫したパディング・タイポグラフィがあればコンポーネントの信号になります。失敗パターンは過剰分割（ラベルごとにコンポーネント化）や過度の一体化（画面全体が単一コンポーネント）です。
生成器はターゲットスタックやデフォルトに基づいてスタイリング方式を選びます：
高品質な出力はデザイントークン（色、スペーシング、半径、シャドウ）を活用して、設計変更時にも一貫性を保つようにします。ピクセル単位を厳密に再現すると13pxのような一-off 値で保守が難しくなることが多いです。
デザインファイルは固定フレーム（例：1440、375）で描かれることが多いですが、コードはそれ以上に適応する必要があります。ツールは複数サイズのバリエーションがあれば整列させてブレークポイントを推定できますが、バリアントが無い場合は一般的なブレークポイントにフォールバックし、不自然なジャンプを生むことがあります。
AIは繰り返しカードのグリッドや等間隔、整列を見て、例えば3カラムが2カラム、1カラムへと変わると判断します。手作業で微調整されたように見えるレイアウトは意図か揺らぎか区別できないため苦手です。
動的コンテンツ（長いテキストやローカライズ）については、生成コードが固定幅/高さを設定したり過度に切り捨て（truncation）することがあります。簡単なチェックとしては：
画像やメディアはピクセルクロップを保持しがちなので、アスペクト比を保つ、どのようにクロップするか、縮小時にどう振る舞うかといったルールを明示しておくと良いです。
AIは見た目からは分からない要件を扱うのが苦手です。視覚的に表れる要素はある程度推測できますが、アクセシビリティの多くは明示が必要です。
推測できること：
推測できないこと：
生成されたUIコードは一見近い見た目でも、解釈ミスが累積すると問題になります。多くはデザインがルールを明確にエンコードしていないために起きる「合理的な推測」に由来します。
よくある失敗例：
divに）生成結果は下書きとみなして、人間が手を入れる前提で作業を組むのがベストです。準備のポイント：
レイヤー名に意味を持たせる（例：Button/Primary、Card/Product、）。「Rectangle 12」や「Group 5」は避ける。
AIが生成したコードは時間を大きく節約できますが、以下の手順でレビューとリファクタリングを行ってください：
AIはアクセラレータとして使うのが最適で、自動操縦（オートパイロット）として頼り切るべきではありません。ワークフローはデザインシステムの成熟度や画面のリスクに合わせて選択します。
二つの一般的なワークフロー：
デザインツール内のAIアシスト（例：Figmaプラグイン）：ソースファイルに近いままスキャフォルドを得られるので、デザイナーの反復と名前付け・コンポーネント・トークンの整合を保ちやすい。
外部コンバータ（アップロード/エクスポート → コード）：多くのファイルやチームに対する一括変換に向くが、構造の掃除やインタラクションの配線に時間がかかることが多い。
実務では、design-to-codeを「仕様から出荷まで」のフローに組み込み、生成を下書きとして扱い、追加の査読とリファクタリグを行うことが多いです。例えば のようなプラットフォームは、フロントエンド（React）とバックエンド（Go/PostgreSQL）、モバイル（Flutter）をチャットで記述して生成し、スナップショットやロールバック、ソースコードのエクスポートまで対応する例です。
h2h3header、nav、main、footer）altが適切（装飾ならalt=""）生成コードでよく見られるミスは、label/forの欠落、誤った見出しレベル、クリック可能なdiv（キーボードサポート無し）、フォーカススタイルの欠如、代替テキストの無いアイコンなどです。
出荷前の簡単なチェックリスト：
h1→h2→h3）header、nav、main、footer）alt（装飾ならalt=""）があるモーダル、ドロワー、複雑なフォーム、カスタムセレクト、ドラッグ＆ドロップのような非自明な状態を持つUIには短いアクセシビリティ仕様（例：「モーダルでフォーカスをトラップする」「Escで閉じる」「インラインエラーをアナウンス」）を追加すると生成品質が大きく向上します。
Form/Input/TextAuto Layoutや制約を使う（ピクセルベースの振る舞いではなく、flex/grid的に振る舞うデザインにする）。
トークンとスタイルを定義して再利用する（色・フォント・スペーシングを変数化）。
ステートやバリアント、短い意図注記を含める（hover/pressed/disabled、エラー状態、ロード状態、短い注釈）。
チームでチェックリストをつくり、内部リンク（例：/blog/design-to-code-checklist）を追加すると品質が安定します。
h1が一つであるか、論理的なh2/h3になっているか）ul/olか（divで積み上げられていないか）AIが最も効果を発揮する場面：
注意が必要な場面：
最後に、少量のパイロットを回して評価基準（レイアウトの忠実度、コンポーネント再利用率、レスポンシブ性、アクセシビリティの基本、リファクタリング時間）で採点してください。ツール比較やプラン検討の際は /pricing を確認すると良いでしょう。