生成AIのためのGit入門　第6章：小さくコミットするとClaude Codeの作業が管理しやすくなる

2026年6月11日 最終更新日時 : 2026年6月11日 山崎講師山崎講師

Claude Codeを使うと、実装スピードが上がります。

でも、スピードが上がるからこそ、Gitのコミットは小さく分けることが大切です。

Claude Code公式ドキュメントでは、Claude Codeはコードベースを読み、ファイルを編集し、コマンドを実行し、開発ツールと連携できるエージェント型のコーディングツールだと説明されています。つまり、複数ファイルをまたいだ作業を一気に進められる力があります。

一方で、Gitのcommitは、インデックスに入っている現在の変更内容を、変更説明のメッセージと一緒に新しいコミットとして記録するコマンドです。

少し難しく聞こえますね。

簡単に言うと、コミットは「ここまでの作業を1つのまとまりとして保存すること」です。

ゲームでたとえるなら、セーブポイントです。

ただし、セーブポイントは細かく作ったほうが安全です。

最初の町からラスボス直前まで一度もセーブしないと、失敗したときに大変ですよね。

開発も同じです。

Claude Codeにたくさん作業してもらうほど、こまめにコミットしましょう。

小さくコミットするとは何か

小さくコミットするとは、1つの目的ごとに変更を保存することです。

たとえば、次のような単位です。

コミット単位内容
DTOを追加するデータ受け渡し用のクラスだけを追加する
DAOに検索処理を追加するSQLとResultSetの詰め替え処理だけを書く
入力チェックを追加するバリデーション処理だけを追加する
テストを追加する既存処理のテストだけを書く
不要なコードを整理する動きを変えずに読みやすくする

逆に、大きすぎるコミットは次のようなものです。

ログイン機能を追加して、検索機能も作って、DAOを整理して、CSSも直して、テストも追加する

このようなコミットは、あとから見返したときに何をしたのかわかりにくくなります。

お弁当でたとえるなら、ご飯、おかず、デザート、飲み物を全部ぐちゃぐちゃに混ぜて1つの箱に入れるようなものです。

食べられるかもしれません。

でも、何が入っているのか確認しにくいですよね。

コミットも同じです。

Claude Codeは速いからこそ変更が大きくなりやすい

Claude Codeは、人間より速く複数ファイルを編集できます。

たとえば、次のように依頼したとします。

ユーザーのマッチング機能を作ってください。

この依頼だけだと、Claude Codeはたくさんの作業を一気に行うかもしれません。

作業変更される可能性があるもの
DTO作成MatchedUserDto.java
DAO作成UserMatchingDao.java
SQL追加同じ商品にLIKEしたユーザーを取得するSQL
mainメソッド追加DAO単体で実行する処理
サンプルデータ追加INSERT文
既存クラス修正パッケージ名やimportの調整

このすべてを1つのコミットに入れると、確認が大変です。

レビューする人も、「DTOの追加を見ればいいのか」「SQLの妥当性を見ればいいのか」「mainメソッドの動作確認を見ればいいのか」がわかりにくくなります。

Claude Codeの作業が速いほど、人間側は変更を小さな箱に分ける必要があります。

AIに一気に荷物を運んでもらうとしても、段ボールにはラベルを貼って分けておきたいですよね。

小さなコミットはレビューしやすい

小さなコミットの大きなメリットは、レビューしやすいことです。

レビューとは、コードの変更内容を確認する作業です。

たとえば、次の2つを比べてみましょう。

コミットレビューのしやすさ
ユーザー機能を全部追加変更範囲が広く、確認が大変
MatchedUserDtoを追加DTOだけ見ればよいので確認しやすい
UserMatchingDaoにSQLを追加SQLとDB取得処理に集中して確認できる
mainメソッドで動作確認を追加実行用コードだけ確認できる

小さなコミットなら、見るべきポイントがはっきりします。

DTO追加のコミットなら、フィールド名、getter、setter、toStringを見る。

DAO追加のコミットなら、SQL、PreparedStatement、ResultSetを見る。

テスト追加のコミットなら、テストケースと期待値を見る。

確認する場所が狭いので、ミスにも気づきやすくなります。

試験勉強でたとえるなら、教科書1冊を一気に復習するより、今日は第1章だけ確認するほうが集中できますよね。

