git logが作業ログになる：Claude Codeにコミットを書かせるだけ

1 「先週なにやってたっけ」を、git log に書いてある状態にしておく
2 なぜコミットログが「作業ログ」になるのか
3 何に効くか
4 Claude Code のログ分析でも、同じことはできるけど
5 おわりに

「先週なにやってたっけ」を、git log に書いてある状態にしておく

ども！Claude Code と毎日仕事している龍ちゃんです。

月曜にやったこと、金曜には忘れてるんですよね。タスクが増えてくると「追い切れる気がしない」になって、ちゃんとやろうと思っても結局やらない、みたいな。

そういう人に向けた話なんですが、前提を先に言っておきますね。2つあって。

全業務（ブログも調査もツール開発もセミナー資料も）を1つのリポジトリに突っ込んでいる
それは個人の進捗管理リポジトリで、作業者は自分1人

この2つが揃ってるから、git log が自分の活動ログになるんですよね。土台の「全業務を1つのリポジトリに集約してる」話自体は「Claude Codeで全業務を1リポジトリに一元管理する作業基盤の作り方」で書いていて、そこで「git の履歴がそのままタスクの棚卸しになる」と予告してたんですが、今日はその中身の話です。

2026-06-02 Claude Codeで全業務を1リポジトリに一元管理する作業基盤の作り方

やってることは特別なことは何もなくて。Claude Code に書かせたコミットメッセージと時刻を git log でちらっと眺めるだけ。マジで小さい Tips なんですが、地味に効いてるのでおすそわけします。

この記事の全体像は、こんな感じです。

なぜコミットログが「作業ログ」になるのか

じゃあなんで、ただの git log が作業ログとして読めるのか。理由は2つです。

1つめは、コミットメッセージを Claude Code に書かせてること。差分を読んで「何を・なぜ変えたか」を要約してくれるので、書き方が安定するんですよね。自分で手打ちしてると、つい fix とか wip みたいな雑なログになりがちなんですが（笑）、Claude に書かせると一文できちんと残る。だから後から読み返しても意味がわかります。「”wip” じゃ後から誰も分からないけど、AIに書かせたら実際に役立つ履歴になった」って言ってる人もいて（freek.dev）、これめちゃくちゃ分かるんですよね。

もう1つが、これが今日のポイントになるんですが。理想を言えば、タスクを「終わる分量」で切ることなんですよね。1個終わるごとにコミットが1つ落ちる＝コミットが「完了の単位」になる。結果、git log が「終わらせたことが時系列に並んだ列」になる。いわゆる atomic commits ってやつですね。「コミット履歴はコードがどうしてこうなったかを語る”物語”だ」って言ってる人もいて（Telling stories through your commits）、まさにそれを作業ログとして読んでる感覚です。

でも現実は、当日朝にいきなり降ってくるタスクもあるし、月末締めのやつと今週中のやつが混在してたりして。粒度をそろえて設計する、できてるか？というと、まあ僕もできてないです（笑）。

そこで Claude Code にコミットを書かせると、差分を読んでファイル単位で適切な粒度に分けてくれるんですよね。僕がよくやるのは、ダーッと一日走り切って、コミットの分割は後から AI に丸投げするやつ。設計しきれてなくても、それで足りてます。

だから個人で運用する分には、「自分しか見ない＝コミット粒度のルールが本来ない世界」でも、git log がそのまま活動ログになるんですよね。ちなみにこれ、リポジトリを分けてたら履歴も割れて1本で見渡せないんですが、全部1リポジトリだから成立してます。

長めのタスクのときは、いったん途中でコミットを切っておいて、翌日 git log で「どこまでやってたか」を確認してから戻る、という使い方もしてます。

実際、時刻付きで眺めるとこんな感じで並びます。

