増え続けるGitHubリポジトリは「削除」ではなく段階的なArchive運用で整理する

開発会社の GitHub Organization は、案件や検証のたびにリポジトリが増え、数年経つと「どれが生きているのか分からない」状態になりがちです。社内で運用している整理基準を紹介します。ポイントは、削除ではなく Archive（凍結）を使い、判断を段階に分けることです。

設計の考え方

• 運用中のリポジトリにはステータスを付けない。 ラベルの網羅的なメンテナンスは続かないため、「止めてよいか検討する対象」にだけ印を付ける。ステータスなし = 運用中がデフォルト
• 凍結 = GitHub の Archive。 コード・履歴・参照をすべて保持したまま変更だけを防ぐ安全な停止状態であり、削除ではない。復元も1操作でできる

月次フロー

1. 月1回、GitHub API の pushed_at を基準に 24ヶ月以上更新のないリポジトリを機械的に抽出する
2. 該当リポジトリに status:archived_candidate ラベルを付与し、一覧を社内共有する
3. ヒアリング期間（原則1ヶ月）で、現在の利用状況と保持の必要性を確認する
4. 1ヶ月後に再チェックし、保持が必要ならラベルを外して運用中に戻す。異議がなければ Archive を実施する

Archive の最終判断は必ず人手で行います。自動化するのは「候補の抽出」までです。

例外と原則

• 法的・契約上の理由で保持が必要なもの、参照専用として残すもの、再利用が明確に決まっているものは最終更新日によらず対象外にできる（理由を明記）
• 判断に迷う場合は候補ラベルのまま保留してよい。**「迷ったら Archive しない」**が原則

機械的な抽出基準（24ヶ月・pushed_at）と人間の判断（ヒアリング・最終決定）を分離することで、月次の運用コストを最小限に保ちながら、Organization を常に把握可能な状態に維持できます。