「PRを出した後にレビュアーから細かい指摘で5往復した」 — 開発者なら誰でも経験があるはずです。typo、エッジケース漏れ、削除し忘れたconsole.log、テストの足りない部分。人間レビュアーの時間を消費する前に、自分で気づきたい指摘です。

Claude Codeにはセルフレビューを助ける /review コマンドが用意されています。本記事では、/review の使い方と、私が半年使って定着した運用パターンを整理します。

/review はその場で変更内容をAIにレビューさせるコマンド

Claude Codeのプロンプトで /review と打つと、直前のセッションでClaudeが触ったコード変更を、Claude自身に再レビューさせる挙動になります。git stagedなファイル、未コミットの編集、コミット済みの直近差分など、対象範囲はその時々のセッション内容によります。

返ってくる指摘の内容は、たとえば次のあたりです。

  • typo(変数名、コメント、文字列リテラル)
  • エッジケースの抜け(空配列、null、認証失敗時のフォールバック)
  • 不要な変更(消し忘れた console.log debugger)
  • セキュリティリスク(APIキーのハードコード、SQLインジェクションの可能性)
  • スタイルの不統一(同じ意味のコードが別の書き方で混在)

完璧ではありませんが、ヒューマンレビューの前段として十分機能します。

Claude Code 公式 /review コマンド

docs.anthropic.com

私はこのコマンドを知る前、レビュー前に自分でdiff全体を眺めて確認していました。30分かけて1回見逃した変更を、/review だと10秒で気づかせてくれる、という体験を何度もしました。

使うタイミング — 3つの場面

/review をいつ叩くと効くか。私の運用での3つの場面です。

第一に、コミット直前。一連の編集が終わって git add した状態で /review を叩く。「これからコミットしようとしている内容にレビュー観点で問題ありますか」が拾えます。意外なtypoや消し忘れが減ります。

第二に、長時間の作業後。1〜2時間続けて編集した後、頭が疲れて見落としが増えやすい状態で /review を叩く。AIは疲れないので、こちらの集中力低下を補ってくれます。

第三に、他人のレビューに送る前のセルフチェック。レビュアーの時間を尊重するなら、明らかなミスを /review で拾っておくのが礼儀です。私は社内レビューで「typo指摘」が来る回数が、/review を入れる前後で半減しました。

拾える指摘の精度を上げるコツ

/review の精度は、CLAUDE.md と直前の文脈の質に直結します。何も書かれていないリポジトリで叩くと、汎用的な指摘しか返ってきません。

精度を上げる工夫は次のとおり。

  • CLAUDE.md に「コミットメッセージは feat: fix: で始める」のような規約を書く → 命名違反を指摘してくれる
  • CLAUDE.md に「テストファイルは tests/ 配下に必ず1つ作る」と書く → テスト追加漏れを指摘してくれる
  • AGENTS.md に過去の事故例を書く → 同じパターンの危険を再レビュー時に拾う

私のリポジトリでは media/AGENTS.md に Next.js 16 の破壊的変更への注意を書いていて、/review が「これは Next.js 15 のAPIなので、16では fetch のcache挙動が違います」と指摘してくれる場面があります。

CLAUDE.md と AGENTS.md の整備度合いが、そのまま /review の役立ち度合いになります。

hooks と組み合わせて自動レビューにする

毎回手で /review を叩くのが面倒なら、Claude Code の hooks 機能で自動化できます。.claude/settings.json で、特定の操作タイミングに /review を強制発火させる設定です。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          { "type": "command", "command": "echo 'ファイル編集ごとにレビューを推奨' >&2" }
        ]
      }
    ]
  }
}

上は単にメッセージを表示するだけのサンプルですが、ファイル編集後にレビューを促す形にできます。本格的な自動レビューを組むなら、hooks から claude を別プロセスで呼び出して、その出力を Slack に流すような構成も組めます。

Claude Code hooks 公式

docs.anthropic.com

私は個人作業ではhooksまでは入れていません。手で叩く意識を持っておく方が、レビュー結果を真面目に読むからです。チーム運用では hooks 自動化の価値は高いはず。

限界 — /review で拾えないもの

正直に書くと、/review で拾えない指摘もあります。私が体感した範囲だと、

  • 設計レベルの問題(「このクラス分割は責務がおかしい」「データモデルが将来詰まる」)
  • ビジネスロジックの誤り(コードは正しく動くが、要件と違う実装)
  • パフォーマンスの問題(計算量、N+1クエリ)
  • 副作用のあるテスト失敗(モックが甘いせいで本番でだけ落ちるバグ)

これらは人間レビュアーやEnd-to-Endテストの守備範囲です。/review を入れたから人間レビューが不要、ではない。人間レビューの前に明らかなミスを減らすツールという位置づけです。

私のチームでは、/review を「ヒューマンレビュアーへの敬意」と説明しています。レビュアーの時間を、設計議論のような価値の高い指摘に使ってもらうために、機械が拾える指摘は機械に任せる、という発想です。

私の運用フローの実例

参考までに、私が業務で回しているフローを書きます。

  1. Claude Codeで一連の編集が終わる
  2. /clear で履歴を整理しない(レビュー対象の文脈を保つため)
  3. /review を叩く
  4. 返ってきた指摘に対応(typoは直す、設計指摘は判断して残すか直す)
  5. git add -p で差分確認しながらstaging
  6. git commit のメッセージは Claude に下書きさせる
  7. git push してPR作成

このフローで、PRレビューの所要時間が体感で30%減りました。減ったぶんで、レビュアーが設計面の指摘を出してくれるようになり、コードの品質も上がる、という二次効果がありました。

Claude Code Best Practices(関連記事)

docs.anthropic.com

まとめ

  • /review は直前の変更をClaude自身に再レビューさせるコマンド
  • typo・エッジケース漏れ・機密情報混入を、人間レビュー前に拾える
  • 使うタイミングはコミット直前・長時間作業後・他人レビュー前
  • 精度を上げるには CLAUDE.md と AGENTS.md の整備が効く
  • hooks と組み合わせて自動化も可能。チーム運用ではおすすめ
  • 設計・ビジネスロジック・パフォーマンスは人間レビューの守備範囲