2026-07-13 / AI活用

AI-DLCとは何か。AIエージェント時代に、なぜ開発方法論が必要なのか

コード生成からAIエージェントへ進んだ今、開発全体をどう組み直すのか。AWSが提唱するAI-DLCの考え方と、v2で追加された設計原則を整理します。

AIにコードを書かせることは、珍しくなくなりました。

入力の続きを補完するだけでなく、リポジトリを読み、不具合を調べ、ファイルを直し、テストが通るまで作業する。現在のコーディングエージェントは、一つの開発タスクをまとめて任せられるところまで進んでいます。

一方で、実装が速くなったからといって、開発全体がそのまま良くなるわけではありません。

何を作るのか。なぜその設計にするのか。セキュリティや性能をどこまで求めるのか。誰が結果を確認するのか。運用を始めた後、何を見て改善するのか。

こうした判断が曖昧なままでは、AIは間違った方向にも速く進みます。完成したコードは残っても、途中で人が伝えた判断がチャットの中へ埋もれることもあります。

私がAI-DLCに注目しているのは、この問題をAIツールの使い方ではなく、開発方法そのものの問題として扱っているからです。

AI-DLCは、AWSが提唱するAI-Driven Development Life Cycleの略称です。AIにコードを書かせる手順ではありません。AIを前提に、要件、設計、実装、テスト、デプロイ、運用までを組み直す方法論です。

この記事では、AIコーディングからAIエージェントまでの流れを確認した上で、AI-DLCがどのような立場を取り、何を解決しようとしているのかを整理します。さらに、AI-DLC Workflows 2.0で追加された設計原則も見ていきます。

AI-DLCは、AIを使うための開発方法論
コード補完から、開発を進めるAIエージェントへ
AI-Assistedでも、完全自律でもない
AIが計画し、人間が判断する
AI-DLCが解こうとしている課題
Intentから運用まで文脈をつなぐ
v2で追加された設計原則
正しさを確認できる範囲だけ自律させる
人間の判断を少しずつ蒸留する
向いている開発と、向いていない開発
私がAI-DLCに注目している理由
まとめ

AI-DLCは、AIを使うための開発方法論

最初に、AI-DLCとAI-DLC Workflowsを分けます。

AI-DLCは方法論です。AIと人間が開発へどう参加し、何を成果物として残し、どこで判断するかを定めます。

AI-DLC Workflowsは、その方法論をAmazon Q、Kiro、Codex、Claude Codeなどの環境で動かすための実装です。

AI-DLC Workflows 2.0は、その実行基盤を作り直しているプレビュー版です。複数の専門エージェント、Stage、Skill、監査、学習などを組み合わせ、方法論を実際に動かします。

製品名やリポジトリ構成だけを見ると、AI-DLCが一つの開発ツールに見えるかもしれません。しかし、中心にあるのは「どのAIを使うか」ではなく、「AIを前提に開発をどう進めるか」という考え方です。

AWSのAI-DLC Method Definition Paperは、AI-DLCをAIネイティブな開発方法論として定義しています。既存の開発工程へAIを追加するのではなく、AIの速度や能力に合わせて、工程、役割、成果物、確認方法を組み直す立場です。

コード補完から、開発を進めるAIエージェントへ

AIとソフトウェア開発の関係は、短い期間で変わりました。

2021年に登場したGitHub Copilotは、AI pair programmerとして、書いているコードの続きを提案しました。人が開発を進め、AIが行や関数を書く作業を助ける形です。

その後、Claude CodeやCodexのようなコーディングエージェントが登場しました。現在は、リポジトリを読み、複数のファイルを変更し、コマンドやテストを実行しながら、一つの仕事を進められます。

さらにKiroは、実装前にrequirements、design、tasksを作るSpec-Driven Developmentを示しました。コードを書く前に、AIが置いた前提や要件を人が確認できる形にするものです。

ここまでの変化を、私は次のように整理しています。

段階	AIが扱う主な単位	人間の役割
コード補完	行、関数、テスト	実装を主導する
コーディングエージェント	不具合修正、機能、Pull Request	仕事を依頼し、結果を確認する
仕様駆動のエージェント開発	要件、設計、実装タスク	仕様と計画を確認する
AI-DLC	Intentから運用まで	判断、承認、検証、責任を担う

