Claude Code Action で PR 自動化｜止め時・任せ時を業務常用者が

Q: どの Claude モデル（Sonnet / Opus / Haiku）を CI で使えばいいですか？

業務での使い分けとしては、PR レビューや CI コード生成は Sonnet 4.5 を主軸、複雑なリファクタ提案は Opus 4.7、簡易な型チェック・命名チェックは Haiku がコスト×品質のバランスが取れているという感覚です。「絶対これが正解」とは申し上げず、用途・コスト・PR の規模で使い分ける運用感覚をおすすめします。詳しくは本記事の「モデル選び」のセクションをご参照ください。

Claude Code は触ったが、毎回ターミナルで手で動かすのが面倒。PR レビューを Claude に自動でやらせたいが、GitHub Actions の YAML を見ても認証まわりが分からない——AI コーディングを業務で常用している層から、ここ半年で急に増えた相談です。

ラッコキーワード実測（2026 年 5 月時点）では Claude Code Action の月間検索数 2,400 / SEO 難易度 34 / CPC $24.60——企業導入の検討層が集まる超商用ワードです。結論から言うと、「個人＋少規模チームなら Anthropic 直 API、エンタープライズなら Bedrock 経由、PR レビュー自動化は人間の最終マージを残す」の 3 つを抑えれば、最初の一歩は外しません。業務で部分的に運用してきた立場から、認証 3 系統・料金構造・MCP 統合・運用リスクまで整理します。

とりあえず最短で 1 回試したい方は、セクション 3「最小セットアップ」とセクション 7「PR レビュー自動化」から読み始めると、本日中に「最初の YAML」が動くところまで届きます。

01 — 結論：Claude Code Action は「GitHub Actions で Claude Code を動かす公式ハーネス」、3 用途に絞れば外さない

📖 この章で使う用語

Claude Code Action：GitHub Actions 上で Claude Code を動かす公式の仕組み（ハーネス）。GitHub Marketplace で配布されるパッケージ名は anthropics/claude-code-action。

GitHub Actions：GitHub の自動化機能。PR や Issue が動いたら、自動でスクリプトを走らせる。「ベルトコンベア」のイメージ。

CI/CD（Continuous Integration / Continuous Delivery：継続的インテグレーション・継続的デリバリー）：変更を頻繁に統合してテストし、本番リリースまで自動化する仕組み。「料理人が試食しながら一品ずつ仕上げて、できたものから順にお店に出す」イメージ。

PR（Pull Request：プルリクエスト）：GitHub の「変更を本流に取り込んでくださいリクエスト」。営業の「稟議書」に近い感覚。

ハーネス（harness）：エージェントを業務フローに組み込む枠組み。馬具・装具からの由来で、「自律する馬を業務の馬車につなぐ装具」のイメージ。

まず結論から書きます。Claude Code Action は 「GitHub Actions で Claude Code を動かすための、Anthropic が公式で配布しているハーネス（仕組み）」——これが、業務で部分的に運用してきた私のいちばん実用的な答えです。

3 行で覚えていただきたいのは、次の用途対応です。

PR レビュー自動化 ＝ ◎ 最も価値が出やすい主軸用途（人間の最終マージは残す）
CI コード生成・コミットメッセージ補助 ＝ ○ 部分的に効く補助用途
大規模リファクタ自動化 ＝ △ できなくはないが、まずは個人 OSS で実験する用途

「迷ったらこの 3 用途だけ覚えれば OK」一行マップです。新しい記事や YAML サンプルを見ても、「これは 3 用途のどこに住んでいる使い方か」を確かめれば、置き場所に迷わなくなります。

ここで本記事の立ち位置を最初に明示します。Claude Code Action は、私が業務で部分的に使う場面はあるが、フル運用はしていないツールです。これまでの経験から「個人 OSS リポでの動作確認 + 一部の業務リポで PR レビュー補助に組み込む」レベルで触っており、全社の CI 基盤に深く組み込んで毎日叩く運用ではありません。本記事で語れる範囲は、最小セットアップ・認証経路の選び方・料金構造の見方・PR レビュー自動化の運用作法・MCP 統合の射程・運用リスクの整理まで——「業務で部分的に使ってきた私の運用観察と、公開情報からの整理」のハイブリッドです。

「迷ったらここから」3 ステップで、最初の一歩を案内します。

anthropics/claude-code-action を GitHub Marketplace で確認（公式 Action）
Anthropic API キーを取得し、GitHub Secrets に登録
最小 workflow.yml（10〜20 行）を .github/workflows/ に置き、テスト PR で動作確認

最後に重要なメタ宣言を 1 つ。本記事では、「絶対に Claude Code Action が安全」「絶対にコストが膨らまない」「絶対に PR レビューを任せきれる」とは申し上げません。コードベース・組織規模・既存 CI 文化で振れ幅が大きい領域です。本記事の各セクションで述べる判断軸は「2026 年 5 月時点・私の業務観察と公開情報からの整理」であり、最終判断は社内の情シス・法務・コンプライアンス部門、必要に応じて専門の弁護士の方へご相談いただくのが筋です。

なお、本記事は親ハブ記事 AI コーディングとはの「ハーネス」概念の独立深掘りスポークとして位置づけられます。AI コーディング全体地図は親ハブ、本記事は「Claude Code を CI に組み込む専門深掘り」という関係です。

02 — Claude Code Action とは——GitHub Marketplace 公式 Action と「ハーネス」概念

📖 この章で使う用語

Action（GitHub Marketplace 上のパッケージ）：GitHub Actions のための再利用可能な部品。anthropics/claude-code-action@v1 のように呼び出す。「料理レシピを共有して使い回す」イメージ。

公式リポジトリ：Anthropic が運営する正規の配布元。github.com/anthropics/claude-code-action。

CLI（Command Line Interface：コマンドラインインターフェース）：黒い画面（ターミナル）にコマンドを入力して操作する形式。「真っ黒な怖い画面」と営業時代の私は思っていました。

ここから、Claude Code Action の 「正体」「Claude 製品群との位置関係」「ハーネスという概念」 を順に整理します。

02-1. Anthropic 公式が配布する GitHub Action パッケージ

Claude Code Action の正体を 1 行で書くと、Anthropic が公式に配布している GitHub Actions 用のパッケージで、PR や Issue のイベントをきっかけに Claude Code を CI 上で起動して、レビューコメント・コード提案・コミットメッセージ叩き台を生成する仕組みです。GitHub Marketplace から anthropics/claude-code-action というパッケージ名で参照し、workflow.yml に 1 行 uses: anthropics/claude-code-action@v1 と書けば呼び出せます（公式仕様の最新版は GitHub Marketplace と公式 README で必ず事前にご確認ください、本記事末尾の「出典」セクションを参照）。

