Claude CodeとGitHub ActionsでPRレビューを自動化する最短手順

監修者_SD以外

監修者プロフィール

森下浩志

日本最大級のAI情報プラットフォーム「romptn ai」編集長。著書に「0からはじめるStable Diffusion」「0からはじめるStable Diffusion モデル・拡張機能集編」など、AmazonベストセラーのAI関連書籍を多数執筆。AIにおける情報の非対称性を解消するための社内研修や出張講義も行う。

@claudeでPRレビューを自動化する全体像

AI コーディングというと、自分のターミナルの中だけで完結するもの、というイメージを持っている方は多いと思います。実は Claude Code は GitHub の Pull Request や Issue のコメント欄から呼び出して、レビューや修正までまるごと任せる 使い方ができます。

やることはとてもシンプルで、PR や Issue のコメントに @claude と書いて指示を添えるだけです。すると Claude が文脈を読み取り、コードのレビュー、バグ修正、機能の実装、さらには Issue の内容を PR に起こすところまで自動で進めてくれます。

この仕組みは GitHub Actions の上で動くため、人がローカルでコマンドを叩き続ける必要がありません。チームの誰がコメントしても同じように反応してくれるので、レビュー待ちで作業が止まる時間を減らせます。

とはいえ「workflow.yml をゼロから書いて、権限や secrets の設定でハマるのでは」と身構えてしまいますよね。後ほどの『最短導入は/install-github-app一本』の章で見るように、入口はコマンド 1 本で済むので、最初の一歩はそれほど重くありません。

この記事では、つまずきにくい順番として次の 3 段階で進めます。

個人で気軽に試す段階から、実務のリポジトリに乗せる段階まで、手を動かしながら順に確認していきましょう。

@claude自動化の仕組み

まずは「@claude とコメントすると、裏で何が動いているのか」を地図にしておきましょう。仕組みがつかめると、後の導入や設定が「おまじない」ではなく「理由のある手順」として頭に入ります。

中身は GitHub Actions のジョブ です。あなたのコメントが合図になって GitHub が用意した実行環境(GitHub-hosted runner)が立ち上がり、その中で Claude があなたのリポジトリを読みながら作業します。手元のパソコンではなく、GitHub の中で動くと考えてください。

動いている本体は、Claude Code と同じ Claude Agent SDK をベースにした公式アクションです。つまりターミナルで使う Claude Code が、GitHub のコメント欄から呼び出せるようになったイメージです。

ここで安心材料が一つあります。コードを処理するのは runner の中だけで、あなたのリポジトリのコードがどこか別の場所に丸ごとコピーされるわけではありません。作業はその実行環境の内側で完結し、終われば片付けられます。

もう一つ押さえたいのが「対話トリガー型」という性格です。常に張りついて監視しているのではなく、あなたが @claude と声をかけたタイミングだけ起動します。呼ばれて初めて動く、依頼ベースの仕組みだと捉えると分かりやすいです。

では @claude は何をしてくれるのか。境界はおおよそ次の範囲です。

ドキュメントの更新やコメント追記のような「コードに対する作業」も、この延長で頼めます。逆に言えば、@claude で呼んで依頼する形が基本で、勝手に何かを始める仕組みではありません。

この「呼ばれたら GitHub の中で動く」という土台を押さえたうえで、次の章からは実際の導入手順に入っていきます。

@claudeを実際に動かす

セットアップが済んだら、Issue か Pull Request のコメント欄に @claude と書き、その後ろにやってほしいことを日本語でも英語でも続けて書くだけで動きます。コメントを投稿すると Claude がそのリポジトリの文脈を読み取り、PR の作成・機能の実装・バグ修正・質問への回答までこなします。

指示の出し方は、用途に応じてだいたい次の4パターンに分かれます。具体的なコメント例を並べると、どう書けばよいかのイメージがつかめます。

実装(Issue から PR まで) — Issue の本文に仕様を書いておき、コメントで実装を依頼します。Claude は Issue の内容を踏まえてコードを書き、そのまま PR を作ってくれます。

@claude implement this feature based on the issue description

バグ修正 — どこで何が起きているかを添えて修正を頼みます。対象のファイルや症状を具体的に書くほど、狙った箇所をピンポイントで直してくれます。

@claude fix the TypeError in the user dashboard component

質問への回答 — 必ずしもコードを書かせる必要はありません。設計の相談や実装方針の質問にも答えてくれます。

@claude how should I implement user authentication for this endpoint?