コーディングエージェントは、AIが実行できる範囲を広げました。AI-DLCは、そのAIを開発全体の中でどう働かせるかを扱います。

出典:

AI-Assistedでも、完全自律でもない

AI-DLCの公式文書は、ソフトウェア開発におけるAIの使い方を大きく三つに分けています。

立場	AIの役割	人間の役割
AI-Assisted	コード生成やテストなど個別作業を助ける	作業全体を主導する
AI-Autonomous	高いレベルの要求から完成まで自律的に進める	最初の依頼と最終確認に寄りやすい
AI-Driven	計画、質問、分解、実行を主導する	重要な判断、承認、検証、責任を担う

AIを補助としてしか使わなければ、人間側の作業構造はほとんど変わりません。反対に、最初の指示だけで完成まで任せると、現在のAIでは誤った前提や判断を安全に止められません。

AI-DLCが取るのは、その間にあるAI-Drivenという立場です。

AIの能力は計画や実行に使う。ただし、事業上の意味、設計上のトレードオフ、リスクの受容などは人間が判断する。AIへ丸投げするのではなく、人間が関わる場所を重要な判断へ移します。

AIが計画し、人間が判断する

通常のチャットでは、人間が質問し、AIが答えます。

AI-DLCでは、最初に人間がIntentを示すと、AIが必要な工程を考えます。曖昧な点を質問し、選択肢や実行計画を出します。人間が内容を確認した後、AIが実行し、結果を再び人間が検証します。

この流れは、開発の各段階で繰り返されます。

人間が目的と制約を示す
AIが質問し、必要な情報を集める
AIが計画と選択肢を作る
人間が判断し、計画を承認する
AIが作業を実行する
AIと人間が結果を検証する
必要なら修正し、次の段階へ進む

人間がすべての作業手順を書くのではありません。AIが進行役になり、人間は目的から外れていないか、許容できるリスクか、本当に完成といえるかを判断します。

AI-DLCが解こうとしている課題

AI-DLCが必要とされる背景には、AIエージェント単体では解決しにくい問題があります。

個人の生産性向上が、開発全体へつながらない

コードや資料が速く作れても、要件確認、レビュー、テスト、デプロイ、運用が従来のままなら、仕事は後工程へ移るだけです。

DORAの2025年調査では、AI利用は個人の生産性やソフトウェアデリバリーのスループットと正の関係を示す一方、安定性とは負の関係が残りました。DORAは、AIが強いチームと弱いチームの両方を増幅すると整理しています。

これはDORAがAI-DLCを評価した結果ではありません。ただ、AIツールの導入だけでは足りず、テスト、フィードバック、ワークフロー、内部基盤を含む開発全体を整える必要があるという問題認識は重なります。

その場のプロンプトに判断が埋もれる

AIへ修正を重ねると、最終的なコードは残っても、なぜそうしたのかが残らないことがあります。次の担当者や別のAIは、同じ判断をもう一度やり直します。

AI-DLCでは、Intent、要件、ユーザーストーリー、非機能要件、リスク、設計、テストなどを成果物として残し、次の工程へ渡します。

案件ごとに必要な工程が違う

小さな不具合修正に大規模な要件定義は不要です。一方、新しいシステムや規制対象のサービスでは、設計、セキュリティ、非機能要件、テストを省けません。

AI-DLCは、Intent、既存コード、複雑さを見て、AIが必要な工程と深さを提案します。人間は、省略してよい工程と、深く扱う工程を確認します。

人間がAIの出力を受け取るだけになる

自動化が進むほど、人間が深く考えず承認する危険があります。AWSは、これをprocess atrophyとして挙げています。

AI-DLCでは、実行前の計画と実行後の成果物を分けて確認します。人間の役割は、AIの出力を眺めることではなく、目的、リスク、妥当性を判断することです。

出典:

Intentから運用まで文脈をつなぐ

最初に定義されたAI-DLCは、Inception、Construction、Operationsの三つのフェーズで説明されています。

Inception

人間が示したIntentを、要件、ユーザーストーリー、受け入れ条件、非機能要件、リスク、測定基準へ具体化します。AIが案を作り、Product Owner、Developer、QAなどが一緒に確認します。

