Gitコミットはセーブポイント、履歴は物語 〜 AI時代だからこそコミット粒度を考える 〜

2026年6月16日

Gitを教えていると、コミットについていろいろ考えさせられます。 正直に言うと、私自身も昔はこんなコミットをしていました。

fix
fix2
final
final2
really_final

……気持ちはよく分かります。動いた瞬間に「とりあえずコミット！」したくなるんですよね。 実は今でも、ローカル作業中には似たようなコミットをすることがあります。 なので、この記事は誰かを注意するためではありません。私自身も試行錯誤している中で、今感じていることを書いてみます。

コミットはセーブポイント

私はコミットを説明するとき、よくこう言います。

コミットはゲームでいうセーブポイントです。

例えばアクションゲームで、ボス戦の前にセーブしておけば安心ですよね。プログラムも同じです。 作業中に、

• UIをいじった
• AI生成コードを入れた
• バグ修正した

そんなタイミングでコミットしておけば、「やっぱり戻したい」ができます。

作業中は細かくコミットしていい

ここは誤解されやすいところです。私は、作業中は細かくコミットしてよいと思っています。 例えばこんな感じです。

UIのボタン配置
ボタンイベント追加
OCR結果表示
NullReference修正

細かいコミットにはメリットがあります。 1. どこで壊れたか追いやすい
「このコミットまでは動いていた」が分かります。 2. 失敗を恐れず試せる
大胆な変更がしやすくなります。 3. AI時代に特に有効
これが最近特に感じることです。

AIは一瞬で大量変更する

生成AIでコードを書くと、こんなことが起きます。

• 1回の指示で200行増える
• 複数ファイルが変更される
• 動くけど理由が分からない

便利ですが、危険でもあります。私自身、AIを使っていて、

この変更、どこから壊れた？

となることが増えました。だからこそ、AIに大きな作業をさせる前後でコミットするのが大事だと思っています。 例えば：

AI導入前
AIによるインベントリ画面生成
生成コードの整理

これだけでも安心感がかなり違います。

最初は「fix」でも十分

ここで誤解してほしくないことがあります。最初から完璧なコミットメッセージを書く必要はありません。 受講生を見ていると、最初はそもそも

• commit が怖い
• push が怖い
• branch が怖い

という人が多いです。でも、コミットできるようになった時点で、すでに大きな前進です。 最初は fix でもいいんです。ただ、チーム開発になると、もう一歩先が必要になります。

共有前はコミットを見直す

作業中は細かくてOKです。ただ、そのまま共有ブランチに入れる前に、少し立ち止まって履歴を見てみるのがおすすめです。 例えばこういう履歴：

fix
fix2
fix3
wip
wip2

作業中なら問題ありません。でも、後から見返した時に「何をしたコミットだったんだろう？」となりやすいです。 なので共有前には、

• 細かすぎないか
• 意味が重複していないか
• 後から見て分かるか

を少し意識すると良いと思います。

履歴は未来の自分へのメッセージ

私はコミットメッセージをこう考えています。

コミットは過去の記録ではなく、未来の自分へのメッセージ

重要なのは「何をしたか」だけでなく、「なぜそれをしたか」です。 悪い例：

fix bug

良い例：

プレイヤー死亡時にHPが0未満になる不具合を修正

後者のほうが、後から見た時に思い出しやすいです。

mainブランチは綺麗に保つ

チーム開発では特に重要です。私はこんなイメージで考えています。

場所	方針
ローカル	細かく自由にコミット
Pull Request 前	コミットを見直す
main	意味のある履歴を残す

私はこれをこう表現しています。

ローカルは作業場　Pull Request はレビュー室　main は展示室

展示室に工具を散らかしたまま置かないですよね。

AI時代でも、いやAI時代だからこそ

「AIがコードを書くならGitは不要では？」そう思う人もいるかもしれません。私は逆だと思っています。 AI時代になるほど、

• 変更量が増える
• 開発速度が上がる
• 人間の理解が追いつかない

だからこそ Git が必要です。Gitは単なるバックアップではありません。

Gitは、変更の意味を管理する道具

だと思っています。

まとめ

私のおすすめはシンプルです。

• 作業中は細かくコミット
• 共有前に少し見直す
• mainは綺麗に保つ

そして最後に、一番伝えたいこと。

コミットはセーブポイント　履歴は物語

この記事は、誰かを注意するために書いたものではありません。私自身もまだ試行錯誤しています。 ただ、皆さんが半年後、1年後にコードを見返した時、「あの時Gitをちゃんと学んで良かった」と思ってもらえたら、嬉しいです。 ※ちなみに Git には、履歴そのものを整理する、さらに高度な機能もあります。それについては、また別の記事で紹介したいと思います。