AI-DLCで2ヶ月間、開発をガチってみた

浦 将平浦 将平· 27 min read
AI-DLCAI駆動開発開発プロセス
目次

こんにちは。リチェルカの浦です。

先日、AI-DLCの提唱者であるRaja SPさんのセッションイベントに参加してきました。

Rajaさんの話の中で、一番大変だったことは根回しだった（意訳）という話があり、根回しのスケールも流石AWS、世界中のAWSオフィスを行脚していたというのは想像がつきません。

実は私もYOUTRUSTのイベントでAI-DLCをテーマにして登壇をしてきました。今回はそこで話した内容を中心に書いていきますが、スタートアップだからこそ進めやすいという条件があります。その辺はよしなにお願いします。

AI-DLC（AI-Driven Development Life Cycle：AI駆動開発ライフサイクル）とは

AWSが2025年に公開した、AIモデルが開発プロセスそのものを主導する開発ライフサイクルで、要件定義から改善までAIが計画・実行を主導し、人間が監督・承認を担う開発アプローチです。

ワークフローやルールはGitHubに公開されています。まだ正式リリースはされていませんがAI-DLC v2のα版も公開されています。

v1:https://github.com/awslabs/aidlc-workflows

v2:https://github.com/awslabs/aidlc-workflows/tree/v2

余談ですが、Claude Codeが登場したのは2025年2月。2026年7月時点でまだ1年半しか経っていません。AI-DLCの開発は2024年からスタートしていたようなので、まさに時代に合わせた開発手法です。Rajaさん自身もまだこれが最適解だとは思っていないようで、大きく思想は変わらないがやり方は変わっていくと述べています。実際にAI-DLCのv1とv2はプロセスが全く異なります。

AIは個人ではなく、チームを強くする

生成AIの活用というと、多くの場合「個人の生産性向上」の話になります。開発現場も例に漏れません。Claude CodeやCodexなどで要件定義から実装、コードレビューまであらゆる工程にAIが登場します。こうした使い方はもうどこでも当たり前になってきています。

ただ、AI-DLCを実践して最初に感じたのは、「AIを使う人が増えた」ことではありませんでした。変わったのは、チームの働き方そのものでした。

AIはチームの中心にいる

従来の開発は、営業やCSが顧客の課題を整理し、PdMが要件をまとめ、エンジニアが設計・実装するという分業が基本です。途中でコミュニケーションは取るものの、成果物ができて初めて「思っていたものと違う」というズレが露見することも少なくありません。

AI-DLCでは、前提が変わります。AIは「仕様を書いてくれる存在」ではなく、議論を前に進めるファシリテーターとして振る舞います。AIが問いを投げ、ビジネスサイドとエンジニアが同じ場で議論し意思決定していきます。

ただ、ここはボトルネックにもなり得ます。何せ人を集めるという社内調整力に労力がかかるし、全員集めればいい議論になるとも限りません。ここはAI-DLCを推進するPdMやエンジニアの皆さんが、まず最初につまづくポイントです。

専門性が掛け合わさる

現時点では営業サイドまでは巻き込んでいないのですが、議論の質に変化があったことは実感しています。

ビジネスサイドは顧客と業務を、エンジニアは技術と現在の仕様上の制約を理解しています。

よくありがちなのはビジネスサイドが思っている「これ」とエンジニアが思っている「これ」は目線が違う分、解釈に差異があるケースです。コミュニケーションエラーと言ってしまえばそれまでですが。

AI-DLCでは、要件定義を一緒にやります。「機能の仕様は問題ないか」「その仕様でユーザーの問題を解決できるのか」など、AIの問いをきっかけに、顧客視点と技術視点を同時に持ちながら要件を作れるので、要件そのものの質が上がっていきます。

個人最適ではなく、チーム最適へ

2ヶ月やってみて分かったのは、AIは個人の能力を拡張するだけの存在ではない、ということ。

たしかに一人ひとりの作業は速くなります。でもそれ以上、チーム全体の意思決定の質が上がったことでした。個人がAIを使う世界で速くなるのは「アウトプットを作る速度」ですが、AI-DLCで変わるのは「アウトプットそのものの質」です。

ただまだどうなるかはわかりません。今AI-DLCで進めているプロジェクトはグリーンフィールド（新規コード）が中心です。プロジェクトが完了し、そこからアップデートしていく際にはブラウンフィールド（既存コードが元になる）になります。

まだプロジェクトが完了するまでもう少しだけ時間がかかりますが、今後課題になるとしたら、今の速度で品質を落とさずに開発、デリバリーできるかだと考えています。

ボトルネックはAIではなく、人間だった

AI-DLCを始めた頃は、とにかく手探りでした。どんなアウトプットが返ってくるのか読めなかったので、まずはやってみよう精神でAI-DLCを起動して、「◯◯という機能を実装したい」的なところから進めていました。

