Claude Code GitHub Actionsの導入と料金｜@claude連携の設定・分単価とトークン課金

Claude Code GitHub Actionsは、IssueやプルリクエストのコメントにClaudeを呼び出して、レビュー・修正・PR作成をワークフローの中で実行させる仕組みです。導入でつまずくのはコマンドではなく、認証の選び方と費用の見積り方です。費用はGitHub Actionsの実行時間とClaudeの利用料に分かれますが、Actionsの無料枠やClaudeの認証方式によって追加課金の有無が変わります。公式ドキュメントとリポジトリのaction.ymlから、2026年9月時点の仕様と単価を整理します。

まとめ：導入経路と費用の要点

実体はAnthropic公式のanthropics/claude-code-action@v1というcomposite actionと、リポジトリに入れるClaude GitHub Appの組み合わせです。旧版の解説にある「本体リポジトリをForkしてCloneする」準備は不要で、Appのインストール、Claudeへの認証設定、ワークフローファイルの配置で利用できます。

• セットアップは2経路：Claude Codeのターミナルで/install-github-appを実行する方法と、App導入・シークレット追加・ワークフロー配置を手で行う方法。どちらもリポジトリの管理者権限が必要です。
• モードは自動判定：prompt入力が無ければ@claudeメンション待ち（インタラクティブ）、あれば無条件で実行（オートメーション）。v1でmode入力は廃止されました。
• 費用は二重：GitHub Actionsの実行分（Linux 2コアx64は1分$0.006、ジョブ単位で分に切り上げ、パブリックリポジトリは無料）と、Claudeのトークン課金（Sonnet 5は入力$2／出力$10 per MTok）。サブスクリプションのOAuthトークンで認証すればトークン側はプランの利用枠から消費されます。
• 認証は3択：APIキー、サブスクリプションのOAuthトークン、そしてOIDCのワークロードID連携。組織で共有するならAPIキーかOIDCで、OAuthトークンは発行者個人のサブスクリプションに紐づくため共有に向きません。

以下、実行モデル、セットアップ、料金の計算、コストを抑える設計、鍵を置かない認証、権限とセキュリティ、v1移行の落とし穴の順に見ていきます。

Claude Code GitHub Actionsの実行モデル

GitHub Appとcomposite actionの役割分担

Claude GitHub Appは、ClaudeがリポジトリのファイルやIssue、プルリクエストを読み書きするための入口です。公式ドキュメントはこのうちContents（読み書き）・Issues（読み書き）・Pull requests（読み書き）の3つをアクションが依拠する権限として挙げています。一方のanthropics/claude-code-action@v1はcomposite actionです。@v1は更新され続ける移動タグで、v1系の最新リリースは2026年9月19日公開のv1.0.231です。action.ymlを見ると最初のステップでoven-sh/setup-bunによりBun 1.3.14を導入し、その上でClaude Codeを起動します。Bunの取得を避けたい閉じた環境ではpath_to_bun_executableで実行ファイルを指定できます。

promptの有無による実行モードの切り替え

v1のアクションは、ワークフローの書き方から動作モードを自分で判断します。prompt入力を書かなければトリガーフレーズ（既定は@claude）を待ち、Issueやプルリクエストのコメント、レビュー、新規Issueの本文・タイトルに反応して、進捗と結果をそのIssueやPRのコメントとして書き込みます。promptを書くとメンションを待たずに実行し、結果は既定でワークフローの実行ログに出ます。PRへコメントさせたい場合は、プロンプトでそう指示し、投稿できるツールを許可する必要があります。

起動者の書き込み権限とbot許可条件

どちらのモードでも、アクションはClaudeを動かす前に起動者を2段でチェックし、いずれかで弾かれると実行は失敗します。IssueとPRのイベントでは起動者にリポジトリの書き込み権限が必要で、書き込み権限のない特定ユーザーを許可するにはallowed_non_write_usersの指定と自前のgithub_tokenの受け渡しが要ります。もう1段はbot判定で、allowed_botsに列挙しないbotは拒否されます。これはClaudeがbotのコメントに反応して無限に回ることを防ぐためのもので、スケジュール実行にも適用されます。cronのスケジュール実行は通常、cronを最後に変更したユーザーに帰属しますが、デフォルトブランチの変更でも起動者が変わるため、実際のactorを確認し、それがbotならallowed_botsに加えないと動きません。

