anthropics/claude-code-action@v1の設定リファレンス｜入力一覧・claude_args・betaからの移行

anthropics/claude-code-action@v1は、GitHubのイシューやプルリクエストの上でClaude Codeを動かす公式のGitHub Actionです。v1は2025年8月26日に公開され、v1タグは2026年9月25日にv1.0.235へ付け替えられています。この記事では、v1.0.235のaction.ymlに定義された入力39項目を用途別に整理し、claude_argsで渡すCLIフラグ、@betaからの移行表、権限チェックの既定動作までを公式リポジトリの記述とソースコードに沿って説明します。

導入手順（GitHub Appのインストールとシークレット登録）と料金の内訳はClaude Code GitHub Actionsの導入と料金｜@claude連携の設定・分単価とトークン課金で扱っています。本記事はワークフローを書く段階で引くリファレンスです。

まとめ：claude-code-action@v1の要点

• モードはpromptの有無で決まる：promptなしは@claudeに応答する対話モード、ありはメンションを待たずに走る自動化モード。v1でmode入力は廃止されました。
• モデル・ターン数・許可ツールはclaude_argsに書く：model・max_turns・allowed_toolsなどの旧入力はaction.ymlから消えており、残しても効きません。
• Bashは既定で使えない：テストやビルドを走らせるなら--allowedToolsでBash(npm run test:*)のようにコマンド単位で許可します。
• 起動者は2段で検査される：書き込み権限のある人間だけが起動でき、botはallowed_botsに載せない限り拒否されます。
• github_tokenにGITHUB_TOKENを渡すと後続CIが止まる：GITHUB_TOKENで作られたコミットは次のワークフローを起動しません。独自GitHub Appのトークンを渡す構成なら起動します。

claude-code-action@v1の実体と現行版

このアクションはcomposite actionで、最初のステップがoven-sh/setup-bunでBun 1.3.14を入れ、その上でアクション本体（TypeScript）とClaude Codeを実行します。package.jsonは@anthropic-ai/claude-agent-sdkの^0.3.283に依存しています。Bunをすでに持つ環境（NixOSや独自コンテナ）ではpath_to_bun_executableで自前のバイナリを渡すとインストールを飛ばせます。

v1は付け替え式のタグで、2026年9月23日から25日の3日間だけでv1.0.232〜v1.0.235の4回リリースされています。@v1と書けば修正が自動で入る一方、挙動も予告なく変わります。@v1.0.235のようなバージョンタグも技術的には付け替えられるため、改変まで防ぎたい本番リポジトリではコミットの完全なSHAで固定し、更新はDependabotのプルリクエストで受けるのが安全です。

同じリポジトリには下位部品のclaude-code-base-actionもあります。公式のsecurity.mdによると、base-actionは起動者の権限チェックもベースブランチからの設定復元も行いません。イシューやプルリクエストを起点に動かすなら、チェックを備えたclaude-code-actionを使ってください。

promptの有無で決まる2つの実行モード

対話モードは、イシューやプルリクエストのコメント、プルリクエストのレビュー、新しく開いたイシューの本文かタイトルに含まれるトリガー文字列（既定@claude）に反応します。assignee_triggerで指定したユーザーへの割り当てや、label_triggerのラベル付与（イシューのlabeledイベント）でも起動します。v1.0.235のtrigger.tsでは、トリガー文字列の直前が行頭か空白、直後が空白・行末・.,!?;:のいずれかのときに一致と判定します。@claude!や@claude,は起動し、@claude-botやclaude@mentionは起動しません。公式FAQは@claude!を起動しない例に挙げていますが、実装とは食い違っています。

自動化モードは既定ではコメントを残しません。v0のagentモードのように進捗コメントが欲しい場合はtrack_progress: trueを付けます。ただし対応イベントは、pull_requestのopened・synchronize・ready_for_review・reopened・labeledと、issuesのopened・edited・labeled・assignedに限られます。それ以外のイベントで指定するとエラーになります。

@claudeに応答する最小ワークフロー

公式リポジトリのexamples/claude.ymlをもとに、4種類のイベントで@claudeを拾う構成です。

name: Claude Code
on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]
  issues:
    types: [opened, assigned]
  pull_request_review:
    types: [submitted]

