AI開発プロジェクトのポストモーテム設計｜ブレームレス根本原因分析・再発防止の3段階設計・学びを組織知にするナレッジ共有の型【2026年版】

「次から注意します」を組織から根絶する——ポストモーテムの設計

障害が発生した。原因を特定し、修正した。そして「次から注意します」で終わる——この対応は禁止です。3日徹夜している状態でも同じミスをしない体制を作ることが、ポストモーテムの本質です。

Googleが提唱した「ブレームレスポストモーテム」は、個人を責めるのではなくシステムの弱点を発見する文化です。本記事では、AI開発プロジェクトにおけるポストモーテムの設計と、学びを組織知にする仕組みを解説します。

ポストモーテムの5セクション構成

1. サマリー（何が起きたか・影響範囲・対応時間）
2. タイムライン（発生→検知→対応→復旧の時系列）
3. 根本原因分析（なぜ起きたか・5 Whys）
4. 再発防止策（仕組みで防ぐ具体的なアクション）
5. 学びの共有（組織として何を学んだか）

根本原因分析の実践

多層防御で考える

障害の根本原因は1つではありません。複数の防御層が全て突破された結果として障害が発生します。

実例：不要ファイル混入事故

現象：VM上のUIにMac自動生成メタデータファイルが表示された
直接原因：FEのスキャンロジックが._ファイルをフィルタしていなかった
深層原因：BEのscan APIにも入力バリデーションがなかった
根本原因：FE→BE→DBの経路に多層防御が設計されていなかった

再発防止策（3層）：
A. FE側：スキャン時に._ファイルを除外するフィルタ追加（根本対応）
B. BE側：scan APIで._始まりのターゲットを弾くバリデーション追加（防御的対応）
C. 両方修正で多層防御を実現

5 Whysで掘り下げる

Why 1: なぜUIに不要ファイルが表示された？
  → DBに._ファイルが登録されていたから

Why 2: なぜDBに登録された？
  → BEのscan APIがフィルタなしで受け入れたから

Why 3: なぜBEにフィルタがなかった？
  → FE側でフィルタする前提だったから

Why 4: なぜFEにもフィルタがなかった？
  → Macの._ファイルを想定していなかったから

Why 5: なぜ想定されていなかった？
  → 開発環境と本番環境のOS差異をテストケースに含めていなかったから

再発防止策の3段階設計

段階	手法	例
検出	自動テスト・監視・アラート	CIに._ファイル混入チェックを追加
防止	入力バリデーション・型制約・CIガード	FE/BE両方でフィルタ（多層防御）
回復	ロールバック手順・バックアップ	DBレコード一括削除スクリプト

「注意する」はどの段階にも該当しません。意志の力に頼る対策は再発防止策ではありません。

ブレームレス文化の実践

「誰が」ではなく「何が」を問う

• ❌「誰がこのコードをマージしたのか」
• ✅「なぜこのコードがレビューを通過したのか」

• ❌「なぜ確認しなかったのか」
• ✅「確認する仕組みがなぜ存在しなかったのか」

ブレームレスは「責任を問わない」という意味ではありません。システムの弱点を特定し、仕組みで防ぐことに焦点を当てるということです。

心理的安全性の確保

エスカレーションの恐怖を取り除くことが重要です。「頑張りすぎ」が原因のミスなら組織が守ります。問題を隠すことこそが最大のリスクです。

AI開発プロジェクト特有の障害パターン

パターン	根本原因	再発防止策
Prisma/Alembicスキーマ衝突	DDL管理が一本化されていない	マイグレーション封印+CIガード
.envファイルの平文露出	CLAUDE.mdにガードレールがない	セキュリティセクション追加
誤デプロイ（int2環境）	デプロイ先制約が未定義	CLAUDE.mdにデプロイ先を明記
DNS解決失敗（NXDOMAIN）	プライベートDNSゾーン未リンク	インフラ設定チェックリスト
ディスク容量不足でpull失敗	旧イメージの蓄積	デプロイ前にprune+容量確認
.gitignoreで必要ファイル除外	パターンが広すぎる	除外ルールのレビュー+CI型チェック

学びを組織知にする仕組み

ポストモーテムリポジトリの運用

1. 全ポストモーテムを1箇所に集約：Notion、Wiki、Gitリポジトリ等
2. 検索可能にする：タグ・カテゴリで分類（インフラ/アプリ/データ/セキュリティ）
3. 新人オンボーディングに組み込む：過去の障害事例を学習教材として活用
4. 四半期で振り返る：同じパターンの障害が再発していないか確認

AIでポストモーテムを効率化

• タイムライン自動生成：Slackログ・Gitコミット・デプロイログからAIが時系列を構築
• 類似障害の検索：過去のポストモーテムから類似パターンを自動検出
• 再発防止策の提案：障害パターンに基づくCIガード・テスト追加の提案

まとめ：ポストモーテム実施チェックリスト

タイミング	チェック項目
障害発生直後	復旧を最優先し、詳細調査は後回しにしたか
復旧後24時間以内	タイムラインを記録したか（記憶が新鮮なうちに）
ポストモーテム会議	ブレームレスの原則を冒頭で宣言したか
ポストモーテム会議	5 Whysで根本原因を特定したか
再発防止策	「注意する」以外の仕組みによる対策を設計したか
再発防止策	検出・防止・回復の3段階で設計したか
共有	ポストモーテムをリポジトリに追加したか
フォローアップ	再発防止策の実施状況を追跡しているか

ポストモーテムは「反省会」ではなく「組織の免疫システム」です。障害から学び、仕組みで防ぎ、その知識を組織全体で共有する——この循環が、チームの耐障害性を継続的に高めます。

関連記事

• エンジニアのデバッグ思考法
• デプロイ障害の6ステージ切り分け
• リスクマネジメント実践ガイド

AI開発の品質管理はrenueにご相談ください。