デザインのズレと手戻りをゼロにする、現代のパーツ設計アプローチ
Evolution of Component Design in 2026
Web制作の現場において、画面をボタンやカードなどの「パーツ単位（コンポーネント）」で作成するスタイルは当たり前になりました。その代表的な手法として、かつては「Atomic Design（アトミック・デザイン）」がよく使われていました。しかし現在では、そのまま使われるケースは少なくなっています。
その理由はシンプルです。「このパーツは分子なのか、それとも組織なのか」といった余計な分類作業に時間が取られたり、デザインと実際のコードでルールがズレてしまう問題が多かったからです。
今のWeb制作では、そうした不必要な迷いをなくし、デザインとコードを自動でピタッと一致させる「よりシンプルで崩れにくい仕組み」へと進化しています。
本記事では、昔の手法で起きがちな失敗パターンと、チーム全員でスムーズに使える現代のコンポーネント設計術をわかりやすく解説します。
目 次
- なぜAtomic Designは現場で破綻したのか？
- 現代のWeb制作における3つの新しい常識
- 迷ったらこれ！現代のWeb制作に最適な「3つの分類ルール」
- デザインとコードのズレをなくす「Design Tokens」とは？
- 明日から試せる！現代のコンポーネント設計・導入の3ステップ
- まとめ
読了目安: 約7分 / 約3,500字
なぜAtomic Designは現場で破綻したのか？
Brad Frost氏が提唱したAtomic Design（アトミック・デザイン）は「画面を小さなパーツから組み立てる」という素晴らしい考え方を広めました。しかし、実際のWeb制作現場で使っていくうちに、主に次の3つの問題で現場が混乱し、破綻するケースが増えていきました。
分類基準のブレ（「どれに入れればいいの？」問題）
例えば「写真・タイトル・文章・ボタン」がセットになったカード型UIを作ったとき、「これは分子？それとも組織？」という不毛な議論が発生します。人によって判断がバラバラになるため、パーツの格納場所が散らかり、「あのパーツどこにあったっけ？」と探す手間が増えてしまいました。結果として、探す時間だけで作業時間が削られる悪循環に陥ったのです。
「見た目だけのパーツ」と「データが入ったパーツ」の混同
Atomic Designはパーツの「大きさ（粒度）」だけで分類していたため、「ただの見た目用のボタン（どこでも使える）」と「最新ニュース一覧（特定のデータを読み込む）」が同じレベルで扱われてしまいました。その結果、パーツの使い回しがしづらくなり、仕様変更時の管理が非常に複雑になってしまいました。
パーツ同士がガチガチにくっつきすぎて直せない問題
親パーツの中に子パーツをガッチリと埋め込むような構造になりがちでした。そのため、一番小さなボタンの仕様を少し変更しただけで、それを組み込んでいるカードやヘッダーなど、上の階層のパーツすべてに影響が及んで画面が崩れ、大量の手戻りが発生してしまったのです。「1箇所直すと全体が壊れる恐怖」は、制作者の大きな心理的ストレスとなっていました。
現代のWeb制作における3つの新しい常識
昔の手法（Atomic Design）の失敗を経て、今のWeb制作では「もっと自由で、崩れにくいパーツづくり」のための3つの新しいアプローチが主流になっています。
「中身を自由に差し替えられる」仕組み
パーツの中に別のパーツを固定で埋め込むのをやめました。「枠組み（入れ物）」だけ作っておき、中に入れる要素はあとから自由にセットできる構造（差し込み口を作るイメージ）にします。これにより、デザインの変更やパーツの組み替えが驚くほど簡単になり、ちょっとした構成変更でコードを書き直す必要がなくなりました。
デザインのルール（色や余白）を一箇所でまとめて管理する
色、余白、文字サイズ、影などの基本ルールを「デザイン・トークン」と呼ばれる共通データとして一括管理します。デザインツール（Figmaなど）で色を変えれば、Webサイトのコード側にも自動で反映されるため、「デザインと実際の画面で色が違う」という不具合や連絡の手間がゼロになります。
「見た目」と「裏側の機能」を切り離して作る
「ボタンの見た目（デザイン）」と、「クリックした時にどう動くか（機能やアクセシビリティ）」を完全に別々で作るアプローチが一般的になりました。これにより、見た目をガラッとリニューアルしても、裏側の重要な機能やキーボード操作などの動作が壊れない頑丈なWebサイトが作れます。
迷ったらこれ！現代のWeb制作に最適な「3つの分類ルール」
パーツの分け方で迷わないために、今の現場では複雑な分類をやめ、「パーツの役割（使う目的）」に合わせてシンプルに3つに分ける方法がよく使われています。
| レイヤー名 | どんなパーツ？（役割） | 具体的なコンポーネント例 |
| 基本パーツ （UI / Primitives） | どこでも使える、純粋な見た目だけのパーツ | ボタン、入力枠、ダイアログ枠、バッジ |
| パターン型パーツ （Composables） | 基本パーツを組み合わせて作った、汎用的な枠組み | 問い合わせフォーム構造、カードリスト、ヘッダーナビ |
| 機能ブロック （Features / Views） | 実際のデータ（ニュースや会員情報など）が表示される大きな塊 | 記事詳細エリア、マイページダッシュボード、CTAブロック |
３つの分類にすると何が良いのか？
このシンプルなルールにすることで、「誰でも・どこにパーツを入れればいいか」が迷わなくなります。「どこでも使える見た目だけのボタン」と「実際の最新ニュースを表示するエリア」が明確に分かれているため、デザインの変更やパーツの使い回しが驚くほどスムーズになります。新しくチームに入ったメンバーでも、すぐに構造を理解できる点も大きなメリットです。
デザインとコードのズレをなくす「Design Tokens」とは？
現代のパーツ設計において、切り離せない重要な仕組みが「Design Tokens（デザイン・トークン）」です。一言でいうと、「色や余白などのデザインルールを、一箇所でまとめて管理する共通の辞書」のようなものです。
[Design Tokens (JSON)]
├──> Figma (Styles / Variables)
└──> CSS Variables / Tailwind CSS (Web Code)
なぜデザイン・トークンを使うと作業が楽になるのか？
これまでは、デザイナーがFigmaで「青色（#2563eb）」を「少し濃い青色」に変更した場合、コーダーへ連絡して手動でコードを書き換える必要がありました。そのため、修正漏れや連絡ミスの原因になっていたのです。
デザイン・トークンを導入すると、以下のようにルールを段階的に管理します。
- 基本の値： ブランドカラーやベースとなる余白の数値
- 役割の名前： 「メインボタンの背景色」「警告メッセージの文字色」などの意味付け
- パーツへの割り当て： 「お問い合わせボタン」などの個別パーツへの適用
この仕組みを作ることで、デザインツールで色や余白を変更すれば、Webサイトのコード側にも自動で変更が反映されます。結果として「デザインカンプと実際の画面で色が違う」といった不具合や無駄な手戻りが完全にゼロになります。
明日から試せる！現代のコンポーネント設計・導入の3ステップ
「新しい設計思想の良さは分かったけれど、どこから手をつければいいのか分からない」という方のために、プロジェクトへ無理なく導入するための3ステップを紹介します。
ステップ1：色と余白の「名前」をチームで共通化する
いきなりコードやツールを連携させなくても大丈夫です。まずは「メインカラー＝primary」「標準の余白＝space-md」のように、デザイナーとコーダーの間で言葉の定義（デザイン・トークン）を揃えることから始めます。
ステップ2：「見た目だけのパーツ」を独立させる
ボタンやフォームの枠など、プロジェクト全体で汎用的に使う最小パーツ（基本パーツ）を先に定義します。データや複雑な動きを持たせず、「見た目だけの状態」で独立して使えるように整理することが第一歩です。
ステップ3：パーツ同士の埋め込み（固定化）をやめる
カードUIなどの枠組みを作る際、内部に特定のテキストやボタンを直書きで埋め込まないようルール化します。「中身は外から差し替える」コンポジション構造を意識するだけで、パーツの使い回しやすさが大幅に向上します。
まとめ
現代のコンポーネント設計は、単に画面をパーツごとに切り分ける作業ではなく、「デザインとWebサイトのコードを自動でピタッと一致させる仕組み」へと進化しました。
- 大きさで分けるのをやめ、使い道に合わせた「3つの分類」に切り替える
- パーツの中に固定で埋め込まず、中身を自由に差し替えられる仕組みにする
- 色や余白のルールを一箇所でまとめて管理し、デザインとコードのズレを自動で防ぐ
昔の手法で起きがちだった不必要な迷いや手戻りをなくし、チーム全員がスムーズに動ける制作基盤を整えることが、結果としてWebサイトの品質と開発スピードを大きく引き上げます。が、結果としてWebサイトの品質と開発スピードを大きく引き上げます。
もし、フリーランス中心の制作体制や大人数のチーム開発で、デザインのブレやコーディングの品質管理に難しさを感じているなら、制作プロセスやルールそのものを見直すタイミングかもしれません。感じているなら、制作プロセスやルールそのものを見直すタイミングかもしれません。
ゲツコーギルドでは、こうした最新のコンポーネント設計を取り入れたディレクション業務や、チーム内でのガイドライン策定・マネジメントの仕組みづくりについてのご相談も承っています。Web制作の品質向上や体制構築でお困りの際は、ぜひお気軽にお問い合わせください。
あわせて読みたいツキヨミ
出典一覧
- W3C Design Tokens Community Group Specification
https://www.w3.org/community/design-tokens/ - Component-Driven Development Guidelines
https://www.componentdriven.org/
作成日: 2026.05.15
更新日: 2026.08.04
URL Copy
木村ロキ
江戸下町産。WEBプロデューサー兼CEO。東日本大震災をきっかけに、場所や時間を選ばないクリエイターの働き方を体現するべく、慣れ親しんだ東京を離れ、瀬戸内海の離島へと移住。またフリーランスの地位向上と理想的なweb制作集団を構築するために、女性制作ギルド 秘密結社キユリアス（Qrious）を立ち上げるほか、地方創生や地域活性化、クリエイターの育成や再生、再起に注力し、現在３つのクリエイティブ・ギルドと１つの再生プロジェクトを運営。ボーラーハットがトレードマーク。現在は離島から東京へと戻り、新たなステージを構築中。