jobs:
  claude:
    if: |
      (github.event_name == 'issue_comment' && contains(github.event.comment.body, '@claude')) ||
      (github.event_name == 'pull_request_review_comment' && contains(github.event.comment.body, '@claude')) ||
      (github.event_name == 'pull_request_review' && contains(github.event.review.body, '@claude')) ||
      (github.event_name == 'issues' && (contains(github.event.issue.body, '@claude') || contains(github.event.issue.title, '@claude')))
    runs-on: ubuntu-latest
    timeout-minutes: 30
    concurrency:
      group: claude-${{ github.event.issue.number || github.event.pull_request.number }}
      cancel-in-progress: false
    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 }}
          additional_permissions: |
            actions: read

公式例との違いはtimeout-minutes・concurrency・additional_permissionsを足した点です。jobs.<id>.ifはランナーを起動する前に評価されるので、メンションのないコメントで課金時間を消費しません。id-token: writeは既定のGitHub App認証に必要で、外すとOIDC関連のエラーになります。プルリクエスト上のCI結果をClaudeに読ませるには、ジョブのpermissionsのactions: readと、アクションのadditional_permissionsのactions: readが両方必要です。そろうとmcp__github_ci__download_job_logなどCI用のツールが使えるようになります。

concurrency.groupにgithub.event.issue.numberだけを使うと、pull_request_review_commentとpull_request_reviewではこの値が空になり、別々のプルリクエストの実行が同じグループに入って待たされます。プルリクエスト番号へのフォールバックを必ず書いてください。cancel-in-progressをtrueにすると、Claudeがコミットを積んでいる途中のジョブが後続のメンションで打ち切られます。groupとキャンセルの設計はGitHub Actionsのconcurrency｜groupの設計とcancel-in-progress・queueの選び方で詳しく扱っています。

入力パラメータ一覧（v1.0.235の39項目）

action.ymlの入力はすべて任意です。認証だけは、anthropic_api_key・claude_code_oauth_token・ワークロードID連携・クラウドプロバイダ指定のどれか1系統を必ず与えます。

認証とプロバイダの入力

claude_code_oauth_tokenはPro・Max・Team・Enterpriseプランでclaude setup-tokenを実行して発行します。トークンは発行した個人のサブスクリプションに結び付くため、組織で共有するシークレットにはAPIキーかワークロードID連携を使うよう公式ドキュメントは勧めています。ワークロードID連携の入力と同時にanthropic_api_keyなどの静的な認証情報を渡すと、静的な方が優先されて連携は使われません。APIキーを置かない構成の手順はClaude Code GitHub Actionsの導入と料金にまとめています。

起動条件とアクセス制御の入力

include_comments_by_actorとexclude_comments_by_actorは*[bot]のようなワイルドカードを受け付け、両方に該当した場合は除外が優先されます。公開リポジトリでは、信頼できる投稿者のコメントだけをClaudeに読ませる用途に使えます。

ブランチとコミットの入力

branch_name_templateでは{{prefix}}・{{entityType}}・{{entityNumber}}・{{timestamp}}・{{sha}}・{{label}}・{{description}}の7変数が使えます。独自のGitHub Appで動かす場合はbot_idとbot_nameを両方そのAppの値に変えます。片方だけだとコミットの作成者表示が食い違います。

コメントとログ出力の入力

classify_inline_commentsは、確定フラグの付いていないインラインコメントをセッション終了まで保留し、本物の指摘か試し書きかを判定してから投稿します。この判定はanthropic_api_keyが前提で、ワークロードID連携では判定が省かれて全件そのまま投稿されます。show_full_outputはツールの実行結果まで出力し、公開リポジトリならそのログを誰でも読めます。シークレットACTIONS_STEP_DEBUGをtrueにしたデバッグモードでは自動で有効になる点にも注意が必要です。

実行環境と拡張の入力

promptにはリポジトリの.claude/skills/にあるスキルを/skill-nameの形で渡せます。プラグイン内のスキルならpluginsでcode-review@claude-code-pluginsのように「プラグイン名@マーケットプレイス名」を指定し、/code-review:code-reviewのように名前空間付きで呼びます。プラグインを自作して社内で配る手順はClaude Codeプラグインの作り方と社内配布を参照してください。

後続ステップで使える出力

