FigmaからWebページを実装するとき、選択した要素のCSSを順番にコピーするだけでは、きれいな実装にならないことがあります。

実際には、ページ全体の構造、繰り返し部品、PCとスマートフォンの違い、既存サイトのCSSルールを読んでからコードへ落とす必要があります。

この記事では、FigmaデザインをHTML・CSSへ実装するときの作業順を、実案件を想定して整理します。

情報の基準日：2026年8月12日
FigmaのInspect / Dev Mode機能や利用条件は更新されます。Figma公式のGuide to inspecting、Guide to Dev Mode、Use code snippets in Dev Modeで最新仕様を確認してください。

先に結論：Figmaは「CSSをコピーする場所」ではなく「仕様を読む場所」

実装は次の順番が進めやすいです。

  1. ページ全体を見る
  2. PC / SPフレームを比較する
  3. 共通部品を洗い出す
  4. 色・文字・余白のルールを確認する
  5. 画像・アイコンの扱いを決める
  6. HTML構造を作る
  7. 大きなレイアウトを実装する
  8. レスポンシブを入れる
  9. 細部を調整する
  10. Figmaとの差分を確認する

最初から1要素ずつ数値を合わせるより、ページのルールを先に把握します。

FigmaのInspect / Dev Modeで確認できること

Figma公式では、Inspectでレイヤーのlayout、color、typography、text、component properties、styles、variablesなどを確認できると案内しています。

Dev Modeでは、選択した要素の距離を測ったり、Inspect panelでレイアウト・スタイルを見たり、コードスニペットを確認できます。

2026年8月時点では、Dev Modeは有料プランのFullまたはDev seatが対象です。ただし、ファイル権限やプランに応じたInspect手段も用意されています。

FigmaからHTML・CSSへ実装する簡単な使い方【2026年8月時点】

Step 1：最初にページ全体を縮小して見る

コードを書く前に、フレーム全体を見ます。

確認するのは、

  • セクション数
  • セクション順
  • 最大コンテンツ幅
  • 背景色の切り替わり
  • カード等の繰り返し
  • CTAの位置
  • ヘッダー / フッター

です。

ここでページ構造をメモしておきます。

header
hero
features
case-study
pricing
faq
cta
footer

Step 2：PCとSPを並べて比較する

PCとSPで単純に幅だけが変わっているとは限りません。

例えば、

  • 2カラム → 1カラム
  • 画像と文章の順番入れ替え
  • ナビゲーション → ハンバーガー
  • 表 → 横スクロール
  • ボタン幅変更
  • 一部装飾を非表示

などがあります。

違いがある箇所を先に一覧化します。

Step 3：共通部品を見つける

Figmaで同じカード・ボタン・見出しが繰り返されているなら、コード側でも再利用を検討します。

例えば、

  • .button
  • .section-heading
  • .feature-card
  • .price-card

などです。

見た目が似ていても用途が違う場合は無理に1つへまとめません。

Step 4：コンテナ幅と余白ルールを確認する

個々の要素のmarginより先に、ページ全体の基準を見ると実装しやすくなります。

Figmaで、

  • 左右端からコンテンツまでの距離
  • セクション間隔
  • カード間gap
  • カード内padding

を確認します。

例えば複数セクションが同じ左右位置なら、共通containerにできます。

.container {
  width: min(1200px, calc(100% - 48px));
  margin-inline: auto;
}

数値は実際のデザインに合わせます。

Step 5：文字のスタイルを確認する

テキストを選択して、

  • font family
  • font size
  • font weight
  • line height
  • letter spacing
  • color

を確認します。

似た見出しが複数ある場合は、共通ルールを探します。

Figma上のすべてのテキストに個別classを作るのではなく、サイト内のタイポグラフィとして整理します。

Step 6：色とVariables / Stylesを確認する

同じ色が複数箇所で使われるならCSS custom propertiesへまとめる方法があります。

:root {
  --color-text: #1f2937;
  --color-muted: #64748b;
  --color-primary: #2563eb;
  --color-surface: #f8fafc;
}

FigmaにVariablesやStylesが設定されている場合は、単なるHEX値よりその意味も確認します。

Step 7：画像・アイコンを書き出す

書き出す前に、

  • SVGでよいか
  • PNG / WebP等が適切か
  • 背景透過が必要か
  • 2倍サイズが必要か
  • 既存assetsに同じ素材がないか

を確認します。

