Figma デザインシステムの作り方7ステップ【SaaS開発実践ガイド】

Figmaでデザインシステムをつくりたいけれど、「どこから手をつければいいかわからない」「Variables・Variants・Auto Layoutをどう組み合わせるのか」と行き詰まっていませんか？

本記事では、 FigmaのUI/UX機能を使ってデザインシステムをゼロから構築する7ステップ を、SaaS開発の現場目線で具体的に解説します。デザイントークン（Variables）の定義・3階層トークン設計・Variantsによるバリアント管理・Dev Modeを使った開発連携・ブランチ機能での継続運用まで、 Figmaツールの具体的な操作と設定値 に絞って説明します。

「デザインシステムとは何か」という概念論は最小限にとどめ、 今日のFigma作業にすぐ適用できる実装手順 を中心に構成しています。

ステップ1：デザイントークンの基礎定義

Figmaを用いたデザインシステム構築において、最初に取り組むべきステップはデザイントークンの基礎定義です。色やタイポグラフィ、余白といった基本要素を変数（トークン）として定義することで、SaaS開発におけるUIの統一感を担保します。

すべての要素を初期から細かく定義しすぎると管理コストが膨らむため、まずは主要なブランドカラーや見出しのフォントサイズなど、プロダクト全体で頻出する要素に絞って定義することが重要です。小さく始めて徐々に拡張していくアプローチが、デザインシステムの形骸化を防ぎます。

デザイントークンの具体例（SaaS向け初期設定）

SaaSプロダクトを立ち上げる際、最低限設定しておくべきトークンの具体例は以下の通りです。

• ブランドカラー: メインとなるPrimaryカラー（例：#3B82F6）と、その濃淡
• ステータスカラー: 成功（Success）、警告（Warning）、エラー（Danger）、情報（Info）を示す色
• タイポグラフィ: 見出し（H1〜H3）、本文（Body）、注釈（Caption）のフォントサイズと行間
• スペーシング: 4pxや8pxを基準とした余白のスケール（例：Space-4 = 4px, Space-8 = 8px）

現場で運用する際の注意点として、SaaS開発の技術選定を行う段階で、フロントエンドのフレームワークとFigmaの連携方法や命名規則をあらかじめエンジニアとすり合わせておく必要があります。

ステップ2：デザイントークンの階層構造と管理

ステップ1で定義したトークンをさらに効率的に運用するために、階層構造の設計が必要です。Figmaの「Variables（バリアブル）」機能を活用してトークンを管理するのが現在のベストプラクティスです。

Variablesを利用することで、カラーコードや数値の直接入力を避け、あらかじめ定義された変数を各コンポーネントに適用できます。これにより、将来的なブランドカラーの変更やダークモード対応が極めてスムーズになります。

3階層のトークン構造の具体例

トークンを設計する際は、一般的に以下の3つの階層に分けて管理します。

1. Globalトークン（プリミティブ）: 具体的なカラーコードや数値そのものを定義します。
   • 例：Blue-500 = #3B82F6
2. Semanticトークン: その数値を「背景色」や「テキスト色」といった意味合いに紐づけます。
   • 例：Color-Primary-Default = {Blue-500}
3. Componentトークン: 特定のボタンやカードなどに限定して適用します。
   • 例：Button-Bg-Primary = {Color-Primary-Default}

初期のSaaS立ち上げ期であれば、GlobalとSemanticの2階層からスモールスタートし、コンポーネントが複雑化してきた段階でComponentトークンを追加するといった柔軟な判断が求められます。

ステップ3：拡張性を意識したコンポーネント設計

デザイントークンの設計が完了したら、次はUIパーツを再利用可能なコンポーネントとして組み立てます。Figmaの「Auto Layout（オートレイアウト）」機能を活用し、画面サイズの変化に追従する基礎コンポーネントを作成します。

SaaSで頻出するコンポーネントの設計例

ここで重要になるのは、「どこまでを共通コンポーネントとし、どこからを個別画面専用のUIとするか」という線引きです。SaaS開発では、以下のような要素から共通化を進めるのが効果的です。

• 基礎要素（Atoms）: ボタン、テキスト入力フィールド、チェックボックス、アイコン
• 複合要素（Molecules）: 検索ボックス（入力フィールド＋ボタン）、リストアイテム
• 汎用モジュール（Organisms）: データテーブル、サイドナビゲーション、ヘッダー

汎用的に使う基本コンポーネントと、特定の機能に特化したローカルコンポーネントを明確に区別し、プロジェクトの成長に合わせた柔軟性を持たせることが設計の鍵となります。

ステップ4：バリアント設計とプロパティ管理

ボタンや入力フォームなどのUI要素は、状態やサイズによって複数のパターンが存在します。Figmaのバリアント（Variants）機能は、関連する複数のコンポーネントを1つのグループとしてまとめる機能です。

プロパティパネルの値を切り替えるだけで必要な状態のUIコンポーネントを瞬時に呼び出せるため、デザイン作業の効率が飛躍的に向上します。

ボタンコンポーネントのプロパティ設定例

バリアントを設計する際は、「エンジニアが実装するコードのProps（プロパティ）と一致しているか」が重要です。具体的には以下のように設定します。

