Claude Code × GitHub Actions連携ガイド|CI/CDでAIコードレビューと自動PR生成を実装する手順【2026年版】
こんにちは、株式会社TIMEWELLの濱本です。
先週、社内の若手エンジニアから「PRに@claudeって書くだけでレビューコメントが全部埋まるの、反則じゃないですか」と言われました。反則なのか、それともこれが2026年の当たり前なのか。その境目に立っているのが、今回のテーマであるClaude CodeとGitHub Actionsの連携です。
anthropics/claude-code-action は2026年春にv1 GAへ到達し、ベータ版で悩まされていた設定の散らかり具合がかなり整理されました。私自身、社内の複数リポで導入と撤退を繰り返してきましたが、v1の「モード自動判定」とskillsのネイティブ統合は体感が別物です。CI上でAIに実装をさせる、という選択肢が現実味を帯びてきました。
この記事では、Claude Code × GitHub Actionsをこれから入れるチーム向けに、セットアップから実運用、セキュリティ、コスト最適化までをひと通り整理します。YAMLの実例を3つ載せ、途中でCoderabbitやCopilotとの使い分けにも触れるので、導入判断の材料として読めるはずです。
Claude Code Actionで何ができるのか
anthropics/claude-code-action@v1 は、GitHubのイベントを起点にClaude Codeを呼び出すための公式アクションです。中身はClaude Agent SDKで、ランナー上でClaude Codeをそのまま動かす構造になっています。つまりローカルでclaudeコマンドを叩いて試せる挙動は、ほぼそのままCIに持ち込めると考えて差し支えありません。
代表的な使い方は3通りです。1つ目はインタラクティブ応答で、PRやIssueのコメントに@claudeと書くと、Claudeがその文脈を読み取って回答やコード変更を返します。2つ目は自動レビューで、pull_requestイベントをトリガーにしてClaudeが差分を読み、レビューコメントを投稿します。3つ目は定期自動化で、scheduleやworkflow_dispatchを組み合わせ、毎朝のコミットサマリーや依存ライブラリの棚卸しレポートを作らせる運用です。
2026年3月にAnthropicが発表したCode Reviewは、このアクションの延長線上にある機能で、複数のレビュー観点ごとに専門エージェントを並列投入する設計になっています。「セキュリティ担当のClaude」「パフォーマンス担当のClaude」「規約遵守担当のClaude」が同時に1つのPRを読み、それぞれの視点からインラインコメントを返してくるイメージです。実装としては、複数ジョブを並列に走らせるだけなので、YAMLの記述も重くなりません。
ちなみにGitLabやBitbucketにもCI統合はありますが、公式アクションが最も成熟しているのはGitHubです。AWS BedrockやGoogle Vertex AI経由で動かすエンタープライズ構成の場合でも、土台はGitHub Actions前提になっているため、本記事もGitHub中心で進めます。
セットアップの最短ルートと手動手順
最短ルートはClaude Codeのターミナルで/install-github-appを実行する方法です。これでGitHubアプリのインストール、必要なシークレット登録、ワークフローファイルのコピーまでがウィザード形式で進みます。社内標準として配布するなら、むしろ手順を明文化しておきたいはずなので、ここでは手動セットアップの中身を整理しておきます。
手順は3ステップです。
- Claude GitHubアプリを対象リポにインストールする(https://github.com/apps/claude)
ANTHROPIC_API_KEYをSettingsのSecrets and variables内、Actions欄に登録する.github/workflows/claude.ymlを作成し、anthropics/claude-code-action@v1を呼び出す
GitHubアプリが要求する権限はContents、Issues、Pull requestsの3つで、いずれもRead & Writeです。Claudeに何ができるかはこの権限範囲で決まるので、セキュリティ担当者と読み合わせをしておくと後で揉めません。APIキーはPro/Maxユーザーならclaude setup-tokenで生成するCLAUDE_CODE_OAUTH_TOKENに置き換えてもよく、料金プランが月額寄せのチームはこちらのほうが会計上スッキリします。
最小構成のYAMLはこれだけです。
name: Claude Code
on:
issue_comment:
types: [created]
pull_request_review_comment:
types: [created]
jobs:
claude:
runs-on: ubuntu-latest
permissions:
contents: write
issues: write
pull-requests: write
steps:
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
これだけでPRやIssueのコメントに@claude 実装してと書けば動きます。v1のポイントはmodeを明示しなくてよくなったことで、トリガーとプロンプトの有無からインタラクティブ応答かautonomous実行かをアクション側が自動判定します。ベータから上げる際はdirect_promptをpromptへ、max_turnsをclaude_args: --max-turnsへ置き換える必要があり、ここを忘れるとジョブが黙って失敗します。
余談ですが、私は最初secrets.GITHUB_TOKENの権限不足でClaudeのコメントがPRに反映されずハマりました。ワークフローのpermissions:ブロックを明示的に書くこと、これが地味に大事です。デフォルトをreadに絞っている組織ほど引っかかります。
PR自動レビューのワークフローを組む
インタラクティブ応答だけだと「気付いた人がメンションすれば動く」という運用になり、レビュー文化は変わりません。効果が大きいのはむしろ、PRが立った瞬間に自動レビューが走るパターンです。
以下は、pull_requestイベントで差分をレビューさせる実運用向けの例です。
name: Claude Code Review
on:
pull_request:
types: [opened, synchronize, reopened]
jobs:
review:
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: write
issues: write
id-token: write
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
prompt: |
このPRを以下の観点でレビューしてください。
1. ロジックの誤り、null安全性、例外処理
2. セキュリティ(SQLインジェクション、認可漏れ、機微情報の露出)
3. パフォーマンス(N+1、無駄な再レンダー、キャッシュ設計)
4. 社内のCLAUDE.mdに記述された規約との整合
重大度をHigh/Medium/Lowで明記し、該当行にインラインコメントを投稿してください。
claude_args: |
--max-turns 5
--model claude-sonnet-4-6
ポイントはいくつかあります。fetch-depth: 0で全履歴を取ってくるのは、Claudeがベースブランチとの差分だけでなく周辺の文脈を読むためです。--max-turns 5はClaudeの試行回数上限で、初期値の10だと暴走時に跳ね上がるので、レビュー用途では3〜5が安全圏。モデルは既定のSonnetが費用対効果の落としどころで、深い解析が必要なクリティカルなリポだけclaude-opus-4-7に切り替える運用にしています。
レビュー観点を複数に分けたい場合、1ジョブに全部書くより、security-reviewとperformance-reviewとconvention-reviewのように並列ジョブを立てるほうが結果が読みやすくなります。各Claudeが別スレッドでインラインコメントを返すので、レビュー観点ごとに担当者が反応しやすい構造になる。ここはAnthropic公式のCode Reviewが採っている設計思想そのままです。
もう一つ効くのが、レビュー対象ファイルの事前フィルタです。lockファイルや生成物、dist/配下を毎回レビューさせるのはトークンの無駄。paths-ignoreで粗く除外し、プロンプト側でも「以下のファイルは無視してよい」と一文入れておくと、同じPRでコストが半分近くまで落ちることがあります。社内計測では、20ファイル規模のPRでひと月あたり30〜40%のトークン削減につながりました。
定期レポートとIssueトリアージを自動化する
PRレビューの次に効いてくるのが、スケジュール実行です。毎朝9時に前日のコミットをまとめたMarkdownをSlackに流す、毎週月曜に未対応Issueの優先度を整理して新しいIssueコメントで可視化する、といったユースケースが典型です。
3つ目のYAML例として、workflow_dispatchとscheduleを併用した定期レポートを載せます。
name: Daily Repo Report
on:
schedule:
- cron: "0 0 * * 1-5" # 平日9:00 JST(UTC 0:00)
workflow_dispatch:
permissions:
contents: read
issues: write
pull-requests: read
jobs:
report:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
prompt: |
直近24時間のコミット、マージ済みPR、新規Issueを集計し、
- マージ済みPR一覧(タイトル・作者・サマリー)
- 未対応の高優先度Issue
- 次にレビュー待ちのPR
の3セクションに分けて、本リポに「daily-report」Issueとして投稿してください。既存の同名Issueがあれば本日分コメントを追加してください。
claude_args: "--max-turns 4 --model claude-sonnet-4-6"
workflow_dispatchを入れておく地味なメリットは、動作確認が一発でできる点です。GitHubのActionsタブから手動実行ボタンが生え、スケジュールを待たずに叩ける。運用に乗る前と後の両方で、この手動トリガーには何度も助けられます。
Issueトリアージに使う場合は、issuesイベントのtypes: [opened]をトリガーにして、新規Issueが立ったタイミングでラベルを自動付与させる構成が現実的です。Claudeに「このIssueの内容を読み、bug、enhancement、questionのいずれかのラベルを付け、再現手順が不足していれば質問コメントを投稿せよ」と命じるだけで、トリアージ担当の負担が目に見えて減ります。私の関わっているOSSリポでは、導入後2週間で「ラベル付け係」の作業時間がほぼゼロになりました。
ここまで来るとClaudeは単なるレビュワーではなく、リポジトリの管理人に近い動きをします。PR生成、レビュー、Issue整理、定期棚卸し。コーディングの前後工程をまるごと任せられる構造になっている点が、GitHub Copilotの「書くときの補佐」とは役割がはっきり違います。
関連する設計思想については、以前書いたClaude Codeスキル45選とsuperpowersプラグインの記事も参考になるはずです。スキルの呼び出しはGitHub Actionsのprompt内から直接できるようになったので、社内用のスキルを1つ作ってCIで呼ぶ、という運用も普通に回ります。
セキュリティとコストを現実的に設計する
ここから先は、実運用で必ずつまずくセキュリティとコストの話です。
まずセキュリティ。ANTHROPIC_API_KEYは絶対にワークフローファイルへ直書きしない。GitHubのSecret Scanningと Anthropicは提携していて、公開リポにキーが漏れた場合は自動で無効化されます。助けてもらえるとはいえ、鍵は漏れないに越したことはありません。また、アクションのshow_full_outputオプションはv1で既定オフに変わりました。これを有効化するとツール実行の全出力がログに流れ、公開リポだとトークンや環境変数が丸見えになりかねない。必要な場面以外では触らないのが鉄則です。
ネットワーク制限を厳しくやるならStepSecurity社のHarden-Runnerと組み合わせる選択肢があります。Claudeのアクション実行中に許可する外部エンドポイントをapi.anthropic.comだけに絞り、他への通信をブロックする構成です。サプライチェーン攻撃でAction内から別サーバーにコードを吸い出される類のリスクを、実運用で下げられる数少ない手段として重宝しています。
エンタープライズで社内コードを外部に出せない場合は、AWS BedrockやGoogle Vertex AI経由で動かします。その際の認証はOIDC連携が定石で、aws-actions/configure-aws-credentials@v4やgoogle-github-actions/auth@v2とactions/create-github-app-token@v2を組み合わせ、静的なアクセスキーを一切持たずに短命トークンで動かす構成にします。APP_IDとAPP_PRIVATE_KEYのSecretsだけを管理すればよく、キー漏洩リスクが構造的に下がる。コンプライアンス部門との対話もこの構成なら通りやすいです。
コストの話もシビアに見ておきます。Claude Code + GitHub Actionsの運用コストは、アクティブなリポ1つあたりおおむね月5〜10ドル程度に収まることが多いというのが2026年の相場観です。ただしこれは「1日数件のPRに対してSonnetでレビュー」の話で、Opus 4.7を常用すると一気に数倍になります。Opusは入力100万トークンあたり15ドル、出力75ドル。Sonnetはそれぞれ3ドルと15ドルなので、5倍差です。
私の運用ルールはシンプルで、既定はSonnet、クリティカルリポの深い解析だけOpus。これだけでコストが安定します。さらに、--max-turnsを明示することと、生成ファイル・lockファイル・画像をpaths-ignoreで除外することが効きます。Claudeに「500行のpackage-lock.jsonを読ませる」のが一番もったいない出費だと考えてください。
ひとつ実務の知恵として共有すると、月次予算を超えた場合に備えてリポ変数のCLAUDE_ENABLEDを立て、各ワークフローのif:にvars.CLAUDE_ENABLED == 'true'を入れておく方法があります。コスト超過時はこのフラグを切るだけでClaude関連ジョブが一斉に止まる。請求書ショックを避ける運用として、地味に効きます。
他ツールと比べて、いつClaude Codeを選ぶか
2026年時点で、AIコードレビューの主要選択肢は3つです。Claude Code Review、GitHub Copilot Code Review、CodeRabbit。体感と調査を踏まえて、私なりの使い分けを書いておきます。
| ツール | 価格の目安 | 強み | 向いているチーム |
|---|---|---|---|
| Claude Code | APIトークン従量(月5〜20ドル/リポ) | 多エージェント並列、深い文脈理解、skillsでカスタム化 | レビュー品質を最大化したい、社内規約が厚い |
| GitHub Copilot Code Review | 10ドル/ユーザー | 既にCopilot入れているなら導入即日、60M件の運用実績 | 最小工数で足りるレベルを素早く |
| CodeRabbit | 24ドル/ユーザー | GitHub/GitLab/Bitbucket/Azure対応、F1スコア51.5% | 複数プラットフォーム、大規模運用 |
ベンチマークだけ見るとCodeRabbitのF1が高いのですが、Claude Codeの真価はそこではありません。CLAUDE.mdと社内スキルを読ませて、会社独自のレビュー観点を持ったレビュワーに仕立てられる点が一番の差です。汎用ベンチマークでは測れない、「この会社のコードならこう書くよね」という文脈追従の強さはClaudeが頭ひとつ抜けています。
逆にボリュームで殴るなら、CopilotかCodeRabbitが現実解です。1日100本PRが立つような組織で全部Opus 4.7を走らせると、コストが合わない。Claudeは「重要PRだけ深く読む」用途に寄せ、日常の軽レビューは別ツールで回す、という二段構えが効率的だと考えています。
併用時のプラクティスとして、Claudeの自動レビューには「他のAIレビュワーが既にコメントしている場合、重複は避ける」と一文プロンプトに入れておくと、PR内のコメント洪水を抑えられます。このあたりの運用設計は、Claude Codeでエージェントチームを組む記事で書いた、複数AIエージェント同士を協調させる設計と同じ考え方です。
TIMEWELLでも、社内のエンジニアリング基盤ではこの連携を前提に運用設計をしています。エンタープライズでClaude系の導入をゼロから進める場合、社内データと法規制の両立が一番の難所になることが多く、ここをまとめて相談できる相手を持っておくと立ち上がりが早いです。AIコンサルティングのWARPでは、Claude CodeとGitHub Actionsを含む開発ワークフローへの組み込みを設計段階から伴走しますし、ナレッジ基盤側に社内規約や過去レビューを持ちたいなら、エンタープライズAIのZEROCKにCLAUDE.mdの元ネタを寄せるのが筋のよい構成です。
最後に
Claude CodeとGitHub Actionsの連携は、2026年に入って「試す価値がある」から「入れないと置いていかれる」ラインに移ったと感じています。v1でYAMLが整理され、skillsと組み合わせれば会社独自の職人レビュワーを仕立てられる。BedrockやVertex AI経由で動かせばコンプライアンス要件もクリアでき、Harden-Runnerとの組み合わせでセキュリティも現実的な水準に持っていけます。
とはいえ、全自動に振り切ると必ずしっぺ返しが来ます。Claudeのレビューを最終判断にせず、重要な指摘だけ人が読む。自動マージさせるのはテストが厚い部分だけに絞る。このあたりの線引きを組織の合意として持っておくことが、長く回すうえで一番大事です。
まずは1つのリポに最小構成で入れて、2週間運用してから適用範囲を広げる。この進め方が、失敗の少ない導入手順だと私は思っています。試してみて、合う合わないの手応えを自分たちの手で掴んでみてください。
参考文献
[^1]: Anthropic. "Claude Code GitHub Actions". https://code.claude.com/docs/en/github-actions [^2]: anthropics/claude-code-action. GitHub Repository. https://github.com/anthropics/claude-code-action [^3]: StepSecurity. "anthropics/claude-code-action Security: How to Secure Claude Code in GitHub Actions with Harden-Runner". https://www.stepsecurity.io/blog/anthropics-claude-code-action-security-how-to-secure-claude-code-in-github-actions-with-harden-runner [^4]: Effloow. "Best AI Code Review Tools 2026: CodeRabbit vs Claude Code Review vs Qodo vs GitHub Copilot". https://effloow.com/articles/best-ai-code-review-tools-coderabbit-claude-qodo-2026 [^5]: Claude Code Guides. "Claude Code Pricing, Plans & Cost Optimization Guide 2026". https://claudecodeguides.com/pricing-hub/ [^6]: systemprompt.io. "How to Set Up Claude Code in GitHub Actions (2026 Guide)". https://systemprompt.io/guides/claude-code-github-actions
