Claude Code GitHub Actionsの使い方｜設定・権限・費用

「GitHubのコメントでClaudeを呼び出せると聞いたが、何を設定すればいいのか分からない」「導入したら、いくらかかるのか、勝手にコードを書き換えられないかが心配」と感じて調べている方も多いのではないでしょうか。

Claude Code GitHub Actionsは、GitHubの自動化の仕組み「GitHub Actions」の中でClaude Codeを動かす機能です。IssueやプルリクエストのコメントでClaudeを呼び出して作業を頼んだり、プルリクエストが作られたときに自動でレビューさせたり、毎朝決まった時間にレポートを作らせたりできます。パソコンを開いていなくても、GitHub上の出来事をきっかけにClaudeが動くのが、手元のClaude Codeとの大きな違いです。

この記事では、仕組みと導入の手順、設定ファイルの読み方、使い方の例、費用、権限と安全面、動かないときの確認点を順に解説します。内容は2026年10月時点の公式情報をもとにしています。画面の項目名や仕様は変わることがあるので、導入の前に公式ドキュメントもあわせて確認してください。

Claude Code GitHub Actionsとは

Claude Code GitHub Actionsは、Anthropicが公開している「claude-code-action」という部品（アクション）を、GitHubのワークフローに組み込んで使う機能です。ワークフローとは、「このような出来事があったら、この作業を実行する」という自動化の手順をまとめたファイルのことです。リポジトリの.github/workflows/フォルダに置きます。

Claudeは、GitHubが用意する実行環境（ランナー）の上で動きます。リポジトリのファイルを読み、必要ならコードを直してコミットし、結果をコメントで返します。手元のパソコンでClaude Codeを起動する必要はありません。

できること

公式ドキュメントでは、おもに次の使い方が紹介されています。

最後の2つは、誰かが「@claude」と書かなくても動きます。「何をさせるか」を設定ファイルに書いておくことで、GitHub上の出来事をきっかけに自動で実行されます。

似た名前の機能との違い

ClaudeとGitHubをつなぐ機能は複数あり、名前も似ているため混同しやすいところです。公式ドキュメントでも、この機能とは別のものとして次の3つが挙げられています。

レビューだけが目的で、TeamまたはEnterpriseプランを使っているなら、ワークフローを書かなくて済むCode Reviewのほうが手軽です。一方で、レビューの観点や実行のタイミングを細かく決めたい場合や、レビュー以外の自動化もしたい場合は、GitHub Actionsが向いています。公式ドキュメントでも、プロンプト・モデル・きっかけを自分で管理したいときに使うものとして位置づけられています。

ClaudeとGitHubの連携の全体像はClaudeとGitHubの連携の記事で、手元のClaude Codeでgitやプルリクエストを扱う方法はClaude Code GitHub連携の記事で解説しています。この記事は、GitHub Actionsの設定と運用に絞って掘り下げます。

対話モードと自動モード

アクションは、ワークフローの書き方によって、動き方を自動で切り替えます。公式ドキュメントでは「対話モード」と「自動モード」の2つが説明されています。

対話モードの「@claude」は初期設定で、trigger_phraseという項目を変えれば、別の言葉にもできます。旧バージョン（ベータ版）で必要だったmodeという設定は、いまは書かなくても、アクションが判断してくれます。

設定の手順

導入の方法は2通りあります。Claude Codeを手元で使っているなら、コマンド1つで進められるクイックセットアップが手軽です。会社の事情でコマンドが使えない場合や、ファイルの内容を細かく管理したい場合は、手動で設定します。どちらの場合も、対象のリポジトリの管理者（admin）権限が必要です。

始める前に確認すること

GitLabのパイプラインでClaude Codeを動かしたい場合は、別の仕組み（Claude Code GitLab CI/CD）が用意されています。この記事の手順はGitHub専用です。

クイックセットアップの手順

Claude Codeから/install-github-appを実行すると、GitHub Appの導入、認証情報の登録、ワークフローファイルの準備までを案内してくれます。

