AI-DLCとは？モブエラボレーション・Boltの進め方とWorkflows v2の使い方【2.11対応】

AI-DLC（AI-Driven Development Life Cycle／AI駆動開発ライフサイクル）は、AWSが2025年7月に公表した、AIに計画と草案づくりを主導させ、人間は検証と意思決定に回る開発方法論です。要件を詰める場は「モブエラボレーション」、実装を詰める場は「モブコンストラクション」と呼ばれ、スプリントは数時間〜数日で回す「Bolt」に置き換わります。方法論を実行する道具としてAWSはawslabs/aidlc-workflowsをOSSで公開しており、2026年10月19日時点の安定版はv2系の2.11.0です。本記事では用語と3フェーズ、モブエラボレーションの進め方を整理したうえで、2.11.0を実際に導入して確かめた設定時の挙動、国内事例、導入の判断基準までを解説します。

まとめ：AI-DLCとモブエラボレーション、Workflows v2の要点

• 定義：AWSが2025年7月31日に公表した方法論。AIが計画を立てて質問し、人間が承認してから実装に進む。
• 用語：Intent（目的）→ Unit of Work（作業単位）→ Bolt（時間〜日単位の最小の反復）。スクラムのエピック・スプリントに対応する。
• モブエラボレーション：Inceptionで職種横断のチームがAIの質問と提案をその場で検証する場。ホワイトペーパーは数週間〜数か月の逐次作業を数時間に凝縮するとしている。
• Workflows v2：進行をTypeScript製のエンジンが管理する実装。安定版は2.11.0（2026年10月8日）で、Claude Code・Kiro・Codex CLI・Cursor・opencode・GitHub Copilotに対応する。
• 導入の注意：aidlc configは既存の.claude/CLAUDE.mdがあると衝突として止まる。v2の合議（collaborators）はenterprise以外では既定でオフ。
• 判断：モブの場でAIの提案を評価できる業務担当とエンジニアが揃うなら、小さな新規機能から自走できる。

AI-DLCとは：AWSが2025年に示した定義と登場した背景

AWSは2025年7月31日、DevOpsブログのAI-Driven Development Life Cycle: Reimagining Software EngineeringでAI-DLCを公表しました（日本語訳はAI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築）。原典の骨子は「AIが実行し人間が監視する」と「ダイナミックなチームコラボレーション」の2点です。AIは作業計画を作り、意図のすり合わせのための質問を投げ、重要な決定は人間に委ねます。

AI支援型・AI管理型との違い：AIの進行と人間の意思決定

AWSのSkill Builderコースを紹介したAWS Japanブログは、AI-DLCを既存プロセスにAIを狭く後付けする「AI支援型（AI-Assisted）」とも、AIが自律的に作り切る「AI管理型（AI-Managed）」とも異なるものと位置づけています。コード補完はAI支援型、指示だけ出して放置するのはAI管理型にあたり、AI-DLCはその中間で、AIが計画・タスク分解・設計案を主導しつつ、承認ゲートでは必ず人間が止めます。

AI-DLC登場の背景：コーディング以外の工程に残る待ち時間

同ブログは「コーディング工程の時短は実現できても、開発ライフサイクル全体のアジリティには繋がっていない」という課題に対するAWSの回答がAI-DLCだと説明しています。原典も、計画・会議といったSDLCの儀式に時間の大部分が使われていると指摘しています。AIを補助として足すだけでは、待ち時間の多い工程が残るという問題意識です。開発支援ツールの全体像はCoding Agent（コーディングエージェント）とは？仕組み・3つの型と主要ツールの選び方、AWS側のツールがAmazon Q DeveloperからKiroへ移った経緯はAmazon Q Developerの料金｜Free・Pro Tierの上限とKiro移行後の費用で整理しています。

AI-DLCの基本用語：Intent・Unit・Boltとスクラム用語の対応

