Agentic Evolution Engine と playbook 進化

SOUL.md は読み取り専用のペルソナ層になり、実際に学習・蓄積し、1 件ずつ淘汰できるのは行動ルール集（playbook）です。

一言でいうと

以前は、エージェントが教訓を学ぶと、LLM に自分のペルソナファイル SOUL.md を丸ごと書き換えさせていました。DuDuClaw 1.53 以降、SOUL.md はエージェントにとって読み取り専用です（変更できるのはあなただけ。ダッシュボードまたはオペレーター端末経由）。実際に学習・蓄積し、1 件ずつ淘汰できるのは、新しい**行動ルール集（playbook）**です。本ドキュメントでは、何が変わったのか、あなたへの影響、設定と観察の方法を説明します。

なぜ置き換えたのか

3 か月の実運用データから、旧メカニズムは「壊れても誰も気づかない」ことが多いと分かりました：

ペルソナファイルが安全上限を超えて長くなると、以降のすべての学習提案が同じゲートでブロックされ、システムは「要手動レビュー」を誰も見ない 1 行のログに書くだけ——エージェントはそこで止まり、誰かが偶然気づくまで新しいことを学べなくなります。
観察期間のルールは本来「会話数が足りなければ待つ」でしたが、待機ロジックに穴があり、最終的には「十分待ったのだから検証済みとみなす」という動きになっていました。実際には裏付けとなる証拠がまったくありません。
業界も同じ方向に動いています：Anthropic 公式の記憶 API は「少数の大きなファイル」の代わりに「多数の小さく焦点の定まったファイル」を推奨し、Letta（MemGPT の後継）はメイン AI に自身のコア記憶の編集をそもそも許しません。ペルソナファイル自体が廃れる気配はなく、廃れつつあるのは「LLM に丸ごと書き換えさせる」ことです——これはプロンプトインジェクション攻撃に最も悪用されやすい部分でもあります。

何が変わったか（あなたへの実際の影響）

SOUL.md を編集するのはあなたで、エージェントは自分では変更できません。 エージェントの性格、口調、責任範囲を調整したいときは、これまでどおりダッシュボードの「エージェント → 詳細 → 編集」か、ファイルを直接編集します。違いは、エージェントが夜中にこっそり自分のペルソナファイルを書き換えることがなくなった点です。
新しい学習の器は Playbook（行動ルール）で、ペルソナファイル丸ごとの書き換えを置き換えます。 各ルールは小さく、独自の分類（ミスの修正／既存のやり方の最適化／新しいやり方の探索）を持ち、どの状況でトリガーすべきかを記録し、検証用のテストケースを少なくとも 1 件リンクし、helpful/harmful の成果スコアを蓄積します。成績の悪いルールは自動的に引退し、誰も手を出せない巨大な文書に無限に積み上がることはありません。
検証が細粒度になりました。 以前は「ペルソナファイル全体を書き換え、24 時間観察し、全体を confirm するか全体を rollback するか」でした。現在は各ルールが個別に検証され、個別に去就を決めます——あるルールの成績が悪ければ、そのルールだけをロールバックし、他の良い学びを巻き込みません。
旧メカニズムは 2026-09-29 に削除されました。 SOUL.md 全文書き換えの経路、その [evolution] legacy_soul_evolution 非常口、SOUL.md のバージョン管理、24 時間の観察ウィンドウ、自動ロールバック、duduclaw evolution finalize コマンドをすべて削除しました。SOUL.md は v3 以降すでにエージェントに対して読み取り専用であり、これらが守っていた書き込み経路自体が存在しませんでした。古い agent.toml に残った legacy_soul_evolution = true は無視されます。
新しいエージェントは初日から学習します。 同じ日から [evolution] gvu_enabled は出荷時 true です。新規作成された AI 社員は、誰かがスイッチを入れなくても経験ルールを蓄積します。コストは両側から抑えられています：gvu_cooldown_minutes がラウンドの開始間隔を制限し、LLM コストゼロの Gate が judge 呼び出しを支払う前に見込みのない候補を却下します。動かしたくないエージェントには gvu_enabled = false を設定してください。

