LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

Web Componentsとは何か — ブラウザ標準のUI部品化技術

Web Componentsとは、再利用可能なカスタム要素をブラウザの標準機能だけで作成できる、複数の技術で構成された仕組みを指します^*1。特定のJavaScriptフレームワークのランタイムに依存せず、ブラウザが直接解釈できる固有タグとしてUI部品を定義できる点が中心的な特徴です。

MDN（Mozilla Developer Network、ブラウザベンダーMozillaが運営するWeb技術の公式リファレンス）は、Web Componentsを「機能をカプセル化し、コードの競合を気にせずWebアプリケーション内で利用できるようにする、複数の技術のスイート」と説明しています^*1。ここでいうスイートとは単一の技術ではなく、Custom Elements・Shadow DOM・HTML Templateという3つの標準APIの組み合わせを意味します。

この標準化を主導しているのはWHATWG（Web Hypertext Application Technology Working Group、主要ブラウザベンダーが参加するHTML標準策定団体）とW3C（World Wide Web Consortium、Web技術標準を策定する国際団体）です。Custom ElementsとShadow DOMはHTML Living Standardの一部としてWHATWGが仕様を管理しており^*2、特定企業の製品仕様ではなくブラウザ横断の標準として定義されています。

なぜ検討するか — フレームワークをまたぐ部品化の動機

Web Componentsの導入が検討される背景には、フロントエンドのフレームワークが数年単位で移り変わるという実務上の課題があります。React・Vue・Angularなどのフレームワークで作られたUI部品は、原則としてそのフレームワークの実行環境に依存します。フレームワークを乗り換えると、UI部品も作り直しが必要になる場合があります。

Web ComponentsはブラウザのCustom Elements APIで定義されるため、フレームワークをまたいで同じ部品を使える可能性があります。React公式ドキュメントも、ダッシュを含むタグ名（例：<my-element>）やis属性を持つ要素をカスタム要素として認識し、Reactアプリの中に直接埋め込めることを説明しています^*3。フレームワークの入れ替えが起きても、標準技術で作られた部品自体は引き続き利用できる可能性がある点が動機の一つです。

もう一つの動機は、複数のアプリケーションやサイトを横断してUI部品を共有する場面です。社内で複数のプロダクトチームが異なるフレームワークを採用している状況では、共通の見た目・挙動を持つ部品をチームごとに作り直すと保守コストが分散します。Web Components向けの軽量ライブラリLitは、公式ドキュメントで「デザインシステムの構築」を主要なユースケースの一つに挙げ、複数のアプリケーションやサイト間で共有できるコンポーネントを作れると説明しています^*4。

Litは同時に「既存のHTMLサイトへの段階的な機能追加（プログレッシブエンハンスメント）」もユースケースとして挙げています^*4。フレームワーク全体を刷新せずに、既存ページの一部だけを部品単位で置き換えたい場合にも選択肢になります。

Custom Elements・Shadow DOM・Templateが担う役割

Web Componentsを構成する3つの技術は、それぞれ異なる役割を担います。役割を切り分けて理解すると、どこまでを標準技術だけで実装し、どこからライブラリに頼るかを判断しやすくなります。

Custom Elements — 独自タグの定義とライフサイクル管理

Custom ElementsはJavaScriptのAPI群で、開発者が定義した振る舞いを持つHTML要素を作成できるようにします^*1。MDNは要素の種類を「Autonomous custom elements（自律型カスタム要素）」と「Customized built-in elements（組み込み要素拡張型）」の2種類に整理しています^*5。前者はHTMLElementを継承してゼロから振る舞いを実装するタイプ、後者はHTMLParagraphElementなど既存の標準要素を継承して機能を拡張するタイプです。なお、組み込み要素拡張型についてはSafariが対応を予定していないとMDNは注記しています^*5。

Custom ElementsにはconnectedCallback（要素がドキュメントに追加された時）・disconnectedCallback（削除された時）・attributeChangedCallback（監視対象の属性が変化した時）といったライフサイクルコールバックが用意されています^*5。これにより、要素の表示・非表示や属性変更に応じた処理を標準APIだけで記述できます。

Shadow DOM — スタイルとDOMのカプセル化

