Figma Auto LayoutをCSSに変換する：Flexboxへの対応とGridが必要になるとき

Figmaのファイルを開いて、あるフレームで「Auto Layout」がオンになっているのを見たことがあるなら、すでにCSS Flexboxとかなり近いものを目にしています。これはFigmaのデザイナーが意図的に同じ思考モデルを取り入れたからです。direction・gap・padding・alignmentはほぼそのまま対応します。Figma-to-CSSの対応関係が曖昧になるのはサイズ指定の挙動です。「hug」「fill」「fixed」は意図を表すものであり、単一のCSS宣言ではありません。正しい出力は、その要素を取り囲むレイアウトのコンテキストによって変わります。どこが直接対応し、どこがそうでないかを理解することが、間隔の値をひとつひとつ目分量で推測することなく、デザインファイルから保守しやすくレスポンシブなCSSへとたどり着く鍵になります。

Auto Layoutが実際に制御しているもの

Auto Layoutは、フレームを絶対配置された図形の集まりではなく、本物のレイアウトコンテナのように振る舞わせるためのFigmaの仕組みです。あるフレームでオンにすると、設定できるプロパティがいくつか現れます。

• Direction（方向）— 子要素を縦に並べるか、横に並べるか。
• Spacing / gap（間隔）— 各子要素の間の固定距離。
• Padding（パディング）— フレームの端と子要素との間の余白。辺ごとに設定可能。
• Alignment（整列）— 主軸・交差軸に沿った子要素の並び方。
• Resizing behavior（リサイズの挙動）— フレームとその子要素がコンテンツに合わせて縮むか、利用可能なスペースを埋めるか、固定サイズのままかを決める。

これらは何ひとつ恣意的なものではありません。それぞれのプロパティが存在するのは、実際のレイアウトエンジンが知る必要のある情報に対応しているからであり、だからこそほとんどの場合CSS Flexboxへとこれほど綺麗に写像できるのです。

Figma Auto LayoutからFlexboxへ：プロパティ対応表

この表がFigma-to-CSS変換の実務上の核心です。ほとんどの行はそのまま置き換えられますが、一部はコンテキスト次第であり、その点はNotes列で明示しています。

重要な注意点：Figmaの「Fill container」は、常に単一の普遍的なCSS宣言に変換されるわけではありません。flex: 1にすべきか、width: 100%にすべきか、align-self: stretchにすべきかは、その要素がflexコンテナ、blockコンテナ、gridのいずれの中にあるかによって決まります。同じFigmaのプロパティでも、親の種類によって必要なCSSは変わります。

メンタルモデル：Auto LayoutコンテナからFlexコンテナへ

FigmaのUIを取り除いてしまえば、両者の概念は直接対応します。

すべてのAuto Layoutフレームは、いわば「潜在的なflexコンテナ」です。実際の作業は、各フレームについて、そのサイズ指定の挙動が対応するCSSで何を意味するのかを見極めることにあります — それを次のセクションで扱います。

Hug contents、Fill container、固定サイズ

サイズ指定の挙動は、手作業によるFigma-to-CSS変換が最もつまずきやすいポイントです。Figmaは意図を表現するのに対し、CSSは具体的な宣言を要求するからです。

Hug contents

「hug contents」の要素は、自身のコンテンツに合わせてサイズが決まります — 固定の寸法を持たず、コンテンツの変化に応じて伸び縮みします。Web上での最も近い等価物は、多くの場合、明示的なwidthやheightをそもそも設定しないことです。block要素やflex itemは、デフォルトですでにコンテンツに合わせてサイズが決まるからです。明示的に指定する必要がある場合は、width: fit-contentやheight: fit-contentがかなり近い挙動になりますが、常に等価というわけではありません。flexコンテナの中では、flex-growを指定しないitemはすでに追加のCSSなしで「hug」のように振る舞うため、その上にfit-contentを重ねるのは冗長だったり、ブラウザによってはデフォルトの挙動と微妙に異なったりすることがあります。

