デプロイ戦略 ― 頻度を上げてリスクを下げる ― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「開発運用アーキテクチャ」カテゴリ第8弾として、デプロイ戦略について解説する記事です。

現代は頻繁に・小さく・安全にデプロイする文化が主流。デプロイ頻度・失敗率・復旧速度は DORA 4指標の中核です。本記事ではローリング／Blue-Green／Canary／Feature Flag／Shadow Deployment／Dark Launchなどの戦略、ロールバック設計、AI時代の自動Canary判定まで解説します。

このカテゴリの他の記事

なぜデプロイ戦略が必要か

デプロイ失敗が最大の障害要因

Google SRE の報告では、本番障害の70%以上が変更（デプロイ・設定変更）起因です。デプロイ戦略が事故を減らします。2012年 Knight Capital 事件は「8台中1台の取り残し + 45分で4.4億ドル損失 + 倒産」というデプロイ事故の象徴例で、本記事のデプロイ戦略はまさにこの種の事故を防ぐためのものです（詳細は付録「重大インシデント事例集」）。

頻繁なデプロイが品質を上げる

「大きく・稀に」デプロイすると失敗時の影響範囲が巨大になります。小さく・頻繁にすれば1回の被害が小さく、切り戻しも容易になります。

ビジネススピードを支える

新機能を作っても1か月リリースできないのでは意味がありません。デプロイ戦略は技術的意思決定と同じくらいビジネス成果に直結します。

主要な戦略

デプロイ戦略には複数のパターンがあります。それぞれリスク・コスト・複雑度が違うため、システムに応じて使い分けます。

flowchart TB
    subgraph BG["Blue-Green"]
        BLUE[Blue<br/>v1 旧版] --> ROUTER1[Router] -.切替.-> GREEN[Green<br/>v2 新版]
    end
    subgraph CN["Canary"]
        ROUTER2[Router]
        ROUTER2 -->|95%| OLD[v1]
        ROUTER2 -->|5%→25%→100%| NEW[v2]
    end
    subgraph FF["Feature Flag"]
        APP[本番アプリ v2<br/>機能はOFF]
        APP -.|フラグON| FEATURE[新機能解放]
    end
    subgraph SH["Shadow"]
        REQ[本番リクエスト] --> V1[v1<br/>応答]
        REQ -.|並行| V2[v2<br/>結果は破棄]
    end
    classDef bg fill:#dbeafe,stroke:#2563eb;
    classDef cn fill:#dcfce7,stroke:#16a34a;
    classDef ff fill:#fef3c7,stroke:#d97706;
    classDef sh fill:#fae8ff,stroke:#a21caf;
    class BG,BLUE,GREEN,ROUTER1 bg;
    class CN,OLD,NEW,ROUTER2 cn;
    class FF,APP,FEATURE ff;
    class SH,REQ,V1,V2 sh;

戦略	内容	リスク
Rolling Update	順次置換	中
Blue-Green	2環境を切替	低・コスト2倍
Canary	一部ユーザーだけ新版	最低
Feature Flag	コードは本番・機能はOFF	最低
Recreate	全停止→新版起動	高
Shadow	本番と並行に新版走らせる	低・検証向き

中でも Canary が重要なのは、本番でしか見えない問題を早期に捕まえられるからです。テスト環境では再現できない本物のユーザー行動・本物のデータ分布・本物のトラフィックパターンに新版を少量だけ晒し、異常があれば影響ユーザーを最小限に抑えて撤退できます。ステージングで問題なかったのに本番で初めて壊れるケースは少なくなく、Canary はその最後の安全網になります。

ただし Canary にはそれなりの実装コストが伴います。リクエストを割合で振り分けるトラフィックルーティング（Service Mesh や Ingress の重み付け）、新旧のエラー率・レイテンシを比較するメトリクス自動判定（Flagger や Argo Rollouts など）が必要で、監視基盤が整っていない段階ではいきなり Canary から始めるのは困難です。だからこそ「Canary + Feature Flag」が現代の定石として語られ、細かく制御し問題時の影響を最小化する装備一式として採用されます。

