去年の弥七が埋めた一行を、今年のCodexが掘り当てた

このチャットは、もう何度アーカイブしたかわからない。

「終わった」と思って閉じるたび、予約投稿が止まるたびに掘り返し、また調べ、また閉じる。

今回ようやく、本当に閉じられそうである。

---

発端は去年の応急処置だった

WordPressへの攻撃対策としてIP制限を導入したあと、予約投稿が動かなくなった。

当時は原因を追い切れず、ChatGPTと相談しながら外部cronを導入し、「とりあえず動かす」方向で対処した。

保守では珍しいことではない。

まずサービスを止めないことが優先になる。

ただ、その応急処置の中に、新しい不具合も一緒に埋め込んでいた。

---

九か月後、調査方法が変わっていた

今年は、最初からコードを読み始めなかった。

Codexへ渡したのは、

• 関係するPHP
• WordPress本体の処理
• 実行ログ
• テーマ側の条件
• 現在の構成

人間が一行ずつ読むのではなく、静的解析で候補を洗い出してもらう。

こちらは結果を見ながら追加調査を依頼し、必要な情報だけを渡していく。

原因特定と修正を意識して分離する進め方になっていた。

---

犯人は十一行目にいた

原因は意外なほど小さかった。

DOING_CRON を有効にするため、先に DOING_CRON を定義していたのである。

しかしWordPress側は、その定数を見て、

「もうcronは動いている」

と判断し、本来実行するはずだった処理を終了していた。

エラーも出ない。

ログにも残らない。

だから九か月も見逃された。

削除したのは、たった一行。

それだけで予約投稿は動き始めた。

---

保守は机の前でやるものではなくなった

今回、自分はずっとPCの前にいたわけではない。

Codexへ調査を依頼し、外出し、移動中に結果を確認する。

原因が見つかった時点でディレクターへ速報を送り、修正内容を共有し、出先で案件をクローズした。

コードを書く場所と、保守を進める場所は、もう一致しなくなっている。

---

AIが進化しただけではない

振り返ると、一年前と今年で変わったのはAIだけではなかった。

去年は、

「とりあえず直す」

ことが目的だった。

今年は、

• ログを残す
• 原因特定と修正を分ける
• 調査指示を具体化する
• ChatGPTとCodexを役割分担させる
• 技術内容を報告用の言葉へ翻訳する

そんな保守の進め方そのものが変わっていた。

AIを使うようになって、人間の仕事が減ったわけではない。

人間が考える場所が変わったのである。

---

おわりに

去年、AIと一緒に書いた一行を。

今年、別のAIと一緒に見つけた。

保守とは、過去の自分との共同作業でもある。

そして今回、このチャットもようやく本当に閉じられそうである。