Grandream

公開: 2026.08.1411 min read

AI-DLCとは何か｜AWSが示す「AIが開発を主導し、人間は判断に回る」開発方法論

AIエージェントの開発をご検討中ですか？ AIエージェント開発サービスを見る →

結論から書きます。AI-DLCは「AIにコードを書かせる方法」ではありません。「AIが開発プロセスを主導し、人間は意思決定と監督に回る」という開発方法論です。

ここを取り違えると、AI-DLCは「工程が増えただけの重いフロー」に見えてしまいます。逆にここを押さえると、cc-sddのような仕様駆動開発（SDD）ツールとの違いも、かなりはっきりします。

この記事では、AI-DLCの中心原則・3フェーズ・SDDとの違いを整理したうえで、AWS自身が後から「重い固定フローは失敗する」と否定している点まで含めて見ていきます。

まず、いわゆる「AI活用開発」との違い

AI-DLCは、AWSが2025年7月に公開した方法論です。出発点は、いまのAI活用が抱えている構造的な問題意識にあります。

一般的なコーディングエージェントの使い方は、どちらかというとこうです。

人間：「このAPIを実装して」 AI：「実装しました」

これは AI-assisted development（AI支援開発） です。主役は人間で、AIは道具として補助に入ります。

逆側の極には、完全自律型があります。

人間：「ECサイトを作って」 AI：要件から実装まで全部ひとりで進める

AWSは、このどちらにも問題があると見ています。

	進め方	AWSが見る問題
AI支援開発	人間が考え、設計し、実装する。AIは各作業を補助する	人間中心の古いSDLCがそのまま残るため、効果が工程の一部にしか及ばない
完全自律型	要件から実装まで、AIがひとりで進める	本来人間が負うべきビジネス判断まで、AIに委ねてしまう
AI-DLC	要件化・設計・実装をAIが実行し、人間は判断と承認に立つ	―

そこでAI-DLCが取ったのは、両者の中間を取ることではなく、役割そのものを組み替えるというアプローチでした。

中心原則は「AI Powered Execution + Human Oversight」

AWSが明示している中心原則は、AI Powered Execution with Human Oversight（AIによる実行と、人間による監督）です。意味としては「AIが作業する人、人間が決める人」と捉えて差し支えありません。

従来であれば、エンジニアが「要件の整理 → 設計書 → コード → テスト → IaC」まで担当していました。AI-DLCでは、これをAIが先にやります。人間が引き受けるのは、次のような要所です。

その要件解釈で正しいか
A案とB案なら、どちらを採るか
このアーキテクチャで進めてよいか
このリスクを許容するか

AWS自身も、「AIが計画を作成し、曖昧な点について質問し、人間が検証したうえで実装に進む」というメンタルモデルとして説明しています。ここがAI-DLCで一番重要な部分です。

全体は3フェーズで構成される

AI-DLC全体は、ビジネス上の意図（Business Intent）を起点に、Inception → Construction → Operations の3フェーズで進みます。

AI-DLCの3フェーズ（Inception・Construction・Operations）の流れを示したフロー図

① Inception：何を作るかを決める

最初のフェーズは要件化です。たとえば「LINEで予約管理システムを作りたい」という一言から始まったとき、流れはこうなります。

手番	やること
人間	ビジネス上の意図を渡す（「LINEで予約管理システムを作りたい」）
AI	曖昧な点を質問する（誰が予約するか／キャンセルルール／店舗は複数か／既存システムの有無）
人間	回答し、判断する
AI	Requirements・User Stories・Architecture・Units of Work を作成する

ポイントは、人間が一から要件定義書を書くのではないことです。AIが質問して要件を掘り、人間がそれに答える。この、チーム全体でAIの質問と提案を検証していく進め方を、AWSは Mob Elaboration と呼んでいます。

なお、従来「Epic」と呼ばれていた粒度は、AI-DLCでは Units of Work という呼び方に置き換えられています。

② Construction：実際に作る

次が構築フェーズです。ただしこれは、「設計書を完成させてからプログラマーに渡す」というウォーターフォールではありません。AIが「設計 → 人間と確認 → 実装 → テスト → 人間と確認」を高速に回します。

AWSの説明では、Inceptionで検証済みのコンテキストを使い、AIが論理アーキテクチャ・ドメインモデル・コード・テストまで提案・生成します。ここは Mob Construction と呼ばれ、技術的な判断はチームがその場で明確化していく形を取ります。

③ Operations：作って終わりにしない

3つ目が運用フェーズです。Infrastructure as Code・デプロイ・監視・運用・改善までを、前フェーズで蓄積した同じコンテキストを持ったままAIが扱います。

だから名称も、AI Driven Development Life Cycle（AI駆動開発ライフサイクル） であって、AI Driven Coding ではないわけです。コーディング支援の話ではなく、ライフサイクル全体の再設計として提示されています。

たとえば、実務ではこう変わる

