SaaS・IT

【2026年最新】Claude Codeでコード品質の自動計測・改善ガイド

公開 2026年7月3日更新 2026年7月7日

Claude Codeを使えば、循環的複雑度やコード重複率などの品質指標を自動計測し、CLAUDE.mdでチーム標準化してCI/CDに組み込める。5つの指標×7ステップでコードベースの健康状態を可視化する実践手法を解説。

結論：Claude Codeでコード品質を上げる実務設計は、「品質メトリクスをリポジトリ側で定義し、Claude Codeに計測・原因分析・修正案・再検証を回させる」形がいちばん安定します。

要点1：Claude Code公式ドキュメントでは、コードベース読解、ファイル編集、コマンド実行、hooks、Code Review、GitHub Actions、OpenTelemetry/Analytics連携が確認できます。
要点2：lint、typecheck、test、coverage、complexity、security scan、review findingsは、まずCIとローカルコマンドで再現可能にします。
要点3：自動改善は「format/lintの小修正」から始め、仕様変更やセキュリティ・個人情報・課金に関わる変更はplan modeと人間レビューを挟みます。

対象読者：Claude Codeを開発チームに導入し、品質計測と改善のループを作りたいエンジニア、EM、PM、SRE、QA担当者。

今日やること：まずリポジトリに npm run quality や make quality のような単一入口を作り、Claude Codeに「このコマンドを通すまで原因分析と修正を続けて」と依頼できる状態にします。

「Claude Codeで品質改善を自動化したいんですが、何を測ればいいですか？」

この相談でよく起きるのが、いきなり「Claude Codeに全部直してもらう」方向へ進んでしまうことです。正直、それだと最初の数回は気持ちよく動いても、チームで運用した瞬間に詰まります。なぜなら、何をもって品質が上がったのか、どの修正を自動化してよいのか、誰が最終判断するのかが曖昧なままだからです。

本記事は、実在企業の成果数値ではなく、実装パターン解説として書いています。サンプルの閾値や改善量は、導入時にそのまま保証される数値ではありません。あなたのリポジトリ、CI時間、障害リスク、レビュー文化に合わせて調整してください。

前提として、Claude Codeは公式ドキュメント上で「コードベースを読み、ファイルを編集し、コマンドを実行し、開発ツールと統合するagentic coding tool」と説明されています。つまり、品質メトリクスを内蔵の魔法として扱うのではなく、既存の品質ツールをClaude Codeの作業ループに接続するのが本筋なんです。

全体像：Claude Codeで作る品質改善ループ

コード品質の自動計測・改善は、次の7ステップに分けると運用しやすくなります。

品質メトリクスを決める：lint、typecheck、test、coverage、complexity、security、レビュー指摘数などを定義する。
単一コマンド化する：npm run quality、make quality、scripts/quality.sh のように入口を一本化する。
CLAUDE.mdに品質ルールを書く：Claude Codeが毎回読む前提ルールとして、修正前後の確認手順を明記する。
hooksで軽い検査を自動実行する：ファイル編集後にformatやlintを走らせ、失敗を早く見つける。
/code-reviewで差分のリスクを読む：単なる整形ではなく、ロジックエラーや回帰リスクを見る。
CI/GitHub Actionsで再現する：Claude Codeの手元だけでなく、PR上でも同じ品質ゲートを通す。
メトリクスを保存する：改善前後のJSON、JUnit、coverage、check run、OpenTelemetryやAnalyticsを追える状態にする。

関連する基礎設定は、当サイトの Claude Code settings.json設定ガイドと Claude Code hooks自動化ガイドでも扱っています。この記事では、そこに「品質メトリクス」という軸を足して、より実務寄りに組み直します。

まず決めるべき品質メトリクス

品質メトリクスは、多ければよいわけではありません。最初は「PRを安全にマージできるか」を判断できる最小セットで十分です。