コミットも同じです。

小さなコミットは原因調査しやすい

小さなコミットは、バグが出たときにも役立ちます。

たとえば、Claude Codeにいろいろ作業してもらったあと、急にログイン機能が動かなくなったとします。

1つの巨大なコミットに全部入っている場合、原因を探すのが大変です。

巨大コミットの場合困ること
DAOもDTOもControllerもSQLも同時に変更どこが原因かわかりにくい
テストの期待値も同時に変更仕様変更なのかバグなのかわかりにくい
リファクタリングも混ざっている動きの変更と整理の変更が区別しにくい

一方で、小さくコミットしていれば、次のように追えます。

コミット確認できること
DTO追加データの入れ物だけ追加された
DAO追加DB取得処理が追加された
ログイン条件修正ログインに関わるSQLだけ変更された
テスト追加動作確認用のテストだけ追加された

バグが出たときに、「ログイン条件修正のコミットからおかしくなったかもしれない」と見当を付けられます。

料理でたとえるなら、味見をしながら少しずつ調味料を入れるようなものです。

塩、砂糖、醤油、ソースを一気に入れると、味がおかしくなったときに原因がわかりません。

少しずつ入れれば、「塩を入れすぎたな」と気づけます。

Claude Codeへの依頼も小さくする

小さくコミットするためには、Claude Codeへの依頼も小さくする必要があります。

悪い依頼例です。

Warning
ユーザーマッチング機能を全部作ってください。

この依頼だと、Claude Codeは広い範囲を一気に変更しがちです。






良い依頼例です。





Success


まず、マッチング結果を表すMatchedUserDtoだけを作成してください。
フィールドはmatchedUserId、matchedUserName、commonLikeCount、commonItemTitlesにしてください。
DAOやSQLはまだ作成しないでください。












この依頼なら、作業範囲がDTOだけに絞られます。





そのあと、差分を確認してコミットします。





git status
git diff
git add src/main/java/com/example/demo/model/dto/MatchedUserDto.java
git commit -m "マッチング結果用DTOを追加"










次にDAOを依頼します。





Success


次に、SuperDaoを継承したUserMatchingDaoを作成してください。
同じ商品にLIKEしたユーザーを1名取得するSQLを書いてください。
ServiceとREST APIは作成しないでください。












このように、Claude Codeへの依頼を小さく分けると、コミットも自然に小さくなります。





コミットメッセージは何をしたかがわかるように書く





小さくコミットしても、コミットメッセージが雑だと効果が下がります。





悪い例です。





git commit -m "修正"










これでは、何を修正したのかわかりません。





次のようなメッセージのほうがよいです。





git commit -m "マッチング結果用DTOを追加"

git commit -m "LIKEが共通するユーザーを1名取得するDAOを追加"

git commit -m "UserMatchingDaoに動作確認用mainメソッドを追加"










コミットメッセージは、未来の自分へのメモです。





1週間後、1か月後に見返したとき、「このコミットで何をしたのか」がわかるように書きましょう。





学校のノートでも、「メモ」とだけ書いてあるページより、「英語の比較級まとめ」と書いてあるページのほうが探しやすいですよね。





コミットメッセージも同じです。





1コミット1目的を意識する





小さくコミットするうえで大切なのは、1コミット1目的です。





1つのコミットには、1つの目的だけを入れます。





悪いコミット理由
ログイン修正とCSS変更を同時に入れる目的が違う変更が混ざっている
バグ修正とリファクタリングを同時に入れる動きの変更と整理の変更が区別しにくい
DTO追加とSQL修正とテスト修正を全部入れるレビュー範囲が広くなりすぎる





良いコミットです。





良いコミット目的
マッチング結果用DTOを追加データの入れ物を用意する
LIKE共通ユーザー取得SQLを追加マッチング対象を取得できるようにする
動作確認用mainメソッドを追加DAO単体で実行できるようにする
不要なimportを削除コードを整理する





1コミット1目的にすると、変更理由を説明しやすくなります。





レビューでも、「このコミットはDTO追加です」と説明できます。





目的が明確なコミットは、チームにとっても親切です。





AIの変更をそのまま全部コミットしない





Claude Codeが作業したあと、すぐにgit add .で全部コミットしたくなるかもしれません。





