AIコーディング 2026.10.21 読了 4 分

移行前の動きを記録しておかないと、直ったか分からない

「前はどうだったか」を誰も覚えていません。先に記録を取る方法を決めました。

この記事の結論

移行後に必ず起きるのが「前はこう動いていた気がする」という話だ。記録が無いと確かめようがない。

記憶は当てにならない

移行後に出た指摘のうち、実際には前から同じ動きだったものが相当あった。

記録が無いと、これを証明できない。結果として、こちらが直す羽目になる。もともとの仕様なら、直すかどうかは別の判断のはずだ。

いちばん簡単で効いたのがこれだった。移行前に、主要なURLを全部取得して保存する。

while read url; do
  curl -s "$url" > "before/$(echo $url | md5).html"
done < urls.txt

移行後に同じことをして、差分を取る。差分が出た所だけ見ればいいので、確認が現実的な量になる。

日時、セッションID、CSRFトークン、広告タグ。これらは毎回変わるので、そのまま比べると全ページが差分になる。

比べる前に、変わる部分を置換して潰しておく。

sed -E 's/[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9:]{8}/DATE/g'

潰す対象は、1回差分を見れば分かる。最初から完璧に用意しようとしなくてよい。

サイトマップがあればそれを使う。無ければアクセスログから取る。

awk '{print $7}' access.log | sort | uniq -c | sort -rn | head -200

アクセス数の多い順に並ぶので、上位200件を押さえれば実質的にほぼ全部になる。使われていないURLに時間をかけない。

そのまま使える形

移行の前に、いまの挙動をそのまま保存する。正しいかどうかは問わない。比較の基準にする。

2番の異常系を忘れない。移行後に変わりやすいのは、正常系ではなく境界のほうだ。PHPの版が上がると、空文字や数字めいた文字列の扱いが変わる。

curlでセッションを保持すれば取れる。ここは手間がかかるが、ログインの内側ほど壊れたときの影響が大きいので省けない。

テスト用のアカウントを1つ作っておくと、以降の確認が全部これで済む。

画面だけでは、裏で動く処理が分からない。バッチやメール送信は、入力と出力をファイルに吐くようにしておく。

移行後に同じ入力を流して、出力を突き合わせる。画面と違って目で見ても分からないので、記録がないと確認そのものができない。

1日では足りなかった。月末だけ動く処理、週次のバッチがある。

最低1か月は流したい。間に合わない場合は、せめて「この期間しか記録していない」とはっきりさせておく。あとで想定外が出たとき、記録の範囲外だったのか、本当に壊したのかが分かる。

差分が大量に出たとき、全部を目で追うのはつらい。

差分をまとめて渡して「意味が変わっている差分だけ抜き出して」と頼むと、空白や並び順だけの違いを除いた一覧が返る。ここは素直に速かった。

ただし最終判断は見る。「意味が変わっていない」と言われた中に、1件だけ本物が混ざっていたことがある。

当たり前のようだが、順番を間違えやすい。少し直してから記録を取ると、その「少し」が比較の基準に紛れ込む。

記録を取り終えるまでは、サーバーの設定も含めて何も変えない。変えたくなったら、変える前にもう一度記録を取る。

移行前後の差分一覧を報告書として渡すと、何を確認したかが相手に伝わる。

「全部確認しました」より、「200URLを比較し、差分が出た12件はこの理由です」のほうが信用される。作業の中身が見えるからだ。

あわせて読む

コードが書けなくてもAIで作れる範囲と、そこで止まる理由 — プログラミング未経験でAIにコードを書かせたとき、どこまで進んでどこで止まるのかを実際に試して整理しました。
AIが書いたコードをそのまま入れて壊したときの、戻し方と予防 — 動いていたものが動かなくなり、どこを変えたか分からなくなりました。復旧の手順と、同じことを繰り返さないための備えです。
AIにコードを直させるとき、範囲を区切らないと別の場所が壊れる — 1か所の修正を頼んだつもりが、関係ない機能が止まりました。範囲の伝え方と、巻き込みを防ぐ手順です。