Four Keys はもう「4つ」ではない — 2026年版 DORA メトリクスの現在地と、AI導入の効果を証明する唯一の方法

こんにちは、大平です。

技術顧問として入った先で「開発生産性は Four Keys で見ています」と言われることが増えました。いい傾向だと思って中身を確認すると、ほぼ例外なく2019年頃の定義で止まっています。

その間に、DORA 側は静かに、しかし大きく定義を動かしていました。指標は4つから5つに増え、カテゴリ名は変わり、長年使われてきた Elite / High / Medium / Low のランク分けは廃止され、Google が公開していたオープンソース実装はアーカイブされています。日本語の解説記事の大半が、この変更に追いついていません。

この記事では、2026年7月時点の Four Keys の現行定義を、DORA 公式ドキュメントで裏を取りながら整理します。あわせて「では何で測るのか」というツールの現在地と、AI導入の効果を数字で証明するための使い方までまとめました。開発組織の数字を経営会議に載せている方、これから載せようとしている方に向けた保存版のつもりで書いています。

「Four Keys は4つ」で止まったまま使われている

まず現状認識から。この指標に対する理解は、いま3つの層に割れています。

1. いまだに4つだと思っている — 圧倒的多数
2. 5つ目は「信頼性」だと思っている — 2021年のレポートを読んだ層
3. 現行の5つ目が「デプロイ手戻り率」だと知っている — ごく少数

厄介なのは、2番目の層が「自分は最新版を知っている」と認識していることです。後述しますが、この理解は DORA 自身が公式に撤回しています。

なぜこれだけズレるのか。理由は単純で、日本語の解説記事の多くが2019〜2021年に書かれ、その後更新されていないからです。検索して上位に出てくる記事が古い定義を説明し、それを読んだ人が社内資料を作り、その資料が数年間使われ続ける。定義が古いこと自体は罪ではありませんが、「うちは Elite 相当です」のように、すでに存在しない基準で経営に報告してしまうのは問題です。

現行の定義 — 2026年7月時点で、指標は5つある

DORA 公式ガイド（dora.dev/guides/dora-metrics-four-keys）に記載されている現行の定義は以下のとおりです。

5つ目として2024年に加わったのがデプロイ手戻り率です。計画外デプロイを全デプロイで割った値で、10回のデプロイのうち3回が障害対応の緊急デプロイなら30%になります。

意味するところは、「予定していた開発ではなく、火消しに使われたデプロイの割合」です。開発チームの時間がどれだけ計画外の後始末に吸われているかが、そのまま数字で出ます。経営から見れば、投じた開発費のうち何割が「作る」ではなく「直す」に消えているかの指標として読めます。

「5つ目は信頼性」は、DORA 自身が撤回した誤りである

ここが最も誤解されている論点です。

2021年の State of DevOps Report は、実際に「reliability（信頼性）」を5つ目の指標として提示しました。だから当時これを読んだ層は「Four Keys は5つになった、5つ目は信頼性だ」と理解しています。この記憶自体は間違っていません。当時のレポートに、確かにそう書いてあったからです。

しかし DORA は後に、公式の metrics history ページでこれを明確に否定しています。

The 2021 report inaccurately called the "reliability" metric the "fifth metric" when, in reality, "reliability" is more a measure of operational performance than a measure of software delivery performance.

（A history of DORA's software delivery metrics）

「2021年のレポートは、信頼性を『5つ目の指標』と呼んだが、それは不正確だった」と自ら認めています。理由は測っている軸が違うからです。信頼性は運用性能の指標であって、Four Keys が対象としているソフトウェアデリバリ性能ではない。同じ土俵に乗せてはいけないものを乗せてしまった、という訂正です。

誤解のないように補足すると、これは「信頼性を測るな」という話ではありません。可用性やレイテンシは当然重要で、SLO として別に管理すべきものです。Four Keys という枠組みの中の5つ目ではない、というだけの整理です。デリバリ性能側の5つ目として2024年に入ったのが、前節の手戻り率になります。

カテゴリ名が Stability から Instability に変わった意味

もうひとつ、静かですが重要な変更があります。後半2指標のカテゴリ名が「安定性（Stability）」から「不安定性（Instability）」に変わりました。

単なる言い換えに見えますが、指標の読み方そのものへの注意書きとして機能しています。CD Foundation の解説にある比喩がわかりやすい。

高熱は不調のサインである。しかし平熱だからといって健康とは限らない。

つまりこれらは異常を検知する指標であって、健全性を証明する指標ではない。変更失敗率が低いことは「良い」の証明になりません。極端な話、そもそもデプロイしていなければ失敗率はゼロになるからです。

あわせて、失敗デプロイの復旧時間が「安定性」から「スループット」側に移りました。理屈は、リードタイムが短いチームは特別な緊急手順を用意しなくても普通のパイプラインで修正を流せるから。復旧の速さは安定性の性質というより、デリバリ能力の性質だという整理です。

