公開日 2026-08-05 · 執筆 MarkupGen チーム
Figmaデザインをきれいなhtml・cssに変換する方法(ステップバイステップ)
Figmaファイルを開発者に渡すとなると、たいていは誰かが座り込んで、すべてのフレームをHTMLとCSSで一から手作業で組み直すことになります。余白を測り、ブレイクポイントを推測し、細かな判断を何十回も重ねた末に最終的なページがデザインと一致していることを祈る——そんな作業です。このガイドでは、完成したFigmaデザインからそのままきれいでセマンティックなマークアップへとたどり着く、もっと速い方法を紹介します。
手動でのFigma→HTML引き継ぎが遅い理由
引き継ぎに費やす時間の大半は、クリエイティブな作業ではなく「翻訳」作業です。
- Auto Layoutの設定を読み取り、Flexboxのルールとして手作業で再実装する。
- Figmaファイルにすでに定義されているpadding、gap、フォントサイズを測り直す。
- Figmaのフレームは通常1つの固定幅しか持たないため、レスポンシブのブレイクポイントをどこに置くかを判断する。
- 意味のない
<div>タグが10階層も入れ子になったマークアップを整理する。
どれも難しい作業ではありませんが、繰り返しの多い作業であり、まさにそうした反復的な手作業こそがミスや不整合の温床になります。
ステップ1: Figmaからフレームをエクスポートする
静的な画像をエクスポートしたり、レイヤーごとにスタイルをコピーしたりする代わりに、変換したいフレームを選択し、MarkupGenのFigmaプラグインを使ってワークスペースに送信します。プラグインはフレームの構造、スタイル、画像をまとめて取り込むため、何かをゼロから作り直す必要はありません。
ステップ2: 構造をコードへ自動的にマッピングさせる
ここが、手作業のほとんどが消える部分です。自動的に変換される例をいくつか挙げます。
- Auto Layout → Flexbox。 FigmaのAuto Layoutプロパティ(方向、gap、padding、配置)は、目分量で調整する代わりに、対応するCSS Flexbox構造へそのままマッピングされます。
- 制約 → レスポンシブなブレイクポイント。 レイアウトのリサイズ制約は、単一の固定幅ページではなく、流動的でレスポンシブなルールへと反映されます。
- レイヤー → セマンティックなHTML。 出力結果は、深く入れ子になったラベルのない
<div>の羅列ではなく、意味のある要素を優先します——ページのブロックは<section>に、ナビゲーションバーは<nav>に、見出しは適切な順序で<h1>〜<h3>に、段落は<p>に、ボタンはその挙動に応じて<button>または<a>に、画像はalt付きの<img>になります。それ自体に意味を持たない汎用的なレイアウトコンテナは、依然として<div>のままです——すべてのFigmaレイヤーにあらかじめ決まったセマンティックタグが用意されているわけではなく、どのタグを選ぶかは固定的な対応表ではなく、コンテンツが実際に何を意味するかによって決まります。
ステップ3: 出力フォーマットを選ぶ
どのプロジェクトも同じ種類のコードを必要とするわけではありません。デプロイ先のスタックに応じて、次のいずれかの形式でエクスポートできます。
- 素のHTML/CSS——静的サイトやビルド工程のないプロジェクト向け。
- Tailwind CSS——デザインの実際のspacing、カラー、タイポグラフィのトークンから生成されたユーティリティクラス。詳しくはFigmaからTailwind CSSへ:実践的な変換ガイドを参照してください。
- React——既存のアプリにそのまま組み込めるコンポーネント。詳しくはFigma to React：開発者のための実践的なワークフローを参照してください。
ステップ4: エクスポート前に仕上げる
自動変換でほとんどの作業は完了しますが、デザインからコードへの変換が100%機械的に済むことはほとんどありません——コピーの微調整が必要になったり、あるセクションだけ手動でレイアウトを調整する必要が出てきたりします。エディターでは、最終的なパッケージを生成する前に、コンテンツ、フォント、レイアウトをビジュアルに調整でき、さらに各エクスポートは自動でスコアリングされるため、出力が本番投入できる状態かどうかを一目で確認できます。
レスポンシブ対応:デスクトップのピクセル値をそのままコピーするだけではない
Figmaのフレームは通常、1440pxのデスクトップフレームのように、1つの特定の幅を表しているだけです。別途モバイル用のフレームが並んで用意されていることもあります。だからといって、その幅をCSSにハードコーディングしてtransform: scale()でページ全体を縮小すればよいわけではありません。Figmaは自動的にレスポンシブなCSSを生成してくれるわけではなく、あくまで手がかりを提供するだけであり、それを実際のレスポンシブな挙動に変換するのは、開発者または変換システムの役目です。
- Auto Layoutのhug / fill / fixedのサイズ指定は、要素がコンテンツに合わせて縮小すべきか、コンテナいっぱいに広がるべきかを示します——
width: auto、width: 100%/flex: 1、あるいは固定のmax-widthのどれを選ぶかの基準になります。 - 制約(左右に固定、コンテナに合わせて拡大縮小...)は、Auto Layoutが管理しない要素に挙動を追加します。
- メディアクエリは依然として必要です。レイアウトの形が実際に変わる幅——カラムが1列に積み重なる、ナビゲーションが折りたたまれるなど——では必須です。Figmaのフレームはいくつかの固定されたビューポートサイズしか捉えておらず、その間のすべての幅を捉えているわけではないためです。
目標は、たまたま開いているフレームのピクセル値をそのままコピーすることではなく、画面サイズ全体にわたってデザインが意図するレスポンシブな挙動を再現することです。
ここでいう「きれい」とは実際どういう意味か
「きれいなコード」は単なるマーケティング用語ではなく、具体的でチェック可能な特性を指します。
- 単一の要素を不必要に囲む
<div>ラッパーがないこと。 - すべてを見た目だけ見出し風にスタイリングするのではなく、正しい見出し階層(
h1→h2→h3)になっていること。 - 意味のある箇所でセマンティックタグが使われていること——これは検索エンジンやスクリーンリーダーがページを理解するために必要なものでもあります。
最後のポイントは見た目以上に重要です。ブラウザやクローラーが解析しやすいマークアップは、次に担当する開発者にとっても読みやすいマークアップでもあります。これは構造的にアクセシビリティの大部分を支える土台でもあります。セマンティックタグ以外にまだ手作業での確認が必要な点——ARIA、フォーム、コントラスト、キーボード操作——についてはFigmaからアクセシブルなhtmlへ:実践ガイドを参照してください。
小さな例:Auto Layoutから実際のマークアップへ
以下のようなシンプルなカードを例に考えてみましょう——アイコン、タイトル、そして「Learn more」リンクを、Auto Layout(垂直方向、16pxのgap、24pxのpadding)で配置したものです。手作業で組み直すと、つい意味を持たない<div>の積み重ねに頼りがちです。フレームの実際の構造から変換すると、同じカードは次のようになります。
<article class="feature-card">
<img src="/icons/rocket.svg" alt="" class="feature-card__icon" />
<h3 class="feature-card__title">Fast setup</h3>
<a href="/docs/getting-started" class="feature-card__link">Learn more</a>
</article>
.feature-card {
display: flex;
flex-direction: column;
gap: 16px;
padding: 24px;
}
いくつか注目すべき点があります。このカードは汎用的なラッパーではなく<article>になっています。それ自体で完結したひとかたまりのコンテンツだからです。アイコンにはalt=""が付いています。装飾的な要素であり、見出しのテキストがすでにカードの内容を伝えているためです。「Learn more」はクリックハンドラを持つ<div>ではなく、本物の<a href>です。これは別のページへ遷移するリンクだからです。Auto Layoutのvertical方向と16pxのgapは、目分量ではなく、そのままflex-direction: columnとgap: 16pxにマッピングされます。これはもっとも一般的なマッピングですが、正しく扱うべき点はほかにもあります(padding、配置、hug/fillのサイズ指定、ネストしたAuto Layoutなど)。より詳細なマッピングについてはFigma Auto LayoutをCSSに変換する：Flexboxへの対応とGridが必要になるときを参照してください。
FigmaからHTMLへ変換する際によくある間違い
Figmaのデザインを手作業でコードに変換する際、繰り返し出てくる間違いがいくつかあります。
- すべてのレイヤーを
<div>にしてしまう。 コンテンツが実際には何なのか(ナビゲーション、見出し、ボタンなど)を無視すると、スクリーンリーダーにとっても検索エンジンにとっても、マークアップが理解しづらくなります。 position: absoluteを多用しすぎる。 Figmaのキャンバス上の正確なピクセル位置を再現できますが、コンテンツや画面サイズが変わった途端に崩れてしまいます。- Auto Layoutを無視して、間隔を目分量で手作業指定する。 デザインファイルにすでに定義されているプロパティから直接変換する場合に比べて、はるかにミスが起きやすく、保守もしづらくなります。
- デスクトップの寸法をハードコーディングし、最初から柔軟なレイアウトを組むのではなく、レスポンシブ対応を後回しにしてしまう。
- 見出し階層が乱雑になる——正しい
h1→h2→h3の順序ではなく、見た目の大きさだけでフォントサイズを選んでしまう。 - 不必要な
<div>ラッパーを、それ自体ですでに意味を持つ要素の周りに付けてしまう、あるいは「見た目が同じ」と「意味的に同じ」を混同してしまう。
実際のワークフローの中での位置づけ
このプロセスは開発者の判断を置き換えるためのものではありません——機械的な変換作業を取り除くことで、その判断力を本当に必要な部分、つまりインタラクションの細部やエッジケース、より大きなコードベースへのページの統合にこそ振り向けられるようにするものです。同じフレームを手動コーディングと比較するとどう違うのか、あるいは制作会社がクライアントワークフローにどう組み込んでいるかもあわせてご覧ください。エクスポート、構築、仕上げ、エクスポートという4ステップのプロセス全体をプロダクト上で実際に確認したい場合は、自分のFigmaファイルで無料で試すことができます。
よくある質問
FigmaをHTMLに変換するにはどうすればよいですか？ 変換したいフレームを選択し、そのレイヤー構造とAuto Layoutの設定を読み取ったうえで、それをセマンティックなHTMLと対応するCSSに変換します——Auto LayoutはFlexboxに、制約はレスポンシブな挙動になります。これは手作業でも行えますが、MarkupGenのような自動化ツールを使えば、繰り返しの多い変換作業を省くことができます。
Figmaをレスポンシブなhtml・cssに変換できますか？ はい、ただし完全に自動というわけではありません。Auto Layoutと制約は、リサイズの挙動(縮小、拡大、固定)についての手がかりを提供しますが、具体的なブレイクポイントを決めたり、さまざまな画面サイズでレイアウトを確認したりする作業には、依然として人または変換システムによる判断が必要です。
Figma Auto Layoutはcssの何に対応しますか？
主にCSS Flexboxに対応します。directionはflex-directionに、gapはgapに、paddingはpaddingに、alignmentはjustify-content/align-itemsにマッピングされます。FlexboxではなくCSS Gridを使うべき場面も含め、より詳細なマッピングについてはFigma Auto LayoutをCSSに変換する：Flexboxへの対応とGridが必要になるときを参照してください。
FigmaをHTMLに変換する際、セマンティックなHTMLを使うべきですか？
はい。セマンティックなHTML(nav、article、button、正しい見出し階層など)は、スクリーンリーダーや検索エンジンがページの構造を正しく理解する助けになります——単なるコードの見た目の問題ではありません。
FigmaからHTMLへの変換は自動化できますか？ 大部分は自動化できます——レイヤー構造の読み取り、Auto LayoutのFlexboxへのマッピング、制約からのブレイクポイントの生成などです。ただし最終的なレビュー(コンテンツ、エッジケース、コードベースへの統合)には、依然として人の手による確認が必要です。
すぐに自分のデザインを変換したいですか？MarkupGenでFigmaデザインをHTML/CSSに変換する →