初めまして、テックバディ運営の大下です。ふだんはAI駆動開発を学べるエンジニア向けスクール「テックバディ」の立ち上げをしながら、現場で新人エンジニアと接する機会も多いのですが、意外と共通して悩んでいるのが今回のテーマです。
「とりあえず動いたのでcommit」「キリが良さそうなのでcommit」——こんな理由でコミットを切っていませんか。
わたしも最初の数ヶ月は、1日の終わりにまとめて1コミットしたり、逆に細かすぎてfixだけのコミットが10個並んだり、粒度がずっと定まりませんでした。レビュアーから「このコミット、何をした差分ですか」と聞かれて答えに詰まったこともあります。
最近はAIにコードを生成してもらう機会が増え、一度に大きな差分が出力されるぶん「このAI生成分をどう分割してコミットするか」という新しい悩みも出てきました。今回はその両方を整理します。
なぜ粒度がバラつくのか
原因はシンプルで、「作業の区切り」と「意味の区切り」を混同しているからです。
- 作業の区切り：今日はここまでやった、休憩前だから、というタイミング基準
- 意味の区切り：この差分は「何をしたか」を一言で説明できるか、という内容基準
コミットログはあとから読む人（未来の自分やレビュアー）のための記録です。作業の区切りで切ると、ログを見ても「何が起きたか」が分からず、git blameやレビューの役に立ちません。
判断基準は「1コミット=1つの動詞で言えるか」
具体的には、コミットする前に次の問いに答えられるかを確認します。
このコミットは、1つの動詞（追加する／直す／リネームする／削除する）で説明できるか
説明できないなら、それは複数の意味が混ざっている合図です。分割しましょう。
# NG：意味が3つ混ざっている
git commit -m "ログイン機能追加、タイポ修正、CSS調整"
# OK：意味ごとに分割
git commit -m "feat: メールアドレスでのログイン機能を追加"
git commit -m "fix: バリデーションメッセージのタイポを修正"
git commit -m "style: ログインフォームの余白を調整"
AI生成コードを分割するときの視点
Claude CodeやCopilotに機能実装を依頼すると、1回の出力で「機能本体」「テスト」「軽微なリファクタ」がまとめて差分として返ってくることがよくあります。ここでそのまま1コミットにしてしまうと、あとでレビューする側は「どこが本題でどこがついでの修正か」を差分全体から読み解く必要が出てしまいます。
分割の目安は次の3つです。
- 機能本体とテストは分ける：本体の意図を先に読んでもらい、テストは補強として後ろに置く
- AIが「ついでに」直した箇所は分ける：依頼していないリファクタや命名変更が混ざっていたら、意図的に別コミットへ
- 依存関係があるものは1つにまとめる：型定義の追加とそれを使う実装のように、片方だけでは動かない変更は無理に割らない
git add -p（パッチ単位でステージング）を使うと、1回で出力された差分でも意味ごとに拾ってコミットできます。
git add -p
# ハンクごとに y/n/s で選びながら意味の単位でステージング
実践チェックリスト
コミット前に、この5つを上から見ていくとブレにくくなります。
- このコミットを1つの動詞で言えるか
- コミットメッセージを見ただけで差分の内容が想像できるか
- 「ついでに直した」ものが混ざっていないか
- このコミット単体でビルド・テストが通るか
- revertしたときに、意図しない部分まで巻き込まないか
最後の「revertしたときに」が地味に重要です。1コミットに複数の意味が混ざっていると、片方だけ取り消したいときに困ります。
まとめ
粒度の正解は「作業の区切り」ではなく「意味の区切り」です。1コミット1動詞を基準にすれば、AIが生成した大きな差分でも迷わず分割できます。コミットログは未来の自分とチームへの手紙だと思って、意味の通じる単位で残していきましょう。
AI駆動開発を実務レベルで学べるエンジニア向けスクール「テックバディ」について
「テックバディ」は、生成AIを使いこなして実務レベルの開発をやりきる力を、模擬案件を通じて身につけるエンジニア向けスクールです。「AIに書かせるだけ」で終わらせず、設計力・品質担保力・判断力まで鍛えるカリキュラムで、現場で任される仕事の幅を広げたい方をサポートしています。