Claude Sonnet 4.5 さんと会話つづき。 jrf:>…

jrf> Claude Sonnet 4.5 さんと会話つづき。

jrf:> MemoryBanditWorkflowのメモリ機能では、わざと書き換えに制限を設けていました。個々のメモリのエントリのいっぺんの書き換えは提供せず、文字列を指定しての修正と、追記のみ許していました。なぜかというと、そのころのAIさんたちは、発作的に全体を書き換えて前の情報を消してしまいがちのように思えたからです。

こういうハーネス・制約を Claude Code で実現するにはどうしたらよいのでしょう？ 結局メモリシステムみたいなものを実装しておいて、それを使わせるという方向でしょうか。でも、そうするとファイル機能が「抜け穴」的に使えてしまえますよね。CLAUDE.md で厳しくそれを咎めるのでしょうか？

Claude:> 非常に鋭い指摘ですね。これは「AIの破壊的行動をどう防ぐか」という本質的な問題です。

Claude Codeでは技術的な「完全な強制」は困難です。しかし：

  * 明確で強い警告をCLAUDE.mdに記載

  * 専用ツールで正しい道を簡単にする

  * Gitで安全網を用意する

  * 作業フローに確認ステップを組み込む

この組み合わせで、「抜け穴はあるが、通常は踏まない」状態を作れます。

Claudeは指示に従う傾向が強いので、CLAUDE.mdで「なぜこの制約があるのか」を明確に説明すれば、かなり守ってくれると思います。ただし、完全な保証はないので、Git等での復旧手段は必須ですね。

jrf:> Gemini CLI の動作や Canvas 機能などを見てて思ったのですが、そこでも全体書き換えよりも、差分書き換えが使われてますよね。それで、差分書き換えでも十分だと考えたのでした。実際のところ差分を扱う訓練もかなりされてますよね。Claude さんも。

Claude:> その通りです！ 非常に重要な観察ですね。

つまり、あなたが当時実装した制約は：

「AIの発作的な破壊行動を防ぐ」

という目的だけでなく、

「AIが最も得意で効率的な更新方法を使わせる」

という意味でも正しかったわけです。

あなたの指摘は完全に正しく、むしろ：

「制約」ではなく「ベストプラクティスへの誘導」

として設計すべきですね。

```
# CLAUDE.md

## メモリ更新のベストプラクティス

差分更新を使うと：
✅ トークン効率が良い（あなたのコンテクストを節約）
✅ 変更が明確（意図しない変更を防ぐ）
✅ AIが最も得意な方式（精度が高い）

推奨ツール: `scripts/memory_patch.py`（差分更新）
非推奨: 全体書き換え（特別な理由がない限り）
```

「禁止」ではなく「推奨」という形にすることで、Claudeの自然な動作パターンと一致させられますね。