セットアップの2経路と必要な権限

クイックセットアップの前提と制約

/install-github-appはgithub.comのリポジトリでのみ動作します。gitのリモートがgitlab.comやbitbucket.orgの場合は通知を出して終了するため、GitLabのパイプラインで使うなら別系統の手順になります。事前にGitHub CLIを入れてgh auth loginで認証しておく必要があり、未導入ならClaude Codeが警告します。コマンドはAppのインストール、認証シークレットの登録（APIキーならANTHROPIC_API_KEY、サブスクリプションのトークンならCLAUDE_CODE_OAUTH_TOKEN）、ワークフローファイルを載せたブランチのpushとプルリクエストの下書きまでを一気に進めます。すでにclaude.ymlがあるリポジトリで再実行すると、ワークフローファイルを最新版へ更新する選択肢が出ます。

手動セットアップとワークフローのpermissions

Claude Codeをローカルで動かしていない場合や、ワークフローファイルを自分で管理したい場合は手動です。Claude GitHub Appを入れ、シークレットを追加し、リポジトリのexamples/claude.ymlを.github/workflows/へコピーします。このファイルはサンプルではなくそのまま動く実装で、Claude Code GitHub Actions公式ドキュメントが示す最小構成は次のとおりです。

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 }}

定型部分ではない行が3つあります。id-token: writeはアクションが既定のGitHub App認証を行うために必須です。actions: readはPR上のCI結果をClaudeに読ませるためのもの。ifはコメント本文に@claudeが含まれないときにランナーを起動させないための条件で、後述のコスト管理に直結します。認証をサブスクリプションのトークンに替えるなら、anthropic_api_keyの行をclaude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}に差し替えます。トークンはローカルでclaude setup-tokenを実行して発行し、Pro・Max・Team・Enterpriseの各プランで利用できます。

組織へ展開するときの分岐

クイックでも手動でも設定単位はリポジトリ1本です。組織全体へ広げるなら、Appを組織レベルで一度インストールし、認証シークレットを組織レベルのActionsシークレットに置き、ワークフローは各リポジトリに配置するか、ジョブをReusable Workflowとして1か所に定義して各リポジトリから呼びます。このとき共有するシークレットにはOAuthトークンではなくAPIキーを使うのが公式の指針です。OAuthトークンはclaude setup-tokenを実行した個人のサブスクリプションに紐づくため、退職や解約でワークフローが一斉に止まります。ワークフロー本体の共通化の作法はReusable Workflows（GitHub Actions）とは？workflow_callでの作成・呼び出しとinputs/secrets/outputsの渡し方で整理しています。

料金の内訳と1回あたりの見積り

GitHub Actions側の分課金

本記事の例はGitHubホストランナーを使い、無料枠を超えた実行時間に分課金が発生します。セルフホストランナーも利用でき、その実行時間にGitHub Actionsの分課金はかかりません。GitHubは各ジョブの分数と端数を1分単位に切り上げるので、30秒で終わったジョブも1分として計上されます。標準ランナーの分単価はGitHubのランナー料金リファレンスに掲載されている次の値です。

runs-on: ubuntu-latestで動かす標準構成は1分$0.006です。プライベートリポジトリには無料枠があり、GitHub FreeとFree for organizationsが月2,000分、ProとTeamが3,000分、Enterprise Cloudが50,000分。パブリックリポジトリで標準ランナーを使う分は無料です。ただしlarger runnerは無料枠の対象外で常に課金されます。1回4分のジョブなら4分×$0.006＝$0.024、1日20回でも$0.48で、Teamプランの無料枠3,000分に収まる限り追加請求は発生しません。この例ではActions側は1日$0.48相当ですが、無料枠は同じ所有者の他のワークフローと共用するため、合計使用量で追加請求を判断します。枠の考え方はGitHub Actionsの料金｜2026年改定後の分単価・無料枠とコスト削減の判断基準で詳しく扱っています。

