Claude Code CI/CD自動化｜レビューとテストを仕組み化する設計

AIをCI/CDに組み込むとは、レビュー待ちという“人の詰まり”を仕組みで解く設計です。自動化すべきはコードを書く工程ではなく、レビューが滞る工程。

「レビュー依頼を出してから返ってくるまでに半日かかる」「レビューの指摘内容がレビューアごとにバラバラで、新人がどこを直せばいいのか分からない」「テストとChangelogは、余裕があるときだけ手で書いている」——開発現場で聞くのは、コードを書く速度ではなく、その前後の手作業と待ち時間の話です。

Claude Code CI/CD 自動化とは、Claude Codeをヘッドレスモード（-p / --print フラグ）や公式GitHub Action（anthropics/claude-code-action）でCIパイプライン上に配置し、コードレビュー・セキュリティ監査・テスト生成・ドキュメント更新といった定型的な判断工程を自動実行する設計のことです。人間のレビューを置き換えるのではなく、人間が設計とロジックに集中できるよう、その手前の工程をシステム側に寄せる考え方になります。

出典: Anthropic公式: GitHub Actions

本記事では、Claude CodeをCI/CDパイプラインに組み込む具体的な方法と、実運用で効果を発揮するパイプライン設計パターンを解説します。AI活用完全ガイドで、AI活用の全体像を把握できます。

この記事でわかること

CI/CDパイプラインにAIを組み込みたいDevOpsエンジニア・開発リーダーに向けた記事です。設定手順だけでなく、どこまでAIに任せてどこから人間が引き取るかという運用設計まで扱います。

• ヘッドレスモードの仕組みと安全な実行設定 — -p / --print、--no-user-prompt、--allowedTools の3点セットで、非対話かつ権限を絞った実行ができます。
• 公式GitHub Action（claude-code-action）のセットアップ — /install-github-app による自動セットアップと、ワークフローYAMLの手動記述という2つの方法があります。
• CI/CDで自動化できる6つのユースケース — PRレビュー、セキュリティ監査、テスト生成、Changelog生成、ドキュメント同期、Issueトリアージを、優先順位をつけて並べます。
• 実行時間とAPIコストを制御する設計上の注意点 — max_turns・max_tokens・timeoutとトリガー制限で、パイプラインが重くならない範囲に収めます。
• AIに任せる領域と人間が判断すべき領域の線引き — 自動レビューをどこまで信用し、どこから人間が引き取るかを明示します。

「AIレビューを入れてみたいが、どこから手を付ければいいか分からない」という開発リーダーの方に向けて書いています。最後まで読むと、自社のリポジトリ1本にスモールスタートでAIレビューを組み込み、そこから段階的に自動化範囲を広げる道筋を描けるようになります。

CI/CDパイプラインで自動化すべき工程の見極め方

CI/CDにAIを組み込むかどうかを考える前に、まず「今どこで詰まっているのか」を書き出すところから始めるのが要点になります。

ツールを入れてから使い道を探すと、動いているけれど誰も読まないレビューコメントが積み上がるだけになりがちです。

スプレッドシート管理されたレビュー基準の限界

多くのチームで、レビュー観点は「Wikiやスプレッドシートのチェックリスト」として存在しています。ただ、その運用にはよくある限界があります。

• 更新が数ヶ月に一度 ── 更新されるのは数ヶ月に一度です
• レビューの質がばらつく ── レビューアは結局自分の経験則で見てしまい、レビューの質がレビューアごとにばらつきます
• 基準か好みか判別できない ── 新人が指摘を受けても、それがチームの基準なのか個人の好みなのかが判別できません

これは営業がスプレッドシートで案件を管理していて、フォーマットが人によって微妙に違ってしまう状態とよく似ています。

手動のチェックリストは「読む人の意志」に依存します。

