AI-DLC(エーアイ・ディーエルシー)とは
AI-DLCとは、AIが開発作業を主導し、人が重要な判断を確認しながら、構想から運用までを短い単位で進めるAWS提唱の開発方法論です。AIにコードを書かせるだけでなく、目的・設計・検証・運用の文脈をつなぐ点に特徴があります。
英語表記：AI-Driven Development Life Cycle
AWSが2025年7月に公開し、その後は適応型ワークフローや具体的な実装例も示しています。2026年9月時点では、特定の製品を買えば完成する仕組みではなく、開発チームの進め方を組み替えるための考え方と実践手順として位置づけるのが適切です。
従来の開発工程と何が違うのか？
従来は、人が要件を文章化し、設計し、実装し、テストする各工程でAIを補助的に使う形が中心でした。AI-DLCでは、AIエージェントが質問、案の作成、コード変更、確認資料の準備まで進め、人は選択肢の妥当性と重要な決定を確かめる役割へ比重を移します。
ただし、AIへ目的だけを渡して放置する方式ではありません。事業上の優先順位、受け入れ条件、セキュリティ、公開判断の責任は人に残ります。AIの提案が速くても、誤った前提のまま進めば手戻りも速くなるからです。
基本の流れは構想、構築、運用の3段階です。構想では課題と価値を明確にし、構築では小さく作って確かめ、運用では実際の利用から得た学びを次の判断へ戻します。工程を一方通行にせず、検証結果を次のサイクルへ返すことが要点です。
AWSはこの方法論を二本柱で説明しており、もう一方の柱はチームの集まり方です。構想段階のMob Elaborationではチーム全員がAIの質問と提案を検証し、構築段階のMob Constructionでは技術や設計の選択をその場で補います。担当者が持ち帰って後日レビューする形とは、会議の持ち方も人の集め方も変わる点に注意しましょう。
継続する文脈が土台になる
AIは会話のたびに、会社の事情や過去の判断を自動で理解するわけではありません。AI-DLCでは、目的、原則、要件、設計上の決定、検証結果などをリポジトリ内の文書へ残し、後続の作業でも参照できる形に整えます。
良い指示文を一度書くことより、判断の根拠を更新し続けることが重要です。担当者が替わっても、AIエージェントが変わっても、何を守るべきかを読み直せる状態が品質を支えます。
古い方針を残したまま新しい依頼を重ねると、文脈そのものが誤りの原因になります。決定を追加するだけでなく、廃止された前提を明示し、現在有効な文書を区別する運用が欠かせません。
導入は一つの仕事から始める
最初から全社の開発工程を置き換える必要はありません。たとえば社内ツールの小さな機能、データベース設計の可視化、既存コードの安全確認など、入力と受け入れ条件を説明できる仕事を一つ選びます。
開始前に、完了の条件、AIが触れてよい範囲、人が承認する地点、失敗時の戻し方を決めましょう。速さだけでなく、修正の再現性と確認にかかる負担も測ると、導入価値を判断しやすくなります。
AIが作った成果物は、通常のレビューやテストを省く理由にはなりません。本番データ、認証情報、外部公開に関わる変更は、隔離された環境と権限の制限を先に用意してください。
経営判断では何を確かめるか？
経営者が見るべきなのは、生成したコードの量ではありません。価値のある変更が、確認可能な形で利用者へ届くまでの時間が中心指標でしょう。完成件数だけでなく、差し戻し、障害、確認待ち、属人化も記録対象です。
AIの利用料だけを比較すると、文脈整備やレビューの工数が抜け落ちます。小規模な試行で、従来手順とAI-DLCの手順を同じ受け入れ条件で比べれば、自社の仕事に合う深さを選べます。
短期間で成果が出た試行を、そのまま高リスクな基幹システムへ広げないことも大切です。変更の影響が大きいほど、人の承認、監査記録、復旧手順を厚くします。
Topicスプリントではなく「ボルト」と呼ぶ理由
AWSの原典では、数時間から数日で終える短い作業単位をboltと呼びます。AIが作業の待ち時間を縮めると、一定期間に仕事を詰める区切りより、検証できる成果へ素早く到達する単位が合うという発想です。大きなepicに代えて、Unit of Workという単位も置いています。
AI-DLCに関するよくある質問
- AI-DLCはスクラムと併用できますか？
- 既存の会議や管理方法を直ちに廃止する必要はありません。ただし、AWSの原典は短いboltとUnit of Workを中心に再設計しています。まず一つの小規模案件で、従来の区切りを残す部分と置き換える部分を決めて試すのが安全です。
- AI-DLC専用のAI製品が必要ですか？
- 特定製品だけを指す名称ではありません。AWSはAmazon Q DeveloperやKiro、Amazon Bedrock AgentCoreを使う実装例を公開していますが、重要なのは人の検証点、継続する文脈、短い成果単位を設計することです。
- 開発者がいない会社でも導入できますか？
- AIが作った変更の安全性や正しさを確認できる担当は必要です。外部の開発会社へ依頼する場合も、受け入れ条件、権限、公開判断、問題時の復旧責任を会社側で明確にしてください。