Claude側のトークン課金

費用の主役はこちらです。1回の実行で読むコードの量、対話のターン数、出力の長さで変動します。APIキー認証の場合の単価はClaude APIの料金ページに基づき次のとおりです。

単位は100万トークンです。旧来の解説で見かける「入力1,000トークンあたり$15」のような記述は単位が1,000倍ずれているうえ、その価格帯はOpus 4.1以前の退役モデルのものです。表の3モデルではキャッシュ読み取りが基本入力の0.1倍、書き込みが5分保持で1.25倍・1時間保持で2倍の単価です。書き込み費用は別にかかりますが、CLAUDE.mdや長いシステムプロンプトを毎回読み直す構成でも、プロンプトキャッシュが効けば入力側の負担は1桁下がります。Sonnet 5の$2／$10は導入時に2026年8月31日までの暫定価格として案内されていたものが標準価格になり、9月1日に予定されていた$3／$15への引き上げは行われないとドキュメントに明記されています。

Claude Code全体の実測費用とCI見積りへの適用範囲

1回あたりのトークン量は事前に読めないため、見積りは公表されている実測値から始めるのが確実です。Anthropicはエンタープライズ導入の平均を1開発者あたり稼働日$13程度、月$150〜250とし、90%の利用者が稼働日$30未満に収まるとしています。これはGitHub Actions経由に限らないClaude Code全体の数字で、CI用途の上限や平均を示すものではありません。CIの見積りは実行回数と1回あたりの実測費用から算出します。実務では小さなパイロットで自分たちのベースラインを測り、そこから広げるのが公式の推奨です。GitHub Actionsの分課金がここに上乗せされますが、前項の計算どおり比率としては小さく、この試算ではトークン費用を優先して確認するという判断になります。

コストを抑えるワークフロー設計

効くのは「起動させない」と「1回の上限を決める」の2つです。まず最小構成のif条件を外さないこと。これが無いと@claudeを含まないすべてのコメントでランナーが立ち上がります。次に、1回の作業量に上限を置きます。

jobs:
  claude:
    if: contains(github.event.comment.body, '@claude')
    runs-on: ubuntu-latest
    timeout-minutes: 15
    concurrency:
      group: ${{ github.workflow }}-claude-${{ github.event.issue.number || github.event.pull_request.number || github.run_id }}
      cancel-in-progress: true
    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 }}
          claude_args: |
            --model claude-sonnet-5
            --max-turns 5

claude_argsはClaude CodeのCLI引数をそのまま受け取ります。--max-turnsで対話のターン数を、--modelでモデルを固定できます。APIキー認証では、モデル未指定時にSonnet 5より単価の高いOpus 5が選ばれる場合があります。Claude Codeの既定モデルはアカウント種別で決まり、Anthropic APIキーで認証する場合はOpus 5（入力$5／出力$25）です。Sonnet 5の$2／$10に対して単価は2.5倍です。ただし、同じ作業でもモデルによって消費トークン数やターン数が異なるため、請求額が必ず2.5倍になるわけではありません。ProとTeam StandardはSonnet 5、Microsoft FoundryはSonnet 4.5が既定です。CIのレビューや軽い修正は、まずSonnet 5で必要な品質を満たすか確認し、--model claude-sonnet-5のようにモデルIDまで固定しておくのが安全です。公式のコスト管理の指針は、@claudeへの依頼を具体的に書いてターン数を減らす、Issueテンプレートで前提を先に渡す、毎回読まれるCLAUDE.mdを短く保つ、--max-turnsで反復を制限する、ワークフローにタイムアウトを設ける、concurrencyで並列実行を抑える、の6点です。

逆にやらないほうがよい設定もはっきりしています。pull_requestのsynchronizeを無条件のトリガーにすると、レビュー中のpushごとにレビューが走り、1本のPRで何度も課金されます。自動レビューを常設するならopenedとready_for_reviewに絞るか、ラベルで明示的に起動させるほうが読みやすく安価です。定期実行に回す場合、スケジュールはデフォルトブランチからのみ動き、パブリックリポジトリでは60日間リポジトリに活動が無いとGitHubがスケジュールを無効化します。