• 基準をファイルに落とす ── CLAUDE.md のようなリポジトリ内のファイルに落とし、CIから毎回参照させると、基準そのものがコードと一緒にバージョン管理されます
• 基準を変えたい場合 ── PRを出す、という運用に変わります

工程ごとの「手作業が残っている箇所」を棚卸しする

自動化の候補を洗い出すときは、工程・現状・自動化の余地という3列で並べると判断しやすくなります。

全部を一度に自動化しようとする前に、どこが一番滞っているかを可視化する作業だと考えていただくとイメージしやすいはずです。

この表で「大きい」に当たる工程から手を付けます。

• 全部を一度に自動化する ── パイプラインが重くなり、コストも読めなくなります
• まずは1リポジトリ・1ユースケースから ── 効果が見えたら広げるのが現実的です

自動化の前に決めておく3つのルール

導入前に決めておくと後で揉めないのが、次の3点です。

1. AIのレビューコメントは「マージをブロックするのか、参考情報なのか」
2. AIが生成したコード（テストなど）を誰がレビューしてマージするのか
3. AIの指摘が明らかに的外れだったとき、誰がプロンプトを直すのか

特に3点目は運用上の要です。プロンプトの設計・チューニングは人間の仕事であり、放置するとAIレビューが形骸化します。

• 管理者を決める ── CLAUDE.md とワークフローYAMLの管理者をチーム内で1人決めておくと、担当者が変わっても基準が引き継げる仕組みになります
• ファイルとルールで回す ── 特定の個人の経験に頼らず、ファイルとルールで回る状態を作ることが、後から新人が加わったときの立ち上がりの速さにもつながります

ヘッドレスモードでCI/CDに組み込む基礎設定

CI/CD環境では人間の操作が介在しないため、Claude Codeを非対話的に動かす仕組みが土台になります。

ここを理解しておくと、GitHub Actionsに限らずGitLab CIやJenkinsでも同じ考え方で組めます。

-p / --printフラグによる非対話実行

Claude Codeの通常利用はインタラクティブなターミナルセッションですが、--print（短縮形: -p）フラグを使えば、Claude Codeをバッチ処理として実行できます。

詳しくは「Claude Codeの企業導入セキュリティガイド」で解説しています。

claude -p "このファイルの問題点を指摘してください" --file src/index.ts

このコマンドは、プロンプトを処理し、結果を標準出力（stdout）に表示して終了します。

Unixパイプと組み合わせれば、Gitの差分をレビューするといった処理も1行で実現できます。詳しくは「Claude Codeでプロジェクト管理を効率化する方法」で解説しています。

git diff HEAD~1 | claude -p "この差分をレビューしてください"

上の画面は、本記事で扱う次のコマンドと、公式Actionのセットアップに使う /install-github-app をターミナル上に並べたものです。

• claude -p
• git diff
• git log
• git describe --tags --abbrev
• git diff origin

冒頭には claude --version の実出力が表示されています。

以下の画面は、Claude CodeのCI/CD関連コマンドを並べたターミナル画面です。

--no-user-promptによる完全非対話実行

CI/CD環境では、--no-user-prompt フラグを併用することで、ユーザー確認のプロンプトが一切表示されなくなり、パイプラインがブロックされるリスクを減らせます。

パーミッション確認が発生した場合は、操作を実行せずスキップする動作になります。

claude -p "テストを実行して結果を報告してください" \
  --no-user-prompt \
  --allowedTools "Read,Grep,Glob,Bash(npm test)"

--allowedTools フラグと組み合わせることで、CI環境で実行可能な操作を明示的にホワイトリスト化できます。この設定により、次のような細かい制御が可能です。

• レビュー用途 ── 読み取り専用ツールのみを許可します
• テスト実行用途 ── 特定のBashコマンドのみを許可します

用途ごとに許可範囲を変えるのは、HubSpotでユーザーの権限セットを役割別に分けるのと似た発想になります。

出力フォーマットの選択

