AI変更のChange Failure Rateをどう測るか：リリース速度と事故率を両立する指標設計

TL;DR

• AI導入後は変更量が増えるぶん、事故率の定義を先に固定する必要がある
• Change Failure Rate は「障害件数」だけでなく「切り戻し」「緊急修正」も含めて設計する
• 指標はチームを責めるためではなく、レビュー強度を調整するために使う

はじめに

AI生成コードがチームの変更量に占める割合は、この1年で急速に増えている。GitHub Copilot やカスタムエージェントが日常的にPRを出すようになると、リリース回数は自然に増加する。しかし「速くなった」だけでは価値を証明できない。事故を起こさずに速度を維持できているかを示す指標が必要になる。

この記事では、DORA Four Keysの1つである Change Failure Rate（CFR） を、AI生成変更を含むチームでどう定義・計測・運用するかを整理する。

:::message DORA指標をそのまま持ち込むのではなく、自チームの事故定義を合わせるところから始めるのがポイントだ。生産性指標全般の選び方は開発生産性指標の歩き方で詳しく解説している。 :::

1. 事故をどう定義するか

Change Failure Rateを測る前に、「何をfailureとカウントするか」をチームで合意する必要がある。DORAの原典では「サービスの低下やサービス停止を引き起こし、修正が必要な変更の割合」と定義されている。しかしAI生成変更を含む開発では、この定義だけでは曖昧さが残る。

failureの3分類

実務上、failureは以下の3つに分類すると計測しやすい。

この3分類を使うと「障害は出なかったが切り戻した」ケースも漏れなく拾える。AI生成変更は個々の変更が小粒になりやすいため、Incident だけを数えると実態より低い数値が出やすい点に注意が必要だ。

境界条件：何をカウントしないか

• テスト環境だけで検出し、本番に出なかった不具合はカウントしない
• 意図的なフィーチャーフラグの切り替えはカウントしない
• 依存ライブラリの脆弱性パッチ適用で機能影響がなかった場合はカウントしない

この境界条件をドキュメントに書いておくだけで、計測担当者間のブレが大きく減る。

2. 速度と品質をどう両立するか

AI導入でデプロイ頻度が上がったチームが陥りやすい罠は、CFRの分母（総変更数）が急増して分子（failure数）も比例的に増えるのに、率だけ見て「横ばいだから問題ない」と判断してしまう ことだ。

リスクスコアとレビュー強度の連動

すべての変更に同じレビュー負荷をかけるのは非現実的だ。変更ごとにリスクスコアを付け、スコアに応じてレビュー強度を変える設計が効果的になる。

// リスクスコアに応じたレビュー強度の割り当て
type RiskLevel = 'low' | 'medium' | 'high'

const reviewPolicy: Record<RiskLevel, { autoMerge: boolean; reviewers: number }> = {
  low:    { autoMerge: true,  reviewers: 0 },
  medium: { autoMerge: false, reviewers: 1 },
  high:   { autoMerge: false, reviewers: 2 },
}

このリスクベースの振り分けを自動化する方法はAI生成PRの品質ゲートを自動化するで詳しく解説している。また、リスク判定基準そのものの設計はリスクベースリリース運用が参考になる。

CFRの計測式

計測式はシンプルに保つ。

CFR = (Incident + Rollback + Hotfix) / 総デプロイ数 × 100

週次で計測し、4週移動平均で傾向を見るのが実用的だ。短期の変動に一喜一憂せず、トレンドの変化をキャッチするために移動平均を使う。

3. ダッシュボード運用の落とし穴

CFRをダッシュボードに載せて「見える化」するチームは増えているが、運用を誤ると逆効果になる。よくある3つの落とし穴を挙げる。

落とし穴1：数値の一人歩き

CFRが上がったとき「誰のせいか」を探す文化ができると、チームは変更を避けるようになる。指標は個人を責めるためではなく、レビュー強度やテスト戦略を調整するためのシグナル として使うべきだ。

落とし穴2：分母の定義ブレ

「1 PR = 1デプロイ」なのか「1回のデプロイパイプライン実行 = 1デプロイ」なのかで数値は大きく変わる。CI/CDパイプラインの構成と合わせて定義を統一する必要がある。パイプラインの最適化についてはCIが遅い原因を分解するも参照してほしい。

落とし穴3：CFR単独での判断

CFRだけを見ていると「変更しなければ事故は起きない」という誤った方向に進む。デプロイ頻度・リードタイム・MTTRと組み合わせて4指標をセットで見ることが重要だ。KPI同士の関係性と学習ループの回し方はAI開発KPIと学習ループで体系的に整理している。

まとめ

CFRをAI時代のチームで活用するためのステップは3つだ。

1. failureの定義を揃える -- 障害・切り戻し・緊急修正の3分類をチームで合意する
2. リスクベースでレビュー強度を変える -- すべてのPRに同じ工数をかけない
3. 4指標セットでトレンドを追う -- CFR単独で判断しない

まずは「何をfailureと呼ぶか」の定義をチームで1回揃えるところから始めてほしい。定義が決まれば計測は自動化できるし、計測できれば改善サイクルが回る。