TL;DR
- AI コーディング導入後の Change Failure Rate（CFR）は、「AI が増やす失敗」「観測されにくい失敗」「人間レビューが追いつかない失敗」 の 3 因子で膨らみやすい（経験則）。
- DORA 公式定義（production deployment のうち remediation が必要だった割合）はそのまま使えるが、AI-augmented vs human-authored を分離して計測しないと打ち手が見えない[公式値]。
- 本記事は再定義の 4 ステップ（除外条件・粒度・観測点・閾値）と、6 ヶ月で取るべき意思決定を Tech Lead / EM 向けに整理する。
はじめに
DORA の Change Failure Rate（CFR）は「production に deploy された変更のうち、サービス劣化を引き起こし remediation（hotfix / rollback / fix forward / patch）が必要になった割合」と Google 公式が定義しています[公式値]（DORA Metrics 公式ガイド）。2025 DORA Survey では 0-2% が high performer の閾値で、これは AI コーディング以前から大きくは変わっていません[公式値]。
ところが 2026 年中頃の現場では、91% の開発者が AI を採用、merged code の 20% 超が AI-authored という状況で[公式値]（GetDX - Measuring CFR in the era of AI-assisted engineering）、CFR の数字が「ツールではなく組織の問題なのか、AI 起因なのか」を切り分けられない事案が増えています。本記事は、CFR を 再定義 4 ステップ で AI コーディング時代の実務に戻すためのガイドです。
DORA / SPACE / DevEx の比較選定は DORAとSPACEの選び方、入門的な指標選定は 開発生産性指標の歩き方 を参照してください。
1. なぜ既存 CFR 定義は AI コーディングで歪むか
3 因子で歪みます（経験則）。
因子 1: AI が増やす失敗
AI 生成コードは小規模変更が多く、人間レビューが「ざっと見て LGTM」になりやすい。結果、AI-augmented PR の方が rollback 率が高くなる傾向があります（GetDX 報告）。本記事の経験則ベースでは、AI-augmented PR は human-authored PR より rollback 率が 1.5-2 倍高いケースが少なくありません（経験則・5〜30 名規模で観測）。
因子 2: 観測されにくい失敗
AI は型エラー・テスト失敗を回避するためにテストごと修正することがあります。これは「テストは通るが期待と違う実装」を生み、運用で初めて発覚する failure を増やします。具体的なアンチパターンは 仕様駆動開発の落とし穴と対策 のパターン 2（受入条件の後付け）と整合します。
因子 3: 人間レビューが追いつかない失敗
AI で PR 数が 1.5-3 倍に増えると、レビュー遅延が CFR の隠れたドライバになります。レビュー運用の設計は AI時代のレビュー運用設計、オンコール疲弊との連動は オンコール疲弊を防ぐ運用設計 を参照。
2. CFR を再定義する 4 ステップ
公式値を尊重しつつ、AI 時代の実務に戻すためのフレームです。
Step 1: 除外条件を明文化する
CFR 公式定義は「production deployment」が前提ですが、何を deployment と数えるかでブレます。
- 含む: production への merge、Feature Flag の本番 rollout、緊急 hotfix
- 除く: staging-only deploy、canary（最小 traffic）、internal-only リリース、設定変更のみ
- 除外要件: 各除外条件は ADR / Runbook で明文化し、6 ヶ月ごとに見直し
Step 2: 粒度を「PR 単位 + AI/human ラベル」に分ける
DORA 公式の CFR 計算式は変えず、ラベル分離だけ追加します[公式値]。
CFR = (failed deployments / total deployments) × 100
派生指標:
CFR_ai = (ai-augmented failed / ai-augmented total) × 100
CFR_human = (human-only failed / human-only total) × 100
ΔCFR_ai = CFR_ai - CFR_human
ΔCFR_ai > 0 が継続するなら、AI 起因の failure が組織全体の CFR を押し上げています。閾値は経験則で ΔCFR_ai が 1.0 ポイント以上 が改善対象。
Step 3: 観測点を「PR ラベル + commit metadata + CI シグナル」の 3 系統で取る
ラベルだけでは漏れます。3 系統を組み合わせます（経験則）。
- PR ラベル:
ai-generated/ai-augmented/human-onlyを Issue/PR テンプレで強制 - Commit metadata:
Co-Authored-By: Claude/Co-Authored-By: Codex等を機械抽出 - CI シグナル: GitHub Actions ワークフローで自動付与（GitHub Agentic Workflow と CI/CD を参照）
3 系統の OR 条件で「AI-augmented」と判定するのが現実解。
Step 4: 閾値を 4 段階で設計する
- Tier A（0-2%）: high performer、現状維持
- Tier B（2-5%）: 改善対象、
ΔCFR_aiで AI/human を切り分けて打ち手選定 - Tier C（5-10%）: 緊急改善、AI レビュー強化（Claude Code hooks の実践パターン集 の deterministic 制御を導入）
- Tier D（10%超）: 一時的な AI 採用ペースダウン、Issue テンプレ + 受入条件の整備（仕様駆動開発の落とし穴と対策）
旧定義との切り替え条件
AI-authored ratio が 15% を超えたら本フレームへ移行（経験則）。それ未満なら DORA 公式定義のままで充分です。
3. DORA / SPACE との接続
CFR は DORA 5 指標のうち Instability 軸に属します（2024 年に Deployment Rework Rate が追加された 5 指標モデル）[公式値]（DORA Insights - Metrics history）。AI 時代に CFR を再定義するなら、SPACE の 5 次元と組み合わせて多次元で見るのが定石です。
| 軸 | 補完する指標 |
|---|---|
| DORA Instability | CFR / Deployment Rework Rate |
| DORA Throughput | Deployment Frequency / Change Lead Time / Failed Deployment Recovery Time |
| SPACE Performance | 品質欠陥数 / 顧客クレーム数 |
| SPACE Satisfaction | レビュー疲弊 / オンコール負荷 |
詳細は DORAとSPACEの選び方 と 開発生産性指標の歩き方 を参照。
4. 観測実装：3 つのレイヤー
4.1 PR レイヤー
GitHub Issue/PR テンプレに以下を追加（GitHub Agentic Workflow と CI/CD を参照）。
## AI/Human 分類（必須）
- [ ] human-only（AI 補助なし）
- [ ] ai-augmented（部分的 AI 補助）
- [ ] ai-generated（主体的 AI 生成）
4.2 Commit レイヤー
Co-Authored-By: Claude / Codex / Cursor / Copilot 等を機械抽出。例:
git log --since="30 days ago" --grep="Co-Authored-By: Claude" --pretty=oneline | wc -l
4.3 CI レイヤー
GitHub Actions ワークフローで自動ラベリング + メトリクス収集。観測基盤の設計は AIエージェントの可観測性と障害解析 を参照。
5. 6 ヶ月で取るべき意思決定
Month 1-2: 計測基盤を立ち上げる
- 除外条件 ADR を 1 本書く
- PR テンプレに AI/human ラベルを追加
- 1 ヶ月分のベースラインを取得（CFR / ΔCFR_ai）
Month 3-4: ΔCFR_ai を縮める打ち手
- AI レビュー強化（hooks deterministic 制御 / SDD pitfall パターン 2 対策）
- Issue テンプレ + 受入条件強化
- レビュー運用見直し（AI時代のレビュー運用設計）
Month 5-6: 組織展開と再評価
- 全チームへ標準化
- 6 ヶ月後の CFR / ΔCFR_ai を再測
- AI 採用ペースの見直し判断
FAQ
Q1. CFR と Defect Density はどう使い分けますか？
CFR は production deployment の failure 率、Defect Density は コードベースあたりの欠陥数で対象が異なります（DORA Metrics 公式ガイド）。CFR は SRE/Platform 側、Defect Density は QA 側の指標として並走させるのが現実解（経験則）。
Q2. AI-authored の判定はどこまで厳密にすべきですか？
OR 条件で運用するのが現実解（経験則）。3 系統（PR ラベル / commit metadata / CI シグナル）のいずれかでも match すれば AI-augmented として扱います。厳密性より 計測の継続性 が優先で、6 ヶ月運用してから精度を見直すのが定着しやすいです。
Q3. 高 CFR を AI のせいにするのは妥当ですか？
ΔCFR_ai を 3 ヶ月以上計測してからしか妥当性を主張できません（経験則）。1 ヶ月のスナップショットでは有意差が出にくく、組織側の運用設計（レビュー / オンコール / SDD）が原因の方が多いケースもあります。詳細は 仕様駆動開発の落とし穴と対策。
Q4. CFR が下がらない場合、最初に見直すべきは何ですか？
レビュー運用です（経験則）。AI 出力品質より レビューゲート設計 の方が CFR への寄与が大きい場合が多く、AI時代のレビュー運用設計 と Claude Code hooks の実践パターン集 で deterministic 制御の導入を検討します。
Q5. 経営層への説明はどう組み立てればよいですか？
DORA 5 指標 + ΔCFR_ai の組み合わせで、業界比 + 自社推移 + AI 起因の切り分けを 1 ページで提示するのが効きます（経験則）。詳細は DORAとSPACEの選び方 のロードマップを参照。
References
- DORA Metrics 公式ガイド — CFR を含む 5 指標モデルの公式定義
- DORA Insights - Metrics history — Deployment Rework Rate 追加の経緯
- State of AI-assisted Software Development 2025 — AI 時代の DORA 最新年次レポート
- GetDX - Measuring CFR in the era of AI-assisted engineering — AI 時代の CFR 計測実務
- Atlassian - DORA Metrics — CFR の Atlassian 公式解説
- Apache DevLake - CFR Metrics — オープンソース実装
