はじめに
UIコンポーネントをどう分割し、どう整理するか。これはフロントエンド開発で必ず一度はぶつかる悩みです。その答えとして最も有名なのが Atomic Design（アトミックデザイン） ですが、「とりあえずAtomic Designで」と採用した結果、molecules と organisms の線引きで延々と議論したり、ディレクトリ構造が破綻したりした経験を持つ方も多いのではないでしょうか。
本記事では、Atomic Designの 思想・メリット・デメリット・採用の判断基準 を整理したうえで、近年注目されている 他のUI設計思想 もあわせて紹介します。「自分のプロジェクトにどの設計思想が合うのか」を考えるための地図として使っていただければと思います。
対象読者
- React / Vue などでコンポーネント設計に悩んでいる方
- Atomic Designを採用するか迷っている、または採用したが運用に苦労している方
- Atomic Design以外の選択肢を知りたい方
本記事は特定のフレームワークに依存しない「設計思想」の話が中心です。コード例より概念の整理に重きを置いています。
TL;DR
- Atomic Design はUIを5階層（Atoms → Molecules → Organisms → Templates → Pages）に分け、小さな部品の組み合わせで画面を作る思想。デザインシステム／UIの一貫性 に強い。
- 最大のメリットは 再利用性・一貫性・共通言語。最大のデメリットは 階層の境界が曖昧 で、運用ルールがないと破綻すること。
- 「分類のための分類」になりがちなので、チームでルールを決めて運用する ことが採用成功の鍵。
- 代替・併用候補として Feature-Sliced Design (FSD)、Feature-based（bulletproof-react系）、Container/Presentational、Component-Driven Development (CDD)、BEM などがある。
- Atomic Designは「見た目の部品」、FSDなどは「機能・ビジネスロジックの単位」と 関心が異なる ため、対立ではなく 組み合わせて使える。
Atomic Designとは
Atomic Designは、Webデザイナーの Brad Frost 氏が提唱したUI設計の方法論です。化学において物質が「原子 → 分子 → 有機体」と組み上がっていくアナロジーを使い、UIを 小さな部品の組み合わせ として捉えます。
思想の核 ― 「ページ」ではなく「システム」を設計する
Atomic Designの根底にある思想は、「ページ単位ではなく、再利用可能な部品の集合（デザインシステム）としてUIを設計する」 という考え方です。
従来のWeb制作は「トップページ」「一覧ページ」といったページ単位で作られがちでした。しかしページ単位の設計では、同じようなボタンやフォームが各ページに散らばり、デザインの一貫性が崩れ、修正コストも膨らみます。
Atomic Designはこれを逆転させ、「最小単位の部品を作り、それを組み合わせてページを構築する」 というボトムアップの発想を持ち込みました。デザイナーとエンジニアが同じ語彙（atoms, molecules…）で会話できる、いわば 共通言語 を作ることが本質です。
5つの階層
TemplatesとPagesの違いは「実データが入っているかどうか」です。Templatesは構造（レイアウト）の検証、Pagesは実コンテンツでの検証という役割分担になっています。
Atomic Designのメリット
1. 再利用性が高い
小さな部品から組み上げるため、AtomsやMoleculesを 複数の画面で使い回せます。一度作ったボタンを全画面で共有できるので、UIの増改築が効率的になります。
2. デザインの一貫性が保たれる
部品を共通化することで、色・余白・タイポグラフィなどが画面間でブレにくくなります。デザインシステムとの相性が抜群 で、ブランドの統一感を担保しやすいのが強みです。
3. 修正・保守がしやすい
「ボタンのデザインを全部変えたい」というとき、Atomを1つ直せば全体に反映されます。変更の影響範囲が 部品単位で閉じる ため、メンテナンスコストを下げられます。
4. デザイナーとエンジニアの共通言語になる
「このOrganismを修正して」のように、職種をまたいで 同じ語彙で会話 できます。コミュニケーションコストの削減は、見落とされがちですが大きな効果です。
5. 概念がシンプルで理解しやすい
「原子・分子」という比喩は直感的で、設計思想の入口としての学習ハードルは比較的低めです。
Atomic Designのデメリット
1. 階層の境界が曖昧
最大の弱点です。「これはMoleculesかOrganismsか」 の判断が人によって割れ、レビューや議論で時間を浪費しがちです。明確な正解がないため、チーム内で基準を決めないと容易に崩壊します。
「この検索ボックスはMolecules？ それともOrganisms？」という議論に何時間も費やしてしまうのは、Atomic Design採用チームの“あるある”です。分類そのものが目的化していないか常に意識しましょう。
2. 過度な分割で複雑になりやすい
「とにかく細かく分ければ良い」と考えると、ファイル数が爆発し、1つの機能を追うのに何階層もたどる羽目になります。再利用されない部品まで律儀に分割 すると、かえって可読性が落ちます。
3. ビジネスロジック・状態管理の指針がない
Atomic Designは 見た目の構造 に関する方法論であり、データフェッチ・状態管理・ドメインロジックをどこに置くかは 何も語りません。アプリ全体のアーキテクチャはこれだけでは決まらない、という点を理解しておく必要があります。
4. 初期導入コストが高い
部品を洗い出し、命名規則やディレクトリ構造のルールを整備する初期作業が必要です。小規模・短納期のプロジェクトでは、このコストが見合わないこともあります。
5. 機能横断の変更に弱い
「ある機能だけを丸ごと削除・移動したい」とき、関連部品が atoms/molecules/organisms に散らばっているため、1つの機能をまたいで集約しにくい という指摘があります。これは後述のFeature-Sliced Designが解決しようとしている課題です。
採用ポイント ― 向いている場面・向いていない場面
向いているケース
- デザインシステムを構築するプロジェクト（複数プロダクトでUIを共有するなど）
- UIの 一貫性 が最重要な、規模の大きいサービス
- デザイナーとエンジニアの 協業 が密なチーム
- Storybookなどで コンポーネントカタログ を整備したい場合
向いていないケース
- 小規模・短期のプロジェクト（オーバーエンジニアリングになりがち）
- UIより ビジネスロジックの複雑さ が支配的なアプリ
- 再利用性が低く、画面ごとに作りが大きく異なるサービス
採用を成功させるコツ
-
5階層に固執しない。
atoms / molecules / organismsの3段階だけ使う、templatesは省く、といった割り切りは現場でよく行われます。 - 分類より運用ルール。「Organismsの定義」をチームで1行で言語化し、迷ったら多数決で決めて先に進む。
- 機能ベースの構造と組み合わせる。「見た目の部品」はAtomic Design、「機能のまとまり」は後述のFeature-basedで、と役割分担する。
近年は「ラベル（atoms/moleculesといった名前）そのものは重要ではなく、小さく作って組み合わせるという原則 こそが本質だ」という捉え方が主流になりつつあります。比喩に縛られすぎないことが大切です。
他のUI設計思想
Atomic Designだけが選択肢ではありません。関心の異なる代表的な設計思想を紹介します。
Feature-Sliced Design (FSD)
近年、特にReactエコシステムで注目を集めているアーキテクチャ方法論です。技術的な種類（components, hooks…）ではなく、機能・ビジネス領域でコードを分割 するのが核心です。
app / pages / widgets / features / entities / shared といった レイヤー にコードを分け、各レイヤー内を機能ごとの スライス に切ります。「上位レイヤーは下位レイヤーにのみ依存する」という明確な依存ルールがあり、大規模アプリの見通しを保ちやすいのが特徴です。
Atomic Designが UIの一貫性 を対象にするのに対し、FSDは アプリのフローとドメインの複雑さ を対象にします。関心が異なるため、FSDの shared/ui 部分にAtomic Designを適用する といった併用も可能です。
Feature-based（bulletproof-react など）
FSDほど厳格ではなく、「機能（feature）ごとにディレクトリをまとめる」 というシンプルな考え方です。features/auth、features/cart のように、ある機能に必要なコンポーネント・ロジック・APIを1か所に凝集させます。
機能の追加・削除・移動が容易で、コードの所在が直感的になります。Reactのベストプラクティス集として有名な bulletproof-react がこのスタイルを採用しており、中〜大規模アプリの現実解として人気があります。
Container / Presentational パターン
コンポーネントを 「ロジックを持つContainer」 と 「見た目だけのPresentational」 に分離する古典的パターンです。
- Presentational: propsを受け取って表示するだけ。状態を持たない
- Container: データ取得や状態管理を担い、Presentationalにデータを渡す
関心の分離（見た目とロジック）が明快で、テストもしやすくなります。Hooksの普及で「Containerコンポーネント」をわざわざ作る必要性は薄れましたが、「見た目とロジックを分ける」という思想自体は今も有効 で、Atomic Designの各部品にも自然に適用できます。
Component-Driven Development (CDD)
「小さなコンポーネントから順にボトムアップで開発・検証していく」 という開発プロセスの思想です。Storybookに代表されるツールで、コンポーネントを画面から独立させて単体で開発・確認します。
Atomic Designが「どう分類するか（構造）」の話なのに対し、CDDは「どういう順序・手法で作るか（プロセス）」の話で、両者は 非常に相性が良い です。Atomic Designで分類した部品をStorybookでカタログ化する、という組み合わせは王道です。
BEM（Block, Element, Modifier）
主に CSSの命名規則 に関する手法です。block__element--modifier（例: card__title--active）という命名で、スタイルの衝突を防ぎ、再利用性を高めます。
UIの「構造」ではなく「クラス名の付け方」というレイヤーの話なので、Atomic DesignやFSDと 競合せず併用 できます。
設計思想の比較表
| 設計思想 | 主な関心 | 分割の軸 | 適した場面 |
|---|---|---|---|
| Atomic Design | UIの一貫性・再利用 | 見た目の粒度（原子〜ページ） | デザインシステム構築 |
| Feature-Sliced Design | アプリ構造・ドメイン | 機能／レイヤー | 大規模・複雑なSPA |
| Feature-based | 機能の凝集 | 機能単位 | 中〜大規模アプリの現実解 |
| Container/Presentational | 見た目とロジックの分離 | 責務 | 部品単位の関心分離 |
| CDD | 開発プロセス | 開発の順序・手法 | コンポーネント単体開発 |
| BEM | CSS命名・スタイル | クラス名 | スタイルの衝突防止 |
これらは 対立する選択肢ではなく、関心のレイヤーが違う ものが多く含まれます。たとえば「FSDで全体構造を決め、UI部品はAtomic Designで分類し、開発はCDDで進め、CSSはBEMで書く」という組み合わせが成立します。
まとめ
- Atomic Design はUIを5階層に分け、小さな部品の組み合わせでUIを構築する思想。一貫性・再利用性・共通言語 が最大の強み。
- 一方で 階層の境界が曖昧 で、ビジネスロジックの指針がないため、これ単体でアプリ全体を設計しきることはできません。
- 採用の鍵は 「分類のための分類」に陥らないこと。5階層に固執せず、チームで運用ルールを決めて柔軟に使うのが現実的です。
- Feature-Sliced Design / Feature-based はアプリ構造の問題を、Atomic Design はUI部品の問題を扱います。関心が違うので 組み合わせて使う のが今どきの考え方です。
「どの設計思想が一番優れているか」ではなく、「自分のプロジェクトの関心はどこにあるか」 から逆算して選ぶ・組み合わせることが、後悔しない設計への近道だと思います。
参考資料
Atomic Designの現場での実感をまとめた記事です。
Feature-Sliced Designの公式サイト（代替手法の比較も充実しています）。