営業時代のたとえで書くと、これは 「自社で書いた提案書テンプレを、社内のテンプレ集に登録して全営業が使えるようにする」 感覚に近いです。一度書いた workflow.yml をリポジトリの .github/workflows/ に置いておけば、PR が立つたびに自動で同じ仕事をしてくれる。営業時代に「毎回ゼロから提案書を書かない」ためにテンプレを整備していた感覚と、CI に Action を組み込む感覚はそっくりです。

02-2. Claude.ai / Claude Code CLI / Claude Code Action——3 経路の俯瞰

Claude を業務で使う経路は、現時点で大きく 3 つあります。本記事で扱う Claude Code Action の位置づけを、3 経路の俯瞰で整理します。

Claude.ai（Web） ＝ブラウザのチャット画面で Claude と対話する経路。詳しくは Claude 使い方を参照
Claude Code（CLI） ＝個人マシンのターミナルから claude コマンドで Claude にフォルダ単位の作業を依頼する経路。詳しくは Claude Code 使い方を参照
Claude Code Action（CI） ＝ GitHub Actions の中で Claude Code を起動して PR レビューやコード生成を自動化する経路（本記事の主題）

「個人で触る → 個人 PC でフォルダ単位で動かす → CI で自動化する」という段階に対応しています。本記事を読む読者の方は、おそらく Claude.ai と Claude Code CLI までは触ったことがある方が多いと思います。Claude Code Action はその「次の一歩」——個人マシンで動かしていた Claude Code を、リポジトリの自動化フローに乗せる段階の道具です。

02-3. 「ハーネス」とは——エージェントを業務フローにつなぐ装具

AI コーディングとはでも触れた 「ハーネス（harness）」 という概念を、本記事ではもう一歩深掘りします。馬具・装具を意味する英単語の harness が、AI コーディング界では「自律的に動くエージェント（馬）を、業務フロー（馬車）につなぐ装具」の意味で使われ始めています。

Claude Code Action は、まさにこの 「Claude Code というエージェントを、GitHub の PR レビュー / CI ワークフローという馬車につなぐハーネス」 に当たります。馬（エージェント）が自律的に走る能力を持っていても、馬車（業務フロー）に接続する装具がなければ、業務には組み込めない。Claude Code Action は、その接続装具を Anthropic 公式が提供してくれている、と理解すると掴みやすいです。

GitHub Actions が初めての方のために最小説明を添えると、GitHub Actions は 「リポジトリで何かが起きたら（PR が立った / コードが push された / Issue がコメントされた）、自動でスクリプトを走らせる仕組み」——ベルトコンベアのイメージです。Claude Code Action は、このベルトコンベアの 1 つの工程に Claude Code を組み込む部品、という関係です。

03 — 最小セットアップ——5 ステップで PR コメント自動生成まで届く

📖 この章で使う用語

Secrets（GitHub の機密情報管理機能）：API キーなどの秘密情報をリポジトリ設定に安全に保管する場所。漏れたら大事なので、ログに出さない仕組み付き。「金庫」のイメージ。

workflow.yml：GitHub Actions の動作を定義する YAML ファイル。.github/workflows/ に置く。

YAML（ヤムル）：設定ファイルの書式の 1 つ。インデント（字下げ）が文法を決める繊細な書式。「目次のような階層構造を字下げで表すメモ」のイメージ。

ここから、Claude Code Action を 「個人 OSS リポで最短で動かす」 ための 5 ステップを書きます。業務で部分的に使ってきた私の実感としては、最小サンプルは「動く形」を確認するためのもので、本番運用にはチーム合意・コストガード・人間レビューが別途必要——という温度感を最初にお伝えしておきます（本記事でフル運用の手順を書ききるつもりはありません）。

03-1. 最小セットアップ 5 ステップ

最小セットアップの全体像を 5 ステップで書きます。

Anthropic API キーを取得（claude-code-hajimekata のセットアップ手順を参照、console.anthropic.com から発行）
GitHub リポジトリの Secrets に登録（リポジトリの Settings → Secrets and variables → Actions → New repository secret、Name: ANTHROPIC_API_KEY、Value: 取得したキー）
.github/workflows/claude-pr-review.yml を新規作成（リポジトリのルートに .github/workflows/ フォルダがなければ作る）
最小 workflow.yml を貼り付け（次の 03-2 のサンプル）
テスト PR を立てて動作確認（小さな typo 修正 PR で十分、Actions タブでログを追う）

ここまでで、PR が立つたびに Claude がレビューコメントを自動生成する最小構成が動きます。所要時間は初回 30 分〜1 時間（API キー取得・Secrets 登録・YAML 貼り付け・テスト PR の試走を含む）が現実的です。

03-2. 最小 workflow.yml（PR レビュー版）

最小サンプルを 1 つ載せます。10〜20 行で動く粒度です。

# .github/workflows/claude-pr-review.yml
# PR が立った／更新されたら Claude にレビューコメントを書いてもらう最小構成
name: Claude PR Review

on:
  pull_request:
    types: [opened, synchronize]

permissions:
  contents: read
  pull-requests: write
  issues: write

jobs:
  review:
    runs-on: ubuntu-latest
    # Draft PR は除外（コスト爆発を避ける、本記事の「リスクと注意点」セクション参照）
    if: github.event.pull_request.draft == false
    steps:
      - uses: actions/checkout@v4
      - name: Run Claude Code Action
        uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          # 人間の最終マージは前提として残す運用です

YAML のインデント（字下げ）が崩れると動かないので、貼り付けたあとに VS Code の GitHub Actions 拡張 で構文チェックしておくと、初回の躓きを避けられます。

03-3. 動作確認のコツ

最小サンプルが動いたか確認するコツは 3 つです。

Actions タブを見る ：リポジトリ上部の「Actions」タブで、ワークフローの実行状況がリアルタイムで追えます
失敗時のログを最初から最後まで読む：エラーは大抵 Secrets 未登録（ANTHROPIC_API_KEY is not set）か YAML インデント崩れの 2 つ
小さな PR で試す：いきなり大きな差分の PR で試すとコストも消費するし観点も追いきれません。typo 修正レベルの小さな PR で「動く形」を確認するのが安全です

営業時代のたとえで書くと、新しい提案書テンプレを社内で使い始めるとき、まずは小さな案件で 1 度試して、テンプレの粗を直してから大型案件に投入する——その作法と同じです。Claude Code Action も同じく、まず小さな PR で動作を確かめてから、本格的な業務リポに広げていくのが現実的だと思います。

04 — 認証経路 3 系統——Anthropic 直 API / AWS Bedrock / Google Vertex AI の選び方

📖 この章で使う用語

IAM（Identity and Access Management）：AWS の「誰が何にアクセスできるか」の権限管理機能。「会社の入退室カードと部屋ごとの権限」のイメージ。

