MarkupGenMarkupGen
ドキュメントリソースブログ活用事例比較
ログイン無料で変換する
  1. MarkupGen
  2. /ブログ
  3. /FigmaのブレークポイントとCSSメディアクエリの対応関係
ブログに戻る

公開日 2026-08-20 · 執筆 MarkupGen チーム

FigmaのブレークポイントとCSSメディアクエリの対応関係

FigmaのブレークポイントとCSSメディアクエリの対応関係

簡単な答え: FigmaにはCSSのようなブレークポイントというネイティブな概念がありません。デザイナーは、画面サイズごとに個別のフレームを用意するか、メディアクエリを一切必要としないAuto Layoutの流動的なリサイズ(fill/hug)でレスポンシブ性を再現しています。どちらのアプローチが使われているかによって、CSS出力に明示的な@mediaルールが必要かどうかが決まります。

Figmaには実はブレークポイントがない

これははっきり言っておく価値があります。よくある思い込みだからです。FigmaにはCSSのメディアクエリに相当する「ここにブレークポイントを設定する」というネイティブな機能がありません。デザイナーが代わりに実際に行っていることは2つのパターンに分かれ、それぞれCSSへの変換のされ方がまったく異なります。

パターン1: 画面サイズごとに個別のフレーム

伝統的なアプローチは、デスクトップ・タブレット・モバイルそれぞれに独立したフレームを用意し、それぞれの幅で手作業でレイアウトすることです。これは明示的なCSSブレークポイントに直接対応します。各フレームのレイアウトが対応する@media (min-width: ...)ブロック内のスタイルになり、開発者の仕事は実際のブレークポイントの値をどこに置くか(フレームの幅に合わせるか、768px/1024pxのような標準的なブレークポイントに合わせるか)を決めることです。Figmaのフレーム幅はCSSの仕様ではなく、キリのいいデザイン上の判断にすぎないからです。

このアプローチが適しているのは、サイズによってレイアウトが構造的に異なる場合です——単なる再フローではなく、本当に異なる場合です(サイドバーがボトムナビになる、3カラムのグリッドが並び替えられたコンテンツを伴うシングルカラムになる、など)。

パターン2: 流動的なAuto Layoutリサイズ——多くの場合メディアクエリは不要

もうひとつのパターンは、各幅でレイアウト全体を描き直すのではなく、ひとつのフレームに設定された Auto Layout のリサイズ挙動——「コンテナいっぱいに広がる」と「コンテンツに合わせて縮む」——に頼るものです。折り返して利用可能なスペースを埋めるように設定されたカードの行、隣接する「fill」のメインコンテンツエリアの横にある固定幅のサイドバー、柔軟なコンテナの中で自然に折り返すテキスト——これらはどれもブレークポイントを必要としません。これは、たった一つの@mediaルールもなしに、flex-wrap、パーセンテージ幅、min-width/max-widthが与えてくれるのと同じCSSの挙動です。

これは、生成されたCSSをレビューするうえでより価値のある洞察なので、あえて指摘しておきます。すべてのレスポンシブな詳細がメディアクエリになるべきわけではありません。 Auto Layoutの流動的なリサイズに頼っているデザインは、自然に幅の範囲全体で流動的なCSSに変換されます。その上に明示的なブレークポイントを追加するのは、たいていの場合、レイアウトがすでに持っている挙動を再現するだけの不要な作業になります。

手作業での変換でよくある失敗

  • 流動的なCSSがすでにカバーしている部分にブレークポイントを追加してしまう。 その結果、デザインが実際に必要とする以上の@mediaルールが生まれ、レイアウトが本来必要とする以上に保守しづらいスタイルシートになります。
  • 本当に必要なブレークポイントを見逃してしまう。 デザインに構造的に異なるモバイルフレームが実際に存在する場合に、デスクトップのレイアウトを、本来意図されていなかった形に無理やり再フローさせようとしてしまいます。
  • 恣意的なブレークポイントのピクセル値を選んでしまう。 デザイン自体のフレーム幅にも、プロジェクトの既存のブレークポイントのスケールにも一致しない、他の誰のCSSにも使われていない単発の値を作り出してしまいます。

