Claude Codeでコードを書いてPRを出す。レビューで指摘を受ける。直す。次のPRでまた同じ種類の指摘を受ける。
Claude Codeはセッションをまたぐと記憶をリセットします。これが根本的な問題です。プロンプトをどれだけ丁寧に書いても、新しいセッションでは前回の学びが消えて最初からやり直しになります。
必要なのはプロンプトの工夫ではなく、過去の失敗を蓄積してセッションをまたいで読み込ませる仕組みです。
この記事では、レビュー指摘をClaude Codeの設定ファイルに蓄積し、同じミスを繰り返させなくする「失敗学習ループ」を紹介します。3ヶ月運用した結果、同種のレビュー指摘が繰り返されることはほぼなくなりました。
実例：レビュー指摘から生まれたルール
仕組みの説明の前に、実際にPRレビューで指摘を受けて記録した教訓を紹介します。「こういうものを記録するのか」というイメージを持ってもらえると、後の説明が頭に入りやすくなります。
EUC-JPファイル破壊事件
20年以上続くWebサービスのコードベースには、EUC-JPでエンコードされたPHPファイルが大量に残っています。UTF-8が当たり前の今ではピンとこない話ですが、2000年代前半に書かれたコードはEUC-JPやShift_JISが普通でした。既存の全ファイルをUTF-8に変換するのは影響範囲が大きすぎて、レガシーなエンコーディングと共存し続けるしかありません。
Claude CodeのEdit/Writeツールは内部的にUTF-8で処理しています。EUC-JPのPHPファイルをEditツールで編集すると、ファイル全体がUTF-8に変換されて日本語が文字化けします。
最初にこれが起きたのはあるリポジトリでした。memoryに記録しました。
### EUC-JPファイルの編集 (2026-01-10)
- **状況**: PHPファイルをEditツールで編集した
- **失敗**: EUC-JPがUTF-8に変換されて文字化けした
- **正解**: `file` コマンドでエンコーディングを確認し、EUC-JPならPythonのバイナリ操作で編集するレビュー指摘ではなくClaude Codeのツール自体がファイルを壊すパターンです。しかもgit diffを見るまで気づかない。この種の「静かな破壊」こそ記録しておくべき教訓です。
失敗学習ループの仕組み
ここからは、上のような教訓をどこに・どう蓄積するのかを説明します。
失敗学習ループは3つの層で構成されています。
~/.claude/
├── projects/<project-hash>/
│ └── memory/ ← ① プロジェクト固有の学び
│ ├── MEMORY.md
│ └── pr-review-lessons.md
├── rules/ ← ② 汎用ルール（全プロジェクト共通）
│ ├── testing-conventions.md
│ └── failure-learning.md
└── CLAUDE.md ← ③ 毎回読み込まれるエントリポイントClaude Codeは起動時に CLAUDE.md と rules/ 配下のファイルを読み込みます。memory/ 配下はプロジェクトごとに分かれていて、そのプロジェクトで作業するときだけ読み込まれます。
教訓の流れはこうなります。
レビューで指摘を受ける
↓
memory/ に教訓として記録
↓
同じパターンが別プロジェクトでも発生 → rules/ に昇格
↓
全セッションで自動適用重要なのは「最初から網羅的なルールを書こうとしない」ことです。まずmemoryに記録して、繰り返されたら昇格させる。実戦で検証されたルールだけが残ります。
Claude Code自身に記録させる
手動で毎回memoryに書くのは面倒です。Claude Code自身に「失敗したら記録する」というルールを設定すれば、自動化できます。
~/.claude/rules/failure-learning.md に以下を書いています。
# 失敗時の自動記録
タスクが失敗・間違いだった場合、以下を自動で実行すること：
1. 失敗の原因を簡潔に分析する
2. 適切な場所に記録する：
- プロジェクト固有の失敗 → memory/ 配下
- 汎用的な失敗パターン → rules/ 配下にルール追加
3. 同じ失敗がメモリに2回以上記録されている場合は、ルールに昇格させる記録フォーマットも指定しています。
### [簡潔なタイトル] (YYYY-MM-DD)
- **状況**: 何をしようとしたか
- **失敗**: 何が間違っていたか
- **正解**: 正しいアプローチ実際の動きはこうです。たとえばClaude CodeがEUC-JPファイルをEditツールで壊してしまい、git diffで文字化けに気づいたとします。その場でClaude Codeに「EUC-JPファイルだった、Editツールを使ってはいけない」と伝えると、コードを修正すると同時にmemoryファイルに教訓を追記します。その後の新しいセッションでは、memoryに書かれた教訓を読んだ上でコードを書くので、同じミスが起きなくなります。
記録するもの・しないもの
何でも記録すると、設定ファイルがノイズだらけになります。基準を決めておくのが大事です。
記録する
- レビュアーから指摘されたコーディングパターン
- 2回以上発生した同種のエラー
- プロジェクト固有の制約（エンコーディング、API仕様など）
記録しない
- ネットワーク障害などの一時的なエラー
- 1回しか発生していない環境固有の問題
- CLAUDE.mdに既に書いてあること
3ヶ月運用した結果、memoryには15件、rulesには5件が蓄積されています。月に1〜2件ずつ増えるペースです。
memory → rules への昇格基準
memoryに同じパターンの失敗が2回以上記録されたら、rulesに昇格させます。
先ほどのEUC-JPの例で言えば、最初はあるリポジトリのmemoryに記録しました。しかし同じサービスには複数のリポジトリがあり、どれもEUC-JPファイルを含んでいました。別のリポジトリで同じ失敗が発生した時点で、rulesに昇格させました。
memory/（リポジトリA固有）
↓ リポジトリBでも同じ破壊が発生
rules/euc-jp-files.md（全プロジェクト共通）昇格後のルールはこうなっています。
# EUC-JPファイル編集の絶対ルール
PHPファイルを編集する前に、必ず `file <path>` でエンコーディングを確認する。
- `ISO-8859 text` / `Non-ISO extended-ASCII text` → EUC-JPファイル
- `UTF-8 text` → UTF-8ファイル（Edit/Writeツール使用可）
EUC-JPファイルはEdit/Writeツールを絶対に使わない。
Pythonバイナリ操作で編集すること。ルール化してからは一度も再発していません。
昇格させるときのポイントは、プロジェクト固有の文脈を取り除いて汎用的な表現に書き換えることです。「リポジトリAのPHPファイルはEUC-JP」→「PHPファイルを編集する前にエンコーディングを確認する」のように。
チームへの展開
個人の失敗学習をチームに広げるには、リポジトリのルートに .claude/ ディレクトリを配置します。
リポジトリ/
├── .claude/
│ ├── CLAUDE.md # チーム共有ルール
│ └── commands/
│ └── pr-review.md # PRレビュースキルここに書いたルールは、そのリポジトリでClaude Codeを使う全員に適用されます。
ポイントは「個人のmemoryで検証済みのルールだけをチームに共有する」ことです。自分のmemoryで効果を実感したルールを、チームのCLAUDE.mdに書く。実績のないルールを入れても守られないし、メンテナンスコストだけが増えます。
まとめ
失敗学習ループの要点は3つです。
- レビュー指摘を構造化して記録する — 「状況・失敗・正解」の3点セットで書く
- Claude Code自身に記録させる —
failure-learning.mdルールで自動化する - 繰り返されたら昇格させる — memory → rules → チームCLAUDE.md
プロンプトエンジニアリングに凝るよりも、地道にレビュー指摘を蓄積する方が確実に効きます。使い込むほどルールが増えて、Claude Codeの出力品質が上がっていく仕組みです。
まず今日、直近のPRのレビューコメントを1つだけ選んで memory/pr-review-lessons.md に書いてみてください。フォーマットは「状況・失敗・正解」の3行です。それだけで次のセッションからClaude Codeの動きが変わります。
