· updated

Claude Code Action で 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 回試したい方は、最小セットアップと PR レビュー自動化から読み始めると、本日中に「最初の YAML」が動くところまで届きます。

Claude Code Action の正体｜公式ハーネスの位置づけ・3 用途マップ・ハーネス概念

📖 用語：Claude Code Action＝GitHub Actions 上で Claude Code を動かす公式の仕組み（anthropics/claude-code-action）。GitHub Actions＝PR や push をきっかけに自動でスクリプトを走らせる「ベルトコンベア」。CI/CD＝変更を頻繁に統合・テストし本番まで自動化する仕組み。ハーネス（harness）＝自律するエージェント（馬）を業務フロー（馬車）につなぐ装具。

Claude Code Action の『任せ時』と『止め時』を分けた概念図。任せてよいのは PR の一次レビュー・コミットメッセージ下書き・Issue/PR 説明文の整形・抜け漏れ観点の列挙、人間が必ず止めるのはマージ可否の最終判断・本番デプロイ・機密/Secrets の取り扱い・契約や要件の決定

結論から書きます。Claude Code Action は 「GitHub Actions で Claude Code を動かすための、Anthropic 公式のハーネス（仕組み）」——これが業務で部分運用してきた私のいちばん実用的な答えです。覚えていただきたいのは次の 3 用途マップで、新しい記事や YAML を見ても「3 用途のどこに住む使い方か」を確かめれば置き場所に迷いません。

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

私自身は フル運用まではしていません。個人 OSS リポでの動作確認と、一部の業務リポで PR レビュー補助に組み込む「部分運用」レベルです。最初の一歩は次の 3 ステップです。

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

本記事では 「絶対に安全」「絶対にコストが膨らまない」「絶対に PR レビューを任せきれる」とは申し上げません。コードベース・組織規模・既存 CI 文化で振れ幅が大きく、判断軸は「2026 年 5 月時点の私の業務観察と公式ドキュメント」によるもの。最終判断は社内の情シス・法務・コンプライアンス部門、必要に応じて専門の弁護士の方へご相談ください。本記事は親ハブ AI コーディングとは の「ハーネス」概念の独立深掘りスポークです。

Claude Code Action とは——公式パッケージ・3 経路・ハーネス概念

Claude Code Action の正体は、Anthropic 公式の GitHub Actions 用パッケージで、PR や Issue のイベントをきっかけに Claude Code を CI 上で起動し、レビューコメント・コード提案・コミットメッセージ叩き台を生成する仕組み です。workflow.yml に uses: anthropics/claude-code-action@v1 と書けば呼び出せます（最新版は GitHub Marketplace と公式 README で確認、本記事末尾「出典」を参照）。営業時代のたとえなら 「自社の提案書テンプレを社内テンプレ集に登録して全営業が使えるようにする」 感覚で、一度書いた YAML を .github/workflows/ に置けば PR が立つたび自動で同じ仕事をしてくれます。

Claude を業務で使う経路は大きく 3 つあり、Claude Code Action は「個人で触る → 個人 PC でフォルダ単位 → CI で自動化」の最終段に当たります。

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

AI コーディングとは で触れた 「ハーネス（harness）」——馬具を語源に、自律エージェント（馬）を業務フロー（馬車）につなぐ装具——を一歩深掘りすると、Claude Code Action はまさに「Claude Code というエージェントを GitHub の PR レビュー / CI ワークフローという馬車につなぐ装具」です。馬が自律的に走れても接続装具がなければ業務に組み込めない。その装具を Anthropic 公式が提供している、と理解すると掴みやすいです。

導入の前提を固める｜最小セットアップ・認証 3 系統・料金・モデル選び

📖 用語：Secrets＝API キーなどの秘密情報をリポジトリ設定に安全に保管する「金庫」。workflow.yml＝GitHub Actions の動作を定義し .github/workflows/ に置く YAML ファイル。YAML＝インデント（字下げ）が文法を決める設定書式。

Claude Code Action を 「個人 OSS リポで最短で動かす」 ための土台を、セットアップ・認証経路・料金・モデルの 4 点でまとめます。最小サンプルは「動く形」を確認するためのもので、本番運用にはチーム合意・コストガード・人間レビューが別途必要です。

