プログレッシブデリバリーとは？自動分析で昇格とロールバックを判断する実装と採用基準

プログレッシブデリバリーは、新バージョンへの切り替えを一気に行わず、少ない露出から始めて監視の数値が基準を満たしたときだけ次の段階へ進める配信の制御方式です。カナリアリリースと似ていますが、決定的な差は「進めるか戻すかを人が見て判断するのか、収集したメトリクスが自動で判断するのか」にあります。この記事では狭義と広義で食い違う定義の整理から、判定に載せる指標の選び方、SLOのエラーバジェットからしきい値と観測窓を導く手順、Argo RolloutsとFlaggerの実装の差、そして採用を見送るべき条件までを実装目線でたどりました。版番号は2026年8月5日にGitHubの各リポジトリで確認した内容です。

まとめ：プログレッシブデリバリーは切り戻し判断を人から外すための仕組み

先に結論を置きます。この方式の価値は段階的に公開することそのものではありません。カナリアの露出を絞るだけなら手作業でもできます。価値があるのは、昇格と切り戻しの判断基準を宣言的に書き下し、深夜のリリースでも同じ基準で機械が実行する状態を作れる点にあります。

導入の順序は逆にしないでください。先に要るのは観測です。エラー率と応答時間をバージョン別に分けて取得できない環境では、自動判定を入れても比較対象が無く、しきい値がただの飾りになります。次にトラフィックの分割手段、最後に自動判定という順で積み上げます。

見送ってよい条件もはっきりしています。リリース頻度が月に数回、カナリアへ流れる要求が1段階あたり数百件に届かない規模なら、統計的に差を検出できないため自動判定は機能しません。その場合はローリングアップデートと手動確認で十分です。判断を機械に渡すのは、判断の回数が人手で捌けなくなってからで構いません。

プログレッシブデリバリーの定義と狭義・広義で変わる対象範囲の境界

この言葉は文脈によって指す範囲が二段階に変わります。記事や製品ドキュメントを読むときは、どちらの意味で使われているかを先に見分けてください。

狭義の定義＝メトリクス分析と自動ロールバックまで含むデプロイ制御

狭義では、カナリアリリースに「自動分析」と「自動ロールバック」を足したものを指します。トラフィックの5%を新バージョンへ向け、一定時間そのまま置き、Prometheusなどから取得したエラー率が基準内なら20%へ上げる。基準を外れたら即座に0%へ戻す。この一連の判断ループが宣言的に定義され、人の承認を挟まずに回る状態が狭義のプログレッシブデリバリーです。

この定義を採ると、必要な構成要素は3つに絞られます。トラフィックを比率で割る仕組み、バージョン別にメトリクスを取れる観測基盤、そして両者をつないで判定するコントローラー。どれか1つでも欠けると成立しません。

広義の定義＝公開範囲を段階的に絞って影響半径を制御する手法群の総称

広義では、フィーチャーフラグによる機能単位の公開制御、特定ユーザーセグメントへの限定リリース、A/Bテストまでを含む総称として使われます。RedMonkのJames Governorが2018年にこの語を提唱した当時の文脈は、こちらの広い意味に近いものでした。

広義で読むと「デプロイとリリースを分離する考え方すべて」が範囲に入ります。ベンダーの製品ページが広義、Kubernetes界隈の技術記事は狭義を指していることが多く、同じ語で会話しているつもりが噛み合わない原因です。社内で使う際は、どちらの意味かを最初に合意しておくと後の設計が揃います。

継続的デリバリーとの違いは到達点が本番反映か安全な全面展開か

継続的デリバリー（CD）のゴールは、コード変更をいつでも本番へ反映できる状態を保つことです。パイプラインが緑になった時点で目的は達成されています。プログレッシブデリバリーは、その先の「反映してから全ユーザーへ行き渡るまで」を対象にします。

両者は競合せず直列につながる関係です。パイプラインを整えないままリリース制御だけ入れても、そもそも自動でデプロイが走らないため出番が来ません。

段階公開と自動分析と自動昇格を一つの制御ループに束ねる仕組みの流れ

