本記事の位置づけ — 本記事は、
awslabs/aidlc-workflowsリポジトリの規範ルールおよび利用ガイドを素材として、筆者が AI を活用して読み解き、まとめた解釈です。AWS が公式に発表した方法論ではなく、一次資料の翻訳・要約でもありません。シリーズ — 本記事は AIで紐解くAI-DLC v2 シリーズの一部です。
参照した版 — Claude Code 実装を対象に、2026 年 8 月 4 日時点のコミット
c73ee984（AIDLC_VERSION 2.5.37、core/）を参照しています。Claude Code 以外の実装（Kiro CLI／Kiro IDE／Codex CLI／opencode）は対象外で、記述が異なる場合があります。OSS 実装は更新が続いているため、最新の状態は公式リポジトリをご確認ください。
概要
AI-DLC v2 を自分のチームと案件に入れるべきか。この問いに、一次資料（core/）は直接の答えを持ちません。core で裏取りできるのは「何を・どこまで・どんな前提でできるか」という能力と制約までで、そこから先の「だから誰に向くか」は読み手が引く推論です。ただ一つ、想定用途を公式が一行で明言した一次資料があります。9種あるスコープそれぞれの description です。
本記事では、このスコープの想定用途を軸に据え、導入で引き受けるものと引き換えに得るものを並べて、どんなチーム・案件に素直に向くのかを読み解きます。
判断の出発点
導入判断は、リード／アーキテクト／EM が「この案件に AI-DLC v2 を通すか」を決める場面です。ところが一次資料を読んでも、「導入すべき／すべきでない」と述べた箇所は見当たりません。core が示すのは、機構の能力と制約までです。
そこで本記事は、事実が示す能力と制約を判断の材料へ読み替える役に徹します。機構そのものは説明せず、各論は深掘り記事へ送ります。他の進め方との優劣も論じません。扱うのは、core が実際に支える範囲から見た案件・チームとの相性だけです。
幸い、判断の手がかりになる一次資料が一つだけあります。スコープ定義の description です。これを最初の判断軸にします。
案件タイプという判断軸
最初に効くのは「今回はどの種類の案件か」です。AI-DLC v2 は案件の種類を9つのスコープで表し、各スコープのファイルがフロントマターの description に「何のためのものか」を一行で書いています。これは推論ではなく、公式が置いた一次の表明です。
この description を手がかりとして読み替えたのが次の表です。EXECUTE 列は、そのスコープが全32ステージのうち実際に何本を走らせるかを表します。
| スコープ | description（原文） | EXECUTE | 向く案件 |
|---|---|---|---|
enterprise |
Regulated enterprise feature, full audit trail | 32 / 32 | 規制・監査証跡が要る本番機能 |
feature |
Default for new features, practical depth | 32 / 32 | 新機能全般。迷ったらここ（既定） |
workshop |
Facilitated group session with mandatory gates | 25 / 32 | 研修・ハンズオン・集合演習 |
mvp |
Skip operations, ship the core | 22 / 32 | 運用を後回しにコアを最短で出す案件 |
infra |
Infrastructure changes | 13 / 32 | インフラ変更 |
security-patch |
CVE response | 10 / 32 | 脆弱性に急いで対応する案件 |
poc |
Prove feasibility fast | 8 / 32 | 実現可能性を素早く確かめる検証 |
refactor |
Clean up existing code | 8 / 32 | 振る舞いを変えない整理 |
bugfix |
Fix a specific bug | 7 / 32 | 特定バグの修正 |
読み方は二つです。description は公式が想定する案件像をそのまま言い当てているので、手元の案件がどれに近いかで最初の見当がつきます。EXECUTE 数は通す工程の重さで、同じ「導入する」でも enterprise の32工程と bugfix の7工程では引き受ける手間がまるで違います。案件タイプを選ぶことは、通す工程数を選ぶことでもあります。
スコープを選ぶ機構そのもの（自動推定・--scope・深さの既定）は別記事「スコープ」で、各工程をどこまで作り込むかの深さは別記事「深さ」で扱います。
導入で引き受けるもの
導入すると何を背負うのか。core から読み取れる負担は次のとおりです。
毎ステージの承認
初期化の3工程を除き、通すステージのすべてに承認ゲートが付きます。人が「承認」と言うまでワークフローは進みません。ゲートの数はスコープで決まり、全工程を通す feature や enterprise なら29、bugfix なら4です。しかもこの承認権限は持ち越されません。あるステージで「おすすめで進めて」と答えても、それはそのステージ限りで、次のステージには引き継がれません。自律で走らせるには、対象ステージごとに人が明示で許可する必要があります。
放置に近づけられる唯一の場所は、構築フェーズの Bolt（構築の実行単位）ループです。最初の Bolt は設定に関わらず常にゲート付きで、その直後の問いかけで「自律（autonomous）」か「Bolt ごとに承認（gated）」かを一度だけ選びます。autonomous を選んでも、コード生成が失敗したときは必ず止まって人に確認します。導入するチームは、各工程で成果物を確認・承認する運用を引き受けます。承認の差し戻しや「現状で承認」の仕組みは別記事「承認ゲート」で、最初の Bolt が常に止まる理由は別記事「ウォーキングスケルトン」で扱います。
助言どまりの機械検証
AI-DLC v2 の機械検証（センサー5種）は、すべて助言（advisory）として出荷されます。成果物を独立に評価するレビュアーも同じく助言にとどまり、NOT-READY を返してもワークフローは止まりません。中身を見て止められるのは承認ゲートの人だけです（証拠が揃わないと完了を拒む機械的な前提条件は別にあり、後述のアーティファクト・ガードもその一つです）。つまり「ツールが品質を保証する」とは読めません。センサーもレビュアーも穴を可視化して人を助ける第二の目で、品質の最終責任は人に残ります。導入しても、レビュー工数はそのまま要ります。レビュアーの往復判定は別記事「レビュアー」で、保存ごとに走るセンサーは別記事「センサー」で扱います。
破壊的変更に追随する成熟度
ワークフローの進行を記録する状態ファイルについて、その形式の移行ツールは出さない方針が core 自身に書かれています。古い形式を検出すると、診断コマンドは「ワークスペースをアーカイブして始め直せ」と促します。コード中のコメントはこれを「1.0 前は移行を出さない方針（pre-1.0 no-migration policy）」と明言します。宣言した成果物がディスクに無いとステージの完了を拒むアーティファクト・ガードも入っており、それを前提にしていなかった自動化スクリプトはそこで止まります。
加えて、core は特定のモデルを指定しません。各エージェントが宣言するのは仕事の性質を表す tier: で、判断を要する9体が judgment、レビュアー2体が balanced、定型の3体が templated です。ビルドがこれを各ハーネスのモデル指定へ投影します。
Claude Code では judgment の9体がセッションのモデルをそのまま引き継ぎます。つまり弱いモデルでセッションを開始すれば、委譲先も弱いままです。フレームワークが勝手に格上げすることはないので、モデルの選択がそのまま成果物の質に出ます。
ハーネス側の出荷設定はさらに踏み込んでいます。dist/claude/.claude/settings.json は Fable・Opus・Sonnet の各モデル ID に [1m] を付け、1M コンテキストの変種を指定します。オーケストレーターだけでなく、tier から投影されたモデルで動くサブエージェントも 1M コンテキストになります（Haiku は 1M の変種が無いため据え置き）。この構成をそのまま使うには、AWS Bedrock でそれらのモデルへのアクセスが有効になっている必要があります。
導入は「一度入れて固定」ではなく、破壊的変更に追随し、進行中のワークフローを作り直す覚悟を含みます。成熟度の限界は別記事「限界と注意点」で扱います。
引き換えに得るもの
引き受けるものの裏返しが、得るものです。承認ゲート・決定論的なエンジン・学習ループという三つの仕組みは、導入する側から見ると、人の主導権（重要な決定はすべて承認ゲートを通る）、予測可能性（次にやることはエンジンが決め、LLM には委ねない）、学習の蓄積（人の修正を恒久ルールにして以後へ持ち越す）になります。
| 得るもの | 何が嬉しいか |
|---|---|
| 主導権 | AI の速度を使いつつ、意思決定は人が握り続けられる |
| 予測可能性 | 同じスコープなら同じ工程・同じ承認の形で進む |
| 学習の蓄積 | チームの修正が一箇所に溜まり、次の案件は前回より賢く始まる |
これらが効くのは、「AI に速く書かせたいが、人が置いていかれるのは困る」チームです。逆に小さな使い捨てスクリプトを最速で出したいだけなら、全工程にゲートを敷く設計はそのぶん重くなります（その用途には poc や bugfix の細い道が用意されています）。この三つの仕組みがなぜこの形なのかは別記事「設計思想」で扱います。
導入判断のフレーム
ここまでを一枚にすると、導入判断は「案件タイプ → 通す工程の重さ → 引き受けるもの」の対応で読めます。
そのうえで、入れる前に自問することがあります。
- 毎ステージの承認の手間を払えるか。払えないなら、放置自動化を期待した導入は噛み合いません。
- 人のレビュー工数を残せるか。センサーもレビュアーも助言にとどまり、品質の最終責任は人に残ります。
- 動く標的に追随できるか。破壊的変更と作り直しを許容できる、実験・パイロット的な座組みか。
三つに「はい」と言えるチームの、description に合う案件。そこが AI-DLC v2 の素直な導入先です。
まとめ
導入判断は、core の事実を三段で読み替える作業です。案件タイプ（スコープの description）で向きを見当づけ、通す工程数で重さを測り、承認・レビュー・成熟度という引き受けるものと、主導権・予測可能性・学習という得るものを天秤にかけます。一次資料に「導入すべき」の一語はありませんが、判断軸の材料はすべて core の中にあります。全体像は別記事「概念マップ」で扱います。
参照元
| ファイル | 内容 |
|---|---|
core/scopes/（9ファイル） |
スコープ9種の定義。各フロントマター description（想定用途の一次表明）と EXECUTE/SKIP の散文。判断軸テーブルの正本 |
core/aidlc-common/stages/（32ファイル） |
全32ステージ。各フロントマター scopes: の集計が EXECUTE 実数（32/32/25/22/13/10/8/8/7）の正本 |
knowledge/aidlc-shared/ai-dlc-principles.md |
「Not every task requires every stage.」と、7つの中核原則（人が決める／深さの適応／追跡可能な成果物／複数役割の専門性／創発的振る舞いの禁止／仮定より質問／矛盾の検出） |
aidlc-common/protocols/stage-protocol.md |
初期化3工程を除く全ステージの承認ゲート、自律は推論しない（遵守チェックリスト項目6）、autonomous/gated、ウォーキングスケルトンとラダープロンプト、失敗時の halt-and-ask |
core/sensors/ |
センサー5種すべて助言（advisory・止めない） |
core/agents/（14ファイル） |
エージェント14体の tier: 宣言（judgment 9／balanced 2／templated 3）。core は素のモデル名を持たず、ビルドが各ハーネスのキーへ投影する |
dist/claude/.claude/settings.json |
ハーネス固有の出荷設定。Fable・Opus・Sonnet のモデル ID に付く [1m]（Haiku は据え置き）、AWS_REGION、事前承認ツール |
tools/aidlc-version.ts |
AIDLC_VERSION = "2.5.37" |
tools/aidlc-utility.ts |
旧版検出時の archive-and-reinit 促しと「pre-1.0 no-migration policy」 |
tools/aidlc-lib.ts |
配布物5種（Claude Code・Kiro CLI・Kiro IDE・Codex CLI・opencode）。ハーネスのディレクトリは4種（Kiro の2つが .kiro を共有） |
関連記事
前の記事: 限界と注意点
次の記事: 並列実行
目次: AIで紐解くAI-DLC v2