AI-DLCは、スクラムの用語を置き換える形で独自の語を定義しています。定義の出典はAI-DLCのホワイトペーパー（Method Definition Paper）です。

Intent（意図）：達成したいビジネス目標を書く起点

ホワイトペーパーはIntentを、達成すべきビジネス目標・機能・技術的成果を表す「high-level statement of purpose」と定義しています。「在庫照会をAPIで外部に公開したい」程度の粒度で書き、足りない条件はAIが質問で埋めていきます。条件や例外を最初から構文で書き分けたいときは、EARS記法による要件の書き方が下書きの型として使えます。

Unit of Work（作業単位）：Intentから切り出す自己完結した作業要素

UnitはIntentから導かれる「cohesive, self-contained work element」で、それ単体で測定可能な価値を届ける大きさに切ります。原典ではDDDのサブドメインやスクラムのエピックに相当するものとされ、疎結合に分割して独立した開発・デプロイを可能にします。v2のConstructionでは、Unitの依存グラフに沿って独立したUnitが同時に実行されます。

Bolt（ボルト）：スプリントより短い最小の反復

Boltはホワイトペーパーで「smallest iteration in AI-DLC」とされ、Unitまたはその中のタスク群を時間〜日単位で実装する反復です。スクラムガイドではスプリントを1か月以下の固定期間と定めています。Boltは、AIの草案に人間がすぐ判断を返す前提で反復を短くします。なおv2の実装では、Boltは「Delivery Planning」ステージで記録する計画上のデリバリーの区切りで、実行時の並列バッチとは別物だとAWS社員のAWS Builder Centerの解説は説明しています。方法論のBoltとツール上の実行単位を混同しないようにしてください。

3フェーズの流れ：Inception・Construction・Operations

方法論としてのAI-DLCは3フェーズで進みます。各フェーズの計画・要件・設計はリポジトリに保存され、次のフェーズとセッションをまたいで文脈として引き継がれます。

Inceptionフェーズ：Intentから要件・ストーリー・Unitへの具体化

AIがIntentを詳細な要件・ユーザーストーリー・Unitへ変換し、チームがモブエラボレーションで検証します。「何を作るか」をここで確定させるため、上流の判断ミスは後工程すべてに響きます。

Constructionフェーズ：AIによる設計・コード・テストの提案

Inceptionで検証した文脈をもとに、AIが論理アーキテクチャ・ドメインモデル・コード・テストを提案し、チームはモブコンストラクションで技術判断をその場で決めます。

Operationsフェーズ：チームの監督下でのIaC管理とデプロイ

前フェーズまでの文脈を使い、AIがInfrastructure as Codeとデプロイを扱い、チームが監督します。

v2の5フェーズ・33ステージとの対応

実装側のWorkflows v2は、3フェーズの前に初期化とアイデア検討を足した5フェーズ・33ステージで構成されています。2.11.0を導入したプロジェクトの.claude/settings.jsonに書き込まれる案内文から、内訳は次のとおりでした。

全ステージを毎回通すわけではありません。依頼内容から「スコープ」が選ばれ、たとえばbugfixはIDEATIONを飛ばしてリバースエンジニアリング・要件分析・コード生成・ビルドとテスト・デプロイだけを実行します。

モブエラボレーションの進め方：参加者・所要時間・成果物

モブエラボレーション（Mob Elaboration）は、Inceptionフェーズで職種横断のチームが同じ場に集まり、AIが出す質問と提案をその場で検証して要件を固める作業です。elaborationは「推敲」「入念な準備」を意味する英単語で、日本語訳の原典にもその訳註が付いています。ここが機能しないと、後工程の速さは得られません。

モブエラボレーションの参加者と時間：職種横断の体制と原典が示す数時間