ヘッドレスモードでは --output-format オプションで3種類の出力形式を選択できます。

CI/CDパイプラインで結果を後続ステップに渡す場合は、json形式が扱いやすい選択肢です。

# JSON出力をjqで後処理する例
claude -p "このコードの問題点を列挙してください" \
  --output-format json | jq '.result'

stream-json 形式は、処理中にリアルタイムでログを確認したい場合に有効です。

長時間のレビューや大規模なコードベースの分析で、パイプラインのタイムアウト前に進捗を確認できます。

セキュリティ設定の3つの機構

CI/CD環境でのセキュリティは3つの機構で担保します。どれか1つではなく、3つを組み合わせて初めて事故の起きにくい構成になります。

• ツール制限（--allowedTools） — 実行可能なツールをホワイトリストで限定
• 環境変数 — APIキーをシークレットとして管理（ログに出力しない）
• タイムアウト — 無限実行を防止する最大実行時間の設定

何をCIに読ませてよいかというルールは、ツール設定とは別に社内で決めておく必要があります。

GitHub Actionsによるパイプライン実装

GitHub Actionsは公式Actionが用意されているため、最も統合度が高い選択肢です。PRへの自動コメントやIssueの自動トリアージまで含めて、追加の実装なしで動かせます。

ここでは、まず1本動かすための最小構成から入り、モノレポでの応用に広げます。

公式Action: claude-code-action

Anthropicが公式に提供する anthropics/claude-code-action@v1 は、GitHub Actionsランナー上でClaude Codeを実行し、PRへの自動コメントやIssueの自動トリアージを実現します。

セットアップは2つの方法があります。

1. CLIから自動セットアップ — Claude Codeのターミナルで /install-github-app を実行
2. 手動セットアップ — ワークフローYAMLを直接記述

最初の1本は自動セットアップで動かし、挙動を確認してからYAMLを手で調整していくと、つまずきにくくなります。

基本的なPRレビューワークフロー

name: Claude Code Review
on:
  pull_request:
    types: [opened, synchronize]

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

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: $
          max_turns: 5
          timeout_minutes: 10
          prompt: |
            このPRの変更点をレビューしてください。
            以下の観点で評価してください：
            1. ロジックの正確性
            2. エラーハンドリングの網羅性
            3. パフォーマンスへの影響
            4. セキュリティリスク
            5. テストの十分性

このワークフローにより、PRが作成・更新されるたびにClaude Codeが自動でコードレビューを実行し、結果をPRのコメントとして投稿します。

• fetch-depth: 0 ── 全コミット履歴を取得することで、変更の文脈をより正確に理解できます
• permissions の contents: read ── レビュー用途ではリポジトリへの書き込みを不要にするためです

パス別レビューの設定

モノレポ構成では、変更されたパスに応じて異なるレビュー基準を適用できます。

- uses: anthropics/claude-code-action@v1
  with:
    anthropic_api_key: $
    prompt: |
      変更されたファイルに基づいてレビューしてください。
      - src/api/ → APIの後方互換性を確認
      - src/db/ → SQLインジェクションのリスクを確認
      - src/auth/ → 認証・認可のセキュリティを重点確認
      - src/components/ → アクセシビリティとパフォーマンスを確認

ここで書いているのは、要するに「どのディレクトリを触ったら何を確認するか」というチームの暗黙知です。これまでベテランの頭の中にあったものを、YAMLとして明文化することになります。

人が異動しても基準が残る、という意味で仕組み化の効果が大きいところです。

公式Actionが向かないケース

一方で、公式Actionが噛み合わないケースもあります。

• GitHub以外をメインに使っているチーム
• オンプレミスのGitサーバーを使っているチーム
• レビュー結果をGitHub外のシステム（自社のダッシュボードなど）に集約したいチーム

これらのチームでは、ヘッドレスモードで自前のスクリプトを書いたほうが素直です。公式Actionは「GitHub上で完結させたい場合の最短経路」であって、唯一の選択肢ではありません。

