Figmaのレスポンシブデザイン：Mobile・Desktopレイアウトの仕組み

1440pxのデスクトップと375pxのスマートフォン、どちらの幅でも正しく見えるFigmaのフレームがあっても、その間のレスポンシブな挙動が決まっているわけではありません。Figmaが見せてくれるのは2つの固定されたスナップショットにすぎず、実際の訪問者の画面サイズがとりうるすべての幅を埋めるには、ブラウザ側に明示的なルールが必要です。「この2つのフレームは正しく見える」という状態から、実際に破綻しないレイアウトへとたどり着くには、Auto LayoutとConstraintsを単なる見た目の設定ではなくレスポンシブのシグナルとして読み取り、Figmaの仕事がどこで終わり、どこからCSSが引き継ぐべきかを理解する必要があります。ここでは実践的なメンタルモデル、実装前に確認すべきこと、そしてMarkupGenの自動レスポンシブ出力がどこに位置づけられるかを解説します。

Figmaのフレームはビジュアル仕様であり、レスポンシブなCSSではない

Figmaはフレームを常に1つの固定幅でレンダリングします。ブラウザのように、ファイル内の何かが画面サイズをまたいで実際に「動く」わけではありません。Figma上でレスポンシブデザインのように見えるものは、実際にはリサイズイベントの動作するシミュレーションではなく、意図を記述する一連のルール(Auto Layoutのdirection、gap、サイズ指定モード、レイヤーのConstraints)にすぎません。その意図が現実のものになるのはCSSの段階です——実際にビューポート幅に反応するのはflex-direction、gap、パーセンテージ、clamp()、@mediaルールです。Figmaのファイルは、完成したレスポンシブコードをすでに含んでいるものとしてではなく、意図の一次情報源として扱いましょう。

MobileとDesktopのフレームは、2つではなく1つのデザインを表している

同じファイルの中に、数週間の間隔を空けてデザインされ、いつの間にか食い違ってしまったデスクトップフレームとモバイルフレームが同居しているのはよくあることです——見出しレベルが違う、コンポーネントのバリアントが違う、明確な理由もなく片方にしか存在しないコンテンツがある、といった具合です。そうではなく、2つのフレームを同じコンテンツモデルの異なるビューとして扱いましょう——同じ見出し、同じコンポーネント(その場しのぎの複製ではなく、状態にはバリアントを使う)、そして並べ替える明確な理由がない限り同じ順序の同じ情報です。両方のフレームがこの根底の構造を共有していれば、CSS側でやるべきことは主にレイアウトの調整——行を列に積み替える、グリッドの列数を調整する、副次的なUIを折りたたむ——であり、互いに無関係な2つのテンプレートを別々に保守することにはなりません。

Auto LayoutとConstraints：実際にレスポンシブな挙動に引き継がれるもの

Auto Layoutのdirection、gap、padding、サイズ指定モード(hug、fill、fixed)はFlexboxと密接に対応しています——プロパティごとの詳しい対応関係はFigma Auto LayoutをCSSに変換するを参照してください。レスポンシブな挙動という観点で特に重要なシグナルはサイズ指定モードです。「fill」の要素は、コンテナに合わせて伸び縮みすべきである(flex: 1、width: 100%)ことを示しており、「fixed」はそうすべきではないことを示しています。

Constraintsはこれとは別の問いに答えるものです——要素の親がリサイズされたときにその要素がどう振る舞うか、という問いであり、Auto Layoutの外にある要素にとって特に重要になります。

• 左 / 右(Left / Right)— 片方の端に固定され、親がリサイズされても位置が変わらない固定オフセットに近い。
• 左右(Left and Right)— 親と一緒に伸縮し、左右のマージンを固定したwidth: 100%に近い。
• 中央(Center)— 親がリサイズされても中央に留まり続け、margin: 0 autoや中央揃えのflex/grid配置に近い。
• 拡大縮小(Scale)— 親と比例してリサイズされる。CSSにはこれに直接対応する単一の仕組みはなく、通常は相対単位で近似することになる。
• 上 / 下(Top / Bottom)(およびその組み合わせ)— 同じロジックを縦軸に適用したもの。

実際のファイルの多くは両方を組み合わせて使っています——コンテナ内の子要素同士の配置にはAuto Layoutを、そのコンテナ自体が自分より大きな何かの中でどう振る舞うかにはConstraintsを使う、という具合です。

ブレークポイント：Figmaのフレームから実際のCSSへ

