CI/CD とは？なぜ必要なのかを図解で理解する

2026年8月23日 最終更新日時 : 2026年9月7日 akinori

概要

「CI/CD を入れましょう」という言葉は現場で頻繁に飛び交いますが、いざ「CI/CD って結局なに？」と聞かれると答えに詰まる人は少なくありません。本記事では、CI/CD を 手作業のリリースで起きていた痛み から逆算して整理し、図で全体像をつかめるようにします。特定のツールに依存しない考え方を中心に、最後に GitHub Actions の最小例まで通します。

対象読者は次のような方です。

  • 名前は知っているが、何が嬉しいのか腹落ちしていない
  • チーム開発を始めて「なんとなく怖いデプロイ」を卒業したい
  • これから CI/CD を導入する立場になった

CI/CD の正体：2つの言葉に分解する

CI/CD は 2 つ（または 3 つ）の言葉の頭文字です。

略語 正式名称 ざっくり言うと
CI Continuous Integration（継続的インテグレーション） コードを頻繁に統合し、その都度自動でテストする
CD Continuous Delivery（継続的デリバリー） いつでもリリースできる状態を自動で保つ
CD Continuous Deployment（継続的デプロイ） 検証を通ったら自動で本番まで出す

CD は文脈によって「デリバリー」と「デプロイ」の 2 つの意味を持ちます。違いは 本番反映を人が押すか、全自動か の一点だけです。

Continuous Delivery : ...検証OK → [ 人が承認 ] → 本番
Continuous Deployment: ...検証OK →   （自動）   → 本番

なぜ必要なのか：手作業リリースの痛みを図で見る

CI/CD の価値は「導入前がどれだけ大変か」を見ると一気に理解できます。

Before：全部手作業のリリース

開発者A ──┐
開発者B ──┼─▶ 各自のPCで動作確認（環境バラバラ）
開発者C ──┘
              │
              ▼
   誰かがまとめてマージ ──▶ 手でテスト実行（やる人・やらない人）
              │
              ▼
   手順書を見ながら本番サーバへ手動デプロイ
   （コマンドの打ち間違い・手順抜け・深夜作業）
              │
              ▼
        本番で初めてバグ発覚 😱

この構造には、次のような典型的な痛みがあります。

  • 「私の環境では動く」問題：確認する環境が人によって違う
  • 統合が遅れて衝突が爆発：数日〜数週間ぶりにマージすると競合だらけ
  • テストの実行が属人化：忙しいと省略され、品質がブレる
  • デプロイが職人芸：手順書と気合い。担当者が休むと誰もリリースできない
  • 問題の発見が遅い：本番に出てから気づくため、修正コストが跳ね上がる

After：CI/CD を通したリリース

開発者が push / PR 作成
        │
        ▼
┌─────────────────────────────┐
│  CI（自動・毎回同じ環境）    │
│  1. コード取得               │
│  2. 依存インストール         │
│  3. Lint / 静的解析          │
│  4. 自動テスト               │
│  5. ビルド                   │
└─────────────┬───────────────┘
              │ 成功したらマージ
              ▼
┌─────────────────────────────┐
│  CD（自動）                  │
│  6. 成果物を作る             │
│  7. ステージングへデプロイ   │
│  8.（承認 or 自動）本番へ    │
└─────────────────────────────┘

ポイントは、「毎回・同じ手順・同じ環境で・自動的に」 実行されることです。人間の記憶力や気合いに品質を依存させないのが CI/CD の本質です。

CI がもたらす3つの効果

  1. 問題を早く見つける

小さな変更ごとにテストが走るため、壊れた瞬間に気づけます。「どの変更が原因か」も、直近の 1 コミットに絞り込めます。

  1. 統合の苦しみを分散する

毎日こまめに統合すれば、マージ競合は小さいうちに片付きます。「金曜の大統合大会」がなくなります。

  1. レビューの土台になる

テストが緑（成功）であることを PR の前提にできるため、レビュアーは「動くこと」の確認から解放され、設計や可読性に集中できます。

CD がもたらす効果

  • リリースが小さく・頻繁に・怖くなくなる

1 回のリリースに含まれる変更が小さいほど、問題の切り分けも切り戻しも簡単です。

  • 手順の属人化がなくなる

デプロイ手順がコード（パイプライン定義）として残るため、担当者依存が解消されます。

  • 切り戻し（ロールバック）も仕組みにできる