「既存システムにユーザー招待機能を追加したい」というケースで考えてみます。従来型では、担当者間をバトンのように渡っていきます。

PdMが要件をまとめる → エンジニアが設計する → エンジニアがコードを書く → エンジニアがテストを書く → レビュアーが確認する → デプロイ

AI-DLCでは、同じ仕事が次のように分担されます。

担当	やること
Human	「ユーザー招待機能を追加したい」と意図を渡す
AI	既存コードを調査し、疑問点を洗い出す（招待期限は／既存ユーザーへの招待は／権限は誰が設定するか／再送は可能か／メールサービスは既存を使うか）
Human	洗い出された論点を意思決定する
AI	Requirements と Design を作成する
Human	アーキテクチャを承認する
AI	実装・テスト・マイグレーション・IaC を作る
Human	重要な差分だけ確認する
AI	デプロイし、監視する

人間が登場する回数はむしろ増えていますが、中身が変わっています。「作る」から「方向付ける・判断する・検証する」へ移っているわけです。

SDD（仕様駆動開発）との違い

ここは混同されやすいところなので、はっきり分けておきます。

SDDの思想は、基本的にこうです。

Specを先に固定し、それを実装のsource of truthにする

一方、AI-DLCの思想はこうです。

AIを開発ライフサイクルの主実行者にして、人間との対話で継続的に意思決定する

つまり、そもそも軸が違います。

	SDD	AI-DLC
中心	Specification	AI + Human collaboration
主目的	仕様との整合	開発全体のAI化
AIの役割	Specを実装する	開発プロセスを主導する
Humanの役割	Specを書く／確認する	判断・承認する
対象範囲	主に設計〜実装	要件〜運用
Specの位置づけ	非常に重要	手段の一つ

したがって、AI-DLCはSDDを包含することもできますが、SDDである必要はありません。SDDは「仕様の一貫性」を担保する手段であり、AI-DLCから見れば選択肢の一つにすぎない、という関係です。

この理解に立つと、「SDDツールを入れたからAI-DLCをやっている」わけではないことも見えてきます。

Agileとも少し違う：SprintではなくBolt

AI-DLCは、「2週間Sprint」のような従来のサイクルも疑っています。

AWSはSprintの代わりに Bolt という単位を提示していて、これは週単位ではなく、数時間〜数日程度の短く密度の高い作業サイクルを指します。AIによって成果物の生成が高速化するなら、人間の作業速度を前提に決められた週単位の工程を、そのまま維持する理由はない、という考え方です。

これはAI-DLCの本質をよく表しています。「Scrumにコーディングエージェントを足す」のではなく、AIがいることを前提に、SDLC自体を作り直すという提案なわけです。

「Human Oversight」を誤解すると、一気に重くなる

ここが実務上いちばん事故りやすいポイントです。Human Oversightは、「AIが1ファイル変更するたびに人間が承認し、テストを1本足すたびにまた承認する」といったものではありません。

本来、人間が入るべきなのは判断価値の高いポイントだけです。

人間が判断すべき領域	例
Requirement	退会ユーザーのデータを削除するか、保持するか
Architecture	FirestoreとPostgreSQLのどちらで行くか
Security	このAPIをpublicにしてよいか
Business	この仕様変更を許容するか

逆に、関数名・ファイル配置・単体テストの細部・lintエラーの修正といった粒度まで人間が逐一判断していたら、AI-DLCを名乗る意味がありません。

監督とは「全部見ること」ではなく、「見るべきところを決めて、そこだけ確実に見ること」です。ここを設計しないまま導入すると、承認待ちの行列がボトルネックになり、AIを入れる前より遅くなります。

AWS自身も「重い固定フロー」を否定している

見落とされがちですが、これは重要な点です。

AWSは2025年11月、AI-DLCの Adaptive Workflows（適応型ワークフロー） をオープンソースとして公開しました。そこでAWS自身が、既存のAI開発ワークフローの問題として次の3つを挙げています。

挙げられている問題	内容
One-Size-Fits-All Workflow	ハードコードされた画一的な工程に、あらゆる案件を通してしまう
深さを変えられない	各段階の関与の深さを調整できず、過剰設計になる
人間の監督の弱体化	自動化によって開発者が受動的な実行者に流れ、批判的な検証が失われる（process atrophy）

一つ目については、「単純なバグ修正にまで同じRequirements → Design → Implementationの工程を強制すると、不要な成果物・承認・儀式（ceremony）が発生して生産性を落とす」と、かなり明確に書かれています。

つまり本来のAI-DLCは、案件の重さによって工程そのものが変わります。

案件	通す工程
小さなバグ修正	AIが調査 → 実装 → テスト（それだけ）
新規決済システム	Inception → アーキテクチャ設計 → 人間の判断 → Construction → 人間の判断 → Operations

作業内容に応じて、工程の広さ（どの段階を実行するか）と深さ（どこまで厳密にやるか）をAI側が変える。 これが現在AWSが推しているAdaptive Workflowの方向です。「プロセスに問題を合わせるのではなく、問題にプロセスを合わせる」と表現されています。

