問題: レビューイの思い込みと、レビュアーの確認疲れ

コードレビューで頻出する会話。

実装者: 「このリファクタ、ロジックは変わってません」 レビュアー: 「ロジックは変わってないように見えるけど…実際に動いたの?」 実装者: 「ローカルでさっと試したので大丈夫だと思います」 レビュアー: (internal sigh) 「では自分で動確認します」

この流れが起きるのは、ロジックが「正しそう」と「実際に動く」が異なるから。

実装者は「コードを読んで正しいと判断」した。レビュアーは「コードが正しいように見えても、実装者が実際に動かしていないなら疑う」という合理的な疑念を持つ。その結果、レビュアーの時間がテスト確認に消費される。

解決: /verify でレビュー前に「動いた証拠」を持ってくる

/verify を使えば、リファクタの実装者が最初から「動いたことの証拠」を用意する ことができる。

/verify

このコマンドは、あなたが加えた変更が本当に動いているか、実装されたコードが実際に目的を果たしているかを確認する。単なるユニットテスト通過ではなく、実際の動作環境でその機能が正しく動くこと を検証する。

実務での使い方

ステップ 1: リファクタ実装後、すぐに /verify を実行

リファクタが終わったら、コミット前に /verify を使って動作確認を自動化する。あなたが手動で「テストを走らせる」手順を書く必要はない。Claude Code が既存のテストを見つけ、対象の機能を実行し、結果を報告する。

ステップ 2: 動作確認の結果をコミットメッセージに記録

Refactor: extract user validation logic

- Extracted validation into separate module
- /verify: All 24 existing tests pass
- Load test: P99 latency unchanged (baseline 145ms → 143ms)

この「動いたことの記録」があれば、レビュアーは「ロジックが変わっていないか確認」に注力できる。「本当に動いているのか確認」という疑念を最初からなくせる。

/loop で「毎回動く」を担保する

単発の /verify でも十分だが、リファクタが複数の環境で一貫して動くこと を示したければ /loop を組み合わせる。

/loop 5 /verify

これは /verify を 5 回実行する。つまり、あなたのリファクタが「一度だけ動いた」のではなく「何度実行しても動く安定性がある」ことを示す。特に以下の場面で有効。

  • 状態に依存するロジックの書き換え — データベース接続、キャッシュの扱い
  • 並行処理の変更 — 複数スレッド間の競合状態が隠れやすい
  • 外部 API の呼び出し変更 — タイムアウトやリトライロジック

レビュアーの観点: 「証拠がある」と「手探り」の差

証拠がないケース

  • 実装: リファクタ完了、手動テストで「多分大丈夫」
  • レビュー: 「では自分の環境でも動かしてみます」→ 確認に 15 分
  • リスク: 本番でも動くかは、リリース後までわからない

証拠があるケース

  • 実装: リファクタ完了、/verify で「24 個のテスト全て成功」を記録
  • レビュー: 「ロジックの変更がないか」「設計判断は妥当か」に集中
  • リスク: テスト環境で動いている状態を本番に持ち込む問題だけに絞られる

レビュアーは確認に 3 分で済み、残りの時間で「本当にこのリファクタが必要か」「他にもっといい方法があるか」という高次の判断ができる。

実装パターン: リファクタリングの定型フロー

1. コードを書く
2. /verify でテストを実行
   → 失敗したら、コード修正
   → 成功したら、コミットメッセージに結果を記録

3. (オプション) /loop で複数回実行確認
   → 特に「状態を持つロジック」を変更した場合

4. プルリクエストに出す
   → 「動作確認済み」の事実をレビュアーに提示

よくある質問

Q: /verify と既存のテストスイートの違いは?

既存のテストスイート（npm test など）は「ローカル開発環境でテストを走らせる」。/verify は「Claude Code がテスト環境を構築して動作を確認」するので、セットアップの手順が不要。また、/verify は その変更に影響を受ける機能を自動で検出して確認する という側面も強い。

Q: リファクタが大きい場合、一度の /verify で全部確認できるか?

できる。/verify はコード全体のテストスイートを実行するので、単発のリファクタより大型の変更ほどその価値が出る。ただし「何回動いても安定か」が気になる場合は /loop を使う。

Q: レビュアーが /verify 結果を信頼しないケースは?

ある。特に「テストがそもそも信頼できない」「テストが古い」という環境では、/verify の結果も疑問の対象になる。その場合は テストそのものの整備 が先。リファクタの動作確認の問題ではなく、テスト設計の問題。

レビュー時間を削る本質

リファクタに対する疑念の大半は「本当に動くのか」という確実性の問題。

この確実性を リファクタの実装段階で示す ことで、レビュアーは「この判断は妥当か」という本来のレビュー仕事に戻れる。

/verify はコマンドではなく、 「動いたことを証明する文化」 の起点。