CI/CDパイプラインとは？基礎から設計・運用・計測まで徹底解説

ソフトウェアの配布スピードと品質を両立する仕組みがCI/CDパイプラインです。「コードを書いたらすぐにユーザーに届けたい」「でもバグは出したくない」－この相反する要求を実現する技術として、今や開発現場に欠かせない存在となっています。本記事では「定義」「構成要素」「設計と実装」「運用KPI（DORAなど）」まで、実務で使える形で分かりやすく整理します。

CI/CDパイプラインとは

基本的な定義

CI/CDパイプラインは、CI（継続的インテグレーション）とCD（継続的デリバリー/デプロイメント）を自動化する一連の工程です。

簡単に言うと、「コードを書いてからユーザーに届くまでの道のり」を自動化する仕組みです。手作業で行っていたビルド、テスト、デプロイといった作業を、機械に任せることで、ミスを減らし、スピードを上げることができます。

CIとCDの違いを理解しよう

CI（継続的インテグレーション）は、主に以下の作業を自動化します：

• コードのコンパイル（ビルド）
• 自動テストの実行
• コード品質のチェック

一方、CD（継続的デリバリー/デプロイメント）は：

• 検証済みのコードをサーバーに配置
• 本番環境への反映
• ユーザーが使える状態にする

イメージとしては、CIが「料理の下ごしらえと味見」、CDが「お皿に盛り付けてお客様に提供」という感じです。

パイプラインの基本概念

パイプラインは「流れ作業」のようなものです：

1. イベント（きっかけ）
   • コードをpush（アップロード）した
   • プルリクエスト（レビュー依頼）を作った
   • タグ（バージョン番号）を付けた
2. ジョブ（作業）
   • テストを実行する
   • ビルドする
   • デプロイする
3. アーティファクト（成果物）
   • ビルドされたアプリケーション
   • テスト結果レポート
   • 配布用パッケージ

これらが順番に、時には並行して実行されることで、効率的な開発フローが実現します。

導入で得られる効果

品質の向上

CI/CDを導入すると、以下のような品質向上が期待できます：

• 回帰バグの早期発見: 「以前は動いていたのに、新しいコードを追加したら壊れた」という問題をすぐに見つけられます
• 再現性のあるビルド: 「私の環境では動くのに…」という問題がなくなります
• コード品質の維持: 自動的にコードの書き方をチェックし、統一感のあるコードベースを保てます

スピードの改善

手作業で1時間かかっていたリリース作業が、ボタン一つで5分に短縮されることも珍しくありません：

• リードタイムの短縮: アイデアが実装されてからユーザーに届くまでの時間が大幅に短くなります
• デプロイ頻度の向上: 1ヶ月に1回だったリリースが、1日に何回でも可能になります
• フィードバックループの高速化: ユーザーの反応をすぐに次の開発に活かせます

可観測性の向上

すべての変更が記録され、追跡可能になります：

• 変更の可視化: 誰が、いつ、何を変更したかが一目瞭然
• 監査可能な履歴: コンプライアンスや規制対応に必要な証跡が自動的に残ります
• 問題の原因追跡: 不具合が発生した際、どの変更が原因かをすぐに特定できます

組織文化の変革

技術的な効果だけでなく、チームの働き方も変わります：

• 「小さく頻繁に出す」文化: 大きな変更を一度に出すのではなく、小さな改善を積み重ねる
• 失敗を恐れない文化: すぐに戻せるので、新しいことにチャレンジしやすくなる
• 協力的な文化: 自動化により、開発者と運用チームの壁がなくなる

パイプラインの標準ステージ

ソース取得／依存解決

パイプラインの最初のステップは、コードと必要なライブラリを準備することです：

yaml

# 例：Node.jsプロジェクトの場合
steps:
  - name: コードの取得
    uses: actions/checkout@v3
    
  - name: Node.jsのセットアップ
    uses: actions/setup-node@v3
    with:
      node-version: '18'
      
  - name: 依存関係のインストール
    run: npm ci  # package-lock.jsonから正確にインストール

