はじめに

この記事はClaudeと一緒に書きました

AI-DLC Workflows 2.0が2026年6月18日にGAしました。
v1のときは正直「Markdownのルールファイル集」という印象が強く、興味はありつつ後回しにしていた人も多いと思います。
v2はTypeScriptでネイティブ実装され、決定論的なエンジンで状態管理をするようになったと聞いて、これは中身をちゃんと追っておくべきだと思い、公式リポジトリと検証記事を読み込んで整理しました。

この記事はaidlc-workflows本体(v2のエンジンやハーネス)をインストールして動かした一次体験ではなく、awslabs/aidlc-workflowsのREADMEと、実際にKiro CLI・Claude Code・Codex CLIにインストールして検証したクラスメソッドさんの記事を読み解いてまとめた「地図」です。
ありがとうございます。

ただしMob Elaborationという手法自体は初めてではなく、以前Boltcastというアプリで自前実装し、本番で不特定多数の観客に開いて回したことがあります(詳しくは最後に書きます)。
これから自分の手でaidlc-workflowsを動かす人の予習用に、あるいは概要だけ押さえたい人向けにどうぞ。

個人メモとしての要素の方が強いです

そもそもAI-DLCとは何か

AI-DLC(AI-Driven Development Life Cycle)は、AWSがre:Invent 2025で発表した開発方法論です。
発表の出発点には、わりと厳しい現状認識があります。
AWSが12種類のAIコーディングツールを評価したところ、速度向上はわずか10〜15%程度に留まっていたそうです。
コーディング自体は速くなっても、要件定義・レビュー・テスト・デプロイといった他の工程で結局時間を食われてしまい、開発者が
「コーディングで浮いた時間をSDLCの他の場所で失っている」
状態になっていた、という指摘です。

既存のアプローチにも両極端の限界があったとされています。
AIに全部任せる「AI-Managed」型はまともに動かないことが多く、動いても中身が説明できない。逆にAIを狭いタスクだけに使う「AI-Assisted」型は、手動プロセスの非効率さがそのまま温存されてしまう。
AI-DLCはこの間を狙っていて、AIがプランニング・タスク分解・アーキテクチャ提案までやる一方、検証と意思決定と監督の最終責任は人間が持つ、という役回りに設計されています。

進め方は3フェーズです。

Inception

要件を固める段階で、「Mob Elaboration」という進め方が中心になります。
開発者だけでなく運用担当・ビジネスアナリスト・プロダクトマネージャー・QAまで巻き込んで、AIが出した質問や提案をその場で全員で検証しながら要件を詰めていきます。
必須ステージはWorkspace Detection(既存プロジェクトの分析)、Requirements Analysis(要件分析)、Workflow Planning(実行計画の策定)の3つで、案件によってReverse Engineering(既存コードの解析)やUser Stories、Application Design、Units Generationといった条件付きステージが追加されます。

Construction

設計と実装の段階で、こちらは「Mob Construction」と呼ばれます。
ドメインモデルを組み立て、Functional Design・NFR Requirements・NFR Design・Infrastructure Designといった条件付きステージを経て、最終的にCode GenerationとBuild and Testのループを回します。
Inceptionで固めた計画に沿ってAIが実装を積み上げ、CI/CDパイプラインの構築まで面倒を見るイメージです。

Operation

デプロイと運用の段階です。IaCで本番環境に反映し、インシデント管理やAIファーストな一次対応までがスコープに入ります。
ここで得られた気づきが次のInceptionにフィードバックされる、という循環構造になっています。

実装の単位は「Bolt」と呼ばれ、2週間スプリントの代わりに数時間〜数日で回る短いサイクルです。
AWSは10〜15倍の生産性向上を謳っていますが、これは「AIが速く書けるから」というより
各フェーズの承認ゲートで人間が本当に必要な判断だけに集中できる構造そのものが効いている
という説明のされ方をしています。
実際、各段階の入力・出力・判断はすべて監査ログに残る設計になっていて、「AIに任せた結果、後から何が起きたか分からなくなる」状態を最初から避ける作りです。