CI/CDで自動化できる6つのユースケース

ここからは、CI/CDで自動化できる6つのユースケースを見ていきます。すべてを同時に入れる必要はなく、効果が見えやすいものから1つずつ足していくのが現実的です。

並べ方としては、導入しやすさと効果の大きさが両立するものを先に置いています。

パターン1〜2: PRレビューとセキュリティ監査

最も一般的なのがPRレビューの自動化です。人間のレビューアがコードを読む前に、Claude Codeが構文チェック、ロジックの問題、セキュリティリスクを事前に検出します。

効果としては、次が挙げられます。

• レビュー待ち時間の短縮
• レビューアの負担軽減
• CLAUDE.md に基準を記載することによるレビュー基準の統一

セキュリティ監査は、PRの変更に対してセキュリティ専門のレビューを自動実行するパターンです。

従来の静的解析ツールでは検出が難しいビジネスロジックの脆弱性も、Claude Codeのコード理解力で発見できるケースがあります。

name: Security Audit
on:
  pull_request:
    paths:
      - 'src/auth/**'
      - 'src/api/**'
      - 'src/db/**'

jobs:
  security-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: $
          prompt: |
            セキュリティの観点でこのPRをレビューしてください。
            確認項目:
            - 認証・認可の実装に漏れはないか
            - SQLインジェクション、XSS、CSRFのリスク
            - 入力値バリデーションの網羅性
            - シークレットのハードコーディング
            - 権限昇格の可能性
            - IDOR（安全でない直接オブジェクト参照）

paths で対象を絞っているのがポイントです。全PRで重いセキュリティレビューを回すとコストも実行時間も膨らむため、認証・API・DB周りに限定しています。

パターン3〜4: テスト生成とChangelog生成

テスト生成は、PRの差分を分析し、変更されたコードに対応するテストケースを自動生成するパターンです。

- uses: anthropics/claude-code-action@v1
  with:
    anthropic_api_key: $
    prompt: |
      変更されたファイルに対するユニットテストを生成してください。
      テストフレームワーク: Jest
      カバレッジ目標: 分岐カバレッジ80%以上
      テストケースには正常系・異常系・境界値を含めてください

生成されたテストは別ブランチにプッシュし、人間がレビューしてからマージするフローが安全です。

Changelog生成は、マージされたPRの内容を分析し、リリースノートを自動生成するパターンです。

リリース直前に手で書いていた作業が、タグのプッシュをトリガーに自動で回ります。

name: Generate Changelog
on:
  push:
    tags:
      - 'v*'

jobs:
  changelog:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Generate changelog
        run: |
          git log $(git describe --tags --abbrev=0 HEAD^)..HEAD --pretty=format:"%s" | \
          claude -p "以下のコミットメッセージからリリースノートを生成してください。
          カテゴリ分け（機能追加/バグ修正/改善/破壊的変更）して、
          ユーザーが理解しやすい文章にしてください" \
          --output-format text > CHANGELOG_LATEST.md

パターン5〜6: ドキュメント同期とIssueトリアージ

ドキュメント同期は、コードの変更に連動して、READMEやAPIドキュメントの更新を自動化するパターンです。

• 検出して通知 ── APIの引数や戻り値が変更された場合に、ドキュメントとの不整合を検出してPRにコメントします
• 自動更新はしない ── ドキュメントを自動で書き換えるのではなく「ずれの検出まで」に留めると、誤った自動更新を避けられます

Issue自動トリアージは、新しいIssueが作成されたときに、内容を分析してラベルの自動付与、担当者のサジェスト、優先度の推定を行うパターンです。

on:
  issues:
    types: [opened]

