Figma to React：開発者のための実践的なワークフロー

完成した Figma のデザインを実際に動く React コンポーネントとして手作業で組み直す作業は、デザインファイルを見ている分には簡単そうに見えて、エディタを開いた瞬間に面倒になるタイプの作業です。ただコンポーネントを書くだけではなく、デザインの中にすでに存在している余白や整列、レスポンシブな振る舞いをもう一度自分で導き出し、細かい判断を何十回も重ねたあとで、それでも結果がデザインと一致していることを祈ることになります。ここでは、その判断力を本当に必要な部分——コンポーネントの境界、レイアウトの挙動、そして画面サイズが変わっても結果が破綻しないかどうか——に集中させてくれる、実践的な Figma to React ワークフローを紹介します。

Figma から React コンポーネントを手作業で組み立てるのが遅い理由

この引き継ぎ作業に費やす時間の大半は、難しい問題を解くためではなく、すでに決まっているデザイン上の判断を別のフォーマットに「翻訳」するために使われています。

• 各レイヤーの Auto Layout の設定を読み取り、JSX 内の Flexbox のルールとして手作業で再実装する。
• Figma ファイルにすでに正確に定義されている padding、gap、フォントサイズを測り直す。
• Figma のフレームは通常ひとつの固定幅しか持たないため、コンポーネントをどこからレスポンシブにするかを推測する。
• 使い回せるものから始めるのではなく、コンポーネント構造や props をゼロから組み立てる。

これらはどれもデザインスキルや、特別難しいエンジニアリングを必要とするものではありません。単に繰り返しの多い機械的な作業であり、そしてまさにこうした繰り返しの手作業こそが、デザインと実際にリリースされる UI とのズレが生まれる原因になります。

Figma コンポーネントから React コンポーネントへ

Figma のレイヤーを React コンポーネントに変換する際の唯一絶対のルールというものはありません——それは、どれだけ繰り返し使われるか、バリアントが何を表しているか、そしてアプリの他の部分がどう構成されているかによって変わります。出発点として、バリアントを持つ Figma コンポーネント（たとえば primary/secondary の状態を持つ Button）は通常、状態ごとに別々のコンポーネントを作るのではなく、バリアントを props として扱うひとつの React コンポーネントになります。

<Button variant="primary" size="md">
  Get started
</Button>

同じ考え方は、デザインの中で繰り返されるあらゆるものに当てはまります。Figma ファイル内に似たようなカードが3つあれば、それは同じ JSX を3つコピーするのではなく、配列データから描画するひとつの Card コンポーネントにすべきというサインです。ここで最もよくある失敗は、コンポーネントを作りすぎることです。すべての Auto Layout フレームをそれぞれ別ファイルにしてしまうと、再利用性を高めることなく間接参照ばかりが増えてしまいます。より詳しい Figma-to-React の概念マッピング——コンポーネントの境界やバリアント props でよくあるつまずきどころも含めて——については、Figma Auto LayoutからReactへ:フレームからコンポーネントへを参照してください。

MarkupGen のワークフローを React に適用する

MarkupGen は、Figma のデザインを HTML、CSS、または React コンポーネントに変換する Figma プラグイン付きの SaaS プラットフォームです。空のコンポーネントファイルからではなく、すでに生成済みのコードから始められます。ワークフローは 4 つのステップです。

1. Figma からフレームをエクスポートする。 変換したいフレームを選び、MarkupGen の Figma プラグインでワークスペースに送ります。プラグインはフレームの構造、スタイル、画像をまとめて取り込むため、レイヤーをひとつずつコピーする必要はありません。

2. AI が実際のデザインからコードを組み立てる。 そこから AI が、そのフレームの実際の構造とスタイルに基づいて HTML と CSS を組み立てます。デザインが「だいたいこんな感じ」だろうという一般的な推測ではありません。

3. 出力フォーマットとして React を選ぶ。 出力フォーマットはエクスポートごとに選択できます。素の HTML/CSS、Tailwind CSS、あるいは React コンポーネントです。React を選べば、同じ構造から組み立てられたコンポーネントが得られ、静的なページではなく、既存のコードベースにそのまま組み込める状態になります。（素の HTML/CSS が必要な場合は、Figma から HTML への一般的なワークフローを参考にしてください。）

4. 調整してから最終パッケージをエクスポートする。 最終的なコードを生成する前に、アプリ内エディタでコンテンツ、フォント、レイアウトをビジュアルに調整できます。エクスポートごとに AI による品質スコアも自動で付与されるため、そのまま本番投入できる状態かどうか、それともあと一手間必要かをひと目で判断できます。

Auto Layout がコンポーネント内で Flexbox になる仕組み

このワークフローの中で、手作業を最も減らしてくれるのがレイアウト部分です。Figma の Auto Layout のプロパティ——方向、gap、padding、整列——は自動的に、それに相当する CSS の Flexbox 構造にマッピングされます。しかもこのマッピングは、静的な HTML ページだけでなく、生成された React コンポーネントの中にもそのまま反映されます。gap が設定された Auto Layout の要素の並びは、gap や padding、整列がすでにコンポーネントのスタイルに組み込まれた flex コンテナになります。目視で位置を合わせ直す必要はありません。ネストされた Auto Layout フレームも同じように、ネストされた flex コンテナへとマッピングされ、これによりカードやリスト、ナビゲーションといったレイアウトのほとんどをカバーできます。ただし、本当にグリッド状のデザインについては、CSS Grid のほうが適している場合もあります。このマッピングの仕組みをもう少し詳しく知りたい場合は、Auto Layout が Flexbox にどうマッピングされるかを参照してください。

