個人開発でプロジェクトを凍結したのに自動化が動き続けた話 — GitHub Actions cron と Slack 通知を止め忘れる盲点

結論：プロジェクト凍結時に必ず確認する3点

# 1. そのプロジェクト名で .github/workflows を grep する
grep -r "indie-db\|indiedb\|recipe-ai" .github/workflows/

# 2. scheduled-tasks/ を確認する
ls scheduled-tasks/ | grep -i "{frozen-project-name}"

# 3. MEMORY.md / CLAUDE.md の凍結リストと突合する
grep "IndieDB\|recipe-ai" MEMORY.md

戦略ドキュメントに「凍結」と書いたとき、コードは止まります。自動化は止まりません。

---

凍結したのに Slack 通知が届く

2026年5月上旬、Slack の #automation-logs チャンネルに見覚えのある通知が届きました。

✅ IndieDB Collector: 23件取得 (2026-05-07 13:02 JST)

IndieDB は4月20日に凍結を決定したプロジェクトです。STRATEGY.md にも MEMORY.md にも「凍結」と書きました。それなのに、5月7日時点でも週2回（月・木 13:00 JST）の cron が動き続けていました。

recipe-ai も同じです。4月29日に凍結を決定したはずが、extract-health-check が毎日08:00 JSTに走り、5月8日まで成功し続けていました。

凍結から最長で約3週間、無駄なリソース消費と Slack ノイズが継続していたことになります。

---

なぜ止め忘れるのか：戦略レイヤーと自動化レイヤーの分離

凍結判断は「戦略レイヤー」で行います。

• STRATEGY.md を更新する
• MEMORY.md に凍結を記録する
• 今後そのプロジェクトに着手しないことを決める

この作業はドキュメントの更新で完結します。問題は、付随する自動化レイヤーには何も伝わらないことです。

GitHub Actions の cron は .github/workflows/ 内の YAML ファイルが存在し、リポジトリに直近60日以内のアクティビティがある限り動き続けます。Slack 通知ルーティング、scheduled-tasks/ の SQL バッチ、SKILL.md に記載した daily-operator の実行条件——これらはすべて「コードが残っているかどうか」で動作を決定します。

戦略レイヤー  : STRATEGY.md → 凍結 ✅
自動化レイヤー: .github/workflows/*.yml → 動作中 ⚠️

この2つのレイヤーを橋渡しするチェックリストがなかったことが根本原因です。

---

実際に何が起きていたか（2026年5月 実録）

IndieDB Collector

• 凍結決定: 2026-04-20
• 最終実行確認: 2026-05-07（凍結から17日後）
• 内容: 商工会議所・connpass のイベントを週2回収集し、DB に insert + Slack 通知
• 影響: 無関係なイベントデータが DB に蓄積。Slack の #automation-logs にノイズ通知が届き続けた

recipe-ai extract-health-check

• 凍結決定: 2026-04-29
• 最終実行確認: 2026-05-08（凍結から9日後）
• 内容: 毎日08:00 JST にレシピ抽出の健全性チェックを実行
• 影響: 実際にはほぼ何も起きないが、GitHub Actions の実行ログが蓄積され、失敗時にアラートが飛ぶ設計だったため潜在的な誤検知リスクがあった

2件合計で、約2〜3週間のノイズが継続しました。

---

再発防止：凍結チェックリスト（3ステップ）

凍結判断をしたその場で、以下の3点を必ず確認するようにしました。

ステップ1：.github/workflows/ を grep する

# プロジェクト名のバリエーションすべてで検索
grep -r "indie-db\|indiedb" .github/workflows/
grep -r "recipe-ai\|recipe_ai" .github/workflows/

ヒットしたファイルを開き、on: schedule: のブロックを確認します。cron: が書かれていれば、ワークフローを workflow_dispatch のみに変更するか、ファイルごと削除します。

ステップ2：scheduled-tasks/ や daily-operator を確認する

モノレポで daily-operator のような定期実行スクリプトを運用している場合、そこに凍結プロジェクトのタスクが残っていないかを確認します。

# scheduled-tasks/ に凍結プロジェクト名が残っていないか
ls scheduled-tasks/
grep -r "IndieDB\|recipe-ai" scheduled-tasks/

SKILL.md に記載された「毎日実行するスキル」リストも同様に確認対象です。

ステップ3：MEMORY.md / CLAUDE.md の凍結リストと突合する

凍結リストを一覧として持っておき、.github/workflows/ のワークフロー名と突合するとモレを検出しやすくなります。

## 凍結プロジェクト一覧（MEMORY.md より）
- IndieDB: 凍結 2026-04-20 → workflow停止確認 2026-05-09 ✅
- recipe-ai: 凍結 2026-04-29 → workflow停止確認 2026-05-09 ✅

この「確認済み」チェックを MEMORY.md に残すことで、次回の月次監査でも追いかけられます。

---

月次メンテナンス監査の習慣化

凍結チェックリストは「凍結するとき」だけでなく、月1回の定期監査でも有効です。

# 実行中のワークフローを一覧取得
gh workflow list --all

# 直近30日で一度も実行されていないワークフロー
gh run list --limit 100 --json workflowName,createdAt \
  | jq 'group_by(.workflowName) | .[] | {name: .[0].workflowName, last_run: (.[0].createdAt)}'

このスクリプトで「動いているけど誰も見ていない」ワークフローを可視化できます。GitHub Actions には 60日間アクティビティがないリポジトリのスケジュールを自動停止する仕組みがありますが（出典：GitHub Actions is 60-day inactivity policy）、個人のモノレポではメインのコミットが頻繁にあるため、この自動停止が機能しないケースがあります。

---

で、どう稼ぐ？

「凍結プロジェクトの自動化クリーンアップ」は、それ単体では収益にならないように見えますが、「メンテナンス監査の習慣」を売るという文脈に乗せると話が変わります。

方向1：監査スクリプトを有料コンテンツにする

上記の gh workflow list + gh run list のコンポジット、凍結チェックリスト付きの MEMORY.md テンプレート、月次監査プロンプトをまとめた記事を有料記事（¥XXX）として出版できます。

方向2：「個人開発のモノレポ管理術」シリーズのひとつにする

• STRATEGY.md の設計
• 自動化レイヤーの整理（本記事）
• MEMORY.md と SKILL.md の使い分け
• 凍結〜再開のプロトコル

このシリーズとして記事を積み上げると、モノレポ管理に困っている個人開発者のメーリングリスト（Lab Free）への入り口になります。

方向3：Build in Public ネタとして使う

「凍結したのに自動化が3週間動いていた」という失敗談は、X（旧Twitter）での共感度が高いテーマです。失敗→発見→修正→チェックリスト化 のストーリーとして発信すると、「それ俺もある」という反応を得やすく、フォロワー獲得や Lab Free 登録への導線になります。

---

まとめ：今日やること3つ

1. 凍結済みプロジェクト名で .github/workflows/ を grep する — ヒットしたら cron の停止または削除を行う
2. 月次メンテナンス監査の予定を立てる — gh workflow list --all で実行中ワークフローを一覧取得し、凍結リストと突合する習慣をつける
3. 凍結判断と同時に自動化停止チェックリストを実行する — MEMORY.md に「凍結 + workflow停止確認済み ✅」を残す

戦略レイヤーで止めた気になっていても、自動化レイヤーは走り続けます。次の凍結判断のときは、コードと自動化を一緒に止めてください。

---