確認作業の1ポイント
作業前の指示と、作業後の確認を分ける
テンプレート、チェックリスト、報告書、ロールバックは、Codex作業を安全に閉じるための道具です。急いで次へ進む前に確認項目を見直しましょう。
報告書をもらったら、すぐ次に進めていい？
変更ファイル、触っていないファイル、停止条件、公開URL確認を見てから判断しましょう。
今回やった作業
ページ数が多いサイトでは、毎回すべてのURLを確認するのは現実的ではない場合があります。今回の実践ログでは、トップ、カテゴリ、個別、変更対象、関連親ページなど代表URLを選び、確認範囲を明記した流れをまとめます。
今回の作業では、Codexの作業報告をそのまま完了扱いにせず、公開URL、公開HTML、HTTPステータス、エラー文字列、確認したURL一覧を使って裏取りしました。公開中サイトでは、ローカルやファイル上の変更と、ユーザーが見る公開ページが一致しているとは限らないためです。
作業前の状態
作業前は、複数ページに影響する可能性がある変更を行った後でした。全ページ確認は重いため、主要ページや代表URLを選ぶ必要がありました。どこまで確認したかを報告書に残さないと、確認済みという言葉が曖昧になります。
作業前の問題は、実装したつもり、確認したつもり、完了したつもりが混ざりやすいことでした。特に公開HTML、Fatal error、SQLSTATE、代表URLの確認範囲は、指示文で明確にしておかないと報告から抜けやすくなります。
作業前に問題だったこと
確認範囲が曖昧だと、「確認済み」と書かれていても、どのURLを見たのか分かりません。全ページ確認していないなら、代表確認であることを明記する必要があります。未確認範囲を隠さないことも重要です。
Codex作業では、作成・変更・調査・公開反映・実画面確認が別の段階です。どこまで終わっているかを分けて見ないと、公開ページで見えない状態や500エラーを見逃します。完了条件だけでなく、完了と言わない条件も必要です。
Codexに任せたこと
Codexには、主要ページの選定、代表URLの確認、カテゴリ違いのURL確認、対象ページのHTTP 200、Fatal / SQLSTATE確認、確認したURL一覧、未確認範囲の明記を任せました。
Codexには、対象URLの取得、公開HTMLの確認、grep対象の確認、HTTP 200、Fatal errorなし、SQLSTATEなし、sitemap.xml、robots.txt、関連ページの確認を任せます。確認したURLを報告書に残すことで、後から確認範囲を追えるようにします。
人間が判断したこと
人間側では、全件確認ではなく代表確認にすること、トップ、カテゴリ、個別、関連ページをバランスよく見ること、問題が出たら確認範囲を広げることを判断しました。
人間が判断するのは、公開確認の範囲と完了扱いにする基準です。全ページ確認が必要なのか、代表URLでよいのか、エラーが出た時に停止するのか、未確認事項をどう扱うかは、人間が先に決めてCodexへ渡します。
実際に使った指示文の考え方
指示文では、「確認して」だけではなく、何を確認するかを具体化します。公開HTMLで見る文言、リンク、class、HTTPステータス、Fatal error、SQLSTATE、確認したURL、未確認範囲を報告対象にします。DB、cron、.htaccess、robots.txt、ads.txt、広告タグ、Search Console確認タグには触らないことも明記します。
うまくいった点
うまくいった点は、報告と実態を分けられたことです。Codexの「実装済み」や「完了」という言葉だけではなく、公開HTML上の証拠、HTTP 200、エラー文字列なし、確認URL一覧で裏取りできるようになりました。
詰まった点・危なかった点
- ファイル変更だけで完了扱いにする
- 公開HTMLを確認しない
- HTTP 200を確認しない
- 確認したURLを報告しない
- 未確認範囲を隠す
危なかったのは、ファイル上の変更で満足してしまうことです。公開HTMLに出ていない、HTTPが200ではない、Fatal errorが出ている、確認範囲が曖昧という状態では、公開作業としてはまだ不十分です。
作業後に確認したこと
作業後は、対象ページが200 OKであること、Fatal errorやSQLSTATEがないこと、公開HTMLに対象文言やリンクがあること、canonicalとrobotsが維持されていること、noindexが入っていないこと、CSSが読み込まれていることを確認します。
次から使える指示文テンプレート
以下は、公開確認や完了条件をCodexへ依頼する時に使えるテンプレートです。
以下の公開中サイトで、Codex作業後の公開確認を行ってください。
全ページ確認ではなく、まず主要ページと代表URLを選んで確認してください。
トップページ、カテゴリページ、個別ページ、今回変更したページ、関連する親ページを優先してください。
確認したURL、HTTPステータス、Fatal errorなし、SQLSTATEなし、未確認範囲を報告してください。
問題が出た場合は、確認範囲を広げる前に直前変更と原因候補を整理してください。確認チェックリスト
公開確認は、確認したURLと確認内容を残すことが大切です。
- 代表URLを決めた
- 複数カテゴリを確認した
- 変更対象ページを確認した
- 親ページを確認した
- 全件確認しない理由がある
- 問題があれば範囲拡大
- 確認したURLを報告した
- 未確認範囲を明記した
- HTTP 200を確認
- Fatal / SQLSTATEなし
関連する使い方ガイド
注意書き
この記事は、実際の作業を一般化してまとめた実践ログ型ガイドです。具体的な案件名、内部情報、サーバーパス、秘密情報は掲載していません。
公開確認では、Codexに任せる確認作業と、人間が判断する完了基準を分けることが重要です。確認していないことは未確認と書き、見えていないものを完了扱いにしない運用にします。