「またこのミスやっちゃった」という経験は、誰にでもあります。気をつけているはずなのに同じ失敗が定期的に発生する、というのはエンジニアの日常です。
ただ、ミスを「気をつける」で乗り切ろうとしても、再発は止まりません。経験上、同じミスが繰り返されるのは個人の集中力の問題ではなく、分類の問題です。失敗を4種類に整理し、種類ごとに合った防止策を当てれば、再発は劇的に減ります。AI はこの分類作業の良き相棒になります。
なぜ「分類」が再発防止の鍵なのか
「気をつける」は対策にならない
再発防止策として「気をつけます」「次から注意します」が出てくる場合、その対策はほぼ確実に効きません。気をつけるだけで防げるミスなら、最初から起きていません。
「気をつける」が機能しない理由は、ミスの種類によって有効な対策が全く違うからです。チェックリストが効く失敗もあれば、ドキュメント整備が効く失敗もあり、アーキテクチャ変更でしか直らない失敗もあります。「気をつける」は最も効果の薄い対策の代表です。
分類精度が上がれば対策の精度も上がる
逆に、ミスを正しく分類できれば、対策は機械的に決まります。「ケアレスミスだからチェックリストを足す」「プロセス欠陥だから手順書を直す」のように、分類→対策のマッピングさえあれば、その場で迷わず動けます。
AI は分類作業に向いています。失敗の概要を渡すと、4分類のどれに該当するか、複数該当するならどの比重が大きいかを冷静に判断してくれます。自分一人で分類しようとすると「自分のせいにしすぎる」「逆に環境のせいにしすぎる」のバイアスがかかりがちです。
失敗の4分類
分類1: ケアレスミス（注意力の問題）
特徴: 知識も手順も理解しているが、その瞬間の集中力低下や思い込みで間違える。
典型例:
- リリース対象ブランチを取り違える
- 環境変数の設定漏れ
- コミット対象ファイルを誤る
- コピペ先を間違える
有効な対策: 機械的なチェックを入れる。人間の注意力に頼らない仕組み化。
- pre-commit hook で検査
- リリース前の自動 lint
- 「もう一度確認しますか？」のプロンプト
- 操作対象を視覚的にハイライトする UI
効かない対策: 「確認を徹底する」「気をつける」
分類2: 知識不足（理解の問題）
特徴: そもそも正しい方法を知らない。やり方を知らずに間違える。
典型例:
- 新しいライブラリの使い方を間違える
- 言語仕様の誤解（参照渡しと値渡しの混同など）
- 規約や規格の存在を知らない
- 過去の事例・前例を知らない
有効な対策: ドキュメント整備と学習機会。アクセス可能な情報源を増やす。
- CLAUDE.md やプロジェクト Wiki の整備
- AI に「この領域で気をつけるべきことを教えて」と相談
- 同じ失敗をした他者の事例を共有
- ライブラリのリファレンスを手元に置く
効かない対策: 「次は調べてからやります」だけ（情報源が整備されていなければ調べようがない）
分類3: プロセス欠陥（手順の問題）
特徴: 個人の知識・注意力ではなく、作業手順そのものに穴がある。誰がやっても同じ失敗が起きる構造。
典型例:
- リリース手順書の特定ステップが抜けている
- レビューフローに「○○を確認」のチェックがない
- デプロイ後の検証項目が定義されていない
- 引き継ぎテンプレートがなく、毎回情報が抜ける
有効な対策: 手順を変える。手順書、テンプレート、自動化スクリプトの追加・修正。
- 手順書のステップ追加
- レビューチェックリストの項目追加
- デプロイ後の自動検証スクリプト
- 引き継ぎテンプレートの整備
効かない対策: 個人への注意喚起、教育、根性論
分類4: 構造的バイアス（仕組みの問題）
特徴: 環境・組織・アーキテクチャそのものが、特定のミスを誘発する構造になっている。手順を変えても防げない。
典型例:
- 本番環境とステージング環境が見た目で区別できず、誤操作が起きる
- 似た名前のライブラリ・関数が併存し、混同が頻発
- 設定ファイルが10箇所に分散しており、整合性が取れない
- 緊急リリースが頻繁すぎて、通常の手順が守れない
有効な対策: アーキテクチャ・ガバナンスの変更。根本的な構造変更。
- 環境を視覚的に区別する（色・名前・URL）
- 紛らわしい命名のリネーム・統合
- 設定ファイルの集約
- 緊急リリースの頻度を減らすための上流対策
効かない対策: 個人努力、手順書追加、チェックリスト
4分類を AI に判定させる
プロンプト例
1以下の失敗事例について、4分類のどれに該当するか判定してください。2複数該当する場合は、主因と副因に分けてください。3
4【失敗の概要】5{何が起きたか・誰が・いつ・どんな結果になったか}6
7【経緯】8{どんな手順で進めて、どこで間違えたか}9
10【既存の対策】11{過去に取った再発防止策と、それでも再発した経緯}12
13【判定】141. 主因: {分類1-4のどれか}152. 副因: {あれば}3 collapsed lines
163. 主因の根拠: {なぜその分類か}174. 推奨対策: {分類に対応する対策の具体案}185. 効きにくい対策: {過去取られたが効かないだろう対策}「効きにくい対策」を出させるのが効きます。これがないと、過去にやって効かなかった対策をまた採用するリスクが残ります。
複数分類が混在する場合
実際の失敗は、4分類が混在することが多いです。例えば「リリース手順書の抜け（プロセス欠陥）+ レビュー時の見落とし（ケアレスミス）」のような複合パターンです。
このとき、主因に対する対策を最優先で打ちます。プロセス欠陥が主因なら手順書修正が一番効き、ケアレスミス対策（pre-commit hook 追加）は副次的に打ちます。逆順だと「手順書はそのままで pre-commit hook だけ追加」になり、再発を防ぎきれません。
実例：cherry-pick 反復失敗の分類
過去に何度かやらかした「cherry-pick 時に必要なコミットを取りこぼす」失敗を、4分類で整理してみました。
当初の対策: 「もっと確認します」（分類1の対策）→ 効かず再発
AIに分類させた結果:
- 主因: 分類3（プロセス欠陥）— cherry-pick 対象を機械的にリストアップする手順がなく、目視で選んでいた
- 副因: 分類1（ケアレスミス）— 候補が多いと見落としが発生
対応した対策:
- 主対策: cherry-pick 候補を
git log --no-merges --reverseで機械的にリストし、テンプレートに貼って差分確認する手順を導入 - 副対策: 該当ブランチへの cherry-pick 前後で
git log --onelineの比較を必須化
結果: 主対策（プロセス変更）導入後は再発ゼロ。「気をつける」だけで戦っていた頃の労力が嘘のようです。
エンジニアにとっての価値
1. 「自分のせいだ」と「環境のせいだ」の二択から抜け出せる
ミスが起きると、人は「自分が悪かった」か「環境が悪い」のどちらかに振れがちです。4分類はその中間を埋めるので、感情的にならずに対策を組めます。
2. 対策の費用対効果が読める
「pre-commit hook 追加（数時間）」「手順書修正（30分）」「アーキテクチャ変更（数週間）」は対策コストが全く違います。分類が正しければ、最小コストで最大効果の対策を選べます。
3. チームで失敗を共有しやすくなる
「これは分類3のプロセス欠陥です」と言えると、個人攻撃にならずにチームで対策を議論できます。失敗を共有する心理的ハードルが下がります。
落とし穴と対処
落とし穴1: 分類1（ケアレスミス）に逃げる
「ケアレスミスでした、次から気をつけます」は最も逃げやすい分類です。本当に分類1か、実は分類3（プロセス欠陥）ではないかを必ず疑います。同じケアレスミスが2回以上起きたら、それは分類3の可能性が高いです。
落とし穴2: 分類4（構造的バイアス）への対策を先送り
分類4の対策はコストが高いので「今回は分類1の対策だけで」と先送りしがちです。しかし構造的バイアスは放置すると再発し続けるので、優先順位を下げ続けると累積コストが膨らみます。年に1度は分類4の見直しを入れるのが目安です。
落とし穴3: AI の分類を鵜呑みにする
AI は分類作業が得意ですが、現場の文脈は知りません。「組織的に手順書修正が通らない」「アーキテクチャ変更は予算が下りない」などの制約は、人間が補足する必要があります。AI の分類は出発点であって、最終判断ではありません。
落とし穴4: 対策を打ったら振り返らない
対策を打って終わりにすると、効果が出ているか分かりません。対策後3ヶ月で再発回数を確認し、減っていなければ分類が間違っていた可能性を検討します。
適用範囲
この分類が効くシーン：
- 同じミスが繰り返されている全ての場面
- ポストモーテムの作成
- チーム内での失敗共有
- 個人の振り返り
- 新人メンバーへの再発防止教育
効きにくいシーン：
- 一回限りの偶発事象（再発がないなら分類自体が不要）
- 緊急対応中（事後で良い）
- 完全な未知領域での試行錯誤（そもそも「正解」がない）
まとめ
| 分類 | 特徴 | 有効な対策 | 効かない対策 |
|---|---|---|---|
| 1. ケアレスミス | 注意力の問題 | 機械的チェック・hook | 「気をつける」 |
| 2. 知識不足 | 理解の問題 | ドキュメント・学習 | 注意喚起だけ |
| 3. プロセス欠陥 | 手順の問題 | 手順書・テンプレ修正 | 個人教育 |
| 4. 構造的バイアス | 仕組みの問題 | アーキテクチャ変更 | 手順書追加 |
「同じミスを繰り返す」のは個人の問題ではなく分類の問題です。分類精度が上がれば防止策の精度も上がります。AI は分類作業の良き相棒になり、感情的にならずに対策を組めます。「気をつけます」を卒業して、構造で再発を止めるアプローチに切り替えると、同じ失敗に消耗する時間が大きく減ります。