Figmaにはネイティブなブレークポイントの機能がありません——「768px未満でレイアウトを切り替える」といった設定は存在しないのです。ファイルが実際に与えてくれるのは、画面サイズごとの個別のフレームか、構造上の変化を一切伴わずに流動的にリサイズする単一のAuto Layoutフレームのどちらかです。どちらを見ているかによって、CSSに明示的な@mediaルールが必要かどうかが決まり、作業の大部分は、恣意的なデバイス幅ではなく、レイアウトが本当に形を変える箇所に合わせてブレークポイントの値を選ぶことです。FigmaのブレークポイントとCSSメディアクエリの対応関係では、この2つのパターンを詳しく解説し、手作業での変換がどこでつまずきやすいかも扱っています。

Figmaでの判断をレスポンシブなCSSに落とし込む

Figma側のシグナルさえ明確になれば、CSS側で必要になるのは、一貫して適用すべき比較的少数のツールセットです。

• Flexbox— ほとんどのAuto Layoutフレーム(行、列、ナビゲーションバー、カードリストなど)に使う。
• Grid— ダッシュボードやギャラリーのように本質的に二次元的なレイアウトに使う。Auto Layoutでは、入れ子の行と列でそれを偽装していることが多い。
• メディアクエリ— サイドバーがボトムナビになる、グリッドがシングルカラムになるといった、レイアウトの形そのものが変わる箇所に使う。
• 流動的なサイズ指定(パーセンテージ、minmax()、clamp())— デザイナーが実際に指定した幅と幅の間を埋めるすべての範囲に使う。隙間を埋めるためにブレークポイントを追加するのではなく。
• max-width— Figmaのフレーム自体には表れていなくても、大画面でテキストやコンテンツが不快なほど横に間延びしないようにする。
• 折り返しと積み重ね(flex-wrap、行が列になるなど)— 縮小するのではなく再フローすべきコンテンツに使う。
• 表示・非表示の切り替え— 本当にモバイル専用・デスクトップ専用の要素に使う。display: noneで要素を隠すとアクセシビリティツリーからも除外されるため、慎重に行う価値がある。モバイルメニューのように、隠したコンテンツを別の方法で到達可能にしておく必要がある場合は、アクセシブルなHTMLへのFigma変換を参照。

Figmaをレスポンシブレイアウトに変換する際によくある間違い

• モバイルを縮小版のデスクトップとして扱ってしまうこと。本来は独自の階層と優先順位を持つ、それ自体のレイアウトであるべき。
• ピクセル値をハードコーディングしてしまうこと。Figmaのフレームに具体的な数値が表示されている箇所すべてに対して行いがちだが、本来はfill/fixedのサイズ指定とConstraintsを使って、実際に何を固定すべきかを判断するべき。
• テキストの折り返しを無視してしまうこと。原語では1行に収まる見出しやボタンのラベルも、より長い言語に翻訳すると2〜3行に折り返すことがあり、1行のテキストを前提としたレイアウトは崩れる。
• 絶対配置に頼ってしまうこと。デザインをピクセル単位で一致させようとして使いがちだが、フレームと厳密に同じ幅では正しく見えても、その間のあらゆる幅で崩れる。
• Figmaのフレームが描かれた幅だけを確認してしまうこと——例えば375pxと1440pxだけを見て、実際の崩れのほとんどが起きるその間のすべての幅を確認しないこと。

開発者への引き継ぎチェックリスト

Figmaファイルからレスポンシブな挙動を実装する前に、推測に頼らず、デザイン上で直接いくつかの点を確認しておく価値があります。

• どのフレームが存在するか、そしてモバイルとデスクトップが同じコンテンツを再構成したものなのか、それとも本当に異なる体験として意図されているのか。
• 各フレームのAuto Layout設定——リサイズが必要な要素のdirection、gap、padding、サイズ指定モード。
• Auto Layoutの外にある要素のConstraints——特に端に固定されている要素や中央揃えの要素。
• 各フレーム幅でのスペーシングとタイポグラフィ——それらはスケールするのか、それとも固定されたままなのか。
• コンポーネントのバリアント——コンポーネントに独立したモバイル用バリアントがあるのか、それとも同じコンポーネントが適応することを想定しているのか。
• モバイルとデスクトップのフレームの間で実際に何が異なるか、そしてその違いがすべて意図的なものなのか、それとも異なる時期に編集されたファイル間の単なる食い違いにすぎないのか。

