🚀【初心者向け】CI/CDとは何か？ビルド・テスト・デプロイの自動化をやさしく解説

開発現場でよく聞く言葉のひとつに、 CI/CDがあります。

GitHub ActionsやJenkinsを調べていると、 かなりの確率で登場する言葉です。

しかし、

• CIとCDは何が違うの？
• 結局、自動デプロイのこと？
• ビルドやテストもCI/CDなの？
• なぜわざわざ自動化する必要があるの？
• GitHub ActionsやJenkinsとの関係は？

と、全体像が見えにくい技術でもあります。

CI/CDを理解するうえで大切なのは、 ツールの使い方から覚えないことです。

まず、

コードを書く
   ↓
ビルドする
   ↓
テストする
   ↓
成果物を作る
   ↓
環境へ反映する

というソフトウェア開発の流れを理解すると、 CI/CDが何を解決しているのかが見えてきます。

この記事では、前半でCI/CDの基本を整理し、 後半ではPipeline、Artifact、Rollback、 Blue/Green Deployment、Canary Releaseなど、 実際のシステム運用につながるところまで掘り下げます。

---

結論：CI/CDは「変更を安全に届け続ける仕組み」

CI/CDをひと言で表すなら、

ソフトウェアの変更を継続的かつ安全に届けるための仕組み

です。

単なる「自動デプロイ」ではありません。

Developer
    ↓
  Commit
    ↓
   Build
    ↓
   Test
    ↓
 Artifact
    ↓
  Deploy

これまで人間が手作業で行っていた工程を、 できるだけ再現可能な形で自動化していきます。

その結果、

• 人為的ミスを減らす
• 問題を早く発見する
• 同じ手順を繰り返せる
• 変更を小さく頻繁に届けやすくする

といった効果が期待できます。

---

そもそもCIとは何か？

CIは、 Continuous Integrationの略です。

日本語では、 継続的インテグレーションと呼ばれます。

ポイントは、 開発者が行った変更を頻繁に統合し、 その変更が壊れていないか継続的に確認することです。

Developer A ─┐
             │
Developer B ─┼→ Repository
             │      ↓
Developer C ─┘    Build
                    ↓
                   Test

たとえばGitHubへコードをpushしたときに、 自動で、

• コンパイル
• 単体テスト
• 静的解析
• コード品質チェック

などを実行できます。

問題があれば、 本番環境へ進む前に気付けます。

---

CIがないと何が困るのか？

CIがない開発を考えてみます。

Aさん
↓
コード変更

Bさん
↓
コード変更

Cさん
↓
コード変更

数週間後
↓
まとめて統合

💥 動かない

変更を長期間ため込むほど、 どの変更が原因なのかを特定するのも難しくなります。

そこで、小さな変更を頻繁に統合し、 そのたびにビルドやテストを実行します。

小さく変更
   ↓
統合
   ↓
自動チェック
   ↓
問題発見
   ↓
早く修正

CIの重要な目的は、 統合時の問題をできるだけ早く見つけることです。

---

ではCDとは何か？

少しややこしいのがCDです。

CDという略語は、文脈によって主に次の2つを指します。

• Continuous Delivery
• Continuous Deployment

名前は似ていますが、意味は少し違います。

---

Continuous Delivery

Continuous Deliveryは、 継続的デリバリーです。

本番へリリースできる状態まで、 継続的に準備しておく考え方です。

Commit
 ↓
Build
 ↓
Test
 ↓
Release可能
 ↓
【人間が承認】
 ↓
Production

本番への最終リリースを、 人間が判断する構成も含まれます。

---

Continuous Deployment

Continuous Deploymentは、 継続的デプロイメントです。

一定の自動チェックを通過した変更を、 本番環境まで自動的にデプロイする考え方です。

Commit
 ↓
Build
 ↓
Test
 ↓
Deploy
 ↓
Production

Continuous Deliveryよりも、 自動化の範囲が本番反映まで伸びています。

そのため「CD」とだけ書かれている場合は、 DeliveryなのかDeploymentなのかを文脈から確認する ことが大切です。

---

CI/CD全体を図にするとどうなる？

かなり単純化すると、 次のように整理できます。