APIキーを保存しないOIDC認証の設定

ワークロードID連携（OIDC）

長期有効なシークレットをリポジトリに置きたくない場合は、ワークフローのGitHub OIDCトークンをClaude Consoleのサービスアカウント経由でAPIアクセスと交換できます。指定する入力はanthropic_federation_rule_id（fdrl_で始まる連携ルールID）とanthropic_organization_idが中心で、anthropic_service_account_id（svac_）とanthropic_workspace_id（wrkspc_）は連携ルールが対象を特定できていれば省略できます。

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_federation_rule_id: ${{ vars.ANTHROPIC_FEDERATION_RULE_ID }}
          anthropic_organization_id: ${{ vars.ANTHROPIC_ORGANIZATION_ID }}

このときid-token: writeは必須です。自前のgithub_tokenを渡す構成でも交換処理に使うため省けません。GitHub Actions側でOIDCを使ったクラウド認証を組んだ経験があれば発想は同じで、GitHub ActionsとTerraformでAWSのCI/CDを構築する手順（OIDC・S3ネイティブロック対応）で扱っている信頼関係の設計がそのまま参考になります。

Bedrock・Agent Platform・Foundryのモデルエイリアス解決先

推論を自社のクラウド契約に通す場合はuse_bedrock、use_vertex、use_foundryのいずれかをtrueにします。3つともOIDCのID連携で認証するため、静的なクラウド資格情報をリポジトリに置く必要はありません。見落としやすいのは同じ--model sonnetを書いてもプロバイダによって実際のモデルが違う点で、単価と挙動の両方に影響します。

Sonnet 4.5と4.6は入力$3／出力$15で、Sonnet 5の$2／$10より高いため、Bedrock経由でエイリアス任せにすると意図せず1.5倍の単価を払うことになります。プロバイダを跨いで運用するなら、エイリアスではなくモデルIDを明示的に固定するほうが安全です。

権限とセキュリティで詰まる点

GitHub Appの一括承諾権限とカスタムAppによる限定

Claude GitHub AppはCode Reviewやウェブ版の自動修正など、GitHubと連携するClaude機能すべてで共有されます。GitHub Appの権限セットは機能ごとに分けられないため、インストール時に承諾するのはアクションが使わないものを含む11項目（Actions・Checks・Contents・Discussions・Issues・Members・Metadata・Pull requests・Repository hooks・Statuses・Workflows）です。GitHubの仕様上、この一部だけを承諾することはできません。組織のルールでアクションが実際に使う権限だけに絞りたい場合は、Contents・Issues・Pull requestsだけを持つカスタムGitHub Appを作る方法があります。ただしカスタムAppが賄えるのはこのアクションだけで、Code Reviewとウェブ版の自動修正は公式Appのままです。

fork PRとトークンの扱い

パブリックリポジトリでfork由来のPRを通常のpull_requestイベントで処理する場合、GitHubはGITHUB_TOKEN以外のシークレットをランナーへ渡しません。つまり通常のpull_requestイベントでシークレット認証する構成では、fork由来のPRをそのまま自動レビューできないので、同一リポジトリのブランチからのPRに限定した運用を前提に設計します。もう1つの定番のつまずきは、Claudeのコミットで後続のCIが動かないというものです。原因はGitHubが既定のGITHUB_TOKENで作られたコミットではワークフローを起動しない仕様で、github_token: ${{ secrets.GITHUB_TOKEN }}を渡している行を外してClaude GitHub Appとして認証させるか、カスタムAppのトークンを渡せば解決します。

資格情報そのものの扱いも押さえておきます。APIキーとOAuthトークンはリポジトリに直接コミットせず必ずシークレットに置くこと、シークレットを削除しても鍵自体は有効なままである（APIキーを完全に無効化するにはClaude Console側でそのキーを削除する。OAuthトークンの失効は別途行う）ことの2点です。Claude Code本体の認証情報の扱いはClaude Codeソースコード流出事件の全貌｜npm混入で51万行公開の原因・内部構造・対策で扱った教訓とも重なります。

