1チケットを自律で消し切るループを作った――司令塔1・マネージャ1・専任3の敵対的レビュー付き設計

以前、Claude Codeで11人編成のマルチエージェント開発チームを構築した話を書いた。あれは「AIに組織を組ませたらどうなるか」という実験だった。今回はその逆で、人数を極端に絞った話をしたい。

きっかけは、日々の作業の中で「同じ段取りを毎回自分の手で踏んでいる」ことに気づいたからだ。トラッカーからチケットを開き、テストケースを起こし、直す前の状態を確認し、実装して、レビューして、PRを作って、ステータスを更新する。1枚ずつは大したことがない。でも、この一連を1日に何度も繰り返していると、頭を使うべきは「何を直すか」なのに、実際に時間を食っているのは「段取りを回すこと」だった。ここをいちばんもったいないと感じた。

そこで、チケットを1枚投げたら、検証つきで安全に消化されて返ってくるループを作った。名前は ment-loop としている。この記事は、その設計と、詰めていく過程で得たものの記録だ。先に正直に書いておくと、コマンド自体は実装済みで検証もできる状態だが、実チケットでのフル走行はまだこれからの段階にある。そこも隠さず書く。

そもそも何を作ったか

/ment-loop は、課題トラッカー（Notion など）の「未着手」「着手中」のチケットを順に拾い、各チケットを**「完了相当ステータス」まで自律処理する**汎用ループだ。汎用と言うからには、プロジェクト固有の値をコマンドにベタ書きしない。リポジトリの場所、ブランチの基点、トラッカーの状態名といった固有値は、各プロジェクト直下の .claude/ment-loop.config.md に置いて、そこから駆動する。

設計の芯は1つだけだ。

摩擦をなくす。つまり「チケットを投げたら、検証つきで安全に消化されて返ってくる」。推測で進めず、曖昧なら聞く。勝手に壊さない（破壊的な操作は、設定に書いたものしかしない）。

この「勝手に壊さない」を担保に置いたのは、自律ループでいちばん怖いのが暴走だからだ。速く回ることよりも、止まるべきところで止まることを優先した。

なぜ3層に分けたのか

最初は1つのエージェントに全部やらせようとした。すぐに破綻した。実装で頭がいっぱいのエージェントに、同時に「このチケットはもう完了と見なしていいか」という進行判断までさせると、どちらも中途半端になる。人間が実装しながら進捗会議を仕切ろうとすると失敗するのと同じだ。

なので、責務で3層に割った。

層	名前	責務
司令塔	`/ment-loop`	設定を読み、ソース種別を判定し、作業リストを組み、1件ずつ下位へ委譲する。確認の上申と再開、最後のサマリ。自分では実装もレビューもしない
マネージャ	`ment-resolver`	1チケットを完結処理する。ブランチ管理・レビュー実行・トラッカー更新・進行判断。重い作業はさらに専任へ渡す
専任	`test-case-author`	受入条件と仕様から検証可能なテストケースを作る。コードは触らない
専任	`evidence-collector`	ローカルでテストを再現し、修正前（失敗）・修正後（合格）のエビデンスを取る。コードは触らない
専任	`ment-implementer`	プランや指摘に沿って最小差分で実装・修正する。commit や PR はしない

ポイントは、専任がそれぞれ**「やらないこと」を持っている**ところだ。テストを書く人はコードを直さない。エビデンスを取る人もコードを直さない。実装する人はコミットしない。役割を分けるだけでなく、越境を禁じておく。この発想自体はAI駆動開発の役割分担の記事で書いた「作る・設計する・保守するは別のスキル」と地続きで、レビュアーと実施者を分けるのと同じ理屈だ。

パイプライン：1チケットが「完了相当」になるまで

1チケット（=1ユニット）の処理は、こういう流れになる。

ユニット ── BASE を最新化(fetch + pull --ff-only) → ブランチ作成
 └ 作業項目(子)ごとに逐次:
      TC作成 → 修正前エビデンス → 実装プラン → 実装 → 修正後エビデンス
      → code-review(子の差分・must-fix 0 まで)
      → 子コミット(1子=1コミット) → 子を DONE
 └ 全子完了後: 親PR を1本作成 → pr-review を1回(must-fix 0 まで)
 └ 両レビュー must-fix=0 なら チケットを DONE
 └ 後始末: BASE のクリーン状態へ戻す(ブランチは再開のため残す)

細かいが効いている決めごとが3つある。

子ごとに1コミットにする。差分の境界を作業項目の単位に保てるので、レビューとエビデンスがどの変更に紐づくのか後から追える。累積したツリーが前の子の成果を上書きして無効化する、という事故も防げる。
code-review は作業項目ごと、pr-review はPRに1回。粒度を分けている。pr-review の修正が子のコードを変えたら、その子のエビデンスだけ取り直す。
ゼロ基準を守る。レビューの must-fix（高・中）が0になっていないチケットは、DONE にしない。ここを緩めると自律ループはただの「それっぽく閉じる機械」になる。