MarkupGenがレスポンシブの基盤をどう自動化するか

すべてのエクスポートは、汎用的なブレークポイント一覧ではなく、フレーム自体のAuto Layout設定とリサイズのConstraintsから出発します——direction、gap、paddingはそのまま正確に引き継がれ、fill/hugのサイズ指定は流動的なCSSに変換されるため、ほとんどのレイアウトで、手書きのメディアクエリなしに画面サイズ全体にわたってスケールする結果が得られます。

モバイルで本当に異なる構造が必要なデザイン——横並びではなく縦積みのナビゲーション、並べ替えられたhero、非表示のサイドバーなど——の場合、アプリ内エディターは既存のHTML/CSSから、現在のページ専用のMobileまたはDesktopレイアウトを、専用のメディアクエリとともに個別に生成できます。適用前にレビューでき、以降は訪問者の画面サイズによってどちらがレンダリングされるかが決まります。どちらの場合も出力はネストされた<div>ではなくセマンティックなHTMLを優先し、Vanilla CSS、Tailwind、Bootstrap、Bulma、Materialize、Picoに対応しており、エクスポートごとに自動でAIによる品質スコアが付与されます。これらは上記のチェックリストの代わりにはなりません——あくまでデザインの実際のシグナルから生成された出発点であり、公開前には他のレスポンシブ実装と同じようにレビューする価値があります。

自分のFigmaファイルが両方の画面サイズでどのように反応するか試してみたい方は、Figma to HTML変換ツールを——お使いのスタックがReactなら直接Reactに変換を——無料でクレジットカード不要でお試しください。

よくある質問

Figmaのデザインでは、モバイルとデスクトップのレイアウトをどう扱うべきですか？ 2つの無関係なファイルとしてではなく、同じコンテンツ・見出し・コンポーネントを2つの幅で表現した1つのデザインとして扱いましょう。Auto LayoutとConstraintsは、その共有された構造がどう適応すべきかを記述するものであり、折りたたまれたナビゲーションや並べ替えられたheroのような本当の構造的な違いは、CSSのメディアクエリで実装します。

Figma Auto LayoutとConstraintsは、デザインを自動的にレスポンシブにしてくれますか？ いいえ。これらは意図——コンテナが変化したときに要素がどうサイズを変え、どう振る舞うべきか——を記述するものであり、その意図は実際のCSSにおいてFlexbox、Grid、流動的なサイズ指定、メディアクエリへと変換される必要があります。Figmaも変換ツールも、レスポンシブに関するすべての判断を単独で自動生成してくれるわけではありません。

Figmaのデザインから、CSSのブレークポイントをどう選べばよいですか？ Figmaにはネイティブなブレークポイント機能がないため、恣意的なデバイス幅ではなく、レイアウトの形が実際に変化する箇所を基準にブレークポイントを決めましょう。デザインが画面サイズごとに個別のフレームを使っている場合、各フレームのレイアウトが通常1つの@mediaブロックになります。Auto Layoutの流動的なリサイズに頼っている場合は、多くの場合ブレークポイントはまったく不要です。

FigmaにおけるAuto LayoutとConstraintsの違いは何ですか？ Auto Layoutは、フレームの子要素がどう配置されるか——direction、gap、padding、サイズ指定——を制御するもので、display: flexに最も近い存在です。Constraintsは、要素の親がリサイズされたときにその要素がどう振る舞うか——端に固定される、中央揃えになる、拡大縮小するなど——を制御するもので、Auto Layoutの外にある要素や、Auto Layoutフレームが自分より大きな何かの中でどう振る舞うかにとって特に重要です。

モバイルとデスクトップは、Figmaの別々のファイルに分けるべきですか？ 必ずしもそうする必要はなく、コンポーネントを共有しながら同じファイルに保つほうが、食い違いに気づきやすくなることが多いです。ファイル構成そのものよりも重要なのは、2つのフレームが同じコンテンツモデル——同じコンポーネントと階層——を表しているかどうか、そして両者の間で変わるのがコンテンツではなくレイアウトであるかどうかです。

Figmaのデザインをレスポンシブに実装する前に、何を確認すべきですか？ 存在するフレーム、それぞれのAuto LayoutとConstraintsの設定、フレーム間でスペーシングとタイポグラフィがどう変化するか(あるいは変化しないか)、コンポーネントに独立したモバイル用バリアントがあるかどうか、そしてモバイルとデスクトップのフレームの違いが、偶然の食い違いではなく意図的なものかどうかです。