Claude Code を GitHub Actions で動かす【2026年10月】— 法人が先に決める認証・権限・費用の上限

「Pull Request が出たら Claude に先にレビューさせたい」「毎朝、前日の Issue とコミットの要約を自動で出したい」。GitHub を使っている会社で Claude Code を試した担当者が次に考えるのは、手元の PC ではなく GitHub Actions の側で動かすことです。

ただし、GitHub Actions で動く Claude は「社員の代わりにコミットを押し、Issue に返事を書く別の利用者」になります。誰が起動できるのか、どの権限を GitHub に渡すのか、認証に何を使うのか、費用はどこに積み上がるのかを、動かす前に決めておく必要があります。

この記事では、Claude Code の公式ドキュメント（2026年10月時点）と GitHub の課金ドキュメントだけを出典に、Claude Code GitHub Action の2つの動き方、認証の3つの選び方、GitHub App の権限、二重の費用の上限の切り方、導入前チェックリストと雛形を整理します。読者は、社内の情報システム・開発・業務改善の担当者を想定しています。

1. 似た名前の製品が3つある。 ワークフローファイルで動かす「Claude Code GitHub Action」、ワークフロー不要の管理型「Code Review」、クラウドで動く「Claude Code on the web」。この記事は1つ目が主題で、2つ目との違いを費用面で押さえます
2. 動き方は2つ。 prompt を書かなければ @claude のメンションに応答する対話モード、prompt を書けばイベントで無人に動く自動モード。自動モードの Claude は、許可しない限りシェルも GitHub API も触れません
3. 認証は「人に紐づくか」で選ぶ。 API キーは組織の資産、OAuth トークンは発行した人のサブスクリプションに紐づきます。複数リポジトリで共有するなら API キーか、秘密情報を置かない OIDC 連携です
4. GitHub App の権限は全部まとめて受け入れる仕組み。 必要な3つだけに絞りたいなら自前の GitHub App を作ります。ただし Code Review と Web の自動修正は公式 App が必須です
5. 費用は二重。 GitHub Actions の分数と Claude の API トークン。--max-turns・ワークフローのタイムアウト・concurrency で上限を切り、実測で見直します

公式ドキュメントは冒頭で「Claude Code の名前を共有する製品が複数ある」と断っています。発注や社内説明で混ざりやすいので、最初に表で分けます。

Code Review は Team・Enterprise 向けの研究プレビューで、Zero Data Retention を有効にした組織や HIPAA 構成の組織では使えません。レビューは平均 20 分で完了し、1回あたり平均 $15〜25 の費用が PR の大きさに応じて変わります。費用はプランに含まれる利用枠とは別に、利用クレジットから請求されます。

※ 出典: Claude Code Docs — Claude Code GitHub Actions（取得 2026-10）、Claude Code Docs — Code Review（取得 2026-10）

判断の軸は1つです。ワークフローの文面・モデル・起動条件を自分たちで持ちたいか。 持ちたいなら GitHub Action、PR レビューだけが目的で保守したくないなら Code Review です。以降は GitHub Action の話に絞ります。

Claude Code GitHub Action は、ワークフローの設定からどちらで動くかを自動で判定します。切り替えのスイッチは prompt 入力の有無です。

どちらのモードでも、起動した相手に2つの検査が入ります。

• 書き込み権限: Issue・PR のイベントでは、起動した利用者にリポジトリへの書き込み権限が必要です。権限の無い特定の人を許すには allowed_non_write_users と自前の github_token を渡します。schedule のように人が起こさないイベントは対象外です
• 人であること: すべてのイベントでボットのアクターを拒否します。ボット同士の無限ループを防ぐ仕組みで、許すなら allowed_bots に列挙します。定期実行は「最後に cron を変更した利用者」に帰属するため、その人がボットなら同じく列挙が必要です

※ 出典: Claude Code Docs — Claude Code GitHub Actions（Interactive and automation modes / Who can trigger runs）（取得 2026-10）

定期実行には GitHub 側の制約も2つ書かれています。スケジュールされたワークフローは既定ブランチからしか動かず、公開リポジトリでは 60 日間リポジトリに活動が無いとスケジュールが無効になります。社内の私有リポジトリなら後者は気にしなくて済みますが、実験用の公開リポジトリで「いつの間にか止まっていた」の原因になります。