仕組み

新しく学習されたルールはすべて同じライフサイクルをたどり、検証と去就は「ルール単位」で決まります：

学習提案（ルール 1 件）
       |
       v
+---------------------------+
| ゼロ LLM チート検出        |  <-- eval 問題文の丸写し / 常に成立する空文 /
+-------------+-------------+      失敗隠しの指南 → 即ブロックして理由を記録
              |
              v
+---------------------------+
| eval case をリンク         |  <-- 各ルールは少なくとも 1 件リンクし、
+-------------+-------------+      機械検証可能なアサーションを添える
              |
              v
+---------------------------+
| 観察期間                   |  <-- aee_settle_hours（デフォルト 24 時間）
+-------------+-------------+
              |
              v
+---------------------------+
| ルールごとの去就判定       |  <-- helpful/harmful スコアを蓄積；
|                           |      成績不良はそのルールだけロールバックし
|                           |      自動的に引退
+---------------------------+

有効化の方法

2 つのスイッチを両方オンにする必要があります：

[evolution]
enabled = true        # マスタースイッチ（master switch）
gvu_enabled = true    # 学習ループ本体

オンボーディング、業種テンプレートのウィザード、create_agent ツールで作成したエージェントには、agent.toml に gvu_enabled = true が書き込まれます（2026-09-29 以降）。ランタイム側のゲートは変わっていません。キーが無い、または形式が不正な場合は false として読まれます。手書きの agent.toml や、それ以前に作成されてこの行を持たないエージェントは、行を追加するまでオフのままです。

その他のよく使う設定：

[evolution]
gvu_cooldown_minutes = 60     # エージェントごとの学習クールダウン（分）。
                              # 短時間に学習が連続発火してリソースを浪費するのを防ぐ
aee_settle_hours = 24         # 新しく学んだルールを去就判定まで何時間観察するか
strategy = "balanced"         # 各学習ラウンドを修正／最適化／探索のどれに寄せるか

strategy は 4 種類：

値	適した状況
`balanced`（デフォルト）	修正・最適化・探索のバランス型
`innovate`	新しいやり方の探索を重視。ポジションを模索中の新しいエージェント向け
`harden`	既存ルールの最適化を重視。安定稼働済みで磨き込みたいエージェント向け
`repair_only`	ミスの修正のみで新ルールを探索しない、最も保守的

観察の方法

ダッシュボードの「記憶」ページに「自己進化」タブが追加され、以下を確認できます：

進化モード概要：学習を有効にしているエージェントの数
停滞検出：あるエージェントの学習が何ラウンドも連続で却下されたり、長期間新しい学びがない場合にここに警告が出ます（以前はこの状況がまったく見えませんでした）
却下統計チャート：学習提案がどのゲートで最も多くブロックされているかが分かり、ルールが厳しすぎるのか提案の質が低いのかを判断できます
経験則リスト：各エージェントが現在持っているルール。各カードは平易な言葉で表示され（「タスクに〈できない、能力不足〉が現れたら、〈まず手持ちのツールを確認する〉」）、その下の「なぜこのルールがあるのか」の 1 行で出所と証拠を説明します（何回の失敗から帰納されたか、いくつの検収ケースが守っているか、実際に何回使われ、うち何回役立ったか）。モデルに見せる原文は「生のルール内容を見る」に畳まれ、必要なときだけ展開します。ステータスは一貫した平易なラベルで表示：観察中（未発効）／試用中／発効中／長く未使用のため格納済み／引退済み。ワンクリックで JSON にエクスポートしたり、同意できないルールを無効化したりできます。

平易な言い換えは純粋なテンプレート組み立てで、モデルを一切呼び出しません。そのため一覧ページの再読み込みで費用も遅延も発生しません。自然な文が組み立てられない場合は無理に生成せず、カードは原文表示に切り替わり「このルールはまだ平易な文に自動変換できません」と明示します。

