1. はじめたきっかけ
Claude（デスクトップ版）でチャットするだけ。VS Codeもほとんど開いたことがなかった。
そんな自分が4か月前にたまたま見つけた1本の動画。
外資ITエンジニアが実践する GitHubで人生を管理する方法
その動画を見て、日々の思いつきや、やりたいことをGitHub Issueに残していく使い方に興味を持った。
気になることは日々たくさんある。
「読みたい記事」「見たい動画」「買いたいもの」「試したいツール」
スマホのメモ、写真、ブックマーク…いろいろ試したけれど、
結局見返さないまま忘れ、そのうち残すこと自体もしなくなっていた。
だからこそ、思いついたことをIssueとして残すという考え方に興味をもった。
この記事では、GitHub Actionsの具体的なコードやClaude Codeの細かい設定手順ではなく、4か月使ってみて自分の行動がどう変わったか、どこでつまずいたかを中心に書く。
2. GitHubで人生を管理するって何？
やっていることはシンプル。
日々の思いつき・行動・学びを、できるだけGitHub Issueに残し、終わったらかんばん上でCloseしていく。
しかも、これを全てClaude Codeから実行していることで、よりハードルを下げている。
Issueを綺麗に作成しなくてもいい。
Claude Codeから以下のような指示をする
- xxxという本を買う
- wifiルーター買い替え検討
- 歯医者を予約する
3. 学びの「あとで」を、ぜんぶIssueに放り込む
最初に効いたのは学びのインプットだった。
気になる記事もUdemyの講座も生成AIに関する動画も、「あとで読もう」「あとで見よう」
Claude Codeに伝えて片っ端からIssueにする。
- この記事あとで読む
- Gitの講座を最後までやる
- AWS CDKのコンストラクトを理解する
- 動画のURLそのまま貼り付けてあとで見る
これでタイトル、締切、ラベルのついたIssueになる。読み終わったらCloseに動かすだけ。たまったIssueをかんばんで眺めると、いま何を学びたいのかが見えてくる。
ただ、何度もやるうちに気づいた。毎回同じことを頼んでいる。
タイトルつけて、締切拾って、ラベル振って、Issueにして
これ、もっとラクにできないか。同じ指示を何度も打つたびに、そう思うようになった。
4. 見よう見真似で「skill」にたどり着いた
「毎回同じことを頼んでいる」問題。
これを解決してくれたのがskillだった。一度教えた手順に名前をつけて、ひとことで呼び出せるようにする仕組みだ。
- これまで → 「タイトルつけて、締切拾って、ラベル振って、Issueにして」
- skill 化 → 「いつものやつ」のひとことで完結
最初は、こんな機能があることすら知らず、仕組みを深く理解していたわけでもない。
自分の場合は、動画を見て人のやり方を真似て、動かしては直す。その見よう見真似で、自分用の skill を少しずつ作れるようになった。
もちろん最初から完璧にはいかない。ただ、自分の場合はClaude Codeに「この作業をスキル化して」と頼むところから始められた。
5. 走ったら、ひとことで完結する（marathon-log）
ここからは、実際に一番定着した例として、ランニング記録のskillを紹介する。
最初に育てた skill が、ランニングの記録（marathon-log） だった。走るたびに距離・ペース・心拍・感想を記録するのは面倒で、放っておくと続かない。
今は走ったあと、これを打つだけ。
走った
あとはskillが全部やってくれる。
ランニングに関する知識が薄い自分にとっては、走るたびに知識豊富なコーチが横についてアドバイスしてくれているような感覚に近い。
6. 毎朝、勝手に動いてくれる
skill が「呼べば動く」ものなら、こっちは 「呼ばなくても動く」 ものだ。毎朝、自分が何もしなくても、必要な情報が Slack に届く。一気通貫する処理を試したかった。
① 朝のブリーフィング
カレンダーの予定と、締切が近い Issue を横断して、「今日やること」を1通にまとめてくれる。
＜朝Slackに届く実際の画面＞
② 体調レポート
スマートウォッチの睡眠・体調データを、ただの数字ではなく評価に翻訳して届けてくれる。
＜朝Slackに届く実際の画面＞
7. 4か月を数字で振り返る
ここまで紹介してきた取り組みが、4か月でどれくらい積み上がったのかを数字で振り返ってみる。
| 指標 | 数字 | 見えてきたこと |
|---|---|---|
| Issue | 326件 | 思いつきや行動がログとして残るようになった |
| Closed Issue | 283件（Close率 87%） | 作るだけでなく、実際に消化できていた |
| コミット | 285件 | 小さな改善を継続していた |
| skill | 17本 | 定型作業をひとことで動かせるようになった |
| 自動化 | GitHub Actions 6本 + Claudeスケジュール 2系統 | 朝・週次の習慣に組み込まれていた |
月別のIssue作成数を見ると、最初の2か月は試行錯誤が中心だった。
4月に自動化へ着手し、5月に一度ピークを迎えた。
最初はとにかく何でもIssueにしていた。
続けるうちに、残しておくと後で役に立つものが少しずつ分かってきた。
数字にしてみると、GitHub Issueは単なるToDoではなく、自分用の行動ログ基盤になっていたことが分かった。
月別のIssue作成数には、そのまま熱量が出ていた。
2月 ████████████████████ 68件 始めた月
3月 ██████████████ 49件
4月 ████████████████████ 67件 自動化に着手
5月 ████████████████████████████████ 109件 ピーク
6月 █████████ 33件（10日時点）
8. ぶつかった壁
ここまで読むと順調そうだけど、実際は作り直してばかりだった。
特に難しかったのは、skillや自動化が増えたあとだった。
学習用、ランニング用、朝の通知用と少しずつ増やしていくうちに、似た処理が重複したり、どのskillが何をしているのか分からなくなったりした。
たとえばランニング系の skillを何度も作り直すうちに、毎朝動いているはずの自動実行が壊れたこともある。
原因は、AIが便利すぎたことだった。
一度作ったskillに「ここも直して」「これも直して」と思いつくたびに修正を重ねてしまい、修正のたびに他のskillや自動化との整合性が崩れていく。AIに任せて、勢いで直す。いわゆるバイブコーディングで進めた結果、全体の整合性が取れなくなっていた。
転機は ハーネスエンジニアリングという考え方を知ったことだ。
「何を作らせるか」より、「全体の整合性を保つ仕組みを整える」 ことが先だと気づいた。
具体的には、skillに限らず、何かを作る・直す前に、Claude Code自身に次のチェックリストを出力させてから作業を始める、というルールを作った。
【作業開始前チェック】
今回の変更対象
影響を受ける既存処理
影響を受ける定期実行（GitHub Actions / Claudeスケジュール）
壊れる可能性がある箇所
実装後に実行する確認コマンド
ロールバック方法
このチェックをスキップして作業を始めることは禁止にしている。
skillを「ここ直して」と頼んだときも、まずこのチェックリストが出力されてから作業が始まる。地味だけど、これを徹底するようになってから「修正のたびに何かが壊れる」状態がかなり減った。
9. まとめ
最初のきっかけをくれた動画の作者の方には、本当に感謝している。
あの動画を見なければ、GitHub Issueをここまで日常で使うことはなかったと思う。
最初は「歯医者に行く」レベルの、ただのメモをIssueとして管理していた。それでも、思いついたことをその場でIssueにするだけで、スマホのメモやブックマークのように見返さず忘れていくものが減った。これだけでも、自分にとっては十分な変化だった。
それを続けるうちに、Claude Code、skill、自動化、ルールが少しずつ増えていった。結局それらは、「思いついたことをIssueにする」楽しさを守るための仕組みだった。
4か月続けてみてこれは単なるタスク管理ではなく、自分の行動を残し、振り返り、次の行動につなげるための仕組みになっている。
まだ4か月分のログでしかない。
それでも、1年続ければ、自分が何に興味を持ち、何を試し、どこでつまずき、どう変わってきたのかを振り返れるはずだ。
つまずいたらルールを直し、思いついたらIssueにする。
その積み重ねを、これからも地道に続けていきたい。