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

簡単な答え： FigmaをプレーンCSSに変換するとは、Auto LayoutをFlexboxに変換し、塗り・spacing・タイポグラフィの各値をユーティリティクラスの近似値ではなく実際の数値として解決したうえで、依存関係のない出力を保つことを意味します。すべてのルールを完全にコントロールしたい場合や、あとから学習・インストール・上書きが必要なフレームワークを使いたくない場合に適した選択肢です。

プレーンCSSをフレームワークより選ぶ理由

MarkupGenが対応するすべての出力形式——プレーンCSS、Tailwind、Bootstrap、Bulma——は、同じソース、つまりFigmaフレームの実際の構造と値から出発します。プレーンCSSは、ファイルとブラウザの間に何も挟まらない、いわば最もシンプルな形式です。

• クラス命名規則を覚える必要がない。 Tailwindのユーティリティスケールやbootstrapのコンポーネントクラスは強力ですが、それでも習得すべきひとつの体系です。プレーンCSSはCSSさえ知っていれば十分です。
• フレームワークの重量がない。 未使用クラスをパージしても、フレームワークはビルドステップと、更新し続けるべき依存関係を追加します。プレーンCSSのエクスポートにはそのどちらもありません。
• すべてのルールをその場で編集できる。 spacingの値を変更するには、ひとつの宣言を編集するだけで済み、目的のピクセル値に対応するユーティリティクラスを探し回る必要はありません。

そのトレードオフこそ、まさにTailwindが解決しようとしているものです。スケールを強制するフレームワークがなければ、誰かが同じ数値を再利用する規律を保たない限り、コードベースが成長するにつれてspacingや色の値に不整合が生じることがあります。単一のランディングページや小規模なサイトであれば、これが問題になることはほとんどありません。多くの貢献者が関わる大規模なプロダクトの場合は、判断する前にVanilla CSS vs Bootstrap vs Tailwindを読んでおく価値があります。

実際に変換が必要なもの

Figmaフレームは一見して分かる以上の構造を持っており、それぞれの要素はCSSの特定の部分に対応します。

これらはどれも特別なものではなく、開発者がデザインをピクセル単位で手作業で再現するときに行うのと同じマッピングです。違いは、スクリーンショットを目視で推測するのではなく、フレームの実際の構造と値から行っている点です。

MarkupGenがCSSを生成する仕組み

ワークフローは出力形式にかかわらず同じ4ステップです。MarkupGenプラグインを使ってFigmaからフレームをエクスポートすると、構造・スタイル・画像がまとめて取り込まれます。次にAIが、画像を近似するのではなく、その実際の構造からマークアップを構築します。調整が必要な場合はアプリ内エディタでコンテンツ・フォント・レイアウトを微調整し、最後に最終パッケージをエクスポートします。

プレーンCSSに限って言えば、生成されるスタイルシートはフレームの実際の色とspacingの値を使用し、フレームワークの事前定義されたスケールに丸め込むことはありません——#3B82F6に設定された塗りは、最も近いTailwindのblueではなく、そのままの値として出力されます。Auto LayoutはFlexbox構造に自動的にマッピングされ（プロパティごとの詳しい対応関係はAuto Layout to CSSを参照）、レスポンシブな挙動も、別途手作業のパスを追加するのではなく、フレームのリサイズ制約から生成されます。出力されるHTMLはデフォルトでネストした<div>よりもセマンティックな要素を優先しており、これは保守性だけでなく、アクセシビリティやSEOの観点でも重要です。

Figmaの変数をCSSカスタムプロパティに変換する

Figmaの変数（色、タイポグラフィ、spacing、角の半径、エフェクト）は、デザインファイルの中でデザインシステムに最も近い存在であり、概念的にはCSSカスタムプロパティ——スタイルシート内のすべてのルールから参照できる、--name: valueのペアからなる:rootブロック——に対応します。前述の通り、MarkupGenの現在のCSS出力は、この:root変数層を自動的に生成するのではなく、各プロパティを要素ごとの具体的な値として解決します。そのため、このマッピングを構築するのは手作業のステップになります。とはいえ、パターンさえ理解すれば機械的な作業です。

