Claude Code Action は、GitHub の Issue や Pull Request で @claude とメンションすると（いわゆる @claude メンションで） Claude がレビュー・修正・コミットまで行う Anthropic 公式の GitHub Action です。star は 8,729、fork 2,093。本記事では action.yml を実際に取得して 39個の入力と6個の出力を数え、多くの記事が案内する @v1 タグの実体をコミットSHAで確認し、write権限チェックを迂回する2つの入力が何を意味するのかを公式ドキュメントと突き合わせて整理します。
30秒でわかる Claude Code Action
・Anthropic公式・MIT・★8,729。実体は Bun で動くコンポジットアクション（11ステップ・入力39・出力6）
・@v1 は可動タグ。実測で v1 と v1.0.207 は同一コミット 70fec183。直近30日で24リリースなので中身は毎日変わる
・既定の防御は「write権限を持つユーザーだけが起動できる」。これを外す入力が2つあり、公式が RISKY と明記
・allowed_non_write_users 使用時はシークレットのスクラブ＋Linuxでは bubblewrap による PID名前空間分離が入るが、「リスクを減らすが排除しない」と公式が明言
・認証は APIキー / OAuthトークン / Bedrock / Vertex / Foundry / OIDCフェデレーションに対応
GitHub Actions Claude 連携の入口として最も使われているのがこのアクションです。Claude Code そのものの導入・設定はClaude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引きにまとめてあります。本記事はそれをCIに載せる話です。
Claude Code Actionとは——GitHubイベントからClaude Codeを起動する公式Action
Claude Code Action は、GitHub 上の出来事をきっかけに Claude Code を走らせるためのアクションです。action.yml の description にはこうあります。
Flexible GitHub automation platform with Claude. Auto-detects mode based on event type: PR reviews, @claude mentions, or custom automation.
イベント種別からモードを自動判定するのが v1.0 系の設計です。PRに対して起動すればレビュー、Issueコメントで @claude と書けばそのIssueへの対応、といった具合に振る舞いが変わります。
実測時点の基本情報を整理します。
| 項目 | 実測値（2026-08-27） |
|---|---|
| リポジトリ | anthropics/claude-code-action（Anthropic公式） |
| star / fork | 8,729 / 2,093 |
| ライセンス | MIT |
| 最新リリース | v1.0.207（2026-08-27・当日） |
| オープンIssue | 708件 |
| 公開開始 | 2025-05-19 |
| 実行方式 | composite（11ステップ） |
| 入力 / 出力 | 39 / 6 |
オープンIssueが708件あるのは、機能追加の速さと利用者数の多さの両方を反映しています。後述のとおりリリース頻度が極端に高いプロジェクトなので、Issueの積み上がり自体は放置のサインとは限りません。
何が「自動判定」されるのか
v1.0 系の売りである「モード自動判定」は、イベント種別に応じて Claude に渡す前提が変わるという意味です。PRのレビューイベントで起動したなら差分をレビューする文脈、Issueコメントで起動したならそのIssueを解決する文脈、というように、プロンプトを毎回自分で書き分けなくてよくなります。prompt 入力を明示すれば自動判定を上書きして任意の指示にもできるので、定型のCIタスク（リリースノート生成、ラベル整理など）にも転用できます。
トリガーの種類
既定では @claude というフレーズに反応しますが、trigger_phrase で変更できます。それ以外の起動方法も用意されています。
・assignee_trigger — 特定ユーザーをアサインすると起動
・label_trigger — 特定ラベル（既定は claude）を付けると起動
・prompt を直接渡して、スケジュール実行や workflow_dispatch から回す使い方
作成するブランチ名も branch_prefix（既定 claude/）と branch_name_template で制御でき、テンプレートには が使えます。
【実測】@v1 の実体——可動タグであることをSHAで確認する
多くの導入記事は次のように書きます。
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: $
この @v1 が何を指しているのかを、GitHub の Git ref API で実際に確認しました。
| タグ | 指すコミット | コミット日時 |
|---|---|---|
v1 |
70fec183852c |
2026-08-27 00:09 UTC |
v1.0.207 |
70fec183852c |
2026-08-27 00:09 UTC |
v1.0.206 |
1f291e1cfe0f |
2026-08-25 22:32 UTC |
v1 と v1.0.207 は同一コミットです。 つまり v1 は固定されたメジャーバージョンではなく、最新リリースへ張り替えられ続ける可動タグです。
問題はリリース頻度です。実測しました。
・直近30日：24リリース
・直近60日：48リリース
平均するとほぼ1日1回です。@v1 を指定しているワークフローは、実質的に毎日別のコードを実行していることになります。
これ自体は珍しくありませんし、セキュリティ修正が速く届くという利点もあります。ただしCIが昨日まで動いていたのに今日壊れたときに、自分のリポジトリ側の変更だけを見ていると原因にたどり着けません。本番のワークフローでは、バージョンかコミットSHAで固定するほうが切り分けが楽です。
# 版で固定する
- uses: anthropics/[email protected]
# SHA で固定する（最も厳密）
- uses: anthropics/claude-code-action@70fec183852c...
参考として、このアクション自身は依存する外部アクションをコミットSHAで固定しています。action.yml の1ステップ目はこうです。
- uses: oven-sh/setup-bun@0c5077e51419868618aeaa5fe8019c62421857d6
このSHAを解決すると oven-sh/setup-bun の v2.2.0（2026-03-14）でした。公式自身がサプライチェーン対策としてSHA固定を実践しているわけで、利用側が @v1 のままなのはやや非対称です。
action.yml は main と v1.0.207 で完全に一致していることも確認しました（入力39・出力6・ステップ11がいずれも同数、ファイル差分なし）。実測時点では main が先行しているという状態ではありません。
【実測】コンポジットアクションの中身——11ステップが何をしているか
action.yml の runs.steps を読むと、実行の流れが分かります。
| # | ステップ | 内容 |
|---|---|---|
| 1 | Install Bun | oven-sh/setup-bun（SHA固定）。Node ではなく Bun で動く |
| 2 | Setup Custom Bun Path | path_to_bun_executable 指定時のみ |
| 3 | Install Dependencies | bun install --production |
| 4 | Install subprocess isolation dependencies | allowed_non_write_users 指定かつ Linux のときのみ |
| 5 | Pin bun binary for post-steps | 後段が同じBunを使うようコピー |
| 6 | Prepend system bin dirs to PATH | /usr/bin /bin を先頭に |
| 7 | Run Claude Code Action | 本体 |
| 8 | Re-prepend system bin dirs to PATH | BASH_ENV LD_PRELOAD 等を空に戻す |
| 9 | Cleanup SSH signing key | ssh_signing_key 指定時 |
| 10 | Post buffered inline comments | インラインコメントの投稿 |
| 11 | Revoke app token | 終了時にアプリトークンを DELETE で失効 |
起動から終了までを1本の流れにすると、権限チェックがどこで効くのかが分かります。
allowed_non_write_users で迂回可（RISKY）" A->>A: "Bun導入・bun install --production" A->>C: "Claude Code 実行" C-->>A: "conclusion / branch_name / session_id" A->>GH: "アプリトークンを DELETE で失効" Note over A,GH: "BASH_ENV / LD_PRELOAD も空に戻す"
注目すべきは 11番目です。GitHub App のトークンを使った場合、ジョブの終わりに API を叩いて自分でトークンを失効させています。短命トークンをさらに明示的に破棄する設計で、これは丁寧な実装です。
8番目も見逃せません。BASH_ENV と LD_PRELOAD を空に戻しています。これらはシェルやダイナミックリンカの挙動を乗っ取れる環境変数で、Claude が実行したコードによって汚染された可能性を後段のステップに持ち越さないための処理です。allowed_non_write_users を使っているときだけ走ります。
出力は6つあり、後続ステップから使えます。
| 出力 | 用途 |
|---|---|
conclusion |
success / failure |
branch_name |
Claude が作ったブランチ |
execution_file |
実行ログのパス |
structured_output |
--json-schema 使用時のJSON |
session_id |
--resume で会話を継続できるID |
github_token |
使用されたトークン |
session_id があるので、複数ジョブにまたがって同じ会話を続ける組み方ができます。
Claude Code Action のセキュリティ設計——既定の防御と、それを外す2つの入力
Claude Code Action は「AIにリポジトリの書き込み権限を渡す」仕組みなので、権限設計が中核です。公式の docs/security.md を読むと、既定の防御は明快です。
既定：write権限を持つユーザーしか起動できない。 Issue・PR・コメント・レビューの各イベントでリポジトリのアクセス権が検査されます。workflow_run イベントでは、上流の実行を開始したアクター（例：フォークPRの作者）の権限も併せて検査され、write権限がなければ Claude を走らせる前に停止します。workflow_dispatch / repository_dispatch / schedule は、GitHub 自体がwrite権限を要求するため個別検査の対象外です。
既定：ボットは起動できない。 GitHub App やボットは既定で拒否されます。
この2つを外す入力が用意されており、どちらも公式が警告を付けています。
バイパス1：allowed_bots
特定のボット、または * ですべてのボットに起動を許可します。公式の警告はこうです。
⚠️ Allowed bots are not checked for repository permissions.
許可したボットはリポジトリ権限を検査されません。 公開リポジトリでは、外部の誰かが作った GitHub App が Issue を立てたりコメントしたりできるため、allowed_bots: '*' にしているとそうしたAppが自分の書いたプロンプトでこのアクションを起動できる可能性があります。公式は「* より明示リストを使え」「信頼するApp名だけ挙げろ」「どうしても * が必要なら workflow の permissions: を最小に」と書いています。
バイパス2：allowed_non_write_users（公式が RISKY と明記）
write権限チェックそのものを外します。公式ドキュメントの見出しからして 「⚠️ Non-Write User Access (RISKY)」 です。
緩和策は実装されています。
・Anthropic・クラウド・GitHub Actions のシークレットをサブプロセスの環境変数から除去（best-effort のスクラブ）
・Linux ランナーで bubblewrap が使える場合、サブプロセスを PID名前空間で分離
・CLAUDE_CODE_SCRIPT_CAPS で特定スクリプトの呼び出し回数を上限設定できる（例：{"edit-issue-labels.sh":2}）
ただし公式は効果を誇張していません。
This reduces but does not eliminate prompt injection risk
「リスクを減らすが排除はしない」と明言しています。そのうえで、使うなら次を守るよう求めています。
・workflow の permissions: を最小にする（例：ラベル付けだけなら issues: write のみ）
・github_token には secrets.GITHUB_TOKEN を渡す。これはジョブの宣言権限にスコープされ、ジョブ終了で失効する
・個人アクセストークン（PAT）を使わない。静的なトークンは実行間で回転せず、プロンプトインジェクションによって時間をかけて部分的あるいは完全に復元されうる
・claude_args で使えるツールを絞る（例：--allowedTools "Bash(gh issue view:*)"）
なお、スクラブは CLAUDE_CODE_SUBPROCESS_ENV_SCRUB: 0 で無効化できます。無効化する理由がない限り触らないでください。
pull_request_target / workflow_run の落とし穴
公式ドキュメントが特に強く警告しているのがこれです。両イベントはベースリポジトリのシークレットを持って実行されます。そこでPRのheadをワークスペース直下にチェックアウトしてからこのアクションを走らせると、Claudeは信頼できないコードを作業ディレクトリとして実行することになります。
Do not check out an untrusted ref into the workspace root before this action.
この一文は、CIにAIを組み込むときの一般則としても有効です。
最小構成のワークフロー
実際に置くファイルは短く済みます。既定の防御（write権限保有者のみ）に任せる、いちばん素直な構成は次のとおりです。
name: Claude
on:
issue_comment:
types: [created]
permissions:
contents: write
pull-requests: write
jobs:
claude:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: anthropics/[email protected]
with:
anthropic_api_key: $
allowed_bots も allowed_non_write_users も書いていない点が重要です。書かなければ既定の防御がそのまま効きます。
どの認証方式を選ぶか
action.yml の入力を見ると、認証だけで9個あります。
| 方式 | 入力 |
|---|---|
| APIキー | anthropic_api_key |
| OAuthトークン | claude_code_oauth_token |
| Amazon Bedrock | use_bedrock |
| Google Vertex AI | use_vertex |
| Azure AI Foundry | use_foundry |
| OIDCフェデレーション | anthropic_federation_rule_id / anthropic_oidc_audience / anthropic_service_account_id / anthropic_organization_id / anthropic_workspace_id |
OIDCフェデレーション系の入力が揃っているのは、長期のAPIキーをGitHub Secretsに置かずに済ませたい組織向けの設計です。GitHub Actions の OIDC トークンを Anthropic 側のフェデレーションルールで検証させる構成になります。
これら3クラウド経路とOIDCの実動作は、本記事では未検証です。 対応する入力が action.yml に存在することを確認したにとどまります。
plugins と plugin_marketplaces という入力もあり、Claude Code のプラグインをCI上で読み込ませられます。ローカルのスキル・プラグイン運用をそのままCIへ持ち込む使い方については、qvr（quiver）とは｜エージェントスキルにlockfileと監査を持ち込むGo製パッケージマネージャやalamops/skills解説｜evals付き個人スキル集9本と公式eval手法への反論を読むも参考になります。
Claude Code Action を Claude Code CI に載せる前に決めておくこと
バージョンを固定するか決める。 @v1 は毎日中身が変わります。壊れたときの切り分けを重視するなら固定、セキュリティ修正の即時反映を重視するなら @v1。どちらでもよいですが、選んだ理由をワークフローのコメントに書いておくと後任が迷いません。
permissions: を最小から始める。 Claude ができることは workflow の権限に縛られます。まず contents: read と pull-requests: write 程度から始め、必要になったら足すのが安全です。
外部からの起動を許すかどうかを決める。 既定（write権限保有者のみ）で足りるなら allowed_bots も allowed_non_write_users も触らないのが最善です。触る必要が出たときは、公式の docs/security.md を読んでから設定してください。この2つは便利機能ではなく、防御を外すスイッチです。
コストの上限を意識する。 Issueコメントごとに Claude Code が走るので、活発なリポジトリでは呼び出し回数がそのまま費用になります。label_trigger に絞る、trigger_phrase を目立たない語にするなど、起動条件を狭める設計が有効です。
まとめ
・Claude Code Action は Anthropic 公式・MIT・★8,729。実体は Bun で動く11ステップのコンポジットアクション（入力39・出力6）
・@v1 は可動タグ。実測で v1 と v1.0.207 は同一コミット 70fec183。直近30日で24リリース（60日で48）なので、実質毎日更新される
・公式自身は依存アクションをコミットSHAで固定している（oven-sh/setup-bun = v2.2.0）
・終了時にアプリトークンを自ら失効させ、BASH_ENV / LD_PRELOAD を空に戻すなど、実装は丁寧
・既定の防御は「write権限保有者のみ起動可」。外す入力は allowed_bots と allowed_non_write_users の2つで、どちらも公式が警告付き
・allowed_non_write_users の緩和策（シークレットのスクラブ・bubblewrap分離）は、公式が「リスクを減らすが排除しない」と明記
action.yml は誰でも読めます。導入前に runs.steps を1回眺めておくと、「このActionが自分のCIで何をするのか」が具体的に分かります。
参照ソース
- anthropics/claude-code-action — 公式リポジトリ。
action.ymlの入力・出力・コンポジットステップ（2026-08-27 実測） - docs/security.md — アクセス制御・
allowed_bots/allowed_non_write_usersの警告・pull_request_targetの注意（2026-08-27 参照） - claude-code-action Releases — リリース頻度の実測（直近30日24件・60日48件）（2026-08-27 参照）
- GitHub Git ref API —
v1/v1.0.207/v1.0.206の指すコミットSHA（2026-08-27 実測）
