「先週なにやってたっけ」を、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、腰を据えて深掘りしたいなら会話ログ、という住み分けです。そっちのガッツリ系をやりたくなったら、また別記事で紹介しますね。 おわりに タスク管理ツールを新しく増やさなくても、コミットメッセージを Claude Code に書かせてるなら、 git log はもう作業ログとして読めます。まずは自分の git log を時刻付きで眺めてみるところから。「あ、先週これやってたわ」が見えてくると、地味に面白いですよ。 ほなまた〜 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post git logが作業ログになる：Claude Codeにコミットを書かせるだけ first appeared on SIOS Tech Lab .

仕事の素材が散らばっていると、AIは手伝いきれない ども！Claude Code と毎日仕事している龍ちゃんです。 調査メモはNotion、コードはGit、ブログの下書きはGoogle Docs、スライドはまた別のツール……仕事の素材って、気づくとあちこちに散らばってませんか。 地味につらいのが「 AIに手伝ってもらいにくい 」こと。せっかく Claude Code を使っていても、調査メモが別の場所にあると「先月の調査をもとに、このコードのことを記事にして」が一発で通らない。毎回こっちが文脈を運ぶ羽目になります。 で、たどり着いた答えはすごくシンプルで。 日常のどんなタスクも、1つのリポジトリの中で進める 。調査も検証も実装もブログも、全部そこでやる。それだけです。 これをやると、いいことが2つあって。1つは、Claude Code が全部読んで横断して手伝ってくれること。もう1つが やった作業が消えずに積み上がる ことなんですよね。ここで言う”積み上がる”は、一度やった調査や検証が、後の別のタスクから参照されて使い回せる状態のことです。バラバラのツールでやると、終わったタスクはそのまま埋もれて消える（うっすらとした記憶で探すのも大変）。でもリポジトリの中で進めれば、調査も検証も全部残って、次の仕事の土台になる。点だった作業が、線でつながっていく感覚です。 この記事では、その「全部1リポジトリ」をどう組んで、どういう連鎖が起きて、どこから始めればいいかを順に話します。 全業務を1つのリポジトリに集約している まず、どんなエンジニアにも共通する話をします。コードを書く人なら、調査も検証も実装も同じリポジトリに置くだけで、「なんでこの設計にしたんだっけ」と悩む時間が減ります。コードの隣に検証メモが残っているし、「あの調査どこだっけ」と探し回らなくていい。仕事の種類は関係ないんですよね。 僕の場合は、さらに発信活動も業務の一部に入っているので、ブログやセミナーも同じ場所に置いています。会社としてテックブログとYouTubeチャンネルを運営していて、情報発信も仕事のうちになっているんですよね。だから開発・調査・発信が全部同じ業務として同じ場所にある、というのが実情です。 ディレクトリがそのまま業務の地図になっていて、こんな感じです。 リポジトリ/ ├── docs/ │ ├── research/ # 調査・リサーチ │ ├── experiment/ # 検証・実験 │ ├── article/ # ブログ記事の下書き │ ├── seminar/ # セミナー企画・登壇資料 │ └── data/ # 業務まわりのデータ置き場 │ ├── blog/ # 公開ブログのスクレイピング │ ├── pv/ # 月次PVデータ │ ├── x-post/ # X（旧Twitter）投稿 │ ├── youtube/ # YouTube用の原稿 │ └── … # チラシ・登壇資料なども └── application/ # 開発・ツール実装 git に乗らない仕事は、乗せにいく コードやドキュメントみたいに自然と git に残るものだけじゃなくて、放っておくと残らない仕事もあえてここに入れています。たとえば会議（Google Meet）の文字起こしや、Slack でもらったレビューのやり取り。ふつうはリポジトリの外で流れて消えていくものなんですが、ファイルにして置いておくと「なんでこう決めたんだっけ」の経緯まで同じ場所にそろうんですよね。手作業にはなるんですけど、後からじわじわ効いてきます。 会議録や Slack のやり取りには、社外秘や他のメンバーの発言（＝第三者の個人情報）が混ざりがちです。リポジトリを公開・共有・画面共有する場面で一緒に漏れる導線になるので、そういうものは別管理にするか .gitignore に入れる、保存自体も所属組織のポリシーに沿う、を前提にしてください。 ここで大事にしているのは、 何をリポジトリに入れるか（＝AIに読ませるか）は人間が判断している ということです。デリケートな情報は、そもそもリポジトリに置かない＝AIにも渡さない。AIに自動で何でも食わせるのではなく、「これは入れてよい素材か」を人の目で一段かませる。僕も「出していい素材」と「社外秘」は置き場を分けていて、後者はそもそもこの仕組みに乗せません。 整理されていること自体が目的じゃないんですよね。「ここに全部ある」という状態が、後の仕事の進めやすさを変えます。次のセクションで具体的に話しますね。 点と点が、線でつながった 「全部1つのリポジトリに入れた」結果、一番大きく変わったのは「知識の使われ方」ですね。 以前は、調査した内容は調査ノートの中で完結していました。記事を書くときは記事フォルダだけ見て、コードを書くときはコードだけ触って、という感じで。それぞれの仕事は「点」として存在していたんですよね。 それが1つのリポジトリに集まると、調査→検証→実装→発信という流れが、ファイルのパスをたどるだけで全部追えるようになりました。 docs/research/ での調査が起点になって、そこから docs/experiment/ での検証に進み、検証結果は2方向に分岐します。エンジニアとしての成果は application/ の実装へ、発信としての成果は docs/article/ のブログ記事やセミナー資料へ。さらにブログが公開されると、PV分析の結果を見て次の調査テーマが決まっていく。こうして、バラバラだった点が線でつながって、ぐるっと循環するようになります。 この「つながり」こそが、僕がやりたかったことの正体だと思っているんです。点のままだと、作業が終わった瞬間に埋もれていく。でも線でつながっていれば、どこかの作業が後の作業の土台になる。調査メモが記事を変え、記事のPVが次の調査を決め、検証の経緯が実装の判断根拠になる。やった仕事が消えずに積み上がっていく、という感覚です。 線でつながっている実例 コードの前に、検証の計画をドキュメントで残す 検証や実験をするとき、僕はいきなりコードから書き始めないんですよね。先に「何を確かめたいのか」「どういう手順でやるのか」「どんな仮説を置くのか」をドキュメントに書いて、整理してから実装に入ります。いわゆるドキュメント駆動ですね。 たとえば最近やった MCP サーバーの検証だと、「返ってくるデータ量やツール定義の書き方が、LLM のトークン消費にどう効くか」という仮説と検証シナリオを先にドキュメントで組み立てて、それから実際に動かすコードを書きました。計画のドキュメントと、それを動かすコードが、同じリポジトリに並んで残ります。 これの何がいいかというと、後から「なんでこの設計にしたんだっけ」となったとき、計画の方を見れば、どんな仮説を立てて、測ってみてどうで、だからこうした、という経緯が全部たどれるんですよね。判断の理由が実装の隣に残っている状態です。お恥ずかしい話、以前はこういう計画や経緯メモは別のドキュメントツールに書いて、そのうち参照されなくなる流れだったので。リポジトリで完結させると「消えない判断根拠」として残り続ける。後で設計を見直すとき、隣のドキュメントを開けば理由がそのまま残っている状態です。 さらに、検証して出た結果（レポート）も同じ場所に書き残しておくと、もっと変わります。 計画 → 実装 → 検証結果 までが1か所にそろうので、その結果をそのままブログやセミナーのネタに使うところまで、一本の線で通るんですよね。「検証したけど、結果どこ行ったっけ」と一回一回情報を探す手間がなくなって、やった検証がそのまま発信の素材になります。 PVの傾向から次のネタが決まる 「隣のネタを拾う」という感覚に近いんですが。Agent Skills まわりの記事が伸びていたので、じゃあ隣のトピックである Issue 操作のネタを調査して記事にしよう、という判断をしたことがありました。PV分析→調査→記事化という一連の流れが、同じリポジトリで完結したんですよね。分析結果のメモと記事のドラフトが同じ場所にあると、「この流れで次は何をすべきか」をAIと一緒に考えやすいし、読んだ分析が次の調査へ自然につながっていく。過去のデータが次の仕事の起点になる、というのが一番わかりやすい実例だと思います。 PVのみを意識してブログを出しているわけではありませんが、データも身近にあることで投稿ブログの分析などがブログ執筆のプロセスに入ってきて、執筆活動の質に少しだけマーケティング的視点を入れることができるようになってきました。 この記事自身が一番の実例 こちらのブログでもデータを集約したことでの恩恵にふんだんにあやかっています。 Karpathy の LLM Wiki や みのるんさんの「Claude Codeですべての日常業務を爆速化しよう」 がモノレポや知識集約まわりで同じ方向のことを書いているのを調査ノートで確認していたので、「集約しようというだけじゃなく、集約すると連鎖が起きるという方向で書こう」と記事の角度を変えられました。巨人たちが同じことを言っているのは、独自の発見というよりむしろ裏付けですね。あくまで参考にさせてもらっている立場です。それでも、調査メモが記事の角度を変えたというのは、先行事例の調べものがそのまま次の判断材料になった一例です。（ちなみに先人たちは巨人って表現をしてきたのはAIですww） なお、検証から記事化するフローの詳細は「 検証→記事化で知見を資産化する 」でまとめています。”知見を資産化”という考え方はこの記事が先行しているので、合わせてどうぞ。スライドも application/slides に置いているので、記事の内容をそのまま流用してセミナー資料も作れます。 過去記事を下敷きにして情報補完する ブログを書いていると「この話、前に別の記事で書いたな。リンク貼っておこう」という場面がよくあります。でも、過去記事を探して、URLを確認して、リンクを貼って……というのを毎回手作業でやるの、地味につらいんですよね。過去記事も同じリポジトリにあれば、Claude が「その話はこの記事で書いてますよ」と拾って、リンク候補まで出してくれる。手で探していたリンク貼りが要らなくなります。 もう一つ、これも小さいけど助かるのが、企画の重複を防げることです。「これ書こう」と思って調べ始めたら、実は企画レベルで前に着手していた、みたいなことがたまにあるんですよね。過去の記事も企画メモも全部同じ場所にあると、書き始める前に「似たやつ、もうありますよ」とAIが気づいてくれる。書き上げてから「これ前にやってたやつだ」と気づく事故が減ります。 どちらも、過去の仕事が文脈ごと同じ場所に残っているから成り立つ話で。別のツールに書き散らしていたら、そもそも探し出せなかったと思います。 始め方は1本のファイルから 一気に全業務を移す必要はないんですよね。おすすめは「まずリポジトリを1つ作る」こと。それだけです。 次に、 docs/research/ みたいなディレクトリを切って、 /research で調査させた結果か、手元の調査メモを1本だけ置く。その1本を起点に、記事やコードから参照が伸びていきます。最初から整えようとしなくていいんですよね。「置き場を1つ決めて1本置く → そこから参照が伸びる」という流れが最小の始め方で、リポジトリに仕事が溜まるほど、使い回せるものが増えていきます。 調査の品質を上げる /research の使い方は「 Claude Codeの調査品質を /research で上げる 」と「 調査→構造化→注入 」で紹介しているので、調査の置き場から始めたい方はそちらもどうぞ。 使ってみての感想 使い始めて一番変わったのは「終わった仕事が消えずに残っていく」感覚ですね。以前は、調査やメモは「その仕事のためだけのもの」で、終わったら参照されなくなっていくことが多かったんです。でも全部1つのリポジトリに入れると、終わった仕事が次の仕事の土台になっていく。同じ時間をかけた作業が、使い捨てじゃなくて積み上がっていく感じがあります。 Second Brain 的な考え方とも近いんですが、ちょっと違うのは、僕にとっての「外部記憶」はむしろブログの方なんですよね（笑）。一度書いて公開した話は、もう頭で覚えておかなくても「あの記事に書いてある」で済む。リポジトリはその手前にある、書く前の素材が全部そろっている場所、というイメージです。自分が思い出せなくても Claude が横断して引き出してくれるので、記憶の代替というよりは仕事の土台になっている感覚ですね。「積み上がる」というのが、いちばんしっくりくる言葉です。 あと、進捗管理やタスク管理も同じリポジトリで回しているんですが、git の履歴がそのままタスクの棚卸しになる、という話は少し長くなるので次の記事に書こうと思っています。近日公開予定です。 今回関連する記事はこちらです。 調査品質・ /research の使い方 調査→構造化→AIへの注入 検証→記事化で知見を資産化 製品モノレポとの違い（CLAUDE.md活用） 履歴でタスクを棚卸しする（次記事・近日公開予定） ほなまた〜 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Claude Codeで全業務を1リポジトリに一元管理する作業基盤の作り方 first appeared on SIOS Tech Lab .

はじめに サーバーワークスの池田です。 今週（5/24〜5/30）の Claude Code は v2.1.152 から v2.1.158 まで6バージョンがリリースされました（v2.1.151 と v2.1.155 は npm に公開されていない欠番です）。 期間中には Claude Opus 4.8 と dynamic workflows という大型のリリースもありました。これらは別記事で詳しく扱っているため、本記事では CLI 本体とプラグイン周りの実務的な変更を中心にまとめます。 なかでも注目は、コードの脆弱性をその場で検知・修正する security-guidance プラグインと、…