Cursor での CI/CD パイプライン設定：完全ガイド

継続的インテグレーションと継続的デプロイ（CI/CD）パイプラインは、ビルド、テスト、リリースのプロセスを自動化し、チームが安全かつ頻繁にコードをリリースできるようにします。モダンな CI/CD は複数のプラットフォームにまたがります — GitHub ホストプロジェクト用の GitHub Actions、GitLab リポジトリ用の GitLab CI、セルフホストで高度にカスタマイズ可能なパイプライン用の Jenkins です。Cursor は、統合された AI アシスタントと VS Code 互換の拡張モデルにより、パイプライン設定の作成と保守に優れたエディタです。自然言語プロンプトからワークフローを生成し、YAML 構文を検証し、プロジェクトの進化に合わせてパイプラインをリファクタリングできます。

本ガイドでは、Cursor での完全な CI/CD ワークフローをカバーします：GitHub Actions、GitLab CI、Jenkins の設定、自動テストの統合、AI を活用したパイプライン設定の生成と最適化、そして安全で信頼性の高い自動化のためのベストプラクティスです。

Cursor での CI/CD ツールのセットアップ

必須の拡張機能

Cursor は VS Code の拡張エコシステムを引き継いでいます。パイプライン作成を効率化するために以下をインストールします：

1. YAML（Red Hat 製）— GitHub Actions、GitLab CI、Docker Compose ファイルのスキーマ検証。
2. GitHub Actions — ワークフローファイルの構文ハイライトとスニペット。
3. GitLab Workflow — GitLab CI の検証と MR 管理。
4. Docker — Dockerfile の作成とイメージビルドのヘルパー。

ヒント

YAML 拡張機能は、よく知られたファイルタイプの JSON スキーマを自動的にダウンロードします。.github/workflows/deploy.yml を作成すると、Cursor は公式 GitHub Actions スキーマに対して構造を検証し、すべてのフィールドの自動補完を提供します。

CI/CD 用のプロジェクト構造

CI/CD 対応のプロジェクトには通常以下が含まれます：

project/
  ├── .github/
  │   └── workflows/
  │       ├── ci.yml
  │       └── deploy.yml
  ├── .gitlab/
  │   └── ci/
  │       └── templates.yml
  ├── .jenkins/
  │   └── Jenkinsfile
  ├── src/
  ├── tests/
  ├── Dockerfile
  ├── docker-compose.yml
  └── package.json

GitHub Actions

最初のワークフローの作成

GitHub Actions は .github/workflows/ 内の YAML ファイルを使用します。基本的な CI ワークフローはすべての push と pull request で実行されます：

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

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

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - name: Install dependencies
        run: npm ci

      - name: Lint
        run: npm run lint

      - name: Type check
        run: npm run type-check

      - name: Run tests
        run: npm test -- --coverage

      - name: Upload coverage
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: coverage-report
          path: coverage/
          retention-days: 14

ヒント

CI では npm install の代わりに npm ci を使用してください。ci コマンドは lockfile から正確なバージョンをインストールし、再現可能なビルドを生成し、lockfile の不整合を早期に検出します。

マトリックスビルド

マトリックスを使用して複数の Node.js バージョンとオペレーティングシステムでテストします：

jobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      fail-fast: false
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]
        node-version: [18, 20, 22]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: npm
      - run: npm ci
      - run: npm test

依存関係のキャッシュ

依存関係とビルド出力をキャッシュしてワークフローを高速化します：

- name: Cache npm
  uses: actions/cache@v4
  with:
    path: |
      ~/.npm
      node_modules
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-node-

警告

package-lock.json のハッシュのみに基づくキャッシュキーは、lockfile が変更されるとミスします。ランナー環境間の相互汚染を避けるため、キーに OS と Node バージョンを含めてください。

再利用可能なワークフロー

大規模なワークフローを再利用可能なコンポーネントに分割します：

# .github/workflows/reusable-test.yml
name: Reusable Test

on:
  workflow_call:
    inputs:
      node-version:
        required: true
        type: string

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ inputs.node-version }}
          cache: npm
      - run: npm ci
      - run: npm test

別のワークフローから呼び出します：

jobs:
  test:
    uses: ./.github/workflows/reusable-test.yml
    with:
      node-version: 20

デプロイメントワークフロー

main ブランチでのみ実行されるデプロイジョブ：

# .github/workflows/deploy.yml
name: Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    needs: test
    environment:
      name: production
      url: https://app.example.com
    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-deploy
          aws-region: us-east-1

      - name: Login to ECR
        uses: aws-actions/amazon-ecr-login@v2

      - name: Build and push
        uses: docker/build-push-action@v6
        with:
          context: .
          push: true
          tags: |
            123456789012.dkr.ecr.us-east-1.amazonaws.com/app:latest
            123456789012.dkr.ecr.us-east-1.amazonaws.com/app:${{ github.sha }}

      - name: Deploy to ECS
        run: |
          aws ecs update-service --cluster app-cluster --service app-service --force-new-deployment

