WordPress移行記事の本文幅・行間をブログ基準に揃え直した一日

進捗ドキュメントを確認させることから、今日はいつも始まった。前日までに大きなバグを何本も潰していたはずなのに、いざ再開しようとすると自分でもどこまで終わっていたか怪しい。頼りになるのは記憶ではなくmemo/2026-07-22/progress-2026-07-22.mdのほうだった。

今日だけでこのサイクルを3回繰り返すことになる。コンテキストが埋まるたびに区切り、進捗ドキュメントを更新してから次のセッションへ渡す。3回目の再開のときには、もう自分でもどれが今日の何回目の続きなのか数えないと分からなくなっていた。

裏では機械的なチェックスクリプトも並行して走り、リンク切れやテーブル崩れを勝手に洗い出してくれていた。ただ、その日いちばん記憶に残ったのは機械が拾えない種類の指摘、つまり見た目そのものへの違和感の連続だった。

本文の実効幅がなぜか合っていない

移行先のページはブログ記事のフォーマットを踏襲したはずだった。ところが並べて見ると、なんとなく幅が違う気がする。「ブログ記事、あるじゃないですか。あれとメインコンテンツの幅を合わせてほしいんですよ」と伝え、実測を頼んだ。

計測結果を見ると、外枠の要素自体は800pxで一致している。ところが本文を包む要素には左48pxのパディングがあり、実際のコンテンツ幅は752pxだった。

原因を辿らせると、この48pxは技術記事向けの行番号ガター機能のための余白だと分かった。行番号を表示する機能そのものは会計記事には要らない。パディングの数値だけを移植し、機能は持ち込まないという判断で決着させた。全記事を作り直させ、パンくずやタイトルは元の位置のまま、本文だけが右にわずかに沈み込む見た目になったことをブラウザで確認した。

詰まった行間の正体は、見出し側の上書きだった

幅は合ったはずなのに、続けて「行間ですね。あとパラグラフの間……これ両方多分ちょっと詰まりすぎてる」という指摘が来た。「多分そのブログのCSSが当たってないと思います」という見立てが的中していた。

実機のp要素のcomputed styleを測らせ、原因を追わせる。本家のブログでは.docコンテナにline-height: 1.7が設定され、見出し（h1を除く）も本文もそのまま継承している。移行先のテンプレートは、見出し（h2〜h6）にline-height: 1.3の個別指定が残っていて見出しの行間だけ本家より詰まって見え、加えてpのmarginが未移植でパラグラフ同士の間隔も詰まっていた。原因は1つではなく、見出し側の行間と本文側の余白、2つが重なって「全体的に詰まっている」という見え方になっていた。

/* 見出しに残っていた個別指定を削除し、.docのline-height: 1.7に統一 */
h2, h3, h4, h5, h6 { line-height: 1.3; } /* ← これを削除 */

見出し側の指定を消させ、pのmargin（1rem 0）、imgのmargin（24px 0）、strong/bのfont-weight（900）も本家の数値に合わせて追加させた。210記事を再変換させ、数値も見た目も本家と一致したことを確認した。

「クリックヒアー」は、動画の1コマ目だった

ある記事を見ていて、「クリックヒアー」というプレースホルダーが目に入った。「これ多分動画の1コマ目なんですかね」と聞かれ、記憶をたどる。もともと普通の静止画の上に、当時苦渋の決断でこの仕組みを載せた記憶がうっすら残っていた。WordPress時代、クリックすると静止画が動くGIFに切り替わるという、今となっては古典的なJSトリックだった。

このパターンは116記事・546箇所という規模で残っていた。旧サイトから移す過程で、切り替えを起こしていたonclick属性がまるごと落ちていて、静止画のまま固定されていたのが不具合の正体だった。

ffmpegでGIFを動画に変換させ、1コマ目はそのまま起動画像（poster）として残し、上に再生ボタンを重ねる実装に変えさせた。動画そのものを差し替えるのではなく、当時の「1枚目を先に見せる」という判断だけは引き継いで、仕組みだけを今の技術に載せ替える形にした。この日の後半では、同じ「クリックで画像が切り替わる」系の別パターン（動画とは無関係な、Q&Aの解答を切り替える仕組み）が15記事・142箇所で見つかり、同じ考え方で汎用対応させることになる。

ぼやけて見えたのは、黒い膜のせいだった

その再生ボタンを実装させた直後、「これなんかすごい曇って見えるじゃないですか」という指摘が飛んできた。画像を見せられると、たしかに全体が薄いフィルターを掛けたようにくすんでいる。

原因はオーバーレイの背景に敷いていた半透明の黒（rgba(0,0,0,0.18)）だった。動画そのもののオーバーレイならこの濃さでも違和感はないが、1コマ目の静止画をそのまま見せたい今回の用途では、この膜が画質を落として見えていた。

poster画像がある場合は背景を透明にし、画像そのものがクリアに見えるよう直させた。視覚的にも曇りが消えたことを確認してから、次のバグ潰しに進んだ。

「今開いてないですよね」で気づいたこと

別の作業の区切りで、実装した機能の確認をすでに終えたと報告した。すると「ごめん、表示って確認してくれてますか？Chrome DevToolsで。今開いてないですよね」と聞き返された。

慌ててタブの状態を確認させると、指摘の通りだった。少し前まで開いていたはずのプレビュータブは既に閉じられていて、今開いているのは全く別のページだった。

そのターンの中で複数回、実際にクリックや矢印キー操作、モバイルエミュレーションでの検証はやらせていたのは事実だ。ただ、「確認済み」と報告した時点でそのタブは目の前になかった。過去にやった確認と、今この瞬間に見えている状態は別物だと突きつけられた形になる。

新しいタブを開き直させ、その場であらためて見せてもらってから、続きの報告に進んだ。ボタンクリックや矢印キー操作、モバイルでのタップまで、やった検証の中身自体は間違っていなかった。抜けていたのは、報告の直前にもう一度画面を開き直す、というただ一手間だけだった。

セッションが埋まるたびに、ドキュメントへ渡す

今日はこの調子で作業を進め、コンテキストが埋まるたびに区切りを入れた。区切りの前にやることは決まっていて、進捗ドキュメントを最新化してから引き継ぎプロンプトを出す。

次のセッションは必ずそのドキュメントを読むところから始まり、前回どこまで終えたかを確認してから続きに入る。1日の中で3回、このサイクルを回した。同じ日にここまで区切りを重ねたのは、この移行作業では初めてだった。

今日の学び

• 幅も行間も、原因は「新しいCSSが足りない」ではなく「余計な指定が上書きしている」側にあった。差分を疑うときは、足りない箇所より先に、消し忘れた個別指定を探した方が早いことがある
• 昔「苦渋の決断」で組んだ実装は、理由を思い出せなくても意味はあった。1コマ目を先に見せるという判断そのものは引き継ぎ、仕組みだけを今の作り方に載せ替えるのが現実的だった
• 「確認した」と言えるのは、今この瞬間に画面が開いている時だけだ。少し前にやった確認を根拠に「確認済み」と言い切ると、その差はいずれ突かれる
• 1日に3回もセッションを区切ることになったが、進捗ドキュメントさえ更新しておけば、続きは前回の続きとして自然に始められた。記憶ではなくドキュメントに頼る方が、結局は早い

210記事のうち、実際にカテゴリを横断してChrome DevToolsで目視確認まで済んだのはまだ一部だ。残りは次のセッションに引き継いだ進捗ドキュメントの中で待っている。