1. リポジトリでClaude Codeを開く対象のリポジトリのフォルダでclaudeを起動します。
2. コマンドを実行する入力欄に/install-github-appと入力し、画面の案内に従います。まずClaude GitHub Appが導入されます。
3. 認証情報を選ぶすでにClaude CodeでAPIキーを使っている場合は、そのキーが再利用されます。そうでない場合は、サブスクリプションの長期トークンを作るか、APIキーを貼り付けるかを選びます。
4. ワークフローファイルを選ぶ追加するワークフロー（「@claude」に応答するもの、PRをレビューするもの）を選びます。認証情報は、リポジトリのシークレットとして保存されます。
5. プルリクエストを作って取り込むClaude Codeがワークフローファイルを入れたブランチをプッシュし、GitHubをブラウザで開いてプルリクエストの作成画面を表示します。このプルリクエストを作成し、マージすると「@claude」が使えるようになります。

途中で中断したい場合は、Escキーを押します。すでに始まっている手順は最後まで実行され、それ以降の手順は始まりません。終了時の画面に、リポジトリにすでに行われた変更（プッシュされたブランチや保存されたシークレット）が表示されます。

GitHub Appの導入後に「GitHub Actionsの設定を続けるか」と聞かれます。「Skip for now」を選ぶと、GitHub Appだけを入れた状態で止められます。残りは、あとで/install-github-appをもう一度実行すれば進められます。

手動セットアップの手順

コマンドを使わずに設定する場合は、GitHub Appの導入、シークレットの登録、ワークフローファイルの配置を自分で行います。

1. Claude GitHub Appを入れるClaude GitHub App（github.com/apps/claude）を対象のリポジトリに導入します。アクションが使う権限は、Contents（ファイルの変更）、Issues、Pull requestsのそれぞれの読み書きです。
2. シークレットを登録するリポジトリの「Settings」→「Secrets and variables」→「Actions」から、ANTHROPIC_API_KEY（APIキー）またはCLAUDE_CODE_OAUTH_TOKEN（サブスクリプションの長期トークン）のどちらかを登録します。
3. ワークフローファイルを置くアクションのリポジトリで公開されているexamples/claude.ymlを、自分のリポジトリの.github/workflows/に置きます。そのままで動く形のファイルで、初期状態ではANTHROPIC_API_KEYを使う設定になっています。
4. 動作を確かめるIssueかPRのコメントに「@claude」と書いて、返事が来るかを確認します。

CLAUDE_CODE_OAUTH_TOKENを登録した場合は、ワークフローのanthropic_api_keyの行を、claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}に書き換えます。

認証情報の選び方

アクションがClaudeを呼び出すための認証情報には、いくつかの選択肢があります。

公式ドキュメントでは、複数のリポジトリでシークレットを共有する場合は、OAuthトークンではなく、Claude ConsoleのAPIキーを使うよう案内されています。OAuthトークンは、claude setup-tokenを実行した人のサブスクリプションに結び付いているためです。このトークンは1年間有効な長期のもので、モデルへの問い合わせにしか使えません。

組織で導入するとき

クイックセットアップも手動セットアップも、1つのリポジトリごとの設定です。組織の複数のリポジトリに広げる場合は、公式ドキュメントで次の進め方が紹介されています。

• Claude GitHub Appを組織単位で1回導入し、対象を「すべてのリポジトリ」か「選んだリポジトリ」にする
• 認証情報は、組織のActionsシークレットとして1つ登録し、リポジトリごとの登録を省く
• ワークフローファイルは、使うリポジトリごとに置くか、1つを「再利用可能なワークフロー」として定義して各リポジトリから呼び出す

長期のシークレットをそもそも保存したくない場合は、ワークロードID連携も使えます。GitHubのOIDCトークンをClaude Consoleのサービスアカウントと交換する方式で、ワークフローにはid-token: writeの権限が必要です。Console側の設定は、アクションのセットアップガイドに手順があります。

設定を取り消すとき

使うのをやめる場合は、導入した順と逆に、次の3つを取り除きます。

