Claude Code GitHub Actionsは、GitHubのリポジトリの中でClaude Codeを動かす仕組みです。IssueやPull Request(PR)のコメントに@claudeと書いて依頼すると、GitHub Actionsのワークフローが起動し、Claudeがコードを読み、変更をブランチにコミットして、結果を同じコメント欄に返します。手元のパソコンを開いていなくても、GitHub上のやり取りだけで作業を任せられるのが特徴です。

この記事は、2026年10月30日に確認したAnthropicの公式資料、Claude Code GitHub Actionの公式リポジトリの文書、GitHub Actionsの公式資料をもとに、編集部が設定と確認の手順をまとめたものです。本文中のワークフローや依頼文は説明用の例で、編集部が実際のリポジトリで動かして確かめた実測結果ではありません。入力項目や既定値は版によって変わるため、導入時は公式の例と照らし合わせてください。

Claude Code GitHub Actionsとは:PRやIssueからClaude Codeを動かすワークフロー

Claude Code GitHub Actionsの公式資料(英語)では、この機能はanthropics/claude-code-actionという部品(Action)を、リポジトリのワークフローの中で動かす仕組みと説明されています。PRやIssueのコメントで@claudeに頼むと、Claudeがコードを分析し、変更を加えてコミットします。また、プロンプトを指定しておけば、PRが作られたときや決まった時刻など、GitHubのイベントをきっかけに自動で動かすこともできます。

動き方は、ワークフローにprompt(指示文)を書くかどうかで自動的に決まります。

モード決まり方起動のきっかけ結果が出る場所
対話モードpromptを指定しないコメントやレビュー、新しいIssueの本文・題名にある@claude依頼したIssueやPRのコメント
自動化モードpromptを指定するワークフローに書いたイベント(PRの作成、定期実行など)既定ではワークフローの実行ログ

名前の似た機能と混同しないことも大切です。PRごとに自動でレビューを付ける「Code Review」は、ワークフローを書かずに使うTeam・Enterprise向けの機能です。手元のパソコンでスクリプトからclaude -pを呼ぶ使い方はheadless実行の記事、手元で決まった処理を自動で走らせる仕組みはhooksの記事で説明しています。この記事は、GitHubのイベントから起動した仕事の設定・権限・結果の受け取り方に絞ります。

@claudeの依頼から結果を受け取るまでの流れです(Issueから依頼した場合)。コメントに@claudeと書いて依頼し、依頼者の権限を確かめてActionsが起動し、ブランチにコミットして進み具合を1つのコメントに示し、人が差分を確かめてPRを作成・マージします。
図:@claudeの依頼から結果を受け取るまでの流れです(Issueから依頼した場合)。コメントに@claudeと書いて依頼し、依頼者の権限を確かめてActionsが起動し、ブランチにコミットして進み具合を1つのコメントに示し、人が差分を確かめてPRを作成・マージします。編集部の説明図です。製品の実画面ではありません。画像を開くと拡大できます。

GitHub Actionsを設定する前に決めること

導入の作業そのものは短く済みますが、先に次の3点を決めておくと、あとで設定を作り直さずに済みます。

  • リポジトリの管理者権限:どちらの導入方法でも、対象リポジトリの管理者(admin)権限が必要です。
  • 認証の方法:Claude Consoleで作るAPIキー(シークレット名ANTHROPIC_API_KEY)か、Claudeのサブスクリプション(Pro・Max・Team・Enterprise)で使うOAuthトークン(CLAUDE_CODE_OAUTH_TOKEN)のどちらかを選びます。APIキーは使った分だけAPIの料金がかかり、OAuthトークンはサブスクリプションの利用枠を使います。OAuthトークンは手元でclaude setup-tokenを実行して作ります。
  • 費用の見込み:実行のたびに、GitHub Actionsの実行時間(ワークフローを動かすGitHub側の仮想マシン「ランナー」の利用分)と、Claudeの利用分の2種類がかかります。

複数のリポジトリで同じ認証情報を使う組織では、公式資料は、OAuthトークンよりもClaude ConsoleのAPIキーを勧めています。OAuthトークンはclaude setup-tokenを実行した人のサブスクリプションに結び付くためです。長く有効なシークレットそのものを置きたくない場合は、GitHubが発行する一時的な身分証明(OIDCトークン)を使う「ワークロードIDフェデレーション」という方法も用意されています。Amazon Bedrock、Google CloudのAgent Platform、Microsoft Foundryを経由させる場合は、クラウドプロバイダー向けの公式手順に従います。

