CI/CDの基礎
このドキュメントの目的
CI/CD（継続的インテグレーション / 継続的デリバリー） の基本概念を理解し、なぜ現代のSaaS開発において不可欠であるかを把握することが目標です。
IDサービスを題材にした具体例を使用しますが、設計原則自体はあらゆるSaaSに共通して適用できます。
CI/CDとは
3つの概念の違い
CI/CDは3つの段階に分かれます。それぞれ自動化の範囲が異なります。
継続的インテグレーション (CI)
┌──────────────────────────────────────────────────────────┐
│ コード変更 → ビルド → テスト → フィードバック │
│ │
│ 開発者が頻繁にコードを統合し、自動テストで品質を検証する │
└──────────────────────────────────────────────────────────┘
継続的デリバリー (CD)
┌──────────────────────────────────────────────────────────┐
│ CI + → ステージング環境へ自動デプロイ → 手動承認 → 本番 │
│ │
│ 本番リリースの「準備」までを自動化し、リリース判断は人が行う │
└──────────────────────────────────────────────────────────┘
継続的デプロイ (Continuous Deployment)
┌──────────────────────────────────────────────────────────┐
│ CI + → 自動デプロイ → 本番 │
│ │
│ テストを通過すれば自動的に本番環境にデプロイされ る │
└──────────────────────────────────────────────────────────┘
| 段階 | ビルド | テスト | ステージングデプロイ | 本番デプロイ |
|---|---|---|---|---|
| 継続的インテグレーション | 自動 | 自動 | 手動 | 手動 |
| 継続的デリバリー | 自動 | 自動 | 自動 | 手動（承認制） |
| 継続的デプロイ | 自動 | 自動 | 自動 | 自動 |
IDサービスの場合: 認証・認可という高い信頼性が求められる領域では、継続的デリバリー（本番リリース前に手動承認）が一般的です。すべてのテストが通っても、セキュリティ影響の確認やリリースノートの精査を人が行います。
なぜCI/CDが必要か
手動デプロイの課題
手動でビルド・テスト・デプロイを行う場合、以下の課題が生じます。
手動デプロイの問題:
開発者A ──push──▶ 本番サーバー ──手動デプロイ──▶ 障害発生!
│
「テスト忘れた」 │
「設定ファイルが違う」 │
「どのバージョンを入れた?」 │
▼
ロールバック不能
| 課題 | 具体例 |
|---|---|
| 人的ミス | テスト未実行、設定ミス、手順漏れ |
| 再現性のなさ | 「私の環境では動く」問題 |
| 速度の限界 | デプロイに数時間、リリース頻度が月1回に低下 |
| 追跡困難 | どのバージョンがどの環境にあるか不明 |
| ロールバック困難 | 問題発生時に前のバージョンに戻せない |
CI/CDによる改善効果
| 観点 | 手動 | CI/CD |
|---|---|---|
| デプロイ頻度 | 月1回 | 日に複数回 |
| リリースまでの時間 | 数日〜数週間 | 数分〜数時間 |
| 変更失敗率 | 高い（手順ミス） | 低い（自動化・テスト） |
| 復旧時間 | 数時間〜数日 | 数分（自動ロールバック） |
これらの指標はDORA メトリクス（DevOps Research and Assessment）として知られ、ソフトウェアデリバリーのパフォーマンスを測定する業界標準です。
CI/CDの構成要素
CI/CDパイプラインは以下の要素で構成されます。
┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐
│ ソースコード│──▶│ ビルド │──▶│ テスト │──▶│ アーティ │──▶│ デプロイ │
│ 管理 │ │ │ │ │ │ ファクト │ │ │
│ │ │ │ │ │ │ 管理 │ │ │
│・Git │ │・コンパイル│ │・ユニット │ │・Docker │ │・Staging │
│・ブランチ │ │・依存解決 │ │・統合 │ │ Image │ │・Production│
│・Pull Request│ │・静的解析 │ │・E2E │ │・JAR/WAR │ │・ロール │
│ │ │ │ │・セキュリティ│ │・バージョニ│ │ バック │
│ │ │ │ │ スキャン │ │ ング │ │ │
└───────────┘ └───────────┘ └───────────┘ └───────────┘ └───────────┘
1. ソースコード管理
すべてのCI/CDはソースコード管理（SCM）から始まります。
- バージョン管理: Gitによるコード変更の追跡
- ブランチ戦略: 開発・リリースのワークフロー制御
- トリガー: Push / Pull Request / タグ作成をきっかけにパイプライン起動
2. ビルド
ソースコードを実行可能な形式に変換します。
IDサービスの場合:
Java ソースコード
↓ Gradle build
JAR ファイル
↓ Docker build
Docker Image
↓ Push
Container Registry
3. テスト
品質を保証するための自動テストを実行します。
| テストの種類 | 目的 | 実行時間 |
|---|---|---|
| 静的解析（Lint） | コード規約・潜在バグの検出 | 数秒〜数分 |
| ユニットテスト | 個々の関数・クラスの動作検証 | 数秒〜数分 |
| 統合テスト | コンポーネント間の連携検証 | 数分 |
| E2Eテスト | 実際のユーザーシナリオ検証 | 数分〜数十分 |
| セキュリティスキャン | 脆弱性・依存ライブラリの検査 | 数分 |
4. アーティファクト管理
ビルド成果物を保存・バージョニングします。
- Docker Image: コンテナレジストリ（Docker Hub, ECR, GCR等）
- JAR/WAR: Maven Repository、S3等
- バージョニング: セマンティックバージョニング、Git SHA
5. デプロイ
アーティファクトをターゲット環境に配置します。
- 環境管理: Dev → Staging → Production の昇格
- デプロイ戦略: ローリング / Blue-Green / Canary
- ロールバック: 問題発生時の自動復旧
CI/CDツールの分類
SaaS型 vs セルフホスト型
| 特性 | SaaS型 | セルフホスト型 |
|---|---|---|
| 代表例 | GitHub Actions, CircleCI, GitLab.com | Jenkins, GitLab Self-Managed, Argo CD |
| インフラ管理 | 不要 | 自前で管理 |
| 初期コスト | 低い | 高い（構築工数） |
| カスタマイズ性 | 制限あり | 高い |
| セキュリティ | ベンダー依存 | 自社管理可能 |
| スケーラビリティ | プラン依存 | 自前でスケール |
主要ツールの比較
| ツール | 種別 | 特徴 |
|---|---|---|
| GitHub Actions | SaaS | GitHubとの統合が強力、YAML定義、マーケットプレイス |
| GitLab CI/CD | 両方 | GitLabに内蔵、Auto DevOps、セルフホスト可能 |
| Jenkins | セルフホスト | プラグイン豊富、高いカスタマイズ性、歴史が長い |
| CircleCI | SaaS | 高速な実行、Docker対応、設定がシンプル |
| Argo CD | セルフホスト | Kubernetes特化、GitOps、宣言的デプロイ |
| AWS CodePipeline | SaaS | AWSサービスとの統合、CodeBuild/CodeDeploy連携 |
IDサービスの場合: GitHub Actionsが広く使われています。オープンソースプロジェクトでは無料枠が利用でき、GitHub上のPull Requestとの連携が容易です。
CI/CDの成熟度モデル
CI/CDの導入は段階的に進めるのが効果的です。
レベル0: 手動 レベル1: CI導入
┌──────────────────────┐ ┌──────────────────────┐
│ ・手動ビルド │ │ ・自動ビルド │
│ ・手動テスト │───▶│ ・自動テスト │
│ ・手動デプロイ │ │ ・手動デプロイ │
│ ・バージョン管理なし │ │ ・Git管理 │
└──────────────────────┘ └──────────────────────┘
│
▼
レベル3: 継続的デプロイ レベル2: CD導入
┌──────────────────────┐ ┌──────────────────────┐
│ ・全自動デプロイ │ │ ・自動ビルド │
│ ・Feature Flags │◀───│ ・自動テスト │
│ ・カナリアリリース │ │ ・自動ステージングデプロイ│
│ ・自動ロールバック │ │ ・手動本番デプロイ │
└──────────────────────┘ └──────────────────────┘
| レベル | 状態 | 典型的な指標 |
|---|---|---|
| 0 - 手動 | ビルド・テスト・デプロイすべて手動 | リリース頻度: 月1回以下 |
| 1 - CI導入 | ビルド・テストが自動化 | リリース頻度: 週1回 |
| 2 - CD導入 | ステージングまで自動デプロイ | リリース頻度: 週数回 |
| 3 - 継続的デプロイ | 本番まで全自動 | リリース頻度: 日に複数回 |
各レベルへの移行で必要なこと
レベル0 → 1（CI導入）:
- Git導入とブランチ戦略の策定
- 自動ビルドスクリプトの作成
- ユニットテストの作成と自動実行
レベル1 → 2（CD導入）:
- ステージング環境の構築
- デプロイの自動化（Infrastructure as Code）
- 統合テスト・E2Eテストの充実
レベル2 → 3（継続的デプロイ）:
- 高いテストカバレッジと信頼性
- Feature Flagsによる段階的リリース
- 自動ロールバックの仕組み
- 監視・アラートの整備
CI/CDがもたらす開発文化の変化
CI/CDの導入は技術的な変化だけでなく、開発チームの文化にも影響を与えます。
| 観点 | CI/CDなし | CI/CDあり |
|---|---|---|
| コードレビュー | まとめてレビュー、大きな差分 | 小さなPull Request、頻繁なレビュー |
| テスト | リリース前にまとめて手動テスト | 変更のたびに自動テスト |
| リリース | 大きなリリース、高リスク | 小さなリリース、低リスク |
| 障害対応 | 原因特定に時間がかかる | 変更が小さいため原因特定が容易 |
| フィードバック | 遅い（数週間後に問題発覚） | 速い（数分でテスト結果） |
次のステップ
CI/CDの基本概念を理解しました。
次に読むべきドキュメント
- パイプライン設計 - パイプラインの構造と設計パターン
- CI/CDにおけるテスト戦略 - テストの自動化と品質ゲート
最終更新: 2026-03-04 対象: SaaS開発初心者・CI/CD未経験者