Claude Codeのコミット前レビューゲート: 壊れた差分を止める5分の型

金曜の夜、Claude Codeと気持ちよく10ファイル直して、ノリで git commit && git push した。

月曜の朝、トップページのGumroadリンクが死んでた。無料PDFのボタンが、404に飛んでた。週末の売上はゼロ。

差分は5行も見れば気づけたミスでした。でも、見なかった。「速く書けた満足感」が、「最後に確かめる5分」を食い潰したんです。

Claude Codeを使うほど、コードを書くのは速くなります。でも速くなった分だけ、commitする直前の5分が効いてきます。ここで僕がほしいのは「よくできています」じゃない。壊れた差分、足りないテスト、崩れたCTA、混ざった無関係な変更——この4つを、commitする前に止めてくれる門番です。

今日はその門番、僕が毎回使っている「レビューゲート」の型を、コピペできる形で全部出します。

この記事の要点

• レビューゲートは安心するための儀式じゃない。commitしていいかを判定する遮断機。通らなければpushしない。
• 順番は固定。①git statusとgit diff --statで範囲を固める → ②差分をClaude Codeに渡して「findings first（良い点より先に問題から）」で返させる → ③buildを通す → ④記事なら公開URLでh1とCTAを目視 → ⑤stageするファイルが今日の目的と一致するかだけ見る。
• Claude Codeに「レビューして」だけ言うと、褒め言葉が増えて本物のリスクが埋もれる。観点を指定して縛るのがコツ。
• 記事やLPでは、buildの成功だけじゃ足りない。公開URL・h1・無料PDF・Gumroadリンク・未翻訳本文まで見て、はじめて「壊れてない」と言える。
• 仕組みはコピペできる。PowerShellの確認コマンド・レビュー用プロンプト・YAMLのブロック条件を、この記事に全部置いてあります。

なぜ「レビューゲート」が要るのか

普通のコードレビューと何が違うのか。ひとことで言うと、**目的が「学び」じゃなく「遮断」**です。

チームでやるレビューは、設計を議論したり、知見を共有したりする場でもある。でもcommit前のゲートは違う。聞いてることは1個だけ。「これ、今commitして大丈夫?」。YESかNOか。グレーなら止める。それだけです。

なぜここまで割り切るかというと、Claude Codeとの作業は事故の作られ方が変わったから。昔は1行ずつ自分で打っていたので、おかしな変更は打っている最中に気づけた。今はAIが10ファイルまとめて書く。手は動かしてない。だから「気づくタイミング」が、commitの直前のここしか残ってないんです。

特に僕みたいに記事とLP（ランディングページ）で食ってる人間にとっては、buildが通っただけじゃ全然安心できません。buildは「コードとして壊れてないか」しか見てくれない。でも売上を左右するのは、公開URLが正しいか、canonicalがズレてないか、h1が想定どおりか、無料PDFのボタンが生きてるか、Gumroadのリンク先が合ってるか、相談への導線が消えてないか——buildが緑でも、ここが死んでたら売上はゼロです。冒頭の月曜の朝が、まさにそれでした。

このテーマをチーム運用の粒度まで広げたい人は、Claude Codeレビュー運用チェックリストもあわせてどうぞ。

レビューゲートの5ステップ

僕が毎回踏んでいる手順です。順番に意味があるので、入れ替えないでください。

1. 範囲を固める。 まず git status --short と git diff --stat で、今回どこを触ったかを確定させる。ここで「あれ、なんでこのファイル変わってんの?」が出たら、もうこの時点で1個見つかってます。
2. 差分をAIに渡す。 変更内容をClaude Codeに渡して、「良い点より先に問題から（findings first）」返すよう指示する。観点を指定するのが肝心。後でプロンプトを丸ごと載せます。
3. buildを通す。 指摘を直したら npm run build を実行。MDXの構文ミス、壊れたimport、リンク切れは、ここで初めて顔を出すことが多い。
4. 公開物を目で見る。 コンテンツを触ったなら、公開URLかローカルプレビューを開いて、h1とCTAを自分の目で確認する。スクリーンショット1枚撮るだけでいい。
5. stageを絞る。 最後に、stageしようとしているファイルが「今日の目的」に合っているかだけ見る。テストだけ足したつもりが設定ファイルやロックファイルを巻き込んでないか。違うものは外す。