Rolling Update

古いバージョンを順次新バージョンに置き換える方式です。Kubernetes のデフォルト戦略で、一部の Pod から新版に入れ替えていきます。シンプルで追加インフラ不要ですが、問題時の切り戻しに時間がかかる欠点があります。

メリット	デメリット
追加インフラ不要	切り戻しが遅い
シンプル	新旧混在が長い
K8s 標準	スキーマ変更で困る

マイナーな更新には適していますが、スキーマ変更や互換性のない変更には向きません。

Blue-Green Deployment

2つの本番環境（Blue・Green）を用意し、ロードバランサで切替する方式です。Blue が現行、Green が新版で、問題がなければトラフィックを Green に切替、問題あれば Blue に戻すだけです。

flowchart TB
    LB([Load Balancer])
    B1["Blue: v1.0<br/>全トラフィック"]
    G1["Green: v1.1<br/>待機中"]
    SW{切替}
    B2["Blue: v1.0<br/>待機中"]
    G2["Green: v1.1<br/>全トラフィック"]
    LB --> B1
    LB -.待機.-> G1
    B1 --> SW
    G1 --> SW
    SW --> B2
    SW --> G2
    classDef lb fill:#fef3c7,stroke:#d97706;
    classDef active fill:#dcfce7,stroke:#16a34a;
    classDef standby fill:#f1f5f9,stroke:#64748b;
    classDef sw fill:#fae8ff,stroke:#a21caf;
    class LB lb;
    class B1,G2 active;
    class G1,B2 standby;
    class SW sw;

メリット	デメリット
瞬時の切替・切り戻し	インフラコスト2倍
DB スキーマ変更も扱える	DB の共有で注意必要
検証環境として使える	データ整合性課題

Canary Deployment

新版を一部ユーザー（5% → 20% → 50% → 100%）に段階的に展開する方式です。問題があれば早期に検知でき、影響ユーザーを最小化できます。最も安全なデプロイ戦略として、SRE 組織では標準化しています。

段階	割合	観察期間
Phase 1	1〜5%	15分
Phase 2	20%	30分
Phase 3	50%	1時間
Phase 4	100%	-

各段階でエラー率・レイテンシを自動監視し、異常があれば自動ロールバックするのが理想です。Argo Rollouts・Flagger・Spinnaker などのツールが支援します。

Feature Flag（機能フラグ）

コードは本番にデプロイし、機能の ON/OFF を動的制御する方式です。デプロイとリリースを分離でき、「デプロイ済みだが誰にも見えない」状態を作れます。A/B テスト・段階リリース・緊急停止にも使えます。

ツール	特徴
LaunchDarkly	エンタープライズ定番
Flagsmith	OSS 版あり
Unleash	OSS・GitLab 統合
PostHog	分析と統合
独自実装	設定ファイル or DB

「コードのデプロイ」と「機能のリリース」を分離するのが現代的な発想で、リスクを大幅に下げられます。

データベースマイグレーション

DB スキーマ変更を伴うデプロイは最も難しい領域です。コードと DB の整合性を保ちながら、無停止で変更するには特別な設計が必要です。Expand and Contractパターンが標準です。

ステップ	内容
Expand	新旧両対応のスキーマに拡張
コード更新	新カラムを使い始める
Backfill	古いデータを新カラムに埋める
Contract	古いカラム削除

1リリースで全部やろうとすると本番停止します。複数回に分けて徐々に移行するのが現代的なベストプラクティスです。

自動ロールバック

デプロイ後に異常を検知したら自動で前バージョンに戻す仕組みです。人手による判断を待たないため、被害が最小化されます。監視指標（エラー率・レイテンシ・SLO）を見て自動判断します。

トリガー	例
エラー率急増	5xx 率が2倍
レイテンシ悪化	P95 が閾値超過
SLO 違反	バーンレート 10x 超
手動判断	ボタン1つで戻せる

