コミット前の3分チェック: Claude Codeが触った範囲を確認してから確定する

金曜の夕方、僕は「記事のボタンの文言だけ直しておいて」とClaude Codeに頼みました。戻ってきて git status を見たら、変更ファイルが18個。文言だけのはずが、商品リンクのマップ、関連記事の差し込み、ついでに直したという翻訳ファイルまで並んでいます。

一つひとつは「親切でやってくれた」変更です。でも、そのまま全部コミットしていたら、別の作業中だった未保存の修正まで巻き込んで、翌日のデプロイで原因不明のエラーに半日溶かしていました。

賢いAIほど、頼んだ範囲を少しはみ出して仕事をします。悪気はありません。だからこそ、確定する直前の「ここまでで止めて、人が目で見る」一拍が要るんです。

この記事の要点

• Claude Codeは依頼に忠実でも、手を入れる範囲が静かに広がる。確定前の確認はその「はみ出し」を見つける作業。
• 確認は3分の決まった順番で回す。範囲の確認 → 差分の確認 → 検証 → ファイルを選んでステージ、の4ステップ。
• AIに任せるのは「変更の実行」、人が判断するのは「どこまでを今回の確定に含めるか」。ここを混ぜない。
• コピペできる確認スクリプトを置いた。git status と差分の要約を一画面で出して、見落としを減らす。
• ビルドが通っただけで安心しない。公開後の表示や翻訳の中身は、別の目で見る必要がある。

なぜ「確定する直前」に確認を置くのか

確認のタイミングは、作業を始める前でも、作業の途中でもなく、コミットする直前がいちばん効きます。理由は単純で、AIが実際に触ったファイルの全体像が、その瞬間にだけ確定するからです。

始める前にいくら「ここだけ触ってね」と指示しても、AIは作業中に「ついでに直したほうがいい」と判断したものに手を出します。途中で止めると、まだ作業が完結していないので何を見ればいいか分かりません。全部終わって、確定する一歩手前。ここで初めて「頼んだことと、実際に変わったもの」を突き合わせられます。

僕がよく事故るのは収益に関わる部分です。たとえば商品ページへのリンクが一文字ずれただけで、クリックした読者が「ページがありません」に飛びます。文章の質がどれだけ良くても、リンク先が死んでいたら売上の機会はそこで終わりです。だから差分を見るときは、リンク先が変わっていないかを最初に確かめます。

Claude Codeの基本的な使い方をまだ固めていない人は、先に Claude Code 入門ガイド で全体像をつかんでおくと、この確認手順の意味がはっきりします。

3分で回す確認の順番

毎日続けられないと意味がないので、手順は4ステップに絞っています。完璧な監査ではなく、軽い安全装置です。

1. 範囲を声に出す。 今回の依頼は何だったか、一文で言い直す。「記事のボタン文言の修正」のように。これが後の判断の物差しになります。
2. 変更ファイルの一覧を見る。 git status で、変わったファイルの顔ぶれを確認。一文で言った範囲から外れたファイルがあれば、そこに付箋を貼る気持ちで印をつけます。
3. 印をつけたファイルの差分を読む。 範囲外のファイルだけ中身を見る。親切な変更なら残す、関係ない変更なら今回は外す、を一つずつ決めます。
4. 必要なファイルだけ選んでステージする。 git add . で全部入れない。今回の依頼に必要なファイルだけを名指しで加えます。

ポイントは3番目です。AIが広げた範囲を「全部受け入れる」か「全部却下する」かの二択にしないこと。一つずつ、残すか外すかを人が決めます。地味ですが、ここを飛ばすと冒頭の18ファイル事故が起きます。

AIに任せる範囲と、人が判断する範囲

この線引きを曖昧にすると、確認そのものが形だけになります。僕は次のように分けています。

やること	担当	理由
文章やコードの修正を実行する	AI	量が多く、機械的にこなせる
構文エラーや明らかなミスを直す	AI	ルールが明確で自動化しやすい
変更を今回の確定に含めるか決める	人	依頼の意図を知っているのは人だけ
リンク先や公開後の表示を確認する	人	ビルドが通っても中身は保証されない
削除・本番データ・課金に関わる操作	人	戻せない事故は人の承認を必須にする

AIに「含めるか決めて」まで任せると、AIは自分が直したものを当然のように全部含めようとします。判断だけは手元に残す。これが事故を減らす一番の勘どころです。

コピペで使えるプロンプト雛形

確認をAIに手伝わせるときは、AIに「自己採点」させず、「事実を並べさせる」のがコツです。次の雛形をそのまま貼って使えます。

これからコミットします。確定の前に、次を事実だけ報告してください。判断はこちらでします。

1. 今回の依頼を一文で要約
2. git status で変更されたファイルを一覧（追跡外も含む）
3. そのうち、依頼の一文から外れていそうなファイルと、その理由
4. リンクや公開後の表示に影響しそうな変更があれば、該当箇所

「問題ありません」とは書かないでください。判断材料だけ並べてください。

最後の一文が効きます。これを入れないと、AIは「特に問題ありません、コミットして大丈夫です」と気持ちよくまとめてしまい、確認の意味が消えます。プロンプトの細かい組み立て方は プロンプトエンジニアリング応用編 に詳しくまとめています。

コピペで動く確認スクリプト

毎回 git status と git diff を打ち分けるのは面倒なので、変更の全体像を一画面に出すスクリプトを置いておきます。PowerShellとbashの両方を用意しました。中身は「変更ファイルの一覧」と「ファイルごとの追加・削除行数」を並べるだけのものです。

