AI-DLC Workflow V2のReviewer Class: レビューの重さを選べる仕組み
「レビュー待ちで12分も止まるんだけど……」。AI-DLC Workflow V2 のステージレビュー、もっと軽くできないの？ できます。Reviewer Classで見ていきましょう。シリーズ第22回。
Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 22AI-DLC Workflow V2のReviewer Class: レビューの重さを選べる仕組み This article
1. はじめに
AI-DLC Workflow V2（以降V2）解説シリーズの第22回です。今回のテーマはReviewer Class、ステージレビューの「重さ」を制御する仕組みです。
先に結論を述べると、V2はステージレビューを3段階のクラス（adversarial / advisory / none）に分類し、ステージの性質に応じた適切なレビュー強度を選べるようにしました。これにより、Inceptionフェーズの散文ステージで12分以上かかっていたレビュー工程が大幅に短縮されています。
V2のステージには、成果物が完成した後に品質ゲートとしてレビューが走ります。第8回 でエージェント構成を紹介したとき、レビュー専任のエージェントが2体いることに触れました。覚えているでしょうか。このレビュー機構は品質を守るために存在しますが、ワークフロー全体の所要時間にも影響します。
ここで重要なのは、レビューの厳しさが一律である必要はないという点です。要件定義の文章と、コード生成後の設計成果物では、求められる検証の深さが違います。Reviewer Classはその違いを仕組みとして表現しています。
では、レビューの仕組みをおさらいするところから始めましょう。
2. レビューとは何だったか
Reviewer Classの話をする前に、V2のステージレビューの仕組みを整理しておきます。ステージプロトコル（§12a）では、
reviewerフィールドを宣言したステージに対して、成果物完成後にレビューエージェントが起動します。流れを振り返ります。- ステージのリードエージェントが成果物を作成する
- レビューエージェントがサブエージェントとして起動する
- レビューエージェントは成果物を読み、
## ReviewセクションにREADYまたはNOT-READYの判定を書く - NOT-READYの場合、リードが修正してレビューを再実行する
- READY、または反復上限に達したら、承認ゲートに進む
レビューエージェントは2体です。
aidlc-product-lead-agentが要件・ストーリー・モックアップ系の成果物を担当し、aidlc-architecture-reviewer-agentが技術設計系の成果物を担当します。どちらもbalancedティア（中程度の推論負荷）で動作します。レビューエージェントは成果物を独立した目で評価するため、ビルダーの作業メモや計画は読みません。エビデンスに基づいた判定だけを行います。
3. 課題: 全ステージにadversarialレビュー
Reviewer Class導入前は、レビューを宣言した12ステージはいずれも同じ動作をしていました。レビューエージェントが成果物を「反論」し、NOT-READYならリードが修正し、再レビューが走る。この反復ループです。
この設計を実際に運用する中で、構造的な課題が浮かび上がりました。ライブA/Bテストの計測結果によると、Inceptionフェーズの人間承認付きステージでは、レビューの振る舞い（反論・修正・再チェック）だけで1ステージあたり12分以上を消費していました。
これは個別のステージの問題ではなく、アーキテクチャの問題です。Requirements AnalysisやUser Storiesのような散文中心のステージに、コード生成と同じ厳密さの反復レビューを適用しても、費用対効果が合いません。散文ステージには人間の承認ゲートが控えているため、レビューエージェントが所見を出せれば十分で、修正ループは人間がRequest Changesで回せます。
では、advisory（助言型）の単発レビューではどうか。同じA/Bテストで検証したところ、adversarial（反論型）と同じカテゴリの所見を検出しつつ、反復ループを省略するぶんだけ大幅に待ち時間を短縮できました。Requirements Analysisステージ（同一シード）での計測結果を表にまとめます。
| 構成 | ステージ所要時間 | 備考 |
|---|---|---|
| adversarial（2パスループ） | 12分34秒〜20分38秒 | 判定結果により変動 |
| advisory（単発パス） | 8分49秒〜14分31秒 | 同じカテゴリの所見を検出。修正ループなし |
| レビューなし | 5分53秒 | レビューエージェント起動せず |
（出典: PR #718。Requirements Analysisステージ、同一シードでのライブ計測）
adversarialでは判定がREADYかNOT-READYかで所要時間が倍近く変わります。advisoryはその振れ幅を抑えつつ、所見の検出能力を維持しています。
4. Reviewer Classの導入
この計測結果をもとに、V2は3つのレビュークラスを導入しました。それぞれの契約を整理します。
adversarial（反論型）
レビューエージェントが成果物を「反論」する契約です。READYにできない根拠を探し、NOT-READYならリードが修正して再レビューを受けます。反復上限は
reviewer_max_iterations（デフォルト2回）で、エンジンが強制します。上限に達しても未解決の所見が残っている場合は、その旨を記載して承認ゲートに進みます。advisory（助言型）
1回だけのレビューパスです。レビューエージェントは同じエビデンス基準で所見を出しますが、修正ループには入りません。READYでもNOT-READYでも、判定はそのまま承認ゲートに引き渡されます。所見は重要度順に並べられ、承認ゲートで人間がトリアージします。人間がRequest Changesを選べば、それがリビジョンのきっかけになります。反復上限はエンジンによって1に固定されます。
none（レビューなし）
レビューエージェントの起動自体を省略します。完了レシート（
REVIEW_COMPLETED）の要件も外れるため、レビュー起因の待ち時間はゼロです。ただし、自律Bolt内のレビューには適用されません（後述）。反復上限は0です。5. 3層の解決モデル
有効なレビュークラスは、3つの入力から決まります。解決ルールは「low-wins」、つまり3つのうち最も軽いクラスが勝ちます。
入力① ステージ宣言（review_class）
各ステージのフロントマターに記載します。値は
adversarialまたはadvisoryです。reviewerフィールドを宣言してreview_classを省略すると、デフォルトでadversarialになります。noneはステージ宣言の値としては存在しません。レビューが不要なステージはreviewerフィールド自体を削除します。入力② スコープ上限（review_cap）
スコープファイルのフロントマターに
review_capを宣言すると、そのスコープ下で動くステージのレビュークラスに上限をかけられます。値はadversarial、advisory、noneのいずれかです。宣言しなければスコープ側からの制限はありません。入力③ 実行時オーバーライド（/aidlc --review）
ワークフロー実行中に
/aidlc --review <class>で、以降のステージに適用する上限を設定できます。こちらもadversarial、advisory、noneの3値です。adversarialを指定するとオーバーライドがクリアされます。クラスを引き上げることはできません。解決の具体例
code-generationステージ（宣言: adversarial）をbugfixスコープ（review_cap: advisory）で実行し、--reviewオーバーライドなしの場合を考えます。- ステージ宣言: adversarial
- スコープ上限: advisory
- オーバーライド: なし（制限せず）
low-winsルールにより、有効クラスはadvisoryです。反論ループには入らず、1回のレビューパスで承認ゲートに進みます。
自律Boltの免除
自律Swarm（Bolt）内のレビューは、スコープ上限と実行時オーバーライドの両方から免除されます。Bolt内ではレビューがマージ前の唯一の検証手段であるため、ステージ宣言のクラスがそのまま適用されます。
6. デフォルトの割り当て
ステージ別のレビュークラス
advisoryがデフォルトのステージ（7ステージ、Ideation/Inception）と、adversarialのままのステージ（5ステージ、Construction）に分かれています。
| ステージ | フェーズ | レビューエージェント | クラス |
|---|---|---|---|
| intent-capture | Ideation | aidlc-product-lead-agent | advisory |
| rough-mockups | Ideation | aidlc-product-lead-agent | advisory |
| requirements-analysis | Inception | aidlc-product-lead-agent | advisory |
| user-stories | Inception | aidlc-product-lead-agent | advisory |
| refined-mockups | Inception | aidlc-product-lead-agent | advisory |
| domain-design | Inception | aidlc-architecture-reviewer-agent | advisory |
| units-generation | Inception | aidlc-architecture-reviewer-agent | advisory |
| contract-design | Inception | aidlc-architecture-reviewer-agent | advisory |
| functional-design | Construction | aidlc-architecture-reviewer-agent | adversarial |
| nfr-requirements | Construction | aidlc-architecture-reviewer-agent | adversarial |
| nfr-design | Construction | aidlc-architecture-reviewer-agent | adversarial |
| infrastructure-design | Construction | aidlc-architecture-reviewer-agent | adversarial |
| code-generation | Construction | aidlc-architecture-reviewer-agent | adversarial |
Ideation/Inceptionの散文ステージは人間承認付きゲートがあるため、adversarialの反復ループよりも、advisoryの所見を人間が判断する方が効率的です。Constructionの設計・実装ステージは成果物の整合性が後工程に直結するため、adversarialを維持しています。
スコープ別のreview_cap
| スコープ | review_cap | 効果 |
|---|---|---|
| bugfix | advisory | adversarialステージもadvisoryに引き下げ |
| poc | advisory | adversarialステージもadvisoryに引き下げ |
| workshop | advisory | adversarialステージもadvisoryに引き下げ |
| enterprise | なし（宣言なし） | ステージ宣言のまま |
| feature | なし（宣言なし） | ステージ宣言のまま |
| mvp | なし（宣言なし） | ステージ宣言のまま |
| infra | なし（宣言なし） | ステージ宣言のまま |
| refactor | なし（宣言なし） | ステージ宣言のまま |
| security-patch | なし（宣言なし） | ステージ宣言のまま |
bugfix、poc、workshopは軽量スコープであり、反復レビューのコストに見合わないケースが多いため、スコープ全体でadvisoryに上限を設定しています。
7. 使い方
ワークフロー開始時に指定する
1
/aidlc --review advisory Build a REST API for user managementこの場合、ワークフロー全体でadvisoryが上限になります。adversarialを宣言したステージもadvisoryで動作します。
実行中に変更する
1
/aidlc --review none以降のステージでレビューを省略します。レビューエージェントは起動せず、完了レシートも不要になります。
オーバーライドをクリアする
1
/aidlc --review adversarialオーバーライドが解除され、ステージ宣言とスコープ上限だけで解決されます。クラスを引き上げる効果はありません。
現在の設定を確認する
1
2
/aidlc config get review
/aidlc config listconfig get reviewでReview Overrideフィールドの現在値を確認できます。config listは深さ・テスト戦略とあわせて一覧表示します。注意点
--review noneを指定しても、自律Bolt内のレビューは免除されません。Bolt内ではステージ宣言のクラスが常に適用されます- レビューエージェントのティアはmedium推論負荷に固定されています。クラスを変えてもエージェントの推論コストは変わりません。変わるのは反復回数と、それに伴う待ち時間です
- 状態ファイル（
aidlc-state.md）にReview Overrideが記録され、REVIEW_CLASS_CHANGED監査イベントが発行されます
8. まとめ
Reviewer Classの設計意図を一言でまとめると、「レビューの重さをステージの性質に合わせる」ことで、品質を落とさずにワークフローの待ち時間を削減する仕組みです。
要点を整理します。
- 3クラス: adversarial（反復検証）、advisory（単発助言）、none（省略）
- 解決ルール: ステージ宣言 × スコープ上限 × 実行時オーバーライドのうち、最も軽いクラスが有効（low-wins）
- デフォルト配分: Ideation/Inceptionの散文7ステージはadvisory、Constructionの設計5ステージはadversarial
- 自律Bolt免除: 人間の承認ゲートが存在しないBolt内では、スコープ上限とオーバーライドは無効。ステージ宣言がそのまま適用される
ライブ計測で12分以上かかっていたInceptionステージのレビューが、advisoryへの切り替えで反復ループを省略し、大幅に短縮されました。品質は人間の承認ゲートが担保し、レビューエージェントはその判断材料を効率的に提供する。Reviewer Classはこの役割分担を仕組みとして実現しています。
Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 22AI-DLC Workflow V2のReviewer Class: レビューの重さを選べる仕組み This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article