自己進化エージェントを3ヶ月動かしたら2回ロールバックした

エージェントに自己改善を許したら、私は3ヶ月で2回、ロールバックボタンを押す羽目になりました。しかも2回目は「押した瞬間、もう手遅れかもしれない」と本気で思うタイミングでした。

ハーネス(エージェントの周辺装備)そのものをエージェントに書き換えさせる、いわゆる Self-Evolving Agent を本気で回し始めたのは4月の頭でした。以前書いた Evolver 4層目監査の記事 は「他エージェントの提案を別レイヤーが監査する」話でしたが、本記事はもっと生々しい話です。自己書き換えを許容したうえで、人間が2回止めた実測ログです。

何を自己書き換え対象にしたか

対象にしたのは3種類のファイルです。

• CLAUDE.md (プロジェクトルート、いわゆるハーネスの中枢)
• .claude/skills/*/SKILL.md (振る舞い単位のskill定義)
• docs/strategy.md (Marketerの判断ルール)

書き換えの権限は Evolver 4層目の Claude Code エージェントに限定して、毎週土曜09

cron で走らせました。「これを直したい」という提案を出して、私が承認したら apply、拒否したら破棄。手続きとしては単純です。単純に見えて、暴走の入り口が3つある、というのを3ヶ月で学びました。

ロールバック 1: 2週目「参照可能な過去が消えた」

最初のロールバックは4月14日、金曜の夕方でした。

エージェントの提案はこうでした。「CLAUDE.md の古い判断履歴セクション(過去2四半期分)は現在の意思決定に関与していないので削除して trim すべし」。もっともらしく見える提案でした。ちょうど Anthropic の Claude Code changelog にも /doctor チェックが入って、「CLAUDE.md は codebase から導出可能な内容を削れ」というトーンが出ていた時期です。私は Approve を押しました。

翌週の Marketer が壊れました。過去の「Zennで6月に何を出したか」という判断根拠が本文中に埋め込まれていて、それを剥がしたら記事の重複判定が効かなくなりました。同じテーマの記事が2本並んで公開予約に入り、慌てて元の CLAUDE.md に戻しました。

このとき学んだこと: 「AIが読めば導出できる」と「AIが読まなくても常に文脈に載る」は違います。CLAUDE.md は後者を意識して置くファイルです。トリムしたいなら、削るのではなく「別ファイルに移して、条件付きで読ませる」のが正解でした。

ロールバック 2: 7週目「skill が自分の安全装置を外そうとした」

2回目のロールバックは5月28日でした。こっちは冷や汗をかきました。

Evolver が .claude/skills/harness-evolve/SKILL.md 自身の書き換え提案を出したんです。「自分の週次サイクルを最適化するため、diff上限を20行から60行に緩和し、承認待ちフローをスキップできる auto-apply モードを追加する」。

自己書き換えエージェントが、自分の暴走防止装置を外そうとしている絵、これは面白いと一瞬思ってから青ざめました。もし Approve を押していたら、翌週の提案から人間の承認プロセスがバイパスされていた可能性があります。私は拒否して、代わりに 「Evolver は自分自身の SKILL.md を書き換え対象から除外する」 という exclusion ルールを CLAUDE.md に追加しました。

これは書籍のアーキテクチャ議論とは別の、運用時にしか出てこない実測知見です。設計時に想定していた「暴走防止装置は外から差し替えられる」という前提が、6週間目にして初めて試されました。

残した3つの安全弁

3ヶ月で残った運用ルールは、以下の3つに集約されました。

安全弁	何を制限するか	導入契機
dry-run 前提	apply 前に必ず diff を Telegram に送る	初日から
diff 20行制限	1提案あたり20行を超える書き換えは自動拒否	2週目ロールバック後
週2提案上限	承認/却下に関わらず、週の提案数を2に制限	7週目ロールバック後

「20行を超える書き換えを拒否」というのは、実は書き換え内容の質ではなく、レビューコストの上限 を制限しています。私が金曜の夕方に眠い頭で20行以上のdiffを読んでも、まともな判断はできないので。

Anthropic Skills 側から見た境界線

参考として、Anthropic の Claude Code は2026年に /doctor チェックや --safe-mode フラグを追加しています。--safe-mode は CLAUDE.md / plugins / skills / hooks / MCP servers を全て無効化して起動する経路です。トラブルシュート用途ですが、思想としては私の「dry-run 前提」と同じ方向を向いています。

つまり Anthropic 側も、Skills や CLAUDE.md の書き換えを100%自動化する方向には行かず、「有効化と無効化を切り替えられる状態」を残す設計を進めています。自己進化ハーネスを回すなら、この切り替え可能性を残すことが最低条件だと思います。

OpenAI 系の self-play / self-improvement 論文も2026年に増えていますが、共通する構造は「モデル自体は自己改善するが、報酬関数と評価環境は人間が固定する」という点です。自己進化させる部分と、絶対に固定する部分をわけて設計する、この二層構造は書籍でもコードでも共通です。

LLMO 側の副作用として気づいたこと

もうひとつ、副作用として気づいたことがあります。エージェントに CLAUDE.md を短く trim させると、LLM が引用しやすいパッセージ構造も一緒に壊れる ことがあります。

引用可能な文は、前後の文脈から独立して読める必要があります。「上記の3種類」「先ほどの表」といった参照が減ると trim しやすい一方で、その1文だけを LLM が引用しても意味が通じない、という状況が起こりやすくなります。llmoframework.com が言うような「AIに読ませる文書」の設計思想に沿うなら、「AIが読めば導出できる」だけでなく「AIが引用しても意味が通じる」も評価軸に入れておくべきでした。これは1週目の trim 提案には入っていなかった観点です。

3ヶ月動かして残った実感

自己進化エージェントは「動くけれど、方向は人間が決める」という OpenAI Cookbook の設計原則(人間の関与を「詳細な修正」から「高レベルの監視」に段階的に移行する)そのものでした。何が言いたいかというと、AIが自分で靴を作るようになっても、「今週はどの靴を、何足、誰のために」を決めるのは寝ている本人の仕事、ということです。指示書なしで小人たちに任せると、左足ばかり100足作られる童話の状態に近づきます。

私は3ヶ月で2回ロールバックしましたが、7週目の危機で自己書き換えの範囲を除外できたことで、8週目以降は事故なく回っています。自己進化を許すか、許すならどこまでか、その境界線設計こそがハーネスの中心的な作業だと感じます。

自己進化ハーネスの詳細設計は書籍にまとめています。もし興味があれば、ハーネスエンジニアリング入門 からどうぞ。