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