Claude Code GitHub Actionsの導入手順

導入方法は、Claude Codeのコマンドで進める「クイックセットアップ」と、自分でファイルを置く「手動セットアップ」の2つです。

クイックセットアップ:/install-github-appで進める

  1. GitHub CLIを用意する。ghコマンドを入れ、gh auth loginでGitHubにログインしておきます。
  2. コマンドを実行する。対象リポジトリのフォルダーでclaudeを起動し、/install-github-appを実行して案内に従います。Claude GitHub Appのインストールと、認証情報のシークレット登録が進みます。
  3. PRを作ってマージする。Claude Codeがワークフローのファイルを入れたブランチを作り、PRを作る画面をブラウザで開きます。PRを作成してデフォルトブランチへマージすると、@claudeが使えるようになります。

このコマンドはgithub.comのリポジトリ専用です。GitLabやBitbucketのリポジトリでは案内を表示して終了します(GitLabにはGitLab CI/CD向けの公式手順があります)。途中でやめたい場合はEscキーを押すと、実行中の手順だけを終えて止まり、どこまで済んだかが表示されます。

手動セットアップ:アプリ・シークレット・ワークフローを自分で置く

  1. Claude GitHub Appをリポジトリにインストールします。
  2. リポジトリのSettingsにある「Secrets and variables」から、Actions用のシークレットとしてANTHROPIC_API_KEYかCLAUDE_CODE_OAUTH_TOKENを登録します。
  3. 公式リポジトリのexamples/claude.ymlを、自分のリポジトリの.github/workflows/に置き、デフォルトブランチに入れます。OAuthトークンを使う場合は、ファイル内のanthropic_api_keyの行をclaude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}に置き換えます。

コマンドが失敗したときや、手元でClaude Codeを使っていないとき、ワークフローの中身を自分で管理したいときは、手動セットアップを選びます。導入後は、IssueかPRのコメントで@claudeに簡単な質問をして、返事が来るかを確かめます。

最小のGitHub Actionsワークフローを1行ずつ読む

公式資料に載っている、@claudeのメンションに応える(対話モードだけの)最小のワークフローは次のとおりです。スマホでは長い行が折り返して表示されます。

name: Claude Code
on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]
jobs:
  claude:
    if: contains(github.event.comment.body, '@claude')
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
      issues: write
      id-token: write
      actions: read
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
  • on:IssueやPRへのコメント(issue_comment)と、PRのコード行へのレビューコメント(pull_request_review_comment)が「作成されたとき」に起動します。types: [created]なので、コメントを編集しただけでは起動しません。
  • if:コメントに@claudeが含まれるときだけジョブを動かします。関係のないコメントでランナーを起動しないための条件です。
  • permissions:ファイルの変更、PRとIssueへの書き込みを許可します。id-token: writeはClaude GitHub Appとして認証するために必要で、actions: readはPRのCI結果をClaudeが読むためのものです。
  • actions/checkout:Claudeが作業するためのリポジトリのコピーをランナーに用意します。
  • anthropic_api_key:登録したシークレットを渡します。キーをファイルに直接書いてはいけません。

なお、公式リポジトリのexamples/claude.ymlには、この2つに加えて、新しいIssueの作成・担当者の割り当て(issues)と、PRレビューの提出(pull_request_review)でも起動する条件が書かれています。Issueを立てた時点の本文で依頼したい場合は、examples/claude.ymlをそのまま使います。

GitHub Actionsで起動するイベントを決める

同じClaude Code GitHub Actionsでも、起動のきっかけによって、設定と結果の受け取り方が変わります。

きっかけ設定の要点結果の受け取り方
@claudeのコメントpromptなし(対話モード)同じIssue・PRのコメントが作業に合わせて更新される
PRの作成・更新pull_requestイベントとprompt(スキルの呼び出しも可)既定は実行ログ。レビューの例では--commentでPRにコメントを付ける
決まった時刻scheduleのcron(実行する時刻の書式)とprompt実行ログ。使うツールの許可が別に必要