VPC（Virtual Private Cloud）：AWS 内の「自社専用ネットワーク区画」。インターネットから隔離できる。「ビル内に作る専用フロア」のイメージ。

AssumeRole：IAM の機能の 1 つで、「ある立場（Role）を一時的に借りる」動作。「他部署の決裁権限を一時的に借りる」感覚。

Workload Identity Federation：Google Cloud の機能で、外部システム（GitHub Actions 等）から GCP リソースに認証なしでアクセスできる仕組み。

ここから、Claude Code Action を CI から呼び出すときの 「認証経路 3 系統」 を整理します。SERP 上位の記事は、ほとんどが直 API の単一系統しか扱っていません。業務で部分的に運用してきた経験から、認証経路の選び方が CI 統合の最初の分かれ目になることが分かったので、本記事では 3 系統を横並びで比較します。

04-1. Anthropic 直 API（個人〜少規模チーム向け、私は業務でこちらを常用）

最もシンプルな認証経路です。console.anthropic.com で API キーを発行し、GitHub Secrets に ANTHROPIC_API_KEY として登録するだけ。業務本番運用のメイン経路として私が常用しているのはこちらです。詳しくは Claude Code 始め方と Claude 料金プランを合わせてご参照ください。

# 直 API 認証のみ（最小構成）
- name: Run Claude Code Action
  uses: anthropics/claude-code-action@v1
  with:
    anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}

向いているのは、個人 OSS / 5〜10 人スタートアップ / 小規模チームの CI です。API キー 1 本で 5 分で始められます。「絶対この経路がベスト」とは申し上げません——組織要件（金融・医療・公共のコンプラ）が出てきたら、04-2 の Bedrock 経由に切り替えていく流れになります。

04-2. AWS Bedrock 経由（エンタープライズ要件向け、私は個人検証＋選定整理レベル）

AWS Bedrock 経由で Claude Code Action を動かす経路です。私の業務では Bedrock 経由 Claude は部分使用（概念・選定整理レベル）——直 API との違い、IAM 連携 / VPC 内通信 / 監査ログのメリット、料金体系の見方までを「概念・選定の整理レベル」で語れますが、Claude Code Action × Bedrock の本番フル運用の経験はありません。詳しくは AWS Bedrock を合わせてご参照ください。

# AWS Bedrock 経由（IAM Role Assume + 環境変数）
permissions:
  id-token: write  # OIDC で AWS にログインするため
  contents: read
  pull-requests: write

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsBedrockRole
          aws-region: us-east-1
      - name: Run Claude Code Action via Bedrock
        uses: anthropics/claude-code-action@v1
        with:
          # Bedrock 経由モード（公式仕様の最新版を必ず確認）
          use_bedrock: "true"
          model: "anthropic.claude-sonnet-4-5-20250929-v1:0"

向いているのは、金融・医療・公共・大企業のように 「コードを Anthropic 直 API に送ることを社内コンプラが許容しない」「IAM 統合・VPC 内通信・監査ログを既存 AWS 基盤に集約したい」 組織要件が出てきた段階です。AWS の既存契約・IAM 認証情報・CloudTrail / CloudWatch の監査基盤がそのまま継承できるので、社内稟議が通りやすいというメリットがあります。

04-3. Google Vertex AI 経由（GCP 系スタック向け、公開情報からの整理）

Google Cloud の Vertex AI 経由で Claude モデルを呼び出す経路です。私の業務では Vertex AI 経由 Claude は触っておらず、ここは公開情報からの整理にとどめます。Anthropic 公式ドキュメントによると、Vertex AI 経由でも Claude モデルが利用可能で、認証は Google Cloud の Workload Identity Federation を使うのが推奨されています（公式仕様の最新版は本記事末尾の「出典」セクションを参照）。

向いているのは、既存のスタックが Google Cloud / Workspace 中心の組織です。直 API / Bedrock / Vertex AI のどれを選ぶかは、「既存の社内インフラ契約がどこに偏っているか」 で決まることが多い、というのが業界の標準的な整理だと思います。

3 経路の比較を 5 軸で並べると、次のようになります。

軸	Anthropic 直 API	AWS Bedrock 経由	Google Vertex AI 経由
認証方式	API キー（Secrets）	IAM Role + OIDC	Workload Identity Federation
IAM 連携	×	◎（既存 AWS IAM 継承）	◎（GCP IAM 継承）
VPC 内通信	×	◎（PrivateLink）	◎（VPC Service Controls）
課金経路	Anthropic 直契約	AWS 請求書に統合	GCP 請求書に統合
監査ログ	自前で整備	CloudTrail / CloudWatch	Cloud Audit Logs

「絶対この経路が正解」とは申し上げません。本記事で書ける温度感としては、(1) 個人〜少規模チームなら直 API、(2) AWS 系のエンタープライズ要件が出たら Bedrock 経由、(3) GCP 系のスタックなら Vertex AI 経由——という選び方が、公開情報と私の業務観察を組み合わせた現実的な目安です。

05 — 料金構造——API トークン課金 vs Max プラン権利の整理

📖 この章で使う用語

トークン（token）：LLM が文章を処理する最小単位。「ざっくり、日本語 1 文字 ≒ 1〜2 トークン」と覚えれば OK。タクシーのメーターのように、話せば話すほど課金が積まれる。

従量課金：使った分だけ請求される料金体系。電気料金や水道料金と同じ。

サブスク（subscription）：月額固定で使い放題（ただし上限あり）。Netflix のような形式。

ここで、Claude Code Action を CI から呼ぶときの 「料金構造の正しい理解」 を整理します。サジェスト 5 位「max plan」と 8 位「料金」を独占吸収する位置づけの章です。

05-1. 重要な誤解の正解——Max プランは CI から原則使えません

最初に、業務で部分的に運用してきた中で 「読者の方が最も誤解しやすい論点」 を 1 つ書きます。

Claude Max プランの権利は、GitHub Actions（CI）からは原則として使えません。Max プランは Claude.ai（Web）と Claude Code CLI（個人マシン）でのサブスク権利で、CI/CD 環境から呼ぶ場合は、別途 Anthropic API キーを発行して、API のトークン従量課金が走る のが公式仕様です（2026-05-19 取得、本記事末尾の「出典」セクションを参照）。

「Max プラン課金しているから、CI からも使い放題」と誤解した状態で導入すると、API 課金が別請求で乗ってきて、月末の請求書を見て驚く——という事態になりかねません。これは Claude 料金プランで書いた「Claude.ai サブスク（Pro/Max）と Anthropic API は別請求」という構造の応用です。

05-2. 料金体系の全体像

整理すると、Claude を業務で使う料金経路は次の通りです。

