Claude Codeにコードレビューを頼むときの指示書：指摘の重さ・差し戻しの条件・差分だけの再レビュー

Claude Code にコードのレビューを頼んでも、返ってくるのが書き方の好みや「もっと良い案」ばかりで、どれを直せば出してよいのかが決まらない。直すたびに別の指摘が増えて終わらない。この記事を読むと、コードを書いたのとは別のAIに渡すレビュー依頼の指示書を、指摘の重さ3段階・差し戻してよい条件・一度に全部出させる決まり・直した後は差分だけ見させる決まりを入れて、写してすぐ書けるようになります。枠のもとにしたのは、運営者が自分用に作っているYouTubeライブのコメント管理ツール「LiveJazzup」の開発記録です。2026-11-10 14:42 時点の記録で、開発は進行中（システムテスト＝アプリを実際に動かして項目ごとに確かめる試験の、やり直しの途中）、アプリはまだ完成していません。この記事で使うのはそのうち17番目〜26番目の工程（2026-11-10 02:15〜03:46 の記録）で、この区間はすでに終わっています。

Claude Code にコードレビューを頼むときに写して使う指示書の枠

ここに載せるのは、記録の型を一般化した枠です。例は自作で、LiveJazzup の中身ではありません。「CSVを読んで月ごとに集計する、社内の小さなスクリプト」のレビューをAIに頼む場面を想定しています。この枠を、私たちが別の作業で使って試してはいません。

担当・作業場所・確かめのコマンド・書いてよいファイル・完了条件といった、どの指示書にも共通の欄の書き方は、前の記事に載せました。ここでは、レビューを頼むときに足す欄を中心に書きます。

• 前の記事：Claude Code・Codexへのプロンプトに確かめ方を書く：指示書と報告書の枠

先に言葉をそろえておきます。レビューは、書かれたコードを別の目で読んで、問題を指摘してもらうことです。PASS は合格、REWORK は差し戻し（直してからもう一度出すように返すこと）です。差分は、直す前と直した後で変わった所だけを抜き出したものです。git diff 前 後 は、その差分を表示するコマンドです。

1回目のレビューを頼む指示書

# レビュー依頼 — 月次集計スクリプト / 第5回 / コードレビュー

| 項目 | 値 |
|---|---|
| 担当 | コードのレビュー役（コードを書いたのとは別のAI） |
| 工程 | コードレビュー |
| 連番 | 0005 |
| 許された判定 | PASS / REWORK |
（作業場所・報告書・書いてよいファイルの欄は、ふだんの指示書と同じ）

## 1. この回の目的
第2〜4回で作ったコード（変更の全部）が、決めたとおりに作られているか・
正しいか・試験が妥当かを見る。
レビューの組（セキュリティ・実行環境・コード）の3本目。
この回が終わったら、3本の指摘をまとめて1回で直しに戻す。

## 2. 決まっていること（論じ直さない）
- 要件と合格の条件は 要件.md のとおり
- 試験の件数を理由に差し戻さない

## 3. 前提となる事実（決めではない）
- 組の1本目・2本目は REWORK。指摘は レビュー結果_セキュリティ.md と
  レビュー結果_実行環境.md にある。
  同じことを重ねて出さない。同じ所を見るなら新しい指摘にせず、その番号を書く。
- 依頼者がすでに把握していて、次の直しで直すもの：（あれば書く）。重ねて出さない。

## 4. やること
1. 決めたとおりか：合格の条件ごとに、満たしている所（ファイルと関数）を書く
2. 正しさ：壊れる入力や順序が無いか
3. 試験の妥当性：試験が本物の部品で確かめているか（偽物で通しているだけではないか）
4. 既存を壊していないか
5. REWORK のときは、直すべき所をすべて一度に出す。指摘ごとに
   番号・重さ（直さないと出せない／直すべき／望ましい）・場所・
   何が足りないか・当たる基準 を付ける。
   重さの意味（自分の言葉で1行ずつ書く）：
     直さないと出せない＝… ／ 直すべき＝… ／ 望ましい＝…
   直し方は決めない。
   好み・書き方・より良い案で差し戻さない（それは「望ましい」として書く）。
6. 読むだけで確かめられないものは、確かめられなかったと書く
   （推し量りで判定を付けない）。

## 5. 対象外
- ソース・試験の変更。git は読むだけ（diff・log・status）。
- アプリを起こすこと（起こさせるかは、あなたの環境で決める）

## 6. 完了条件
1. 合格の条件それぞれに、満たす所か、満たしていない・確かめられないことが書いてある
2. REWORK なら、指摘それぞれに 番号・重さ・場所・足りないもの・当たる基準 がある。
   PASS なら「直さないと出せない」「直すべき」の指摘が0件である。
