本記事の位置づけ — 本記事は、
awslabs/aidlc-workflowsリポジトリの規範ルールおよび利用ガイドを素材として、筆者が AI を活用して読み解き、まとめた解釈です。AWS が公式に発表した方法論ではなく、一次資料の翻訳・要約でもありません。シリーズ — 本記事は AIで紐解くAI-DLC v2 シリーズの一部です。
参照した版 — Claude Code 実装を対象に、2026 年 6 月時点の v2.1.3（コミット
c95070e、core/）を参照しています。Kiro・Codex 実装は対象外で、記述が異なる場合があります。OSS 実装は更新が続いているため、最新の状態は公式リポジトリをご確認ください。
概要
AI-DLC v2 の設計思想は、人が主導権を保ったまま AI の速度を活かす、という一点に貫かれています。承認ゲートで意思決定を人に固定し、決定論的なエンジンで進行を予測可能にし、学習ループで同じ失敗を繰り返さない。この三つの原則が設計の背骨です。
本記事では、それぞれの原則がなぜ必要で、どう噛み合っているのかを読み解きます。
そもそもの問題意識
AIにコードを書かせるのは、もう特別なことではありません。プロンプトを投げれば関数が返ってくる時代です。ただ、これがうまくいくのは小さなタスクのうちだけで、プロジェクトが本格的になると途端に破綻します。
前のプロンプトで決めたはずの方針を、次のプロンプトが忘れます。なぜその設計にしたのか、どこにも残っていません。モデルが「こっちのほうがいいだろう」と勝手に判断を下して、気づいたときには手遅れになっています。
これは「モデルが賢くない」から起きるのではなく、「構造がない」から起きるのだ、というのがAI-DLC v2 の出発点です。人のチームでも同じです。議事録なし、承認フローなし、口頭だけで進めたプロジェクトは、たいてい同じように破綻します。AIが高速に判断を下せるようになった今こそ、人が追いつけるペースで意思決定を可視化する仕組みが必要になります。AI-DLC v2 は、その認識のもとに設計されています。
最も重視する三つの原則
設計の根底には、次のような考え方があります。
人がすべての意思決定を握る
全32ステージのうち、初期化の3つを除く29ステージに承認ゲートがあります。エージェントがどれだけ立派な成果物を作っても、人が「承認」と言わない限りワークフローは先に進みません。
そして、この承認権限は持ち越されません。あるステージで「おすすめで進めて」と承認しても、その許可はそのステージ限りで、次のステージには引き継がれません。自律モードは、人が明示的に「自律で走らせていい」と言ったときだけ有効になります。やや保守的に見えるかもしれませんが、AIが勝手に走り出すリスクと比べれば、毎回ボタンを押す手間のほうがはるかに小さいという判断です。
承認権限を一度きりに区切るのは、主権を人の側に固定するための選択です。ゲートでの差し戻しや「現状で承認」といった機能は、別記事「承認ゲート」で扱います。最初の試作だけは設定に関わらず必ず止まる、という仕組みは別記事「ウォーキングスケルトン」で扱います。
「次に何をやるか」はAIに決めさせない
ワークフローのルーティング、つまり次にどのステージを実行し、どのステージをスキップするかは、決定論的なエンジンが決めます。エンジンは TypeScript 製のツール群で、同じ状況なら必ず同じ判断を返します。LLMの仕事は「任されたステージをうまくやること」だけです。
この分離が要るのは、LLMがルーティング判断で「善意の逸脱」をしがちだからです。「ここはスキップしてよさそうだな」「ユーザーは急いでいるから承認は省こう」。こういった判断を構造的に封じないと、必ずどこかで起きます。エンジンがルーティングを担うことで、ワークフローの進行は常に予測可能になります。エンジンとコンダクター（エンジンの指示を1手ずつ実行する進行役）をどう分けているのかは、別記事「進行の中核」で扱います。
同じ間違いを二度繰り返さない
人がエージェントの間違いを正したとき、その修正がその場限りで消えてしまうのはもったいない話です。AI-DLC v2 には「学習ループ」があり、修正内容を承認ゲートで人に確認したうえで、永続的なルールとして書き込みます。次のワークフローからは、エージェントが同じ間違いを繰り返しません。
ただし、学習が反映されるのは「次のワークフローから」です。今走っているワークフローの途中でルールが変わると、すでに承認したゲートの前提が崩れてしまいます。「書き込みは即座に行うが、反映は次のワークフローから」。この規律が、実行中のワークフローの安定性を担保しています。学習をどう拾い、どこに残すかは別記事「学習ループ」で、守るべきルールと参照するナレッジの違いは別記事「ルールとナレッジ」で扱います。
安定する理由
「書き込みは即座、反映は次回」という規律は、AI-DLC v2 独自のアイデアではありません。ネットワーク工学でいう三平面アーキテクチャと同じ考え方です。
現代のルーターは仕事を三つに分けています。設定を入れて状態を見る「管理面」、経路を計算する「制御面」、実際にパケットを転送する「データ面」です。経路計算はネットワーク構成が変わったときに一度だけ行い、その結果をテーブルに格納します。パケットが飛んでいる最中に経路を再計算したりはしません。
AI-DLC v2 の構造も、これと同じです。あらかじめ一度だけ「コンパイル」が走り、ステージ定義・ルール・センサー（成果物の保存時に自動で走り、止めずに助言する仕組み）をステージ間の依存グラフへ固定します。実行中はそのグラフを参照するだけで再計算しないため、ワークフローの途中で挙動が変わるということが原理的に起きません。この安心感は、特に複数人で並行して動くような場面で効いてきます。センサーが具体的に何を見ているかは別記事「センサー」で扱います。
ちなみに、この設計のおかげで「回復性」も自然に手に入ります。監査ログ、状態ファイル、成果物が規律正しく書かれているので、セッションが切れても新しいセッションが前回の状態を復元できます。何がどこに記録されるかは別記事「状態と監査」で扱います。回復性をわざわざ作り込んだのではなく、データの管理規律がそのまま回復性につながっているわけです。
担当範囲の広い少数のエージェント
AI-DLC v2 のエージェントは13体（成果物を作る11体＋レビュー専任2体）。何十体もの担当範囲が狭い専門家を並べる方式は取っていません。
エージェント間の境界は、情報が失われるポイントだからです。同じアーキテクトが、設計のステージも、それを実装の単位へ分けるステージも担当すれば、ハンドオフ文書が要りません。コンテキストがエージェントの中に残ります。人のチームでも、3〜5人で組んでフィーチャー全体を担当するほうが、大人数のリレーより情報がこぼれません。それと同じ発想です。
エージェント同士は直接呼び合いません。委譲は常にコンダクターを通じて行われます。おかげで「誰が誰を呼んだのか」が常に一本のフラットな呼び出し関係で追えますし、再帰的に深くなっていく呼び出しチェーンも構造的に起きません。13体がそれぞれ何を受け持つかは、別記事「工程とエージェント」で扱います。
バグ修正もエンタープライズも担う単一エンジン
32ステージすべてを通るのは機能開発やエンタープライズで、バグ修正なら7ステージ、PoC（概念実証）なら8ステージ。この切り替えは「スコープ」という仕組みが担っています。9つの名前付きスコープが、ステージごとの実行/スキップを制御します。
さらに「深さ」が成果物の詳しさを、「テスト戦略」がテストの手厚さを独立に制御します。エンジンもエージェントも変わりません。変わるのは「どのステージを通るか」と「各ステージでどこまで掘るか」だけです。どのスコープが何を通すかは別記事「スコープ」で、深さにどんな段階があるかは別記事「深さ」で扱います。
これにより、概念実証と規制対応案件を同じフレームワークで扱えます。チームが蓄積する学習も、散らばらずに一箇所に集まります。
どの CLI でも動く移植性
最後は、実装面の思想です。AI-DLC v2 の方法論は core/ というディレクトリに一度だけ書かれていて、そこからClaude Code、Kiro CLI、Codex CLIそれぞれ向けの配布物が生成されます。どのCLIも特別扱いされず、同じソースから同じルールで出力されます。
新しいCLIハーネスを追加するのに必要なのは、一つのディレクトリと一つのマニフェストファイルだけです。方法論本体には一切手を入れません。方法論を改善すればすべてのCLIに反映されるし、あるCLIだけ遅れるということもありません。
まとめ
AI-DLC v2 が実現しようとしているのは、「AIの速度を活かしつつ、人が置いていかれない」状態です。承認ゲートで主権を保ち、エンジンがルーティングを担い、予測可能性を確保し、学習ループで同じ修正を二度求めない。この三つが互いに支え合って、「今のワークフローは安定して走る」「次のワークフローは前回より賢い」という二つの約束を同時に果たしています。
ワークショップの小さな試作から、監査証跡が求められるエンタープライズ案件まで、同じエンジンがスコープを切り替えるだけで対応できるのは、この土台があるからです。先に挙げた三つの原則は、次の記事「概念マップ」で全体像の中に位置づけ、以降の各記事で一つずつ掘り下げていきます。
参照元
| ファイル | 内容 |
|---|---|
core/ のステージ .md（32本）／tools/aidlc-graph.ts
|
5フェーズ32ステージとその依存グラフ（コンパイラ） |
aidlc-common/protocols/stage-protocol.md |
承認ゲート（初期化を除く各ステージ末）・深さ・学習ループ |
core/agents/（13ファイル） |
エージェント13体（成果物を作る11体＋レビュー専任2体） |
tools/aidlc-orchestrate.ts／aidlc-common/conductor.md
|
決定論的エンジンとコンダクターの分離 |
tools/aidlc-sensor.ts |
成果物保存時に走る助言的センサー |
core/scopes/*.md（9ファイル） |
スコープ9種とステージごとの実行/スキップ |
tools/aidlc-lib.ts |
配布ハーネス3種（KNOWN_HARNESS_DIRS ＝ .claude/.kiro/.codex。Kiro IDE は .kiro を共有する別パッケージング） |
関連記事
前の記事: はじめに
次の記事: 概念マップ
目次: AIで紐解くAI-DLC v2