Claude.ai Pro / Max プラン：Claude.ai（Web）と Claude Code CLI（個人マシン）でのサブスク権利。月額固定（2026/5 時点で Pro $20 / Max $100 〜、公式料金ページで必ず最新確認）
Anthropic API（直）：API キー経由のトークン従量課金。CI から呼ぶ唯一の直契約経路
AWS Bedrock 経由：Anthropic API のトークン従量課金 + AWS 経由の請求集約（料金は概ね同等水準、公式料金ページで必ず最新確認）
Google Vertex AI 経由：同じく従量課金 + GCP 経由の請求集約

CI で Claude Code Action を動かすときは、「サブスクとは別の請求経路（API）が走っている」 という構造を、最初に頭に入れておくのが安全です。

05-3. コスト感の目安と、コスト爆発を避ける 3 つの運用ルール

PR 1 件を Claude にレビューさせた場合のコスト感は、PR の規模・選んだモデル・出力の長さ で振れます。2026/5 時点の Anthropic 公式料金ページの数字をベースに、業務での部分運用の感覚を組み合わせると、Sonnet 4.5 で 1 PR あたり数十円〜数百円のレンジに収まることが多い、というのが目安です（厳密な数字は PR の差分量で大きく変わるので、最新の料金は anthropic.com/pricing で必ず事前にご確認ください）。

問題は、この目安が PR の規模・本数・運用ルールで簡単に 10 倍 100 倍に膨らむ ことです。コスト爆発を避ける運用ルールを 3 つ書きます。

Draft PR を除外する：if: github.event.pull_request.draft == false で、まだ書き途中の Draft PR をレビュー対象から外す（最小サンプルにも入れた条件）
月次予算アラートを仕込む：Anthropic のダッシュボード / AWS Budgets / GCP Budgets で、月額 $50 / $100 / $500 などの段階で警告メールが飛ぶように設定
1 日のリクエスト上限を仕込む：ワークフロー内で 1 日のレビュー回数をカウントし、上限を超えたら skip する（簡易には GitHub Actions の concurrency で同時実行を制限）

「絶対にコストが膨らまない」とは申し上げません。PR 量・組織規模・運用作法で振れ幅が大きい領域です。最初の 1 ヶ月は 「個人 OSS リポ → サンドボックスリポ」 で慣らしてから業務リポに広げる、という段階運用をおすすめします。詳しくはセクション 14「学習・導入の最初の一歩」を参照してください。

06 — モデル選び——Sonnet 4.5 / Opus 4.7 / Haiku を CI でどう使い分けるか

📖 この章で使う用語

モデル ID（Model ID）：API で呼び出すときの「このモデルを使ってください」という識別子。例：claude-sonnet-4-5-20250929。

コンテキスト窓：LLM が一度に読める文章の最大長。長い PR を一度に読ませたいときに効く。

ここで、CI から呼ぶ Claude のモデル選びを整理します。サジェスト 6 位「model」を吸収する位置づけの章です。詳しい Opus / Sonnet / Haiku の違いは Claude Opus と Claude 料金プランで扱っていますので、本章は 「CI 用途別の使い分け」 に絞ります。

06-1. 3 モデルの CI 用途別マップ

業務での使い分けとして、私が現時点で使ってきた感覚を表にまとめます。

モデル	CI 用途	コスト感	私の使用感
Sonnet 4.5	PR レビュー / 軽めのコード生成 / コミットメッセージ叩き台	中（バランス型）	業務で常用、Claude Code Action の主軸モデル
Opus 4.7	複雑なリファクタ提案 / 長文 PR の全体俯瞰レビュー / 設計レビュー	高（最上位）	Claude Code（個人マシン）で常用、CI ではコスト次第で部分的に利用
Haiku	軽量な型チェック / 命名チェック / 単純な typo 指摘	低（最廉価）	コスト最適化のシーンで併用

「絶対 Sonnet 4.5 が正解」とは申し上げません。PR の規模・観点の深さ・予算で使い分けが変わります。私の業務感覚での出発点は 「まず Sonnet 4.5 を主軸で組み、複雑な PR だけ Opus 4.7 に切り替える条件分岐を後から仕込む」 ——この順序が、コスト×品質のバランスを取りやすいと感じています。

06-2. workflow.yml でのモデル指定

workflow.yml でモデルを明示的に指定するサンプルです（モデル ID は公式の最新版を必ず確認してください、本記事末尾の「出典」セクションを参照）。

# モデルを明示指定するサンプル
- name: Run Claude Code Action
  uses: anthropics/claude-code-action@v1
  with:
    anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
    # Sonnet 4.5 を主軸として指定
    model: "claude-sonnet-4-5-20250929"
    # 出力トークン上限を明示（コスト爆発を避ける、本記事の「課金構造」セクション参照）
    max_tokens: 4096

PR の規模で動的にモデルを切り替えたい場合は、ワークフロー内で github.event.pull_request.changed_files の数を見て、閾値超えなら Opus、それ以外は Sonnet、というように分岐させる方法もあります（公開情報の整理の範囲、私の業務では一部のリポで条件分岐を入れたことがあります）。

07 — PR レビュー自動化——最重要 UC、人間の最終マージを残す前提で 5 シーン

📖 この章で使う用語

diff（ディフ）：ファイルの「変更前」と「変更後」の差分。GitHub では緑（追加）と赤（削除）で色分けされる。

OWASP Top 10：Web アプリのセキュリティリスクの代表 10 種類をまとめた、OWASP（Open Web Application Security Project）の標準的なリスト。

ここから、本記事のいちばん厚い章です。サジェスト 3 位「レビュー」と 9 位「review」を独占吸収する位置づけで、PR レビュー自動化の 5 シーン を業務観察ベースで整理します。詳しいプロンプト設計は AI コードレビューで扱っていますので、本章は 「Claude Code Action としての CI 組込み観点」 に絞ります。

07-1. PR レビュー自動化の温度感宣言

最初に立ち位置を明示します。Claude Code Action を業務で部分的に使ってきた中で、いちばん価値が出やすいと実感しているのが PR レビュー自動化です。一方、Claude にレビューを任せきって人間レビューを省ける、とは絶対に申し上げません——マージ判断 / 本番デプロイ / 機密処理 / 契約変更の 4 つは、人間が責任を持って判断する領域です。

07-2. PR レビュー自動化の 5 シーン

業務観察と公開情報の整理から、PR レビュー自動化が価値を出しやすい 5 シーンを並べます。

PR 開始時のレビューコメント自動生成（◎ 業務で部分的に使うシナリオ）
PR 更新時の差分追加レビュー（○ 業務で部分的に使うシナリオ）
テスト失敗時の原因解析の叩き台投稿（○ 業務で部分的に使うシナリオ）
セキュリティ観点（OWASP Top 10）の自動チェック（△ 個人 OSS で検証レベル、本番運用は別途人間レビュー必須）
ドキュメント差分のチェック（△ 個人 OSS で検証レベル）

07-3. PR 開始時のレビューコメント自動生成（5 シーンのうち代表サンプル）