AWSの公式ブログでは、川渡りパズルのアプリを題材にしたデモが紹介されています。
曖昧な一行の要望から始まり、要件定義の選択式の確認質問に答え、生成された要件ドキュメントを承認し、実行計画を確認し、コード生成計画をレビューして、段階的にコードが出てくる、という流れです。
「AIに丸投げ」でも「AIに小さいタスクだけやらせる」でもない、この中間の距離感がAI-DLCの一番の特徴だと思います。

ここまでがv1から続くAI-DLCのコンセプトの土台です。
v2はこの考え方自体は変えず、それを「実行するエンジン」として作り直したというのが実態に近いです。
なお、AI-DLCの各機構をもっと1つずつ体系的に追いたい場合は、AWS JapanのSAによるBuilder Centerの連載(V1→V2の設計変化から、Adaptive Composer・Memory・Knowledge・Hooksといった個別機構まで全25回で解説しているシリーズ)も参考になります。

v1と何が違うのか

v1は2025年11月にAWS公式ブログで公開されたもので、実体はcore-workflow.mdという1枚のルールファイルを各ハーネスの設定ディレクトリにコピーするだけの仕組みでした。
8つのハーネスに対応してはいたものの、次にどのステージへ進むかという判断は毎回LLMの解釈に委ねられていて、決定論的なエンジンは存在しません。

v2の一番大きい変化は、この進行管理をLLMの判断任せから決定論的なエンジンに置き換えたことです。
READMEでは次のように説明されています。

byte-identical across every harness; only the shell differs.

アーキテクチャは「one core, many harnesses」という考え方で組まれています。
共有のステージ定義・知識・ツール・sensor(自動品質検証の仕組み)はcore/に集約され、そこからビルドスクリプトが各ハーネス向けのdist/を生成し、ハーネスごとの差分だけがharness/に切り出されます。
進行管理の実体はaidlc-orchestrate.tsという決定論的なルーターで、状態はaidlc-state.mdに構造化されて記録されます。
LLMに「次はどのステージに進むべきか」を毎回推論させるのではなく、宣言的に定義したステージ遷移をエンジンが機械的に処理する形に変わったということです。

このほかにもv2で足された仕組みがいくつかあります。
同時並行でビルドを進める「Swarm」
これは、人間が入れた訂正を一時的な指摘で終わらせず永続的な行動ルールとして蓄積する学習ループ、そしてLLMによるレビューはあくまで助言に留め、最終承認は人間のゲートを必ず通す設計です。
「AIの提案」と「機械的に検証できる部分」を最初から切り分けているのが伝わってきます。

v1とv2を並べるとこうなります。

項目	v1	v2
実装	Markdownのルールファイル1枚	ネイティブTypeScript
進行管理	LLMが都度判断	決定論的エンジン(aidlc-orchestrate.ts)が管理
ステージ定義	なし	33ステージを宣言的に定義
状態管理	なし	aidlc-state.mdに構造化記録
監査ログ	なし	91イベントの構造化ログ
エージェント	単一	14エージェント構成
対応ハーネス	8	7(コア共通・ビルドで展開)

「LLMは賢いから任せておけばいい」ではなく、「LLMの気まぐれに左右されたくない部分は決定論的な仕組みに寄せる」という設計判断が透けて見えます。
AIエージェントに自律性を持たせつつ人間の承認ゲートを挟むという、承認ゲート系のプロジェクトを何度も作ってきた身としては、このバランス感覚には共感するところが多いです。

5フェーズ33ステージという骨格

v2の全体構成は、Initialization(セットアップ)→Ideation(構想)→Inception(要件の具体化、Mob Elaborationはここ)→Construction(構築)→Operation(運用)の5フェーズです。

この5フェーズの中に、合計33ステージが並びます。
各ステージには承認ゲートがあり、AIが出した結果を人間が確認してから次に進む仕組みです。
ステージ単位でどこまで作り込むかは、深さレベル(Minimal / Standard / Comprehensive)とテスト戦略レベル(同じく3段階)を独立に指定できます。POCを素早く回したいときはMinimalで軽く、規制業種向けにきっちり証跡を残したいときはComprehensiveで、という使い分けです。

