CSSの本当の問題が、グローバルだという点ではなく、UIユニットとは何かを実は定義したことがないという点だとしたら？
この感覚、経験したことがありませんか。あるスクリーンのパディングを調整すると、10ファイル離れたボタンがおかしく見える。同じHTMLが異なるコンテキストで異なるレンダリングをされる。どのルールが画面上の何に責任があるのか、もはや判別できない。念のため別のセレクタを追加する。さらに別のセレクタを追加する。やがてスタイルシートは考古学の発掘現場となり、コンポーネントは委員会による設計のような見た目になる。
ほとんどのチームはこれをCSSのせいにする。それは間違っている。
本当の問題はCSS ではなく構造
実際に起こっているのはこういうことだ：HTMLはある場所にあり、CSSは別の場所にあり、DOM動作はさらに別の場所にある。各パーツは独立していれば問題ないように見える。しかし、それらは同じビジュアルユニットを説明しながら、同じ場所にいることがない。
そのギャップの中に、ズレは潜む。
HTML単体では、要素がどのように振る舞うかは教えてくれない。CSSは、その要素がどの構造ユニットに属しているかを教えてくれない。DOM コードは同じ領域を変更するが、スタイルのコンテキストも元の意図も持ち込まない。同じ従業員について3つの異なるチームが働きながら、異なる言語を話し、同期していない状態だ。
「問題は、それらの責任を一緒に持つ明確なUIユニットがなかったことでした。そのユニットがなければ、小さな修正がファイル間のギャップに蓄積されます。」
小さな修正は確実に蓄積される。セレクタが調整される。ルールが追加される。DOMパッチが現れる。各々は局所的には正当だ。しかし画面全体としては理解不能になる。
Razor Pagesを使用していたあるデベロッパーが気付いたことがある。.cshtmlと.cshtml.cssのペアリングは関係性を強制した──CSSはそのページ内に自動的にスコープされる。影響の半径はデフォルトで小さい。他のファイルの奥深い3層にあるものを壊してしまったかもと常に疑わることなく、スタイルを実装できる。
完璧ではなかった。しかし、あることが明白になった：関連する責任が属するユニットに付着していると、他のどこにも漏れなくなる。
実際のUIユニットは何を所有するのか？
この気付きが別の問いを生み出した：Razor Pagesが示したように、HTMLとCSSがフロントエンドコードの意味のある境界に付着していたら、どうだろうか？
ぼんやりしたレイヤー──ここにマークアップ、そこにスタイル、動作は宙を浮く──で考える代わりに、要素所有権で考え始める。1つの境界が1つの構造ルート、1つのローカルスタイルコンテキスト、DOM動作が存在する1つの場所を所有する。その境界が構造とスタイルと動作が出会える唯一の場所になるため、変更は漏れなくなる。
これはすべてをコンポーネントフレームワークに変えることではない。独自の構造を所有できるほど小さなユニットを持つことだ。
ElementBoundaryと呼ぶシンプルなものを想像してみよう：
const profileCard = new ElementBoundary(
/* html */ `
<section>
<h2 class="title">Profile</h2>
<p class="value">Active</p>
</section>
`,
/* css */ `
[root] {
padding: 12px;
border: 1px solid #d0d7de;
}
[root] .title {
font-size: 14px;
margin: 0 0 8px;
}
`
);
const screen = ElementBoundary.first("#screen");
screen.append(profileCard);
コンストラクタは重要ではない。重要なのは、1つの要素ユニットがそのHTMLとCSSの両方を所有しているという点だ。スクリーンコンテナは同じ境界モデルを通じて扱われ、生のDOM アクセスに戻ることはない。[root]プレースホルダは自動的に境界固有のセレクタに書き直されるため、CSSはそのユニット内にのみ適用される。
これはShadow DOM ではない。Shadow DOMは通常のDOM フローから外す。これはフローの中に留まりながら、UI が成長するにつれてスケールする狭いスタイル境界を与える。作成、検索、配置はすべてDOM操作に散らばる無関係な操作ではなく、同じモデルに従う。
なぜこれが実際にズレ問題を解決するのか
このように考え始めると、3つのことが変わる。
CSSは、グローバルレイヤーとして扱われるのではなく、要素ルートに紐付いているため、ローカルになる。DOM動作はページ全体を浮遊する代わりに特定のユニットに属するため、配置が簡単になる。UI自体は、既存の領域も新しく作成された領域も同じ構造的意味に従うため、首尾一貫した考え方ができる。
「どのセレクタが責任があるのか」と問う代わりに、「どの境界がこれを所有しているか」と問い始める。これは全く異なる会話だ。
HTMLが説明していることとCSSがしていることとDOM コードがしていることの間のギャップ──そのギャップは消える。フレームワークを使ったからではなく、ユニットが何かを定義したから。
これが重要なのは、スケーリングするフロントエンドがCSS構文のために失敗するのではなく、チームが責任の始まりと終わりについて合意したことがないために失敗するから。明確な境界を定義すると、その曖昧さは死ぬ。恐れることなく物事を変更できる。技術的負債を生まずに機能を追加できる。新しいデベロッパーをオンボードする際に、スタイリング戦略全体をリバースエンジニアリングする必要がない。
革新的ではない。構造的だ。
🧬 関連インサイト
- 詳細はこちら： Higress Joins CNCF as Alibaba’s AI Gateway Bet—And Nginx Has Until 2026 to Worry
- 詳細はこちら： Claude Code’s Token Collapse: When AI Pricing Models Break Developer Workflows
よくある質問
DOM境界はReactなどのコンポーネントフレームワークに取って代わるのか？ いいえ。これはあなたが使うどのフレームワークの中での構造化についてです。Reactコンポーネントもこのパターンを採用できます。プレーンな JavaScript でも可能です。境界は責任についてのもので、ツールについてではありません。
既存のCSSで機能するのか？ はい、セレクタを境界スコープを尊重するようにリファクタリングできれば。新しいプロジェクトはすぐに採用します。レガシーコードには若干の書き換えが必要ですが、1度に1つのユニットにスコープされます。
これはCSS Modulesと同じか？ 目標は似ていますが、アプローチは異なります。CSS Modulesは命名規則とツールを使用します。境界は構造ユニットを JavaScript で明示的にし、HTML、CSS、動作を技術的にだけでなく概念的に結びつけます。