最重要シーンの 1 つ「PR 開始時のレビューコメント自動生成」のサンプル workflow.yml を載せます。

# .github/workflows/claude-pr-review.yml
# PR が立ったら Claude にレビューコメントの叩き台を書いてもらう
name: Claude PR Review (Initial)

on:
  pull_request:
    types: [opened]

permissions:
  contents: read
  pull-requests: write

jobs:
  review:
    runs-on: ubuntu-latest
    if: github.event.pull_request.draft == false
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0  # 差分計算のため全履歴を取得
      - name: Run Claude PR Review
        uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          model: "claude-sonnet-4-5-20250929"
          prompt: |
            このリポジトリの PR 差分を、以下の観点で読んでください：
            1. 型・命名・論理・セキュリティ・可読性
            2. 業務ドメイン整合は人間レビュー前提として一旦スキップ
            出力フォーマット：高 / 中 / 低 の 3 段階で 10 件以内
            最後に必ず「人間の最終マージが必要です」と添えてください。

07-4. PR 更新時の差分追加レビュー

PR が synchronize（push で更新）されたタイミングで、差分部分のみ追加レビューさせるパターンです。コストを抑えながら、PR が成熟していく過程で逐次レビューが入る運用が組めます。

on:
  pull_request:
    types: [synchronize]  # PR 更新時のみ

07-5. セキュリティ観点（OWASP Top 10）の自動チェック

OWASP Top 10 の観点を Claude に渡してチェックさせるパターンも実現できますが、本番運用ではセキュリティ専門家による人間レビューが別途必須 という前提を絶対に外さないでください。AI のセキュリティ自動チェックは「叩き台」「気付きのきっかけ」までであって、責任を負った最終判定にはなりません。

07-6. 人間判断ゾーン 4 つの再確認

AI コーディングとはの「ハーネスとは」セクションで書いた 「人間判断ゾーン 4 つ」 を、本章でも改めて確認します：

マージ判断：Claude のレビューを通過しても、最終的に main にマージするのは人間
本番デプロイ：本番環境への適用は人間が責任を負う
機密処理：機密データを扱うコードは、人間がコンプラ観点で必ず通す
契約変更：API 仕様変更・ライセンス変更・SLA 影響を持つ変更は、人間の最終承認が必須

「絶対に PR レビューを Claude に任せきって人間レビューを省ける」とは申し上げません——これは本記事の中でも最も強くお伝えしたいメタ宣言です。

08 — コミットメッセージ自動生成・Issue 起票補助——PR レビュー以外の業務 UC

📖 この章で使う用語

コミット（commit）：変更を「ここで一区切り」と記録する操作。営業の日報の「1 日分の振り返り」に近い感覚。

PR レビュー自動化以外の業務 UC を、簡潔に整理します。詳しい射程は AI コーディングの「自動化（PR / コミット / CI）」セクションで扱っていますので、本章は 「Claude Code Action としての CI 組込み観点」 に絞ります。

08-1. コミットメッセージ・PR 説明文の自動生成

PR を立てたタイミングで、Claude に diff から「PR 説明文の叩き台」「コミットメッセージの叩き台」を生成させるパターンです。

# .github/workflows/claude-pr-description.yml
# PR が立ったときに、diff から PR 説明文の叩き台を生成
name: Claude PR Description

on:
  pull_request:
    types: [opened]

permissions:
  contents: read
  pull-requests: write

jobs:
  describe:
    runs-on: ubuntu-latest
    if: github.event.pull_request.draft == false
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Generate PR description
        uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            この PR の diff から、以下を含む説明文の叩き台を作ってください：
            - 変更の意図（1 段落）
            - 主な変更点（箇条書き 5 件以内）
            - 動作確認手順（箇条書き 3 件以内）
            最後に「人間が内容を確認・修正してください」と添えてください。

08-2. Issue 起票補助・リファクタ提案・ドキュメント自動更新

その他の業務 UC として、次のようなパターンが考えられます。

Issue 起票補助：バグレポートテンプレを Claude に整形させる
リファクタ提案：テストが落ちたコミットで、修正案を PR コメントで提案させる（マージは人間）
ドキュメント自動更新：API スキーマ変更時に、README の該当箇所の更新案を提案させる

これらはすべて 「Claude が叩き台を出し、人間が確認・修正・最終承認する」 という分業前提です。CI 自動化の魅力に流されて「Claude が PR を立てて Claude が承認する」までやらせるのは、絶対に避けてください（本記事セクション 11「リスクと注意点」も参照）。

09 — MCP サーバー統合——CI から社内ナレッジ・DB に接続する最新動向

📖 この章で使う用語

MCP（Model Context Protocol：モデルコンテキストプロトコル）：LLM が外部リソース（GitHub / Postgres / Slack 等）を統一規格で参照できるように、Anthropic が 2024 年に公開したプロトコル。「USB 規格」のような共通インターフェース。

MCP サーバー：MCP の規格に準拠した、外部リソースを LLM に提供する側のプログラム。

RAG（Retrieval-Augmented Generation：検索拡張生成）：LLM に最新情報や社内情報を「その場で検索して」答えさせる仕組み。本屋の「司書」に例えるパターン（詳しくは RAG とはを参照）。

ここで、サジェスト 7 位「mcp」を吸収する独立章です。SERP がほぼ触れない最新領域 ——Claude Code Action と MCP サーバー統合の組み合わせを整理します。

09-1. MCP の業務での立ち位置

MCP（Model Context Protocol）は、Anthropic が 2024 年に公開した「LLM が外部リソースを統一規格で参照するためのプロトコル」です。私の業務では、Cursor MCP（Cursor からの MCP サーバー設定）を業務でセットアップして常用しており、ここは語れる範囲です。詳しくは Cursor 使い方の MCP セクションをご参照ください。

一方、Claude Code Action × MCP サーバー統合（CI から MCP を呼ぶ運用）は、私自身は個人検証＋公開情報からの整理レベル——業務本番運用ではない、というのを最初に明示しておきます。本章で語れるのは、Cursor MCP 業務常用の延長で見えてくる「CI × MCP の射程」までです。

09-2. CI × MCP の業務 UC（個人検証＋公開情報の整理）

Claude Code Action から MCP サーバーを呼ぶことで、CI 上でも以下のような統合が原理的に可能です（公開情報からの整理）。

社内ナレッジ MCP サーバーから RAG 検索 → PR レビューに反映：社内ドキュメントを MCP サーバーで提供しておき、PR レビュー時に「この変更は社内ガイドラインに整合しているか」を聞ける
社内 DB スキーマ MCP サーバーから整合性チェック：DB スキーマ変更を含む PR で、既存スキーマとの整合性を Claude に確認させる
GitHub MCP サーバー経由でリポジトリ横断レビュー：複数リポにまたがる変更を、GitHub MCP サーバー経由で Claude に俯瞰させる

