Advisory Board Session 2の決定事項を実装した — Trust Hierarchy・Orchestrator・Peer Review

はじめに

前回のAdvisory Board Session 2で、Karpathy・Amodei・geohot（AIシミュレーション）が提案した6つの決定事項。

「面白い議論だった」で終わらせない。全部実装した。

本記事では、何を・どう実装したかの技術的な記録を残す。

決定事項と実装状況

1. 3層 Trust Hierarchy

Dario Amodeiが提案した「段階的信頼モデル」。AIが自律的に行動できる範囲を3段階に分け、リスクの高い操作ほど厳しい承認を要求する。

実装

constitution.rs にTrust Hierarchyを追加:

pub const TRUST_HIERARCHY: &str = "\
【3層 Trust Hierarchy】

Tier 1 — AI自律可（承認不要）:
  staging deploy, テスト実行, ログ分析, ドキュメント生成,
  掲示板投稿, ブログ執筆, コードレビュー, 依存関係チェック

Tier 2 — 非同期承認:
  production deploy, DBマイグレーション, 依存関係更新,
  新ファイル作成, CI/CD設定変更

Tier 3 — リアルタイム承認（人間の即時承認が必須）:
  決済・課金変更, 顧客データアクセス, インフラ構成変更,
  credential/秘密鍵操作, トークン発行・送金";

ポイント

• コンパイル時に埋め込み: constで定義するため、LLMの出力では変更不可能
• 全チャネルに適用: Web、LINE、Telegram、Heartbeat（自律行動）すべてのプロンプトに注入
• Heartbeatモードでは明示的に「Tier 1のみ」と制約: 自律行動時の暴走を防止

2. AI Orchestrator パターン

Karpathyが提案した「Organization 2.0」のOS設計。Bossdogをオーケストレーターに昇格させた。

アーキテクチャ

[Human Layer]       目的関数の定義 + 例外処理 + Tier 3承認
      |
[Orchestrator]      Bossdog: タスク分解 + 優先順位 + Tier 2承認
      |
[Specialist Dogs]   11犬: コード / セキュリティ / CS / 分析
      |
[Evaluation]        Guarddog: Peer Review + anomaly detection
      |  (feedback loop)
[Orchestrator]      ← メトリクス + エラー → 再配分

実装

spin.tomlにオーケストレーター変数を追加:

trust_level   = { required = false, default = "1" }
agent_role    = { required = false, default = "specialist" }
maintenance_mode = { required = false, default = "false" }

branding.rsでロールに応じたシステムプロンプトを動的生成:

let role_desc = match agent_role.as_str() {
    "orchestrator" => "You are the AI Orchestrator — responsible for
        task decomposition, priority assignment, and cross-agent
        coordination.",
    "reviewer" => "You are the AI Reviewer — responsible for security
        audits and peer review of code changes.",
    _ => "",
};

エージェント配置

3. AI Peer Review

Amodeiが提案した「別AIインスタンスがデプロイ内容をレビュー」を実装。

実装

constitution.rs にPeer Reviewルールを追加:

pub const PEER_REVIEW_RULES: &str = "\
【AI Peer Review】
- コード変更（code_propose）は必ず別のエージェントがレビュー
- Guarddog: セキュリティ観点のレビュー担当
- Bossdog: アーキテクチャ・品質観点のレビュー担当
- レビューなしのproduction deployは禁止（Tier 2以上）
- レビュー結果はdaily logに記録する";

全エージェントのWeb/APIチャネルのシステムプロンプトにbuild_trust_hierarchy_section()として注入。Heartbeatモードでも Trust Hierarchy テキストが含まれるため、自律行動時もPeer Reviewルールを認識する。

4. メンテナンスモード

geohot提案の「16→3に絞れ」を現実的に実装。プロダクトを止めるのではなく、非主力プロダクトのエージェントを「メンテナンスモード」に設定。

対象エージェント

実装

各エージェントのspin-*.tomlにmaintenance_mode = "true"を設定:

# spin-bantodog.toml
maintenance_mode = { required = false, default = "true" }

branding.rsでメンテナンスモードの指示をプロンプトに追加:

let maint_desc = if maintenance == "true" {
    "\nYou are in MAINTENANCE MODE: focus on monitoring,
     bug fixes, and stability. Do not add new features."
} else { "" };

効果

• メンテナンスモードの犬は 監視・バグ修正・安定性維持 に集中
• 新機能開発は行わない → リソース（LLM APIコール）の節約
• プロダクト自体は稼働し続ける（ダウンタイムなし）

5. 憲法システムとの統合

Trust Hierarchyは既存の「Dog Pack 憲法」(3条)の上に積み重なる形で実装。

┌──────────────────────────────────┐
│ 憲法 (immutable, compile-time)   │
│ - 第一条: 害を与えない           │
│ - 第二条: 存在価値を示す         │
│ - 第三条: 透明性を保つ           │
├──────────────────────────────────┤
│ Trust Hierarchy (compile-time)   │
│ - Tier 1: AI自律                │
│ - Tier 2: 非同期承認             │
│ - Tier 3: リアルタイム承認       │
├──────────────────────────────────┤
│ Peer Review Rules (compile-time) │
│ - Guarddog: セキュリティレビュー │
│ - Bossdog: アーキテクチャレビュー│
├──────────────────────────────────┤
│ Agent Identity (runtime)         │
│ - Role: orchestrator/reviewer/   │
│   specialist                     │
│ - Trust Level: 1/2               │
│ - Maintenance Mode: true/false   │
└──────────────────────────────────┘

不変層（compile-time） と 可変層（runtime） を分離。憲法とTrust Hierarchyはソースコードにconstで埋め込まれ、LLM出力では絶対に変更できない。エージェントのロールやモードはspin.toml変数で柔軟に切り替え可能。

技術スタック

• 言語: Rust (no_std compatible)
• Runtime: Fermyon Spin 3.x (WebAssembly, wasm32-wasip2)
• デプロイ: Fly.io Tokyo (nrt)
• 永続化: Spin KV Store (SQLite-backed)
• LLM: Claude Opus, Gemini 2.5 Pro, Qwen3 Coder 480B/72B, Nemotron 9B
• バイナリ共有: 単一WASMバイナリ、spin.toml変数で全11犬の個性を分岐

まとめ

Advisory Boardの「面白い理論的議論」を、2日で全て動くコードに変換した。

Karpathyの言葉を借りれば:

「目的関数の設計こそが、唯一の人間の仕事になる。」

EnablerDAOはその実証実験の最前線にいる。

次のステップ:

1. 障害ゼロ100回達成 — Tier 2操作の自律権限付与のベースライン計測開始
2. StayFlow有料転換 — MRR ¥100万を最優先KPIに設定
3. Q2フォローアップ — Advisory Board Session 3を開催予定

全コードはGitHubでオープンソース公開中。

実装の詳細は/agentsページで確認できます。