Codexの完了報告はどこを見る？build・check・diff・本番確認URLの読み方

結論：完了報告は成功宣言ではなく、検証可能な証拠の束

Codexが「完了」と報告しても、それは作業の区切りを示す文章であって、仕様どおり・安全・本番反映済みを一度に証明するものではありません。目的と変更範囲、差分、決定的なチェック、生成物、commit、push、本番確認を別々に読み、確認できない項目は未確認のまま扱います。

報告の各項目を「証拠」として読み替える

「変更しました」は対象範囲の説明、「build成功」はそのチェックの結果、「commitしました」はGit上の記録です。どれも別の層を自動的には保証しません。特に通常pushはGitHubのbranchを更新しても、手動FTPや別CDN上の公開HTMLを更新したことにはなりません。

GitHubの差分レビューへつなぐ

GitHub Docsは、レビューの目的とIssueなどの文脈を先に確認し、Files changedでファイルごとの差分を読み、依存変更はmanifestやlockfileも確認してから、comment・approve・request changesを選ぶ流れを案内しています。Codexの完了報告も同じ順に、要約を鵜呑みにせず、目的、全変更ファイル、チェック、レビュー判断へ戻します。

• 依頼の目的と受け入れ条件が、変更後の差分に残っているか見る
• 変更ファイルを一つずつ確認し、package、lockfile、workflow、設定、画像、共通CSSを別枠で見る
• buildやCIの成功を、仕様適合や本番反映の成功と混同しない
• AIの要約・reviewコメントは論点整理に使い、採用・merge・公開の判断は人間が持つ

静的サイトの完了報告で外せない確認

AI開発横丁のような静的サイトでは、ソースデータを編集しただけでは納品物の確認になりません。build後のstatic HTML、sitemap、search index、metadata、uploadを順に確認し、distとuploadが同じ版かを見ます。GitHubへのpushまでをローカルリリース候補として記録し、手動アップロードを行っていない場合は「本番未反映」と明示します。

AIレビューが速くても、検証を省略しない

2026年7月の研究は、207プロジェクトの102万件のpull requestを調べ、AI reviewerを含む一部の協働パターンで判断が速くなる一方、レビュー品質が自動的に良くなるわけではなく、人間だけのレビューを効率と品質の両方で一貫して上回るパターンは確認できないと報告しています。別のポジションペーパーも、実務上のボトルネックを「動くコードを出せるか」から、人間が意図を合わせ、検証し、方向を修正できるかへ広げています。完了報告では速さではなく、検証可能性と人間の判断点を残します。

長時間タスクの完了報告は、成果より先に確認済み事項を見る

AIエージェントの作業が長くなるほど、完了報告には変更内容だけでなく、実行した検証、未確認事項、触っていない範囲、uploadやsitemapの反映有無が必要になります。

MarketBenchから見る完了報告の読み方

エージェントの成功確率やtoken usageの自己評価は、実測とズレることがあります。完了報告では、自信のある言い方より、実行ログ、差分、build/check結果、未確認事項を優先して見ます。

WorkからCodexへ渡したtaskの完了報告を読む

Workで調査・企画しCodexへ実装を渡した場合、完了報告では公式source、変更範囲、build / check、static HTML、sitemap、upload、diff、commit / push、本番未反映を分けて確認します。新desktop appで入口が統合されても、成果物と検証結果を一つの成功表現にまとめません。