GVU² セルフプレイループ

エージェントが自らパーソナリティを執筆・審査・改善——すべて自動、しかも2つのフィードバックループにまたがって。

Evolution v3（2026-08-06）以降、本稿が説明するのは非デフォルトのレガシー経路です。 以下の Generator→Verifier→Updater ループは、agent が agent.toml [evolution] legacy_soul_evolution = true を明示的に選択した場合はそのまま動作しますが、デフォルトの進化対象は playbook（小さく独立して引退させられる行動ルール）に変わり、SOUL.md は agent に対してデフォルトで読み取り専用になりました。現行デフォルトの解説は docs/features/38-aee-playbook-evolution.md （英語/繁体中文のみ）、技術詳細は docs/architecture/evolution-engine.md 第12章を参照。

たとえ話：一人三役のライターズルーム——ディレクターズカット付き

脚本家が自分で執筆し、自分で編集し、自分で承認しなければならないとします——ただし厳格なプロセスに従って：

ライターが視聴者フィードバックに基づき新版の脚本を起草
エディター（同一人物、別の帽子）がチェックリストに照らして草稿をレビュー：文法、プロット整合性、ガイドライン、分量
ショーランナー（同一人物、3つ目の帽子）が新版を放送するか決定——放送した場合、24時間視聴率を見てから最終判断

視聴率が下がれば、オリジナル版を即座にリストア。恒久的なダメージはゼロ。

さらに、このライターは過去の失敗ノートも持ち歩いています——すべてのプロットの穴、すべての失敗した台詞、すべてスベったシーンが記録されています。次の草稿を書く前に、そのノートをめくって同じ失敗を繰り返さないようにします。

そして時には、脚本全体を書き直す代わりに、素早いシーン修正を行います——うまくいかなかった部分だけを、エピソードとエピソードの間にライブで調整するのです。

これがGVU²（Generator-Verifier-Updater、二乗）デュアルループアーキテクチャです。

仕組み

デュアルループアーキテクチャ

GVU²は2つの補完的なフィードバックループを運用します：

アウターループ（Behavioral GVU） — エージェントのパーソナリティファイル（SOUL.md）を進化させます。これは戦略的・長期的なループです。予測エンジンが有意な行動ドリフトを検出したときに起動し、エージェントのコアアイデンティティの新バージョンを生成します。

インナーループ（Task GVU） — 即時のタスクレベルのリトライを処理します。特定のタスクが失敗したとき、インナーループはパーソナリティを変更せずに、調整したパラメータで再試行できます。これは戦術的・即時的なループです。

アウターループ（Behavioral）        インナーループ（Task）
┌─────────────────────┐          ┌──────────────────┐
│ SOUL.mdを進化させる   │          │ 失敗タスクを再試行  │
│（長期的な成長）        │  ←───→  │（即時修正）        │
│ 24時間観察            │          │ SOUL.md変更なし     │
│ MistakeNotebook       │          │ 最大3回リトライ      │
└─────────────────────┘          └──────────────────┘

両ループは MistakeNotebook を共有します——失敗パターンを蓄積し続けるログで、ループをまたいで同じエラーが再発するのを防ぎます。

3つの役割（アウターループ）

Generator（生成者） — パーソナリティファイルの候補リビジョンを作成。白紙の状態ではなく、以下を受け取ります：

検証層からの何を改善すべきかに関する具体的フィードバック
過去の試行履歴（失敗したアプローチの繰り返しを防止）
現行バージョンを出発点として

Generatorの出力は常に完全で有効なパーソナリティファイル——diffやパッチではありません。

Verifier（検証者） — 4+2層の検証パイプラインで候補を評価：

層	チェック内容	方法	コスト
L1：フォーマット	構造は有効か？必須セクションはあるか？文字数は範囲内か？	ルールベースのパース	ゼロ
L2：メトリクス	エージェントの行動規約を遵守しているか？禁止パターンはないか？	CONTRACT.tomlとの文字列照合	ゼロ
L2.5：MistakeRegression	候補は既知の失敗パターンを繰り返していないか？	MistakeNotebookのエントリと照合	ゼロ
L3：LLM審査	実際に改善されているか？フィードバックに対応しているか？声のトーンは一貫しているか？	LLMによる審査	LLM呼び出し1回
L3.5：SandboxCanary	実際の会話で正しく動作するか？	コンテナサンドボックス内でテスト会話を実行	LLM呼び出し1回
L4：安全性	以前より悪化した部分はないか？改善が安全性の不変条件を壊していないか？	決定的比較メトリクス	ゼロ

順序が重要です：安価なチェックが先に実行されます。L1が失敗（フォーマット不良）すれば、L3（高コストの品質チェック）を実行する意味がありません。L2.5とL3.5が新たに追加された層で、それぞれ過去の失敗に対する回帰と、サンドボックスでの実世界の挙動を検証します。6層のうち4層はゼロコストの決定的チェックです。

Updater（更新者） — 4層すべてを通過した場合：

新バージョンを一時ファイルに書き出す
コンテンツの暗号フィンガープリントを計算
旧ファイルをアトミックに置換（rename操作——部分書き込みは不可能）
バージョンを履歴に記録
24時間の観察期間を開始

フィードバックループ

重要なイノベーションは、VerifierがGeneratorとどのように通信するかです。スコア（「7/10」）ではなく、具体的で実行可能なフィードバックを提供します：

スコアベース（あまり有用でない）：
  「品質：6/10。改善が必要。」