カテゴリ	見る指標	代表ツール	Claude Codeに任せる作業
静的解析	lint error、warning数	ESLint、Ruff、golangci-lint	原因箇所の特定、機械的修正、ルール違反の説明
型安全性	typecheckエラー数	TypeScript、mypy、pyright	型の不整合を差分単位で修正
テスト	failed tests、flaky tests、実行時間	Vitest、Jest、pytest、JUnit	失敗ログを読み、回帰原因を絞る
カバレッジ	statement/branch/function coverage	Istanbul、coverage.py、JaCoCo	足りない分岐のテスト案を作る
複雑度	cyclomatic complexity、関数行数	eslint complexity、radon、lizard	関数分割、責務分離、既存helper再利用を提案
セキュリティ	secret混入、危険な依存、権限漏れ	gitleaks、npm audit、Semgrep	検出結果の優先度整理と修正案作成
レビュー品質	Important/Nitの指摘数、再発数	Claude Code Code Review、GitHub check run	差分のロジックリスクを読み、修正を適用

ここで大事なのは、Claude Codeに品質の定義を丸投げしないことです。品質基準はチームが決め、Claude Codeはその基準に沿って探索・修正・再検証する役割に置きます。

Step 1：品質チェックを単一コマンドにまとめる

まず、Claude Codeが迷わず実行できる「品質の入口」を作ります。TypeScriptプロジェクトなら、たとえば次のような構成です。

{
  "scripts": {
    "quality:format": "prettier --check .",
    "quality:lint": "eslint . --max-warnings=0",
    "quality:typecheck": "tsc --noEmit",
    "quality:test": "vitest run --coverage",
    "quality": "npm run quality:format && npm run quality:lint && npm run quality:typecheck && npm run quality:test"
  }
}

Pythonなら make quality でも構いません。

.PHONY: quality
quality:
	ruff check .
	ruff format --check .
	pyright
	pytest --cov=src --cov-report=xml --junitxml=reports/junit.xml

この段階でClaude Codeに投げる最初のプロンプトは、修正ではなく「観察」です。

このリポジトリの品質チェック入口を確認してください。
package.json、Makefile、CI設定、README、CLAUDE.mdを読み、現在のlint、format、typecheck、test、coverageの実行方法を一覧化してください。
不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず「仮定」と明記してください。

実はここを飛ばすと、Claude Codeが npm test だけ通して「完了」と判断したり、逆に存在しないコマンドを推測して遠回りしたりします。品質改善は、最初の入口設計でかなり決まります。

Step 2：CLAUDE.mdに品質ルールを置く

Claude Code公式ドキュメントでは、CLAUDE.md はプロジェクトルートに置くMarkdownファイルで、セッション開始時にClaude Codeが読むものとして説明されています。コーディング標準、アーキテクチャ判断、推奨ライブラリ、レビュー観点を書けます。

品質改善用には、抽象的な「きれいなコードを書いて」ではなく、検証可能なルールを書きます。

# Claude Code Instructions

## Quality Gate
- 変更前に関連ファイルと既存テストを読む。
- 実装後は原則として `npm run quality` を実行する。
- 失敗した場合は、最初に失敗ログを要約し、原因候補を3つ以内に絞る。
- lintやformatだけで直せる変更は小さく修正する。
- public API、DB schema、認可、課金、個人情報処理に関わる変更は、修正前にplan modeで方針を提示する。

## Test Policy
- 新しい分岐を追加した場合は、正常系だけでなく失敗系のテストも追加する。
- snapshot更新は、差分の意味を説明できる場合だけ行う。
- flaky testを見つけた場合は、単にリトライ回数を増やす前に原因を調べる。

## Reporting
- 最終回答では、実行したコマンド、結果、未検証の項目を分けて書く。

公式ドキュメントでは、CLAUDE.md は現在の作業ディレクトリから親ディレクトリへ遡って読み込まれ、CLAUDE.local.md も併せて扱えます。モノレポでは、ルートに共通ルール、各package配下に個別ルールを置くと、品質ゲートを細かく調整できます。

