#claude-code-review-pipeline

長時間いじったあとに「全部見直してください」と投げるのは、だいたい破綻する。差分がでかすぎて、Claude Code も人間も本当に大事なところを見失うからだ。ここでやるべきなのは、差分圧縮と要点整理だ。作業の途中で散らかった変更を、あとから読める単位に畳み直す。変更点の量を減らす話ではない。意味の粒度をそろえる話である。 Claude Code では、ひたすら作業を続けたあとに「変更を要点だけ残す形にして」と頼むと、雑多な修正をまとめ直す助けになる。ファイル整理でも、文書作成でも、コード修正でも効く。要は、あとで自分か相手が追える状態に戻す作業だ。 最初にやることは単純だ。いったん変更を見せて、何を残し、何を捨てるかを明確にさせる。 ```text ここまでの変更を差分圧縮したい。 次の3つに分けて整理してほしい。 1. 本当に残すべき変更 2. まとめられる変更 3. 捨ててもよい一時的な変更や試行錯誤 出力は、変更点の要点を箇条書きで短くまとめて。 そのあと、必要ならコミットメッセージ案も出して。 ``` この頼み方のいいところは、Claude Code に「全部説明しろ」と言わ

「たまに起きる」「さっきは動いた」──その手の話は、だいたい不具合そのものより先に、話の組み立てが崩れている。Claude Code で詰まるのもそこだ。再現しないまま雑に修正へ飛ぶと、原因と対処がズレる。不具合切り分けと再現性確認を先に固めるだけで、勘違いはかなり減る。 Claude Code は、曖昧な状況説明をそのまま飲み込むと、もっともらしい修正案を出してくる。そこに人間側の思い込みが乗ると、別の場所を直して終わりだ。だから最初にやるべきは「直すこと」ではなく、「再現する条件を削ること」になる。 たとえば、こんな頼み方が効く。 ```text この不具合を再現したいです。まず修正はしないでください。 次の情報を整理してください。 どの操作で起きるか 毎回起きるのか、たまに起きるのか 何が起きたように見えるか 直前に変えたファイルや設定は何か 再現手順を1つずつ最小化するならどこまで絞れるか 必要なら、再現確認用のチェックリストを作ってください。 ``` この頼み方のいいところは、Claude Code を「修理係」ではなく「切り分け係」として使える点だ。いきなりコードを書かせる

変更を見ただけで納得した気になると、だいたい後で崩れる。差分は「何を変えたか」しか教えてくれないが、ログは「そのとき何を考えていたか」を残す。Claude Code では、この二つを並べて追う癖をつけると、作業のズレがかなり減る。作業ログ、履歴確認、どちらの感覚でも使えるやり方だ。 特に効くのは、ファイル整理や文書作成みたいに、完成物そのものより「なぜそうしたか」が重要な場面だ。最初はうまくいったように見えても、後から「この並び替えは何のためだったのか」「この削除は本当に安全だったのか」で止まる。筆者も一度、メモの整理を Claude Code に任せたあと、変更履歴だけ見て満足していたら、不要な重複を消したつもりで別の版を残していた。ログを並べていなかったせいで、判断の筋道が消えていたわけだ。 やることは単純だ。Claude Code に作業を頼むとき、最初に「作業ログを残しながら進めてほしい」と明示する。次に、区切りごとに変更内容と判断理由を短く書かせる。最後に、必要なら Git の差分やファイルの更新履歴と見比べる。これだけで、単なる「結果の確認」から「判断の確認」に変わる。 た

PR にそのまま貼る説明文を、いきなり Claude Code に書かせると、だいたい散らかる。要点が混ざる。変更の理由が薄まる。読んだ相手が「で、何を見ればいいの」となる。 ここで効くのが、先に論点整理をさせて、PR説明の芯を作ってから本文に落とすやり方だ。非エンジニアの作業でも同じで、ファイル整理でも文書作成でも、先に「何を伝えるか」を固めるだけで手戻りがかなり減る。 Claude Code は、雑に頼むと雑に広げる。これは欠点というより、指示のあいまいさをそのまま反映するだけだ。だから最初にやることは、文章を書かせることではない。論点を切ることだ。 PR説明、論点整理、この二つを先にやると、説明の芯ができる。芯ができると、後から差分を見た人が追いやすい。レビューの質も上がるし、あとで自分が読み返したときの恥ずかしさも減る。 やり方は単純だ。まず変更内容を丸ごと説明させるのではなく、論点だけを短く抜き出させる。たとえばこんな頼み方でいい。 ```text この変更について、PR説明を書く前の論点整理をしてください。 以下の観点で、重複しないように箇条書きにしてください。 変更の目的

コミット直前に「たぶん大丈夫」で流すのが、いちばん雑に事故る。差分が少ない日ほど油断するし、ファイル整理でも文書作成でも、ひとつの見落としがあとで地味に効く。 Claude Code には、コミット前確認、見落とし確認をやらせておくといい。要は、コミットする前に「何を変えたか」「消し忘れたものはないか」「別ファイルに漏れていないか」を一度洗う。人間がやると集中力が切れた瞬間に抜けるが、Claude Code は淡々と一覧化してくれる。そこが強い。 まず、作業ツリーを見せて、変更点を要約させる。これだけでも十分役に立つ。 ```bash claude ``` Claude Code が起動したら、こんなふうに頼む。 ```text 今の作業ツリーの変更を確認して、コミット前に見落としがないか洗ってください。 次を順に見てください。 変更ファイルの一覧 追加・削除・名前変更の有無 差分の要点 置き忘れた設定値、コメントアウト、デバッグコードの残り 仕様上まずい変更や、関連ファイルの更新漏れ 最後に、コミット前に人間が目で確認すべき点を短く箇条書きで出してください。 ``` この頼み方のいい

修正した説明を、そのまま長文で押しつけるのはだいたい失敗する。読む側は「で、何が変わったのか」だけ知りたいのに、前提や経緯まで全部読む羽目になるからだ。ここで効くのが、要約だ。さらに引き継ぎメモとしてそのまま使える形に落としておくと、次の人が拾いやすい。 Claude Code は、長い説明を短く圧縮するのが得意だ。ただし、雑に投げると要点まで薄まる。修正後の内容を、誰に渡しても同じ理解になる粒度に削るには、最初に「何のための要約か」を言い切るのがコツになる。単なる短縮ではなく、引き継ぎ用のメモにする。ここを外すと、ふわっとした文章が返ってきて終わる。 たとえば、修正した文章がこれだとする。 ```text この機能は、重複したファイル名をまとめて整理できる。対象フォルダを選ぶと、同名ファイルを一覧化し、最後にまとめて確認してから処理を実行する。誤削除を避けるため、最初はプレビューだけ表示する。 ``` これを Claude Code にそのまま丸投げするより、次のように頼むほうが使える出力になる。 ```text 次の説明を、引き継ぎメモとして使えるように短く要約してください。 条件