3. 1本目・2本目と重なる指摘を新しく立てていない
4. ソースに変更が無い（git status で確かめる）

自分の作業に写すときは、題の行・§1 の回の番号・§2 の要件のファイル名を、自分のものに書き換えます。§4-5 の「重さの意味」の行は、下の「重さ3段階は、記録の中でこう使われていた」を見ながら、自分の言葉で埋めてください。3本に分けずに1本だけ頼むなら、§1 の「組の3本目」と「3本の指摘をまとめて」の2行、§3 の1つ目、§6 の3を消します。§5 の「アプリを起こすこと」は、記録では禁止していた項目です。禁止していたことと、その後に起きたことは、最後の「うまくいかなかった所」に書きました。

直した後の再レビューを頼む指示書（差分だけ見させる）

# レビュー依頼 — 月次集計スクリプト / 第9回 / コードレビュー（再レビュー）

| 項目 | 値 |
|---|---|
| 担当 | コードのレビュー役 |
| 許された判定 | PASS / REWORK |

## 1. この回の目的
第5回で出した指摘（指摘1〜10。指摘8は直さないと依頼者が決めた）が、
第8回の直しで直ったかを確かめる。
見るのは、直した所と、直しが新しく持ち込んだもの（自分の領分）だけ。
前の回で問題ないと判定した所を、もう一度全部見直さない。

## 2. 決まっていること（論じ直さない）
- 直しの指示書の「決め」の列。指摘8は直さない。

## 3. 前提となる事実
- 直しの差分：git diff <直す前> <直した後>
- 同じ組のほかの再レビューで出た指摘は、重ねて出さない（同じ所を見るならその番号を書く）

## 4. やること
1. 前の指摘1つずつに、直った／直っていない／一部 を、根拠（ファイルと関数）つきで書く
2. 直しの差分が、新しい不具合を持ち込んでいないか
   （取りこぼし・重なり・順の崩れ・後片付けの漏れ・待ちが返らない など）
3. REWORK のときは、1回目と同じ形で、すべて一度に出す（番号は 指摘11 から）。
   好み・書き方で差し戻さない（「望ましい」として書き、判定は PASS にしてよい）
4. 読むだけで確かめられないものは、確かめられなかったと書く

## 5. 完了条件
1. 前の指摘それぞれに、判定と根拠（ファイルと関数）がある
2. PASS なら「直さないと出せない」「直すべき」の指摘が0件である

指摘をまとめて直しに戻すときの表

レビューが3本そろったら、コードを書いた側への直しの指示書に、指摘を1つの表にして渡します。

## 直すもの（直すべき —— 全部直す）
| # | 指摘 | 決め（依頼者） |
|---|---|---|
| 1 | 指摘3 月をまたぐ行が前の月に数えられる | 締めの日付で数える（要件 2-1） |
| 2 | … | … |

## 直すもの（望ましい —— この回でまとめて直す）
| # | 指摘 | 決め（依頼者） |
|---|---|---|
| 1 | … | … |

直さないもの：指摘8（要件の文に合うので、このまま）
振る舞いを変えるのは指摘の所だけ。この回でほかの機能を足さない。
試験が通ったことだけを、直った根拠にしない。

枠に入れた4つの決まり

決まり	枠のどこに書くか	記録での書き方
指摘の重さを3段階で付けさせる	1回目の §4-5	「直さないと出せない／直すべき／望ましい」のどれかを指摘ごとに付ける
差し戻してよい条件を決める	1回目の §4-5、完了条件 2	PASS は「直さないと出せない」「直すべき」が0件のとき。好み・書き方・より良い案では差し戻さず、「望ましい」として書く
一度に全部出させる	1回目の §4-5、§3	直すべき所を「すべて一度に」。ほかのレビューと同じことは重ねて出さず、番号を参照する
直した後は差分だけ見させる	再レビューの §1	直した所と、直しが新しく持ち込んだものだけを見る。前の回で問題ないとした所を全部見直さない

重さ3段階は、記録の中でこう使われていた

段階の定義の文は、記録の中ではプロジェクト共通の規則のファイルにあり、この記事で使う範囲の外なので載せていません。代わりに、記録の中での使われ方を並べます。あなたが使うときは、段階ごとの意味を自分の言葉で1行ずつ書き足してください。

段階	記録の中での使われ方
直さないと出せない	コードのレビュー（17〜26番目）では1度も付いていない。その後の、テスト結果のレビューで5件付いた
直すべき	最初のレビュー3本で計7件。コードのレビューは、自分が付けた5件について「利用者から見える結果が決めと違う」ことを理由に挙げていた。7件とも直した
望ましい	好み・書き方・より良い案はここに書かせ、差し戻しの理由にしない。最初のレビュー3本で計15件。14件を直し、1件は直さないと決めた