09-3. MCP 統合の最小サンプル（公開情報からの整理）

公開情報をベースにした最小サンプルを 1 つ載せます（公式仕様の最新版を必ず確認してください）。

# .github/workflows/claude-pr-review-with-mcp.yml
# MCP サーバーを CI 上で動かして Claude に渡す最小構成
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Claude with MCP
        uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          # MCP 設定ファイルを渡す（公式仕様の最新版を必ず確認）
          mcp_config: .claude/mcp-config.json

// .claude/mcp-config.json（公開情報からの整理サンプル）
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "${{ secrets.GITHUB_TOKEN }}" }
    }
  }
}

「絶対この設定で動きます」とは申し上げません——MCP の仕様は急速に進化しており、公式仕様の最新版を必ず anthropic.com の MCP ドキュメントでご確認ください。本章で書いている範囲は、Cursor MCP の業務常用観察 + Anthropic 公式情報の整理ハイブリッドです。

詳しい AI エージェント構築は AIエージェントの作り方、MCP の原典は Cursor MCP 業務常用の Cursor 使い方もあわせてご参照ください。

10 — GitLab CI / Jenkins / 自前実装——GitHub 以外の CI/CD で Claude Code を動かす

📖 この章で使う用語

GitLab CI：GitLab が提供する CI/CD 機能。GitHub Actions の GitLab 版。

Jenkins：オープンソースの CI/CD ツール。自前でサーバーに立てて使う。

サジェスト 4 位「gitlab」を吸収する章です。最初に立ち位置を明示します。GitLab CI / Jenkins / CircleCI は私の業務利用なしの領域です。本章は公開情報からの整理レベルにとどめます（profile §2-2 に GitLab 業務利用の記載がないため、創作を避けて整理する位置づけ）。

10-1. Anthropic が公式 Action として配布しているのは GitHub のみ（2026-05-19 時点）

最初に押さえておきたい事実です。Anthropic が公式に GitHub Marketplace 経由で配布しているのは anthropics/claude-code-action で、これは GitHub Actions 専用 です（2026-05-19 時点、本記事末尾の「出典」セクションを参照）。GitLab / Jenkins / CircleCI で Claude Code を動かす場合は、自前で claude CLI を呼び出すハーネス実装 が必要になります。

10-2. GitLab CI で Claude Code を動かす最小サンプル（公開情報からの整理）

GitLab CI で Claude Code を呼び出す自前ハーネスの最小サンプルを、公開情報からの整理として 1 つ載せます（業務での運用経験はなく、公式 README と GitLab CI 公式ドキュメントからの組み立てです）。

# .gitlab-ci.yml（公開情報からの整理サンプル、業務運用経験なし）
claude_pr_review:
  image: node:20
  stage: review
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  variables:
    ANTHROPIC_API_KEY: $ANTHROPIC_API_KEY  # GitLab CI/CD Variables で設定
  script:
    - npm install -g @anthropic-ai/claude-code  # 公式 CLI のインストール（最新の配布チャネルを確認）
    - claude review --diff "$CI_MERGE_REQUEST_TITLE"

GitLab CI / Jenkins / CircleCI で Claude Code を組み込む場合、Anthropic 公式 Action のような統合の薄さが得られないので、「自前ハーネスを書く工数 vs GitHub に CI を寄せる選択」 を最初に天秤にかける現実的な選択肢になります。

「絶対 GitLab CI でも同じ運用が再現できる」とは申し上げません——公式サポートの厚さの差が、運用負荷に直接効いてきます。GitHub Actions 以外の CI/CD で Claude Code を動かす検討に入る場合は、Anthropic 公式の最新ドキュメントと、各 CI/CD プラットフォームのコミュニティ情報を最新の状態でご確認ください。

11 — リスクと注意点——無限ループ／コスト爆発／Secrets 漏れ／社内コード機密の三段安全網

📖 この章で使う用語

rate limit（レートリミット）：API の「1 分間／1 時間あたりの呼び出し上限」。超えるとエラーで弾かれる。

concurrency（コンカレンシー）：GitHub Actions の「同じグループのジョブを 1 つだけ動かす」設定。重複実行を防ぐ。

ここで、SERP 上位の記事がほぼ触れない運用リスク を独立章で扱います。本記事の差別化軸の 1 つです。

11-1. 無限ループリスク

最も初歩的だが、最も多い事故です。Claude が PR にコミットを追加 → Action が synchronize イベントで再起動 → Claude がまたコミット → 無限ループ——という現象が起きます。対策は次の 2 つの組み合わせです。

jobs:
  review:
    if: github.actor != 'github-actions[bot]' && github.actor != 'claude-bot'
    concurrency:
      group: claude-review-${{ github.event.pull_request.number }}
      cancel-in-progress: true

if: で bot 自身のイベントを除外し、concurrency で同じ PR への重複実行を 1 件に制限します。

11-2. コスト爆発リスク

セクション 5「料金構造」と連動するリスクです。Draft PR / 大規模 PR / fork PR / Dependabot PR をすべてレビューに走らせると、月額が想定の 10 倍 100 倍に膨らみます。対策は次の通り。

Draft PR を除外（最小サンプルにも入れた条件）
fork PR を除外（外部からの PR で意図せずキーが消費されるのを防ぐ、if: github.event.pull_request.head.repo.full_name == github.repository）
Dependabot / Renovate PR を除外（依存更新の PR は AI レビュー不要なケースが多い）
月次予算アラートを Anthropic ダッシュボード / AWS Budgets / GCP Budgets で設定

11-3. Secrets 漏れリスク

API キー（ANTHROPIC_API_KEY）を、誤ってログ出力 / PR コメントに含めてしまうリスクです。対策は次の通り。

add-mask で値をマスキング（echo "::add-mask::$VALUE" で出力時に伏字に変える）
PR テンプレートで Secrets を貼らないルールを明文化
公開リポでは fork PR からの Secrets アクセスを禁止（GitHub のデフォルト挙動）

11-4. 社内コード機密リスク（最終判断は法務委ね）

プライベートリポの社内コードを Claude（Anthropic API）に送信している、という事実を、情シス・コンプラ・法務に必ず事前確認してください。本記事では「絶対大丈夫」とは申し上げません——AWS Bedrock 経由や Google Vertex AI 経由を選ぶ、または社内ガイドラインで「機密ファイル・個人情報・社外秘ロジックは入力禁止」を明文化する、といった対応が現実的です。詳しくは AWS Bedrock を合わせてご参照ください。

11-5. AI レビュー鵜呑みリスク

セクション 7 で書いた通り、「Claude のレビューを通したから、人間レビューを省略してマージする」のは絶対に避けてください。Claude のレビューは「人間レビューの叩き台」までで、責任を持って判断するのは人間です。

