ブルーグリーンデプロイメントとは｜仕組み・他方式との違い・AWS/Kubernetes実装をコード例で解説

ブルーグリーンデプロイメント（Blue/Greenデプロイ、略してB/Gデプロイ）とは、本番と同等の環境を2系統用意し、稼働中の旧環境（Blue）と新バージョンの環境（Green）を並行させ、ロードバランサーやDNSの向き先を一気に切り替えてリリースする手法です。切り替えは瞬時で、不具合が出たら向き先をBlueへ戻すだけでロールバックできます。停止メンテナンスを伴う従来のIn-Placeデプロイと違い、ダウンタイムをほぼゼロにできる一方、2系統を同時に維持するためインフラコストは約2倍になり、データベースの後方互換という設計上の難所も伴います。

この記事では、Blue/Greenデプロイの仕組みと一連の流れ、カナリアリリース・ローリングデプロイとの違いと使い分け、メリットと採用すべきでない場面、つまずきやすいデータベースの整合性（expand-contract）、そしてKubernetesとAWS（CodeDeploy・ECSネイティブ）での実装を具体的なコードと設定値で解説します。最後に、自社の既存システムに合うかをどう見極め、どこから着手するかまで、受託開発の判断目線で整理します。

まとめ：Blue/Greenデプロイの要点と判断軸

Blue/Greenデプロイは「同等環境を2系統並べ、トラフィックの向き先を切り替えるだけでリリース・ロールバックする」手法です。瞬時の切り替えと即時ロールバックが最大の価値で、停止が売上や信頼に直結するサービス（ECサイト、オンラインバンキング、24時間稼働API）に向きます。逆に、データベースのスキーマ変更を伴う更新や、常時2系統を維持するコストが見合わない小規模・低頻度の社内システムでは、ローリングやIn-Placeのほうが妥当です。実装は、KubernetesならServiceのselectorを切り替える、AWSならCodeDeployまたはECSネイティブのトラフィック移行設定（all-at-once／カナリア／リニア）を使うのが定番です。成否を分けるのは切り替え機構そのものより、新旧バージョンが同じデータベースを壊さずに共存できるよう後方互換を設計できているか、という点にあります。

ブルーグリーンデプロイメントとは｜言葉の定義と切り替えの仕組み

Blue/Greenデプロイは2010年にMartin Fowler氏が紹介して広まった、リリース時のダウンタイムとリスクを下げるデプロイ戦略です。現在稼働している環境をBlue、新バージョンをデプロイする環境をGreenと呼び、両者を同じ構成で並行稼働させます。

ロードバランサーでBlue環境とGreen環境を切り替える仕組み

利用者のリクエストは、前段のロードバランサー（またはDNS・リバースプロキシ）を経由して現行のBlueへ届いています。新バージョンはBlueとは別系統のGreenへ先にデプロイし、本番トラフィックを受けないままヘルスチェックと動作確認を済ませます。問題がなければ、ロードバランサーの向き先をBlueからGreenへ切り替え、この瞬間に全リクエストがGreenへ流れる形です。Blueはすぐ停止せず、ロールバック用に一定時間そのまま残します。

デプロイから検証・トラフィック切り替え・待機までの一連の流れ

手順は「Greenへデプロイ→Greenで検証→トラフィックをGreenへ切り替え→Blueを待機（必要なら破棄）」の4段階です。切り替え後に異常を検知したら、向き先をBlueへ戻すだけで数秒〜数十秒でロールバックが完了します。In-Placeデプロイのように壊れた本番を修正しながら復旧する必要がなく、「直す」のではなく「戻す」で対応できるのが構造上の強みです。切り替えの前後で監視の目盛りを揃えておくと、異常検知から切り戻しまでを機械的に判断できます。

名前の由来・読み方・B/Gという略称が示す2系統ラベルの意味

「ブルー」「グリーン」という色は、どちらが新でどちらが旧という固定の意味はなく、2系統を区別するためのラベルにすぎません。切り替えのたびに役割は入れ替わり、次回リリースでは現Greenが新たなBlue（現行）になります。読み方はそのまま「ブルーグリーンデプロイメント」で、現場ではB/Gデプロイと略されます。

他のデプロイ方式との違い（In-Place・カナリア・ローリング）

Blue/Greenの位置づけは、他方式と比べると明確になります。判断軸は「切り替えの単位（全量か段階か）」と「ロールバックの速さ」「必要なリソース量」の3つです。

In-Placeデプロイとの違いとダウンタイムの有無や失敗時の比較