警告

本番デプロイには必須レビューアーを設定した GitHub Environments を使用してください。これにより、デプロイジョブが実行される前に手動承認ゲートが追加され、誤ったリリースを防ぎます。

GitLab CI

.gitlab-ci.yml の設定

GitLab CI はリポジトリルートに単一の .gitlab-ci.yml を使用します：

# .gitlab-ci.yml
stages:
  - lint
  - test
  - build
  - deploy

variables:
  NODE_VERSION: "20"
  IMAGE_TAG: $CI_COMMIT_SHORT_SHA

cache:
  key:
    files:
      - package-lock.json
  paths:
    - node_modules/

lint:
  stage: lint
  image: node:${NODE_VERSION}
  script:
    - npm ci
    - npm run lint
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

test:
  stage: test
  image: node:${NODE_VERSION}
  script:
    - npm ci
    - npm test -- --coverage
  artifacts:
    reports:
      coverage_report:
        coverage_format: cobertura
        path: coverage/cobertura-coverage.xml
  coverage: '/Lines\s*:\s*(\d+\.\d+)%/'

build:
  stage: build
  image: docker:24
  services:
    - docker:24-dind
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$IMAGE_TAG .
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker push $CI_REGISTRY_IMAGE:$IMAGE_TAG
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

deploy:production:
  stage: deploy
  image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-ecs:latest
  script:
    - ecs update-task-definition --cluster app-cluster --service app-service --image $CI_REGISTRY_IMAGE:$IMAGE_TAG
  environment:
    name: production
    url: https://app.example.com
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
  when: manual

ヒント

GitLab CI の rules キーワードは古い only/except 構文を置き換えます。if 条件付きの rules を使用してジョブの実行タイミングを細かく制御し、changes と組み合わせて関連ファイルが変更されたときのみジョブをトリガーします。

GitLab CI テンプレート

複雑なパイプラインをインクルードファイルに分割します：

# .gitlab/ci/test.yml
.test-template:
  stage: test
  image: node:${NODE_VERSION}
  before_script:
    - npm ci
  script:
    - npm test

インクルードします：

include:
  - local: .gitlab/ci/test.yml

unit-test:
  extends: .test-template
  script:
    - npm run test:unit

並列およびマトリックスジョブ

test:
  stage: test
  image: node:${NODE_VERSION}
  parallel:
    matrix:
      - NODE_VERSION: ["18", "20", "22"]
        OS: ["alpine", "slim"]
  script:
    - npm ci
    - npm test

Jenkins

Jenkinsfile の作成

Jenkins パイプラインは Jenkinsfile 内の Groovy ベースの DSL を使用します：

// Jenkinsfile
pipeline {
    agent {
        docker {
            image 'node:20-alpine'
            args '-v $HOME/.npm:/root/.npm'
        }
    }

    environment {
        NODE_ENV = 'production'
        DOCKER_IMAGE = "registry.example.com/app:${env.BUILD_NUMBER}"
    }

    options {
        timeout(time: 30, unit: 'MINUTES')
        disableConcurrentBuilds()
        buildDiscarder(logRotator(numToKeepStr: '20'))
    }

    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }

        stage('Install') {
            steps {
                sh 'npm ci'
            }
        }

        stage('Lint') {
            steps {
                sh 'npm run lint'
            }
        }

        stage('Test') {
            steps {
                sh 'npm test -- --coverage'
            }
            post {
                always {
                    junit 'reports/junit.xml'
                    publishHTML(target: [
                        reportDir: 'coverage/lcov-report',
                        reportFiles: 'index.html',
                        reportName: 'Coverage Report'
                    ])
                }
            }
        }

        stage('Build') {
            steps {
                sh 'npm run build'
            }
        }

        stage('Deploy') {
            when {
                branch 'main'
            }
            steps {
                sh "docker build -t ${DOCKER_IMAGE} ."
                sh "docker push ${DOCKER_IMAGE}"
                sh "kubectl rollout restart deployment/app -n production"
            }
        }
    }

    post {
        failure {
            emailext subject: "Build failed: ${env.JOB_NAME} #${env.BUILD_NUMBER}",
                     body: "Check the build at ${env.BUILD_URL}",
                     to: '[email protected]'
        }
        success {
            slackSend channel: '#deploys',
                      message: "Build succeeded: ${env.JOB_NAME} #${env.BUILD_NUMBER}"
        }
    }
}

警告

Jenkinsfile は Jenkins コントローラーの権限で実行されます。信頼できない入力を含むコマンドを sh で呼び出さないでください。シェルインジェクションを防ぐため、補間変数は常に引用符で囲んでください。

