この記事で扱う作業
この記事で扱うのは、公開中サイトでカード一覧の見た目を調整したあと、実画面で意図と違う表示になったため、直前のCSS変更だけを戻した作業です。コード上では整って見える変更でも、実際の画面では余白、幅、並び、スマホ表示の影響で、かえって読みにくくなることがあります。
今回のポイントは、悪化した表示に対してさらにCSSを重ねないことでした。表示が崩れた時ほど、つい「もう少し余白を変える」「別のclassを追加する」と進めたくなります。しかし原因が直前変更にある可能性が高い場合は、追加修正よりも、まず元の状態へ戻して被害範囲を小さくする方が安全です。
このログでは、CSS変更の戻し方だけでなく、Codexに何を確認させるべきか、人間がどの時点で差し戻しを判断するか、戻したあとに何を確認するかまでを、次回使える手順としてまとめます。
作業前の状態
作業前のページには、カード一覧をもう少しランキングらしく見せたいという課題がありました。カードは表示されていましたが、情報のまとまりや順位の見え方が弱く、見た目を整えれば改善できそうに見える状態でした。
そこでCodexにはCSS調整を任せました。ところが、公開画面で見ると意図した「ランキング感」よりも、横に広がった一覧の印象が強くなり、カードごとの比較もしにくくなっていました。コード上では破綻していなくても、実画面では読む順番や視線の流れが変わってしまった状態です。
この段階で重要だったのは、CSS変更の目的が「見た目を変えること」ではなく、「読者が情報を見比べやすくすること」だったと立ち返ることでした。目的から外れた見た目になった時は、変更量が多いほど戻しにくくなります。
作業前に問題だったこと
CSSの変更は、HTMLやメタタグの変更よりも一見軽く見えます。しかし、共通CSSを触る場合は複数ページに影響する可能性があり、カード、一覧、ボタン、スマホ幅の表示までまとめて変わることがあります。
今回危なかったのは、表示悪化の原因を十分に切り分けないまま、さらにCSSを追加しそうになった点です。原因が「直前の幅指定」なのか、「カード内の余白」なのか、「グリッド設定」なのか分からないまま修正を重ねると、どの変更が効いているのか追えなくなります。
特にCodexに対して「見た目をもっと整えて」とだけ頼むと、別のCSSを追加して一時的に整えようとする場合があります。その結果、元の問題は残り、CSSだけが増え、次の作業者が戻しにくい状態になることがあります。
なぜこの作業が必要だったか
この作業が必要だった理由は、表示改善の失敗を小さな範囲で止めるためです。サイト運用では、失敗しないことよりも、失敗した時に戻せる単位で作業することの方が大切な場面があります。
直前変更だけを戻すと、何が原因だったのかを整理しやすくなります。戻したあとにページが元の表示へ近づけば、その変更が悪化の主因だったと判断できます。逆に戻しても改善しない場合は、別の変更やキャッシュ、読み込み順などを疑う材料になります。
また、見た目の問題に気を取られて、HTTP 200、Fatal error、CSS読み込み、スマホ表示、内部リンクのような基本確認を忘れると、より大きな問題を見落とします。見た目を戻す作業でも、公開ページとして成立しているかの確認は必要です。
Codexに任せたこと
Codexに任せたのは、追加の見た目修正ではなく、まず直前変更の特定と戻し作業でした。どのCSSファイルを触ったのか、バックアップや直前状態があるのか、戻す範囲をCSSだけに限定できるのかを確認させました。
また、戻した後の確認もCodexの役割に含めました。戻して終わりではなく、対象ページが200 OKで表示されるか、Fatal errorや500が出ていないか、CSSが読み込まれているか、スマホ幅で大きく崩れていないかを確認する必要があります。
- 直前に変更したCSSファイルを特定する
- バックアップまたは戻せる状態があるか確認する
- CSS以外のファイルを触らず、直前変更だけを戻す
- 戻した後に対象ページのHTTP 200を確認する
- Fatal error、500、CSS読み込み不良がないか確認する
- スマホ表示で大きな崩れがないか確認する
- 本来直したかった問題が残っているか整理する
人間が判断したこと
人間側で判断したのは、「追加修正を積み重ねない」という方針です。Codexは次の修正案を出せますが、出せることと進めるべきことは別です。実画面が悪化した時は、作業を進めるよりも、いったん正常状態へ戻す判断が必要でした。
また、見た目よりも本質的な課題を優先することも人間側で決めました。ランキング型のページであれば、カードの装飾よりも、順位、指標、内部詳細ページへの導線が見えることの方が重要です。CSSで雰囲気を作る前に、情報として何を伝えるべきかを確認しました。
戻す範囲をCSSだけに限定したことも重要です。複数ファイルをまとめて戻すと、別の改善まで消してしまう可能性があります。直前変更だけを戻し、その後で必要な改善を改めて小さく設計する方が安全でした。
実際に使った指示文の考え方
指示文では、「CSSを直してください」ではなく、「原因未特定のまま追加CSSを重ねないでください」と明記することが重要でした。Codexに作業方針を伝えないと、修正を続ける方向に進みやすくなります。
さらに、触ってよい範囲と触らない範囲を分けました。対象は直前に変更したCSSのみとし、DB、cron、.htaccess、広告タグ、Search Consoleタグ、共通部品には触らない条件を入れます。これにより、表示の戻し作業がサイト全体の設定変更へ広がることを防げます。
最後に、戻した後の報告項目を指定します。変更したファイル、戻した範囲、確認したURL、HTTP状態、表示確認、未解決の課題を報告させることで、次の判断に使える作業ログになります。
うまくいった点
うまくいった点は、作業を「戻すこと」に限定したため、影響範囲を小さくできたことです。見た目が悪化した状態で別のCSSを重ねると、後から原因を追うのが難しくなりますが、直前変更だけを戻せば、作業前後の差分が分かりやすくなります。
また、戻した後に「本来直したかった問題が残っているか」を確認したことで、次の改善を冷静に設計できました。今回のようなケースでは、CSS全体の大改修よりも、順位や指標、リンク先など情報の見せ方を優先した方が効果的な場合があります。
Codexに作業報告を出させる時も、「戻しました」だけではなく、何を戻し、何を触っていないかを明記させると、後から実践ログとしても再利用しやすくなります。
詰まった点・危なかった点
危なかった点は、表示の違和感をさらに見た目で隠そうとすることでした。CSSは短い変更でも影響範囲が広く、特に共通classを使っている場合、別ページのカードやボタンまで変わる可能性があります。
もう一つの危険は、バックアップや直前状態を確認せずに戻そうとすることです。戻す対象が不明確だと、必要な変更まで消してしまいます。戻す前に、どのファイルのどの変更を対象にするのかを確認する必要があります。
また、公開画面だけを見て判断すると、キャッシュや一時的な読み込み不良を誤解する場合があります。公開HTML、CSSファイルの読み込み、HTTPステータス、スマホ表示を合わせて見ることで、判断の精度が上がります。
作業後に確認したこと
作業後は、まず対象ページが200 OKで表示されるか確認しました。CSSだけを戻したつもりでも、HTMLやPHPの読み込みに影響していれば、別の問題として表面化する可能性があります。
次に、Fatal errorや500が出ていないか、CSSが読み込まれているか、スマホ幅で大きく崩れていないかを確認しました。表示が戻っていても、CSS読み込みが失敗しているだけなら意味がありません。
最後に、本来直したかった問題が残っているかを整理しました。戻したことで悪化は止められましたが、ランキング感や導線の弱さが残るなら、次の作業ではCSSではなく、順位表示、指標、内部リンクの改善として扱うべきです。
- 対象ページがHTTP 200で表示される
- Fatal errorや500が出ていない
- CSSが読み込まれている
- スマホ表示で大きく崩れていない
- 直前変更だけが戻っている
- DB、cron、.htaccess、広告タグを触っていない
- 本来直したかった課題が整理されている
次回使えるCodex指示文テンプレート
次回同じ作業を依頼する時は、表示をさらに直す前に、直前変更の特定と戻し可否を確認させます。以下のように、追加修正を止める条件まで含めると安全です。
以下の公開中サイトで、直前のCSS変更後に実画面の表示が悪化していないか確認してください。
悪化している場合は、原因未特定のままCSSを追加しないでください。まず直前に変更したCSSファイル、変更範囲、バックアップまたは戻せる状態を確認してください。
必要な場合は、直前変更だけを戻してください。DB、cron、.htaccess、広告タグ、Search Console確認タグ、共通header/footer、問い合わせフォーム実装は触らないでください。
戻した後に、対象ページのHTTP 200、Fatal errorなし、500なし、CSS読み込み、スマホ表示、内部リンク、もともと直したかった課題が残っているかを確認し、変更ファイルと確認結果を報告してください。確認チェックリスト
チェックリストでは、戻す対象と戻した後の公開確認を分けて見ます。CSSを戻しただけで安心せず、公開ページとして壊れていないことまで確認します。
- 直前変更ファイルを特定した
- バックアップまたは戻せる状態を確認した
- CSSだけを戻した
- 追加修正を積み重ねていない
- 戻した後にHTTP 200を確認した
- Fatal errorや500がない
- CSSが読み込まれている
- スマホ表示で大きく崩れていない
- DB、cron、.htaccessを触っていない
- 広告タグとSearch Console確認タグを触っていない
- 本来直すべき問題が残っているか確認した
まとめ
CSS変更が悪化した時に大切なのは、すぐ次の修正を重ねることではありません。まず直前変更を特定し、必要ならその変更だけを戻し、公開ページが安定した状態に戻るかを確認することです。
Codexは修正案を出すのが得意ですが、どこで止めるか、どの範囲だけ戻すか、何を確認したら完了とするかは人間が判断する必要があります。作業の目的が「見た目を変えること」ではなく「読者に情報を伝えること」なら、CSSより順位表示や内部導線を優先すべき場面もあります。
次に同じ作業をする時は、戻せる状態を作り、触るファイルを限定し、戻した後のHTTP、CSS読み込み、スマホ表示、未解決課題まで確認すると、安全に進めやすくなります。
注意書き
この記事は、実際の作業を一般化してまとめた実践ログ型ガイドです。具体的な案件名、内部情報、サーバーパス、秘密情報は掲載していません。
同じ作業でも、サイト構成、利用しているCMSやHTML構成、公開環境、GitHub運用の有無によって確認すべき点は変わります。実作業の前には、対象ファイル、触らないファイル、停止条件、確認項目を決めたうえで進めてください。