生成AIのためのGit入門 第5章：Claude Codeの成果物はgit diffで必ず確認する
山崎講師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 --cachedgit addとは、次のコミットに含める変更を選ぶ操作です。
ステージングとも呼ばれます。
ステージングとは、コミットする前に変更を一時的に並べておく場所へ置くことです。
劇でたとえるなら、本番に出す小道具を舞台袖に並べておくようなものです。
git diffは、まだステージしていない変更を見るコマンドです。
git diff --cachedは、すでにステージした変更を見るコマンドです。
| コマンド | 見る内容 |
|---|---|
| git diff | まだgit addしていない変更 |
| git diff --cached | git add済みで、次のコミットに入る変更 |
コミット前には、git diff --cachedを見る習慣をつけると安全です。
Claude Codeに差分の説明をさせる
git diffを見ても、最初は意味がわからないことがあります。
そんなときは、Claude Codeに差分の説明をさせるのも有効です。
今回のgit diffの内容を、新人エンジニアにもわかるように説明してください。
特にSQLの変更、削除されたコード、影響範囲を重点的に確認してください。
ただし、説明を聞いて終わりではありません。
AIの説明も確認対象です。
Claude Codeに説明させ、人間が差分を見て、納得できたらコミットする。
この流れが大切です。
先生に解説してもらったあと、自分でも問題を解くのと同じです。
聞いただけでは身につきません。
自分の目で確認しましょう。
差分確認で見るべきチェックリスト
Claude Codeの作業後にgit diffを見るときは、次のチェックリストを使ってください。
| チェック | 確認内容 |
|---|---|
| 1 | 依頼した目的に合う変更だけか |
| 2 | 関係ないファイルが変更されていないか |
| 3 | SQLのWHERE句やJOINが意図通りか |
| 4 | deleted_at IS NULLが消えていないか |
| 5 | PreparedStatementの番号がずれていないか |
| 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の作業が管理しやすくなる理由を解説します。
セイ・コンサルティング・グループでは新人エンジニア研修のアシスタント講師を募集しています。
投稿者プロフィール