MarkupGenがこれをどう扱うか

レスポンシブな挙動は、別途手作業のパスを追加するのではなく、フレームの実際のリサイズ制約から生成されます——Auto Layoutのfill/hug設定は自動的に流動的なCSSに変換され、上で説明したのと同じ区別がそのまま適用されます。本当に異なるモバイルレイアウトが存在する(あるいは単一のデスクトップフレームから生成する必要がある)デザインの場合、MarkupGenは別途AIが生成したモバイルまたはデスクトップレイアウトを作成できます——その仕組みについてはFigmaのレスポンシブデザイン:Mobile・Desktopレイアウトの仕組みを参照してください。この背後にあるAuto LayoutからFlexboxへのマッピングについては、Auto Layout to CSSを参照してください。

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

自分のデザインがどちらのパターンを実際に必要としているかを確かめる一番早い方法は、実際に変換してみて、生成されたCSSに@mediaルールがあるか——あるいはないか——を確認することです。自分のFigmaファイルでMarkupGenを無料で試してみるか、含まれる内容を知りたい場合はFigma to HTMLコンバーターのページをご覧ください。

試す: Figma to HTML

関連記事

Figma to HTML vs React vs Tailwind:どれを選ぶべきかブログ

Figma to HTML vs React vs Tailwind:どれを選ぶべきか

MarkupGenで最も多く聞かれる3つの出力形式に関する意思決定ガイド——FigmaをいつHTML/CSSに書き出すべきか、いつReactに書き出すべきか、そしてTailwindが実際どこに当てはまるのか。

続きを読む
Figma to Code:React・Vue・CSSフレームワーク対応まとめブログ

Figma to Code:React・Vue・CSSフレームワーク対応まとめ

MarkupGenはFigmaのデザインをReactやVue 3コンポーネント(Svelte・Angularにも対応)、またはTailwindやBootstrapなどのHTML/CSSに変換できます。

続きを読む
公開前にAI生成HTMLを評価する方法ブログ

公開前にAI生成HTMLを評価する方法

「見た目が正しい」を超えて、AIによるFigma-to-code出力を判断するための再現可能なチェックリスト——視覚的な忠実度、セマンティクス、レスポンシブ性、アクセシビリティ、そして重量。

続きを読む
Figma-to-HTML出力はSEOに対応しているか:確認すべきポイントブログ

Figma-to-HTML出力はSEOに対応しているか:確認すべきポイント

変換されたHTMLは、デザインと見た目が同一でもSEOを損なうことがある。Figma-to-codeのエクスポートを公開する前に確認すべきチェックリスト。

続きを読む
Figmaからアクセシブルなhtmlへ:実践ガイドブログ

Figmaからアクセシブルなhtmlへ:実践ガイド

Figma→HTMLのワークフローでアクセシビリティに実際に必要なこと——セマンティックマークアップ、見出し、ARIA、フォーム、コントラスト、キーボード操作について解説します。

続きを読む
FigmaからCSSへ:実践的な変換ガイドブログ

FigmaからCSSへ:実践的な変換ガイド

フレームワークへの依存を完全になくす。Figmaの値がそのまま編集可能なプレーンCSSに変換される仕組みと、TailwindやBootstrapより適切な場面を解説。

続きを読む
比較

MarkupGen と手動コーディングの比較:Figma から HTML へ

Figmaデザインを手動でコーディングする方法とMarkupGenを使う方法を公平に比較し、プロジェクトに合った選択肢を見つける。

続きを読む
フロントエンド開発者のためのMarkupGen活用事例

フロントエンド開発者のためのMarkupGen

手作業でのコーディングはもう不要。Figmaのフレームをそのままクリーンなコードに変換し、レイアウトではなくロジックに時間を使いましょう。

続きを読む

次のFigmaデザインを数分でコードに変換しましょう

無料で始めて、どんなFigmaファイルからでもきれいなHTML、CSS、Reactを書き出せます。

無料で変換する
MarkupGenMarkupGen© 2025 MarkupGen. 無断転載を禁じます。
ブログ活用事例比較リソース
会社概要ドキュメントプライバシー利用規約お問い合わせ