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

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

AI駆動開発の実運用ノート No.109事故から再発防止までの時間を自分で測る

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

再現手順

フックをその場で AI に書かせる

いま起きた事故の再発防止フックを、依頼から動作確認まで10分で作る——「AI に規律を作らせる」の再現。

手順
  1. 依頼文に3つ入れる: 検知条件(--squash を含む gh pr merge)・ブロックか警告か・バイパストークン名
  2. 生成された .claude/hooks/ のシェルを読む——フェイルオープンがどこに入ったか
  3. .claude/settings.jsonPreToolUse(Bash) に配線する
  4. 手順2の squash 操作をもう一度実行 → 今度は止まる
確認できること
  • 事故が起きてからフックが動くまで何分だったか
  • 既存フックと同じ書式(exit 2 + 理由の提示)になっているか

この手順の目的は、フックを1本手に入れることではありません。 「事故が起きてから、再発防止が動き出すまでの時間」を自分で測ることにあります。

「事故から機械化まで同日〜翌日」という実測は、読むだけなら「よく頑張ったな」で終わります。 しかし自分でやってみると、根性の話ではないと分かります。 フックは条件を判定して止めるだけのシェルなので、依頼から動作確認までは短時間で終わります。だから事故の記憶が新しいうちに、その場で機械化できます。

依頼文に入れる3つ——検知する条件、止めるのか警告か、バイパスのトークン名と理由の記録——は、フック設計の3原則をそのまま依頼に落としたものです。

成功の判定は3点です。 生成されたシェルを読んで、フェイルオープンがどこに入ったかを指させること。 既存のフックと同じ書式(exit 2 と理由の提示)になっていること。 そして、配線したあとに同じ事故操作が止まること。

そのうえで経過時間を確認してください。それがこのプロジェクトの速さの正体です。

書き上がったフックが妥当かどうかは、実物と見比べるのが早いです。 この教材リポジトリで実際に動いているフック5本の全文をフックの実物に載せました。

つづく