• ワークフローファイル：.github/workflows/から、アクションを使っているファイルを削除する（クイックセットアップならclaude.yml、レビュー用を選んだならclaude-code-review.yml）
• シークレット：リポジトリや組織のシークレットを削除する。ただし、シークレットを消しても、認証情報そのものは有効なままなので、完全に無効にするにはClaude ConsoleでAPIキーも削除する
• GitHub App：リポジトリや組織の設定からClaude GitHub Appを削除する。ただし、Code Reviewなど、ほかのClaudeの機能も同じAppを使うため、それらを使っているなら残す

ワークフローファイルの読み方

ワークフローファイルは、YAML（ヤムル）という形式で書かれた設定ファイルです。プログラムを書けなくても、何がどこに書いてあるかが分かれば、読んだり調整したりできます。ここでは、公式ドキュメントに載っている「@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：いつ動くか

onには、ワークフローを動かすきっかけ（イベント）を書きます。上の例では、IssueやPRにコメントが書かれたとき（issue_comment）と、PRの行コメントが書かれたとき（pull_request_review_comment）です。よく使うイベントは次のとおりです。

if：条件を絞る

ifの行は、「コメントに『@claude』が入っているときだけ実行する」という条件です。これがないと、コメントが書かれるたびに実行環境が起動し、GitHub Actionsの実行時間を消費してしまいます。公式ドキュメントによると、アクション自体もトリガーフレーズを確認しますが、起動前に絞っておくことで無駄な実行を防げます。

permissions：何を許可するか

permissionsは、このワークフローが使うGitHubの権限を決めます。必要なものだけを書くのが基本です。

レビューだけをさせるワークフローなら、書き込み権限は不要です。公式ドキュメントのレビュー用の例でも、contents: read、pull-requests: read、issues: read、id-token: writeだけが指定されています。やらせたいことに合わせて、権限を減らしていきましょう。

steps：実際の作業

stepsには、順番に実行する作業を書きます。

• actions/checkout：リポジトリの内容を実行環境に取り込みます。Claudeが作業するための手元のコピーになります。fetch-depth: 1は、履歴を最新の1件だけ取る指定で、動きが速くなります
• anthropics/claude-code-action@v1：Claude Code GitHub Actionsの本体です。@v1は、バージョン1系を使うという指定です
• with：本体に渡す設定です。anthropic_api_keyに、登録したシークレットを指定します

${{ secrets.ANTHROPIC_API_KEY }}という書き方は、「リポジトリのシークレットに登録した値を使う」という意味です。APIキーそのものをファイルに書き込んではいけません。ファイルはリポジトリの利用者全員に見えるため、キーが漏れてしまいます。

with：アクションに渡す設定

よく使う設定項目を、公式ドキュメントから抜き出しました。

全項目は、アクションのリポジトリにある設定リファレンスに載っています。ブランチ名の接頭辞（branch_prefix、初期値はclaude/）、コミットの署名、1つのコメントだけを更新させる設定など、運用で役立つ項目も多くあります。

claude_argsで渡せるもの

claude_argsには、Claude CodeのCLIで使う引数をそのまま書けます。公式ドキュメントで紹介されているのは次のものです。

複数を書くときは、YAMLの|を使って1行に1つずつ書くと読みやすくなります。

claude_args: |
  --max-turns 10
  --model claude-sonnet-5
  --allowedTools "Bash(npm:*),Bash(git:*)"

使い方の例

ここからは、具体的な使い方を紹介します。YAMLは公式ドキュメントとアクションのリポジトリの例をもとにしています。使うときは、自社のリポジトリに合わせて書き換えてください。

@claudeで頼む

最も基本的な使い方です。前の章のワークフローを置くと、IssueやPRのコメントで「@claude」と書くだけで、Claudeが動き始めます。公式ドキュメントには、次のような依頼の例が載っています。

@claude implement this feature based on the issue description
@claude how should I implement user authentication for this endpoint?
@claude fix the TypeError in the user dashboard component

日本語でも依頼できます。ただし、公式ドキュメントに日本語の例は載っていないため、依頼がうまく伝わらない場合は、具体的に書くようにしてください。

