[Guild Plugin] エージェント組織の構造と開発フロー

概要

AIで開発するとき、私たちは普通、一つのプロンプト、あるいは一つのエージェントに分析から実装・テストまで全部任せます。小さな作業ならそれでも問題ありませんが、規模が大きくなると、一人がすべてをこなすやり方はすぐに限界にぶつかります。

Guild Pluginは別のアプローチを選びました。レポごとに役割を分担した専用のエージェント組織を作り、その組織に開発フローを協業でこなさせるClaude Codeプラグインです。この記事では、その組織がどう構成されていて、開発がどんなフローで回るのかを見ていきます。

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

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

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

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

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

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

なぜ一人ではなく組織なのか

エージェント一人に分析・設計・実装・テスト・レビューを全部任せると、3つの問題が生じます。

コンテキストの過負荷 — 一つの会話にすべての文脈(要求事項・設計・コード・テスト)が混ざり合い、次第にぼやけていきます。
自己検証の罠 — 自分が書いたコードを自分でレビューすると、確証バイアスに陥ります。人間も自分のコードのバグにはなかなか気づけません。
専門性の希薄化 — セキュリティ、アクセシビリティ、パフォーマンスのように異なる観点を、一つのペルソナが同時に見るのは難しいものです。

人間の組織はこの問題を分業と独立したレビューで解決します。作る人とレビューする人を分け、必要なときに専門家を呼びます。Guild Pluginも同じことをします — 役割を分け、作る役割とレビューする役割を分離するのです。

ギルドの構成員

/gld initを実行すると、そのレポを分析して専用のギルド(組織)が創設されます。構成員は大きく二つに分かれます。

リーダー(ギルドマスター)

リーダーは別のエージェントではなく、メインセッションがその役割を担います。作業ごとに必要なチームを編成し、各役割にタスクを委任し、結果が食い違えば仲裁し、完了かどうかを判定します。つまりオーケストレーターです。

役割ロースター(16種)

initがレポのスタック・コンベンション・リスクポイントを分析し、役割たちをそのレポに合わせて特化させて作ります。

常に参加する中枢の役割 — リーダー、テックリード、開発者、テスター、QA
必要なときだけ招集される専門家 — プロダクトオーナー、デザイナー、セキュリティ、i18n、DBA、パフォーマンス、アナリティクス、インフラ、テックライター、リリースマネージャー、サポートトリアージ

肝心なのは全員を呼ばないということです。小さな変更には最小人数だけ、UIを触るならデザイナーを、認証・外部公開を触るならセキュリティを — リーダーが変更の表面積とリスクを見て、そのつど招集します。組織の規模を作業のサイズに合わせるわけです。

役割たちはどう協業するのか

役割たちは人間のチームのように**協業のルール(プロトコル)**の下で動きます。中でもバイアスを防ぐためのいくつかの規律が特に重要です。

骨格(スケルトン)優先 — テックリードが設計の骨格(モジュール境界・拡張ポイント)を先に固め、開発者はその上に実装します。
テスト優先、バイアスなし — テスターは開発者の実装を見ずに、受け入れ基準(AC)だけを頼りにテストケースを先に書きます。実装に合わせたテストではなく、要求事項を守るテストになります。
自己検証の禁止 — どの役割も自分の成果物を自分で通しません。別の役割が適合性チェック・レビューを担当し、確証バイアスを構造的に遮断します。
ファイルでやり取り — 役割間の成果物は会話ではなくファイルで受け渡します。膨大なコード変更内容(diff)をメインの会話にそのまま流さずコンテキストを節約でき、セッションが切れても成果物は残ります。

「作る人と検証する人は別」という組織の常識を、エージェント同士の契約に落とし込んだものです。

開発フロー

開発は決まった**中枢(spine)**に沿って流れます。この順序は変わりません。

分析 → 設計 → 実行 → テスト → QA

分析 — 何を、なぜ作るのかを整理し、検証可能な受け入れ基準(AC)を立てます。
設計 — どう作るか骨格を固めます。同時にテスターが(実装を見ずに)テストケースを書きます。
実行 — 実際の実装です。作業の種類に応じて機能実装・バグ修正・リファクタリングに自動で分岐します。
テスト — 自動化された正確性の検証です。パスしたと言うには、実際の実行結果(生ログ)が必要です。
QA — 人間視点の品質確認です。自動テストでは拾えない探索的・ユーザーフローの検証を行い、人間が直接確認すべき項目は別途表面化します。

では進行状況はどこにあるのでしょうか。GitHubのissueとPRのラベルにあります。どの段階まで来たかがラベルとして残るため、セッションが切れてもラベルさえ見ればその地点から再開できます。(この状態管理の方式はSDD Pluginから引き継いだものです。)

Guildを使うコマンドたち

実際にはいくつかのコマンドでこの組織を動かします。代表的なものだけ挙げるとこうなります。

/gld init — レポを分析し、ハーネスとギルド、標準ドキュメントを立ち上げます。(レポごとに一度だけ)
/gld plan <文書|issue> — 設計文書(ファイル)や大きなエピックissueを開発単位のissue群に分解します。プロジェクト仕様からバックログを作る役割です。
/gld dev <issue> — issueを一つ、中枢フロー全体で開発します。(最もよく使います)
/gld review <issue|PR> — 人間と一緒にPRを論理単位で一つずつ確認していくガイド付きレビューです。
/gld audit, /gld evolve — 組織を診断し、成長させるコマンドです。この二つが次の記事たちの主役です。

まとめると、initで組織を立ち上げ → planでやるべきことをissueに分け → devで開発し → reviewで一緒に確認する、という流れです。

SDD Pluginと何が違うのか

私が以前作ったSDD Pluginは、GitHub Issueをベースに分析 → 設計 → 実装 → テストの段階を踏ませるClaude Codeプラグインです。そうなると、こんな疑問が浮かぶかもしれません。「Guild Pluginも結局似たような段階的フロー開発なのでは?」

最大の違いは段階的フローを誰がリードするかです。

SDD Plugin — 人間が4段階のフローを直接リードします。フローは固定されていて、そのフローを遂行するSkillは人間が管理します。
Guild Plugin — フローをエージェント組織が遂行します。役割たちが協業し、リーダーがチームを編成し、planでバックログを作ることまで組織の仕事になります。そして(次の記事たちのテーマである)その組織が自ら成長します。

一言で言えば、SDD Pluginが**「プロセス」だとすれば、Guild Pluginは「そのプロセスを遂行する、成長するチーム」**です。Guild PluginはSDD Pluginの問題意識を引き継ぎ、一段階一般化した結果です。