jobs:
  triage:
    runs-on: ubuntu-latest
    permissions:
      issues: write
    steps:
      - uses: actions/checkout@v4
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: $
          prompt: |
            このIssueを分析し、適切なラベルを提案してください。
            ラベル候補: bug, feature, docs, performance, security
            重複している既存Issueがあれば指摘してください。
            再現手順が不足している場合は質問を投稿してください。

分類・要約・下書き作成はAIが得意とする領域であり、Issueトリアージはその典型です。HubSpotのワークフローで問い合わせ内容を自動分類する設計と、発想としては同じ構造になります。

AIに任せる範囲と人間が判断する範囲

自動レビューを入れたチームでよく起きるのが、「AIのコメントが多すぎて誰も読まなくなる」という状態です。

これは精度の問題というより、AIに任せる範囲を決めていないことから来ます。ここを最初に線引きしておくと、パイプラインが長く使えるものになります。

役割分担の基準

おすすめしたい基準は、「判断の正解がコードの外にあるかどうか」というフレームワークです。

• AIに任せる ── コードを読めば判断できること
• 人間が引き取る ── 事業や顧客の事情を知らないと判断できないこと

Salesforceの承認プロセスに馴染みがある方であれば、AIレビューを「承認の手前に置く一次チェック」と捉えると理解しやすいかもしれません。

この線引きは、AIを「超一流のエンジニア」ではなく「優秀なアシスタント」として扱う発想に基づいています。

アシスタントが下調べと叩き台を用意し、意思決定は人間が行う。CI/CDに置き換えるなら、AIが一次レビューを済ませ、人間が設計とロジックに集中する、という分担になります。

自動マージはおすすめしません

技術的には、AIレビューが通ったら自動でマージする構成も組めます。ただし、この形はおすすめしていません。AIの指摘が網羅的であることと、変更が事業として正しいことは別の話だからです。

• 特に注意する変更 ── 決済・認証・顧客データに触れる変更は、規模にかかわらず人間の承認を挟む設計にしておくのが安全です
• HubSpotのワークフローと同じ構造 ── AIにメール送信を任せるかどうかの議論と同じで、下書きまでは任せ、送信ボタンは人が押します

CI/CDでも、マージという不可逆な操作は人が押す、と決めておくと運用が安定します。

指摘の質を上げるのはプロンプトの改善

AIレビューの精度が物足りないとき、多くの場合はモデルではなくプロンプトと基準ファイルに原因があります。「レビューしてください」だけでは一般論しか返ってきません。

次を CLAUDE.md に書き足していくと、指摘が自社の文脈に寄っていきます。

• 自社のコーディング規約
• 禁止しているライブラリ
• 過去に事故が起きたパターン

ここは一度作って終わりではなく、四半期に一度程度は見直したい部分です。

的外れだった指摘、逆に見逃された不具合を記録しておき、基準ファイルに反映していく。この改善ループを回す担当を決めることが、長く使えるパイプラインの条件になってきます。

パイプライン設計で押さえる実行時間とコストの制御

AIレビューは、入れた瞬間はうまくいっても、PR数が増えるにつれて実行時間とコストが効いてきます。設計段階で上限を決めておくと、後から重くなって止める、という展開になりにくくなります。

実行時間の制御

CI/CDにおけるAIレビューの目標レイテンシは3〜5分以内が目安です。

これを超えると、開発者がレビュー結果を待たずに次の作業へ移ってしまい、フィードバックが読まれなくなります。以下の設定で実行時間を制御します。

長時間のレビューが必要な大規模PRは、変更ファイル数で分割してジョブを並列化するのが効果的です。

そもそもPRが大きすぎる場合は、パイプラインの設定より先にPRの粒度を見直したほうが早いこともあります。

APIコストの管理

CI/CDでのClaude Code利用は、PR数に比例してAPIコストが増加します。コスト管理のポイントは以下のとおりです。