最小セットアップ 5 ステップ

  1. Anthropic API キーを取得（claude-code-hajimekata を参照、console.anthropic.com から発行）
  2. GitHub の Secrets に登録（Settings → Secrets and variables → Actions → New repository secret、Name: ANTHROPIC_API_KEY）
  3. .github/workflows/claude-pr-review.yml を新規作成
  4. 最小 workflow.yml を貼り付け（次のサンプル）
  5. テスト PR を立てて動作確認（小さな typo 修正 PR で十分、Actions タブでログを追う）

ここまでで PR が立つたび Claude がレビューコメントを自動生成する最小構成が動きます。初回所要は 30 分〜1 時間が現実的です。

最小 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 拡張 で構文チェックしておくと、初回の躓きを避けられます。

実際に、この最小構成の workflow.yml を手元で書き起こした画面が次です。uses: anthropics/claude-code-action@v1 を呼び出し、anthropic_api_key は ${{ secrets.ANTHROPIC_API_KEY }}（GitHub Secrets 参照＝キー実値はファイルに書かない）、model に claude-sonnet-4-6 を指定し、prompt に「マージ判断・本番デプロイは人間が行う前提です」と書いて止め時を明文化しています。

Claude Code Action の最小 workflow.yml を書き起こした実際の画面。on: pull_request で発火し、uses: anthropics/claude-code-action@v1、anthropic_api_key は secrets 参照、model: claude-sonnet-4-6、prompt にマージ判断・本番デプロイは人間が行う前提と明記している

動作確認のコツは 3 つ。Actions タブで実行状況をリアルタイムに追う／失敗ログを通読する（エラーは大抵 Secrets 未登録か YAML インデント崩れ）／小さな PR で試す（typo 修正レベルで「動く形」を確認）。提案書テンプレを小案件で試して粗を直してから大型案件に投入するのと同じ作法です。

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

📖 用語：IAM＝AWS の権限管理（入退室カードと部屋ごとの権限）。VPC＝AWS 内の自社専用ネットワーク区画。AssumeRole＝ある立場（Role）を一時的に借りる動作。Workload Identity Federation＝外部システム（GitHub Actions 等）から GCP リソースに認証する Google Cloud の仕組み。

CI から呼ぶときの 認証経路は 3 系統 あり、選び方が CI 統合の最初の分かれ目になります。3 系統を横並びで比較します。

(1) Anthropic 直 API（個人〜少規模チーム向け、私が業務で常用）：console.anthropic.com で API キーを発行し 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 分で始められます。金融・医療・公共のコンプラ要件が出てきたら、次の Bedrock 経由に切り替えていく流れです。

(2) AWS Bedrock 経由（エンタープライズ要件向け、私は個人検証＋選定整理レベル）：直 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"

向いているのは 「コードを直 API に送ることを社内コンプラが許容しない」「IAM 統合・VPC 内通信・監査ログを既存 AWS 基盤に集約したい」 段階。AWS の既存契約・IAM・CloudTrail / CloudWatch の監査基盤を継承でき、社内稟議が通りやすい利点があります。

(3) Google Vertex AI 経由（GCP 系スタック向け）：私の常用範囲を超えるので公式ドキュメント確認の範囲です。公式ドキュメントによると Vertex AI 経由でも Claude が利用可能で、認証は Workload Identity Federation が推奨です（最新版は本記事末尾「出典」を参照）。向いているのは Google Cloud / Workspace 中心の組織。どれを選ぶかは 「既存の社内インフラ契約がどこに偏っているか」 で決まることが多いです。

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

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

現実的な目安は、(1) 個人〜少規模チームなら直 API、(2) AWS 系のエンタープライズ要件が出たら Bedrock 経由、(3) GCP 系スタックなら Vertex AI 経由——というのが公式ドキュメントと私の業務観察の落としどころです。

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

📖 用語：トークン＝LLM が文章を処理する最小単位（日本語 1 文字 ≒ 1〜2 トークン、タクシーのメーター式）。従量課金＝使った分だけ請求（電気・水道と同じ）。サブスク＝月額固定で使い放題（上限あり）。

CI から呼ぶときに 最も誤解しやすい論点 が 1 つあります。Claude Max プランの権利は 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 は別請求」の応用です。

整理すると、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 で動かすときは 「サブスクとは別の請求経路（API）が走っている」 構造を最初に頭に入れておくのが安全です。

