Figma デザインから Codex でコードを生成する手順

Figma と Codex を組み合わせるメリット

Figma は2026年時点でウェブ・アプリのデザインツールとして広く普及しており、Dev Mode を通じてデザイン情報をコードに近い形で書き出せる機能を持っている。Figma の Dev Mode では、選択したコンポーネントの CSS プロパティや React コンポーネントのテンプレートを取得できる。ただし自動生成されるコードはそのままプロダクションに使えるとは限らず、ビジネスロジックや状態管理などが手作業で加わることも多い（出典: https://www.figma.com/developers/api ）。

Codex はこのギャップを埋める役割を担える。Figma から書き出した構造情報を渡すと、コンポーネントの配置や色を維持しながら、より完成度の高いコードを生成できる。自分でゼロからコードを書くよりも早く初期実装を作れるため、デザインのフィードバックサイクルが速い段階では特に効果が出やすい。デザイナーと開発者が同じ Figma ファイルを参照しながら、実装面を Codex に委ねて進められる点も利点のひとつだ（出典: https://openai.com/codex ）。

デザイン変更に伴うコードの修正にも Codex は使える。Figma でコンポーネントのサイズや色が変わった場合、変更後の仕様を伝えることで修正点を反映したコードを得られる可能性がある。毎回ゼロから書き直す必要はなく、差分の修正を指示するという使い方が実用的だ。全コンポーネントの一括変更には向かないが、個別コンポーネントの修正で時間を短縮できるケースがある。

Figma から Codex へ情報を渡す準備

Step 1: Figma Dev Mode でコンポーネントのスタイル情報を取り出す

Figma の Dev Mode はプロプラン以上で利用できる機能で、デザインファイル内のコンポーネントを選択すると CSS プロパティやトークン情報を右パネルに表示する。コピーしたい要素を選択し「Code」タブを開くと、background-color・font-size・border-radius などのスタイル値がそのまま CSS として表示される。さらに「Inspect」パネルではコンポーネントの階層構造も確認できるため、どの要素が親・子関係にあるかをテキストで把握できる（出典: https://www.figma.com/developers ）。

デザイントークンを管理している場合、Tokens Studio などのプラグインを使って JSON 形式でトークンを書き出しておくと Codex へのプロンプトに組み込みやすくなる。--color-primary: #0070f3・--spacing-md: 16px のような変数名とその値を一覧化したテキストを用意しておくことで、Codex がスタイルのルールを理解したうえでコードを生成できる。

コンポーネントの構造については、Figma のレイヤーパネルをもとに HTML の大まかな入れ子構造を手書きで整理しておくと便利だ。「header > nav > ul > li × 5」のようなシンプルな構造メモがあるだけで、Codex のプロンプトに含める情報として十分に機能する。詳細な CSS を丸ごとコピーするより、構造のポイントを人間が整理して渡す方が精度が出やすい。

Step 2: Codex に渡すプロンプトの作り方

Codex へのプロンプトは、デザイン情報と実装要件を分けて伝えるのが基本だ。最初のメッセージでデザイントークン（色・フォント・間隔の変数名と値）を渡し、次のメッセージでコンポーネントの構造と挙動の要件を説明するという流れが安定しやすい。

たとえばナビゲーションバーを実装する場合、まず「このプロジェクトで使うカラーパレットとフォントサイズは次の通りです：…(Figma から書き出した値)」と伝え、次に「この情報を使って、横並びのナビゲーションバーを React コンポーネントとして実装してください。ロゴは左、リンクは右に5項目並べます」と指示する。一度に情報を詰め込みすぎると Codex が意図を取り違えやすいため、役割ごとに分けて伝える方が精度が上がる（出典: https://openai.com/codex ）。

ピクセル単位の指定が必要な場合は、Figma の Dev Mode で確認した数値をそのままプロンプトに含める。「ボタンの高さは 48px、角丸は 8px、パディングは左右 16px・上下 12px」という形で具体的な数値を添えると、生成されるコードがデザインにより近い仕上がりになる。数値を省略して「適当なサイズで」と伝えると Codex が汎用的な値を当てはめてしまい、後から調整が増えることがある。

Step 3: Codex が出力したコードを確認して反映する

Codex が生成したコードは、Figma のデザインと見比べながら確認するのが基本の流れだ。Codex はデザインファイルを直接読み込むわけではなく、テキストで渡された情報を元にコードを書くため、細部が異なるケースもある。色の値がやや違う、余白が意図より狭い、といった差異を発見したら、修正指示を追加メッセージで送ると Codex が修正案を出力する（出典: https://openai.com/codex ）。

Codex ウェブ版（https://chatgpt.com/codex ）を使う場合、生成されたコードをブラウザ上の差分ビューで確認しながら反映できる。変更を承認するかどうかは開発者が判断するため、不要な修正が意図せずコードベースに入るリスクは低い。ウェブ版ではリポジトリに直接連携する形でも使えるため、Figma から取り出した情報をもとにコードを生成・プルリクエストとして送る一連の流れをウェブ上で完結させることが可能だ。