Construction

確認された要件をもとに、設計、実装、テストを進めます。AIが設計案やコードを作り、人間が重要な技術判断と結果の検証を行います。

Operations

デプロイ、監視、保守を扱います。実装で終わらず、運用データや障害から得た情報を次の開発へ戻します。

AI-DLCでは、Intentから分けた価値のまとまりをUnit、Unitを実装・検証する短い反復をBoltと呼びます。週単位のSprintより短く、時間や日単位で作業と検証を進める考えです。

大切なのは用語ではありません。前の工程で確認した内容を、次の工程の文脈として使うことです。要求、設計、実装、テスト、運用が別々の会話にならないようにします。

v2で追加された設計原則

AI-DLC Workflows 2.0は、方法論を維持しながら実行基盤を作り直しています。

ただし、v2は単なる実装更新ではありません。人間の判断をどのように機械へ移し、どの条件でAIが自律的に進み、どこで人間へ戻すかという九つの設計原則が追加されています。

原則	考え方
人間の判断を蒸留する	繰り返される判断や修正を、機械が確認できる形へ変える
Intentは曖昧な状態から始まる	AIが仮定せず、質問して意図を具体化する
AIを自己修正させる	外部の検証条件を使い、失敗を見ながら修正する
作る・確かめる・学ぶを分ける	Generation、Verification、Learningを別々に定義する
すべての開発段階を同じ構造で扱う	実装だけでなく、要件、設計、配備、監視にも生成・検証・学習を適用する
一度に完成させない	小さなSkillとStageへ分解する
自律化を小さく始める	確認できる範囲からAIへ任せる
組織ごとに拡張する	ルールの追加、置換、新しいStageの組み込みを可能にする
実践から学ぶ	人間の修正を、次回の検証ルール候補として残す

v2の方向を一言で表すなら、Human-in-the-loopを固定された完成形ではなく、改善していく出発点として扱ったことです。

人間が毎回見ている観点のうち、繰り返し使えるものを検証条件へ変える。機械が確認できる範囲が広がるほど、人間は曖昧さや新しいトレードオフの判断へ集中できます。

出典:

正しさを確認できる範囲だけ自律させる

v2の中心にあるのがThree-Compartment Modelです。各Stageを三つに分けます。

Generation Spec

何を入力し、何を出力するかを定義します。必要なら、品質のために省いてはいけない中間成果物も指定します。

Verification Spec

正しいとどう判断するかを定義します。要件、制約、品質基準、セキュリティルール、テストなどです。

Learning Spec

実行中の人間による修正、再実行、例外承認から、何を学習候補として残すかを定義します。

この三つを分けることで、「作ってください」という一つの指示へ、目的、品質、学習をすべて押し込まずに済みます。

検証方法も二つに分けます。

検証方法	例	完了の扱い
推論による検証	設計レビュー、文章品質、コードレビューの観点	LLMが評価しても、人間の確認を残す
決定的な検証	自動テスト、静的解析、認証必須、削除禁止	ツールが明確に判定できる

同じAIが生成と評価を行うと、確認項目の表面だけ満たし、本来の意図を外す可能性があります。v2の仕様書もこの問題を認めています。

そのため、LLMによる評価だけでStageを自動完了させません。自動テストや静的解析のように、AIが変更できない検証器で確認できる部分から自律化します。

さらに、試行回数やトークンの上限を設けます。条件を満たせなければ、AIは延々と続けず、人間へ戻します。

v2が目指す自律性は、AIが自信を持ったら先へ進むことではありません。正しさを外から確認できる範囲だけ、AIに反復を任せることです。

人間の判断を少しずつ蒸留する

組織の設計判断、セキュリティ、法令、現場の慣習を、最初からすべて機械が確認できる形にはできません。

そこでv2は、分かっている条件から始めます。

命名規則。必須のテスト。認証のないAPIを公開しないこと。本番環境の削除操作を禁止すること。こうした明文化しやすい条件からVerification Specへ入れます。

まだ言葉にできていない判断は、人間が確認します。人間がAIの出力を修正したら、その内容をLearning Specへ残します。同じ修正が繰り返されるなら、新しい検証条件やガードレールの候補にします。

