テクノロジー本部 AI エンジニアリング部の吉田です。
2025 年 11 月 17 〜 19 日の 3 日間、アマゾンウェブサービスジャパン合同会社が開催する、「AWS AI-DLC Unicorn Gym」というワークショップに参加しました。
本記事では、3 日間のワークショップで得た気づきと、学びを共有します。体験したからこそわかったこと、見えてきた課題について、率直に綴ります。
AI-DLCの基本概念については詳しく触れていないため、次のセクションの参考資料をご参照ください。
なお、本記事の内容は筆者個人の見解に基づいています。
AI-DLC / AI-DLC Unicorn Gym とは何か
AI-DLC（AI-Driven Development Lifecycle） は、AI を前提に要件整理・設計・実装・テストまでを進めるための開発プロセスの考え方です。詳しい背景や進め方については、AI-DLC Whitepaper や AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築 | Amazon Web Services ブログ を参照してください。
出典：AI-Driven Development Life Cycle (AI-DLC) Whitepaper
AI-DLC Unicorn Gym は、その AI-DLC を実際のプロダクト開発テーマで短期間に体験し、自社での活用イメージをつかむためのワークショップ型プログラムです。今回のワークショップは 3 日間の集中形式で開催され、参加者は実際のプロダクト開発テーマに取り組みました。
今回のワークショップには、3 つのチームが参加しました。私のチームは新規サービス開発をテーマとし、プロダクトオーナー（PO）とエンジニアの 2 名での挑戦でした。
私たちの3日間の記録
Day0: 備える
ワークショップの前に、事前に資料やブログの内容を読み、AWS さんからも事前に AI-DLC とはどういったものかという概要を教えていただいていました。
そこで受けた印象は、「AI にいろいろ任せることで開発スピードがとんでもなく速くなるプロセスなんだなあ」くらいのものでした。
そんなぼんやりした期待を持った状態で 3 日間のワークショップに臨みました。
Day1: 駆ける
初日の午前中は、AI-DLC の概要説明からスタートしました。AI-DLC とは何か、どのようなプロセスで進めるのか、従来の開発手法との違いなどについて説明を受け、AI-DLC に対しての具体的なイメージを掴みます。
午後からは、事前に準備していた課題を実際に AI-DLC で進めていきます。まずは Inception フェーズを行い、ユーザーストーリーの作成と Unit 分割をします。
実際に Inception を進めてみて驚いたのは、最初の Intent（要求） から具体的なユーザーストーリーまで落とし込まれるスピードです。
これまでのやり方だと、そこまでたどり着くのにもっともっと時間をかけていた印象があります。要求を整理し、ユーザーストーリーに分解し、優先順位をつけて...という作業に、従来なら数日間かかっていたかもしれません。それが半日足らずで完了しました。
この手応えは非常に大きく、「これは本当に開発のスピードが変わるかもしれない」という期待を抱かせるものでした。
Day2: 変える
2 日目は、大きな決断から始まりました。
朝一番、PO から提案がありました。「Inception をやり直そう」と。
というのも、「このまま進めると、エッジのない平凡なサービスになるのでは？本当に届けたい価値は何なのか、その価値をもっと明確にし、そこに集中すべきではないか。」という思いが初日の夜から心に引っかかっていたそうです。
この問いかけに、私も即座に同意しました。このまま続けていくことで、本当に届けたい価値が届かないのは不本意だと。
初日に作成したユーザーストーリーやコンセプトをすべて捨てるという決断、普段であれば躊躇するはずです。しかし、なぜかチームの誰も後ろ向きにならず、むしろ「やり直してもなんとかなる」という不思議な確信がありました。
結果として、2 日目は Inception フェーズからやり直しました。
Inception を再実施した後、Construction フェーズ（実装）に入り始めたあたりで 2 日目が終了しました。やり直したにもかかわらず、ここまで進めることができたのです。
Day3: 削る
最終日は、Construction フェーズを完遂することを目標に掲げました。
開発すべき機能は 4 つの Unit に分割されています。Unit 4 こそが、私たちが本当に届けたい価値の核心部分でした。
最初は順番どおりに進めていましたが、このままでは核心部分の Unit 4 にはたどり着けない見込みでした。
Unit 1 をいったん切り上げ、Unit 2、3、4 を対応していく方針に切り替えました。
それでも Unit 4 にたどり着くには、それに依存する Unit 2 と Unit 3 を終わらせないといけません。
ここは奥の手として 2 つの Unit を同時に進めるという策に打って出ました。
結果的に、Unit 4 は完了させられませんでしたが、Unit 2 と Unit 3 は完遂できました。普段の開発では、この判断とスピードは実現できなかっただろうと感じます。
ただし、並行作業を進めている最中、PO から心配されるほど、明らかに自分は疲弊していました。
2 名のチームで複数の Unit を同時に進めるのは、想像以上に負荷が高かったのです。
そんな、内容の濃い 3 日間を過ごしました。
この3日間、AI-DLCとは何だったのか
ワークショップに臨む前とこの 3 日間をふりかえったとき、いくつもの「なぜ？」に直面します。
- Day1: なぜあれほど圧倒的なスピードで進められたのか？
- Day2: なぜ丸 1 日分の成果を捨てる決断を、誰も躊躇しなかったのか？
- Day3: なぜ並行作業で、想像以上に疲弊してしまったのか？
何より、Day0 で抱いていた「AI に任せれば開発スピードが上がる」という期待は正しかったのか。
AI-DLCとは何だったのか。
それぞれの「なぜ？」に答えを見出すことで、AI-DLC の本質を探ります。
本質は「プラン→レビュー→実行→レビュー」のサイクルにある
Day1 で体験した圧倒的なスピード。なぜあれほど速く進められたのか。
体験した身からすると、AI-DLC の本質は 「プラン→レビュー→実行→レビュー」のサイクル にあると理解しました。どのフェーズにおいてもこのサイクルが真ん中にあります。Inception でも、Construction でも、常にこのサイクルを回し続けます。
出典：AI 駆動開発ライフサイクル(AI-DLC)ソフトウェアエンジニアリングの再構築
具体的には、AI にユーザーストーリーの作成や Unit 分割の計画を作成させ、生成された計画をチーム全員でレビュー、承認後に実行。実行結果もまたレビュー。という具合です。
AI-DLC はこの、「プラン→レビュー→実行→レビュー」のサイクルを何度も続けます。
ふりかえると、普段の開発も同じです。
何をするかまず決めて、そして実行に移す。その間に何度もレビューしています。
AI-DLC とこれまでの開発の違いは、AI を使うことでこのサイクルが高速に行われるという点です。
このサイクルが AI-DLC の本質であり、これを理解してちゃんと回せるかどうかで全て決まると実感しました。
投資した時間への執着からの解放がもたらすもの
Day2 で体験した、やり直しの決断。なぜあれほどスムーズに決断できたのか。
まず、これまでの開発のことをふりかえってみましょう。
本来、誰もが「価値を届ける」ことを主目的としています。ただ、この主目的を判断基準として決断していくのは非常に難しいものです。
方向性がおかしいことに気づいたとき、すでにかなりの時間を使っていることがほとんどで、「ここまでやってきたんだから、とりあえずこのまま進めてみようか」という結論に陥ることがあります。投資した時間への執着、いわゆるサンクコスト効果が、本来最も重要なはずの「価値を正しく届けられるか」という判断基準を鈍らせてしまうのです。
間違いに気づいても軌道修正を躊躇させる。方向性を変えるべきだと感じても踏み切れない。
AI-DLC は違いました。たった 1 日でユーザーストーリーの作成や Unit への分割といった Inception フェーズの主要な作業を完了できたという事実が、私たちに「ここで大きく方針転換したとしても、なんとかできるだろう」という自信を与えてくれました。
この自信は、2 つの要素が起因しています。
ひとつは、モブワークによる頻繁な意思統一です。
エンジニアと企画が同じ場所で、同じ画面を見ながら、リアルタイムで対話する。この環境があったからこそ、「価値」について常に共通認識を持ち続けることができました。
「Inception をやり直そう」という提案に対して、誰も後ろ向きな気持ちにならなかった。それは「価値を正しく届けられるか」という、本来あるべき判断基準で物事を考えることが、その場にいるメンバー全員で意思統一できていたからです。
もうひとつは、AIによる圧倒的なスピードです。
このスピードがあったからこそ、「やり直してもなんとかなる」という心理的な余裕が生まれ、大胆な判断ができました。
これは開発手法の変化というより、チームの意思決定文化の変革だと言えます。AI-DLC が変えるのは、開発のスピードだけではありません。チームが本来持っている「価値を届ける」という判断軸を、サンクコスト効果から解放し、正常に機能させる力を持っているのです。
人間のキャパシティという制約
Day3 で体験した想像以上の疲弊。なぜあれほど負荷が高かったのか。
AI-DLC が速いからといって、人間のキャパシティを超えた並行作業は無理があるということを痛感しました。
1 つのチームで 2 つの Unit を同時並行するのは良くありません。人間側の認知負荷が高すぎます。「プラン→レビュー→実行→レビュー」のサイクルを高速で回すためには、人間が常に集中してレビューし続ける必要があります。複数の Unit を同時に進めると、この集中力が分散され、レビューの質がどうしても落ちてしまいます。
AI-DLC は確かに圧倒的なスピードをもたらしますが、それは人間のキャパシティを無限にするわけではありません。むしろ、人間が本来持っている判断力やレビュー能力を最大限に発揮できる環境を整えることが重要です。スピードを追い求めるあまり、人間側の限界を超えてしまっては本末転倒です。
同時に、使い手側の能力向上も欠かせません。高速なサイクルについていくには、素早く本質を見抜き、的確に判断する力が求められます。
AI-DLCは開発をどう変えるのか
3 つの「なぜ？」に答えを見つけてきました。
Day0 で抱いていた期待、「AI に任せれば開発スピードが上がる」は正しかったのでしょうか。
答えは、半分正解で半分間違いです。
AI は確かに強力な出力装置として機能します。プランに沿ってユーザーストーリーを作成してくれますし、コードも生成してくれます。しかし、それで終わりではありません。
出来上がってきたユーザーストーリーが適切であるか、正しく価値を届けられるものになっているかというジャッジを下すのは人です。AI が生成したコードが要件を満たしているか、品質は十分か判断するのも人です。
指示に沿ってすべてを AI が作ってくれるという幻想、つまり「AI 主役」のイメージは誤りです。あくまでも AI は出力をしてくれるだけで、最後の最後は人が責任を持って判断をする。つまり人が主役なのです。
AI-DLC の本質は、人が主体となり、AIを道具として使いこなすプロセスでした。
高速なレビューサイクルを回す。
サンクコスト効果から解放され、価値に集中する。
人間のキャパシティを理解し、適切な環境を整える。
モブワークで頻繁に意思統一する。
そのすべての中心にあるのは「人」です。
3 日目の最後、参加した全チームでふりかえりをしました。どのチームの感想も、本質は人に立ち戻っていくようなものばかりでした。このふりかえりを通じて、改めて「人が重要なんだ」と気づかされました。
AI-DLC が変えるのは開発プロセスです。高速なレビューサイクルとモブワークが、スピードと意思決定の文化を変えます。しかし人が主体であることを忘れてはならない。これが、3 日間で体験した AI-DLC の答えでした。
体験から実践へ
3 日間のワークショップを通じて、AI-DLC は非常に有用な開発アプローチであることを実感しました。「プラン→レビュー→実行→レビュー」のサイクルを高速に回すことで、従来では考えられないスピードで開発が進んでいきます。
しかし同時に、AI-DLC はアジャイルの本質的な考え方を共有していますが、スクラムなどの具体的なプラクティスはそのまま適用できないこともわかりました。例えば、見積もりの出し方、チーム構成、PO の関与の仕方など、従来の前提が通用しない場面が多々ありました。
そして何より、AI-DLCは魔法ではなく、実践と習熟が必要なアプローチであるということを知れたことが、大きな収穫でした。AI が全てを自動的に解決してくれるわけではありません。人が主体となり、AI をツールとして使いこなし、チームで協働しながら進めていく。そのプロセスそのものが、AI 時代の開発スタイルなのだと理解できました。
AWS AI-DLC Unicorn Gym に参加できたことは、非常に価値のある体験でした。新たな開発プロセスを実際に体験することで、AI との付き合い方・向き合い方について、ひとつの解を見出すことができたように感じています。
エムティーアイでは、ワークショップ後も複数のチームで AI-DLC の実践を継続しています。AI を活用した開発へのシフトは既定路線ですが、「どのように進めるのが最適か」についてはまだまだ模索中です。チーム構成、事前準備、リモート対応、組織体制など、解決すべき課題は多く残っています。
重要なのは、体験して終わりではないということです。いかにこれを自分たちの体になじませ、染み込ませることができるか。そのための継続的な実践と学習が、今後にとって最も重要だと考えています。
