AI生成物でGitを重くしない整理術

課題

AIで作った画像や、記事一覧から自動生成したページをGitへ追加し続けていると、気づかないうちにGitリポジトリの履歴が重くなることがある。

「大事なものは全部Commitしておけば安心」と考えがちだが、再生成できるファイルと、失うと作り直せない資料を同じように扱うと、後から整理が難しくなる。

AIを使う開発やコンテンツ制作で増えるファイルを、Gitへ残すべきものと、別の置き方を考えるべきものに分けられるようにする。

今回、Gitリポジトリの実サイズは505MBまで増えていた。最大の要因は、記事一覧ページの生成HTMLを、更新のたびに丸ごとGitへ記録していたことだった。

一方、実践用のスクリーンショットやAI生成画像は、同じように容量を使っていても、作り直せない一次資料だった。

この2種類を分けた。

最初にGitリポジトリ全体を調べると、.gitの実サイズは505MBあった。

AI生成画像が主因にも見えるが、履歴上のファイルをサイズごとに集計すると、最大要因は別だった。記事一覧を表示するためのHTMLだった。

このHTMLは、記事の状態が変わるたびに、画像を埋め込んだページ全体を再生成していた。1ファイルの現在サイズだけを見ると見落としやすいが、109版を履歴へ残した結果、履歴上では約853MB相当になっていた。

「今のファイルがそこまで大きくないなら大丈夫」とは言い切れない。毎回丸ごと生成し直すファイルは、履歴の中で何度も同じ種類の容量を使う。

ファイルを整理するとき、容量だけで削除候補を決めると危ない。今回は、次の2つに分けた。

種類	今回の例	扱い
再生成できる派生物	記事データから作る一覧ページHTML	Git管理から外す
作り直せない一次資料	実践時のスクリーンショット、AI生成画像	削除せずGit LFS（大きなファイルを別枠で管理する仕組み）へ移す

一覧ページは、元になる記事データが残っていれば再び作れる。履歴に全版を残しておく価値は低かった。

一方、実際に操作した画面のスクリーンショットや、その時点で採用した生成画像は、同じ条件で再び作れるとは限らない。「容量が大きいから消す」ではなく、保存場所を変える判断にした。

こう思う人もいるかもしれない。

「画像も全部生成し直せるなら、Gitから外してしまえばいいのでは？」

同じ生成指示を使っても、AI生成の結果は毎回同じとは限らない。さらに、実践中の画面や比較用の画像は、その時点で何を確認したかを示す記録でもある。後から必要になったときに困らないよう、保持する方を選んだ。

現在のGit管理から外すだけでは、過去の履歴に残った大きなファイルは小さくならない。

今回は、履歴から再生成可能なHTMLを除外し、画像をGit LFSへ移す対応を行った。この種の移行は履歴を書き換え、共有先との整合を変える可能性がある。

そこで、先に次を確認した。

ここを省くと、「容量は減ったが、必要な画像や履歴を失った」という別の事故になりかねない。

対応後、新しく取得したGitリポジトリの.git実サイズは約14MBになった。容量だけを見ると、505MBから約97%減ったことになる。

ただし、これで直ちにバックアップを消すことにはしなかった。LFSへ移した画像を含む記事制作や公開の流れを数回運用して、問題がないと確認できるまでは保持する。

「移行が完了した」と「移行後の運用が安定した」は別の完了条件になる。ここを分けておくと、後から戻る余地を残せる。

項目	内容
結論	Gitを重くする生成物は、再生成可能な派生物と一次資料を分けて扱う
教訓	容量ではなく、作り直せるか・記録として必要かで保存先を決める
対象読者	AI生成画像や自動生成ページをGitで管理している人

同じ状況に陥ったときの回避策