AI-DLCとは何を刻む進め方？｜工程と成果物を揃える

「AI-DLCという道具を入れれば開発が速くなると聞いたのですが、どの製品を選べばいいのでしょうか」「社内で名前だけが先に回っていて、何を買う話なのか分かりません」——この言葉が出始めた組織で、そろって起きている勘違いです。どちらも、名前が製品を指していると読んでいます。AI-DLCは買って入れる道具ではありません。本当はAWSが提唱している、AIが計画して人が承認するという順番の進め方の名前です。この記事では、AI-DLCが刻む工程と、各工程で何が成果物として出てくるか、発注側として何を見るかを整理します。

AI-DLCという名前が指しているもの

AI-DLCは、日本語ではAI駆動開発ライフサイクルと呼ばれ、AWSが提唱している開発の進め方の名前です。製品でもサービスでもないため、契約して導入するものではありません。公開されている説明では、AIが計画の策定、作業の分解、構成の提案といった開発の流れ全体を取り回し、人が検証と意思決定と監督の責任を持つ形と位置づけられています。

名前の由来は、従来から使われてきた開発の一連の流れに、AIが主に動かすという意味を足したところにあります。AIを補助に使うのではなく、AIが動いて人が判断する側に回るという順番の入れ替えが、この名前の中身です。提唱したのはAWSの解決策設計の担当者とそのチームで、最初の解説は2025年7月に公開されています。

特定のAIの製品のためのものではない点も押さえておきます。AWSは2025年11月に、この進め方の作業手順を、主要なAIの道具で使える形にして公開しました。手順が公開されているため、特定の製品を買わなくても同じ進め方を試せます。2026年9月には、この進め方を基礎から学ぶ無料の学習コースの日本語版も公開されています。

名前の後半にある開発ライフサイクルという言葉は、企画から設計、実装、試験、運用までの一連の流れを指す、以前からある呼び方です。AI-DLCは、その流れを捨てて別のものに置き換えたわけではありません。流れの中で誰が先に動くかを入れ替え、区切りの長さを短くし、各区切りで何を残すかを決め直したものと読むのが、実際に近い理解です。

• AI-DLCは進め方の名前。買って入れる製品ではない
• 提唱しているのはAWS。最初の解説は2025年7月、作業手順の公開は2025年11月
• 日本語の学習コースは2026年9月に公開。修了の確認に合格すると知識の証明が出る

中心にあるのは、AIと人の7つの往復

工程を読む前に、どの工程でも繰り返される基本の動きを押さえると、全体が掴めます。公開されている説明では、この動きは人が作業の内容を渡し、AIが下書きの計画を作って足りない前提を問い返し、人が答え、AIが計画を直し、人が承認してから、AIが実行し、最後に人が結果を確かめるという往復として整理されています。

この往復のうち、人が必ず立つのは3か所です。問いに答えるところ、計画を承認するところ、結果を確かめるところ。ここを飛ばすと、進め方としてのAI-DLCではなくなります。公開されている説明でも、業務の要件を理解して情報にもとづく選択ができるのは人だけである、という前提が明記されています。

発注側にとって重要なのは、この往復が工程として書かれていることです。AIが勝手に作って後から確認するのではなく、承認しないと進まない形が最初から決まっているため、どの時点で何を見せてもらえるかが予測できます。

問い返しが工程に入っていることの意味は、AIに一度の指示で作らせる使い方と比べると分かります。一度で作らせる場合、AIは足りない前提を自分で埋めて作るため、出てきたものを見るまで前提のずれに気づけません。先に問いを出させる形にすると、ずれは作る前に表に出ます。手戻りが減るのは、AIが賢くなったからではなく、前提を確かめる回が工程として置かれたからです。

3つの工程が、それぞれ何を決めるのか

AI-DLCは3つの工程に分かれます。インセプション、コンストラクション、オペレーションで、日本語の解説では構想、構築、運用と訳されることが多いです。それぞれが答える問いは違います。インセプションは何を作るのかとなぜ作るのか、コンストラクションはどう作るのか、オペレーションは動かし続けるにはどうするかです。

