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

Tailwind CSSは、Figmaデザインをコードに落とし込む際に開発者から最もよく求められる出力形式のひとつであり、同時に手作業では最も骨が折れる形式のひとつでもあります。デザイン内のあらゆる余白、色、フォントサイズを「正しい」Tailwindユーティリティクラスへと頭の中で変換しなければならず、この変換作業こそがハンドオフの時間を静かに食いつぶしています。

Figma→Tailwindの手作業変換が遅い理由

Tailwindの価値の本質は、制約された一貫性のあるスケールにあります。余白・色・タイポグラフィはすべて、任意の数値ではなく事前定義されたトークンの集合に沿うようになっています。コードが出来上がった後はこれが大きな強みになりますが、Figmaファイルからそこへたどり着くには、誰かが手作業でこの「型合わせ」をする必要があります。

• spacingのステップを推測する。 デザイナーがpaddingを18pxに設定したとします。これはp-4(16px)なのかp-5(20px)なのか、それともp-[18px]のような任意値が必要なのか。この判断を、ファイル内のすべてのgap・margin・paddingで繰り返すことになります。
• 色をテーマに合わせる。 Figmaのカラーピッカーはtailwind.configのパレットを一切考慮しません。16進数のカラーコードはテーマのグレー・ブルー・ブランドカラーと照合する必要があり、そうしないとbg-gray-100の代わりにbg-[#f4f4f5]のような単発クラスがコード中に散らばってしまいます。
• タイポグラフィのスケールを再構築する。 フォントサイズ、行の高さ、太さはtext-*やfont-*ユーティリティに一貫してマッピングする必要があり、そうしなければFigma上では同じに見える見出しが、コード上では3通りの異なるクラスの組み合わせになってしまいます。
• すべてのブレークポイントで同じ作業を繰り返す。 上記のどれも一度きりのコストではなく、レスポンシブの各バリアントごとにsm:、md:、lg:のプレフィックスを重ねながら手作業で繰り返すことになります。

これらのステップはひとつひとつを見れば難しくありません。しかし、まさにこうした反復的で判断の余地が少ない作業こそ、不整合が入り込みやすい部分です。そして不整合なユーティリティクラスは、Tailwindを使う意味そのものを損なってしまいます。

MarkupGenが実際のデザインからTailwindを生成する仕組み

MarkupGenは、この変換作業を手早くこなすためではなく、そもそも取り除くために作られています。プレーンなCSSに出力する場合でもTailwindに出力する場合でも、ワークフローは同じです。

1. MarkupGenプラグインでFigmaからフレームをエクスポート。 フレームの構造・スタイル・画像をまとめて取得し、ワークスペースに送ります。
2. AIがデザインの実際の構造とスタイルからマークアップを構築。 ざっくりとした近似ではありません。
3. アプリ内エディタでコンテンツ・フォント・レイアウトをビジュアルに調整。 最終確定前に行います。
4. 選択した形式で最終的なコードパッケージをエクスポート。

この記事にとって最も重要なのはステップ4です。出力形式としてTailwind CSSを選ぶと、ユーティリティクラスはデザインの実際のspacing・色・タイポグラフィのトークンから生成されます。スクリーンショットからの推測ではありません。FigmaフレームのpaddingはTailwindのspacingユーティリティのうち最も近いものにマッピングされ、塗りの色はデザインの実際の色値に照らして解決され、フォントサイズや太さも対応するtext-*・font-*クラスへと引き継がれます。これは開発者が手作業で行っていたのと同じ変換作業を、目視ではなくデザインデータから直接行っているだけです。

プレーンなHTML/CSSとReactが残り2つの出力形式です。Tailwindはこの3つのうちのひとつであり、対象のコードベースに応じてエクスポートごとに選択できます。

Auto LayoutはFlexboxのユーティリティクラスになる

実際のFigmaファイルの多くは、コンポーネントらしきものにはAuto Layoutを使っているため、それがどう変換されるかは色やspacingと同じくらい重要です。MarkupGenはAuto Layoutの方向・gap・padding・整列を、対応するCSS Flexbox構造にマッピングします。Tailwind出力では、これが対応するflexユーティリティクラスとして現れます——方向は適切なflex-row / flex-colユーティリティに、gapはgap-*ユーティリティに、paddingはp-* / px-* / py-*に、整列の設定はitems-* / justify-*ユーティリティになります。レスポンシブなブレークポイントや流動的なレイアウトも、フレームに設定済みのリサイズ制約に基づいて自動的に生成されるため、別途手作業のパスを追加する必要はありません。各Auto Layoutプロパティがどのようにflexboxに対応するかをより詳しく知りたい場合は、Auto Layout to CSSを参照してください。

公開前に生成されたクラスを見直す

自動変換はデザインの大部分に対して正しいユーティリティクラスを生成しますが、マージ前にひと通り確認する価値はあります。

• 単発の数値がないか確認する。 デザインがTailwindのスケールから少しずれたspacing値を使っている場合、デザイン側を標準のステップに寄せるか、正確な値のまま残すかを検討します。
• ページ全体で色の一貫性を確認する。 特に同じコンポーネントが複数回登場する箇所では、見た目が同じ色は常に同じユーティリティクラスに解決されるべきです。
• 見出しの階層とセマンティックなタグが正しいか確認する。 出力はデフォルトで、不要にネストした<div>のないクリーンでセマンティックなHTMLとして生成されます。
• アプリ内エディタを使う。 エクスポート済みのクラスを手で編集するのではなく、内容・フォント・レイアウトをビジュアルに調整し、納得できたら再エクスポートします。

各エクスポートには自動でAI品質スコアも付与されるため、そのエクスポートがそのまま出荷できる状態か、もう一度見直す価値があるかをすぐに判断できます。

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

もし今もFigmaの値を手作業でTailwindクラスに変換しているなら、クラスが推測ではなくデザインの実際のトークンから生成されるとどれだけ手間が減るか、一度試してみる価値があります。自分のFigmaフレームでMarkupGenを無料で試すか、4ステップのワークフロー全体を知りたい方はFigma→HTMLの総合ガイドをご覧ください。ご不明な点はsupport@markupgen.comまでお問い合わせください。