変更障害率（Change failure rate）とは、本番環境へのデプロイのうち、直後に障害や緊急対応を引き起こしたものの割合です。 変更失敗率とも訳されます。 DORA（Google Cloud の研究チーム）が提唱する開発生産性指標「Four Keys」の一つで、デプロイ頻度や変更のリードタイムが「届ける速さ」を測るのに対し、この指標はデリバリの「壊れにくさ」を測ります。 この記事では、定義と測り方、速さとのトレードオフが成り立たない理由、下げるための打ち手を整理します。
変更障害率とは何か
DORA の現行定義は「デプロイのうち、直後に即時対応が必要になったものの比率」です。 即時対応とは、ロールバック、緊急修正のデプロイ、パッチの適用などを指します。 10回デプロイして2回ロールバックしたなら、変更障害率は20%です。
対象は、デプロイに起因する失敗に限られます。 インフラの故障や外部サービス起因の障害は、この指標には含めません。 自分たちが本番に加えた変更のうち、何割が問題を起こしたかを測る指標だからです。
現在の DORA はこの指標のカテゴリを不安定性（Instability）と呼びます。 かつては安定性（Stability）という名前でした。 この改名は指標の読み方への注意書きとして機能しています。 不安定性の指標は異常を検知するためのもので、低いことは健全さの証明になりません。 極端な話、デプロイをほとんどしていなければ失敗率はゼロに近づきます。
速さと品質はトレードオフではない
「デプロイを速く頻繁にすれば、その分壊れやすくなる」というのが通説的な感覚です。 DORA の調査はこの見方を繰り返し否定しており、スループットが高いチームは変更障害率も低い傾向が確認されています。
両立が起きる機構はこうです。 高頻度デプロイの前提となる変更の小口化は、1回のデプロイに載る変更を減らし、1回あたりの失敗確率と影響範囲を下げます。 同じく前提となるテストの自動化は、失敗が本番に届く前に検出される割合を上げます。 速さと壊れにくさは、どちらも「自動化されたパイプラインと小さな変更」という同じ能力から出てくる2つの出力です。
この機構を裏返すと、「品質を守るためにリリース回数を減らす」という対応がたいてい逆効果になる理由も分かります。 リリースを減らすと1回に載る変更が膨らみ、失敗の確率も影響範囲も大きくなるからです。
デプロイ手戻り率との違い
DORA には、2024年に加わったデプロイ手戻り率（本番障害の結果として発生した計画外デプロイの比率）という近い指標があります。 変更障害率が捉えるのは、デプロイ直後に発覚する目立つ失敗です。 一方、手戻り率は、数日後にひっそり修正デプロイが打たれるような静かな後始末まで拾います。 変更障害率が健全なのに手戻り率が上がっているなら、小さな問題がレビューをすり抜けて本番に出ているサインです。 両者の関係と手戻り率の測り方は、Four Keys の2026年版の解説記事で詳しく扱っています。
測り方
分母は本番デプロイの回数、分子は即時対応が必要になったデプロイの数です。 難しいのは分子で、「どのデプロイが失敗だったか」の判定は自動化しにくい部分です。 インシデントの記録とデプロイ履歴を突き合わせる仕組みが要るためです。
現実的には、失敗の定義を機械的に判定できる条件としてチームで先に決めておきます。
- 失敗と数える条件の例：ロールバックを実施した、24時間以内に緊急修正をデプロイした、デプロイ起因のインシデントを起票した
- 集計：週次の振り返りで該当デプロイを数えるだけでも運用できる。デプロイ時に「計画どおり／緊急対応」のフラグを付けておくと集計が楽になる
定義を決めずに測り始めると、担当者の裁量で失敗の判定が揺れ、数字の連続性が失われます。
下げ方
変更障害率を下げる打ち手は、失敗を減らす方向と、失敗を軽くする方向の2系統に分かれます。
- テストの自動化：失敗を本番の手前で検出する土台。AI活用を進める場合は特に、この土台が先になる（AI開発とテスト基盤の記事で詳しく書いています）
- デプロイの小口化：1回あたりの失敗確率と影響範囲を下げる
- フィーチャーフラグと段階的リリース：問題があっても影響を一部のユーザーに限定し、全体障害になる前に戻せるようにする
- ロールバック手順の整備：失敗しても短時間で戻せるなら、失敗のコストそのものが下がる
注意点
変更障害率は、ゼロを目指す指標ではありません。 ゼロが続いているなら、挑戦的な変更をしていないか、デプロイが少なすぎるか、失敗を数えていないかのどれかを疑うほうが健全です。
評価指標にすると、障害を起票しない動機や、失敗の定義を甘くする動機が生まれ、数字の信頼性そのものが失われます。 また、かつて使われた「0〜15%なら Elite」といった水準表は、ランク分けの廃止に伴い現在は使えません。 比較の相手は自チームの過去に置き、スループット系の指標と対で傾向を見てください。
関連して読める記事
変更障害率は、スループット系の指標と対で見て初めて意味を持ちます。枠組みの現行定義から押さえたい方は、2026年版の解説からどうぞ。
Four Keys はもう「4つ」ではない — 2026年版 DORA メトリクスの現在地と、AI導入の効果を証明する唯一の方法
「Four Keys は4つ」という理解は2026年時点では古く、DORA公式の指標は5つに増え、Elite/High/Medium/Lowのランク分けも廃止されています。5つ目は広く誤解されている「信頼性」ではなくデプロイ手戻り率であること、Googleのfourkeys OSSがアーカイブ済みで主要ツールもいまだ4指標止まりであること、そして手戻り率だけはツールなしで今日から測れることを、DORA公式ドキュメントで裏を取りながら整理します。AI導入の効果を数字で証明するための使い方までまとめました。
2026年7月27日
開発生産性とは？測り方の全体像と、指標選びで失敗しない考え方
開発生産性とは、開発組織が投入した人と時間に対して、どれだけ速く確実に価値のあるソフトウェアを届けられているかを表す概念です。行数計測が失敗する理由、Four Keys、SPACE、DevExの使い分け、測り始める5つの手順、指標を個人評価に使ってはいけない理由までを総論として整理します。
2026年7月28日
デプロイ頻度とは？DORAが定義する測り方と、頻度が高いほど安全になる理由
デプロイ頻度とは、開発チームが本番環境へどれくらいの頻度でリリースしているかを測るDORAのFour Keys指標です。定義と測り方、頻度が高いほどデプロイが安全になる理由、ランク分け廃止後の正しい比較のしかた、目標化してはいけない理由までを整理します。
2026年7月28日
変更のリードタイムとは？コミットから本番までを測るDORA指標と短縮の順序
変更のリードタイムとは、コミットから本番デプロイまでの時間を測るDORAのFour Keys指標です。なぜ起点が企画ではなくコミットなのか、レビュー待ちとデプロイ待ちに分解する見方、中央値で測る理由、短縮に取り組む順序までを実務目線で整理します。
2026年7月28日
MTTRとは？定義の揺れ、DORA指標としての現在地、平均の罠
MTTRとは、障害発生から復旧までの平均時間を指す指標ですが、Rの解釈が複数あり、DORAは現在この名前を使っていません。定義の揺れ、失敗デプロイの復旧時間への置き換え、平均値が実態を表さない統計上の罠、復旧を速くする打ち手までを整理します。
2026年7月28日