blogのデザインを変えた話―見た目より、壊れにくさを先に考えました

最近、このblogのデザインを変更しました。

きっかけは、ページ上部のメニューです。「プライバシーポリシー」のような長い文字が途中で折り返され、ヘッダーだけ2行になっていました。

それほど致命的な問題ではありません。でも、一度気になると、ずっと気になります。

そこで生成AIにデザイン案を作ってもらい、最終的に Editorial Air という、白を基調にしたデザインへ変更しました。

デザインをかっこよくする話のはずが、最終的には「メニューを減らし、壊れにくくした」という地味な話になりました。

せっかくなので、どういう条件で考え、何をやめ、なぜこの形を選んだのかを記録します。

最初はCSSで改行を止めればよいと思った #

文字の折り返しだけなら、CSSに次の指定を加えれば止められます。

white-space: nowrap;

簡単です。

ただし、当時のヘッダーには、サイト名のほかに8項目と検索ボタンがありました。

ホーム
記事
カテゴリ
タグ
About
お問い合わせ
プライバシーポリシー
運営者情報
検索

これを全部1行に固定すると、今度は狭い画面から横にはみ出します。

つまり、改行を禁止しただけでは直っていません。見え方を変えて、問題を隠しただけです。

えっ。

CSSを1行足して終わる予定だったのですが、ヘッダーの設計から考え直すことになりました。

今回の条件 #

見た目だけで選ぶと、数か月後にまた直すことになりそうだったので、先に条件を決めました。

私が重視した順番は、だいたい下記です。

文字が途中で改行されない
スマートフォンでも横にはみ出さない
記事を読む邪魔をしない
HugoやCongoを更新しても壊れにくい
外部のフォント、UIライブラリ、JavaScriptを増やさない
AdSenseの審査、運用に必要なページを見失わせない
今後、生成AIへ修正を頼みやすい
その上で、少しかっこいい

かっこよさが8番目になっています。

でも個人blogの場合、凝った演出が1つあることより、5年後も普通に記事を読める方が重要だと思いました。

3つのデザインを作った #

いきなり本番を変更せず、生成AIで3つの操作可能なサンプルを作りました。

Editorial Air #

白い背景、青い細線、広めの余白を使った案です。

記事は画像なしの1列表示で、タイトル、日付、カテゴリ、短い説明だけを並べます。今回採用したのがこの案です。

Index Journal #

サイト名と検索を1段目、メニューを2段目へ分けた案です。

情報量が増えても崩れにくく、技術誌の索引のような雰囲気になりました。これはこれでよかったのですが、少し「きちんとした媒体」感が強すぎました。

私のblogは、調べたことを個人的に残す実用メモに近いので、少し立派すぎます。

Soft Grid #

記事を2列のカードで並べる案です。

3案の中では一番華やかでした。しかし、記事ごとの文字量が違うとカードの高さが不揃いになります。画像を使い始めると、さらに画像選びとトリミング作業が増えます。

見た目はよい。

でも、記事を書くたびにデザインの面倒を見るのは、かなり面倒です。

Editorial Airを選んだ理由 #

Editorial Airは、3案の中で一番地味でした。

逆に言うと、一番壊れにくい案でもありました。

1列の記事一覧なら、タイトルが長くても下方向へ伸びるだけです。画像の有無にも左右されません。新しい記事を増やしても、レイアウトの例外がほとんど発生しません。

さらに、HTMLとCSSの関係が単純です。

ヘッダー
  ├─ サイト名
  ├─ 主要メニュー
  └─ 検索

トップページ
  ├─ 説明
  └─ 1列の記事一覧

フッター
  └─ 運営関連ページ

入れ子が少なく、状態変化も少ないので、人間が見ても分かりやすく、生成AIへ修正を頼む場合にも都合がよいです。

生成AIは、一般的なHTMLとCSSを書くのはかなり得意です。一方で、複数のJavaScript、独自UI部品、例外的な画面幅が絡むと、修正した場所とは別の場所を壊すことがあります。

なので、「AIに高性能なものを作らせる」より、「AIが間違えにくい構造にする」方を選びました。

メニューは8項目から4項目へ #

デスクトップの上部へ常時表示するのは、次の4項目と検索だけにしました。

ホーム
記事
カテゴリ
タグ
検索

About、お問い合わせ、プライバシーポリシー、運営者情報は、削除せず全ページ共通のフッターへ移しました。

ここはAdSenseへの影響が少し心配でした。

Googleの説明では、ナビゲーションを分かりやすくし、リンクをクリックして必要な情報へ移動できることが求められています。また、Google パブリッシャー向けポリシーでは、Googleのサービス利用に伴うデータ収集などを説明するプライバシーポリシーが必要です。

一方、「プライバシーポリシーを必ずヘッダーへ置く」という指定は見つけられませんでした。