PR 1 件のコスト感は PR の規模・モデル・出力の長さ で振れ、Sonnet 4.5 で 1 PR あたり数十円〜数百円のレンジに収まることが多い、というのが 2026/5 時点の目安です（厳密な数字は差分量で大きく変わるので anthropic.com/pricing で確認）。問題は この目安が PR の規模・本数・運用ルールで簡単に 10 倍 100 倍に膨らむ こと。コスト爆発を避ける運用ルールは 3 つです。

  1. Draft PR を除外：if: github.event.pull_request.draft == false（最小サンプルにも入れた条件）
  2. 月次予算アラート：Anthropic ダッシュボード / AWS Budgets / GCP Budgets で月額 $50 / $100 / $500 などの段階で警告メール
  3. 1 日のリクエスト上限：ワークフロー内で 1 日のレビュー回数をカウントし上限超で skip（簡易には concurrency で同時実行を制限）

最初の 1 ヶ月は 「個人 OSS リポ → サンドボックスリポ」 で慣らしてから業務リポに広げる段階運用をおすすめします（導入の 3 ステップを参照）。

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

📖 用語：モデル ID＝API で呼ぶときの識別子（例 claude-sonnet-4-5-20250929）。コンテキスト窓＝LLM が一度に読める文章の最大長（長い PR を一度に読ませたいときに効く）。

CI から呼ぶモデル選びを 用途別の使い分け に絞って整理します（Opus / Sonnet / Haiku の違いは Claude Opus・Claude 料金プラン）。私が現時点で使ってきた感覚を表にまとめます。

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

私の出発点は 「まず Sonnet 4.5 を主軸で組み、複雑な PR だけ Opus 4.7 に切り替える条件分岐を後から仕込む」。この順序がコスト×品質のバランスを取りやすいと感じます。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、と分岐させる方法もあります。

業務ユースケース｜PR レビュー自動化・コミット/Issue 補助・MCP 統合・他 CI

📖 用語：diff＝ファイルの「変更前／変更後」の差分（GitHub は緑＝追加・赤＝削除）。OWASP Top 10＝Web アプリのセキュリティリスク代表 10 種をまとめた標準リスト。

本記事のいちばん厚い章です。PR レビュー自動化の 5 シーン を軸に、コミット/Issue 補助・MCP 統合・GitHub 以外の CI までを 「CI 組込み観点」 に絞って整理します（詳しいプロンプト設計は AI コードレビュー）。

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

いちばん価値が出やすいと実感しているのが PR レビュー自動化です。一方、Claude にレビューを任せきって人間レビューを省ける、とは絶対に申し上げません——マージ判断 / 本番デプロイ / 機密処理 / 契約変更の 4 つは人間が責任を持つ領域です。価値を出しやすい 5 シーンは次の通りです。

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

代表シーン「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 件以内
            最後に必ず「人間の最終マージが必要です」と添えてください。

PR が synchronize（push 更新）されたタイミングで差分のみ追加レビューさせれば、コストを抑えつつ PR の成熟過程で逐次レビューが入ります。

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

OWASP Top 10 の観点を渡してチェックさせるパターンも実現できますが、本番運用ではセキュリティ専門家による人間レビューが別途必須 です。AI の自動チェックは「叩き台」「気付きのきっかけ」までで、責任を負った最終判定にはなりません。改めて、AI コーディングとは の 人間判断ゾーン 4 つ——(1) マージ判断、(2) 本番デプロイ、(3) 機密処理、(4) 契約変更（API 仕様・ライセンス・SLA 影響）——は人間の領域です。PR レビューを Claude に任せきって人間レビューを省けるとは申し上げません——本記事で最も強くお伝えしたい点です。

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

📖 用語：コミット（commit）＝変更を「ここで一区切り」と記録する操作（営業の日報に近い）。

PR レビュー以外の業務 UC を CI 組込み観点 に絞って整理します（射程は AI コーディング の「自動化（PR / コミット / CI）」）。PR を立てたタイミングで、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 件以内）
            最後に「人間が内容を確認・修正してください」と添えてください。

その他の業務 UC として、Issue 起票補助（バグレポートテンプレを整形）、リファクタ提案（テストが落ちたコミットで修正案を PR コメント、マージは人間）、ドキュメント自動更新（API スキーマ変更時に README 更新案）があります。これらはすべて 「Claude が叩き台を出し、人間が確認・修正・最終承認する」 分業前提です。「Claude が PR を立てて Claude が承認する」までやらせるのは絶対に避けてください（リスクと注意点も参照）。

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

📖 用語：MCP（Model Context Protocol）＝LLM が外部リソース（GitHub / Postgres / Slack 等）を統一規格で参照するプロトコル（USB 規格のような共通インターフェース）。MCP サーバー＝外部リソースを LLM に提供する側のプログラム。RAG＝LLM に社内情報を「その場で検索して」答えさせる仕組み（RAG とは）。

