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

本記事について

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

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

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

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

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

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

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

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

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

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

主要な戦略

Rolling UpdateとBlue-Green

Rolling Updateは古いバージョンを順次新バージョンに置き換える方式で、Kubernetesのデフォルト戦略です。追加インフラ不要でシンプルな反面、切り戻しが遅く、新旧混在期間が長い。マイナーな更新には適していますが、互換性のない変更には向きません。

Blue-Greenは2つの本番環境を用意し、ロードバランサで切替する方式です。Blueが現行、Greenが新版で、問題がなければトラフィックをGreenに切替、問題あればBlueに戻すだけ。瞬時の切替・切り戻しが最大の強みで、弱点はインフラコストが2倍になることと、共有DBの整合性に注意が要ることです。

Canary — 本番でしか見えない問題を早期に捕まえる

Canaryは新版を一部ユーザー（1〜5%→20%→50%→100%）に段階的に展開する方式です。重要なのは、本番でしか見えない問題──テスト環境では再現できない本物のユーザー行動・データ分布・トラフィックパターン──に新版を少量だけ晒し、異常があれば影響を最小限に抑えて撤退できることです。各段階でエラー率・レイテンシを自動監視し、異常があれば自動ロールバックするのが理想形で、Argo Rollouts・Flaggerなどのツールが支援します。

ただしCanaryには実装コストが伴います。リクエストを割合で振り分けるトラフィックルーティングと、新旧のメトリクス自動比較が必要で、監視基盤が整っていない段階でいきなりCanaryから始めるのは困難です。

Feature Flag — デプロイとリリースを分離する

コードは本番にデプロイし、機能のON/OFFを動的制御する方式です。デプロイとリリースを分離でき、「デプロイ済みだが誰にも見えない」状態を作れます。A/Bテスト・段階リリース・緊急停止にも使えます。ツールはエンタープライズ定番のLaunchDarklyとOSSのUnleashが主役で、その他Flagsmith・PostHog、小規模なら設定ファイルやDB列での自作でも成立します。

Canary・Feature Flag・メトリクス自動判断を組み合わせた形はProgressive Deliveryと呼ばれ、人間を介さないデプロイを実現するSRE組織の標準になっています。

DBマイグレーションと自動ロールバック

DBスキーマ変更を伴うデプロイは最も難しい領域です。1リリースで全部やろうとすると本番が停止するため、Expand and Contractパターン（新旧両対応に拡張→コード切替→backfill→旧カラム削除）で複数回に分けて移行します。具体的なSQL例はCI/CDの記事で解説しています。

自動ロールバックは、デプロイ後に異常を検知したら自動で前バージョンに戻す仕組みです。トリガーはエラー率急増（5xx率が2倍）・レイテンシ悪化（P95が閾値超過）・SLOバーンレート超過など。人手による判断を待たないため被害が最小化され、24時間自動で守られる状態を作れます。

3つのシナリオで考える

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

GitHub ActionsとRolling Updateで十分だと思います。Feature Flagは設定ファイルやDB列での自作で問題なく、追加のインフラも要りません。CIを通過したら本番へ自動デプロイして、問題があれば手動で前のコミットに戻す、という運用から始めましょう。

個人・スタートアップ ― 1か月で出せる構成が正解 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-case-startup/

中小SaaS企業の場合

GitHub ActionsにCanary（Argo Rollouts）、Feature Flag（UnleashやPostHog）を組み合わせる段階です。5%→20%→100%の3段階展開でエラー率とP95レイテンシを自動監視して、異常時には自動ロールバックさせます。DBはExpand and Contractで無停止移行です。マイクロサービスが増えてきたらArgoCD（GitOps）とFlaggerでサービスごとの独立デプロイに進むと、月数百回のデプロイが現実的になってきます。

中小SaaS ― マネージドに寄せて少人数で回す ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-case-saas/

大企業・金融の場合

Blue-Greenに事前承認ワークフロー、Change Advisory Board（変更諮問委員会）を組み合わせた体制になります。リリース時刻は業務時間外に固定して、DBスキーマ変更は別リリースで先行適用、監査ログは永続保存とします。障害コストが極めて高い業種では、速度よりも確実に切り戻せることを優先するべきだと考えています。

大企業基幹系 ― 新しい技術より組織で成立する設計 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-case-enterprise/

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が前提になります。

AI判断軸 ― AIがデプロイ判断を補助する

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

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

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

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

AIにコード生成を任せる場合、Feature Flagを前提にしておくと安全にリリースできます。AIが書いたコードをFeature Flag配下に置き、まず社内ユーザーだけに公開→問題なければ段階的にロールアウト、という流れにすれば、AI生成コードの品質リスクを最小化できます。

やってはいけないこと

デプロイで事故る典型を、特に危険な6つに絞ります。どれも「会社を傾ける級」の破壊力を持ちます。

なおデプロイ時刻を業務ピーク時に設定する、ロールバック訓練を実施しない、といった運用面の緩みも事故の温床です。訓練は四半期1回が目安です。

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

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

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

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

決定理由の残し方 — ADRの例

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

ADRは docs/adr/ にMarkdownで保管し、戦略変更時には必ず新しいADRを起票するルールにしておくと判断の履歴がトレースできます。ADRの書き方全般はドキュメンテーションの記事で詳しく扱います。

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

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

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

この記事に関連する記事

まとめ

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

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

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

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

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

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