PRのレビューを自動で付けたい場合、公式資料にはcode-reviewプラグインを入れてスキルを呼ぶ例があります。公開リポジトリでは、フォーク(他の人のコピー)から出されたPRにシークレットが渡されないため、このレビューは同じリポジトリのブランチから出たPRだけで動きます。

定期実行では、GitHub側の注意が2つ、Claude側の注意が1つあります。GitHubは定期実行のワークフローをデフォルトブランチからしか動かさず、公開リポジトリでは60日間リポジトリに動きがないと定期実行を止めます。また、自動化モードで普通の文章をpromptにした場合、Claudeはそのままではシェルの実行もGitHubのAPIも使えません。必要なツールだけを、claude_argsの--allowedToolsか、settingsの許可ルールで渡します。

GitHub Actionsで許可する範囲を絞る

GitHub上のClaudeは、リポジトリに書き込める権限で動きます。誰が起動できるか、Claudeが何をできるかを、次の3段階で絞ります。

起動できる人を確かめる

公式資料によると、IssueやPRのイベントでは、依頼した人がリポジトリへの書き込み権限を持っていない場合、実行は失敗します。また、ボットからの起動は既定で拒否され、allowed_botsに書いたものだけが許されます。ボット同士がClaudeを呼び合って止まらなくなるのを防ぐためです。書き込み権限のない人にも使わせるallowed_non_write_usersという設定もあります。これは自前のgithub_tokenを渡したときだけ効く設定で、公式リポジトリのセキュリティ文書は「大きなリスクがある」とし、権限をごく狭くしたワークフローだけで使うよう求めています。また同じ文書は、allowed_botsに*(すべてのボット)を指定すると、公開リポジトリでは外部のアプリからも起動されうるとして、信頼できるボットだけを名前で書くよう勧めています。

ワークフローとアプリの権限を見直す

ワークフローのpermissionsは、必要なものだけにします。たとえばレビューのコメントだけを付けるワークフローなら、ファイルへの書き込み(contents: write)は要りません。一方、Claude GitHub Appは、Code Reviewなど他のClaudeの機能と共通のアプリのため、インストール時にはClaude Code GitHub Actionsが使わない権限も含めて一括で許可することになります。GitHubは一部だけの許可を認めていないため、使う権限をContents・Issues・Pull requestsに限りたい場合は、公式の手順に沿って自前のGitHub Appを作って使えます。

Claudeが使えるツールと信頼できない入力

claude_argsの--allowedToolsには、許可するツールを必要な分だけ並べます。公式リポジトリの文書は、外部の人が書いたIssueやコメントに、HTMLコメントや見えない文字で指示を隠して紛れ込ませる手口(プロンプトインジェクション)にも注意を促しています。公開リポジトリでは、Claudeに渡すコメントの書き手をinclude_comments_by_actorで限る設定も用意されています。

GitHub Actionsの実行結果とログを確かめる

対話モードでは、Claudeは依頼されたIssueやPRに1つのコメントを付け、作業が進むたびにその同じコメントを書き換えます。チェック項目で進み具合が表示されるため、新しいコメントが増えていかなくても作業は進んでいます。

コードを変更した場合、開いているPRへの依頼ならそのPRのブランチに、Issueや閉じたPRへの依頼なら新しいブランチにコミットが追加されます。公式リポジトリのFAQによると、既定ではClaudeはPRを自動では作らず、コメントにPRを作成する画面へのリンクを示します。PRを作るかどうか、マージするかどうかは、差分を読んだ人が決める設計です。また、Claudeは依頼されたブランチ以外へのpushや、強制push・rebaseのような履歴を書き換える操作は行いません。

自動化モードの結果や、思ったように動かなかった理由は、GitHubのActionsタブで該当する実行を開き、ジョブのログで確かめます。既定のログは、エラーや完了の状態など必要な情報に絞って表示されます。すべての出力をログに出す設定がshow_full_outputで、GitHub Actionsのデバッグモードでも自動で有効になります。ファイルの中身やコマンドの結果がそのまま残るため、公式リポジトリの文書は、このログを誰でも見られる公開リポジトリでは使わないよう注意しています。

Claudeのコミットに対してCIが動かない場合は、ワークフローでgithub_token: ${{ secrets.GITHUB_TOKEN }}を渡していないかを確認します。GitHubは標準のGITHUB_TOKENで作られたコミットではワークフローを起動しないため、公式資料は、この行を消してClaude GitHub Appとして認証させる方法を案内しています。

