はじめに
Webサイトやアプリの開発を進めていくと、画面を構成する部品（ボタン、フォーム、カードなど）がどんどん増えていきます。そうなると「この部品はどこに置けばいいんだろう」「似たような部品が複数あるけど、どれを使えばいいの?」といった悩みが出てきますよね。
この記事では、そうした悩みを解決する設計手法「Atomic Design」について、基本的な考え方から実際の使い方まで解説します。
この記事で学べること
- Atomic Designの5つの階層とその意味
- それぞれの階層でどんな部品を作るのか
- 実際の画面でどう使い分けるのか
対象読者
- UIコンポーネント（画面部品）の管理方法を知りたい方
- コードの整理整頓に悩んでいる方
- チーム開発で共通の認識を持ちたい方
Atomic Designとは
Atomic Designは、Brad Frost氏が提唱したデザインシステムの設計手法です。理科で習う「原子→分子→有機体」という考え方を、画面部品の設計に応用したものなんですね。
小さな部品から大きな部品へ、段階的に組み立てていくイメージです。
なぜ部品の整理が重要なのか
部品の整理ができていないと、こんな問題が起こります。
- 同じようなボタンがあちこちに散らばっている
- ひとつ修正したら、思わぬところが壊れた
- 新しく参加したメンバーがコードを読めない
- 同じような部品を何度も作り直している
Atomic Designを使うことで、「この部品はどんな役割を持つのか」が明確になり、これらの問題を減らせます。
5つの階層をざっくり理解しよう
Atomic Designでは、画面を構成する部品を5つのレベルに分けて考えます。
レゴブロックを想像してみてください。小さいブロック（Atoms）を組み合わせて、中くらいのパーツ（Molecules）を作り、それらを組み合わせてさらに大きな構造物（Organisms）を作る。最終的には完成した作品（Pages）になりますよね。
それでは、それぞれの階層を詳しく見ていきましょう。
各階層の詳細
Atoms（原子）- 一番小さい部品
Atomsの役割
Atomsは、これ以上分割できない最小の部品です。例えば、ボタン1つ、入力欄1つ、テキスト表示1つといったレベルの部品ですね。
特徴：
- 単体では何かの機能を果たせない
- 他の部品に依存しない（単独で動く）
- いろいろな場所で使い回せる
- 見た目だけを担当する
Xの場合下記のようなコンポーネントが該当します。
注意すべきポイント
- 複雑な処理を入れない（見た目だけに集中）
- データの管理は最小限にする
- 色やサイズの変化はパラメータで制御する
例えば「青いボタン」と「赤いボタン」を別々の部品として作るのではなく、「色を指定できるボタン」として1つの部品を作る、という考え方です。
Molecules（分子）- 部品の組み合わせ
Moleculesの役割
Moleculesは、Atomsを組み合わせて作る、シンプルな機能を持った部品です。
特徴：
- 1つの明確な目的を持つ
- Atomsを組み合わせて作られる
- 単独で意味のある機能になる
- 使い回せる範囲を意識して作る
Xの場合下記のようなコンポーネントが該当します。
Atomsとの違い
Atomsは単体では機能しませんが、Moleculesは組み合わせることで初めて「機能」になります。
例えば、入力欄とボタンを組み合わせると「検索フォーム」という機能が生まれますよね。ただし、検索フォームは「検索するための入力と送信」だけを担当します。検索結果の表示などは別の部品に任せるんです。
Organisms（有機体）- 意味のある塊
Organismsの役割
Organismsは、Atoms、Molecules、そして場合によっては他のOrganismsを組み合わせて作る、ページの中で認識できる大きな塊です。
特徴：
- ページの一部分として意味を持つ
- 複数の機能を含むことがある
- アプリやサイト特有の処理が入ることもある
- 文脈（使われる場所）に依存する場合がある
Xの場合下記のようなコンポーネントが該当します。
複雑さへの対処
Organismsは、サイトやアプリ特有の処理や状態を持つことがあります。ただし、あまりに複雑になると管理が大変になるので、以下の点に注意しましょう。
- 何を担当するのか明確にする
- 大きくなりすぎたら分割を考える
- データ取得などの重い処理は上位に任せることも検討する
Templates（テンプレート）- ページの骨組み
Templatesの役割
Templatesは、Organismsを配置してページ全体の構造を作る部品です。実際の文章や画像などのデータは入れず、「どこに何を配置するか」という骨組みだけを定義します。
特徴：
- ページ全体のレイアウト（配置）を決める
- 実際のデータではなく、仮のデータを使う
- 複数のページで同じ構造を共有できる
- 内容の配置関係を明確にする
データと構造の分離
Templatesの重要なポイントは、「データ」と「構造」を分けることです。
例えば、ユーザープロフィールページのTemplateでは、「ここにユーザー名を表示」「ここに投稿一覧を表示」という配置だけを決めます。実際の「田中太郎」というユーザー名や具体的な投稿内容は、まだ入れません。
こうすることで、同じレイアウトをいろいろなユーザーのページで使い回せますし、デザインの統一感も保ちやすくなるんですね。
Xの場合下記のようなコンポーネントが該当します。
Pages（ページ）- 完成形
Pagesの役割
Pagesは、Templatesに実際のデータを入れて、完成したページを作る部品です。
特徴：
- 実際のデータを扱う
- サーバーからデータを取得する
- URLと結びついている
- サイトやアプリ特有の処理を含む
Xの場合下記のようなコンポーネントが該当します。
データの流し込み
Pagesでは、サーバーからユーザー情報や投稿データなどを取得して、それを各部品に渡していきます。データ取得のやり方や、エラーが起きたときの対処なども、ここで行います。
実際に使ってみよう
どの階層に配置すればいい？
部品を作るときに「これはどの階層だろう？」と迷ったら、以下の質問を自分にしてみましょう。
Atomsかどうか判断する
- これ以上分けたら意味がなくなる？
- 他の部品に依存してない？
MoleculesかOrganismsか判断する
- 1つの明確な目的だけを持ってる？（Molecules）
- 複数の機能や意味を持つ塊？（Organisms）
TemplatesかPagesか判断する
- 実際のデータが入ってる？（Pages）
- 配置だけを決めてる？（Templates）
よくある失敗と対策
失敗例1：Atomsに複雑な処理を入れてしまう
Atomsはシンプルに保ちましょう。入力チェックやデータ加工などの処理は、もっと上の階層に任せます。
例えば、入力欄（Atom）では「文字を入力できる」だけにして、「メールアドレスの形式が正しいか」のチェックは、フォーム全体を管理する部品（MoleculeやOrganism）に任せる、という感じです。
失敗例2：階層を厳しく守りすぎる
Atomic Designは「こうしたほうがいいよ」という指針であって、絶対に守らなければいけないルールではありません。プロジェクトの規模や状況に合わせて、柔軟に使っていきましょう。
失敗例3：すべてを使い回せるようにしようとする
「どこでも使えるように」と考えすぎると、かえって複雑になることがあります。本当に他の場所でも使うのかを考えて設計しましょう。
チーム開発での運用のコツ
フォルダ構成を統一する
src/
components/
atoms/
molecules/
organisms/
templates/
pages/
このように階層ごとにフォルダを分けると、チーム全員が「どこに何があるか」をすぐに理解できます。
名前から役割が分かるようにする
部品の名前を見ただけで、何をする部品なのか分かるようにしましょう。例えば、UserCardなら「ユーザー情報を表示するカード」だと分かりますよね。
コードレビューでチェックすること
- 部品が適切な階層に置かれているか
- 担当する役割が明確で、1つのことだけをしているか
- 不要な依存関係がないか
まとめ
Atomic Designのいいところ・気をつけるところ
いいところ
- 部品の役割がはっきりする
- 使い回せるので、開発が早くなる
- チーム内で共通の理解が持てる
- デザインの統一感が保ちやすい
気をつけるところ
- 最初は理解するのに時間がかかる
- 小さなプロジェクトでは大げさすぎることがある
- どの階層にするか迷うことがある
最初の一歩
Atomic Designの基本が分かったら、実際のプロジェクトで少しずつ試してみましょう。最初から完璧にしようとせず、チームで話し合いながら改善していくことが大切です。
また、Storybookという部品カタログを作るツールを使うと、Atomic Designの良さをさらに実感できます。部品を独立して作れるので、開発しやすくなるんですね。
Atomic Designは、フロントエンド開発における有効な設計手法の1つです。プロジェクトの規模や特徴に合わせて柔軟に活用して、管理しやすいコードを目指していきましょう。