AIエージェントに「分析役」「設計役」「実装役」「監督役」を割り当てても、役名を切り替えるだけで仕事が安全に分担されるわけではない。実装した本人がそのまま自分の成果を承認すれば、独立した審査にはならないからだ。

BMAD-Solo向けにまとめられた工程仕様の草案は、エージェントの役割分担を、個別の人格や文書の集まりではなく、ひと続きの業務フローとして設計する。要点は「タスクごとの単一契約」と「機械検証・独立レビューの二重ゲート」だ。

ただし、これはあくまで設計案であり、実装済みの機能を報告するものではない。既存の文書や設定が移行されたわけでもない。

役割は四つ、流れは一つ

草案では、PlanとActという二つの基本動作の中に、四つの作業責任を位置づける。

• Plan前半：Analyst — 目標、業務上の不変条件、受け入れ基準、未解決の点を整理する。
• Plan後半：Architect — インターフェース、変更範囲、成果物、検証方法、失敗時の戻り先を定める。
• Act前半：Coder — 承認された契約の範囲で実装し、自身の検証結果を記録する。
• Act後半：Supervisor — 成果物と証拠を点検し、機械検証と独立審査を整える。

これは四つのエージェントを必ず別々に動かすという提案ではない。同じエージェントが作業の視点を切り替えることはあり得るが、視点の切り替えは権限や身元を変えない。草案では、同じエージェントによる反対意見の検討や報告書作成は審査の準備にはなっても、独立した承認の代わりにはならないとする。

タスク文書を「唯一の正本」にする

タスクの契約、現在の段階、検証条件、承認状況を、役割別のフォルダーやチャットの要約に分散させず、一つのタスク工件にまとめるのがもう一つの柱だ。全体の案内文書は安定したルールと導線に絞り、現在の作業対象を示すポインターはタスクへの参照だけを持たせる。状態の二重管理を避ける狙いがある。

タスク契約には、何を達成するのか、どのファイルを変更するのか、何をもって合格とするのか、どの検証を必ず実行するのかを記載する。草案はこれらを、それぞれ成果物・受け入れ基準・KCP（重要管理点）として扱う。ここでいうKCPは、作業の品質を確認するために定める必須チェックのことだ。

設計上は、タスクの契約と実行中の状態も区別する。契約の変更は版を上げて再承認し、候補の差し替えや検証のやり直しは新しい試行として記録する。失敗した証拠を上書きしたり、古い候補の合格結果を新しい候補に引き継いだりしないための考え方だ。

放行には二つの「はい」が必要

提案されている二重ゲートでは、次の両方がそろわなければ成果物を下流に渡さない。

1. 機械検証：宣言されたテストやチェックが、対象の候補に対して実際に実行され、結果が記録されている。
2. 独立レビュー：実装に参加していない審査者が、同じ契約・候補・検証結果を確認して承認する。

テスト結果が欠けている、対象候補が古い、必須テストが実行されたか分からない、といった場合は「不明」として扱い、合格にしない。反対に、機械チェックが通っても、業務上の意味や影響まで正しいと自動的に証明されたことにはならない。だから、人によるレビューを別に置く。

この設計では、実装者が自分の成果物を変更できる環境と、承認やリリースを決める入口を分けることも重視する。エージェントのプロンプトに「今から審査役」と書くだけでは、実行時の権限や独立性は担保できない。

品質チェックを作業の後付けにしない

この考え方は、品質要求を業務プロセスに組み込むという発想とも重なる。華為の公開演説には、エンドツーエンドの品質管理体系を構築し、品質要求を各業務プロセスに組み込む方針が記されている。7 草案も、検証を最後にまとめて行うのではなく、タスクの契約、実装、受け渡しそれぞれの段階に組み込む構成をとる。

一方、AIエージェントの分業を扱う研究として「AutoSwarm: Automating Agent Swarms」のプレプリントが公開されている。1 ただし、今回参照できる資料だけでは、草案に登場する具体的な定義や数式が論文本文と一致するかは確認できない。この提案の効果が実証されたと受け取るべきではない。

現時点では「実装」ではなく設計

草案が示すのは、文書の置き場所、状態遷移、検証記録、独立承認、失敗時の復旧などをどう設計するかという工程仕様だ。実際にその仕組みが有効な権限分離を実現しているかは、Roo CodeやClineなどのホスト環境で、設定が読み込まれるか、権限が守られるか、門番が失敗時に処理を止めるかを個別に確かめる必要がある。

つまり、役割分担を増やすこと自体が目的ではない。タスクの正本、候補に結び付いた証拠、独立した承認を一つの業務フローに結び付け、未確認のものを合格として扱わない。その運用を実際のシステムで確かめて初めて、設計案は現場の統制として機能する。

