生成AIのためのGit入門　第5章：Claude Codeの成果物はgit diffで必ず確認する

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

Claude Codeに作業を依頼したあと、いきなり「動いたからOK」と判断してはいけません。

必ずgit diffで変更内容を確認しましょう。

Claude Codeは、コードベースを読み、ファイルを編集し、コマンドを実行できるエージェント型のコーディングツールです。つまり、人間の代わりに複数ファイルをまたいだ変更を行える力があります。だからこそ、変更後の確認が重要になります。:contentReference[oaicite:0]{index=0}

git diffは、変更前と変更後の差分を確認するためのGitコマンドです。Git公式ドキュメントでも、git diffはコミット間や作業ツリーとの差分を見るためのコマンドとして説明されています。

差分とは、「どこがどう変わったのか」という違いのことです。

たとえるなら、作文を先生に添削してもらったときの赤ペン部分です。

完成した作文だけを読むのではなく、「どの文章が消されたのか」「どの文章が追加されたのか」「どこが言い換えられたのか」を見る。

AIが書いたコードでも同じです。

完成品を見るだけではなく、差分を見てください！

なぜgit diffを見る必要があるのか

Claude Codeは便利ですが、AIが行った変更を人間が確認しないまま進めるのは危険です。

理由はシンプルです。

AIは速く作れますが、最終的な責任を持つのは人間だからです。

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

ユーザー検索機能に名前検索を追加してください。

Claude Codeは、UserDao.javaだけを変更するかもしれません。

しかし、場合によってはUserDto.java、UserController.java、SQL、テストコードまで変更するかもしれません。

それ自体は悪いことではありません。

でも、変更内容を確認しないと、次のような問題に気づけません。

確認しないと起きる問題内容
余計なファイルが変更される今回の目的と関係ない修正が混ざる
既存処理が変わる動いていた機能の挙動が変わる
SQL条件が抜けるdeleted_at IS NULLなど重要な条件が消える
命名規則が崩れるプロジェクト内の書き方と違うコードが増える
セキュリティ上の問題が入るSQLインジェクションの危険がある書き方になる

git diffを見ると、こうした問題に気づきやすくなります。

Claude Codeの作業を信頼することと、確認を省略することは別です。

信頼している先輩のコードでもレビューしますよね。

AIのコードも同じです。

git diffの基本的な使い方

Claude Codeが作業したあと、まず次のコマンドを実行します。

git diff





このコマンドを実行すると、まだコミットしていない変更内容を確認できます。





たとえば、UserDao.javaが変更されていれば、追加された行や削除された行が表示されます。





Gitの差分表示では、一般的に削除された行にはマイナス、追加された行にはプラスが付きます。





- SELECT user_id, name FROM users
+ SELECT user_id, name FROM users WHERE deleted_at IS NULL










この例では、WHERE deleted_at IS NULLが追加されています。





deleted_at IS NULLは、論理削除されていないデータだけを取得する条件です。





このように、git diffを見ると、コードの変更点をピンポイントで確認できます。





まずファイル単位で見る





git diffを見るとき、最初からすべての行を細かく読もうとすると疲れます。





まずは、どのファイルが変更されたのかを確認しましょう。





git status










たとえば、次のように表示されたとします。





modified:   src/main/java/com/example/demo/model/dao/UserDao.java
modified:   src/main/java/com/example/demo/model/dto/UserDto.java
modified:   src/main/resources/templates/user/list.html










この時点で、考えるべきことがあります。





今回の作業目的に対して、この3つのファイル変更は妥当でしょうか？





もし「DAOだけ直してほしい」と頼んだのにHTMLまで変更されていたら、確認が必要です。





HTMLの変更が必要な場合もあります。





でも、意図していないなら、Claude Codeに理由を聞くべきです。







なぜlist.htmlを変更したのか説明してください。
今回の目的に不要なら元に戻してください。












Claude Codeに作業させるときは、人間が監督者です。





AIに任せるのではなく、AIを使って開発を進めるという意識を持ちましょう。





次にSQLの変更を見る





新人エンジニアが特に注意して見てほしいのはSQLです。





SQLとは、データベースを操作するための言語です。





SQLの条件が少し変わるだけで、取得されるデータが大きく変わります。





たとえば、次の変更を見てください。





- SELECT car_id, name, price FROM cars WHERE deleted_at IS NULL
+ SELECT car_id, name, price FROM cars










この変更は危険です。





deleted_at IS NULLが消えています。





つまり、論理削除された車まで表示される可能性があります。





論理削除とは、データを完全に消さず、deleted_atに日時を入れて削除扱いにする方法です。





deleted_at IS NULLが消えると、ゴミ箱に入れた商品まで一覧に戻ってくるようなものです。





