Design System Terminology Guideline

目的

この文書は、デザインシステムにおける用語の意味を統一し、設計・実装・ドキュメント・運用・教育のあいだで解釈のズレを防ぐことを目的とする。

命名は単なるラベルではない。命名は、その対象の責務、意味、振る舞い、適用範囲、再利用条件を表す設計上の契約である。

この文書における最重要方針は次のとおりである。

用語は既存のWeb標準と矛盾してはならない。
用語は見た目ではなく責務に基づいて定義しなければならない。
静的な構造、動的なUI、再利用部品、ページ単位の描画定義、外観テーマを混同してはならない。
同じ語を複数の意味で使ってはならない。
異なる概念を同じ語でまとめてはならない。

適用範囲

この文書は以下に適用する。

デザインシステムの用語集
UIライブラリのコンポーネント一覧
実装ガイドライン
デザイナー向けドキュメント
開発者向けドキュメント
CMS / ページビルダー / ノーコードUIの設計用語
社内レビューや設計議論における正式名称

基本原則

1. Web標準で意味が確立している語を再定義してはならない

HTML、CSS、ARIA、ブラウザ実装で既に意味が確立している語は、その意味を尊重しなければならない。

とくに以下の語は意味衝突を起こしやすいため、独自の便利語として再利用してはならない。

block
container
button
menu
columns
row

2. 見た目ではなく責務で命名しなければならない

名称は、見た目や印象ではなく、役割、意味、HTML要素、挙動、適用範囲に基づいて決めなければならない。

たとえば、ボタンのように見えるから Button と呼ぶのではなく、実体が <a> なら Link、<button> なら Button としなければならない。

3. 構造と振る舞いを混同してはならない

構造要素、静的パターン、動的UI、コンポーネント、テンプレート、テーマは、別概念として明確に区別しなければならない。

4. 総称は狭く使うべきである

意味が広すぎる名称は責務を曖昧にする。

Block、Module、Widget、Container のような広い総称は、正式名称としては原則使用すべきではない。

5. 名前は設計境界を表さなければならない

命名は分類のためだけではなく、責務分離のために存在する。

名前が曖昧な場所では、設計上の境界も曖昧になりやすい。

用語定義

Element

定義

Element は、HTML要素そのもの、またはHTML要素に直接対応する最小単位を指す。

例:

div
section
h1–h6
p
a
button
img
ul
table

ルール

HTML要素と1対1で対応する単位は Element と呼ばなければならない。
HTML要素を包括的に指す総称としては Element を優先しなければならない。
HTML要素に対して、別の抽象語を被せるべきではない。

禁止

すべての要素を Block と呼ぶこと
HTML要素の正式な総称として Module や Widget を使うこと

Section

定義

Section は、ページ内の意味的または構造的な区画を表す上位グルーピング概念を指す。

HTML 実装としては section 要素を第一候補とするが、文脈に応じて article などの他のセマンティック要素を用いる場合がある。

ルール

ページ内の区画概念は Section として扱わなければならない。
Section は概念名であり、必ずしも section 要素そのものと1対1対応するものではない。
section 要素を用いるべき場面と、他のセマンティック要素を用いるべき場面は区別しなければならない。
Section は内容幅ラッパーと同一視してはならない。

禁止

単なる汎用ボックスを、理由なく Section と呼ぶこと
Section を内容幅制御用ラッパーの意味で用いること

Container

定義

Container は CSS の container プロパティが適用された要素を指す。

ルール

container 系プロパティが適用された要素のみを Container と呼ぶこと。
section container のように関連するものとセットで呼ぶこと。Container 単体では「何の」が示されていないため、意味が通りにくい。
Container は CSS の container 機能を指す技術用語としてのみ用いること。
内容幅制御のための構造ラッパーを指す正式名称として Container を用いてはならない。

禁止

あらゆる構造ボックスを Container と呼ぶこと

備考

一般的なCSSフレームワーク（Bootstrapなど）では、Container が内容幅制御用ラッパーを指す場合がある。

本規約ではこの用法を採用せず、内容幅制御は Inner、CSS の container 機能を持つ要素のみを Container と呼ぶ。