In-Placeは稼働中のサーバー上でアプリを直接上書きする方式です。追加環境が不要でコストは最小ですが、更新中はダウンタイムが発生し、失敗時は壊れた環境を直す必要があります。Blue/Greenは別系統へ先にデプロイするためダウンタイムがなく、ロールバックも向き先を戻すだけで済みます。この上書き方式の適用対象や事前検証・切り戻しの手順は、インプレースアップグレードの解説記事で詳しく扱っています。

カナリアリリースとの違いと段階的な比率移行を選ぶ場合の使い分け

カナリアリリースは、新バージョンへ最初は数%だけトラフィックを流し、問題がなければ段階的に比率を上げる方式です。Blue/Greenが「0%か100%か」の一括切り替えなのに対し、カナリアは「5%→25%→100%」と徐々に移します。実ユーザーの一部で本番検証しながら影響範囲を限定したいならカナリア、検証はGreenで済ませて一気に切り替え・即ロールバックを優先するならBlue/Greenが向きます。両者は排他ではなく、Green環境へカナリア的に段階移行する折衷も可能です。

ローリングデプロイとの違いとロールバック速度・リソース量の差

ローリングは稼働中のサーバー群を少しずつ新バージョンへ置き換える方式で、追加環境を最小限にしつつ無停止更新ができます。ただし更新中は新旧が混在し、完全移行まで時間がかかり、ロールバックも逆順の置き換えが必要で遅くなります。即時の全量切り替えと高速ロールバックを重視するならBlue/Green、リソースを抑えたいならローリング、という棲み分けです。

メリットとデメリット、インフラコストと採用すべきでない場面の整理

無停止リリースと数秒級ロールバックを両立できる点が主なメリット

最大のメリットは、無停止リリースと数秒級のロールバックを両立できる点です。Greenを本番トラフィックから隔離したまま検証できるため、リリース前に本番同等環境で最終確認ができ、切り替え後の異常も「戻す」操作だけで復旧します。これにより、リリースの心理的ハードルが下がり、デプロイ頻度を上げやすくなります。

本番同等の環境を常時2系統維持するインフラコストのデメリット

デメリットは明確で、本番同等の環境を2系統維持するためのコストです。常時2倍のサーバーを抱えるとランニングコストが増えるため、切り替え完了後にBlueを縮小・破棄してコストを戻す運用や、コンテナ・オートスケールで一時的にGreenを立ち上げる構成が現実解になります。また新旧が同じデータベースや外部サービスを共有する場合、その互換性管理（後述）が新たな複雑さとして加わります。

Blue/Greenを第一候補にすべきでない代表的な3つの場面

次のいずれかに当てはまるなら、Blue/Greenは第一候補にしないほうが無難です。第一に、後方互換にできない破壊的なデータベース変更を含むリリース。Blueへ即ロールバックしてもスキーマが戻らず、戻す利点が失われます。第二に、更新頻度が低く可用性要件も緩い社内システム。2系統のコストに見合いません。第三に、巨大なステートをローカルに持つアプリ（大きなインメモリキャッシュやローカルファイル依存）で、Green側のウォームアップに時間がかかり「瞬時切り替え」が成立しないケースです。これらではローリングやIn-Place、あるいはカナリアのほうが適します。

データベースと状態の整合性をどう保つか｜共有DBの後方互換の設計

Blue/Greenで最も事故が起きやすいのは切り替え機構ではなくデータ層です。新旧バージョンが同じデータベースを共有する以上、Greenの新コードが書き込んだデータをBlueが読めない、あるいはその逆、という非互換が起きるとロールバックが機能しなくなります。

共有DBでの後方互換とexpand-contractの3ステップ

定石は、スキーマ変更を「拡張（expand）→両対応→収縮（contract）」の3ステップに分け、1回のリリースで破壊的変更を完結させないことです。まず新旧どちらのコードでも動くようにカラムを追加（NULL許容や別名追加）し、両バージョンが新旧フィールドを並行して扱える状態を作っておきます。新バージョンが安定してから、次以降のリリースで旧カラムを削除する流れです。こうすればBlueへ戻しても旧コードが読み書きでき、ロールバックが安全に保てます。

-- 前提: 旧カラム is_verified を新カラム email_verified へ移行する
-- ステップ1: 拡張（旧コードを壊さず新カラムを追加。NULL許容で旧と並存）
ALTER TABLE users ADD COLUMN email_verified boolean;

-- ステップ2: 新旧両バージョンが is_verified と email_verified の両方へ書き込む
--（Greenの安定を確認）

-- ステップ3: 収縮（次以降のリリースで旧カラムを削除）
ALTER TABLE users DROP COLUMN is_verified;

セッションとキャッシュ、非互換マイグレーションを扱う際の注意点

