Codex Guide

CSS cache busting

CodexでCSS変更後に
キャッシュ対策をした実践ログ

CSSを変更しても、公開画面では古いCSSが読まれていることがあります。今回の実践ログでは、CSSファイルを変えたかだけでなく、公開HTMLがどのCSS URLを読んでいるかを確認し、必要に応じてバージョンクエリで反映確認しやすくした流れをまとめます。

この記事は、実際の作業を一般化してまとめた実践ログ型ガイドです。具体的な案件名、内部情報、サーバーパス、秘密情報は掲載していません。

当サイトはOpenAI公式サイトではありません。CodexやChatGPTの使い方を、実体験ベースで整理する非公式ガイドです。

まなぶちゃんがCodex作業の読み方を確認しているイラスト GPTガイドくんがCodex作業の確認ポイントを説明しているイラスト

読み方の1ポイント

目的、対象、確認項目を分けて読む

このページでは、Codex作業を安全に進めるための考え方を整理します。実行前に、対象、触らないもの、確認項目を分けて見ると迷いにくくなります。

まなぶちゃん

このページも、全部を一度に覚えないとダメ？

GPTガイドくん

必要なところから読めば大丈夫です。作業前に対象と停止条件、作業後に確認項目を見ると安全です。

目的を見る注意点を見る確認する

今回やった作業

CSSを変更しても、公開画面では古いCSSが読まれていることがあります。今回の実践ログでは、CSSファイルを変えたかだけでなく、公開HTMLがどのCSS URLを読んでいるかを確認し、必要に応じてバージョンクエリで反映確認しやすくした流れをまとめます。

今回の作業では、表示改善を目的にした変更でも、実画面で悪化したら止めることを重視しました。Codexに実装だけを任せるのではなく、変更差分、バックアップ、戻す範囲、公開後の確認まで整理させることで、作業を広げすぎないようにします。

作業前の状態

作業前は、CSSを変更したはずなのに実画面で変化が分かりにくい状態でした。古いCSSがブラウザやサーバー側のキャッシュで残っているのか、そもそも別のCSSファイルを読んでいるのか、切り分けが必要でした。

表示改善系の作業は、コード差分だけでは良し悪しを判断しにくい領域です。カード幅、余白、折り返し、ボタン位置、PCとスマホの見え方が絡むため、作業前の意図と実画面の印象を分けて確認する必要があります。

作業前に問題だったこと

CSSが反映されない時、さらにCSSを追加すると原因が分かりにくくなります。本当にCSSが効いていないのか、古いCSSを見ているのか、HTML側の参照が変わっていないのかを確認しないと、不要な変更を増やしてしまいます。

特に危ないのは、表示が悪化した時に追加修正を重ねてしまうことです。原因が分からないままCSSを足すと、あとで戻す時にどこまでが必要な変更なのか分からなくなります。まず直前変更を疑い、戻すか、範囲を小さくするかを判断する方が安全です。

Codexに任せたこと

Codexには、公開HTMLのCSS参照、CSSファイルの変更内容、読み込みURL、必要な場合だけのバージョンクエリ更新、公開HTMLで新しいCSS URLが出ているか、PCとスマホの表示確認、不要なファイル変更の有無を確認させました。

Codexには、対象ファイルの確認、差分確認、バックアップ確認、公開HTML確認、HTTP 200、Fatal / 500、CSS読み込み、PCとスマホ表示の確認を任せます。修正案を出すだけでなく、戻す案と停止条件も報告させることで、判断しやすい形にします。

人間が判断したこと

人間側では、キャッシュ対策を乱用しないこと、CSS変更が本当に必要か確認すること、v= クエリは反映確認のために使うことを判断しました。最終的な表示確認は、ファイル差分ではなく実画面で行います。

人間が見るべきなのは、作業が終わったかどうかだけではありません。目的に近づいたか、悪化していないか、影響範囲が大きすぎないか、戻す方が安全かを判断します。Codexの報告を受けても、最後は実画面で確認して決めます。

実際に使った指示文の考え方

指示文では、CSS修正だけを頼まず、戻す条件、触らないファイル、確認URL、作業後の確認項目まで入れます。DB、cron、.htaccess、robots.txt、ads.txt、AdSenseタグ、Search Console確認タグには触らないことも明記します。

うまくいった点

うまくいった点は、悪化した表示を無理に上書きせず、確認と判断を分けられたことです。戻す、比較する、上位3件だけに絞る、キャッシュを確認するという選択肢を持てると、CSS作業で迷子になりにくくなります。

詰まった点・危なかった点

  • 実画面を見ずに完了扱いにする
  • 原因未特定のままCSSを積み増す
  • 全体を戻して正常な変更まで消す
  • PCだけ見てスマホを見ない
  • 戻した後のHTTP確認を省く

CSSやレイアウトの作業は、変更量が少なくても影響が大きいことがあります。特に公開中サイトでは、Fatal error、500、CSS未読込、スマホ表示崩れ、意図しない巻き戻しを避ける必要があります。

作業後に確認したこと

作業後は、対象ページがHTTP 200であること、Fatal / 500がないこと、CSSが読み込まれていること、公開HTMLの参照が正しいこと、PCとスマホで大きく崩れていないことを確認します。あわせて、canonical、robots、noindexなし、内部リンクが壊れていないことも見ます。

次から使える指示文テンプレート

以下は、CSS失敗や表示悪化が起きた時にCodexへ貼れるテンプレートです。

以下の公開中サイトで、CSS変更が公開画面に反映されているか確認してください。

まず公開HTMLのCSS参照URLを確認し、変更したCSSファイルが読み込まれているかを見てください。

古いCSSが読まれている可能性がある場合は、必要に応じてCSS参照のバージョンクエリ更新を提案してください。

ただし、不要なファイル変更や乱用は避けてください。

作業後は、公開HTMLで新しいCSS URLを確認し、PCとスマホで表示を確認してください。

確認チェックリスト

表示改善は、作業後の確認まで含めて完了です。

  • CSS変更した
  • CSS参照が更新された
  • 公開HTMLで新しいCSS URLを確認した
  • 古いCSSが残っていない
  • 不要なファイル変更をしていない
  • PCで表示確認した
  • スマホで表示確認した
  • CSS変更以外のファイルを触っていない

関連する使い方ガイド

実践ログ型ガイド一覧Codex作業を一般化した実践ログの一覧です。 CSS変更が悪化した時の戻し方CSS変更を積み増さず戻した実践ログです。 上位3件だけ強調した実践ログ全体改修ではなく上位3件を目立たせた実践ログです。 Codexロールバック戻す判断と確認項目を整理する固定ガイドです。 Codexバックアップ作業前後のバックアップ確認に関するガイドです。 Codex公開前チェックHTTPや表示確認を行う固定ガイドです。 Codex作業報告の見方報告と実画面確認を分けて見るガイドです。

注意書き

この記事は、実際の作業を一般化してまとめた実践ログ型ガイドです。具体的な案件名、内部情報、サーバーパス、秘密情報は掲載していません。

CSS変更やロールバックは、対象ファイルと確認項目を絞って行うことが重要です。Codexに任せる部分と、人間が実画面で判断する部分を分けることで、追加修正の積み増しや意図しない巻き戻しを避けやすくなります。