アイコンを全部画像化せず、既存アイコンライブラリやSVG componentの利用ルールがあるならそちらに従います。

Step 8：HTML構造を先に作る

FigmaのFrame名をそのままHTML要素へ変換する必要はありません。

見た目ではなく、ページ内容に合うHTML構造を作ります。

例えば、見出し付きのまとまりならsection、主要ナビならnavなどを使います。

Step 9：大きなレイアウトから実装する

最初は、

  • container
  • grid / flex
  • section padding
  • card width
  • image ratio

など大枠を合わせます。

影・border radius・細かなletter spacingは後回しでも構いません。

Step 10：SPを早い段階で実装する

PCを100%完成してからSPへ移ると、PC側の固定値が邪魔になる場合があります。

主要セクションのPCができたら、一度狭い幅で確認します。

MDNのResponsive Web Designでは、flexible grids、media queriesなどを使い、さまざまな画面サイズへ適応する考え方が説明されています。

Step 11：中間幅も確認する

PCデザインが1440px、SPが375pxでも、その間には多くの画面幅があります。

例えば1024px、768px、600px付近で、

  • カードが窮屈
  • 見出しが不自然に3行
  • ナビがはみ出す
  • 画像が小さすぎる

などが起きないか確認します。

Step 12：JavaScriptの仕様をPrototypeから確認する

FigmaにPrototypeが設定されている場合は、

  • クリック時の遷移
  • モーダル
  • タブ
  • accordion
  • hover

などを確認します。

ただし、Prototypeがないから動きが不要とは限りません。仕様書や依頼内容も確認します。

Step 13：Dev Modeのコードスニペットは参考値として使う

Figma公式では、Dev ModeのCode sectionで選択したオブジェクトに応じた自動生成コードスニペットを表示できます。

便利ですが、そのコードをそのまま本番CSSへ貼ることを完成形にはしません。

理由は、

  • 既存サイトのclass設計
  • 共通component
  • responsive rules
  • CSS variables
  • semantic HTML

など、Figmaの1レイヤーだけでは分からない情報があるからです。

Step 14：デザインとの差分をセクション単位で確認する

ページ完成後だけでなく、主要セクションごとに比較します。

確認項目は、

  • 左右位置
  • 最大幅
  • 上下余白
  • 文字サイズ・行高
  • 画像サイズ
  • カード高さ
  • ボタン
  • border / shadow

です。

Step 15：SPも同じように比較する

PCだけ一致しても完了ではありません。

SPでは、

  • 余白
  • 改行
  • 要素順
  • 画像のcrop
  • button width
  • 横スクロール

を重点的に確認します。

Figmaの数値をそのまま使わないケース

固定height

Figma上でカードheightが固定されていても、Webでは文章量が変わる場合があります。

必要性がなければheightではなくpaddingやmin-heightで調整したほうが安全なことがあります。

絶対配置

デザイン上の座標をすべてposition: absoluteで再現すると、画面幅や文章量の変化で崩れやすくなります。

通常レイアウトで組める部分はGrid / Flexbox等を使います。

テキストの強制改行

デザイン上の改行をすべて<br>で固定すると、中間幅で不自然になる場合があります。

意味上必要な改行か、見た目のための改行かを分けます。

既存サイト案件ではデザインより既存ルールも見る

新規LPならFigmaを中心に作れますが、既存サイトへ追加する場合は、

  • 既存button component
  • container
  • font rule
  • breakpoint
  • class naming
  • SCSS structure

を優先する場面があります。

同じ見た目なのに別実装を作ると保守コストが増えます。

実装後はPreviewへ出す

ローカルだけで確認を終えず、Preview環境で実URLとして確認します。

次の工程はGit→Preview→Lighthouse→公開までのWebサイト公開レシピで整理しています。

初めて案件としてFigma実装を受ける場合は、Web制作案件の進め方も合わせて確認してください。

Figmaからの実装自体にまだ不安がある場合は、HTML・CSS・JavaScriptでWebページを1枚作る基本へ戻ると整理しやすいです。

まとめ

Figmaからのコーディングでは、CSS数値をコピーすることより、デザイン全体の規則を読み、Webとして壊れにくい構造へ翻訳することが重要です。

ページ構造 → 共通部品 → レイアウト → レスポンシブ → 細部 → 差分確認の順に進めると、細かな調整に入る前に大きなズレを減らせます。

次に読む記事

今のテーマから次の行動へ進むときは、以下の記事も参考にしてください。