AI駆動開発中に、Gitのcore.autocrlfで改行コード差分にハマった話

はじめに

AIにコード修正をお願いしながら開発していると、作業スピードがかなり上がります。

ただ、その一方で、

え、なんでこのファイル全部差分になってるの？

ということがありました。

実際に変更したのは一部だけなのに、Git上ではファイル全体が変更されたように見える。

GitHubのGUI上で確認しても、ぱっと見では何が変わったのか分からない。

最初はVSCodeのフォーマット設定や、AIが余計な整形をしたのかと思っていました。

しかし原因を調べてみると、Gitの core.autocrlf による改行コードの自動変換 が原因でした。

今回は、AI駆動開発中にハマったLF/CRLFの改行コード差分についてまとめます。

そもそもLF、CRLFとは

LF、CRLFは改行コードの種類です。

テキストファイルでは、画面上では同じように改行されて見えますが、内部的には別の文字として扱われます。

種類	主に使われる環境
LF	Linux / macOS
CRLF	Windows

見た目ではほとんど違いが分かりません。

しかし、Gitから見るとLFとCRLFは別物として扱われることがあります。

そのため、コードの中身はほとんど変わっていないのに、改行コードだけが変わったことで、ファイル全体が変更されたような差分になることがあります。

今回起きたこと

今回のプロジェクトでは、改行コードはLFで統一するルールでした。

そのため、VSCode上でもLFに統一したつもりでした。

しかし、AIにコード修正をさせたあと、Gitの差分を確認すると、変更した覚えのないファイルまで大量に差分として表示されていました。

GitHubのGUI上で見ると、コードの内容自体はほとんど変わっていないように見えます。

そのため、最初は原因が分かりませんでした。

TortoiseGitなどの差分ツールで確認したところ、LFからCRLFに変換されていることが分かりました。

つまり、コードのロジックが大きく変わったのではなく、改行コードが変わったことで差分が大量に発生していました。

原因はGitのcore.autocrlfだった

今回の主な原因は、VSCodeというよりGit側の設定でした。

Windows環境で以下のコマンドを実行します。

git config core.autocrlf

ここで以下のように返ってきた場合、Gitが改行コードを自動変換する設定になっています。

true

core.autocrlf が true の場合、GitがLFとCRLFを自動で変換します。

Windows環境では、チェックアウト時にCRLFへ変換されることがあります。

そのため、プロジェクトとしてはLFで統一していたつもりでも、Git側の設定によってCRLFに変換されてしまう場合があります。

今回も、LFで統一したつもりのファイルが、Gitの設定によってCRLFに変換されていました。

その結果、コードの中身はほとんど変わっていないのに、ファイル全体が変更されたような差分になっていました。

対処法

改行コードをGitに自動変換されたくない場合は、以下のコマンドを実行します。

git config core.autocrlf false

グローバル設定として変更する場合は、以下です。

git config --global core.autocrlf false

これで、Gitによる改行コードの自動変換を無効化できます。

設定後、以下のコマンドで確認します。

git config core.autocrlf

または、グローバル設定を確認する場合は以下です。

git config --global core.autocrlf

false と表示されれば、自動変換は無効になっています。

ただし、チーム開発の場合は、自分だけで判断して設定を変えるのではなく、プロジェクトのルールに合わせる必要があります。

.gitattributesでリポジトリ側にルールを書く

個人のGit設定だけに依存すると、開発者ごとに挙動が変わる可能性があります。

そのため、リポジトリ全体で改行コードを統一したい場合は、.gitattributes を使う方法があります。

例えば、LFで統一したい場合は以下のように書きます。

* text=auto eol=lf

これをリポジトリに追加しておくことで、個人の環境差による改行コードのブレを減らせます。

チーム開発では、個人のGit設定だけでなく、.gitattributes でルールを明示しておく方が安全だと思います。

VSCode側の設定も確認する

今回の主原因はGitの core.autocrlf でしたが、VSCode側の設定も確認しておくとよいです。