実装の中身は、状態機械とタイマーとクエリの組み合わせです。

重み付けとベイクタイムでトラフィック比率を刻む段階定義の書き方

段階定義は「重みを上げる」「一定時間待つ」の反復で書きます。Argo RolloutsならsetWeightとpauseを交互に並べ、FlaggerならstepWeightとintervalとmaxWeightで刻み幅と間隔と上限を指定します。表現は違っても意味は同じです。

待ち時間はベイクタイムと呼ばれます。この時間が短すぎると、メモリリークや接続プールの枯渇のように負荷が蓄積してから顕在化する不具合を素通りさせかねません。逆に長くすると1回のリリースに数時間かかります。実務では、既知の障害が表面化するまでの時間から逆算して決めるのが合理的です。JVMのようにウォームアップで応答時間が変動する基盤なら、初回の段階だけ長めに取る書き方も選べます。

分析実行が返す成功・失敗の判定ロジックと自動ロールバックが走る条件

判定の仕組みは、指定間隔ごとにクエリを投げて条件式で真偽を返す形です。Argo RolloutsではAnalysisTemplateにsuccessConditionまたはfailureConditionを書き、実行単位であるAnalysisRunが測定を繰り返します。連続何回まで失敗を許すかはfailureLimitで決めます。

ここで見落としやすいのが「測定できなかった」場合の扱いです。Prometheusが応答しない、クエリが空を返す、といった状態は成功でも失敗でもありません。エラー時にどう倒すかを明示しないと、監視が落ちている間だけ全段階が素通りする経路が生まれます。既定に任せず、測定不能はロールバック側へ倒す設定を選んでください。

手動承認ゲートと自動昇格を組み合わせる段階設計と停止させる条件

全段階を自動にする必要はありません。5%と20%は自動、50%を超える段階だけ人の承認を挟む、という混在が実務では扱いやすい形です。Argo Rolloutsはpauseに時間を書かなければ無期限停止となり、コマンドかUIでの承認を待ちます。

停止条件も設計対象です。営業時間外は昇格させない、金曜の夕方以降は次の段階へ進めない、といった運用上の制約は、パイプライン側のスケジュールで表現します。ツールの設定に書けない制約をルールとして人の頭に置くと、担当者が変わった瞬間に失われます。

カナリア・ブルーグリーン・フィーチャーフラグとの関係と役割分担の整理

この4つは競合する選択肢ではなく、層が違う道具です。どこで何を切り替えるのかで整理すると重なりが消えます。

カナリアリリースとの関係は判定の自動化があるかどうかで分かれる

カナリアリリースは露出を絞る方式そのものを指し、判定の主体を問いません。ダッシュボードを人が見て「問題なさそう」と判断して次へ進めるのも立派なカナリアです。プログレッシブデリバリーは、その判断を条件式へ落として機械に渡した状態を指します。

言い換えると、プログレッシブデリバリーはカナリアの上位互換ではなく、カナリアの運用形態の1つです。比率制御の仕組みや異常検知の考え方そのものはカナリアリリースの段階的な露出制御で扱っており、本記事は判定側の設計に絞っています。

ブルーグリーンとの関係は切替の瞬間性と段階性で使い分けが決まる

ブルーグリーンは面を丸ごと切り替えるため、比率という概念を持ちません。0%か100%かの二択です。したがって狭義のプログレッシブデリバリーとは直接組み合わせにくく、代わりに「切り替え前に新面へ合成トラフィックを流して分析する」形で自動判定を挟みます。

選択の入口は切り戻しに許せる時間です。数秒で戻す要件なら面ごと切り替えるBlue/Greenの設計、追加リソースを持てないならローリングアップデートの入れ替え制御という順で消去法をかけ、残った領域が本記事の対象になります。

フィーチャーフラグとの関係はアプリ層とインフラ層で責務が分かれる

フラグはアプリのコード内で分岐を切り替えます。インフラ側のトラフィック制御では、1つのリクエストが新旧どちらのバージョンへ届くかしか決められません。「特定の法人テナントだけ新機能を見せる」「社内アカウントだけ先に開放する」といった属性ベースの制御は、フラグでなければ書けない領域です。

