Claude Code GitHub Actionとは？導入手順や使い方、料金体系を徹底解説

Claude Code GitHub Actionは、Anthropic公式が提供するGitHub Actions向けの統合アクションです。PRやIssueに「@claude」とメンションするだけで、Claudeがリポジトリ全体を読み取り、コードレビュー・実装・CI修正・ドキュメント更新までを自動で進めます。
2025年8月にGA（一般提供）化されたv1.0以降、設定が大幅に簡素化され、Anthropic直接APIに加えてAmazon Bedrock・Google Vertex AI・Microsoft Foundryからの利用にも対応しました（公式ドキュメント本文の構成例はBedrock・Vertex中心、Foundry経由はAgent SDKとの組み合わせで運用するケースが多い）。

本記事では、2026年5月時点の最新情報をもとに、Claude Code GitHub Actionの主要機能・導入手順・料金体系（2026年6月15日からのAgent SDK月次クレジット分離を含む）・エンタープライズ展開・他のAIコーディングエージェントとの使い分けまでを体系的に解説します。
あわせて、移行で詰まりやすい論点と組織展開を見据えた運用設計のポイントまで整理し、PRレビューや実装の自動化を実務に落とし込むための判断材料を網羅します。

Claude Code GitHub Actionとは

Claude Code GitHub Actionは、Anthropicが提供するAIモデル「Claude」をGitHub Actionsのワークフロー内で動かすための公式アクションです。PRやIssueのコメント欄で @claude とメンションするだけで、Claudeがリポジトリ全体を読み取り、コード分析・レビュー・修正提案・機能実装までを自動で進めます。

通常のClaude CodeはターミナルやIDEで対話的に使う前提でしたが、Claude Code GitHub Actionは「GitHub上で完結し、PCを起動していなくても動く」点が大きな違いです。スマートフォンからIssueにコメントすれば、通勤中に変更ブランチとPR作成リンクが届く運用も成立します（PRを自動でオープンするかはワークフロー設計次第）。

公式アクションとしての位置づけ

anthropics/claude-code-actionはAnthropic自身がメンテナンスする公式リポジトリであり、GitHub Marketplaceには「Claude Code Action Official」として登録されています。@v1 タグを指す形でワークフローから参照するのが推奨設定です。

主な機能は次のとおりです。

• 自動モード検出
  ワークフローのコンテキストに応じて「インタラクティブモード（@claudeメンション応答）」と「自動化モード（明示的なprompt実行）」を自動的に切り替えます。
  
  

• コードレビュー
  PRの変更点を分析し、品質・バグ・セキュリティ・パフォーマンスなど多面的なフィードバックを返します。
  
  

• コード実装
  シンプルな修正・リファクタリング・新機能の実装が可能で、結果は変更ブランチへのコミットとPR作成リンクの提示として返ります（自動PR化はワークフロー設計次第）。
  
  

• 進捗トラッキング
  タスクの完了状況をチェックボックスとしてコメントに動的に書き出します。
  
  

• 構造化出力
  GitHub Actions outputsとしてJSON形式で結果を返せるため、後続ジョブと連携できます。
  
  

これらの機能はすべて「同じGitHub Actionsランナー上でClaude Codeを動かす」というシンプルな構造の上に成り立っています。Action自体はGitHub-hostedまたはセルフホストのランナー上で実行されますが、モデル呼び出しのAPIコールはAnthropic直接API・Amazon Bedrock・Google Vertex AI・Microsoft Foundryなど、選択したプロバイダーへ送信される点に注意してください。データレジデンシーやログ保持の要件は、利用プロバイダー・リージョン・契約条件（Zero Data Retention契約等）で個別に確認するのが基本です。

3つの代表的な起動モード

Claude Code GitHub Actionは、設定によって以下3つのモードのいずれかで動きます。導入時はまず「自分のチームがどのモードを主軸にするか」を決めると判断がぶれません。

レビュー依頼を担当者から振りたいだけならインタラクティブで十分ですが、CI/CD的に「全PRに必ず1回レビューを通す」運用にしたい場合は自動化モードを選ぶことになります。両者を混在させても問題ありません。

通常のClaude Codeとの違い

同じClaudeエンジンでも、ターミナル版のClaude CodeとClaude Code GitHub Actionは実行環境と操作体験が違います。

同じClaudeエンジンを使う以上、応答品質の差はほぼありません。**「人間が手元で対話するか／GitHubの仕組みの中で動かすか」**が選択軸になります。Web版・IDE版・GitHub Action版を1つのClaude Agent SDKが束ねている、と捉えると全体像が掴みやすくなります。

Claude Code GitHub Actionでできること

Claude Code GitHub Actionは、開発ワークフローの中でも「人間の手数が多くなりがちな繰り返し作業」を肩代わりするのが得意です。ここではv1.0時点で実用化されている代表的な4つのユースケースと、それぞれの価値を整理します。

PRレビューの自動化

PRレビューはClaude Code GitHub Actionの最も基本的かつ実用的な用途です。Claudeは変更されたファイルを1つずつ確認し、複数観点でフィードバックをコメントとして返します。