• トリガーの制限 — 全PRではなく、特定のラベルが付いたPRのみレビュー
• パスフィルタ — ドキュメント変更のみのPRはスキップ
• 時間帯制限 — 営業時間内のPRのみ自動レビュー
• 日次予算 — API利用額に日次上限を設定
• max_turnsの制限 — 不要な往復を抑制（3〜5ターンが目安）

最初から全PR対象にするのではなく、特定のラベルが付いたPRだけを対象に始めると、コストの実測値を見ながら範囲を広げられます。1ヶ月動かせば、自社のPR規模での費用感がつかめるはずです。

APIキーの管理

ANTHROPIC_API_KEY はリポジトリのSecretsまたは組織レベルのSecretsに保存します。

• 平文で出力しない ── ワークフローの入力パラメータやログに平文でキーが出力されないよう注意が必要です
• harden-runnerの併用 ── StepSecurityの harden-runner を併用すれば、GitHub Actionsランナー自体のセキュリティも強化できます

セキュリティ面の詳細な対策については、Claude Codeの企業導入セキュリティガイドを参照してください。

GitLab CI・JenkinsでのCI/CD自動化

GitHub以外のCIツールを使っているチームでも、ヘッドレスモードを使えば同じ設計を再現できます。公式Actionのような統合機能はありませんが、レビューの実行そのものはCLIで完結するため、移植性は高い構成です。

ツールが変わっても「基準はCLAUDE.mdに置く、実行はCLIで完結させる」という考え方自体は変わりません。

GitLab CIでの構成

GitLab CIでは、ヘッドレスモードを使ってジョブ内でClaude Codeを実行します。

code_review:
  stage: review
  script:
    - npm install -g @anthropic-ai/claude-code
    - git diff origin/main...HEAD | claude -p "この差分をレビューしてください" \
        --output-format json \
        --no-user-prompt \
        --allowedTools "Read,Grep,Glob" > review.json
  artifacts:
    paths:
      - review.json

--no-user-prompt と --allowedTools を組み合わせることで、非対話的かつ安全にCI環境で実行できます。

• 結果を残す ── review.json としてアーティファクトに残しておけば、後続ジョブでMRへのコメント投稿などに使えます
• 導入前に見込むこと ── GitHub Actionsのような自動コメント機能は無いため、この後続ジョブを自前で組む一手間が発生します

Jenkinsでの構成

JenkinsではPipelineスクリプト内で sh ステップとしてClaude Codeを呼び出します。

• APIキーの管理 ── Credentialsプラグインで管理し、withCredentials ブロック内で環境変数として注入するのが安全です
• 組み込み方 ── GitLab CIと同様、実体はヘッドレスモードのコマンドをシェルで呼ぶだけなので、既存のPipelineスクリプトに1ステップ追加する形で組み込めます

すでに動いているPipelineの構造を変える必要が無いため、導入の心理的なハードルは低い部類だと考えています。

ツール選定は「今あるもの」を起点に

どのCIツールが優れているかという議論よりも、すでにチームが日常的に使っているツールの上にAIレビューを載せるほうが定着しやすいと考えています。

• 新しいツールを導入した場合 ── AIレビューの評価とツールの評価が混ざってしまい、うまくいかなかったときに原因が切り分けられません
• 企業様によって最適な形は異なります ── 既存のパイプラインに1ステップ足すところから始めるのが無難です

HubSpot開発におけるCI/CD自動化への応用

Claude CodeによるCI/CD自動化は、一般的なWebアプリ開発だけでなく、HubSpot周辺の開発にも応用できます。

HubSpotのテーマ開発やAPI連携の品質担保にAIを組み込む設計は、開発体制を持つ企業様であれば検討の余地があります。

HubSpot CMS開発のCI/CD

Content Hubのテーマ開発では、テンプレートやモジュールの変更をClaude Codeでレビューし、HubL（HubSpotのテンプレート言語）の構文エラーやアクセシビリティの問題を自動検出できます。

