HTML to Frame：DOMがFigmaのAuto Layoutになる仕組み

WebページをFigmaの画像に変換するのは簡単です。難しいのは、デザイナーが組んだように振る舞うFigmaフレームに変換することです。見た目は正しくても、見出しを編集した瞬間に崩れてしまうフレームでは、スクリーンショットと大差ありません。

この記事では、HTML to FramesがDOMをネストされたFigmaフレームに変換する方法、Auto Layoutエンジンが何をスタックにするかを判断する方法、そして結果を採用する前に自らの処理を検証する理由を、順を追って説明します。

DOMからフレームツリーへ

Webページはツリー構造です。body にはセクションが含まれ、セクションにはコンテナ、コンテナにはカード、カードには見出しやボタンが含まれます。Figmaファイルもツリー構造で、フレームの中にフレーム、テキスト、ベクターが含まれます。

HTML to frame変換の基本的な考え方は、一方のツリーをもう一方のツリーに対応させることです：

• 各ページと各画面が最上位のフレームになります。 1ページをDesktop、Tablet、Mobileでインポートすると、3つのフレームが横に並びます。
• ボックスとして機能する要素はネストされたフレームになります。 背景、ボーダー、角の半径、シャドウ、クリッピングはフレームのプロパティになります。
• テキストはテキストレイヤーになり、混在するスタイルも保持されるため、太字のリンクを含む文も1つのテキストレイヤーのままです。
• SVGは編集可能なベクターに、画像は画像の塗りになります。
• 疑似要素（::before、::after）、shadow DOMのコンテンツ、z-indexの順序も引き継がれるため、重なり順はブラウザが描画したとおりになります。

目指しているのは、すべてのDOMノードを書き出すことではなく、デザイナーが読み解けるレイヤーパネルです。検証のためにより細かいレイヤー構造が必要な場合は、Detailed layersオプション（Pro）を使えます。

フレームの命名

大きなファイルでも見つけやすいように、最上位のフレームには次のような名前が付きます：

example.com/pricing — Desktop (1920)

名前にはドメインとパス（クエリがあればそれも）が含まれ、プロトコルと www は省かれ、その後に画面とその幅が続きます。長さは最大60文字です。ソースURLもフレームに保存されるため、ワンクリックでのRe-importが可能になります。

ステップ1：まずピクセル単位で正確に組み立てる

エンジンは、いきなりAuto Layoutを推測することから始めるわけではありません。正しく見えることが保証されたバージョンから始めます：

1. 選択した幅で、実際のブラウザでページをレンダリングします。Desktopの場合はSite width、つまりページの実際のデザインからプラグインが測定した幅です（全幅なら1920、ボックス型サイトならボックス幅、フルードなサイトなら1440）。
2. すべての要素のジオメトリと計算済みスタイルを測定します。
3. 絶対位置でフレームツリーを組み立てるため、すべてのレイヤーがブラウザが配置したとおりの場所に収まります。

この絶対配置のバージョンがセーフティネットです。その後に行う処理はすべて、自らの正しさを証明しなければならない改善です。

ステップ2：内側から外側へAuto Layoutを推定する

次に、エンジンはフレームを最も内側から外側へとたどります。各フレームについて子要素の実測ジオメトリを調べ、これらをAuto Layoutのスタックとして表現できるかを判断します。

推定するのは次の項目です：

• 方向 — 子要素は縦と横のどちらのスタックで並んでいるか？
• 折り返し — カードのCSS gridや flex-wrap のように、折り返し行を形成しているか？
• 間隔 — 子要素間の間隔は、1つの値として扱えるほど一定か？
• パディング — 各辺で、子要素はフレームの端からどれだけ離れているか？
• 配置 — 各軸で、子要素は先頭、中央、末尾のどこに揃っているか？

内側から外側へ処理することが重要です。カードの中身がきれいな縦のスタックになれば、そのカード自体を、周囲にあるカードの行の中の1つのアイテムとして扱えるからです。

決定的に重要なのは、推定がCSSの解析ではなく、ブラウザが実際にレンダリングした結果に基づいている点です。行がflexbox、grid、float、inline-blockのどれで作られていても、実測結果は同じであり、エンジンはそれをもとに処理します。

ステップ3：レスポンシブな意味づけを加える

間隔とパディングが正しいスタックは出発点にすぎず、まだレスポンシブデザインのようには振る舞いません。エンジンは意図も推定します：

• 中央寄せのコンテンツ → Center。 コンテンツが親の中で中央に配置されていれば、Centerに揃えられるため、フレームをリサイズしても中央に保たれます。
• 最大幅のボックスは中央に保たれます。 全幅のセクション内にある最大幅付きのコンテンツコンテナは、その幅を維持したまま中央に留まります。
• 均等なカードとflex-grow → Fill。 1行を均等に分け合うカードや、余白を埋めるように伸びる要素は、Fill containerに設定されます。
• ロゴ … メニュー … アイコン → 間のアイテムがFillに。 典型的なヘッダーでは、グループ間の余白が伸びる部分です。エンジンはその間のアイテムをFillにするため、ヘッダーが広がってもロゴは左に、アイコンは右に留まります。

これが、ある1つの幅でページと一致するだけのフレームと、実際にリサイズできるフレームとの違いです。

ステップ4：すべての子要素を検証する（許容誤差2 px）

デザインを崩さないための肝心な部分です。あるフレームにAuto Layoutのプランを適用した後、エンジンはすべての子要素の位置を元のピクセル単位で正確なレイアウトと照合します。各子要素は、ブラウザが配置した場所から2 px以内に収まらなければなりません。

• すべての子要素が一致すれば、そのプランが採用されます。
• 一致しなければ、よりシンプルなプランを試します。 たとえば、より積極的な配置やFillの設定を外した単一のスタックです。
• どのプランも一致しなければ、そのフレームは絶対位置を保ちます。

