チームで開発していると、「変更したらテストして、動いたら本番に上げる」という作業が毎日何度も発生します。これを毎回手でやるとミスも待ち時間も増える。そこを自動化するのが CI/CD です。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
これは何をする係？
CI/CD は、コードの変更を 自動でテストして届ける 流れ作業（※1 パイプライン）です。名前は2つの頭文字からできています。
- CI（継続的インテグレーション） — 変更のたびに 自動でビルド・テスト し、壊れをすぐ見つける
- CD（継続的デリバリー／デプロイ） — テストを通ったものを 自動で本番へ配る
工場のベルトコンベアを思い浮かべてください。部品（変更）を載せると、検査（テスト）を通り、合格したものだけが出荷（本番）される——それを人手なしで回すイメージです。
登場人物メモ:
- ※1 パイプライン — 取得→ビルド→テスト→配布と、自動でつながった一連の段取り
- ※2 ビルド — 書いたコードを、実際に動く形に組み立てる工程
この部分をもっと深く（中級）
CI/CD の本体は パイプライン——ソース取得→ビルド→テスト→デプロイと 自動でつながった段取り です。各段階を ステージ と呼びます。
アニメーション『CI/CDパイプラインの流れ』を開く
登場人物メモ:
- ※1 トリガ — パイプラインを起動させるイベント（push・プルリクエストなど）
- ※2 アーティファクト（成果物） — ビルドで出来た配布物。同じ物を各環境へ配る
- ※3 ロールバック — 問題が出たとき、1つ前の正常な状態へ戻すこと
仕事の流れ
- 開発者がコードの変更を送る（これが引き金）
- 自動で ビルド（※2 動く形に組み立て）される
- 自動で テスト され、壊れていないか検査される
- 通れば 自動で本番へ配られる（失敗したら止まって差し戻し）
大事なのは、この一連が 人の操作なしで一気に流れる こと。だから速く、ミスが減ります。
この部分をもっと深く（中級）
- push などの トリガ でパイプラインが起動する
- ビルド で成果物（アーティファクト）を作る
- テスト を通し、失敗したらそこで止めて差し戻す
- 通れば 環境 を段階的に進めて配る（開発→ステージング→本番）
同じ成果物を各環境へ運ぶのがコツです。環境ごとに作り直さないので、「本番だけ動かない」を防げます。
下の図は、push を引き金にビルド・テストが走り、成果物がレジストリ経由で本番へ届くまでを1手ずつ追ったものです。
アニメーション『CI/CDパイプラインの走行（push→build→test→deploy）』を開く
- 開発者 — 変更を push する人。ここから先は基本すべて自動で流れる
- CI — push を引き金に走る自動化係。ビルドとテストを順に実行する
- レジストリ — ビルドした成果物（イメージ）を保管する棚。各環境はここから同じ物を受け取る
- 本番 — 利用者に届く環境。テストを通った成果物だけがここへ配られる
0 / 6
自動化でうれしい理由
- 壊れをすぐ検知 — 変更した直後にテストが走るので、原因がすぐ分かる
- 手作業のミスが減る — 配る手順を人がやらないので、打ち間違いが起きない
- 待ち時間が消える — 「担当者が手で上げるのを待つ」がなくなる
小さな変更をこまめに流せるので、問題が起きても原因が絞りやすい のも利点です。
この部分をもっと深く（中級）
- 環境の段階 — いきなり本番ではなく、本番同等の ステージング で最終確認してから出す
- ロールバック（※3）— 問題が出たら すぐ前の版へ戻せる 備えを用意しておく
- 小さく頻繁に — 1回の差分を小さく保つと、壊れても原因の切り分けと戻しが容易
- 失敗は止める — テストが赤なら先へ進めない設定にし、壊れを本番の手前で堰き止める
なぜ小さく頻繁が安全か。大きな変更をまとめて出すと、失敗時に どの変更が原因か分からず、戻すと他の正常な変更まで巻き添えにします。小さければ、その1つを戻すだけで済みます。
⚠️ うまくいかないとき
- テストが甘い — 検査が薄いと、壊れたまま本番へ通ってしまう
- テストが遅い — 検査に時間がかかると、流れ全体が詰まる
- 失敗を無視 — 赤（失敗）を放置すると、自動化の意味が消える
この部分をもっと深く（中級）
- テスト不足 — 検査が薄いと、壊れが本番へ通り抜ける
- パイプラインが遅い — 検査に時間がかかると、開発全体が詰まる
- 環境差 — 本番とステージングの構成がずれると、通ったのに本番で落ちる
- 戻せない設計 — ロールバック手段がないと、障害時に復旧が長引く
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. 取得→ビルド→テスト→配布と、自動でつながった一連の段取りをカタカナで何と呼びますか。
問2. 書いたコードを、実際に動く形に組み立てる工程をカタカナで何と呼びますか。
問3. テストの途中で失敗が見つかったとき、CI/CDの望ましい動きは？
問4. CI/CDを一言でいうと？
問5. CI（継続的インテグレーション）がするのは、次のどれ？
問6. CD（継続的デリバリー／デプロイ）がするのは、次のどれ？
問7. CI/CDのパイプラインが動き出す「引き金」に当たるのは？
問8. CI/CDを自動化してうれしい理由として、当てはまらないのはどれ？