SERP がほぼ触れない最新領域 です。MCP は Anthropic が 2024 年に公開したプロトコルで、私は Cursor MCP を業務でセットアップして常用しており、ここは語れる範囲です（Cursor 使い方 の MCP セクション）。一方、Claude Code Action × MCP（CI から MCP を呼ぶ運用）は私の常用範囲を超えるので、Cursor MCP 常用の延長で見える「CI × MCP の射程」までを書きます。原理的には次の統合が可能です。

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

公式仕様をベースにした最小サンプルが次です（最新版を必ず確認してください）。

# .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 ドキュメントで確認してください。AI エージェント構築は AIエージェントの作り方、MCP の原典は Cursor 使い方 も参照。

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

📖 用語：GitLab CI＝GitLab 版の CI/CD。Jenkins＝自前サーバーに立てて使う OSS の CI/CD ツール。

GitLab CI / Jenkins / CircleCI は私の常用範囲を超えるので、公式ドキュメントを確認しながら整理します。押さえておきたい事実として、Anthropic が GitHub Marketplace で配布する anthropics/claude-code-action は GitHub Actions 専用 です（2026-05-19 時点、本記事末尾「出典」を参照）。GitLab / Jenkins / CircleCI で動かす場合は 自前で claude CLI を呼び出すハーネス実装 が必要です。GitLab CI の最小サンプルが次です（公式 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 / Jenkins / CircleCI では公式 Action のような統合の薄さが得られないので、「自前ハーネスを書く工数 vs GitHub に CI を寄せる選択」 を最初に天秤にかけます。公式サポートの厚さの差が運用負荷に直接効くので、検討時は各プラットフォームの最新情報を確認してください。

運用とロードマップ｜リスク 5 つ・私の部分運用・失敗 5 つ・導入 3 ステップ

📖 用語：rate limit＝API の単位時間あたりの呼び出し上限（超えるとエラー）。concurrency＝GitHub Actions の「同じグループのジョブを 1 つだけ動かす」設定（重複実行を防ぐ）。

意外と解説記事が触れない運用リスクを 5 つ整理します。

無限ループリスク

最も多い事故です。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 件に制限します。残る 4 リスクの安全網は次の通りです。

  • コスト爆発（料金構造と連動）：Draft / 大規模 / fork / Dependabot PR を全部走らせると月額が 10 倍 100 倍に。Draft 除外＋fork 除外（if: github.event.pull_request.head.repo.full_name == github.repository）＋Dependabot / Renovate 除外＋月次予算アラートで防ぐ
  • Secrets 漏れ：API キーをログ / PR コメントに含めない。echo "::add-mask::$VALUE" でマスキング、PR テンプレで貼らないルール明文化、公開リポは fork PR からの Secrets アクセス禁止（GitHub デフォルト）
  • 社内コード機密：プライベートリポの社内コードを Claude（Anthropic API）に送信する事実を情シス・コンプラ・法務に必ず事前確認。Bedrock / Vertex AI 経由を選ぶ、または「機密ファイル・個人情報・社外秘ロジックは入力禁止」を明文化（AWS Bedrock）
  • AI レビュー鵜呑み：PR レビュー自動化で書いた通り、レビューを通したから人間レビューを省略してマージ、は絶対に避ける

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

私が実際にどう使っているか——部分運用の実際

📖 用語：部分運用＝フル運用ではなく限られた範囲だけで使う状態。個人 OSS リポ＝公開・実験用の GitHub リポジトリ（本番業務と切り離して試せる場所）。

職種別の架空ユースケースを並べる代わりに、私が実際にどう使っているかを正直に書きます。フル運用はしておらず、個人 OSS リポでの動作確認と一部の業務リポでの PR レビュー補助という「部分運用」レベルです。

いちばん手応えがあるのは、個人 OSS リポでの「毎日の一次レビュー」。自分のコードを PR にするたび、型・命名・論理の抜け・可読性の観点で出した直後にフィードバックが付きます。先輩が常駐していなくても毎日「一次読者」が付く感覚で、効くのは PR レビュー自動化と同じ仕組み——AI のコメントはあくまで叩き台、採否は自分で判断します。営業時代、先輩に提案書を見せるのが怖かった私が言うのも何ですが、怖がらずに早く見せた人ほど上達が早い（学習の文脈は 生成AIエンジニア転職 未経験）。