守っておく価値のある命名規則があります。並行する別の命名体系を新たに考案するのではなく、Figmaの変数自身のグループ／名前の構造をそのまま踏襲すること（color/primary → --color-primary）です。そうすればデザインが進化していっても、両者を照らし合わせやすい状態を保てます。変数がカスタムプロパティとして存在するようになったら、エクスポートされたCSSの中で、生成された具体的な値をvar(--color-primary)のような参照に置き換えていきます。

この手法に頼る前に知っておく価値のある2つの制約があります。まず、すべてのFigma変数がひとつのCSSプロパティにきれいに対応するわけではありません——デザインの異なる箇所でボーダーの色とテキストの色の両方に使われている変数があったとしても、その用途が本質的に異なるのであれば、コード上でも紐づけたままにすべきとは限りません。また、レスポンシブな変数（ブレイクポイントごとに変化するspacingの値など）は、関連する各メディアクエリの中で再宣言する必要があります。単一の:rootカスタムプロパティは、一度にひとつの値しか保持できないためです——Figmaのブレイクポイントごとのフレームは、CSSのカスケードに基づくレスポンシブな上書きへ自動的には変換されません。

公開前に生成されたCSSをレビューする

• 値のズレを確認する。 一貫性を強制するユーティリティスケールがないため、padding: 15pxと別の場所のpadding: 16pxのような、本来同じ数値であるべき類似値がないかスキャンしましょう。
• フレームのデフォルトサイズだけでなく、実際のブレークポイントでレスポンシブな挙動を確認する。ひとつのスクリーンショットを信頼するのではなく、ブラウザの幅を実際にリサイズして確認しましょう。
• クラス／セレクタ名を確認する。 プロジェクトに独自の命名規則（BEM、CSS Modulesなど）がある場合は、マージ前に調整しましょう。
• アプリ内エディタを使う。 エクスポート後のコードを直接手で編集するのではなく、コンテンツやレイアウトの調整はアプリ内エディタで行い、再エクスポートすることでズレが生じないようにしましょう。

各エクスポートには自動でAI品質スコアも付与され、ライブプレビューを元のデザインと比較します。手動レビューの前に、公開できる状態かどうかを素早く判断する目安になります。

よくある質問

CSS出力はCSSカスタムプロパティ（変数）を使いますか？ 出力は、変数駆動のテーマレイヤーではなく、要素ごとに標準的で直接編集可能なルールを重視しています。プロジェクトでカスタムプロパティの仕組みを使っている場合は、生成された値を手作業でそこに組み込むことを想定しておいてください。

レイアウトはデフォルトでレスポンシブですか？ はい。ブレークポイントは、あとから追加されるのではなく、フレームのAuto Layoutのリサイズ制約から生成されます。個別のモバイル/デスクトップレイアウトでこれがどう機能するかは、Figmaのレスポンシブデザイン：Mobile・Desktopレイアウトの仕組みを参照してください。

Tailwind出力とはどう違いますか？ 元になるソースデータは同じですが、行き着く先が異なります。Tailwind出力は値を最も近いユーティリティクラスに解決します（スケール外の値には任意値のフォールバックを使用）。プレーンCSS出力は、デザインの正確な値を標準的な宣言としてそのまま保持します。プロジェクトがすでにユーティリティフレームワークを標準にしているかどうかで選んでください。

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

プレーンCSSのエクスポートとフレームワークベースのエクスポートのどちらを選ぶか迷っている場合、最も早い見分け方は、同じデザインで両方を実際に見比べてみることです。MarkupGenを無料で試すか、Figma→HTML変換ガイドで全体像を確認してください。まず概要だけ知りたい方は、Figma to CSSコンバーターのページをご覧ください。