リポジトリに置く認証は、次の3系統から選びます。選ぶ軸は「誰が辞めたら止まるか」です。

claude setup-token が発行するのは有効期間1年の OAuth トークンで、モデルへのリクエストだけに使えます。コマンドはトークンをどこにも保存せず、画面に表示したものを自分でコピーして秘密情報に登録します。組織に展開する場合、公式ドキュメントは「複数リポジトリで共有する秘密情報には OAuth トークンではなく API キーを使う」よう明記しています。OAuth トークンは claude setup-token を実行した人のサブスクリプションに紐づくためです。

※ 出典: Claude Code Docs — Authentication（Generate a long-lived token）（取得 2026-10）、Claude Code Docs — Claude Code GitHub Actions（Set up for an organization）（取得 2026-10）

秘密情報を一切置かない構成が OIDC 連携です。ワークフローが GitHub から受け取る OpenID Connect トークンを、Claude Console のサービスアカウント（Workload Identity Federation）か、Amazon Bedrock・Google Cloud・Microsoft Foundry の IAM と交換します。どの方式でもワークフローに id-token: write の権限が要ります。クラウド事業者経由では use_bedrock・use_vertex・use_foundry のいずれかを "true" にし、クラウド側で「このリポジトリのトークンだけを信頼する」条件を付けます。

※ 出典: Claude Code Docs — Use Claude Code GitHub Actions with cloud providers（取得 2026-10）

組織展開のときの置き場は3点です。GitHub App は組織レベルで1回だけ入れる、秘密情報は組織レベルの Actions シークレットに置く、ワークフローは各リポジトリに置くか再利用可能ワークフローとして1か所に定義する。撤去するときは、シークレットを消しても資格情報そのものは無効にならないため、API キーは Console 側でも削除します。

Claude GitHub App は、GitHub Action・Code Review・Web セッションの自動修正が共用する1つの App です。GitHub App の権限は1セットしか持てないため、GitHub Action が使わない権限も含めて受け入れることになります。インストール時に付与する権限は次のとおりです。

※ 出典: Claude Code Docs — Claude Code GitHub Actions（GitHub App permissions）（取得 2026-10）

GitHub は権限の一部だけを受け入れる操作を許しません。「GitHub Action が使う3つだけにしたい」組織は、Contents・Issues・Pull requests の3権限だけを持つ自前の GitHub App を作り、APP_ID と APP_PRIVATE_KEY をシークレットに置く構成を選びます。ただし自前 App がカバーするのは GitHub Action だけで、Code Review と Web の自動修正には公式 App が必要です。

もう1つ覚えておく挙動があります。App が以前に持っていなかった権限を要求すると、GitHub は所有者に承認を求め、承認されるまでは古い権限のまま動きます。「突然レビューが止まった」の原因が、組織オーナー宛の承認待ちだったという形で現れます。

ワークフロー側の権限は App とは別に、YAML の permissions: に書きます。公式の例では contents: write・pull-requests: write・issues: write・id-token: write・actions: read の5つです。id-token: write は既定の GitHub App 認証に必要で、actions: read は PR の CI 結果を Claude が読むためのものです。レビューだけさせるなら contents: read に落とせます。

公式ドキュメントは、1回の実行が2種類の資源を消費すると書いています。GitHub Actions の分数と、Claude の API トークンです。OAuth トークンで認証した場合、後者は API の請求ではなくサブスクリプションの利用枠から消費されます。

GitHub 側の分数は、私有リポジトリに対してプランごとの無料枠があり、超過分が課金されます。公開リポジトリで標準の GitHub ホストランナーを使う場合は無料です。

※ 出典: GitHub Docs — About billing for GitHub Actions（取得 2026-10）

超過分は Linux 2コア（x64）のランナーで 1 分あたり $0.006 で、分数はワークフローを起動した人ではなくリポジトリの所有者に課金されます。

Claude 側のトークンは、プロンプトと応答の長さ・作業の複雑さ・コードベースの大きさで変わります。モデルを claude_args の --model で選ぶとき、2026年10月時点の API 価格は次のとおりです。

※ 出典: Claude Platform Docs — Pricing（取得 2026-10）