「前のバージョンに戻す」ことも自動化・手順化できます。

環境

本記事のサンプルは、次を前提にした最小構成です。

  • ホスティング: GitHub リポジトリ
  • CI/CD ツール: GitHub Actions
  • 対象: Node.js プロジェクト（他言語でも考え方は同じ）

CI/CD ツールには GitHub Actions のほか、GitLab CI/CD、CircleCI、Jenkins などがあります。どれを使っても「トリガー → 一連のステップを自動実行」という骨格は共通 です。

実装例：GitHub Actions の最小 CI

.github/workflows/ci.yml を置くだけで、push と Pull Request のたびにテストが自動で走ります。

name: CI

# いつ動かすか（トリガー）
on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      # 1. リポジトリのコードを取得
      - name: Checkout
        uses: actions/checkout@v4

      # 2. 実行環境（Node.js）を用意
      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: "20"
          cache: "npm"

      # 3. 依存をインストール
      - name: Install
        run: npm ci

      # 4. 静的解析（Lint）
      - name: Lint
        run: npm run lint

      # 5. 自動テスト
      - name: Test
        run: npm test

CI/CD の設定ファイルは、どのツールでもだいたい次の 3 要素で構成されます。この対応関係を覚えておくと、別ツールへ乗り換えても迷いません。

要素 意味 上の例での該当
トリガー いつ動かすか on:（push / pull_request）
実行環境 どこで動かすか runs-on: ubuntu-latest
ステップ 何をするか steps:（取得 → 準備 → テスト）

デプロイ（CD）を足すイメージ

CI が緑になったら、続けてデプロイの job を足します。「テストが通ったブランチだけデプロイする」という条件を付けるのが定石です。

  deploy:
    needs: test            # test が成功したときだけ動く
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build
        run: npm run build
      - name: Deploy
        run: ./scripts/deploy.sh   # デプロイ手順をコード化して置く

needs: test によって、テストが落ちたら絶対にデプロイされない ゲートを作れます。これが「壊れたものを本番に出さない」仕組みの正体です。

確認方法

  1. 上記 ci.yml をリポジトリに追加して push する
  2. GitHub の Actions タブを開くと、ワークフローの実行状況が緑（成功）／赤（失敗）で表示される
  3. わざとテストを壊して push すると、赤くなり、Pull Request 上にも失敗が表示されることを確認する
  4. Pull Request の「マージ前にチェックの成功を必須にする」設定（ブランチ保護ルール）を有効にすると、赤い PR はマージできなくなる

この「赤ではマージさせない」設定まで入れて初めて、CI が形骸化せず品質ゲートとして機能します。

注意点

  • テストが無いと CI は空箱：CI は自動で「テストを走らせる」だけです。中身のテストが薄ければ効果も薄い。まずは 1 本でもいいので自動テストを用意する。
  • 遅いパイプラインは使われなくなる：1 回 30 分かかると誰も待ちません。キャッシュ活用・並列化・重いテストの分離で高速に保つ。
  • 秘密情報はコードに書かない：API キーやトークンは必ず Secrets（GitHub なら Repository/Environment secrets）に置き、YAML やコードに直書きしない。
  • 全自動デプロイは段階的に：最初は「ステージングまで自動、本番は承認制（Continuous Delivery）」から始め、信頼がたまってから本番自動化（Continuous Deployment）へ進めると安全。

まとめ

  • CI/CD は「毎回・同じ手順・同じ環境で・自動で」統合とリリースを回す仕組み
  • CI は変更のたびに自動テストし、問題を早く小さく見つける
  • CD はいつでも安全に出せる状態を保ち、リリースの属人性と恐怖を消す
  • 設定ファイルの骨格は「トリガー → 実行環境 → ステップ」で、ツールが変わっても考え方は同じ
  • まず「push でテストが自動で走る」最小 CI から始め、「赤ではマージさせない」まで通すと効果が出る

CI/CD は大掛かりな仕組みに見えますが、出発点は YAML 1 枚です。小さく始めて、痛みを感じた部分から自動化を足していくのが、続けられる導入の近道です。

＼ 最新情報をチェック ／

カテゴリー
CI/CD
タグ

コメントを残す

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。

前の記事
main ブランチのCIが通ったら本番へ——自動デプロイ「ゲート」の落とし穴と設計手順
2026年8月22日
次の記事
GitHub Actions 入門 — ワークフローの基本構文
2026年8月23日