両者を併用すると、インフラ層で基盤の安全性を確認し、アプリ層で機能の公開範囲を決める二段構えです。フラグ側の実装パターンと寿命管理はFeature Toggleの定義と基本概念にまとめてあります。なおフラグ評価APIの標準化を進めるOpenFeatureはCNCFのインキュベーティングプロジェクトで、仕様は2026年8月5日時点でv0.9系が公開されています。

判定に使うメトリクスの選び方とSLOをしきい値へ落とし込む手順

設計の成否はここで決まります。指標を増やすほど誤検知が増え、少なすぎると通り抜けが起きるため、絞り方に方針が要ります。

判定に載せる指標はエラー率・遅延・飽和度・業務指標の四つに絞る

まず入れるべきはHTTPの5xx比率です。次に応答時間の分位点。平均ではなく95パーセンタイルか99パーセンタイルを使います。平均は少数の極端な遅延を丸めてしまい、体感の悪化を拾えません。

• エラー率：5xx比率。4xxはクライアント起因が混ざるため原則含めない
• 遅延：p95またはp99。旧バージョンとの相対比較で見る
• 飽和度：CPU・メモリ・接続プール使用率。リークの検出に効く
• 業務指標：カート投入率や検索成功率など、壊れると売上に直結する数値

実務でまず必要なのは上の2つだけです。飽和度と業務指標は、最初のリリースで自動判定が安定して回るようになってから足してください。4種類すべてを初回から入れると、どの指標が誤検知したのかを切り分ける作業でリリースが止まります。

SLOのエラーバジェットから判定しきい値と観測窓を決める手順

しきい値を勘で置くと、緩すぎて素通りするか厳しすぎて毎回ロールバックするかのどちらかになります。SLOから逆算する手順を踏んでください。

1. 対象サービスのSLOを確認する（例：月間の成功率99.9%）
2. そこからエラーバジェットを出す（月間0.1%＝30日で約43分の停止相当）
3. 1回のリリースで消費してよいバジェットの割合を決める（例：5%）
4. その消費量を超えない新バージョン側のエラー率上限を、段階ごとの露出比率で割り戻す
5. 観測窓を、その比率で必要な件数が貯まる長さに設定する

この計算をすると、露出5%の段階では非常に短い時間で判定できないことが数字で見えます。しきい値と観測窓はセットで決まるものであり、片方だけ触っても判定の質は動きません。

トラフィックが少ない環境で判定が揺れる理由と回避のための調整

日次1万リクエストのサービスで、カナリアに5%を割り当てると1日500件、5分間の観測窓なら2件前後しか流れません。この件数で「エラー率1%」を判定させると、1件失敗しただけで50%と算出され、確実にロールバックが走ります。件数が少ない場面での比率は、ほとんど乱数と変わらない振れ方をします。

回避の手は3つ。観測窓を分ではなく時間の単位へ伸ばす、初段の露出比率を5%ではなく20%以上へ上げる、あるいは比率ではなく絶対件数で条件を書く。どれも取れないなら、そのサービスに自動判定は向いていません。手動確認へ戻す判断のほうが安全です。

Argo RolloutsとFlaggerによる実装の違いとトラフィック制御層の選択

Kubernetes上の実装は事実上この2つが選択肢になります。どちらもCRDでカナリアの進行を宣言しますが、既存マニフェストへの入り方が異なります。

Argo RolloutsはRolloutリソースと分析テンプレートで組み立てる

Argo RolloutsはDeploymentをRolloutという独自リソースへ置き換える方式です。GitHubのリリース情報では2026年8月5日時点の最新タグがv1.9.1（2026年7月17日公開）で、1.9系が現行にあたります。段階定義と分析テンプレートの参照を同じリソース内に書けるため、リリース手順が1ファイルで読み切れる形になります。

代償として、既存のDeploymentを書き換える移行作業が発生します。HelmチャートやKustomizeのベースがDeployment前提で組まれている場合、そこを触る判断が要ります。コントローラーの内部構造とコンポーネントの役割はArgo Rolloutsのアーキテクチャ解説で分解しました。