AWSの金融サービス向けのAI-DLC解説は、開発者・プロダクトマネージャー・ビジネスアナリスト・QAエンジニアといった職種横断のチームがモブプログラミングの形式で協働すると説明しています。ホワイトペーパーは、従来なら数週間〜数か月かけていた逐次の作業を「a few hours」に凝縮するとしています。東京海上日動システムズのワークショップでは、AIが出力した内容をビジネス側と開発者がレビューし、AIに修正を指示する様子が紹介されています。運営するときは、AIの質問を全員が見える画面に出し、業務担当がその場で答え、エンジニアと品質担当が実現性とテストのしやすさを指摘する分担にすると、質問を持ち帰らずに済みます。

成果物：PRFAQ・ユーザーストーリー・NFR・リスク・推奨Bolt

ホワイトペーパーが挙げるInceptionの成果物は、定義済みのUnitに加えて、PRFAQ（プレスリリースと想定問答）、ユーザーストーリー、非機能要件（NFR）、リスクの記述、ビジネス意図に結び付く測定基準、推奨されるBoltです。会議の議事録ではなく、次のConstructionでAIがそのまま読む文書を残すのが目的です。「誰のための機能か」「例外をどう扱うか」への答えが受け入れ基準として文章になっていなければ、その場の合意はAIに引き継がれません。

v2での実装：AIエージェント同士の合議とcollaboratorsの既定値

Workflows v2では、モブエラボレーションがINCEPTIONの「User Stories」ステージに組み込まれています。2.11.0のステージ定義を読むと、このステージはmode: mobで動き、プロダクトマネージャー役のエージェントがペルソナとストーリーの草案を書き、デザイン・開発・品質の各エージェントが互いの意見を見ずに別々の観点で寄稿し、最後にプロダクトリーダー役がレビューする手順になっています。ストーリーにはUS1.1、受け入れ基準にはAC1.1.1形式のIDが振られます。

ただし、この合議が動くのは協働者（collaborators）が有効なときだけです。導入直後の11スコープの設定を確認したところ、collaborators: onはenterpriseだけで、feature・mvp・workshopなど残り10スコープはoffでした。2.11.0のリリースノートも、enterprise以外ではリードのエージェントだけで進み、合議は/aidlc --collaborators onで有効にすると書いています。AIエージェントの合議は人間のモブの代わりではありません。人間が集まって答える場は、v2を使っても別に設ける必要があります。

モブコンストラクション：設計と実装に関するリアルタイムの意思決定

モブコンストラクション（Mob Construction）はConstructionフェーズの合同検証で、AIが提案した論理アーキテクチャ・ドメインモデル・コード・テストに対し、チームが技術判断とアーキテクチャの選択をリアルタイムで明確にします。Skill Builderのコースでは、最初のBoltで端から端まで動く最小構成を作って構成を証明する「Walking Skeleton」もここで扱われています。

レビューが人間のボトルネックになる問題とv2の2つのループ

AIの生成量に人間のレビューが追いつかない問題は、Qiitaの実践報告でも「AIではなく人間がボトルネックになる」と報告されています。AWS Builder Centerのv2解説は、v1を「全サイクルで人間が検証するモデル」と呼び、人間が検証を一手に担う限り処理速度は頭打ちになるとして、v2ではAIとツールが自己検証するインナーループと、人間が承認ゲートや設計判断だけに関わるアウターループに分けたと説明しています。各ステージにはレビュー専任のエージェントが付きます。人間の修正指示をルールとして蓄積する学習機能もありますが、同じ誤りの再発を保証するものではなく、2.11.0のスコープ定義ではbugfixとexpressで既定がオフでした。それでも承認者が少なすぎるとアウターループで詰まるため、誰がどの成果物を承認するかは着手前に決めておきます。作業単位ごとに記録を残す発想はチケット駆動開発（TiDD）のNo Ticket, No Commitのルールとも重なります。

従来手法との違い：アジャイル・AI-SDLC・仕様駆動開発との比較

アジャイル（スクラム）との違い：反復の長さと計画の主導権