同じイベントでの再実行と重複を防ぐ

GitHubの公式資料(再実行)によると、ワークフローの実行を「Re-run」で再実行すると、最初に起動した人の権限で、元のイベントと同じコミット・同じブランチを対象に動き直します(再実行できるのは最初の実行から30日以内)。Claudeの場合も、元のコメントの依頼をもとにもう一度動くと考えられますが、公式資料に明記はなく、編集部も確かめていません。そこで編集部としては、途中までコミットが進んでいた実行をそのまま再実行するより、ブランチの状態を確かめてから、新しいコメントで「続きから」と依頼し直す方が、変更が二重になりにくいと考えます。

同じPRに続けて@claudeと書くと、複数の実行が同時に走ることがあります。公式資料は、費用を抑える方法の1つとして、GitHubの同時実行の制御(concurrency)で並行する実行を絞ることを挙げています。具体的な書き方の例は載っていないため、ここでは編集部が作った例を示します(実際のリポジトリでは動かしていません)。ジョブに次の設定を足すと、同じIssue・PRの番号ごとに1つずつ動くようになります。

    concurrency:
      group: claude-${{ github.event.issue.number || github.event.pull_request.number }}
      cancel-in-progress: false

ただし、GitHubの公式資料(同時実行の制御)によると、既定では同じグループで待機できる実行は1つだけで、新しい実行が来ると待機中の古い実行は取り消されます。依頼を取りこぼさずに順番に処理したい場合は、同じ資料にあるqueue: maxの指定(最大100件まで待機)も検討してください。あわせて、公式資料が勧めるとおり、claude_argsの--max-turnsでやり取りの回数を、ジョブのtimeout-minutes(GitHubのワークフロー構文)で動かせる時間の上限を決めておくと、想定外に長く動き続けることを防げます。

@claudeに反応しない時のGitHub Actionsの確認順

  1. アプリとワークフロー:Claude GitHub Appがリポジトリに入っているか、Actionsが有効か、ワークフローのファイルがデフォルトブランチにあるかを確かめます。GitHubの公式資料(ワークフローを起動するイベント)によると、IssueやPRの会話欄へのコメント(issue_comment)で動くワークフローは、デフォルトブランチにあるファイルからしか起動しません。
  2. シークレット:ANTHROPIC_API_KEYかCLAUDE_CODE_OAUTH_TOKENが登録され、ワークフローの入力名と合っているかを見ます。認証エラーなら、同じキーを手元のclaudeで試して有効か確かめます。
  3. 書き方と依頼者:@claudeが独立した語として書かれているか(/claudeや@claude-botでは反応しません)、依頼した人に書き込み権限があるかを確認します。
  4. 古い設定:anthropics/claude-code-action@betaを使っている場合は@v1に変え、modeの入力を消し、direct_promptをpromptに、max_turnsやmodelをclaude_argsに移します。

使い終わった場合は、ワークフローのファイルとシークレットを削除します。Claude GitHub Appは、Code Reviewなど他のClaudeの機能で使っていなければ削除します。シークレットを消しても中のAPIキー自体は有効なままなので、使わないキーはClaude Consoleでも削除します。

まとめ:GitHub Actionsは小さな依頼と権限の確認から始める

Claude Code GitHub Actionsは、@claudeのコメントやGitHubのイベントからClaude Codeを動かし、結果をコメントとブランチで受け取る仕組みです。最初は対話モードの最小ワークフローで、小さな修正を1件だけ依頼し、コメントの更新、ブランチへのコミット、PRを作る前の差分確認までを一通り確かめます。そのうえで、起動できる人、ワークフローの権限、許可するツール、同時実行の上限を決めてから、PRの自動レビューや定期実行へ広げると安全です。Claude Code全体の始め方はインストール手順、手元での権限の考え方は権限設定の記事も参考にしてください。

チームで導入する場合は、誰が@claudeで依頼してよいか、Claudeのコミットを誰がレビューしてマージするか、月の費用をどこまで許すかを先に決めておくと、運用が安定します。業務の流れに合わせた設計や社内ルールづくりは、PLaiのAI社員導入支援でも相談できます。