ci-cd-and-automation

CI/CD と自動化

概要

品質ゲートを自動化し、テスト、リンティング、型チェック、ビルドに合格しない変更が本番環境に到達しないようにします。CI/CD は、ほかのすべてのスキルを支える強制の仕組みです。人間やエージェントが見落とす問題を一貫して検出し、変更のたびに実行します。

シフトレフト： パイプラインのできるだけ早い段階で問題を検出します。リンティングで見つかったバグの修正には数分しかかかりませんが、本番環境で見つかった同じバグの修正には数時間かかります。チェックを前倒しし、テストの前に静的解析、ステージングの前にテスト、本番環境の前にステージングを行います。

より速いほうがより安全： バッチを小さくし、リリース頻度を高めると、リスクは増えるのではなく減ります。変更が30件あるデプロイより、3件あるデプロイのほうがデバッグしやすくなります。頻繁にリリースすることで、リリースプロセスそのものへの信頼が高まります。

使用する場面

• 新しいプロジェクトの CI パイプラインを設定するとき
• 自動チェックを追加または変更するとき
• デプロイパイプラインを設定するとき
• 変更をきっかけに自動検証を実行するとき
• CI の失敗をデバッグするとき

品質ゲートのパイプライン

すべての変更は、マージ前に次のゲートを通過します。

Pull Request Opened
    │
    ▼
┌─────────────────┐
│   LINT CHECK     │  eslint, prettier
│   ↓ pass         │
│   TYPE CHECK     │  tsc --noEmit
│   ↓ pass         │
│   UNIT TESTS     │  jest/vitest
│   ↓ pass         │
│   BUILD          │  npm run build
│   ↓ pass         │
│   INTEGRATION    │  API/DB tests
│   ↓ pass         │
│   E2E (optional) │  Playwright/Cypress
│   ↓ pass         │
│   SECURITY AUDIT │  npm audit
│   ↓ pass         │
│   BUNDLE SIZE    │  bundlesize check
└─────────────────┘
    │
    ▼
  Ready for review

ゲートを省略することはできません。 リンティングに失敗したらリンティングを修正してください。ルールを無効にしてはいけません。テストに失敗したらコードを修正してください。テストを省略してはいけません。

GitHub Actions の設定

基本的な CI パイプライン

# .github/workflows/ci.yml
name: CI

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

jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Lint
        run: npm run lint

      - name: Type check
        run: npx tsc --noEmit

      - name: Test
        run: npm test -- --coverage

      - name: Build
        run: npm run build

      - name: Security audit
        run: npm audit --audit-level=high

データベース統合テストを含む場合

  integration:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_DB: testdb
          POSTGRES_USER: ci_user
          POSTGRES_PASSWORD: ${{ secrets.CI_DB_PASSWORD }}
        ports:
          - 5432:5432
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'npm'
      - run: npm ci
      - name: Run migrations
        run: npx prisma migrate deploy
        env:
          DATABASE_URL: postgresql://ci_user:${{ secrets.CI_DB_PASSWORD }}@localhost:5432/testdb
      - name: Integration tests
        run: npm run test:integration
        env:
          DATABASE_URL: postgresql://ci_user:${{ secrets.CI_DB_PASSWORD }}@localhost:5432/testdb

注： CI 専用のテストデータベースであっても、認証情報をハードコードせず、GitHub Secrets を使用してください。これにより、適切な習慣が身につき、ほかの場面でテスト用認証情報を誤って再利用することを防げます。

E2E テスト

  e2e:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'npm'
      - run: npm ci
      - name: Install Playwright
        run: npx playwright install --with-deps chromium
      - name: Build
        run: npm run build
      - name: Run E2E tests
        run: npx playwright test
      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: playwright-report
          path: playwright-report/

CI の失敗をエージェントにフィードバックする

AI エージェントと CI を組み合わせる強みは、フィードバックループです。CI が失敗したときは、次のようにします。

CI fails
    │
    ▼
Copy the failure output
    │
    ▼
Feed it to the agent:
"The CI pipeline failed with this error:
[paste specific error]
Fix the issue and verify locally before pushing again."
    │
    ▼
Agent fixes → pushes → CI runs again

重要なパターン：

Lint failure → Agent runs `npm run lint --fix` and commits
Type error  → Agent reads the error location and fixes the type
Test failure → Agent follows debugging-and-error-recovery skill
Build error → Agent checks config and dependencies

デプロイ戦略

プレビュー環境へのデプロイ

手動テスト用に、すべての PR でプレビュー環境へデプロイします。

# Deploy preview on PR (Vercel/Netlify/etc.)
deploy-preview:
  runs-on: ubuntu-latest
  if: github.event_name == 'pull_request'
  steps:
    - uses: actions/checkout@v4
    - name: Deploy preview
      run: npx vercel --token=${{ secrets.VERCEL_TOKEN }}

フィーチャーフラグ

フィーチャーフラグを使うと、デプロイとリリースを切り離せます。未完成またはリスクのある機能をフラグで制御してデプロイすると、次のことができます。

• 機能を有効にせずにコードをリリースする。 早い段階で main にマージし、準備が整ったら有効にします。
• 再デプロイせずにロールバックする。 コードを元に戻す代わりに、フラグを無効にします。
• 新機能をカナリアリリースする。 まずユーザーの1％に有効化し、次に10％、最後に100％にします。
• A/B テストを実施する。 機能を有効にした場合と無効にした場合の動作を比較します。