スクラムは1か月以下の固定期間のスプリントで区切り、プロダクトオーナーがプロダクトバックログの並び順に責任を持ちます。AI-DLCでは反復が数時間〜数日のBoltになり、IntentをUnitへ分解する作業と計画の草案をAIが担います。違いは、計画を最初に書くのが人間かAIかにあります。

AI-SDLCとの違い：一般概念とAWSが定義した方法論

「AI-SDLC」は既存のSDLCの各工程にAIを取り入れる一般的な概念を指すことが多い言葉です。AI-DLCは、Intent・Unit・Bolt・モブといった用語とプロセスモデルを伴う、AWSが定義した特定の方法論です。検索や社内資料で混ざりやすいため、どちらの話かを最初に確認してください。

仕様駆動開発（SDD）との違い：成果物起点か工程起点か

仕様駆動開発は、要件・設計・タスクの仕様書を先に固め、エージェントにその仕様どおり実装させる手法です。AI-DLCも仕様に当たる成果物を残しますが、主眼はチームの役割分担と反復の回し方、つまり工程全体の設計にあります。考え方は仕様駆動開発（SDD）とは？従来手法との違いとSpec Kitで試す手順、ツールの違いは仕様駆動開発ツール比較｜Spec Kit・Kiro・cc-sdd・OpenSpec・Tesslの違いと選び方で解説しています。なおAI-DLCは、スクラムでは各チームの裁量だったDDDなどの設計技法を方法論の中核に組み込んでおり、v2にも「Domain Design」ステージがあります。

AI-DLC Workflows v2の変更点：ルールファイルから決定論的エンジンへ

awslabs/aidlc-workflowsの公開：2025年11月のルールファイル版から

AWSは2025年11月29日、DevOpsブログのOpen-Sourcing Adaptive Workflows for AI-Driven Development Life Cycle (AI-DLC)で、Amazon Q DeveloperのルールとKiroのステアリングファイルとして実装したワークフローをOSSにしました。案件の規模に応じて実行する段階を変える適応型の設計で、ライセンスはMIT-0です。

v1とv2の違い：LLMからエンジンへの進行管理の移管

v1はエージェントがルールファイルを読み、次に何をするかをLLM自身が判断する方式でした。v2はTypeScriptで作り直され、どのステージを実行するか、承認を通したかをエンジンが管理します。LLMはエンジンに問い合わせて、指示された1つの作業を実行するだけです。

v2.11.0のREADMEは、14のエージェント（ドメイン専門11・レビュアー2・構成を組み立てる役1）、11のワークフロープロファイル、115イベントの監査証跡を挙げています。8月時点の解説記事では9スコープ・74イベントとされており、版ごとに数字が増えているため、引用するときは版を添えてください。推奨モデルはREADMEではClaude Opus 4.8で、Builder Centerの解説は弱いモデルだとステージの飛ばしやゲートの省略が起こりうると注意しています。

版の推移：2026年6月の2.0.0から10月の2.11.0まで

変更履歴（CHANGELOG）では2.0.0の日付が2026年6月18日で、READMEのPreview表記をGAに改めるPR #620は7月22日にマージされました。GitHubのReleasesを2026年10月19日に確認すると、v1系の最終はv1.0.1（6月30日）、v2系の安定版は2.7.0（9月1日）・2.8.0（9月8日）・2.9.0（9月15日）・2.10.0（9月24日）・2.11.0（10月8日）と1〜2週間おきに出ています。日付付きの2.11.1プレビュー版はほぼ毎日公開されていますが、10月17日版のリリースノートには「Full Suite failed」の警告とmacOSの検証失敗が記載されていました。業務ではプレビューを避け、Latest表示の安定版を使ってください。

対応するハーネス7種と最低バージョン

v2では、エージェントごとの差を吸収する層を「ハーネス」と呼びます。v2.11.0のREADMEに載っている対応先と条件は次のとおりです。各エージェントの特徴はKiroとは？AWS製の仕様駆動AI IDEの特徴・料金・使い方やClaude Codeとは？できること・使い方・料金で解説しています。