• HubLは拾いにくい領域 ── HubSpot固有のテンプレート言語のため、一般的な静的解析ツールでは拾いにくい領域です
• 自社固有の文脈 ── こうした文脈こそ、CLAUDE.md に規約を書いてAIに参照させる価値が出てきます

HubSpot API連携開発のCI/CD

HubSpot API連携アプリの開発では、次などを自動化できます。

• APIレスポンスのスキーマ変更検知
• エラーハンドリングのチェック
• レート制限への対応漏れの検出
• 全体の自動化 ── AI駆動開発の全体像と組み合わせることで、開発プロセス全体の自動化が実現します

ここで意識したいのは、CI/CDの自動化が「コンタクト→取引→顧客→請求」という業務フロー全体のどこを支えているかという視点です。

API連携の実装ミスは、HubSpot上のデータ不整合として現れ、最終的にはレポートの信頼性やフォーキャストの精度に影響します。開発工程の品質担保は、実は営業・経営が見る数字の品質担保につながっています。

自社に合わせた設計に落とす

HubSpotを使った開発体制は、次のように企業様によって大きく異なります。

• 社内にエンジニアがいる企業様
• 外部パートナーと組む企業様
• ノーコード中心で運用する企業様

企業様によって最適な形は異なりますので、ここで挙げたパターンをそのまま適用するというより、自社のリリース頻度と体制に合わせて取捨選択いただくのがよいでしょう。

社内にエンジニアが少ない企業様であれば、まずはドキュメント同期のような影響範囲の小さいユースケースから試すのが現実的です。

実運用でのCI/CD自動化活用事例

公開されている事例を見ると、AIをCIに組み込む狙いは「速度」より「メンテナの負荷分散」にあることがうかがえます。

人を増やせない中で品質を保つ手段として選ばれているのが実態です。

Shopifyのオープンソース開発

Shopifyは、オープンソースプロジェクトでClaude Code Actionを導入し、外部コントリビューターからのPRの初期レビューを自動化しています。

CIでの自動レビューにより、メンテナの負荷を軽減しつつ、PRのフィードバックまでの待ち時間を短縮できたというケースが報告されています。

Netlifyのドキュメント自動更新

Netlifyは、コードの変更に連動してドキュメントの不整合を検出するCIワークフローを構築しています。

• 検出 ── APIの変更とドキュメントのずれを自動検出します
• 修正 ── 修正PRを自動生成するパイプラインにより、ドキュメントの鮮度を維持しています

ドキュメントの更新は後回しになりやすい作業であるだけに、コードの変更をトリガーにする設計は、人の善意に頼らない仕組み化の例として参考になります。

どちらの事例にも、次の共通点があります。

• AIに最終判断を委ねない ── 人間が確認する対象を絞り込むために使っている点が共通しています
• 自動化の目的 ── 「人を減らすこと」ではなく「人が見るべきものを減らすこと」に置くと、設計の判断がぶれにくくなります

よくある質問

Q1. GitHub Actions以外のCIツールでもClaude Codeを使えますか？

はい、ヘッドレスモード（-p / --print フラグ）を使えば、GitLab CI、Jenkins、CircleCI、Azure DevOpsなど、任意のCIツールで利用できます。--no-user-prompt フラグでパイプラインのブロックを防止し、--allowedTools で実行可能なツールを制限することで、安全な非対話実行が可能です。公式GitHub Actionの恩恵（PR自動コメントなど）を受けたい場合はGitHub Actionsが最も統合度が高いですが、基本的なレビュー機能はどのCIツールでも実現できます。

Q2. CI/CDでのClaude Code利用コストはどの程度ですか？

コストはPRの規模と頻度に依存するため、一概には言えません。max_turnsとmax_tokensを適切に設定し、パスフィルタやラベルによるトリガー制限を併用することでコストを制御できます。まずは特定のラベルが付いたPRだけを対象に1ヶ月運用し、自社のPR規模での実測値をつかんでから対象範囲を広げるのが現実的です。