VSCodeでは、画面右下に現在の改行コードが表示されています。

例えば以下のように表示されます。

LF
CRLF

ここをクリックすると、そのファイルの改行コードを変更できます。

また、VSCodeの settings.json に以下を設定すると、新規ファイルの改行コードをLFにできます。

{
  "files.eol": "\n"
}

プロジェクトでLFに統一している場合は、VSCode側でもLFになるようにしておくと安心です。

AI駆動開発時に注意したいこと

CodexなどのAIにコード修正を任せると、コードの中身は正しくても、保存時に改行コードが変わることがあります。

特に注意したいのは以下です。

既存ファイルはLFだったのに、AI修正後にCRLFになる
コーディング規約ではLF統一なのに、CRLFで保存される
GitHubのGUI上では差分の原因が分かりにくい
差分がファイル全体に広がり、レビューしにくくなる
本当に確認すべき修正箇所が埋もれる

AIを使うと修正スピードは上がります。

ただし、AIが出したコードをそのまま信じるのではなく、差分の内容まで確認する必要があります。

特に、修正量の割に差分が多すぎる場合は、改行コードやフォーマット変更が混ざっていないか確認した方がよいです。

AGENTS.mdなどにルールを書いておく

AIにコード修正を依頼する場合、プロジェクトのルールを明示しておくと安全です。

例えば、AGENTS.md などに以下のように書いておきます。

## コーディング規約

- 改行コードはLFで統一してください
- 既存ファイルの改行コードをCRLFに変更しないでください
- 不要なフォーマット変更は行わないでください
- 修正対象以外のファイル差分を出さないでください

AIに依頼するときも、プロンプトで以下のように明示するとよいです。

既存の改行コードは変更しないでください。
LFで統一してください。
必要な箇所以外のフォーマット変更は行わないでください。

これを書いたからといって必ず防げるわけではありません。

しかし、AIが修正するときの前提条件として伝えておくことで、余計な差分が発生する可能性を下げられます。

コミット前に確認すること

コミット前には、差分の量が不自然に多くないか確認します。

例えば、以下のコマンドで差分の概要を確認できます。

git diff --stat

また、空白や改行まわりの問題を確認する場合は以下も使えます。

git diff --check

差分が想定より多い場合は、すぐにコミットせず、以下を確認した方がよいです。

改行コードがLFからCRLFに変わっていないか
不要なフォーマット変更が入っていないか
AIが修正対象外のファイルまで変更していないか
GitHub上では分かりにくい差分になっていないか

自分の場合は、TortoiseGitで確認することで、LF/CRLFの変換が原因だと分かりました。

GitHubのGUIだけでは分かりにくい場合があるので、別の差分ツールで確認するのも有効だと思います。

まとめ

今回、AI駆動開発中に大量の差分が出てしまい、原因を調べたところ、Gitの core.autocrlf による改行コードの自動変換が原因でした。

Windows環境では、Gitの設定によってLFがCRLFに変換されることがあります。

確認コマンドは以下です。

git config core.autocrlf

true になっている場合、自動変換が有効になっています。

自動変換を無効にしたい場合は、以下を実行します。

git config core.autocrlf false

プロジェクト全体でLFに統一したい場合は、.gitattributes に以下のように書く方法もあります。

* text=auto eol=lf

AIは便利ですが、最終的にコミットするのは自分です。

コードの内容だけでなく、改行コードや不要なフォーマット変更も確認する必要があります。

特にAI駆動開発では、修正スピードが上がる分、差分確認の重要性も上がると感じました。

今後は、以下を意識して開発していきたいです。

Gitの core.autocrlf を確認する
VSCodeの改行コード設定を確認する
.gitattributes でルールを明示する
AIへの指示に改行コードのルールを書く
コミット前に差分をよく確認する

改行コードは見た目では分かりにくいですが、Git差分としては大きなノイズになります。

同じように、AI駆動開発中に謎の大量差分が出た場合は、LF/CRLFの変換を疑ってみるとよいかもしれません。