Inner / Outer

定義

Inner は Section の直下などに配置され、内容幅の制御や中央寄せを担う内側ラッパーを指す。

Outer はコンポーネントやパターンの外側に配置され、外部余白、周辺配置、周囲との関係調整などの外部関連型レイアウトを担うラッパーを指す。

ルール

内容幅の制御は Inner の責務としなければならない。
Outer は外部余白、整列、隣接要素との関係調整に限定して用いるべきである。
Inner / Outer は単体ではなく、section inner や card outer のように関連対象とセットで用いるべきである。
Inner / Outer を万能ラッパーとして用いてはならない。

備考

典型的な構造は Section > SectionInner > ChildComponent または Section > SectionInner > ChildComponentOuter > ChildComponent とする。

原則的に Inner / Outer 共にコンポーネントの子要素として扱う。ChildComponentOuter を ChildComponent に持たせたり、ChildComponentOuter 単独でコンポーネントとしない。

禁止

Inner / Outer をコンテナクエリの対象概念と混同すること
Inner / Outer をコンポーネントの子要素以外に定義すること

Gutter

定義

Gutter は、コンテンツ外縁とビューポート端のあいだを保護するインライン方向の余白を指す。

ルール

外縁保護余白は Gutter と呼ばなければならない。
Gutter の値はトークン化し、全体で共有しなければならない。
Gutter は各Sectionごとの場当たり的なpadding調整に置き換えてはならない。

禁止

列間や要素間の空きを Gutter と呼ぶこと
Gutter を gap や space と同義で扱うこと

Gap

定義

Gap は、Flex、Grid、Multi-column などにおける子要素間の間隔を指す。

ルール

要素間の距離は Gap と呼ばなければならない。
行間、列間、カード間、チップ間の距離は gap の概念で扱うべきである。
Gap と Gutter は厳密に区別しなければならない。

禁止

通常フロー内の margin を Gap と呼ぶこと

Columns

定義

Columns は、CSS の Multi-column Layout によって配置された構造を指す。

ルール

Multi-column Layout によって配置された列配置のみ Columns と呼ばなければならない。
Flexbox による列配置は Flex Columns と呼ばなければならない。
Grid による列配置は Grid と呼ばなければならない。

禁止

FlexレイアウトやGridレイアウトを単に Columns と呼ぶこと
FlexレイアウトやGridレイアウトと Multi-column Layout を同じ用語で扱うこと

Flex Columns

定義

Flex Columns は、Flexbox によって横方向に配置された列構造を指す。

ルール

Flexbox による列配置は Flex Columns と呼ばなければならない。
Columns（Multi-column Layout）や Grid と混同してはならない。

禁止

Flexbox による列配置を単に Columns と呼ぶこと

Grid

定義

Grid は、CSS Grid Layout によって配置された構造を指す。構造的なレイアウト設計における第一級の選択肢として扱う。

ルール

構造レイアウトでは Grid を優先的に検討すべきである。
Grid と Flex は別概念として記述しなければならない。

Row

定義

Row は、独立要素名ではなく、親レイアウト文脈によって成立する配置上の概念を指す。

ルール

Row は単独の要素種別として定義してはならない。
Row はレイアウトの結果として説明されるべきである。

禁止

Row を正式なElement名として導入すること

Paragraph

定義

Paragraph は、単一段落、または単一のテキストブロックを指す。

ルール

単一の段落テキストは Paragraph と呼ばなければならない。
Paragraph と Rich Text は分けて定義しなければならない。

禁止

単一段落を曖昧に Text とだけ呼ぶこと

Rich Text

定義

Rich Text は、複数のインライン装飾や複数種の子要素を内包しうる編集領域を指す。

ルール

長文編集領域は Rich Text と呼ばなければならない。
Rich Text を提供する場合、子要素への制御手段も設計しなければならない。
Rich Text は単一段落や単純なテキスト挿入と混同してはならない。

禁止

div、p、span、長文編集領域をすべて Text でまとめること
子要素を制御できないまま Rich Text を中核要素にすること