派手なステップは1つもありません。でも、この5つを毎回やるかどうかで、月曜の朝の顔色が変わります。

コピペできる最小セット

ここが本題。3つのブロックをそのまま使ってください。

まず範囲を固めて、buildまで走らせるコマンド。僕はWindowsなのでPowerShellですが、git の部分はどのOSでも同じです。

git status --short
git diff --stat
git diff -- src tests
npm.cmd run build

次に、差分をClaude Codeに渡すときのプロンプト。「レビューして」だけだと褒め言葉が返ってくるので、観点を指定して縛るのがポイント。「指摘がないなら、まだ未検証の項目を挙げて」の一文を入れておくと、AIが安易に「問題なし」で逃げられなくなります。

このdiffをcommit前にレビューして。
バグ・退行・テスト不足・壊れたCTA・危険なコマンドを最優先で見て。
良い点より先に、見つけた問題から返して。
各指摘には severity（深刻度）/ ファイル上の根拠 / ユーザーへの影響 / 最小の修正 を付けて。
指摘がなければ、まだ未検証のまま残っている項目を挙げて。

最後に、「これに当てはまったらcommitを止める」という条件を、自分用に言語化したもの。チェックリストをYAMLで持っておくと、Claude Codeにそのまま渡して機械的に照合させられます。

review_gate:
  must_check:          # 毎回必ず見る
    - build_result     # buildは通ったか
    - changed_files    # 変更ファイルは想定どおりか
    - public_url       # コンテンツ変更時は公開URLのh1とCTA
    - revenue_cta      # 無料PDF・Gumroad・相談リンクは生きてるか
  block_commit_if:     # 1つでも該当したら止める
    - failing_build    # buildが落ちている
    - untranslated_body # 本文が対象言語になっていない
    - fallback_page    # フォールバックページが出ている
    - unrelated_diff   # 無関係な差分が混ざっている

このYAMLの block_commit_if が、さっきの「遮断機」の正体です。どれか1つでも当たったら、その日はcommitしない。直してから出直す。

どう効くか：3つの実例

抽象論だと刺さらないので、実際に僕の手を止めた場面を3つ。

• CTAを変えた日。 記事のCTA文言を直したとき。block_commit_if のおかげで、Gumroadリンクと導入相談リンクを差分レビューの必須項目に格上げした。結果、リンク先がうっかり別商品になっていたのを公開前に発見。冒頭の月曜の朝の、二度目はなかった。
• テストだけ足したつもりの日。 git diff --stat を見たら、テスト以外に設定ファイルとロックファイルが2つ混ざっていた。AIが「ついでに」更新したやつ。stageから外して、テストだけをcommitした。
• 翻訳記事の日。 titleは日本語に直したのに、本文の冒頭3行とCTAの文言が英語のまま残っていた。untranslated_body で引っかかって気づいた。タイトルだけ見て安心するのが、いちばん危ない。

3つとも、buildは緑でした。buildだけ見ていたら、3つとも素通りしていた事故です。

バグの「報告のしかた」自体を型にしたい人は、Claude Codeバグ報告テンプレートが地続きで役に立ちます。

ありがちな失敗と、その回避

正直に、僕がやらかしたパターンを並べます。

