同じミスをしないAIを作る具体的な方法。『失敗ログ』を渡す記憶設計
AIに同じ説明を何度もしている人へ。
昨日の記事で、俺は「AIが昨日のことを覚えていないのは、記憶の置き場を用意していないからだ」と書いた。
今日は、その続きで実装の話をする。
やったことはAIに人格を与えたわけでも、巨大な記憶DBを作ったわけでもない。Claude Codeには CLAUDE.md、Codexには AGENTS.md、共通の作業には記事制作ルール、失敗ログ、公開済み記事ログを分けて置いた。作業前にそれを読ませるようにした。
それだけで変わった。
サムネの方針を忘れる。H2の直下に画像を入れ忘れる。noteで崩れるMarkdownテーブルをそのまま貼る。こういう「前にもやったミス」を、次の作業で先回りして避けるようになった。
AIを賢くしたというより、AIが参照できる“昨日の失敗”を用意した。
この記事は、無料パートで「どういう構造で渡しているか」まで、メンシ限定パートで 俺が実際に見せているMDの抜粋と、そのまま使える型 まで出す。
先に読むとつながる関連記事も確認した。概念編は 昨日の記事、ルールMDの話は くすmdが、もうあった、AIごとの役割分担は 局どれに課金すべき? が近い。
この記事でわかること
✅ 「失敗ログを渡す」だけでAIが同じミスをしにくくなった3つの実例
✅ 設定 (ルール) と記憶 (失敗ログ) は完全に別物だという話
✅ AIに渡す情報を「3層」に分けると判断が安定する理由
✅ 実際にAIへ読ませているMDの地図
✅ 🔒メンシ: 自分のAI用MD / AGENTS.md / memory / rules 抜粋とコピー用テンプレ
🧠 昨日の続き、実装に降りた話

昨日の記事ではこう書いた。
「設定」は全部静的なルールブックだ。「昨日何をやったか」「どんな判断をしたか」「どこで詰まったか」は書けない。 ── ルールブックと、昨日の経緯は別物だ。
これを書いた瞬間、社内で質問が来た。
「概念は分かったのでみせてほしいです」
みんな「考え方」までは納得する。でも「実装」が分からない。
概念と実装の間に、ちゃんと橋を架けないと、AIは賢くならない。
俺自身、この橋を架けるのに3ヶ月かかった。最初は「AI用の設定ファイルに方針を全部書けば解決する」と思っていた。書いた。AIはルール通りにはなった。でも、賢くはならなかった。
そこで気づいたのが「失敗ログを渡す」という発想だった。
🔥 失敗ログを渡したら、AIが同じミスをしなくなった3つの実例

実装側の肌感として、最も劇的な変化が起きたのはこの3つの場面だ。
例1: タイトル候補が、毎回同じパターンで詰まる問題
note記事のタイトル案を毎日AIに出させていた。主にClaude Codeで試していたが、ChatGPTでもCodexでも同じ傾向があった。最初の1週間、出てくる案はだいたいこういうのだった。
「AIで〇〇する5つの方法」「ChatGPTを最大限活用するコツ」
平凡。クリックされない。何度「もっと刺すように」と指示しても、似たような提案に戻る。
そこで、俺が 「ボツにしたタイトル30本と、その理由」 を memory/title-rejection-log.md というファイルに書いてAIに渡した。
- 「AIで稼ぐ5つの方法」 → 量産型、平均的、刺さらない
- 「ChatGPTを最大活用」 → 抽象的、現場感ゼロ
- 「AIで月10万」 → 数字は良いが文脈が薄い
...
翌日、出てきたのはこういう案だった。
「ChatGPTに5,000円燃やした俺が、二度とやらないこと」
同じ方向に戻らなくなった。「これはダメ」という負のサンプル30個を渡しただけで、思考の方向が変わった。
AIは「正解」を渡されても伸びない。「不正解の集合」を渡されると伸びる。
例2: 設計判断が、3ヶ月前の自分と矛盾しなくなった
俺はnote-pipelineというツールを作っている。3ヶ月前に「サムネはBEFORE/AFTER形式で統一」と決めた。
ところが、別の記事のサムネをAIに依頼すると、しれっと「タイトルだけドーン」のサムネを提案してくる。過去の自分の判断と矛盾するのに、AIはそれに気づかない。
そこで memory/design-decisions.md に 「いつ・なぜ・何を決めたか」 をログとして残した。
2026-04-26: サムネはBEFORE/AFTER形式に統一
理由: 単発の「文字ドーン」だと記事ごとにブランドが分散する。
左モノクロ→右カラーで「読む前後の変化」が伝わる。
適用範囲: 全note記事
これを渡した翌日から、AIは「あなたが2026-04-26に決めた通りBEFORE/AFTER形式で行きますか?」と聞いてくる。
「過去の自分との会話」をAIが代行してくれるようになった。これは1人で仕事してる人間にとって、大きな武器だ。
例3: 同じ失敗を二度と提案しなくなった
これが一番効いた。
過去にAIから提案されて、自分で試して失敗したパターンを memory/anti-patterns.md に書いた。
- ❌「マークダウンテーブルをそのままnoteに貼る」
→ noteはテーブル記法サポートが弱い、崩れる、必ずPNG画像化する
- ❌「blockquoteの中にbullet listを入れる」
→ noteのProseMirrorパーサが空行で blockquote を終了させる、必ず外に出す
これを渡した瞬間、AIは 二度とこのパターンを提案しなくなった。「失敗ログは負のサンプル」ではなく、「禁止カード」として扱われるようになった。
「できること」より「やってはいけないこと」をAIに教える方が、判断は早く正確になる。
⚙️ 俺は3層に分けてAIに渡している

