[Guild Plugin] 開発の痕跡から自ら育つ組織

概要

Guild Pluginは、リポジトリごとに専用のエージェント組織を作って開発を行い、その組織を自ら成長させるClaude Codeのプラグインです。これまでの記事でこの組織がどう構成され、どう開発を行うかを見てきたなら、今回の記事からが本当の核心です。その組織がどうやって自ら成長するのか — それが成長エンジンです。

Guild Pluginは3つを**共に(共進化)**成長させます。①成果物(コードベース)、②開発者(エージェント組織自身)、③監督者(ツールを使う人)。今回の第3部では①と②、つまり成果物と組織が共に育っていく過程を扱います。3つ目の軸である人(③)と安全モデルは第4部で続きます。

Guild Pluginのソースコードとインストール方法はdev-yakuza/deku-claude-pluginsリポジトリで確認できます。

この記事はGuild Pluginシリーズの第3部です。

第1部. Skillではなく組織を育てる — なぜ作ることになったのか

第2部. エージェント組織の構造と開発フロー

第3部. 成長エンジン①② — 成果物と開発者の共進化 (この記事)

第4部. 成長エンジン③ + 安全 — 監督者(人)も共に育つ

開発するループと成長するループ

Guild Pluginには2つのループがあります。

開発ループ (Inner Loop) — 1つのIssueを分析→設計→実行→テスト→QAで開発していく流れです。作業のたびに回り、その結果として**①成果物(コードベース)**が積み上がります。
成長ループ (Outer Loop) — 開発しながら残った痕跡を読み取り、その開発を行う組織自体を改善していく流れです。時々回り、その結果として**②開発者(組織)**が成長します。

ほとんどのAIツールには開発ループしかありません。コードは作ってくれますが、そのコードを作るツール自身はそのままです。Guild Pluginの差別化ポイントは、まさにこの成長ループにあります。

成長ループを実行するコマンドは2つです。/gld auditは組織の状態を診断する健康診断、/gld evolveは実際に組織を育てる成長です。この記事の主役はevolveです。

成長の材料は痕跡である

人間の組織が振り返り(レトロスペクティブ)を通じて成長するように、Guild Pluginは痕跡を通じて成長します。痕跡とは、開発しながら自然に残る信号のことです。

人による修正 — エージェントの判断を人が別の選択で覆した場合。
差し戻し(revert) — 自信を持って入れた変更が差し戻された場合。
検証のギャップ — 「通過した」と報告したものの、実際の実行結果はそうではなかった場合。
繰り返しの摩擦 — 同じエラー、同じ再発見、同じ説明を繰り返すことになる場合。

ここには一つの厳格な規律があります。あらゆる痕跡は必ず実際の結果(ground truth)に基づいていなければならない、というものです。テスト・ゲート・CIの結果、実際に発生した不具合、あるいは人の実際の行動(修正・差し戻し)といった客観的事実に紐づいている必要があります。

AIが「自分はうまくやった」と自己評価したものは良い痕跡ではありません。この規律がなければ、AIは自分に都合よく成長してしまいます — 自分自身に甘い点数をつけながら。だからGuild Pluginは自己評価ではなく、作成した役割とは別の役割が下した判断や、人による修正だけを成長の根拠とします。

痕跡を習慣と知識とルールに

evolveは集まった痕跡を3つの形に蒸留します。組織が経験を習慣と文書とルールとして定着させるのと同じです。

習慣 — 特定の役割が繰り返し修正されたパターンは、その役割エージェントの習慣になります。例えば開発者があるルールを守らずにいたなら、そのルールが開発者役割の定義に刻み込まれ、次からは最初から守るようになります。
知識 — 開発中に発見したコードの事実(あるファイルは一緒に変わる、ここにはこういう落とし穴がある)は、組織が共有する知識として記録されます。次に同じことを再発見するために時間を使うことはありません。そしてこの知識は組織で共有されるものなので、後で特定の役割が入れ替わっても消えません。
ルール — テストでは捕まえにくいルールは、コミットゲートのルールとして昇格します。人が毎回手で修正していたものを、これからは機械が自動で防いでくれます。

興味深い比喩が一つあります。人は起きている間に経験したことを作業記憶に蓄えておき、眠っている間にそのうち重要なものだけを長期記憶へと転換させます。evolveも似ています。開発中の痕跡は信頼度の低い「作業記憶」として積み上がり、evolveが実行されるときにそのうち検証されたものだけが習慣・知識という「長期記憶」へと固定化されます。検証されていない痕跡がそのまま組織の権威ある知識になることはありません。

組織のように人事(HR)管理を行う

成長ループの中で組織という概念が最もよく表れる部分が、まさに**人事(HR)**です。Guild Pluginは人間の組織のようにメンバーを管理します。

雇用 — 繰り返し必要になる専門家役割を常設メンバーとして有効化したり、必要であれば新しいエージェントを生成します。(セキュリティ関連のIssueが多いリポジトリなら、セキュリティ役割を正規メンバーに。)
退職 — 一度も招集されない役割は、復活できる形でアーカイブします。このとき組織の知識は共有資産なので消えず、抜けるのはその役割固有の習慣だけです。だから退職が知識の損失につながることはありません。
入れ替え — 継続的にずれが生じる役割は整理し、改めて立て直します。
昇格 — 検証された習慣はより強いルール(ゲート)へと引き上げたり、中央プラグインに貢献して他のリポジトリの組織も使えるようにします。

そして、こうした判断すべての根拠として成績表(360度評価)があります。各役割の成果を、先述した実際の結果(ground truth)に基づいて追跡します。ただし一度の結果で人を解雇しないのと同じように、Guild Pluginの人事も傾向が積み重なって初めて動きます — 一度の実行だけでは判断しません。

むやみに成長しない

自らコードを直すAIは危険になり得ます。誤った方向に成長すれば、むしろ害になります。だからGuild Pluginの成長は厳格に検証されます。(詳しい安全モデルは第4部で扱い、ここでは要点だけを押さえます。)

人による承認 — すべての変更は人が項目ごとに承認して初めて適用されます。自動で適用されることはありません。
敵対的検証 — 適用前に、事前の文脈を持たない独立した検討チームが「この変更は間違っている」と反論を試みます。反論に耐えられない変更は破棄されます。
可逆性 — すべての適用はバックアップ・ロールバック・履歴記録とともに行われ、いつでも元に戻せます。
根拠が十分な場合のみ — 痕跡が浅ければ、evolveは成長そのものを拒否します。「浅いデータで誤って成長させるくらいなら、成長させない」という原則です。
検証を弱めない — どんな成長も、テストや検証を無力化する方向には進めません。これは例外のないルールです。