AI コードレビューをGitHub Actionsで始める：Claude Codeの設定と運用

変わるのは、開発者が作業に付き添う必要があるかどうかです。従来はリポジトリを開き、Claudeを起動して、結果をGitHubに戻すまでローカルのセッションを動かし続ける必要がありました。Actionを使えば、メンテナーは範囲を絞った依頼を残し、後からコメントや変更案を確認できます。開発者の勤務時間外にも処理を始められますが、結果を確認する時間は引き続き必要です。

本記事は、2026年10月15日に確認したAnthropicの現行ドキュメントに基づいています。以下のワークフローは、導入時の設定として意図的に機能を制限しています。どのIssueでも無人で解決できるという意味ではありません。

リポジトリにAI コードレビューの窓口を用意する

GitHub Appは入館証、ワークフローは作業指示書、ランナーは一時的な作業用PCと考えると、役割をつかみやすくなります。ワークフローはGitHubに実行のタイミングを伝える設定ファイルで、ランナーは実際に処理を動かすマシンです。

このActionは、Issueやプルリクエスト内のメンションに応答できます。代わりにpromptを指定すると、自動実行するジョブになります。小規模なチームなら、変更のたびにレビュー費用をかける前に、明示的な依頼で有効な用途を見極めるのが手軽です。Actionの使い方。

初回セットアップを済ませ、ワークフローをマージする

リポジトリの管理者権限で、案内に沿ってインストールします。インストール済みのGitHub CLIでgh auth loginを実行して認証し、リポジトリ内でclaudeを開いて、/install-github-appを実行してください。使用するワークフローと、APIキーまたはサブスクリプションによる認証を選び、用意されたワークフローのPRを作成してマージします。インストールはローカルで行いますが、その後のジョブはGitHub上で動きます。公式のクイックセットアップ。

手動で設定する場合も、最終的な構成は同じです。

1. 対象のリポジトリにClaude GitHub Appをインストールします。
2. リポジトリのSettings → Secrets and variables → Actionsを開き、下表の認証用シークレットをどちらか1つ登録します。
3. Anthropicの動作例を.github/workflows/claude.ymlにコピーし、登録したシークレットに対応する認証用の入力パラメーターを選んで、ファイルをマージします。
4. @claudeと具体的な依頼を含むコメントを投稿します。

以上は、認証情報の選択を明示した公式の手動セットアップ手順です。Actionのセットアップガイド。

サブスクリプションで認証する場合は、ローカルでclaude setup-tokenを実行し、出力されたトークンをシークレットとして保存します。Anthropicは、Pro、Max、Team、Enterpriseプラン向けにこの方法を案内しています。生成したトークンの有効期間は1年なので、更新の担当者を決めておきましょう。トークンによる認証。

課金先は認証情報で決まります。 APIキーによる実行はAPI課金、OAuthトークンによる実行はClaudeサブスクリプションの利用として扱われます。GitHub Actionsのランナー使用量は、それとは別に計上されます。サブスクリプションのトークンは生成した個人に属するため、複数のリポジトリで共有するシークレットにはAPIキーを使うことをAnthropicは推奨しています。認証と料金。

標準のApp構成では、GitHubの個人アクセストークンは不要です。GitHubへのアクセスとClaudeの認証は別の仕組みで、前者はAppが、後者は選択したシークレットが担います。認証用の入力パラメーター。

まずはメンションで起動する小さなワークフローから

この構成は、信頼できるチームのリポジトリで、小さなファイル変更を行う用途に向いています。ファイルの読み取りと編集ができ、GitHub API経由でコミットできます。Claudeにはシェルツールを渡さないため、この構成でテストコマンドを実行することはできません。テストの実行は、変更案に対して自動チェックを行う既存のCIに任せます。

以下を.github/workflows/claude.ymlとして保存してください。Actionの指定に使うactions/checkout@v6とanthropics/claude-code-action@v1は、Anthropicの現行サンプルに掲載されているものです。ターン数の上限を5、タイムアウトを15分にしているのは、導入時の設定例として本記事が選んだ値です。Anthropicのデフォルト値ではありません。公式ワークフロー。

name: Claude on request
on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]

jobs:
  claude:
    if: contains(github.event.comment.body, '@claude')
    runs-on: ubuntu-latest
    timeout-minutes: 15
    concurrency:
      group: claude-small-team
      cancel-in-progress: false
    permissions:
      contents: write
      issues: write
      pull-requests: write
      id-token: write
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          use_commit_signing: true
          claude_args: |
            --max-turns 5
            --tools "Read,Glob,Grep,Edit,Write"
            --disallowedTools "Bash,WebFetch,WebSearch"

サブスクリプションで利用する場合は、anthropic_api_keyの行をclaude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}に置き換えます。認証方法はどちらか一方を指定してください。標準のGitHub App認証に必要なid-token: writeは残します。公式ワークフローと認証、入力パラメーターのリファレンス。

それぞれの制限は、役割が異なります。