セッションをアプリのメモリに持つ構成では、切り替え時にログイン状態が失われるため、セッションは外部ストア（RedisやDB）に逃がしておきます。キャッシュのキー設計がバージョン間で変わる場合は、名前空間を分けて互いを汚染しないようにします。どうしても後方互換にできない破壊的マイグレーションは、Blue/Greenの一括切り替えとは相性が悪いため、データ移行を別リリースに分離するか、メンテナンスウィンドウを設ける判断が必要です。

KubernetesでのBlue/Green実装｜Serviceのselector切り替え

Deploymentを2系統用意しServiceのselectorを切り替える手順

Kubernetesでは、同じアプリのDeploymentをversion: blueとversion: greenの2つ用意し、Serviceのselectorがどちらを指すかで本番トラフィックの向き先を決めます。Greenを先に適用してPodがReadyになったことを確認し、Serviceのセレクタをgreenへ書き換えれば一括で切り替わります。問題があればセレクタをblueへ戻すだけです。

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
    version: green   # blue から green へ書き換えて切り替え
  ports:
    - port: 80
      targetPort: 8080

# Greenを適用してReady確認後、セレクタを切り替える
kubectl apply -f deploy-green.yaml
kubectl patch service web -p '{"spec":{"selector":{"version":"green"}}}'

# ロールバックはセレクタを blue へ戻すだけ
kubectl patch service web -p '{"spec":{"selector":{"version":"blue"}}}'

Kubernetes自体の基礎はKubernetes（クーベネティス）とは？読み方・K8sの意味からの解説記事もあわせて参照してください。

Ingressやサービスメッシュを使った比率での段階移行の実装

Serviceセレクタの切り替えは0%か100%の一括移行です。比率を刻んで段階移行したい場合は、Ingressの重み付けルーティングや、IstioなどサービスメッシュのVirtualServiceでblue・greenへのトラフィック比率を制御します。これによりBlue/Greenの土台の上でカナリア的な段階移行も実現でき、まず数%だけGreenへ流して様子を見る、といった運用が組めます。

AWSでのBlue/Green実装（CodeDeployとECSネイティブ）

CodeDeployによるトラフィック移行設定の種類と選び方

AWSでBlue/Greenを行う代表的な方法がAWS CodeDeployです。ECS（FargateやEC2）やLambdaに対し、リスナーの向き先を新タスクセットへ切り替える形で動きます。トラフィックの移し方は事前定義の設定から選べ、一括・リニア・カナリアに対応します。事前定義された主な移行設定は次のとおりです。

• ECSAllAtOnce：全トラフィックを一括で新環境へ切り替える
• ECSLinear10PercentEvery1Minutes：毎分10%ずつリニアに移行する
• ECSLinear10PercentEvery3Minutes：3分ごとに10%ずつリニアに移行する
• ECSCanary10Percent5Minutes：先に10%流し、5分後に残り90%を移す
• ECSCanary10Percent15Minutes：先に10%流し、15分後に残り90%を移す

いずれも接頭辞はCodeDeployDefault.で、上記はその後半部分です。段階移行を選ぶと、途中でCloudWatchのアラームに引っかかった時点で自動的に切り戻せます。

ECSネイティブBlue/Green（2025年〜・CodeDeploy不要）

2025年7月にAmazon ECSはCodeDeployを使わずサービス単体でBlue/Greenを行うネイティブ機能を提供開始し、2025年10月にカナリア・リニアへ対応してCodeDeployと機能が同等になりました。2026年時点でAWSは新規構築ではECSネイティブを既定の選択肢として案内しています（CodeDeployも引き続き利用可）。ECSに特化した仕組みと設定はECSネイティブBlue/Greenデプロイメントとは何か？仕組みと概要を解説した記事で詳しく扱っています。

Elastic BeanstalkとAzureでの環境切り替えの方法

AWS Elastic Beanstalkでは、新バージョンを別環境にデプロイし、環境URLをスワップ（Swap Environment URLs）することでBlue/Greenを実現します。Azureの場合はApp Serviceのデプロイスロット（staging→productionのスワップ）が同じ役割を果たし、AKS（Azure Kubernetes Service）上ではKubernetesと同じくServiceやIngressで切り替えます。

CI/CDパイプラインへの組み込みとロールバックの自動化設計

GitHub Actions等での自動切り替えとヘルスチェック

Blue/Greenは手動切り替えでも成立しますが、本領を発揮するのはCI/CDへ組み込んだときです。ビルド・テストの後にGreenへデプロイし、ヘルスチェックの成功を確認してから切り替えコマンドを実行する、という流れをパイプライン化します。GitHub ActionsなどでのCI/CD連携の考え方はGitHubとCI/CDツールの統合のメリットを解説した記事が参考になります。