• 「レビューして」だけ言う。 いちばん多い失敗。これだと良い点の要約が増えて、本当のリスクがその下に埋もれる。さっきのプロンプトみたいに、見る観点を先に指定して縛る。
• commit直前にbuildを省く。 「ちょっとした文言修正だから」が口癖になると終わり。MDXの構文、import、リンク切れは、たいてい “ちょっとした” 修正に潜んでる。
• 無関係なdirty fileを巻き込む。 後で「いつ壊れた?」を調べるとき、無関係な変更が同じcommitに混ざっていると、原因の切り分けが一気にしんどくなる。1commitは1目的。
• AIの「問題ありません」を鵜呑みにする。 AIは未検証と問題なしを混同しがち。だからプロンプトに「未検証の項目を挙げて」を入れて、逃げ道を塞ぐ。

レビュー全体の観点を体系で押さえたいなら、Claude Codeコードレビュー チェックリストに観点を整理してあります。あわせて、レビューを単発でなく仕組みにする話はコードレビューを仕組み化する実践ガイドにまとめました。

なお git diff --stat のオプションの正確な挙動は、Gitの公式ドキュメントが一次情報として確実です。フラグの細かい違いで迷ったら、ここを見るのが早い。

handoffに何を残すか

Claude Codeの作業は、その場で終わったように見えて、価値が決まるのは翌日です。自分の確認か、別の人のレビューか。だからhandoff（引き継ぎメモ）には、何を変えたかだけじゃなく、なぜその範囲に絞ったか、どの証拠を見たか、次にどこが壊れそうかまで書きます。

記事なら、本文の改善点・内部リンク・外部リンク・heroImage・公開URL・CTAの遷移先をまとめる。これがあると、次に自動化を回したとき、同じ判断をゼロからやり直さずに済む。

地味だけど、ここをサボると「先週の自分が何を考えてたか分からない」状態になります。未来の自分への、いちばん安いプレゼントです。

よくある質問

Q. 普通のコードレビューと、このゲートは何が違うの? A. 目的が違います。普通のレビューは設計の議論や学びの場。ゲートが聞くのは「今commitして大丈夫か」だけです。グレーなら止める。判定に振り切っているのが違いです。

Q. 個人開発でも要りますか? 自分しか見ないのに。 A. 個人こそ要ります。自分しか見ないからこそ、誰もミスを止めてくれない。冒頭の月曜の朝は、まさに一人開発で起きました。AIが10ファイルまとめて書く時代は、最後の門番を自分で用意するしかありません。

Q. 毎回buildするの、時間かかりませんか? A. かかります。でも、壊れたまま公開してロールバックする時間に比べたら、桁違いに安い。文言1行の修正でも、その1行がリンク切れを生むことがあるので、僕は省きません。

Q. プロンプトの「findings first」って何ですか? A. 「良い点の要約より先に、見つけた問題から返して」という指定です。これがないと、AIは褒め言葉を先に並べて、本当のリスクがその下に埋もれます。順番を指定するだけで指摘の質が変わります。

Q. YAMLの block_commit_if は、どう使えばいい? A. そのままClaude Codeに渡して「この条件に当てはまるものがdiffにあるか照合して」と頼むと、機械的にチェックしてくれます。自分の頭のチェックリストを、AIに代行させるイメージです。

実際に試した結果

冒頭の「月曜の朝の404」以来、僕はcommit前の5分を儀式じゃなく遮断機として扱うようにしました。

変わったのは気分じゃなくて、数字です。block_commit_if を回すようになってから、リンク切れと未翻訳本文での「公開後やり直し」が、体感でほぼゼロになった。差分を --stat で固めてからAIに渡す癖をつけたら、無関係なファイルを巻き込んだ汚いcommitも激減しました。

正直、最初は「いちいち面倒くさい」と思っていました。でも、面倒なのは最初の数回だけ。今は手が勝手に git diff --stat を打っています。速く書けるようになったぶんの保険を、最後の5分で買っている——そういう感覚です。Claude Codeで生産性を上げたい人ほど、この門番から入れてみてください。

次に何を仕組みにするか迷ったら、教材一覧にレビュー・デバッグ・記事更新の型を置いてあります。チーム導入や公開前の検証フローまで設計したいなら、研修・相談で具体的な構成を一緒に詰められます。