Shadow DOMは、要素にカプセル化された専用のDOMツリー（shadow tree）を取り付けるAPIです^*1。MDNの解説によれば、ページ側のdocument.querySelectorAllはshadow tree内部の要素を検出せず、ページのCSSもshadow tree内部の要素には影響しません^*6。この双方向のカプセル化が、UI部品を外側のページと干渉させずに独立させる仕組みの核になっています。

サーバーサイドレンダリング（SSR）への対応として、Declarative Shadow DOM（宣言的Shadow DOM）という仕組みも標準化されています。<template shadowrootmode="open">という構文でHTML内にshadow rootを宣言でき、ブラウザがHTMLを解析する段階でshadow rootへ変換されます^*6。これにより、JavaScriptの実行を待たずにサーバー側で生成したHTMLだけでshadow DOMを構築できます。

HTML Template — マークアップの再利用

<template>要素は、ページ上には描画されないマークアップの雛形を保持するための要素です^*7。JavaScriptから内容を取得してDOMに複製・追加することで、同じ構造を繰り返し利用できます。<slot>要素と組み合わせることで、部品の呼び出し側から中身を差し込める仕組み（コンポジション）を作れます^*7。名前付きslotを使えば、1つの部品の中に複数の差し込み口を用意することも可能です^*7。

LitなどのHelperライブラリを使う理由

Custom Elements・Shadow DOM・Templateはいずれも低レベルのブラウザAPIであり、状態管理・再描画・スタイル記述を素のJavaScriptだけで組み立てると記述量が増えます。この負担を軽減する目的で作られたのが、Googleが開発を主導するLitなどのヘルパーライブラリです。

Lit公式サイトは自らを「高速で軽量なWeb Componentsを構築するためのシンプルなライブラリ」と説明し、「リアクティブな状態管理・スコープ付きスタイル・宣言的なテンプレートシステムを、小さく高速かつ表現力豊かな形で提供する」ことを特徴として挙げています^*4。重要な点として、Lit公式は「すべてのLitコンポーネントは標準的なWeb Componentsである」と明記しています^*4。つまりLitは専用の実行環境を作るのではなく、標準APIの記述を助けるレイヤーという位置づけです。

Lit公式はこの設計方針について、特定環境への依存度を抑えつつ利用の自由度を高める狙いがあると説明しています^*4。特定のライブラリのバージョンに縛られる度合いを抑えつつ、標準APIだけで書く場合より少ないコード量で部品を実装できる点が採用理由になります。ライブラリを使うか素のCustom Elementsで書くかは、部品の複雑さと開発チームの習熟度に応じた選択になります。

導入前に詰めるべき3つの論点

Web Componentsは標準技術である一方、既存の開発体制にそのまま組み込めるとは限りません。導入前に詰めておくべき論点を3つに整理します。

論点1：フォーム連携とアクセシビリティの実装コスト

Shadow DOMでカプセル化した独自仕様のフォーム部品は、ブラウザ標準の<input>のようにそのままフォーム送信に参加しません。MDNはカスタムフォームコントロールの構築を「高度なトピック」と位置づけ、実装にあたって「すべての利用者がアクセス可能であることを確認する」重要性に言及しています^*8。Custom Elements APIにはattachInternalsによって要素をフォームに関連付ける仕組みが用意されていますが^*5、ARIA属性の付与やキーボード操作対応は個別に設計する必要があり、標準の<input>や<button>を使う場合より実装コストがかかります。

論点2：既存フレームワークとの相互運用性

Custom Elementsとフレームワークの間では、値をプロパティとして渡すか属性として渡すかという扱いの違いが生じます。React公式ドキュメントは、Reactがカスタム要素に対してデフォルトでは値を属性として渡すこと、配列などの非文字列値はシリアライズされて渡されることを説明しています^*3。一方で、カスタム要素のコンストラクタで対象のプロパティ名が事前に定義されている場合は、Reactはそのプロパティに任意のJavaScript値をそのまま渡せると明記しています^*3。フレームワーク横断のテストプロジェクトCustom Elements Everywhereも、プロパティと属性のどちらを優先するかはフレームワークごとに実装方針が異なると整理しています^*9。相互運用性は無条件に成立すると断定できるものではなく、部品側の設計とフレームワーク側の挙動を事前にすり合わせる作業が発生します。