レスポンシブな挙動をきちんと機能させる

レスポンシブな挙動こそ、Figma-to-React の出力を最も注意深く確認すべき部分であり、軽視していい部分ではありません。Auto Layout のサイズ調整モード——Hug、Fill、Fixed——とフレームのリサイズ制約は、コンポーネントが異なる幅でどう振る舞うべきかを示す実際のシグナルです。たとえば Fill コンテナは、固定のピクセル値ではなく、可変幅や CSS の flex: 1 を使うべきだというシグナルになります。しかし、Figma も変換ツールも、それだけで完全なレスポンシブ React コードをすべて自動生成できるわけではありません。具体的な breakpoint、モバイルでレイアウトをどう折り返すべきか、特定の幅を下回ったときに別の配置が必要かどうかといった判断は、これらのシグナルに置き換えられるのではなく、それらを手がかりにしながら、依然として人が解釈する必要があります。実務的には、max-width やメディアクエリが正しく引き継がれていると信じ込む代わりに、生成された（あるいは手作業で組んだ）コンポーネントをいくつかの実際の breakpoint で確認すること、そしてデスクトップ用の Figma フレームをモバイルの挙動における最終結論としてではなく、あくまで出発点として扱うことを意味します。

アプリに組み込む前にコンポーネントをレビューする

生成されたコードでほとんどの作業は済みますが、既存のアプリにマージする前にひと通りレビューしておく価値はあります。

• コンポーネントの分割単位を確認する。 生成されたコンポーネントが、自分のコードベースで自然に分割するであろう単位と一致しているか確認しましょう。プロジェクトに取り込んだあとで、さらに細かく分割することもいつでもできます。ボタンやカード、ナビゲーションといった繰り返し使われる UI は、たいていコンポーネントとしてちょうどよい粒度です。すべてのレイヤーまで細かく分割してしまうと、間接参照が増えるだけです。
• 見た目だけでなく markup も確認する。 出力結果は、深くネストした <div> よりも、正しい見出し階層を持つセマンティックな HTML を優先します。これは検索エンジンやスクリーンリーダーが頼りにする部分でもあるので、ざっと目を通しておく価値があります。インタラクティブな部分には本物の <button> や <a> 要素が使われているか、画像に alt テキストが付いているかも確認しましょう。Figma のフレームと見た目が似ているからといって、それらが自動的に保証されるわけではありません。より詳しいチェックリストはFigmaからアクセシブルなhtmlへ:実践ガイドを参照してください。
• コンテンツや文言を再チェックする。 エクスポート後にデザインが変更された部分があれば、最終コードをプロジェクトに取り込む前に、アプリ内エディタで直しておくのが一番簡単です。
• 自分のデータと state を接続する。 生成されたコンポーネントが担うのは構造とスタイルまでです。実際の props や API データ、アプリの state に接続する作業は、引き続き自分で行う必要があります。

自分のデザインで試してみる

このワークフローは、コンポーネントの挙動に関する開発者の判断を置き換えるものではありません。すでに決まっているレイアウトの決定を JSX と CSS に変換するという機械的な作業を取り除くことで、その判断力を本当に必要な部分に振り向けられるようにするものです。MarkupGen には無料プランがあるので、まずは無料で始めて、必要になったときだけアップグレードできます——隠れた料金はなく、いつでも解約可能です。実際のデザインで四つのステップをすべて試してみたい方は、自分の Figma ファイルで試してみてください。ご質問があれば support@markupgen.com までご連絡ください。

FAQ

Figma のデザインを React に変換するにはどうすればいいですか？ フレームの構造と Auto Layout の設定を確認し、繰り返し使われている部分のうちどれを props でバリアントを扱う再利用可能なコンポーネントにするか決めたうえで、その構造から React コンポーネントと CSS を作成（または生成）します——Auto Layout は Flexbox にマッピングされ、リサイズ制約はレスポンシブな挙動の手がかりになります。MarkupGen のようなツールを使えば、この最初のパスを自動生成できます。いずれの場合も、リリース前にコンポーネントの境界、アクセシビリティ、実データについてレビューする価値があります。

Figma のデザインは再利用可能な React コンポーネントにできますか？ できますが、すべてのレイヤーをコンポーネント化すべきというわけではありません。ボタンやカード、ナビゲーション項目、フォームフィールドなど、繰り返し使われる UI はよい候補です。デザインの中に一度しか登場しないレイヤーは、通常は専用のコンポーネントにする必要はありません。

Figma の Auto Layout は React や CSS にどのようにマッピングされますか？ 主に CSS の Flexbox にマッピングされます。方向は flex-direction、gap は gap、padding は padding、整列は justify-content/align-items になり、React コンポーネントが使っている CSS の実装方法に応じてそのまま反映されます。

Figma-to-React の出力をレスポンシブにするにはどうすればいいですか？ フレームの Auto Layout のサイズ調整モードとリサイズ制約から始めましょう——これらは意図されたリサイズの挙動を示すシグナルです。ただし、breakpoint の追加や調整、モバイル専用のレイアウトは自分で行う必要があります。Figma も変換ツールも、デザインにまだ表現されていないレスポンシブな挙動を完全に推測することはできません。

すべての Figma コンポーネントを React コンポーネントにすべきですか？ いいえ。デザインファイルがたまたま「コンポーネント」とラベル付けしたものすべてをコンポーネント化すると、コードの保守性を高めることなく間接参照が増えてしまう傾向があります。再利用される、繰り返しのパターンにはその価値がありますが、一度しか使われないレイヤーには通常その価値はありません。

自分のデザインをすぐに変換したい方は、MarkupGen で Figma デザインを React に変換する →