宣言型パイプライン vs スクリプト型パイプライン

上記の例は宣言型構文を使用しています。複雑なロジックにはスクリプトブロックに移行します：

stage('Conditional Deploy') {
    steps {
        script {
            def env = params.ENVIRONMENT
            if (env == 'production') {
                input(message: 'Approve production deployment?', ok: 'Deploy')
            }
            sh "./deploy.sh ${env}"
        }
    }
}

Jenkins 共有ライブラリ

再利用可能なパイプラインロジックのために、共有ライブラリを定義します：

// vars/npmPipeline.groovy
def call(Map config = [:]) {
    pipeline {
        agent any
        stages {
            stage('Install') {
                steps {
                    sh 'npm ci'
                }
            }
            stage('Test') {
                steps {
                    sh 'npm test'
                }
            }
            stage('Build') {
                steps {
                    sh 'npm run build'
                }
            }
        }
    }
}

Jenkinsfile で使用します：

@Library('my-shared-lib') _

npmPipeline(nodeVersion: '20')

パイプラインでの自動テスト

ユニットテスト

- name: Run unit tests
  run: npm run test:unit -- --reporter=junit --outputFile=reports/junit.xml

GitHub Actions で結果を公開します：

- name: Publish test results
  uses: dorny/test-reporter@v1
  if: always()
  with:
    name: Unit Tests
    path: reports/junit.xml
    reporter: java-junit

統合テスト

データベースサービスコンテナに対して統合テストを実行します：

jobs:
  integration:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: test
          POSTGRES_DB: app_test
        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: 20
      - run: npm ci
      - run: npm run test:integration
        env:
          DATABASE_URL: postgresql://postgres:test@localhost:5432/app_test

ヒント

GitHub Actions のサービスコンテナは、統合テスト用の使い捨てデータベースを提供します。データベースの準備ができる前にテストが開始されないよう、常にヘルスチェック（--health-cmd）を含めてください。

エンドツーエンドテスト

CI で Playwright E2E テストを実行します：

e2e:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-node@v4
      with:
        node-version: 20
    - run: npm ci
    - name: Install Playwright browsers
      run: npx playwright install --with-deps
    - name: Run E2E tests
      run: npx playwright test
    - name: Upload report
      if: always()
      uses: actions/upload-artifact@v4
      with:
        name: playwright-report
        path: playwright-report/

セキュリティスキャン

依存関係とコードのスキャンを追加します：

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

- name: CodeQL analysis
  uses: github/codeql-action/init@v3
  with:
    languages: javascript-typescript

- name: Perform analysis
  uses: github/codeql-action/analyze@v3

- name: Trivy container scan
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: app:latest
    severity: CRITICAL,HIGH

AI支援パイプライン設定

プロンプトからワークフローを生成

Cursor の AI は説明から完全なパイプラインファイルを生成します。新しい .yml ファイルで Ctrl+K を開き、プロンプトを入力します：

Create a GitHub Actions workflow that: runs on push to main and on PRs,
sets up Node 20, installs dependencies with npm ci, runs lint, type-check,
and tests with coverage, builds a Docker image, pushes it to GitHub
Container Registry, and deploys to a Kubernetes cluster using kubectl.
Use caching and environment protections.

Cursor は完全で有効なワークフローを生成します。権限とシークレットを確認し、マトリックステストや Slack 通知の追加を依頼して改善します。

ヒント

CI/CD 設定のプロンプトでは、正確なプラットフォームとバージョンを指定してください。「Node 20 と Docker buildx を使用した GitHub Actions」は、「Node アプリ用の CI パイプライン」よりもはるかに優れた出力を生成します。

既存パイプラインの最適化

Cursor は遅いパイプラインを分析・最適化できます。ワークフローファイルをハイライトし、プロンプトを入力します：

Analyze this GitHub Actions workflow and suggest optimizations to reduce
runtime. Identify: missing cache opportunities, jobs that could run in
parallel, oversized images, and unnecessary steps.

AI が提案する一般的な最適化：

• 依存関係のキャッシュを追加。
• lint、テスト、ビルドを並列ジョブに分割。
• Docker レイヤーキャッシュを使用。
• 同じブランチの古い実行をキャンセル。

パイプラインテストの生成

プッシュ前に act を使用して GitHub Actions をローカルで実行します：

# Install act
brew install act

# Run a specific workflow locally
act -j test -W .github/workflows/ci.yml

Cursor にプロンプト：「このワークフローを act でローカル実行するためのテストイベントとモックシークレットのセットを生成してください。」

シークレット管理

GitHub Actions シークレット

シークレットはコードではなく、リポジトリまたは環境設定に保存します：