公式ドキュメントが挙げる、両方の費用を下げる手は6つです。

1. @claude への依頼を具体的に書き、ターン数を減らす
2. Issue テンプレートで文脈を先に渡す
3. CLAUDE.md を短く保つ（毎回の実行で読まれる）
4. claude_args に --max-turns を入れて反復回数を制限する
5. ワークフローのタイムアウトで暴走を止める
6. GitHub の concurrency で並列実行を制限する

※ 出典: Claude Code Docs — Claude Code GitHub Actions（Manage costs）（取得 2026-10）

組織全体の利用状況は Analytics ダッシュボードと monitoring のページで追えます。ここで決めておきたいのは「月いくらまで」ではなく、「1回の実行に何ターン・何分まで許すか」です。前者は後から実測で決められますが、後者を決めずに動かすと、1本の暴走した PR で月の枠を使い切ります。

公式の例を基に、社内で最初に入れる2本のワークフローを示します。どちらも timeout-minutes と concurrency を足し、トークンは --max-turns で上限を切っています。

# .github/workflows/claude.yml — @claude のメンションに応答する
name: Claude Code
on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]
jobs:
  claude:
    # コメントに @claude が無ければランナーを起動しない
    if: contains(github.event.comment.body, '@claude')
    runs-on: ubuntu-latest
    timeout-minutes: 30            # 1回の上限時間（暴走の保険）
    concurrency:
      group: claude-${{ github.event.issue.number }}
      cancel-in-progress: false    # 同じ Issue/PR では直列に動かす
    permissions:
      contents: write
      pull-requests: write
      issues: write
      id-token: write              # 既定の GitHub App 認証に必要
      actions: read                # PR の CI 結果を読む
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          claude_args: "--max-turns 15 --model claude-sonnet-5-5"

# .github/workflows/daily-report.yml — 前日のコミットと Issue を要約する
name: Daily Report
on:
  schedule:
    - cron: "0 23 * * 0-4"       # UTC 23:00 ＝ 日本時間 平日 8:00
jobs:
  report:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    permissions:
      contents: read
      issues: read
      id-token: write
    steps:
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: "前日のコミットと未解決の Issue を日本語で要約してください。変更の無い項目は省略します"
          claude_args: |
            --max-turns 10
            --model claude-sonnet-5-5
            --allowedTools "mcp__github__list_commits,mcp__github__list_issues"

雛形2のポイントは、平文の prompt で動く自動モードの Claude には、--allowedTools に書いた GitHub の読み取りツール以外の道具が無いことです。シェルもファイル書き込みも許していないので、要約以外のことは起きません。GitHub API 経由でコミットと Issue を読むため、checkout の手順も省けます。

※ 出典: Claude Code Docs — Claude Code GitHub Actions（Run on a schedule）（取得 2026-10）

社内でこの構成を自分たちで組むときの決め方と止め方は、企業向けの実務書にもまとめています。

PR のレビューをワークフローで持ちたい場合は、prompt に /code-review:code-review --comment のスキル呼び出しを渡し、plugin_marketplaces と plugins で code-review プラグインを入れる公式の例があります。--comment を付けないとレビュー結果はログにしか出ません。公開リポジトリではフォークからの PR に秘密情報が渡らないため、同じリポジトリのブランチからの PR だけが対象です。

最初のワークフローを既定ブランチにマージする前に、次の12項目を確認します。担当者と承認者が別々に付けるのが目安です。

1. Claude が push したのに CI が走らない。 既定の GITHUB_TOKEN で作られたコミットには GitHub がワークフローを起動しません。github_token: ${{ secrets.GITHUB_TOKEN }} を渡しているなら外して GitHub App として認証させるか、自前 App のトークンを渡します
2. 公開リポジトリで、知らない人の @claude が走った。 クラウド事業者経由の構成では、資格情報の手順が書き込み権限の検査より先に動くため、拒否されるまでに App トークンの発行とクラウドへのサインインが済み、Actions の分数が消費されます。資格情報の前に権限を検証する手順を足します
3. @beta のままで動きが変わった。 anthropics/claude-code-action@beta を @v1 に上げるときは、mode 入力を消し、direct_prompt を prompt に、max_turns や model を claude_args に移します。custom_instructions は --append-system-prompt になります
4. 担当者が退職したらレビューが止まった。 OAuth トークンは発行した人のサブスクリプションに紐づきます。共有リポジトリは API キーか OIDC 連携に切り替えます
5. シークレットを消したから安全だと思っていた。 シークレットの削除は資格情報を無効にしません。API キーは Claude Console 側でも削除します

