はじめに

/loop は、プロジェクト全体の自動レビューだけでなく、特定のソースコードを繰り返し読む用途にも向いています。
たとえば、認証まわりの変更、決済処理のリファクタ、テストが薄い既存コードの見直しなど、何度も確認したい箇所に対して有効です。

ただし、ソースレビューで /loop を使う場合、プロジェクト全体レビューとは設計が違います。
重要なのは、対象ファイルを狭く切り出し、同じ観点で繰り返し読み、指摘が改善されたかを確認することです。

この記事では、/loop を使ったソースレビュー方法を、実務で使える手順として整理します。

ソースレビューでは「読む範囲」を先に決める

AIにソースレビューを依頼するとき、最初に必要なのは対象範囲です。
範囲が曖昧だと、関連しそうなファイルを広く読みすぎて、指摘も散らばります。

/loop 15m Review only these files:

- src/auth/session.ts
- src/auth/permission.ts
- src/auth/session.test.ts

Focus on authorization boundary, error handling, and test gaps.
Do not edit files.

このように、読むファイルと観点を固定します。
/loop の目的は、毎回違う話をさせることではなく、同じ観点で状態変化を追うことです。

ソースレビュー用コマンドを作る

チームで繰り返し使うなら、ソースレビュー用のコマンドを定義しておくと便利です。
レガシー形式なら .claude/commands/、現在の推奨に寄せるなら .claude/skills/<name>/SKILL.md に切り出します。

---
description: Review specified source files without editing
argument-hint: [files-or-directory]
---

Review the source code specified by the user: $ARGUMENTS

Rules:

- Do not edit files.
- Read nearby tests and types only when needed.
- Focus on correctness, responsibility, boundary conditions, and maintainability.
- Prefer concrete findings over style opinions.
- Include file paths and the reason each issue matters.
- If the issue depends on missing context, mark it as "needs confirmation".

このコマンドの役割は「修正すること」ではなく「レビューの論点を安定して出すこと」です。

観点を3つまでに絞る

ソースレビューでは、観点を増やしすぎると出力が薄くなります。
1回のループでは、最大3つ程度に絞るのが扱いやすいです。

たとえば認証系なら、次のように絞ります。

  • 認可境界が呼び出し元任せになっていないか
  • エラー時に安全側へ倒れているか
  • テストが正常系だけに偏っていないか

データ更新系なら、観点は変わります。

  • トランザクション境界が曖昧でないか
  • 部分更新時に整合性が崩れないか
  • リトライ時に副作用が重複しないか

レビューの品質は、観点の数ではなく、対象コードに対して観点が合っているかで決まります。

ループで見るべき変化

/loop を使う価値は、1回目の指摘そのものよりも、修正後の再レビューにあります。
同じ観点で繰り返すことで、次の変化を確認できます。

見る変化 確認すること
指摘が解消したか 同じ問題が残っていないか
副作用が増えていないか 修正で別の責務が壊れていないか
テストが追従したか 実装変更だけで終わっていないか
新しい不明点が出たか 仕様確認が必要な箇所を残せているか

この見方にすると、/loop は単なる自動コメント生成ではなく、レビューサイクルを支える補助になります。

出力形式をレビュー向けに固定する

ソースレビューでは、指摘をそのまま人間が確認できる形式にしておくと効率が上がります。

Output format:

## Review Target

- Files:
- Focus:

## Findings

### 1. [severity] Title

- Location:
- Why it matters:
- Suggested direction:
- Confidence: high / medium / low

## Questions

- Specification points that need human confirmation

## Re-review Notes

- Previously reported issues that are now fixed
- Previously reported issues still remaining

Confidence を入れるのは重要です。
AIの指摘には、確実なものと推測が混ざります。レビューアーはその濃淡を見て、PRコメントにするか、単なる確認事項にするかを決めます。

PRコメントにする前に人間が変換する

AIのレビュー出力は、そのままPRに貼ると強すぎたり、文脈が足りなかったりします。
人間のレビューコメントに変換するときは、次のようにします。

Comment 
@Reviewer: この関数では認可済みである前提が呼び出し元に寄っているように見えます。
この層で直接チェックしない方針であれば、関数名かコメントで前提を明示したいです。
そうでなければ、ここで権限チェックを持たせたほうが変更時の事故を減らせそうです。

ここでは、AIの指摘を「断定」ではなく「確認可能な設計論点」に変換しています。
ソースレビューでは、この変換がレビュー品質を左右します。

よくある失敗

1. ループ中に修正まで任せる

ソースレビュー中に勝手な修正を許すと、指摘対象が動いてしまいます。
レビュー用ループは読み取り専用にし、修正は別タスクとして扱います。

2. 指摘の重複を放置する

同じ指摘を毎回出されると、レビューアーの負担が増えます。
「前回と同じ指摘は remaining として要約する」と指示します。

3. 観点なしで回す

「このソースをレビューして」だけでは、静的解析のような浅い指摘に寄りがちです。
必ず、責務、境界、例外、テスト、依存などの観点を指定します。

まとめ

/loop を使ったソースレビューは、コードを自動で採点する仕組みではありません。
特定のソースを、同じ観点で繰り返し読み、修正後の変化を追うためのレビュー補助です。

  • 読むファイルを先に固定する
  • 観点は最大3つ程度に絞る
  • 出力形式をレビュー向けに固定する
  • 再レビューでは「何が直り、何が残ったか」を見る
  • PRコメントにする前に、人間が設計論点へ変換する

レビューで本当に価値があるのは、AIが多くの指摘を出すことではありません。
人間が判断しやすい論点を、安定した形式で出し続けられることです。

参考