git add .
git commit -m "Claude Codeの修正"










でも、この流れは注意が必要です。





git add .は、現在のディレクトリ配下の変更をまとめてステージします。





便利ですが、不要なファイルまで入ることがあります。





たとえば、次のようなものです。





混ざる可能性があるもの問題
一時ファイル本来コミット不要
ログファイル環境依存の情報が入る可能性がある
試しに作ったサンプル本番コードに不要
関係ない修正コミットの目的がぼやける





新人エンジニアのうちは、まずgit statusで変更ファイルを確認してください。





git status










そのうえで、必要なファイルだけgit addする方法もおすすめです。





git add src/main/java/com/example/demo/model/dto/MatchedUserDto.java










このように、ファイルを指定して追加すると、コミットに入る内容をコントロールできます。





慣れてきたらgit add .を使ってもよいですが、最初は「何をコミットするのか」を意識することが大切です。





git diff --cachedでコミット前に最終確認する





git addしたあと、コミット前にもう一度確認しましょう。





git diff --cached










git diff --cachedは、次のコミットに入る変更を確認するコマンドです。





つまり、「今から保存しようとしている内容」を見るためのコマンドです。





お弁当のふたを閉める前に、中身を確認するようなものです。





ご飯、おかず、箸がちゃんと入っているか。





入れなくてよいものが混ざっていないか。





コミットも同じです。





コミットする前に、中身を見てください。





git diff --cached










確認して問題なければ、コミットします。





git commit -m "LIKEが共通するユーザーを1名取得するDAOを追加"










小さくコミットするとClaude Codeにやり直しを頼みやすい





小さくコミットしておくと、Claude Codeにやり直しを頼みやすくなります。





たとえば、DTO追加まではよかった。





でも、DAOのSQLが少し複雑すぎた。





この場合、DTO追加のコミットは残したまま、DAOの変更だけ戻してやり直せます。





もしDTO、DAO、mainメソッド、SQL、サンプルデータを全部1つの変更として扱っていたら、どこまで戻すかが難しくなります。





小さなコミットは、作業の区切りです。





区切りがあるから、戻る場所がはっきりします。





登山でたとえるなら、途中の休憩ポイントです。





休憩ポイントがあれば、道を間違えたときにそこまで戻れます。





休憩ポイントなしで一気に進むと、どこから間違えたのかわかりません。





コミット前にテストや実行確認をする





コミットする前には、できる範囲で動作確認をしましょう。





Claude Codeがコードを書いてくれても、動作確認は必要です。





たとえば、DAOにmainメソッドがあるなら、mainメソッドを実行します。





LIKEベースのユーザーマッチングを開始します。
対象ユーザーID: 1
マッチング対象ユーザー:
MatchedUserDto{matchedUserId=2, matchedUserName='佐藤', commonLikeCount=2, commonItemTitles='Java入門書, MySQL入門書'}
処理を終了します。










このように、想定通りの結果が出るか確認します。





テストコードがあるプロジェクトなら、テストも実行します。





mvn test










または、Gradleなら次のようになります。





./gradlew test










実行確認してからコミットすると、そのコミットの信頼性が上がります。





「この時点では動いていた」と言えるからです。





Claude Codeにコミット単位を指定して依頼する





Claude Codeに依頼するとき、最初からコミット単位を意識した指示を出すのも効果的です。





たとえば、次のように頼みます。







今回はDTOの追加だけを行ってください。
DAO、Service、Controller、テストは変更しないでください。
変更後に、コミットメッセージ案も1つ提案してください。












または、次のように頼みます。







今回はUserMatchingDaoだけを作成してください。
DTOは既存のMatchedUserDtoを使ってください。
mainメソッドはまだ作成しないでください。
変更後にgit diffで確認すべきポイントを説明してください。












このように依頼すると、Claude Codeの作業範囲が狭くなります。





AIに「小さく作って」と伝えることが大切です。





AIは便利な助手ですが、作業範囲を決めるのは人間です。





小さくコミットする流れの具体例





ユーザーマッチング機能をClaude Codeで作る場合、次のように進めると管理しやすくなります。