お店でたとえるなら、販売終了した商品をまた棚に並べてしまう状態です。





SQLのdiffを見るときは、特に次の点を確認してください。





確認ポイント理由
WHERE句検索条件が変わるため
JOIN取得するデータの範囲が変わるため
ORDER BY並び順が変わるため
LIMIT取得件数が変わるため
deleted_at IS NULL削除済みデータを除外するため
プレースホルダPreparedStatementの値と対応しているか確認するため





プレースホルダとは、SQLの中で値をあとから安全に入れるための?のことです。





PreparedStatementを使うと、SQLに直接文字列を連結するより安全に値を渡せます。





PreparedStatementの番号ずれに注意する





Claude CodeがSQL条件を追加したとき、PreparedStatementの番号がずれることがあります。





たとえば、元のコードが次のようになっていたとします。





String sql = "SELECT user_id, name FROM users WHERE name LIKE ?";
PreparedStatement statement = connection.prepareStatement(sql);
statement.setString(1, "%" + name + "%");










ここにrole条件を追加した場合、SQLは次のようになります。





String sql = "SELECT user_id, name FROM users WHERE role = ? AND name LIKE ?";
PreparedStatement statement = connection.prepareStatement(sql);
statement.setString(1, role);
statement.setString(2, "%" + name + "%");










このように、?の順番とsetStringの順番が一致している必要があります。





もし次のようになっていたら危険です。





String sql = "SELECT user_id, name FROM users WHERE role = ? AND name LIKE ?";
PreparedStatement statement = connection.prepareStatement(sql);
statement.setString(1, "%" + name + "%");
statement.setString(2, role);










roleに名前の検索文字列が入り、nameにroleが入ってしまいます。





お弁当でたとえるなら、ご飯の場所におかずを入れて、おかずの場所にご飯を入れているようなものです。





入れ物は同じでも、場所が違うと意味が変わります。





git diffでSQLが変わっていたら、PreparedStatementの番号も必ず確認しましょう。





削除されたコードを必ず見る





git diffでは、追加されたコードだけでなく、削除されたコードも重要です。





新人エンジニアは、つい「何が追加されたか」に目が行きがちです。





でも、実務では「何が消されたか」のほうが重要な場合があります。





たとえば、次のような削除があったとします。





- if (user == null) {
-     throw new IllegalArgumentException("ユーザーが存在しません。");
- }










このチェックが消えると、存在しないユーザーに対して処理が進んでしまうかもしれません。





別の例です。





- AND deleted_at IS NULL










この1行が消えただけで、削除済みデータまで対象になります。





さらに別の例です。





- connection.setAutoCommit(false);










トランザクション制御が消えている可能性があります。





トランザクションとは、複数のDB処理をひとまとまりとして扱う仕組みです。





銀行振込でたとえるなら、「Aさんの口座から引く」と「Bさんの口座に入れる」をセットで成功させる考え方です。





片方だけ成功すると困りますよね。





削除されたコードには、重要な安全装置が含まれていることがあります。





git diffでは、追加行だけでなく削除行も必ず見てください。





大量の差分が出たら危険サイン





Claude Codeに小さな修正を頼んだのに、git diffが大量に出ることがあります。





この場合は、すぐにコミットしないでください。





まず、変更が本当に必要か確認しましょう。





状況確認すること
1メソッド修正のはずなのに10ファイル変わった変更範囲が広すぎないか
フォーマット変更だけで大量差分が出た本質的な変更が埋もれていないか
関係ないクラス名が変わった命名変更が必要だったのか
テストの期待値が変わった仕様を勝手に変えていないか





大量差分は、部屋全体の模様替えに似ています。





椅子の位置だけ直してほしかったのに、机、本棚、ベッド、カーテンまで変わっていたら驚きますよね。





Claude Codeの大量差分も同じです。





必要な場合もあります。





でも、理由を確認するべきです。





今回の変更範囲が広い理由を説明してください。
目的に不要な変更があれば元に戻してください。










AIには、変更理由を説明させましょう。





説明できない変更は、基本的に入れないほうが安全です。





git diff ファイル名で1ファイルずつ確認する





差分が多い場合は、ファイルごとに確認すると読みやすくなります。





git diff src/main/java/com/example/demo/model/dao/UserDao.java










このように書くと、UserDao.javaの変更だけを確認できます。





一度に全部を見るより、1ファイルずつ確認したほうが理解しやすいです。





新人エンジニアには、この方法をおすすめします。





大量の差分を一気に見ると、途中で集中力が切れます。





教科書を1冊まるごと読むより、1章ずつ読んだほうが理解しやすいですよね。





git diffも同じです。





git diff --statで変更量をざっくり見る





まず全体の変更量だけ見たい場合は、次のコマンドが便利です。





git diff --stat










