確認作業の1ポイント
作業前の指示と、作業後の確認を分ける
テンプレート、チェックリスト、報告書、ロールバックは、Codex作業を安全に閉じるための道具です。急いで次へ進む前に確認項目を見直しましょう。
報告書をもらったら、すぐ次に進めていい?
変更ファイル、触っていないファイル、停止条件、公開URL確認を見てから判断しましょう。
今回やった作業
CSS用の追加classが、実際に公開HTMLへ出力されているか確認した流れを一般化します。CSSを追加しても、HTML側に想定したclassが出ていなければ、対象要素には効きません。
今回の作業では、Codexの報告だけでなく、公開URL、公開HTML、PC表示、スマホ表示、スクリーンショット、人間が見た時の所感を組み合わせて確認しました。表示系の改善は、ファイル変更やHTTP 200だけでは判断できません。読者が実際に見る画面で、順位、指標、ボタン、導線が理解できるかまで見る必要があります。
作業前の状態
作業前は、上位3件を強調するためにclassを追加したい状態でした。CSS側には強調用の指定があっても、公開HTMLにclassが出ているか、想定件数と実際の出力件数が一致しているか、余計なカードに出ていないかを確認する必要がありました。
作業前の段階では、修正対象は分かっていても、どの画面サイズで、どの要素を、どの基準で見ればよいかが曖昧でした。スマホ表示、PC表示、公開HTML、実画面、スクリーンショット確認を分けずに扱うと、報告は完了に見えても、実際には読みにくい状態を見逃す可能性があります。
作業前に問題だったこと
CSSファイルだけ見ても、表示改善の確認としては十分ではありません。HTMLにclassが出ていない、class名が違う、想定より多く出ている、想定より少ない、対象外ページにまで出ている、といったズレがあると、表示は意図通りになりません。
Codex作業では、機械的な確認と人間が見る表示確認を分けて考えることが大切です。HTMLに存在すること、CSSが読み込まれていること、HTTP 200で返ること、スマホで読みやすいこと、PCで情報密度が適切なことは、それぞれ別の確認です。どれか一つだけで完了扱いにすると、表示改善の品質が不安定になります。
Codexに任せたこと
Codexには、公開HTML取得、追加classのgrep確認、想定件数の確認、CSSファイルの読み込み確認、classとCSS指定の一致確認、余計なclassが出ていないか、主要ページでの確認を任せました。CSSだけで完了扱いにせず、公開HTMLと実画面の両方を見るようにしました。
あわせて、公開HTMLで対象要素が出ているか、CSSが読み込まれているか、画面サイズごとに崩れがないか、確認したURLを報告書に残すことも任せました。表示確認は感覚だけに寄せず、HTTP 200、公開HTML、スクリーンショット、目視所感をセットにすると、後から確認しやすくなります。
人間が判断したこと
人間側では、CSSだけで完了にしないこと、HTMLにclassが出ていること、想定件数と一致していること、上位3件だけなら3件に限定すること、余計なページや余計なカードに出ていないことを判断しました。
人間が判断するのは、最終的に読者に伝わるかどうかです。Codexは確認項目を洗い出し、公開HTMLやHTTP状態を調べるのに向いています。一方で、読みやすいか、迷わないか、ランキングページとして意味が伝わるか、表示改善が本当に良くなったかは、人間が実画面を見て判断する必要があります。
実際に使った指示文の考え方
指示文では、単に「表示を確認してください」と書くのではなく、PC表示とスマホ表示を分け、横スクロール、ボタン配置、順位表示、順位指標、追加class、スクリーンショット、人間目線の所感を確認対象にしました。DB、cron、.htaccess、robots.txt、ads.txt、AdSenseタグ、Search Console確認タグには触らない条件も明記しました。
うまくいった点
うまくいった点は、表示確認を「大崩れなし」だけで終わらせなかったことです。PCとスマホを分けて見ることで、どの画面で何が読みやすいか、どの導線が埋もれているかを整理できました。公開HTMLとスクリーンショットを組み合わせることで、実装済みと見た目の良し悪しを分けて判断できました。
詰まった点・危なかった点
- PCだけで表示確認済みにする
- 公開HTMLにあるだけで画面確認を省く
- スマホの横スクロールを見ない
- スクリーンショットを残さない
- 人間が見た時の所感を報告しない
危なかったのは、HTMLに出ていることをそのまま表示改善と見なしてしまうことです。公開HTMLにclassや文言が出ていても、CSSの当たり方、余白、折り返し、画面幅によって読者には伝わらないことがあります。表示系の作業ほど、最後に画面を見て戻す判断も必要です。
作業後に確認したこと
作業後は、公開URLが200 OKであること、canonicalが自己URLであること、robotsがindex,followであること、noindexメタがないこと、CSSが読み込まれていること、スマホ表示で大崩れがないこと、PCとスマホそれぞれで重要導線が見えることを確認します。さらに、未完成文言や秘密情報が混じっていないことも確認対象にします。
次から使える指示文テンプレート
以下は、表示確認やスクリーンショット確認をCodexへ依頼する時に使えるテンプレートです。
以下の公開中サイトで、CSS用に追加したclassが公開HTMLに出力されているか確認してください。
対象URLを取得し、追加classをgrepで確認してください。
上位3件だけに付けるclassの場合は、想定件数が3件か確認してください。
CSSファイルが読み込まれているか、class名とCSS指定が一致しているか、余計なカードや対象外ページにclassが出ていないかも確認してください。
CSSだけで完了扱いにせず、公開HTMLと実画面の両方を確認してください。確認チェックリスト
表示確認では、確認した画面サイズと確認観点を分けて残すことが重要です。
- 追加classあり
- 想定件数あり
- 主要ページで確認
- CSS反映確認
- class名とCSS指定が一致
- 余計なclassなし
- 対象外ページに出ていない
- 公開HTMLで確認
- 実画面で確認
関連する使い方ガイド
注意書き
この記事は、実際の作業を一般化してまとめた実践ログ型ガイドです。具体的な案件名、内部情報、サーバーパス、秘密情報は掲載していません。
表示確認では、Codexに任せる確認作業と、人間が判断する見え方の確認を分けることが大切です。確認していないことは未確認と書き、見えていないものを完了扱いにしないようにします。