Claudeは、返事を1つのコメントにまとめ、作業の進み具合に合わせて更新していきます。コメントの内容は、アクションのリポジトリのFAQで、「進捗のチェックボックス付きで、同じコメントが更新される」と説明されています。

プルリクエストを自動でレビューする

プルリクエストが作られたときに、自動でレビューさせる例です。公式ドキュメントでは、code-reviewプラグインを入れて、そのスキルを実行する形で紹介されています。

name: Code Review
on:
  pull_request:
    types: [opened, synchronize, ready_for_review, reopened]
jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: read
      issues: read
      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 }}
          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: '--allowedTools "mcp__github_inline_comment__create_inline_comment"'

このワークフローで重要なのは、次の2か所です。

• --comment：付けると、レビュー結果がプルリクエストにコメントとして投稿されます。付けないと何も投稿されず、結果は実行ログでしか読めません
• claude_argsの--allowedTools：行ごとのコメントを投稿するための仕組みを起動するのに必要です。スキル側に同じ許可が書かれていても、この行は残しておきます

公式ドキュメントによると、Claudeはドラフトや閉じられたプルリクエスト、自動作成や軽微な変更と判断したもの、すでにClaudeのコメントが付いているものは見送ります。また、公開リポジトリでは、フォークからのプルリクエストにはGitHubがシークレットを渡さないため、同じリポジトリ内のブランチからのプルリクエストだけがレビューされます。

レビューの対象を絞りたいときは、onにpathsを書くと、特定のフォルダやファイルが変更されたときだけ実行できます。アクションのリポジトリには、そのための例（pr-review-filtered-paths.yml）も用意されています。

毎朝のレポートを作る

promptを書けば、スケジュールのような「人の操作がないきっかけ」でも動かせます。毎日決まった時刻に、前日のコミットと未解決のIssueをまとめる例です。

name: Daily Report
on:
  schedule:
    - cron: "0 9 * * *"
jobs:
  report:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      issues: read
      id-token: write
    steps:
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: "Generate a summary of yesterday's commits and open issues"
          claude_args: |
            --model claude-sonnet-5
            --allowedTools "mcp__github__list_commits,mcp__github__list_issues"

スケジュール実行では、次の点に注意してください。

• 時刻はUTC：cronの時刻はUTC（協定世界時）で書きます。日本時間（JST）はUTCより9時間進んでいるため、上の「0 9 * * *」は日本時間の18時です。日本時間の朝9時なら「0 0 * * *」になります
• ツールを許可する：文章のpromptだけでは、Claudeはシェルやコマンドを使えません。必要なツールを--allowedToolsで許可します。上の例では、コミットとIssueを読む2つのツールを許可しています
• 既定のブランチだけ：GitHubは、スケジュール実行を既定のブランチのファイルからのみ動かします
• 公開リポジトリでは自動停止がある：公開リポジトリでは、60日間活動がないと、スケジュールが無効になります
• 結果は実行ログ：初期状態では、結果は実行ログに残ります。IssueやSlackに送りたい場合は、そのための指示とツールが別に必要です

スケジュール実行は「人がコメントした」というきっかけがないため、実行者の確認の対象外です。ただし、GitHubはスケジュール実行を、cronの設定を最後に変えたユーザーの実行として扱います。そのユーザーがボットの場合は、allowed_botsにそのボットを入れないと動きません。

Issueにラベルを付ける

新しいIssueの内容を読んで、ラベルを付ける例です。アクションのリポジトリのissue-triage.ymlでは、次のような設定になっています。

on:
  issues:
    types: [opened]
jobs:
  triage-issue:
    runs-on: ubuntu-latest
    timeout-minutes: 10
    permissions:
      contents: read
      issues: write
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 0
      - uses: anthropics/claude-code-action@v1
        with:
          prompt: "/label-issue REPO: ${{ github.repository }} ISSUE_NUMBER: ${{ github.event.issue.number }}"
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          allowed_non_write_users: "*"
          github_token: ${{ secrets.GITHUB_TOKEN }}