手順Claude Codeへの依頼コミットメッセージ例
1MatchedUserDtoだけ作成するマッチング結果用DTOを追加
2UserMatchingDaoの骨組みだけ作成するUserMatchingDaoの基本構造を追加
3同じ商品にLIKEしたユーザーを取得するSQLを追加する共通LIKEユーザー取得SQLを追加
4ResultSetからDTOへ詰め替える処理を追加するマッチング結果をDTOに変換する処理を追加
5mainメソッドで動作確認できるようにするUserMatchingDaoに動作確認用mainメソッドを追加





このように分けると、各コミットで見るべき内容が明確になります。





コミットごとにgit diffを確認し、問題なければ保存する。





この積み重ねが、Claude Codeを安全に使うコツです。





小さくコミットするメリット





ここまでの内容を、メリットとして整理します。





メリット内容
レビューしやすい変更範囲が小さいので確認しやすい
原因調査しやすいどの変更で問題が起きたか追いやすい
戻しやすい不要な変更だけ取り消しやすい
説明しやすい1コミット1目的なので理由を伝えやすい
Claude Codeに再依頼しやすい失敗した部分だけやり直せる





小さなコミットは、開発の整理整頓です。





Claude Codeで速く作る。





Gitで小さく保存する。





git diffで確認する。





この流れができると、AI開発はかなり安定します。





小さくコミットするデメリット





もちろん、小さくコミットすることにも少しデメリットはあります。





デメリット内容
最初は手間に感じる作業を分ける必要がある
コミット数が増える履歴が細かくなる
どこで区切るか迷う慣れるまで判断が難しい





ただし、このデメリットは慣れると小さくなります。





むしろ、あとから巨大な変更を読み解くほうが大変です。





最初に少し丁寧に分けることで、あとからの確認、レビュー、修正が楽になります。





宿題を毎日少しずつやるのは少し面倒です。





でも、提出日前日に全部やるよりずっと安全ですよね。





コミットも同じです。





第6章のまとめ





Claude Codeを使うなら、コミットは小さく分けましょう。





Claude Codeはコードベースを読み、複数ファイルをまたいで作業できる強力なツールです。だからこそ、Gitのコミットで変更を小さな単位に整理することが重要です。





ポイント内容
小さく依頼するClaude Codeへの作業指示を小さく分ける
小さく確認するgit diffで変更内容を確認する
小さくコミットする1コミット1目的で保存する
具体的なメッセージを書くあとから見て内容がわかるようにする
コミット前に動作確認するその時点で動いていることを確認する





一言でまとめるなら、こうです。





Claude Codeに速く作らせるなら、Gitでは小さく保存する。





AIはアクセルです。





小さなコミットは、途中で何度も作る安全なセーブポイントです。





セーブポイントが多いほど、安心して先へ進めます。





新人エンジニアのうちは、1つのコミットにいろいろ詰め込まないでください。





DTOを追加したらコミット。





DAOを追加したらコミット。





SQLを直したらコミット。





テストを追加したらコミット。





このように小さく進めるだけで、Claude Codeの作業はかなり管理しやすくなります。





次章では、失敗しても戻せるからこそ、Claude Codeに大胆な作業を任せられる理由を解説します。





セイ・コンサルティング・グループでは新人エンジニア研修のアシスタント講師を募集しています。


投稿者プロフィール
山崎講師



山崎講師代表取締役

セイ・コンサルティング・グループ株式会社代表取締役。

岐阜県出身。

2000年創業、2004年会社設立。

IT企業向け人材育成研修歴業界歴20年以上。

すべての無駄を省いた費用対効果の高い「筋肉質」な研修を提供します！

この記事に間違い等ありましたらぜひお知らせください。



学生時代は趣味と実益を兼ねてリゾートバイトにいそしむ。長野県白馬村に始まり、志賀高原でのスキーインストラクター、沖縄石垣島、北海道トマム。高じてオーストラリアのゴールドコーストでツアーガイドなど。現在は野菜作りにはまっている。



			


	
	
	
	
		
				


					
対象読者
新人エンジニア研修講師
									


		
	







	
前の記事
生成AIのためのGit入門　第5章：Claude Codeの成果物はgit diffで必ず確認するNew!!
2026年6月11日

	
次の記事
生成AIのためのGit入門　第7章：失敗しても戻せるから、AIに大胆な作業を任せられるNew!!
2026年6月11日