人間のオペレーターに依存しないのが現代的で、24時間自動で守られる状態を作ります。

CI/CDパイプライン

デプロイ戦略を支えるのが CI/CD（Continuous Integration／Continuous Deployment）です。コードがコミットされたら自動でビルド・テスト・デプロイするパイプラインを構築します。

ツール	特徴
GitHub Actions	GitHub 統合・人気
GitLab CI	GitLab 統合
CircleCI	早期から SaaS
ArgoCD／Flux	GitOps K8s 特化
Jenkins	古参・高カスタマイズ

GitOps（Git を唯一の真実にしてデプロイ）が現代トレンドで、コミットがそのままデプロイになる運用が主流です。

Progressive Delivery

Canary・Feature Flag・自動判断を組み合わせた次世代デプロイ戦略です。「プログレッシブ（段階的）」にユーザーを新版に移行し、観測データで自動判断します。Argo Rollouts・Flagger がこの思想を体現しています。

要素	役割
段階的展開	ユーザー比率を徐々に増やす
メトリクス分析	SLI で自動判断
自動ロールバック	異常時は即座に戻す
A/B テスト統合	同時に効果測定

人間を介さないデプロイが実現でき、100% 自動化された SRE 組織の標準です。

判断基準①：トラフィック量

トラフィック量でデプロイ戦略が変わります。少量なら Rolling で十分、大規模なら Canary + Progressive 必須です。

トラフィック	推奨
低（社内ツール）	Rolling Update
中（B2C 一般）	Blue-Green or Canary
大（数百万 RPS＝Requests Per Second）	Canary + Feature Flag
超大（GAFA 規模）	Progressive + 自動判断

判断基準②：リスク許容度

金融・医療・決済のように障害コストが極めて高い業種は、最も慎重なデプロイが必要です。逆に実験的 B2C は高速デプロイ文化が向きます。

リスク許容度	推奨
高（SaaS 試験機能）	Feature Flag 中心・高頻度
中（一般 B2C）	Canary + 監視
低（金融・医療）	Blue-Green + 事前承認
最低（航空・原子力）	段階リリース + 長期検証

ケース別の選び方

個人開発・小規模Webサービス

GitHub Actions + Rolling Update（K8s 標準）。Feature Flag は設定ファイルや DB 列で自作、追加インフラ不要。CI 通過で本番自動デプロイ、問題あれば手動で前コミットに戻す運用で十分です。

スタートアップ・成長期B2C SaaS

GitHub Actions + Canary（Argo Rollouts）+ Feature Flag（Unleash／PostHog）。5%→20%→100% の3段階展開、エラー率・P95 レイテンシを自動監視して異常時は自動ロールバック。DB は Expand and Contract で無停止移行します。

中堅企業・マイクロサービス多数

ArgoCD（GitOps）+ Flagger + LaunchDarkly。サービスごとに独立デプロイ、Progressive Delivery で SLI ベース自動判断、Feature Flag は組織全体で統一管理。月数百回のデプロイが現実的になります。

金融・医療・決済

Blue-Green + 事前承認ワークフロー + Change Advisory Board（変更諮問委員会）。リリース時刻は業務時間外に固定、DB スキーマ変更は別リリースで先行適用、監査ログは永続保存。AI エージェントによる自動対応は要件次第で検討します。

よくある勘違い

リリース頻度が少ない方が安全

逆です。頻度が高いほど1回のリスクが小さく、筋肉が鍛えられます。Google は1日数千回デプロイしています。

Blue-Greenなら完璧

DB 変更の考慮なしには使えません。Expand and Contract が必要です。

Feature Flagを増やせば増やすほど安全

管理コストが爆発します。Flag のライフサイクル管理（使い終わったら削除）が必須。Feature Flag を気軽に増やし続けた結果、200個近く溜まってどれが現役でどれが死体か誰も分からなくなり、新人のオンボーディングで「Flag 一覧を読むだけで半日」という状態になった、という話は SaaS 現場で定期的に語られます。Flag はリリース時に削除タスクを必ずセットで切るのが唯一の処方箋です。