一緒にこのプロジェクトを進めてくれているエンジニアの中に、AI-DLCを本職でバリバリに進めている方がいました。そのため完全な手探り状態ではありませんでしたが、正直普通にやった方が早いんじゃないかと最初は思っていました。

最初はうまくいっているように見えた

AIは「こういうことですか？」「次はこれを教えてください」と、驚くほど自然に返してきます。やっぱAI優秀だなぁ、もう人間いらないじゃんと思っていました。

ところが要件定義(Inception)の終盤に差し掛かるくらいに、違和感が出はじめます。最初に渡した情報とずれた回答をしてきてしまいました。チャットの指示で直そうとしていたんですが、全く解消されず、頭を抱えました。

AIは間違えているわけではなかった

チャット上で、明確に定義し直した内容を送っても改善されないということは、どこかのコンテキストを引きずってしまっているからだと思ったので、まずは最初に戻ってみました。

その結果、原因は最初に渡したドキュメントの言葉の定義が曖昧だったことでした。AIはその曖昧な定義を正解として認識してしまっていたのです。

詳しくは説明できないのですが、とある機能でLLMにデータを渡す処理があります。データの渡し方には複数のパターンが存在しているため、AIにはパターンごとにどういう渡し方をするのか定義して渡していました。ただ、人でも理解がやや難しいこともあってか、一部ニュアンスで定義してしまっていました。

AIはドキュメントに存在しないコンテキストを把握していません。曖昧なまま情報を渡せば、AIはその曖昧さからなんとかしようと試みますが、間違う時は間違います。

人とのコミュニケーションにおいても、解釈の余地をなくすことが重要です。ただそこには目に見えないコンテキストが存在します。しかしながらAIにそれは通用しません（今の時点では）。AIと開発を進めることにおいては、いかに曖昧な定義をしないかにかかっていると改めて実感しました。

AIは止まらない。だから人間が止まれる単位で渡す

最初に渡した情報を最後まで引きずることがわかったので、AI-DLCを開始する前にSpecsというMDファイルの作成に取り掛かりました。やや規模が大きいこともあり、作成に2週間ほどかかりました。

AI-DLCでは曖昧な要求から矛盾を潰し、構築まで進める機構が備わっているものの、それはAIに委ねる範囲を広げることと同義です。何を作りたいのか、どんな意味を持つのかについては人が責任を持つべきだと考えています。

抽象的に表現するならば、以下の点を意識した方がいいと考えています。

  • 解決したい課題だけを渡す
  • 前提条件と制約を明確にする
  • 論点を小さな単位に分割する

これはAIのためでもあり、人間のためでもあります。人間がレビューできる単位、正しく判断できる単位まで問題を分解しておくことが結果的に速度と質の両立につながるのではないかと現時点では考えています。

やり直しは、思っていたより速くできる

AI-DLCからの質問への回答で、判断に迷うケースも出てきます。質問の意図は理解できても、今作っているものではオーバースペック気味だったり、別件で進行中のものと整合性を合わせなければジャッジできなかったりする場合があります。

現在のプロジェクトではフロントエンドとバックエンドを分けて進めていました。そのため、すり合わせが完了していない事項についての問いがAIから出てきた場合、暫定回答するしかできない場面が度々ありました。

こういった場面においてどうするべきかチーム全体で話し合った際に、以下のような方針に決めました。

  • 不要だと思っても先に進めて最後に捨てればいい
  • やり直しといっても一度議論しているので回答はサクサク進められる

2週間かけて作りたいものを明確に定義していたこともあり、手戻りが発生することはほとんど起きていないのですが、学びとして下記のようなことが言えます。

間違いに早く気付いて素早く戻れること

質問への回答が適当になってしまい、想定したアウトプットが出なかったり、前提の間違いに後で気づいたりした場合でも、すぐにリカバリーできます。

なぜなら、一度議論したことで、何が曖昧だったか、どこがズレたかがわかっています。そのうえで何を定義すべきかも明確になっている状態だからです。また、そこまでのやりとりは全てドキュメントとして残っています。そのため、やり直しといっても0から考えるのではなく、整理した内容をAIに伝え直すことがメインになります。

AI-DLCは矛盾した状態のままでは前に進められない仕組みです。しかしそれは、AIにとって矛盾がない状態とも言えます。誤った情報を与えてしまった場合でも、AIは矛盾を修正するような問いを投げかけてきます。また、推奨回答&理由もセットで提案されることがあります。一見ありがたい機能なのですが、思考の放棄につながる恐れもあるため、脳死で選択しないよう注意しましょう。

早く戻れるようにするためには、AIに与える情報をできる限り小さくすること、もっと言えば人が理解できる単位で与えることが重要だと考えています。AIと人、双方の認知負荷をできる限り減らす工夫をすれば、やり直すコストもその分小さくなります。

専門外に、はみ出せるか

