結論：Claude Code をCI/CDパイプラインの設計・自動構築に使うと、GitHub Actionsのyaml記述・Slackアラート設計・ロールバック戦略まで、コードとインフラ設定を一貫してアシストできる。ただし、本番環境への自動デプロイ判断には必ず人間のレビューゲートを挟むこと。
- 要点1：CIワークフロー設計を Claude Code に依頼する5パターン（lint-only / テスト統合 / ステージング自動デプロイ / 本番承認ゲート / マルチサービス並列）を用途別に使い分ける
- 要点2：Pre-Push Hookで型チェック・lint を Claude Code 経由で走らせると、CI失敗を手元で事前ブロックできる
- 要点3：秘密情報混入・本番DB誤発火・環境変数漏洩の3つは Claude Code が最も見落としやすい失敗パターン — 対策を必ずセットで実装する
対象読者：Claude Code を業務に使い始めたエンジニア・DevOpsエンジニア・PM。GitHub Actionsの基本を知っているが、CI/CD設計をClaude Codeで効率化したい人。
今日やること：自分のリポジトリで「5パターン比較表」を見てどのパターンが最適か決め、該当セクションのyaml例をコピーして動かす。
「GitHub Actionsのyamlをゼロから書くのが面倒で、毎回Stack Overflowを見ながら書いている」
CI/CD設計の相談会でよく聞く声です。実際にClaude Codeに「このプロジェクトのCIパイプラインを設計してください」と依頼すると、プロジェクト構成を読んで適切なyamlを生成してくれます。ただし、注意しないと本番DBへの誤発火や秘密情報の混入といった深刻な問題も起きます。
本記事では、実装パターンを解説する想定シナリオ（モデルケース）をベースに、Claude CodeでCI/CDパイプラインを構築する5パターンと、現場でよく起きる失敗3つの対策を紹介します。
Claude Code でCI/CD設計をする前に知っておくべきこと
Claude Code はコードファイルを読み取り、プロジェクト構造を把握した上でyamlやスクリプトを生成できます。しかしCI/CDの自動化は「動けばいい」では済まない領域です。以下の原則を先に把握してください。
- 本番デプロイに自動実行の権限を与えすぎない — Claude Codeが生成したyamlをそのまま本番に適用する前に、必ずdry-run確認を挟む
- secrets は Claude Code に見せない — GitHub Secretsなどの機密値を.claude/設定やプロンプトに書かない
- 生成されたyamlは必ずレビューする — 動作するyamlでも、セキュリティポリシーや組織のルールに反する記述が混じっていることがある
以上を前提に、5パターンを見ていきます。
CI/CDパイプライン設計の5パターン比較表
まずパターンを選んでから実装に入ると、不要な作り込みを防げます。
| パターン | 概要 | 適合プロジェクト | Claude Code への依頼難易度 | 本番デプロイ |
|---|---|---|---|---|
| P1: lint-only CI | PR時にlint・型チェックのみ実行 | 小規模・個人開発・スクリプト系 | 低（最も簡単） | なし |
| P2: テスト統合 CI | lint + ユニットテスト + カバレッジ計測 | 中規模アプリ・SaaS | 中 | なし or 手動 |
| P3: ステージング自動デプロイ | mainブランチへのマージで staging に自動デプロイ | アジャイル開発・週次リリース | 中 | staging のみ自動 |
| P4: 本番承認ゲート | staging 確認 → 手動承認 → production デプロイ | B2B SaaS・金融・医療系 | 高 | 承認後のみ |
| P5: マルチサービス並列 CI | モノレポの複数サービスを並列でテスト・デプロイ | モノレポ・マイクロサービス | 高 | サービス別に設定 |
自社のリリース頻度・チーム規模・リスク許容度に合わせてパターンを選んでください。以下では各パターンの実装例を示します。
パターン1：lint-only CI — Claude Code への依頼プロンプトとyaml例
最もシンプルなパターンです。Claude Code に以下のように依頼します。
Claude Code への依頼プロンプト例：
このリポジトリ（TypeScript + ESLint + Prettier）用のGitHub Actions CIワークフローを作成してください。
条件：
- PRが作成・更新されたときに実行
- ESLint と Prettier チェック、tsc --noEmit を実行
- Node.js 20を使用
- キャッシュ（node_modules）を活用して高速化
- 不足している情報があれば先に確認してください
- 仮定した点は「仮定：」と明記してください
上記のプロンプトを受け取ったClaude Codeが生成するyamlは概ね以下の構成になります（実際の生成結果はプロジェクト構成により異なります）。
# .github/workflows/ci-lint.yml
name: CI Lint & Type Check
on:
pull_request:
branches: ["main", "develop"]
jobs:
lint:
name: Lint & Type Check
runs-on: ubuntu-latest
steps:
- name: Checkout
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: Run ESLint
run: npm run lint
- name: Run Prettier check
run: npm run format:check
- name: TypeScript type check
run: npx tsc --noEmit
このyamlのポイントは npm ci（npm install ではなく）と cache: "npm" の組み合わせです。CI実行時間を短縮しつつ、package-lock.json に記録された依存関係を厳密に再現します。
パターン2：テスト統合 CI — ユニットテスト + カバレッジ計測
P1にテスト実行とカバレッジレポートを追加します。
# .github/workflows/ci-test.yml
name: CI Test
on:
pull_request:
branches: ["main", "develop"]
push:
branches: ["main"]
jobs:
test:
name: Unit Test & Coverage
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: "20"
cache: "npm"
- run: npm ci
- name: Run tests with coverage
run: npm run test:coverage
env:
NODE_ENV: test
# 本番DBの接続情報はここに書かない。テスト用のみ
DATABASE_URL: ${{ secrets.TEST_DATABASE_URL }}
- name: Upload coverage to Codecov
uses: codecov/codecov-action@v4
with:
token: ${{ secrets.CODECOV_TOKEN }}
fail_ci_if_error: false
重要な点は DATABASE_URL に ${{ secrets.TEST_DATABASE_URL }} を使っていることです。本番DBの接続文字列を直接書いたり、環境変数として echo でログに出力すると、GitHub Actionsのログに残ります。Claude Code が生成したyamlでもこの点は必ず確認してください。
パターン3：ステージング自動デプロイ — mainマージで staging に反映
テストが通過したらstaging環境に自動デプロイします。Claude Code への依頼時は「デプロイ先の環境とコマンド」を明示することが重要です。
# .github/workflows/deploy-staging.yml
name: Deploy to Staging
on:
push:
branches: ["main"]
jobs:
test:
name: Run Tests
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: "20"
cache: "npm"
- run: npm ci
- run: npm test
deploy:
name: Deploy to Staging
needs: test
runs-on: ubuntu-latest
environment: staging # GitHub Environments で承認ルールを設定可能
steps:
- uses: actions/checkout@v4
- name: Deploy
run: |
# 例: SSH経由でVPSにrsync + reload
echo "Deploying to staging..."
# 実際のデプロイコマンドはプロジェクトに依存
# ssh user@staging-host 'cd /app && git pull && npm ci && pm2 reload app'
env:
STAGING_SSH_KEY: ${{ secrets.STAGING_SSH_KEY }}
- name: Notify Slack on success
if: success()
uses: slackapi/[email protected]
with:
payload: |
{
"text": "✅ Staging deploy succeeded: ${{ github.sha }}",
"channel": "#deployments"
}
env:
SLACK_WEBHOOK_URL: ${{ secrets.SLACK_DEPLOY_WEBHOOK }}
- name: Notify Slack on failure
if: failure()
uses: slackapi/[email protected]
with:
payload: |
{
"text": "🚨 Staging deploy FAILED: ${{ github.sha }} — <${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}|ログを確認>",
"channel": "#deployments"
}
env:
SLACK_WEBHOOK_URL: ${{ secrets.SLACK_DEPLOY_WEBHOOK }}
Slack通知の設定で注意が必要なのが SLACK_WEBHOOK_URL の管理です。Claude Code にSlack通知を追加させると、Webhook URLをyamlにハードコードするプロンプトを生成することがあります。必ずGitHub Secretsに格納し、${{ secrets.SLACK_DEPLOY_WEBHOOK }} で参照してください。
パターン4：本番承認ゲート — GitHub Environments を使った手動承認フロー
B2BサービスやデータベースへのDDL適用など、本番デプロイに人間の判断が必要な場合はGitHub Environmentsの承認機能を使います。
# .github/workflows/deploy-production.yml
name: Deploy to Production
on:
workflow_dispatch: # 手動トリガーのみ（mainへのpushでは自動実行しない）
inputs:
tag:
description: "Deploy tag (e.g. v1.2.3)"
required: true
jobs:
deploy-staging:
name: Deploy to Staging (pre-check)
runs-on: ubuntu-latest
environment: staging
steps:
- uses: actions/checkout@v4
with:
ref: ${{ github.event.inputs.tag }}
- name: Deploy to Staging
run: echo "Deploying ${{ github.event.inputs.tag }} to staging..."
approval-gate:
name: Wait for Production Approval
needs: deploy-staging
runs-on: ubuntu-latest
environment: production # GitHub Repository Settings > Environments で承認者を設定
steps:
- name: Awaiting approval
run: echo "Approved. Proceeding to production deploy."
deploy-production:
name: Deploy to Production
needs: approval-gate
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
ref: ${{ github.event.inputs.tag }}
- name: Production Deploy
run: |
echo "Deploying to production..."
# 実際のコマンドはプロジェクトに依存
env:
PROD_DEPLOY_KEY: ${{ secrets.PROD_DEPLOY_KEY }}
- name: Create GitHub Release
uses: actions/create-release@v1
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
tag_name: ${{ github.event.inputs.tag }}
release_name: "Release ${{ github.event.inputs.tag }}"
draft: false
prerelease: false
このパターンのポイントは2点です。
workflow_dispatchで手動トリガーのみにし、mainブランチへのpushで自動実行されないようにする- GitHub RepositoryのSettings > Environments > productionで「Required reviewers」に承認者を設定する
Claude Code にこのパターンを依頼するとき、「本番環境への自動デプロイは禁止、手動承認ゲートを必ず入れてください」と明示しないと、pushトリガーで直接本番デプロイするyamlを生成することがあります（後述の失敗パターン参照）。
パターン5：マルチサービス並列 CI — モノレポ対応
モノレポ構成でフロントエンド・バックエンド・マイクロサービスを並列でテストするパターンです。
# .github/workflows/ci-monorepo.yml
name: Monorepo CI
on:
pull_request:
branches: ["main"]
jobs:
detect-changes:
name: Detect Changed Services
runs-on: ubuntu-latest
outputs:
frontend: ${{ steps.filter.outputs.frontend }}
backend: ${{ steps.filter.outputs.backend }}
worker: ${{ steps.filter.outputs.worker }}
steps:
- uses: actions/checkout@v4
- uses: dorny/paths-filter@v3
id: filter
with:
filters: |
frontend:
- 'apps/frontend/**'
backend:
- 'apps/backend/**'
worker:
- 'apps/worker/**'
test-frontend:
name: Test Frontend
needs: detect-changes
if: needs.detect-changes.outputs.frontend == 'true'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: "20"
cache: "npm"
cache-dependency-path: apps/frontend/package-lock.json
- run: npm ci --prefix apps/frontend
- run: npm test --prefix apps/frontend
test-backend:
name: Test Backend
needs: detect-changes
if: needs.detect-changes.outputs.backend == 'true'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: "20"
cache: "npm"
cache-dependency-path: apps/backend/package-lock.json
- run: npm ci --prefix apps/backend
- run: npm test --prefix apps/backend
env:
DATABASE_URL: ${{ secrets.TEST_DATABASE_URL }}
all-checks-pass:
name: All Checks Pass
needs: [test-frontend, test-backend]
if: always()
runs-on: ubuntu-latest
steps:
- name: Check results
run: |
if [[ "${{ needs.test-frontend.result }}" == "failure" || "${{ needs.test-backend.result }}" == "failure" ]]; then
echo "One or more jobs failed"
exit 1
fi
echo "All checks passed"
このパターンで Claude Code に依頼するときは「変更されたサービスだけCIを実行したい」「並列実行でCI時間を短縮したい」と具体的に伝えます。dorny/paths-filter などのサードパーティActionの使用を提案された場合は、そのActionのリポジトリを自分でも確認することを推奨します（公式: github.com/dorny/paths-filter）。
Pre-Push Hook で CI 失敗を手元でブロックする設定
CIが失敗してからプッシュし直すのは非効率です。Claude Code に .claude/hooks/pre-push.sh の設計を依頼すると、pushする前に型チェック・lintを自動実行するhookを生成できます。
#!/bin/bash
# .claude/hooks/pre-push.sh
# pre-pushフックでlint・型チェックを実行
set -e
echo "Running pre-push checks..."
# TypeScript 型チェック
echo "→ Type check..."
npx tsc --noEmit || {
echo "❌ TypeScript errors found. Push aborted."
exit 1
}
# ESLint
echo "→ ESLint..."
npm run lint || {
echo "❌ Lint errors found. Push aborted."
exit 1
}
# 単体テスト（高速なユニットテストのみ）
echo "→ Unit tests..."
npm run test:unit || {
echo "❌ Unit tests failed. Push aborted."
exit 1
}
echo "✅ All pre-push checks passed."
このhookを有効にするには以下を実行します（.claude/hooks/ を使う場合はClaude Codeの設定に依存します。通常の .git/hooks/pre-push として設置する場合は chmod +x .git/hooks/pre-push で有効化）。
# .git/hooks/pre-push として設置する場合
cp .claude/hooks/pre-push.sh .git/hooks/pre-push
chmod +x .git/hooks/pre-push
# チーム全員に共有したい場合はhuskyを使う
npm install --save-dev husky
npx husky init
echo "bash .claude/hooks/pre-push.sh" > .husky/pre-push
Slack 通知とロールバック設計のベストプラクティス
Slack通知の設計方針
CI/CDパイプラインの状態をSlackに通知する設計をClaude Codeに依頼するとき、以下の要件を明示します。
以下の条件でSlack通知を設計してください：
- ✅ 成功時: staging デプロイ完了、コミットsha・担当者名
- 🚨 失敗時: ジョブ名・ステップ名・Actions のログURL
- ⚠️ 本番承認待ち: 承認者へのメンション + ジョブURL
- Webhook URLはGitHub Secretsに格納し、yamlにハードコードしない
- 仮定した点は「仮定：」と明記してください
ロールバック設計
デプロイ後に問題が発生したときのロールバック手順を、Claude Code にあらかじめ設計させておくと安全です。以下は想定シナリオ（試算値・モデルケース）として示すロールバックyamlです。
# .github/workflows/rollback.yml
name: Rollback Production
on:
workflow_dispatch:
inputs:
rollback_tag:
description: "Rollback to this tag (e.g. v1.2.2)"
required: true
reason:
description: "Reason for rollback"
required: true
jobs:
rollback:
name: Execute Rollback
runs-on: ubuntu-latest
environment: production
steps:
- uses: actions/checkout@v4
with:
ref: ${{ github.event.inputs.rollback_tag }}
- name: Log rollback intent
run: |
echo "ROLLBACK initiated by: ${{ github.actor }}"
echo "Rolling back to: ${{ github.event.inputs.rollback_tag }}"
echo "Reason: ${{ github.event.inputs.reason }}"
- name: Execute rollback
run: |
echo "Deploying ${{ github.event.inputs.rollback_tag }} to production..."
# 実際のデプロイコマンドをここに
env:
PROD_DEPLOY_KEY: ${{ secrets.PROD_DEPLOY_KEY }}
- name: Notify Slack of rollback
uses: slackapi/[email protected]
with:
payload: |
{
"text": "🔄 ROLLBACK executed to ${{ github.event.inputs.rollback_tag }} by ${{ github.actor }}\nReason: ${{ github.event.inputs.reason }}",
"channel": "#deployments"
}
env:
SLACK_WEBHOOK_URL: ${{ secrets.SLACK_DEPLOY_WEBHOOK }}
ロールバックyamlも workflow_dispatch（手動トリガー）のみにし、誰がいつどのタグへロールバックしたかをSlack + GitHub Actionsのログに残す設計にしています。
【失敗パターン3選】Claude Code を CI/CD に使うときの落とし穴
❌ 失敗1：本番データベースへの誤発火
起きやすいシナリオ：「テスト環境用のCI設定を作って」と依頼したところ、Claude Code が生成したyamlの DATABASE_URL に本番環境のシークレットを参照する記述が混入した。CIでマイグレーションが実行され、本番DBに意図しないDDL変更が入った。
対策：
- テスト用のシークレット名（
TEST_DATABASE_URL）と本番用（PROD_DATABASE_URL）を明確に分離する - CIでDBマイグレーションを実行する場合は、必ず
--dry-runまたは--checkフラグを最初に実行するステップを入れる - Claude Code に依頼するときは「テスト専用のDBのみ使用、本番DBには絶対に接続しない」と明示する
# ❌ 危険な例
env:
DATABASE_URL: ${{ secrets.DATABASE_URL }} # 本番と同じシークレット名
# ✅ 安全な例
env:
DATABASE_URL: ${{ secrets.TEST_DATABASE_URL }} # テスト専用シークレット
NODE_ENV: test
❌ 失敗2：秘密情報の混入（Webhook URLやAPIキーのハードコード）
起きやすいシナリオ：Claude Code にSlack通知を追加させたところ、生成されたyamlの中にWebhook URLがハードコードされていた。レビューを省いてそのままコミット → GitHubリポジトリに公開 → Slackチャンネルへのスパム送信被害。
対策：
- 生成されたyamlをコミットする前に、
git diffでhooks.slack.comやsk-、xoxb-などのパターンが含まれていないか確認する - GitHub Secret Scanning（docs.github.com）を有効化し、シークレットのプッシュをブロックする
- Claude Code への依頼プロンプトに「シークレット・APIキー・Webhook URLは必ずGitHub Secretsに格納し、yamlにハードコードしない」を毎回含める
❌ 失敗3：mainへのpushで本番に直接デプロイする設定になっていた
起きやすいシナリオ：「mainブランチへのpushで自動デプロイ」と依頼したところ、Claude Code が staging/production を区別せずに on: push: branches: [main] で本番サーバーへのデプロイを生成した。テスト目的でmainに直接プッシュしたところ、本番環境に未テストのコードが反映された。
対策：
- Claude Code への依頼時に「mainへのpushはstagingまでのデプロイ。本番デプロイはworkflow_dispatchで手動トリガーのみ」と明示する
- GitHub Environments の「Required reviewers」設定でproduction環境への自動実行をブロックする（GitHub公式ドキュメント参照）
- 生成されたyamlの
on:セクションを最初に確認する習慣をつける
Claude Code に CI/CD 設計を依頼するときの有効なプロンプト設計
CI/CD設計のプロンプトで成果を出すには、以下の要素を含めます。
以下の条件でGitHub Actions CIワークフローを設計してください。
【プロジェクト情報】
- 言語/フレームワーク: [TypeScript / Next.js / など]
- テストフレームワーク: [Vitest / Jest / など]
- デプロイ先: [VPS / Vercel / AWS / など]
【ワークフローの要件】
- PRトリガー: lint・型チェック・ユニットテスト
- mainマージ: staging環境に自動デプロイ
- 本番デプロイ: 手動承認ゲートあり（workflow_dispatch のみ）
【セキュリティ要件】
- シークレット類はすべてGitHub Secretsに格納
- 本番DBへの接続はdeployジョブ以外から禁止
- Webhook URLなど機密値をyamlにハードコードしない
【通知要件】
- 成功・失敗をSlackの #deployments チャンネルに通知
不足している情報があれば先に質問してください。
仮定した点は「仮定：」と明記してください。
「不足している情報があれば先に質問してください」「仮定した点は明記してください」の2文は、どのCI/CD設計依頼にも必ず加えることを推奨します。これにより、Claude Code が不明な点を確認せずに進めてしまうリスクを減らせます。
公式ドキュメントとTier 1ソース
本記事の実装例はパターン解説用のモデルケースです。実際の実装にあたっては以下の公式ドキュメントを必ず参照してください。
- GitHub Actions 公式ドキュメント（docs.github.com/en/actions）
- GitHub Environments — Required reviewers 設定
- GitHub Secret Scanning
- Claude Code 公式ドキュメント（docs.anthropic.com）
- slack-github-action 公式リポジトリ（github.com/slackapi/slack-github-action）
まとめ：Claude Code × CI/CD で今日から始める3つのアクション
- パターン表を参照してプロジェクトに合ったパターンを1つ選ぶ — リリース頻度とリスク許容度で決まります。個人開発や小規模チームならP1-P2から始めると負担が少ないです
- Claude Code への依頼プロンプトにセキュリティ要件を必ず含める — 「シークレットはGitHub Secretsに格納」「本番デプロイは手動承認ゲートあり」の2点は毎回明示する
- 生成されたyamlをコミットする前に
on:セクションとシークレット参照を確認する — 動くyamlでも、セキュリティ設計が意図と一致しているかを目視確認する習慣をつける
CI/CD設計の相談や Claude Code 活用方法について、より詳しく個別に話したい方は下記からお気軽にご連絡ください。
よくある質問（FAQ）
- Q. Claude Code は GitHub Actions のyamlをどこまで自動生成できますか？
- A. プロジェクトの構成ファイル（package.json、Dockerfileなど）を読み取り、lint・テスト・デプロイの基本フローを生成できます。ただし、組織固有のインフラ構成や承認フローは人間が要件を明示する必要があります。生成されたyamlは必ず動作確認・レビューをしてください。
- Q. 本番デプロイに Claude Code を使っても安全ですか？
- A. Claude Code はコード・設定の生成を支援するツールであり、本番環境への直接デプロイは Claude Code がトリガーするものではありません。生成されたCI/CDの設定を人間がレビューし、適切な承認ゲートを設けることが前提です。
- Q. Slack通知の設定で注意することは？
- A. Webhook URLは絶対にyamlにハードコードしないことが最重要です。GitHub Secretsに格納し、
${{ secrets.SLACK_WEBHOOK_URL }}で参照してください。Claude Code が生成したyamlにWebhook URLが直接記述されている場合は、コミット前に必ず修正してください。 - Q. Pre-Push Hookとの違いはCI/CDと何が違いますか？
- A. Pre-Push Hookはローカル環境でプッシュ前に実行される検証です。CI/CDはリモート（GitHub Actionsなど）で実行されます。Pre-Push Hookで事前ブロックすることで、不要なCIの実行を減らし、チームのCI待ち時間を短縮できます。ただしHookはローカルで無効化できるため、CI側でも同じチェックを実施することを推奨します。
- Q. モノレポで一部のサービスだけCIを実行したい場合は？
- A. パターン5（マルチサービス並列CI）で紹介した
dorny/paths-filterなどを使い、変更されたパスに基づいて実行するジョブを制御できます。Claude Code に「変更されたサービスだけテストを実行するCI設定」と明示して依頼すると、paths-filterを使った設計を提案してくれます。 - Q. ロールバック手順はどう設計すればいいですか？
- A. 本記事のパターン4と合わせて、rollback.yml（workflow_dispatch + production environment）を別ファイルで用意することを推奨します。ロールバック対象タグを引数で指定し、Slackに実行者・タグ・理由を残す設計にすると、障害対応の記録として活用できます。
著者プロフィール
佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載執筆。Claude Code 個別指導・法人導入支援を提供。