ポイントは、毎回同じ環境を再現することです。

静的解析（Lint/Format/SAST）

コードを実行する前に、書き方をチェックします：

yaml

- name: コードスタイルのチェック
  run: |
    npm run lint        # ESLintでJavaScriptをチェック
    npm run format:check # Prettierで整形状態を確認
    
- name: セキュリティ脆弱性のスキャン
  run: |
    npm audit          # 依存関係の脆弱性をチェック
    # SASTツールでコード内の脆弱性を検出

これにより、レビュー時に「インデントが…」「変数名が…」といった議論を避けられます。

ビルド／パッケージ

ソースコードを実行可能な形式に変換します：

yaml

- name: アプリケーションのビルド
  run: |
    npm run build
    
- name: Dockerイメージの作成
  run: |
    docker build -t myapp:${{ github.sha }} .
    docker push myapp:${{ github.sha }}

コンテナ化することで、「どこでも同じように動く」アプリケーションが作れます。

テスト（ユニット→結合→E2E）

品質を保証する最も重要なステップです：

yaml

# ユニットテスト（個々の機能のテスト）
- name: ユニットテストの実行
  run: npm run test:unit
  
# 結合テスト（複数の機能の連携テスト）
- name: 結合テストの実行
  run: npm run test:integration
  
# E2Eテスト（ユーザー視点での動作テスト）
- name: E2Eテストの実行
  run: |
    npm run start:test &  # テスト用サーバーを起動
    npm run test:e2e      # ブラウザでの自動テスト

テストは「ピラミッド型」が理想的です：

• ユニットテスト（多い・速い・安定）
• 結合テスト（中間）
• E2Eテスト（少ない・遅い・不安定になりやすい）

セキュリティ・コンプライアンス

最近特に重要性が増している領域です：

yaml

- name: 脆弱性スキャン
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: 'myapp:${{ github.sha }}'
    
- name: ライセンスチェック
  run: |
    # 使用しているライブラリのライセンスを確認
    license-checker --onlyAllow 'MIT;Apache-2.0;BSD'
    
- name: SBOM（ソフトウェア部品表）の生成
  run: |
    syft myapp:${{ github.sha }} -o json > sbom.json

デプロイ戦略

本番環境への反映は慎重に行います：

yaml

# ステージング環境へのデプロイ
- name: ステージングデプロイ
  run: |
    kubectl set image deployment/myapp \
      myapp=myapp:${{ github.sha }} \
      -n staging
      
# 本番環境へのデプロイ（承認後）
- name: 本番デプロイ
  if: github.ref == 'refs/heads/main'
  environment: production  # GitHub環境保護ルール
  run: |
    kubectl set image deployment/myapp \
      myapp=myapp:${{ github.sha }} \
      -n production

検証・ロールバック

デプロイ後の確認も自動化します：

yaml

- name: ヘルスチェック
  run: |
    # デプロイ後のアプリケーションが正常か確認
    for i in {1..10}; do
      if curl -f https://myapp.com/health; then
        echo "アプリケーションは正常です"
        exit 0
      fi
      sleep 30
    done
    echo "ヘルスチェック失敗"
    exit 1
    
- name: 自動ロールバック
  if: failure()
  run: |
    # 前のバージョンに戻す
    kubectl rollout undo deployment/myapp -n production

設計の勘所（アーキテクチャ）

分岐と並列処理

時間のかかるテストは並列化して高速化します：

yaml

jobs:
  test:
    strategy:
      matrix:
        test-suite: [unit, integration, e2e]
    runs-on: ubuntu-latest
    steps:
      - name: ${{ matrix.test-suite }}テストの実行
        run: npm run test:${{ matrix.test-suite }}

これにより、3つのテストが同時に実行され、全体の時間が1/3になります。

キャッシュ戦略

毎回同じものをダウンロードするのは時間の無駄です：

yaml

- name: 依存関係のキャッシュ
  uses: actions/cache@v3
  with:
    path: ~/.npm
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-node-

アーティファクト管理