• --toolsはClaudeが使える組み込みツールを選びます。Read、Glob、Grepはファイルの調査に、EditとWriteは変更に使います。ActionがGitHubと通信するために別途接続しているMCPツールは、この指定では制限されません。
• --allowedToolsは、指定したツールを確認なしで使用する権限を与えます。使用可能なツールすべてを限定するホワイトリストではありません。ここでは--disallowedToolsを明示し、シェルとWebのツールを禁止しています。
• --max-turnsはエージェントが作業を繰り返す回数を制限します。トークン数や金額の上限ではありません。また、上限に達すると、作業が未完了のままエラーで終了することがあります。CLIリファレンス。

use_commit_signing: trueを指定すると、コミットはGitHub API経由で行われます。このため、Claudeにシェル経由のgitコマンドを許可しなくても、変更を保存できます。署名用のシークレットを追加する必要はありません。ActionのGitHubツールは引き続き利用できるため、この構成には書き込み能力があります。コミット署名、Actionの実装。

固定の同時実行グループを指定することで、このワークフローがリポジトリごとに同時実行できるジョブは1つになります。デフォルトのキュー動作では、新しい待機中の依頼が古い待機中の依頼を置き換えることがあります。タスクを確実に保持するキューではありません。タイムアウトは、セットアップを含むジョブ全体の経過時間を制限します。GitHubの同時実行制御、ワークフロー構文。

レビューは@claude review this PR for missing permission checks; report findings without changing filesで試せます。Issueの修正なら、@claude fix the null handling described above, change only the parser and its regression test, and state which checks were not runのように依頼します。

デフォルトでは、起動する人にリポジトリへの書き込み権限が必要で、ボットからの起動はブロックされます。Issueの修正では、ブランチと、人がPRを作成するためのリンクが返る想定です。チームの手順にも、PRの作成は人が行うことを明記しましょう。Actionのセキュリティ。

試行後にPRの自動レビューを追加する

PRを自動レビューするには、/install-github-appのセットアップでレビューワークフローを選択します。このワークフローのcode-reviewプラグインは、--commentと、以下のコメント用ツールの許可設定を使って指摘を投稿します。公式のレビュー設定例。

この独立したレビューワークフローでは、Actionの入力に次の設定を含めます。

plugin_marketplaces: "https://github.com/anthropics/claude-code.git"
plugins: "code-review@claude-code-plugins"
prompt: "/code-review:code-review --comment ${{ github.repository }}/pull/${{ github.event.pull_request.number }}"
claude_args: >-
  --max-turns 5
  --allowedTools "mcp__github_inline_comment__create_inline_comment"

これらの入力は、上記のメンション用ワークフローではなく、公式のpull_requestワークフロー内で使います。チェックアウト、認証、ジョブの権限設定は維持し、ジョブのタイムアウトを追加してください。さらに、if: github.event.pull_request.head.repo.full_name == github.repositoryでフォークからのPRを除外します。ターン数の上限は試行用の設定として扱いましょう。途中で上限に達したレビューは未完了です。ドキュメントに記載されたレビュー用スキルは、ドラフトなど一部のPRも対象外にします。

Appの導入範囲とツールの権限は別々に管理する

まずは対象を絞ってリポジトリにインストールします。公式のClaude Appは複数のClaude機能で権限を共有しており、GitHubではその一部だけを承認することはできません。YAMLのpermissionsブロックを小さくしても、Appのインストール時に与えた権限は狭まりません。Appの権限モデル。

その権限が広すぎる場合は、Contents、Issues、Pull requestsへのアクセス権を持つカスタムAppを使う手順に従います。この方法では、APP_IDとAPP_PRIVATE_KEYのシークレットを追加し、Appトークンを生成してgithub_tokenとして渡すステップも設けます。固定のClaude APIキーをなくしたいチーム向けに、セットアップガイドはワークロードIDフェデレーションも説明しています。GitHubジョブの認証情報を、有効期間の短いAPIアクセスに交換する仕組みです。カスタムAppとフェデレーションの設定。

簡潔なCLAUDE.mdを用意し、レビューの優先事項、変更してよい範囲、修正に添えるべき検証結果を記載します。指示は作業の進め方を導き、リポジトリの権限とツールの制限はアクセスを強制的に制御します。無人実行を有効にする前に、設定済みのフック、つまりライフサイクルイベントで自動実行されるコマンドや、追加のツールサーバーも確認してください。プロジェクトの指示。より広い観点での導入判断はClaude Codeのレビュー記事で、セットアップ時に使うコマンドはスラッシュコマンドのガイドで解説しています。

任せるなら、この順番で試したい6つの仕事

依頼内容を説明しやすく、結果を確認しやすい仕事から始めましょう。以下はワークフローの提案であり、削減効果を測定した結果でも、成果の保証でもありません。

導入用の構成では、依存関係のインストールやテストスイートの実行はできません。それらが必要な仕事には、信頼できるコード向けに別途レビューした実行構成を追加し、許可するコマンドと、その構成専用の制限を指定してください。許可したテストコマンドであっても、実行するのはリポジトリのコードです。無害そうなコマンド名でも、そのコードの安全性は保証されません。

起動条件を増やす前に、つまずきやすい点を確認する

