本記事の位置づけ — 本記事は、
awslabs/aidlc-workflowsリポジトリの規範ルールおよび利用ガイドを素材として、筆者が AI を活用して読み解き、まとめた解釈です。AWS が公式に発表した方法論ではなく、一次資料の翻訳・要約でもありません。シリーズ — 本記事は AIで紐解くAI-DLC v2 シリーズの一部です。
参照した版 — Claude Code 実装を対象に、2026 年 6 月時点の v2.1.3（コミット
c95070e、core/）を参照しています。Kiro・Codex 実装は対象外で、記述が異なる場合があります。OSS 実装は更新が続いているため、最新の状態は公式リポジトリをご確認ください。
概要
深さ（depth）は、ワークフローが各ステージで成果物をどこまで作り込むかを決める設定です。実行するステージの数は変えません。一つひとつの作り込みの丁寧さ、つまりコンダクター（進行役の AI）が出す質問の数と、出来上がる成果物の詳しさが変わります。値は最小限・標準・網羅的の3段階で、同じステージを浅くも深くも回せます。
深さがあるおかげで、バグ修正のような軽い案件は要点だけに絞り、規制対応のような重い案件は隅々まで詰める、という調整が一つの仕組みの中でできます。本記事では、深さがどの3段階を取り、テストの作り込みを決めるテスト戦略とどう分かれ、いつどう変えられるのかを読み解きます。
振る舞いを決める3つの軸
AI-DLC v2 には、ワークフローの振る舞いを変える独立した軸が3つあります。深さはそのうち「各ステージの作り込み」を受け持ちます。
| 軸 | 決めること |
|---|---|
| スコープ | どのステージを実行するか |
| 深さ | 各ステージをどこまで作り込むか |
| テスト戦略 | テストをどこまで作り込むか |
スコープには9つの種類があり、案件の性質に応じて実行するステージを切り替えます。その一覧と使い分けは別記事「スコープ」で扱います。本記事は残る2つ、深さとテスト戦略に集中します。
3段階の深さ
深さが取りうる値は、最小限（Minimal）・標準（Standard）・網羅的（Comprehensive）の3段階です。
| 深さ | 成果物の作り込み | 向く場面 |
|---|---|---|
| 最小限 | 核心の判断だけを薄く。任意の項目は省く | バグ修正・パッチ・PoC |
| 標準 | 必要な項目をひと通り揃え、根拠も簡潔に明記 | ほとんどの機能開発・MVP |
| 網羅的 | 要件の洗い出し、非機能要件、コンプライアンス、監査文書まで | 規制対応・エンタープライズ |
変わるのは、成果物の分量と、コンダクターが各ステージで出す質問の数です。最小限なら1ステージあたり2〜4問で手早く進み、標準は5〜8問、網羅的は8問以上かけて隅々まで詰めます。これらは目安であって上限ではなく、説明が曖昧なら最小限でも質問を増やしますし、要件が明確なら網羅的でも減らします。なお、回答どうしの矛盾の検出と解消だけは、どの深さでも必ず行います。
テスト戦略との分離
深さは成果物（文書・図・質問）の作り込みだけを決め、テストの本数には関与しません。テストをどこまで作り込むかは、テスト戦略という別の軸が受け持ちます。テスト戦略の値も深さと同じ最小限・標準・網羅的の3段階です。
両者が分かれているおかげで、「成果物は標準でしっかり作るが、テストは最小限で速く回す」といった組み合わせが選べます。テスト戦略の既定は深さに追従し、深さを標準にすればテスト戦略も標準になります。例外は研修向けの workshop スコープだけで、深さは標準のまま、テスト戦略だけを最小限にします。学びのために成果物は揃えつつ、テストは軽くしてペースを保つ狙いです。
--test-strategy フラグを使えば、深さと独立にテスト戦略だけを上書きできます。--depth standard --test-strategy minimal とすれば、標準の成果物に最小限のテスト、という構成になります。
既定値と変更のタイミング
深さの既定値はスコープが決めます。どのスコープがどの深さを既定にするかは別記事「スコープ」で扱います。決まった既定は、ワークフローの初期化で状態ファイル（aidlc-state.md）に書き込まれて確定します。
そのうえで、人は後から深さを変えられます。変更できる場面は3つです。
| タイミング | やり方 |
|---|---|
| 起動時 |
--depth フラグで指定（例：--scope bugfix --depth comprehensive） |
| スコープ確認時 | 提示されたスコープを確認する場面で深さを変更 |
| 承認ゲート | やり直しのフィードバックとして別の深さを要求 |
優先順位は単純で、明示的な指定があればそれを、なければスコープの既定を使います。深さやテスト戦略を変えると、監査ログに DEPTH_CHANGED／TEST_STRATEGY_CHANGED として記録が残ります。承認ゲートそのものは別記事「承認ゲート」で扱います。
具体例
同じステージ群を通しても、深さが変われば成果物の重さは大きく変わります。
| 案件 | 深さ | 成果物の作り込み |
|---|---|---|
| バグ修正 | 最小限 | 修正に必要な質問のみ。要件は数件、設計判断記録（ADR）なし |
| 機能開発 | 標準 | 標準の作り込み。要件十数〜数十件、ADR 数件 |
| 規制対応 | 網羅的 | 最大限の作り込み。代替案分析つきの ADR、コンプライアンス文書まで |
エンジンもエージェントもステージの数も変わりません。変わるのは「どこまで掘るか」だけです。
参照元
| ファイル | 内容 |
|---|---|
core/tools/aidlc-utility.ts |
深さ・テスト戦略の enum（minimal/standard/comprehensive）と解決ロジック（テスト戦略の既定は深さに追従） |
core/aidlc-common/protocols/stage-protocol.md |
§8 深さ別の質問数の目安・成果物スケール、承認ゲートでの変更、矛盾検出は全深さで必須 |
core/scopes/（9ファイル） |
各スコープの depth 既定。aidlc-workshop.md のみ testStrategy: Minimal を分離 |
core/tools/aidlc-audit.ts |
監査イベント DEPTH_CHANGED／TEST_STRATEGY_CHANGED の定義 |
関連記事
前の記事: スコープ
次の記事: 成果物の流れ
目次: AIで紐解くAI-DLC v2