ビルドした成果物は適切に管理します：

yaml

- name: アーティファクトの保存
  uses: actions/upload-artifact@v3
  with:
    name: build-${{ github.sha }}
    path: dist/
    retention-days: 30  # 30日後に自動削除

バージョニングのベストプラクティス：

• コミットハッシュを使う（一意性が保証される）
• セマンティックバージョニング（v1.2.3）を併用
• タグ付けによるリリース管理

環境分離とドリフト防止

開発・ステージング・本番環境の差異（ドリフト）を防ぐには、Infrastructure as Code（IaC）が有効です：

terraform

# terraform/environments/production/main.tf
module "app" {
  source = "../../modules/app"
  
  environment = "production"
  instance_count = 3
  instance_type = "t3.medium"
  
  # 環境固有の設定
  enable_monitoring = true
  enable_backup = true
}

シークレット管理

パスワードやAPIキーは絶対にコードに含めません：

yaml

- name: データベース接続
  env:
    DB_PASSWORD: ${{ secrets.DB_PASSWORD }}  # GitHubシークレット
  run: |
    # 環境変数として安全に利用
    npm run migrate

ブランチ戦略

シンプルで効果的な戦略を選びましょう：

Trunk-Based Development（推奨）：

• mainブランチに頻繁にマージ
• 機能フラグで未完成機能を隠す
• シンプルで高速

Git Flow（従来型）：

• develop、release、hotfixなど複数ブランチ
• 複雑だが、リリースサイクルが明確
• 大規模チーム向け

ツール選定の視点

CI/CD基盤の比較

主要なツールとその特徴：

ツール特徴向いているケースGitHub ActionsGitHubと完全統合、豊富なマーケットプレイスGitHubユーザー、OSSGitLab CIGitLabに組み込み、強力な機能GitLabユーザー、オンプレミスJenkins老舗、プラグイン豊富、カスタマイズ性高大規模企業、複雑な要件CircleCI高速、並列処理に強いスタートアップ、高速開発

テストツール

用途別の主要ツール：

• ユニットテスト: Jest（JS）、pytest（Python）、JUnit（Java）
• E2Eテスト: Playwright、Cypress、Selenium
• 契約テスト: Pact（マイクロサービス間の約束事をテスト）

インフラ・デプロイツール

• IaC: Terraform（マルチクラウド）、Pulumi（プログラマブル）
• Kubernetes: Helm（パッケージ管理）、ArgoCD（GitOps）
• 監視: Prometheus + Grafana、Datadog、New Relic

セキュリティツール

• 依存関係: Dependabot、Renovate（自動更新）
• 脆弱性スキャン: Snyk、Trivy、OWASP Dependency Check
• コード分析: SonarQube、CodeQL

実装テンプレート（最小サンプル）

すぐに使える基本的なCI/CDパイプラインの例：

yaml

# .github/workflows/ci-cd.yml
name: CI/CD Pipeline

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

env:
  NODE_VERSION: '18'
  
jobs:
  # ステージ1: 品質チェック
  quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'npm'
          
      - name: Install dependencies
        run: npm ci
        
      - name: Lint
        run: npm run lint
        
      - name: Format check
        run: npm run format:check
  
  # ステージ2: テスト
  test:
    needs: quality
    runs-on: ubuntu-latest
    strategy:
      matrix:
        test-type: [unit, integration]
    steps:
      - uses: actions/checkout@v3
      
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'npm'
          
      - name: Install dependencies
        run: npm ci
        
      - name: Run ${{ matrix.test-type }} tests
        run: npm run test:${{ matrix.test-type }}
        
      - name: Upload coverage
        uses: actions/upload-artifact@v3
        with:
          name: coverage-${{ matrix.test-type }}
          path: coverage/
  
  # ステージ3: ビルド
  build:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'npm'
          
      - name: Install dependencies
        run: npm ci
        
      - name: Build application
        run: npm run build
        
      - name: Build Docker image
        run: |
          docker build -t myapp:${{ github.sha }} .
          docker save myapp:${{ github.sha }} > myapp.tar
          
      - name: Upload Docker image
        uses: actions/upload-artifact@v3
        with:
          name: docker-image
          path: myapp.tar
  
  # ステージ4: デプロイ（mainブランチのみ）
  deploy:
    if: github.ref == 'refs/heads/main'
    needs: build
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: Download Docker image
        uses: actions/download-artifact@v3
        with:
          name: docker-image
          
      - name: Load and push Docker image
        run: |
          docker load < myapp.tar
          # ここでレジストリにプッシュ
          
      - name: Deploy to production
        run: |
          # ここでKubernetesやECSにデプロイ
          echo "Deploying to production..."
          
      - name: Health check
        run: |
          # デプロイ後の確認
          echo "Checking application health..."

