配布資料の目次 › 失敗事例カード
配布資料 40失敗事例カード集
実際に起きた事故を12件、カードにしました。
どれも格好はつきません。DB を消し、コードを消し、バックアップは19日間止まっていました。 ただ、その一つ一つがルールになりフックになったので、そこまで含めて残してあります。
各カードは「何が起きたか → なぜ起きたのか → そこから生まれたルール → どう機械に守らせたか → 持ち帰るなら」の順で書きました。 自分のプロジェクトで一番起こりそうなものから読んでいただくのがいいと思います。
恐らくここに辿り着いた方の中には、私と同じような暗中模索を繰り返されている方もいるのではないかと思います。 以下の多くは、AI駆動開発を始めると高確率で踏む地雷です。
カード一覧
| # | 事例 | 出てくる部 | 強制の方式 |
|---|---|---|---|
| 01 | ツール呼び出し書式ミスで AI の作業が停止し続けた | 4 | 三層 hook |
| 02 | プロジェクト記憶の引き継ぎが静かに取りこぼされ続けた | 4 | git hook 4種 + 専用同期スクリプト |
| 03 | デプロイ乱発で CI 無料枠が枯渇し自動化が全停止した | 5 | 4時間レートリミット hook |
| 04 | スキーマ比較コマンドの誤用で開発 DB が全消去された | 3 | 運用ルール + 鮮度監視 |
| 05 | スカッシュマージで実装済みコードが静かに消えた | 3 | 規約 + マージ hook 案内 |
| 06 | 検証スキップと早期 Done が積み重なり信頼を毀損した | 3 | コミット/マージ/Done の三重ゲート |
| 07 | 文書の古い金額を信じて金銭の事実を誤説明した | 2 | 運用ルール（live 値裏取り） |
| 08 | CSS だけの監査が同じ漏れを2回すり抜けさせた | 3 | コミット境界の混入検知 hook |
| 09 | タイムゾーンのない timestamp が集計を9時間ずらした | 3 | 運用ルール（NG/OK 例） |
| 10 | SSH 切断がデプロイとその監視を沈黙させた | 5 | スクリプト構造対策 + リマインド hook |
| 11 | 否定された設計案を AI が何度でも再提案した | 2 | 絶対禁止リスト + 自動ロード + レビュー観点 |
| 12 | 「小さな変更」と承認したはずが実測で別物になった | 2 | 運用ルール（tsc 実測の明記義務） |
12件を貫く型
再発防止の型は、どれも三段でした。
①事故をイシューに記録する → ②ルールとして条文化する → ③可能ならフックで機械的に強制する。
ただし、③まで行けない失敗があります。 04・07・09 のような「判断の質」の問題は、フックでは止められません。 こちらは規約の明文化と、セッション開始時の規律注入で在中させるしかありません。
読むときは、「この失敗はフックで止まるか、止まらないか」を分類しながら読んでみてください。 その分類がそのまま、自分のプロジェクトに何を仕込むかの設計になります。
余談 — モデルの世代が上がれば踏まずに済む地雷もある
正直に書いておきます。
ここにある12件は、当時使っていたモデルと当時の環境で実際に起きたことです。 そのうち何件かは、今のモデルなら踏みません。
たとえば事例 #01 のツール呼び出し書式ミスは、かなりモデル世代に依存した失敗でした。 新しい世代では、あの書式崩れ自体をほとんど見なくなっています。 見積もりを印象で答える癖（#12）や、否定した案に戻ってくる癖（#11）も、世代が上がるほど軽くなっている実感があります。
なので「12件全部にフックを書け」とは言いません。 自分の環境で実際に踏んだものから1本ずつ増やしてください。踏んでいない地雷の対策は、たいてい形骸化します。
ただし、世代が上がっても消えない種類があります。
DB を消したコマンド（#04）も、19日間死んでいたバックアップ（#04）も、履歴を潰すマージ（#05）も、 モデルが賢くなったから起きない、という性質のものではありません。 ツールの仕様と、人間側の運用の問題だからです。 「完了」の定義が滑る（#06）のも、証拠を要求する側が決めることなので、モデルの性能とは別の話になります。
読むときの目安はこう考えています。
AI の出力の癖に起因する失敗は、世代とともに減ります。 仕組みと権限の設計に起因する失敗は、減りません。
後者にだけフックを書けば、たぶん3本で足ります。