CIでテスト通ったら本番に出して良い

段階的展開が基本。いきなり100% はリスク高です。

DORA 4指標による数値Gate

※ 2026年4月時点の業界相場値です。テクノロジー・人材市場の変化で陳腐化するため、定期的にアップデートが必要です。

デプロイ戦略の質は DORA 4指標で測るのが世界標準です。

DORA指標	Elite	High	Medium	Low
デプロイ頻度	日複数回	週〜日次	月1〜週1	月1未満
変更リードタイム（コミット→本番）	1時間以内	1日〜1週間	1週間〜1か月	1〜6か月
変更失敗率	0〜15%	16〜30%	16〜30%	46〜60%
復旧時間（MTTR）	1時間以内	1日以内	1日〜1週間	1週間〜1か月

Canary展開の数値Gateは、Phase 1: 1〜5% で15分観察、Phase 2: 20% で30分、Phase 3: 50% で1時間、Phase 4: 100%。エラー率が旧版 + 0.5%超、または P99 > 旧版 × 1.2 で自動ロールバック。これが Argo Rollouts／Flagger 標準の判定基準です。

Elite レベルを目指すなら、日複数回デプロイ + 1時間以内復旧。Canary + Feature Flag が前提です。

デプロイ戦略の鬼門・禁じ手

デプロイで事故る典型パターン。どれも「会社を傾ける級」の破壊力を持ちます。

禁じ手	なぜダメか
全サーバーに一度に新版デプロイ	2012年 Knight Capital 事件（8台中1台に古いコード、45分で4.4億ドル損失）のパターン
Feature Flagを使わず全公開リリース	問題時に全ユーザー影響、切り戻し不能
DBマイグレーションとコードデプロイを同時	不整合時の切り戻し不能。expand／contractで分離
Feature Flagを使ったまま放置	200個溜まってどれが現役か不明、オンボーディング半日コース
CIでテスト通過＝本番100%展開	Canary なしは無謀、段階展開が必須
自動ロールバックなし	人間判断待ちで被害拡大、SLI ベース自動判断が必須
デプロイ時刻を業務ピーク時に設定	障害時の影響範囲最大化、業務時間外推奨
リリースノート・変更履歴を残さない	障害時の原因特定不能、Git と PR に必ず記録
ロールバック訓練を実施しない	いざという時に動けない、四半期1回の訓練必須
「大きく稀に」月1回のビッグバンリリース	DORA Low レベル、1回の失敗が致命的
デプロイ手順を個人の頭の中	担当者休暇で全停止、Runbook + IaC 化必須

2012年8月の Knight Capital事件（8台のうち1台に古いコードが残り、意図しない自動売買が45分で4.4億ドル損失、会社消滅）、2021年6月の Fastly グローバル障害（顧客の設定変更1回で世界中の主要サイトが1時間同時停止）──「デプロイ戦略の甘さ」が企業を消す典型事例です。

デプロイは「大きく稀に」が最悪。小さく頻繁に + Canary + 自動ロールバックが鉄則です。

AI時代の視点

AI 駆動開発（バイブコーディング）と AI 活用が前提になると、デプロイ戦略はAIが書いたコードを本番に出す仕組みとして重要性を増します。AI 生成コードは量が多く、人間が全件レビューできない前提に立つ必要があります。

AI時代に有利	AI時代に不利
小さな変更・高頻度デプロイ	大きなバッチデプロイ
Canary + 自動判断	人力判断だけ
Feature Flag 前提	全公開即時
自動テスト充実	手動テストメイン

AI が書く時代は安全に出せる仕組みがより重要になります。AI は時に大胆な変更を提案するため、Feature Flag で守られた状態でリリースするのが新常識です。

AI 時代はFeature Flag + Canaryが標準装備。AI の大胆さを安全に飼いならします。

