AI-DLCとは？AIと人で進める開発を図解

AI-DLCの対象は、アプリや業務システムを作り、使いながら改善する一連の仕事です。AIがその流れを進める中心的な役割を担います。

AI-DLCは、Amazonのクラウド事業を担うAWSが提唱した開発方法です。特定のAI製品や、購入すれば開発をすべて任せられるサービスの名前ではありません。

アプリや業務システムのように、コンピューター上で動く仕組みを「ソフトウェア」と呼びます。AI-DLCは、そのソフトウェア開発にAIをどう組み込むかを示す方法です。

AI-DLCでは、作業の実行に加え、段取りづくりと前提の引き継ぎにもAIを組み込みます。人は、目的を示し、計画や結果がその目的に合うかを確かめます。

AIがプログラムを速く書けても、作るものが決まらず、確認する人も分からなければ、開発全体は進みません。AWSは、個々の作業の時短を、開発全体の改善につなげる方法としてAI-DLCを説明しています。

この比較は「作業ごとに依頼する使い方」との違いを整理したものです。実際のAI活用には幅があり、すべての製品や現場を二分するものではありません。

AI-DLCが目指すのは、AIの提案を受け、人が必要な判断を返し、次の作業へ進める関係です。そのやり取りが、開発のどこで起こるのかを見てみます。

基本の流れは「何を作るか決める」「作って確かめる」「使える状態を保つ」です。AWSの基礎解説では、それぞれを開始・構築・運用と呼んでいます。

開始では、誰の困りごとを解くか、どの機能が必要かを整理します。構築では、仕組みを設計し、プログラムを作り、期待どおりに動くかをテストします。運用では、利用できる環境へ届け、動作を見守り、問題に対応します。

各工程をつなぐのが、目的や条件、設計、確認結果の記録です。AIとの会話が変わっても、「何を作るか」「なぜそう決めたか」を次の作業で参照できる形に残します。

この3段階は基本概念の説明です。実践用の公開手順「AI-DLC Workflows 2.0」では、初期設定や構想を含めて5段階に分けています。基本概念と実践用手順で、工程の区切り方が異なります。

工程や確認の詳しさは、作るものに合わせて調整します。小さな不具合の修正にも、新しいシステムを一から作る場合と同じ量の計画を課すわけではありません。

人は、作る目的と優先順位を決め、AIの計画や結果が業務に合うかを確かめます。AI-DLCでも、重要な意思決定と責任は人や組織に残ります。

業務担当者は、現場の困りごとや使い方を伝えます。エンジニアは、設計・安全性・動作を技術面から確かめます。どちらか一方だけで判断せず、同じ提案をそれぞれの専門性で検討するのがチームの役割です。

判断の違いを、説明用の架空例で考えます。「備品を予約する画面がほしい」という要望でも、困っているのが空き状況の分かりにくさなのか、承認の待ち時間なのかで、必要な仕組みは変わります。

待ち時間を減らしたい一方、高額な機器は責任者が確認してから貸したい場合もあります。ここでは「承認が必要な備品と、その責任者」を人が決めたとします。その条件は、AIへの説明だけで終わらせず、動作とテストまでつなげます。

この例で人が担ったのは、画面の見た目への賛否だけではありません。便利さと管理上の制約をすり合わせ、何を満たせば使ってよいかを決めたことです。ここが曖昧だと、作る速さだけが上がっても、欲しかった仕組みには近づけません。

AIを開発全体で活用するには、使える環境と、仕事を渡す仕組みも必要です。公開報告では、この両方に手を入れた例が見られます。

フィットネスサービスのPelotonは、AI導入時の最初の障害が、モデルではなく認証情報の管理だったと報告しています。認証情報は、AIの利用を許可するための「鍵」に当たるものです。

AWSの導入支援部門、Professional Servicesは、AIが得意な仕事を見極め、複雑な仕事を確認できる単位に分けるには習熟の時間が必要だと振り返っています。導入した瞬間に、任せ方まで完成するわけではありません。

ここで扱ったのは、各社・提供者による公開報告です。当社の支援実績ではなく、同じ対策で同じ成果が得られることを示すものでもありません。

AI-DLCを自社で役立てるには、解くべき問題、使ってよい条件、改善の確かめ方をそろえる必要があります。AIに任せる範囲は、この判断ができる体制と併せて考えます。

本記事で重視するのは、AIが出した案を、自社の事情に合う判断へ変えることです。同じAIを使っても、現場の困りごとを捉える力や、部署間で条件を合意する力は、道具を導入しただけではそろいません。

目的と確認体制が社内でそろっていれば、自分たちのチームで小さく試す選択もできます。一方、部署ごとに優先順位が違う、試作の評価基準が決まらない、業務と技術の話がかみ合わない場合は、その整理が専門家に相談する理由になります。

伴走支援では、決定と理由を残し、支援が終わった後も自社で変更・確認できる状態までを考えたいところです。

AI-DLCは、AIが計画や作成を進め、人が大事な判断を返す開発方法です。その理解を自社につなげる最初の問いは、「AIに何を作らせるか」とともに、「誰の、どの困りごとを解くか」です。

定義と仕組みはAWSの公式解説、工程の詳細はAWS Labsの公開資料を参照しました。第5章の事例は提供者の報告、第4章の備品貸出は説明用の架空例です。「本記事の考察」と第6章の支援の観点は筆者の分析であり、特定案件の実績を示すものではありません。図は本記事の説明に合わせて作成しています。

1. AWS：AI-DLCの基本説明 — 2025年8月8日。略語の意味、定義、AIと人の協働、開始・構築・運用の基本説明。
2. AWS：AIが計画し、人が判断する仕組み — 2025年11月29日。計画と結果の確認、チームの協働、記録、工程の調整。
3. AWS：開発チームの協働 — 2026年5月26日。金融分野向け解説から、職種間の協働を参照。個社の成果数値は本記事の効果として扱っていません。
4. AWS：日本語の基礎学習コース — 2026年9月1日。開発全体を見直す背景、効果の測定、日本語の無料基礎コース。
5. AWS Labs：実践用の公開ワークフロー — 公開README。方法論と実践用ワークフローの区別、5段階の構成を参照。
6. AWS Labs：公開ワークフローの工程 — 公開工程ガイド。初期設定・構想・開始・構築・運用の区分を参照。基礎解説の3段階と混同しないよう本文で区別。
7. AWS・Peloton：AI開発を支える利用環境の再構築 — 2026年7月29日。第5章・図7の認証情報の管理上の課題と対策。AWSとPeloton担当者の報告。
8. AWS Professional Services：自らAI-DLCを実践して学んだこと — 2026年6月12日。第5章・図7の仕事の渡し方と、習熟に時間が必要という振り返り。同部門の公開報告。

資料内容の確認日：2026年9月14日。掲載リンクは2026年9月15日に再確認。方法論の基本説明と公開ワークフローの工程分けを区別しました。公開事例の成果数値を一般化したり、当社の実績に置き換えたりしていません。