チャットアプリでルールを見る

ダッシュボードを開かなくても尋ねられます：

/rules       # 現在発効中の上位 3 件（平易な言葉）
/rules all   # 全件（観察中・格納済みを含む。引退済みはダッシュボードに残る）

こちらもモデルコストはゼロ：コマンドは AI に届く前にインターセプトされて処理されます。

返答の中で「なぜそうしたの？」と聞くこともできます。AI に注入されるルールには番号と 1 行の説明が付くようになったため、AI は根拠にしたルールをそのまま指し示せます（「こう学んだからです：…」）。もっともらしい理由を後付けで作文することはありません。

ルールの試行結果（採用／ロールバック／証拠不足）は日次ダイジェストの学習イベント節に集計され、個別のプッシュ通知であなたを煩わせることはありません。

上級：ルールのエクスポートと eval スイートの実行

あるエージェントが現在学んでいるルールを一括エクスポートしたい場合（手動レビューや、将来エージェント間で経験を複製したい場合など）：

duduclaw export playbook --agent <エージェント id> --out rules.json

各ルールの去就は、リンクされた「検証問題集」（eval case）が決めます。自分で検証を 1 回実行したい、または問題集を作成・拡充したい場合：

duduclaw eval evals/<エージェント id>                       # 問題集をフル実行
duduclaw eval evals/<エージェント id> --case foo,bar         # 指定した問題だけ実行
duduclaw eval evals/<エージェント id> --exclude-dir held-out # 保留問題を除外（エージェントが答えを見るのを防ぐ）

1.53 以降、新しく学習されるルールはすべて少なくとも 1 件の検証問題をリンクし、機械検証可能なアサーション（どのツールを使うべきか、出力に含めるべき／含めてはならない文字列）を数件添える必要があります。まだ問題集がない場合は、SOUL.md の行動ルールから問題のドラフトを生成できます：

duduclaw eval-scaffold --agent <エージェント id>    # ドラフトを evals-drafts/ に生成

ドラフトは evals-drafts/ に置かれ、あなたが手動レビューして evals/ に移した後にはじめて学習メカニズムに採用されます。未レビューのドラフトが正式な問題集に紛れ込むことはありません。あるルールのアサーションに再生可能な記録が存在しない場合、システムは正直に「未検証」とマークして参考情報に格下げし、テスト済みのふりはしません。

旧メカニズム時代に多くの行動ルールを SOUL.md に書き込んだエージェントがいる場合、それらを新しい playbook に移行できます（先にドラフトを生成し、レビュー後に適用）：

duduclaw playbook migrate-soul --agent <エージェント id>          # ステップ 1：移行ドラフトを生成
duduclaw playbook migrate-soul --agent <エージェント id> --apply  # ステップ 2：レビュー後に適用

チート対策監査（1.53 から内蔵）

学習提案は検証に入る前に、ゼロ LLM のチート検出を通ります。ルール内容が検証問題の問題文を大量に写している（答えの丸暗記）、常に成立する空文になっている、または失敗を報告せず隠すようエージェントに教えている場合、提案は即座にブロックされ理由が記録されます。「審査員に気に入られる言い回し」のような曖昧なシグナルは統計に記録されるだけで直接の否決には使われず、正常なルールの誤殺を避けます。

障害帰属：誰の失敗だったのか

「このラウンドは失敗した」しか見えない学習ループには、責任の置き場が1つしかなく、毎回それをモデルに置きます。これは思っている以上に誤りです。ラウンドが失敗する理由は、レビュアーの判断ミス、rate limitへの到達、バイナリの欠落、あるいは従業員が使おうとしたツールが自身の権限設定でブロックされたこと、などさまざまです。そこから学習すると、もともと壊れていなかった挙動を「修正」するルールができあがります。

