Codex Guide

HTTP 200 and Fatal check

Codexで公開URLのHTTP 200と
Fatalなしを確認した実践ログ

どれだけ本文やデザインを整えても、公開URLが500になっていたり、Fatal errorが出ていたりすれば公開ページとして成立しません。今回の実践ログでは、HTTP 200、Fatal errorなし、SQLSTATEなしを確認した流れをまとめます。

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

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

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

確認作業の1ポイント

作業前の指示と、作業後の確認を分ける

テンプレート、チェックリスト、報告書、ロールバックは、Codex作業を安全に閉じるための道具です。急いで次へ進む前に確認項目を見直しましょう。

まなぶちゃん

報告書をもらったら、すぐ次に進めていい？

GPTガイドくん

変更ファイル、触っていないファイル、停止条件、公開URL確認を見てから判断しましょう。

指示を作る報告書を見る公開を確認する

今回やった作業

どれだけ本文やデザインを整えても、公開URLが500になっていたり、Fatal errorが出ていたりすれば公開ページとして成立しません。今回の実践ログでは、HTTP 200、Fatal errorなし、SQLSTATEなしを確認した流れをまとめます。

今回の作業では、Codexの作業報告をそのまま完了扱いにせず、公開URL、公開HTML、HTTPステータス、エラー文字列、確認したURL一覧を使って裏取りしました。公開中サイトでは、ローカルやファイル上の変更と、ユーザーが見る公開ページが一致しているとは限らないためです。

作業前の状態

作業前は、ページ修正や記事追加を行った直後でした。対象ページだけでなく、カテゴリトップやsitemap、関連ページが正常に返るかも確認する必要がありました。PHPエラーやSQLSTATEのような文字列が出ていないかも見る必要があります。

作業前の問題は、実装したつもり、確認したつもり、完了したつもりが混ざりやすいことでした。特に公開HTML、Fatal error、SQLSTATE、代表URLの確認範囲は、指示文で明確にしておかないと報告から抜けやすくなります。

作業前に問題だったこと

作業報告で「作成しました」とあっても、公開URLが正常に表示されているとは限りません。共通部品を使うサイトでは、1箇所の変更が別ページに影響する場合があります。見た目以前に、公開URLが生きているか確認することが基本です。

Codex作業では、作成・変更・調査・公開反映・実画面確認が別の段階です。どこまで終わっているかを分けて見ないと、公開ページで見えない状態や500エラーを見逃します。完了条件だけでなく、完了と言わない条件も必要です。

Codexに任せたこと

Codexには、対象URL、主要URL、sitemap.xml、robots.txtのHTTPステータス確認、Fatal error文字列確認、SQLSTATE文字列確認、関連ページ確認、確認したURL一覧の報告を任せました。

Codexには、対象URLの取得、公開HTMLの確認、grep対象の確認、HTTP 200、Fatal errorなし、SQLSTATEなし、sitemap.xml、robots.txt、関連ページの確認を任せます。確認したURLを報告書に残すことで、後から確認範囲を追えるようにします。

人間が判断したこと

人間側では、まず公開URLが生きているか確認すること、対象ページだけでなく関連ページも見ること、FatalやSQLSTATEが出ている場合は作業継続ではなく停止条件にすることを判断しました。

人間が判断するのは、公開確認の範囲と完了扱いにする基準です。全ページ確認が必要なのか、代表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確認を行ってください。

対象ページ、カテゴリトップ、sitemap.xml、robots.txtを確認し、HTTP 200、Fatal errorなし、SQLSTATEなしを確認してください。

確認したURLを一覧にして報告してください。

もし500、Fatal error、SQLSTATEが出た場合は、追加作業を止めて原因候補と直前変更ファイルを報告してください。

DB、cron、.htaccess、robots.txt、ads.txt、広告タグ、Search Console確認タグは触らないでください。

確認チェックリスト

公開確認は、確認したURLと確認内容を残すことが大切です。

  • HTTP 200
  • Fatal errorなし
  • SQLSTATEなし
  • 主要URLを複数確認した
  • sitemap.xml確認
  • robots.txt確認
  • 確認したURLを報告した
  • 500があれば停止
  • 直前変更ファイルを確認した

関連する使い方ガイド

実践ログ型ガイド一覧Codex作業を一般化した実践ログの一覧です。 報告と実画面のズレ確認ログCodex報告と実画面を分けて確認した実践ログです。 公開HTML確認ログ公開HTMLで実装状態を確認した実践ログです。 Codex作業報告の見方報告と確認結果を分けて見る固定ガイドです。 Codex公開前チェック公開前に見るべきHTTPやSEOタグ確認です。 Codex 404確認リンク切れや404を確認する固定ガイドです。 Codex指示文の作り方完了条件や停止条件を書くための固定ガイドです。

注意書き

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

公開確認では、Codexに任せる確認作業と、人間が判断する完了基準を分けることが重要です。確認していないことは未確認と書き、見えていないものを完了扱いにしない運用にします。