Shadow DOMの「黒歴史」を終わらせる、`::part`という名の美しきカプセル化の逃げ道
Webコンポーネント、そしてShadow DOM。
あの初めて触ったときの「俺たちのCSS汚染から完全に守られた、神聖なるカプセル化された小宇宙」という感動を、君は覚えているだろうか。グローバルなCSSが意図せずコンポーネントをぶち壊す「CSS Hell」から解放され、我々はついに秩序を手に入れた……はずだった。
しかし、現実はどうだ。
いざ実務のプロダクトでデザインシステムを構築し始めると、この「完全なカプセル化」という名の鉄のカーテンが、途方もない足枷となって我々の牙を剥く。
「おい、このボタンコンポーネントの内部にあるアイコンの色だけ、親のテーマに合わせて変えたいんだけど……」
「カスタムプロパティ（CSS変数）をインジェクションしまくればいいだろ」
「いや、プロパティの数が爆発してCSS変数地獄（CSS Variable Hell）になってるんだが？ しかも動的な計算が必要な複雑なパーツだと、変数のバケツリレーが破綻する」
そう、我々はかつて、Shadow DOMの壁を無理やり突破するために、ドキュメントの奥深くから無理やり変数をねじ込んだり、ひどい時にはコンポーネント内部に `
// === Webコンポーネント（Shadow DOM内部）の実装 ===
class MyCard extends HTMLElement {
constructor() {
super();
this.attachShadow({ mode: 'open' });
this.shadowRoot.innerHTML = `
デフォルトタイトル
`;
}
}
customElements.define('my-card', MyCard);
ここでブラウザの内部（BlinkやGeckoなどのレンダリングエンジン）で何が起きているか。
セレクタの合致判定において、`::part` は「Shadow Treeの境界を透過する特殊なスコープ付きセレクタ」として処理される。
パフォーマンスの観点から言えば、ブラウザはドキュメント全体のCSSツリーと各Shadow Rootのツリーを別々に管理しているが、`::part` が存在する場合、スタイル再計算（Style Recalc）のフェーズにおいて、ホスト要素から指定されたパートへの参照解決が高速に行われるように最適化されている。
ただし、ここで重要な制約がある。`::part` は一段階しか透過しない。
つまり、コンポーネントAのShadow DOMの中に、さらにコンポーネントBがあり、その中の要素をコンポーネントAの外部から直接 `::part` で叩くことはできない（コンポーネントA自身が `part` を中継して露出させる必要がある）。この設計により、コンポーネントの多重構造におけるカプセル化の崩壊を防いでいるのだ。
---
2. メモリ効率とレンダリング負荷：CSS変数地獄からの脱却
かつて、Shadow DOMのスタイリングを柔軟に行おうとすると、以下のようなアプローチが主流だった。
/ 昔やりがちだったCSS変数による制御 /
my-button {
--button-bg: #fff;
--button-text-color: #000;
--button-padding: 8px 16px;
--button-border-radius: 4px;
--button-box-shadow: 0 2px 4px rgba(0,0,0,0.1);
/ これがコンポーネントの数だけ無限に増殖する... /
}
このアプローチの何がクソかというと、CSS変数のインHERIT（継承）とカスタムプロパティマップのメモリ消費、そしてスタイルのカスケード解決における無駄なコストだ。コンポーネント内部のあらゆるプロパティをCSS変数経由でバインドしようとすると、CSSプロパティのマップが肥大化し、わずかな変数の変更でも広範囲な再計算を引き起こす。
一方、`::part` を使ったアプローチはどうか。
/ 現代的な ::part による直接的かつ限定的なスタイリング /
my-button::part(native-button) {
background-color: var(--brand-primary);
border-radius: 0; / 外部から構造的な上書きも可能 /
}
これにより、Shadow DOM内部のCSSは最小限のデフォルト値（フォールバック）だけに集中でき、外部のコンシューマは必要な部分だけをピンポイントでスタイリングできる。
ブラウザのスタイルエンジンにとっても、CSS変数の動的解決ツリーを辿るより、特定の要素の属性（`part`）に基づいたスタイルルール適用の方が、メモリフットプリントが小さく、レンダリングパイプライン（Style -> Layout -> Paint）の効率が良いケースが多い。特に大規模なデザインシステムにおいては、CSS変数のオーバーヘッドを劇的に削減できる。
---
3. 実務で踏み抜く地雷：特異性（Specificity）と非同期の競合
しかし、レジェンドたるもの、綺麗事だけでは語らない。`::part` を実務の現場に導入した瞬間、多くのエンジニアが地雷を踏み抜いて爆死する。その代表例が「特異性（Specificity）」の罠だ。
地雷その1: 内部のCSSとの優先順位バトル
Shadow DOMの内部に定義されたスタイルと、外部の `::part` セレクタは、どちらが強いのか？
答えは、「外部の `::part` セレクタは、Shadow DOM内部の通常の要素セレクタより強いが、内部のIDセレクタやインラインスタイルには負ける」だ。さらに言えば、`::part` 自体の詳細度は、疑似クラスや疑似要素のルールに従う。
/ 外部からの指定 /
my-component::part(button) {
background: green; / .btnには勝つが、#special-btnには勝てない！ /
}
【回避策】
コンポーネント作者は、内部でIDセレクタを `part` 対象の要素に絶対に付与してはならない。また、内部のCSS側で無駄に詳細度（Specificity）を高めるべきではない。`::part` で外部から上書きされることを前提とするパーツには、内部のCSSは極力フラットなクラスセレクタ、あるいはタグセレクタレベル留めておくのが、アーキテクトとしての美学であり、正しい設計だ。
地雷その2: 疑似クラスの制限と動的な非同期競合
`::part` の中で使える疑似要素や疑似クラスには厳しい制限がある。例えば、`::part(foo):hover` のように、パーツ自体の状態（ホバーやフォーカス）を外からフックすることは可能だ。
/ これは動作する /
my-input::part(control):hover {
border-color: rebeccapurple;
}
しかし、親の状態に応じてパーツを変化させたい場合や、Webコンポーネントが非同期でレンダリングされる際のタイ밍問題（FOUC: Flash of Unstyled Content）に直面する。
カスタム要素がまだ `customElements.define` によってアップグレードされていない（hydration前や遅延読み込み時）、あるいは内部のShadow DOMが構築される前に外部のCSSが適用されると、`::part` のスタイルは一時的に「マッチしない不気味な状態」になる。
特にSSR（サーバーサイドレンダリング）やマイクロフロントエンド環境において、非同期ローディングされるコンポーネント群とグローバルCSSの競合は頭痛の種だ。
【回避策】
未定義のカスタム要素に対する `:not(:defined)` 疑似クラスと組み合わせ、ローディング中のレイアウトシフトやスタイルのちらつきを完璧にコントロールせよ。
/ 未定義の間は非表示にするか、スケルトンを表示する /
my-card:not(:defined) {
opacity: 0;
transition: opacity 0.3s ease-in-out;
}
my-card {
opacity: 1;
}
---
4. アーキテクチャの極み：`exportparts` による多重カプセル化の調停
さて、先ほど「`::part` は一段階しか透過しない」と言ったな。
「じゃあ、サードパーティ製のカプセル化されたコンポーネントをラップして、さらに自分のコンポーネントの一部として公開したいときはどうするんだよ？」という絶望的なユースケースが必ず訪れる。
ここで登場するのが、シークレット武器、`exportparts` 属性だ。
これこそが、コンポーネントの多重構造におけるアーキテクチャの救世主である。
/ === 最上位のドキュメント（外部）からのスタイリング === /
outer-component::part(submit-button) {
/ inner-componentの中にある inner-btn を、outer-componentの part="submit-button" として直撃できる！ /
background-color: #ff4500;
}
この `exportparts` の存在により、どれほど複雑なコンポーネントのツリー構造であっても、設計者が意図したパスに沿って、安全かつクリーンにスタイリングの権限を外部へ委譲できるのだ。この仕組みを理解しているか否かで、大規模なデザインシステムの拡張性は天と地ほどの差が出る。
---
結びにかえて
CSSの進化は遅いと言われる。だが、Shadow DOMと `::part`、そして `exportparts` のエコシステムは、Webコンポーネントを「ただのおもちゃ」から「堅牢で拡張性のあるエンタープライズ・アーキテクチャ」へと昇華させた最大の功績だ。
かつての我々は、カプセル化という名の牢獄の中で、CSS変数のパッチワークに溺れていた。
だが、もうその必要はない。`::part` という正統な窓を開け放ち、保守性、パフォーマンス、そして美しさが完璧に調和したコンポーネント設計を、あなたのプロダクトに実装しよう。
コードを書け。そして、美しきカプセル化の境界線を支配せよ。
コメント