ただし、これは1件の開発の記録です。この枠が別の開発でもうまくいくかは確かめていません。

枠のもとになった記録：3本そろって差し戻し、まとめて直し、差分だけ見直して PASS

ここからは、上の枠のもとになった記録を順に見ていきます。担当の分け方は次のとおりです。コードを書いたのは Codex、レビューをしたのは Claude で、レビューは観点ごとに別の担当に分けていました。指示書を書いて結果を受け、次の工程を決めるのは進行役のAI（記録上の呼び名は「PM補佐」）です。Claude と Codex は記録上の担当名で、動かしている製品は Claude Code と Codex CLI です（2026-11-10 に運営者に確認）。レビューは、Claude Code に指示書を渡して頼んだものです。

観点の違う3本を、同じ形の指示書で頼んだ

最初のレビューは、セキュリティ・実行環境・コードの3本の組でした。3本とも、許された判定は PASS／REWORK の2つで、「やること」には同じ形の決まりが入っています。

• REWORK のときは、直すべき所をすべて一度に出す
• 指摘ごとに、番号・重さ（直さないと出せない／直すべき／望ましい）・場所・何が足りないか・当たる基準を付ける
• 直し方は決めない
• 読むだけで確かめられないものは、確かめられなかったと書く

3本目のコードのレビューの指示書には、さらに「好み・書き方・より良い案で差し戻さない（それは『望ましい』として書く）」と「試験の件数・網羅を理由に差し戻さない」が入っていました。目的の欄には「組の3本目で、この回が終わったら3本の指摘をまとめて1回で開発へ戻す」とあります。

3本が同じことを重ねて出さない工夫もありました。3本目の指示書には、1本目・2本目が REWORK だったことと指摘の置き場が書かれ、「同じことを重ねて出さない。同じ所を見るなら新しい指摘にせず、その番号を参照する」とあります。進行役がすでに把握していて次の直しで直す予定のものも、「重ねて出さない」と書かれていました。2本目のレビュー役は、3本目への申し送りに、自分が見ていない範囲（業務の決まりごとの正しさ・名前の付け方・重複・試験の中身）を書いて渡しています。

3本とも差し戻し：直すべき7件・望ましい15件

レビュー	判定	直さないと出せない	直すべき	望ましい
セキュリティ	REWORK	0	1	4
実行環境	REWORK	0	1	6
コード	REWORK	0	5	5
計		0	7	15

出た指摘の例です（中身は言い換えています）。

• 直すべき：画面へ状態を配るとき、出来事1件ごとに一覧の全件を複製して送っている。決めてある「毎秒50件を5分間」に耐える裏づけが無い（実行環境）
• 直すべき：一覧を遡ると、見ていた位置ではなく、いちばん古い80件へ飛ぶ（コード）
• 直すべき：設定の7項目のうち3つに、画面から変える入口が無い（コード）
• 望ましい：試験用の画面に、押しても何も起きないボタンが残っている（セキュリティ）
• 望ましい：範囲の外の設定値が、知らせ無しに既定値へ戻る（セキュリティ）

コードのレビューの報告書には、単体試験（部品1つずつをプログラムで自動的に確かめる試験）12件について、どれも本物の部品で確かめていて偽物で通してはいないが、部品を組み上げた段の不具合はどの試験でも捕まらない作りになっている、と書かれていました。進行役への申し送りには「試験が通ったことを直った根拠にしないで」という依頼があります。

3本そろうのを待って、1回の直しにまとめた

進行役は、1本目の結果が出た 02:15 の時点で「組の残り2本の後にまとめて直しの回へ戻す」と記録しています。3本目が出た 02:41 には「3本の指摘をまとめて直す。直した後、3本のレビューを直した所だけ回し直す」と書いています。

直しの指示書は、上の「指摘をまとめて直しに戻すときの表」の形でした。

• 3本の結果の置き場を表で示し、「まとめて1回で直す」
• 振る舞いを変えるのは指摘の所だけ。この回でほかの機能を足さない
• 直すべき7件は全部直す。望ましいも、この回でまとめて直す
• 指摘ごとに「決め（進行役）」の列を置き、進行役が決めたことがあればそれに従わせる
• 直さないもの1件と、その理由（要件の文に合うので、このまま）
• 直した所ごとに、変えたファイルと、どう確かめたか（試験の中か・測りか・読んでか）の表を出させる
• 試験が通ったことだけを直った根拠にしない