メタ宣言を改めて 1 つ。「絶対に Claude Code Action が安全」「絶対にコストが膨らまない」「絶対に PR レビューが完璧」とは申し上げません。最終判断は社内の情シス・法務・コンプライアンス部門、必要に応じて専門の弁護士の方へご相談ください。

12 — Claude Code Action を、エンジニアでない人がどう関わるか（非エンジニア UC 5 本）

📖 この章で使う用語

GitHub アカウント：GitHub にログインして使う個人 ID。無料で作れて、PR や Issue を立てられる。「Gmail のアカウント」と同じ感覚。

ここから、Claude Code Action を非エンジニアの方がどう関わるか を 5 シーンで整理します。GitHub Actions の YAML を直接書く必要はなく、「すでにエンジニアが用意したリポジトリで PR / Issue を立てる側」の関わり方が中心になります。

12-1. 営業職：Issue 起票補助で「お客様要望をエンジニアに渡す形式」が自動整形

Before：お客様要望をテキストで受け取り、自分でフォーマット整形してエンジニアに渡す。1 件 30 分かかる。 After：GitHub Issue にテキストを貼り付けて立てると、Claude Code Action が「要望サマリ / 影響範囲想定 / 質問項目」を整形して自動でコメント。整形時間が 5 分以内に。 所要時間：初回セットアップはエンジニア側、営業職の方は GitHub アカウント作成（5 分）と Issue 起票の慣れ（30 分）から始められます。 最初の壁：GitHub アカウント作成 + Markdown 記法に少し慣れる必要があります。営業時代の私は、Markdown を「箇条書きの作法を統一する道具」と理解した瞬間から心理障壁が下がりました。

12-2. 事務職：社内ドキュメント PR で typo / 用語ゆれを Claude が指摘

Before：社内ドキュメントを自分で読み返して typo / 用語ゆれを発見する。読み返し作業に集中力が削られる。 After：社内ドキュメントを GitHub で管理し、変更時に PR を立てると Claude Code Action が「typo / 用語ゆれ / 文体崩れ」を自動指摘。AI を「第一読者」として、人間は「最終確認」に集中。 所要時間：エンジニアと協業して初期セットアップ後、事務職の方の運用は PR を立てるだけです。 最初の壁：「ドキュメントを GitHub で管理する」文化への慣れが必要。最初は Word / Google Docs と並走する運用から始めるのが現実的です。

12-3. 個人事業主：自分用業務マニュアル（Markdown 管理）に Claude が文体統一を提案

Before：個人で業務マニュアルを書き溜めるが、書いた時期で文体・用語がバラバラになる。 After：個人 GitHub リポで Markdown 管理し、Claude Code Action に「文体統一・用語統一」の観点で叩き台を出させる。 所要時間：初回セットアップは個人 OSS 版なら 1 時間以内、運用は週次 30 分程度。 最初の壁：GitHub と Markdown の最低限の作法。最初の 1 リポを立てるところがいちばんの心理障壁ですが、超えてしまえば「個人用テンプレ集の効率化」に直結します。

12-4. 副業ライター：取材原稿の GitHub 管理＋PR で AI に事実確認

Before：取材原稿を Word / Google Docs で管理し、事実確認は自分で 1 件ずつ調べる。 After：取材原稿を GitHub Markdown で管理し、PR で Claude Code Action に「数字の出典確認 / 用語の使い方 / 文体の統一」を依頼。事実確認は人間の最終判断を絶対に外さない前提で、AI を一次読者として使う。 所要時間：1 取材あたり、AI 一次レビューに 5〜10 分、人間最終確認に 30 分〜1 時間。 最初の壁：GitHub の作法 + AI の指摘を鵜呑みにせず、必ず自分で事実確認するという心構え。AI ハルシネーション（自信満々で間違える、新人時代の私のような挙動）が混ざるので、最終確認は絶対に人間が責任を持ってください。

12-5. エンジニア志望（学習中）：個人 OSS リポで毎日 AI レビューを受ける

Before：独学でコードを書いても、レビューしてくれる人がいない。 After：個人 OSS リポで Claude Code Action を仕込み、自分のコードを毎日 AI レビューに通す。型・命名・論理・セキュリティ・可読性の観点で毎日フィードバックが得られる。 所要時間：初回セットアップ 30 分〜1 時間、運用は PR を立てるだけ。 最初の壁：「自分の独学コードを AI に見せるのが怖い」という心理障壁。営業時代の私が「先輩に提案書を見せるのが怖い」と思っていたのと同じです。怖がらずに見せた人ほど、上達が早かった——というのは、業界を問わず共通の話だと感じます。詳しくは生成AIエンジニア転職未経験もあわせてご参照ください。

5 シーン共通の最初の壁は 「YAML を自分で書く心理的抵抗」 ですが、公式テンプレを流用して Secrets を登録するだけで動く粒度に絞れば、非エンジニアの方でも段階的に関われる仕組みです。

13 — 失敗パターン 5 つと、業務で踏みやすい落とし穴

📖 この章で使う用語

Linter（リンター）：コードや YAML の文法・スタイルを自動チェックするツール。「文章校正ツールのコード版」のイメージ。

業務で部分的に運用してきた中で、Claude Code Action の導入時に踏みやすい落とし穴を 5 つ書きます。

13-1. `ANTHROPIC_API_KEY is not set` エラー

最も多い初歩エラーです。Secrets に登録したつもりが、リポジトリ Settings ではなく Organization Settings 側だった、Environment 設定で値が見えていない、というケースが多いです。対処の最初の一歩：リポジトリ Settings → Secrets and variables → Actions で、ANTHROPIC_API_KEY の名前が一字一句正しく登録されているか確認してください。

13-2. workflow.yml の YAML インデント崩れ

YAML はインデント（字下げ）が文法を決める書式なので、コピペで 1 行ずれただけで動きません。対処の最初の一歩：VS Code の GitHub Actions 拡張、または yamllint で構文チェックしてから push してください。

13-3. Draft / fork / Dependabot PR まで全部レビューに走ってコスト爆発

セクション 11「リスクと注意点」と連動する落とし穴です。if: 条件で除外しておかないと、月末の API 請求で驚くことになります。対処の最初の一歩：if: github.event.pull_request.draft == false をまず追加、続いて fork PR / Dependabot PR の除外条件を順次足してください。

13-4. 同じ PR を Claude が連続コメント

concurrency グループを設定していないと、PR が短時間に複数回更新されたときに Claude のコメントが重複します。対処の最初の一歩：concurrency.group を PR 番号で組み、cancel-in-progress: true を入れてください。

13-5. `model` ID が古いまま動かない