$ git log --pretty=format:"%cd %s" --date=format:"%m/%d %H:%M"
05/31 23:09 docs(article): 連載のブログ記事と計画を追加
05/31 23:09 docs(research): /copyの調査結果を追加
05/31 16:44 docs(slides): 月次LTのスライドを改稿
05/29 14:32 feat(tool): サムネ生成のオプションを追加
05/29 10:10 docs(seminar): OSCの企画ドキュメントを追加

「いつ・どの領域で・何を終わらせたか」が、ただの履歴なのにちゃんと読める。

何に効くか

いちばん多いのはタスクの復帰ですね。中断してたタスクに戻ってきたとき、直前のコミットを見れば「あ、ここまでやって、次これやろうとしてたわ」が一発で思い出せる。長いチャット履歴を遡らなくていいんですよね。

週次・月次の振り返りにも効きます。git log --since="1 week ago" --author="$(git config user.name)"（月次なら --since="1 month ago"）みたいに期間と自分を絞れば、「この期間やったこと」がそのままリストで出てくる。週報や月次レポートを書くときはもちろん、出した報告を「先月ほんとにこれやってたっけ」と裏取り確認するときにも、ゼロから思い出す作業がなくなって、素材がほぼそこにある状態になります。

あとは地味に、自分の稼働の把握。どの領域にどれだけコミットしてたかを見てると、実際に手を動かして終わらせた量がうっすら見えてくるんですよね。終わる分量で切ってるぶん、コミットの分布が「実際に終わらせた仕事」にわりと近いです。正確な稼働率みたいな数字じゃないですけど、「今週は調査に寄ってたな」「ツール開発、全然進んでないな」くらいの肌感は掴めます。しかもこれ、上司に報告するためじゃなくて自分のためなので、相手が自分のデータな分、忖度ゼロで「先週サボってたな〜」と向き合えるのがいいところです（笑）。

もう1つ意識してるのが、「git に乗らない仕事は、乗せにいく」というやつです。会議とかチャットって、ふつうはリポジトリに残らないじゃないですか。なので僕は、Google Meet の文字起こしはファイルを作ってリポジトリにコミットしてますし、Slack でのレビューも「何を投げて、それに対してどう返ってきたか」をファイルとして保存してます。

もちろん社外秘や他メンバーの発言が混ざるものは入れない、と人間が判断したうえで、ですが

手作業にはなるんですが、「なぜこうなったか」の意思決定の過程って、後から見返したときに価値があるので。作業の進捗はひとつのリポジトリで一元管理しようっていう意識です。まあ、乗せ忘れたものは映らないんですけどね（笑）。

Claude Code のログ分析でも、同じことはできるけど

正直に言うと、同じような振り返りは Claude Code 側のデータでもできます。claude --resume を叩けば過去セッションの一覧が出て、各セッションのサマリーや最終更新時刻、git ブランチが並ぶので、「このへんで何やってたか」をたどれます。もっとガッツリやるなら、会話ログ（セッションの全文）を分析にかける手もあります。

でも、見る量が多いんですよね。 会話ログは1セッションで数百行いくし、セッション一覧のサマリーも粒度がまちまちです（セッションに自動でタイトルが付くのは Plan を承認したときなどで、名前を付けてないセッションは最初のプロンプトがそのまま表示されたりする）。ぱっと「何やってたっけ」を解消したいだけなら、ちょっと情報が多い。

その点 git log は「メッセージ＋時刻」だけ。見る情報が少ないぶん、さっと振り返るには圧倒的に軽いんです。正直、git log が楽すぎてセッション一覧をわざわざ開く気にならないんですよね（笑）。

逆に、Claude Code のログ分析が向いてるのは、セッションをまたいで「どういう経緯でこの判断に至ったか」とか「自分のクセ・口癖」みたいな、もっと踏み込んだ詳細分析のほうですね。軽く棚卸ししたいだけなら git log、腰を据えて深掘りしたいなら会話ログ、という住み分けです。そっちのガッツリ系をやりたくなったら、また別記事で紹介しますね。