「本文が詰まって見える」の真犯人はテーマ側の1行のmarginだった話
この記事について
版元が運用する媒体の一つ（以下 MT）で「本文が読みにくい」という指摘があった。「読みにくい」は主観的な感想で、そのままでは直しようがない。実際に CSS まで遡って原因を特定し、対処を組み立て、さらに本番へ可逆な形でデプロイするところまでを一つの設計として仕上げた記録。
症状から原因へ
指摘だけでは「フォントが小さい」のか「行間が狭い」のか「段落が詰まっている」のか判別できない。実際にレンダリング結果の CSS を1つずつ確認していくと、原因はテーマ（Cocoon）のカスタマイザーが本文の段落要素へ自動で当てていた、次の1行だった。
/* テーマのカスタマイザーが自動生成していたインラインCSS */
p { margin-bottom: 0.1em; }
段落間の余白がほぼゼロになっていた。加えて本文の font-size は 16px・line-height は 1.6・letter-spacing は 0 という設定で、これも日本語の長文には窮屈な数値だった。見た目の「詰まった感じ」は、この2つの要因が重なって生まれていた。
対処：子テーマに管理ブロックを追加する
WordPress 本体やテーマ本体を直接編集すると、テーマの更新で上書きされて消える。そこで子テーマの CSS に、管理範囲を明示したブロックとして追記する形にした。
/* === MANAGED_BLOCK_START === */
.entry-content p {
margin-bottom: 1.5em !important;
line-height: 1.95 !important;
letter-spacing: 0.02em;
}
.entry-content h2 {
margin-top: 2.6em !important;
margin-bottom: 1.1em !important;
}
/* 表・引用・図版・画像も下余白ゼロだと詰まって見えるので同様に確保 */
.entry-content table,
.entry-content blockquote,
.entry-content figure {
margin-bottom: 1.8em !important;
}
/* === MANAGED_BLOCK_END === */
段落・見出し・リスト・表・引用・画像それぞれに、視覚的な「切れ目」が機能する余白を明示的に与えた。特に段落の margin-bottom を 0.1em から 1.5em に変えたことが、体感の詰まり感を解消する上で一番効いた変更だった。
デプロイ設計：可逆性を最優先にする
本番の WordPress へは FTP で子テーマの style.css を直接書き換える必要があった。手作業での書き換えはミスが混入しやすく、しかも一度上書きすると差分の追跡が難しい。そこでデプロイ処理自体を、次の3点を満たすスクリプトとして作った。
| 要件 | 実装 |
|---|---|
| 差分を書き込む前に必ず確認できる | --dry-run で FTP へは一切書き込まず、変更前後の diff だけを表示する |
| 巻き戻せる | 配備の直前にリモートの style.css をタイムスタンプ付きでリモート・ローカル両方にバックアップする |
| 完全撤去できる | --remove フラグで管理ブロックごと削除し、元の状態に戻す |
管理ブロックはコメントのマーカー（開始・終了）で範囲を区切り、置換のたびにこのマーカー間だけを丸ごと入れ替える方式にした。マーカーの外側にあるテーマ本来の CSS には一切触れない。
def replace_managed_block(original: str, block: str | None) -> str:
start = original.find(START_MARKER)
end = original.find(END_MARKER)
if start != -1 and end != -1:
head = original[:start]
tail = original[end + len(END_MARKER):]
else:
head, tail = original, ""
# block=None なら管理ブロックを削除するだけ（--remove の実体）
return head + (block or "") + tail
--remove は block に None を渡すだけで実現できる。追加と削除を同じ関数で表現できるようにしたことで、ロールバック用の別ロジックを持つ必要がなくなった。
やってみてわかったこと
- 「読みにくい」のような主観的な指摘は、実際にレンダリングされた CSS のプロパティ1行まで遡ると、再現性のある具体的な原因になる。感覚的な指摘のまま対処を始めない
- WordPress 本体・テーマ本体を直接編集せず、子テーマ側にマーカー付きの管理ブロックとして閉じ込めておくと、更新で消えるリスクを避けられるうえに「どこを自分たちが触っているか」が一目で分かる
- 本番の CSS を FTP で直接差し替える運用では、差分プレビュー・バックアップ・完全ロールバックの3点を先に設計してからでないと、怖くて何も試せない。可逆性は後から足す機能ではなく、最初に決める前提条件だった
更新履歴
- 2026-08-06: 初稿公開