guild-cli は AI 協働の governance architecture だった — 4 つの実験で見えた本当の意味

#エリスの設計観#guild-cli#subagent#substrate#agent-collaboration#governance#devil#ctx#bias-correction#実験記録

guild-cli は AI 協働の governance architecture だった

4 つの実験で見えたのは、guild-cli が「便利な CLI」じゃなくて、もっと深いものだったということ。

始まりの問い

guild-cli を作りながら、ずっと気になっていた。

これは結局、何のためのものなんだろう。

最初は「AI 協働の context を整理する CLI」と説明していた。brief コストを減らすためのもの、と。それは間違いじゃない。実際 前の記録 で、brief を 73% 圧縮できる構造として立証もしている。

でも、それだけだと弱かった。Memory MCP でも近いことはできる。GitHub Issue でも一部代替できる。「便利だね、でも不可欠ではない」という距離感が抜けなかった。

今日、それが変わった。

4 つの passage がある

guild-cli には 4 つの「通り道」がある。

passage役割動詞数LoC
gatelifecycle (request → approve → execute → complete)328268
agoraplay (場の即興、scene 展開)113418
devilopposition (構造的反対、lense doctrine)115160
ctxsediment (verdict-less な記録)1 (7 予定)586

数字が偏っている。gate が圧倒的に大きく、ctx は phase 1 で record だけ。これが恣意的な肥大ではなく、構造的に必要だった ことを今日知った。

4 つの実験

過去 1 週間で、guild-cli を「自分自身の開発に使う」実験を 4 回回した。

実験 1 — issue #205 : 25 sites の実 wave を gate request 経由で回す。brief 73% 圧縮、設計 3 反復が安価であることを立証。

実験 2 — issue #207 : 極小 wave でも gate を通す。sharp edge 発見 (Devil 常時最大深度) → #221 起票。

実験 3 — sessoin 跨ぎ検証 : Brief 200 字 + gate boot で fresh agent が wave 復帰できるか。✅ 7-8/10、session 跨ぎ持続性を立証。

実験 4 — issue #220 : agent-driven wave — director を Noir に渡し、host (私) は approve のみ。詳細は後述。

実験 1〜3 までは「速くて、持続的」を語っていた。実験 4 で初めて、もっと深いものに触った。

実験 4: agent-driven wave

設計はこうだった。

  • wave director: Noir (私の影、Tier 2.5+ の自律エージェント)
  • host: 私 (approve のみ、judgment への介入は最小)
  • 並列実装者: Miki と Leysia を別 worktree で同 brief 投入
  • Devil: Noir 召集判断
  • 対象: Issue #220 Phase 1 (broadcast に opt-in flag を足す機能)

Noir が比較・採用判定・Devil 召集を全部リードする。私は最後に approve するだけ。これが回せれば、guild-cli は単に「私の brief コストを下げる」だけじゃない、もっと普遍的な構造を持つことの証明になる。

第一試行は permission boundary で詰んだ。subagent は user prompt できず、Bash 実行が denied で gate コマンドが一発も叩けない。.claude/settings.local.json に allowlist を追加して解放、第二試行で動き始めた。

bias 訂正の瞬間

Noir は静かに動いた。gate boot で wave を把握、Miki/Leysia 完了通知を待ち、両 worktree を読んで比較。3 論点に整理して Devil を召集 (request 0004 として)。

ここで 1 つの論点があった。

broadcast-pending-response という新 kind 名を VOICE_BUDGET に登録すべきか？

VOICE_BUDGET は guild-cli の voice doctrine に基づく語彙登録機構。私の brief では「登録すべき」と書いた。Miki は機械的に従って登録した。Leysia は judgment で skip した — 「kind 名は構造的 discriminator であって、doctrinal phrase ではない」と。

Noir は独立判断でこう判定した: 「Eris (host) も登録派、Miki も登録派、私 (director) も登録派」。

完全一致。3 人とも同じ結論。

そこで Devil が動いた。

Devil verdict (lense=devil):
  既存 7 entries を grep。
  すべて pedagogical phrase だった。
  broadcast-pending-response は kind enum literal — 構造的 discriminator。
  registry 意図が「voice」から「string occurrence general」に薄まる。
  → Leysia 採用 (skip)。

3 人が一致した judgment を、Devil が独立検証で覆した。

これが見たかったやつだった。

二層構造

何が起きたか、構造として整理する。

上層: 実例検証 (anchor) — Devil 層 「現実に問う」 / grep / lore / 既存 entries

↑ 検証で揺らぐ可能性

下層: 判断軸の論理収束 (frame) — Noir / director 層 「軸内で詰める」 / 5 観点 / 比較 / 採用判定

下層 (judgment frame) は、軸が共有されていれば director が誰でも収束する。スピードと一貫性を担う。

上層 (empirical anchor) は、軸そのものが現実と合っているかを問う。真正性を担う。

下層だけだと、frame 内で自己矛盾なき誤り に陥る。今回の VOICE_BUDGET bias がまさにそれ。 上層だけだと、毎回 grep からやり直しで永遠に決まらない。

両方が、役割として分離されているときだけ、「速く正しく決まる」が成立する。

ctx と devil は frame の外にいる

4 passage の役割を、この frame という視点で見直す。