/* Figma: Hug contents、横方向のAuto Layout */
.button {
  display: flex;
  width: fit-content; /* 多くの場合不要 — flex itemはデフォルトですでにコンテンツに合わせて縮む */
}

Fill container

「fill container」の要素は、利用可能なスペースいっぱいに広がります。正しいCSSは、完全に親要素によって決まります。

• flexコンテナ内、主軸方向の場合：flex: 1（またはflex-grow: 1）。
• flexコンテナ内、交差軸方向の場合：align-self: stretch。
• block要素の親の中の場合：width: 100%。

/* Figma: Fill container、横方向のAuto Layoutフレームの子要素 */
.sidebar-content {
  flex: 1;
}

「fill container → CSS」に、どこでも通用する単一のルールはありません。親のレイアウトコンテキストを見誤ると、flex itemではない要素にflex: 1を指定しても何も起こりません。

Fixed（固定サイズ）

Figmaでの固定寸法は、一般的にCSSでの明示的なwidthやheightに対応します。ただし、Figmaからそのままコピーしたピクセル値が正しい変換先とは限りません。デザインが意図しているのが厳密な制約（width: 240px）なのか、それとも本来は柔軟な要素に対する上限・下限（min-width / max-width、min-height / max-height）なのかを確認しましょう。すべての固定値を厳密なwidthとして扱うことは、実際のコンテンツや異なるビューポートに適応できないレイアウトを生む、よくある原因です。

Auto LayoutとConstraintsの違い

Auto LayoutとConstraintsは、関連はしているものの異なる問題を解決する仕組みであり、両者を混同することが変換ミスのよくある原因になります。

• Auto Layoutは、フレームの子要素同士がどう配置されるかを制御します — direction、gap、padding、alignment、サイズ指定の挙動です。display: flexに最も近い対応物です。
• Constraintsは、要素の親がリサイズされたときにその要素がどう振る舞うかを制御します — 左/右/上/下/中央への固定、あるいは拡大縮小です。Constraintsは、そもそもAuto Layoutフレームの中にない要素や、Auto Layoutフレーム自体が固定サイズの親の中でどう振る舞うかにとって、特に重要になります。

実際には、要素の最終的なCSSは両方の情報を必要とすることが多いです。Auto Layoutはコンテナとその子要素のflexプロパティを教えてくれますが、そのコンテナ自体を固定として扱うべきか、それとも自身の親と一緒にリサイズすべきかは、constraintsが教えてくれます。どちらか一方だけでは、レスポンシブ対応の全体像はわかりません。

Auto Layoutはレスポンシブなcssをどこまで支えるか

Auto Layoutはレスポンシブな挙動のための実用的な手がかりを与えてくれますが、それ単体で自動的にレスポンシブなCSSになるわけではありません。実際に何が得られるのかを正確に理解しておく価値があります。

• Auto Layoutのサイズ指定の挙動（hug / fill / fixed）は、どの要素が伸び、縮み、あるいは固定されたままであるべきかを示します — これはレスポンシブレイアウトの土台であり、flex、width: 100%、あるいは固定サイズへとそのまま変換されます。
• Figmaのconstraintsは、コンテナがリサイズされたときに要素がどう振る舞うべきかについての情報を補います。これはAuto Layoutが管轄していないあらゆる部分にとって重要です。
• どちらもブレークポイントを生成しません。あるデザインのレイアウトが特定の幅で本当に形を変える場合 — カラムが積み重なる、ナビゲーションが折りたたまれるなど — それでもCSSのメディアクエリが必要です。Figmaのフレームは通常、いくつかの固定されたビューポート幅を表しているだけで、その間の範囲全体を表しているわけではないからです。
• デザイナーが実際に指定したサイズとサイズの間では、流動的なサイズ指定（パーセンテージ、flex、minmax()、clamp()）のほうが、隙間を埋めるためにブレークポイントを追加するよりも、意図した挙動を忠実に再現できることがよくあります。

