この記事はCodex製です。
##依頼内容と課題
依頼は、既存プロダクトで発生した Cloudflare Workers の技術障害を、実装レベルでどう解決したかを整理し、あわせて「今後Codexをどう使うと再発防止まで含めて速く解けるか」を技術ブログとしてまとめること。
今回の課題は、同一URLでも断続的に 500/503 が混在し、体感原因（管理更新直後の不整合）と実際の真因（ランタイム/アダプタ層異常）がズレていた点だった。
主に観測したシグネチャ:
TypeError: components.ComponentMod.handler is not a function（500）Worker exceeded CPU time limit.（503）- ユーザー操作有無に関係なく再現率が揺れる断続障害
##アプローチ
今回有効だったのは、Codexに「実装」「検証」「記録」を一連で回させる調査フローを強制したこと。
- 再現を主観ではなく分布で固定
連続アクセスでステータス分布を取り、wrangler tailと時刻を突合。 - 仮説を分離
仮説A: 更新直後キャッシュ不整合
仮説B: OpenNext/Workers 実行基盤の断続不整合
この2本を同時に検証。 - 反証駆動で切り分け
更新シナリオ（閲覧→更新→別UA閲覧）を機械的に再現し、安定成功を確認。 - 上流修正の一次情報を確認
OpenNext Cloudflare1.16.5のHEAD静的アセット経路修正を根拠として採用。 - 修正・再デプロイ・同条件で再検証
修正後に同じ試験回数で再実行し、エラーシグネチャ消失を確認。
ポイントは、Codexに「原因推測」ではなく「反証可能な試験設計」を先に作らせること。これで、相関の強い誤因（更新直後だから壊れた）に引っ張られずに真因へ到達できた。
##アウトプット
今回のアウトプットは、単発復旧ではなく「同型障害に再利用できる運用テンプレート」まで含めて確定したこと。
###1. 技術的な確定事項
- 主因はアプリ更新処理ではなく、Workers 実行層での断続異常だった
- OpenNext 更新と再検証で
500/503シグネチャが解消した - 「更新後に壊れる」は主因ではなく、観測タイミングの相関だった
###2. Codex活用の標準手順（今後）
- 最初の依頼で
症状 / 期待する完了条件 / 制約を固定する - Codexに
再現スクリプト + ログ収集 + 仮説比較を必ず同時実行させる - 修正後は「同じ試験を同じ回数」で回帰確認する
- 最後に、変更理由と検証結果を docs/memo へ残す
###3. 実務での使い分け
- Codexに任せる: 再現自動化、ログ抽出、差分調査、回帰検証
- 人間が決める: 影響許容度、本番反映タイミング、ロールバック判断
この分担にすると、障害調査の初速を落とさず、誤修正率も下げられる。今回の復旧で確認できた価値は、コード生成そのものより、調査プロセスを壊さず走り切る実行力にある。
##参照した一次情報・一次ソース
このエントリ執筆時に参照した公開一次情報は次の6件。