デプロイ頻度とは、開発チームが本番環境にどれくらいの頻度でソフトウェアをリリースしているかを表す指標です。 DORA（Google Cloud の研究チーム）が提唱する開発生産性指標「Four Keys」の一つで、公式の定義は「一定期間のデプロイ回数、またはデプロイ間隔」とされています。 単純な回数の数え上げに見えますが、この数字には開発プロセス全体の健全性が集約されて表れます。 この記事では、定義と測り方、そして「頻繁にデプロイするほど安全になる」という直感に反する関係が成り立つ理由を整理します。
デプロイ頻度とは何か
デプロイ頻度は、DORA が定義する5つのソフトウェアデリバリ指標のうち、スループット（仕事を届ける速さ）側に分類される指標です。 数える対象は本番環境への反映で、ステージング環境や検証環境へのリリースは含めません。 新機能のリリースだけでなく、バグ修正や設定変更のデプロイも1回と数えます。
チームによって「週に何回」という回数で見る場合と、「前回のデプロイから何日空いたか」という間隔で見る場合がありますが、測っているものは同じです。 毎日複数回デプロイするチームもあれば、四半期に1回の大型リリースだけのチームもあります。 この差は、リリース作業がどれだけ自動化されているか、1回のリリースにどれだけの変更をまとめているかという、開発様式の差をそのまま映します。
頻度が高いほど安全になる理由
「本番を触る回数が増えれば、事故も増えるはずだ」というのが自然な感覚です。 しかし DORA の一連の調査では、デプロイ頻度が高いチームほどデプロイの失敗が少ないという傾向が繰り返し確認されています。
この逆転が起きる機構は、1回のデプロイに載る変更量にあります。 デプロイ頻度は、実質的には変更のバッチサイズ（1回のリリースに載せる変更の大きさ）の代理指標です。 月に1回のリリースには数百の変更が載り、どれかが問題を起こしたとき、原因の候補も数百あります。 毎日デプロイしていれば1回に載る変更は数個で、問題が起きても原因はほぼ絞れており、戻すのも簡単です。 つまり、頻度を上げること自体が安全にするのではなく、頻度を上げるために必要になる変更の小口化が、失敗の確率と影響範囲を同時に小さくします。
もう一つ、頻度を上げるにはテストとリリース作業の自動化が事実上の前提になります。 手作業のリリース手順のまま毎日デプロイすることはできないからです。 だから高いデプロイ頻度は、自動化されたパイプラインが整っていることの証明としても読めます。
廃止された Elite / High / Medium / Low の水準表
デプロイ頻度の解説では、「オンデマンド（1日複数回）なら Elite、月1回未満なら Low」といった4段階の水準表が長く引用されてきました。 この水準表は現在は使えません。 DORA は2025年のレポートでランク分けそのものを廃止し、多次元のチームプロファイルによる分類へ移行しています。 経緯はFour Keys の2026年版の解説記事にまとめています。
比較の相手は、他社の水準ではなく自チームの過去に置いてください。 プロダクトの性質によって妥当な頻度の水準は大きく変わります。 たとえばモバイルアプリはストア審査を挟むため、Webサービスと同じ頻度にはなりません。 絶対値の高低よりも、自チームの傾向が上向いているか下向いているかに意味があります。
測り方
デプロイ頻度は、5指標の中で最も測りやすい指標です。 CI/CDパイプラインのデプロイイベントを数えるだけでよく、コミットとデプロイの紐づけ（変更のリードタイムで必要になる基盤）も、インシデントとの突合（変更障害率で必要になる仕組み）も要りません。
数字をぶれさせないために、次の決め事を先にしておきます。
- 対象の環境：本番環境への反映のみを数える
- サービスの単位：複数サービスを運用している場合、サービスごとに数えるか、チームで合算するかを固定する。マイクロサービス構成ではサービス数が増えるだけで合算値が自然に増えるため、傾向を見るには単位の固定が前提になる
- 集計の粒度：週次または月次で継続的に記録する
Findy Team+ や Datadog などの専用ツールで自動集計するのが定石ですが、規模が小さいうちはデプロイのたびにスプレッドシートへ1行足すだけでも傾向は見えます。 計測基盤づくりに時間を使いすぎて改善に着手しないより、粗くても今日から記録を始めるほうが先です。
注意点
デプロイ頻度を目標や評価指標にすると、指標として機能しなくなります。 回数が評価されるなら、意味のない小さなデプロイを刻んで数字を作る動機が生まれるからです。 この指標は診断のために見るものであって、報酬や査定に紐づけるものではありません。
また、デプロイ頻度はスループット側の指標なので、単独では「速いが壊れている」状態を検出できません。 変更障害率やデプロイ手戻り率といった不安定性側の指標と必ず対で見てください。 頻度が上がり、かつ失敗の割合が横ばい以下であって、初めて改善と言えます。
関連して読める記事
デプロイ頻度は、Four Keys の他の指標と組み合わせて初めて意味を持ちます。まず枠組みの全体像から押さえたい方は、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日