3つが独立していない点が特徴です。公開されている説明では、前の工程で積み上がった文脈を次の工程が受け取るため、後の工程に進むほどAIの提案が的を射たものになると説明されています。つまり、インセプションを飛ばしてコンストラクションから始めると、後の工程の質が落ちます。急いでコードから入りたくなる場面ほど、この順番が効きます。

工程の長さも従来と違います。数週間の区切りではなく、時間から日の単位で区切って回すとされています。この刻みの細かさが、後で触れる呼び名の入れ替えと、会議の持ち方の変化に直接つながります。

前の工程に戻れるのかという疑問も出ます。公開されている説明では、工程が問題に合わせて深さを変えるとされており、一度決めた要件を動かせない仕組みではありません。ただし戻るときは、要件の文書と実行の計画を直してから戻ります。文書を直さずに会話だけで方針を変えると、次の工程でAIが古い文書を前提に作り始めます。

インセプションで出てくる成果物

ここからが本題です。工程の名前を覚えても、実際に何が手元に出てくるかが分からなければ、発注側は何も確認できません。インセプションで出るものは、公開されている手順の説明をたどると3つに整理できます。確認の問いの一覧、要件の文書、実行の計画です。

まず、AIが作業を始める前に確認の問いの一覧が出ます。要件のうちAIが判断できない点を並べた文書で、人はここに直接答えを書き込みます。答えが埋まると、AIは答えの間に矛盾がないかを確かめてから先に進みます。次に出るのが要件の文書で、答えを踏まえて整理された要件です。人が読んで承認します。

3つ目が実行の計画です。この後の工程をどの順番でどこまでやるかを書いたもので、あわせて流れを図にしたものが出ます。ここで、条件によって省いてよい段階を実際に省くかどうかが決まります。作業を始める前に、作らないと決めたものが文書に残るのが、この工程のありがたいところです。

加えて、最初に作業の場所として専用のフォルダが作られ、進行の状態を記録する文書と、何をしたかを追える記録が置かれます。既にあるシステムに足すのか、新しく作るのかの判定も、この段階で行われます。進行の状態と操作の記録が文書として残るため、後から誰が何を承認したかを辿れます。

コンストラクションで出てくる成果物

コンストラクションは、承認された要件と計画を前提にAIが手を動かす工程です。ここで最初に出るのも、成果物そのものではなく計画です。作業の単位ごとに、番号を振った手順と、終わったかどうかを示す印の付いた一覧が出て、人が承認します。

承認されると、AIがその計画の順番どおりに作ります。終わった手順には印が付くため、どこまで進んだかが一覧で見えます。この形は、進み具合を会議で聞き出すのではなく文書を見れば分かるという点で、発注側の手間を減らします。作られたものは、人が見て確認します。

最後に出るのが、組み立てと試験の記録です。必要なものと実行する命令を含んだ組み立ての手順、そして単体、結合、性能という試験の層ごとの内容、それらの結果を要約した文書が出ます。公開されている説明では、AIが論理的な構成、業務の構造の模型、コード、試験を提案し、人がその場で技術的な判断と構成の選択を明確にする形と説明されています。なお、どこまで満たせば受け入れるかという線の決め方は別に整理することなので、ここでは触れません。

もう1つ知っておくとよいのが、計画が作業の単位ごとに1つずつ出るという点です。案件全体で1枚の計画が出るのではなく、単位の数だけ計画と手順の一覧が並びます。発注側にとっては、単位の数がそのまま全体の見通しになります。単位が1つしかない案件は範囲が閉じており、10を超えるなら、どの単位から着手するかを先に決めておく必要があります。

オペレーションで出てくる成果物

オペレーションは、作ったものを動かし続ける工程です。公開されている説明では、前の工程で積み上がった文脈を使って、AIが基盤の設定をコードの形で扱い、配置の作業を進め、それをチームが監督するとされています。基盤の設定がコードとして残るため、誰が何を変えたかが追えるようになります。

この工程の成果物は、動かすための設定と、配置の記録です。人の仕事は、作業そのものよりも監督に寄ります。ただし、公開されている歩き方の解説では、例として示されたものが構築の工程で終わっており、運用の工程の細かい手順までは具体的に示されていません。ここは、自社の運用の決まりに合わせて埋める部分が残ると考えたほうが安全です。

発注側として押さえておきたいのは、この工程まで含めて1つの進め方だという点です。作って渡すところで終わる契約にすると、積み上がった文脈が運用に引き継がれません。どこまでをこの進め方で回すのかを、発注の範囲として先に決めておく必要があります。

