---
title: Claude Codeにクソみたいなhookを書かせて、個人開発のバカデカいコミット問題をなんとかしている話
description: 個人開発で巨大コミットが量産されがちな問題を、Claude Codeのstop hookで力技解決している話。
pubDate: 2026-05-08T00:00:00.000Z
tags: ["vibe-coding", dev, ai]
canonical_url: "https://toyoshima.work/blog/claude-code-hook-commit"
---

# Claude Codeにクソみたいなhookを書かせて、個人開発のバカデカいコミット問題をなんとかしている話

個人開発してると、気づいたらコミット1本にすべての変更が入っていることがあります。

「一応コミットしてる」という体裁は保たれているんですが、git logを見ると1000行以上変わっているとか、新しいコンポーネントを10〜20ファイル作ってからさらにその上にもう1コミット積む、みたいなことが普通に起きていて。嫌だなと思いながら続けています。

## なんでそうなるか

一人でやってるからです。これに尽きます。

チーム開発だとプルリクを出して誰かにレビューしてもらうから、ある程度の単位でコミットを切らざるを得ない。でも個人開発だとその強制力がなくて、「まあ今日中に終わらせよう」→「終わった！コミットするか」→「あれ変更量えぐいな」みたいな流れになります。

AIを使って開発していると特にこれが加速します。Claude Codeに「このページのレイアウト直して、あとついでにコンポーネントも整理して」みたいなことを頼んでいると、気づいたら十数ファイルが変わっていて、しかもそれが一続きの会話の中での出来事なので、どこで区切るかもよくわからない。

「まあ個人開発だから別にいいか」という気持ちもあります。でもなんか薄っすら罪悪感みたいなものがあって、ずっとモヤモヤしていました。

## 自分でコミット書くか、と言われたら書かない

根本的な問題として、コミットを書くのがめんどくさい、というのがあります。

コードを書いているときの集中が切れるタイミングでコミットするのが理想なのはわかっているんですが、実際に手が止まっているときって「よし次何しよう」という気持ちになっていて、コミットに使う数十秒がもったいなく感じる。結果として後回しになり続けて、最終的にバカでかいコミットになる。

自分がそういう人間だということはもうわかっているので、「仕組みで解決しよう」という方向に考えが向きました。

## 仕組みは2段構えになっている

まず一段目として、CLAUDE.md（Claude Codeに渡すプロジェクトの指示書）に「ファイル編集が完了した論理的な区切りでコミットすること」と書いています。こっちが本命で、Claudeが作業しながらちゃんとコミットメッセージも書いて、意味のある単位でコミットを切ってくれる、という想定です。

実際これがうまく機能しているときは、会話の中でちゃんと `feat: ○○を追加` みたいなコミットが積まれていきます。

ただ、ちゃんと機能しないときもあって。作業に集中しすぎてコミットし忘れたまま会話が終わる、みたいなことが起きる。そのフォールバックとして、stop hook（セッション終了時に実行されるhook）を仕込んでいます。

`.claude/settings.json` にこういう感じで書きます。

```json
{
  "hooks": {
    "Stop": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "git add -A && git diff --cached --quiet || git commit -m \"checkpoint: $(date '+%Y-%m-%d %H:%M')\"",
          }
        ]
      }
    ]
  }
}
```

これで、セッションが終わるときにまだコミットされていない変更があれば「checkpoint: 2026-05-16 23:41」みたいなメッセージで自動コミットされます。何をしたかは書かれていないのでドキュメントとしては最低ですが、変更が失われないという状態にはなる。

pushは自分でやります。「git push」だけは手動でいい。自動pushは怖い。

## 全然解決していないことも認識している

これで何が解決したかというと、「過去のある時点の状態に戻れる」という最低限のことだけです。

コミットメッセージには何の情報もないし、変更の単位はセッション単位なので相変わらず大きい。チーム開発でこれをやったら間違いなく怒られます。というか怒られる前にPR出せないと思う。

ただ個人開発で今一番困っていたのが「戻れなくなること」だったので、それが解決されただけで十分とも思っています。「ちゃんとしたコミット運用」をしたいわけじゃなくて、「なんもなくてやばくなること」を防ぎたかっただけなので。

今いる会社でもGitHub自体を導入したのがここ最近という状態で、以前はFTPで直接サーバーにファイルを上げていたらしいので、比較対象がゆるい環境にいるというのも正直あります。

## ちゃんとやりたい気持ちはある

OSSを作るとか、ちゃんとチームで開発するとかいう状況になったら、さすがにこんなやり方はしないと思います。というか多分できない。

ただそれまでの間、個人開発のコード管理として「最悪消えなければOK」という基準でやっていくのは、正直まあいいかなと思っています。チーム開発の作法は実際にチームで開発するときに覚えればいいし、今は「とにかく作る」に集中したい。

hooksという仕組みがあることを知って、「これ使えばええやん」と思って実装してみたら実際に動いて、それだけで十分でした。全体的にクソみたいな解決策だという自覚はありますが、機能しているのでまあいいです。