v1の解説でよく出てくるAmazon Q DeveloperとClineは、v2の対応表にありません。それらを使い続けるならv1系の選択になります。

AI-DLC Workflows v2の使い方：2.11.0を入れてaidlc doctorを通すまで

ここからは、2026年10月19日にmacOSで2.11.0を導入し、Claude Code向けに設定した手順と結果です。手元の設定を汚さないよう、HOMEを一時ディレクトリに向けて実行しました。

aidlcのインストール：OS別の2.11.0固定コマンド

READMEのQuick Startは最新の安定版を入れる1行ですが、チームで版を揃えるならリリースノートにある版指定の形を使います。BunやNode.jsは不要です。

# macOS / Linux / WSL（2.11.0に固定）
curl -fsSL https://github.com/awslabs/aidlc-workflows/releases/download/v2.11.0/install.sh | sh -s -- --version 2.11.0

# Windows PowerShell（2.11.0に固定）
irm https://github.com/awslabs/aidlc-workflows/releases/download/v2.11.0/install.ps1 -OutFile install.ps1
./install.ps1 -Version 2.11.0

macOSとLinuxでは、コマンドは~/.local/binに、本体は~/.local/share/aidlcに入ります（環境変数AIDLC_BIN_DIR・AIDLC_INSTALL_ROOTで変更可）。実行するとchecksums.txtと来歴情報（aidlc-release.intoto.jsonl）を取得してSHA-256で照合したうえで「PASS installed AI-DLC 2.11.0 with all harness runtimes」と表示され、PATHへの追加方法が案内されました。パイプ実行が禁止されている端末では、install.shを保存して中身を確認してから実行します。

aidlc configでプロジェクトを設定する：作られるファイルと衝突時の挙動

cd /path/to/your-project
aidlc config --harness claude
aidlc doctor

空のGitリポジトリでaidlc config --harness claude --yesを実行すると、324ファイルが作られました。.claude/配下（約10MB）に14のエージェント定義、11のスコープ定義、スキル、フック、エンジンのツール群が入り、aidlc/配下にチームの記録とメモリ、.gitignoreには「BEGIN AI-DLC:gitignore」で囲んだ除外設定が追記されます。

既存のプロジェクトに入れるときに知っておきたい挙動が2つあります。

• 既存の.claude/CLAUDE.mdがあると止まる：自前の.claude/CLAUDE.mdを置いた状態で実行すると、「1 config conflict(s)」と表示されて終了コード4で止まり、何も書き換えませんでした。上書きするなら--force、残すならファイルを移してから再実行し、変更内容はaidlc config --dry-run --verboseで事前に確認できます。ルート直下のCLAUDE.mdは触られませんでした。
• .claude/settings.jsonは併合される：独自の許可設定（Bash(npm test)）を入れたsettings.jsonは残ったまま、AI-DLCのフック登録と許可エントリが追加されました。既存の.gitignoreの行も残ります。

aidlc doctorの結果を読む：導入直後の4つの警告

aidlc doctorはMachine・Project・Framework integrityの3区分で点検し、導入直後のプロジェクトでは「0 problems, 4 warnings」でした。警告は、PATHがシェルにしか通っていない、更新確認のキャッシュが無い、このプロジェクトでまだフックが一度も動いていない、aidlc/配下に未コミットの記録がある、の4件です。フックの警告は最初のチャット前には出るのが正常で、doctor自身もそう説明します。READMEのトラブルシューティングも「まずプロジェクトのルートでaidlc doctor」を最初の手順にしています。aidlc/の記録はgitで共有する前提なので、チームで使うならコミットしてください。

/aidlcでIntentを渡す：スコープの選ばれ方

設定したプロジェクトでClaude Codeを起動し、チャット欄に次を入力します。設定時にそのフォルダでClaude Codeを開いていた場合は、終了して起動し直してください。