AIエージェントに「分析役」「設計役」「実装役」「監督役」を割り当てても、役名を切り替えるだけで仕事が安全に分担されるわけではない。実装した本人がそのまま自分の成果を承認すれば、独立した審査にはならないからだ。

BMAD-Solo向けにまとめられた工程仕様の草案は、エージェントの役割分担を、個別の人格や文書の集まりではなく、ひと続きの業務フローとして設計する。要点は「タスクごとの単一契約」と「機械検証・独立レビューの二重ゲート」だ。

ただし、これはあくまで設計案であり、実装済みの機能を報告するものではない。既存の文書や設定が移行されたわけでもない。

役割は四つ、流れは一つ

草案では、PlanとActという二つの基本動作の中に、四つの作業責任を位置づける。

• Plan前半：Analyst — 目標、業務上の不変条件、受け入れ基準、未解決の点を整理する。
• Plan後半：Architect — インターフェース、変更範囲、成果物、検証方法、失敗時の戻り先を定める。
• Act前半：Coder — 承認された契約の範囲で実装し、自身の検証結果を記録する。
• Act後半：Supervisor — 成果物と証拠を点検し、機械検証と独立審査を整える。

これは四つのエージェントを必ず別々に動かすという提案ではない。同じエージェントが作業の視点を切り替えることはあり得るが、視点の切り替えは権限や身元を変えない。草案では、同じエージェントによる反対意見の検討や報告書作成は審査の準備にはなっても、独立した承認の代わりにはならないとする。

タスク文書を「唯一の正本」にする

タスクの契約、現在の段階、検証条件、承認状況を、役割別のフォルダーやチャットの要約に分散させず、一つのタスク工件にまとめるのがもう一つの柱だ。全体の案内文書は安定したルールと導線に絞り、現在の作業対象を示すポインターはタスクへの参照だけを持たせる。状態の二重管理を避ける狙いがある。

タスク契約には、何を達成するのか、どのファイルを変更するのか、何をもって合格とするのか、どの検証を必ず実行するのかを記載する。草案はこれらを、それぞれ成果物・受け入れ基準・KCP（重要管理点）として扱う。ここでいうKCPは、作業の品質を確認するために定める必須チェックのことだ。

設計上は、タスクの契約と実行中の状態も区別する。契約の変更は版を上げて再承認し、候補の差し替えや検証のやり直しは新しい試行として記録する。失敗した証拠を上書きしたり、古い候補の合格結果を新しい候補に引き継いだりしないための考え方だ。

放行には二つの「はい」が必要

提案されている二重ゲートでは、次の両方がそろわなければ成果物を下流に渡さない。

1. 機械検証：宣言されたテストやチェックが、対象の候補に対して実際に実行され、結果が記録されている。
2. 独立レビュー：実装に参加していない審査者が、同じ契約・候補・検証結果を確認して承認する。

テスト結果が欠けている、対象候補が古い、必須テストが実行されたか分からない、といった場合は「不明」として扱い、合格にしない。反対に、機械チェックが通っても、業務上の意味や影響まで正しいと自動的に証明されたことにはならない。だから、人によるレビューを別に置く。

この設計では、実装者が自分の成果物を変更できる環境と、承認やリリースを決める入口を分けることも重視する。エージェントのプロンプトに「今から審査役」と書くだけでは、実行時の権限や独立性は担保できない。

品質チェックを作業の後付けにしない

この考え方は、品質要求を業務プロセスに組み込むという発想とも重なる。華為の公開演説には、エンドツーエンドの品質管理体系を構築し、品質要求を各業務プロセスに組み込む方針が記されている。7 草案も、検証を最後にまとめて行うのではなく、タスクの契約、実装、受け渡しそれぞれの段階に組み込む構成をとる。

一方、AIエージェントの分業を扱う研究として「AutoSwarm: Automating Agent Swarms」のプレプリントが公開されている。1 ただし、今回参照できる資料だけでは、草案に登場する具体的な定義や数式が論文本文と一致するかは確認できない。この提案の効果が実証されたと受け取るべきではない。

現時点では「実装」ではなく設計

草案が示すのは、文書の置き場所、状態遷移、検証記録、独立承認、失敗時の復旧などをどう設計するかという工程仕様だ。実際にその仕組みが有効な権限分離を実現しているかは、Roo CodeやClineなどのホスト環境で、設定が読み込まれるか、権限が守られるか、門番が失敗時に処理を止めるかを個別に確かめる必要がある。

つまり、役割分担を増やすこと自体が目的ではない。タスクの正本、候補に結び付いた証拠、独立した承認を一つの業務フローに結び付け、未確認のものを合格として扱わない。その運用を実際のシステムで確かめて初めて、設計案は現場の統制として機能する。