ルールはシンプルです：デザインは決して崩れません。 複雑なセクションではAuto Layoutのフレームが少なくなるかもしれませんが、気づかないうちにずれるレイアウトになることはありません。

どのくらいの頻度で成功するのでしょうか？ 実在のサイトでの自社テストでは、およそ86〜97%のフレームでAuto Layoutが推定されました。たとえば、ある製品サイトでは93%、LinearとStripeでは88%でした。結果はページの作り方によって変わるため、これらは保証ではなく測定値としてお考えください。

ステップ5：絶対配置のまま残るフレームの制約

絶対位置を保つフレームも、置き去りにはされません。エンジンはそれらに適切な制約を設定します：

• Stretch — 全幅の背景レイヤーなど、親全体に広がる要素向け。
• Scale — 比例してリサイズされるべき要素向け。
• Center — 親の中で中央に配置された要素向け。
• Min — 左端または上端に固定。
• Max — 右端または下端に固定。

そのため、絶対配置のフレームでも、親をリサイズしたときに妥当な振る舞いをします。

ステップ6：診断 — フレームが絶対配置のまま残った理由

結果画面には、そのインポートのフレーム数、レイヤー数、Auto Layoutの割合が、不足フォントや警告とともに表示されます。さらに、特定のフレームが絶対配置のまま残った理由も一覧表示されます。実際には、子要素が重なっている、通常のフローの外にある、あるいは1つのスタックとして表現できないほど間隔が不規則なセクションが、絶対配置のまま残る傾向にあります。

この診断は2つの点で役立ちます：

• デザイナーにとって — 完全にレスポンシブにする必要がある場合、どのセクションを手作業で変換すべきかがわかります。
• 開発者にとって — 必要以上に複雑なレイアウトコードのヒントになることがよくあります。

CSSのflexboxとgridからAuto Layoutへ：対応表

エンジンは実測ジオメトリをもとに処理するため、以下の対応表はCSSプロパティの文字どおりの変換ではなく、典型的な結果を示しています。さらに詳しくは、CSSのflexboxとgridをFigmaのAuto Layoutにをご覧ください。

具体例：3枚のカードが並ぶ料金セクション

各ステップを具体的にするために、よくあるセクションを思い浮かべてください。上部に中央寄せの見出しとサブ見出しがあり、その下に3枚の料金カードが1行に並んでいます。各カードには、プラン名、価格、機能リスト、ボタンがあります。

エンジンは通常、次のように処理します：

1. ピクセル単位で正確な組み立て。 すべての要素を実測位置に配置します。この時点でセクションはすでに正しく見えます。
2. 最も内側のフレームから。 各機能リストは、一定の間隔を持つ縦のスタックになります。各カードは、名前、価格、リスト、ボタンからなる縦のスタックになり、パディングはカードの端までの距離から算出されます。
3. カードの行。 3枚のカードは同じ幅、同じ間隔で横に並んでいるため、行は1つの間隔を持つ横のスタックになり、各カードは幅を均等に分け合うようにFillに設定されます。
4. ヘッダー部分。 見出しとサブ見出しは中央寄せなので、Centerに揃えた縦のスタックになります。
5. 検証。 すべてのフレームのすべての子要素を、元の位置と照合します。たとえば「Most popular」のバッジが中央のカードの上端に重なっている場合、そのカードのプランは2 pxのチェックを通らないかもしれません。エンジンはよりシンプルなプランを試し、それも一致しなければ、そのカードは制約付きで絶対位置を保ちます。そして結果画面で、それがどのフレームだったかを知らせます。

結果は、リサイズできるセクションです。フレームを広げればカードが一緒に広がり、機能リストを編集すればカードもそれに合わせて伸びます。Components & hover states（Pro）を使えば、3枚のカードは構造が共通しているため、1つのコンポーネントのインスタンスとして取り込まれることもあります。

実際の作業で何が変わるか

インポートしたページを開くと、次のことができます：

• 見出しを編集するとセクションが伸び、その下のコンテンツが押し下げられます。
• 間隔の値を1つ変えるだけで、カードのグリッドを詰められます。
• フレームをリサイズすると、Fillのアイテムが伸び、中央寄せのコンテンツはその場に留まります。
• カードをコンポーネントのインスタンスに差し替えられます。 Components & hover states（Pro）を使えば、繰り返されるカードがすでにコンポーネントになっている場合もあります。

これが、フレームツリーと平坦化された画像を分けるものです。その違いについては、HTML to canvasの比較で詳しく取り上げています。

Auto Layoutの結果を良くするためのヒント

1. 正しい幅でインポートする。 DesktopにはSite widthを使い、Responsive setでTabletとMobileを追加して、各ブレークポイントを確認できるようにしましょう。
2. オーバーレイを非表示にする。 Hide cookie banners & popupsをオンにすると、固定表示のダイアログがセクションに重なって絶対配置を強いることがなくなります。
3. 安定した状態をキャプチャする。 アニメーションはキャプチャ時に静止しますが、遅れて読み込まれるコンテンツにはExtra wait（Pro）が役立ちます。
4. 手作業で変換する前に診断を確認する。 どのフレームを見るべきかが正確にわかります。
5. レイヤーが公開中のページと一致しているかを確認したいときは、Reference screenshot（Pro）を使いましょう。

さらに詳しく

• インポートの流れ全体：HTMLをFigmaに変換する方法
• すべての変換機能：機能
• すべてのオプションの解説：ドキュメント
• プランと制限：料金

プラグインを入手して、よく知っているページをインポートしてみてください。エンジンを理解する一番の近道は、結果をリサイズして何が保たれるかを確かめることです。