プロジェクト記憶の設計については、Claude CodeのCLAUDE.md設計ガイドもあわせて読むと、チーム内でのルール衝突を避けやすくなります。

Step 3：REVIEW.mdでレビュー観点を絞る

Claude CodeのCode Reviewは、GitHub PR上の自動レビューだけでなく、ローカルの /code-review コマンドでも使えます。公式ドキュメントでは、Code Reviewはロジックエラー、セキュリティ脆弱性、回帰などを見る仕組みとして説明され、CLAUDE.md や REVIEW.md で挙動を調整できます。

品質改善で特に効くのは、REVIEW.md で「何をImportantとするか」を明確にすることです。

# REVIEW.md

## Important
Report as Important only when the change may:
- break production behavior
- skip authorization or tenant scoping
- leak personal data, credentials, request bodies, or tokens
- make rollback difficult
- change public API behavior without tests or migration notes

## Nit
Report as Nit when the issue is:
- naming clarity
- duplicate helper logic
- overly broad try/catch
- missing small refactor opportunity

## Do not report
- Formatting already enforced by CI
- Generated files
- Lockfiles unless they introduce dependency risk
- Test-only fixtures that intentionally duplicate data

## Evidence
Every behavior claim should cite the relevant file and line, or explain why the evidence is indirect.

これで、Claude Codeのレビュー指摘が「好みのコメント」に寄りすぎるのを防げます。CIがすでに見ているformatやlintをレビューで繰り返さず、人間レビューが見落としやすいロジック・権限・データ境界に集中させるイメージです。

Step 4：Claude Codeの操作は「plan → fix → verify」に分ける

Claude Codeには、セッション内で使えるコマンドが多数あります。品質改善で最初に覚えるべきなのは、/plan、/code-review、/simplify、/verify、/diff です。

場面	使う操作	狙い
大きめの修正前	`/plan`	調査と方針提示に止め、いきなり編集させない
差分レビュー	`/code-review high`	ロジックエラーや回帰リスクを探す
レビュー指摘の適用	`/code-review --fix`	見つかった指摘を作業ツリーへ反映する
整理だけしたい	`/simplify`	バグ探索ではなく、再利用・単純化・効率化に寄せる
動作確認	`/verify`	テストや型チェックだけでなく、変更が意図通り動くか確認する

実務では、次のように頼むと安定します。

/plan
`npm run quality` が失敗しています。
まず失敗ログを読み、原因を分類してください。
修正はまだ行わず、次の形式で計画を出してください。
1. 失敗している品質ゲート
2. 影響範囲
3. 直す順番
4. 自動修正してよい箇所
5. 人間確認が必要な箇所
不足している情報があれば、最初に質問してから作業を開始してください。

この一手間がかなり効きます。特に、型エラーを直すつもりでpublic APIを変えてしまう、テストを通すために期待値だけ雑に更新してしまう、といった事故を避けやすくなります。

Step 5：hooksで編集後の軽い品質チェックを自動化する

Claude Code公式ドキュメントでは、hooksは特定のライフサイクルで自動実行されるユーザー定義のshell command、HTTP endpoint、LLM promptなどとして説明されています。代表的なイベントには PreToolUse、PostToolUse、Stop などがあります。

品質改善で使いやすいのは、Edit や Write の後に軽い検査を走らせる PostToolUse hookです。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/quality-after-edit.sh",
            "timeout": 120,
            "statusMessage": "Running lightweight quality checks"
          }
        ]
      }
    ]
  }
}

hook本体は、最初は軽くします。

#!/usr/bin/env bash
set -euo pipefail

mkdir -p reports

