final_FINAL_v3 というタグが付いた Figma ファイルを開いたものの、名前のない 30 個のフレーム、ロックされた背景レイヤー、そしてランダムな装飾用の円と同じグループ内にネストされたボタンを見つけた……。これは、誰もが認めたいとは思わないものの、実際によくあることです。そのような混沌とした状態を Codex のような AI コーディングツールに読み込ませると、出力は入力の結果をそのまま反映します。大規模言語モデルであっても、「Garbage in, garbage out（ゴミを入力すれば、ゴミが出てくる）」の原則は変わりません。
乱れたハンドオフの構造
デザイナーはスピードを重視します。フレームを複製し、古い試作案を残したままにし、構造化された auto-layout の代わりに目分量での整列に頼ることがあります。その結果、「Frame 3827」のようなレイヤー名が、機能的なボタンの隣に並ぶことになります。装飾的なグラデーションの塊が、主要なコールトゥアクション（CTA）と同じグループに含まれていたり、デバイスのモックアップが、コンテンツのように見える外装（chrome）で実際のインターフェースを包み込んでいたりします。隠しレイヤーがファイル内に残ったままになっており、自動パーサーを混乱させるのを待っている状態です。
Codex を使用する開発者にとって、この問題は双方の怠慢によるものではありません。AI には人間のようなパターン認識能力が欠けています。AI はレイヤーツリーを文字通りに読み取ります。デザイナーがボタン、見出し、背景のブラーを一つの平坦化されたグループに入れた場合、Codex はそれらを構造的に等価な兄弟要素として扱います。その結果、色を確認する前に、構造的に壊れたフロントエンドが出来上がってしまうのです。
理想に近づくためのワークフロー
単なる変換器としてではなく、エディター（編集者）のように振る舞えば、乱れたソースからでもクリーンなコードを出力させることができます。目標は、Codex が適切な推測を行えるだけの十分なコンテキストを与え、その推測が合理的なフロントエンドアーキテクチャの範囲内に収まるよう制約をかけることです。
AI が見る前に、すべてを抽出する。 アクセス権がある場合は Dev Mode をオンにしてください。インスペクトパネルから生の CSS プロパティをコピーします。カラー変数やテキストスタイルをエクスポートします。これらの構造化されたデータを、プロンプトと一緒に Codex に投入します。スクリーンショットは空間的な配置の真実を示し、メタデータは正確な hex コード、フォントスタック、行の高さを提供します。どちらか一方が欠けると、モデルの推測は不完全なものになります。
プロンプトではレイアウトシステムを厳格に指定する。 Codex に単に「このページをコード化して」と頼んではいけません。何を使用するかを正確に指示してください。「ナビゲーションは CSS Flexbox で、ダッシュボードのグリッドは CSS Grid で構築してください。アイコンに対して通知バッジを配置する場合を除き、absolute positioning は使用しないでください。」 AI ツールは、デザインファイルから固定の x-y 座標を直接解析するため、デフォルトで absolute positioning を使用しがちです。明示的な指示によって、その傾向を上書きできます。
スクリーンショットをガードレールとして活用する。 フレームを 2x 解像度でエクスポートします。それらをテキストのコンテキストと一緒にアップロードします。Codex が最初のパスを生成したら、その結果をブラウザで開き、スクリーンショットと並べて確認します。スペーシングのズレ、ボーダーの欠落、フォントウェイトの不一致がないかチェックしてください。AI は大まかな構成は正しく捉えますが、具体的なパディングを間違えることがよくあります。
修正を前提に計画する。 レンダリングされた出力を視覚的なリファレンスと比較し、エラーを手動で修正します。AI はテキストラベルを image タグに変えてしまったり、<article> や <section> の代わりに汎用的な div でカードを囲んだりすることがあります。このレビュー工程は必須です。これこそが、生成されたコードをプロダクションコードへと昇華させる段階なのです。
AI が迷走するポイント
注意深いワークフローであっても、特定の乱れたパターンは一貫して Codex を混乱させます。
最大の要因は「装飾的なノイズ」です。Figma ファイルには、機能的なインターフェースの一部ではない背景のグロー効果、ステータスバーのテンプレート、イラスト用のアイコンなどが含まれていることがよくあります。明確なラベルがないと、AI はそれらを永続的な DOM 要素としてコード化してしまいます。その結果、CSS の background や box-shadow で済むはずのぼかした円に対して、専用の div タグが生成されてしまうのです。
「平坦化された階層構造」はコンポーネント検出を妨げます。整理されたファイルでは、カードは画像、タイトル、アクションを含む auto-layout フレームです。しかし、乱れたファイルでは、これら 3 つの要素がルートレベルに存在し、視覚的には整列していても、構造的には孤立していることがあります。Codex はカードの境界を完全に見逃し、共通の親要素を持たない要素のフラットなシーケンスを出力してしまいます。
ノイズからシグナルを分離する
このドラフトは、デザインと AI 生成コードの橋渡しをする際に、すべての開発者が直面する具体的な問いを投げかけています。
Figma のメタデータとスクリーンショット、どちらをより信頼しますか？
両方を信頼しましょう。ただし、役割は異なります。色、フォントサイズ、スペーシングトークン、書き出し済みのアセットなどの正確な値には、Figmaのメタデータを使用してください。構造や視覚的な階層については、スクリーンショットの方が優れています。もしメタデータでレイヤーの座標が x: 120, y: 300 となっていても、スクリーンショットでカードの中央に配置されているように見える場合は、レイアウトについてはスクリーンショットを、スタイリングについてはメタデータを信頼してください。スクリーンショットを正解（ground truth）とし、インスペクトパネルを使って正確な値を補完するようにしましょう。
UIとデバイスフレームをどのように切り分けますか？
何かを書き出す前に、UI以外のすべてのレイヤーを非表示にします。スマートフォンのモックアップやデスクトップのクローム（枠組み）を選択し、表示をオフにしてください。ファイルが乱雑すぎて、テンプレートとコンテンツの区別がつかない場合は、複数の画面にわたって繰り返されている要素を探します。ステータスバー、ホームインジケーター、ナビゲーションシェルなどは、通常、全く同じ位置に配置されています。実際のボタン、フォーム、コンテンツは、変化する中央部分に配置されます。すべての画面で固定されているように見えるものは、すべて非表示にします。残ったものが、あなたの扱うべき本当のインターフェースです。
整理されていないファイルでコンポーネントの境界をどのように見つけますか？
視覚的なクラスタリング（塊）を探し、次にスペーシングで検証します。もし4つの要素が一定の16pxの間隔で並んでおり、共通の背景色を持っているなら、たとえデザイナーがグループ化していなくても、それらは一つのコンテナに属している可能性が高いです。Figmaのレイヤーリストで、要素が連続してスタックされているかを確認してください。