この例では、/label-issueというスキルとスクリプトを、リポジトリ側に用意しておく必要があります。また、allowed_non_write_users: "*"は、書き込み権限のない人が作ったIssueでも動かす設定です。セキュリティ上の注意点があるため、後の「権限と安全」の章で説明します。

timeout-minutes: 10は、実行時間の上限を10分にする指定です。想定外に長く動き続けて、費用がかさむことを防げます。

CIの失敗を自動で直させる

アクションのリポジトリには、CI（自動テスト）が失敗したときに、失敗の内容をClaudeに渡して修正させる例（ci-failure-auto-fix.yml）もあります。CIが失敗したことをきっかけにworkflow_runで動き、失敗したジョブのログを集めてClaudeに渡し、修正用のブランチを作る流れです。

便利な反面、この例には、ファイルの冒頭に注意書きがあります。プルリクエストのブランチのコードを、書き込み権限のある状態で実行するため、リポジトリへの書き込み権限を持つ全員が信頼できる場合にだけ使うように書かれています。外部の協力者を受け入れているリポジトリでは使わないでください。

スキルやプラグインを実行する

promptには、文章のほか、スキルの呼び出しも書けます。リポジトリの.claude/skills/に置いたスキルなら、actions/checkoutをアクションの前に実行して、/スキル名をpromptに書きます。プラグインに入っているスキルは、plugin_marketplacesとpluginsでプラグインを入れてから、/プラグイン名:スキル名の形で呼び出します。

チームで決めたレビュー手順やリリース前のチェックをスキルにしておけば、同じ手順を手元でもGitHub上でも使い回せます。

費用の考え方

Claude Code GitHub Actionsには、機能そのものの利用料はかかりません。かかるのは、GitHub Actionsの実行時間と、Claudeの利用料の2つです。公式ドキュメントでも、1回の実行でこの2種類を消費すると説明されています。

2種類の費用

サブスクリプションの長期トークンで認証した場合は、APIの従量課金ではなく、Claudeの契約を使います。ただし、契約の利用枠のうち、この実行がどのように数えられるかの詳しい説明は、公式ドキュメントでは確認できませんでした。まず少ない回数で試し、使用量の画面で減り方を確かめてください。

GitHub Actionsの実行時間

GitHubのプランには、毎月無料で使える実行時間があります。GitHubの公式ドキュメントでは、標準のGitHub-hostedランナー（GitHubが用意する実行環境）について、次の枠が案内されています。

公開リポジトリで標準のランナーを使う場合は、無料です。枠を超えると、実行環境ごとの分単価で課金されます。同じページでは、Linuxの2コアが1分あたり0.006米ドルと案内されています（2026年10月時点）。macOSやWindowsのランナーは単価が高くなります。公式ドキュメントの例はいずれもLinuxのubuntu-latestなので、この指定のままにしておけば、単価を低く保てます。

Claudeの利用料

APIキーで認証する場合、Claudeの利用料は、APIの従量課金です。指示や読み込んだファイルの長さ、Claudeの回答の長さ、作業の回数に応じたトークン（文字量の単位）の数で決まります。レビューのように、変更の多いプルリクエストを読む作業や、リポジトリ全体を調べる作業は、トークンを多く使います。トークンの単価は、Anthropicの料金ページで公開されています。

費用は、リポジトリの大きさ、プルリクエストの数、頼み方によって大きく変わるため、一般的な金額の目安は示せません。まず、1つのリポジトリで1〜2週間試し、Claude Consoleの使用量で実際の金額を確かめてから、広げる範囲を決めるのが確実です。

費用を抑える方法

公式ドキュメントでは、2種類の費用を下げるための方法が、次のように紹介されています。

特に、--max-turnsとtimeout-minutesは、設定しておくだけで、想定外の費用を防ぎやすくなります。最初は小さめの値で始め、足りなければ増やす進め方がおすすめです。

クラウド経由で使う場合

Claude APIを直接使うかわりに、自社のクラウド契約を通してClaudeを使うこともできます。アクションには、Amazon Bedrock（use_bedrock: "true"）、Google Cloudの基盤（use_vertex: "true"）、Microsoft Foundry（use_foundry: "true"）のための設定があります。