if [ -f package.json ]; then
  if npm run --silent quality:format; then
    echo "format:pass" >> reports/claude-quality-events.log
  else
    echo "format:fail" >> reports/claude-quality-events.log
    exit 2
  fi

  if npm run --silent quality:lint; then
    echo "lint:pass" >> reports/claude-quality-events.log
  else
    echo "lint:fail" >> reports/claude-quality-events.log
    exit 2
  fi
fi

ここでフルテストまで毎回走らせるかは慎重に決めます。小規模リポジトリなら問題ありませんが、10分以上かかる統合テストを編集のたびに走らせると、Claude Codeの探索が鈍ります。hooksは「早期検知」、CIは「最終判定」と分けるのが現実的です。

より詳しいhook設計は、Claude Code hooksでformat・test・通知を自動化する実践ガイドで掘り下げています。

Step 6：品質メトリクスをJSONで保存する

「改善した気がする」では、チームに展開できません。最低限、品質ゲートの結果をJSONやJUnit XMLで保存します。

{
  "generated_at": "2026-07-07T00:00:00Z",
  "commit": "local-working-tree",
  "quality": {
    "format": "pass",
    "lint_errors": 0,
    "type_errors": 0,
    "failed_tests": 0,
    "coverage_statements": 82.4,
    "coverage_branches": 71.8,
    "security_findings": {
      "critical": 0,
      "high": 0,
      "medium": 2
    }
  },
  "notes": [
    "coverage thresholds are team-defined examples, not universal pass criteria",
    "manual review is still required before merging"
  ]
}

このJSONは、Claude Codeが読むためにも、人間が比較するためにも使えます。たとえば次のように依頼します。

reports/quality-before.json と reports/quality-after.json を比較してください。
改善した項目、悪化した項目、判断保留の項目を分けてください。
数値の差分は表にし、悪化した項目については原因候補と次の確認コマンドを提案してください。
数字と固有名詞は、根拠となるファイル名または計算式を添えてください。

この形にしておくと、Claude Codeの最終回答も「lintが通りました」だけではなく、「何がどう変わったのか」を説明しやすくなります。

Step 7：GitHub ActionsでPR上の自動改善を作る

Claude Code GitHub Actionsは、公式ドキュメント上で @claude メンションに応じた実装、PR作成、bug fixなどに使える仕組みとして説明されています。Action v1では anthropics/claude-code-action@v1 を使い、prompt と claude_args で指示やCLI引数を渡せます。

品質改善用の最小例は、次のような形です。

name: Claude Quality Assist

on:
  pull_request:
    types: [opened, synchronize]
  issue_comment:
    types: [created]

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

jobs:
  claude-quality:
    if: github.event_name == 'pull_request' || contains(github.event.comment.body, '@claude')
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run quality
        continue-on-error: true
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            This pull request has quality gate results from `npm run quality`.
            Analyze failures, propose minimal fixes, and update the PR only when the change is mechanical and low risk.
            Do not change public API behavior, authorization, billing, data retention, or migration files without explaining the risk first.
          claude_args: |
            --max-turns 5
            --allowedTools "Read" "Bash(npm run quality*)" "Bash(npm test*)" "Edit" "Write"

セキュリティ上、API keyはGitHub Secretsで扱い、リポジトリに直書きしません。公式ドキュメントでも、GitHub Actions利用時はSecretsを使い、必要最小限の権限にすることが推奨されています。

CI/CD全体の設計は、Claude CodeでCI/CDパイプラインを自動化するガイドと Claude CodeのQA・テスト自動化ガイドも参考になります。

Code Reviewを品質メトリクスに含める

Claude CodeのCode Reviewは、単なるlintではありません。公式ドキュメントでは、PR差分とコードベース文脈を使い、ロジックエラー、セキュリティ脆弱性、壊れたedge case、微妙な回帰を探すと説明されています。

ただし、重要な注意点があります。Code Reviewのcheck runは既存のレビュー運用を壊さないよう、マージを直接ブロックしない中立的な結論として扱われる設計です。したがって、「Code Reviewがあるから人間レビュー不要」ではありません。むしろ、レビュー前の下ごしらえと、レビュー後の再発防止に使うのが現実的です。