Link

定義

Link は、ナビゲーションのための要素であり、HTML の <a> に対応する。

ルール

<a> を用いる要素は Link と呼ばなければならない。
Link をボタンライクに見せることは許容されるが、それは見た目の問題であり名称を変える理由にはならない。

禁止

<a> を正式名称として Button と呼ぶこと

Button

定義

Button は、ページ内イベントや状態変化を発火する要素であり、HTML の <button> に対応する。

ルール

<button> を用いる要素は Button と呼ばなければならない。
Button の定義は見た目ではなく、意味と挙動で決めなければならない。
<a> をボタンライクに見せることは許容されるが、それは視覚表現の問題であり、Button と命名する理由にはならない。

禁止

ボタンのように見えるという理由だけで Button と呼ぶこと
<a> を既定で Button 扱いすること

補足: Link / Button の境界ケース

<input type="submit">、<input type="button">、<input type="reset"> は、挙動上 Button として扱う。
<a role="button"> は実装上の責務が Button に近づくため Button として扱う。しかし、原則としてこのパターンは避けるべきである。
ARIA role は補助的な意味づけであり、正式名称の第一決定要因としては用いない。

Navigation

定義

Navigation は、サイト内またはアプリ内の移動導線を担うナビゲーション領域を指す。原則として <nav> に対応する。

ルール

サイト導線は Navigation と呼ばなければならない。
必要であれば Primary Navigation、Footer Navigation、Local Navigation のように責務を明示すべきである。

禁止

サイトナビゲーションの正式名称として Menu を使うこと

各項目がユーザーによって実行または選択される操作メニューは Menu と呼ばなければならない。
必要であれば Edit Menu や Command Menu のように責務を明示すべきである。
サイト内移動のための導線は Menu ではなく Navigation と呼ばなければならない。

禁止

サイトナビゲーションの正式名称として Menu を使うこと
ツールバーやコマンド選択UIの正式名称として Nav を使うこと

Template

定義

Template は、ページレベルまたは同等の上位単位に適用される描画定義を指す。

Template は、動的データ、条件分岐、ビルド時データ注入、または差し替え可能なページ構造を伴う場合がある。

ルール

Template は静的断片ではなく、ページ単位またはそれに準ずる上位単位の描画定義として用いなければならない。
Template は Pattern や Component と混同してはならない。

Pattern

定義

Pattern は、静的な再利用可能な視覚的な表示の断片を指す。

ルール

静的な再利用可能な視覚的な表示の断片は Pattern と呼ばなければならない。
Pattern は動的データや条件ロジックを前提としてはならない。
Pattern は Template や Component と混同してはならない。

禁止

静的レイアウト断片を Template と呼ぶこと
単なる複製可能断片を自動的に Component と見なすこと

Component

定義

Component は、単一の定義から管理され、差し替え可能な入力点を持ち、構造・見た目・必要に応じて振る舞いの契約が明示された再利用単位を指す。

ルール

Component は単一ソースから管理されなければならない。
Component は props、slots、content areas、variants など、差し替え可能な入力点を持つべきである。
Component は単なる複製ではなく、定義とインスタンスの関係を持たなければならない。

禁止

見た目だけが共通化されているという理由で Component とすること

Dynamic Element

定義

Dynamic Element は、JavaScript または状態遷移を伴う挙動中心のUI要素を指す。

ルール

Dynamic Element は「動的かどうか」という挙動上の分類軸を表す用語として用いなければならない。
Dynamic Element と Component は排他的な分類ではない。
再利用契約を持つ動的UIは、Dynamic Element であり、かつ Component でもあり得る。

禁止

Dynamic Element と Component を同一分類軸の排他的な選択肢として扱うこと
すべての挙動UIを一律に Component とだけ呼んで済ませること

Theme

定義

Theme は、共有アーキテクチャの上に乗る見た目、トークン、タイポグラフィ、色、余白、事前構成済みレイアウトのまとまりを指す。

ルール

Theme はアーキテクチャと分離して定義しなければならない。
Theme は構造や機能よりも外観と既定値の差分を担うべきである。
Theme の差し替えでアーキテクチャや動的ロジックが壊れてはならない。