claude_argsで渡すモデル・ツール・プロンプト指定

claude_argsはClaude CodeのCLI引数をそのまま受け取ります。複数行のブロックで書くと読みやすくなります。

- uses: anthropics/claude-code-action@v1
  with:
    anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
    claude_args: |
      --model claude-sonnet-5
      --max-turns 10
      --allowedTools "Bash(npm run test:*),Bash(npm run lint:*)"
      --append-system-prompt "テストが無い変更には必ずテストを追加すること"

--modelの指定と省略時の既定モデル

--modelを省くと、Claude Codeの既定モデルが使われます。Claude Codeのモデル設定ドキュメントでは、Anthropic API・Pro・Max・Team・Enterprise、およびBedrockとAgent Platformの既定がOpus 5.5、Microsoft FoundryだけがSonnet 4.5です。Claude APIの料金表によると、100万トークンあたりの単価はOpus 5.5が入力$4・出力$20、Sonnet 5が入力$2・出力$10で、入出力ともちょうど2倍の差があります。レビューや定型の要約のように判断の難度が低いジョブは--model claude-sonnet-5を明示すると、既定のままより安く済みます。

公式のmigration-guide.mdやconfiguration.mdの例にはclaude-4-0-sonnet-20250805のような古い形式のモデルIDが残っています。そのまま写さず、claude-sonnet-5やclaude-opus-5-5のような現行のIDに置き換えてください。

--allowedToolsで開けるBashとMCPツール

既定でClaudeが使えるのは、ファイルの読み書き・コミット・読み取り専用のgitコマンド、コメントの作成と更新、基本的なGitHub操作です。任意のBashは実行できません。npm testを走らせたいならBash(npm run test:*)のようにコマンドの接頭辞で許可します。Bashを丸ごと許可すると、プロンプトインジェクションで任意コマンドを実行される経路が開きます。

アクションはGitHub MCPサーバーとファイル操作用のサーバーを自動で起動しますが、そのツールも--allowedToolsに名前を書くまで使えません。コードレビューの行コメントを投稿させるならmcp__github_inline_comment__create_inline_commentを明示します。リポジトリ直下の.mcp.jsonに定義したサーバーも同じ扱いです。

--append-system-promptと--system-promptの違い

--append-system-promptはClaude Code組み込みのシステムプロンプトの後ろに指示を足し、--system-promptは組み込みのプロンプトを丸ごと置き換えます。v0のcustom_instructionsに相当するのは前者です。置き換えるとブランチの扱いやコメント更新の手順まで消えるため、アクション上では--append-system-promptを使い、恒常的なルールはリポジトリのCLAUDE.mdに書くのが扱いやすい分担です。

settings入力で渡す環境変数・権限・フック

CLI引数にない設定はsettingsにJSONで渡します。v0のclaude_envはenvオブジェクトに移りました。

- uses: anthropics/claude-code-action@v1
  with:
    anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
    settings: |
      {
        "env": { "NODE_ENV": "test", "CI": "true" },
        "permissions": { "deny": ["WebFetch"] }
      }

settingsにはhooksも書けます。フックの書式とイベントの一覧はClaude Code Hooksの設定方法｜全33イベント一覧とsettings.jsonの書き方を参照してください。

@betaからv1への移行：廃止された入力の置き換え表

@betaから@v1へタグだけ替えると、廃止された入力はaction.ymlに定義がないため効かなくなります。GitHubは未定義の入力に警告を出しますが、ジョブは失敗しません。モデル指定やターン数の上限が黙って外れた状態で動き続けるので、次の表に沿って書き換えてください。

自動化モードでプルリクエストを扱うとき、v0のoverride_promptで使えた$PR_NUMBERのような置換変数はありません。移行ガイドはpromptの先頭にREPO: ${{ github.repository }}とPR NUMBER: ${{ github.event.pull_request.number }}を書く形を推奨しています。これが無いと、Claudeはどのプルリクエストを見ればよいか分かりません。

structured_outputによる後続ステップの条件分岐

