ClaudeCodeでGitHub Actionsを設定する方法【CI/CD自動化の実例】
「コードを更新するたびに手作業でテストを動かして、ビルドして、サーバーに上げて……」そんな繰り返し作業に疲れていませんか。GitHub Actionsを導入すれば、GitHubに変更をpushした瞬間に自動でテスト・ビルド・デプロイが走ります。しかし、YAMLファイルの書き方に独特のクセがあり、初心者には少しハードルが高いのも事実です。そこで活躍するのがClaudeCodeです。ClaudeCodeに自然な日本語で要件を伝えるだけで、適切なworkflow.ymlファイルを生成してくれます。本記事では、GitHub Actionsの基礎から、ClaudeCodeを使ったワークフロー作成、シークレット管理、デプロイ自動化までを、実プロンプト例とコードサンプルを交えて徹底解説します。
結論：ClaudeCodeとGitHub Actionsの組み合わせで開発が劇的に変わる
結論から言うと、ClaudeCodeとGitHub Actionsを組み合わせることで、非エンジニアでもプロ品質のCI/CDパイプラインを構築できます。ポイントは次の3つです。
1つ目は、ClaudeCodeがYAMLの構文を完璧に理解しているため、「Node.js 20でテストを走らせて、mainブランチへのpush時だけVercelにデプロイ」といった自然言語の指示を、そのまま動作するワークフローに変換できる点です。手動で書くと半日かかる作業が数分で終わります。
2つ目は、シークレット管理やキャッシュ戦略といったセキュリティ・パフォーマンスのベストプラクティスを、ClaudeCodeが自動的に提案してくれる点です。APIキーをハードコードしてしまうような初心者ミスを未然に防げます。
3つ目は、既存のワークフローに対するレビューや改善も依頼できる点です。「このワークフローの実行時間を短くして」と頼めば、キャッシュやマトリクスビルドを使った最適化案を提示してくれます。
以下の章では、GitHub Actionsの基礎概念から始めて、ClaudeCodeへの具体的なプロンプト例、テスト自動化、デプロイ自動化、シークレット管理、トラブルシューティングまでを順に解説していきます。読み終えるころには、自分のリポジトリにすぐ導入できる状態になっているはずです。
GitHub Actionsとは何か：CI/CDの基本を理解する
GitHub Actionsは、GitHubが公式に提供する自動化プラットフォームです。リポジトリ内に.github/workflows/というフォルダを作り、そこにYAML形式の設定ファイルを置くだけで、GitHubの様々なイベント（push、pull request、issue作成など）に応じて自動でスクリプトが実行されます。これを一般に「CI/CD（継続的インテグレーション／継続的デリバリー）」と呼びます。
CI（Continuous Integration）とは、コードを頻繁にメインブランチへ統合し、その都度自動でテストやビルドを行うことで、バグの早期発見と品質向上を図る手法です。CD（Continuous Delivery/Deployment）は、テストを通過したコードを自動で本番環境やステージング環境にデプロイする仕組みを指します。
GitHub Actionsの基本構成要素は次のとおりです。
- Workflow（ワークフロー）：自動化処理全体の定義。
.ymlファイル1つが1つのワークフローに対応。 - Job（ジョブ）：ワークフロー内で実行される作業単位。複数のジョブを並列実行することも可能。
- Step（ステップ）：ジョブを構成する個々のコマンドやアクション。
- Action（アクション）：再利用可能な処理単位。
actions/checkout@v4のように、GitHubマーケットプレイスから取得できる。 - Runner（ランナー）：ワークフローを実際に実行するサーバー。GitHubがホストするUbuntu/Windows/macOSが標準。
料金体系も初心者に優しく、Publicリポジトリは無制限無料、Privateリポジトリも個人プランで月2,000分まで無料で使えます。小規模な開発であれば実質コストはゼロです。
ClaudeCodeでworkflow.ymlを生成する基本手順
ClaudeCodeでGitHub Actionsのワークフローを作る最大のコツは、「何を、いつ、どこで実行したいか」を明確に伝えることです。実際のプロンプト例を見てみましょう。
プロンプト例1：Node.jsプロジェクトの基本テストワークフロー
このNext.jsプロジェクト用に、GitHub Actionsのワークフローを作ってください。
- mainブランチへのpushとpull request時に動作
- Node.js 20を使用
- npm ciで依存関係インストール
- npm run lintとnpm run testを実行
- ファイルは.github/workflows/test.ymlに保存
このプロンプトに対して、ClaudeCodeは次のようなYAMLを生成します。
name: Test
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
test:
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 lint
run: npm run lint
- name: Run tests
run: npm run test
ポイントは、ClaudeCodeがcache: 'npm'を自動的に追加してくれることです。これがあるとnpm installが2回目以降劇的に速くなります。明示的に頼まなくても、ベストプラクティスを取り入れてくれるのがClaudeCodeの強みです。
プロンプト例2：Python + pytestのワークフロー
Pythonプロジェクト用のテストワークフローを作ってください。
- Python 3.11と3.12の両方でテストを実行（マトリクスビルド）
- requirements.txtから依存関係をインストール
- pytestでテスト実行
- カバレッジレポートも生成して、Codecovにアップロード
ClaudeCodeはマトリクスビルドや外部サービス連携も正確に組み立てます。「Python 3.11と3.12の両方で」のような並列実行も、strategy.matrixを使って自動構成してくれます。
テスト自動化を実現する具体的なワークフロー
実務で最もよく使われるのは、テストの自動化です。テストを自動化すれば、人間がうっかり「テスト忘れた」という事故を防げます。
プロンプト例3：フロントエンドE2Eテストの自動化
Playwrightを使ったE2Eテストのワークフローを作ってください。
- pull request時に実行
- npm run buildでビルド後、npm run startでサーバー起動
- 起動を待ってからnpx playwright testを実行
- テスト失敗時はスクリーンショットをアーティファクトとして保存
生成されるYAMLは次のようになります。
name: E2E Test
on:
pull_request:
branches: [main]
jobs:
e2e:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'npm'
- name: Install dependencies
run: npm ci
- name: Install Playwright browsers
run: npx playwright install --with-deps
- name: Build
run: npm run build
- name: Start server
run: npm run start &
- name: Wait for server
run: npx wait-on http://localhost:3000
- name: Run Playwright tests
run: npx playwright test
- name: Upload screenshots on failure
if: failure()
uses: actions/upload-artifact@v4
with:
name: playwright-screenshots
path: test-results/
retention-days: 7
注目すべきはif: failure()の使い方です。これはテスト失敗時のみスクリーンショットを保存するという条件分岐で、ClaudeCodeに「失敗時だけ」と日本語で伝えるだけで適切に組み込まれます。
型チェックも組み込みたい場合は、次のように追加できます。
さきほどのワークフローに、TypeScriptの型チェック（tsc --noEmit）も追加してください。
ビルドより前のステップで実行してください。
デプロイ自動化のワークフロー設計
CI（テスト）が固まったら、次はCD（デプロイ）です。デプロイ自動化のパターンは大きく分けて、Vercel、Cloudflare、AWS、独自サーバーなどがありますが、ここでは代表的なものを紹介します。
プロンプト例4：Vercelへの自動デプロイ
mainブランチへのpush時にVercelへデプロイするワークフローを作ってください。
- Vercel CLIを使用
- 本番デプロイ（--prodフラグ付き）
- VERCEL_TOKEN、VERCEL_ORG_ID、VERCEL_PROJECT_IDはGitHub Secretsから取得
- デプロイ前にテストが通っていることを前提とする（testジョブの完了を待つ）
生成されるワークフロー例：
name: Deploy to Vercel
on:
push:
branches: [main]
jobs:
test:
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 run test
deploy:
needs: test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install Vercel CLI
run: npm install --global vercel@latest
- name: Pull Vercel environment
run: vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN }}
- name: Build
run: vercel build --prod --token=${{ secrets.VERCEL_TOKEN }}
- name: Deploy
run: vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }}
env:
VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}
needs: testの指定により、テストジョブが成功したときだけデプロイが実行されます。これが「壊れたコードを本番に流さない」CI/CDの基本原則です。
Cloudflare Workersへのデプロイを依頼する場合は次のようになります。
Cloudflare Workersへのデプロイワークフローを作ってください。
- mainブランチへのpush時に実行
- wranglerコマンドでデプロイ
- CLOUDFLARE_API_TOKENとCLOUDFLARE_ACCOUNT_IDはSecretsから取得
- デプロイ後にヘルスチェックURLを叩いて200が返るか確認
シークレット管理：APIキーを安全に扱う方法
GitHub Actionsを使ううえで最も重要なのが、シークレット（APIキー、トークン、パスワード）の管理です。これを間違えるとリポジトリにキーが漏洩し、重大なセキュリティ事故につながります。
絶対にやってはいけないことは、YAMLファイルや.envファイルにAPIキーを直接書いてリポジトリにcommitすることです。たとえPrivateリポジトリであっても、共同編集者全員に閲覧されてしまいます。
正しい方法は、GitHubの「Settings → Secrets and variables → Actions」画面からシークレットを登録し、ワークフロー内で${{ secrets.SECRET_NAME }}の形で参照することです。これらの値はログにも表示されず、Pull Requestのフォーク元には渡されません。
プロンプト例5：シークレットを使ったAPI連携テスト
Stripe APIを使うテストワークフローを作ってください。
- STRIPE_SECRET_KEYをGitHub Secretsから読み取る
- テスト実行時に環境変数として渡す
- 万一ログにキーが出力されないよう、setp-secretsアクションでマスク
ClaudeCodeは次のように生成します。
- name: Run integration tests
env:
STRIPE_SECRET_KEY: ${{ secrets.STRIPE_SECRET_KEY }}
run: npm run test:integration
env:セクションで環境変数として渡すのが基本パターンです。これにより、コード内でprocess.env.STRIPE_SECRET_KEYとして参照できます。
なお、社内アプリの場合は別途、本番環境のシークレットはCloudflare WorkersのSecretsに登録し、GitHub Actionsからは「デプロイのトリガーを引くだけ」にする運用が安全です。
実践チュートリアル：ゼロから本番デプロイまで
ここでは、Next.jsアプリにGitHub Actionsを導入し、テスト→ビルド→デプロイまで一気通貫で自動化する手順を、ClaudeCodeに任せながら進めてみます。
ステップ1：プロジェクトの準備
ローカルにNext.jsプロジェクトがあり、GitHubのPrivateリポジトリと連携済みの状態を前提とします。ClaudeCodeを起動し、プロジェクトのルートディレクトリで作業します。
ステップ2：基本ワークフローの生成
ClaudeCodeに次のプロンプトを送ります。
このNext.jsプロジェクト用に、GitHub Actionsのワークフローを.github/workflows/ci.ymlとして作成してください。
- mainブランチへのpushとPR時に発火
- Node.js 20を使用
- 依存関係のキャッシュを有効化
- npm ci、npm run lint、npm run typecheck、npm run testを順に実行
- いずれかが失敗したらワークフロー失敗
ClaudeCodeはファイルを自動生成します。
ステップ3：シークレットの登録
GitHubリポジトリの「Settings → Secrets and variables → Actions」へ移動し、「New repository secret」をクリックします。必要なキー（例：CLOUDFLARE_API_TOKEN）を登録します。
ステップ4：デプロイワークフローの追加
.github/workflows/deploy.ymlを追加してください。
- CIワークフローが成功した後にmainブランチへのpushでのみ動作
- Cloudflare Workersへデプロイ
- wrangler deployコマンドを使用
- preview_urlsは無効化されている前提
ステップ5：動作確認
ローカルで小さな変更をcommitしてpushします。
git add .
git commit -m "Add CI/CD workflow"
git push origin main
GitHubの「Actions」タブを開くと、ワークフローが実行されている様子が確認できます。緑のチェックマークが表示されればデプロイ成功です。
ステップ6：失敗時のデバッグ
万一失敗した場合は、ClaudeCodeにエラーログを貼り付けて聞きます。
このワークフローのログでエラーが出ました。原因と修正方法を教えてください。
[エラーログを貼り付け]
ClaudeCodeはログから原因を特定し、修正パッチを提案してくれます。
ワークフローの最適化とベストプラクティス
ワークフローが動くようになったら、次は「速く、安く、安全に」する最適化です。
実行時間の短縮には、依存関係のキャッシュが最も効果的です。actions/setup-node@v4のcache: 'npm'オプションだけで、2回目以降のnpm installが10秒以下になることもあります。
マトリクスビルドは、複数の環境で並列にテストする手法です。OSバージョンやNode.jsバージョンの組み合わせをテストできます。ただし並列数だけ料金がかかるため、CI環境では1つに絞り、リリース前だけマトリクスを動かすのが現実的です。
concurrency制御を入れることで、同じブランチへの連続pushで古いワークフローを自動キャンセルできます。
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
依存関係の自動更新には、Dependabotとの連携も有効です。「Dependabotが作るPRに対しても自動でテストを走らせる」設定はGitHub Actionsのデフォルトで動きます。
FAQ：GitHub Actions × ClaudeCode よくある質問
Q1. GitHub Actionsの料金はいくらかかりますか？
Publicリポジトリは無制限に無料です。Privateリポジトリでも個人プラン（Free）で月2,000分、Proで月3,000分まで無料で使えます。それを超えるとUbuntu環境で1分あたり約0.008ドルの従量課金です。月100分程度の利用なら実質無料と考えて問題ありません。
Q2. ClaudeCodeに「ワークフローを修正して」と頼んだとき、既存ファイルを上書きされてしまわないか心配です。
ClaudeCodeはファイル編集時に差分を提示し、ユーザーの確認を求めます。承認しない限り上書きは行われません。また、Gitでバージョン管理されていれば、万一の誤上書きもgit diffやgit restoreで簡単に戻せます。
Q3. workflow.ymlの構文エラーが出たときの対処法は？
GitHub上の「Actions」タブでエラー行が表示されるので、その箇所をClaudeCodeに貼り付けて「このエラーを直して」と頼むだけで修正案が得られます。VSCodeに「GitHub Actions」拡張機能を入れておくと、ローカルでもリアルタイムにYAML構文をチェックしてくれます。
Q4. シークレットを誤って漏らしてしまったら？
ただちにそのキーを無効化（ローテーション）してください。Stripe、AWS、Cloudflareなどすべてのプロバイダはキー無効化機能を持っています。リポジトリ履歴からの削除にはgit filter-branchやBFG Repo-Cleanerが使えますが、根本対策は「無効化して新しいキーを発行する」ことです。
Q5. デプロイが本番に直接行くのが怖いです。ステージング環境を挟むには？
GitHub Actionsの「Environments」機能を使うと、特定のジョブに「承認が必要」という制約をかけられます。プロンプト例：「productionへのデプロイ前に手動承認ステップを追加してください」と頼めば、ClaudeCodeがEnvironments対応のワークフローを生成します。
Q6. プライベートアクションを共通化したい場合は？
ClaudeCodeに「このワークフローの共通部分を、組織内のリポジトリで再利用できるようにComposite Action化してください」と依頼すれば、action.ymlを含む再利用可能なアクションを生成してくれます。
Q7. ワークフローのデバッグが大変です。コツはありますか？
ACTIONS_STEP_DEBUGというSecretをtrueで登録すると、詳細ログが有効になります。また、ClaudeCodeに「このステップで何が起きているか、echoでデバッグ出力を追加して」と頼めば、適切なログ出力を組み込んでくれます。
まとめ
GitHub ActionsとClaudeCodeの組み合わせは、非エンジニアでもCI/CDパイプラインを構築できる強力な手段です。YAMLの細かい構文を覚える必要はなく、「何を、いつ、どこで実行したいか」を日本語で伝えるだけで、ベストプラクティスに沿ったワークフローが手に入ります。重要なのは、シークレット管理を徹底し、APIキーを絶対にコードに埋め込まないこと、そしてmainブランチへの直接pushではなくPRベースでの運用に切り替えることです。これだけで、開発の生産性とプロダクトの品質が同時に向上します。まずはテスト自動化から始めて、慣れてきたらデプロイ自動化へと段階的に拡張していくのが成功のコツです。