こんにちは、KIYONOエンジニアインターンの一人です。
みなさん一度は自分のブランドを持ちたいなぁと思ったことがあるかもしれません。ですが、ブランド独自の世界観を維持し続けるのは容易ではありません。メンバーが増えたり横展開していくと元々の思想から離れていってしまうこともあるでしょう。だからこそ、運用の現場では迷わない「共通言語」としてのブランドガイドラインを策定します。
と言うことで今回はWeb サイトの CMS 構築に向けて、ブランドガイドラインを作成したプロセスを紹介します。この記事では、実際に行った技術的ポイント(スクレイピング、スクロール処理(Lazy Load 対策)、Google Colab を活用した Selenium 実行環境構築、フォント / カラーの自動抽出)について、再現可能なコードとともに分かりやすくまとめています。
📘 CMS 構築とは?
CMS(Contents Management System)は、Web サイトのコンテンツをノーコードで更新できる管理基盤です。代表例で言うとこのTechBlogで使われているWordpressです。
- ページ追加・修正が誰でもできる
- 運用が効率化される
- コンテンツが増えやすくなる
一方で、CMS を導入すると複数の担当者が編集に関わるようになるため、デザインが崩れやすくなるという課題もあります。そこで重要になるのが、統一基準(ブランドガイドライン)の整備です。
🎨 ブランドガイドラインとは?
ブランドガイドラインは、Web サイトのデザインを統一するための「基準書」です。有名なガイドラインで言うとhuluやgoogle などがあります。
Hulu のブランドガイドライン
Hulu は「Hulu Green(#1CE783)」を中心に、タイポグラフィは Graphik、CTA ルールや Vessel(角丸枠)など体系的に定義されています。
公式ガイドはこちら:
Google のブランドシステム
Google は Logotype, Google G, Dots からなる要素体系と、プロダクト全体での一貫性を重視した運用ガイドを公開しています。
公式ドキュメントはこちら:
代表的な項目は以下の通りです。
- 見出し・本文で使用するフォント
- メインカラー、アクセントカラー、背景色
- ボタンやリンクのスタイル
- 余白、行間、レイアウトルール
- 画像・イラストのトーン
今回の目的は、これらを実際のサイトから自動抽出し、CMS 運用時にも統一しやすい環境を整えることでした。
🔍 使用した技術
今回利用した技術スタックはこちらです。
■ スクレイピング
Web ページの HTML・CSS 情報を自動で取得して解析する技術です。デザイン要素の調査に有効です。
■ スクロール処理(Lazy Load 対策)
現代の Web サイトは、スクロールしないと読み込まれない要素が多いため、自動スクロールでページ最下部まで動かし、全要素を取得可能な状態にする処理を導入しています。
■ Selenium(ヘッドレスブラウザ操作)
- レンダリング後の CSS を取得できる
- JS 実行が可能
- Lazy Load / SPA でも対応できる
■ Google Colab
Google Colabはブラウザだけで実行環境を用意できるため、メンバー間で同じノートブックを共有して“同じ条件”で再現できます。GPU/CPUリソースや依存パッケージが都度リセットされる特性を踏まえ、環境構築セルを先頭に置くことで失敗を最小化できます。さらに、ランタイムの再接続やタイムアウト時もセル単位で再実行できるため、スクレイピングやヘッドレス検証の長時間処理を安全にやり直せます。
🧪 実際に使用したコード
▼ ① 環境構築(Chrome + Selenium / Google Colab)
Chrome と Selenium を安定して動かすための最小構成です。
# セル1:環境準備(Google Colab)
!apt-get update
!wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add -
!echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google-chrome.list
!apt-get update
!apt-get install -y google-chrome-stable
!pip install selenium requests beautifulsoup4 cssutils lxml webdriver-manager
▼ ② Selenium の設定(ヘッドレスモード)
解析対象は「レンダリング後のスタイル」を扱うため、実ブラウザ相当の ヘッドレスChrome を起動します。
from selenium import webdriver
from selenium.webdriver.chrome.options import Options
from selenium.webdriver.chrome.service import Service
from webdriver_manager.chrome import ChromeDriverManager
def get_chrome_driver():
options = Options()
# Chrome >= 109 の headless new モード
options.add_argument("--headless=new")
options.add_argument("--no-sandbox")
options.add_argument("--disable-dev-shm-usage")
options.add_argument("--window-size=1920,1080")
service = Service(ChromeDriverManager().install())
driver = webdriver.Chrome(service=service, options=options)
return driver
▼ ③ フォント・カラー抽出ロジック(JS + Python)
DOM 全体の要素を走査し、以下を用途別に分類して取得します。
- フォント(見出し / 本文 / ボタン / リンク)
- テキストカラー
- 背景カラー
抽出された情報はサマリ化し、後で CSV として出力します。
import time
import csv
import json
from urllib.parse import urlparse
from selenium.webdriver.common.by import By
from selenium.webdriver.common.keys import Keys
# サイトを完全レンダリングさせるための自動スクロール
def auto_scroll_to_bottom(driver, pause=0.5, max_tries=30):
last_height = driver.execute_script("return document.body.scrollHeight")
tries = 0
while tries < max_tries:
driver.execute_script("window.scrollTo(0, document.body.scrollHeight);")
time.sleep(pause)
new_height = driver.execute_script("return document.body.scrollHeight")
if new_height == last_height:
break
last_height = new_height
tries += 1
・・・・
▼ ④ 結果を CSV として保存
# 上記の write_font_csv / write_color_csv が生成
# - font_usage.csv
# - color_usage.csv
# 2 つのファイルがブランドガイドライン作成のベースデータになります。
____________________________________________________________________________________
実際使用したコード
code1
📊 実際に得られた成果
- サイトでよく使われているフォントの傾向が可視化された
- メインカラー・アクセントカラーの実態を正確に把握できた
- ページごとのデザインのばらつきが検知できた
- ガイドライン化すべき箇所が明確になった
手作業では気づきにくい差異も、自動化することで客観的に把握できます
__________________________________________
得られた成果を元に作成したカラーガイド
得られた結果を元に作成したブランドガイドライン(カラー)


✨ まとめ
- CMS 化ではデザインの一貫性が特に重要
- 既存サイトのデザイン要素を自動抽出することで、ブランドガイドラインの根拠をデータとして示せる
- Selenium + Colab で効率的に解析が可能
- 分析結果を CSV 化し、ガイドライン作成フローを標準化できた
ブランドガイドラインは「おしゃれのため」ではなく、CMS 運用を安定させるための“土台づくり”だと再認識したプロジェクトでした。次回はCMS構築について書きます。


コメント