// Simple feature flag pattern
if (featureFlags.isEnabled('new-checkout-flow', { userId })) {
  return renderNewCheckout();
}
return renderLegacyCheckout();

フラグのライフサイクル： 作成 → テスト用に有効化 → カナリアリリース → 全体展開 → フラグと不要なコードを削除。いつまでも残るフラグは技術的負債になります。作成時に削除日を設定してください。

段階的なロールアウト

PR merged to main
    │
    ▼
  Staging deployment (auto)
    │ Manual verification
    ▼
  Production deployment (manual trigger or auto after staging)
    │
    ▼
  Monitor for errors (15-minute window)
    │
    ├── Errors detected → Rollback
    └── Clean → Done

ロールバック計画

すべてのデプロイは元に戻せるようにします。

# Manual rollback workflow
name: Rollback
on:
  workflow_dispatch:
    inputs:
      version:
        description: 'Version to rollback to'
        required: true

jobs:
  rollback:
    runs-on: ubuntu-latest
    steps:
      - name: Rollback deployment
        run: |
          # Deploy the specified previous version
          npx vercel rollback ${{ inputs.version }}

環境管理

.env.example       → Committed (template for developers)
.env                → NOT committed (local development)
.env.test           → Committed (test environment, no real secrets)
CI secrets          → Stored in GitHub Secrets / vault
Production secrets  → Stored in deployment platform / vault

CI に本番環境のシークレットを持たせてはいけません。CI テストには専用のシークレットを使用してください。

CI 以外の自動化

Dependabot / Renovate

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: npm
    directory: /
    schedule:
      interval: weekly
    open-pull-requests-limit: 5

ビルド担当者の役割

CI を正常な状態に保つ責任者を決めます。ビルドが失敗したとき、ビルド担当者の仕事は修正するか元に戻すことであり、失敗の原因となった変更を行った人に任せることではありません。これにより、誰かが直すだろうという思い込みのもとで、ビルドの不具合が積み重なるのを防げます。

PR チェック

• 必須のレビュー： マージ前に少なくとも1件の承認を得る
• 必須のステータスチェック： マージ前に CI を通過する
• ブランチ保護： main への強制プッシュを禁止する
• 自動マージ： すべてのチェックに合格し、承認されていれば自動的にマージする

CI の最適化

パイプラインが10分を超える場合は、効果の大きい順に次の方法を適用します。

Slow CI pipeline?
├── Cache dependencies
│   └── Use actions/cache or setup-node cache option for node_modules
├── Run jobs in parallel
│   └── Split lint, typecheck, test, build into separate parallel jobs
├── Only run what changed
│   └── Use path filters to skip unrelated jobs (e.g., skip e2e for docs-only PRs)
├── Use matrix builds
│   └── Shard test suites across multiple runners
├── Optimize the test suite
│   └── Remove slow tests from the critical path, run them on a schedule instead
└── Use larger runners
    └── GitHub-hosted larger runners or self-hosted for CPU-heavy builds

例：キャッシュと並列処理

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '22', cache: 'npm' }
      - run: npm ci
      - run: npm run lint

  typecheck:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '22', cache: 'npm' }
      - run: npm ci
      - run: npx tsc --noEmit

  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '22', cache: 'npm' }
      - run: npm ci
      - run: npm test -- --coverage

よくある言い訳

言い訳	実際のところ
「CI が遅すぎます」	パイプラインを最適化してください（下記の CI の最適化を参照）。CI を省略してはいけません。5 分のパイプラインで、何時間ものデバッグを防げます。
「この変更は些細なものなので、CI を省略します」	些細な変更でもビルドを壊すことがあります。そもそも、些細な変更なら CI はすぐに終わります。
「テストが不安定なので、再実行すればいいです」	不安定なテストは本当のバグを隠し、全員の時間を無駄にします。不安定さを解消してください。
「CI は後で追加します」	CI のないプロジェクトでは、壊れた状態が積み重なります。初日からセットアップしてください。
「手動テストで十分です」	手動テストは拡張性がなく、再現性もありません。可能な限り自動化してください。

注意すべき兆候

• プロジェクトに CI パイプラインがない
• CI の失敗が無視または握りつぶされている
• パイプラインを通過させるために、CI でテストが無効化されている
• ステージングでの検証なしに本番環境へデプロイしている
• ロールバックの仕組みがない
• シークレットがコードまたは CI 設定ファイルに保存されている（シークレットマネージャーではなく）
• 最適化の取り組みがないまま CI に長い時間がかかっている

検証

CI のセットアップまたは変更後に、次の項目を確認してください。

• すべての品質ゲートがそろっている（lint、型チェック、テスト、ビルド、監査）
• すべての PR と main へのプッシュでパイプラインが実行される
• 失敗するとマージがブロックされる（ブランチ保護が設定されている）
• CI の結果が開発サイクルにフィードバックされる
• シークレットがコード内ではなく、シークレットマネージャーに保存されている
• デプロイにロールバックの仕組みがある
• テストスイートのパイプライン実行が 10 分未満で完了する