- name: Deploy
  env:
    API_KEY: ${{ secrets.API_KEY }}
    DATABASE_URL: ${{ secrets.DATABASE_URL }}
  run: ./deploy.sh

警告

GitHub はログ内のシークレット値をマスクしますが、シークレットがより大きな文字列の一部として表示される場合、構造化ログで漏洩する可能性があります。トークンを含む可能性のある完全なリクエストボディのログ出力を避け、secrets コンテキストは env または with でのみ使用し、エコーされる可能性のある run スクリプトでは使用しないでください。

GitLab CI 変数

deploy:
  variables:
    DATABASE_URL: $CI_DATABASE_URL
  script:
    - ./deploy.sh

GitLab UI で変数を「マスク」と「保護」としてマークし、保護ブランチでのみ表示されるようにします。

Jenkins 認証情報

環境変数の代わりに Credentials Store を使用します：

withCredentials([string(credentialsId: 'api-key', variable: 'API_KEY')]) {
    sh './deploy.sh'
}

Cursor での CI/CD のベストプラクティス

パイプラインを高速に保つ

• 依存関係とビルド出力をキャッシュ。
• 独立したジョブを並列実行。
• イメージビルドに Docker レイヤーキャッシュを使用。
• 新しいコミットがプッシュされたときに進行中の実行をキャンセル。

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

早期かつ明確に失敗させる

• テストの前に lint と型チェックを実行。
• 1つの失敗が残りを無効にするマトリックスジョブで fail-fast: true を使用。
• 失敗時に通知を送信（Slack、メール、Teams）。

アクションバージョンの固定

# 避ける — latest は予期せず壊れる可能性がある
- uses: actions/checkout@v4

# 推奨 — 再現性のためにコミット SHA に固定
- uses: actions/[email protected]

ヒント

サードパーティアクションはタグではなく、完全なコミット SHA に固定してください。タグはメンテナーによって移動される可能性があり、サプライチェーンセキュリティリスクとなります。SHA 固定は実行される正確なコードを保証します。

昇格に Environments を使用

GitHub Environments は保護ルール、必須レビューアー、デプロイ追跡を提供します：

deploy:staging:
  environment: staging

deploy:production:
  needs: deploy:staging
  environment:
    name: production
    url: https://app.example.com

パイプラインのデバッグ

失敗したジョブの再実行

GitHub Actions では失敗したジョブのみを再実行でき、時間とコンピュートリソースを節約できます：

gh run rerun <run-id> --failed

デバッグログの有効化

- name: Debug step
  env:
    ACTIONS_STEP_DEBUG: true
  run: echo "Detailed logs enabled"

リポジトリシークレット ACTIONS_STEP_DEBUG を true に設定して、詳細なランナーログを取得します。

ローカルでの YAML 検証

Cursor の YAML 拡張機能を使用して、入力中に構文を検証します。より深い検証には actionlint を使用します：

brew install actionlint
actionlint .github/workflows/*.yml

ヒント

Cursor はタスク設定で保存時に actionlint を実行できます。現在のファイルに対して actionlint を実行し、問題パネルにエラーを表示する .vscode/tasks.json エントリを追加します。

よくある落とし穴と回避方法

古いキャッシュ

無効化されないキャッシュは依存関係の変更を隠す可能性があります。常にキーに lockfile ハッシュを含めます：

key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}

無制限のジョブ増大

ログローテーションがないと、古いビルドが蓄積します。リテンションを設定します：

# GitHub: リポジトリ設定で設定
# Jenkins:
options {
    buildDiscarder(logRotator(numToKeepStr: '20'))
}

アーティファクトの if: always() 忘れ

失敗したジョブのアーティファクトはデフォルトでアップロードされません。失敗時でもテストレポートとカバレッジを取得するために if: always() を追加します。

警告

デプロイステップでの if: always() には注意が必要です — テスト失敗後にデプロイしたくないはずです。if: success() && github.ref == 'refs/heads/main' のような特定の条件を使用してください。

ログ内のシークレット

シークレットを echo しないでください。マスクされていても、シークレットが他の出力の部分文字列である場合、部分的な漏洩が発生します。シークレットスキャンツールを使用し、最初のデプロイ時にログを手動で確認します。

まとめ

Cursor は、GitHub Actions、GitLab CI、Jenkins にまたがる CI/CD パイプラインの作成と保守に強力なエディタです。YAML 拡張機能はスキーマ検証を提供し、サービスコンテナは統合テストを可能にし、AI アシスタントは自然言語プロンプトからパイプライン設定を生成、最適化、デバッグします。CI ワークフローのスキャフォールドから始め、自動テストとセキュリティスキャンを追加し、Cursor の AI に反復的な設定を任せて、信頼性が高く、高速で安全なデプロイのリリースに集中しましょう。