この場合、GitHubのOIDCトークンでクラウドに認証するため、リポジトリにクラウドの長期的な認証情報を保存する必要がありません。クラウド側では、IAMロールなどの信頼設定を事前に作ります。手順はクラウドごとに異なるので、公式ドキュメントの「Use Claude Code GitHub Actions with cloud providers」を参照してください。Bedrockを使ったClaude Codeの導入全般はClaude Code Bedrockの記事で解説しています。

権限と安全

Claudeは、リポジトリのファイルを書き換え、コメントを投稿できます。そのため、誰が動かせるのか、何を許可するのかを、先に決めておくことが大切です。ここでは、公式ドキュメントとアクションのリポジトリのセキュリティ文書をもとに整理します。

誰が動かせるか

アクションは、実行の前に、動かした人を2つの観点で確認します。どちらかに該当すると、実行は失敗します。

つまり、通常の設定では、リポジトリに書き込める人だけが、Claudeを呼び出せます。外部の人が公開リポジトリにIssueを書いても、Claudeは動きません。

GitHub Appの権限

Claude GitHub Appは、Claudeのさまざまな機能（Claude Code GitHub Actions、Code Review、クラウドセッションの自動修正）で共通して使われます。GitHub Appの権限は1つのセットにまとまっているため、導入時には次の権限をまとめて許可することになります。

GitHubでは、権限の一部だけを受け入れることができません。この権限の範囲が組織の方針に合わない場合は、公式ドキュメントで、Contents・Issues・Pull requestsの3つだけを持つ、自社専用のGitHub Appを作る方法が案内されています。ただし、自作のAppで動くのは、Claude Code GitHub Actionsだけです。Code Reviewやクラウドセッションの自動修正には、公式のAppが必要です。

使えるツールを絞る

Claudeが使えるツールは、--allowedToolsで決まります。アクションのリポジトリのFAQでは、シェルコマンドの実行（Bashツール）は、初期状態では無効と説明されています。使わせたいコマンドだけを、次のように指定します。

claude_args: |
  --allowedTools "Bash(npm install),Bash(npm run test:*),Bash(npm run lint:*)"

このように、実行してよいコマンドを名前で限定します。「すべて許可」にせず、テストと静的解析など、必要なものだけを許可するのが基本です。

Claudeにできないこと

アクションのリポジトリのFAQとセキュリティ文書には、Claudeの動作の制限が書かれています。

• ブランチのマージ、リベース、強制プッシュ（force push）はしない。呼び出されたブランチ（自分のブランチかPRのブランチ）以外には、プッシュしない
• 初期設定では、プルリクエストを自動では作らない。変更を新しいブランチにコミットし、プルリクエスト作成ページへのリンクを返す。人が確認してから作成する
• 権限は、動かしているリポジトリの中に限られる。ほかのリポジトリにはプッシュできない
• 閉じられたプルリクエストには、プッシュできない。新しいブランチが作られる

これらは、システムの指示として実装されているため、--allowedToolsでgitのコマンドを許可しても、リベースの依頼は断られると説明されています。

外部からの入力に注意する

公開リポジトリのIssueやコメントは、誰でも書けます。そこに、AIへの指示が隠されている可能性があります（プロンプトインジェクション）。たとえば、HTMLのコメントや見えない文字を使って、「秘密の情報を出力して」といった指示が混ぜられることがあります。

アクションは、HTMLコメントや見えない文字などを取り除いて、Claudeに渡します。ただし、セキュリティ文書では、新しい回避方法が出てくる可能性があるため、外部の協力者からの入力は、原文を確認してからClaudeに処理させることをすすめています。公開リポジトリでは、include_comments_by_actorで、Claudeに渡すコメントの書き手を絞る方法もあります。

pull_request_targetとworkflow_runの注意

pull_request_targetやworkflow_runは、リポジトリ本体のシークレットを使って実行されます。セキュリティ文書では、これらで信頼できない参照先（フォークのプルリクエストの内容など）を作業場所のルートにチェックアウトしてから、アクションを動かさないよう案内されています。外部の人のプルリクエストを扱う場合は、基本のブランチをルートにチェックアウトし、プルリクエストの内容は別のフォルダに取り込んで、--add-dirで渡す方法が示されています。