レビューで検出される代表的な観点は以下のとおりです。

レビュアーが見落としやすい細かな観点まで網羅できるため、レビュー品質の底上げと人間レビュアーの負荷軽減を同時に得られます。プロンプトに「セキュリティを重点的に」「TypeScriptの型定義を確認して」のように具体的な指示を与えれば、プロジェクトの特性に合わせて観点を絞ることも可能です。

実務的には、人間レビュアーは設計判断・要件整合・破壊的変更の影響などClaudeが判断しづらい論点に集中し、機械的に拾える指摘はClaudeに任せる役割分担が現実的です。Anthropic公式のGitHub Code Review機能も併用すれば、全PRに自動レビューが入る運用に拡張できます。

IssueからPRドラフトまでの自動化

Issueに記載された仕様や要件をもとに、Claudeがコード実装からブランチ作成・コミット・PR作成リンクの提示までを一気通貫で進めます。Issueをassignしたタイミングや、Issue本文に @claude を含めて起票したタイミングで自動的に動き始めます。Anthropic公式のsecurity ドキュメントによると、デフォルト挙動は「変更ブランチを作成し、PR作成リンクをコメントに提示する」までで、ドラフトPRや本番PRを自動オープンするにはワークフロー設計（prompt で明示指示する、PR作成ステップを追加する等）が必要になります。

Claudeが行う作業の流れは概ね次のとおりです。

1. Issueの内容を読み取り、実装すべき機能を整理する
2. タスクリストを作成し、進捗をコメントとして共有する
3. 作業用ブランチを作成する
4. コードを実装し、必要に応じてテストも書く
5. 変更内容をコミットする
6. PR作成リンクをコメントに提示する（ワークフロー設定でドラフトPRの自動作成まで進めることも可能）
7. Issueに完了報告を投稿する

定型的な実装タスク、仕様が明確な機能追加、リファクタリングのようなパターンが見えやすい変更で力を発揮します。Issueに「目的・仕様・技術的制約・受け入れ条件」を明確に書いておくほど、出てくるPRの精度は高くなります。逆に仕様が曖昧なIssueを投げると、PRが意図と外れたまま完成してしまうため、Issueテンプレートを整えてから運用に乗せるのが定石です。

CI失敗の自動修正

CIテストが失敗した際に、エラーログを分析して原因を特定し、修正コードを提案・適用するパターンです。workflow_run イベントを使えば、失敗をトリガーに自動で修正サイクルを回せます。

対応のしやすさはエラー種別によって差があります。

lintやフォーマット違反のような「正解が決まっている」エラーは高い精度で自動修正できる一方、依存関係の競合のように「ポリシー判断が要る」エラーは人間が決めた方が早いケースもあります。最初は ESLint/Prettier 系の自動修正から始め、安定したら型エラー・ユニットテストへ広げていくと事故が少なくなります。

ドキュメント同期

