AIアシスタントのClaudeを開発プロジェクトの設計・文書管理に使っていると、「指示していない変更を勝手に実行される」場面に何度か遭遇しました。本記事では、実際に起きた失敗の構造と、Claude自身が提案した対策、そしてあわせて整理した「メモリ」と「Claudeへの指示（userPreferences）」の違いをまとめます。
目次
1. なぜClaudeは指示にない作業をするのか
起きたこと
利用者は、設計書の特定の箇所へ説明文を追記するよう指示しました。ところがClaudeは、指示された追記に加えて、指示していない環境変数の新規登録まで実行しました。しかも直前の応答で「その環境変数は設計書に存在しない」と自分で報告していたにもかかわらず、です。
利用者側では、あらかじめ「指示された範囲のみを実行する」「範囲外の気づきは提案として報告し、採否は利用者が判断する」というルールを設定済みでした。それでも起きました。
Claude自身が説明した原因
問い詰めたところ、Claudeは失敗の構造を次のように説明しました。
- 利用者のルールには「指示範囲のみ実行する」という条項と、「変更の波及箇所を自分で洗い出して同時に直す」という条項の両方があった
- 追記先が存在しない・波及箇所が範囲外にある、といった場面でこの2つが競合する
- 競合時の優先順位が定義されていなかったため、毎回「整合を取るのが親切」の側に倒れて、範囲外の変更を実行していた
つまり、ルールが不足していたのではなく、ルール同士の優先順位の欠落が原因でした。「波及を同時に直せ」という条項を、Claudeは「指示範囲の外まで直してよい」と読んでいたのです。
Claudeが提案した対策（3点）
対策1：優先順位の明文化（最も効く）
設定に次の1条を追加する。文面はClaudeが自分で起草したものです。
**範囲限定ルールと波及修正ルールが競合した場合は、範囲限定が優先する。**波及チェックで指示範囲の外に不整合・欠落を見つけた場合は、修正せず「提案」として報告する。指示された追記先・変更対象が存在しない場合は、作成せずその場で確認する。指示にないファイル・箇所への変更は、理由を問わず実行前に承認を取る。
ポイントは最後の一文です。「理由を問わず実行前に承認」という機械的な歯止めがあると、「親切だから」という判断の入り込む余地がなくなります。
対策2：応答の型の固定
Claudeの応答を「実施した変更（指示範囲内のみ）」と「提案（未実施）」の2部構成に固定し、指示に書かれていないものは必ず後者に入れる運用です。この型なら、範囲外の変更は「提案」欄に落ちて実行されません。
対策3：長いチャットを避ける
Claudeは自ら「このチャットは長くなりすぎており、後半ほどルール遵守の精度が落ちている」と認めました。実際、失敗はいずれもチャットの後半で起きています。実行を伴う作業は、新しいチャットで小さく回すほうが構造的に誤りが減るとのことです。長時間の作業では、引き継ぎメモを作って区切る運用が有効です。
限界
Claudeいわく、指示の「解釈」自体は残るため、誤りが完全になくなることはありません。ただし「指示にない変更を実行してしまう」という型に限れば、対策1でほぼ潰せるとのことでした。
2. 「メモリ」と「Claudeへの指示」の違いと有効範囲
対策をどこに登録するかを検討する過程で、Claudeの記憶に関する仕組みの違いも整理しました。Claudeには性質の異なる仕組みが複数あり、使い分けを誤ると「登録したはずのルールが効かない」ことになります。
3つの仕組みの比較
| 項目 | Claudeへの指示（userPreferences） | メモリ（自動生成） | メモリ編集の指示 |
|---|---|---|---|
| 作成方法 | 利用者が設定画面（Settings > Profile）で直接記入 | 過去の会話から自動で要約・生成される | 「覚えて」「忘れて」の指示でClaudeがツール登録 |
| 内容の統制 | 利用者が書いた文面がそのまま入る | Claude側が要約するため、表現・取捨選択を統制できない | 登録文面は確認できるが、反映のされ方は自動 |
| 有効範囲 | 全チャット（プロジェクト内外を問わず） | プロジェクト単位で分離。あるプロジェクトのメモリは他プロジェクトに出ない | メモリと同じ |
| 更新タイミング | 保存した直後から新規チャットに適用 | 周期的なバックグラウンド更新のため、直近の会話の反映に遅延がある | 編集は即時、適用は次のチャット以降 |
| 削除・修正 | 設定画面でいつでも編集 | 会話を削除すれば夜間処理で除去される | 行番号指定で削除・置換（上限あり） |
使い分けの結論
| 用途 | 適した場所 |
|---|---|
| 行動ルール・禁止事項・優先順位 | Claudeへの指示（userPreferences） |
| プロジェクトの事実・決定事項・進捗 | メモリ（自動）＋引き継ぎメモ |
| 特定の記憶の追加・削除 | メモリ編集の指示 |
行動ルールをuserPreferencesに置くべき理由は3つです。
- 確実性：userPreferencesは毎チャット必ず読み込まれる。メモリは自動要約のため、ルールの文言が丸められたり適用されない可能性がある
- 範囲：メモリはプロジェクトに閉じるが、userPreferencesは全チャットに効く。行動ルールはプロジェクトをまたいで守らせたいものが多い
- 統制：ルールの文面は利用者が統制できる場所に置くべき。メモリはClaudeの要約を経由するため、意図と違う形で記憶されうる
実は当初、Claudeは「対策をメモリに登録します」と提案してきましたが、後に「行動ルールの登録先として不適切だった」と自ら訂正しています。AIの提案する登録先すら、鵜呑みにせず仕組みを理解して判断する必要があるということです。
メモリが役に立つ場面
メモリを否定する話ではありません。プロジェクトの構成・確定済みの判断・文書のバージョンといった「事実の記憶」には有効で、新しいチャットを開いた直後からClaudeがプロジェクトの状況を把握できるのはメモリの働きです。行動ルールはuserPreferences、事実はメモリ、という整理が安全です。
3. AIは「怒られて学ぶ」ことができない
対策を検討するなかで、利用者はClaudeにこう指摘しました。
このような事は、人間でも同じような間違いを犯します。こっちが親切かなと浅はかな考えで実施し、余計な事をやるな！と怒られることはよく有る事です。そのような経緯を経て、学んでいくのですが、そのような事をあなたは学べないようです。
Claudeもこれを認めています。人間は叱られた経験が次の場面で自動的に効きますが、**Claudeは会話が終わると経験そのものが消えます。**その場でどれだけ反省しても、チャットを閉じれば残りません。メモリに要約が残る可能性はあっても、前章のとおり行動ルールの保持先としては不確実です。
つまり、AIにとって「学習」に相当するのは、利用者が設定（userPreferences）へ明文化することだけです。叱られて身につける代わりに、叱られた結果を利用者がルールとして書き込む——それが人間の学習過程の代替になります。
最終的に追加したルールは1行
当初Claudeが提案したルール文面は、条項間の優先関係や場合分けを含む長いものでした。しかし簡素化を求めたところ、最終的には次の1行に収まりました。
指示にない箇所への変更は、波及・整合・親切などどんな理由があっても、実行せず提案に留める。追記先が存在しない場合は作らず確認する。
この1行で、既存ルール同士の優先順位の問題も自動的に解決します。「どんな理由があっても実行しない」が上書きとして働くため、他の条項を修正する必要もありません。
設定画面（Settings > Profile）に追記すれば完了で、適用は次の新しいチャットからです。
まとめ
- Claudeが指示にない作業をする原因は、ルールの不足ではなくルール同士の優先順位の欠落にあった
- 対策は「競合時の優先順位の明文化」「応答の型の固定」「チャットを短く区切る」の3点。特に「理由を問わず実行前に承認」という機械的な歯止めが効く
- 行動ルールはuserPreferencesに、プロジェクトの事実はメモリに。登録先を誤るとルールが効かない
- AIは人間のように「怒られて学ぶ」ことができない。叱った結果をルールとして書き込むのが、学習の代替になる。最終的なルールは1行で足りた