そのため、失敗したラウンドが学習シグナルになる前に、DuDuClawは証拠から誰の失敗かを判定します。追加のモデル呼び出しはありません。答えは5通りあり、学習に使われるのはそのうち1つだけです。

帰属先	見え方	学習への影響
AI従業員	ほかに異常のない通常の失敗ラウンド	通常どおり。学習に入るのはこのケースだけ
レビュアー	コストゼロの証拠チェックとレビュアーの判断が食い違う：答えが実際のツール結果に裏づけられているのに却下された、またはハードな証拠チェックが失敗したのに承認された	除外
環境	使用量上限、課金、タイムアウト、プログラムの欠落、起動失敗、利用可能なアカウントなし	除外
足場（scaffolding）	返信はツールを使ったと言っているのにツール活動が捕捉されていない、またはラウンド中に権限ゲートがツール呼び出しをブロックした	除外
不明	そのラウンドについて観測できたものが何もない	除外

「除外」は文字どおりの意味です。そのラウンドは証拠なしとして扱われ、そのとき有効だったルールは減点も加点もされません。成功として再採点することはあえてしていません。そうすると、そのラウンドに影響していないルールに手柄を与えることになるからです。除外はすべて、帰属先と発火したルールを記したfault_attributedエントリとして監査証跡に書かれるため、どのラウンドがなぜ見送られたかを確認できます。

同じラベルは記録されたミスにも付きます。AI従業員以外に帰属されたミスは、ミスを永続ルールに統合する「同種3件」のしきい値にカウントされなくなります。この機能が出る前に記録されたミスは従来の意味のままで、引き続きカウントされます。

デフォルトで有効です。すべての失敗をモデルのせいにする従来の動作に戻すには、~/.duduclaw/config.tomlに次を書きます。

[evolution]
fault_attribution = false

背景：The Misattribution Gap（arXiv:2605.22842）は、本当の原因が別にあった64件の失敗のうち64件でモデルを責めた帰属システムを報告しています。Model or Harness?（arXiv:2607.28802）は「固定のリストから書き込み時に帰属先を決め、判断できなければUnknownと書く」というルールの出典です。

まだできていない部分

これは段階的に進めている改造です。以下の項目は計画中で、本バージョンには含まれていません。別途アナウンスします：

各学習を「反証可能な仮説」として立て、観察期間が漠然と統計を眺めるのではなく、具体的な答えを待つようにする
蓄積したルールの意味レベルでの定期的な重複整理（現在の重複検出はほぼ一字一句同じ重複しか防げず、「5 つのルールが実は同じことを言っている」といった理解を要する重なりはまだ発見できません）

因果サポート（2026-09-29、テレメトリのみ）

候補ルールには数値が 1 つ増えました。そのトリガー信号のうち、人が実際に承認した因果主張で裏づけられている割合です。主張は監査ログ由来で、タスクが却下・エスカレーションされたときに「このツールエラーがこの種のタスクの失敗と同時に記録された」をレビュー待ち候補として残します。モデル呼び出しはゼロ、データはこの端末から出ません。因果レビュー画面で承認して初めてサポートになります。

この数値が意図的に行わないことが 2 つあります。

ルールを採用するかどうかの判定には一切関与しません。転記された共起を 1 人が承認しただけのものは品質測定ではないため、コミットゲートは双方向でこれを見ません。ルールカードとラウンドのスナップショットに出るだけです。
承認済み主張が 1 件もない場合は 0 ではなく「未測定」と表示されます。誰も主張をレビューしていない従業員は、ルールに根拠がない従業員ではありません。

実際に効かせたい場合は config.toml [evolution] require_causal_evidence = true。サポートのない新規ルールはシャドウ候補として入り、保存もスコアリングもされますが、証拠が揃うまでプロンプトには注入されません。ルールは破棄されず保持されます——「まだ証拠がない」と「間違っている」は別物です。既定はオフで、オフの間は書き込み経路が従来とビット単位で同一です。