カスタマイズのポイント

このテンプレートを自分のプロジェクトに合わせるには：

1. 言語・フレームワークの変更
   • NODE_VERSIONを自分の言語に変更
   • npmコマンドを適切なものに置き換え
2. テストの調整
   • matrix.test-typeに必要なテストを追加
   • カバレッジの閾値を設定
3. デプロイ先の設定
   • 環境変数でデプロイ先を管理
   • 認証情報はシークレットに保存

デプロイ戦略の比較

Blue-Green デプロイ

2つの同じ環境を用意し、瞬時に切り替える方式：

yaml

# Blue-Green デプロイの例
- name: Deploy to Green environment
  run: |
    # 新バージョンをGreen環境にデプロイ
    kubectl set image deployment/myapp-green \
      myapp=myapp:${{ github.sha }} \
      -n production
      
- name: Health check Green
  run: |
    # Green環境の正常性を確認
    ./scripts/health-check.sh green
    
- name: Switch traffic to Green
  run: |
    # ロードバランサーをGreenに切り替え
    kubectl patch service myapp \
      -p '{"spec":{"selector":{"version":"green"}}}'
      
- name: Keep Blue as backup
  run: |
    # Blue環境は次回のデプロイまで保持
    echo "Blue environment kept as rollback option"

メリット：

• 即座にロールバック可能
• ダウンタイムなし
• シンプルで理解しやすい

デメリット：

• リソースが2倍必要
• データベース移行が複雑

Canary デプロイ

新バージョンに少しずつトラフィックを流す方式：

yaml

# Canary デプロイの例
- name: Deploy Canary (10%)
  run: |
    # 10%のトラフィックを新バージョンに
    kubectl set image deployment/myapp-canary \
      myapp=myapp:${{ github.sha }}
    kubectl scale deployment/myapp-canary --replicas=1
    
- name: Monitor metrics (5 minutes)
  run: |
    # エラー率やレスポンスタイムを監視
    ./scripts/monitor-canary.sh 5m
    
- name: Increase Canary (50%)
  run: |
    # 問題なければ50%に増加
    kubectl scale deployment/myapp-canary --replicas=5
    ./scripts/monitor-canary.sh 10m
    
- name: Full rollout
  run: |
    # 最終的に100%切り替え
    kubectl set image deployment/myapp \
      myapp=myapp:${{ github.sha }}
    kubectl scale deployment/myapp-canary --replicas=0

メリット：

• リスクを最小限に抑えられる
• 実際のユーザーでテスト
• 段階的な確認が可能

デメリット：

• 設定が複雑
• 監視体制が必要
• 時間がかかる

Feature Flags（機能フラグ）

コードは出すけど、機能のON/OFFを制御：

javascript

// アプリケーション内での実装例
if (featureFlags.isEnabled('new-checkout-flow')) {
  // 新しいチェックアウト機能
  return <NewCheckoutComponent />;
} else {
  // 従来の機能
  return <OldCheckoutComponent />;
}

yaml

# CI/CDでの機能フラグ管理
- name: Update feature flags
  run: |
    # 機能フラグの設定を更新
    curl -X POST https://feature-flag-service.com/api/flags \
      -H "Authorization: Bearer ${{ secrets.FF_API_KEY }}" \
      -d '{
        "flag": "new-checkout-flow",
        "enabled": true,
        "rollout_percentage": 10
      }'

