AI-DLCとは？非エンジニアのPMが「AI駆動開発ライフサイクル」をかみ砕いてみた

こんにちは！PMのYukaです。

先日、初めてAWS Summit Japan 2026 に参加してきました。今まで名前だけ聞いたことがあったもののなかなか参加できる機会がなかったので、雨の中でしたがワクワクウキウキで楽しかったです。

そんなイベントの中でわたしが一番楽しみにしていたセッションは「AI 駆動は上流工程にこそ活きる」。サブタイトルの「非エンジニアにこそ知ってほしい」というキーワードに惹かれ、何かわたしでも活かせる内容かなあとワクワクで席につきました。セッションは予約満席だったので、同じような方が多かったのかなと思います。

そちらのセッションで紹介されていたのが、本記事で取り扱う「AI-DLC」です。

AI-DLC（AI-Driven Development Life Cycle、AI駆動開発ライフサイクル）とは、AWS が提唱した、AI を開発プロセスの中心的な協力者に据え、人間が要所で判断と監督を行う開発方法論です。名前だけ聞くとエンジニア向けの話に思えるかもしれません。でもセッションを聴いて腑に落ちたのは、これが「作る速さ」より「合意の速さ」の話であり、上流工程の会議こそ変わる、つまりわたしたち非エンジニアの仕事の進め方が変わる話だということでした。この記事では、AI-DLC とは何かを非エンジニアの PM 目線でかみ砕いたうえで、なぜ会議が変わるのか、3つのフェーズと「モブワーク」で何が起きるのか、人間の仕事はなくなるのか、そしてわたしたちに求められることまでを順番に見ていきます。

わたし自身、AI-DLC を実務で回すのはこれからです。だからこそ、同じ「これから使っていく側」の目線で、セッションで聴いた内容と AWS の公開情報を自分なりに整理してみました。

AI-DLCとは

AI-DLC とは、AI を開発プロセスの中心的な協力者に据え、人間が要所で判断と監督を行う開発方法論です。2025年7月に AWS の公式ブログで提唱され、同年11月には実践のためのワークフロー定義が GitHub でオープンソースとして公開されました。2025年12月の re:Invent 2025 のセッションでも紹介されています。

まず紛らわしい点から片づけます。AI を開発に使うこと全般は、広く「AI駆動開発」と呼ばれています。AI-DLC はその全般を指す言葉ではなく、AI駆動開発の考え方を開発の最初から最後まで貫けるように AWS が体系立てた、一つの方法論の名前です。また、提唱から約1年の若いフレームワークで、業界にどう根づいていくかはこれから見えてくる段階です。

では何が新しいのでしょうか。

AWS の整理では、現在の AI の使われ方は大きく2つに分けられます。

• AI アシスト型：人間が従来どおりのプロセスで開発し、コード補完など限られた作業にだけ AI を使うやり方です。品質は保てますが、会議や調整の進め方が変わらないため速度はあまり上がりません。
• AI マネージド型：人間がほとんど関与せず、AI に自律的に作らせるやり方です。スピードは出ますが、複雑なシステムでは品質を保ちにくいとされています。

AI-DLC は、この二つの弱点をどちらも解消することをねらった新しい方法論です。AI が作業することを前提に開発の進め方そのものを設計し直し、AI が手を動かし、人間が要所で判断する役割分担に転換します。

従来の開発ライフサイクル（SDLC、ソフトウェア開発ライフサイクルと呼ばれます）と並べると、違いは次のとおりです。

なお AI-DLC は AWS によって定義されていますが、特定の AI 製品のためのものではなく、主要な AI エージェントで使える形でワークフローが公開されています。

ボトルネックは「作る速さ」より「合意の速さ」

ではなぜ、AIと作業するにあたり進め方そのものを変える必要があるのでしょうか。上流工程でよくある悩みから考えると、わかりやすくなります。※本記事では上流工程を「何を作るかを決める工程」（企画から要件定義＝作るものの条件決め、設計の序盤あたりまで）と定義します。つまり、わたしたち非エンジニアが深く関わる部分です。

たとえば、新機能のアイデアが企画会議で出たとします。気になるポイントといえば、「技術的に実現できるのか」「効果は見込めるのか」。確かめるには PoC（実現可能性を確かめる小さな試作と検証）が必要で、そのPoCを作るにも承認・人手の確保・開発サイドへの説明……が発生し、検証に辿り着くまでに時間がかかってしまいます。