claude_argsに--json-schemaでスキーマを渡すと、結果が検証済みのJSONとしてstructured_outputに入ります。composite actionは動的な出力を定義できない制約があるため、全フィールドが1つのJSON文字列にまとまり、fromJSON()で取り出します。次の例は、CIワークフローが失敗したときにClaudeが失敗ログを読んで不安定なテスト（flaky test）かどうかを判定し、確度が高ければ失敗したジョブだけを再実行します。公式のexamples/test-failure-analysis.ymlをもとに、ログ取得を前段のステップへ移し、再実行をgh run rerunに替えています。

name: Flaky test check
on:
  workflow_run:
    workflows: ["CI"]
    types: [completed]

jobs:
  detect-flaky:
    if: github.event.workflow_run.conclusion == 'failure' && github.event.workflow_run.run_attempt == 1
    runs-on: ubuntu-latest
    permissions:
      contents: read
      actions: write
      id-token: write
    env:
      GH_TOKEN: ${{ github.token }}
      GH_REPO: ${{ github.repository }}
      RUN_ID: ${{ github.event.workflow_run.id }}
    steps:
      - uses: actions/checkout@v6
      - name: Save failed logs
        run: gh run view "$RUN_ID" --log-failed | tail -n 400 > failed.log
      - name: Detect flaky tests
        id: analyze
        uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            REPO: ${{ github.repository }}
            RUN ID: ${{ github.event.workflow_run.id }}
            Read failed.log and determine if this failure is a flaky test.
            Return: is_flaky (boolean), confidence (0-1), summary (string)
          claude_args: |
            --json-schema '{"type":"object","properties":{"is_flaky":{"type":"boolean"},"confidence":{"type":"number","minimum":0,"maximum":1},"summary":{"type":"string"}},"required":["is_flaky","confidence","summary"]}'
      - name: Rerun failed jobs
        if: |
          steps.analyze.outputs.structured_output != '' &&
          fromJSON(steps.analyze.outputs.structured_output).is_flaky &&
          fromJSON(steps.analyze.outputs.structured_output).confidence >= 0.8
        run: gh run rerun "$RUN_ID" --failed

ログは前段のステップでファイルに落としているので、Claudeには既定のファイル読み取りだけを使わせ、Bashを許可せずに済みます。run_attempt == 1の条件は、再実行した回がまた失敗したときに判定と再実行が繰り返されるのを止めるためのものです。しきい値の0.8は設定例で、誤判定を防ぐ保証になる値ではありません。workflow_runでは上流の実行を始めた人の書き込み権限も検査されるため、書き込み権限のない外部貢献者のフォークPRが起点の失敗では、アクションはClaudeを起動せずに止まります。

起動者チェックと緩める入力のリスク

アクションはClaudeを起動する前に、トリガーした相手を2段で検査します。イシュー・プルリクエスト・コメント・レビューのイベントでは起動者に書き込み権限が必要で、workflow_runでは上流の実行を始めた人の権限も確かめます。加えて、すべてのイベントでbotを拒否します。scheduleの実行はcronを最後に変更したユーザーに帰属するため、その人がbotならallowed_botsに載せないと定期実行が落ちます。

allowed_botsとallowed_non_write_usersを使う判断

allowed_botsに載せたbotは、リポジトリへのインストールも書き込み権限も確認されません。公開リポジトリで'*'を指定すると、誰かが作ったGitHub Appがイシューを開くだけで、そのAppが用意したプロンプトでClaudeが動きます。Dependabotのように名前が決まっている相手だけを列挙し、'*'は使わないでください。

allowed_non_write_usersは書き込み権限の検査そのものを外す入力で、github_tokenを渡した場合だけ機能します。使ってよいのは、ラベル付けのようにissues: writeしか持たないジョブに限られます。その場合も渡すトークンは${{ secrets.GITHUB_TOKEN }}にし、個人アクセストークンは使いません。ジョブ終了で失効しない静的なトークンは、プロンプトインジェクションで少しずつ抜き出されるおそれがあると公式が注意しています。ワークフローの権限を絞る考え方はGitHub Actionsのpermissions｜GITHUB_TOKENの既定権限と最小権限の設計で扱っています。

pull_request_targetとworkflow_runでのチェックアウト

pull_request_targetとworkflow_runはベースリポジトリのシークレットで動きます。フォークのプルリクエストの先頭コミットをワークスペース直下にチェックアウトしてからアクションを呼ぶと、Claudeは外部の人が書いたファイル群の上で、自社のAPIキーを持って動くことになります。ベースブランチを直下に置き、プルリクエスト側はpath: pr-headのように別ディレクトリへ取り出してclaude_args: "--add-dir pr-head"で渡すのが公式の推奨です。