• Type（種類）: Primary, Secondary, Outline, Ghost
• Size（サイズ）: Small, Medium, Large
• State（状態）: Default, Hover, Active, Disabled
• Icon（アイコン有無）: Boolean property（True/False）で管理

あらゆるUIパターンをバリアントとして網羅しようとすると組み合わせが膨大になります。テキストの変更やアイコンの表示・非表示は「コンポーネントプロパティ（Component Properties）」を利用し、バリアントの軸から切り離すことで、管理すべき総数を劇的に削減できます。

ステップ5：デザインと開発の連携フロー

いくらFigma上で美しいコンポーネント群を整理しても、それがエンジニアリングの現場で正確に実装されなければ意味がありません。デザインと開発のシームレスな連携フローを確立することが不可欠です。

効率的なハンドオフ（受け渡し）の実践例

Figmaからコードへの落とし込みをスムーズにするための具体的な仕組みとして、以下のようなツールの連携が挙げられます。

• Figma Dev Modeの活用: エンジニアがFigmaを開いた際、CSSや指定したフレームワーク（ReactやVueなど）のコードスニペットを直接取得できる状態にします。マージンやカラーコードを視覚的に素早く確認できます。
• Storybookとの連携: フロントエンド開発で用いるコンポーネントカタログ（Storybook）とFigmaのデザインデータを同期させます。これにより、実装済みのコンポーネントとFigma上のデザインに差分がないかを一目で比較できるようになります。

ステップ6：運用ルールと協業体制

Figmaで構築したコンポーネントをプロダクト開発に活かすためには、チーム全体での運用ルールとコラボレーション体制の構築が不可欠です。

コンポーネント追加・変更の承認フロー例

チーム運用において最もよく発生するトラブルが、コンポーネントの無断変更やDetach（切り離し）です。これを防ぐための具体的なフローを設けます。

1. 提案: デザイナーが新しいUIが必要と判断した場合、既存のコンポーネントで代用できないか検討します。
2. レビュー: 新規作成が必要な場合、エンジニアと実装難易度や再利用性をレビューします。
3. マージ: 承認されたコンポーネントのみを、管理者がFigmaのマスターライブラリにPublish（公開）します。

Figmaのライブラリ権限を適切に管理し、コアとなるコンポーネントの編集権限を特定の管理者に限定する運用が効果的です。初期フェーズで PMF達成 を目指すには、こうした細かな運用ルールが中長期的な開発速度を支えます。

ステップ7：継続的な運用とアップデート

デザインシステムは「一度作って終わり」ではありません。プロダクトの成長やユーザーの要望に合わせて、システム自体を進化させ続ける必要があります。

Figmaブランチ機能を活用した安全な改修

既存のコンポーネントを修正する際、他の画面や機能に意図しない影響を与えるリスクがあります。これを回避するためには、Figmaの「ブランチ（Branching）」機能を活用します。

メインのファイルを直接編集するのではなく、機能改修用のブランチを作成してデザインを変更します。チーム内で変更内容と意図をレビューした後に、メインファイルへマージ（統合）する運用を行うことで、大規模なSaaS開発でも安全にデザインシステムをアップデートできます。

定期的にデザイナーとエンジニアが参加する定例ミーティングを設け、Figma上のデザインと実装された画面の差分をチェックする時間を確保してください。

よくある質問

既存のSaaSプロダクトに後からデザインシステムを導入するには？

すべての画面を一度にリニューアルするのではなく、ボタンや入力フォームといった汎用性の高い最小単位のコンポーネントから段階的に導入することをおすすめします。新機能の開発に合わせて部分的に新しいコンポーネントを適用していく「漸進的（ぜんしんてき）なアプローチ」が安全です。

Figmaの無料プランでもデザインシステムは作れますか？

作成自体は可能ですが、チームでの運用には限界があります。無料プランでは「チームライブラリへのコンポーネント公開」機能に制限があるため、複数のファイルやプロジェクトでUI要素を効率的に共有・管理するためには、プロフェッショナルプラン以上の契約が推奨されます。

デザイントークンとFigmaのスタイルの違いは何ですか？

スタイル（Styles）は「色」や「タイポグラフィ」といった具体的な視覚表現を保存する機能です。一方、デザイントークン（Variables）は数値や色に「意味」を持たせた変数です。Variablesを使うことで、ライトモード・ダークモードの切り替えや、余白（数値）の管理など、スタイルよりも高度で柔軟なシステム設計が可能になります。

まとめ

本記事では、SaaS開発を成功に導くFigmaデザインシステムの作り方を7つのステップで解説しました。

• ステップ1: デザイントークンの基礎定義でブランドの統一感を担保する
• ステップ2: Variablesを活用してトークンを3階層で管理する
• ステップ3: Auto Layoutで拡張性を意識した基礎コンポーネントを作る
• ステップ4: Variantsとプロパティ管理でUI状態を効率的に整理する
• ステップ5: Dev Modeなどを活用しデザインと開発の連携フローを作る
• ステップ6: 承認フローを定めて無断変更を防ぐ運用体制を築く
• ステップ7: ブランチ機能を活用してプロダクト成長に合わせて継続運用する

これらのポイントを押さえ、具体的な運用ルールをチームで共有することで、UIの一貫性と開発スピードの両立が実現します。デザインシステムはチーム全体で育てていく基盤です。本記事で解説した手順を参考に、貴社の開発プロセスに最適なシステムを構築してください。