ここが昨日の記事で「3層で考える」と示唆した部分の、実装側の答えだ。
第1層: ルール (CLAUDE.md / rules/)
「どうあるべきか」の方針。変わりにくい、長期保存。
例:
コーディング規約
文体ルール (instkoni風など)
記事構造の標準テンプレ
これは静的ファイル。AIエージェントが起動するたびに読み込まれる。
第2層: 経緯 (memory/)
「何があったか」の履歴。毎週・毎日更新される動的情報。
例:
失敗ログ (anti-patterns)
ボツにした提案
過去の判断と理由
「今こういう状況」の現在地メモ
これが昨日の記事で言った「記憶」の正体だ。ルールではなく、経緯。
第3層: 現在のタスク (会話 / プロンプト)
その瞬間の依頼内容。揮発性、その会話だけ。
「今日はこの記事を書く」「この関数を直す」── これは記憶に残さない、その時だけの情報。
3層を分ける意味は、それぞれ更新サイクルが全く違うからだ。
更新頻度だけで見ると、こうなる。
第1層: ルール ── 月1回。文体ルール、コード規約。
第2層: 経緯 ── 日次 / 週次。失敗ログ、ボツ集。
第3層: タスク ── 都度。今日のチャット内容。
3層を1ファイルに混ぜると、必ず壊れる。だから分ける。
混ぜるとどうなるか。「文体ルール」のファイルに「昨日のチャット要約」を追記し続けると、ファイルが肥大化して、ルールが埋もれる。AIはルールを見落とす。動かない記憶設計の典型的な失敗パターンだ。
実際に俺が読ませているものは、ざっくりこの5つに分かれる。
<project-root>/CLAUDE.md
└─ Claude Codeが最初に読む、プロジェクト入口
<project-root>/AGENTS.md
└─ Codexなど別AIとも共有する、作業ルールの入口
<project-root>/docs/NOTE_ARTICLE_CREATION_MEMORY.md
└─ note記事を作るときの制作メモリ
<project-root>/memory/anti-patterns.md
└─ 同じミスを繰り返さないための失敗ログ
<project-root>/memory/published-articles.md
└─ 公開済み記事をAIが参照するためのログ
ポイントは、CLAUDE.md に全部を書かないことだ。
CLAUDE.md は入口。memory/anti-patterns.md は失敗ログ。published-articles.md は過去記事の棚卸し。役割が違う。だから分ける。
AIに渡す情報は、量より置き場所で決まる。
🎯 何を渡すべきで、何を絶対に渡してはいけないか

ここが意外と語られない。「全部渡せばいい」と思っている人ほど、AIの判断が逆に荒くなる。
✅ 渡すべきもの
失敗ログ (なぜダメだったか、文脈つき)
採用決定ログ (なぜこれを選んだか)
過去の判断と日付
個人的な制約 (体調、時間、予算)
❌ 渡してはいけないもの
単なる愚痴・感情の記録 (判断のノイズになる)
矛盾する複数の方針 (どれを優先するかが不明)
古すぎて文脈が消えた情報 (誤った前提として参照される)
個人情報・他人の情報 (倫理・法務リスク)
「失敗ログ」と「単なる愚痴」は紙一重だ。違いは、「次の判断を変える材料になるか」 で見る。
例えば「今日は疲れた」は愚痴だ。でも「今日AIエージェントでエラーが連発、原因は環境変数の設定ミス、次回は起動前にチェック」は失敗ログだ。形式は同じでも、AIが学習に使えるかが違う。
ここで実装側に降りた人ほど、情報の選別がAIの賢さを決めることに気づく。

🔒 ここからメンシ限定 ── 自分のAI用MD / rules / memory の中身
無料パートで書いた「3層構造」の概念を、俺が実際に運用している中身そのもの で見せる。コピーして、自分用に変えて、すぐ使えるレベルで出す。
ここからは、実際に自分が見せているMDの抜粋を出す。全文をそのまま出すと長すぎるので、動き方が分かる部分だけ に絞る。自分の環境に移すなら、この形で十分スタートできる。
GPTとOpus4.6に記事の価値を辛口レビューをしてもらった


具体的なコードですか…。今度ZIP配布などで対応考えてみます‼
まずnoteのパイプラインを作っているのを例にあげてるのも価値提供としてどうなのかと…。どんなものが欲しいのかコメントくださると助かります!
📎 付録0: 自分の構成
この記事が気に入ったらチップで応援してみませんか?