運用の決まりを自社が持っている場合、この工程が最も手を入れる場所になります。配置の手順、変更の記録、止めるときの連絡。これらは会社ごとに違うため、公開されている手順のままでは埋まりません。逆に言えば、この工程の文書は自社の運用の決まりを写す先になるので、既にある決まりを持ち込む前提で読むのが正しい向きです。

工程ごとの成果物の一覧

ここまでを1枚にまとめます。発注側が見るべきなのは、工程の名前ではなく、その工程が終わったときに手元に何があるかです。次の表を見ながら、自社の案件でどこまで文書が出ているかを確かめられます。

工程	AIが作るもの	人が出すもの	工程の終わりに残るもの
インセプション	確認の問いの一覧、要件の文書、実行の計画と流れの図	問いへの答え、要件と計画の承認	承認された要件と、やらないと決めた範囲
コンストラクション	作業単位ごとの手順の計画、コード、組み立てと試験の記録	計画の承認、出てきたものの確認	印の付いた手順の一覧と、試験の結果の要約
オペレーション	基盤の設定のコード、配置の作業	監督と、自社の運用の決まりへの当てはめ	設定の履歴と、配置の記録

表を見て気づくのは、どの工程にも、人が承認する行があることです。逆に言えば、承認の記録が残っていない工程は、この進め方で回っていません。外部に頼む場合は、承認の記録を成果物として求めておくと、後から辿れます。

もう1つ気づくのは、成果物の多くが文書だという点です。コードだけを納品物と考えていると、この進め方の価値の半分を受け取り損ねます。要件と計画の文書は、次の改修のときにAIに渡す前提の材料になるため、その場の確認用ではなく資産として受け取るべきものです。

成果物が1つの場所にまとまって残ることにも意味があります。作業の場所として作られたフォルダに、進行の状態、操作の記録、要件、計画、試験の結果が並びます。担当者が代わったとき、この一式を渡せば経緯が引き継げます。次の改修でAIに前提を渡すときの材料にもなるため、案件が終わった後も消さずに置いておく場所を決めておきます。

呼び名が入れ替わる。スプリントはボルトになる

AI-DLCの解説を読むと、聞き慣れない言葉が出てきます。これは飾りではなく、刻みの単位が変わったことを表すために置き換えられた呼び名です。週の単位で区切っていた反復はボルトと呼ばれ、時間から日の単位になります。大きなまとまりを指していたエピックにあたるものは、ユニット・オブ・ワークと呼ばれます。

会議の呼び名も変わります。インセプションで関係者が集まって進める場はモブエラボレーション、コンストラクションで技術的な判断をその場で決める場はモブコンストラクションと呼ばれます。どちらも、報告して承認を取る場ではなく、その場で一緒に作る場として設計されています。解説では、前者で関係者全員が参加し、AIがその場で数分のうちに試作を出すこと、後者で機能ごとの小さなチームに決定権を持つ人が同席することが挙げられています。

呼び名が揃っていないと、会議が通らない

呼び名の入れ替えは、社内では別の形で問題になります。同じ会議で、ある人はスプリントと言い、別の人はボルトと言い、第三の人は反復と言う。指しているものが同じでも、期間の前提が違うため、いつまでに何が出るのかの認識がずれます。ずれたまま日程を引くと、出てこないものを待つ人が必ず現れます。

揃えるべきなのは、用語集を作ることではありません。期間、成果物、承認する人の3点が、呼び名ごとに同じ答えを返せる状態にすることです。ボルトと言ったときに、それが何日で、終わりに何が出て、誰が承認するのかを全員が同じに答えられるなら、呼び名は英語でも日本語でもかまいません。

実務で効くのは、新しい呼び名を覚えさせるのではなく、自社が既に使っている言葉との対応表を1枚だけ作ることです。会議の冒頭で1枚を配れば、呼び名の議論に時間を使わずに中身に入れます。ただし社外との会話では相手の呼び名に合わせます。委託先がこの進め方を採っているのに、こちらが独自の訳語を使うと、成果物の対応が取れなくなります。