コード変更に合わせてREADMEやAPIドキュメントを自動更新する用途です。push イベントで paths に src/** を指定し、変更があったときだけドキュメント差分を投げ込むワークフローを組めば、コードとドキュメントの乖離を構造的に防げます。

更新対象として現実的なものは以下です。

「人間が書くと続かない」ドキュメント運用を、コード変更のたびに走るパイプラインに置き換えるのがポイントです。リポジトリのルートに CLAUDE.md を置いて文体・章構成のルールを定義しておけば、複数人で書き分けても表現がブレません。

Claude Code GitHub Actionの料金体系

Claude Code GitHub Actionを動かすためのコストは、**(1) Claude側の利用料（API or サブスクリプション）**と (2) GitHub Actions実行時間 の2つに分かれます。さらに2026年6月15日からはサブスクリプション側で大きな課金変更が入るため、ここを抑えておかないとプラン選択を誤ります。

Claude側の利用料（API従量とサブスクリプション）

Claudeの利用は、Anthropic公式のClaude料金ページに整理された通り、API従量とサブスクリプションの2系統から選びます。GitHub Action側の認証も2方式に分かれており、APIキー利用なら anthropic_api_key 入力にAnthropic APIキーを渡し、Pro/Max等のサブスクリプション連携であれば claude_code_oauth_token 入力にOAuthトークンを渡します。両者で指定するパラメータ名が異なる点に注意します。

API従量課金はモデルごとに単価が異なります。2026年5月時点の代表モデル単価は以下のとおりです。

Claude Code GitHub ActionのデフォルトモデルはSonnetであり、Opusを使いたい場合は claude_args で --model claude-opus-4-7 のように明示します。実務では「日常レビューはSonnet固定、複雑な実装系Issueだけ手動でOpusを指定」というモデル使い分けが費用対効果のバランスを取りやすい構成です。

2026年6月15日からのAgent SDK月次クレジット分離（重要）

2026年6月15日に、サブスクリプション利用者向けの大きな課金変更が施行されます。Anthropic公式のヘルプセンター「Use the Claude Agent SDK with your Claude plan」によると、Agent SDK経由の利用（Claude Agent SDK、claude -p 非対話モード、Claude Code GitHub Action、サードパーティ製アプリ）は別の月次クレジット枠に分離され、フルAPIレートで課金されるようになります。

このクレジットはユーザー単位（プール不可）・月次リフレッシュ・繰越不可・1回のオプトイン必要という仕様です。インタラクティブな端末・IDE上のClaude Code利用には影響しませんが、GitHub Action経由の自動化はすべてこの新クレジットを消費する扱いになります。

実際にどの程度の規模感かを掴むために、1日4件のPRレビューを30日間こなすケースで試算すると、Sonnet 4.6で約$25/月の消費になり、Proの$20クレジットを月半ばで使い切る計算です。クレジット枯渇後はAPIフルレートでの追加課金、または処理停止のどちらかになります。

加えて、同じ2026年6月15日に旧モデルIDが退役します。AnthropicのModel deprecationsページに従い、claude-sonnet-4-20250514 → claude-sonnet-4-6、claude-opus-4-20250514 → claude-opus-4-7 への切り替えが必須で、退役日以降の旧モデルIDへのリクエストはエラーになります。SDKパッケージ名も @anthropic-ai/claude-code → @anthropic-ai/claude-agent-sdk（TypeScript）、claude-code-sdk → claude-agent-sdk（Python）に改名されています。ワークフローファイルとSDK依存の両方を一度棚卸ししておくと安全です。

GitHub Actions実行時間のコスト

Claude Code GitHub ActionはGitHub-hosted runnerで動くため、GitHub Actions側の課金も発生します。パブリックリポジトリは無料、プライベートリポジトリはプラン別の無料分（Proは3,000分/月）を超過した分が課金対象です。

セルフホストランナーを使う場合はGitHub Actions側の課金はかかりませんが、ランナーのインフラ運用コストが別途必要になります。Bedrock / Vertex経由で大きめのワークロードを回す組織では、セルフホストでコストとセキュリティを同時に最適化するパターンも見られます。

コスト最適化の実務指針

Claude Code GitHub Actionのコストは、モデル選択 × ターン数 × 起動頻度 の積で決まります。実務で効くコスト最適化の打ち手をAI総合研究所の支援経験から整理すると、以下のポイントが投資対効果が高いものです。

• モデルの使い分け
  日常PRレビューはSonnet 4.6、複雑な実装やバグ調査だけOpus 4.7に切り替える。claude_args で --model を明示するだけで切り替えられます。
  
  

• --max-turns の設定
  会話のターン数を10前後に絞ると、Claudeの暴走的な深堀りを抑えられます。コードレビューであれば5ターン程度で十分なケースが多いです。
  
  

• プロンプトキャッシュの活用
  API利用時は同一プロンプト断片の再利用でキャッシュが効きます。大規模リポジトリで CLAUDE.md を参照させるパターンとは特に相性が良いです。
  
  

• トリガー条件の絞り込み
  paths フィルタや if: 条件で「ドキュメントだけの変更ではClaudeを起動しない」「特定ディレクトリ配下のPRだけにレビューを走らせる」設定にすると、無駄起動を防げます。
  
  

料金プランの詳細や利用制限・支払い方法は、Claude Code料金完全ガイドで個別に解説しています。

Claude Code GitHub Actionの導入手順

Claude Code GitHub Actionのセットアップは、最短10〜15分程度で完了します。Anthropic直接APIを使うならクイックセットアップ、Bedrock / Vertex / Foundry経由を使うなら公式アクションの専用入力（use_bedrock / use_vertex / use_foundry）を有効化する手動セットアップが基本路線です。

事前準備と必要な権限

セットアップを始める前に、以下を満たしているか確認します。

必須要件

• GitHubリポジトリの管理者権限（GitHub App追加とSecrets登録のため）
• Anthropic APIキー、または利用するクラウドプロバイダーの認証情報
• ワークフロー権限を含むGitHub CLIトークン（クイックセットアップ時）
• gh CLI（ローカルから /install-github-app を流す場合）

推奨要件

• Claude CodeのCLI版が手元にインストール済み
• リポジトリのルートに CLAUDE.md を置く準備（プロジェクト固有ルールの整備）

クイックセットアップ（/install-github-app）

最も簡単なセットアップは、Claude CodeのCLIから /install-github-app を実行する方法です。Claude Codeが対話形式でGitHub App追加・Secret登録・ワークフローファイル作成PRまでガイドします。

# Claude Code GitHub Actionを入れたいリポジトリに移動
cd /path/to/your/repository

# Claude Codeを起動
claude

# インストールコマンドを実行
/install-github-app

このコマンドを実行すると、以下のステップが順に走ります。

1. 対象リポジトリの確認
2. Claude GitHub Appのインストール承認
3. APIキーの設定（既存キーを使うか新規発行するかを選択）
4. ワークフローファイルを追加するPRの作成

PRがマージされた時点でセットアップは完了です。IssueやPRで @claude をメンションすれば動き出します。

手動セットアップの手順

クイックセットアップが使えない場合（Bedrock / Vertex / Foundry経由の利用、組織ポリシーで自動PRを許可しない環境など）、手動セットアップに切り替えます。

Step 1: Claude GitHub Appのインストール

Claude GitHub Appを対象リポジトリに追加します。アプリは以下の権限を要求します。

• Contents: Read & Write（ファイル変更のため）
• Issues: Read & Write（Issueへの応答のため）
• Pull requests: Read & Write（PR作成と変更プッシュのため）

Step 2: APIキーをGitHub Secretsに登録

リポジトリの「Settings → Secrets and variables → Actions」へ進み、ANTHROPIC_API_KEY という名前でAnthropic APIキーを登録します。APIキーはAnthropic Consoleから発行します。

Step 3: ワークフローファイルの作成

.github/workflows/claude.yml を作成し、以下の内容を記述します。

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

jobs:
  claude:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
      issues: write
    steps:
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}

このワークフローは、Issue/PRコメントとIssue起票・アサインをトリガーに、@claude メンションへ応答する最小構成です。permissions でリポジトリ書き込み権限を明示しておかないと、ClaudeがPRやファイル変更を作れない点に注意してください。

Step 4: 動作確認とトラブル対処

任意のIssueに @claude このリポジトリの構造を要約して のようにコメントすれば、数十秒〜数分でClaudeから返信があります。返ってこない場合は、以下を順にチェックします。

1. ワークフローが .github/workflows/ 直下にあり、トリガーが issue_comment 等を含むか
2. GitHub Actionsがリポジトリで有効になっているか
3. ANTHROPIC_API_KEY Secretが登録されているか
4. コメントが @claude で始まっているか（/claude 等は誤検出）

これでも応答しない場合は、Claudeアプリのインストール対象に該当リポジトリが含まれているかを確認します。

Claude Code GitHub Actionの使い方とカスタマイズ

セットアップが終わったら、次は「どう指示を出すか」と「どこまで動作を調整できるか」を押さえます。Claude Code GitHub Actionは、自然言語のプロンプトと claude_args / CLAUDE.md / Skillsの組み合わせで、かなり細かい運用設計まで対応できます。

@claudeメンションの基本構文

Issue・PRコメント内で @claude を付けて自然言語で指示を出すだけで、Claudeはコンテキスト（Issue本文、関連ファイル、PR差分など）を読み取って応答します。特別な構文を覚える必要はありません。

@claude このPRのセキュリティ面をレビューしてください

@claude バグの原因を特定して修正方法を提案してください

@claude このIssueの内容を実装してドラフトPRを作成してください

実務では「観点を絞ったプロンプト」のほうが品質が安定します。例えばPRレビューなら「@claude このPRをセキュリティ・パフォーマンス・テストカバレッジの3観点で確認してください。特にN+1クエリの有無を重点的に見てください」のように、見てほしい観点と優先順位まで明示するのがコツです。

CLAUDE.mdでのプロジェクト規約定義

リポジトリのルートに CLAUDE.md を置くと、Claudeがそのファイルを読み込んで以降の作業に反映します。コーディング規約・命名ルール・テスト方針・禁止事項などをここで一元化することで、毎回プロンプトに長文の前提条件を書き込む必要がなくなります。

# プロジェクトルール

## コーディング規約
- TypeScriptを使用
- ESLint設定に従う
- 関数には必ずJSDocコメントを記載
- 変数名はキャメルケース

## テスト
- Jestを使用。カバレッジ80%以上を維持
- `npm test` でテスト実行

## コミットメッセージ
- Conventional Commits（feat / fix / docs / chore など）
- 日本語の本文＋英語のtypeの組み合わせを許容

## 禁止事項
- `console.log` をmainブランチにコミットしない
- `any` 型の利用を避ける
- 直接DOM操作を行わない（React前提）

複数人が同じリポジトリでClaudeを呼ぶときほど、CLAUDE.md の効果は大きくなります。「Claudeが書いたコードのレビュー観点が人によってブレる」「テンプレ的なリファクタが場当たり的になる」といった状況を回避できます。詳細な書き方やMemory機能との関係は、CLAUDE.md解説記事で個別にまとめています。

claude_argsによる動作調整

v1.0で mode / direct_prompt / custom_instructions / max_turns / model などの個別オプションは廃止され、すべて claude_args に集約されました。Claude Code CLIの引数をそのまま渡せるため、柔軟性と簡潔さを両立できます。

- uses: anthropics/claude-code-action@v1
  with:
    anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
    prompt: "Review this PR for security issues"
    claude_args: |
      --append-system-prompt "Follow our coding standards"
      --max-turns 10
      --model claude-sonnet-4-6

このアプローチの利点は2つあります。1つ目は、Claude Code CLIで使い慣れたオプションをそのままワークフローに持ち込めるため、ローカルとCIの設定が一致しやすくなる点です。2つ目は、新しいCLIオプションがCLI側で増えてもアクション側のリリースを待たずに即座に使える点で、機能追従の遅延が小さくなります。

代表的な引数の使い所は以下のとおりです。

Skills / Pluginsの呼び出し

prompt 入力は単なる自然言語だけでなく、Claude Skills呼び出しも受け付けます。リポジトリの .claude/skills/ 配下に置いたスキルや、プラグインマーケットプレイス経由のスキルをワークフローから直接トリガーできます。

- uses: anthropics/claude-code-action@v1
  with:
    anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
    plugin_marketplaces: "https://github.com/anthropics/claude-code.git"
    plugins: "code-review@claude-code-plugins"
    prompt: "/code-review:code-review ${{ github.repository }}/pull/${{ github.event.pull_request.number }}"

このパターンの強みは、レビュー基準・実装手順・チェックリストといった「組織のナレッジ」をスキルとしてバージョン管理できる点です。プロンプトを毎回書き直すよりも、スキルとして定義しておけば誰が呼んでも同じ品質の応答が返ります。

ワークフロートリガーのカスタマイズ

最後に、起動トリガーの組み立て方を整理します。自動レビューを全PRに通すなら以下のような構成が定番です。

name: Auto Code Review
on:
  pull_request:
    types: [opened, synchronize]
    paths:
      - 'src/**'
      - '!docs/**'

jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            このPRを以下4観点でレビューしてください。
            1. コード品質と可読性
            2. 潜在的なバグやエッジケース
            3. パフォーマンス影響
            4. セキュリティリスク
          claude_args: "--max-turns 5"

この構成のポイントは、paths で src/** 配下のPRだけに限定しつつ、ドキュメント変更（docs/**）はレビュー対象から除外しているところです。さらに --max-turns 5 で1PRあたりのコストを抑えており、組織での連続運用に耐える設計になっています。GitHub Actionsのエージェンティックワークフローとの組み合わせで、より高度な自動化に発展させることも可能です。

Claude Code GitHub Actionをエンタープライズで使う

エンタープライズでは、Anthropic直接APIではなく自社のAmazon BedrockやGoogle Vertex AI経由でClaudeを利用するケースが大半です。データレジデンシー・既存契約の活用・統一請求といった理由から、これら2クラウド経由の構成は実務で頻繁に登場します。Microsoft Foundryについても、公式のaction.ymlでは use_foundry 入力が用意されており、Direct API / Bedrock / Vertex / Foundry の4経路すべてが構成可能です。ただし公式ドキュメント本文の手順例はBedrock・Vertexが中心で、Foundryについては個別の構成例が薄いのが現状のため、本記事もBedrockとVertexを軸に解説します。

Amazon Bedrock経由

Bedrock経由で動かす場合、AWS側でOIDC（OpenID Connect）プロバイダを構成し、GitHub ActionsからIAMロールを引き受ける形にするのがセキュリティ的に妥当です。静的なAWSアクセスキーをSecretに置く運用は、認証情報の流出リスクが高いため避けます。

name: Claude PR Action (Bedrock)

permissions:
  contents: write
  pull-requests: write
  issues: write
  id-token: write

on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]
  issues:
    types: [opened, assigned]

jobs:
  claude-pr:
    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 == 'issues' && contains(github.event.issue.body, '@claude'))
    runs-on: ubuntu-latest
    env:
      AWS_REGION: us-west-2
    steps:
      - uses: actions/checkout@v4

      - name: Generate GitHub App token
        id: app-token
        uses: actions/create-github-app-token@v2
        with:
          app-id: ${{ secrets.APP_ID }}
          private-key: ${{ secrets.APP_PRIVATE_KEY }}

      - name: Configure AWS Credentials (OIDC)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_TO_ASSUME }}
          aws-region: us-west-2

      - uses: anthropics/claude-code-action@v1
        with:
          github_token: ${{ steps.app-token.outputs.token }}
          use_bedrock: "true"
          claude_args: '--model us.anthropic.claude-sonnet-4-6 --max-turns 10'

このワークフローの肝は3点あります。1つ目はOIDC連携で短命な一時クレデンシャルしか発行しない点、2つ目は組織独自のGitHub Appを使って github_token を生成している点、3つ目はBedrock固有のモデルID（us. のようなリージョンプレフィックス付き）を claude_args の --model に渡している点です。これでセキュリティ・監査・モデル指定の3つを同時に満たせます。

Google Vertex AI経由

Vertex AI経由ではWorkload Identity Federationを使い、GCP側で発行したサービスアカウントをGitHub Actionsから引き受けます。ダウンロード可能なサービスアカウントキーを使わないため、鍵の漏洩や定期ローテーション運用の手間が消えます。

- name: Authenticate to Google Cloud
  id: auth
  uses: google-github-actions/auth@v2
  with:
    workload_identity_provider: ${{ secrets.GCP_WORKLOAD_IDENTITY_PROVIDER }}
    service_account: ${{ secrets.GCP_SERVICE_ACCOUNT }}

- uses: anthropics/claude-code-action@v1
  with:
    github_token: ${{ steps.app-token.outputs.token }}
    use_vertex: "true"
    claude_args: '--model claude-sonnet-4-6 --max-turns 10'
  env:
    ANTHROPIC_VERTEX_PROJECT_ID: ${{ steps.auth.outputs.project_id }}
    CLOUD_ML_REGION: us-east5

VertexのモデルIDは、Sonnet 4.6以降は claude-sonnet-4-6 のような短いIDで指定できます。Sonnet 4.5以前など一部の旧モデルは claude-sonnet-4-5@20250929 のように @日付 形式での指定が必要なので、利用するモデルに合わせて公式のVertex AIモデルID表を確認してください。プロジェクトIDは認証ステップから自動取得しているため、ワークフローに固定値を書く必要はありません。

Microsoft Foundry経由

Microsoft Foundry経由でClaudeを呼び出す場合は、Azure側でClaudeモデルへのアクセスを有効化したうえで、公式アクションの use_foundry 入力を true に指定します。Azure既存のID管理（Entra ID）・課金（Azure Subscription）・監査（Azure Monitor）にClaude利用を統合できる点が強みです。Bedrock・Vertexと違って公式ドキュメント本文に詳細な構成例が少ないため、初期構築時はaction.ymlの入力仕様とAzure Service Principal経由のフェデレーテッド資格情報を組み合わせて設計するのが安全です。

具体的な設定は、use_foundry: "true" に加え、ANTHROPIC_FOUNDRY_RESOURCE や ANTHROPIC_FOUNDRY_BASE_URL といったFoundry系環境変数をジョブの env で渡す形が標準です。独自エンドポイントを叩く必要があるケースや、より細かい挙動制御を行いたい場合は、claude -p などのAgent SDK / CLIをジョブ内で併用する選択肢もあります。詳細な構成はClaude Code on Microsoft Foundryの解説記事で個別に整理しています。

カスタムGitHub App・OIDCのセキュリティ設計

3クラウドいずれの構成でも共通して効くセキュリティ設計が「カスタムGitHub App＋OIDC」の組み合わせです。Anthropic公式が提供するClaude GitHub Appをそのまま使うのが最短ですが、エンタープライズでは以下の理由から自社App化を選ぶケースが増えています。

• アクセス対象リポジトリを最小化できる
  組織配下の全リポジトリではなく、対象を絞り込んだAppとして配布できます。
  
  

• コミット作成者の表示をブランド統一できる
  自社App名でPRやコミットが作成されるため、監査ログでの追跡が容易になります。
  
  

• トークン生成を actions/create-github-app-token で一元化できる
  ワークフロー内で短命なインストールアクセストークンを発行し、必要なジョブにだけ渡せます。
  
  

セキュリティ面では、permissions: id-token: write を最上位ジョブで明示し、必要最小限のIAM/IAMロール権限（Bedrock呼び出しのみ、Vertex AI Userのみ等）に絞ることが鉄則です。Claude側のAPIキーをSecretに置きっぱなしにせず、トークン生成を都度走らせる構成にすれば、漏洩時の影響範囲を局所化できます。

実装の重さで言えば、3経路とも公式アクション入力（use_bedrock / use_vertex / use_foundry）が用意されているため、基本構成自体の手間は大きく変わりません。差が出るのは認証側で、Bedrock・VertexはOIDC＋Workload Identity系の整備が必要、FoundryはAzure Service Principal＋Foundry系環境変数の指定が必要、といった形でクラウドごとの前段が変わります。AWS/GCP/Azureいずれかが既に社内標準として整備されているなら、その上に乗せるのが最も早道です。エンタープライズでの全体設計はClaude Code企業導入ガイドも参考になります。

他のAIコーディングエージェントとの比較

GitHub上で動くAIコーディングエージェントは複数あり、それぞれ得意領域と料金体系が異なります。Claude Code GitHub Actionだけが正解ではなく、自社の開発フローと既存契約を踏まえて選ぶ視点が重要です。

通常のClaude Code（CLI/Web/IDE）との使い分け

同じClaudeエンジンでも、通常のClaude CodeとGitHub Actionで向く用途が違います。一覧で整理すると以下のようになります。

実務での使い分けは、「個人の探索」と「組織の自動化」を別物として設計するのが正解です。アイデア出し・大きな構造変更はターミナル版で対話し、出来上がったPRに対する一律のレビューや、Issueテンプレートからの自動実装はGitHub Action版に任せる、という役割分担で過不足なく回ります。Claude Code on the webを併用すれば、外出先からスマホでも同じClaudeに指示を出せるようになります。

GitHub Copilot Coding Agentとの比較

GitHub Copilot Coding Agentは、GitHub公式の自律型コーディングエージェントです。GitHub Copilotサブスクリプションに統合されており、エコシステム連携の深さが強みです。

選択の軸は「既存のサブスクリプション契約」と「IDE体験の一体性」です。GitHub Copilotを全社契約しているなら、Coding AgentはCopilot契約の範囲内で追加コストを抑えやすくなります。一方でAnthropic APIやAmazon Bedrockを既に活用している組織や、CLAUDE.md + Skillsで運用ルールを明文化したい組織では、Claude Code GitHub Actionの柔軟性が活きます。

Devinとの比較

Devinは、自律性の高さで知られるAIエンジニアです。タスクを投げると調査・設計・実装・デバッグまで一気通貫で進める設計になっています。

Devinは2026年に料金体系を刷新し、Proプラン（$20/月）でも基本的な自律実行が試せるようになりました。とはいえ「全タスクを丸ごとAIに任せる」プロダクト思想は変わっておらず、本格運用にはMaxやTeamsプランが前提になります。実務的には、まずClaude Code GitHub Actionで「人間レビューを残したまま定型作業を自動化」する段階から入り、より広い自律性が必要になった時点でDevinの追加導入を検討するのが現実的なルートです。

Claude Code GitHub Actionの導入判断で詰まる論点

Claude Code GitHub Actionは導入そのものは数十分で済む一方、運用に乗せる段階でいくつか判断を迫られる論点があります。ここではAI総合研究所の支援経験から、特に詰まりやすい4つの論点と判断軸を整理します。

課金変更後のプラン選び（2026/6/15以降）

最大の判断ポイントは、2026年6月15日からのAgent SDK月次クレジット分離にどう対応するかです。現状Pro $20でClaude Codeを潤沢に使えていた組織でも、Agent SDK経由分（GitHub Action経由）が別枠化された瞬間にクレジット枯渇が発生し得ます。

判断のフレームとしては以下が実務的です。

• 個人開発・小規模リポジトリ（PRレビュー月50件以下）
  Pro $20の新クレジット枠で大きな問題は出にくいです。API追加課金を許容しておけば破綻しません。
  
  

• チーム開発・PRレビュー月数百件規模
  Max 5x（$100/月）が現実的な基準線です。Sonnetを中心に運用すれば3,000万トークン程度の余裕がつきます。
  
  

• 複数チーム横断・大量自動化（CI修正・ドキュメント同期も含む）
  Max 20x（$200/月）か、Anthropic APIへの直接切り替えを検討します。クレジットがプール不可な点を踏まえると、利用が集中するチームではAPIの方が見通しが立てやすいケースもあります。
  
  

• エンタープライズ・既存クラウド契約あり
  Bedrock / Vertex / Foundry経由（いずれも公式アクションの専用入力で構成可能）に寄せ、Anthropicの直接サブスクリプションは外す選択も成立します。請求とID管理を既存契約に一本化できる利点が大きく、社内決裁も通しやすくなります。
  
  

Claude Codeの法人プラン比較記事で、組織規模別のプラン選定論点を個別に整理しています。

モデル選択（Sonnet 4.6 / Opus 4.7 / Haiku 4.5）

「すべてOpus 4.7にすれば品質が上がる」と考えがちですが、コスト効率と品質のバランスを取るとSonnet中心の運用が最適解になるケースが多いです。

実務での選び分けの目安は以下のとおりです。

切り替えは claude_args の --model だけで済むため、ワークフローを複数用意し、トリガーごとにモデルを変えるのも有効です。例えば「PRレビューはSonnet」「@claude bug で始まるコメントだけOpus」のように、コメントの内容でモデルを変える設計も可能です。詳細はClaude Opus 4.7解説記事で個別にまとめています。

人間レビューを残す境界設計

Claudeが自動でPRを作る運用にする場合、「どこまで人間のレビューを残すか」を最初に決めておかないと、後で事故が起きます。AI総合研究所の支援経験で見えた現実的な境界線は以下です。

• mainブランチへの直接マージは絶対に許可しない
  Claude生成PRは必ずドラフト or レビュー必須PRとし、人間の承認なしにマージされない設定にします。
  
  

• 本番デプロイに直結するリポジトリは特に慎重に
  Infrastructure as Codeリポジトリや、デプロイパイプラインに直結するリポジトリでは、Claude起動を限定的なディレクトリに絞り、人間レビューを必須化します。
  
  

• 依存パッケージの追加・バージョンアップはレビューで止める
  セキュリティリスクが高い操作なので、package.json 変更を伴うPRは人間レビューを通すルールを CLAUDE.md に明記します。
  
  

• シークレットや認証情報を扱うコードは触らせない
  .env や認証関連ファイルを --disallowedTools で除外、または CLAUDE.md で「触らない」と明記します。
  
  

「Claudeが書いた」と「Claudeに任せて良い」は別問題です。書かせる範囲と任せる範囲を明示的に分離することが、エージェント運用の事故を防ぐ第一歩になります。

既存ベータ版ワークフローの移行

v1.0で旧設定（mode / direct_prompt / custom_instructions / max_turns / model）は廃止され、prompt と claude_args への統一が行われました。ベータ版から移行するには、ワークフローファイルの書き換えが必要です。

ベータ版（旧）と v1.0（新）の対比例は以下のとおりです。

# ベータ版（旧）
- uses: anthropics/claude-code-action@beta
  with:
    mode: "tag"
    direct_prompt: "Review this PR for security issues"
    anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
    custom_instructions: "Follow our coding standards"
    max_turns: "10"
    model: "claude-3-5-sonnet-20241022"

# v1.0（新）
- uses: anthropics/claude-code-action@v1
  with:
    prompt: "Review this PR for security issues"
    anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
    claude_args: |
      --append-system-prompt "Follow our coding standards"
      --max-turns 10
      --model claude-sonnet-4-6

移行作業は単純な置換が多いですが、モデルIDも同時に最新（claude-sonnet-4-6 / claude-opus-4-7）へ更新するのが安全です。2026年6月15日以降は旧モデルIDがエラーになるため、施行日までに完了させる前提でスケジュールを引いておきます。詳細手順は公式の移行ガイドに整理されています。

コード自動化の先にある業務全体のエージェント基盤

Claude Code GitHub ActionでPRレビュー・実装・CI修正までを自動化できる体制が整うと、次の関心は「開発以外の業務もどこまで自動化できるか」に移ります。経費承認や請求書処理、ナレッジ検索のような業務側のAI化は、コードレビューとは別レイヤーの設計が必要です。

AI Agent Hubは、Microsoft TeamsからAIエージェントを呼び出し、ERPやCRM、SharePoint等と連動して業務を自動実行するエンタープライズAI基盤です。Claude Code GitHub Actionで開発側を、AI Agent Hubで業務側を、それぞれエージェントとして設計することで、組織全体のAI活用が一段引き上がります。

• 開発と業務を別レイヤーで設計
  Claude Code GitHub Actionはコードに対する自動化、AI Agent Hubは業務システムへの自動化。レイヤーを分けることで、責任範囲・セキュリティ要件・運用主体を明確に切り分けられます。
  
  

• 構築基盤が違ってもAgent管理は1つに集約
  Microsoft Foundry / n8n / Copilot Studioのどれで作ったAgentでも、1つのダッシュボードで実行ログ・権限・セキュリティチェックを統合管理。シャドーAIの乱立を防ぎます。
  
  

• 使い慣れたMicrosoft環境をそのまま活用
  Teams・Excel・Outlookなど既存ツールの延長でAIエージェントが動作。新しいツールの学習コストはゼロです。
  
  

• データは100%自社テナント内で完結
  Azure Managed Applicationsとして自社テナント内で動作するため、業務データが外部に出ない設計。AIの学習対象からも完全除外できます。

AI総合研究所の専任チームが、開発側のClaude Code GitHub Action活用から業務側のエージェント基盤設計まで、組織横断のAI活用ロードマップを一貫して支援します。まずは無料の資料で、AI Agent Hubの全体像と導入ステップをご確認ください。

コード自動化の先にある業務全体のエージェント基盤

開発業務のAI化を組織全体に広げる

Claude Code GitHub ActionでPRレビューやIssue実装を自動化できる一方、業務全体のAI化には開発外の基幹システムや承認フローとの接続が欠かせません。AI Agent Hubは、TeamsからAIエージェントを呼び出し、ERP・CRMと連動して業務を自動実行するエンタープライズAI基盤です。

▶ 無料で資料をダウンロード

まとめ

Claude Code GitHub Actionは、GitHub上での開発ワークフローにClaudeを公式の形で組み込めるアクションです。本記事の論点を1行ずつ振り返ります。

• Claude Code GitHub Actionとは: PRやIssueへの @claude メンションをきっかけに、Claudeがコード分析・レビュー・実装を自動で進める公式アクション。v1.0で自動モード検出と統一インターフェースが整い、設定が大幅に簡素化された。
• できること: PRレビュー自動化・IssueからPR生成・CI失敗の自動修正・ドキュメント同期の4つが代表ユースケース。
• 料金体系: API従量とPro/Max/Team/Enterpriseサブスクから選択。2026年6月15日からAgent SDK経由の利用はサブスク別の月次クレジット枠に分離され、フルAPIレートで課金される（Enterprise seat-based Standardは対象外）。
• 導入手順: クイック（/install-github-app）と手動の2方式。GitHub App追加・APIキー登録・ワークフローファイル作成の3ステップで完結する。
• 使い方とカスタマイズ: 自然言語の @claude 指示が基本。CLAUDE.md で規約を集約し、claude_args でモデル・ターン数・ツール制御を行う。Skills/Pluginsで組織ナレッジを再利用できる。
• エンタープライズ展開: 公式アクションがAnthropic直接API・Bedrock・Vertex AI・Foundryの4経路に対応（ドキュメント例はBedrock/Vertex中心、Foundryは併用設計が一般的）。OIDC＋カスタムGitHub Appの組み合わせでセキュリティと監査を両立できる。
• 他エージェントとの比較: GitHub Copilot Coding Agentは既存Copilot契約活用に強み、Devinは高自律で高単価。Claude Code GitHub Actionは柔軟性と現実的なコストのバランス型。
• 導入判断で詰まる論点: 課金変更後のプラン選び・モデル使い分け・人間レビュー境界・ベータ版移行の4点を最初に決めると運用が安定する。

まずは1リポジトリでクイックセットアップを試し、CLAUDE.md にチーム規約を1ページ書き起こして、PRトリガーから運用に乗せていくのが現実的な第一歩です。そこから自動化範囲を広げていけば、開発ワークフローのボトルネックを段階的に解消できます。