経営会議で使うときの実務的な含意はこうなります。不安定性の指標が良好であることを「安心材料」として報告させてはいけません。スループット系と必ず対で見て、初めて意味を持ちます。

Elite / High / Medium / Low はもう存在しない

長年使われてきた4段階のランク分けは、2025年のレポートで廃止されました。

代わりに導入されたのが、7つのチームプロファイルによる分類です。スループットと不安定性だけでなく、チーム性能・プロダクト性能・個人の有効性・摩擦・バーンアウトまで含めた多次元でクラスタリングされています。

• Harmonious high-achievers（全次元で高い）
• Pragmatic performers（速度・安定性は高いがエンゲージメントは頭打ち）
• Constrained by process（システムは安定しているが非効率なプロセスに工数を食われている）
• Stable and methodical（慎重な職人型。持続可能なペースで高品質）
• Legacy bottleneck（不安定なシステムに仕事を支配され、士気も低い）
• Foundational challenges（性能・環境・成果のすべてで苦戦）
• High impact, low cadence（価値の高い仕事を出すが、スループットが低く不安定性が高い）

この変更が示唆することは重要です。単一の順位づけをやめたのは、「Elite を目指す」という使い方が誤用を生んだからだと読めます。デプロイ頻度を上げること自体が目的化し、チームの疲弊や成果の空回りが見えなくなる。

実際、Constrained by process と Legacy bottleneck は、どちらも「性能が低い」に分類されますが、処方箋がまったく違います。前者に必要なのは承認フローの見直しで、後者に必要なのはシステムの作り直しです。同じ「Low」というラベルを貼った瞬間、この差は見えなくなります。

自社の現在地を語るときは、「うちは High 相当」ではなく「うちは承認プロセスがボトルネックになっているタイプ」と言えるかどうか。そこまで解像度が上がって初めて、次の投資判断ができます。

何で測るか — 主要ツールはいまだに4指標止まり

ここからは実務の話です。まず注意点をひとつ。

⚠️ Google が公開していたオープンソース実装 dora-team/fourkeys は、2024年1月にアーカイブされています。リポジトリにも「現在メンテナンスされていない」と明記されており、ダッシュボードの閾値も2019年版レポートのままです。日本語の解説記事にはまだこれを推奨しているものが多いので、今から新規に採用してはいけません。

では代替は何か。公式ドキュメントと比較記事を当たって整理したのが以下です。

一覧して分かるとおり、2026年7月時点で、5指標にフル対応しているツールはほぼ Faros AI だけです。Datadog の公式ドキュメントにも手戻り率の記載はありません。定義が2024年に更新されてから2年経っても、ツール側の追随はこの状況です。

ここから導かれる結論は、たぶん多くの方の予想と逆になります。

手戻り率だけは、ツールを待たずに今日から測れる

ツールの対応が最も遅れている手戻り率が、実は5指標の中で最も安く測れます。

DORA が原典の調査で使っている設問はこれです。

approximately how many deployments in the last six months were not planned but were performed to address a user-facing bug? （直近6ヶ月のデプロイのうち、計画外で、ユーザー影響のあるバグ対応のために行ったものはおよそ何件か）

必要なのは「そのデプロイは計画されたものだったか、バグ対応だったか」というフラグ1個だけです。変更リードタイムのようにコミット時刻とデプロイ時刻を紐づける基盤も、変更失敗率のようにインシデントとデプロイを突合する仕組みも要りません。

運用としては、デプロイ時に planned / unplanned のラベルを付ける。それだけです。既存の PR テンプレートやデプロイ用の Slack コマンドにチェックボックスを1つ足せば、今日から始まります。集計はスプレッドシートで足ります。

そして、この指標は変更失敗率が拾えないものを拾います。変更失敗率が捉えるのは「デプロイ直後に即時対応が必要になった、目立つ失敗」です。一方で手戻り率が捉えるのは、数日後にひっそり修正デプロイが打たれるような、静かな火消しの量です。変更失敗率が健全なのに手戻り率が上がり続けているなら、小さな問題がレビューをすり抜けて本番に出ている、というサインになります。

5指標対応ツールの登場を待つ必要はありません。4指標は既存ツールで自動化し、手戻り率だけ手で足す。これが2026年時点の現実解だと考えています。

なお、規模が小さいうちは全部手で数えても問題ありません。週次のデプロイ回数と障害件数をスプレッドシートに記録するだけで傾向は見えます。計測基盤の構築に半年溶かして、肝心の改善に着手しないのが最も多い失敗です。ダッシュボードを作ることは成果ではありません。

→ 自社の計測設計を個別に相談したい方は、記事末尾の相談窓口からどうぞ。

AIとの関係は、2024年と2025年で結論が逆転した

定義の話から少し離れて、いま最も関心の高い論点にも触れておきます。DORA は2年連続でAIを正面から調査していて、結論が去年と変わっています。

2024年の結果は厳しいものでした。AI採用が25%増えると、デリバリのスループットが1.5%低下し、安定性が7.2%低下する。一方で回答者の75%が「生産性が上がった」と答えている。個人の生産性は上がっているのに、チームのデリバリは悪化するという逆説です。