ローカルでは、次の順番が扱いやすいです。

/code-review high

見つかったImportantだけを優先してください。
Nitは最大5件までに絞り、CIで既に検出されるformatやlintは指摘しないでください。
各指摘について、根拠となるファイルと行、想定される失敗条件、最小修正案を出してください。

修正まで任せる場合は、対象を絞ります。

/code-review --fix

Importantのうち、テスト追加または局所的なロジック修正で解決できるものだけ適用してください。
public API、DB schema、認可、課金、個人情報処理に関わる変更は適用せず、計画だけ出してください。
修正後に `npm run quality` を実行し、結果を要約してください。

コードレビュー効率化の観点は、Claude Codeコードレビュー効率化ガイドでも扱っています。

OpenTelemetryとAnalyticsで「Claude Codeの使われ方」も見る

コード品質のメトリクスと、Claude Code利用状況のメトリクスは分けて考えます。coverageやlint errorはリポジトリの品質メトリクスです。一方、Claude Codeの利用回数、受け入れられた編集、セッション、token/cost、tool実行などは、運用メトリクスです。

公式ドキュメントでは、Claude CodeのMonitoringでOpenTelemetry exportを設定でき、メトリクス、ログ、traces、cardinality制御に関する環境変数が説明されています。またAnalyticsでは、Team/Enterprise向けにusage metrics、contribution metrics、leaderboard、CSV exportなどが紹介されています。

実務上は、次のように分けます。

見たいもの	保存先	判断に使うこと
lint/test/coverage	CI artifacts、reports配下、品質DB	PRを安全にマージできるか
Code Review指摘数	GitHub check run、PRコメント	回帰リスクやレビュー負荷が増えていないか
Claude Code利用状況	Analytics、OpenTelemetry backend	どのチームが使いこなしているか、コストが膨らんでいないか
hookの失敗	hook log、OTel log、CI summary	自動化が開発体験を悪化させていないか

Claude Codeの利用量が増えているのに、テスト失敗やレビュー指摘が減らない場合、ツールの問題ではなく、品質ルールやプロンプト設計が曖昧な可能性があります。

そのまま使える品質改善プロンプト7選

ここからは、実務で使いやすいプロンプトです。全てに「不足情報があれば質問」「仮定は仮定と明記」を入れてあります。

1. 品質メトリクス棚卸し

このリポジトリの品質メトリクスを棚卸ししてください。
対象はlint、format、typecheck、unit test、integration test、coverage、security scan、CI workflowです。
各項目について、実行コマンド、設定ファイル、出力形式、現在の閾値、足りない点を表で整理してください。
不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず「仮定」と明記してください。

2. qualityコマンド作成

このリポジトリに `quality` コマンドを追加してください。
既存のlint、format、typecheck、testコマンドを尊重し、新しいツールを増やす場合は理由を説明してください。
変更後、READMEまたはCLAUDE.mdに実行方法を追記してください。
不足している情報があれば、最初に質問してから作業を開始してください。

3. lintエラーの最小修正

`npm run quality:lint` の失敗を最小差分で修正してください。
ルールを無効化する前に、コード側で直せるか検討してください。
自動生成ファイルや外部ライブラリ由来の問題は、修正対象から外す提案をしてください。
修正後に同じコマンドを再実行し、結果を報告してください。

4. 型エラーの原因分析

`npm run quality:typecheck` の失敗ログを読み、原因を分類してください。
型定義の不足、実装の不整合、仕様変更、テストfixtureの古さを分けてください。
public APIを変える修正は適用せず、先に計画を出してください。
不足している情報があれば、最初に質問してから作業を開始してください。

5. カバレッジ不足のテスト追加

coverage reportを読み、未テストの重要分岐を3つまで選んでください。
単にcoverage率を上げるのではなく、回帰リスクが高い順にテストを追加してください。
テスト名には、守りたい仕様が分かる名前を付けてください。
数字と固有名詞は、根拠となるreportファイルまたは計算式を添えてください。

