AI-DLC Workflow V2のDepthとTest Strategy: アーティファクトの粒度とテスト量を独立に制御する
スコープを選べばステージ構成が決まる。ここまでは分かった。でも各ステージが出すドキュメントの詳しさや、テストの数はどうやって調整するの？ 実はDepthとTest Strategyという独立した2つのノブがあります。シリーズ第14回。
Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 14AI-DLC Workflow V2のDepthとTest Strategy: アーティファクトの粒度とテスト量を独立に制御する This article
1. はじめに
この記事はAI-DLC Workflow V2シリーズの第14回です。
第4回 で、スコープによって33ステージのうちどれを実行し、どれをスキップするかが決まる仕組みを見ました。第5回 ではAdaptive Composerがタスクの特性からカスタムスコープを動的に提案する仕組みを扱いました。
しかしスコープが決めるのは「どのステージを通るか」まで。同じ
featureスコープでも、あるプロジェクトでは簡潔な設計書と最小限のテストで十分だし、別のプロジェクトでは監査対応の詳細ドキュメントと徹底的なテストが必要です。この粒度の違いを制御する仕組みが、DepthとTest Strategyです。この記事では、V2が持つ3つの制御軸のうち残り2つ、Depth（深度）とTest Strategy（テスト戦略）を見ていきます。スコープがワークフローの「形」を決めるのに対し、DepthとTest Strategyはワークフローの「密度」を決める仕組みです。
2. 3つの制御軸の整理
まず全体像を整理します。V2のワークフローは、3つの独立した軸で制御されます。
スコープ（振り返り）
覚えているでしょうか。スコープは「33ステージのうちどれをEXECUTE（実行）し、どれをSKIP（スキップ）するか」を定義したグリッドです。
featureなら全33ステージ、bugfixなら7ステージ、pocなら8ステージ。タスクの性質によって、ワークフローに含まれるステージ数が変わります。
Depth（深度）
Depthは「各ステージが出力するアーティファクトの詳細度」を制御します。同じステージを実行しても、DepthがMinimalなら1〜2ページの要約、Comprehensiveなら網羅的なドキュメントが生成されます。ステージの選択（スコープ）とは独立に設定できます。
Test Strategy（テスト戦略）
Test Strategyは「生成されるテストの量と種類」を制御します。Minimalなら要件ごとに1テスト、Comprehensiveならコンポーネントあたり10〜15テストに全種別（ユニット、インテグレーション、E2E、パフォーマンス、セキュリティ）が含まれます。
3軸の独立性
ここで重要なのは、この3軸が独立に設定できる点です。
- スコープ = どのステージを実行するか
- Depth = アーティファクトの詳しさ
- Test Strategy = テストの量と種類
たとえば「スコープは
feature（全33ステージ実行）、DepthはMinimal（ドキュメントは簡潔に）、Test StrategyはComprehensive（テストは徹底的に）」という組み合わせが成立します。ドキュメントは軽いがテストは厚い、というプロジェクト方針を表現できるわけです。3. Depthの3レベル
Depthの3レベルを詳しく見ていきましょう。
Minimal: 核心のみ
Minimalは最小限の出力です。各ステージは核心的な決定事項だけを記録し、オプションのセクションはスキップします。
- 1〜2ページのアーティファクト
- 主要な決定事項のみ記載
- オプションセクションは省略
- 補足分析や代替案の詳細説明は含まない
向いている場面は、バグ修正やパッチ、概念実証（PoC）など、速度が優先される作業です。
Standard: バランスの取れた詳細度
Standardはデフォルトの出力レベルです。必須セクションが漏れなく含まれ、決定の根拠も簡潔に記述されます。
- 完全なアーティファクト（全必須セクション含む）
- 決定事項に根拠が付く
- 簡潔ながら十分な説明
ほとんどの新機能開発やMVPに適しています。「なぜその決定をしたか」が後から追えるだけの情報が残ります。
Comprehensive: エンタープライズ向けの網羅性
Comprehensiveは監査証跡やコンプライアンスが求められる環境向けです。
- 拡張アーティファクト（オプションセクションも含む）
- 詳細な正当化の記述
- コンプライアンスマトリクスとの相互参照
- 網羅的なNFR（非機能要件）仕様
Minimalが開発チーム内で次のステージに進むための最小記録だとすれば、Comprehensiveは「なぜこの判断をしたか」を設計に関わっていない第三者に説明できる水準です。規制対応や社内監査のあるプロジェクトで選ばれます。
ステージ出力の変化
では、同じステージでDepthが変わると出力がどう変わるか。Requirements Analysis（要件分析）ステージを例に見てみます。
| 観点 | Minimal | Standard | Comprehensive |
|---|---|---|---|
| ドキュメントの長さ | 1〜2ページ | 完全な要件書 | 網羅的な要件書＋補足資料 |
| 代替案の記載 | なし | 簡潔な根拠 | 詳細なトレードオフ分析 |
| 非機能要件 | 主要項目のみ | 標準的なNFRセクション | 詳細なNFR仕様＋コンプライアンス参照 |
| 関連するゲート質問 | 少ない | 標準的 | 多い（網羅的な確認） |
言い換えれば、Depthが上がるほどステージの「密度」が増します。ステージ数は変わらないが、各ステージでの作業量とアーティファクトの情報量が変わる。これがDepthの本質です。
4. Test Strategyの3レベル
次にTest Strategy（テスト戦略）を見ていきます。Depthがアーティファクト全般の詳細度を制御するのに対し、Test Strategyはテストの量と種類に特化した軸です。
Minimal: 最小テストモデル（Nyquist model）
Minimalの着想は信号処理のNyquist率（ナイキスト率）から来ています。信号を正しく復元するために必要な最小サンプリング周波数のことで、V2ではこれを「正しさを確認するために必要な最小テスト数」に読み替えています。
具体的な基準は以下のとおりです。
- 識別された要件1つにつきテスト1つ（要件駆動であり、コンポーネント駆動ではない）
- コンポーネントごとにhappy-path（正常系）のユニットテストが少なくとも1つ（要件がマップされていなくても保証）
- ユニットテストのみ。インテグレーション、E2E、パフォーマンス、セキュリティテストは生成しない
- 典型的なプロジェクトで合計約5〜15テスト
ワークショップやトレーニング、概念実証、バグ修正など、テストスイートへの投資よりもスピードが重要な場面に向いています。
これらの数値は目安であり、厳密な上限ではありません。安全上の理由でエージェントがこの範囲を超える判断をすることもあります。
Standard: コンポーネント単位モデル
Standardはコンポーネント間の境界を検証するバランスの取れたカバレッジです。
- コンポーネントあたり5〜8テスト
- ユニットテスト＋インテグレーションテスト（コンポーネント間の主要な境界）
- E2E、パフォーマンス、セキュリティテストはNFR要件が明示的に求める場合のみ
- テストピラミッドの比率: 約75%ユニット / 約20%インテグレーション / 約5% E2E
新機能開発やMVPに適しています。過剰投資なしに、コンポーネント間の結合点が検証される水準です。
Comprehensive: フルカバレッジモデル
Comprehensiveは全テスト種別にまたがる徹底的なカバレッジです。
- コンポーネントあたり10〜15テスト
- 全テスト種別: ユニット＋インテグレーション＋E2E＋パフォーマンス（NFRが存在する場合）＋セキュリティ（NFRが存在する場合）
- テストピラミッドの比率が全種別にわたって適用される
エンタープライズ機能や規制システム、テストカバレッジの監査証跡が求められる環境に向いています。
3レベルの比較表
| 観点 | Minimal | Standard | Comprehensive |
|---|---|---|---|
| テスト数の目安 | 要件1つにつき1テスト（計5〜15） | コンポーネントあたり5〜8 | コンポーネントあたり10〜15 |
| テスト種別 | ユニットのみ | ユニット＋インテグレーション | 全種別（ユニット/インテグレーション/E2E/パフォーマンス/セキュリティ） |
| 駆動単位 | 要件ごと | コンポーネントごと | コンポーネントごと（全種別展開） |
| 最低保証 | コンポーネントごとhappy-path 1つ | 左記を内包 | 左記を内包 |
| テストピラミッド | 適用なし（ユニットのみ） | 75% / 20% / 5% | 全種別にわたり適用 |
5. スコープごとのデフォルト設定
ここまでDepthとTest Strategyの各レベルを見てきました。では、9つのスコープそれぞれでデフォルトがどう設定されているかを確認します。
デフォルトの原則
基本原則はシンプルです。ほとんどのスコープでは、Test StrategyのデフォルトはDepthと同じ値を継承します。DepthがStandardならTest StrategyもStandard、MinimalならMinimal。
ただし1つ例外があります。
workshopスコープだけは、DepthがStandardなのにTest StrategyはMinimalです。この理由は表の後で説明します。9スコープの比較表
| スコープ | 実行ステージ数 | Depth（デフォルト） | Test Strategy（デフォルト） | 用途 |
|---|---|---|---|---|
enterprise | 33 / 33 | Comprehensive | Comprehensive | 規制対応のエンタープライズ機能 |
feature | 33 / 33 | Standard | Standard | 新機能開発（デフォルトスコープ） |
mvp | 23 / 33 | Standard | Standard | グリーンフィールドのMVP |
poc | 8 / 33 | Minimal | Minimal | 実現可能性の検証 |
bugfix | 7 / 33 | Minimal | Minimal | バグ修正 |
refactor | 8 / 33 | Minimal | Minimal | コードの再構成 |
infra | 13 / 33 | Standard | Standard | インフラ変更 |
security-patch | 10 / 33 | Minimal | Minimal | CVE対応 |
workshop | 26 / 33 | Standard | Minimal | ワークショップ・トレーニング |
workshopの特殊性
表を見ると、
workshopだけDepthとTest Strategyが異なっています。DepthはStandard、Test StrategyはMinimal。この組み合わせには明確な意図があります。ワークショップでは参加者が各ステージの出力アーティファクトを読んで学ぶため、ドキュメントの詳細度（Depth）はStandardが必要です。一方、テストの量は学習目的では重要ではなく、むしろテスト生成に時間を取られるとワークショップのペースが落ちます。そこでTest StrategyだけをMinimal（最小テストモデル）に下げ、「アーティファクトは学習に十分な詳細度、テストは最小限」というバランスを実現しています。
この
workshopスコープの設計が、DepthとTest Strategyを独立した軸として分離する意義をよく表しています。もしDepthとテスト量が1つの軸に結合されていたら、「ドキュメントは詳しいがテストは少ない」という組み合わせは表現できません。6. 組み合わせの柔軟性
DepthとTest Strategyはスコープのデフォルトから独立に上書きできます。この柔軟性をもう少し掘り下げます。
上書きのタイミング
上書きは3つのタイミングで可能です。
- ワークフロー開始時のCLIフラグ:
/aidlc --depth comprehensiveや/aidlc --test-strategy minimalで指定 - スコープ確認時の返答: スコープが提示された時に
--depth <level>で返す - 任意の承認ゲート: ワークフロー実行中のどの承認ゲートでも、フィードバックとして異なるレベルを要求できる
組み合わせの例を見てみましょう。
1
/aidlc --scope bugfix --depth standardこの指定は「バグ修正の7ステージ構成で実行するが、各ステージのアーティファクトはStandardの詳細度で出力する」という意味になります。スコープとDepthをそれぞれ独立に指定しています。
1
/aidlc --depth standard --test-strategy minimalDepthとTest Strategyを別々に指定することも可能です。「ドキュメントはStandard、テストはMinimal」。workshopスコープのデフォルトと同じ組み合わせを、他のスコープでも実現できます。
代表的な6パターン
実際によく使われる組み合わせを整理します。
| Depth | Test Strategy | 効果 | 向いている場面 |
|---|---|---|---|
| Standard | Standard | 標準的なアーティファクト、バランスの取れたテスト | 一般的な新機能開発（デフォルト） |
| Standard | Minimal | 標準的なアーティファクト、最小テスト | ワークショップ、タイムボックスのあるセッション |
| Minimal | Minimal | 簡潔なアーティファクト、簡潔なテスト | バグ修正、パッチ |
| Comprehensive | Comprehensive | 網羅的なアーティファクトと網羅的なテスト | 規制対応のエンタープライズ機能 |
| Comprehensive | Standard | 網羅的なアーティファクト、バランスの取れたテスト | エンタープライズだがテストは実用主義的に |
| Minimal | Comprehensive | 簡潔なアーティファクト、徹底的なテスト | 重要なバグ修正で確信が必要な場合 |
最後の「Minimal × Comprehensive」に注目してください。ドキュメントは最小限だが、テストは徹底的に書く。「バグの原因は分かっている。設計書は要らない。でも修正が正しいことをテストで証明したい」という場面で使える組み合わせです。
このような対角的な組み合わせが成立するのは、DepthとTest Strategyが独立した軸だからです。もし「詳細度」という1つのノブしかなければ、ドキュメントもテストも一律に上げ下げするしかありません。
スコープとの組み合わせ
3軸の組み合わせはさらに柔軟です。たとえば以下のような指定ができます。
1
/aidlc --scope enterprise --depth standard --test-strategy standardこれは「全33ステージを実行するが（enterprise）、各ステージの出力はStandard詳細度に抑え（depth）、テスト量もStandardにする（test strategy）」という意味です。enterpriseスコープのデフォルトはDepth=Comprehensive / Test Strategy=Comprehensiveですが、チームの判断でそれを緩和しています。
逆に、軽いスコープで密度を上げることもできます。
1
/aidlc --scope poc --depth standard --test-strategy standard概念実証（8ステージ）だが、アーティファクトとテストはStandard水準で出力する。PoC段階でもある程度のドキュメントとテストを残しておきたい場合の選択です。
7. まとめ
この記事ではV2のワークフローを制御する3つの独立した軸を見てきました。
スコープが「どのステージを実行するか」を決め、Depthが「各ステージの出力をどれだけ詳しくするか」を決め、Test Strategyが「テストをどれだけ書くか」を決めます。この3つは互いに独立に設定できるため、プロジェクトの性質に応じて細かく調整が可能です。
重要なのは、この独立性が設計上の偶然ではなく、明確な意図を持っている点です。
- ドキュメントは詳しく書きたいがテストは最小限にしたいワークショップ
- ドキュメントは簡潔でいいがテストの確信は欲しい重要バグ修正
- 全ステージ動かすがアーティファクトは軽くしたい反復開発中のエンタープライズ
こうした現実のプロジェクト状況は、1つのスライダーでは表現できません。3軸の独立性があるから、ワークフローの「形」と「密度」を別々に調整できるのです。
自分のプロジェクトで迷ったときの考え方をまとめます。
- まずスコープを選ぶ。タスクの性質に合うスコープが33ステージの構成を決めます
- デフォルトのDepthとTest Strategyで始める。ほとんどの場合、スコープのデフォルト値が適切です
- 必要に応じて上書きする。承認ゲートのどのタイミングでも変更できるため、最初から完璧に決める必要はありません
3つの軸はそれぞれ異なる問いに答えています。「何を作るか」（スコープ）、「どこまで説明するか」（Depth）、「どこまで検証するか」（Test Strategy）。自分のプロジェクトでこの3つの問いに別々に答えることが、V2のワークフロー設定の基本です。
Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 14AI-DLC Workflow V2のDepthとTest Strategy: アーティファクトの粒度とテスト量を独立に制御する 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