FlaggerはCanaryリソースで既存ワークロードを包んで制御する

FlaggerはDeploymentをそのまま残し、別途Canaryリソースを定義して対象を指定します。既存マニフェストへの変更が小さく、後から外しやすいのが特徴です。GitHubのリリース情報では2026年8月5日時点の最新タグがv1.44.0（2026年7月21日公開）でした。

分析はMetricTemplateで定義し、Webhookで負荷生成や受け入れテストを挟めます。カナリア開始前に合成トラフィックを流して事前確認する運用が組みやすく、低トラフィックのサービスで判定件数を稼ぐ手段として使えます。運用主体はFlux CD側のプロジェクトです。

トラフィック制御層はGateway APIとサービスメッシュから選ぶ

比率でトラフィックを割るには、その機能を持つ層が必要です。選択肢はIngressコントローラーのアノテーション、サービスメッシュ、Gateway APIの3系統。Gateway APIは2026年8月5日時点でv1.6.1（2026年7月16日公開）が最新タグで、1.6系が現行です。

判断は既存構成から決めます。すでにIstioやLinkerdが入っているならメッシュの重み付けをそのまま使う。何も無い状態から始めるなら、メッシュの導入コストを負うよりGateway APIか手持ちのIngressで済ませるほうが軽くなります。カナリアのためだけにサービスメッシュを新規導入する判断は、運用の学習コストに見合いません。

導入が失敗する典型パターンと採用を見送るべきシステム側の条件

ここは言い切ります。以下に当てはまるなら入れないほうが良い結果になります。

観測基盤が無いまま自動判定だけ先に入れる導入順序が招く空回り

最も多い失敗は順序の誤りです。バージョン別にメトリクスを分離できない状態でコントローラーだけ入れると、新旧が混ざった数値で判定することになり、カナリアが壊れていても全体平均に埋もれます。

先に必要なのは、Podやサービスにバージョンのラベルを付け、クエリでそれを絞り込める状態です。ここが整っていれば手動カナリアでもすぐ効果が出ます。自動判定はその後で構いません。

フラグの寿命を管理せず分岐が残り続ける負債化と後始末の決め方

フィーチャーフラグを併用する場合、消し忘れが積み上がります。分岐が10箇所を超えたあたりから組み合わせのテストが現実的でなくなり、どの経路が本番で動いているのか誰も答えられなくなります。

対策は単純です。フラグを作る時点で削除予定日を書き、期限を過ぎたら失敗するテストを一緒に入れる。運用ルールの周知ではなく、期限切れを機械的に検出できる形にしてください。人の記憶に頼る後始末は必ず漏れます。

採用を見送ってよい四つの条件と代わりに選ぶべき方式の当てはめ

見送り判断の条件を4つ挙げます。第1に、1段階あたりのリクエストが数百件に届かない低トラフィックのサービス。第2に、リリース頻度が月数回以下で、判断回数が人手で捌ける規模。第3に、バージョン別のメトリクス分離ができておらず、当面その整備予定も無いケース。第4に、新旧が同時に動くと壊れる非互換なスキーマ変更を含むリリースです。

1と2ならローリングアップデートと手動確認、3は観測基盤の整備が先、4は新旧同時稼働を避けられるブルーグリーンか、スキーマ変更を二段階へ割る設計へ寄せます。プログレッシブデリバリーが効くのは、リリース頻度が高く、トラフィック量があり、判断の反復が人のボトルネックになっている場合に限られます。

観測基盤から積み上げる段階的な導入手順と運用体制に必要な前提

入れると決めた場合の進め方です。一度に全部やらず、各段階で価値が出る形に分けます。

観測基盤から手動カナリアを経て自動判定へ進む三段階の積み上げ方

第1段階は観測の整備です。バージョンラベルを付与し、エラー率と応答時間の分位点をバージョン別に出せるダッシュボードを作ります。この時点で、既存のリリースの品質が数値で見えるようになります。