禁止

アーキテクチャそのものを Theme と呼ぶこと
テーマ変更が構造破壊を伴うことを前提とすること

非推奨語

以下の語は、正式名称としては原則非推奨とする。

Block

理由: CSS の display: block や論理的な指定と衝突し、一般総称として意味が曖昧すぎるため。

Wrapper

理由: 本規約では構造ラッパーの責務を Inner（内容幅制御）と Outer（外部関連型レイアウト）に分離して定義しており、Wrapper は「何の責務を持つラッパーか」を表さないため。

Text

理由: 単一段落、インラインテキスト、長文編集領域などを区別できないため。

Widget / Module

理由: 責務範囲が曖昧で、設計境界を表さないため。

判定フロー

新しい名称を追加する前に、以下を確認しなければならない。

1. その語はWeb標準で既に意味が定まっているか

定まっている場合、その意味と一致する場合のみ使ってよい。

一致しない場合は別名を定義しなければならない。

2. その名前は見た目に基づいていないか

見た目に基づく場合は再検討しなければならない。

責務、意味、HTML要素、挙動、スコープに基づく名称を優先する。

3. それは静的か動的か

静的であれば Pattern の可能性が高い。

動的であれば Dynamic Element、ページレベルで条件描画を行うなら Template の可能性が高い。

4. 単一ソースで管理されるか

単一ソースで再利用契約を持つなら Component の可能性がある。

そうでないなら Pattern または単なる Element である可能性が高い。

5. ページ全体に適用されるか

ページ単位かつ条件適用されるなら Template を検討する。

そうでないなら Template と呼んではならない。

推奨対応表

用途	推奨語	非推奨語
HTML要素の総称	Element	Block, Module, Widget
セクション境界	Section	Group
CSSのcontainer機能を持つ要素	Container	Generic container, Wrapper
内容幅ラッパー	Inner	Container, Wrapper
外部関連型レイアウト用ラッパー	Outer	Wrapper
外縁保護余白	Gutter	Padding, Column gutter
要素間余白	Gap	Gutter
Multi-columnによる列配置	Columns	Flex Columns, Grid Columns
Flexによる列配置	Flex Columns	Columns
Gridによる構造配置	Grid	Columns, Grid Columns
単一段落	Paragraph	Text
長文編集領域	Rich Text	Text
`<a>`	Link	Button, Link Button
`<button>`	Button	Link Button
サイト導線	Navigation	Menu
操作メニュー	Menu	Nav
静的再利用断片	Pattern	Template
ページ描画定義	Template	Pattern
再利用契約を持つ単位	Component	Static copy
挙動中心UI	Dynamic Element	Component の一括呼称
外観差分	Theme	Architecture

ドキュメント運用ルール

1. すべての正式用語に定義を持たせなければならない

少なくとも以下を記述しなければならない。

何を指すか
何を指さないか
どこで使うか
どこでは使わないか

2. UIラベルと正式名称はできるだけ一致させるべきである

プロダクトUIと実装ドキュメントで名前が異なる場合、教育コストと誤解が増える。

3. 用語の追加・変更は互換性変更として扱うべきである

名称変更は単なる表記揺れ修正ではなく、理解モデルの変更である。

影響範囲を確認せずに変更してはならない。

4. 俗称は正式名称の代わりにしてはならない

俗称を許容する場合でも、正式文書上の標準名称を別に定義しなければならない。

最終指針

この規約の目的は、語感を整えることではない。設計境界を明確にし、責務の混線を防ぐことにある。

したがって、命名に迷った場合は次を優先する。

その名前はHTML/CSSの意味と矛盾していないか
その名前は見た目ではなく責務を表しているか
その名前は静的 / 動的 / 構造 / テーマ / テンプレートを混同していないか
その名前は再利用条件を表しているか
その名前は将来の保守と教育に耐えるか

名前が曖昧であることは、たいてい責務が曖昧であることの兆候である。

本規約では、その曖昧さを用語の段階で排除する。

tak-dcxi/design-system-terminology.md