フォークからのPRでは、シークレットを使えない場合があります。 GitHubは通常、フォークを起点とするpull_requestとpull_request_review_commentの実行にシークレットを渡しません。そのジョブでClaudeの認証情報が空になるのは、信頼境界に基づく動作です。シークレットを取得するためだけにpull_request_targetへ切り替え、フォークのコードを実行してはいけません。メンテナーが起動するissue_commentのジョブにもシークレットが渡されることがあります。コメントした人を信頼できても、PR内のファイルまで信頼できるわけではありません。GitHubのフォークに関するセキュリティガイド。

ツールを制限しても、プロジェクト起動時のコードは無効になりません。 ActionはClaudeの一部の設定をベースブランチから復元しますが、スクリプトなどのプロジェクトファイルはPR側から取り込まれることがあります。Claudeに許可するツールだけでなく、フックやツールサーバーの設定も監査してください。Actionの信頼境界。

ランナーの実行時間には、別の制約があります。 標準のGitHubホステッドランナーは、パブリックリポジトリでは無料です。プライベートリポジトリではプランごとの利用枠があり、超過分は課金されます。支払い方法を登録せずに利用枠を使い切ると、ジョブが停止することがあります。Claudeの使用量と併せて、Actionsの使用量ページも確認しましょう。GitHub Actionsの課金。

正しく設定したワークフローでも、レート制限で中断することがあります。 APIの制限は、1分あたりのリクエスト数と入出力トークン数に適用されます。トークンとは、モデルが処理するテキストの単位です。retry-after付きの429が返った場合は、再試行まで待ち、同時実行するジョブを減らします。このヘッダーがなく、利用ティアの支出上限が原因で429になった場合は、実行を繰り返すのではなく、課金や上限の問題を解消する必要があります。サブスクリプションによる認証にも、そのプランの使用量上限が適用されます。APIのレート制限、Claudeの使用量上限。

ボットが応答しない問題と、その後のCIが動かない問題は別です。 応答がない場合は、デフォルトブランチにワークフローがあるか、Actionsが有効か、シークレットが入力パラメーターと対応しているか、コメントした人に書き込み権限があるかを確認します。メンションは省略せず@claudeと書いてください。後続のCIが動かない場合は、誰かがApp認証をgithub_token: ${{ secrets.GITHUB_TOKEN }}に置き換えていないか確認します。GitHubはこのトークンが生成した多くのイベントを抑止します。また、一部のPRワークフローは承認を必要とします。GitHubトークンの動作。

この仕組みから考えられる2つの事業

最も有望なのは、小規模チーム向けにレビュー環境を構築・運用するサービスです。 買い手は、役に立つ指摘、明確な責任分担、見通しの立つ運用上限を求める開発責任者です。2026年10月15日に取得したDataForSEOの米国・英語市場の推定値では、「ai code review」は月間検索数1,300件でした。関心の存在を示すデータであり、顧客数ではありません。最初に販売するサービスなら、1つのリポジトリを設定し、レビューの優先事項を指示に落とし込み、過去のPRで指摘を評価したうえで、使用量と実行失敗のレポートを継続して提供する形が考えられます。課題は誤検知による確認疲れです。コードベースが変化してもレビュー品質を維持することに、継続的な価値があります。汎用プロンプトを包んだだけのサービスでは、使い続ける理由が乏しくなります。

受託開発会社には、顧客のリポジトリで再利用できるレビューポリシーのパッケージを提供できます。 同じ市場のDataForSEO推定値では、「ai code review tools」は月間検索数590件、「github ai code review」は140件です。最小限の製品としては、再利用できるワークフロー、顧客別の指示テンプレート、認証情報の管理責任者の記録、制限の設定漏れを確認するチェックをまとめる方法があります。担当者の引き継ぎがあっても、設定の一貫性を保ちやすくなります。ただし、権限とテスト環境は顧客ごとに異なります。テンプレートの有用性を保つには、保守と評価が必要です。これらの検索語を使う層は重なっているため、検索数を足して市場規模と見なしてはいけません。

仕事に合った実行環境を選ぶ

リポジトリのイベントを起点に処理し、設定・権限・ログをCIと一緒に管理したいなら、GitHub Actionsを選びます。ノートPCを閉じたまま、ブラウザーから単発の仕事を開始して指示を調整したいなら、クラウドセッションが向いています。毎晩のバックログ確認のように、保存したタスクを繰り返し実行し、ワークフローのYAMLを保守するよりClaudeがホストするスケジュール・設定機能を使いたいなら、Routinesによる定期実行を選びます。RoutinesはGitHubとAPIのトリガーにも対応するため、スケジュール実行だけを理由にActionsを選ぶ必要はありません。Routinesは引き続きリサーチプレビューです。クラウドセッション、Routines。

月曜日に、リポジトリの管理者にAppのインストールと、制限を設けたワークフローのマージを進めてもらいましょう。既知のバグと、焦点を絞ったレビューを依頼し、出力をチーム自身の判断と照らし合わせます。確認の手間と使用量に見合う結果が得られてから、起動条件を増やしてください。

チーム向けにこのワークフローの構築・保守を依頼したい場合は、AIによる自動化をご相談ください。