@betaからv1への移行と旧情報の見分け方

2025年前半の記事を参照して組んだワークフローは、anthropics/claude-code-action@betaを指しているものが少なくありません。v1への移行で必要な書き換えは4点です。usesの@betaを@v1にする、モードが自動判定になったのでmode入力を削除する、direct_promptをpromptに置き換える、max_turnsやmodelといったCLI相当のオプションをclaude_argsへ移す。custom_instructionsは同名のフラグが無く、--append-system-promptに相当します（--system-promptは既定のプロンプトを置き換えてしまうため別物です）。公式の移行ガイドが挙げる旧入力の対応は次のとおりで、これらはaction.ymlの入力定義から消えているため、書き残したまま@v1へ上げると指定が無視されます。

古い情報を見分ける目印もはっきりしています。アクション本体のリポジトリをForkしてCloneする手順、モードを手で切り替える説明、Actionsマーケットプレイスを検索して選ぶ前提の記述は、いずれも現行の構成では不要または存在しません。入力パラメータを一覧で確認したいときはClaude Code Action v1の使い方と設定｜GitHubのコードレビューをAIで自動化するを、Claude Code本体のコマンドや権限設定から確認したいときはClaude Codeの使い方｜導入から権限とCLAUDE.md設定まで実務手順を参照してください。

よくある質問

Claude Code GitHub Actionsの料金はいくらですか？

GitHub Actionsの実行分とClaudeのトークンの合算です。前者はubuntu-latestなら1分$0.006で、プライベートリポジトリでもFreeは月2,000分、ProとTeamは3,000分の無料枠があり、パブリックリポジトリの標準ランナーは無料です。後者はモデル次第で、Sonnet 5なら入力$2／出力$10 per MTok。Anthropicが公開しているClaude Code全体の実測は1開発者あたり稼働日$13程度で、90%が稼働日$30未満に収まっています。

GitHubと連携するのに何が必要ですか？

リポジトリの管理者権限、Claude GitHub Appのインストール、認証シークレット（ANTHROPIC_API_KEYまたはCLAUDE_CODE_OAUTH_TOKEN）、そして.github/workflows/に置くワークフローファイルの4つです。/install-github-appを使う場合はGitHub CLIの導入とgh auth loginも前提になります。

ProやMaxのサブスクリプションで動かせますか？

動かせます。ローカルでclaude setup-tokenを実行して長期有効なOAuthトークンを発行し、CLAUDE_CODE_OAUTH_TOKENとしてシークレットに登録してclaude_code_oauth_token入力に渡します。対応プランはPro・Max・Team・Enterpriseです。ただしトークンは発行した個人のサブスクリプションに紐づくため、組織で共有する認証情報としては適しません。

@betaから@v1へタグだけ変更しても動きますか？

v1はベータから破壊的変更を含むため、modeやdirect_promptを使ったままタグだけ@v1に変えると失敗します。移行するときは4点の書き換え（タグ変更、mode削除、direct_promptからprompt、CLI相当オプションのclaude_argsへの移動）をまとめて行ってください。

@claudeにメンションしても反応しないときは何を見ますか？

公式のトラブルシュートは5点を挙げています。Appがそのリポジトリにインストールされているか、リポジトリでワークフローが有効か、APIキーまたはOAuthトークンがシークレットに設定されているか、コメントが/claudeや@claude-botではなく単語として@claudeを含んでいるか、コメントした人に書き込み権限があるか。書き込み権限が無いユーザーを許可する場合はallowed_non_write_usersと自前のgithub_tokenが必要です。

関連記事

• Claude Code Action v1の使い方と設定｜GitHubのコードレビューをAIで自動化する
• GitHub Actionsの料金｜2026年改定後の分単価・無料枠とコスト削減の判断基準
• Claude Codeとは？できること・使い方・料金とコード解析の実力【2026年版】
• Claude Codeの使い方｜導入から権限とCLAUDE.md設定まで実務手順
• GitHub ActionsとTerraformでAWSのCI/CDを構築する手順（OIDC・S3ネイティブロック対応）