対応表の形は、3列あれば足ります。自社で使っている言葉、この進め方での呼び名、その呼び名での期間と成果物です。3列目が書けない行があれば、そこは社内で決まっていない箇所なので、会議で決めるべき論点として残ります。表を配ることが目的ではなく、書けない行を見つけることが目的だと考えると、作る手が止まりません。

モブで進める2つの場面に、誰が出るのか

発注側や間接部門にとって、最も生活が変わるのがここです。会議の役割が、報告を聞いて承認することから、その場で一緒に決めることに変わります。従来は、要件を渡して数週間後に成果物を見る形でした。この進め方では、その場でAIが試作を出すため、決める人がいないと会議が止まります。

出る人を絞る必要もあります。解説では、構築の場では機能ごとの小さなチームで進め、そこに安全や法務のように決定権を持つ人を同席させることが挙げられています。全員を毎回呼ぶと会議が重くなるため、その回に決めることに応じて同席者を変える形が現実的です。誰が出るかを回ごとに決める人を、先に置いておきます。

同席する側に求められるものも変わります。技術の職ではない人に必要な力として挙げられているのは、経験を伝える力と、適切な問いを立てる力です。自分で作業する速さよりも、AIにうまく作業してもらう力が問われるという指摘もあります。業務の事情を言葉にできる人が会議にいるかどうかが、成果物の質を決めます。

同席が難しい場合の逃げ道も作っておきます。決定権を持つ人がその回に出られないなら、その回で決めることを先に一覧にして、事前に答えをもらっておきます。解説で挙げられているのは同席ですが、狙いは決めが会議の中で完結することにあります。答えが用意されていれば、同席と同じ働きをします。

工程が、どこまで深くやるかを自分で決める

この進め方のもう1つの特徴が、工程の深さが固定されていないことです。公開されている説明では、各工程が、どの深さで実行すべきかを自ら評価し、手順が問題に合わせて変わるとされています。手順に問題を合わせるのではなく、問題に手順を合わせるという説明の仕方がされています。

実務では、これが実行の計画に現れます。条件によって省いてよい段階を、実際に省くかどうかがこの計画で決まります。小さな改修なら検討の段階を薄くし、業務の根幹に触るものなら厚くする。どちらを選んだかが文書に残るため、後から、なぜこの検討を省いたのかを辿れます。

発注側が気をつけるのは、省いた理由が書かれていない計画を承認しないことです。深さを選べる仕組みは、裏を返せば手を抜ける仕組みでもあります。何を省いたかと、なぜ省いてよいと判断したかを計画に書かせてから承認する、という1行を自社の決まりに置いておきます。

発注側が各工程の入口で見る点

工程と成果物が分かれば、見る点は絞れます。見るのは出来上がりの品質ではなく、入口で渡されたものと、承認の記録です。品質の判断は専門的になりますが、文書がそろっているかどうかは、技術の知識なしに確かめられます。

具体的には4つです。確認の問いに自社が答えたか、答えが要件の文書に反映されているか、実行の計画で何を省くと決めたか、承認した人の名前が残っているか。この4つが埋まっていれば、少なくとも進め方としては回っています。埋まっていない場合、AIが作ったものを誰も検証していない可能性があります。

逆に、見ても意味が薄いものもあります。コードの行数や、作業した時間の合計は、この進め方では進み具合の指標になりません。AIが書く量は人の労力と対応しないため、量で測ると判断を誤ります。見るのは、承認した回数と、承認の後に手戻りが出た回数です。手戻りが多い工程は、問いへの答えが足りていない工程です。

外部に頼む場合は、承認の記録を成果物として契約に書いておきます。口頭で承認した事実は残らないため、後から何を承認したかを争う場面が出ます。承認した文書の版と日付が残る形にしておけば、手戻りの責任の所在も整理しやすくなります。これは相手を疑うためではなく、AIが作ったものに人が目を通した証拠を双方に残すための手当てです。

人が承認する場所を、先に決めておく

この進め方は人の承認を前提に組まれていますが、承認を誰が出すのかは進め方の側では決まっていません。ここを決めないまま始めると、承認がその場にいた人の判断になり、後から誰も責任を辿れなくなります。

決め方は2段階です。まず、3つの工程それぞれについて、承認を出す人の役割名を書きます。次に、その人が不在のときに代わりに出せる人を書きます。この2行があれば、会議が止まりません。承認を出す人が業務の事情を知らない場合は、その人に問いへの答えを書かせるところから設計を見直します。

