AI への指摘は、ルールだけでなく理由と判断の経緯まで残す
指摘したはずのことを、また間違える
Claude Code などの AI で作業していると、前に指摘したのと同じ間違いにまた出会います。 セッションが変われば、会話の中で伝えたことは残らないからです。
そこで「CLAUDE.md や記憶ファイルにルールを残す」のが定番です。 ただ、ルールを 1 行残すだけだと、次のようなことが起きます:
- どこまで当てはまるのかわからない: 「本番のパスを推測しない」と書いてあっても、何をすれば推測でなくなるのかは書かれていない
- 似た別の場面で効かない: 前と同じ形の場面は避けられても、形が少し変わると同じ間違い方をする
- いらなくなっても消せない: なぜあるのかわからないルールは、消してよいのか判断できない
足りないのは、そのルールができた理由です。 私はいま、AI が指摘を記憶するときに次の 4 つを書かせています。
4 つに分けて残す
例です。 AI がファイル一覧だけを見て、本番の配置先を決めつけたときの記憶はこうなります:
本番サーバーの配置先を、ファイル一覧などの状況証拠から断定しない。
候補が複数あるなら、どれが動いているかを確かめてから手順を出す。
**Why:** `admin/` と `dev/` に同じ構成のコードがあったのに、名前から
管理画面は `admin/` だと決めつけて手順を出した。実際に動いていたのは `dev/` だった。
**How to apply:** パスやデプロイ先に依存する手順を書く前に、
「動いているのは X で合っていますか」と確かめる。同じ構造のコピーが並ぶサーバーでは特に。
**Reasoning trace:** 名前が管理画面らしいことと、必要なファイルがあることの 2 点で判断した。
`dev/` にも同じファイルがあったのに比べなかった。名前からの連想を、確かめた事実として扱った。
それぞれ役割が違います。
| 項目 | 書くこと | 役に立つとき |
|---|---|---|
| ルール | 次にどうするか | いつも |
| Why | 何が起きたか | 当てはまらない場面を見分けるとき、消してよいか考えるとき |
| How to apply | どの場面で、何をするか | 作業中に思い出すとき |
| Reasoning trace | なぜそう判断したか、どこで間違えたか | 形の違う場面で、同じ間違い方を避けるとき |
経緯まで書くと、間違い方がわかる
一番変わったと感じるのは Reasoning trace（判断の経緯）です。 結果だけを見ると小さなミスでも、経緯を書かせると本当の原因が別のところにあるとわかります。
たとえば、AI に記事のカバー写真を選ばせて、権利元のはっきりしない写真が混ざったときです。 結果だけなら「ストック写真を使わない」で終わります。 経緯を書かせると、こうなりました:
ファイル名に
adobestock_があるものだけを除外し、それ以外は使った。ファイル名で判断できないストック写真があることを軽く見ていた。
直すべきなのは「ストック写真を使わない」というルールではなく、見分け方のほうでした。 そこで、ルールは「権利元を確かめられない写真は使わない」になりました。
もう 1 つ、記事の下書きを頼んだときの例です。 「サイト名は書かなくていい」と伝えたら、AI はサイト名だけを消して、そのサイトの話は残しました。 私が伝えたかったのは、出どころがわからないようにしてほしい、ということです。 経緯を読むと、指示を文字どおりの範囲で受け取ったことがわかります。 これは「この言葉を消す」というルールでは防げません。
Claude Code で書かせる
Claude Code には、AI 自身がメモを残す自動メモリーがあります。 ただ、毎回必ず保存するわけではなく、形も決まっていません。 そこで、全プロジェクト共通の ~/.claude/CLAUDE.md にこう書いています:
- 修正を受けたら feedback の記憶を保存する
- 「なぜその判断をしたか」と「なぜ間違いだったか」の両方を記録する
- 構造: ルール → **Why:** → **How to apply:** → **Reasoning trace:**
記憶は ~/.claude/projects/<プロジェクト>/memory/ に 1 件 1 ファイルで保存され、目次の MEMORY.md が毎回読み込まれます（先頭の 200 行か 25KB まで）。 各ファイルの中身は、必要になったときに読まれます。
ほかのツールでも、プロジェクトに置いたテキストファイルへ同じ形で書かせて、最初に読むよう指示すれば、同じことができます。
たまったら、置き場所を変える
記憶はためるだけだと、読まれるかどうかが AI 任せになります。 それに、プロジェクトごとに分かれているので、ほかのプロジェクトには効きません。 私の手元でも「日本語で返答する」という同じ記憶が 3 つのプロジェクトにできていました。 これは全プロジェクト共通の CLAUDE.md に置くべきものです。
そこで、ときどき見直して、内容に合った場所へ移します:
| 内容 | 移す先 |
|---|---|
| いつも守る短いルール | CLAUDE.md、.claude/rules/ |
| 特定のファイルを触るときだけのルール | paths を指定した .claude/rules/ |
| 特定の作業の手順やチェックリスト | スキル |
| AI の判断に任せず、必ず止めたいこと | hook |
| もう当てはまらないもの | 消す |
CLAUDE.md やルールは読み込まれるだけで、強制力はありません。 公式ドキュメントでも、確実に止めたい操作には PreToolUse の hook を使うよう案内されています。 また、CLAUDE.md が長くなると守られにくくなるので、1 ファイル 200 行未満が目安です。 特定の作業でしか使わないものはスキルに移したほうが、いつもの読み込みが軽くなります。
私は、この見直しも AI に頼んでいます。 全部の記憶を読ませて、移す候補と消す候補を出させ、私が承認したものだけを反映します。 候補ごとに確かめさせているのは次の 2 つです:
- その場限りの事情を除いても成り立つか
- 1 回の失敗から広げすぎていないか。 ルールにすると害になる場面はないか
実際に、モデルを直すときの確認項目や、変更の影響範囲の調べ方についての指摘が複数たまったところで、それぞれ 1 つのスキルにまとめました。
気をつけていること
- 効果を測ったわけではない: 手元には 19 プロジェクトで 132 件の記憶があり、うち 94 件に判断の経緯が付いています。 ただ、間違いが何割減ったかは測っていません。 「読み返したときに原因がわかる」というのが正直な実感です
- 経緯は AI の自己申告: AI が書いた経緯が、本当の原因とは限りません。 後から筋の通った説明を作っている可能性もあります。 仮説として読み、Why には起きた事実を書かせます
- 記憶は古くなる: 書いた時点の情報なので、ファイル名や設定はもう変わっているかもしれません。 使う前に今の状態を確かめさせます
- 平文で残る: 記憶は手元のファイルです。 パスワードや API キーのような秘密情報は書かせないようにします
まとめ
AI に同じ間違いをさせたくないときは、
- ルールだけでなく、Why、How to apply、Reasoning trace まで書かせる
- 指摘を受けたらそう記録するよう、
CLAUDE.mdに書いておく - たまったら見直して、
CLAUDE.md、スキル、hook に移すか、消す
の 3 つを試してみてください。 まずは CLAUDE.md に 3 行足すだけで始められます。