PowerShell版（Windows）。

# precommit-check.ps1
# コミット前に、変更ファイルと変更量を一画面で確認する

Write-Host "=== 今回触ったファイル ===" -ForegroundColor Cyan
git status --short

Write-Host "`n=== ファイル別の変更量（追加 / 削除）===" -ForegroundColor Cyan
git diff --stat HEAD

Write-Host "`n=== 確認のチェックリスト ===" -ForegroundColor Yellow
@(
  "依頼を一文で言える",
  "範囲外のファイルが混じっていない",
  "リンク先と公開後の表示を見た",
  "今回必要なファイルだけをステージする"
) | ForEach-Object { Write-Host "  [ ] $_" }

bash版（macOS / Linux / Git Bash）。

#!/usr/bin/env bash
# precommit-check.sh
# コミット前に、変更ファイルと変更量を一画面で確認する

echo "=== 今回触ったファイル ==="
git status --short

echo ""
echo "=== ファイル別の変更量（追加 / 削除）==="
git diff --stat HEAD

echo ""
echo "=== 確認のチェックリスト ==="
for item in \
  "依頼を一文で言える" \
  "範囲外のファイルが混じっていない" \
  "リンク先と公開後の表示を見た" \
  "今回必要なファイルだけをステージする"; do
  echo "  [ ] $item"
done

実行はこれだけです。

bash precommit-check.sh

このスクリプトは何も自動で判断しません。判断は人がやる、という前提を崩さないために、あえて「並べて見せるだけ」にしています。チェックリストの4項目が全部埋まったら、必要なファイルだけを git add ファイル名 で加えてコミットします。

実務で効く3つの場面

1. 記事や資料の公開前。 多言語の記事を一気に公開するとき、翻訳ファイルが英語のまま残っていることがあります。ビルドは通るのに中身が訳されていない。差分でファイル名だけ見て満足せず、公開後のページで本文の言語まで確認します。

2. 既存ファイルの書き直し。 文章を直したつもりが、ページ内のリンクや商品名まで書き換わっていることがあります。「文章の改善」と一文で範囲を決めておけば、リンクの変更は範囲外として一度立ち止まれます。

3. チームへの導入時。 Claude Codeがどこまで自動で進み、どこで人に聞いたかを記録に残します。承認のルール（自動で進めてよい操作、必ず人に聞く操作）が曖昧なまま運用すると、メンバーごとに事故の起き方が変わって収拾がつきません。

よくある落とし穴と直し方

落とし穴1: git add . で全部入れてしまう。 未保存だった別作業の変更まで巻き込みます。直し方は単純で、. を使わず、ファイル名を名指しでステージする習慣にすること。面倒に感じても、これが一番速い保険です。

落とし穴2: ビルドが通ったから安心する。 ビルドは構文を見るだけで、リンク先が正しいか、翻訳が中身まで訳されているかは見ません。直し方は、公開後のページを実際に開いて、見出し・本文・リンク先を目で確認すること。機械の合格と、人の合格は別物です。

落とし穴3: AIに「問題ない？」と聞いて終わる。 AIは頼まれれば「大丈夫です」と言いがちです。直し方は、前述のプロンプト雛形のように「判断は書かず、事実だけ並べて」と指示すること。判断の主語を人に戻すと、確認が機能し始めます。

確認を習慣として定着させるコツは Claude Code 生産性アップのコツ にもまとめています。git の --stat などの公式な挙動は Git 公式ドキュメント で確認できます。

よくある質問

Q. 確認に毎回3分もかける余裕がありません。 A. 変更が小さい日は1分で終わります。3分かかるのは範囲外のファイルが多い日で、それはそもそも確認が必要な日です。時間の長さは、危なさのバロメーターだと思ってください。

Q. AIにステージまで任せてはいけませんか。 A. 安全だと分かっている小さな作業なら任せても構いません。ただし「どのファイルを含めるか」の最終判断だけは人に残すのをおすすめします。ここが事故の入り口になりやすい場所です。

Q. コミットメッセージには何を書けばいいですか。 A. 「何を変えたか」と「何で確認したか」の二つです。たとえば「ボタン文言を修正、公開後ページでリンク先を確認」のように。後から見たときに、確認したかどうかが一目で分かります。

Q. 範囲外のファイルが、実は直したほうがよい変更だったら。 A. それでも今回は外します。別のコミットに分けるだけで、消すわけではありません。一つのコミットに一つの意図、を守ると後で追いやすくなります。

実際に試した結果

冒頭の18ファイル事件のあと、僕はこの4ステップを毎回の確定前に挟むようにしました。試したのは、記事公開、ファイルの書き直し、設定変更の3パターンです。

いちばん効いたのは「依頼を一文で言い直す」という最初のステップでした。これを口に出すだけで、範囲外のファイルが視界に飛び込んでくるようになります。確認スクリプトを走らせてから git add . を打つのをやめ、ファイルを名指しでステージするようにしたら、別作業を巻き込む事故はゼロになりました。

そして意外だったのは、AIへの聞き方を「問題ない？」から「事実だけ並べて」に変えた効果です。同じAIが、急に役立つ確認パートナーになりました。賢いAIを探すより、確認の主語を人に戻す。これが、僕にとっていちばん地味で、いちばん効いた一手でした。

権限設計や公開前のチェックを、チーム全体の運用にまで落とし込みたいときは、研修・相談 で具体的な設計を一緒に組み立てています。