ただし、AIが勝手にルールを変えるわけではありません。新しいルールは人間へ提案され、承認された後に使われます。

この流れを繰り返すことで、以前は人間が毎回確認していたことを、次回から機械が確認できるようにします。人間の判断を一度で置き換えるのではなく、実践を通じて少しずつ蒸留していきます。

向いている開発と、向いていない開発

AI-DLCは、すべての開発を重い工程へ通すための方法論ではありません。

向いているのは、次のような開発です。

要件や設計に複数のトレードオフがある
既存システムや外部サービスとの連携が多い
セキュリティ、性能、可用性などの非機能要件が重要
複数人や複数の専門領域が関わる
開発後の運用や継続的な改善まで扱う
判断や承認の経緯を後から確認する必要がある

一方で、簡単なスクリプトや使い捨ての試作まで、すべて同じ深さで進める必要はありません。判断が少なく、失敗時の影響も小さいなら、短い計画とテストだけで十分な場合があります。

AI-DLC Workflowsは、案件に合わせて実行するStageと深さを変える考えを持っています。それでも、成果物を作り、確認する分の負荷はあります。方法論を使うこと自体を目的にせず、作るものの複雑さとリスクに合わせる必要があります。

また、AI-DLCを使えば必ず速くなると断定はできません。AI-DLC固有の効果を広く比較した独立研究は、今回確認した公開資料の範囲では見つかりませんでした。

人間の実装作業が減っても、要求、設計、リスクを短時間で判断する負荷は残ります。AIの生成速度に人間の確認が追いつかなければ、承認が形だけになる危険もあります。

私がAI-DLCに注目している理由

AIエージェントの性能は、これからも上がっていくと思います。より長い仕事を任せられ、複数のエージェントが分担し、人が細かく指示しなくても実装が進むようになります。

だからこそ、モデルの性能とは別に、仕事を進める方法が必要になります。

何を目的とするのか。何を正しいとするのか。どこまで任せるのか。失敗したらどこで止めるのか。人間の修正を次へどう残すのか。

AI-DLCは、これらを開発工程の中へ置いています。

特にv2の「人間の判断を少しずつ機械が確認できる形へ変える」という考え方に注目しています。

最初から人間を外すのではありません。人が確認し、直し、その判断を残す。繰り返し使える判断は、次回からAI自身が確認できるようにする。人は、まだ言葉になっていない問題や、新しい判断へ時間を使う。

これは、私がAI-RPAで考えていることとも共通します。AIエージェントへ仕事を任せる前に、業務を棚卸しし、判断基準と人の確認点を決め、小さく始めて育てる。対象は業務とソフトウェア開発で違いますが、AIに人間の判断を蒸留していく点は同じです。

AIが何をできるかだけでなく、AIと人間がどう仕事を進めるかを考える。その具体的な方法論として、AI-DLCを見ています。

まとめ

AI-DLCは、AIコーディングツールの使い方ではありません。AIを前提に、Intent、要件、設計、実装、テスト、デプロイ、運用をつなぎ直す開発方法論です。

AIが計画し、質問し、実行する。人間は、目的、制約、リスクを判断し、結果を検証する。AI-Assistedと完全自律の間に、AI-Drivenという立場を置いています。

AI-DLC Workflows 2.0は、そこからさらに進みます。

人間の判断を機械が確認できるルールへ変える。生成、検証、学習を分ける。正しさを確認できる範囲だけAIに自己修正を任せる。試行回数やトークンに上限を設け、分からなければ人間へ戻す。人間の修正を次の検証条件へ育てる。

目指しているのは、AIへ一度にすべてを任せることではありません。

人間が判断すべきことを見極めながら、任せられる範囲を少しずつ広げることです。

AIエージェントが強くなるほど、必要になるのは強いプロンプトだけではありません。目的、判断、検証、学習を残せる開発の形です。AI-DLCは、その形を考えるための方法論です。

公式情報

※ 本記事は2026年7月13日時点の公開情報をもとにしています。AI-DLC Workflows 2.0はGA Previewであり、Stage、Agent、導入方法などは変更される可能性があります。

相談する