# GitHub Actions：Greenへデプロイ→Ready確認→トラフィック切替
- name: Deploy green
  run: kubectl apply -f deploy-green.yaml
- name: Wait for rollout
  run: kubectl rollout status deploy web-green
- name: Switch traffic to green
  run: kubectl patch service web -p '{"spec":{"selector":{"version":"green"}}}'

ロールバックの判断基準の数値化と自動での切り戻しの仕組みの設計

ロールバックは「いつ戻すか」を事前に数値で決めておくことが肝心です。エラーレートやレイテンシ、5xx応答率などのしきい値を定め、切り替え後の監視でこれを超えたら自動でBlueへ戻す仕組みへ落とし込みます。CodeDeployにはCloudWatchアラーム連動の自動ロールバックがあり、Kubernetesでも監視ツールのアラートからセレクタを戻すジョブの起動が可能です。戻すと決めてから人が判断していては遅れるため、判断基準の数値化と自動化が信頼性を左右します。

自社にBlue/Greenを導入すべきかの判断基準と構築の相談先

Blue/Greenは万能の正解ではなく、事業要件と運用体制に見合ってはじめて投資が回収できます。導入効果が高いのは、①停止が売上や信頼へ直結し無停止リリースの価値が大きい、②リリース頻度を上げたいが切り戻しの怖さがボトルネックになっている、③スキーマ変更を後方互換で設計する運用文化を持てる、といういずれかに当てはまる場合です。逆に、更新が年数回で可用性要件も緩い社内システムに2系統を常時抱えるのは過剰投資に傾きます。まずは既存のデプロイ方式のどこに痛みがあるかを言葉にし、その痛みをBlue/Greenが解くのかを確かめるところから始めます。

実際に難しいのは、切り替え機構そのものより、既存のデータベースと外部連携を壊さずに後方互換へ寄せる設計と、ロールバックを数値で自動化する運用づくりです。この上流の設計から本番運用までを、株式会社一創のAWSを中心としたクラウドインフラ構築・運用支援で伴走します。CodeDeployとECSネイティブのどちらから始めるべきか、共有DBの移行をどう段階化するか、といった判断段階からご相談いただけます。

よくある質問

ブルーグリーンデプロイメントについて検索されることの多い質問に答えます。

ブルーグリーンとカナリアの違いは？

Blue/Greenは0%か100%かの一括切り替え、カナリアは数%から段階的に比率を上げる移行です。即時の全量切り替えと高速ロールバックを優先するならBlue/Green、実ユーザーの一部で影響を限定しながら検証したいならカナリアが向きます。両者は排他ではなく、Green環境へカナリア的に少しずつ移す折衷も組めます。

ブルーグリーンデプロイのデメリットは？

本番同等の環境を2系統維持するコストが最大のデメリットです。加えて、新旧が同じデータベースを共有する場合の後方互換管理が複雑さとして加わります。切り替え後にBlueを縮小・破棄してコストを戻す運用や、コンテナで一時的にGreenを立ち上げる構成で緩和します。

データベースのスキーマ変更はどう扱う？

expand-contract（拡張→両対応→収縮）で段階的に変更し、1回のリリースで破壊的変更を完結させないのが定石です。まずNULL許容で新カラムを足し、新旧両バージョンが並行して読み書きできる状態を作ってから、次以降のリリースで旧カラムを削除します。こうすればBlueへ戻しても旧コードが動き、ロールバックが安全に保てます。

AWSではどう実装する？

CodeDeployでリスナーの向き先を新タスクセットへ切り替えるか、2025年に提供されたECSネイティブBlue/Greenを使います。2026年時点の新規構築ではECSネイティブが案内の中心です。どちらの方式も一括・カナリア・リニアのトラフィック移行に対応し、Elastic Beanstalkでは環境URLのスワップでも実現できます。

Kubernetesでの最小構成は？

version: blueとversion: greenの2つのDeploymentと、片方を指す1つのServiceがあれば成立します。Serviceのselectorをgreenへ書き換えれば切り替え、blueへ戻せばロールバックです。段階移行が要るなら、Ingressの重みやサービスメッシュを足して比率を制御します。

関連記事

• ECSネイティブBlue/Greenデプロイメントとは何か？仕組みと概要を解説：AWSでの最新の実装手段を掘り下げています。
• Kubernetes（クーベネティス）とは？読み方・K8sの意味から解説：Blue/Greenの土台となるKubernetesの基礎を扱っています。
• GitHubとCI/CDツールの統合のメリット：切り替えを自動化するCI/CD連携の考え方です。
• AKS（Azure Kubernetes Service）とは｜できること・料金・始め方を解説【2026年版】：Azure側でのKubernetes実装を解説しています。