プルリクエストに対して動くとき、アクションは.claude/・.mcp.json・.claude.json・.gitmodules・.ripgreprc・CLAUDE.md・CLAUDE.local.md・.husky/の8つをベースブランチの内容に戻します。package.jsonやロックファイル、Makefileはプルリクエスト側のままです。ベースのsettings.jsonに書いたフックがnpm runやmakeを呼んでいると、その中身はプルリクエストの作者が決められます。フックからはbunx [email protected] --no-config --write .のように版と設定を固定して直接ツールを呼んでください。シークレットの置き場所と漏えい経路の整理はGitHub ActionsのSecrets管理にあります。

Claudeがやらない操作と詰まりやすい挙動

Claudeはコミットを積んでプッシュするだけで、マージ・リベース・強制プッシュはしません。この制限はシステムプロンプトで課されているため、Bash(git rebase:*)を許可しても断ります。プルリクエストも既定では作らず、ブランチにプッシュしたうえで作成画面へのリンクを返します。ワークフローファイル（.github/workflows/）の書き換えもできません。

コミット履歴について補足すると、アクションはプルリクエストでは直近20コミット、新しいブランチでは1コミットだけを取得します。クローズ済みやマージ済みのプルリクエストでメンションすると、既存のブランチには積めないので新しいブランチが作られます。

github_tokenに${{ secrets.GITHUB_TOKEN }}を渡す構成は避けるべきです。GitHubはGITHUB_TOKENで作られたコミットを契機にワークフローを起動しないため、Claudeが直したブランチでテストが一度も走らないままマージ判断を迫られます。コメントの投稿者もclaude[bot]ではなくなり、use_sticky_commentも正しく更新されません。github_tokenを使うのは、actions/create-github-app-tokenで発行した独自GitHub Appのトークンを渡す場合（この場合は後続CIも起動します）と、allowed_non_write_usersのためにGITHUB_TOKENを渡す場合の2つに限り、それ以外は空のままにしてください。

よくある質問

anthropics/claude-code-action@v1とは何ですか？

Anthropicが公開しているGitHub Actionで、イシューやプルリクエストのコメント、またはpromptで渡した指示を受けてClaude Codeをランナー上で動かします。v1は2025年8月26日に公開された正式版で、それ以前の@betaとは入力の構成が異なります。

claude-code-actionで使うモデルはどう指定しますか？

claude_argsに--model claude-sonnet-5のように書きます。v0のmodel入力は廃止されています。省略するとClaude Codeの既定モデルになり、Anthropic APIではOpus 5.5、Microsoft FoundryではSonnet 4.5です。

ANTHROPIC_API_KEYなしで動かせますか？

動かせます。claude_code_oauth_tokenでPro・Max・Team・Enterpriseのサブスクリプションを使う方法、anthropic_federation_rule_idとanthropic_organization_idでOIDCのワークロードID連携を使う方法、use_bedrock・use_vertex・use_foundryでクラウド経由にする方法があります。

料金はどこでかかりますか？

GitHub Actionsのランナー時間と、Claude側のトークン利用の2か所です。サブスクリプションのOAuthトークンで認証した場合、トークン分はAPI課金ではなくサブスクリプションの利用枠から消費されます。金額の見積もりは導入と料金の記事とGitHub Actionsの料金で扱っています。

@claudeにメンションしても反応しないのはなぜですか？

多いのは、コメントした人にリポジトリの書き込み権限がない、@claudeが単語として独立していない、ジョブのif条件がそのイベントを拾っていない、の3つです。GitHub App未インストールやシークレット未設定でも同じ症状になります。

関連記事

• Claude Code GitHub Actionsの導入と料金｜@claude連携の設定・分単価とトークン課金
• GitHub Actionsの料金｜2026年改定後の分単価・無料枠とコスト削減の判断基準
• GitHub Actionsのpermissions｜GITHUB_TOKENの既定権限と最小権限の設計
• pr-review-toolkitとは｜Claude Codeプラグインの導入とreview-prの使い方
• Claude Codeとは？できること・使い方・料金とコード解析の実力【2026年版】