メリット：

• デプロイと機能公開を分離
• A/Bテストが簡単
• 即座にOFF可能

デメリット：

• コードが複雑になる
• フラグの管理が必要
• 技術的負債になりやすい

セキュリティ（DevSecOps）

左シフトセキュリティ

セキュリティチェックを開発の早い段階で実施：

yaml

# 開発段階でのセキュリティチェック
- name: IDE設定の共有
  run: |
    # .vscode/settings.json
    {
      "eslint.rules": {
        "no-eval": "error",
        "no-implied-eval": "error"
      }
    }

# コミット時のチェック
- name: Pre-commit hooks
  run: |
    # .pre-commit-config.yaml
    repos:
      - repo: https://github.com/Yelp/detect-secrets
        hooks:
          - id: detect-secrets

署名付きサプライチェーン

コードからデプロイまでの改ざんを防止：

yaml

- name: Sign container image
  run: |
    # Cosignでコンテナイメージに署名
    cosign sign --key cosign.key myapp:${{ github.sha }}
    
- name: Generate SBOM
  run: |
    # ソフトウェア部品表の生成
    syft myapp:${{ github.sha }} -o spdx-json > sbom.json
    
- name: Sign SBOM
  run: |
    # SBOMにも署名
    cosign attach sbom --sbom sbom.json myapp:${{ github.sha }}
    cosign sign --key cosign.key myapp:${{ github.sha }}

ポリシーとガードレール

自動的にセキュリティポリシーを強制：

yaml

# OPA (Open Policy Agent) によるポリシー定義
- name: Policy check
  run: |
    # policy/security.rego
    package kubernetes.admission
    
    deny[msg] {
      input.request.kind.kind == "Pod"
      input.request.object.spec.containers[_].image
      not starts_with(input.request.object.spec.containers[_].image, "myregistry.com/")
      msg := "コンテナイメージは承認済みレジストリからのみ許可されます"
    }

可観測性とSLO

メトリクスの収集

パイプラインとアプリケーションの両方を監視：

yaml

# Prometheusメトリクスの例
- name: Record deployment metrics
  run: |
    # デプロイメトリクスを記録
    curl -X POST http://prometheus-pushgateway:9091/metrics/job/deployment \
      --data-binary @- <<EOF
    deployment_timestamp{environment="production",version="${{ github.sha }}"} $(date +%s)
    deployment_duration_seconds{environment="production"} ${DEPLOY_DURATION}
    EOF

ログとトレースの統合

デプロイIDで全体を追跡可能に：

javascript

// アプリケーション側の実装
const tracer = require('./tracer');

app.use((req, res, next) => {
  // デプロイIDをトレースに含める
  const span = tracer.startSpan('http_request');
  span.setTag('deployment.id', process.env.DEPLOYMENT_ID);
  span.setTag('version', process.env.APP_VERSION);
  next();
});

ダッシュボードの構築

チーム全体で共有するKPIダッシュボード：

yaml

# Grafanaダッシュボードの定義例
dashboard:
  title: "CI/CD Pipeline Metrics"
  panels:
    - title: "デプロイ頻度"
      query: "rate(deployment_timestamp[7d])"
      
    - title: "ビルド成功率"
      query: "sum(build_success) / sum(build_total) * 100"
      
    - title: "平均リードタイム"
      query: "avg(deploy_timestamp - commit_timestamp)"
      
    - title: "MTTR"
      query: "avg(incident_resolved_timestamp - incident_created_timestamp)"

KPI／DORA指標での評価

DORA指標とは

Google Cloud DevOps Research and Assessment チームが提唱する4つの指標：

1. デプロイ頻度
   • エリート: 1日に複数回
   • 高: 週1回〜月1回
   • 中: 月1回〜半年に1回
   • 低: 半年に1回未満
2. 変更のリードタイム
   • エリート: 1時間未満
   • 高: 1日〜1週間
   • 中: 1週間〜1ヶ月
   • 低: 1ヶ月以上
