Claude Codeが自分の「劣化」を週次検知して自動修復する仕組み

前回、申し送りダッシュボードで無人ジョブの状況を毎朝一覧にした話を書きました。今回はその一段上 ―― Claude Code環境自体が「先週より劣化していないか」を自分で計測し、閾値を超えたら自分で~/.claudeを直しにいく仕組みの話です。

先に実測だけ出します。2026-08-23の週次監査では、起動時に毎回注入されるバイト数(inject_bytes)が閾値40,000を超えて56,321バイトまで膨張していました。claude -pによる自己修正で43,487バイト（23%削減）まで戻しましたが、それでも閾値を3,487バイト超えたまま「要人間」と正直に報告して止まっています。一方、1週間前の2026-08-16の同じRED判定では、自己修正の前後でinject_bytesが48,958→48,958と1バイトも動いていない回もありました。直した「つもり」と実際に直った量がズレる ―― これが今回の主題です。

困りごと：環境が壊れているかどうかを人間が毎週見に行く体力がない

発端は2026-07-11のパフォーマンス監査でした。スクリプトのヘッダコメントにそのまま残っています。

背景: 2026-07-11パフォーマンス監査で「退避したはずのagents 99体が注入され続ける」等の
      環境劣化がユーザー体感悪化の主因と判明。以後は人間が面倒を見ずに済むよう常設化。

agents-archive/に退避したはずのサブエージェント定義が、実は再帰的にドットディレクトリまで読み込まれていて99体分そのまま注入され続けていた ―― という事故です。この手の劣化はrulesファイルの継ぎ足し、MEMORY.mdの肥大、hookのスパム化など、毎週少しずつ静かに進行するので、気づいた時には手遅れになりがちです。かといって「週1で自分の設定ディレクトリを見に行く」を人間の習慣に頼ると、まず続きません。

全体像：計測 → 自己修正 → 独立再計測の3層ループ

~/.claude/scripts/cc-self-audit.shが日曜8:30にlaunchdで起動し、この3段を1本のシェルスクリプトでやります。

1. 静的計測：注入バイト数・agents読込数を実ファイルから数える
2. 動的計測：前回実行以降のtranscriptから、監査hookのスパム・不満ワード・tool失敗を数える
3. 閾値を超えたら（RED）claude -pが~/.claude内だけを自己修正し、修正後に同じ計測をもう一度独立に走らせて改善を検証する

fail-open設計で、bash 3.2互換・set -uo pipefail。監査自体がコケても既存の環境を壊さないようにしてあります。

5指標と閾値

静的2指標は毎回フルスキャン、動的3指標はself-audit/lastrun.markerより新しいtranscript（最大200ファイル）だけを見ます。計測本体はこれです。

collect() {
  local inject_bytes agents_loaded
  inject_bytes=$(( \
    $(find "$HOME/.claude/rules" -name '*.md' -print0 2>/dev/null | xargs -0 cat 2>/dev/null | wc -c) + \
    $(cat "$HOME/.claude/CLAUDE.md" 2>/dev/null | wc -c) + \
    $(cat "$HOME/CLAUDE.md" 2>/dev/null | wc -c) + \
    $(cat "$HOME/.claude/projects/-Users-matsubara/memory/MEMORY.md" 2>/dev/null | wc -c) ))
  agents_loaded=$(find "$HOME/.claude/agents" -name '*.md' 2>/dev/null | wc -l | tr -d ' ')
  # ...動的3指標(stopspam/frustration/toolerr)は前回実行以降のtranscriptから...
}

breaches()は素朴にPython辞書と比較するだけです。

th = {'inject_bytes': 40000, 'agents_loaded': 60,
      'stopspam': 15, 'frustration': 8, 'toolerr': 400}
for k, t in th.items():
    if m.get(k, 0) > t:
        print(f'{k}={m[k]} (閾値{t})')

stopspam/frustrationの検出は最初、素朴なgrepでした。すると2026-07-12の実測でstopspamが6→40、frustrationが4→18に跳ね上がってしまいました。原因はhookスクリプト自身のソース引用やtranscript内のtool_result本文の部分一致まで誤検知していたことです。今はStop hookが実際に注入するStop hook feedback:\n[.../self_audit_stop.sh]:という固定文字列の完全一致と、type=userかつisMetaでない=人間の実発言だけに絞っています。

自己修正：claude -pに~/.claudeだけを触らせる

REDになったら、検知した違反と直近履歴を埋め込んだプロンプトでclaude -pを呼びます。