実際のユースケースと活用パターン

ランディングページのセクションごとに実装を分担する

Figma で設計したランディングページを実装する場合、ヒーローセクション・フィーチャーセクション・CTA セクションといった単位に分けて Codex に実装させるパターンが使いやすい。各セクションの Figma コンポーネントからスタイル情報を書き出し、ひとつずつ実装を依頼することで、全体の品質を管理しながら進められる。大きなページを一度に実装しようとすると指示が複雑になりがちなため、セクション単位に分割することが有効だ（出典: https://openai.com/codex ）。

各セクションを実装する際には、前のセクションで定義したスタイル変数を引き継ぐことを明示すると、一貫したデザインのコードが出力されやすくなる。「前のメッセージで定義した変数を使って次のセクションを実装してください」という指示を添えることで、プロジェクト全体でスタイルが統一される可能性が高まる。

デザインシステムのコンポーネントライブラリを構築する

Button・Input・Modal・Card などの基本コンポーネントを Figma で設計してある場合、それぞれのコンポーネントを Codex で実装してライブラリとして整備する進め方が成立する。Figma のスタイルガイドに記述されているコンポーネントのバリアント（プライマリ・セカンダリ・ゴースト）とサイズ（sm・md・lg）の情報を整理してプロンプトに含めると、variants 対応のコンポーネントを生成しやすくなる（出典: https://www.figma.com/developers ）。

コンポーネントごとに独立したセッションで実装を依頼し、完成したものを順次ライブラリに追加していく方法が、後からのメンテナンスをしやすくする。すべてを1つの長いセッションで実装しようとすると、途中で Codex が文脈を取り違えることがある。

既存コンポーネントのデザイン変更に対応する

デザインリニューアルで既存コンポーネントのカラーや余白が更新された場合、Figma の変更前後の差分を整理して Codex に伝えることで修正コードを得られる。「primary ボタンの背景色を #0070f3 から #005fcc に変更し、hover 時の色も同じ比率で暗くする」という形で差分を言語化すると、Codex がスタイルシートの該当箇所を特定して変更案を出力できる可能性がある。全コンポーネントの一括変更には向かないが、個別コンポーネントの修正では時間を短縮できるケースがある。

うまくいかないときの対処と注意点

Codex が Figma の意図と大きくずれたコードを出力するケースでは、プロンプトに含める情報の粒度を見直すことが有効だ。デザイントークンのリストが長すぎると Codex が全体を把握しきれないことがある。必要なプロパティだけを絞って渡す方が、結果が安定しやすい。特にフォントファミリーや色変数が多い場合は、実装対象のコンポーネントに関係するものだけをピックアップして渡すのが現実的なアプローチだ。

Figma の Auto Layout が書き出す CSS は正確であるが冗長なことが多い。すべてをプロンプトに貼り付けるより、重要なプロパティを人間が整理したうえで渡す方が Codex の生成精度が上がりやすい。Figma が出力するコードを「参考として渡す」位置づけで使い、そこから情報を取捨選択するステップを省略しないことが重要だ（出典: https://www.figma.com/developers ）。

Codex はデザインファイルを画像として直接認識する機能は2026年6月時点では持っていない。テキストベースの情報しか受け取れないため、スクリーンショットを渡して「これを実装して」という形には対応していない。構造・スタイル・ふるまいをテキストで整理して渡すという前提で使う必要がある。Figma の Dev Mode が出力する CSS やコンポーネントの属性情報を活用することが、この制約を乗り越えるカギになる。

また、Codex が生成するコードはベストプラクティスに沿っている場合が多いが、プロジェクト固有のファイル構成やコーディング規約とは合わない場合もある。最初に「このプロジェクトでは TypeScript を使い、スタイルは CSS Modules で管理しています」のように前提条件をプロンプトに含めておくと、生成されるコードがプロジェクトの規約に近い形になりやすい（出典: https://openai.com/codex ）。

まとめ

Figma と Codex を組み合わせることで、デザインから実装への橋渡しを効率化できる。ポイントは Figma Dev Mode で取り出したスタイル情報と構造情報をテキストとして整理し、Codex に段階的に渡すことだ。デザイントークンを先に渡してスタイルを確立し、次にコンポーネント構造を伝えて実装させるという2段階のアプローチが安定性が高い。デザインシステムのコンポーネント実装、ランディングページのセクション単位の実装、既存コンポーネントのデザイン変更対応といった場面で特に活用しやすい。Codex がデザインファイルを直接読み込めない現状においては、開発者が情報の橋渡し役を担うことが鍵になる。Figma の Dev Mode と Codex それぞれの得意・不得意を理解したうえで、小さな単位から試してみるのが最も実用的な始め方だ（出典: https://openai.com/codex ）。