02:59 に直しの回が終わり、直すべき7件と望ましい14件が直されました。lint（プログラムの書き方の誤りを自動で探す道具）はエラー0、単体試験は12件とも通っています。

直しの中で測った数字（測り方の注記つき）

「毎秒50件を5分間」の裏づけが無いという指摘に対して、直しの回では、15,000件（毎秒50件×5分ぶん）を流して測る道具を作り、アプリを起こさずに処理の部分だけに流して測っていました。

項目	直す前に相当する方式	直した後の方式
1件あたりの処理時間	19.1126 ミリ秒	0.1366 ミリ秒
配る状態の大きさ（記録の書き方のまま）	最終の全状態 3,159,429 バイト	1件あたり 315.9 バイト

終わったときの一覧は 10,000件でした。注記：直す前の時間は、直す前のコードをそのまま流した値ではありません。同じ15,000件のうち50件ごとの標本300点で「一覧の全件を複製する」部分を実測し、直した後の処理時間に足した値です。純粋な前後の比較ではない、と読んでください。大きさの行も、左は最後の時点の全状態の大きさ、右は1件あたりの大きさで、同じ物差しの比較ではありません。実際に5分間流して画面が追いつくかは、後のシステムテストで見る形になっていました。

再レビューは「直した所だけ」を3本

再レビューの指示書（3本とも同じ形）には、次のように書かれています。

• 見るのは直した所と、直しが新しく持ち込んだもの（自分の領分）だけ
• 前の回で守っていると判定した所を、もう一度全部見直さない
• 直しの指示書で進行役が決めたこと（直さないと決めた1件を含む）は論じ直さない
• 見る差分の範囲を git diff 前 後 の形で示す
• 前の指摘1つずつに、直った／直っていない／一部 を根拠つきで書く
• 好み・書き方で差し戻さない（「望ましい」として書き、判定は PASS にしてよい）

再レビュー	時刻	判定	前の指摘	新しい指摘
セキュリティ	03:05	PASS	5件すべて直った	望ましい 2件
実行環境	03:14	PASS	7件すべて直った	望ましい 6件
コード	03:21	PASS	9件すべて直った（直さないと決めた1件を除く）	望ましい 3件

コードの再レビューは、アプリの画面を起こせないため、その経路の2件は確かめられなかったと書いています。

残った「望ましい」を直し、その差分だけをもう1回

3本が PASS になった後、進行役は、新しく出た望ましい11件を、システムテストの前に直す回を出しました。直しの指示書には、そのうちのいくつかはシステムテストと人の目での確認にそのまま当たるとして、「試験で紛らわしい結果を出さないために、システムテストの前にこの回で直す」とあります。03:28 に11件の直しが終わり、進行役がアプリを動かして見つけた食い違い1件も、03:37 に別の直しの回で直しました。

この2回の直しは、差分だけのレビューに掛けています。指示書には「この2回の直しが指摘どおりに直っているか・新しく壊していないかを、差分だけで見る」「差分の外にある、これまでの指摘や既に PASS の所を重ねて出さない」とあり、新しく壊していないかの観点として「取りこぼし・重なり・順の崩れ・後片付けの漏れ・待ちが返らない・ログの鍵が増えた」が並んでいました。結果は 03:46 に PASS（直さないと出せない0・直すべき0・望ましい4）です。

最初のレビュー結果が出た 02:15 から、最後のレビューが PASS になった 03:46 まで、約1時間半の区間です。

うまくいかなかった所：レビューがすべて PASS の後に「直さないと出せない」が5件出た

記録のレビュー役は3本とも、指示書でアプリを起こすことを禁じられていました。2本目と3本目は、lint や試験を自分で流すことも禁じられていました（実行の結果が要るときは、進行役の記録を使う決まりです）。コードのレビューは、アプリとブラウザを起こさないと確かめられない3項目を「確かめられない」のまま残し、推し量りで判定を付けていません。

そのあと、コードのレビューがすべて PASS した状態でシステムテストを行い、その結果のレビューで「直さないと出せない」が5件付いて差し戻しになりました。コードのレビュー（17〜26番目）では1度も付かなかった段階です。5件の中身は、この記事では扱いません。

読むだけのレビューで、本来どこまで見つけられたはずなのかは、記録からは判定できません。記録から言えるのは、コードを書いたのとは別のAIにレビューを分け、PASS が3本そろっても、動かした結果のレビューで止まる指摘が出た、ということです。枠の「5. 対象外」でアプリを起こすことを禁じるかどうかは、あなたの環境と、動かして確かめる工程を別に持つかどうかで決めてください。

開発はまだ途中で、2026-11-10 14:42 の時点では、システムテストのやり直しが続いています。