Claude Code GitHub Actions実践ガイド — PRレビュー・Issue自動実装・セキュリティスキャンをCI/CDに組み込む
なぜGitHub ActionsでClaude Codeを動かすのか
ローカルのClaude Codeで開発速度が上がった。ターミナルでclaudeと打てばコードが書け、テストが走り、リファクタリングも一瞬で終わる。しかし、PRを開いてからマージされるまでの工程——レビュー、セキュリティチェック、Issue対応——は依然として人間のリソースに依存している。
ここにGitHub Actionsが入る。ローカルのClaude Codeが「開発」を担い、CI上のClaude Codeが「レビュー・品質ゲート・自動対応」を担う。この役割分担により、コードが書かれてからマージされるまでの全工程にAIが関与する開発フローが完成する。
claude-code-actionはv1.0 GAとして成熟しており、Stars 7k超、リリース157回を数える。従来のlintベースCIと根本的に異なるのは、@claudeメンション駆動のインタラクティブ性だ。PRコメントで「@claude このロジックのエッジケースを確認して」と書けば、Claude Codeがコードを読み、レビューコメントを返す。静的解析では拾えない設計上の問題や、文脈を踏まえた改善提案ができる点が強い。
さらに、ローカルで書いたCLAUDE.mdやHooksの資産がCI環境でもそのまま活きる。プロジェクトのコーディング規約やレビュー観点をCLAUDE.mdに書いておけば、ローカル開発でもCIレビューでも同じルールが適用される。
セットアップ:最初のワークフローまで
GitHub Appインストールと認証設定
最も手軽な始め方は、Claude Code CLIで/install-github-appを実行する方法だ。OAuthフローでGitHub App連携が完了し、リポジトリへのアクセス権が設定される。
認証方式は用途に応じて選択する。
| 方式 | 適したケース | 設定 |
|---|---|---|
| Anthropic Direct API | 個人・小規模チーム | anthropic_api_key シークレット |
| Claude Code OAuth | Pro/Maxプラン個人利用 | claude setup-tokenで生成 |
| AWS Bedrock OIDC | 企業AWS環境 | use_bedrock: true |
| Google Vertex AI WIF | GCP環境 | use_vertex: true |
個人開発なら、Anthropic APIキーをGitHub SecretsにANTHROPIC_API_KEYとして登録するのが最もシンプルだ。リポジトリの Settings → Secrets and variables → Actions から設定できる。
最小構成のワークフローYAML
name: Claude Code
on:
issue_comment:
types: [created]
pull_request_review_comment:
types: [created]
issues:
types: [opened, assigned]
permissions:
contents: write
pull-requests: write
issues: write
jobs:
claude:
runs-on: ubuntu-latest
steps:
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
これだけで、PRやIssueで@claudeとメンションすればClaude Codeが応答する。modeパラメータの指定は不要——v1.0ではpromptの有無で自動検出される。
v1.0の破壊的変更に注意。 v0.xから移行する場合、以下のパラメータ名が変わっている。
| v0.x(非推奨) | v1.0 |
|---|---|
direct_prompt | prompt |
custom_instructions | claude_args: --system-prompt |
max_turns | claude_args: --max-turns |
model | claude_args: --model |
allowed_tools | claude_args: --allowedTools |
claude_env | settings(JSON) |
v0.xの書き方でも非推奨警告付きで動作するが、将来のバージョンで削除される可能性があるため、早めに書き換えておくのがよい。
ユースケース別ワークフロー実装
@claudeメンション駆動PRレビュー
PRのコメントで@claudeとメンションすると、Claude Codeがコードを読んでレビューコメントを返すワークフローだ。
name: Claude PR Review
on:
issue_comment:
types: [created]
pull_request_review_comment:
types: [created]
permissions:
contents: read
pull-requests: write
issues: write
jobs:
review:
if: contains(github.event.comment.body, '@claude')
runs-on: ubuntu-latest
steps:
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
claude_args: >-
--model claude-sonnet-4-6
--max-turns 10
--allowedTools "Read,Glob,Grep"
ポイントは--allowedToolsでツールを制限している点だ。レビュー用途ではファイルの読み取りと検索だけあれば十分で、Bash実行やファイル書き込みを許可する必要はない。これがCIでの安全設計の基本になる。
Issue自動実装(assignトリガー)
Issueにアサインされたら、自動でブランチを作成し、実装してPRを出すワークフロー。正直、最初にこれが動いたときは驚いた。
name: Claude Issue Implementer
on:
issues:
types: [assigned]
permissions:
contents: write
pull-requests: write
issues: write
jobs:
implement:
runs-on: ubuntu-latest
steps:
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
prompt: |
Issueの内容を分析し、以下の手順で実装してください:
1. 必要な変更を特定
2. 実装
3. テストがあれば実行して確認
4. 変更内容をPRの説明に記載
claude_args: >-
--model claude-sonnet-4-6
--max-turns 20
promptを指定するとautomationモードとして動作し、@claudeメンションを待たずに即座に処理を開始する。--max-turns 20で暴走を防止しつつ、ある程度の複雑さには対応できるようにしている。
セキュリティスキャン(claude-code-security-review)
claude-code-security-reviewは、PRのdiffのみを対象にセキュリティ分析を行う専用アクションだ。パターンマッチではなくコードの意味を理解した上で脆弱性を検出し、PRのインラインコメントとして報告する。
name: Security Review
on:
pull_request:
permissions:
pull-requests: write
contents: read
jobs:
security:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
ref: ${{ github.event.pull_request.head.sha }}
fetch-depth: 2
- uses: anthropics/claude-code-security-review@main
with:
claude-api-key: ${{ secrets.ANTHROPIC_API_KEY }}
注意点が2つある。まずfetch-depth: 2が必須——diff分析のために直前のコミットが必要だ。次に、パラメータ名がclaude-api-key(ハイフン区切り)で、claude-code-actionのanthropic_api_key(アンダースコア区切り)とは異なる。地味にハマるポイントなので気をつけてほしい。
デフォルトモデルはClaude Opus 4.1(claude-opus-4-1-20250805)で、高精度な分析が行われる。偽陽性フィルタリングも内蔵されており、DoSやレート制限関連の一般的な指摘は自動的に除外される。
CI環境でのCLAUDE.md設計とプロンプト最適化
ローカル用のCLAUDE.mdがそのままCI環境で使われるが、CI固有の指示を追加したい場面は多い。claude_args: --system-promptでCI専用の指示を注入できる。
claude_args: >-
--system-prompt "あなたはCIのコードレビュアーです。以下の観点でレビューしてください:
1. セキュリティ(SQLインジェクション、XSS、認証バイパス)
2. パフォーマンス(N+1クエリ、不要な再レンダリング)
3. プロジェクトの命名規約との一貫性
破壊的な操作(ファイル削除、git push等)は絶対に実行しないでください。"
PRレビューでは、diffコンテキストがアクションによって自動注入されるため、promptにdiffの取得方法を書く必要はない。レビュー観点だけを明確に指定すればよい。
リポジトリ横断で共通のルールを適用したい場合は、.github/CLAUDE.mdを配置する。各リポジトリのCLAUDE.mdがプロジェクト固有のルール、.github/CLAUDE.mdが組織共通のルールという階層構造になる。
コスト管理とハマりどころ
APIコスト最適化
CI運用で気になるのはコストだ。モデル別の目安を把握しておこう。
| モデル | PRレビュー1回あたり | 用途 |
|---|---|---|
| Claude Sonnet 4.6 | $0.03〜0.05 | 日常のPRレビュー、Issue実装 |
| Claude Opus 4.6 | $0.15〜0.30 | セキュリティスキャン、複雑な分析 |
日常的なPRレビューにはSonnet 4.6で十分だ。claude_args: --model claude-sonnet-4-6で指定する。セキュリティスキャンのようにより高い精度が求められる場面ではOpusを使う、という使い分けが現実的だろう。
--max-turnsの設定は重要だ。デフォルトでは無制限のため、複雑なIssueに対してClaude Codeが延々とターンを消費し続ける可能性がある。PRレビューなら5〜10、Issue実装なら15〜20を目安に設定しておくとよい。
よくあるトラブルと対処法
権限不足エラー。 最も多いハマりポイントだ。以下の権限をすべて指定する必要がある。
permissions:
contents: write # ブランチ作成・コード変更
pull-requests: write # PRコメント・作成
issues: write # Issueコメント
contents: readだけにしていてPR作成で失敗する、というケースが非常に多い。
大量PRによるレート制限。 同時に複数のPRが開かれた場合、APIのレート制限に引っかかる可能性がある。concurrencyグループで制御する。
jobs:
review:
runs-on: ubuntu-latest
concurrency:
group: claude-review-${{ github.event.pull_request.number || github.event.issue.number }}
cancel-in-progress: false
steps:
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
claude_args: >-
--model claude-sonnet-4-6
--max-turns 10
CI環境固有の差異。 GitHub ActionsのランナーではHOMEが/home/runnerになり、ローカルの.claudeディレクトリは存在しない。ローカルで動いていたMCP設定やHooksがCIで動かない場合、この環境差異が原因であることが多い。CI用の設定はsettingsパラメータで明示的に渡すのが確実だ。
まとめ:ローカルからCI/CDへ、Claude Code自動化パイプラインの完成形
Claude Codeの真価は、ローカルの開発体験をCI/CDパイプラインに拡張したときに発揮される。導入は段階的に進めるのがおすすめだ。
- PRレビュー自動化から始める(最小構成、低リスク)
- セキュリティスキャンを追加(マージ前の品質ゲート)
- Issue自動実装に拡張(十分な運用知見を積んでから)
ローカルのClaude Codeで書き、GitHub ActionsのClaude Codeでレビュー・セキュリティチェックし、マージしてデプロイする。この一気通貫のフローが、1つ目のワークフローYAMLを追加するだけで動き始める。まずは最小構成から試してみてほしい。
