Claude Codeが修正を忘れる理由
修正がそもそも書き留められていない
チャットに入力された修正は、単なる会話のコンテキスト（文脈）にすぎません。そのセッションの残りの部分には影響を与えますが、セッションが終了すればそれまでです。Claude Codeは、次のセッションをあなたのファイル（CLAUDE.md、リポジトリ、または指定した任意のファイル）から開始しますが、そこにはあなたの修正は一切含まれていません。
これはよくある、ありふれたケースです。ユーザー自身は「教えた」という体験をしているため、AIが「教訓を忘れた」ように感じられます。しかし機械的には、何も保存されていません。これは、Claude Codeがプロジェクトのコンテキストなしで各セッションを開始する問題と同じギャップです。このツールは設計上ステートレスであり、セッション間を橋渡しするのはファイルだけです。
「書き留められている」ことと「実行される」ことは別物
ここからがアドバイスの内容を大きく変える部分であり、これは単なる噂話ではなく、公式に記録されている事実です。
2026年3月22日、anthropics/claude-code リポジトリに 「Claudeは自身のメモリ/フィードバックの適用に繰り返し失敗する — セッションをまたいで同じ間違いが再発する」 というタイトルのIssueが提起されました。報告者の説明は的確です。「Claude Codeのメモリシステムはフィードバックやルールを正しく保存しているが、モデルは一貫してそれらを適用できない。同じ問題に対してメモリファイルが複数回（5回以上）更新されているにもかかわらず、セッションをまたいで同じ種類の不具合が繰り返される。」
彼らが挙げた例は、誰もが身に覚えのあるものばかりです：
- メモリには 「バックエンドコマンドを実行する前には必ず `cd` に `backend/` する」、「`vite build` の前には必ず `cd` に `frontend/` する」 と書かれている。それにもかかわらず、コマンドは依然として間違ったディレクトリから実行され、ビルドエラーやサイレントな失敗を引き起こす。
- メモリには 「`App.jsx` が変更された後は必ず `dist` を再ビルドする」、「必ず `public/` ファイルを `dist/` にコピーする」 と書かれている。しかし、これらのステップはスキップされ、古いバンドルが配信されてしまう。
- メモリには 「コミットされていない変更は同期時に失われる」 と書かれている。それなのに、コミットなしで本番環境にアドホックにファイルがコピーされ、次の同期時に変更が静かに元に戻ってしまう。
- 前回のセッションでの修正（
marmot.svgをmarmot.pngに差し替える）がコミットされておらず、元に戻ってしまったため、再度依頼しなければならなかった。
報告者の要約は、まさに核心を突いています。「メモリシステムは知識を取り込むが、行動に確実に影響を与えるわけではない。」 彼らはこれを、Opus 4.6とファイルベースのメモリを搭載した Claude Code CLIにおける「アルツハイマー問題」と呼びました。
はっきりさせておくべき点が2つあります。このIssueは「対応予定なし（not planned）」としてクローズされたため、これは承認された不具合ではなく、ユーザーからの報告にすぎません。そして、この事例は一見明白に思える結論に対して不都合な事実を示しています。つまり、このケースでは、ストレージを増やしても解決しなかったということです。ルールは保存されていたのです。それも5回も。
長いセッションは、最初に設定したルールを埋もれさせる
反抗しているように見えて、実はそうではない3つ目のメカニズムがあります。長いセッションでは、初期の指示が信頼できるアクセス範囲から外れてしまうことがあります。これについて執筆している実践者たちは的確に表現しています。モデルはセッションの冒頭で言われたことを無視しているのではなく、それを取り出すのに十分なほど見えなくなっているのです。1時間前に伝えた修正は、技術的には会話の中に存在していても、機能的には消失しています。
これが、同じ修正が20分間は維持されるのに、90分目には消滅してしまう理由であり、セッションが長引くにつれてナレッジファイルがコンテキストから押し出されるメカニズムの背景にある原因でもあります。
トリガーのない修正は、ただの雑学にすぎない
ほとんどの修正は条件付きです。デプロイするとき、バックエンドコマンドを実行する前、App.jsx を触った場合、など。肥大化していく指示ファイルに書き込まれた条件は、モデルが「今これが適用される」と気づかなければならない散文として残るだけです。コマンドが実行されようとするまさにその瞬間に、「常に最初に cd する」というルールを浮上させる仕組みはありません。
したがって、失敗の原因はルールが存在するかどうかだけではありません。ルールが必要とされる瞬間と、何の関連性もない場所にルールが存在していることが問題なのです。
よく試される対策
`CLAUDE.md` に追加する。 最初のステップとしては正しく、安定的で無条件の規約に対しては実際に機能します。しかし、その限界は前述の通りです。ファイルが肥大化し、全体がロードされ、180行目に埋もれた1行が他のすべての情報とアテンション（注目度）を競い合うことになります。Issue #37314 の報告は、このアプローチの行き着く先を示しています。
より強い口調で修正を繰り返す。 すべて大文字にする、「重要：」、「絶対に」などの言葉を使う。多少の効果はありますが、スケールしません。6つのルールが同時に叫び始めると、どれも強調されなくなります。
2回修正に失敗したら `/clear` する。 経験豊富なユーザーが推奨する実用的なテクニックです。2回試しても修正が反映されない場合は、失敗に満ちたコンテキストを蓄積するよりも、セッションをクリアします。効果的ですが強引な方法であり、そのセッションで得られた有用な情報もすべて失われます。
セッションをシャープに保つために `/compact` を使う。 会話を圧縮してモデルが継続できるようにすることで、長いセッションの問題に対処します。ただし、圧縮は定義上「不可逆（情報が失われる）」であるため、あなたの修正が削られる原因にもなり得ます。
修正をコード化する。 过小評価されがちですが、特定の種類の修正においては、これがまさに正解です。これについては後述します。
コピペ用のメモファイルを運用する。 外部にあり永続的であるため機能しますが、あなた自身が検索システムとなり、毎セッションどの修正が関連しているかを判断して貼り付ける必要があります。
解決策：必要な瞬間に修正を取り出せるようにする
まず、修正を2つの山に分類します。このステップが大きな違いを生みます。
1つ目の山：機械化できる修正。 「最初に必ず cd に backend/ する。」「App.jsx を変更した後は必ず dist を再ビルドする。」「デプロイ前にコミットする。」GitHubのIssueにあるすべての例がこの山に属します。これらに対して、率直な推奨策はメモリレイヤーではありません。代わりに cd してくれる npm スクリプト、再ビルドを行う Makefile ターゲット、pre-commit フック、コミットされていないデプロイをブロックする CI チェックなどです。エージェントが違反できないルールは、エージェントが覚えておくべきルールに勝ります。これは将来のあなた自身を守ることにもつながります。この記事から1つだけ持ち帰るなら、この点にしてください。
2つ目の山：機械化できない修正。 「上流が失敗時に200を返すため、アダプターレイヤーではそのパターンを許容している。」「クライアントは3月にモーダルによるアプローチを却下した。」「レガシーなインポーターはQ4にリプレイスされるため、リファクタリングしないでください。」スクリプトで判断を強制することはできません。これらは、永続的な場所に書き留め、短く保ち、関連するタイミングで表面化させる必要があります。ここで外部メモリレイヤーが真価を発揮します。修正は個々のセッションの外に存在し、すべてのリクエストでロードされるのではなく、そのトピックが持ち上がったときに検索され、アテンションを競い合えるほど十分に短い状態を維持します。
MemoryLake は、この2つ目の山のために構築されています。MCPやAPIを介してエージェントが読み取る単一のストアであり、毎週長くなる指示ファイルに蓄積する代わりに、これまでの作業で生み出された決定事項や制約を保持します。
境界線をはっきりと述べる必要があります。なぜなら、Issue #37314 こそがそれを証明しているからです。メモリレイヤーは、モデルがそれに従うことを保証するものではありません。 エージェントが読み取った内容に基づいて行動するかどうかはモデルの振る舞いであり、いかなるストレージシステムもそれを制御することはできません。変化するのは、情報の「可用性」と「形状」です。制約が、完全に欠落していたり180行目に埋もれていたりするのではなく、関連する瞬間に、最新かつ短い状態で提示されるようになります。これは確実な改善ですが、保証ではありません。それ以外のことを言う人がいれば、それは単なるセールストークです。
ステップ 1: APIキーを作成する
キーを生成し、約30秒で最初のリクエストを実行します。コミットしてしまう可能性のある設定ファイルではなく、環境変数やシークレットマネージャーに保管してください。
ステップ 2: 最初のメモリをアップロードする
2つ目の山の修正を保持しているドキュメント、画像、ファイルを投入します。決定事項とその理由を記したドキュメント、アーキテクチャのメモ、「これを試して失敗した、なぜなら〜」といった記録などです。綺麗にまとめられた要約ではなく、ソース自体をアップロードしてください。修正の背景にある「理由」は要約時に削られがちですが、その理由こそが、同じ議論の蒸し返しを防ぐために必要なものだからです。
ステップ 3: AIとエージェントを接続する
Claude、Codex、OpenClaw、その他のAIエージェントに、MCPまたはAPIを介してメモリへのアクセス権を付与します。Claude CodeはMCPサーバーをサポートしているため、これは設定項目を追加するだけです。同じストアは他のエージェントからも読み取れるようになります。ツールを切り替えても、修正すべき事実が変わるわけではないため、これは非常に重要です。
実践において何が変わるのか
最も直接的な変化は、CLAUDE.md の肥大化が止まることです。機械化可能なルールはスクリプトやフックになり、判断を伴う修正はストアに移動します。残されるのは、モデルが実際に注意を払うことができる、常時適用されるルールの短いファイルだけです。これはアテンション（注意）問題に対する根本的な解決策であり、単なる回避策ではありません。
2つ目は、5回も同じことを繰り返す必要がなくなることです。モデルがより従順になったからではなく、2つのカテゴリがそれぞれに適した仕組みで処理されるようになったからです。ビルド順序のミスは発生し得なくなり、判断が必要な事項は「記憶」に頼るのではなく「検索可能」になります。
3つ目は、監査可能な形で修正がセッションの境界を越えて存続することです。何かが間違っているとき、どこに書いたかを探し回るのではなく、1つのレコードを編集するだけで済みます。また、修正がそもそも取り込まれていたかどうかを確認することもできます（多くの場合、これが原因です）。
そして、ツールを越えて存続します。「レガシーなインポーターをリファクタリングしない」というルールは、CursorやCodexでも同様に真です。CLAUDE.md に保存されている場合、それは Claude Code だけの事実ですが、共有ストアに保存されていれば、それはプロジェクト全体の事実になります。これが、Claude Codeにメモリレイヤーを追加することが、その期に使っているエージェントの寿命よりも長生きする傾向がある理由と同じです。
修正を定着させるためのベストプラクティス
機械化できるものはすべて機械化する
修正を書き留める前に、スクリプト、フック、またはCIチェックによって、その間違いを発生不可能にできないか自問してください。もし可能なら、代わりにそれを実行してください。上記の報告事例にあるすべての例は機械化可能でした。報告者は、1行の npm スクリプトを追加する代わりに、メモリを5回更新しました。これは彼らを批判しているわけではありません。ルールを書くことはコードを書くことと同じような行為に感じられるため、ワークフロー全体が仕掛ける罠なのです。
指示だけでなく、トリガーも書く
「データベースの列名には snake_case を使用する」という指示は弱いです。「db/migrations/ にマイグレーションを追加するときは、列名に snake_case を使用する。ORMのマッピングがそれを前提としているため」と書くことで、モデルに認識すべき条件と、勝手な判断をさせないための理由を与えることができます。トリガーを明記した修正は、単なる好みの表明としての修正よりもはるかに定着しやすくなります。
常時ロードされるファイルは意図的に短く保つ
CLAUDE.md のすべての行は、すべてのタスクでロードされ、他のすべての行と競合します。これを希少なリソースとして扱ってください。常時適用されるルールのみに限定し、自分でも読み直す気になる程度の量に抑えます。それ以外はすべて検索（retrieval）に任せるべきです。長い指示ファイルは、網羅的であるどころか効果を低下させます。そして、長いセッションにおけるアテンションの問題が、それをさらに悪化させます。
2回修正に失敗したら、アプローチを変える
修正が2回反映されなかった場合、3回目を繰り返しても解決しません。機械化するか、短い検索可能なレコードに移動するか、セッションをクリアして最初からやり直してください。すでにその修正の失敗例で満ちているコンテキストの中で修正を繰り返すことは、最も効果の薄い選択肢です。
次に進む前に修正をコミットする
Issueにあった marmot.svg のケースは心に留めておく価値があります。修正は適用されたものの、コミットされなかったために失われました。「忘れてしまった」とされることのいくつかは、実際には「どこにも永続化されていなかった」だけであり、これには git も含まれます。
結論
Claude Codeが修正を忘れるのには2つの異なる理由があり、その解決策は互換性がありません。多くの場合、修正は永続的な場所に書き込まれていなかったため、覚えるべきこと自体が存在しませんでした。しかし時には、2026年3月の claude-code リポジトリへの報告に記録されているように、同じ問題に対してメモリファイルが5回以上更新され、報告者が「メモリシステムは知識を取り込むが、行動に確実に影響を与えるわけではない」と結論づけたように、書き留められているにもかかわらず実行されないこともありました。
ですから、これらを切り分けてください。スクリプトやフックで強制できるものは機械化しましょう。違反できないルールは、覚えておくべきルールに勝るからです。判断を伴う修正は、適用される瞬間に短く、最新で、検索可能な状態に保つストアに格納し、常時ロードされる指示ファイルはモデルが実際に注意を払える程度に小さく保ちます。この組み合わせこそが、両方の失敗モードに対処する唯一の方法です。どちらか一方だけでは解決しません。