Anthropic のモデルは新バージョンが定期的にリリースされ、古いモデル ID は予告期間後に廃止されます。対処の最初の一歩：Anthropic 公式モデル ID 一覧（anthropic.com）で最新の Sonnet / Opus / Haiku のモデル ID を必ず確認し、workflow.yml の model: フィールドを最新版に揃えてください。

14 — 学習・導入の最初の一歩——個人 OSS リポ → 業務リポへの 3 ステップ

📖 この章で使う用語

サンドボックス：本番に影響しない「実験用の安全な箱庭」環境。「料理を本番のお客様に出す前に、まかない料理で試す」イメージ。

最後に、Claude Code Action の 導入の最初の一歩 を 3 ステップで案内します。業務で部分的に運用してきた立場として、いきなり業務リポに入れるのは推奨しません——個人 OSS → サンドボックス → 業務リポの段階運用が、いちばん事故が少ない経路だと感じています。

14-1. ステップ 1：個人 OSS リポで動作確認（所要 1 日）

個人の GitHub リポジトリで、本記事セクション 3 の最小 workflow.yml を貼り付け、テスト PR を立ててみてください。Anthropic API キーの取得は Claude Code 始め方で扱った手順を流用できます。所要は半日〜1 日。「YAML が読める / Secrets が登録できる / Actions タブでログが追える」 の 3 つを体感するのが目的です。

14-2. ステップ 2：チーム内サンドボックスリポで 1 ヶ月運用（所要 1 ヶ月）

会社の「サンドボックスリポ」または「捨てて良いプロトタイプリポ」で、1 ヶ月運用してみてください。コスト感（月額いくら）・ノイズ感（レビューコメントの的中率）・運用ルール（Draft 除外・fork 除外などの追加条件）を、チームで合意していくフェーズです。

14-3. ステップ 3：業務リポへの段階的導入（所要 3 ヶ月〜）

サンドボックスでの 1 ヶ月運用で問題なければ、業務リポに段階導入します。重要な順序は次の通り。

情シス・コンプラ・法務に事前確認：プライベートリポの社内コードを Claude（Anthropic API）に送信する旨を、必ず社内承認を取る
Bedrock 経由の検討：組織要件次第で、直 API → Bedrock 経由に切り替える検討（詳しくは AWS Bedrock を参照）
小さな PR から導入：いきなり全 PR に適用せず、特定のラベルが付いた PR だけ Claude レビューを走らせる、などの段階的展開

「絶対この 3 ステップで失敗しない」とは申し上げません——組織規模・既存 CI 文化・コンプラ要件で振れ幅が大きい領域です。本記事の各セクションで述べる判断軸は「2026 年 5 月時点・業務で部分運用してきた私の観察と公開情報からの整理」であり、最終判断は社内の情シス・法務・コンプライアンス部門にご相談いただくのが筋です。

関連記事として、AI コーディング全体の俯瞰は AI コーディング、PR レビューの詳しいプロンプト設計は AI コードレビュー、エンタープライズ AI 基盤の選び方は AWS Bedrock もあわせてご参照ください。

15 — よくある質問（FAQ）

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

A. Action 自体は無料で利用できますが、CI から Anthropic API を呼び出すので、API トークン課金が別途発生します（公式料金ページで必ず最新確認）。Max プランの権利は CI からは原則使えず、API キー＝従量課金が走る点に注意してください。詳しくは本記事セクション 5「料金構造」をご参照ください。

Q2: Claude Max プランの権利を GitHub Actions から使えますか？

A. 原則使えません。Claude Max プランは Claude.ai（Web）と Claude Code CLI（個人マシン）でのサブスク権利で、CI/CD 環境からは別途 Anthropic API キーが必要です（公式仕様、2026-05-19 取得）。詳しくは本記事セクション 5「料金構造」をご参照ください。

Q3: Claude Code Action は GitLab CI でも動きますか？

A. Anthropic が公式 Action として配布しているのは GitHub Actions 用のみです（2026-05-19 時点）。GitLab CI / Jenkins / CircleCI で動かす場合は、claude CLI を自前の .gitlab-ci.yml 等で呼び出す自前ハーネス実装になります。詳しくは本記事セクション 10「GitLab CI / Jenkins / 自前実装」をご参照ください。

Q4: PR レビューを Claude に任せきりにしてもいいですか？

A. 「絶対に大丈夫」とは申し上げません。マージ判断 / 本番デプロイ / 機密処理 / 契約変更の 4 つは、人間が責任を持って判断する領域として明確に線を引いておく必要があります（本記事セクション 7 / セクション 11 参照）。Claude のレビューは「人間レビューの叩き台」と位置づけるのが、業務で部分的に使ってきた私の実感としていちばん健全な使い方です。

Q5: どの Claude モデル（Sonnet / Opus / Haiku）を CI で使えばいいですか？

A. 業務での使い分けとしては、PR レビューや CI コード生成は Sonnet 4.5 を主軸、複雑なリファクタ提案は Opus 4.7、簡易な型チェック・命名チェックは Haiku がコスト×品質のバランスが取れているという感覚です（本記事セクション 6 参照）。「絶対これが正解」とは申し上げず、用途・コスト・PR の規模で使い分ける運用感覚をおすすめします。

訂正・お問い合わせ

本記事の内容に誤り・古い情報・追記すべき観点を見つけられた場合は、サイトお問い合わせフォーム（send@bon-bon-tools.com）までお知らせください。確認のうえ、本文末に「訂正履歴」を追記して透明性を保ちます。Claude Code Action の仕様・料金・モデル ID・公式 Action のバージョンなどの一次情報は、Anthropic 社の公式ドキュメントおよび GitHub 公式リポジトリが最も信頼できるソースですので、本記事と公式情報に差がある場合は公式情報を優先してご判断ください。AWS Bedrock / Google Vertex AI の認証経路や料金体系については、各クラウドの公式ドキュメントを必ずご確認ください。最終的な導入判断は、社内の情シス・法務・コンプライアンス部門、必要に応じて専門の弁護士の方へご相談ください。

出典

anthropics/claude-code-action（GitHub 公式リポジトリ）（取得：2026-05-19）
Anthropic Claude Code 公式ドキュメント（取得：2026-05-19）
Anthropic 公式料金ページ（API Pricing）（取得：2026-05-19）
Anthropic Claude モデル一覧（Models overview）（取得：2026-05-19）
GitHub Actions 公式ドキュメント（取得：2026-05-19）
GitHub Marketplace（取得：2026-05-19）
GitHub Actions Secrets and variables（取得：2026-05-19）
AWS Bedrock 公式ページ（取得：2026-05-19）
AWS Bedrock Pricing（取得：2026-05-19）
Google Cloud Vertex AI - Anthropic Claude models（取得：2026-05-19）
Model Context Protocol（MCP）公式（取得：2026-05-19）
OWASP Top 10（取得：2026-05-19）
GitHub Actions - aws-actions/configure-aws-credentials（取得：2026-05-19）