3. 変更失敗率
   • エリート: 0-15%
   • 高: 0-15%
   • 中: 0-15%
   • 低: 46%以上
4. サービス復旧時間（MTTR）
   • エリート: 1時間未満
   • 高: 1日未満
   • 中: 1日〜1週間
   • 低: 1週間以上

測定方法の実装

sql

-- デプロイ頻度の計算
SELECT 
  DATE_TRUNC('week', deployed_at) as week,
  COUNT(*) as deploy_count,
  COUNT(*) / 7.0 as daily_average
FROM deployments
WHERE environment = 'production'
  AND deployed_at >= CURRENT_DATE - INTERVAL '3 months'
GROUP BY week
ORDER BY week DESC;

-- リードタイムの計算
SELECT 
  AVG(EXTRACT(EPOCH FROM (deployed_at - committed_at)) / 3600) as avg_lead_time_hours,
  PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY deployed_at - committed_at) as median_lead_time
FROM deployments
WHERE deployed_at >= CURRENT_DATE - INTERVAL '30 days';

改善サイクルの実践

1. 現状測定: まず現在地を知る
2. ボトルネック特定: 最も時間がかかっている部分を見つける
3. 実験: 小さな改善を試す
4. 効果測定: 数値で確認
5. 定着: 効果があれば標準化

よくある落とし穴と対策

テストが遅い問題

問題: E2Eテストに1時間以上かかる

対策:

yaml

# テストの並列実行
test:
  strategy:
    matrix:
      shard: [1, 2, 3, 4]
  steps:
    - name: Run E2E tests (shard ${{ matrix.shard }}/4)
      run: npm run test:e2e -- --shard=${{ matrix.shard }}/4

フレークテスト（不安定なテスト）

問題: 同じコードなのに成功したり失敗したりする

対策:

yaml

- name: Run tests with retry
  uses: nick-fields/retry@v2
  with:
    timeout_minutes: 10
    max_attempts: 3
    command: npm test
    # 3回中2回成功すれば通過とする

環境ドリフト

問題: 「本番だけで起きる」問題

対策:

yaml

# すべての環境を同じTerraformモジュールで管理
- name: Apply infrastructure
  run: |
    terraform init
    terraform workspace select ${{ env.ENVIRONMENT }}
    terraform apply -auto-approve

手動作業の残存

問題: 「〇〇さんしかできない」作業

対策:

1. 手順書を作る
2. スクリプト化する
3. CI/CDに組み込む
4. 権限を適切に設定

秘密情報の漏洩

問題: パスワードがコードに書かれている

対策:

yaml

# 自動検出ツールの導入
- name: Detect secrets
  uses: trufflesecurity/trufflehog@main
  with:
    path: ./
    base: ${{ github.event.before }}
    head: ${{ github.event.after }}

導入ロードマップ（現実解）

フェーズ1: 現状把握（1-2週間）

まず、今どうやっているかを可視化：

markdown

## 現状の棚卸しチェックリスト
- [ ] ビルド手順（何分かかる？）
- [ ] テスト手順（自動化されている？）
- [ ] デプロイ手順（誰が実行？）
- [ ] 平均リードタイム測定
- [ ] 過去の障害と対応時間

フェーズ2: 最小パイプライン構築（2-4週間）

必要最小限から始める：

yaml

# 最初はこれだけでOK
name: Minimal CI
on: [push]
jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Build
        run: make build
      - name: Test
        run: make test

フェーズ3: 段階的拡張（1-3ヶ月）

少しずつ機能を追加：

1. Linterの追加: コード品質の自動チェック
2. E2Eテスト: 重要な機能だけでも
3. セキュリティスキャン: 最低限の脆弱性チェック
4. ステージング環境: 本番前の確認環境

フェーズ4: 観測とKPI（継続的）

効果を数値で確認：

yaml

