AI駆動開発の実運用ノート

本編の目次 › 第4部 規律の仕組み化 › わざと事故る

AI駆動開発の実運用ノート No.108スカッシュマージの消失事故を自分の手で起こす

AI と併走してチケット販売サービスを本番運用まで到達させた記録を、そのまま文字に残しています。今回は第4部「規律の仕組み化」から、「わざと事故る」のお話です。

再現手順

スカッシュ消失を実際に起こす

同じファイルを触る大小2本の PR を自分で作る。まず事故を起こし、次に止まることを確かめる。

手順
  1. 同じファイルを触る PR を2本作る(大: 複数ファイルの共通化 / 小: その1ファイルへの追記)
  2. フックを外した状態で、大を通常マージし、続けて小を squash でマージ
  3. git log --oneline と対象ファイルの差分を見る → 小の変更が消えている
  4. フックを有効にして同じ操作 → pre-merge-check.sh が止める
確認できること
  • 手順2でエラーも警告も一切出ない——これがいちばん怖い
  • 通常マージなら履歴が残るので git reflog から復元できる

なぜ、わざわざ自分で事故を起こす必要があるのか。

この事故が「エラーの出ない事故」だからです。 エラーが出る失敗なら、説明を読むだけでも警戒できます。しかしスカッシュ消失は、コマンドが成功し、画面上は何の異常もないまま、実装済みのコードが消えます。

文章で「怖い」と読んでも警戒心は残りません。 自分の手で一度、正しい変更が黙って消えるのを見ておく必要があります。

用意するのは、同じファイルを触る大小2本のPRです。どちらもそれ自体は正しい変更にします。 大きいほうは複数ファイルの共通化、小さいほうはそのうち1ファイルへの追記、といった形です。

成功の判定はこうなります。 まず、squash マージでエラーも警告も一切出ないこと。 これが確認できれば「気づけない」を体感できています。 次に、消えた変更を自分で見つけられること。 そして、フックを有効にした状態で同じ操作をしたときに止まること。 最後に、通常マージなら履歴が残るので復元できることまで確かめてください。

事故のあとに問うべきは「いつ気づけたか」です。次にそのファイルを触るときか、最悪はリリース後になります。

つづく