画面をレゴブロックのように組み立てる

Introduction to Atomic Design Systems

Web制作において「ページ数が増えるほどデザインの統一感が失われる」「ボタンやフォームの仕様変更が入るたびに修正作業が全ページに波及する」といった課題に直面することは少なくありません。

こうした手戻りや品質のブレを防ぐために不可欠なのが、ページ単位ではなく「コンポーネント（部品）」単位で画面を構造化する思考法です。その代表的なフレームワークがAtomic Design（アトミック・デザイン）です。

一見すると難解に思える概念ですが、本質は「Webサイトをレゴブロックの組み合わせとして分解・整理すること」にあります。本記事では、Atomic Designの基本概念から、実際のWeb制作現場で破綻させないための実用的なアレンジ手法までを分かりやすく解説します。

【追記】
※この記事は2024年に公開されたコンテンツです。
2026年現在の最新トレンドや運用のアップデートについては、以下の記事をご覧ください。

Atomic Designはもう古い？現代のコンポーネント設計術

---

目 次

1. なぜページではなく「パーツ」で分解するのか？
2. Atomic Designの5つの分類（階層モデル）
3. 現場で「Atomic Design」が迷走しやすい原因と対策
4. 実務で迷わない！シンプルにまとめる「3段階分類法」
5. 失敗しないための「過度な共通化」を防ぐ注意点
6. まとめ

---

読了目安: 約7分 / 約3,200字

---

なぜページではなく「パーツ」で分解するのか？

昔ながらのWeb制作では、「トップページ」「会社概要」「サービスページ」といった「ページ単位」でデザインやコードを作るのが一般的でした。

しかし、この作り方には次のような大きな落とし穴があります。

• 似たようなボタンなのに、ページごとに角丸や余白がビミョーに違う
• 「ボタンの色を変えて」と言われたら、全ページのコードを修正して回る羽目になる
• 新しいページを作るたびに似たようなコードが増え、管理が大変になる

特に大規模なサイトや長期的に運用するメディアの場合、「あっちのページのボタンは角丸5pxなのに、こっちのページは角丸8pxになっている」といった細かな表記揺れが積み重なり、Webサイト全体のブランドイメージを損ねてしまいます。また、修正漏れによるバグ対応などで、制作者の精神的コストも大きく削られていました。

こうした無駄な作業やデザインのブレを防ぐのが「パーツ単位（コンポーネント）」で考えるスタイルです。あらかじめ「サイト共通で使うレゴブロック（パーツ集）」を作っておき、実際のページはそのブロックを並べて組み立てる形に切り替えます。

Atomic Designの5つの分類（階層モデル）

Atomic Design（アトミック・デザイン）では、画面のパーツを「原子（最小パーツ）」から「ページ（完成形）」までの5つの段階に分けて組み立てていきます。

[原子: Atoms] ─> [分子: Molecules] ─> [組織: Organisms] ─> [テンプレート: Templates] ─> [ページ: Pages]

化学の分子構造に例えられていますが、基本的には「一番小さな部品（レゴブロック1個）を組み合わせて、最終的に大きな部屋（完成したWebページ）を作る」というイメージです。

原子（Atoms）

これ以上小さく分解できない、デザインの「最小パーツ」です。ボタン単体や文字入力枠など、これだけでは機能として成り立たないものが多く含まれます。

• 具体例： ボタン、入力枠、アイコン、見出し、カラーパレット

分子（Molecules）

2つ以上の「原子」を組み合わせて、ひとつの小さな機能を持たせたパーツです。

• 具体例： 「入力枠」＋「ボタン」＝ 検索フォーム
• 具体例： 「アイコン」＋「ユーザー名」＝ プロフィール見出し

組織（Organisms）

「分子」や「原子」を組み合わせて作る、独立して成り立つ大きなブロックです。実際のWebサイト上で明確な役割を持ちます。

• 具体例： ヘッダー全体（ロゴ＋メニュー＋検索フォーム）
• 具体例： 記事カードの一覧エリア、お問い合わせフォーム全体

テンプレート（Templates）

実際のテキストや画像（コンテンツ）が入っていない、骨組み（レイアウト配置）の状態です。どのコンポーネントがどこに配置されるかという「構造」を定義します。

• 具体例： 記事詳細ページのワイヤーフレーム（ヘッダー・メインコンテンツ・サイドバー・フッターの位置関係）

