SOUL.md バージョン管理とロールバック

アトミックなパーソナリティ更新と自動ロールバック——エージェント進化のセーフティネット。

たとえ話：ソフトウェアのカナリアリリース

ソフトウェアデプロイメントにおける「カナリアリリース」：新バージョンをユーザーの5%にデプロイし、24時間メトリクスを観察し、問題なければ全員にロールアウト。カナリアが死んだら（メトリクスが急落）、即座にロールバック。

DuDuClawはエージェントのパーソナリティ更新に同じ原則を適用します。パーソナリティファイル（SOUL.md）はエージェントの「デプロイ済みソフトウェア」——すべての更新がカナリアプロセスを経ます。

仕組み

更新プロセス

GVUループが新バージョンのパーソナリティファイルを生成しても、旧ファイルを単純に上書きしません。代わりに、マルチステップのアトミック書き込みプロセスに従います：

GVUが候補パーソナリティファイルを生成
     |
     v
ステップ1：一時ファイルに書き込み
  （本番ファイルとは別のファイル）
     |
     v
ステップ2：暗号フィンガープリントを計算
  （コンテンツの一意なハッシュ——1文字でも変われば
   ハッシュは完全に異なる）
     |
     v
ステップ3：アトミックrename
  （単一のファイルシステム操作で本番ファイルを
   一時ファイルに置換——部分状態は存在しない）
     |
     v
ステップ4：バージョンメタデータを記録
  （タイムスタンプ、フィンガープリント、変更理由、
   トリガーとなったフィードバックへのリンク）
     |
     v
ステップ5：24時間観察を開始
  （新バージョンでのパフォーマンスメトリクスを監視）

なぜアトミック書き込みが重要か

アトミック書き込みなしの場合を考えてみましょう：

危険なアプローチ：
  1. 本番ファイルを開く
  2. 内容をクリア
  3. 新しい内容を書き込む
  4. ファイルを閉じる

ステップ2と3の間でシステムがクラッシュすると、
パーソナリティファイルは空になる。
エージェントはパーソナリティを持たない。会話が失敗する。

アトミック書き込み（一時ファイル + rename）の場合：

安全なアプローチ：
  1. 完全な新コンテンツを一時ファイルに書き込む
  2. 一時ファイルを本番ファイルパスにrename（単一操作）

ステップ1でクラッシュした場合：
  → 一時ファイルは不完全だが、本番ファイルは無傷。
ステップ2でクラッシュした場合：
  → renameはアトミック——起きたか起きていないかのどちらか。
     本番ファイルは完全に旧か完全に新。決して部分的にならない。

観察期間

新バージョンが稼働した後、システムは一連の指標を監視します：

24時間観察ウィンドウ
     |
     v
  モニタリング：
  +--------------------------------------------+
  | - ユーザー満足度シグナル                       |
  |   （ユーザーはポジティブに反応しているか？）     |
  |                                             |
  | - 予測エンジン精度                             |
  |   （エージェントの行動は予測可能か？）           |
  |                                             |
  | - エラー率                                    |
  |   （エージェントのミスが増えていないか？）       |
  |                                             |
  | - 会話完了率                                   |
  |   （ユーザーが会話の途中で離脱していないか？）   |
  +--------------------------------------------+
     |
     v
  +------+------+
  |             |
安定/         悪化
改善          |
  |           v
  v         自動ロールバック：
新バージョン  保存されたフィンガープリントで
を確定       前バージョンをリストア

ロールバックも同様にアトミック——前バージョンのコンテンツがフィンガープリントでインデックスされており、リストアは同じ一時ファイル→renameプロセスです。

ドリフト検出

進化サイクルの外でも、システムは定期的にパーソナリティファイルの整合性をチェックします：

定期的な整合性チェック（N分ごと）
     |
     v
現在のフィンガープリントを計算
     |
     v
期待されるフィンガープリントと比較
     |
  +--+--+
  |     |
一致   不一致
  |     |
  v     v
OK    アラート：
      「パーソナリティファイルが進化パイプラインの
       外で変更されました！」

以下のシナリオをキャッチします：

人間が手動でファイルを編集してエラーを導入
別のプログラムが誤って上書き
悪意ある行為者がコンテンツの注入を試みた

アラートはログに記録されダッシュボードに表示されます。設定に応じて、システムは期待されるバージョンに自動リストアできます。

バージョン履歴

パーソナリティファイルの各バージョンがメタデータ付きで記録されます：

バージョン履歴：
  v12（現在） - 2026-04-07T10:30:00Z
    フィンガープリント：a3f8c1...
    理由：「ユーザーフィードバックに基づき挨拶の温かみを改善」
    状態：観察中（残り18時間）

  v11 - 2026-04-06T14:00:00Z
    フィンガープリント：b7d2e9...
    理由：「エラーリカバリの言語を追加」
    状態：確定（観察通過）

  v10 - 2026-04-05T09:15:00Z
    フィンガープリント：c1a4f6...
    理由：「技術説明のフォーマルさを軽減」
    状態：確定

この履歴は複数の目的に役立ちます：

デバッグ：エージェントの行動が変わった場合、特定のバージョンに追跡可能
ロールバック先：直前のバージョンだけでなく、任意の過去バージョンにリストア可能
進化監査：エージェントのパーソナリティが時間とともにどう進化したかを表示

なぜ重要か

ゼロダウンタイム進化

パーソナリティ更新中にエージェントがオフラインになることはありません。アトミックrenameがシームレスな移行を保証——ある瞬間にはエージェントは旧パーソナリティを使い、次の瞬間には新パーソナリティを使います。再起動なし、ギャップなし、部分状態なし。

デフォルトで可逆

すべての変更を元に戻せます。これにより進化は安心して試せるものになります——悪い変更のコストは24時間のわずかなパフォーマンス低下、その後の自動修正です。恒久的なミスではありません。

改ざん検出可能

フィンガープリントシステムにより、無許可の変更はすべて検出可能。ファイルを直接アクセスから保護するセキュリティフックと組み合わせることで、パーソナリティファイルは署名付きソフトウェアリリースと同等の整合性保証を持ちます。

コンプライアンス対応

規制産業にとって、バージョン履歴はエージェント行動のすべての変更——いつ、なぜ、影響は何か——の監査可能な証跡を提供します。

他システムとの連携

GVUループ：このシステムが管理する候補バージョンを生成
セキュリティフック：パーソナリティファイルを無許可のアクセスから保護
予測エンジン：精度メトリクスが観察期間の健全性評価にフィードバック
ダッシュボード：バージョン履歴と観察状態がWebインターフェースで表示
CONTRACT.toml：行動規約がパーソナリティファイルがなってはならないものを定義

まとめ

エージェントの進化は強力ですがリスクを伴います。SOUL.mdバージョン管理は、進化を実用的にするためのセーフティインフラを提供します：アトミック更新が破損を防止、観察期間がリグレッションをキャッチ、自動ロールバックが影響範囲を制限、ドリフト検出が無許可の変更をキャッチ。セーフティネットなしの進化は無謀です。このシステムがあれば、進化は体系的になります。