config-gc

Config GC — Claude Code設定のガベージコレクション

ランタイムガベージコレクションから着想を得ています。参照されなくなったオブジェクト、冗長なオブジェクト、期限切れのオブジェクト、または価値の低いオブジェクトを定期的にスキャンし、領域を再利用します。決定的な違いは、ここでは収集に人間の介在が必要であることです。自律的に削除してはいけません。

アクティベーションのタイミング

• ユーザーがClaude Code設定のクリーンアップ、監査、またはスリム化を依頼した場合
• スキルが多すぎる、フックがノイズが多い、セッション起動が遅いとユーザーが不満を述べた場合
• 月次/定期設定レビューが行われた場合
• 大規模なスキルパック（例：このリポジトリ）をインストールした後、既存設定との重複を調整するため

以下の場合はアクティベートしないでください：プロジェクトのソースコードのクリーンアップ（それはリファクタリングです）、チャット履歴の消去、Claude Code自体のアンインストール。

設計思想

1. 追記専用設定は漏れ出す。 スキル、メモリファイル、フック、権限エントリは追加される一方です。定期的なレビューなしに静かに腐っていきます。
2. 1回限りのパージよりも定期的な監査の方が効果的。 約30日ごとにスキャンし、毎回少数の候補を提案します。
3. チャネルごとに戦略を変える。 蓄積タイプ（スキル、フック、権限など）ごとに独自の陳腐化シグナルがあります。すべてに同じルールを適用しないでください。
4. 最初はソフトデリート。 .disabled にリネーム → ~/.claude/_gc_trash/ に移動 → 実際の削除。常に元に戻す道を残してください。
5. 強制人間介在。 各候補に対して個別の [y/n/skip] 確認を行います。「すべてはい」のショートカットはありません。
6. ログを残す。 GCの実行ごとに ~/.claude/gc_log.md に追記します。何に触れたか、その理由、元に戻す方法を記録します。

スキャンチャネル

#	チャネル	パス	陳腐化 / 冗長性のシグナル
1	スキル	~/.claude/skills/*/	名前の重複がひどい；最近のトランスクリプトで一度もトリガーされていない；ユーザーの実際の作業とドメインが一致しない；SKILL.mdが壊れているか空
2	メモリ	~/.claude/**/memory/*.md + そのインデックス	1つのトピックに複数のインデックスエントリ；新しいエントリと矛盾する内容；日付が過ぎたもの；インデックスにない孤立ファイル；マージすべき100語未満の断片
3	フック	~/.claude/hooks/ + 設定	ディスク上に存在するが、どのフック設定からも参照されていないスクリプト；書き換えによって置き換えられた古いバージョン
4	権限	settings.json / settings.local.json の permissions.allow	重複エントリ；ワイルドカードで既にカバーされている特定のエントリ（例：Bash(*) が許可されているのに Bash(git push) がある）；過去の実験による一回限りの許可
5	MCPサーバー	~/.claude.json またはプロジェクトの .mcp.json	接続に失敗するサーバー；機能的に重複しているもの；長期間未使用
6	スケジュール済みリマインダー/ジョブ	ユーザーが保存している場所	30日以上経過した発火済みワンショット；対象スクリプトが存在しなくなったジョブ
7	プロジェクト履歴	~/.claude/projects/*/	古いハンドオフスナップショット；新しい状態に置き換えられたセッション記録
8	ランタイムキャッシュ	cache/, file-history/, logs/, shell-snapshots/	サイズとmtimeでソート；30日以上経過した大きなアイテムを提案

ワークフロー

1. スキャン すべてのチャネル（またはユーザーが指定したサブセット）をスキャンします。パス、チャネル、フラグを立てたシグナル、サイズ、最終更新日を収集します。
2. ランク付け 信頼度（壊れている/孤立 = 高；単に古い = 低）でランク付けし、番号付きテーブルで提示します。各実行で約20候補に制限します。GCは定期的であり、網羅的ではありません。
3. 1つずつ確認。 各候補について証拠を表示し、[y/n/skip] を尋ねます。ユーザーはいつでも中断できます。
4. 確認されたアイテムをソフトデリート： スキルとフックには .disabled リネームを、ファイルには _gc_trash/<date>/ への移動を優先します。権限エントリはJSONに存在します（コメント不可）：設定ファイルをバックアップし、削除した各エントリを gc_log.md にそのまま記録し、jq で allow 配列から削除します。ユーザーが明示的に要求した場合にのみハードデリートします。
5. ログに記録 ~/.claude/gc_log.md に実行を記録します：タイムスタンプ、処理したアイテム、元に戻す手順。
6. 報告 再利用されたサイズ、まだ正常なチャネル、推奨される次回レビュー日を報告します。

