Hugo移行後のデザイン調整地獄｜CSS1400行・Figma導入・スマホ対応の全記録
前回の記事では、WordPressからHugoへの移行を2日で完了させた話を書いた。
90記事のMarkdown変換、画像ダウンロード、URL一致確認、GitHub Pagesへのデプロイ。技術的な移行作業は確かに2日で終わった。
だが、本当の地獄はここからだった。
テーマのCSSカスタマイズが終わらない
Hugoのテーマ「Mainroad」を選んだ。シンプルで2カラム対応、ブログ向きの構成。だがデフォルトのデザインは正直そっけない。WordPress時代に使っていたCocoonの見た目に慣れていた自分にとって、「なんか違う」の連続だった。
色を変える。余白を調整する。カードのデザインを変える。ヘッダーを全幅にする。フッターにリンクを並べる。1つ直すと別の場所が気になる。custom.cssに1行追加するたびに、「あ、ここも直さなきゃ」が発生する。
最終的にcustom.cssは1400行を超えた。
テーマのclearfixが-webkit-line-clampを殺す
一番ハマったのがこれ。リンクカードの説明文を3行で切って三点リーダー（…）を表示したかった。CSSの-webkit-line-clampを使えば簡単なはず。
ところが何をやっても効かない。!importantをつけても、セレクタの詳細度を上げても、インラインスタイルで直接指定しても。DevToolsで確認するとdisplay: -webkit-boxを指定しているのに、Computed Styleではflow-rootになっている。
原因を探るのに丸1日かかった。結論から言うと、Chromeが-webkit-boxを内部的にflow-rootとして報告しているだけで、実は動いていた。
DevToolsのConsoleで新しいdiv要素を作ってdisplay: -webkit-boxを設定し、getComputedStyleで確認してもflow-rootが返ってくる。clearfixとは無関係だった。
つまり「動いてないと思い込んで別の方法（max-height）に変えた」のが間違いで、最初から動いていた。CSSデバッグの教訓：推測でCSSを書くと沼る。DevToolsで実測値を見てからピンポイントで直す。
テーマを使う意味とは何か
custom.cssが1400行。テンプレートの上書きファイルも10個以上。ここまでカスタマイズすると「テーマ使ってる意味ある？」という疑問が湧く。
結論としては、まだある。テーマが担ってくれている部分:
- カテゴリ・タグ一覧ページの生成
- ページネーション
- ハンバーガーメニューのJS
- OGP・meta周りのテンプレート
- レスポンシブの基本設計
- CSSのベーススタイル（フォント、テーブル、コードブロック等）
これを全部自分で書くとなると相当な量になる。テーマの価値は「HTML構造とJSの土台を自分で書かなくていい」こと。見た目はCSSでいくらでも変えられる。
Figma導入で「なんとなくCSS調整」から脱却
CSSが終わらない根本原因に気づいた。デザインのゴールがないのだ。
「なんか違う」→「ここを直そう」→「あ、こっちも気になる」の無限ループ。ゴールがないからいつまでも終わらない。
そこでFigmaを導入した。PC・タブレット・スマホの3ブレイクポイントで完成形のデザインを先に作る。コンポーネント化してバリアント（device=PC/Mobile）で管理する。テキストスタイルでフォントサイズを一元管理する。
Figmaで決めてからCSSに落とす。この流れに変えたら、CSSの調整が驚くほど速くなった。「この要素は何px？」が明確だから迷わない。
FigmaもClaude Codeに作らせた
「わざわざブログのデザインにFigmaを使うのか」と思われそうだが、自分でFigmaをポチポチ操作したわけではない。
FigmaのMCPが編集に対応したので、Claude Codeに元サイトのURLを渡して「このデザインをFigmaに起こして」と指示した。各レスポンシブのページデザインが自動で生成される。そこからプロンプトで「ここの余白を24pxに」「この文字を15pxに」と微調整を繰り返した。
コンポーネント化、バリアント作成、テキストスタイル登録もClaude Code経由。Figmaの操作を覚える必要がなかった。
Figmaの達人でも何でもない。Claude Codeが達人なだけだ。
Figmaデザインファイルを公開します
今回作ったFigmaのデザインファイルを公開する。Hugo + Mainroadテーマのカスタマイズを考えている人の参考になれば。
スマホ表示の改善が一番効果があった
デザイン調整の中で、最もインパクトが大きかったのがスマホ表示の改善だ。
横並びカード → 縦型カードで劇的に見やすく
最初のスマホ表示は、PCと同じ横並びカード（アイキャッチ左・テキスト右）を縮小しただけだった。85×48pxの小さいサムネイルに、11pxの文字。読めなくはないが、何の記事かパッと見でわかりにくい。
Figmaでスマホ専用の縦型カードをデザインした。アイキャッチ画像が上部に大きく表示され、その下にタイトル。これだけで印象が全然違う。
文字サイズ13px → 15pxで読みやすさが激変
最初はFigmaのデザインに忠実に13pxにしていた。だが実機で見ると小さすぎる。h2が16px、h3が14pxだと本文との差がほとんどない。
最終的にh3と本文を同じ15pxにした。見出しは装飾（背景色や左ボーダー）で十分区別できるので、サイズで差をつける必要がなかった。たった2pxの違いだが、スマホでの読みやすさが劇的に変わった。
ハンバーガーメニューをヘッダー画像にオーバーレイ
最初はカテゴリメニューをスマホでもそのまま折り返し表示していた。5カテゴリ程度なら収まるが、ヘッダーの下に別のバーとして領域を取るのがスマートじゃない。
Figmaでデザインした通り、ハンバーガーメニューをヘッダー画像の右上にオーバーレイ配置した。HTMLの構造上、メニューはヘッダー画像の外にあったので、header-wrapperで包んでposition: absoluteで重ねる形にした。
前後ナビをスマホでは非表示に
「前の投稿」「次の投稿」のナビゲーション。一般的にクリック率は1-3%と言われている。PCなら記事の最下部にあっても邪魔にならないが、スマホだとサイドバーの前に挟まって導線が切れる。関連記事があれば十分なので、タブレット・スマホでは非表示にした。
ロゴ画像をテキスト+SVGフィルターに置き換えた
ヘッダーのブログ名は、以前はネットのロゴ作成サイトで作った画像を使っていた。だが画像だとサイズ変更のたびに作り直しが必要で、レスポンシブ対応が面倒。
テキスト+CSSで再現できないか試した。
CSSのtext-shadowでは角がきれいに縁取りできない
最初はtext-shadowで4方向に影を重ねて縁取りを再現しようとした。だが文字の角や曲線部分に隙間ができる。-webkit-text-strokeは文字の内側にも線が入るので白が痩せる。
SVG feMorphologyで完璧な縁取りを実現
最終的にSVGフィルターのfeMorphologyを使った。文字の輪郭を膨張させて、そこに半透明の黒を塗り、元のテキストの上に重ねる方式。
<svg style="position:absolute;width:0;height:0;">
<filter id="text-outline">
<feMorphology operator="dilate" radius="1.5" in="SourceAlpha" result="expanded"/>
<feFlood flood-color="rgba(0,0,0,0.5)"/>
<feComposite in2="expanded" operator="in" result="outline"/>
<feMerge>
<feMergeNode in="outline"/>
<feMergeNode in="SourceGraphic"/>
</feMerge>
</filter>
</svg>
HTMLに<svg>タグを1つ追加するだけ。CSSでfilter: url(#text-outline)を指定すれば完了。文字の角もきれいに縁取りされる。
Cloudflareに全画像を移行してリポジトリを軽量化
記事の画像274ファイル（50MB）をGitリポジトリに入れていたが、cloneするたびに全部ダウンロードされるのは効率が悪い。
Cloudflare R2（S3互換のオブジェクトストレージ）に全画像を移行した。カスタムドメインimg.morisakiblog.comで配信。無料枠（10GB/月、100万リクエスト）で個人ブログなら十分。
移行後にBFG Repo-Cleanerでgit履歴からも画像を完全削除。リポジトリサイズが7.4MBまで軽量化された。
Claude Codeがいなかったら無理だった
正直に言う。このデザイン調整作業、Claude Codeなしでは絶対に終わらなかった。
やっていたことの9割は:
- 「ここの余白が気になる」と伝える
- Claude CodeがCSSを修正する
- ブラウザで確認する
- 「もうちょい大きく」と伝える
- 即修正される
このループが1日に何十回と回る。人間が1つずつCSSを書いて、ファイルを保存して、ブラウザをリロードして…とやっていたら1週間かかる作業が数時間で終わる。
さらにDevToolsでの調査（CSSの競合原因の特定）、Figma MCPでのコンポーネント更新、git操作、bot名義でのPR作成まで全部やってくれる。
**テーマのclearfix問題も、Claude Codeと一緒にDevToolsでデバッグしたから原因を特定できた。**一人だったら「よくわからんけどmax-heightで回避しよう」で終わっていた。
まとめ
Hugo移行は2日で終わるが、デザイン調整は2週間かかった。
振り返って学んだこと:
- Figmaでデザインを先に決める。ゴールがないとCSSは永遠に終わらない
- DevToolsで実測値を確認してからCSSを書く。推測で書くと沼る
- スマホ表示を優先的に改善する。PVの半分以上はスマホから来る
- 80%でリリースして改善する。完璧を目指すとCSS沼にハマる
- テーマは「土台」として使う。見た目は全部CSSで変えられる