「直しました」で終わらせると、たいていどこかがまだ死んでいる。見た目は直っていても、テストは別の場所で赤いまま、あるいは差分だけ眺めると肝心の修正が抜けている。そこで効くのが、検証と照合だ。テスト結果と git diff を突き合わせる。これだけで「直したつもり」のまま次に進む事故がかなり減る。 Claude Code でも同じで、修正依頼を出して、返ってきた変更をそのまま信じるのは雑すぎる。AI はちゃんと直すこともあるが、関係ない箇所を触ったり、テストの失敗原因を外したまま別方向をいじったりもする。だから最後は、人間が「テストが指している場所」と「差分で実際に変わった場所」を重ねて見る。ここをサボると、手戻りが増える。かなり露骨に増える。 たとえば、こんな流れだ。 ```bash git diff ``` で変更点を見てから、 ```bash npm test pytest go test ./... ``` でテストを走らせる。失敗したら、そのエラーメッセージと diff を同時に見る。Claude Code に頼むときも、ただ「直して」では弱い。こう投げるといい。 ```tex

自分で書いた差分ほど、雑に見てしまう。そこが一番まずい。 「差分レビュー」や「レビュー依頼」を自分宛てに投げる感覚で Claude Code を使うと、勢いで書いた変更を一度外に出せる。すると、読みにくい命名、説明不足のコメント、余計なファイル変更が、かなり早い段階で見つかる。 人間の目は、実装した瞬間の文脈に引っ張られる。だから「動くしまあいいか」で流しやすい。Claude Code に赤入れさせる価値は、そこを機械的に叩ける点にある。コードの正しさだけでなく、差分の見た目、変更範囲の広さ、説明の足りなさまで見させると、後で恥をかく率が下がる。 やり方は単純だ。作業が一段落したら、未コミットの差分をまとめて見せて、レビュー観点を先に渡す。Claude Code はターミナルから使うエージェントなので、ローカルのファイルを見ながら指摘を返せる。ここで大事なのは、「直して」と丸投げする前に、まず「レビューして」と頼むことだ。いきなり修正させると、確認したい論点まで勝手に書き換えられることがある。 たとえば、こんな依頼文で十分だ。 ```text 以下の差分をレビューしてほしい。 目的はコ

雑にいじってから確認させると、だいたい手戻りする。Claude Code でもそこは変わらない。先にセルフレビュー、つまり事前レビューの観点を出させてから変更に入るだけで、あとから「そこじゃない」を潰しやすくなる。 この手は、コード修正だけの話ではない。ファイル整理、不要キャッシュの削除、文書の推敲みたいな作業でも効く。いきなり本体を触らせると、見た目は進んでも肝心の判断基準があいまいなまま走る。結果、差分は増えるのに、欲しかった品質には届かない。かなりもったいない。 やることは単純だ。変更を頼む前に、「何を見て自分で確認するか」を Claude Code に先に書かせる。観点を先に固定しておくと、作業中のブレが減る。人間の側も、あとからレビューしやすい。 たとえば、いきなり「この関数を直して」と投げる代わりに、こう始める。 ```text この変更を始める前に、自己レビューの観点を先に列挙してほしい。 対象は次の通り。 変更対象ファイル: src/app.ts 目的: エラーハンドリングの改善 制約: 既存の挙動を変えすぎない 出力: 先にレビュー観点、その後に変更案 観点は、機能、

レビューで毎回ゼロから目をこらしていると、だいたいどこかで雑になる。しかも厄介なのは、雑になる場所が毎回少しずつ違うことだ。今回たまたま見たつもりでも、次回は別の抜けが出る。これ、かなりもったいない。 Claude Code は、こういう「見る観点が毎回似ている仕事」に強い。レビュー観点テンプレ、あるいは確認テンプレとして定型を持たせておくと、何を見ればいいかを毎回考え直さなくて済む。結果として、確認が速くなるだけでなく、抜け漏れも減る。 ただし、テンプレを作れば勝手に賢くなるわけではない。雑な観点をそのまま固定すると、雑さまで恒久化する。ここを外すと、むしろ手戻りが増える。筆者は最初、「とりあえず変更点を見て」とだけ投げて、結局あとから「ここも確認して」「いや、権限まわりも見て」と差し戻しを食らった。あれはだいぶだるかった。最初から観点を固定しておけば、こんな往復は減る。 まずやることは単純だ。よく見るポイントを、短い文章で並べる。Claude Code に渡すなら、こういう形でいい。 ```text この作業のレビューでは、次の観点を毎回確認してください。 変更の目的と、実際の差分