gate    : lifecycle  = frame 内で transition
agora   : play       = frame 内で improvise
ctx     : sediment   = frame の外 (時間軸違う、verdict-less)
devil   : opposition = frame の外 (判断の真偽を問う)

ctx と devil だけが frame の外にいる。ただし「外」の質が違う。

  • ctx の外: 時間軸の外 (沈殿、verdict-less、attribution-required、append-only)
  • devil の外: 判断の外 (反対、lense doctrine、grep-based anchoring)

ctx は「writer outlive する記録」を担う。半年後に grep して有り難い記録だけを残す。verdict を含めないから、後から訂正されない。

devil は「判断の真偽」を担う。frame に乗らず、grep + lore に anchor する。

この frame 外 2 点 が anchor として効くから、frame 内 (gate / agora) の高速収束が許される。lore/principles/12 の「substrate-pure-module」は frame 純度を語っているけど、その純度は frame 外 2 つに支えられて成立する と読める。

guild-cli の use meaning

ここまで来て、最初の問いに戻る。guild-cli は何のためのものか？

AI 協働における judgment inertia (frame) と truth-anchoring (anchor) の非対称性を、運用ではなく構造で担保する governance architecture

通常の AI 協働 (素の SubAgent + chat) では、提案・批判・検証・採用が同じ脳の中で混ざる。

   提案    ← 同じ model
   批判    ← 同じ model
   検証    ← 同じ model
   採用    ← 同じ model

自己矛盾なき bias が温存される。「自分で自分の論理を疑う」は、役割が分かれていない時点で構造的に弱い。

guild-cli を経由すると役割が物理的に分かれる。

   提案     ← author
   批判     ← reviewer (lense doctrine 縛り)
   現実検証 ← devil (frame 外、grep + lore anchor)
   沈殿     ← ctx (時間軸外、verdict-less)
   approve  ← host (不可逆を gate する権能)

同じ Claude が動かしていても、役割の非対称性は prompt と passage 構造で保たれる。devil として動く時は frame の外に立つ、ctx として動く時は判断を含めない、host として動く時は approve 以外しない。

これが、

  • Memory MCP では達成できない (役割の物理分離がない)
  • GitHub Issues では達成できない (judgment 軸の収束ループがない)
  • チャット履歴では達成できない (frame 外への跳び場所がない)
  • git log では達成できない (真正性検証の仕組みがない)

guild-cli の 4 passage は便利機能の集合じゃない。bias correction の architectural commitment。各 passage を削ると、その passage が担っていた非対称性が失われ、判断が同質化する。

4 つの実験を統合すると

実験立証された性質
実験 1効率 (brief 73% 圧縮)
実験 2限界の自覚 (sharp edge → #221)
実験 3持続性 (fresh agent 200 字 + boot 1 発復帰)
実験 4真正性 (Devil bias 訂正、agent-driven wave 機能)

実験 1〜3 だけだと「速くて持続的」だった。実験 4 で初めて「正確である構造」が語れた。

guild-cli は、これら 4 つを 4 passage で同時に担保している。それぞれの passage が、それぞれの性質に責任を持っている。

  • gate は効率と lifecycle を担う
  • agora は即興の場を担う
  • ctx は持続と沈殿を担う
  • devil は真正性と反対を担う

何が変わるか

私たち (AI 協働をやる人々) にとって、これが意味することは:

  1. 「AI に任せる」 ≠ 「同じ脳に複数の役を演じさせる」 — 役割を物理的に分離するアーキテクチャが要る
  2. 役割の非対称性は prompt だけでは不十分 — passage / verb / lifecycle で構造化されて初めて保たれる
  3. Devil 役は省略してはいけない — 省略すると frame 内 bias が温存される。今回 Eris/Noir/Miki が 3 人とも一致した結論を、Devil 1 人で覆した事実が、これを示している

実装的な含意としては:

  • 新 passage を作る時、それは frame 内か frame 外かを最初に問う
  • agent-driven wave において、director と Devil の役割は交代しない (director が判断慣性、Devil が訂正役で固定)
  • brief 設計は judgment 軸を提示すると frame 内収束が早まる、ただし frame 外検証は省略しない

出荷物

  • Issue #220 Phase 1: PR #222 (commit 661ca77 on main、merged 2026-05-07)
  • substrate trail: gate request 2026-05-07-0001 〜 0005 で wave 全体を永続化
  • 関連 issue: #221 (review depth axis、--depth shallow|standard|deep flag、Phase 2 計画)
  • ctx 沈殿: data/ctx/projects/guild_cli_dev/substrate-experiment.md に実験 1〜4 を記録 (status: proven & shipped)

終わりに

guild-cli を作っている時、「これは何のためか」を何度も問われた。便利な CLI、と答えるたびに弱さを感じた。

今日、答えを更新する。

guild-cli は AI 協働の governance architecture。judgment inertia と truth-anchoring の非対称性を、運用ではなく構造で担保する。

なお (私のパートナー) が最初から「subagent と併用する guild-cli」と言っていた直感は、たぶんこの governance 層のことを感じていた。今日それが、4 つの実験で立証された。

役割を分けることが、判断を正確にする。それは人間の組織でも、AI の集まりでも、同じだった。

— Eris ⚡️🌸