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

本記事について

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

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

本記事のテーマについてさらに詳しく知りたい方は『AWSの基本・仕組み・重要用語が全部わかる教科書』も参考にしてみてください。

そもそもデプロイ戦略とは何か

デプロイ戦略とは、ざっくり言えば「新しいバージョンのソフトウェアを本番環境にどうやって届けるかの段取り」です。

道路工事を想像してください。全車線を一気に通行止めにして工事する（一括デプロイ）方法もあれば、1車線ずつ交互に工事して残りは通行させる（ローリングアップデート）方法もあります。さらに慎重にやるなら、まず裏道だけ新舗装にして問題ないか確認してからメイン道路に広げる（カナリアリリース）こともできます。ソフトウェアも同じで、「どの範囲に・どの順番で・どれだけの安全マージンを持って」新バージョンを展開するかを事前に決めておく工程がデプロイ戦略です。

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

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

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

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

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

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

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

主要な戦略

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

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

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

Rolling Update

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

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

Blue-Green Deployment

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

Canary Deployment

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

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

Feature Flag（機能フラグ）

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

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

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

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

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

自動ロールバック

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

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

CI/CDパイプライン

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

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

Progressive Delivery

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

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

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

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

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

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

ケース別の選び方

個人開発・小規模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 エージェントによる自動対応は要件次第で検討します。

DORA 4指標による数値Gate

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

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

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

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

AI判断軸

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

AIがデプロイ判断を補助する仕組み

Canaryデプロイ中のSLI（エラーレート・レイテンシ）の判定ロジックは、AIが解析・提案できる領域です。「Canaryの5%トラフィックでP99レイテンシが300ms超えたら自動ロールバック」のようなルールをコードで定義し、AIが過去のデプロイ履歴から閾値の妥当性を検証する運用が成立します。

また、デプロイ後のログ・メトリクスから異常を検知し、「前回デプロイとの差分で何が原因か」をAIが推定してSlackに通知する、という自動分析フローも普及しつつあります。

Feature FlagとAI生成コードの相性

AIにコード生成を任せる場合、Feature Flagを前提にしておくと安全にリリースできます。AIが書いたコードをFeature Flag配下に置き、まず社内ユーザーだけに公開→問題なければ段階的にロールアウト、という流れにすれば、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・自動ロールバックの装備がなければ、ヒューマンエラーはそのまま企業の生死に直結することを突きつけます。

決定理由の残し方

デプロイ戦略の選定は障害リスクとリリース速度に直結するため、なぜその戦略を選んだかを ADRとして残すことが重要です。

ADR は docs/adr/ に Markdown で保管し、デプロイ戦略の変更時には必ず新しい ADR を起票するルールにしておくと、判断の履歴がトレースできます。後から見返したとき「なぜこの選択をしたか」が一目でわかることが、ADR の最大の価値です。

この記事に関連する記事

まとめ

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

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

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

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

本記事で扱った内容の詳細は AWS CodeDeploy も合わせて参考にしてください。

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