なぜ「上級」CI/CDパイプラインが必要なのか
「テストは通っているのに、本番で壊れる」。基本的な GitHub Actions のワークフローに慣れた頃、多くの開発者がこの壁にぶつかります。本当に信頼できるパイプラインは、もう一段踏み込んだ設計から生まれます。
Antigravity のAIエージェント機能を使いながら、以下の上級パターンを実装していきます。
- マトリクスビルド: 複数のNode.jsバージョン・OS・環境変数の組み合わせを並列テスト
- セキュリティゲート: SAST(静的アプリケーションセキュリティテスト)、依存関係の脆弱性監査、シークレット漏洩検知
- 自動リリース: Conventional Commits に基づくセマンティックバージョニングとCHANGELOG自動生成
- 高度なキャッシュ戦略: ビルド時間を劇的に短縮するレイヤードキャッシュ
対象読者は、GitHub Actions の基本(ワークフローファイルの作成、トリガー設定)を理解しており、より堅牢なパイプラインを構築したい中級〜上級開発者です。基本的な設定方法については「GitHub Actions × Antigravity 連携ガイド」をご参照ください。
マトリクスビルドの設計と最適化
マトリクス戦略の基本構造
マトリクスビルドは、複数の環境条件を組み合わせてテストを並列実行する仕組みです。Antigravity のエージェントに「マトリクスビルドのワークフローを生成して」と指示すれば、プロジェクト構成に応じた最適な設定を提案してくれます。
# .github/workflows/ci-matrix.yml
name: CI Matrix Build
on:
push:
branches: [main, develop]
pull_request:
branches: [main]
jobs:
test:
runs-on: ${{ matrix.os }}
strategy:
fail-fast: false # 1つ失敗しても他を継続
matrix:
os: [ubuntu-latest, macos-latest]
node-version: [18, 20, 22]
exclude:
- os: macos-latest
node-version: 18 # macOS + Node 18 は不要
include:
- os: ubuntu-latest
node-version: 22
coverage: true # 最新環境でのみカバレッジ取得
steps:
- uses: actions/checkout@v4
- name: Setup Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node-version }}
cache: 'npm'
- name: Install dependencies
run: npm ci
- name: Run tests
run: npm test
- name: Upload coverage
if: matrix.coverage
uses: codecov/codecov-action@v4
with:
token: ${{ secrets.CODECOV_TOKEN }}fail-fast: false の重要性
デフォルトでは、マトリクス内の1つのジョブが失敗すると残りのジョブはすべてキャンセルされます。fail-fast: false を設定することで、特定の環境でのみ発生するバグを見逃さずに済みます。
レイヤードキャッシュ戦略
npm のキャッシュだけでは不十分な場合があります。ビルド成果物やテストフィクスチャもキャッシュすることで、CI実行時間を大幅に短縮できます。
# 高度なキャッシュ設定
- name: Cache build artifacts
uses: actions/cache@v4
with:
path: |
~/.npm
.next/cache
node_modules/.cache
key: ${{ runner.os }}-build-${{ hashFiles('**/package-lock.json') }}-${{ hashFiles('src/**') }}
restore-keys: |
${{ runner.os }}-build-${{ hashFiles('**/package-lock.json') }}-
${{ runner.os }}-build-ここでのポイントは restore-keys の段階的なフォールバックです。完全一致するキャッシュがなくても、部分一致で直近のキャッシュを復元し、差分のみを再ビルドします。実測値として、Next.js プロジェクトでビルド時間が平均 4分30秒 → 1分20秒まで短縮された事例があります。
セキュリティゲートの統合設計
なぜCI/CDにセキュリティスキャンを組み込むのか
脆弱性はデプロイ後に発見するより、マージ前に検出する方がコストが桁違いに安くなります。GitHub Actions のワークフローに3つのセキュリティレイヤーを組み込む設計を紹介します。
レイヤー1: 依存関係の脆弱性監査
# .github/workflows/security.yml
name: Security Gate
on:
pull_request:
branches: [main]
schedule:
- cron: '0 9 * * 1' # 毎週月曜9:00 UTC
jobs:
dependency-audit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: 22
- name: Install dependencies
run: npm ci
- name: Run npm audit
run: |
# critical と high のみブロック(medium/low は警告のみ)
npm audit --audit-level=high --omit=dev 2>&1 | tee audit-report.txt
if [ $? -ne 0 ]; then
echo "::error::High/Critical vulnerabilities found. See audit report."
exit 1
fi
- name: Upload audit report
if: always()
uses: actions/upload-artifact@v4
with:
name: npm-audit-report
path: audit-report.txtレイヤー2: SAST(静的アプリケーションセキュリティテスト)
CodeQL を使った静的解析を組み込みます。Antigravity のエージェントに「CodeQL ワークフローを追加して、TypeScript の脆弱性パターンを検出するように設定して」と指示すると、プロジェクトに最適な設定を生成できます。
codeql-analysis:
runs-on: ubuntu-latest
permissions:
security-events: write
steps:
- uses: actions/checkout@v4
- name: Initialize CodeQL
uses: github/codeql-action/init@v3
with:
languages: javascript-typescript
queries: +security-and-quality # セキュリティ+品質ルール
- name: Autobuild
uses: github/codeql-action/autobuild@v3
- name: Perform CodeQL Analysis
uses: github/codeql-action/analyze@v3
with:
category: "/language:javascript-typescript"レイヤー3: シークレット漏洩検知
secret-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0 # 全履歴が必要
- name: Detect secrets with Gitleaks
uses: gitleaks/gitleaks-action@v2
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}Gitleaks はコミット履歴全体をスキャンし、APIキー、パスワード、トークンなどのパターンを検出します。fetch-depth: 0 で全履歴を取得する点が肝心です。
セキュリティゲートを必須チェックに設定する
これらのジョブをブランチ保護ルールの「必須ステータスチェック」に追加することで、セキュリティスキャンをパスしないPRはマージできなくなります。
# GitHub CLI でブランチ保護ルールを設定
gh api repos/{owner}/{repo}/branches/main/protection \
--method PUT \
--field required_status_checks='{"strict":true,"contexts":["dependency-audit","codeql-analysis","secret-scan"]}'semantic-release による完全自動リリース
Conventional Commits の導入
自動リリースの基盤となるのが Conventional Commits です。コミットメッセージの形式を統一することで、バージョン番号の自動決定とCHANGELOG生成が可能になります。
feat: ユーザー認証にOAuth2サポートを追加
fix: ダッシュボードのメモリリークを修正
perf: 画像圧縮パイプラインを最適化(処理速度40%向上)
feat!: APIレスポンス形式をv2に変更(破壊的変更)
# コミットタイプとバージョン変更の対応
# fix → パッチ (1.0.0 → 1.0.1)
# feat → マイナー (1.0.0 → 1.1.0)
# feat! → メジャー (1.0.0 → 2.0.0)
commitlint でコミットメッセージを強制する
# .github/workflows/commitlint.yml
name: Commitlint
on:
pull_request:
branches: [main]
jobs:
commitlint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: 22
- name: Install commitlint
run: npm install -g @commitlint/cli @commitlint/config-conventional
- name: Validate commits
run: npx commitlint --from ${{ github.event.pull_request.base.sha }} --to ${{ github.event.pull_request.head.sha }} --verbosesemantic-release ワークフローの実装
# .github/workflows/release.yml
name: Release
on:
push:
branches: [main]
permissions:
contents: write
issues: write
pull-requests: write
jobs:
release:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
persist-credentials: false
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: 22
- name: Install dependencies
run: npm ci
- name: Run tests
run: npm test
- name: Semantic Release
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
run: npx semantic-releasesemantic-release の設定ファイル(.releaserc.json)も Antigravity に生成させることができます。
{
"branches": ["main"],
"plugins": [
"@semantic-release/commit-analyzer",
"@semantic-release/release-notes-generator",
[
"@semantic-release/changelog",
{
"changelogFile": "CHANGELOG.md"
}
],
[
"@semantic-release/git",
{
"assets": ["CHANGELOG.md", "package.json"],
"message": "chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}"
}
],
"@semantic-release/github"
]
}この設定により、main ブランチへのpushごとに以下が自動実行されます。コミットメッセージの解析によるバージョン決定、CHANGELOG.md の自動更新、GitHub Release の作成とリリースノート生成、そしてパッケージの公開(NPMの場合)です。
Antigravity エージェントを活用したワークフロー生成
agents.md によるCI/CD専用エージェントの定義
Antigravity の agents.md 機能を使って、CI/CD専用のエージェントプロファイルを定義できます。
<!-- .antigravity/agents.md -->
## CI/CD Architect Agent
You are a CI/CD pipeline architect specializing in GitHub Actions.
### Responsibilities
- Design and optimize GitHub Actions workflows
- Implement security scanning pipelines
- Configure caching strategies for build performance
- Set up automated release processes
### Guidelines
- Always use pinned action versions (e.g., @v4, not @main)
- Implement fail-fast: false for matrix builds
- Include artifact uploads for debugging failed runs
- Use OIDC for cloud provider authentication instead of long-lived secretsこのエージェントに「現在のプロジェクトに最適なCI/CDパイプラインを設計して」と指示すると、プロジェクトの package.json、テスト設定、デプロイ先を自動で解析し、カスタマイズされたワークフローを生成します。
ワークフローのデバッグにAIを活用する
CI が失敗した際、Antigravity のエージェントにログを貼り付けて「このCIの失敗原因を分析して修正案を提示して」と依頼できます。エージェントはエラーログのパターンを認識し、過去の類似事例から修正方法を提案してくれます。
実践: 統合パイプラインの全体設計
ここまでの要素を統合した、プロダクション品質のパイプライン設計図を示します。
# .github/workflows/pipeline.yml — 統合パイプライン
name: Production Pipeline
on:
push:
branches: [main]
pull_request:
branches: [main]
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true # 同一ブランチの古い実行をキャンセル
jobs:
# Phase 1: 品質ゲート(並列実行)
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
- run: npx tsc --noEmit # 型チェック
test:
runs-on: ubuntu-latest
strategy:
fail-fast: false
matrix:
shard: [1, 2, 3, 4] # テストを4分割して並列実行
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: 22, cache: 'npm' }
- run: npm ci
- run: npx vitest --shard=${{ matrix.shard }}/4
security:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with: { fetch-depth: 0 }
- run: npm ci && npm audit --audit-level=high --omit=dev
- uses: gitleaks/gitleaks-action@v2
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
# Phase 2: ビルド(Phase 1 完了後)
build:
needs: [lint, test, security]
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 build
- uses: actions/upload-artifact@v4
with:
name: build-output
path: .next/
retention-days: 7
# Phase 3: デプロイ(main ブランチのみ)
deploy:
if: github.ref == 'refs/heads/main' && github.event_name == 'push'
needs: [build]
runs-on: ubuntu-latest
environment: production
steps:
- uses: actions/checkout@v4
- uses: actions/download-artifact@v4
with: { name: build-output, path: .next/ }
- name: Deploy to Cloudflare Workers
uses: cloudflare/wrangler-action@v3
with:
apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
command: deployこの設計のポイントは以下の通りです。concurrency 設定により同一ブランチの古い実行を自動キャンセルし、リソースを節約します。テストをシャード分割して並列実行することで、大規模テストスイートでも高速に完了します。needs による依存関係で、品質ゲートをパスした場合のみビルド・デプロイに進みます。environment: production により、デプロイ前に承認を要求するワークフローも構築可能です。
まとめ
上級CI/CDパイプラインの構築は、単に「自動化する」だけでなく、セキュリティ・品質・速度のバランスを設計する作業です。マトリクスビルドによる網羅的なテスト、3層のセキュリティゲート、semantic-release による自動リリースを組み合わせることで、人手を介さずに高品質なデリバリーを維持できます。
Antigravity のAIエージェントは、これらのワークフローの初期設計からデバッグまで強力にサポートしてくれます。基本的な連携方法を確認したい場合は「GitHub Actions × Antigravity 連携ガイド」を、GitHub全般の統合については「GitHub 統合ガイド」もあわせてご覧ください。