6. Code Review指摘の修正

/code-review high の指摘を読み、Importantのみ対応してください。
各指摘について、原因、修正方針、変更ファイル、検証コマンドを示してから修正してください。
Nitは今は修正せず、最後に別リストで残してください。
認可、課金、個人情報、DB migrationに関わる変更は適用前に確認してください。

7. 改善前後のレポート作成

今回の品質改善の前後比較レポートを作ってください。
対象はquality commandの結果、テスト失敗数、coverage、Code Review指摘、未解決リスクです。
改善した点、変わらない点、悪化した点を分けてください。
未検証の項目は「未検証」と明記し、確認コマンドを添えてください。

自動修正してよい領域・止めるべき領域

Claude Codeの自動改善は便利ですが、全てを同じ強さで任せると危険です。自動化の境界を先に決めます。

領域	自動修正の向き不向き	運用ルール
format	向いている	formatterに任せ、レビューでは扱わない
lintの機械的修正	向いている	ルール無効化は理由を必須にする
型エラー	中程度	public API変更はplan modeへ回す
テスト追加	中程度	仕様を変えず、既存挙動を保護するテストを優先
リファクタリング	範囲次第	小さな関数分割まで。設計変更はレビュー必須
認可・課金・個人情報	止めるべき	人間レビュー、セキュリティレビュー、組織規程を優先
DB migration	止めるべき	rollback、互換性、データ移行計画を別途確認

Claude Code公式ドキュメントのpermission modesでは、plan mode、auto mode、accept editsなどの使い分けが説明されています。特にauto modeは便利ですが、公式にもresearch previewとして位置づけられており、安全性を保証するものではありません。品質改善でも、強い自動化ほどレビューと権限設計を厚くします。

チーム運用の権限設計は、Claude Code権限設計チームガイドと Claude Code企業セキュリティチェックリストをあわせて確認してください。

よくある失敗パターンと回避策

失敗1：品質メトリクスをClaude Codeに決めさせる

NG：「このリポジトリの品質をいい感じに改善して」

OK：「lint errorを0、typecheckをpass、unit testをpassにしてください。coverageは今回は改善対象外です」

品質はチームの判断基準です。Claude Codeはその基準に沿って動く補助ツールであり、基準そのものを勝手に決める存在ではありません。

失敗2：coverageだけを追う

NG：「coverageを80%以上にしてください」

OK：「決済キャンセル、権限エラー、外部API失敗の分岐を優先してテストしてください。coverageは副次指標として見ます」

coverageは便利ですが、数字だけを追うと、意味の薄いテストが増えます。品質改善では「壊れたら困る仕様」を先に守ります。

失敗3：hookで重すぎる検査を走らせる

NG：編集のたびに全E2E、全integration test、全security scanを走らせる。

OK：PostToolUseではformat/lint、StopやCIではunit/integration/security scanに分ける。

自動化は、開発体験を悪化させた瞬間に使われなくなります。早い検査と重い検査を分けるだけで、継続率がかなり変わります。

失敗4：自動修正PRをそのままマージする

NG：Claude Codeが直したので、CI passだけ見てmergeする。

OK：CI pass、Code Review、差分レビュー、必要に応じた人間のドメインレビューを通す。

AIは補助ツールであり、最終判断者ではありません。特にセキュリティ、個人情報、金融、医療、採用、行政、契約に関わる処理では、専門家・責任者・所属組織の規程に従ってください。

導入ロードマップ：1週間で始めるなら

最初から全自動にしなくて大丈夫です。1週間で始めるなら、次の順番が現実的です。