あわせて、AIに判断させないと決める場所も書いておきます。要件のうちどれを優先するか、どの機能を落とすか、どこまでの出来で世に出すか。これらは業務の損得に直結するため、AIの提案を材料として使っても、決めるのは人です。AIに提案を出させるときは、なぜそう提案するのかの根拠を一緒に書かせ、人が確認する範囲を先に決めておきます。

承認の場所と、AIに判断させない場所。この2つを先に文字にすることが、この進め方を試すための実質的な準備です。道具の選定よりも先に効きます。

最初の1本に選ぶもの

試すときの題材の選び方にも型があります。選ぶべきは、止まっても業務が止まらない、範囲が閉じている、成果物を自社の人が読んで分かるものです。基幹の処理や、社外の相手に見える部分を最初に選ぶと、承認の関門が多すぎて、進め方そのものの良さが見えません。

既にあるシステムに足すのか、新しく作るのかは、最初の工程で判定されます。新しく作るほうが、この進め方の効果は分かりやすいです。既にあるものに足す場合、既存の決まりや過去の経緯を問いへの答えとして大量に書く必要があり、その負担が最初に来ます。1本目を既存のものに足す形で始めると、進め方の評価と資料づくりの苦労が混ざります。

1本目で見るのは速さではありません。問いの一覧に自社が答えられたか、承認の関門で議論が起きたかを見ます。問いに答えられなかった箇所は、業務の側で決まっていないことが見つかった場所です。ここを洗い出せた時点で、1本目の目的は達成されています。

期間の感覚もつかんでおきます。区切りが時間から日の単位だとされているため、1本目に数週間を置くと、区切りの短さから来る良さが試せません。数日で一巡させ、そこで出てきた文書を持って次を決める。この刻みに自社の会議の周期が合うかどうかも、1本目で確かめておきたい点です。

学び方と、つまずきやすい点

学ぶ入口は用意されています。AWSの学習の仕組みで、この進め方を基礎から学ぶ無料のコースの日本語版が2026年9月に公開されており、修了の確認に合格すると知識の証明が出るとされています。発注側の担当が先に受けておくと、会議での会話が通ります。そのうえで、つまずきやすい点を先に押さえておきます。

• 製品だと思って選定を始める：買うものを探し始めると、進め方をどう変えるかの話が止まる
• インセプションを飛ばしてコードから入る：後の工程が受け取る文脈が薄くなり、提案の的が外れる
• 承認を形だけ通す：問いに答えず承認すると、AIが前提を推測して作り、手戻りが後でまとまって来る
• 呼び名だけを社内に持ち込む：期間と成果物と承認者が揃っていないと、言葉が増えただけになる
• コードの量で進み具合を測る：AIが書く量は人の労力と対応しないため、判断を誤る

手順が公開されているため、試すための初期の費用はほとんどかかりません。ただし、試せることと社内で回せることは別です。まずは1人が手元で一巡させて、出てくる文書の形を自分の目で見ておくと、社内での説明が具体的になります。文書の見本が手元にあるかどうかで、会議の通りやすさが変わります。

最後に1つ。この進め方は、人の判断の量を減らしません。手を動かす時間が減る代わりに、問いに答え、計画を承認し、結果を確かめる時間が増えます。その時間を誰の予定に確保するかを決めないまま始めると、承認が滞って全体が止まります。速くなるのは作る工程で、判断の工程は人の予定の空き具合で決まる、という前提で計画を引いてください。

まとめ

AI-DLCは買って入れる道具ではなく、AWSが提唱する、AIが計画して人が承認する順番の進め方です。工程はインセプション・コンストラクション・オペレーションの3つで、それぞれから確認の問いの一覧、要件の文書、実行の計画、手順の計画、コード、組み立てと試験の記録、基盤の設定と配置の記録が残ります。発注側が見るのは出来上がりの品質ではなく、問いに答えたか、何を省くと決めたか、誰が承認したかの記録です。呼び名は無理に統一せず、既存の言葉との対応表を1枚配る。まずは、止まっても業務が止まらない1本を選び、問いの一覧に自社が答えられるかを確かめるところから始めてみてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。