※ 出典: Claude Code Docs — Claude Code GitHub Actions（Troubleshooting / Uninstall / Upgrade from beta）（取得 2026-10）、Claude Code Docs — Use Claude Code GitHub Actions with cloud providers（取得 2026-10）

この記事で参照した一次資料です。入力名や既定値は更新されるため、実装前に該当ページで最新の記述を確認してください。

• Claude Code GitHub Actions（設定・2つのモード・権限・費用・パラメータ一覧）
• Use Claude Code GitHub Actions with cloud providers（Bedrock・Google Cloud・Foundry の OIDC 連携）
• Code Review（管理型レビューの対象プラン・費用・起動条件）
• Authentication（claude setup-token・認証の優先順位）
• Pricing（モデル別の API 価格）
• About billing for GitHub Actions（プラン別の無料分数と超過料金）

ワークフローの文面・モデル・起動条件を自分たちで持ちたいなら GitHub Actions 方式、PR のレビューだけが目的でワークフローを保守したくないなら Code Review です。Code Review は Team・Enterprise 向けの研究プレビューで、費用はプランの利用枠とは別に請求されます。両方を同時に入れることもでき、その場合は公式 App が共用されます。

公式ドキュメントは、複数リポジトリで共有する秘密情報には OAuth トークンではなく Claude Console の API キーを勧めています。OAuth トークンは claude setup-token を実行した人のサブスクリプションに紐づくためです。退職や異動で止まる認証を会社の仕組みに組み込まないのが基本です。

いいえ。Issue と Pull Request のイベントでは、書き込み権限のある利用者だけが起動でき、ボットが書いたコメントは allowed_bots に載せない限り拒否されます。公開リポジトリでは、フォークからの Pull Request に秘密情報が渡らないため、同じリポジトリのブランチからの PR だけが対象になります。

GitHub Actions の分数と Claude の API トークンの2種類が同時に消費され、トークン量はプロンプトの長さ・作業の複雑さ・コードベースの大きさで変わるため事前の確定はできません。--max-turns とワークフローのタイムアウト、concurrency の3つで上限を切り、Console や Analytics の実測で見直す運用になります。

あります。ワークフローの GitHub OIDC トークンを Claude Console のサービスアカウントと交換する Workload Identity Federation か、Amazon Bedrock・Google Cloud・Microsoft Foundry の OIDC 連携を使うと、静的な API キーをリポジトリに保存せずに動かせます。いずれも id-token: write の権限が必要です。

まず、上のチェックリストの 1〜3 を社内で決めてください。製品の選択・モードの選択・認証の選択が決まれば、雛形はそのまま使えます。最初の1本は雛形2のような読み取り専用の定期レポートから始め、コミットを押す対話モードは2本目に回すと、権限の設計を落ち着いて確認できます。

認証や権限の設計で社内に判断できる人がいない、Bedrock や Google Cloud 経由で動かしたい、既存の CI と Claude の役割分担を整理したい、といった場合はお問い合わせからリポジトリの状況（公開か私有か・組織の GitHub プラン・認証の方針）をお知らせください。契約を前提にせず、書面で構成案と確認項目を返します。Claude 導入全体の論点は Claude 導入支援のページに、提供しているサービスの一覧はサービス一覧にまとめています。

• 2026-10-08: 初版公開

• Claude Code の法人導入ガイド【2026年9月】— 管理者が先に決める設定配布・権限・利用上限・監査
• Claude Code を決まった時刻に動かす【2026年9月】— ヘッドレスモードの定期実行と、無人で許す操作の決め方
• Claude Code で作った自動化が止まっていないか確かめる【2026年10月】— 実行ログ・失敗の通知・やり直しの最小セット
• Claude Marketplace で何が手に入るか【2026年10月】— 3区分の中身と、法人が入れる前に決める5つのこと
• ハーネスエンジニアリング実践ガイド — Claude Code を「育てる」ための 5 つの型
• Claude 導入支援