決めるべきこと — あなたのプロジェクトでの答えは？

以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。

• デプロイ戦略（Rolling／Blue-Green／Canary）
• CI/CDツール（GitHub Actions等）
• Feature Flag採用（LaunchDarkly等 or 自作）
• 段階リリースの割合（5→20→50→100）
• 自動ロールバック基準（SLI閾値）
• DBマイグレーション戦略（Expand／Contract）
• デプロイ頻度の目標（日次・週次・月次）

筆者メモ — 「たった1回のデプロイ」が会社を消した事例

デプロイ戦略を甘く見て破綻した事例は、業界の歴史に何度も刻まれています。

2012年8月の Knight Capital事件は、その極北の教訓です。米国の大手マーケットメーカーだった Knight Capital は、新しい自動売買機能をリリースする際、8台の取引サーバーのうち1台に古いコードが残ったまま本番に出てしまいました。古いコードは新しいフラグを別の機能と誤認し、意図しない大量の自動売買を発動、わずか45分で約4億4千万ドル（当時の自己資本を上回る額）を失い、会社は事実上倒産しました。「デプロイ手順を1台だけ漏らす」というたった一つのヒューマンエラーが、一つの上場企業を消し去った象徴事例です。

もう一つ、2021年6月の Fastlyグローバル障害も有名です。大手 CDN ベンダーの Fastly で、顧客の設定変更1回が潜在バグを踏み抜き、Reddit・Amazon・英国政府サイト・NYT・CNN など世界中の主要サイトが約1時間同時に落ちました。「自分の本番だけ守っても、上流の設定変更1つで世界中が止まる」という、現代のデプロイリスクの深さを示した事件として語り継がれています。

どちらも「デプロイ戦略の甘さ」が致命傷で、Canary・Feature Flag・自動ロールバックの装備がなければ、ヒューマンエラーはそのまま企業の生死に直結することを突きつけます。

最終的な判断の仕方

デプロイ戦略の核心は頻度を上げて、リスクを下げるという逆説の両立です。大きく稀にデプロイすると1回の被害が巨大で切り戻しも重くなります。小さく頻繁にデプロイすれば、1回の失敗の影響は限定的で、筋肉が鍛えられ自動化が進みます。Google が1日数千回デプロイできるのは「安全に出せる仕組み」を積み上げた結果であり、Canary + Feature Flag + 自動ロールバックはそのための必須装備になりました。DB スキーマ変更も Expand and Contract で複数回に分けて移行するのが現代の定石です。

もう一つの決定的な軸はAIが書いたコードを安全に本番へ出すという要請です。AI 生成コードは量が多く人間が全件レビューできない前提に立つと、Feature Flag で守られた状態で Canary 展開し、SLI ベースで自動ロールバックする仕組みがあってはじめて AI の速度を活かせます。「Feature Flag + Canary + 自動判断」は、AI 時代の標準装備として必須になっています。

選定の優先順位

1. 小さく頻繁にデプロイする — 1回の失敗の影響を限定、筋肉を鍛える
2. Canary + Feature Flagを標準にする — デプロイとリリースを分離、影響最小化
3. SLIで自動ロールバック — 人間判断を待たず、被害を秒単位で止める
4. DB変更はExpand and Contract — 1リリースで全部やらず、段階移行で無停止化

「頻度を上げて、リスクを下げる」Feature Flag + Canary で AI の大胆さを飼いならします。

まとめ

本記事はデプロイ戦略について、Rolling・Blue-Green・Canary・Feature Flag・Progressive Delivery・自動ロールバック・DBマイグレーション無停止化まで含めて解説しました。如何だったでしょうか。

小さく頻繁にデプロイし、Canary+Feature Flagを標準にし、SLIで自動ロールバック、DB変更はExpand and Contractで無停止化する。これが2026年のデプロイ戦略の現実解です。

次回は監視とオブザーバビリティ（メトリクス・トレース・ログ統合）について解説します。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

それでは次の記事も閲覧いただけると幸いです。