このコマンドを使うと、どのファイルにどれくらい変更が入ったかをざっくり確認できます。





たとえば、次のようなイメージです。





UserDao.java      | 25 +++++++++++++++++--------
UserDto.java      | 10 ++++++++--
UserController.java | 8 +++++---
3 files changed, 31 insertions(+), 12 deletions(-)










insertionsは追加された行、deletionsは削除された行です。





この表示を見ると、変更の大きさを把握できます。





小さな修正のはずなのに、20ファイル以上変わっていたら注意しましょう。





git diff --cachedでコミット前の差分を見る





git addしたあとに差分を確認したい場合は、次のコマンドを使います。





git diff --cached










git addとは、次のコミットに含める変更を選ぶ操作です。





ステージングとも呼ばれます。





ステージングとは、コミットする前に変更を一時的に並べておく場所へ置くことです。





劇でたとえるなら、本番に出す小道具を舞台袖に並べておくようなものです。





git diffは、まだステージしていない変更を見るコマンドです。





git diff --cachedは、すでにステージした変更を見るコマンドです。





コマンド見る内容
git diffまだgit addしていない変更
git diff --cachedgit add済みで、次のコミットに入る変更





コミット前には、git diff --cachedを見る習慣をつけると安全です。





Claude Codeに差分の説明をさせる





git diffを見ても、最初は意味がわからないことがあります。





そんなときは、Claude Codeに差分の説明をさせるのも有効です。







今回のgit diffの内容を、新人エンジニアにもわかるように説明してください。
特にSQLの変更、削除されたコード、影響範囲を重点的に確認してください。












ただし、説明を聞いて終わりではありません。





AIの説明も確認対象です。





Claude Codeに説明させ、人間が差分を見て、納得できたらコミットする。





この流れが大切です。





先生に解説してもらったあと、自分でも問題を解くのと同じです。





聞いただけでは身につきません。





自分の目で確認しましょう。





差分確認で見るべきチェックリスト





Claude Codeの作業後にgit diffを見るときは、次のチェックリストを使ってください。





チェック確認内容
1依頼した目的に合う変更だけか
2関係ないファイルが変更されていないか
3SQLのWHERE句やJOINが意図通りか
4deleted_at IS NULLが消えていないか
5PreparedStatementの番号がずれていないか
6削除されたコードに重要な処理が含まれていないか
7例外処理や入力チェックが消えていないか
8既存の命名規則や書き方に合っているか
9テストの期待値を都合よく変えていないか
10自分が変更理由を説明できるか





最後の「自分が変更理由を説明できるか」は、とても大切です。





AIが書いたコードでも、チームに入れるなら自分の変更です。





レビューで聞かれたときに説明できない変更は、まだ理解が足りていないサインです。





差分確認後にコミットする





git diffで問題がないと判断できたら、コミットします。





git add .
git commit -m "ユーザー検索に名前条件を追加"










コミットメッセージは、変更内容がわかるように書きましょう。





悪い例です。





git commit -m "修正"










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





良い例です。





git commit -m "ユーザー検索に名前条件を追加"










このメッセージなら、あとから見ても内容がわかります。





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





文化祭の準備ノートに「買い出し」とだけ書くより、「飲み物と紙皿を購入」と書いたほうがわかりやすいですよね。





コミットメッセージも具体的に書きましょう。





第5章のまとめ





Claude Codeの成果物は、必ずgit diffで確認しましょう。





Claude Codeはコードベースを理解し、ファイル編集やコマンド実行を行える強力なツールです。だからこそ、変更内容を人間が確認する必要があります。





ポイント内容
git diffを見るAIがどこをどう変えたか確認する
SQLを重点的に見る条件変更がバグにつながりやすいため
削除行を見る重要な安全装置が消えていないか確認する
大量差分に注意する目的外の変更が混ざっている可能性がある
説明できる変更だけコミットするAIの変更でも責任は人間が持つため





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





Claude Codeにコードを書かせたら、git diffで赤ペン確認をする。





完成品だけを見るのではなく、変更点を見る。





追加されたコードだけでなく、削除されたコードも見る。





SQL、例外処理、入力チェック、削除条件を特に注意して見る。





この習慣があるだけで、AI開発の安全性はかなり上がります。





次章では、小さくコミットするとClaude Codeの作業が管理しやすくなる理由を解説します。





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


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



山崎講師代表取締役

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

岐阜県出身。

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

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

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

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



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



			


	
	
	
	
		
				


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


		
	







	
前の記事
生成AIのためのGit入門　第4章：ブランチを切るだけでAI開発はかなり安全になるNew!!
2026年6月11日

	
次の記事
生成AIのためのGit入門　第6章：小さくコミットするとClaude Codeの作業が管理しやすくなるNew!!
2026年6月11日