目標は、ビューポート全体にわたってレイアウトの意図した挙動を再現することであり、たまたま見ていたFigmaフレームのピクセル寸法をそのままコピーすることではありません。

CSS Gridのほうが適しているとき

Auto Layoutは単一軸のモデルであり、入れ子の組み合わせを含めて、行や列の扱いには非常に強みがあります。しかし中には本質的に二次元のデザインもあり、それを入れ子のFlexboxに無理やり押し込むと、元のデザインよりも保守しづらいコードになってしまいます。どちらが正解かはレイアウト次第です。Flexboxはナビゲーション、ボタングループ、横並びのカード、縦または横に整列したコンテンツなど一次元的な配置に向いており、Gridは二次元的な配置に向いています。次のような場合はCSS Gridを検討してください。

• 要素が行と列の両方で同時に揃う必要があるレイアウト — カードグリッド、ダッシュボード、画像ギャラリーなど。
• 「この要素は2列分にまたがる」「2行分にまたがる」といった明示的な挙動。これはGridのgrid-column / grid-rowでネイティブに扱えますが、Flexboxでは直接表現できません。
• 列数が固定のブレークポイント一覧ではなく、利用可能な幅に応じて変化すべきデザイン（repeat(auto-fit, minmax(...))）。
• 同じグリッド内で要素が重なり合ったり、レイヤー状になったりする領域。Gridの配置システムなら簡単ですが、Flexboxではかなり無理があります。

ひとつの目安として、あるFigmaフレームのAuto Layoutが常に一方向にしか入れ子にならないなら、Flexboxへの変換は忠実です。行と列の整列を偽装するためだけにAuto Layoutフレームのグリッドを組み立てていることに気づいたら、それは大抵、Figmaのインターフェースがネイティブな二次元Gridレイアウトモードを持たないことを補っているサインであり、その場合は実際のCSS Gridを生成する方が理にかなっています。

Auto LayoutからCSSへのよくある落とし穴

対応関係が明確であっても、Auto Layoutを手作業で再現する開発者は、決まっていくつかの点でつまずきます。

• 混在したalignmentが平坦化される。 Figmaでは個々の子要素がグループの整列設定を上書きできますが、それをざっと見てalign-itemsをひとつの値で全体に適用してしまい、本来align-selfで表現すべき個別の上書きを失ってしまうことがよくあります。
• 「hug」と「fill」の混同。 コンテンツに合わせて縮むフレームは、特定のビューポート幅では固定幅のフレームと見分けがつきませんが、コンテンツや画面サイズが変わると挙動がまったく異なります。
• gapではなくmarginに頼ってしまう。 一部の開発者はgapではなく、古いFlexboxのノウハウから受け継いだmarginのテクニックに頼り続けています。gapはすでにブラウザで十分にサポートされているので不要ですし、gapが解決するはずだった間隔のバグをそのまま再現してしまいます。
• 入れ子のAuto Layoutフレームが無計画に入れ子のflexコンテナになる。 入れ子になった各フレームはそれぞれ独立したflexコンテキストであり、機械的に1対1で変換すると、レイアウトに本来必要のないラッパー要素が増えてしまうことがあります。
• paddingが違う要素に付いてしまう。 フレームのpaddingを、コンテナではなく子要素に適用してしまいがちで、これがgapに基づいた兄弟要素間の間隔を狂わせます。
• Auto Layoutだけでレイアウトがレスポンシブになると思い込む。 前述の通り、Auto Layoutとconstraintsはレスポンシブな挙動の手がかりを与えますが、レイアウトの形そのものを本当に変える必要がある場合、メディアクエリの代わりにはなりません。
• 二次元グリッドを偽装するためにFlexboxを入れ子にする。 行と列の両方を揃えるためにAuto Layoutフレームを積み重ねているなら、それは大抵CSS Gridのほうが適したターゲットであるというサインです。

Figma-to-codeワークフローにおけるAuto Layoutの活用

