FigmaのAuto LayoutとCSS Flexboxの対応関係（そしてGridが必要になるとき）

Figmaのファイルを開いて、あるフレームで「Auto Layout」がオンになっているのを見たことがあるなら、すでにFlexboxとかなり近いものを目にしています。これはFigmaのデザイナーが意図的に同じ思考モデルを取り入れたからです。この対応関係を理解することは単なる豆知識ではありません。デザインファイルから、間隔の値をひとつひとつ目分量で推測することなく、実際に動くCSSへと移行できるようになります。

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

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

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

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

Flexboxへの直接的な対応

Figma Auto Layoutのプロパティ	対応するCSS Flexbox
Direction（縦/横）	flex-direction: column / row
要素間のスペース	gap
Padding	padding
主軸方向の整列	justify-content
交差軸方向の整列	align-items
コンテンツに合わせて縮む（Hug）	width: fit-content / height: fit-content
コンテナいっぱいに広がる（Fill）	flex: 1 または width: 100% / height: 100%
固定サイズ	明示的な width / height

この表を見れば、すでにFlexboxを知っている人にとってAuto Layoutが直感的に感じられる理由も、Figmaから出発したデザイナーにとってFlexboxが直感的に感じられる理由もわかります。両者は名前が違うだけで、同じボックスモデルを表現しているのです。

手作業で変換するときにありがちなつまずき

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

• 混在したalignmentが平坦化される。 Figmaでは個々の子要素がグループの整列設定を上書きできますが、それをざっと見てalign-itemsをひとつの値で全体に適用してしまい、本来align-selfで表現すべき個別の上書きを失ってしまうことがよくあります。
• 「hug」と「fill」の混同。 コンテンツに合わせて縮むフレームは、特定のビューポート幅では固定幅のフレームと見分けがつきませんが、コンテンツや画面サイズが変わると挙動がまったく異なります。ここでの判断ミスは、実際のコンテンツで崩れるレイアウトの典型的な原因です。
• gapが使われない。 一部の開発者はgapではなく、古いFlexboxのノウハウから受け継いだmarginのテクニックに頼り続けています。gapはすでにブラウザで十分にサポートされているので不要ですし、gapが解決するはずだった間隔のバグをそのまま再現してしまいます。
• 入れ子のAuto Layoutフレームが無計画に入れ子のflexコンテナになる。 入れ子になった各フレームはそれぞれ独立したflexコンテキストであり、機械的に1対1で変換すると、レイアウトに本来必要のないラッパー要素が増えてしまうことがあります。
• paddingが違う要素に付いてしまう。 フレームのpaddingを、コンテナではなく子要素に適用してしまいがちで、これがgapに基づいた兄弟要素間の間隔を狂わせます。

Flexboxが適さないとき — Gridを検討する

Auto Layoutは単一軸のモデルであり、入れ子の組み合わせを含めて、行や列の扱いには非常に強みがあります。しかし中には本質的に二次元のデザインもあり、それを入れ子のFlexboxに無理やり押し込むと、元のデザインよりも保守しづらいコードになってしまいます。次のような場合は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を生成する方が理にかなっています。

MarkupGenがこれをどう自動化しているか

この対応関係自体はよく知られていますが、実際のデザインファイルにあるすべてのフレーム、すべてのgap値、すべての入れ子コンテナに対して正しく適用し続けるのは骨の折れる作業です。そしてこれこそ、MarkupGenが取り除くために作られた、まさに反復的な変換作業そのものです。ワークフローは4ステップです。まず、付属プラグインを使ってFigmaからフレームをエクスポートすると、構造・スタイル・画像がそのままワークスペースに取り込まれます。次に、MarkupGenのAIがその実際の構造からHTMLとCSSを生成し、Auto Layoutのdirection・gap・padding・alignmentを、手作業の推測に頼ることなく対応するFlexbox構造へ自動的にマッピングします。続いて、アプリ内エディタでコンテンツ・フォント・レイアウトをビジュアルに調整できます。最後に、最終的なコードパッケージをエクスポートします。レスポンシブなブレークポイントは、デザインのリサイズ制約から自動的に生成され、出力形式は使っているスタックに応じて、素のHTML/CSS、Tailwind CSS、Reactコンポーネントから選べます。各エクスポートには自動でAI品質スコアが付与されるため、生成されたコードがすぐ使える状態かどうかを一目で確認できます。出力は不要な入れ子の<div>を避けた、クリーンでセマンティックなHTMLを重視しており、これは保守性だけでなくSEOの観点でも重要です。

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

Auto LayoutからFlexboxへの対応関係を理解しておくと、生成されたコードをより速くレビューできるようになり、どのデザインが本当にGridを必要としているかも見極めやすくなります。手作業での変換をまるごとスキップしたい場合は、自分のFigmaファイルでMarkupGenを無料で試してみるか、エンドツーエンドのワークフローを知るためにFigma→HTML変換ガイドの全編を読んでみてください。