アトミックデザインシステムは、スケーラブルで保守性の高いユーザーインターフェースを構築するための手法として登場しました。本ガイドでは、アトミックデザインとは何かを包括的に解説するとともに、2025年においてもアトミックデザインは有効なのかを検証し、さらに化学のメタファーとしての枠を超えて、アトミックデザインの原則をどのように応用できるかを明らかにします。
10年にわたる業界経験とブラッド・フロスト氏自身の直接的な洞察に基づき、この記事は、厳格な分類よりも、明瞭性、保守性、そして製品化への対応を優先する現代的なデザインシステムを実装するための実践的なガイダンスを提供します。
アトミックデザインとは？その核となるコンセプトを理解
「アトミックデザインとは何か？」という根本的な問いに答えるには、表面的な化学のメタファーを超えて考える必要があります。2013年にブラッド・フロストによって提唱されたアトミックデザインは、階層的な構成、つまりより小さく再利用可能なコンポーネントから複雑なユーザーインターフェースを構築する手法を重視したデザインシステム構築手法です。
アトミックデザイン原則は、当初5つの異なるレベルを提案:
- Atoms(原子) : ボタン、入力、ラベルなどの基本要素
- Molecules(分子) :アトムを組み合わせた単純なコンポーネント
- Organisms(有機体) : 分子とアトムを組み合わせた複雑なコンポーネント
- Templates(テンプレート) : ページレベルのレイアウト構造
- Pages(ページ) : 実際のコンテンツを持つテンプレートの具体的なインスタンス
これらのカテゴリは、この記事全体を通して検討していくように、便利なメンタルモデルを提供しますが、特定のラベルよりも、それらが表す基本原則、つまりインターフェース構築に関する体系的かつ階層的な考え方の方が重要になってきています。
「2025年でもアトミックデザインは有効なのか？」と疑問に思っている方へ。答えは「イエス」です。ただし、皆さんが想像するような意味合いではありません。現代の実装は、厳格なカテゴリを超えて進化し、より柔軟でセマンティックなアプローチを採用することで、現代の開発ワークフローをより適切にサポートしています。
カテゴリー化のトラップ
やデザインシステムを作り始めた当初、私も多くのデザイナーと同じように、「デザインシステムの作り方」をインターネットで検索しました。そこで出会ったのが、Brad Frost’s blog のブログや、アトミックデザインについての 電子書籍でした。しかし私は、業界のさまざまな現場で多くのデザイナーが陥ってきたのと同じ過ちを犯してしまいました。アトミックデザインを文字どおりに解釈し、そのまま適用しようとしたのです。
この文字通りの解釈こそが、分類に関する果てしない議論の原因です。カードの構成要素は分子か生物か？ボタンの集合は分子と言えるのか？こうした議論は知的には興味深いものでしたが、効果的なデザインシステムを構築するという本質的な作業の妨げになることがよくありました。後になって気づいたことですが、こうした厳格な分類へのこだわりは、全体像を見失うようなものでした。
なぜそれが間違いだとわかるのでしょうか?
"答えは情報源から直接届きました。ブラッド・フロスト氏にメールを送り、こう尋ねました。「10年ほど経ちましたが、今でもAtomic Designは正しいアプローチだと思いますか？ 私自身、Atomsの必要性を見出せず、コントロールとトークンのシステムを作ってしまうことがよくあります。」
ブラッド・フロストの啓示：ラベルは決して重要ではなかった
彼の返答は、とても示唆に富むものでした。「Atoms、Molecules、Organisms、Templates、Pages といった具体的なラベル自体が本質だったことは一度もありませんし、実際の仕事の中でそれらをそのまま使っているわけでもありません。ただし、思考のためのメンタルモデルとしては今でも有用です。」
この発見により、私は彼の原著を読み返し、最終章で次の重要な一節を見つけました。
「アトミックデザイン」は流行語として、モジュール設計と開発の概念を凝縮したものであり、ステークホルダーを説得したり、同僚と話し合ったりする際に便利な略語となります。しかし、アトミックデザインは厳格な教義ではありません。結局のところ、どのような分類法を選択するにしても、あなたとあなたの組織がより効果的にコミュニケーションを取り、UIデザインシステムを作り上げるために役立つ分類（タクソノミー）を選ぶことです。 - ブラッド・フロスト
この考え方は、アトミックデザインシステムへの向き合い方そのものを根本から捉え直すものです。「これはアトムか、モレキュールか」といった分類にとらわれるのではなく、チームの具体的なニーズに応え、コミュニケーションを促進する分類法を作成することに重点を置くべきです。この柔軟性こそが、ツールやワークフローが進化し続けても、アトミックデザインの原則が永続的に価値のあるものである理由です。
アトミックデザインの原則が実際に教えてくれること
化学のメタファーを超えて、アトミックデザインは現代のデザインシステム開発において依然として重要ないくつかの基本原則を教えてくれます。
重要なのは、コンポーネントを「アトム」「モレキュール」「オーガニズム」に分類することではありません。本質は、階層的な構成を理解すること、つまり、小さな構成要素がどのように組み合わさって、より大きく複雑な構造を形作るのかという点です。
真の教訓は、コンポーネントを他のコンポーネントをネスト（入れ子に）することです。ただ、それだけです。これが核となる考え方です。しかし、このシンプルな概念は、デザインシステムの構築方法に大きな影響を与えます。
- モジュール性： すべてのコンポーネントは独立して機能すると同時に、他のコンポーネントと組み合わせることも可能である必要があります。
- 再利用性： 一度構築すればどこでも使用できるため、技術的負債とメンテナンスの負担が軽減されます。
- 一貫性： すべてのパターンに単一の情報源が存在するため、視覚的および動作的な一貫性が確保されます。
- スケーラビリティ： スケーラビリティ：既存のコンポーネントから新しい機能を構築できるため、開発が加速されます。
出典： Brad Frost - Extending Atomic Design
これらの原則を理解すると、より実践的な疑問が浮かび上がります。化学ラベルではなく、どのような命名規則を使用すべきでしょうか？
解決策：アトミックデザインラベルよりもセマンティックシステム
抽象的な化学カテゴリーからセマンティックシステムへの進化は、アトミックデザイン手法の成熟を表しています。コンポーネントを抽象的な化学カテゴリーに押し付けるのではなく、現代のデザインシステムでは、コンポーネントが「何をするのか」「どこで使われるのか」を反映した、目的志向で意味のある名称が使われています。
デザインにおけるセマンティックシステムとは？
デザインにおけるセマンティックシステムとは、すべての要素の名前がその意味、目的、そしてインターフェース内での振る舞いを直接伝える手法です。構造の複雑さ（アトミックデザインの化学メタファーなど）に焦点を当てた抽象的な分類システムとは異なり、セマンティックシステムは人間の理解と実用性を重視します。
こう考えてみてください。Modal.Warning.SpeedLimit という名前のコンポーネントに出会ったとき、あなたはすぐに次の3つのことを理解します。
- それが何であるか：警告の表示（モーダルダイアログ）
- その目的：ユーザーへの注意喚起
- その具体的なコンテキスト: 速度制限に関連していること
この瞬時の理解こそが、セマンティックネーミングの威力です。Organism_7 というラベルのコンポーネントを見つけるのと比べてみましょう。そのコンポーネントの目的を理解するには、コンポーネントを詳しく調べたり、ドキュメントを参照したりする必要があります。
セマンティックシステムは、チームコラボレーションの変革
- 開発者はドキュメントを詳しく調べなくても、どのコンポーネントを使用すべきかをすぐに特定できます。
- 設計者はコンポーネント名だけで意図を明確に伝えることができます。
- コンポーネント名が機能を反映することで、QAチームは問題をより効果的に追跡できます。
- システムが自己文書化されているため、新しいチームメンバーのオンボーディングが迅速化されます。
- 関係者は抽象的な用語を習得することなく、議論に参加できます。
アーキテクチャの観点から見ると、セマンティック（意味的）なシステムは、ユーザーやデザイナーの思考モデルとシステム実装を直接対応づけることができます。
デザイナーが「速度制限に関する警告が必要だ」と考えたとき、探すのはまさにそのコンポーネントであって、「大きなモレキュール」や「複雑なオーガニズム」ではありません。
まさにそれを求めます。思考と実装のこのような整合性により、認知負荷が軽減され、開発が加速されます。
コンポーネント命名サンプル
化学ベースのカテゴリ分けではなく：
- Atom: Button
- Molecule: Button Group
- Organism: Navigation Bar
セマンティックでコンテキストに基づいた名前の使用：
- Button.Primary
- Button.Secondary
- Button.Disabled
- Navigation.Main
- Navigation.Settings
- Header.Global
- Modal.Warning
- Card.Status
たとえば 自動車の HMI 開発において、規制対応のためにコンポーネントの使用箇所を追跡する必要がある場合、Organism_7 よりも Modal.Warning.SpeedLimit のほうが、はるかに有用です。
実践における階層的なビルディングブロック
階層的な構成がどのように機能するかを見てみましょう。
階層的な構成要素という観点からのデザインを考える際のポイント：
- 意図をもって設計できる – それが「どこで」「どのように」使われるのかを考えながら設計
- 再利用可能なコンポーネントの作成 – 一度の作成でどこでにでも使える
- 一貫性の維持 – すべてのパターンに対して唯一の正しいソース（Single Source of Truth）を持てる
- 明確なコミュニケーション – カテゴリ分けの議論に時間を取られない
例としてダッシュボード画面を構築する場合：
- Base components (buttons, inputs, labels)
- Composite components (forms, cards, data tables)
- Layout components (grids, containers, navigation)
- Page templates (dashboard layout, detail view, list view)
このような階層的なアプローチにセマンティックな命名を組み合わせることで、チームにとって強力で直感的に使えるシステムが生まれます。
デザイントークン：現代的なアトミックデザインシステムの基盤
デザイントークンとは、ビジュアルデザインの属性を定義するために名前付けされたプロパティのことです。Brad Frost が 10 年以上前にアトミックデザインを提唱した当時、トークンはまだ標準化されていませんでした。しかし現在では、モダンなアトミックデザインシステムに不可欠な存在となり、コンポーネントを真に再利用可能かつテーマ対応可能にするための基盤レイヤーを担っています。
たとえば、#3B82F6 や 16px といった値をデザインやコードの中に直接書き込む代わりに、color.primary.active や padding.md のようなトークンを作成し、それらが具体的な値を表すようにします。これによりマスターコンポーネントと同様に「唯一の正しいソース（Single Source of Truth）」が生まれます。
プログラミングの観点で言えば、トークンは色、余白、タイポグラフィ、その他すべてのコンポーネント構成要素を定義するグローバル変数のようなものです。デザイントークンは、スケールしても一貫性を保てる現代的なアトミックデザインシステムの土台を形成します。
トークンシステムの構築
プリミティブトークン（基盤）
値に意味を持たせたネーミング
- blue_500: #3B82F6
- neutral_800: #1F2937
- spacing_L: 16px
- spacing_XL: 24px
セマンティックトークン（文脈）
プリミティブトークンを参照して定義
- color.primary: blue_500
- color.text.default: neutral_800
- color.text.inverse: neutral_000
- spacing.button.padding: spacing_L
- spacing.card.gap: spacing_XL
トークンのカテゴリ
現代的なデザインシステムでは、通常以下のようなトークンを定義：
- Color（カラー） – Brand, semantic, text, background, border
- Spacing （スペーシング） – Padding, margin, gap
- Typography（タイポグラフィ） – Font family, size, weight, line height
- Layout（レイアウト） – Grid, density, breakpoints
- Effects（エフェクト） – Shadow, blur, opacity
- Motion（モーション） – Duration, easing, delay
- Semantic names（セマンティックな名称） – Success, warning, error, info
- Theme modes（テーマモード） – Light, dark, high contrast
W3C コミュニティでは 2019 年以降、デザイントークンの標準化を進めています。
プリミティブトークンが重要な理由
プリミティブトークンは、デザインシステムに制御レイヤーを追加します。カラーのトークンを例にすると、Black や White といったプリミティブトークンを用意し、それらを 背景色・テキスト色・ストローク色 など、複数のセマンティックトークンから参照します。
プリミティブトークンはテーマ対応に不可欠：
- プリミティブトークンは、テーマが変わっても一定
- セマンティックトークンは、テーマごとに参照するプリミティブトークンが変わる
- ニュートラルカラーの色味を調整する場合も、1つのプリミティブトークンを変更するだけ
- それを参照している すべてのセマンティックトークンが自動的に更新される
メリット：
- 時間を節約できる - 一度変更すれば、デザインシステム全体に反映される
- 一貫性を保てる - バラバラな値や単発の色指定がなくなり、ビジュアルの統一感が保たれる
- 検証しやすくなる - トークン化すべき生の値を発見しやすくなる
- アクセシビリティを支援できる - WCAG のコントラスト基準を満たしているか確認しやすい
- ホワイトラベリング*に対応しやすい - トークンの値を更新するだけで、素早くブランド変更が可能
*開発・製造した製品やサービスを、さまざまなブランド名やロゴを付けて販売する仕組み
セマンティックシステムが、テーマごとに異なるプリミティブトークンを参照している様子を示しています。
テンプレートとページ：今も有効なアトミックデザインの原則
アトミックデザインにおけるラベル（Atoms / Molecules など）は以前ほど重要ではなくなってきていますが、テンプレートとページは、今でもアトミックデザインの原型の中で最も価値のある要素だと私は考えています。これらの上位レイヤーの概念は、コンポーネントライブラリと実際のプロダクトUIとの間をつなぐ役割を果たします。
アトミックデザインシステムにおける「テンプレート」とは？
テンプレートとは、実際のコンテンツを含まないページレベルのレイアウト構造です。どこにどのコンポーネントが配置され、どのように構成されるかを示しますが、内容には プレースホルダー（lorem ipsum、グレーのボックス、FPO 画像など） が使われます。
テンプレートコンポーネントに含まれるもの：
- ヘッダーコンポーネント（実際のコンポーネント）
- ナビゲーションコンポーネント（実際のコンポーネント）
- レイアウトグリッドを備えたコンテンツエリア
- テキストスタイルを使ったプレースホルダーコンテンツ
テンプレートのメリット：
- 画面フロー全体で一貫したレイアウト特性を保証できる
- コンテンツが変わっても構造の整合性を保てる
- すべてのコンポーネントをライブラリと連携したまま維持できる
- 実績のあるレイアウトを使ってページ作成を高速化できる
テンプレートを使ってページを作成
Figma、Sketch、Qt Design Studio などのデザインツールでは、次のように進めます。
- テンプレートコンポーネントのインスタンスを使用する
- プレースホルダーのコンテンツを実データに置き換える
- レイアウト構造はそのまま維持される
- コンポーネントはライブラリとのリンクを保ったまま
たとえば、10画面で同じヘッダーとフッターのコンポーネントを共有する場合、ページテンプレートをベースとして作成します。このアプローチにより、一貫性を確保しつつ、新しい画面を作成するための時間を大幅に削減できます。
QMLの優位性
このプロセスは、コンポーネントインスタンスでできることが制限されている Figma のようなデザインツールでは難しくなる場合があります。一方 QML（Qt Meta-Object Language） では、完全なカスタマイズに必要な あらゆるプロパティやオブジェクトを公開できるため、複雑なインスタンスの差し替えを行う必要がありません。
たとえば、アイコンごとにコンポーネント化して多数のバリエーションを作成する代わりに、
開発者は 画像ソースのプロパティを公開（または alias 化） できます。これにより、デザイナーは 必要に応じてアイコンを切り替えるだけで済み、大量のコンポーネント派生を作る必要がなくなります。
この柔軟性は、自動車 HMI 開発のように、安全性が重要なコンポーネントに対して広範なカスタマイズが必要でありながら、その中核となる挙動や検証状態を維持しなければならない分野で特に重要です。Qt for Embedded Devices を使用する場合や、ISO 26262 standardsへの適合が求められるインターフェースを開発する場合、このレベルの制御性は不可欠になります。
QML によるアトミックシステム設計の利点
- プロパティの公開： カプセル化を壊すことなく、あらゆるプロパティを設定可能にできる
- 型の安全性： 強い型付けにより、コンポーネントの誤用を防げる
- パフォーマンス： コンパイルされた QML により、優れた実行時性能を実現
- デバッグ性： 明確なコンポーネント階層により、問題の追跡が容易になる
アトミックデザインは今でも有効なのか？
「アトミックデザインは今でも有効なのか？」という問いに対する答えは、間違いなくイエスです。ただし、その“有効性のあり方”は進化しています。
具体的な実装方法は成熟してきましたが、アトミックデザインの中核となる原則は、2025年においてもスケーラブルなデザインシステムを構築するうえで不可欠です。
なにが変わったか：
- ラベルの柔軟性 ： チームは、自分たちの文脈に合った命名規則を使うようになった
- トークンが不可欠：デザイントークンは、Frost の当初の構想にはなかった「基盤レイヤー」として定着した
- ツールの進化： 現代のデザインツールは、コンポーネントベースのワークフローをより強力にサポートしている
- 自動化の時代が到来：AI や自動化ツールが、アトミックコンポーネントの生成や保守を支援するようになった
変わっていないこと：
- 階層的な思考：シンプルで再利用可能な部品から、複雑なUIを組み立てる考え方
- 体系的なアプローチ：中央集約されたコンポーネント管理による一貫性の確保
- モジュラーアーキテクチャ：組み合わせ可能なコンポーネント設計
- 明確なコミュニケーション：デザイン上の意思決定を議論するための共通言語
重要なのは、「アトミックデザインが今でも有効かどうか」ではありません。
自分たちのチーム、目的、ツールチェーンに合わせて、その原則をどう適応させるかが問われています。
まとめ
アトミックデザインにおいて、ラベルそのものが本質だったことは一度もありません。この手法が私たちに教えてくれるのは、階層的なビルディングブロックとして考えること、そしてモジュールとして構成することこそ価値があります。さまざまな業界やプラットフォームで長年実践されてきた中で、この核心的な洞察は今もなお、最も重要な学びとして残っています。
デザインシステムが進化するにつれ、私たちが使うツールも現代的なワークフローを支える必要があります。つまり、メタファーに基づく分類よりもセマンティックな明確さ、トークン主導の一貫性、そしてデザイナーと開発者の双方にとって柔軟なコンポーネントアーキテクチャです。
次のデザインシステムを作るとき：
- カテゴリ分けの議論は脇に置き、チームにとって何が自然かを考える
- 目的志向でセマンティックな命名を行い、コンポーネント自体がドキュメントになるようにする
- トークンを基盤とした包括的なトークンシステムを構築する
- 構造とカスタマイズ性のバランスを取った柔軟なテンプレートを用意する
- 本当に重要なこと： 一貫性があり、保守しやすく、実運用に耐えるUIを作ることに集中する
問うべきなのは、「これはアトムか、それともモレキュールか？」ではありません。
本当に問うべきなのは、「このシステムは、チームがより良いプロダクトを、より速く作る助けになっているか？」です。
最終的に、アトミックデザインシステムが成功する理由は、化学のメタファーにあるのではありません。複雑さを管理するための体系的なアプローチを提供していることにあります。それをアトムと呼ぼうが、コンポーネントと呼ぼうが、ビルディングブロックと呼ぼうが本質は同じです。思慮深く階層化された構成こそが、時代を超えて通用する、スケーラブルで保守性の高いデザインシステムを生み出します。