そこで、ページ自体は残し、どのページからも到達できるフッターへ移しました。主要な記事導線と運営情報を分けた方が、むしろナビゲーションは分かりやすいと判断しました。

これは2026年8月時点で確認した内容です。AdSenseのポリシーは変更される可能性があるので、審査時には再確認した方がよいと思います。

スマートフォンのメニューにJavaScriptを使わなかった #

スマートフォンでは、主要メニューを「メニュー」ボタンの中へ入れています。

ここで独自のJavaScriptは作らず、HTML標準の details と summary を使いました。

<details>
  <summary>メニュー</summary>
  <nav>...</nav>
</details>

理由は単純で、JavaScriptが動かなかった場合でもメニューを開けるからです。

高度なアニメーションはありません。でも、キーボードで操作でき、ブラウザの標準機能として開閉します。今回の用途なら、これで十分です。

検索だけはCongoに元からある機能を再利用しました。似た機能を新しく作ると、検索インデックスやキーボード操作を二重に保守することになるためです。

テーマ本体を編集しない #

このblogは、HugoとCongoテーマを使っています。

テーマ内のファイルを直接変更すると、将来Congoを更新したときに差分が衝突します。最初は動いても、更新時に何を残すべきか分からなくなる可能性があります。

そこで変更は、サイト側の次の部分だけに入れました。

メニュー設定
表示設定
サイト側のヘッダー部品
サイト側のトップページ部品
追加CSS

Congo本体には触れていません。

テーマが用意した検索や記事ページはそのまま使い、必要な場所だけ上書きしています。

全部を独自実装する方が自由度は高いです。ただし、自由度と保守の手間は、だいたい一緒に増えます。

今回はそこまで自由になりたくありませんでした。

ライト表示へ固定した #

以前はダーク表示を初期設定にしていました。

新しいデザインでは白い余白と細い青線を基準にしたため、ライト表示へ固定しました。過去にダーク表示を選んだ記録がブラウザに残っている場合も、ライトへ戻すようにしています。

これは欠点でもあります。

OSのダークモードを使っている人にとっては、選択肢が減りました。ライトとダークの両方を同じ品質で維持する方法もありますが、配色確認と修正箇所はほぼ2倍になります。

今回は、デザインを1つに絞り、保守を減らす方を選びました。

実際に確認した画面幅 #

見た目だけ確認して終わると、ちょうど中間の画面幅で壊れることがあります。

今回は次の幅で自動確認しました。

320px
390px
640px
768px
1024px
1440px

確認したのは、次の項目です。

ページ全体に横スクロールが出ない
サイト名とメニューが重ならない
デスクトップの各メニューが1行で表示される
長い記事タイトルが枠からはみ出さない
スマートフォンのメニューが開く
JavaScript無効でも主要ページへ移動できる
フッターにプライバシーポリシーがある
記事の説明が空にならない

最後にHugo 0.148.2 Extendedで本番用ビルドを行い、240ページが生成されることも確認しました。

デザイン変更で240ページを1枚ずつ見るのは無理です。

なので、「すべてを目視する」のではなく、「壊れたときに共通して現れる条件」を自動で確認しています。

残った不満 #

採用したデザインにも、不満はあります。

かなりシンプルで、派手さはない
記事画像がないため、一覧の印象は似通う
ライト表示しか選べない
長い説明文が続くと、トップページが縦に長くなる
640px付近のメニューは、今後項目を増やすと再び苦しくなる

特に最後は重要です。

今回メニューを4項目へ減らしたから収まっているのであって、CSSが未来永劫うまく調整してくれるわけではありません。

また項目を増やしたくなった場合は、無理に横へ詰め込まず、モバイルメニューへ切り替える画面幅を広げるか、2段構成を検討します。

最終的にどうしたか #

私はEditorial Airを採用しました。

一番華やかなSoft Gridではなく、一番変更箇所が少なく、記事を増やしても崩れにくい案です。

今回の変更で一番効果があったのは、色でも余白でもなく、ヘッダーの役割を減らしたことでした。

すべてを上に置く
↓
よく使うものだけ上に置く

これだけで、途中改行、スマートフォンの窮屈さ、将来のメニュー追加という複数の問題が一度に減りました。

デザインは、何を足すかを考える作業だと思っていました。

実際には、何を置かないかを決める作業の方が長かったです。

当面はこの状態で運用し、記事が増えたときに、一覧の読みやすさやカテゴリへの移動が本当に使いやすいかを見ていこうと思います。

参考資料 #

Hugo Documentation（Hugo、確認日 2026-08-11）
Congo Documentation（Congo、確認日 2026-08-11）
AdSense navigation guidance（Google、確認日 2026-08-11）
Google Publisher Policies（Google、確認日 2026-08-11）