アトミックデザイン（Atomic Design）は、UIを「原子・分子・有機体・テンプレート・ページ」の5階層の部品として捉える設計の考え方です。Brad Frost氏が2013年6月10日のブログ記事で提唱し、2016年の同名書籍で体系化しました。
定義そのものは単純ですが、現場では「分子と有機体の線引きが決まらない」「もう古いのでは」という声が絶えません。この記事では原典の英文定義を確かめたうえで、メリット・デメリット、階層を切り分ける判断基準、3階層に減らしてよい条件、Reactのフォルダ構成とStorybookでの見せ方までを順に扱います。
まとめ
原典は5階層をそれぞれの役割で定義していますが、分子と有機体の差は「relatively simple」「relatively complex」という相対表現でしか示していません。この境界はチームが決める設計判断であり、決めずに始めるとレビューのたびに分類の議論が再燃します。
メリットは、部品と画面全体を行き来しながら設計でき、変更が1か所で済むことです。デメリットは分類コストとファイル管理の重さで、画面数が少なく短期で終わる案件ではこちらが上回ります。
「古い」という評価を、本記事ではBrad Frost氏が思考の型（mental model）と書いたものを分類ルールとして運用したことへの反動と見ています。原典を体現したツール Pattern Lab は2026年5月13日にアーカイブされましたが、階層の考え方自体はStorybookの公式ドキュメントやFeature-Sliced Designに引き継がれています。React案件では、共通部品だけをアトミックデザインで整理し、それ以外は機能単位のフォルダに置く構成が現実的です。
アトミックデザインの5階層とBrad Frostの原典定義
原典が定める5階層と代表的なUI部品
見た目・振る舞い・状態を1つにまとめた再利用可能なUI部品をコンポーネントと呼び、これを積み上げて画面を作る進め方をコンポーネントベース開発と呼びます。アトミックデザインは、その部品をどの粒度で切るかに名前を付けたものです。
名前は化学の比喩から来ています。原子が結合して分子になり、分子が集まって有機体になる構造を、UIの組み立てに当てはめたものです。原典のオンライン書籍Atomic Design 第2章は、各階層を次のように定義しています。
| 階層 | 原典の定義（要旨） | UIの例 |
|---|---|---|
| Atoms（原子） | これ以上分解できない基本要素 | ボタン、ラベル、入力欄 |
| Molecules（分子） | 1つの単位として働く比較的単純な部品 | 検索フォーム、商品項目 |
| Organisms（有機体） | 画面の独立した区画をなす比較的複雑な部品 | ヘッダー、商品グリッド |
| Templates（テンプレート） | 部品をレイアウトに置き構造を示すページ単位の枠 | 商品一覧の骨格 |
| Pages（ページ） | 実際の内容を流し込んだテンプレートの具体例 | 実データ入りの一覧画面 |
原典の例では、ラベル・検索入力・ボタンという3つの原子が組み合わさって検索フォームという分子になり、その検索フォームがロゴ（原子）やメインナビゲーション（分子）と組み合わさってヘッダーという有機体になります。原典はInstagramのアプリ画面にも同じ分解を当てはめ、アトミックデザインはWebに限らずあらゆるソフトウェアのUIに使えると書いています。
分子と有機体の定義に残る「relatively」の曖昧さ
原典の英文では、分子は「relatively simple groups of UI elements functioning together as a unit」、有機体は「relatively complex UI components composed of groups of molecules and/or atoms and/or other organisms」と書かれています。何と比べて単純なのか、どこから複雑なのかは示されていません。
この相対性は欠陥ではなく、原典の意図です。同じ章でBrad Frost氏は「atomic design is not rigid dogma」と書き、階層名そのものも組織に合わせて変えてよいとしています。実例として、GEのデザインチームが社内で通じやすいよう「Principles」「Basics」「Components」「Templates」「Features」「Applications」という独自の6分類に置き換えた事例を紹介しています。5階層の名前を守ることより、チームで同じ言葉が通じることを優先するのが原典の立場です。
テンプレートとページで検証すること
テンプレートは、最終的な内容ではなく「underlying content structure（内容の骨格）」を示す階層です。商品名が5文字でも80文字でも崩れないか、レビューが0件のとき空白が残らないかといった、構造の耐性を確かめる場になります。
ページは代表的な実データを流し込んだ具体例で、原典は「test the resilience of the design system（デザインシステムの耐性を試す）」場と位置づけています。共通の部品やレイアウトに起因する崩れがページで見つかったら、原典のとおり分子・有機体・テンプレートに戻って直します。ここをページ側のCSS上書きで済ませ続けると、部品の定義と実際の見た目が離れていき、階層が名ばかりになります。
アトミックデザインのメリット：原典が挙げる3つの利点
部品と画面全体の往復による設計
原典が最初に挙げる利点は「The part and the whole」、つまり抽象（部品）と具体（画面）を素早く行き来できることです。ボタン単体を作り込む視点と、そのボタンが実データ入りの画面でどう見えるかを確かめる視点を、同じ階層構造の上で切り替えられます。
実装面で効くのは変更コストです。ボタンの角丸を4pxから8pxに変える場合、同じボタンのスタイルを各ページに重複して書いていれば、該当する全ページを直すことになります。原子としてボタンを1ファイルに切り出していれば、変更はそのファイルだけで済み、参照しているすべての画面に反映されます。共通化そのものは共通CSSでもできますが、アトミックデザインは「どの粒度で共通化するか」をチームで決める物差しになります。
テンプレートとページによる構造・内容の分離
2つ目は「Clean separation between structure and content」です。テンプレートで構造を、ページで内容を扱うため、「長い商品名が入ると崩れる」のような問題を、デザインの問題か内容の問題かに切り分けて議論できます。原典はMark Boulton氏の「It’s not ‘content then design’, or ‘content or design’. It’s ‘content and design’.」を引き、内容と設計は同時に考えるものだとしています。
階層名によるチーム内の共通語彙
3つ目は「What’s in a name?」で語られる命名の利点です。componentやmoduleという言葉からは大小関係が読み取れませんが、原子・分子・有機体なら化学の基礎知識だけで階層の上下が伝わります。デザイナーとエンジニアが「これは分子として作る」と言えば、粒度の認識がそろいます。
アトミックデザインのデメリットと運用で詰まる点
分子と有機体の分類によるレビュー負担
定義が相対表現である以上、「これは分子か有機体か」に原典を根拠とした正解はありません。基準を書き出さないまま分類をプルリクエストの承認条件にすると、機能の議論より先に分類の議論が始まります。レバテックの記事（2025年7月10日公開・12月24日更新）も、この分類の難しさを出発点に3層への簡略化を提案しています。
ファイル数の増加と命名の二重管理
部品を細かく切るほどファイル数とディレクトリが増えます。さらに、ディレクトリで階層を表したうえでファイル名にもAtomButtonのような接頭辞を付けると、階層を変えるたびにファイル名の一括置換が発生し、Gitの履歴も追いにくくなります。階層の表現はフォルダかStorybookのtitleのどちらか一方に寄せ、ファイル名はコンポーネント名だけにしてください。
デザインツールと実装の分類・命名の対応
Figmaでは「Button / Primary」とバリアント単位で並ぶ部品が、実装ではatoms配下のButtonにvariantというpropsで表現される、といった表現の違いはよく起きます。Figmaのバリアントやコンポーネントプロパティはコードのpropsに対応づけられますが、どの部品をどの階層に置き、どう名付けるかまではツールが決めないため、放っておくと分類と命名が両側でずれていきます。
対処は、どちらを正とするかを先に決めることです。命名の正をデザインツール側に置き、実装のフォルダは実装の都合で決めてよいと明示し、Storybookのtitleだけをデザインツールの名前に合わせます。フォルダ構成まで両者を1対1で一致させる運用は、片方を変えるたびにもう片方の変更を強制するため、長続きしにくくなります。Figmaの部品とコードの部品を対応づける仕組みはFigma Code Connectの使い方｜UIとCLIの始め方・Professionalの制限・CLI v2移行で解説しています。
分子と有機体を切り分ける判断基準
原典の例では、ラベル・検索入力・ボタンからなる検索フォームが分子です。ECサイトのカテゴリページで、同じ商品項目（分子）を繰り返し並べた商品グリッドが有機体です。分子は1つの単位として働く部品、有機体は画面の独立した区画、というのが原典の線引きです。
ただ、この線引きだけでは決まらない部品が必ず出ます。チームで基準を書き出さないと議論は終わらないので、本記事では次の2軸を運用案として提案します。
1つ目は「画面の独立した区画として置くか」です。検索フォームはヘッダーや一覧の上など、他の部品の中に組み込まれて使われます。商品グリッドやヘッダーは、それ自体が画面の1区画を占めます。前者を分子、後者を有機体にすると、原典の例とずれません。
2つ目は「業務ルールを含むか」で、これは原典の定義ではなく配置を決めるための本記事の運用案です。商品項目に「価格は税込で表示する」「在庫切れならボタンを無効にする」といったルールを持たせるなら、原典の分類では分子でも、共通ライブラリではなくプロダクト固有のディレクトリに置きます。階層名とは別に、共通に置くかプロダクト側に置くかをこの軸で決めると、配布物に業務ルールが紛れ込みません。
迷ったら、業務ルールを持たせない形で分子として作ってください。あとから業務ルールを足すのは利用側で包めば済みますが、ルールを入れた部品を共通部品に下ろすには、そのルールを外へ追い出す改修が要ります。
「アトミックデザインは古い」と言われる理由と現在の位置づけ
思考の型を工程表として運用した反動
原典第2章には「Atomic design is not a linear process, but rather a mental model to help us think of our user interfaces as both a cohesive whole and a collection of parts at the same time.」とあります。原子から順に作る工程表ではなく、UIを全体と部品の両面から同時に見るための思考の型だという宣言です。
原子から順に作る工程表として運用したり、分類をレビューの承認条件にしたりすると、原典の想定から外れ、分類の議論にコストがかかり続けます。「古い」と感じたときは、手法を捨てる前にこの運用になっていないかを点検してください。
Pattern Labのアーカイブと引き継がれた考え方
道具の面では、Brad Frost氏らが作ったPattern Labが2026年5月13日にアーカイブされました。GitHub組織の告知は「Pattern Lab is no longer actively maintained」とし、新規リリースもセキュリティ修正も行わないと明記しています。告知はそのうえで、CSSカスタムプロパティ、デザイントークン、フレームワーク標準のコンポーネント文書化が今の主流になったと述べ、方法論の正典としては引き続きBrad Frost氏の書籍を挙げています。
階層の考え方そのものは、他の道具に移りました。Storybook 10.6の公式ドキュメントが、サイドバーを階層化する例として示すtitleは「Design System/Atoms/Button」です。Feature-Sliced Designの公式比較ページも、Atomic Designの構成階層を再利用部品の置き場であるshared/uiに取り入れ、同じ考え方をアプリ全体に広げたと説明しています。消えたのは専用ツールで、階層で部品を考える発想ではありません。書籍の第2版も、原典の公式講座サイトでforthcoming（刊行予定）と案内されています。
3階層に減らしてよい条件
分類コストを下げる現実解が、MoleculesとTemplatesを省いたAtoms・Organisms・Pagesの3階層です。本記事では、次の3つがそろうことを3階層へ減らす検討の目安にしています。
- デザイナーと実装者が同じリポジトリとStorybookを見ている
- テンプレートの構造検証を、Figmaのバリアントや実ページのStorybookで済ませられる
- 共通部品を別パッケージとして他プロダクトへ配布していない
省く階層の役割は、移し先を先に決めておきます。分子にあたる部品をAtomsとOrganismsのどちらに入れるかを命名規約に書き、テンプレートの構造検証はStorybookのページ単位のストーリーで行う、といった形です。
複数プロダクトへ共通ライブラリを配布している場合は、階層名を減らす前に、どの部品を公開し、どの部品が業務ルールに依存するかを決めてください。分子という階層名を残すかどうかより、公開範囲と依存の向きをパッケージの境界で管理するほうが、配布物への業務ルールの混入を確実に防げます。
採用を見送る条件
次のどれかに当てはまる案件では、階層設計を持ち込まないほうが早く終わります。
- 数ページで完結するランディングページや小規模なコーポレートサイト
- 公開期間が決まっていて、改修がほぼ発生しないキャンペーンサイト
- 少人数で口頭の合意が取れ、別チームへの引き継ぎや部品の再利用も予定していない体制
こうした案件では部品の再利用回数が少なく、分類とレビューに使う時間を回収できません。必要なのは階層ではなく、色・余白・フォントの値を共有することです。この部分は後述のデザイントークンが担います。
Reactのフォルダ構成とStorybookでの階層表示
5階層をそのままフォルダにする構成
最も素直なのは、階層名をそのままディレクトリ名にする構成です。設計の意図がファイルツリーを見るだけで伝わり、新しいメンバーにも説明しやすくなります。
src/
components/
atoms/
Button/
Button.tsx
Button.stories.tsx
Input/
molecules/
SearchForm/
ProductItem/
organisms/
ProductGrid/
GlobalHeader/
templates/
ProductListTemplate/
pages/
products/index.tsxこの構成が保てるのは、プロダクトが単一の業務領域で、organisms配下を一覧して目的の部品がすぐ見つかるうちです。有機体が増えてorganisms配下が名前で検索しないと探せない長いリストになったら、次の機能単位構成への移行を考える合図です。
機能単位の構成（Feature-Sliced Design）へ寄せる構成
業務領域が複数に分かれるプロダクトでは、部品を階層名ではなく機能や業務領域ごとにまとめるほうが扱いやすくなります。この方針を体系化した設計手法がFeature-Sliced Designです。第一階層は役割別のレイヤー（App・Pages・Widgets・Features・Entities・Shared。Processesは非推奨）で、その配下にcartやproductといった業務領域ごとのスライスを置きます。アトミックデザインの階層は、このうち共通部品を置くshared/uiの中だけで使います。
src/
shared/ui/ 共通の原子・分子（Button, Input, SearchForm）
entities/product/ui/ ProductCard.tsx
features/cart/
ui/CartSummary.tsx
model/useCart.ts
pages/products/ 画面切り替えの判断は、「このボタンはカート専用だ」と機能で言い切れる部品が大半を占めるかどうかです。そうなら機能単位へ寄せ、どの機能にも属さない部品が大半ならアトミックデザインの階層構成のままにします。両方を中途半端に混ぜた構成が最も保守しづらくなります。レイヤー間のimportルールや検査ツールはFeature-Sliced Design（FSD）とは？3階層とimportルール、Steigerでの検査手順【v2.1】で解説しています。
Storybookのtitleと自動タイトルによる階層表示
フォルダ構成とは別に、カタログ上の並びとして階層を表現できます。Storybook（2026年11月1日時点のnpm最新は10.6.5）では、公式ドキュメントのとおりtitleをスラッシュで区切るとサイドバーが入れ子になります。
import type { Meta, StoryObj } from '@storybook/react-vite';
import { Button } from './Button';
const meta = {
title: 'Design System/Atoms/Button',
component: Button,
} satisfies Meta<typeof Button>;
export default meta;
type Story = StoryObj<typeof meta>;
export const Primary: Story = {
args: { variant: 'primary', children: '購入する' },
};variantとchildrenは、例として想定したButtonコンポーネント側のpropsで、Storybook共通の仕様ではありません。import元はフレームワークに合わせて置き換えます（Next.jsなら@storybook/nextjs-vite）。titleを省略すると、Storybookはストーリーファイルの置き場所からタイトルを自動で推定します。5階層をフォルダに写した構成ならtitleを書かなくても階層が並び、機能単位の構成ならtitleを明示してアトミックデザインの並びに組み替えられます。設定のtitlePrefixを使えば、shared/ui配下だけに「Design System」のような接頭辞を付けることもできます。
この使い分けで、フォルダは機能単位、カタログは階層単位という分離ができます。実装の都合とデザイナー向けの見え方を切り離せるので、機能単位へ移行したあともカタログ上の階層は維持できます。導入手順はStorybookとは？使い方をv10.6で解説｜導入・Next.js連携・CSF Next・テスト、見た目の差分確認を自動化するならChromaticとは？料金と課金スナップショットの計算・Storybook導入とTurboSnap設定を参照してください。
デザイントークンとデザインシステムの中での位置づけ
デザイントークンとUI階層の責務分担
アトミックデザインは部品の組み立て方を扱いますが、部品が使う色や余白の値そのものは扱いません。そこを受け持つのがデザイントークンです。Design Tokens Community Groupは2025年10月28日にDesign Tokens Format Module 2025.10を初の安定版（Final Community Group Report）として公開しました。W3Cの標準でも標準化トラックでもなくコミュニティグループの報告書ですが、公式サイトは採用・参加している組織としてFigmaやStyle Dictionaryなどを挙げています。
形式では値を$value、種別を$typeに書き、色は文字列ではなくcolorSpaceとcomponentsを持つオブジェクトで表します。
{
"color": {
"brand-primary": {
"$type": "color",
"$value": {
"colorSpace": "srgb",
"components": [0, 0.4, 0.8]
}
}
}
}原子のボタンはこのトークンを参照するだけにし、色の値を部品に直接書かないでください。そうすればブランドカラーの変更はトークン1か所で済み、階層の構造には触れずに済みます。値はトークン、組み合わせ方はアトミックデザインの階層、と責務を分けるのが基本形です。デザインシステム全体の構成はデザインシステムとは？構成要素と作り方、ガイドライン・スタイルガイドとの違いで整理しています。
公開デザインシステムの部品粒度の確認
公開されているデザインシステムが、アトミックデザインの階層名をそのまま採用しているとは限りません。原典が紹介したGEのように、独自の名前に置き換えた例もあります。デジタル庁デザインシステムはReact版とHTML版のコンポーネントをStorybookで公開しており、自社で階層を決める前にどの粒度で部品を切っているかを実物で確かめられます。入手手順はデジタル庁デザインシステムのStorybookとGitHub｜React 19版・Figma v2.18.2の入手と取り込み手順にまとめました。部品の粒度や画面の設計から外部に相談したい場合は、弊社のUI/UXデザイン支援でも対応しています。
よくある質問
アトミックデザインとアトミックCSSは同じものですか？
別物です。アトミックCSSは、1つのクラスに1つのスタイルだけを持たせるCSSの書き方で、TailwindCSSやUnoCSSが代表例です。アトミックデザインはUI部品の階層の考え方で、原典は「atomic design has nothing to do with web-specific subjects like CSS or JavaScript architecture」とCSS設計との関係を明確に否定しています。両者は組み合わせて使えます。アトミックCSSの側はUnoCSSとは？アトミックCSSエンジンの設定と採用判断を実装目線で解説で扱っています。
「アトミック」という言葉は何に由来しますか？
化学の原子（atom）です。原子から分子、有機体へと組み上がる化学の階層をUIに当てはめた比喩で、Atoms・Molecules・Organismsの並びも化学用語をそのまま使っています。家具やテキスタイルで言う「アトミック柄」（原子のモチーフを使った柄）や、データベースのトランザクションの「アトミック（不可分）」とは関係ありません。
アトミックデザインを学ぶための公式資料や書籍はありますか？
一次資料はBrad Frost氏のオンライン書籍Atomic Designで、全章が無料で読めます。階層の定義と思考の型としての位置づけは第2章にあります。日本語では、五藤佑典氏の『Atomic Design ～堅牢で使いやすいUIを効率良く設計する』（技術評論社、2018年4月25日発売、A5判320ページ、ISBN 978-4-7741-9705-0）が定番で、Reactでの実装例を含みます。
Material UIなどの既製ライブラリを使うときも必要ですか？
原子にあたる部品はライブラリが提供済みなので、自社で設計するのは分子より上の層です。既製ライブラリを採用しているのに原子から自作すると、同じボタンが2系統できて更新のたびに差分が出ます。導入時は、ライブラリがどの階層まで供給しているかを最初に線引きしてください。VueやAngularでも、考え方はフレームワークに依存せず同じように使えます。
稼働中のプロジェクトに後から導入できますか？
できますが、既存部品を一括で階層に振り分ける進め方は避けてください。動いているUIを分類し直す作業は機能追加を止め、途中で放棄されると階層あり・なしのファイルが混在した状態が残ります。新しく作る部品からルールを適用し、既存部品は改修のタイミングで移すほうが確実です。先にStorybookへ既存部品を登録して一覧にすると、重複している部品と移す順番が見えます。