ページ（Pages）

テンプレートに実際の写真や文章を流し込んだ「完成画面」です。ユーザーが実際に目にする状態で、「文字が長すぎたときに表示が崩れないか」といったチェックもここで行います。

単に見た目を確認するだけでなく、「ブログ記事のタイトルが想定より長くて3行になってしまった時にレイアウトが崩れないか」といった、実際のデータが入った際の耐久テストを行う重要なフェーズでもあります。

現場で「Atomic Design」が迷走しやすい原因と対策

Atomic Designは非常に優れた考え方ですが、Web制作の現場でそのまま使おうとすると、チーム内で「ある問題」が発生して迷走しがちです。

迷走の原因：「これは分子？それとも組織？」問題

特にデザイナーやコーダーを悩ませるのが、「分子（Molecules）」と「組織（Organisms）」の境界線がわかりにくいという点です。

例えば、「写真＋タイトル＋文章＋ボタン」がセットになったカード型UIを作ったとき、「これは分子？それとも組織？」と人によって意見が分かれます。その結果、「パーツをどのフォルダに入れればいいか」という分類作業だけに無駄な時間（コスト）がかかってしまうのです。

実務で迷わない！シンプルにまとめる「3段階分類法」

ルールに縛られすぎて作業スピードが落ちては意味がありません。そのため実際の制作現場では、Atomic Designの良さを残しつつ、よりシンプルにまとめた「3段階の分類ルール」にアレンジして運用するのがおすすめです。

階層	分類名	概要・定義	該当するコンポーネント
1	Atoms（基本パーツ）	これ以上分解できない単体要素	ボタン、フォーム入力枠、バッジ、アイコン
2	Components（UIモジュール）	複数のパーツを組み合わせた共通UI	カード要素、アコーディオン、タブ、モーダル
3	Sections（複合エリア）	画面の大部分を占める大きなレイアウトブロック	ヒーローエリア、ヘッダー/フッター、CTAブロック

3段階にまとめると何が良いのか？

このようにルールをシンプルにしておくことで、「迷ったらまず①か②で作っておく」という判断がすぐにできるようになります。

結果として、デザイナーとコーダーの間の認識のズレがなくなり、無駄な相談や手戻りを大幅に減らすことができます。

失敗しないための「過度な共通化」を防ぐ注意点

コンポーネント設計を始める際によくある失敗が、「すべてを共通化しようとしすぎること」です。

将来的に使うかもしれないからと、無理にパーツを共通化してしまうと、特定のページだけで使いたい少し特殊なデザインに対応できなくなります。その結果、共通パーツの中に例外処理（条件分岐）が増えてコードが複雑化し、かえってメンテナンスしにくくなるケースがあるのです。

まずは「確実に2箇所以上で使うパーツ」から順番にコンポーネント化を進め、例外的なデザインは無理に共通化しないという柔軟性を持つことが、現場で破綻させないための最大のコツです。

まとめ

「UI要素をパーツに分解する」とは、単にデザインを細かく切り分ける作業ではありません。「後から修正や追加が起きたときに、誰も困らない仕組みを作る」ためのアプローチです。

1. ページ単位の作り方をやめ、使い回せる「パーツカタログ」を作る
2. 最小パーツから完成画面までの組み立てルール（階層）を意識する
3. 実務では「Atoms / Components / Sections」の3段階に簡略化して運用する

この仕組みを取り入れることで、修正時の無駄な手戻りが劇的に減り、ページ数が増えても崩れにくいWebサイトを作ることができます。

もし、フリーランス中心の制作体制やチーム開発で、進行管理や品質維持に難しさを感じているなら、制作ルールや体制そのものを見直すタイミングかもしれません。

ゲツコーギルドでは、ディレクション業務やWeb制作を通じて、チーム構成に合わせたコンポーネント設計の導入支援や、制作プロセスの整理・マネジメントのご相談も承っています。Web制作の品質向上でお困りの際は、ぜひお気軽にお問い合わせください。

> お問い合わせ
> ギルドに所属する

---

あわせて読みたいツキヨミ

【2026年】Atomic Designはもう古い？現代のコンポーネント設計術

---

出典一覧

• Brad Frost: Atomic Design Methodology
  https://atomicdesign.bradfrost.com/
• W3C Web Content Accessibility Guidelines (WCAG) 2.1
  https://www.w3.org/TR/WCAG21/