AIに「過去の失敗」をフィードバックして自己改善させる：feedback 61件分析からのROIランキング

AIエージェント（Claude Code）に過去の失敗を学習させる仕組みとして、feedback_*.md というメモリファイルに気づきを書き溜めていました。半年で61件溜まったところでメタ分析してみたら、**「ルール追加よりも自動検証の方がROIが圧倒的に高い」**という結論に至りました。

本記事は、61件のフィードバックを分類し、優先度マトリクスで投資判断する実践記録です。

背景：feedbackファイルが61件に膨らんだ

AI駆動開発を進める中で、Claudeが同じミスを繰り返すたびに、

• 「次回からはこうしてくれ」というルールをCLAUDE.mdに追記する
• もしくは feedback_xxx.md という小さなメモを作って残す

という運用をしていました。半年経った時点で feedback_*.md が 61件 に到達。

CLAUDE.md肥大化問題が再来した

しかしこの運用には限界がありました。

• AIが毎回全フィードバックを読みきれない（コンテキスト圧迫）
• ルールが増えすぎて矛盾が出てくる
• 「過去にこう失敗した」という情報があっても、実装時に思い出さない

ルールを追加しても、ミスの再発率が下がっていない。何かが間違っていると感じ始めました。

メタ分析：61件を5カテゴリに分類

そこでフィードバックを5つのカテゴリに分類しました。

そして各件について、「自動検証が存在すれば防げたか?」 という観点で再分類しました。

つまり、約半分が自動検証で防げるということが見えてきました。

ROIマトリクス：High-Medium で投資判断

そこで「実装コスト × 効果」のマトリクスを作りました。

1
        効果大         効果中         効果小
2
コスト小  [A]            [B]
3
コスト中  [C]            [D]
4
コスト大  [E]

High優先度（5分実装で最大効果）

• 衝突マーカー検出 pre-commit hook: 行頭の <<<<<<< ======= >>>>>>> を検出するだけ。20行のシェルスクリプトで実装可能。過去のcherry-pick事故の3割を防げます。
• memory ファイル鮮度チェック: 直近7日以内に更新されていないエントリは自動でアーカイブ退避。

Medium優先度（半日〜1日で実装）

• cherry-pick 監査 skill: 並行セッション・依存PR・スコープ拡張を6項目で機械チェック。
• デプロイジョブの意図検証: exit 0 ではなく「期待される生成物が存在するか」まで確認。

Low優先度（やってはいけない）

• ルール追加でCLAUDE.mdを膨らませる
• 「気をつける」系の運用ルール

ルール追加の罠：5つの逆効果

ルール追加は一見効果がありそうですが、メタ分析の結果逆効果が見えてきました。

罠1: ルール同士が矛盾する

「PRは小さく分割する」と「依存PRは1本にまとめる」は両立しません。場面で使い分ける必要がありますが、AIは矛盾するルールに直面すると判断停止します。

罠2: 読み込まれない

CLAUDE.md が肥大化すると、AIは末尾のルールから順に「軽く読む」モードに入ります。20番目のルールは事実上効いていません。

罠3: コピペ運用が崩れる

「このプロジェクトでは X してください」というルールが30件溜まると、新しいプロジェクトに移植するときにそのまま持ち込めません。プロジェクト固有性が高すぎるルールばかりになります。

罠4: ルール追加が「対応した感」を生む

事故が起きた時、「CLAUDE.mdにルールを追加しました」で終わらせると、本質的な防止策（自動検証）に投資しなくなります。

罠5: 自動検証なしでは検証されない

「気をつける」系のルールは、実行時に検証されません。AIが本当にそのルールに従っているかは、誰も確認できません。

自動検証への投資が効く構造

逆に、自動検証は以下の点で効きます。

• 実装が一度で済む: hook / skill / lint は一度書けばずっと効く
• AIの判断に依存しない: ルールを「思い出す」必要がない
• 失敗が可視化される: hookが落ちれば即座にわかる
• 転用可能: skill は他プロジェクトに移植できる

つまり、フィードバックが溜まったら、「次のルール追加」ではなく「次の自動検証」を考えるべきです。

実装：上位3つの hook / skill

1. 衝突マーカー検出 hook（5分実装）

1
#!/bin/bash
2
if git diff --cached --name-only | xargs grep -lE '^(<{7}|={7}|>{7})$' 2>/dev/null; then
3
  echo "ERROR: 衝突マーカーが残っています"
4
  exit 1
5
fi

2. memory 鮮度チェック skill（30分実装）

直近7日以内に更新されていない feedback_*.md を archive/ に退避。MEMORY.md から該当行を削除します。

3. cherry-pick-audit skill（半日実装）

並行セッション検出・依存PR確認・スコープ拡張候補・squashハッシュ整合性を6項目で監査。GO/NO-GO 判定を返します。

振り返り：feedback運用の3原則

61件分析を経て、feedback_*.md 運用は以下のルールに落ち着きました。

1. 追記前に問う: 「これは自動検証できるか?」できるなら hook/skill 化を優先
2. 3ヶ月で棚卸し: 古いフィードバックは archive に退避してMEMORY.mdから削除
3. ROIで優先順位: 「コスト小 × 効果大」を最優先で実装

ルールを増やすより、仕組みで縛る。これがAI駆動開発の自己改善の本質だと考えるようになりました。

まとめ

• フィードバック61件のメタ分析で、約半分が自動検証で防げると判明
• ルール追加には5つの罠（矛盾・未読・移植不可・対応した感・未検証）
• 5分で実装できる hook が最大ROI
• AIに学ばせるなら「ルール」より「仕組み」

CLAUDE.md にルールを追記する前に、一度立ち止まって「これ自動検証できないか?」を問うべきです。