業務リポでは PR レビューの補助という一点に絞り、typo・用語ゆれ・コーディング規約・抜け漏れ観点の列挙を一次で見させて人間レビュアーの負担を下げています（結論の「任せ時」と一致）。部分運用にとどめるのは慎重すぎるからではなく 「止め時」を先に決めているから——マージの最終判断・本番デプロイ・機密や Secrets の取り扱い・契約や要件の決定（結論の「止め時」）は人間の領域で、ここを AI に委ねるとリスクの無限ループ・コスト爆発・情報漏れ・責任の所在不明に直結します。なお、エンジニアでない方も、用意済みのリポで PR や Issue を立てる側として関われます（整形済み説明文や typo 指摘を AI が返す入口側。最終確認は人間が責任を持つ前提は同じ）。

失敗パターン 5 つと、踏みやすい落とし穴

導入時に踏みやすい落とし穴を 5 つ、対処とあわせて挙げます。

  • ANTHROPIC_API_KEY is not set：Secrets を Organization 側に登録していた／Environment 設定で見えていない、が多い。リポジトリ Settings → Secrets and variables → Actions で名前が一字一句正しいか確認
  • YAML インデント崩れ：1 行ずれただけで動かない。VS Code の GitHub Actions 拡張または yamllint で構文チェックしてから push
  • Draft / fork / Dependabot PR まで走ってコスト爆発（リスクと連動）：if: github.event.pull_request.draft == false をまず追加、続いて fork / Dependabot 除外条件を順次
  • 同じ PR を連続コメント：concurrency.group を PR 番号で組み、cancel-in-progress: true を入れる
  • model ID が古いまま動かない：古いモデル ID は予告期間後に廃止。anthropic.com で最新の Sonnet / Opus / Haiku の ID を確認し model: を揃える

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

📖 用語：サンドボックス＝本番に影響しない実験用の安全な箱庭環境（まかない料理で試すイメージ）。

いきなり業務リポに入れるのは推奨しません——個人 OSS → サンドボックス → 業務リポの段階運用が、いちばん事故が少ない経路です。

  1. 個人 OSS リポで動作確認（所要 1 日）：最小セットアップの workflow.yml を貼り、テスト PR を立てる。API キー取得は Claude Code 始め方 を流用。「YAML が読める / Secrets が登録できる / Actions タブでログが追える」の 3 つを体感する
  2. チーム内サンドボックスで 1 ヶ月運用：コスト感・ノイズ感（コメントの的中率）・運用ルール（Draft / fork 除外など）をチームで合意する
  3. 業務リポへの段階導入（所要 3 ヶ月〜）：(a) 情シス・コンプラ・法務に事前確認（社内コードを Claude に送信する旨の社内承認）、(b) 組織要件次第で直 API → Bedrock 経由の検討（AWS Bedrock）、(c) 特定ラベル付き PR だけ走らせるなど段階展開

「絶対この 3 ステップで失敗しない」とは申し上げません——組織規模・CI 文化・コンプラ要件で振れ幅が大きく、最終判断は社内の情シス・法務・コンプライアンス部門にご相談ください。関連記事は、全体俯瞰の AI コーディング、プロンプト設計の AI コードレビュー、基盤選びの AWS Bedrock。

よくある質問（FAQ）｜料金・Max プラン・GitLab・任せきり・モデル選び

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

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

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

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

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

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

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

A. 「絶対に大丈夫」とは申し上げません。マージ判断 / 本番デプロイ / 機密処理 / 契約変更の 4 つは、人間が責任を持って判断する領域として明確に線を引く必要があります（PR レビュー自動化 / リスクと注意点 参照）。Claude のレビューは「人間レビューの叩き台」と位置づけるのが、いちばん健全な使い方です。

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

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

この記事は、法人営業を約 7 年やってから未経験 SE → 自社開発と移ってきた現役の生成AIエンジニア aikun が、Claude Code Action を個人 OSS リポでの動作確認と一部業務リポの PR レビュー補助に「部分運用」している手触りをもとに書いています。業務本番フルパイプラインの細部や認証経路（Bedrock / Vertex AI）の本番構成は私の常用範囲を超えるので公式ドキュメントを確認しながら整理しており、最終判断は社内の情シス・法務・コンプラ部門に委ねる前提で書いています。

訂正・お問い合わせ

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

関連記事

出典

新しい記事のお知らせを受け取る → 登録（準備中）