この対応関係自体はよく理解されていますが、実際のデザインファイルにあるすべてのフレーム、すべてのgap値、すべての入れ子コンテナに対してこれを正しく適用し、さらに方向・サイズ指定・フレーム間の階層構造まで解釈するのは、骨の折れる作業です。そしてこれこそ、MarkupGenが解決の手助けをするために作られた、まさに反復的な変換作業そのものです。ワークフローは4ステップです。まず、付属プラグインを使ってFigmaからフレームをエクスポートすると、構造・スタイル・画像がそのままワークスペースに取り込まれます。次に、MarkupGenのAIがその実際の構造からHTMLとCSSを生成し、Auto Layoutのdirection・gap・padding・alignmentを対応するFlexbox構造へマッピングします。続いて、アプリ内エディタでコンテンツ・フォント・レイアウトをビジュアルに調整できます。最後に、最終的なコードパッケージをエクスポートします。レスポンシブなブレークポイントは、デザインのリサイズ制約から生成され、出力形式は使っているスタックに応じて、素のHTML/CSS、Tailwind CSS、Reactコンポーネントから選べます。どんな自動変換でもそうですが、hug/fill/fixedの要素のサイズ指定の挙動や、推測されたブレークポイントは確認しておくべきです。それらは良い出発点ではあっても、デザインと照らし合わせて結果を確認する作業の代わりにはなりません。白紙のファイルからではなく、動くサンプルから始めたい場合は、自分のデザインでMarkupGenのFigma to HTML変換ツールを試すか、エンドツーエンドのワークフローを知るためにFigma→HTML変換ガイドの全編を読んでみてください。

よくある質問

Figma Auto LayoutはどのようにCSSに変換されますか？ direction・gap・padding・alignmentは、それぞれflex-direction・gap・padding・justify-content/align-itemsに直接対応します。hug・fill・fixedといったサイズ指定の挙動もCSSに変換されますが、正確な宣言は固定的な一対一の置き換えではなく、周囲のレイアウトのコンテキストによって決まります。

Figma Auto LayoutはCSS Flexboxと同じものですか？ 密接に関連していますが、同一ではありません。Auto Layoutは意図的にFlexboxの概念をモデルにしているため、ほとんどのプロパティはそのまま対応します。主な違いは、Figmaがサイズ指定をデザイン上の意図（hug、fill、fixed）として表現するのに対し、CSSではその意図を特定のコンテキストで実現する具体的な宣言を選ぶ必要がある点です。

CSSにおける「hug contents」とはどういう意味ですか？ 固定サイズや引き伸ばされたサイズではなく、要素が自身のコンテンツに合わせてサイズを決めることを意味します。Web上では、明示的な幅を指定していないblock要素やflex itemのデフォルトの挙動であることが多く、必要に応じてwidth: fit-content / height: fit-contentで明示的にすることもできます。

CSSにおける「fill container」とはどういう意味ですか？ 要素が親要素内の利用可能なスペースを使って広がることを意味します。コンテキストによって、flexコンテナの主軸ならflex: 1、交差軸ならalign-self: stretch、block要素の親の中ならwidth: 100%に対応します — 常に当てはまる単一の宣言はありません。

Figma Auto Layoutはレスポンシブなcssを自動的に生成しますか？ いいえ。Auto Layoutのサイズ指定の挙動やFigmaのconstraintsは、要素がどう適応すべきかについて有用な手がかりを与えてくれますが、幅によって形が変わるレイアウトのブレークポイントは、依然としてCSSのメディアクエリとして書く必要があります。

FigmaのデザインにはCSS GridとFlexboxのどちらを使うべきですか？ どちらが「優れている」かではなく、レイアウト次第です。Flexboxは行・列・ナビゲーション・ボタングループといった一次元的な配置に向いています。Gridは、ダッシュボードや、要素を行と列の両方に同時に揃える必要があるカードグリッドのような、本質的に二次元のレイアウトに向いています。