レビュー — PR のコメントで @claude を呼べば、その差分を見てレビューを返します。毎回の PR を自動でレビューさせる設定は後ほどの『PRレビュー自動化の二系統』の章で扱います。

ひとつだけ間違えやすい点があります。呼び出しは @claude(メンション形式)で書きます。/claude ではコメントしても反応しないので、もし動かないときはまずここを見直してください。

workflow.ymlをカスタムする

/install-github-app で入る初期設定をそのまま使うのもいいですが、トリガーや権限、モデルを自分で決めたくなったら .github/workflows/ に置く設定ファイルを直接いじります。中身は次のような YAML です。

name: Claude Code
on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]
jobs:
  claude:
    runs-on: ubuntu-latest
    steps:
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          # コメント中の @claude メンションに反応する

on: がワークフローの起動条件です。issue_comment は Issue や PR に付いたコメント、pull_request_review_comment は PR の差分行に付いたレビューコメントを拾います。この 2 つを並べておくと、どちらの場所で @claude と書いても反応するようになります。

uses: で読み込んでいるのが Anthropic 公式のアクションです。バージョンは末尾の @ 以降で固定します。執筆時点では @v1 が最新ですが、ピン番号や指定できるモデル ID は更新されるため、実際の指定は公式ドキュメントの最新版で確認してください。

anthropic_api_key には API キーそのものではなく ${{ secrets.ANTHROPIC_API_KEY }} を渡します。これでキーの中身はリポジトリの Secrets から読み込まれ、ワークフロー本体には書かれません。キーをファイルに直接書くと履歴に残って漏れるので、必ずこの形にします。

挙動の細かい調整は claude_args でまとめて行います。これは Claude Code の CLI オプションをそのまま渡す入口で、使うモデルを --model、1 回の応答で実行する手順の上限を --max-turns で指定できます。

        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          claude_args: "--max-turns 5 --model <モデルID>"

--max-turns を絞るとツールの実行回数に上限がかかり、暴走と API トークンの消費を同時に抑えられます。<モデルID> に入る実際の値は公式ドキュメントの最新版で確認して書き入れてください。

PRレビュー自動化の二系統

Claude Code による PR レビューには、性格の違う2つの回し方があります。ここを取り違えると「自動レビューにしたつもりが、コメントしないと動かない」というズレが起きます。

1つ目は、PR やコメントで @claude と呼んだときだけレビューが走る対話トリガー型です。レビューしたい PR を選んで明示的に呼ぶ使い方で、レビューの観点はリポジトリ直下の CLAUDE.md に書いておくとそれに沿って見てくれます。

2つ目は、メンション不要ですべての PR に自動でレビューを投稿するやり方です。PR が開かれたり更新されるたびに走るので、レビュー漏れを仕組みで防げます。多くの人が「毎 PR 自動レビュー」と言ってイメージするのはこちらで、公式の GitHub Code Review 機能か、code-review プラグインを使って実現します。

言い換えると、呼んだときだけ動かしたいなら前者、毎回もれなく回したいなら後者です。両者は二者択一ではなく、対話型を普段使いしつつ、重要なリポジトリだけ全 PR 自動レビューも併用する、といった組み合わせもできます。

それぞれ設定の差分が異なるので、次の『①@claudeメンションの対話レビュー』と『②トリガー不要の全PR自動レビュー』の章で順番に見ていきます。

①@claudeメンションの対話レビュー

1 つ目は、レビューしてほしい PR で人がコメントしたときだけ走らせるやり方です。誰も呼んでいない PR は動かず、無駄なトークンも GitHub Actions の実行時間も発生しません。

設定は基本のワークフローのままで足ります。コメント投稿を拾う issue_comment と pull_request_review_comment をトリガーにしておけば、本文に @claude を含むコメントが投稿された瞬間にレビューが始まります。レビュー専用に新しい YAML を書き起こす必要はありません。

呼び方も普段の会話と同じで、見てほしい観点を一緒に添えられます。

@claude このPRをレビューして
@claude この変更でNULL安全性に問題がないか見て

ここでもう一歩効いてくるのが、リポジトリ直下に置く CLAUDE.md です。コーディング規約・レビューで見てほしい観点・プロジェクト固有のルールをこのファイルに書いておくと、レビュー時にその内容を踏まえて指摘してくれます。「ここは命名規則を統一したい」「この層では例外を握りつぶさない」といったチーム独自の基準を、毎回コメントで書き直さずに効かせられるわけです。

