[Guild Plugin] 生成AIと一緒に人も成長する

概要

Guild Pluginは、レポジトリごとに専用のエージェント組織を作って開発を行い、その組織自身を成長させるClaude Codeプラグインです。前回までの3部では、**①成果物（コードベース）と②開発者（組織自身）**が共に成長していく過程を扱いました。

今回の最終回では、残るもう一つの軸、③監督者――ツールを使う人を扱います。ツールが自ら成長していくのに、それを使う人だけがそのままでいいのでしょうか。Guild Pluginの答えは「いいえ」です。そして、こうして自らコード・組織・ルールを直していくAIを、どのように安全に制御するのかも併せて整理します。

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

この記事はGuild Pluginシリーズの第4部（最終）です。

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

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

第3部. 成長エンジン①② ― 成果物と開発者の共進化

第4部. 成長エンジン③ + 安全性 ― 監督者（人）も共に育つ（この記事）

3つ目の成長対象は人である

考えてみれば不思議なことです。ツール（②）はどんどん賢くなるのに、それを使う人（③）はそのままだとしたら？人は「なぜこうするのか」を理解しないまま結果だけを受け取るようになり、次第にツールに依存するだけになってしまいます。組織は成長するのに、監督者が停滞してしまうわけです。

そこでGuild Pluginは、監督者（人）も組織の一員として捉え、共に成長させようとします。ただし人は非常に特別な構成員です。成果の推移は記録されますが、エージェントのようにファイルで定義されることも、人事（HR）の対象になることもありません。人は最終的な承認者であり、あらゆる根拠の源――管理される部下ではなく、組織における最高の権威だからです。

ここに一つの決定的な設計原則があります。人の成長は必ず通常利用の副次効果でなければならない、というものです。もし「学習する」といった専用コマンドを別に用意してしまえば、誰もわざわざそれを実行しないでしょう――そうなれば監督者は永遠に成長しません。だから人を育てる仕組みは、独立したコマンドとしてではなく、すでにGuild Pluginで日常的に使っているコマンド（review・evolve・dev）の中に組み込まれています。（唯一、コードベースを案内するonboardだけが独立した学習コマンドです。）

人はどのように学ぶのか

通常利用の中に組み込まれた学習の仕掛けは、学習科学からヒントを得ています。

「なぜ」を教える ― ガイド付きレビュー（review）では「何を直したか」だけでなく、その根本原理を示します。「ここでこの値を分岐させた」ではなく「モードによって変わる値は分岐させるのが原則」というように。局所的な事実ではなく転移可能な原理を学ばせます。
答えを見る前に予測させる ― 問題を明かす前にまず「この部分、どこが危なそうに見えますか？」と尋ねます。予測と実際の差分は、単に答えを見るよりもずっと記憶に残ります。
あなたの判断パターンを映し出す ― evolveが、監督者の繰り返される判断や盲点を（実際の結果に基づいて）振り返りとして見せます。「このリスクを3回受け入れています――その根本原理は…」というように、自分自身のパターンを客観視させます。
タイミングよく思い出させる ― 過去に繰り返した盲点の領域に再び触れようとするまさにその瞬間に、その教訓を一つ示します。後でまとめて報告するより、はるかに効果的です。
習熟度に合わせて引く ― ある領域に慣れるほど説明を減らします。初心者のうちは丁寧に、熟練すれば一行で。くどい説明も、説明不足も避けます。
システムを案内する ― 新しいメンテナーのためにコードベースを一駅ずつ案内するonboardコマンドもあります。唯一、独立して実行する学習の仕掛けです。

人に教えるときの原則

人に教えることは、エージェントに教えるよりもリスクが高い行為です。人は学んだことを信じ、一般化し、実際の権限をもって行動するからです。だからこそ、人に向けた基準は一段と厳格になっています。

必ず実際の結果に基づく ― すべての教訓は、検証済みの結果、実際に発生した不具合、あるいは確定した標準に紐づいていなければなりません。AIの意見は教訓ではありません。 根拠のない観察は、せいぜい「確認が必要な候補」としてしか提示されません。
あくまで勧告であり、選択であり、教え込まない ― 「こういう見方があります」であって、「あなたは間違っています」ではありません。いつでも無視でき、強制はしません。
人に対しては読み取り専用である ― Guild Pluginは人を「直そう」とはしません。見せて、提案して、問いかけるだけです。最終判断と承認の権限は常に人にあります。

まとめると、ツールは組織に対しては習慣を刷り込みルールを強制しますが、人に対してはただ見せて提案するだけです。その境界線は明確です。

自ら直すAIをどう安全にするか

自らコードや組織やルールを直していくツールは、成長の方向を誤れば、むしろ害になります。そのためGuild Pluginの自己成長は、いくつかの**不変原則（neverルール）**の上に成り立っています。

適用は常に人が承認する ― 自動的に反映される変更はありません。人が項目ごとに承認して初めて適用されます。
検証を弱めない ― テストやゲートを無力化する方向の変更は、そもそも許可されません。例外はありません。
すべての適用は元に戻せる ― バックアップ・ロールバック・履歴記録とともに適用され、いつでも原状回復できます。
敵対的に先に検証する ― 自己修正を適用する前に、事前の文脈を持たない独立したレビュー役が「この変更は間違っている」と反論を試みます。自分に都合の良い変更を自分自身で通してしまわないようにする仕掛けです。
根拠が十分なときだけ育つ ― 痕跡が浅ければ、成長そのものを拒否します。

そして、これらの原則の上に、もう一枚決定的なコミットゲートがあります。コミットにシークレットキーが紛れ込んだり、検証を弱める変更が含まれていたりすると自動的にブロックします――人のミスであろうと、AIのミスであろうと関係ありません。これはプロンプトではなく決定的に動作するスクリプトであるため、迂回できません。

要点はこうです。自己成長の自由は、元に戻せる・人が承認する・検証を弱めないという柵の中でのみ許されます。

3つの軸が共に育つ

これで全体像が完成します。Guild Pluginは3つのものを一つのループの中で共に育てます。

①成果物 ― 開発フローがコードベースを積み上げ、
②開発者 ― その開発が残した痕跡が組織を育て、
③監督者 ― その過程を見守る人が原理を学ぶ。

良い組織が良い成果物を生み、その成果物の痕跡が再び組織を改善し、その全過程を見守る人までも――三者そろって良くなっていきます。ほとんどのツールが成果物だけを改善するのとは違い、Guild Pluginはこの三つを一つのループで育てます。これが、最初から語ってきた共進化の完成形です。

おわりに

このシリーズを一言で振り返ると、こうなります。

AIと体系的に開発できるようにしてくれたSDD Pluginには、「ツール自身が成長しない」という限界がありました。その問題を、人が働く仕組み、つまり組織からヒントを得て解いたのがGuild Pluginです。レポジトリ専用のエージェント組織が開発を行い、その痕跡によって成果物・開発者・監督者が共に（共進化しながら）成長しつつ、人の承認・可逆性・検証保護という柵の中で安全に育っていきます。

Guild Pluginはまだ磨き続けられています――実際に使いながら発見したことが、再びツール自身を直していく。もしかすると、この成長エンジンの対象として一番最初に立っているのは、Guild Plugin自身なのかもしれません。