日程	やること	完了条件
Day 1	既存のlint/test/typecheckを棚卸し	品質チェック一覧ができている
Day 2	`quality` コマンドを作る	ローカルとCIで同じ入口が使える
Day 3	`CLAUDE.md` に品質ルールを書く	Claude Codeが検証手順を迷わない
Day 4	`REVIEW.md` を作る	ImportantとNitの基準が明文化されている
Day 5	軽いPostToolUse hookを入れる	編集後にformat/lintの失敗が早く見える
Day 6	GitHub Actionsで品質補助を試す	PR上で品質失敗の分析コメントが出せる
Day 7	1つのPRで改善前後を記録する	品質レポートと未解決リスクが残っている

この時点で「手動でやっていた品質確認が、Claude Codeに説明可能な手順になった」なら成功です。いきなり完全自動化を狙うより、まず再現可能な品質ゲートを作る方が堅いです。

FAQ

Q1. Claude Codeだけでコード品質メトリクスを自動計測できますか？

Claude Codeはコードを読み、編集し、コマンド実行やhooks、GitHub Actions、Code Review、OpenTelemetry連携を使えます。ただしlint、coverage、complexityなどの品質メトリクスは、リポジトリ側のテストツールや計測スクリプトで定義し、Claude Codeに実行・集計・改善を任せる設計が現実的です。

Q2. 自動修正はどこまで任せてよいですか？

format、lintの機械的修正、未使用import削除、単純な型エラー修正は任せやすい領域です。仕様変更、DBマイグレーション、権限、課金、個人情報処理に関わる修正はplan modeやレビューを挟み、所属組織のルールに従ってください。

Q3. hooksで毎回テストを走らせるべきですか？

毎回フルテストを走らせると待ち時間とコストが増えます。PostToolUseではformatや対象ファイル周辺のlintなど軽い検査に絞り、StopやCIで統合テストを走らせるなど、段階を分けるのが扱いやすいです。

Q4. Claude CodeのCode ReviewとCIの違いは何ですか？

CIは決められたコマンドの成否を機械的に判定します。Claude CodeのCode Reviewは差分と周辺コードを読み、ロジックエラー、セキュリティリスク、回帰の可能性を指摘します。CIを置き換えるのではなく、CIの前後で補完する位置づけです。

Q5. チーム導入では最初に何を設定すべきですか？

最初にCLAUDE.mdでコーディング規約と検証コマンドを明文化し、REVIEW.mdでレビュー観点を絞ります。次にsettings.jsonで権限、hooks、sandbox、defaultModeを設計し、GitHub ActionsやCIに同じ品質ゲートを接続します。

参考・出典

Claude Code Docs Overview — Claude Code公式ドキュメント（参照日: 2026-07-07）
Hooks reference — Claude Code公式ドキュメント（参照日: 2026-07-07）
Claude Code settings — Claude Code公式ドキュメント（参照日: 2026-07-07）
Commands — Claude Code公式ドキュメント（参照日: 2026-07-07）
Code Review — Claude Code公式ドキュメント（参照日: 2026-07-07）
Claude Code GitHub Actions — Claude Code公式ドキュメント（参照日: 2026-07-07）
Monitoring — Claude Code公式ドキュメント（参照日: 2026-07-07）
Track team usage with analytics — Claude Code公式ドキュメント（参照日: 2026-07-07）
How Claude remembers your project — Claude Code公式ドキュメント（参照日: 2026-07-07）
Choose a permission mode — Claude Code公式ドキュメント（参照日: 2026-07-07）

まとめ：今日から始める3つのアクション

今日やること：quality コマンドを作り、Claude Codeに実行方法を確認させる。
今週中：CLAUDE.md と REVIEW.md に品質ルールを書き、/code-review で1つのPRを読ませる。
今月中：hooks、CI、品質レポートJSON、GitHub Actionsをつなぎ、改善前後を比較できる状態にする。

次回予告：次の記事では、Claude CodeのCode Reviewと既存CIを組み合わせ、PRごとの品質レポートを自動生成する設計をさらに具体化します。

著者：佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を展開。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載7回執筆。