/aidlc Build a REST API for inventory management

Codex CLIは$aidlc、Kiro IDEはチャット欄のエージェント選択で「aidlc」を選びます。依頼文からスコープが自動で選ばれ、足りない判断は質問され、承認ゲートで止まります。途中で/aidlc --statusで進み具合を確認でき、ステージの追加や省略は--add・--skipで指示します。最初の1本は、範囲が小さく正解を人間が判断できる題材にすると、ステージの進み方と承認の重さを短時間でつかめます。

v1から移るとき・版を上げるときの注意

v1で進めている案件を途中でv2へ切り替えると、どこまで承認したかの記録が引き継がれないため、案件の切れ目で移行します。v2の版を上げるときは、2.11.0のリリースノートにあるとおりaidlc updateのあとにプロジェクトでaidlc config --yesとaidlc doctorを実行します。版が1〜2週間おきに出るので、チームで使う版を決めて、安定版が出たときにまとめて上げる運用が無難です。

AI-DLCの導入事例：東京海上・合同Unicorn Gym・各社の実践

国内の事例は、AWSが主催するワークショップ「AI-DLC Unicorn Gym」が中心です。多くはv2の登場前で、方法論やv1のルールを使った取り組みです。

東京海上日動システムズ：4チームが1.5日で初版を作った金融業界初の事例

AWS Japanブログの事例記事によると、2025年8月26日と27日に金融業界初のAI-DLC Unicorn Gymが行われ、4チームが動作する初版を完成させ、1チームはテスト環境へのデプロイまで終えました。

10名のチームにはビジネス部門・システム部門・パートナーが入っており、モブエラボレーションに業務側が同席した構成です。

11社合同Unicorn Gym：8週間想定の開発が2日間で完了

2026年1月22〜23日にAWS Loft Tokyoで開かれた11社合同のUnicorn Gymでは、IT資産管理システムで「当初8週間を想定していた開発が2日間で完了」、IoTセンサーデータの分析システムで「当初6ヶ月を想定していた内容」を2日間で進めたと報告されています。金融機関向けの更改では、10人弱で1か月近く会議を重ねていた要件定義のドキュメント化が6人・2日間に短縮されたという声も紹介されています。

DMM・Gaudiyの実践：意思決定の課題と継続運用

DMM.comはUnicorn Gymへの参加報告で、モブ形式で意思決定が速くなる一方、リモートワークでの実現方法、ステークホルダーが多い案件でのバッチサイズの問題を挙げ、スコープを小さくすることが最大の課題だとしています。Gaudiyは2025年12月にテックブログで、ホワイトペーパーの概念を自社流に解釈してClaude Codeで3か月運用した知見を公開しており、単発のワークショップではない継続運用の例です。

AI-DLCの課題と導入判断：適用条件・学習方法・内製体制

技術的・組織的な課題：文脈の長さと暗黙知の形式知化

技術面では、コンテキスト長の制約で大きなプロジェクト全体を一度に扱えないため、成果物をリポジトリに残してAIに小分けに渡します。既存案件に適用したBeeXの報告では、4ユニット分の設計文書が数千行規模になり、どこまでを正式な設計資産として保守するかが早い段階で課題になったとしています。組織面では、AIに渡す規約・ADR・ドメイン知識の明文化と、承認者を決めるリーダー層の関与が前提です。

AI-DLCの適用条件：スコープの独立性と承認体制

効きやすいのは、スコープを小さく切り出せる新規機能と、少人数で意思決定を完結できるチームです。ステークホルダーが多く承認に時間がかかる案件や、依存関係が密で1つの変更が広く波及するレガシーシステムでは、DMMが挙げたバッチサイズの問題が足かせになり、全面適用は避けるべきです。若手だけのチームで試したQiitaの実践報告は、AIの提案を「なんとなく良さそう」で通しがちだったとして、経験のあるレビュアーを1人入れることを勧めています。原典が示すのは「数週間かかっていたタスクを数時間または数日で」という方向性で、倍率の保証ではありません。