ソースの形も見分ける。自己参照リレーションを使っていない Notion のデータソースなら「フラット（1行=1ユニット）」、実際に親子で使っているなら「階層（親=ユニット、子=作業項目）」として扱う。そして、判定できないときや、指定と実構造が矛盾するときは、推測せずに止まって聞く。たとえば「フラットのつもり」なのに実は階層構造だった、という場合に押し切ると、子タスクを丸ごと取りこぼす。ここは止まる方が安全だと判断した。GitHub Issues 向けのアダプタは、正直に言うと枠だけで中身は未実装だ。検出したら止まるようにしてある。

敵対的レビューで設計を詰めた

この手のループは、頭の中では綺麗に閉じているように見えて、実際は継ぎ目だらけになる。なので設計そのものを、複数のエージェントに敵対的にレビューさせた。「この設計のどこが破綻するか」を探す係を立てて、粗探しをさせるやり方だ。

初回は6つの観点で47件の指摘が出た。全部を鵜呑みにはせず、実際のファイルの該当箇所で1件ずつ再検証して、41件を反映した。判定レイヤーの穴、子を DONE にするタイミングのズレ、専任どうしの受け渡し（入出力の handoff）が抜けていた箇所、確認のエスカレーション経路が途中で切れていた箇所——出てきたのは、まさに「継ぎ目」ばかりだった。

とくに手こずったのが確認フローだ。検証して直して、を3回繰り返してようやく収束した。ここは後述する。

敵対的レビューは万能ではない。指摘の数が多いほど正しい、わけでもない。47件のうち6件は再検証で「これは指摘の方が誤り」として落とした。レビューの結論をそのまま採るのではなく、実ファイルで裏を取る一手間が要る。

逐次にした理由と、確認の扱い

設計中に迷った論点はいくつもあったが、印象に残っているものを挙げる。

並列ではなく逐次にした。 本音を言えば、チケットを並列で消したかった。その方が速い。でも、いま使っているローカルの開発サーバは、1作業ツリー（=1ブランチ）しか配信できない。並列化するには git の worktree を前提にした作り直しが要る。今回はそこまで手を広げず、「まず1本を確実に」を選んだ。速さより確実さ、という判断だ。

確認は溜めずに、途中で聞く。 最初は「疑問点は最後にまとめて質問」にしていた。これがよくなかった。ループの終盤にまとめて聞かれても、文脈がもう遠い。だから、疑問が出たその時点で作業を止め、ユーザーに聞き、回答を受け取ったら、止まった場所から同じユニットを再開する設計に変えた。ここで1つ制約がある。サブエージェントはユーザーに直接は聞けない。なので確認は、深い階層で発生しても必ず司令塔まで浮かせて聞く。

確認中は、次のチケットへ進まない。 逐次なのだから、現ユニットに留まる。解決しないまま次へ行くと、宙ぶらりんのチケットが増えていくだけだ。技術的な失敗（確認ではなく単なるエラー）のときだけ、次へ進んで再開余地を残す。

この「途中で聞く・同ユニット再開・確認中は動かない」の3点セットが、いちばん揉めた。人間が使う道具として自然に感じられる線を引くのに、何度も引き直した。うちのエージェント運用の可視化については監視ダッシュボードの記事でも触れているが、自律ループでは「今どこで止まって何を待っているか」がさらに大事になる。

正直に：まだ実チケットでは回していない

ここははっきり書いておきたい。ment-loop は指示書（spec）としては確定していて、コマンドもサブエージェントも実ファイルとして存在する。設計の各判断も、勢いではなく検証を通して決めた。

けれど、実運用のチケットでフルに走らせて「完了相当」まで届いた実績は、まだない。設計と実装が終わった段階であって、本番の泥臭さ——想定外のブランチ状態、トラッカー側の揺れ、レビューが延々と収束しないケース——にどこまで耐えるかは、これから確かめる。きれいごとに聞こえるかもしれないが、動かす前から「自律で回ります」と言うのは、この記事でいちばんやりたくないことだった。

だから今回書けるのは、「こう設計した」までだ。「こう運用できた」は、回してから改めて書く。

まとめ

11人のマルチエージェントでは「AIに組織を持たせる」ことを試した。今回の ment-loop は逆で、責務を最小限に割って、1チケットを確実に閉じることに寄せた。人数の多い少ないではなく、どちらも行き着く先は同じだった気がしている。役割を分け、越境を禁じ、止まるべきところで止める。新しい技術というより、昔からある段取りの話だ。

自律ループで怖いのは、速く回ることではなく、間違ったまま静かに閉じてしまうことだ。だから敵対的レビューでゼロ基準を守り、曖昧なら止まって聞く。ここを外さなければ、日々の段取りをAIに預けても、頭を使うべき場所に頭を戻せる——というのが、いまのところの手応えだ。実チケットで回した続きは、稼働してからまた書きたい。

Claude Codeで11人編成のマルチエージェント開発チームを構築した話

こちらは人数を増やした方向の実験。役割分離・通信プロトコル・フェーズ制御を、tmuxベースの実運用の知見として書いています。

/blog/claude-code-multi-agent-team/