公開2025.05.26更新2026.10.06 Claude

Claude Code Actionとは？GitHubで動く仕組みとできないこと・Code Reviewとの違い

Claude Code Actionは、Anthropicが公開しているGitHub Action「anthropics/claude-code-action」の通称です。イシューやプルリクエストに「@claude」と書くと、リポジトリのワークフロー上でClaude Codeが起動し、質問への回答、コードの修正とコミット、プルリクエストのレビューまでを行います。

ただし2026年10月時点では、GitHub上でClaudeを動かす仕組みがこのアクション以外にもあり、名前もよく似ています。この記事では、2026年10月6日公開のv1.0.243を基準に、アクションの仕組みとできること・できないことを公式リポジトリのソースとドキュメントで確認し、混同しやすい3つの仕組みとの違いと選び方を整理します。

まとめ：Claude Code Actionの要点

正体は自分のワークフローで動くGitHub Action：実行場所は自分のGitHub Actionsランナーで、Claude GitHub Appと認証シークレット、ワークフローファイルの3点で動きます。ライセンスはMITです。
起動は2通り：promptを書かなければ@claudeのメンション待ち、書けばイベントやcronでメンションを待たずに実行します。どちらでも起動者の権限確認は行われます。
承認・マージ・正式レビューはしない：プルリクエストの承認とマージ、GitHubの正式なレビュー提出は、セキュリティ上の理由で設計段階から外されています。Bashはコミット用のgitコマンドなど一部だけが既定で許可され、テストやビルドは個別の許可が要ります。
レビューだけならCode Reviewという別製品がある：ワークフローを書かずにPRを自動レビューするマネージド版で、TeamとEnterprise向け、1回平均15〜25ドルです。
選ぶ基準は「どこで動かし、どの契約で払うか」：自分のランナーで動かしたい、推論をAmazon Bedrockなどのクラウド契約に載せたいならこのアクション。ワークフローを持ちたくないならCode ReviewかCopilotのClaudeエージェントです。

Claude Code Actionの正体と現行版

公式ドキュメントは、このアクションを「リポジトリのワークフローの中でClaude Codeを実行するGitHub Action」と定義しています。エディタやIDEの拡張機能ではありません。ローカルでターミナルから使うClaude Codeと同じエージェントを、GitHub Actionsのランナー上で非対話に走らせる仕組みです。内部はClaude Agent SDKの上に組まれており、v1.0.243のpackage.jsonは@anthropic-ai/claude-agent-sdkの^0.3.291に依存しています。

安定版のv1は2025年8月26日に公開されました（リリース一覧）。それ以前の@betaとは入力の体系が違うため、2025年前半に書かれた解説の設定例はそのままでは動きません。@v1は付け替え式のタグで、2026年10月6日時点ではv1.0.243と同じコミットを指しています。10月2日のv1.0.240から6日のv1.0.243まで、5日間で4回のリリースがありました。@v1と書けば修正は自動で入りますが、挙動も予告なく変わります。

検索すると「claude-code-base-action」という別名のリポジトリも見つかります。これはclaude-code-actionリポジトリ内にあるbase-actionディレクトリのミラーで、イシューやコメントの文脈処理を持たない下位部品です。起動者の権限チェックも持たないため、イシューやプルリクエストを起点に動かす用途ではclaude-code-action本体を使います。

Claude Code Actionが動く仕組み

GitHub App・ワークフロー・ランナーの分担

動作に関わる部品は3つです。Claude GitHub Appは、Claudeがリポジトリを読み書きするための入口で、Contents・Issues・Pull requestsの読み書き権限を使います。ワークフローファイルは、どのイベントでアクションを起動するかを決めます。そしてランナーが、Claude Codeの実行そのものを受け持ちます。

Claudeの推論は、APIキー、Claudeのサブスクリプションで発行したOAuthトークン、Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundryのいずれかを通して呼ばれます。費用はGitHub Actions側とClaude側に分けて確認します。Actions側は公開リポジトリの標準ランナーなら無料、Claude側はAPIキーならトークン課金、サブスクリプションのトークンならプランの利用枠からの消費です。分単価やトークン単価の内訳と、Appの導入からシークレット登録までの手順はClaude Code GitHub Actionsの導入と料金｜@claude連携の設定・分単価とトークン課金で扱っています。Bedrock経由の認証設定はBedrock Claudeの使い方：Messages API・InvokeModel・Claude Codeの設定が参考になります。