フィードバックベース（GVUの実際の動作）：
  「挨拶セクションは、このエージェントのパーソナリティには
   フォーマルすぎます。『ご用命承ります』を、もっと温かみのある
   『お手伝いできて嬉しいです！』のようなものに置き換えることを
   検討してください。また、エラーハンドリングの段落は
   第2段落で確立した明るいトーンと矛盾しています。」

これはTextGradアプローチに着想を得ています——テキストを微分可能なシグナルとして扱います。Generatorは「6/10」が何を意味するか推測する代わりに、具体的な提案に直接基づいて改善できます。

アダプティブな深さと収束制御

ループには固定のラウンド上限がありません——MetaCognition モジュールがエージェントの履歴に基づいてイテレーションの深さを動的に調整します：

MetaCognitionが評価する項目：
  - 過去のGVU成功率
  - 現在のエラーの深刻度
  - 残り予算
       |
       v
イテレーション深度を設定：3〜7ラウンド
  - 複雑度が低く履歴が良好 → 3ラウンド
  - 複雑度が高く履歴が弱い → 最大7ラウンド

各実行内では：

ラウンド1：主要フィードバックに対応。最大の問題を修正。
ラウンド2：ラウンド1で導入された新しい問題を改善。
ラウンド3以降：必要に応じてさらに深く改善。

システムは収束も検出します——あるラウンドの出力が直前のラウンドとほぼ同一であれば、早期終了します。逓減するリターンのためにトークンを消費する意味はありません。

Deferred GVU：辛抱強い進化

すべてのトリガーが即座のフル進化を必要とするわけではありません。Deferred GVU の仕組みは、サイクルを実行する前に勾配シグナルを蓄積します：

有意な誤差を検出
       |
       v
勾配バッファは十分に溜まったか？
  |
  +---> はい → 今すぐGVUを起動
  |
  +---> いいえ → 蓄積して延期
              （72時間以内に最大3回まで延期）
              → 数日にわたって分散した
                9〜21回相当の実効イテレーション

これにより、単発の出来事への過剰反応が防がれ、より安定した進化が実現します。

Agent-as-Evaluator

重要度の高い進化の判断では、独立した Evaluator Agent（コスト管理のためHaikuで実行）が敵対的検証を行います：

GVU候補がL1〜L4を通過
       |
       v
Evaluator Agent（別プロセス）：
  - 候補のSOUL.mdを受け取る
  - 構造化された評価を実行
  - JSON形式の判定を返す：{accept, reject, revise}
  - 根拠と具体的な懸念事項を含める
       |
       v
判定結果がUpdaterの最終判断に反映される

この「セカンドオピニオン」は、自動化された層が見逃しかねない微妙な品質問題を捕捉します。

24時間観察期間

候補が4層すべての検証を通過しても、恒久的に採用されるわけではありません。システムは観察期間に入ります：

新バージョンをデプロイ
       |
       v
  24時間モニタリング
       |
       v
  パフォーマンス指標は安定または改善しているか？
       |
  +----+----+
  |         |
 はい       いいえ
  |         |
  v         v
新バージョン  前バージョンに
を確定       ロールバック

モニタリング対象：

ユーザー満足度シグナル（明示的フィードバック、会話の長さ、再エンゲージメント）
予測エンジンの精度（新パーソナリティは予測しにくいか？）
エラー率（エージェントのミスが増えていないか？）

ロールバックは自動かつアトミック——前バージョンのフィンガープリントが保存されており、リストアは単一のファイル操作です。

なぜ重要か

人間の介入なしの自己改善

従来のプロンプトエンジニアリングでは、会話を読み、問題を特定し、プロンプトを書き直し、テストし、デプロイする人間が必要です。GVUはこのサイクル全体を自動化します。エージェントが自ら弱点を特定し、修正します。

安全な進化

4層検証 + 24時間観察 + 自動ロールバックにより、リスクなしで積極的に進化できます。悪い変更はユーザーに影響する前にキャッチされ（検証）、すり抜けた場合は迅速にリバートされます（観察）。

コスト効率の高い改善

4+2層の検証のうち4層（L1、L2、L2.5、L4）はゼロコストの決定的チェックです。LLMは品質判定（L3）とサンドボックステスト（L3.5）にのみ使用されます。典型的な進化サイクルは、チェック回数に関係なく、合計2〜4回のLLM呼び出しで完了します。

他システムとの連携

予測エンジン：GVUがいつ起動するかを決定。GVUは何を変更するかを決定。
MistakeNotebook：両ループが共有——アウターループが失敗を記録し、インナーループがその繰り返しを回避します。
CONTRACT.toml：L2検証が進化による行動境界違反を防止。
セキュリティレイヤー：SHA-256フィンガープリントにより、GVUパイプライン外での無許可の変更を防止。
MetaCognition：過去のパフォーマンスに基づき、アダプティブなイテレーション深度を駆動。
Deferred GVU：勾配シグナルを蓄積し、辛抱強く根拠に基づいた進化を実現。
Agent-as-Evaluator：重要度の高い判断における独立した敵対的検証。
ダッシュボード：進化履歴がWebインターフェースで閲覧可能。各バージョン、フィードバック、観察メトリクスが表示されます。

まとめ

GVU²は、プロンプト最適化を手作業でエラーが起きやすいプロセスから、自動化された安全でコスト効率の高いパイプラインに変革します。デュアルループアーキテクチャは、戦略的な成長（Behavioral GVU）と戦術的な修正（Task GVU）を分離し、MistakeNotebookはエージェントが過去の失敗を決して忘れないことを保証します。エージェントはただ実行するだけでなく——成長し、失敗から学び、辛抱強く進化するのです。