- はじめに
- デリバリーは速ければよいのか
- 改めて、Four Keysは何を測っているのか
- 「デプロイ」と「リリース」の混同がFour Keysを遠ざける
- Dave Farley氏とは
- 『Continuous Delivery』(2010) は何を変えたか
- AI時代に、継続的デリバリーはなぜ重要になるのか
- AI駆動開発を空回りさせないために
- 【告知】AI DevEx Conference 2026 - Future of Development Productivity -
- おわりに
はじめに
こんにちは。テックブログ編集長の高橋（@Taka-bow）です。
冒頭に掲載した「ソフトウェア開発現代史年表Ver2.08」は、ソフトウェア開発の考え方がどのように変化してきたのかを、できるだけ一枚で見渡せるように整理したものです。
この年表の中に、2010年の『Continuous Delivery』があります（赤枠）。
Jez Humble（ジェズ・ハンブル）氏とDave Farley（デイビッド・ファーリー）氏によるこの本は、CI/CDやFour Keysを考えるうえで、出発点にあたる一冊です。
本記事では、この『Continuous Delivery』を起点とする流れを取り上げます。
生成AIによって、コードを書く速度は大きく上がりました。AI駆動開発という言葉も広がり、実装からデプロイまでの時間はますます短くなりました。
しかし、ソフトウェアを速く作れることと、価値あるものを継続的に届けられることは、同じではありません。
そこで今回は、Dave Farley氏の初来日に寄せて、AI駆動開発を機能させる土台としての継続的デリバリーに焦点を当てます。
Dave Farley氏が築いてきた継続的デリバリーとは何か、それがDORA Metricsとどうつながっているのか、そしてAI時代にこの思想がなぜいっそう重要になるのかを整理します。
デリバリーは速ければよいのか
むかし、その場しのぎの言い訳や曖昧な返答を「蕎麦屋の出前じゃないんだから」とたしなめる言い回しがありました。そんな比喩が通じるほど、かつての出前（デリバリー）は「遅くて当てにならないもの」と見られていたのでしょう。
いまは違います。Uber Eatsやmenu、出前館のような専門サービスが増え、マクドナルドのように飲食店自身が届けてくれることも当たり前になりました。
「ピザのデリバリーは30分以内」。そんなイメージを持っている人も多いのではないでしょうか。速く届くこと自体が、ひとつの価値になっています。
しかし、30分で届いたピザでも、冷めきっていたり、注文と違うものが届いたりしたらどうでしょう。速く届いたかと、価値あるものが届いたかは、別の問いです。
ソフトウェアの「デリバリー」も同じです。
私たちエンジニアにとってのデリバリーといえば、CI/CDの「CD」、すなわちContinuous Delivery＝継続的デリバリーです。文字どおり、「ソフトウェアの価値」を「継続的」に「届ける」ことを指します。
近年は生成AIの登場によって、実装からデプロイまでの流れが目に見えて速くなっています。ソフトウェアの「デリバリー時間」が短くなっていることは、多くの現場で体感されているはずです。
ただし、速さはソフトウェアのデリバリーパフォーマンスの一面にとどまります。フードデリバリーと同じく、速く届くことと、価値あるものが届くことは別の話です。
この前提に立つと、Four Keysの見え方も少し変わってきます。
改めて、Four Keysは何を測っているのか
ソフトウェア開発のデリバリーパフォーマンスを測る指標として、Four Keys、および現在のDORA Metricsが広く知られています。
これは、継続的デリバリー（Continuous Delivery）が重視してきたソフトウェアデリバリーの能力を、計測可能な指標として捉えようとするものです。DORA Metricsを理解することは、継続的デリバリーが目指すものを理解することに直結します。
一方で、お客様と話しているとこんな声をよく耳にします。
「我々にはFour Keysのような計測手法はしっくり来ません。なぜなら、アジャイルみたいに何度もリリースしたりしないんです」
この疑問を考える前に、まずDORAが現在「ソフトウェアデリバリーパフォーマンス」をどう捉えているかを整理しておきましょう。
DORAは近年のレポートで、「ソフトウェアデリバリーパフォーマンス」を2つの軸に整理しています。
ひとつは「ソフトウェアデリバリースループット（software delivery throughput）」、つまり、スピードと効率性の軸です。次の3つで測ります。
- 変更リードタイム（change lead time）
- デプロイ頻度（deployment frequency）
- デプロイ失敗時の復旧までの時間（failed deployment recovery time）
もうひとつは「ソフトウェアデリバリーの不安定性（software delivery instability）」、これは、品質と信頼性の逆指標（低いほど良い）です。次の2つで測ります。
- 変更時の障害率（change failure rate）
- やり直し率（rework rate）
旧来の「Four Keys」（2018年頃）はデプロイ頻度・変更リードタイム・変更時の障害率・サービス復旧時間の4指標でしたが、現在のDORAでは5指標を「スループット」と「不安定性」の2軸に整理し直しています。
この再整理は、DORAがソフトウェアデリバリーを単なる速さではなく、速さと不安定性の両面から捉えようとしていることを示しています。AI駆動開発によってコードの生成量や品質の傾向が大きく動くいま、この見方はますます重要になっています。
次に、これらの指標がSDLC（ソフトウェア開発ライフサイクル）上のどこに当てはまるのかを見てみましょう。
この図でまず見てほしいのは、デプロイとリリースの位置関係です。デプロイはSDLC上のひとつのフェーズであり、リリース（図中の▼）はそのあとに位置します。
DORA Metricsのうち、頻度として測るのはリリース回数ではなくデプロイ頻度です。ここを取り違えると、「リリース回数が少ない自分たちにはFour Keysは合わない」という違和感が生まれます。
実際、デプロイとリリースをひとまとまりのイベントとして扱う現場も少なくなく、歴史の長い組織ほど、その傾向が根強い印象です。
しかし、DORA Metricsが見ているのは「ユーザーに何回公開したか」ではなく、「変更をどれだけ継続的に本番へ届けられているか」です。図の中でリリースが何度も登場している理由は、後の章「二つの意味を持つ『リリース』」で詳しく扱います。（ここではまず、DORA Metricsは「リリース回数」ではなく、変更をどれだけ速く、安定して届けられているかを捉える指標だと押さえてください。）
また、最近はAI駆動開発が広まるにつれて、こんな声も聞くようになりました。
「AI時代にFour Keysは合わないですよね」
この見方も、少し立ち止まって考える必要があります。
生成AIは、とりわけ実装・テストのフェーズを大きく速くします。さきほどの図で見たとおり、実装・テストはデプロイの手前にあります。ここが速くなれば、その変化は下流のデプロイや、DORA Metricsの「変更リードタイム」にも表れます。
もちろん、速くなるのは良い面だけではありません。
生成AIが出力したコードを鵜呑みにすれば、欠陥を見逃すリスクも高まります。その影響は、DORAがいう「ソフトウェアデリバリーの不安定性（software delivery instability）」（やり直し率や変更時の障害率）にも現れます。
つまり、生成AIはDORA Metricsを不要にするどころか、数値を大きく動かします。
だからこそ、DORA Metricsが何を測っていて、何を測っていないのかを理解する必要があります。その理解の出発点が、「デプロイ」と「リリース」の違いです。
次章では、Four Keysへの違和感を生みやすいこの混同を、もう少し丁寧にほどいていきます。
「デプロイ」と「リリース」の混同がFour Keysを遠ざける
Four Keysへの戸惑いは、AIが現れるよりも前からあります。
その大きな理由のひとつが、「デプロイ」と「リリース」という二語の混同だと思っています。まずは、この二つを分けておきましょう。
| デプロイ（Deployment） | リリース（Release） | |
|---|---|---|
| 意味 | コードや設定を本番環境に反映する作業 | 機能をユーザーが実際に使える状態にする判断 |
| 性質 | 機械的・技術的（自動化が可能） | ビジネス判断（公開タイミングをコントロール） |
| 頻度 | 高頻度（日次・時間単位もありうる） | 機能ごと・公開戦略次第 |
ところが、多くの現場ではこの二つが切り離されず、ひとつの大きなイベントとして扱われています。デプロイもリリースも「めったに行わない重い作業」になっていれば、Four Keysが自分たちとは無縁に見えてしまうのも当然の感覚です。
たとえば、ゲートキーパー型のQAを置き、「リリース判定会議」を経て本番に出す流れです。この場合、現場の感覚としては「リリース判定会議 → デプロイ」の順序に見えます。
昔のリリース候補マイルストンも、何ヶ月もかけて次の段階へ進めていく形でした。
flowchart LR
A["プレアルファ版<br/>(pre-α)"] --> B["アルファ版<br/>(α)"] --> C["ベータ版<br/>(β)"] --> D["リリース候補版<br/>(RC)"] --> E["ゴールドリリース版<br/>ゴールデンマスター版<br/>(GM)"]
これは、ソフトウェアが物理パッケージで出荷されていた時代の名残でもあります。CD-ROMを焼き（書き込み）、紙のマニュアルを同梱して箱に詰める。バグが見つかればディスクの焼き直し、マニュアルにミスがあれば製本のやり直し⋯⋯手戻りは、時間とコストの両面で致命的なダメージでした。
しかし、時代は変わりました。高速なネットワーク、パワフルなPC、ストレージの大容量化、紙媒体の電子化⋯⋯やり方を過去のままにしておく理由は、もうありません。
それでもこの流れを前提にしていると、リリースとデプロイの適切なタイミング、順序、そして頻度の感覚は分からないままです。
この混同をほどき、「リリース」の二つの意味を分離する考え方を体系化したのが、Jez Humble氏とDave Farley氏です。
Humble氏はその後、DORAの設立メンバーとして、DORA Metricsの礎を築いていきました。今回は、もう一人の著者であるDave Farley氏にスポットを当てます。
Dave Farley氏とは
Dave Farley氏は、継続的デリバリーを語るうえで避けて通れない人物です。
Jez Humble氏との共著『Continuous Delivery』（2010、Jolt Award受賞）は、CI/CD、デプロイメントパイプライン、デプロイとリリースの分離といった考え方を広め、現代のソフトウェアデリバリーの前提をつくった一冊です。単著『Modern Software Engineering』（2021）でも、ソフトウェア開発をエンジニアリングとして捉え直す考え方を示しています。
DORA Metricsも、この継続的デリバリーの思想と地続きにあります。つまりFarley氏は、「継続的デリバリーの本を書いた人」にとどまらず、現在のソフトウェアデリバリーの議論そのものに影響を与えてきた人物です。
Farley氏の言葉に重みがあるのは、実践の現場でも大きな仕事を残してきたからです。
低レイテンシシステムの分野では、Duke Awardを受賞したオープンソースプロジェクト「LMAX Disruptor」に貢献しています。並行処理や高スループットの設計を語る場面で、いまも参照され続ける仕事の一つです。
さらに、応答性や回復性、弾力性を重視する「リアクティブシステム」の考え方を示したReactive Manifestoの共同執筆者でもあります。
近年はYouTubeチャンネル「Modern Software Engineering」（旧名Continuous Delivery）の主宰者として、世界中のエンジニアに継続的デリバリーやモダン・ソフトウェアエンジニアリングの考え方を発信し続けてきました。チャンネル登録者数は26万人を超えています。
英語圏のエンジニアにとっては、継続的デリバリーの代表的な書籍を世に出した人でありながら、いまもYouTubeを通じて最新のソフトウェアエンジニアリングを語り続ける存在です。
Farley氏は近年、DORA（DevOps Research and Assessment）の年次レポートにも参加しています。2022年は10人の著者の一人として、2023年は「継続的デリバリーの効用（Benefits of continuous delivery）」の章の執筆者および分野アドバイザーとして、2024年は分野の専門家として報告書に名を連ねています。
『Continuous Delivery』(2010) は何を変えたか
Jez Humble氏とFarley氏が2010年に出版した『Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation』は、何を変えたのでしょうか。
2010年当時、リリースは重く、失敗が許されないイベントとして扱われていました。本番投入の前には長い調整期間があり、変更はできるだけまとめて出すのが当たり前でした。
『Continuous Delivery』は、この前提を見直す考え方を示しました。
ここでいう「Delivery」は、ソフトウェアをいつでもリリースできる状態に保ち続けることを指します。デプロイ作業そのものや、ユーザー公開としてのリリースとは別の概念です。
主張の柱は、次の3つです。
- デプロイメントパイプラインという概念の提唱
- 「ソフトウェアを常にリリース可能な状態に保つ」という考え方
- 自動化の範囲を「統合（CI）」から「デプロイメント」まで広げたこと
これらは自動化の対象範囲を広げるとともに、ソフトウェア開発の文化にも影響を与えました。変更をまとめて重く出す形から、頻繁に小さく出して安定性を高める形へと、考え方が変わりました。
リリースは一大イベントではなくなり、デイリーないし時間単位の活動になりました。
こうした変化のなかで、「デプロイ」と「リリース」を分けて考える発想が広がりました。次章ではこの分離について詳しく見ていきます。
二つの意味を持つ「リリース」
「リリース」という言葉がややこしいのは、継続的デリバリーに取り組んでいるかどうかで、指しているものが変わるからです。
旧来のリリース管理では、「リリース」は本番投入に向けた承認・計画・調整を含む、大きなマネジメント上の区切りでした。リリース判定会議を経て、デプロイし、ユーザーに公開する。これら全体をまとめて「リリース」と呼んでいたのです。
flowchart LR
A["リリース判定会議"] -- "判定OK" --> B
subgraph Release["リリース"]
direction LR
B["デプロイ<br/>（手動）"] --> C["ユーザー公開"]
end
一方、継続的デリバリーでは、このまとまりを分解します。デプロイは自動化された反映作業として高頻度に行い、ユーザー公開としてのリリースとは切り分けて考えます。
この文脈での「リリース」は、ユーザーが新機能を実際に使えるようになる瞬間です。つまり、先にデプロイしておき、後で公開判断によってリリースする、という順序になります。
flowchart LR
A["デプロイ<br/>（自動）"] --> B["本番環境<br/>（まだ非公開）"]
B -- "公開判断" --> C["リリース<br/>（ユーザー公開）"]
だから、「リリース → デプロイ」も「デプロイ → リリース」も、現場ではどちらも正しい言い方になりえます。問題は順序そのものではなく、それぞれの「リリース」が別の意味を指していることです。
この違いは、コンビニにたとえると分かりやすくなります。
- デプロイ = 商品をバックヤードに搬入する作業
- リリース = その商品を陳列棚に並べて、顧客が買えるようにする判断
flowchart LR
Code["新商品<br/>（コード）"] --> Deploy(("デプロイ<br/>（機械的・高頻度）"))
Deploy --> Backyard["バックヤード<br/>（本番環境）"]
Backyard --> Release(("リリース<br/>（ビジネス判断）<br/>※Feature Flag"))
Release --> Shelf["陳列棚<br/>（ユーザーに公開）"]
Shelf --> Buy(("商品を選んで<br/>購入"))
Buy --> Customer["顧客<br/>（ユーザー）"]
バックヤードに搬入すること（デプロイ）と、陳列棚に並べる判断（リリース）は、本来別々のものです。Jez Humble氏とFarley氏は『Continuous Delivery』で、この二つを意図的に分離する発想を提示しました。
- デプロイは機械的な反映作業として、できる限り自動化し、高頻度に行う
- リリースはビジネス判断として、機能の公開タイミングをコントロールする
この分離を支える代表的な仕組みが、フィーチャーフラグ（Feature Flag）、カナリアリリース、ブルーグリーンデプロイメントです。たとえばフィーチャーフラグを使えば、コードは本番環境に置いたまま、機能の有効／無効や公開対象を切り替えられます。
ただし、これらの仕組みにも限界はあります。データベースのスキーマ変更や外部サービスへの副作用を伴う処理では、設計や運用ルールも含めた備えが必要です。
具体的な運用例は、Findy Tech Blogの過去記事でも紹介しています。
AI時代に、継続的デリバリーはなぜ重要になるのか
ここまで見てきたように、継続的デリバリーは単なる自動化の話ではありません。
変更を小さく保ち、素早くフィードバックを得て、いつでも安全にリリースできる状態を維持するための規律です。
Farley氏は『Modern Software Engineering』（2021）でも、開発そのものをエンジニアリングとして捉え直し、素早く学ぶことと複雑さを制御することの重要性を説いています。
変更を小さく保ち、素早く学び、複雑さを制御する姿勢は、AI時代にこそ重要になります。なぜなら、生成AIは変更を生み出す速度を上げる一方で、その変更が安全で価値あるものかどうかまでは保証しないからです。
生成AIは、速さの面でも品質の面でも、DORA Metricsの数値を動かします。その意味で、DORA Metricsは今も計測の出発点です。
一方で、動いた数値をこれまでと同じように読み解き、開発の良し悪しを判断することは難しくなりました。
DORA Metricsだけでは、「速く届いた先で、ユーザーにどんな価値が生まれたのか」までは見えないからです。
2025年のDORAレポートはAIを「増幅器（amplifier）」と呼び、その効果を引き出す組織側の条件を「AI Capabilities Model」として整理しています。
%%{init: {'flowchart': {'curve': 'linear'}}}%%
flowchart LR
AI("AIの導入")
MUL("×")
subgraph CAP["7つのケイパビリティ"]
direction TB
C1("ユーザー<br/>中心の視点")
C2("優れたバージョン管理<br/>プラクティス")
C3("AIでアクセス可能な<br/>内部データ")
C4("小さいバッチ<br/>単位の作業")
C5("明確で周知された<br/>AIのスタンス")
C6("質の高い内部<br/>プラットフォーム")
C7("健全なデータ<br/>エコシステム")
end
subgraph OUT["アウトカム"]
direction TB
O1("チーム<br/>パフォーマンス")
O2("コードの品質")
O3("個人の有効性")
O4("プロダクト<br/>パフォーマンス")
O5("摩擦の低減")
O6("スループット")
O7("組織<br/>パフォーマンス")
end
AI ~~~ MUL
MUL ~~~ C4
C1 --> O1
C2 --> O1
C2 --> O3
C3 --> O2
C3 --> O3
C3 --> O4
C4 --> O3
C4 --> O4
C4 --> O5
C5 --> O3
C5 --> O4
C5 --> O5
C5 --> O6
C5 --> O7
C6 --> O5
C6 --> O7
C7 --> O7
冒頭のピザのデリバリー話に戻しましょう。
「速く届いた」ことと、「価値あるものが届いた」というアウトカムは、必ずしも一致しません。
DORA Metricsはあくまで「届けるまでの速さと安定性」を示すものです。ピザでいえば、配達時間だけでなく、配送中に崩れずに届いたか、問題が起きたときに素早く立て直せるかまで含めた指標に近いでしょう。大事な指標ですが、それだけでは「届いたあと、ユーザーや事業にとって何が起きたか」までは見えません。
DORAは2025年のレポートで、まさにこの「ユーザー側に何が届いたか」を主役に据えました。
AI Capabilities Modelの7つのケイパビリティ（上の図）のひとつに「ユーザー中心の視点（User-centric focus）」を掲げ、AIを「正しい方向」に効かせるための北極星（North Star）と位置づけています。
チームがアウトプット（出荷した機能の数や速度）を追うばかりで、ユーザーに届いたアウトカムを見失うと、AIは「フィーチャーファクトリー（機能量産工場）」を加速させます。
活動量は多くてもインパクトの出ない状態に陥る、とレポートは警告しています。
DORAの調査では、ユーザー中心の視点が欠けたチームではAIを導入するとチームパフォーマンスにマイナスの影響さえ及ぼす、と報告されています。一方、ユーザー中心の視点を持つチームでは、AIがプラスの影響を大きく増幅すると報告されています。
生成AIでデリバリーがさらに速くなる時代だからこそ、速さの先にあるユーザー側のアウトカムを見失わないことが、これまで以上に重要です。
AI駆動開発を空回りさせないために
「デプロイ」と「リリース」の混同は、用語の取り違えにとどまりません。AI駆動開発を進める組織にとっては、そのままリスクの増幅につながります。
日本のソフトウェア開発現場でも、「リリース＝大イベント」「デプロイ＝リリース当日にやる作業」という理解が、いまだに根強く残っています。
『Continuous Delivery』の日本語訳は2012年に出版されました。
それから14年が経ったいまも、継続的デリバリーの重要な概念的貢献である「デプロイとリリースの分離」は、少なくとも日本の多くの現場で十分に共有されているとは言えません。
継続的デリバリーを実践している組織では当たり前に使われる "Deployment ≠ Release" という整理が、日本の現場ではいまも「同じこと」として語られがちです。
Farley氏は2021年の『Modern Software Engineering』で、誤った考えが根強く残る理由をこう書いています。
間違った考え方をなかなか捨てられない理由のひとつは、ソフトウェア開発のパフォーマンス（能力、業績）を効果的に計測できていないことにあります。
Farley, D.(2022), 長尾高弘 (訳). 継続的デリバリーのソフトウェア工学: もっと早く、もっと良いソフトウェアを作るための秘訣 (Nagao, T., Trans.). 日経BP社. (Original work published 2021) p.70
デプロイとリリースを分離できれば、デプロイの頻度を上げながら、機能の公開タイミングは別途コントロールできます。
逆に、分離できなければ、リリース＝デプロイ＝大イベントの連鎖から抜け出せません。
いまも日本の多くの現場は、「動いているコードには触れるな」という考え方の延長線上にあります。
Farley氏は同書で、こうも指摘しています。
私の印象では、ソフトウェア産業は学ぶことも進化することもなかなかできないで苦闘しているように見えます。この相対的な停滞は、コードを実行するハードウェアのとてつもない進化によって見えなくされているのです。
Farley, D.(2022), 長尾高弘 (訳). 継続的デリバリーのソフトウェア工学: もっと早く、もっと良いソフトウェアを作るための秘訣 (Nagao, T., Trans.). 日経BP社. (Original work published 2021) p.69
2021年のこの指摘は、いまの生成AIにもそのまま当てはまります。生成AIは、変更を大量に、しかも高速に生み出します。
だからこそ、問われているのは「AIでどれだけ速く作れるか」だけではなく、作られた変更を、小さく、安全に、継続的に届けられるか、つまり「開発資本」を組織として持てているかです。
デプロイとリリースを切り分ける土台がなければ、AIは変更の速度だけでなく、リスクも増幅します。DORA Metricsの数値が動いても、それだけではAIが良い方向に働いているかは判断できません。
ここでいう「継続的デリバリーができない」は、単にデプロイ自動化がないことではなく、変更を小さく保ち、デプロイとリリースを切り分け、ユーザーへの影響を制御しながら継続的に届ける仕組みがない状態を指します。
「デプロイ」と「リリース」の混同に、「フィーチャーファクトリー」の罠が重なれば、AI駆動開発はいくら進めても成果に届きません。継続的デリバリーができない組織で、AIは増幅器(amplifier)として空回りを生むのです。
まずは、自チームで「デプロイ」と「リリース」をいまどう区別しているのかを言語化してみてください。境界がぼやけているなら、それ自体が改善の第一歩になります。
【告知】AI DevEx Conference 2026 - Future of Development Productivity -
継続的デリバリーとAI時代のソフトウェア開発について、Farley氏本人の言葉で聞ける機会があります。
AI DevEx Conference 2026で、Farley氏が初めて日本に登壇します。
開催概要は以下のとおりです。
| 項目 | 内容 |
|---|---|
| 開催日時 | 2026年7月22日（水）・23日（木）9:30〜18:40 |
| 開催形式 | オフライン・オンライン配信（要事前登録） |
| チケット | 現地参加チケット（アーリーバード第2弾） ¥3,000（税抜）※締切日：5月27日（水） 現地参加チケット ¥5,000（税抜） オンライン（無料） |
| 開催場所 | JPタワーホール＆カンファレンス（東京・丸の内） |
| 申込URL | https://dev-productivity-con.findy-code.io/aidevex2026 |
| 主催 | ファインディ株式会社 |
| 対象者 | DevExやソフトウェア開発の改善に関心があるエンジニアやマネージャー、経営者など |
Farley氏は、初日の7月22日に次のテーマで登壇します。
「AIと共存する世界のソフトウェアエンジニアリング ─不変の本質とプログラミングの未来」
AIと共存する時代に、より良いソフトウェアをより速く作るためには何が必要なのか。この記事で扱ってきた継続的デリバリーやエンジニアリングの話とも、まっすぐつながるテーマです。
このほか、t_wadaさんこと和田卓人氏や、「DevEx」の第一人者であるEirini Kalliamvakou氏も登壇予定です。DeNA、Uber、Citibank、LinkedInなど、国内外50社以上が登壇します。
ぜひご参加ください！
おわりに
ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。