Developer
   │
   ↓
 Git Push
   │
   ├──── CI ────┐
   │             │
   ↓             │
 Build           │
   ↓             │
 Test            │
   ↓             │
 Artifact        │
   │             │
   └─────────────┘
   │
   ├──── CD ────┐
   │             │
   ↓             │
 Staging         │
   ↓             │
 Production      │
                 │
   └─────────────┘

ただし、 CIとCDの境界がすべての組織で完全に同じというわけではありません。

重要なのは言葉の境界線を暗記することより、 「変更を統合し、検証し、安全に届ける」という流れを理解することです。

---

Buildとは何をしているのか？

CI/CDで頻繁に登場するのが、 Buildです。

Javaなら、

Source Code
    ↓
Compile
    ↓
Test
    ↓
JAR / WAR

といった処理があります。

Dockerを利用している環境なら、

Source Code
    ↓
Build
    ↓
Docker Image
    ↓
Container Registry

のように、 Dockerイメージを成果物として扱う構成もあります。

前回の記事で扱ったDockerが、 ここでCI/CDとつながってきます。

---

Artifactとは何か？

CI/CDを理解するなら、 Artifact（成果物）も覚えておきたい言葉です。

Artifactとは、 ビルドなどによって作られ、 後続工程で利用する成果物です。

たとえば、

• JAR
• WAR
• 実行ファイル
• 配布用パッケージ
• Dockerイメージ

などがあります。

Source Code
    ↓
   Build
    ↓
 Artifact
    ↓
   Deploy

重要なのは、 テストしたものと本番へ出すものをできるだけ一致させる という考え方です。

環境ごとに別々に成果物を作り直してしまうと、 「テストしたもの」と「本番へ出したもの」に差が生まれる可能性があります。

---

Pipelineとは何か？

Build、Test、Deployなどの一連の工程を つないだものを、 Pipeline（パイプライン） と呼びます。

Commit
  ↓
Build
  ↓
Test
  ↓
Security Check
  ↓
Artifact
  ↓
Deploy

実際には、 すべてを一直線にする必要はありません。

たとえばテストを並列実行したり、 本番デプロイ前に承認ステップを入れたりできます。

つまりPipelineは、 ソフトウェアを届ける工程そのものをコードや設定として表現したもの と考えると分かりやすいでしょう。

---

GitHub ActionsやJenkinsは何なのか？

ここでようやく、 GitHub ActionsやJenkinsが登場します。

これらは、 CI/CDのPipelineを実行・自動化するために利用できるツールやサービスです。

CI/CD
＝ 考え方・仕組み

        ↓ 実現する

GitHub Actions
Jenkins
GitLab CI/CD
AWS CodePipeline
など

つまり、

CI/CD ＝ GitHub Actions

ではありません。

GitHub Actionsは、 CI/CDを実現する選択肢のひとつです。

先にCI/CDの考え方を理解しておけば、 利用するツールが変わっても全体像を見失いにくくなります。

---

ここまでのまとめ（初心者向け）

ここまでの内容を整理します。

• CI/CDは変更を継続的かつ安全に届けるための仕組み
• CIでは変更を頻繁に統合し、ビルドやテストなどで検証する
• CDはContinuous DeliveryまたはContinuous Deploymentを指す
• Artifactはビルドなどで作られる成果物
• PipelineはBuild・Test・Deployなどをつないだ処理の流れ
• GitHub ActionsやJenkinsはCI/CDを実現するための手段

特に、

Commit
 ↓
Build
 ↓
Test
 ↓
Artifact
 ↓
Deploy

という流れを頭に入れておけば、 CI/CD関連のサービスやツールを理解しやすくなります。

初心者向けとしては、ここまで理解できれば十分です。

---

▼▼ 深掘り編ここから ▼▼

---

CI/CDの本当の価値は「自動化」だけではない

CI/CDというと、

面倒な作業を自動化して楽をする仕組み

と思われがちです。

もちろん自動化も大きなメリットですが、 もう一つ重要なのが再現性です。

手作業でデプロイする場合、

担当者A
↓
手順①
↓
手順②
↓
設定変更
↓
デプロイ

となっていると、 担当者によって手順が微妙に変わる可能性があります。

CI/CD Pipelineとして定義すれば、

同じInput
   ↓
同じPipeline
   ↓
同じ処理

という状態を作りやすくなります。

つまりCI/CDには、 人間の頭の中にあるリリース手順を、再現可能な仕組みへ変換する という側面があります。

