はじめに

Claude Codeの /loop は、一定間隔でプロンプトやスラッシュコマンドを繰り返し実行するための機能です。
プロジェクト内レビューと組み合わせると、「差分を定期的に読み、危険な変更だけを報告する」ようなローカル自動レビューを作れます。

ただし、便利だからといって /loop に「全部レビューして」と投げるだけでは、実務では使いにくい出力になります。
自動レビューで重要なのは、AIの賢さよりも、レビュー対象・観点・成果物・停止条件を設計することです。

この記事では、/loop を使ってプロジェクト内自動レビューを作るときの設計観点を整理します。

/loopはCIではなく、ローカルで回るレビュー補助

公式のコマンド一覧では、/loop [interval] [prompt] はセッションが開いている間、プロンプトまたはコマンドを繰り返し実行する機能として説明されています。
つまり、CIのように常にサーバー側で動く仕組みではありません。

そのため、設計上は次のように位置づけるのが安全です。

• PRの正式なレビューゲートではなく、レビュー前の補助
• ローカル作業中の差分監視
• 定期的なセルフレビュー
• 人間レビューに渡す前の論点整理

自動レビューを「承認者」にしてはいけません。
/loop で作るべきなのは、レビューアーが読むための一次整理です。

まずレビュー対象を固定する

自動レビューで最初に壊れやすいのは、対象範囲です。
毎回リポジトリ全体を読ませると、処理が重くなり、出力も散ります。

おすすめは、差分を起点に対象を固定することです。

/loop 20m Review the current git diff against origin/main.
Focus only on changed files.
Do not edit files.
Report findings grouped by severity.

チームで共有するなら、これをカスタムコマンドやスキルに切り出します。

---
description: Review current project diff without editing files
argument-hint: [base-branch]
---

Review the current git diff against ${1:-origin/main}.

Rules:

- Read only changed files and directly related files.
- Do not edit files.
- Do not run destructive commands.
- Classify findings as blocker, risk, suggestion.
- Include file paths and reasons.
- If there are no findings, say so explicitly.

このように「読み取り専用」を明記すると、レビュー補助としての境界が安定します。

自動レビューで見るべき観点を絞る

プロジェクト内自動レビューでは、すべての観点を同時に見ようとしないほうがよいです。
毎回のループで確認する観点を固定すると、出力の比較がしやすくなります。

例として、次の4観点に絞れます。

ここで大事なのは、/loop に「美しいコードか」を聞かないことです。
抽象的な品質評価より、差分レビューで実際に見落としやすい観点へ絞るほうが、成果物として役に立ちます。

成果物は「修正」ではなく「レビュー報告」にする

自動レビューの失敗パターンは、AIが勝手に直し始めることです。
チーム運用では、まず報告だけに限定したほうが安全です。

Output format:

## Summary

- Review target:
- Verification status:
- Overall risk:

## Findings

### Blocker

- [file:line] Reason

### Risk

- [file:line] Reason

### Suggestion

- [file:line] Reason

## Not Checked

- Areas not reviewed and why

この形式にしておくと、人間のレビューアーが「どこから読むべきか」を判断しやすくなります。
また、毎回同じ形式で出力されるため、ループごとの差分も見やすくなります。

/loopで回す前にCLAUDE.mdへ運用ルールを書く

/loop のような繰り返し実行は、通常の1回限りの依頼よりも事故が起きやすいです。
そのため、プロジェクトの CLAUDE.md に自動レビューのルールを書いておくと安定します。

## Automated Review Rules

When running automated review loops:

- Do not edit files unless the user explicitly asks for fixes.
- Prefer read-only commands: `git diff`, `git status`, `rg`, test commands.
- Do not run deploy, migration, reset, checkout, or cleanup commands.
- Report uncertainty instead of guessing.
- Stop recommending the same finding if it was already acknowledged.

このルールは、AIのためだけではなく、人間のためにも必要です。
チームで「この自動レビューは何をしてよいのか」を共有できるからです。

失敗しやすい設計

1. 自動修正まで任せる

レビューと修正を同じループに入れると、差分が膨らみます。
最初は「報告だけ」に限定し、修正は人間が明示的に指示するほうが安全です。

2. レビュー対象を広げすぎる

リポジトリ全体を毎回見る設計は、時間も文脈も浪費します。
差分、最近変更されたファイル、指定ディレクトリのいずれかに絞ります。

3. 停止条件がない

/loop は便利ですが、止めどきが曖昧だと同じ報告を繰り返します。
「新規指摘がなければ no new findings と出す」「同じ指摘は再掲しない」などのルールを入れます。

レビューコメントに変換する観点

自動レビューの結果をそのままPRに貼るのではなく、人間のレビューコメントに変換します。

@Reviewer: 自動レビューで、今回の差分にテスト追加がない点が検出されました。
この変更はバリデーション条件を変えているため、正常系だけでなく境界値のテストも追加したほうが安全に見えます。

ポイントは、「AIが言ったから」ではなく、なぜレビュー観点として妥当なのかを人間が説明することです。

まとめ

/loop を使ったプロジェクト内自動レビューは、レビューアーの代替ではありません。
差分を定期的に読み、論点を整理し、人間レビューの入口を整えるための仕組みです。

• レビュー対象は差分や指定ディレクトリに絞る
• 成果物は修正ではなくレビュー報告にする
• CLAUDE.md に自動レビュー時の禁止事項を書く
• 出力形式を固定して、毎回比較できるようにする
• 最終判断は人間のレビューコメントに変換する

自動レビューの品質は、AIの出力だけでは決まりません。
チームがどの観点で読ませ、どこまで任せ、どこから人間が判断するかを設計できているかで決まります。

参考

• Commands - Claude Code Docs
• Claude Code power user tips - Claude Help Center