論点3：過剰適用しない範囲の見極め

Web Componentsはページ全体のアプリケーション状態管理やルーティングを担う仕組みではありません。Lit公式が挙げるユースケースも、デザインシステムの共通部品や既存ページへの段階的な機能追加といった、部品単位の適用が中心です^*4。アプリケーション全体をWeb Componentsだけで構築するのではなく、フレームワークをまたいで再利用したい部品や、マイクロフロントエンド（複数チームが個別に開発した画面断片を1つの画面に統合する構成）の共通部品といった、標準化の恩恵が大きい範囲に適用範囲を絞ることが検討の出発点になります。

外注する場合の委託範囲と発注準備

Web Components導入を外注する場合、委託範囲を事前に線引きしておくことが手戻りを防ぎます。委託先に丸ごと任せる前提ではなく、発注側が判断すべき論点を残したまま依頼すると、成果物と社内の開発体制がかみ合わなくなるリスクがあります。

Custom Elementsの内部状態設計やShadow DOMの境界の引き方を誤ると、既存ページのCSSと部品側のスタイルが想定外に衝突し、公開後の修正に手戻りが生じる可能性があります^*10。委託先には、部品の内部実装だけでなく、既存システムとの結合テスト設計まで含めて依頼範囲を明示することが望まれます。

必要なスキルの面では、ブラウザ標準APIの知識に加えて、対象フレームワークの内部挙動の理解、アクセシビリティ設計の知識が必要になります。これらを1〜2名のみで内製しようとすると、標準API・フレームワーク結合・アクセシビリティの3領域を同時に担う負荷が集中し、レビュー体制が手薄になりやすい点に留意が必要です。専門の開発パートナーに委託する場合は、部品の設計・実装だけでなく、社内エンジニアへの引き継ぎドキュメント作成まで含めて依頼すると、外注後の内製移行がしやすくなります。

まとめ：Web Components導入を進める3つの判断軸

本稿ではWeb Components導入の考え方を、MDN・WHATWG・Lit公式の一次資料に基づいて整理しました。要点を3つに集約すると次の通りです。第一に、Web ComponentsはCustom Elements・Shadow DOM・HTML Templateという3つの標準技術の組み合わせであり、フレームワークに依存せず動く部品を作れる点が導入動機になります。第二に、Shadow DOMのカプセル化はUI部品の独立性を支える一方、フォーム連携・アクセシビリティ・SSR対応には個別の設計が必要です。第三に、フレームワークとの相互運用は年々改善されているものの、プロパティと属性の扱いの違いなど事前確認が必要な論点が残ります。

外注を検討する際は、標準技術だけで作る範囲とライブラリに任せる範囲、既存フレームワークとの接続方法、アクセシビリティ対応の担当範囲を発注前に明確にすることが、導入後の手戻りを抑える判断軸になります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：MDN Web Docs「Web Components」（Mozilla、最終更新2026年）https://developer.mozilla.org/en-US/docs/Web/API/Web_components
2. *2　出典：WHATWG「HTML Living Standard」（WHATWG）https://html.spec.whatwg.org/multipage/custom-elements.html
3. *3　出典：React「Common components (e.g. <div>) – Custom HTML elements」（React公式ドキュメント）https://react.dev/reference/react-dom/components
4. *4　出典：Lit「Lit documentation」（Lit公式サイト）https://lit.dev/docs/
5. *5　出典：MDN Web Docs「Using custom elements」（Mozilla）https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_custom_elements
6. *6　出典：MDN Web Docs「Using shadow DOM」（Mozilla）https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_shadow_DOM
7. *7　出典：MDN Web Docs「Using templates and slots」（Mozilla）https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_templates_and_slots
8. *8　出典：web.dev「More capable form controls」（Google）https://web.dev/articles/more-capable-form-controls
9. *9　出典：Custom Elements Everywhere「Framework interoperability tests」https://custom-elements-everywhere.com/
10. *10　出典：MDN Web Docs「Using shadow DOM」のCSSカプセル化に関する記述に基づく整理（Mozilla）https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_shadow_DOM

Tweet