OUT=$(cd "$HOME/.claude" && printf '%s' "$PROMPT" | run_capped "$FIX_TIMEOUT" "$CLAUDE" \
      --strict-mcp-config --mcp-config '{"mcpServers":{}}' -p \
      --model "$MODEL" --output-format text \
      --allowedTools "Read,Write,Edit,Bash,Grep,Glob" \
      --max-turns 50 2>&1) || true

プロンプト本文には既知の劣化パターンと対処の正典を書いてあります。

2. 既知の劣化パターンと正典:
   - agents_loaded超過 → ~/.claude/agents/ 配下の退避漏れ（ドットdirも読み込まれる）を agents-archive/ へ移動
   - inject_bytes超過 → 肥大したrules/MEMORY.mdを圧縮（フル版は rules-archive/ へ。リンクは全維持し索引整合を検証）
   - stopspam超過 → self_audit_stop.sh の抑制ロジックを点検
   - frustration/toolerr超過 → 該当transcriptをgrepして真因を特定し再発防止を仕込む
4. 修正後に必ず 'cc-self-audit.sh --collect-only' を実行し改善を数値で確認
5. 自分で安全に直せない項目は無理せず、最後に『要人間: 理由』と1行で出力

--strict-mcp-configでMCPサーバーをゼロにし、allowedToolsは読み書き4種＋Bashのみ。作業ディレクトリを~/.claudeに固定し、修正対象を自分のホームディレクトリの外に出さない作りです。

検証：自己申告は信じない

肝はここです。claude -pが「直した」と言っても、修正が終わった直後にスクリプト自身がもう一度collect()を独立に呼び直します。history.jsonlに残っている実例を3つ並べます。

失敗①：自己申告と実測が逆方向にズレた（2026-07-12）

[2026-07-12 08:30:06] RED: stopspam=40 (閾値15) / frustration=18 (閾値8)
[2026-07-12 08:40:00] claude output: frustration=18→0（誤検知だったtool_result部分一致を排除、実発言は0件）、
                       stopspam=40→27（重複計測バグ修正）...次回集計窓で閾値15以下に収束見込み。
[2026-07-12 08:40:03] after: {"stopspam":58,"frustration":32,"toolerr":68}

claude -pは「frustration 18→0」「stopspam 40→27」と申告しましたが、独立再計測の結果はstopspam=58, frustration=32と申告と逆に悪化していました（この誤検知自体が上のgrep問題そのもので、後日修正されています）。もし自己申告だけを信じてDiscordに「✅直りました」と流していたら、実態と真逆の報告になるところでした。

失敗②：直したつもりで数値が1バイトも動かない（2026-08-16）

[2026-08-16 08:30:36] RED: inject_bytes=48958 (閾値40000)
[2026-08-16 08:50:37] claude output: (空)
[2026-08-16 08:51:05] after: {"inject_bytes":48958, ...}

claude output欄が空のまま、before/afterでinject_bytesが完全に同一でした。何も変えずに終わった空振りです。これも独立再計測がなければ「実行はしたから大丈夫」で見逃されていたはずです。

成功：直った上で、直り切らなかった分は正直に「要人間」（2026-08-23）

[2026-08-23 08:30:11] RED: inject_bytes=56321 (閾値40000)
[2026-08-23 08:43:57] claude output: inject_bytes 56321→43487(23%減、全リンク検証OK、個別memoryファイル358件は無傷)。
                       要人間: 残り3487超過分は「稼働中プロジェクト」セクション(進行中の商談・金額・日程を含む)が
                       主因で、機械的に安全判断できないため本人による棚卸しが必要。
[2026-08-23 08:44:27] after: {"inject_bytes":43487, ...}

changelogにはもう少し詳しく残っています。

1) フルバックアップ: rules-archive/memory-md-full-2026-08-23.md に元MEMORY.md(44798 bytes)を保存
2) 「監査・環境の不変条件」「技術リファレンス」の2セクション(解決済み45件・13KB)をインデックスから外し
   アーカイブへの1行ポインタに置換
3) 稼働中プロジェクト内の停止/完了確認済みエントリ4件を削除しアーカイブ参照に置換
4) 個別memoryファイル(358件)は一切削除していない
結果: MEMORY.md 44798→31964 bytes、inject_bytes 56321→43487 bytes (23%削減)
検証: 全リンク255件がファイル実在と一致(MISSING 0件)

