Claude Codeに「もう使っていない」と口頭で伝えただけでは、memory/ やルールファイルは更新されない。この記事では、更新漏れのファイルが複数箇所で整合したまま残り続けた事例と、「整合している文書が多いほどAIが疑いにくくなる」という構造的な問題について書く。
あるとき、AIに「Coworkはもう使っていない」と伝えた。更新された、と思っていた。
2026年4月29日、私がその思い込みに気づいたのは、AIが何週間も後に「Coworkセッションから」という言葉を使ってきたときだった。しかしシグナルはもっと前から出ていた。気づいていたのに、流し続けていたのだ。
この記事では「伝えた ≠ 更新された」という構造と、「整合している文書が多いほど疑いにくくなる」という逆説について書く。
Claude Codeは「伝えた」だけでは記憶ファイルを更新しない
Claudeに何かを伝えたとき、人間はしばしば「更新が完了した」と感じる。会話をしたのだから、相手には伝わったはず——そこまでは正しい。しかしClaudeの動作は、会話文脈だけでなく、セッションをまたいで参照される記憶ファイルやルール文書にも支えられている。
私はCoworkの利用をやめたとき、その旨をClaudeに伝えた。しかし実際には3つのファイルがCoworkを前提にしたまま残っていた：
-
memory/project_cowork_operation.md— 「現在もCoworkと併用している」という記述 -
global-rules.md— 「Coworkセッションからネタを採掘する際は〜に従う」というルール -
content/writing/books/series-2/2026-04-26_concept.md—[cowork-session]タグの説明文
Claudeは嘘をついていたわけではない。参照しているファイルに書いてあることを、忠実に守っていただけだ。問題は、私がそのファイルを更新していなかったことにある。
Claude Codeが古い言葉を使い続けた——記憶ファイルの更新漏れが原因だった
発覚前、Claudeが「Cowork」という言葉を使う場面が何度かあった。そのたびに私は「あ、そうか」と思いながら、次の話題に流れていった。
あるときはZenn Book 2冊目のネタ帳を整理するセッションで、Claudeが「Coworkセッションから採掘する」という前提で提案を組み立ててきた。私はCoworkをやめていたのだから、その提案の前提はそもそも成立していない。別の場面では、global-rules.md のルールがCowork利用を前提にしたまま適用され続けていた。
立ち止まらなかった理由は単純だ。**「まあ、文脈はわかってくれているだろう」**という油断だった。
思えば、このシグナルは非常に低コストで処理できるはずだった。Claudeが古い言葉を使ったとき、「それはもう使っていない。どのファイルに記載がある？」と一言聞けばよかった。最初の一回で止まっていれば、問題はそこで終わっていた。
実際に問題が発覚したのは、別の作業をしている途中に「Coworkセッション」というタグの記述にたまたま目が留まったときだった。「あれ、これもう使っていないはずでは」と思って調査してみると、3か所のファイルが整合していたことが判明した。
なぜClaude Codeは誤りを疑わないのか——整合した記憶ファイルの罠
この問題には2つの層がある。
第1層: 人間の思い込み
「伝えた→更新された」という前提が自動的に成立してしまう。どのファイルが更新されたか、私は確認していなかった。会話によって伝達は完了したが、ファイルの更新は別の話だ——この区別を意識していなかった。
第2層: AIの整合バイアス
1か所だけ古い記述が残っていれば、「古い情報かもしれない」と疑うきっかけになりうる。しかし今回は3か所が同じ方向に整合していた。
Claudeにとってこれは事実の裏付けに見える。複数の文書が同じことを言っているのだから、それが現実だという認識になる。**整合している文書が多いほど、AIはその前提を疑いにくくなる。**これは一見反直感的だが、考えてみれば当然の話だ。証拠が積み重なるほど確信は高まる——たとえその証拠がすべて誤っていても。
この問題が起きやすいのは、セッションをまたいで参照され続けるファイルだ。memory/ 配下のプロジェクト状況メモ、CLAUDE.md の運用ルール、global-rules.md などがその代表格で、一度書いた記述が長期間そのまま残りやすい。「やめた」「変えた」タイミングで、こうした永続参照ファイルを意識的に確認する習慣が有効だ。
| 状況 | AIの反応 |
|---|---|
| 1か所に古い記述 | 「古い情報の可能性あり」と判断しやすい |
| 3か所が整合した古い記述 | 「これが現実」として受け入れる |
memoryファイルの更新漏れを「流した」場合と「止めた」場合
以前、別の記事で「AIが品質ゲートをスキップした」という事例を書いた。あのとき私は「妙に早い」という違和感を持って、「あれ？テスト実施した？」と一言確認した。それだけで問題を早期に発見できた。
今回との構造的な違いは単純だ。
| 品質ゲートスキップの事例 | 今回の事例 | |
|---|---|---|
| シグナル | 「妙に早い」という時間感覚 | 「Cowork」という言葉 |
| 人間の反応 | 気づいた → 止めた | 流した → 思い込みが育った |
| 結果 | 問題を早期発見 | 思い込みが3か所に定着 |
どちらの事例も、シグナル自体は出ていた。違いは「最初の一回で止まったかどうか」だけだ。
（品質ゲートスキップの事例については別途記録している（近日公開予定）。本記事はその対になる事例として読んでもらえると、構造がより鮮明になる。）
CLAUDE.mdと記憶ファイルの更新漏れを防ぐ3ステップ
この経験から、私は一つのルールを設けた。
AIが「使っていないはずの言葉」を使ったとき、それは更新漏れのシグナルとして処理する。
具体的な対処は単純だ：
- 「それはもう使っていない。どのファイルに記載がある？」と聞く
- 該当ファイルをリストアップしてもらう
- 不要な記述を削除または更新する
この確認に必要なのは30秒程度だ。問題を放置すると、整合したまま誤った記述が蓄積されていく。一方で最初に止まれば、それだけで終わる。
もう少し構造的にアプローチするなら、「何かをやめた」「ツールを変えた」「方針を変えた」というタイミングで、関連ファイルを一緒に更新する習慣を持つとよい。変更を「口頭で伝えた」だけで終わらせず、「どのファイルが影響を受けるか」を確認するワンステップを挟む。
「伝えた」だけでは更新されない——文書管理の責任は人間にある
この問題の核心は「AIが嘘をついた」ではない。「人間が更新しなかったファイルをAIが忠実に守り続けた」だ。
AIは文書に書かれていることを前提に動く。その文書を正しく保つ責任は、人間の側にある。そして整合している文書が多いほど誤りを疑いにくくなるという構造上、古い記述の放置は静かに増殖する。
シグナルは出ていた。最初の一回で止まれば済んだ。
この記録が、同じ流し方をしている人の「一回止まる」きっかけになれば十分だ。
関連：Zenn Book シリーズ
本記事で触れた「ルール管理」「エージェント組織の運用」について、より詳しく書いたZenn Bookシリーズがあります。
- コードを書けない私がClaude Codeで「AIチーム」を作るまで（Vol.1）
- コードを書けない私がClaude Codeで「AIチーム」を回すまで（Vol.2）
- コードを書けない私がClaude Codeで「AIチーム」と書き続けるまで（Vol.3）
関連書籍
Claude Codeの実践的な使い方をさらに深めたい方には、以下のKindle本が参考になります。
Claude CodeによるAI駆動開発入門（平川知秀 著） — Claude Codeを使ったAI駆動開発の全体像を解説した入門書。memoryファイルやCLAUDE.mdの位置づけを理解する文脈でも読みやすい。
この記事は はてなブログ からのクロスポストです。