@claudeで呼ぶ対話モードとpromptで回す自動化モード

モードはワークフローの書き方で自動的に決まります。prompt入力を書かない場合は対話モードになり、コメントやイシュー本文の「@claude」、担当者の割り当て、ラベルの付与に反応して、進捗と結果をそのイシューやプルリクエストのコメントに書き込みます。prompt入力を書くと自動化モードになり、プルリクエストの作成、イシューの起票、cronなど任意のイベントでメンションを待たずに実行し、結果は既定でワークフローの実行ログに出ます。例外として、track_progress: trueを付けるとpromptがあっても対話モードとして扱われ、進捗コメントが付きます（v1.0.243のsrc/modes/detector.tsでこの判定がpromptより先に行われます）。

どちらのモードでも、既定で起動できるのはリポジトリへの書き込み権限を持つ人だけで、ボットからの起動も許可リストに載せない限り拒否されます。公開リポジトリで第三者が@claudeと書いても、それだけでは動きません。

トリガー文字列の判定は、v1.0.243のソースでは「直前が行頭か空白、直後が空白・行末・句読点」という正規表現です。「@claude review」のようなコメントにも一致します。後述のCode Reviewも「@claude review」で起動するため、両方を入れたリポジトリでは1つのコメントで2つが同時に走りえます。併用するならtrigger_phraseで反応する文字列を分けます。入力項目の一覧やclaude_argsの書き方はanthropics/claude-code-action@v1の設定リファレンス｜入力一覧・claude_args・betaからの移行にまとめています。

Claude Code Actionでできること

公式のcapabilities-and-limitations.mdが挙げる機能は、コードについての質問への回答、単純〜中程度のコード変更、ブランチへのコミットとプルリクエストの下準備、プルリクエストのレビューです。ブランチの扱いは起点によって決まっています。

呼び出した場所	Claudeのコミット先
イシュー	毎回新しいブランチ
オープン中のプルリクエスト	そのPRのブランチへ直接push
クローズ済みのプルリクエスト	新しいブランチ

イシューから呼んだ場合、Claudeはブランチにコミットしたうえで、内容を記入済みのプルリクエスト作成画面へのリンクを返します。プルリクエストを作るボタンを押すのは人間です。ワークフローとアクションの両方でactions: readを与えておけば、呼び出したプルリクエストのCI結果やジョブのログも読めます。

公式examplesにあるワークフロー例

リポジトリのexamplesディレクトリには、v1.0.243時点で11本のワークフローが置かれています。用途の幅はこの一覧で把握できます。

ファイル	起動イベント	用途
claude.yml	コメント・イシュー作成など	@claudeへの応答
claude-wif.yml	同上	APIキーを置かない認証
pr-review-comprehensive.yml	pull_request	進捗表示付きのPRレビュー
pr-review-filtered-paths.yml	pull_request（paths指定）	特定パスの変更だけレビュー
pr-review-filtered-authors.yml	pull_request	特定の作成者のPRだけレビュー
issue-triage.yml	issues: opened	イシューのラベル付け
issue-deduplication.yml	issues: opened	重複イシューの検出
ci-failure-auto-fix.yml	workflow_run	CI失敗の修正
test-failure-analysis.yml	workflow_run	不安定なテストの再実行判断
manual-code-analysis.yml	workflow_dispatch	コミット要約・セキュリティ確認
agent-approval-check.yml	pull_request_target・コメント	AIのコミットに人間の承認を必須化

レビューやイシュー整理のような「書き込みが少ない」用途から始めると、権限と費用の見通しが立てやすくなります。CI失敗の自動修正のようにClaudeがコミットを積む用途は、次章の制約を理解してからにします。

Claude Code Actionでできないこと

v1.0.243がClaudeに渡すシステムプロンプトには「GitHubの正式なレビューの提出、承認、マージはできない（セキュリティ上の理由）」と明記されています。レビューの指摘を行単位で付けるインラインコメント用のツールも、ソースのコメントによれば「Claudeが誤ってPRを承認しないよう、レビュー機能全体は公開せずインラインコメントだけを提供する」設計です。このほかに公式ドキュメントが挙げる制約は次のとおりです。