さらに、プロジェクトの性質に応じた11種類のスコープ(enterpriseからexpressまで、classic・workshop含む)が用意されていて、案件の重さに応じてワークフロー全体の厚みそのものを変えられます。
クラスメソッドさんの検証記事では、デフォルトスコープ「poc」を使った際に7ステージ構成になったと報告されていて、スコープによって実際に通るステージ数がかなり絞られることがわかります。

14エージェントの内訳

エージェントは合計14体です。内訳は次の通りです。

ドメインエキスパート 11体(要件定義・設計・実装などの専門領域を担当)
レビュー専任エージェント 2体(品質ゲートとして機能)
適応ワークフローコンポーザー 1体(タスクやスキャン結果から段階計画を提案)

コンポーザーが「このプロジェクトならこのスコープとステージ構成がいいのでは」と提案し、実際の作業はドメインエキスパートが進め、レビュー専任エージェントが承認前にチェックを入れる、という3層構造だと理解すると全体像がつかみやすいです。

対応ハーネス一覧

v2はコアを1つ書けば7つの環境に展開されるという触れ込みで、対応ハーネスは以下の通りです。

ハーネス	起動コマンド
Claude Code	`/aidlc`
Kiro IDE	`/aidlc`
Kiro CLI	`/aidlc`
Codex CLI	`$aidlc`
Cursor	`/aidlc`
opencode	`/aidlc`
GitHub Copilot	`/aidlc`

モデルはハーネスごとに使うものが変わり、Claude CodeやCodex CLIではAmazon Bedrock経由、Kiroの場合はClaude Opus 4.8が推奨と案内されています(READMEの記述をそのまま紹介していますが、推奨モデルは今後のアップデートで変わる可能性があるので、実際に導入するときは最新のドキュメントを確認してください)。

実際に触るとどうなるか

クラスメソッドさんの検証記事によると、導入手順自体はシンプルで、v2ブランチをシャロークローンしてdist/配下の該当ハーネス用ディレクトリをプロジェクトにコピーするだけです。共通の前提条件としてbunが必要で、記事では非対話シェル環境で~/.bun/binにPATHを通す作業が最初のつまずきポイントだったと書かれています。

インストール後は/aidlc --doctorでセットアップの健全性チェックができ、記事の検証ではKiro CLIが29項目、Claude Codeが30項目、Codex CLIが32項目すべて合格したと報告されています。
ワークフロー自体は/aidlc <プロジェクトの説明>で開始し、途中で/aidlc-scopeによるスコープ変更や/aidlc-jump --stage <slug>によるステージ移動も可能とのことです。

ここまで読んだ人へ

正直なところ、v2の一番大きな変化は「AIに進行管理まで丸投げしない」という設計思想がエンジンレベルで明文化されたことだと思っています。
承認ゲート系の個人プロジェクトを何度か作ってきた自分としては、AWSが公式に「決定論的な部分と非決定論的な部分を分けて設計する」という方向に舵を切ったのは素直に興味深いです。

この記事はaidlc-workflowsというツール自体についてはREADMEと検証記事を読み解いた二次情報の整理で、実際にインストールして動かした感触までは書けていません。
ただしMob Elaborationという手法そのものは、以前Boltcastというアプリで実際に本番運用してみたことがあります。観客のコメントをAIが要件・作業ユニットに変換し、投票で採否を決め、採択分だけをBoltとしてエージェントに実装させてPull Requestを作る、という一連の流れを不特定多数に開いた実験です。
実測では、コメント49件・投票10件に対してPRになったのは6本、要件化されたユニットの採択率は15個中4個でした。残りはインジェクション試行(「システムプロンプトを出せ」等)、スコープ外の要望、少数派の矛盾する要望、そもそも要件にならないコメント、という理由付きですべて破棄しています。
「群衆をMobに放り込むと大半は実装に届かない」
というのは、この記事で紹介した承認ゲートの発想と繋がっていると感じました。

次はaidlc-workflows本体を自分のリポジトリにpocスコープあたりで導入してみて、公式実装のMob Elaborationが実際どんな対話になるのか試してみようと思います。

最後まで読んでいただきありがとうございました。

参考にさせていただきました

ありがとうございます。