Inception（要件定義フェーズ）の後半からConstruction（設計・実装フェーズ）にかけて、AIの問いがどんどん変わっていきます。Inceptionの前半は「誰の課題を解決するのか」「どんな体験を届けたいのか」といった、ビジネスサイドが得意とする問いが多くなります。一方、後半以降は「データはどう持つか」「APIをどう設計するか」「権限をどう考えるか」といった技術的な問いが中心になります。

記事の前半で人を集めることがネックになると述べましたが、ここもネックになると思っています。特にビジネスサイドの参加者にとって、技術的な話はわからなすぎてつまらないと思われるケースもあるでしょう。

全員が全員何にでも興味を持つわけではないですし、自分の業務と全く異なる話ならなおのこと起こり得ます。AI-DLCを社内で推進していくためには、巻き込み力は思っている以上に重要です。

興味を持つと意識が変わる

前職でPdMをしていた際は、データ設計に関してはエンジニアに全て任せて口は出さないという方針で進めていました。口を出さないことと理解していないことでは話が違うので、今思えば反省すべき点です。当時は「データをどう持つか」「なぜこの設計が妥当なのか」といった話をあまり深くしていませんでした。

AI-DLCはチームで議論しないことには価値が生まれないため、必然的に質問も増えていきます。バックエンドのアーキテクチャについて議論する際に、これまでと何が異なるのか、想定できるリスクはどんなものがあるのかなど、ホワイトボードで図にしてもらいながら理解を深めていました。

大事なのは、なぜその設計が選ばれたのかを理解することであって、自分が設計できるようになることではありません。設計の意図を理解することで、議論全体の質が上がると同時に今後新しく開発をする際にも無駄にならない話です。一方でエンジニアにとっては、顧客を主語にした会話も増えるので、なぜその機能が必要とされるのか想像しやすくなるメリットがあります。

ゼネラリストになるのとは異なる

専門外に染み出すことというのは、全員が何でもできるようになろうという話ではないと考えています。

エンジニアは技術のプロであり、ビジネス側は顧客と業務のプロです。その役割自体は変わりません。ただ、互いの領域に一歩踏み込んで会話できるようになると、意思決定の質が変わります。

お互いの専門性を理解し合いながら議論することで、プロダクトの品質が向上するとともに、チームとしての一体感も強化されます。

チーム力は、個人の能力の総和ではない

まとめると、チーム力は個人の能力の足し算ではないということです。

一人ひとりの知識量が増えたから強くなったのではありません。それぞれが少しずつ専門外を理解し、同じ前提で議論できるようになった結果、チーム全体の意思決定の質が上がった。そこに加えてチーム力も上がりました。同じ釜の飯を食うとはよくいったもので、やっぱり共通認識が増える分、意識も変わってきます。

意思決定したことだけ残してしまうと今度はそれが負債になる

最後に、もう1つ気付いたことがあります。成果物として意思決定したものは残るのですが、なぜその意思決定をしたのかという背景情報は残りません。AI-DLCのログは必ず原文のまま残す仕様ですが、そこにはあくまで決定事項しか記録されていません。

残らないもの

「なぜこの設計を選んだのか」「なぜA案ではなくB案なのか」「そのときどんな懸念が議論されたのか」。こうした意思決定の背景は、ログを見るだけではわかりません。暗黙知になっていた仕様が形式知化されるという意味では、プラスな面もあります。

AI-DLCは、AIが問いを投げ、人間が議論し、人間が意思決定・監督する仕組みです。本当に重要なのは、人間同士の議論のほうです。その議論を残さなければ、後から見た人には成果物だけが残り、「なぜこうなったのか」は誰にも分からなくなります。

AIしか理解できない開発にしない

避けたかったのは、AIしか理解できない開発になることでした。人がコーディングすることはなくなるにせよ、AIにお願いするしかない状況はリスクです。人が触るものを提供する以上、最終的な責任は全て人にあります。

そのようなリスクをできる限り抑えるために、「何を重視して決めたのか」「他にどんな選択肢があったのか」は必ず議事録に残すべきです。開発が続くほど背景を知る人は減り、新しいメンバーは過去の判断理由が分からないまま進めることになります。AI-DLC以外の文脈でも語られますが、やはり暗黙知にさせないことは非常に重要です。

AIを使う側であり続ける

AIはこれからもっと賢くなり続けるでしょう。少なくとも知識だけで言えばもう人間を遥かに超えています。今はまだ一部でも設計書、コード、レビューも全部AIが代替していきます。

だから人間の役割は「作ること」から「判断・監督すること」にシフトしていきます。

でも、その判断までAIに委ねてはいけません。人が触るプロダクトを作る以上、どんな体験が良いのか、どんなプロダクトを作るべきなのか。その意思決定に責任を持つのは、最後まで人間です。AIが生成したコードでも、リリースする責任は私たちにあります。

だからこそ、AIに使われるのではなく、AIを使う側であり続けること。そしてAIだけが理解できる成果物ではなく、人も理解できる意思決定を残すこと。これが、AI-DLCを実運用して一番強く感じたことでした。