---

Pipeline as Codeという考え方

CI/CDの設定をコードや設定ファイルとして管理する考え方を、 Pipeline as Codeと呼ぶことがあります。

たとえばGitHub Actionsでは、 ワークフローをYAMLファイルとして管理できます。

Repository
├─ src/
├─ test/
└─ .github/
    └─ workflows/
         └─ ci.yml

これによって、

• Gitで変更履歴を管理できる
• レビューできる
• 誰が変更したか確認できる
• 過去の設定へ戻しやすい

といったメリットがあります。

アプリケーションコードだけではなく、 「どうビルドし、どうテストし、どう届けるか」までバージョン管理する わけです。

---

CI/CDとDockerはなぜ相性がいいのか？

前回の記事で、 Dockerイメージはアプリケーションと実行環境をまとめて扱えると説明しました。

これをCI/CDと組み合わせると、

Source Code
    ↓
     CI
    ↓
Docker Image
    ↓
Test
    ↓
Container Registry
    ↓
     CD
    ↓
Production

という流れを作れます。

テスト済みのDockerイメージをRegistryへ保存し、 そのイメージを本番環境へデプロイすれば、 環境ごとの差を減らしやすくなります。

さらにイメージへバージョンやコミットSHAなどを紐付けておけば、 どのソースコードから作られた成果物なのか も追跡しやすくなります。

---

「毎回ビルドする」より「同じArtifactを昇格させる」

CI/CD設計で重要なのが、 Build once, deploy many という考え方です。

たとえば、

Source
 ↓
Build
 ↓
Artifact v1
 ↓
Test環境
 ↓
Staging環境
 ↓
Production環境

のように、 同じArtifactを各環境へ進めていきます。

反対に、

Test用にBuild
Staging用にBuild
Production用にBuild

としてしまうと、 環境ごとに成果物そのものが異なる可能性があります。

テストで確認したArtifactそのものを本番まで昇格させることで、 「テストしたものを本番へ出す」 という状態を作りやすくなります。

---

Rollbackとは何か？

どれだけテストしても、 本番リリース後に問題が発生する可能性をゼロにはできません。

そこで重要になるのが、 Rollback（ロールバック）です。

Version 1
   ↓
Version 2 Deploy
   ↓
💥 障害発生
   ↓
Version 1へ戻す

CI/CDでは、 「どうデプロイするか」だけでなく、 問題が起きたときにどう戻すか まで設計しておくことが重要です。

ただし、アプリケーションだけを以前のバージョンへ戻せば 必ず復旧できるとは限りません。

たとえばデータベーススキーマを変更している場合、 旧バージョンのアプリケーションとの互換性がなくなっている可能性があります。

Application v2
      ＋
DB Schema v2

      ↓ Rollback

Application v1
      ＋
DB Schema v2

      ↓

互換性は大丈夫？

そのため実務では、 後方互換性を意識したDB変更なども重要になります。

---

Blue/Green Deploymentとは？

デプロイ方法にも複数の戦略があります。

代表的なもののひとつが、 Blue/Green Deploymentです。

現在稼働している環境をBlue、 新しいバージョンをGreenとします。

        Load Balancer
              │
              ↓
         Blue v1
         稼働中

Green v2
準備・確認中

Green側の準備が完了したら、 トラフィックを切り替えます。

        Load Balancer
              │
              ↓
         Green v2
         新バージョン

Blue v1
待機

旧環境を一定期間残せる構成なら、 問題発生時に切り戻しやすいというメリットがあります。

一方で、 BlueとGreenの両環境を用意するため、 一時的に必要なリソースやコストが増えることがあります。

---

Canary Releaseとは？

もうひとつ代表的なのが、 Canary Releaseです。

いきなり全ユーザーを新バージョンへ切り替えるのではなく、 一部のトラフィックだけを新バージョンへ流します。

Users
 │
 ├─ 95% → Version 1
 │
 └─  5% → Version 2

問題がないことを確認しながら、

5%
 ↓
20%
 ↓
50%
 ↓
100%

のように新バージョンの割合を増やしていきます。

障害の影響範囲を限定しながら、 本番トラフィックで新バージョンを確認できるのが特徴です。

---

Blue/GreenとCanaryは何が違う？

方式	基本的な考え方
Blue/Green	新旧2環境を用意し、トラフィックの向き先を切り替える
Canary	新バージョンへ流すトラフィックを少しずつ増やす