2025年はここが動きました。Google Cloud の公式発表によれば、

Unlike last year, we observe a positive relationship between AI adoption on both software delivery throughput and product performance.

スループットは明確にプラスに転じています。ただし、

AI adoption does continue to have a negative relationship with software delivery stability.

不安定性は依然として悪化したままです。速くはなったが、壊れやすさは解消していない。

数字としては、回答者の90%が業務でAIを使用し、80%超が生産性向上を報告する一方で、30%が「AIの生成コードをほとんど、あるいはまったく信頼していない」と回答しています。使っているし速くなっているが、信頼はしていない。この乖離が、そのまま不安定性の数字に出ていると読めます。

DORA の総括はこの一文に集約されます。

AI doesn't fix a team; it amplifies what's already there. （AIはチームを直さない。すでにそこにあるものを増幅するだけだ）

良い仕組みはより良くなり、悪い仕組みはより悪くなる。この結論については、AIが動かない開発環境の話で別途詳しく書きました。

実務的に効く概念がもうひとつあります。隠れた検証税です。AIはコード生成を加速しますが、生成で浮いた時間はそのまま監査と検証に再配分されます。チームは速度に適応した一方で、その下流のレビュー・テスト・デプロイ・障害対応がAI加速に対応できていない、というのが2025年の診断でした。

だからこそ、AI導入の効果はスループット系だけを見ても分かりません。変更失敗率と手戻り率が横ばい以下であることを確認して、初めて「速くなった」と言えます。ここが上がっているなら、速くなったのではなく前借りしているだけです。テスト基盤の整備が先だという話はAI駆動開発におけるテスト基盤の記事にまとめています。

使うときの3つの原則

最後に、この指標を実際に運用するうえで外せない原則を3つ挙げます。

1. 導入前にベースラインを取る。これが最重要です。後から遡って取得できません。「AIを入れて速くなりました」を証明する手段は、着手前の数週間の記録しかない。逆に言えば、ベースラインなしにAI導入の効果を語っている報告は、すべて印象論です。発注側が受注側に確認すべきポイントでもあります。

2. リードタイムを工程別に分解する。AIが縮めるのは実装時間だけです。リードタイムの内訳は「コミット → PRオープン → レビュー待ち → 承認 → マージ → デプロイ待ち → 本番」と続きますが、AIが効くのは最初の区間だけ。レビュー待ちや承認フローがボトルネックなら、全体のリードタイムは1ミリも動きません。「AIを入れたのに速くならない」の原因のほとんどがこれです。単一の数字ではなく、区間ごとに分解して見てください。

3. 目標にしない。グッドハートの法則そのままで、デプロイ頻度を評価指標にすれば、意味のない小さなデプロイを刻む動機が生まれます。指標は診断のために見るもので、報酬に紐づけた瞬間に信頼性を失います。比較する相手も他チームではなく、自チームの過去にしてください。プロダクトの性質が違えば、妥当なデプロイ頻度の水準はまったく変わります。

この指標で見えないもの

誠実に書いておくと、Four Keys には明確な限界があります。

測っているのはデリバリの速さと安全さだけです。作ったものが使われているか、事業成果が出たかは範囲外なので、アウトカム指標は別に必要になります。

もうひとつ、AI時代に特に重要なのが、理解負債を検出できないことです。AIが書いたコードを誰も説明できない状態は、Four Keys には現れません。遅行指標なので、半年後に「変更リードタイムがじわじわ伸びる」という形でようやく表面化します。Four Keys が良好でも、それだけでは安心できないというのが、いま現場で最も注意している点です。

まとめ

• 指標はもう5つ：2024年にデプロイ手戻り率が追加された。計画外デプロイの比率で、「作る」ではなく「直す」に消えた開発費の割合として読める
• 「5つ目は信頼性」は誤り：2021年レポートの記述を DORA 自身が公式に撤回している。信頼性は運用性能の指標で、デリバリ性能とは軸が違う
• Elite / High / Medium / Low は廃止済み：2025年に7つのチームプロファイルへ。「うちは High 相当」という語り方はもう成立しない
• 主要ツールはまだ4指標止まり：Google の fourkeys OSS は2024年にアーカイブ。5指標フル対応はほぼ Faros AI のみ
• 手戻り率はツールなしで測れる：デプロイに計画/計画外のフラグを1つ付けるだけ。ツール対応を待つ理由がない
• AI導入の効果はスループットだけでは語れない：2025年もなお不安定性は悪化したまま。失敗率と手戻り率が横ばい以下で初めて「速くなった」と言える

定義が動いているという事実そのものが、この指標がまだ現役で研究され続けている証拠でもあります。まずは自社が「4つの時代」の理解で止まっていないか、社内資料を1枚めくって確認してみてください。

そして、AI導入を検討しているなら、着手する前に数週間のベースラインを取ってください。これだけは後から取り返せません。