第2段階で手動カナリアを回します。比率を人が上げ、ダッシュボードを見て判断する。ここで「どの数値がどれだけ動いたら戻すべきか」の相場観が現場に貯まります。第3段階は、その相場観を条件式として書き下す工程です。順番に積むと、最後の自動化は設定作業に近い軽さになります。

パイプライン構築と定常運用で内製と外部委託の線を引くための考え方

この仕組みは、作る作業と回す作業で必要な技能が違います。トラフィック分割層の選定、コントローラーの導入、分析テンプレートの初期設計は、Kubernetesとメトリクス基盤の両方に踏み込む一時的な構築作業です。一方で、しきい値の見直しやフラグの棚卸しは、サービスの中身を知っている自社の担当者が続けたほうが精度が出ます。

構築を外に出し、運用を自社に残す分け方が現実的です。既存構成の棚卸しからリリース制御の設計、その後の内製移行までを引き受ける形として、保守運用・内製化支援で相談を受け付けています。観測基盤が無い段階からでも、どこから手を付けるかの整理は可能です。

よくある質問

プログレッシブデリバリーの設計で実際に問い合わせの多い論点を5つ取り上げます。

プログレッシブデリバリーとカナリアリリースは何が違うのですか？

カナリアリリースは「一部のユーザーにだけ新バージョンを見せる」という露出のさせ方を指す言葉で、進めるか戻すかを誰が決めるかは含みません。プログレッシブデリバリーは、その判断をメトリクスの条件式へ落として機械が実行する状態を指します。カナリアを手作業で回しているなら、それはカナリアリリースであってプログレッシブデリバリーではない、という切り分けになります。

Kubernetesを使っていなくても導入できますか？

できます。必要なのは比率でトラフィックを割る仕組みとバージョン別のメトリクスであり、Kubernetesは手段の1つにすぎません。AWSではCodeDeployのカナリア設定とCloudWatchアラームの組み合わせで、アラーム発火時の自動ロールバックまで実現できます。ただしArgo RolloutsとFlaggerはどちらもKubernetes前提のため、既製ツールの選択肢は狭くなります。

Argo RolloutsとFlaggerはどちらを選ぶべきですか？

既存マニフェストを書き換えられるかで決めます。DeploymentをRolloutへ置き換える改修が通るならArgo Rolloutsが素直で、リリース定義が1ファイルにまとまります。既存資産へ手を入れにくい、あるいは後で外す可能性を残したいならFlaggerです。Canaryリソースを足すだけで済み、削除も容易です。すでにArgo CDでGitOpsを組んでいるなら、運用画面が揃うArgo Rolloutsに寄せる判断も成立します。

自動ロールバックが誤作動して正常なリリースが戻される場合は？

まず観測窓とサンプル件数を疑ってください。件数が少ない状態での比率判定は大きく振れるため、窓を伸ばすか初段の露出比率を上げると収まる場合がほとんどです。それでも直らないなら、判定に使っている指標そのものを見直します。4xxを含めていないか、バッチ処理の時間帯と重なっていないか、ウォームアップ中の応答時間を拾っていないか。失敗許容回数を1回から3回程度へ緩める調整も現実的な手です。

データベースのスキーマ変更を含むリリースでも使えますか？

新旧のバージョンが同時に本番トラフィックを受けても壊れない範囲でのみ使えます。列の追加のように後方互換が保たれる変更なら問題ありません。列の削除やリネームは、新バージョンだけが動く前提の変更なので、カナリア中に旧バージョンが落ちます。この場合はスキーマ変更を「追加して両方が読める状態を作る」「アプリを入れ替える」「使われなくなった列を消す」の三段階へ割り、各段階を別のリリースとして流してください。

関連記事

• カナリアリリースとは：露出制御そのものの仕組みと比率設計を詳しく扱っています
• ローリングアップデートとは：自動判定を入れる前段として選ぶ標準的な更新方式です
• ArgoCDとは：GitOpsでの配信側を担う仕組みで、Rolloutと組み合わせて使います
• Flux CDとは：Flaggerの提供元プロジェクトで、宣言的な同期の前提を確認できます
• DevOpsとは：判断を自動化する前に必要な、開発と運用の責務分担を整理しています