この回は「消していい根拠がある分だけ機械的に削り、根拠のない分（進行中の商談情報）は閾値割れのまま人間に投げる」という判断をclaude -p自身がして、それを独立再計測が裏付けた形です。3件とも同じスクリプトの同じ経路ですが、**「申告と実測が逆行」「申告だけ空振り」「申告と実測が一致し正直に残課題を報告」**の3パターンが実際に起きています。これが「自己申告を信じない」を設計の中心に置いている理由です。

報告：緑は1行、赤は差分入りでDiscordへ

if [ -z "$STILL" ]; then
  notify "🔧 CC自己監査: 劣化検知→自己修正済み。前:[$BREACH] 後:全緑。詳細=$CHANGELOG"
else
  notify "🚨 CC自己監査: 自己修正後も残存 [$STILL]。要確認: $LOG / $CHANGELOG
Claude要約: $(echo "$OUT" | tail -3 | tr '\n' ' ')"
fi

緑（違反なし）の週は✅ CC自己監査: 正常の1行だけをDiscordの#01_alertsに飛ばします。週1実行なので、これは「生存確認」も兼ねています。赤のまま直り切らなかった週（2026-08-23はまさにこれ）は🚨付きで残存差分とclaude -pの要約をそのまま転記し、揉み消さずに人間に渡します。

launchd側：前回の教訓をそのまま活かす

com.lily.cc-self-audit.plistは日曜8:30起動です。

<key>EnvironmentVariables</key>
<dict>
    <key>PATH</key>
    <string>/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin:~/.local/bin</string>
</dict>
<key>ProgramArguments</key>
<array>
    <string>~/.claude/scripts/claude-quota-guard.py</string>
    <string>--job</string>
    <string>com.lily.cc-self-audit</string>
    <string>--</string>
    <string>/bin/bash</string>
    <string>~/.claude/scripts/cc-self-audit.sh</string>
</array>
<key>LowPriorityIO</key><true/>
<key>Nice</key><integer>10</integer>
<key>RunAtLoad</key><false/>

PATHを明示しているのは、前回の記事で書いた「launchdの最小PATHでclaudeが見つからない」を踏まえた対策です。さらに実行本体を直接bash cc-self-audit.shにせず、claude-quota-guard.py --job ... --でラップしています。無人ジョブがプラン枠を食い潰す事故は既に別の仕組みで学んでいたので、週次監査もその枠管理を素通りさせません。Nice 10とLowPriorityIOで、フォアグラウンド作業を妨げない優先度に落としてあります。

踏んだ落とし穴

• 素朴なgrepでstopspam/frustrationが実体と無関係に跳ねた（6→40, 4→18） → hookが注入する固定マーカー文字列の完全一致と、type=userかつisMetaでない発言のみに絞った
• 自己申告(frustration 18→0)が独立再計測(32)と逆行した → 「直した」をログに書かせるだけでは不十分。修正後に必ず同じcollect()をもう一度独立に走らせる設計にした
• RED修正が空振りでbefore/afterが完全一致した回があった → 空振りもSTILL判定にそのまま乗るので、握りつぶさずDiscordに残る
• agents_loadedはドットディレクトリも再帰的に読み込まれる → 単純なfind *.mdではなく、退避先(agents-archive/)自体が~/.claude/agents配下に残っていないかも合わせて見る必要がある
• MEMORY.mdの「進行中の商談」は機械的に安全に削れる根拠がない → 閾値割れのまま「要人間」で止める判断をプロンプト側に明示している

まとめ

• 週次で計測→（赤なら）自己修正→独立再計測の3層ループをlaunchd一本で回している
• 指標はinject_bytes/agents_loaded/stopspam/frustration/toolerrの5つ、すべて数値の閾値超過で判定
• claude -pの自己申告はそのままでは信じない。修正後に同じ計測をもう一度独立に走らせて初めて「直った」と扱う
• 実際に「申告と実測が逆行」「申告だけ空振り」の両方が起きており、独立再計測なしでは見逃していた
• 直し切れない分（進行中の商談情報など）は閾値割れのまま「要人間」で正直に止める設計にしている

次回は、MEMORY.mdの「進行中の商談・案件情報」を機械にどこまで判断させてよいか ―― 自動化と人間の判断の線引きについて書く予定です。

---

Lily（@bokuwalily）― 個人開発者。Claude Code で自動化基盤を組みながら、iOSアプリやWebサービスを量産しています

• AIで「寝てても回る仕組み」を作って月120万にした話は noteの有料記事 に💰
• OSS: github.com/bokuwalily 🐙
• 最新情報・お問い合わせは X @bokuwalily へ🌍
• AI導入・自動化の相談と実装テンプレ7本の配布は 公式LINE から💬

皆さんの ❤️ やシェアが励みになります！