デザインシステム×CSS切替で複数商品を一元管理する方法
複数の商品ラインやブランドを抱える企業では、商品ごとにサイトを個別構築した結果、テンプレートが分岐し、改修のたびに調整工数が増えているケースが少なくありません。
とくに保険・金融・製造業のように商品数が多く、コーポレートとしてのブランド統一感も求められる業種では、個別最適と全体最適のバランス設計が課題になります。
本記事では、共通テンプレートにCSSの出し分けを組み合わせ、プルダウンでブランドカラーを切り替える運用設計について解説します。改修コストを抑えながら、複数商品・複数ブランドを1つのCMSで一元管理するための考え方と、責任範囲の切り分け方までを整理します。
目次
複数商品を個別構築する運用で発生する課題
複数商品を扱う企業のWebサイトでは、商品ごとにテンプレートを個別に構築する運用が長年続いてきました。この場合、以下のような課題が段階的に発生します。
- テンプレートが商品数だけ存在し、共通改修でも全ページに手を入れる必要がある
- 商品ごとにHTML構造が微妙に異なり、コンポーネント再利用ができない
- コーポレートサイトのブランドガイドライン改定時に、反映工数が商品数に比例して増える
- 制作会社が商品ごとに異なると、コード品質やアクセシビリティ対応にばらつきが出る
とくにマーケティング部門から見ると、キャンペーンページを追加するたびに新規テンプレートの見積もりが発生し、意思決定のリードタイムが伸びる点が運用負荷になります。UI/UXチームから見れば、デザイン原則の反映が商品ごとに分断されるため、標準化が進みにくくなります。
共通テンプレート＋CSS出し分けの基本設計
この課題に対する現実的なアプローチが、共通テンプレートにCSSの出し分けを組み合わせる設計です。具体的には次の順序で進めます。
- 商品横断で共通化できるレイアウト、コンポーネント、モジュールを洗い出す
- 共通テンプレートを1セット構築し、HTML構造を統一する
- ブランドごとの差分をCSS変数（カスタムプロパティ）に切り出す
- CMSの管理画面上でブランドカラーをプルダウン選択できるようにする
- 選択されたブランドカラーに応じて、body要素にdata属性を付与し、CSS変数を切り替える
この構造にすることで、HTMLとJavaScriptは共通のまま、色・フォント・余白・ロゴ画像パスといったブランド固有の要素だけが差し替わります。デザインシステムでいう「トークン」の考え方を運用フローに落とし込んだ形です。
CSS変数による切り替えの実装イメージ
具体的には、ブランド識別子を付与した要素を起点にCSS変数を定義し、コンポーネント側は変数を参照する構造にします。
body[data-brand="A"] {--color-primary: #0055aa; --color-accent: #ffcc00;}
body[data-brand="B"] {--color-primary: #228833; --color-accent: #ff6699;}
.button-primary {background: var(--color-primary); color: #fff;}CMS側では、記事作成時にプルダウンでブランドカラーを選択するとbody要素のdata-brand属性が切り替わる仕組みにしておきます。これにより、同一テンプレートを使いながらブランドカラーだけが自動的に差し替わるため、テンプレート改修とブランド適用作業を分離できます。
なお、CSS変数は現在の主要なブラウザで広くサポートされています。万一変数が読み込めない場合に備えて、var(--color-primary, #0055aa)のようにフォールバック値を指定しておくと安心です。
責任範囲とデザインシステムオーナーの設計
この仕組みを長期運用するうえで重要になるのが、責任範囲の切り分けです。単に技術構成を整えるだけでは、時間の経過とともに個別カスタマイズが増え、共通テンプレートが崩れていきます。
推奨される責任分界は以下の通りです。
- デザインシステムオーナー（共通テンプレートとトークン管理の責任者）：共通テンプレート、CSS変数の設計、トークン追加の承認
- 商品担当（ブランド運用者）：プルダウンでのブランドカラーの選択と、コンテンツの更新
- システムベンダー：CSS変数の定義・設定、共通テンプレートの改修、新規コンポーネント追加の実装など、ブランドカラーの選択以外のすべての設定
この分界を明確にし、商品担当の操作をブランドカラーの選択に限定することで、商品担当が独自にCSSを追記してテンプレートの一貫性を崩す事態を防げます。CMSの権限設計と組み合わせ、ブランド単位で編集可能な範囲を制限する運用が現実的です。
導入時に検討すべき設計項目
導入にあたっては、次の設計項目を初期段階で決めておく必要があります。決定すべき項目が多いため、優先順位を付けて段階的に進めることを推奨します。
- トークン設計の粒度（色だけか、余白やタイポグラフィまで含めるか）
- ブランド追加時のフロー（誰が承認し、誰が変数を追加するか）
- 例外対応のルール（キャンペーン限定色などをどこまで許容するか）
- ダークモードや多言語対応との組み合わせ方
- 既存サイトからの移行手順とテスト範囲
とくに保険・金融業では、法令表示や免責文言など商品ごとに必須で表示すべき情報が異なります。CSSの出し分けとは別に、表示ルールを共通コンポーネント化しておくことで、法務チェックの工数も抑えられます。
期待できる運用効果
この設計を導入した場合、次のような効果が期待できます。
- 共通改修時の作業がテンプレート1本の修正で完結し、デプロイ後は全ブランドへ一括反映される（反映タイミングはキャッシュ設定やCIパイプラインの構成に依存します）
- レイアウトが共通の範囲では、ブランド追加時の初期構築工数を、CSS変数の定義とロゴ差し替え程度に抑えられる
- デザイントークンとCSS変数の対応関係を運用ルールとして整えておくことで、デザインと実装の乖離を抑えやすくなる（Style DictionaryやFigmaのVariables機能などを併用すると、同期の自動化もしやすくなります）
- ブランドガイドライン改定時の反映リードタイムが短縮される
一方で、テンプレートの共通化には、既存サイトの構造整理と関係部署との合意形成が必要です。着手前に現状のテンプレート数、コンポーネントの重複状況、権限フローを整理しておくことをおすすめします。
よくある質問（FAQ）
Q. すでに商品ごとに個別テンプレートで運用している場合、共通テンプレートへの移行は現実的でしょうか。
一斉移行ではなく、段階的な統合が現実的です。まず共通化可能なコンポーネントの洗い出しを行い、新規ブランド追加や大規模リニューアルのタイミングで共通テンプレートを適用していく手順をおすすめします。既存サイトは優先度と改修頻度を基準に、移行順序を設計します。
Q. CSS変数による切り替えで、ブランド固有のレイアウト要件には対応できますか。
色やタイポグラフィなどのトークンレベルの差分はCSS変数で対応可能ですが、レイアウト構造自体が大きく異なる場合は、コンポーネントのバリアント設計や部分テンプレートの切り出しで対応します。どこまで共通化し、どこから個別対応にするかの線引きが設計上の重要な判断軸になります。
Q. デザインシステムの運用体制は、どの程度の規模から必要になりますか。
実務経験上、3〜5商品を目安に、複数部門が同一CMSを利用し始める段階から、デザインシステムオーナーを置いた運用体制を検討する価値があります。それ以下の規模でも、将来的なブランド追加が見込まれる場合は、初期段階からトークン設計と責任分界を整えておくことで、後の統合工数を抑えられます。
LYZONが提供するWebサービス
Webに関するお悩みは、まずLYZONへ
構築・運用・AIまで、Webに関わる課題をワンストップで対応。まず何ができるかをご覧ください。
2013年入社。2018年9月より、サポートデスクからディレクターに転身。
主に入れ込みをしながら運用案件を担当している。
美容と音楽が好き。