どちらが常に優れているというものではありません。

システム構成、コスト、リスク、 監視方法、データベースとの互換性などによって選択します。

---

CI/CDでは「テストに通った」だけでは足りない

CI/CD Pipelineを作ると、

Build成功
↓
Test成功
↓
Deploy成功

🎉 完了！

と考えたくなります。

しかし本番環境では、 デプロイ後の状態も確認する必要があります。

たとえば、

• エラー率
• レスポンスタイム
• CPU・メモリ使用率
• HTTPステータス
• アプリケーションログ
• ビジネス上重要な指標

などです。

Deploy
  ↓
Production
  ↓
Monitoring
  ↓
正常？
 ├─ YES → 継続
 └─ NO  → 停止 / 切り戻し

つまり、 CI/CDと監視は切り離して考えにくい ということです。

---

CI/CD Pipelineそのものも攻撃対象になる

CI/CDは本番環境へコードを届けられる強力な仕組みです。

だからこそ、 Pipeline自体のセキュリティも重要です。

たとえば、

• AWSのアクセスキーをリポジトリへ直接書かない
• Secret管理機能を利用する
• Pipelineへ必要以上の権限を与えない
• 依存パッケージや成果物の安全性を確認する
• 誰でも本番Pipelineを変更できる状態にしない

といった対策があります。

前々回の記事で扱ったIAMの 「最小権限の原則」 がここでもつながります。

IAM
 ↓
必要な権限だけ与える

Docker
 ↓
同じ実行環境を扱いやすくする

CI/CD
 ↓
検証した成果物を安全に届ける

Infrastructure & Cloudの技術は、 それぞれ独立しているのではなく、 少しずつ線でつながっています。

---

CI/CDでありがちな落とし穴

① Pipelineを作っただけで安心する

自動化されていても、 テスト内容が不十分なら問題を検出できません。

② Pipelineが遅すぎる

CIに毎回長時間かかると、 開発者が結果を待てなくなり、 CIを避ける動機につながることがあります。

③ 本番デプロイ権限が広すぎる

Pipelineが侵害された場合の影響範囲が大きくなります。

④ Rollbackを考えていない

「デプロイできる」と 「安全にデプロイできる」は別物です。

⑤ ツール導入そのものが目的になる

GitHub ActionsやJenkinsを導入すること自体が、 CI/CDの目的ではありません。

重要なのは、

変更をどのように検証し、安全かつ再現可能な形で届けるか

です。

---

CI/CDの全体像をもう一度整理する

Developer
    ↓
  Commit
    ↓
┌──────────────┐
│      CI      │
│              │
│ Build        │
│ Test         │
│ Check        │
└──────────────┘
    ↓
 Artifact
    ↓
┌──────────────┐
│      CD      │
│              │
│ Staging      │
│ Approval     │
│ Deploy       │
└──────────────┘
    ↓
 Production
    ↓
 Monitoring
    ↓
問題発生
    ↓
Rollback / 切り戻し

CI/CDは、 単純な「自動デプロイ機能」ではありません。

ソフトウェアの変更がコードから本番環境へ到達するまでの道を、 検証可能で再現可能な仕組みに変えていく考え方 なのです。

---

Deep Friendly Tech の一言（後書き）

CI/CDを学び始めると、 GitHub ActionsのYAMLやJenkinsfileなど、 どうしても「書き方」に目が向きがちです。

しかし、その裏側にある流れは意外と素朴です。

作る
 ↓
確かめる
 ↓
届ける
 ↓
見守る
 ↓
問題なら戻す

人間が慎重に行ってきたこの工程を、 機械が何度でも同じように実行できる形へ変えていく。

それがCI/CDを理解するうえでの大切な視点です。

そして、

IAM
  ↓
「誰が実行できる？」

Docker
  ↓
「何を動かす？」

CI/CD
  ↓
「どう安全に届ける？」

と考えると、 ここまで学んできたInfrastructure & Cloudの知識が ひとつのシステムとしてつながり始めます。

ツール名を覚えるだけでは見えなかった、 「なぜこの仕組みが必要なのか」。

そこまで見えるようになると、 CI/CDは単なる自動化ではなく、 ソフトウェアを安全に運ぶための「物流網」として見えてきます。📦