ブランチのマージやリベースなど、コミットのpush以外のgit操作はしない
呼び出されたリポジトリとイシュー・プルリクエストの文脈の外にはアクセスしない
Bashは、コミット署名を使わない構成でのgit add・git commit・git rmとpush用のラッパーだけが既定で許可される。テストやビルドを走らせるにはコマンド単位で許可を足す
対話モードの返答は、最初に投稿した1件のコメントを更新する形で行う

Bashの許可方法について、capabilities-and-limitations.mdは今もallowed_toolsという入力名で説明しています。この入力はv1で廃止されており、現在はclaude_argsに--allowedToolsを書きます。公式リポジトリ内でも文書の更新が実装に追いついていない箇所があるため、設定はaction.ymlと現行のドキュメントで確かめるのが確実です。

AIのコミットに人間の承認を必須にするagent-approval-check

Claudeが承認できないとしても、人間が中身を読まずに承認すれば同じことです。2026年6月30日にリポジトリへ追加されたagent-approval-checkは、エージェントがコミットしたプルリクエストに限って、書き込み権限を持つ人間の承認をN件求めるステータスチェックです。READMEには、Anthropicが社内でエージェントの書いたすべてのPRに適用しているゲートと同じものだと書かれています。承認はPRの承認レビューか、「/approve <先頭コミットのSHA>」というコメントで数えます。ただし承認レビューを付けただけではチェックは再実行されず、次のpushか/approveコメントの時点で集計されます。公式の例は次のとおりです。

name: agent-approval-check
on:
  pull_request_target:
    types: [opened, synchronize, reopened, ready_for_review]
  issue_comment:
    types: [created]
permissions:
  contents: read
  pull-requests: write
  statuses: write
jobs:
  check:
    if: github.event_name != 'issue_comment' || github.event.issue.pull_request
    runs-on: ubuntu-latest
    steps:
      - uses: anthropics/claude-code-action/agent-approval-check@main
        with:
          required_approvals: 2
          agent_emails: [email protected]
          agent_logins: claude[bot],claude-code[bot]

このワークフローはpull_request_targetとissue_commentで起動するため、常に既定ブランチ側のファイルが使われ、プルリクエスト側からチェックを書き換えて自分を承認させることはできません。設置後、保護ブランチの必須ステータスチェックにagent-approval-checkを登録して初めてマージが止まります。READMEはこのチェックをブランチ保護の代わりにしないよう求めており、同じブランチで「書き込み権限を持つ人の承認レビューを最低1件必須」と「新しいコミットのpush時に古い承認を取り消す」も有効にします。後者がないと、承認後に積まれたコミットまで承認済みとして通ります。公式例は@mainを参照していますが、本番ではコミットSHAで固定するほうが安全です。必須チェックとレビュー必須化の設定場所はGitHubのPull Requestの作り方：作成手順とマージ方式・レビュー必須化の決め方で説明しています。

Code Review・Auto-fix・CopilotのClaudeエージェントとの違い

公式ドキュメントの冒頭には「Claude Codeの名を持つ製品は複数ある」という注記があり、このアクションと別製品の区別が案内されています。ここではGitHub Copilot側のClaudeエージェントを加えた4つを比較対象にします。

経路	実行場所	起動のしかた	必要な契約
Claude Code Action	自分のActionsランナー	@claude・任意イベント・cron	APIキーかClaudeのプラン
Code Review	Anthropicの基盤	PR作成・push・@claude review	Team・Enterprise
クラウドセッションのAuto-fix	Anthropicの基盤のVM	PRごとにオン	Pro・Max・Team・Enterpriseの一部席
CopilotのClaudeエージェント	GitHubの基盤	イシュー割り当て・Agentsタブ	GitHub Copilotの有料プラン

Code Reviewとの違い：ワークフロー不要のマネージドレビュー

Code Reviewは研究プレビューの段階で、Team・Enterpriseプランの組織で管理者が有効にすると、プルリクエストの作成時やpushのたびにレビューが走ります。複数のエージェントが差分と周辺コードを並行して調べ、検証の段階で誤検知をふるい落としてから、重大度付きのインラインコメントを付けます。所要時間は平均20分、費用は公式ドキュメントによるとトークン課金で1回平均15〜25ドルで、プランの利用枠ではなく使用量クレジットから別に請求されます。Zero Data Retentionを有効にした組織とHIPAA構成の組織では使えません。