ここで生成 AI を入れれば速くなるかというと、そう単純ではないようです。弊社ブログの「生成AIで生産性は上がりません。その根拠を説明します」でも書かれているように、ツールを導入しただけでは期待した加速は起きにくいことがわかってきています。資料の作成は AI で短縮できたとしても、その内容を関係者が理解し、合意するまでの時間は縮まりません。意思決定が会議のたびに持ち帰りになるなら、プロジェクト全体はほとんど速くならないからです。

AI の得意と不得意を並べると、この構図が見えてきます。

苦手側に並ぶのは、どれも人間の判断が要る項目。また AI の成果物の質は、人間が与える指示の質に左右されます。AI は学習済みの知識に加えて、渡された前提知識や文脈（コンテキスト）をもとに動くため、業務の背景や制約を知らされていない AI は、それらしくても的外れな答えを返します。（「〇〇の専門家として〜」というプロンプトを投げたら、口調だけ専門家になる、など）

整理すると、AI で「作る速さ」が上がるほど、ボトルネックは人間どうしの「合意の速さ」に移ります。AI-DLC は、この合意の部分まで含めて開発の進め方を設計し直そうというフレームワークです。

3つのフェーズと「モブワーク」

AI-DLC の進め方には、3つのフェーズと、それを貫くモブワークという二つの柱があります。

フェーズの分け方は次のとおりです。

• 構想（Inception）：何を、なぜ作るかを決める。企画、要件定義、アーキテクチャ（システム全体の構造）の設計
• 構築（Construction）：どう作るかを決めて、実際に作る。詳細な設計、コードの生成、テスト
• 運用（Operations）：作ったものを動かし続ける。本番環境への反映や監視

あれ？見覚えがあるような……。そうなんです、この分け方自体は、従来の開発とそれほど変わらないんです。

では何が違うのか。特徴は、すべてのフェーズを「モブワーク」で進めることです。モブワークとは、関係者が同じ場（会議室でもオンラインの同じ画面でもかまいません）に集まり、その場で一緒に作業して決めていく進め方です。もともとはモブプログラミングという開発手法があり、その考え方を開発以外の場面にも広げたもの、と考えるとイメージしやすいです。

構想フェーズのモブワーク（AWS の用語では Mob Elaboration）には、エンジニアを含む関係者全員が参加します。企画段階でエンジニアが参加することに疑問を覚える方ももしかしたらいらっしゃるかもしれません。AI-DLC では、エンジニアが構想フェーズの段階から技術的知見を提供するようにしています。ここで効いてくるのがラピッドプロトタイピングです。会議中に出たアイデアを、AI がその場で数分でモックアップ（見た目や動きを確かめるための試作品）にします。実現できそうか、イメージと合っているかを、その場で見て、その場で決められます。承認を待つだけだった会議が、一緒に作る場に変わるわけです。

構築フェーズのモブワーク（Mob Construction）は、機能単位の小さなチームに分かれて進みます。エンジニアが中心になりますが、いわゆる「下流工程」ではありません。セキュリティや法務のように開発者だけでは決められない判断を、その分野の担当者が同席してその場で下します。

ここまで「その場で」にこだわる理由は、AI の速さにあります。AI-DLC では、作業のサイクルが従来のスプリント（週単位の開発サイクル）から、Bolt と呼ばれる時間から日の単位のサイクルに縮みます。スクラムやスプリントになじみがない方は、弊社ブログのスクラムマスター取得記でも雰囲気に触れられます。AI は数時間おきに成果物を出してくるのに、それを判断できる人が会議室に揃っていなければ、AI が人間の承認待ちで止まってしまいプロジェクトも停滞してしまいます。またリアルタイムの議論には、AI への指示の材料になるだけでなく、人間どうしがコンテキストを共有し合う効果もあります。

人間の仕事はなくなるの？

なくならない、というのが AI-DLC の設計思想です。AI は要所で人間に確認を求め、リスクの高い意思決定は人間に委ねるよう設計されています（Human Oversight、人間による監督と呼ばれています）。前の節で見たとおり、正解のない意思決定は AI の苦手領域であり、そこを埋めるのは人間の専門家の知見だからです。

この監督は、お作法ではなく作業の流れとして組み込まれています。AI はいきなり作り始めるのではなく、まず作業の計画を立て、判断が必要な点を人間に質問します。人間が質問に答え、計画を確認して承認すると、そこではじめて AI が実行に移ります。できあがった成果物を人間が検証するところまでが1サイクルです。