Q3. Claude Codeの自動レビューで人間のレビューは不要になりますか？

不要にはなりません。自動レビューは人間のレビューの補助として位置づけるのが適切です。構文チェック、一般的なバグパターン、セキュリティリスクの検出はAIが得意な領域ですが、ビジネスロジックの妥当性やアーキテクチャ判断は人間が担うべき領域です。AIが一次的な問題を処理することで、人間のレビューアが設計やロジックに集中できるようになります。

Q4. プライベートリポジトリのコードがAnthropicに送信されるのは問題ないですか？

Anthropicの標準ポリシーでは、API経由で送信されたコードはモデル学習に使用されません。Enterpriseプランではゼロデータリテンション（ZDR）が契約で保証されます。さらに懸念がある場合は、サンドボックスのネットワーク隔離でAnthropicのAPIエンドポイント以外への通信をブロックする構成が考えられます。加えて、何をCIに読ませてよいかという社内ルールを文書化しておくことをおすすめします。

Q5. 既存のCIパイプラインにClaude Codeを追加する工数はどの程度ですか？

GitHub Actionsの場合、基本的なPRレビュー自動化は比較的短時間で導入できます。/install-github-app コマンドで自動セットアップすれば、ワークフローYAMLの手動記述も最小限で済みます。ただし、実運用に耐える構成にするには、カスタムレビュー基準の設定やパス別ルールの設計が必要で、ここは自社の規約をどれだけ言語化できているかによって所要時間が変わります。

Q6. --output-formatのjsonとstream-jsonの使い分けは？

json は処理完了後に全結果を一括で出力するため、jq などでの後処理やパイプラインの後続ステップへのデータ受け渡しに適しています。stream-json はトークン単位でリアルタイムに出力されるため、長時間の処理中に進捗を確認したい場合や、ストリーミングで結果を表示するダッシュボードとの連携に向いています。通常のCI/CDパイプラインでは json を選ぶのが無難です。

まとめ

Claude CodeをCI/CDに組み込む設計のポイントを振り返ります。

• ヘッドレスモード（-p / --print）と --no-user-prompt、--allowedTools の組み合わせが土台であり、GitHub Actions・GitLab CI・Jenkinsのいずれでも同じ考え方で構成できます
• 出力フォーマットは text / json / stream-json の3種類。後続ステップにデータを渡すならjson形式が扱いやすくなります
• 自動化できるユースケースは、PRレビュー・セキュリティ監査・テスト生成・Changelog生成・ドキュメント同期・Issueトリアージの6つ。全部を一度に入れず、効果が見えやすいものから足していきます
• AIに任せるのは「コードを読めば判断できること」、人間が引き取るのは「事業の事情を知らないと判断できないこと」。マージという不可逆な操作は人が押す設計にします
• レビュー基準を CLAUDE.md としてバージョン管理すれば、個人の力量に依存せず、新人でも同じ基準でレビューを受けられる仕組みになります

まずは1リポジトリ・PRレビュー1本から始めるのが現実的です。次の3ステップで進めてみてください。

1. 自社のレビューで毎回指摘している観点を3〜5個書き出し、CLAUDE.md に落とす
2. 特定のラベルが付いたPRだけを対象に、公式GitHub Actionで自動レビューを1本動かす
3. 1ヶ月運用してコストと指摘の質を実測し、対象範囲とプロンプトを見直す

いきなり全リポジトリに展開するのではなく、1本で効果と費用感を確かめてから段階的に広げる進め方が、結果的に定着しやすくなります。

CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお気軽にお問い合わせください。

あわせて読みたい

• Claude Codeでチーム開発を効率化する方法
• Claude Codeの/rewindコマンド｜失敗した変更を安全にロールバックする方法
• Claude Code × Chatwork連携｜顧客コミュニケーションを自動化する方法
• Claude Code MCP連携の始め方
• Claude Code実践ガイド