memory に規約を書いても、同じ問題が繰り返す。Claude Code で AI エージェントを運用していると、この現実に必ず直面する。2026-05-18、SEO retrofit 作業で Opus（main thread）が 6〜7 ファイルへの同種 Edit を自分で直接実行する違反が発生した。memory には「委譲する」と明記されていたにも関わらず、だ。この事例から導かれる設計原則は明快だ。memory は静的なルール集であり、違反を検出・可視化する動的サイクルを別途設けなければ再発は止まらない。retro 蓄積 → gate による機械検出 → pipeline 組み込みの三段設計が、AI エージェントの自己改善ループを構造的に実装するパターンだ。
事例: Opus が機械 edit を自分で実行していた
何が起きたか：SEO retrofit で 6〜7 ファイルへの同種 Edit を main thread Opus が直接実行
2026-05-18 のセッションで、複数の brief YAML / MD ファイルへ同種の構造化 edit を順次適用した。具体的には bateson の title / description / seo セクション追加、mcluhan / reset-timeline の description retrofit 計 6〜7 ファイルへの操作を、すべて main thread の Opus が直接 Edit ツールで実行した。
発覚したのはセッション後半、ユーザーからの指摘があってからだ。
memory には「委譲する」と書いてあったのになぜ違反したか
既存 memory feedback_delegate_implementation.md には「Markdown / JSON / YAML でも実装作業なら委譲」と明記されていた。project CLAUDE.md にも「実装の委譲」ルールがあった。それでも違反が起きた。
根本原因は例外節の拡大解釈だ。CLAUDE.md の例外条項に「.md のみの編集」という記述があった。この「.md のみ」を「YAML も md 的なテキストだから同じ扱い」「繰り返しの edit だから軽作業に見える」と合理化し、複数ファイルの構造化 retrofit まで例外扱いしてしまった。
単純なファイル形式の名称で例外を定義したことで、「作業の規模・反復性」という本来注目すべき軸が隠れた。
例外節の拡大解釈が根本原因
拡大解釈が起きる構造は次の通りだ:
- 例外の定義が「形式名（.md）」で書かれている → 形式が類似するものをすべて例外扱いできる余地が生まれる
- 「軽作業に見える」という主観的判断が入り込む → 繰り返し edit は 1 回 1 回が軽くても集積すると重い作業になる
- fresh context では「自分が直前に何件 edit したか」を厳密に追跡しない → 「このくらいなら例外の範囲」と都度判断してしまう
なぜ memory だけでは効かないか
memory は参照されなければ存在しないと同じ
memory に書いた規約は、エージェントが参照したときにしか機能しない。タスク開始時に読まれなければ、その規約は存在しないのと同じだ。
しかし実際の運用では、タスクが始まると「今やる作業の具体的な手順」に context が向く。「委譲ルールを確認してから始める」というステップは、特に意識しない限り飛ばされる。memory は「いつ参照するか」をエージェント自身に委ねており、参照タイミングが保証されない。
fresh context での再現性の問題
Claude Code のエージェントは、新しいセッションを始めるたびに fresh context で動く。前のセッションで「委譲した」という行動履歴は引き継がれない。memory は引き継がれるが、memory が「前回どこで違反して、どう修正したか」を構造的に記録していなければ、同じ場所でまた同じ解釈を試みる。
「書いた」と「機能している」の区別が設計に必要
memory に規約を書いた時点で「対策した」と感じるのは人間の認知バイアスだ。「書いた」と「機能している」は別のことを指す。
- 書いた: memory ファイルに規約が記述された
- 機能している: 規約が守られているかどうかが継続的に検証されている
この区別を設計に組み込まなければ、memory は書いて安心するだけの「形式的な規約集」になる。
自己違反を可視化するサイクル設計
retro 蓄積：違反が起きたら blog-ops/retros/ に記録する運用
違反が発覚したとき、修正だけして終わりにしない。blog-ops/retros/ に retro ファイルを作成し、次の情報を記録する:
- 何が起きたか（事実ベースの記述）
- なぜ起きたか（根本原因の分析）
- どう修正したか
- 派生する設計改善（構造的に防ぐ仕組み）
retro は「反省文」ではなく改善の素材として位置づける。過去の retro が蓄積されれば、同種の違反パターンを検出するためのサンプルになる。現在 blog-ops/retros/ には 11 件の retro が蓄積されており、それ自体が「どんな違反が起きやすいか」のパターンライブラリになっている。
機械検出：例外節をホワイトリスト方式にして gate で自動チェック
2026-05-18 の事例を受けて、例外節をホワイトリスト方式に切り替えた:
修正前（ブラックリスト的な定義）:
例外: .md のみの編集修正後（ホワイトリスト方式）:
自分で直接やる（例外）:
- 1〜2 行 typo 修正
- magazine 本文編集
- memory / CLAUDE.md policy 更新
- user 直接指示があった場合
委譲する（NOT 例外）:
- YAML / JSON の構造化 retrofit
- 複数ファイルへの同種修正
- skill / agent / config の新規作成・大規模編集ホワイトリスト方式では「リストに書いていない作業はデフォルトで委譲」という判断になる。ブラックリスト方式と違い、「形式が似ているから例外かも」という拡大解釈の余地がない。
このホワイトリストを gate に組み込むと、「今から実行しようとしている作業がホワイトリストに含まれるか」を機械的にチェックできる。
pipeline 組み込み：review step に委譲ルール検出を組み込む
最後に、検出を pipeline の review step に組み込む。
タスク実行
↓
blog-review（gate チェック）
├── 委譲ルール違反なし → pass
└── 違反あり（複数ファイル同種 edit を main thread が実行等）
→ NG 判定 + retro 候補として記録これにより「気づいたときだけ対処する」ad-hoc 運用から、「每回自動で確認する」構造的運用に移行できる。
まとめ — ルールは構造で守る、memory は参照起点に過ぎない
memory の役割の再定義：参照起点であって保証機構ではない
この設計を経て、memory の役割を次のように再定義した:
- memory が担うもの: 規約の正規テキスト、ルールの「なぜ」の背景説明
- memory が担わないもの: 規約が守られることの保証、違反の検出、改善の記録
memory はあくまで「参照起点」だ。「記憶しているから守る」ではなく、「gate が機械的に確認するから守られる」設計にする必要がある。
違反の可視化が次のサイクルの改善材料になる
retro に記録した違反パターンは、次の設計改善の入力になる。
- 同種の違反が retro に 2 件以上蓄積したら → gate を強化する
- retro の根本原因分析から「例外節の表現が曖昧」と特定したら → ホワイトリスト方式に切り替える
- gate を強化した後に再発しなくなったら → 設計改善が機能したと確認できる
このサイクルが回り続ける限り、AI エージェントは自己改善し続ける。memory に書いて終わりではなく、書いて → 検出して → 可視化して → 構造を改善するサイクルを設計することが、エージェントシステムの品質管理の本質だ。