Git でブランチを切ってプルリクエストを出し、IaC でインフラをコードにする、というところまでは分かった。けれど現場の人が「main にマージしたら、あとは CI/CD が本番まで持っていく」と言うとき、その間で何が起きているのかが見えない、という段階の人は多いはずです。
「自動で本番に出る」と聞くと怖く感じるかもしれません。実際の CI/CD は、自動で出す仕組みである以上に、決めた検査に落ちた変更を、自動で止める仕組みです。この記事では、コミットから本番までの流れと、どこで止まり、どう戻すのかを順に追います。
この記事の結論
- CI/CD は、コードの変更をきっかけにビルド・テスト・デプロイを毎回同じ順で自動に流す仕組みです。
- CI（継続的インテグレーション）は、変更を頻繁に合流させ、そのたびに自動でビルドとテストを回すことです。
- 継続的デリバリーは本番に出せる状態まで自動で用意し、継続的デプロイは本番への反映まで自動で行います。
- パイプラインは段の途中で失敗するとそこで止まり、壊れた変更を後ろの段に流しません。
- 本番の切り替えには、新旧の環境を入れ替えるブルー/グリーンと、一部の通信から試すカナリアがあります。
- AWS では CodePipeline が流れ全体を、CodeBuild がビルドとテストを、CodeDeploy が配布と切り替えを担います。
CI/CD とは｜変更を小さく、何度も、同じ手順で届ける仕組み
CI/CD は、1つのツールの名前ではなく、開発のやり方の名前です。AWS のホワイトペーパー「Practicing Continuous Integration and Continuous Delivery on AWS」は、継続的インテグレーション（CI）を「開発者が変更を定期的に中央のリポジトリへ合流させ、そのたびに自動でビルドとテストを実行するやり方」と説明しています。
たとえるなら、工場の検品ラインです。部品（コードの変更）が届くたびに、機械が同じ順番で組み立て（ビルド）と検査（テスト）を行い、不良が見つかればラインを止めます。人が毎回手で組み立てて目で検査するより、見落としが減り、どの部品で不良が出たかもすぐ分かります。
正確な言葉に戻すと、CI/CD が解いている問題は次の3つです。
| 手作業のリリースで起きること | CI/CD でどう変わるか |
|---|---|
| 変更をためてから一度に出すので、壊れたときに原因の変更を探しにくい | 変更ごとにビルドとテストが回り、どの変更で壊れたかがすぐ分かる |
| 人によって手順が少しずつ違い、「あの人の手元では動いた」が起きる | パイプラインの定義（コード）どおりに、毎回同じ手順で動く |
| 本番に出す作業そのものが重く、怖いので回数が減る | 出す作業が小さく軽くなり、戻す手順も用意されるので回数を増やせる |
2つ目の「定義がコード」という点は、前に読んだ IaC と同じ考え方です。パイプラインの手順もリポジトリに置き、レビューして変える対象になります。
READ ALSO — 学習中向け・段2 構成
IaC とは何か｜手作業との違いと宣言型、CloudFormation・CDK・Terraform の位置づけ
CI と CD は何が違うのか
CI/CD の「CD」には2つの意味があり、混ざって使われます。同じホワイトペーパーの定義で整理すると、次のようになります。
| 名前 | どこまで自動か | 本番への反映 |
|---|---|---|
| 継続的インテグレーション（CI） | 合流のたびにビルドとテスト | しない（本番とは切り離して考える） |
| 継続的デリバリー（CD） | ビルド・テストに加え、テスト環境などへの配布まで。本番に出せる状態を常に用意する | 本番に出す最後の一歩に、人の承認を挟める |
| 継続的デプロイ（CD） | 本番への反映まで | テストに通った変更は、人の明示的な承認なしに本番へ出る |
ホワイトペーパーは、継続的デリバリーの目的を「すべての変更をすぐ本番に出すことではなく、すべての変更をいつでも本番に出せる状態にしておくこと」と書いています。違いは自動化の技術ではなく、本番に出す最後の判断を誰がするか、です。
現場では、テスト環境までは自動で流し、本番の前で人が承認する継続的デリバリーから始めることが多くあります。テストが十分に揃い、戻す仕組みに自信が持てたところで、承認を外して継続的デプロイに寄せていきます。
CHECK 1ここまでの確認
継続的デリバリーと継続的デプロイの違いとして正しいのはどれ?
答えと解説
答え: 2. 継続的デリバリーは本番に出せる状態まで自動で用意し、本番への反映に人の判断を挟める。継続的デプロイは本番まで自動で反映する
どちらもビルドとテストは自動です。違いは本番に出す最後の一歩を人が決めるかどうか。「CI と CD は何が違うのか」の章を読み直してください。
パイプラインはどう流れて、どこで止まるのか
コミットから本番までの一連の流れをパイプラインと呼びます。AWS CodePipeline の用語では、パイプラインはステージ（段）の並びで、各ステージの中にアクション（そこで行う作業）を置きます。段と段の間はアーティファクト（ソースコードやビルドの成果物）で受け渡します。
COMMIT TO PRODUCTIONパイプラインの流れ
コミットは同じ順番の段を通って本番に届く
-
ソース
マージや push がきっかけ
-
ビルド
依存を入れて成果物を作る
-
テスト
単体・静的解析・結合
-
承認
本番の前で人が確認
-
デプロイ
テスト環境 → 本番
典型的な段は次のとおりです。
- ソース — main へのマージやタグの push をきっかけに、その時点のコードを取り出す
- ビルド — 依存ライブラリを入れ、コンパイルやコンテナイメージの作成を行う
- テスト — 単体テスト・静的解析・結合テストを回す（互いに独立したテストは同じ段で並列にできる）
- 承認 — 本番の前で人が確認する（継続的デリバリーの場合）
- デプロイ — テスト環境、次に本番へと配る
失敗したらそこで止まる
CodePipeline のドキュメントにあるとおり、ある段で失敗した実行はそこで止まり、パイプラインの最後まで流れません。テストが1つ落ちれば、その変更はデプロイの段に進みません。これが CI/CD の安全装置の本体です。
Linux のコマンドが返す「終了ステータス」が、ここで効いてきます。ビルドやテストのコマンドが 0 以外で終われば、その作業は失敗として扱われ、段が止まります。自動化の仕組みは、画面の文字ではなく、この成否で次に進むかを決めています。
止まったあとの扱いも用意されています。CodePipeline では、失敗した段を再試行したり、段の設定によって失敗時に直近の成功した実行まで自動で戻したりできます（設定できる条件は公式ドキュメントで確認してください）。
承認は「人が止めておく」段
手動承認のアクションを置くと、パイプラインはそこで止まり、誰かが承認するまで先に進みません。承認の依頼は Amazon SNS のトピックを通じてメールなどに届けられます。却下されるか、決められた期間内に応答が無ければ、その実行は失敗として扱われます。
WHERE IT STOPSパイプラインの門
検査に落ちた変更は、その段で止まって本番に届かない
パイプライン
- ビルド成果物ができた テストへコマンドが 0 で終わる
- テスト1つでも失敗 ここで止まる0 以外で終わる
- 承認却下・無応答 失敗として扱う人が止めておく段
- 本番アラーム 止めて前の版へエラー率などが基準を超える
CHECK 2ここまでの確認
パイプラインのテストの段で1つのテストが失敗したとき、既定で起きることはどれ?
答えと解説
答え: 1. その実行はそこで止まり、後ろの段（デプロイなど）には進まない
失敗した実行はパイプラインの最後まで流れずに止まります。止まることが、壊れた変更を本番に出さない安全装置です。「パイプラインはどう流れて、どこで止まるのか」の章を読み直してください。
AWS ではどのサービスが何を担うのか
AWS で CI/CD を組むときの主な部品は3つです。それぞれ担当する範囲がはっきり分かれています。
| サービス | 担うこと | 何で定義するか |
|---|---|---|
| AWS CodePipeline | 流れ全体の指揮。段の順番・きっかけ・承認・段どうしの受け渡し | パイプラインの定義（段とアクション） |
| AWS CodeBuild | ビルドとテストの実行。使うときだけ用意される環境でコマンドを動かす | リポジトリの buildspec.yml（段階ごとのコマンド・成果物・テストレポート） |
| AWS CodeDeploy | 配布と切り替え。EC2（とオンプレミスのサーバー）・Lambda・ECS へ新しい版を出す | appspec ファイル（何をどこに置き、切り替えの前後で何を確かめるか） |
AWS CodePipeline は指揮者で、自分ではビルドもデプロイもしません。ビルドの段では AWS CodeBuild を、デプロイの段では AWS CodeDeploy（や CloudFormation など）を呼び出します。
ソースの置き場所は、GitHub や GitLab、Bitbucket などの外部の Git を使うのが一般的です。CodePipeline からは AWS CodeConnections の接続を通じてこれらのリポジトリとつなぎ、push などをきっかけにパイプラインを動かせます。GitHub の場合は GitHub App を使った接続で、個人のアクセストークンを保管せずに済みます。
ビルドで秘密情報を扱うとき
データベースのパスワードのような値は、buildspec やパイプラインの定義に直接書きません。AWS Secrets Manager や Systems Manager のパラメータストアに置き、ビルドの実行時に参照して、ビルドのサービスロールには読み取りの権限だけを与えます。
GitHub Actions はどこに位置づくか
GitHub Actions は、GitHub が提供する CI/CD の仕組みです。リポジトリの .github/workflows に置いた YAML のワークフローが、push やプルリクエストなどのイベントで動き、ランナーと呼ばれるマシンの上でジョブを実行します。
役割で比べると、GitHub Actions は CodePipeline と CodeBuild の範囲を1つで担える仕組みです。よくある組み合わせは次の2つです。
- GitHub Actions で完結させる：ビルド・テストから AWS へのデプロイまでをワークフローに書く。AWS へは、長期のアクセスキーを GitHub に置かず、OIDC で一時的な認証情報を受け取る形が GitHub の公式ドキュメントで案内されています
- 役割で分ける：プルリクエストのテストは GitHub Actions で回し、main にマージされたあとの本番までの流れは CodePipeline が受け持つ
どちらが正しいというより、承認や本番の切り替え、ロールバックをどこで管理したいかで決めます。
本番へどう切り替えるのか｜インプレース・ブルー/グリーン・カナリア
テストに通っても、本番で初めて分かる問題は残ります。そこで CodeDeploy のようなデプロイの仕組みは、切り替え方そのものを選べるようにしています。
HOW TO SWITCH本番の切り替え方
本番は一度に替えないやり方を選べる
-
インプレース
動いているサーバーを順に新しい版へ
CodeDeploy では EC2・オンプレミスのみ
-
ブルー/グリーン
新しい環境を用意して、通信を切り替える
旧環境が残っていれば通信を戻せる
-
カナリア
一部の通信で様子を見て、残りを一度に移す
Lambda・ECS で選べる移し方
-
リニア
等しい割合ずつ、等しい間隔で移す
Lambda・ECS で選べる移し方
| 方式 | 何をするか | 戻すとき |
|---|---|---|
| インプレース | いま動いているサーバーを順に止めて新しい版に入れ替える（CodeDeploy では EC2・オンプレミスのみ） | 直前の正常な版を、もう一度デプロイし直す |
| ブルー/グリーン | 新しい版の環境（グリーン）を別に用意して確かめ、通信を旧環境（ブルー）から切り替える | 旧環境が残っていれば、通信を戻す |
| カナリア | 最初に一部の割合の通信だけを新しい版に流し、一定時間待ってから残りを一度に移す | 様子見の間に問題が出れば、残りを移さず戻す |
| リニア | 等しい割合ずつ、等しい間隔で少しずつ移す | 途中で問題が出れば、その時点で戻す |
CodeDeploy のドキュメントでは、Lambda と ECS へのデプロイで、カナリア・リニア・一括の3つの移し方を選べます。
戻す判断も自動にできます。CodeDeploy のデプロイグループに Amazon CloudWatch のアラーム（エラー率など）を関連付けておくと、デプロイ中にアラームが鳴ったときにデプロイを止め、直前の正常な版を新しいデプロイとして出し直すことができます。何を見てアラームを鳴らすかは、監視の設計そのものです。次に読む記事で扱います。
READ ALSO — 学習中向け・段2 構成
Amazon CloudWatch とは何か｜メトリクス・ログ・アラーム・ダッシュボードで「何を見れば何が分かるか」
CI/CD を入れても防げないこと
- テストが検出できない不具合は、パイプラインを素通りする（止まるのは検査に落ちたときだけ）
- データベースの変更のように「戻す」が効かないものは、切り替え方式だけでは戻せない
- パイプライン自身の権限が強すぎると、そこが本番を壊す入口になる
CHECK 3ここまでの確認
新しい版に最初はごく一部の通信だけを流し、様子を見てから残りを切り替える方式はどれ?
答えと解説
答え: 2. カナリア
カナリアは、最初に一部の割合を流して一定時間待ち、問題が無ければ残りを切り替えます。等間隔で少しずつ増やすのはリニアです。「本番へどう切り替えるのか」の章を読み直してください。
参照ソース
- Practicing Continuous Integration and Continuous Delivery on AWS — What is continuous integration and continuous delivery/deployment?（AWS ホワイトペーパー） — CI・継続的デリバリー・継続的デプロイの定義と違い（2026年9月時点の公開版）
- What is AWS CodePipeline?（AWS CodePipeline ユーザーガイド） — パイプライン・ステージ・アクションの役割（2026年9月時点）
- How pipeline executions work（AWS CodePipeline ユーザーガイド） — 失敗した実行が止まり、最後まで流れないこと（2026年9月時点）
- Configuring stage rollback（AWS CodePipeline ユーザーガイド） — 段の失敗時に直近の成功した実行へ戻す設定があること（2026年9月時点）
- Add a manual approval action to a stage（AWS CodePipeline ユーザーガイド） — 手動承認で止まること、SNS での通知、却下や無応答で失敗になること（2026年9月時点）
- GitHub connections（AWS CodePipeline ユーザーガイド） — CodeConnections の接続で GitHub をソースにすること（2026年9月時点）
- Build specification reference for CodeBuild（AWS CodeBuild ユーザーガイド） — buildspec の段階・成果物・レポート・Secrets Manager の参照（2026年9月時点）
- What is CodeDeploy?（AWS CodeDeploy ユーザーガイド） — 対象（EC2・オンプレミス・Lambda・ECS）と、インプレース／ブルー/グリーン（2026年9月時点）
- Working with deployment configurations in CodeDeploy（AWS CodeDeploy ユーザーガイド） — カナリア・リニア・一括の移し方（2026年9月時点）
- Redeploy and roll back a deployment with CodeDeploy（AWS CodeDeploy ユーザーガイド） — 失敗やアラームで、直前の正常な版を新しいデプロイとして出し直すこと（2026年9月時点）
- Understanding GitHub Actions（GitHub Docs） — ワークフロー・イベント・ジョブ・ランナーの説明（2026年9月時点）
- Configuring OpenID Connect in Amazon Web Services（GitHub Docs） — 長期の認証情報を置かずに OIDC で AWS に入る形（2026年9月時点）