まず学ぶなら：AWS Skill Builderの無料ナレッジバッジ

AWS Japanブログが2026年9月1日に紹介した「AI 駆動開発ライフサイクル (AI-DLC) ナレッジバッジ」は、英語版「AI-DLC Foundations」の日本語版で、誰でも無料で受講できます。8モジュールで、9つの原則、7つのベストプラクティス、One-Way Door／Two-Way Doorの意思決定、InceptionとConstructionのDeep Diveを扱い、最後の理解度テストに合格するとバッジが取得できます。チーム全員がこのコースで用語を揃えてからモブエラボレーションに臨むと、当日の説明時間を判断に回せます。

自社だけで始めるか、開発パートナーと組むか：提案を評価できる人の有無

分かれ目は、モブの場でAIの提案を評価できる人がいるかどうかです。要件の妥当性を判断できる業務担当と、生成コードの設計やセキュリティを判断できるエンジニアが揃っていれば、v2の安定版を小さな題材で試すところから自走できます。どちらかが欠ける場合や既存システムの改修を題材にしたい場合は、AIを組み込んだ開発の経験がある外部と1案件だけ伴走し、承認フローとテンプレートを社内に残すのが手戻りの少ない進め方です。一創の生成AI開発・AI受託開発では、生成AIを前提にした開発プロセスの設計から実装までを支援しています。

よくある質問：AI-DLCとモブエラボレーション、v2について5問

AI-DLCとは何の略ですか？

AI-Driven Development Life Cycle（AI駆動開発ライフサイクル）の略です。AWSが2025年7月に公表した、AIが計画と草案を主導し、人間が検証と意思決定を担う開発方法論を指します。

モブエラボレーションとは何ですか？

Inceptionフェーズで、開発者・プロダクトマネージャー・ビジネスアナリスト・QAなど職種横断のチームが集まり、AIの質問と提案をその場で検証して要件・ユーザーストーリー・Unitを固める作業です。Constructionフェーズで同じことを設計と実装について行うのがモブコンストラクションです。

Bolt（ボルト）とは何ですか？

AI-DLCにおける最小の反復で、スクラムのスプリントに相当しますが、週ではなく時間〜日単位で回します。AIの草案に人間がすぐ判断を返す前提の単位です。

AI-DLC Workflows v2は無料で使えますか？v1とどちらを選ぶべきですか？

awslabs/aidlc-workflowsはMIT-0ライセンスのOSSで、ワークフロー自体は無料です。費用がかかるのは、組み合わせるClaude CodeやKiro、Codex CLIなどエージェント側の利用料です。これから始めるならv2系の安定版（2026年10月19日時点で2.11.0）を選び、Amazon Q DeveloperやClineなどv2の対応表に無いエージェントを使い続ける場合に限ってv1系を検討します。

AI-DLCはAWSやKiro以外の環境でも使えますか？

使えます。方法論そのものはクラウドやモデルに依存せず、v2のREADMEも方法論はプロバイダー非依存だとしています。v2はClaude Code・Codex CLI・Cursor・opencode・GitHub Copilotでも動き、モデルの設定は各エージェント側の設定がそのまま使われます。

関連記事

• 仕様駆動開発（SDD）とは？従来手法との違いとSpec Kitで試す手順【2026年10月】
• 仕様駆動開発ツール比較｜Spec Kit・Kiro・cc-sdd・OpenSpec・Tesslの違いと選び方
• Kiroとは？AWS製の仕様駆動AI IDEの特徴・料金・使い方を解説【2026年版】
• Claude Codeとは？できること・使い方・料金：コード解析の実力と導入手順【2026年版】
• Coding Agent（コーディングエージェント）とは？仕組み・3つの型と主要ツールの選び方【2026年9月】