ここがcc-sddのような固定フローと大きく違う

仕様駆動開発ツールのcc-sddは、v3で自律実装ループを持つようになりました。タスク単位で見ると、「全タスクをImplementer → Reviewer →（必要ならDebugger）の順で回し、終わったら次のタスクへ」という形です。

これは品質の再現性という点では強い一方、プロセスを守ること自体が目的化しやすいという性質も持ちます。1行のtypo修正にも、同じ役割分担が回ってしまうためです。

AI-DLCの本来の思想は逆で、「この作業には何が必要か」を先に判定し、必要な工程だけを選び、重要な判断だけを人間へ上げ、残りはAIが進めます。AWSがrigid workflow（硬直したワークフロー）・工程の深さを変えられないこと・過剰自動化の3つを問題として明示しているのは、まさにこの差を指しています。

補足すると、これはcc-sddが悪いという話ではありません。フローを固定することで品質を安定させる設計と、案件に応じてフローを変える設計は、トレードオフの向きが違うだけです。境界が曖昧で検証が難しい領域なら前者が効きますし、日々の小さな変更が多い現場なら後者が効きます。

ただし、方法論と実装（aidlc-workflows）は分けて考える

ここは分離したほうが健全です。

AI-DLC = 方法論
awslabs/aidlc-workflows = その方法論をコーディングエージェント上で実現する一つの実装

現在の実装は、Amazon Q Developer Rules や Kiro Steering Files の形で提供されていて、かなりトレーサビリティ重視の作りになっています。特徴的なのは、AIがチャット内で質問を投げるのではなく、質問をMarkdownファイルとして書き出し、人間が [Answer]: を埋めて回答し、AIに再読み込みさせるという進め方です。

成果物も、会話の履歴ではなくファイルとして残ります。

aidlc-docs/inception/     要件・ユーザーストーリー・コンポーネント設計
aidlc-docs/construction/  機能設計・非機能要件・インフラ設計・コード生成計画
aidlc-rules/extensions/   組織共通のセキュリティ／コンプライアンス指針

フェーズの境界では「Request Changes」か「Approve and Continue」を明示的に選ぶ承認ゲートが置かれます。会話のコンテキストに依存せず、ファイルを真実の源にする設計です。

この作りは、監査可能性が求められる開発では強い一方、軽い変更には明らかに重い。したがって「AI-DLCの思想は良い」と「AWSのaidlc-workflowsをそのまま使うべき」は、別々に判断すべき話です。思想への同意が、実装一式の採用を意味するわけではありません。

結局、AI-DLCの核はこのループ

3フェーズよりも本質的なのは、次のループだと考えています。

ビジネス上の意図を受け取る
AIが既存システムを調べ、計画を立てる
判断が必要かを切り分ける — 必要なら人間へ上げ、不要ならAIがそのまま実行する
結果を検証する
1に戻る

AIの探索・人間の判断・AIの実行と検証が循環するAI-DLCの中核ループを示した関係図

言い換えれば、AIにできる仕事はAIへ寄せ、人間にしかできない意思決定だけを人間へエスカレーションする。これがAI-DLCの中身です。

この理解に立つと、たとえば「Explore → Design → Human review → Implement → Automated verification」という5工程だけの軽量な進め方も、実はAI-DLCの思想とほとんど矛盾しません。「AIが調べて設計案を出す」「人間は設計の妥当性だけ見る」「実装と検証はAIが回す」という役割配置は、AI-DLCそのものだからです。

むしろ小〜中規模のシステム開発なら、**「AI-DLCの思想＋手元のエージェントの軽量ワークフロー」**のほうが、AWSのワークフロー一式をそのまま導入するより合理的なケースが多いと考えています。

まとめ

AI-DLCは「AIにコードを書かせる方法」ではなく、AIが開発を主導し、人間が意思決定と監督に回る開発方法論（AWSが2025年7月に公開）
中心原則は AI Powered Execution with Human Oversight。AIが計画し、曖昧な点を質問し、人間が検証してから実装へ進む
構成は Inception → Construction → Operations の3フェーズ。要件化はMob Elaboration、構築はMob Constructionと呼ばれ、EpicはUnits of Work、Sprintは数時間〜数日のBoltに置き換わる
SDDとは軸が違う。SDDの中心はSpec、AI-DLCの中心はAIと人間の協働。AI-DLCはSDDを包含できるが、SDDである必要はない
Human Oversightは全承認ではなく、要件解釈・アーキテクチャ・セキュリティ・ビジネス判断といった判断価値の高い点に絞るもの
AWS自身が2025年11月のAdaptive Workflowsで、画一的な固定フロー・深さを変えられない工程・過剰自動化を問題として明示している
方法論（AI-DLC）と実装（awslabs/aidlc-workflows）は別。思想に同意することと、ワークフロー実装一式を導入することは切り分けて判断する