スキャンコマンド例

孤立したフックスクリプト（チャネル3） — ディスク上に存在するが、どのフック設定からも参照されていないスクリプト：

for f in ~/.claude/hooks/*; do
  name=$(basename "$f")
  grep -rq "$name" ~/.claude/settings.json ~/.claude/settings.local.json 2>/dev/null \
    || echo "ORPHAN: $f"
done

冗長な権限エントリ（チャネル4） — 重複、およびワイルドカードによって隠蔽されている特定の許可：

jq -r '.permissions.allow[]' ~/.claude/settings.local.json | sort | uniq -d
if jq -e '.permissions.allow | index("Bash(*)")' ~/.claude/settings.local.json >/dev/null; then
  jq -r '.permissions.allow[]' ~/.claude/settings.local.json \
    | grep '^Bash(' | grep -vF 'Bash(*)'
fi

最大の古いキャッシュ（チャネル8） — GNU専用の find -printf の代わりに du -k を使用するため、macOS/BSDでも動作します：

find ~/.claude/file-history ~/.claude/shell-snapshots -type f -mtime +30 \
  -exec du -k {} + 2>/dev/null | sort -rn | head -20

元に戻せるソフトデリート（日付を一度キャプチャして、ログとディレクトリが矛盾しないようにする）：

gc_date=$(date +%Y-%m-%d)
mkdir -p ~/.claude/_gc_trash/$gc_date
mv ~/.claude/skills/dead-skill ~/.claude/_gc_trash/$gc_date/
echo "$(date -Iseconds) moved skills/dead-skill -> _gc_trash/$gc_date/ (undo: mv back)" >> ~/.claude/gc_log.md

確認済みの冗長な権限エントリの削除（JSONにはコメントがありません — バックアップ、ログ記録、編集）：

cp ~/.claude/settings.local.json ~/.claude/settings.local.json.bak
echo "$(date -Iseconds) removed permission entry: Bash(git push) (undo: restore from .bak or re-add)" >> ~/.claude/gc_log.md
jq '.permissions.allow -= ["Bash(git push)"]' ~/.claude/settings.local.json.bak \
  > ~/.claude/settings.local.json

アンチパターン

• 一括承認。 「15個すべて削除しますか？ [y/n]」と尋ねるのは設計に反します。1アイテム、1判断です。
• 初回パスでハードデリート。 _gc_trash/ コピーや .disabled リネームがない場合は、やり方を間違えています。
• 「古い」を「死んでいる」と見なす。 60日間触れられていないスキルが季節的なもの（確定申告シーズン、四半期レビュー）である可能性があります。年数はシグナルであり、評決ではありません。だからこそ人間が確認するのです。
• メモリを切り詰めてクリーンアップする。 矛盾する2つのメモリファイルをマージするには、両方を読み、新しい方の真実を保持する必要があります。長い方を削除するのではありません。
• ~/.claude の外部に触れる（またはプロジェクトの .claude/）。Config GCはソースツリーに決して入り込みません。

ベストプラクティス

• カレンダーだけでなく、大規模な追加後にも実行してください。50スキルのパックをインストールしたときこそ、既存スキルとの重複が発生するタイミングです。
• 2つのスキルが重複している場合、トリガー説明が弱い方を無効にすることを推奨します。おそらくそもそも発動していなかったものです。
• 権限のクリーンアップは、費やした1分あたりの価値が最も高いチャネルです。冗長な許可エントリはセキュリティレビューを困難にします。
• gc_log.md は永久に保持してください。サイズが小さく、「そのフックをいつ無効にしたのか、なぜか」という質問は想像以上によく発生します。

関連スキル

• skill-stocktake — スキルの品質を監査します。config-gcはスキルの存在を監査します。GCを生き延びたスキルに対してstocktakeを実行してください。
• workspace-surface-audit — 追加的な対応物です。何をインストールすべきかを推奨します。config-gcは同じライフサイクルの減法的な半分です。
• configure-ecc — ECCでスキルをインストールした後、config-gcを実行して既存設定との重複を調整します。
• continuous-learning — このスキルが後で監査するメモリファイルを生成します。
• security-review — 権限チャネルとよく組み合わせます。