呼んだときだけ・観点を添えて・自分たちの基準で見てもらう。気になった PR をピンポイントで深掘りしたいときに向いた方式です。

企業の本番で使うときの載せ替え

ここまでの設定は、個人が自分の Claude API キーをそのまま使う前提でした。会社の本番リポジトリに乗せる段になると、データの置き場所や課金を会社のクラウド契約に寄せたくなります。公式が導入手順を用意している差し替え先は Amazon Bedrock と Google Vertex AI の 2 つだけで、anthropic_api_key の代わりにクラウド側で Claude を呼ぶよう向き先を切り替えるのが基本イメージです。

切替に使うフラグ・認証方式・必要なシークレットは下の比較表にまとめました。いずれもクラウド側の権限で認証し、長期キーをリポジトリに置かない考え方は共通です。Bedrock では呼び出すモデル ID にリージョン接頭辞が付く点だけ、直接 API と見た目が変わります。

社外提供元のクラウドを挟むときは、専用の GitHub App を別途用意するのが推奨です。actions/create-github-app-token を使い、APP_ID と APP_PRIVATE_KEY をシークレットに置いて発行したトークンで動かします。

正確なモデル ID や指定値は陳腐化しやすいため本文に散らさず比較表に集約し、OIDC や Workload Identity Federation の AWS / Google 側の手順は各クラウドと Anthropic の公式ドキュメントに沿って進めてください。

secrets運用と権限・コストの注意点

自動化を回し始める前に、安全とコストの土台だけは押さえておきます。ここを飛ばすと、APIキーの漏えいや想定外の請求につながりやすいからです。

まず鉄則として、APIキーをワークフローやコードに直接書かないこと。キーはリポジトリの GitHub Secrets に保存し、ワークフローからは参照だけします。書き方は次の形です。

with:
  anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}

次に権限です。permissions は必要な分だけを与えるのが基本で、絞りすぎると Claude が PR を作れず、広げすぎると事故の余地が増えます。PRの作成・レビューまでひと通り任せる場合の最小セットは次のとおりです。

permissions:
  contents: write
  pull-requests: write
  issues: write
  id-token: write

id-token: write は、後ほどの『企業の本番で使うときの載せ替え』で触れたクラウド側の認証(OIDC)を使うときだけ必要です。直接APIで使う段階では付けなくて構いません。

そして、Claude が出した修正やコードはマージ前に必ず人がレビューする前提で運用します。自動でPRは作れても、最終的な取り込み判断は人が持つのが安全です。

コストは二段で発生します。中身は下の表のとおりで、どちらも使った分だけ増えていきます。

トークン量はタスクの内容やコードベースの大きさで変わるため、「○○を直して」と曖昧に投げるより、対象ファイルや条件を具体的に指定したほうが無駄が減ります。

v1移行で変わった書き方の注意

ここまでが現行の書き方ですが、ネット上には一つ前の @beta 時代のサンプルがまだ多く残っています。それをそのままコピペすると動かない、というのがこの章の本題です。

@beta から @v1 への移行では、パラメータ名がいくつも変わりました。特に `mode:` は廃止され、`direct_prompt` などの個別パラメータは `claude_args`(CLI のオプション渡し)に集約されています。古い名前のまま書くと、その設定が無視されたりエラーになったりします。

旧記法と新記法の対応は次の表のとおりです。手元の workflow が動かないときは、まず使っているパラメータ名がこの左側(旧)になっていないかを確認してください。

名前を置き換えるだけで済むものが多い一方、mode: のように行ごと削除する変更もあります。判断に迷ったら、自分でサンプルを継ぎ足すより、公式ドキュメントとリポジトリの examples に載っている現行の書き方を一度そのまま動かし、そこから差分で調整するのが確実です。

@claude PR自動化のよくある質問

まとめ

ここまで、Claude Code と GitHub Actions で PR レビューを自動化する流れを、簡単な入口から実務投入まで順番に追ってきました。ポイントを振り返ります。

身構えていた初期設定も、入口は1コマンドです。まずは Claude Code のターミナルで /install-github-app を実行し、自分のリポジトリに @claude を呼べる状態を作るところから始めてください。あとはコメントひとつで、レビューと修正がプルリクエスト上で回り始めます。

レビュー基準や運用ルールをさらに作り込みたくなったら、関連記事も合わせて読むと早く形になります。今日の一歩が、明日からのレビュー作業を肩代わりしてくれます。