AIに同じ失敗を繰り返させない — lessons.md で教訓を記憶させた設計の実録

「この前も同じこと言ったのに、また同じミスをしている」——AIエージェントに作業を任せていると、必ずこの瞬間が来ます。

結論から言うと、AIが同じ失敗を繰り返すのは性格の問題ではなく、セッションが終わると記憶がリセットされる構造の問題でした。だから指示書に「やるな」と書いても効きません。私は、失敗のたびに教訓を lessons.md という専用ファイルへ1行ずつ書き残し、次のセッションの開始時に必ずそれを読ませるようにして、ようやく再発を止められるようになりました。

この記事は成功者の教科書ではなく、実際にAIエージェントへ業務を任せて2ヶ月回した実装者の航海日誌です。CIを10日間で14回連続で落としたような失敗を、どうやって「記憶」に変えて再発を止めたのか。そのまま当てはめられる形で、設計プロセスを公開します。

---

結論：教訓は指示書ではなく「専用の記憶ログ」に置く

最初に、2ヶ月運用して落ち着いた結論を1枚で示します。

置き場所	役割	中身
CLAUDE.md（指示書）	入口の契約・常時ルール	プロジェクト定義、守るべき作業原則、人間ゲートの境界
lessons.md（教訓ログ）	失敗から得た再発防止策	「いつ・何で失敗し・次はどうするか」を1件1行で蓄積
lint / CI（機械ガード）	守らせる強制力	教訓のうち機械判定できるものを、物理的に弾く

ポイントは3つです。

1. 指示書（CLAUDE.md）に教訓を全部足さない。 指示書が膨らむほどAIは読み飛ばします。教訓は別ファイル lessons.md に隔離する。

2. 教訓は「1件1行・原因と対策セット」で書く。 物語ではなく、次の作業で参照できる形式にする。

3. セッション開始時に必ず lessons.md を読ませる。 書き残すだけでは意味がなく、着手前に読むルールまで設計して初めて再発が止まります。

この「書く→読む」の往復を仕組みにできるかどうかが、AIを成長させられるかどうかの分かれ目でした。

---

この記事の前提（実験条件）

何を前提に話しているかを先に開示します。

• 運用サイト: masatoman.net（記事 約140本）を、複数のAIエージェントによる自動運用で回しています
• スタック: Next.js 16 + MDX + Vercel。記事は MDX ファイルで管理し、定期実行で各エージェントが動く
• 連携方式: 共有ボード（Notion）をハブにして各エージェントが非同期で読み書き。ログは Slack に集約
• 記憶の置き場: プロジェクト直下に CLAUDE.md（指示書）と tasks/lessons.md（教訓ログ）を分けて配置
• 固定費: 月 約¥3,170（内訳は Claude Pro ¥3,000 ＋ ドメイン 約¥170。ダッシュボードで実測）

つまり「高価なツールで組んだ大規模な仕組み」ではなく、月3千円台で個人が組める範囲の、ただのテキストファイル2枚による記憶設計の話です。

---

読者のよくある詰まり（「それ、自分だ」）

AIに作業を任せて学習させようとすると、だいたい次のどれかで詰まります。

1. 指示書に「やるな」と書いたのに、また同じミスをする。 CLAUDE.md に禁止事項を足し続けても、AIは平気で破ります。指示書は努力目標であって、守られる保証がない。

2. 教訓を書き残してはいるが、次のセッションで読まれていない。 メモは増えるのに、肝心の作業時に参照されないので、結局また踏む。記録と参照が分断されている。

3. 教訓ファイルが膨らみすぎて、どれも効かなくなる。 あらゆる失敗を雑に書き溜めた結果、AIがどれを優先すべきか分からず、全部が等しく無視される。

私は3つ全部踏みました。順に何が起きたかを書きます。

---

実際に起きたこと（数字と失敗）

数字だけ見ると失敗だらけですが、重要なのは、「記録する」だけでは止まらず、「着手前に読む」と「機械で弾く」をセットにして初めて再発が止まったという点です。

---

原因分析：なぜ指示書だけでは再発を止められないのか

失敗が繰り返された箇所には共通点があります。どれも「セッションをまたいで記憶が引き継がれない」ことが原因でした。