# メトリクス収集ジョブの追加
- name: Collect metrics
  if: always()
  run: |
    echo "build_duration_seconds ${{ env.BUILD_DURATION }}" >> metrics.txt
    echo "test_success ${{ job.status == 'success' && '1' || '0' }}" >> metrics.txt
    # Prometheusなどに送信

フェーズ5: 継続的改善

ボトルネックを見つけて改善：

1. 最も遅い部分を特定
2. キャッシュや並列化を検討
3. 不要なステップを削除
4. 新しいツールの評価

FAQ

Q: CIとCDの違いは？

A: CIは「コードを統合してテストする」まで、CDは「本番環境に配布する」までです。CIは開発者向け、CDは運用・ユーザー向けと考えると分かりやすいです。

Q: 小規模プロジェクトでも導入メリットはある？

A: むしろ小規模なうちに導入する方が簡単です。1人プロジェクトでも、自動テストがあれば安心してリファクタリングできますし、デプロイの手間も省けます。

Q: モノレポ/ポリレポどちらが向く？

A:

• モノレポ: すべてのコードを1つのリポジトリに。シンプルだが、規模が大きくなると遅くなる
• ポリレポ: サービスごとにリポジトリを分ける。独立性は高いが、管理が複雑

小規模ならモノレポ、マイクロサービスならポリレポが一般的です。

Q: 規制対応（監査証跡）はどう担保？

A:

yaml

# 監査ログの自動記録
- name: Audit log
  if: always()
  run: |
    echo "{
      \"timestamp\": \"$(date -u +%Y-%m-%dT%H:%M:%SZ)\",
      \"user\": \"${{ github.actor }}\",
      \"action\": \"deployment\",
      \"target\": \"${{ env.ENVIRONMENT }}\",
      \"version\": \"${{ github.sha }}\",
      \"result\": \"${{ job.status }}\"
    }" >> audit.log

すべての変更を記録し、改ざんできないようにします。

Q: ロールバックを自動にするコツは？

A:

1. ヘルスチェックを充実させる: 問題を確実に検出
2. 閾値を明確にする: エラー率○%以上なら自動ロールバック
3. 前バージョンを保持: すぐに戻せる状態を維持
4. 通知を忘れずに: 自動でも人間に知らせる

用語集（初心者向け）

• CI (Continuous Integration): 継続的インテグレーション。コードを頻繁に統合し、自動的にビルド・テストすること
• CD (Continuous Delivery/Deployment): 継続的デリバリー/デプロイメント。テスト済みのコードを自動的に本番環境へ配布すること
• パイプライン: 一連の自動化された処理の流れ
• アーティファクト: ビルドの成果物（実行ファイル、Dockerイメージなど）
• SBOM: Software Bill of Materials。ソフトウェアに含まれる部品（ライブラリなど）の一覧
• SLO: Service Level Objective。サービスレベル目標
• MTTR: Mean Time To Recovery。平均復旧時間
• IaC: Infrastructure as Code。インフラをコードで管理すること
• GitOps: Gitを信頼できる唯一の情報源として、インフラやアプリケーションを管理する手法

まとめ／次のアクション

本記事の要点

1. CI/CDは品質とスピードを両立させる仕組み
2. 小さく始めて段階的に成長させる
3. 自動化により人的ミスを減らし、創造的な仕事に集中できる
4. 数値（DORA指標）で効果を測定し、継続的に改善する

今すぐできること

1. 現在の手作業を書き出す（10分）
2. 最小のCI設定を作る（30分）
3. チームで目標を共有する（1時間）

スターターキット

基本的なCI/CD設定ファイルとチェックリストを用意しました：

• GitHub Actions用設定ファイル
• GitLab CI用設定ファイル
• 導入チェックリスト
• トラブルシューティングガイド

これらのリソースで、すぐに始められます。

サポートのご案内

CI/CDパイプラインの導入・改善でお困りの際は、お気軽にご相談ください：

• 現状分析と改善提案
• パイプライン設計レビュー
• チーム向けワークショップ
• 継続的な改善支援

効率的で品質の高い開発プロセスの実現を、全力でサポートいたします。