指摘させる内容は、リポジトリに置くREVIEW.mdで重大度の基準、対象外のパス、投稿前に求める根拠、報告の形式まで調整できます。アクションとの違いは、レビュー専用のサービスで、任意のイベントで任意の手順を組む仕組みではない点です。費用面では、pushごとに起動する設定で小さなコミットを積むチームほどCode Reviewの請求が膨らみます。レビュー以外の自動化もしたい、モデルを選びたい、自社のクラウド契約で払いたいならアクション側で組みます。

クラウドセッションのAuto-fixとの違い：PRを見張る個人の作業

claude.ai/codeで動くクラウドセッションには、指定したプルリクエストを見張り、CIの失敗やレビューコメントを受けて修正をpushするAuto-fixがあります。ターミナルからは/autofix-prで有効にします。リポジトリ全体のワークフローではなく、PR単位でオンにする個人の作業という位置づけです。

注意点は、レビュースレッドへの返信が自分のGitHubアカウント名義で投稿されることです。公式ドキュメントは、issue_commentで起動するワークフローやTerraformのコメント駆動デプロイがあるリポジトリでは、Claudeの返信がそれらを起動しうると警告しています。

GitHub CopilotのClaudeエージェントとの違い：契約と課金経路

GitHubは2026年2月4日にCopilot Pro+とEnterprise、2月26日にBusinessとProへ、AnthropicのClaudeをコーディングエージェントとして提供し始めました。イシューをClaudeに割り当てると、変更を加えてプルリクエストを作り、終わるとレビューを依頼してきます。GitHub Docsによると中身はClaude Agent SDKで、課金はCopilotのAI CreditsとGitHub Actions分です。Anthropicとの契約は要りませんが、選べるモデルはGitHubが用意したものに限られます。モデルの選び方と料金の詳細はGitHub CopilotでClaudeを使う方法｜モデル切替・エージェント・料金【2026年9月】で扱っています。

Claude Code Actionを選ぶ場面と選ばない場面

アクションを選ぶべきなのは、実行環境を自分で決めたい場合です。セルフホストランナーで社内ネットワークの資源に触れたい、推論をBedrockやAgent Platformの契約に載せたい、イシューのラベル付けのようなリポジトリ内の自動化を、ワークフローとして同じリポジトリで管理したい。このどれかに当てはまればアクションが向いています。定期レポートやGitHubイベントを起点にした処理だけなら、Anthropicのクラウドで動くRoutines（研究プレビュー・Pro以上）でも組めるので、実行環境と課金先で選びます。GitHub Enterprise Serverでも動きますが、/install-github-appはgithub.com専用なので、ワークフローは手で配置します。

逆に、次の条件ではアクションを入れても期待どおりに動かないか、割に合いません。

外部コントリビューターのPRを自動レビューしたい公開リポジトリ：GitHubはforkからのPRで起動した実行にシークレットを渡さないため、公式のレビュー例は同じリポジトリのブランチからのPRでしか動きません。
ワークフローを保守する担当者がいないTeam・Enterprise組織：アクションは@v1の更新で挙動が変わるので、レビューだけが目的ならCode Reviewのほうが運用負荷は小さく済みます。
コメントでデプロイが走るリポジトリ：@claudeの応答やコミットが別のワークフローを起動しうるため、起動条件とpermissionsを絞り切れないうちは入れません。
GitLabやBitbucketのリポジトリ：このアクションはGitHub専用です。GitLabはパイプラインから呼ぶ別の手順が公式に用意されています。

導入を決めたら、最初はcontents: readでコードを書き換えさせないレビュー用途から始め、Claudeにコミットさせる段階でagent-approval-checkを必須チェックに加える、という順番を勧めます。ローカルのClaude Code側の権限ルールやサンドボックスの考え方はClaude Codeのセキュリティ設定｜権限ルール・サンドボックス・管理設定で守る実装手順【2026年10月】で整理しています。

よくある質問

Claude Code Actionは無料で使えますか？

アクション自体はMITライセンスで無料ですが、実行にはGitHub Actionsの分とClaudeの利用料がかかります。公開リポジトリで標準ランナーを使う分のActions料金は無料です。Claude側はAPIキーならトークン課金、サブスクリプションのOAuthトークンならプランの利用枠から消費されます。