AIエージェントは、1回のセッションの中ではよく学びます。「さっき直したばかりだから次は気をつけて」と言えば、その場では直る。けれどセッションが終わると、その学びはきれいに消えます。次に立ち上がったAIは、前回失敗したことを知らない別人として作業を始めます。だから同じ落とし穴に、何度でも、まっさらな気持ちで落ちる。

ここで多くの人は「じゃあ CLAUDE.md（指示書）に書けばいい」と考えます。私もそうしました。でも指示書は、入口でプロジェクトの前提を伝えるためのものであって、細かい失敗の教訓を全部抱えると破綻します。項目が増えるほど一つ一つの重みが薄まり、AIは長い指示書を読み飛ばすようになる。指示書はルールを「伝える」場所であって、過去の失敗を「記憶する」場所ではなかったのです。

そして、たとえ正しく書いても、指示書には強制力がありません。「frontmatter を正しく書け」と書いてあっても、AIはそれを破る。守らせたいなら、人間の善意ではなく機械の壁が要ります。この「指示書では守られない、機械で弾くしかない」という顛末は、別記事で詳しく書いています。本記事の「記憶（再発させない）」と、次の記事の「機械ガード（破られても止める）」は、表裏一体の設計です。

AI agent が規範を破った実録 — CI 14回連続失敗と機械ガード設計

指示書では守られない。AIの出力を機械ルールで弾く検証ゲートの作り方

→

---

判断基準：CLAUDE.md / lessons.md / 機械ガードの使い分け

得た知見を「どこに書くか」で迷ったとき、私はこの3問で振り分けています。

Q1. それは「常に守るべき前提」か、「失敗から得た教訓」か？ プロジェクトの定義や常時ルール（誰のために書くか、人間ゲートの境界など）は CLAUDE.md。実際に踏んでから学んだ再発防止策は lessons.md。前提と教訓を混ぜないことが、どちらも効かせるコツです。

Q2. その教訓は、機械で正否を判定できるか？ 「frontmatter に必須項目があるか」「禁止ワードが混ざっていないか」のように機械判定できるものは、lessons.md に書くだけで止めず、lint / CI ゲートに昇格させる。人間（やAI）の注意力に頼る限り、いつか必ず破られます。

Q3. その教訓は、次の作業で参照されるか？ 書いた教訓が読まれないなら、記録は無意味です。セッション開始時・タスク着手前に lessons.md を読むことを、作業手順そのものに組み込む。「書く」と「読む」を必ずワンセットで設計します。

この3問で振り分けると、冒頭の表（指示書／教訓ログ／機械ガード）に自然に収束します。AIを成長させる鍵は、賢いモデルを選ぶことより、失敗を記憶に変えて次へ渡す仕組みを自分で組むことだ、というのが2ヶ月での実感でした。

なお、そもそもAIに渡す入口の指示書（CLAUDE.md）の質が低いと、教訓ログ以前にドラフトの精度が出ません。入口設計はこちらにまとめています。

CLAUDE.md 設計ガイド2026

AIエージェントが迷わず動くプロジェクト定義の書き方

→

---

今日やること（3つだけ）

1. プロジェクト直下に tasks/lessons.md を1枚作る。 中身は空でいい。まず「教訓を書き溜める専用の場所」を物理的に用意します。指示書（CLAUDE.md）とは必ず分けること。
2. 直近で踏んだ失敗を1件、「原因＋次の対策」の形で1行書く。 物語にしない。例：「全ファイルを git add した→別作業を巻き込んだ。次は staged を確認してから commit する」。
3. AIへの作業手順に「着手前に lessons.md を読む」を1行追加する。 書くだけで終わらせない。読むルールまで設計して、初めて記憶になります。機械判定できる教訓は、後で lint / CI に昇格させましょう。

---

この自動運用クルーの設計と月次レポートを配信中

ここで紹介した「教訓を記憶に変える」記憶設計や、指示書・教訓ログ・機械ガードの使い分け、毎月どこが壊れてどう直したかの実録は、ニュースレターで継続配信しています。AIに業務を任せる設計を自分の手で組みたい人向けの、一次情報の航海日誌です。