ただし、楽になるとは限りません。AI の作業が速いぶん、「これでいいですか」と判断を求められる頻度はむしろ増えるため、判断やレビューで消耗してしまいます。なのでセッションでは、モブワーク後にしっかり休憩を取ることが強く勧められていました。

また AI が作業を担うようになると、若手が手を動かして学ぶ機会は減るのではないか、という不安をお持ちの方もいらっしゃるかもしれません。これに対してセッションでは、モブワークが技能伝承の場になるという見方が示されていました。さまざまな分野の専門家がその場で判断を下すところを、隣で見て学べるからです。若手の頃から他部署の意見をバシバシ浴びる……企業文化によってはなかなか経験できないかもしれません。

非エンジニアのわたしたちに求められること

ここからは、聴講して考えたことも交えて、非エンジニアの仕事に引きつけて整理します。

セッションで挙げられていた AI 時代のスキルは二つありました。

• 経験を伝えるスキル：AI の成果物の質は指示とコンテキストの質に左右されるため、業務の背景、制約、過去の失敗を言語化して渡せる人の価値が上がります。
• 適切な問いを立てるスキル：AI から有益な答えを引き出すには、何を聞くべきかを決める側の力が要ります。

この変化について、セッションでは産業革命との対比が紹介されていました。機械化の時代に、職人の手仕事の腕前よりも機械をうまく使いこなす力が問われるようになったのと同じで、これからは自分で作業する速さよりも、AI にうまく作業してもらう力が問われる、という整理です。

組織としての準備も挙げられていました。一つはコンテキスト基盤の整備です。組織や職種の壁を越えてプロダクトに関する情報へアクセスでき、AI が読み取りやすい形式で情報が残っている状態を作ること。この話は、弊社ブログの「AI時代の業務基盤は、モデルではなく『AIに渡せる業務コンテキスト』で決まる」が同じ問題を扱っているので、あわせて読むと具体的なイメージが湧くと思います。もう一つは、細切れの会議ではなく、まとまった時間で集中して判断する働き方です。作業を中断して別のことへ切り替える「コンテキストスイッチ」には、元の集中に戻るまでの時間というコストがかかります。

わたし自身は、聴講しながら「会議の設計が仕事の肝になりそうだ」と感じました。報告と承認のための会議を減らし、決められる人が揃った共同作業の場を用意する。それ自体は PM がこれまでもやってきたことの延長です。もちろんAI-DLCなくとも普段から会議設計は大事ですが、AI が入ると「その場で作って確かめる」という選択肢が加わるので、会議設計の巧拙がそのまま検証のスピードに直結するようになります。

AI-DLCの向き不向き

最後に、AI-DLC が向く場面と向かない場面も押さえておきます。自分の組織で試せそうかを考える材料にしていただけたら幸いです。

• 対象はチームでの開発です。個人での AI 活用や、人間が関与しない全自動開発は対象外です。
• モブワークが前提です。関係者を同じ時間に集められるか、その場で決められる人が同席できるかが、試せるかどうかの分かれ目になります。
• AI に渡せる形で業務の情報が残っているか（前の節で触れたコンテキスト基盤）も、効果を左右します。

まとめ

AI-DLC とは、AI を開発プロセスの中心的な協力者に据え、人間が要所で判断と監督を行う開発方法論です。ポイントは、AI で「作る速さ」が上がるとボトルネックが「合意の速さ」に移るため、上流工程の会議を報告と承認の場から、AI と一緒にその場で形にして決める共同作業の場に変える、という点にありました。

非エンジニアにとって、これは他人事ではありません。まずは、次の企画や要件定義の会議を思い浮かべて、報告と承認だけで終わっている議題がないかを探してみてください。「この議題は、その場でモックアップを見ながら決められないか」「うちの上流工程をモブワークで一度回すなら、誰に同席してもらうべきか」。そんな問いを開発チームに投げかけるところから、考え始めてもらえたらうれしいです。

もっと詳しく知りたい方は、一次情報である AWS 公式ブログの提唱記事（英語）と GitHub のワークフロー定義をご確認ください。日本語では、AWS Skill Builder の入門コース「Introduction to AI-Driven Development Lifecycle」が体系立った解説になっています（閲覧にはログインが必要です）。