AI-DLCとUnicorn Gymとは
AI-DLC（AI駆動開発ライフサイクル）とは、AIを開発プロセスの中心に据え、企画から実装までをチーム全員で協働しながら高速に進める開発手法です。
詳しくはAWS公式ブログを参照してください。
Unicorn GymはAWSが主催するワークショップです。開始から半日ほどはサンプルプロジェクトを元にAI-DLCの流れを体験し、その後の2.5日で実際の業務テーマで開発をします。
私は5/18~20の3日間、テックリードという立場で参加しました。
AI-DLCのフェーズと3日間の流れ
AI-DLCは大きく以下のフェーズに分かれます。
| フェーズ | 内容 | 我々の進捗 |
|---|---|---|
| Reverse Engineering | 既存コード解析 | Day1 午後イチ |
| Requirements Analysis | AIと対話しながら要件を明確化 | Day1 まる1日 |
| User Stories | ユーザーストーリーの作成 | Day2 午前 |
| Application Design | アプリ上にどう作るかの全体設計 | Day2 午後 |
| Units Generation | 実装単位への分割 | Day2 終盤 |
| Functional Design | 各ユニットの機能設計 | Day3 |
| Code Generation | 実装 | Day3（一部のみ） |
| Build and Test | ビルド・テスト | 未着手 |
各フェーズではAIが成果物（ドキュメントやコード）を生成し、人間がレビュー・承認して次に進みます。
なぜ既存システムで挑んだか
他チームは新規テーマを持ってくる中、我々のチームは7年以上運用している既存システムを持ち込みました。
テーマはメール・Teams・Excelで実施されている内部運用のシステム化です。
ワークショップ参加にあたって、新規開発をテーマとする方が楽なのは間違いありません。
しかし我々が日常的に向き合っているのは、大量のデータと複雑な既存ロジックを抱えたシステムです。7年の間にメンバーの入れ替わりもあり、開発者、PdM、プロダクトオーナー、仕様策定担当とポジションも異なる8人が、それぞれ異なる深さでシステムを理解している状態でした。
ここでAI-DLCが使えなければ導入は難しいため、あえて既存システムで挑みました。
結果: 2倍速で進んだが開発完了まで進めず
3日間でInception Phase（何を作るか決めるフェーズ：要件〜設計）全完了 + Construction Phase（どう作るか決めて実装するフェーズ）途中まで到達しました。日常の開発より2倍速程度は出た感覚です。
ただし、テストからリリースまでを含めたトータルで考えると、おそらくもっと控えめになります。
世の中のAI-DLC導入事例では3倍、5倍の速度向上を謳う記事もありますが、ここからは我々が2倍程度に収まった理由と、逆に2倍出せた理由を整理します。
2倍出せた理由
Unicorn Gymという環境
外部イベントという形式だからこそ、8人を3日間割り込みなしで空けることができました。業務中にこれだけの時間をまるまる確保するのは現実的に無理です。
また、必ず対面になるので、「強制的に集中できる環境」が最大の要因だったのかもしれません。
Reverse Engineering（既存コード解析）が優秀
Reverse Engineeringは、AIが既存コードを読み込んでシステムの全体像をドキュメント化するフェーズです。
我々が持ち込んだシステムは7年間の開発の中で、LaravelとReact+Expressのような異なるアーキテクチャが混ざる状態だったのですが、リポジトリ内のコードを上手く整理してくれたため、後続フェーズでAIがそこまで混乱することはありませんでした。
ただし、過去の方針決定のドキュメントがgitにないため、AIが判断に迷う事が何度かありました。これはプロジェクト期間が長くなればなるほど起こる問題だと思います。
とはいえ、既にアーキテクチャは整理されているので、あとはテックリード視点でAIに適宜方針を伝えれば、大きな問題にはなりませんでした。
このように、即断できる人がいる領域ではAI-DLCの速度が最大限発揮されます。
逆に言えば、人間が即断できない領域はボトルネックになります。
AI-DLCプロセスによる要件分析
Requirements Analysis（要件分析：何を作るべきかをAIと対話しながら明確にするフェーズ）では、AIが既存の業務フロー文書を読み込んで22問の質問を自動生成しました。AIが網羅的に質問を出してくれたので、要件漏れを減らせたと思います。
さらに、AIの質問に答える過程で人間も要件に対する理解が深まるため、サービスの質が上がります。
ただしこの Requirements フェーズで早速人間がボトルネックになりました。
2倍程度に収まった理由
何が起きたか
3日間の内訳を振り返ると、Inception Phase（要件〜設計）にほぼ2日かかりました。Requirements Analysisだけでまる1日、その後のUser Stories（ユーザー視点での要求整理）・Application Design（アプリケーション設計）・Units Generation（実装単位への分割）で2日目の終わりまで。
3日目は16時から発表のため、Construction Phase（実装）にはほとんど時間をかけられていません。
根本原因
問題はチームにありました。
前述の通り、7年の間にメンバーの参加時期もポジションもバラバラで、チーム内で要件に対する理解度に大きな差がありました。
また実際にシステムを使う運用メンバーがチームに居なかったため、要件定義に対するレビューで「これは本当にこの解釈で合っているのか」「この運用は変えていいのか」という確認がメンバー間で繰り返し発生し、全員が納得するまで次のフェーズに進めない状態が続きました。
問題を深掘りしていくと、本質は「どこまで理解すれば先に進んでいいのか」の基準がチーム内で非常に高かったのが原因でした。
AIへのインプット自体は用意できる。AIが整理した結果も出る。でもそこから先、全員がそれを読み、各自が確認し、メンバー間で質問し合い、「全員が完全に理解する」まで進めない。
多少の手戻りがあってもAIが高速で実装してくれるので、慎重になりすぎたのかもしれません。
見えてきたチームの課題
これはAI-DLCの問題ではなく、我々のチームの成熟度の問題だと思っています。
AIにより実装が高速化しており、AI-DLCも各フェーズで方向修正できる構造になっている現在、ドキュメントに完璧を求める必要はなく、後のフェーズで「やっぱり違った」と気づいたら戻ればよかったのです。
実際、スコープ変更が4回発生しましたが、変更自体は問題なく処理できました。
我々に足りなかったのは、「全員が納得するまで進めない」状態から抜け出すための意思決定の基準だと思います。
その対策の一案として、「Consensus（全員合意）」ではなく「Consent（致命的な反対がなければ進む）」という意思決定モデルが有効かもしれないと考え、別記事にまとめました。
一方、技術的な課題ではテックリードとして即断し、それでスムーズに進んでいました。これはテックリードの決断をチームが信頼して委任してくれたからです。
このことからも、今回の問題が際立ってしまったと思います。
まとめ
AI-DLC Unicorn Gymを通して、確かに開発速度は上がりました。ですが、AI-DLCはあくまでツールです。重要なのは、人間の作業が減り判断の比重が高まったこと。
AIがどれだけ優秀でも人間が判断を下せなければ何も進みません。AI-DLCは作業を加速してくれますが、思考や判断は加速してくれないのです。
Werner Vogelsがre:Invent 2025のkeynoteで語った言葉を借りるなら "The work is yours, not the tool's." 。仕事はあなたのものであり、ツールのものではない。
AIに任せる作業が増えても、判断し、方向を示し、チームを前に進めるのは人間がやるべき仕事です。その仕事を自分たちのものとして成熟させられるチームであれば、真にAI-DLCのポテンシャルを引き出せるはずです。
本ブログに掲載している内容は、私個人の見解であり、所属する組織の立場や戦略、意見を代表するものではありません。