また、プルリクエストでアクションを動かすときは、.claude/、CLAUDE.md、.mcp.jsonなどの設定ファイルを、プルリクエストの内容ではなく、基本ブランチのものに戻してから実行します。プルリクエストの作者が、設定ファイルを書き換えて、Claudeの動作を変えることを防ぐ仕組みです。

認証情報とログの扱い

• APIキーやトークンは、必ずGitHubのシークレットに登録し、ワークフローファイルに直接書かない
• ワークフローには、必要な権限だけを書く
• Claudeの変更は、マージする前に必ず人が確認する
• show_full_output（出力をすべて表示する設定）は、初期状態では無効。有効にすると、ツールの実行結果や環境変数などがログに出るため、公開リポジトリでは、ログが誰にでも見える状態になる
• GitHub Actionsのデバッグモードを有効にすると、同じく全出力が表示される

コミットの署名は、初期状態では付きません。use_commit_signingかssh_signing_keyを設定すると、「Verified」の表示が付く署名付きのコミットにできます。前者はGitHubのAPIを使うため設定が簡単ですが、リベースなどの複雑なgit操作はできません。

導入前に決めておくこと

会社で使う場合は、次の項目を先に決めておくと、運用が安定します。

動かないとき

設定したのに「@claude」に反応しない、期待した動きにならない、といった場合の確認点を整理します。公式ドキュメントとアクションのリポジトリのFAQにある内容をもとにしています。

@claudeに反応しない

最後の項目は、公式ドキュメントに明記されたものではなく、GitHub Actionsの一般的な仕様です。コメントをきっかけにした実行では、既定のブランチにあるワークフローが使われるため、/install-github-appで作られたプルリクエストをマージしていないと動きません。

認証のエラーが出る

• APIキーまたはトークンが有効かを、手元のclaudeで確かめてから、ワークフローを調べる
• 標準のGitHub App認証を使う場合は、permissionsにid-token: writeが入っているかを確かめる。ないと、OIDCの認証でエラーになる
• Bedrock・Google Cloud・Foundryでは、クラウド側のロールの信頼設定と、シークレットの名前が合っているかを確かめる

「403 Resource not accessible by integration」と出る

アクションのリポジトリのFAQによると、GitHub Appのトークンでは、ユーザー情報のAPIにアクセスできないために起きるエラーです。現在のバージョンでは、bot_idとbot_nameの初期値がClaudeのボットになっているため、通常は起きません。独自のボットを使う場合は、この2つを両方指定します。

Claudeのコミットで、CIが動かない

公式ドキュメントでは、次の2点が案内されています。

• GitHubは、標準のGITHUB_TOKENで作られたコミットでは、別のワークフローを起動しない。github_token: ${{ secrets.GITHUB_TOKEN }}をアクションに渡している場合は、その行を削除するか、自作のGitHub Appのトークンを渡す
• CIのワークフローのonに、Claudeのプッシュで起きるイベント（pushやpull_request）が入っているかを確かめる

うまくいかない原因を調べるには

Claudeが何をしたかは、GitHubの「Actions」タブから、該当の実行のログで確認できます。ログには、読んだファイルや、実行しようとしたコマンドが記録されます。ツールの許可が足りずに止まっている場合は、そのログから、どのツールを許可すればよいかが分かります。

それでも原因が分からない場合は、アクションのリポジトリのFAQとIssueを確認してください。

よくある質問

まとめ

GitHub Actionsは、設定さえ整えれば、レビューやレポート作成を人の手を離れて回せる仕組みです。一方で、権限・費用・外部からの入力への備えを後回しにすると、かえって運用の負担になります。まずは小さなリポジトリで、上限を付けて試すのが確実です。

社内のリポジトリへの導入や、ワークフローの設計、権限と費用のルールづくりでお困りの場合は、INTERCREATE JAPANがClaude Codeの導入支援としてお手伝いしています。