このページで分かること
Codex報告書と実際の状態が違う時の確認方法を整理します。報告書を鵜呑みにしない、公開URL確認、変更ファイル確認、再確認指示、停止条件を扱います。
起きている症状
報告書では完了と書かれているのに公開URLで反映されていない、変更ファイルが説明と違う、触っていないはずのファイルが変わっている状態です。
最初に確認すること
報告書と実際の状態が食い違う時の原則は、常に「実物」を正とすることです。報告書は作業の説明であって証拠ではありません。食い違いに気づいたら、報告書を読み直すより先に、実物の確認を増やします。
| 確認 | やり方 | そこから分かること |
|---|---|---|
| 公開URLで実際の表示を見る | 報告書の「完了」箇所を、公開URLで1つずつ目視 | 「完了」がローカル完了なのか本番反映済みなのかの食い違い |
| 変更ファイル一覧を確認 | Git差分やFTPの更新時刻で、実際に変わったファイルを列挙 | 報告書に書かれていない変更が混ざっていないか |
| 「触っていない」の記載を検証 | 触っていないと書かれた重要ファイル（SEOタグ・設定系）の実物を見る | 報告漏れ・認識違いの検出。ここが一番の事故ポイント |
| 停止条件に該当していないか | 依頼時に決めた停止条件と、実際の作業範囲を照合 | 本来止まるべき場面で作業が進んでいなかったか |
| 再確認指示を出す | 「報告書のX項目と実際の状態が違う。実物を確認して差分を報告して」と依頼 | AIに実物ベースでの再点検をさせ、食い違いの原因を特定 |
報告と実物の食い違いは、AIが嘘をついているというより、「完了」の定義（ローカルで完了？本番反映まで完了？）や作業範囲の認識がずれていることがほとんどです。再発を防ぐには、依頼文の段階で「完了とは公開URLで確認できた状態を指す」と定義しておくのが効きます。指示の組み立ては指示テンプレート集を参照してください。
Codexに再確認させる指示文
報告書と実際の状態が違う可能性があります。公開URL、変更ファイル、触っていないファイル、停止条件、HTTP確認、内部リンク、SEOタグを再確認し、推測ではなく確認結果で報告してください。やってはいけないこと
- 報告書だけで完了判断する
- 公開URLを見ずに次作業へ進む
- 差分を見ずに上書きする
- 説明と違う変更を放置する
報告と実際がずれる仕組み
「完了しました」と報告されたのに反映されていない、という状況には理由があります。嘘をついているのではなく、報告できる範囲に限界があるためです。
| ずれの種類 | 何が起きているか |
|---|---|
| 作業はしたが反映先が違う | ファイルの編集自体は成功しており、報告としては正しい |
| 一部だけ成功した | 複数ファイルのうち一部が失敗しても、全体は完了と扱われることがある |
| 確認したのが古い状態 | キャッシュが残っていて、反映済みに見えていた |
| 副作用に気づいていない | 指示された箇所は正しく直り、その影響で別の場所が崩れている |
4行目が最も見つけにくいずれです。報告できるのは「やったこと」であって、「やった結果として起きたこと」ではありません。だからこそ、報告書を読むだけでなく実物を見る工程が必要になります。
ずれを見つけた時の伝え方
食い違いに気づいた時、「できていない」と伝えるだけでは、何が違うのか正確に伝わりません。次の3点を添えると解決が早くなります。
- 自分が確認した場所：どのURLを、どうやって開いたかを書きます。キャッシュの可能性も切り分けられます。
- 見えている状態：「変わっていない」ではなく、実際に表示されている内容を書きます。
- 期待していた状態：どうなっていれば正しいのかを明示します。認識の違いがここで分かります。
この3点があると、報告する側と確認する側で、どちらの認識が違っていたかが特定できます。「できていない」だけだと、同じ作業をもう一度繰り返して同じ結果になることがあります。
戻す判断
説明と違う変更があり、影響範囲が読めない場合は、次作業へ進まず差分確認と戻し候補の整理を優先します。
確認チェックリスト
- 公開URLが報告どおり
- 変更ファイルが想定内
- 触っていないファイルが維持されている
- SEOタグが維持されている
- 再確認結果が具体的