はじめに
こんにちは、テックリードの桑名です。
2026年7月16日〜17日の2日間、AWS 主催の「集合型 AI-DLC Unicorn Gym」に参加してきました。
AI-DLC（AI-Driven Development Life Cycle）は、AWS が提唱している AI 駆動開発のライフサイクルです。単に AI にコードを書かせるという話ではなく、要件定義から設計・実装までを AI と一緒に回す前提で開発プロセスそのものを組み替える、という考え方が特徴です。
今回の Unicorn Gym は、複数の企業が同じ会場に集まり、各社が自社の実テーマを持ち込んで2日間ひたすら手を動かすという形式でした。弊社からは開発・QA・デザイナー・マネージャーを含む8名のチームで参加し、LANSCOPE エンドポイントマネージャー クラウド版の既存機能のリアーキテクトをテーマに取り組みました。
この記事では、AI-DLC をチーム開発に適用した2日間の流れと、実践を通じて分かったことを共有します。特に大きかったのは次の3点です。
- 要件整理のリードタイムを大きく短縮できたこと
- 議論が行き詰まったときは、モックで具体化すると前に進みやすいこと
- AI-DLC を導入するには、品質保証などの運用面も自分たちで設計する必要があること
AI-DLC や AI コーディングエージェントをチームで活用することに関心のある方の参考になれば嬉しいです。
AI-DLC とは
AI-DLC は、要件分析からコード生成までを次の3つのフェーズで進める開発ライフサイクルです。
- Inception（構想）：要件分析 → ユーザーストーリー → アプリケーション設計 → 作業単位（Unit）への分割
- Construction（構築）：Unitごとの機能設計 → 非機能要件・設計 → インフラ設計 → コード生成 → ビルド・テスト
- Operations（運用）：リリース後の運用
各フェーズで AI が成果物のたたき台を生成し、人間がレビューして承認する。承認しないと次に進まない、というのが基本の流れです。「Unit」は機能や画面のまとまりを目安にした作業単位で、今回はバックエンドとフロントエンドで1つずつに分割しました。
今回は AI コーディングエージェントとして Kiro を使い、AI-DLC のワークフローをステアリングとして読み込ませた状態で進めました。ワークフロー自体は OSS として公開されています。
イベントの流れ
Day 1 午前：まずは個人ワークで一周する
初日の午前は、いきなりチームの実テーマに入るのではなく、全員が個人ワークで AI-DLC を一周するハンズオンから始まりました。
お題は「シンプルな EC サイトを構築したい」という一文だけ。この一文から AI が要件定義書を起こし、ペルソナ・ユーザーストーリーを作り、アプリケーション設計を経てコード生成まで到達します。
各フェーズで AI から確認事項が投げられ、それに答えることで成果物が固まっていく感覚を、まず自分の手で体験する。この助走があったおかげで、午後からのチーム作業で「今どのフェーズにいて、次に何が起きるのか」を全員が共有できていました。
Day 1 午後：チームの実テーマへ
午後からが本番です。私たちが持ち込んだのは、長年の機能追加で複雑化してしまった既存機能のリアーキテクトでした。
具体的な機能名は伏せますが、以下のような状態になっていました。
- 関連する設定が複数の画面に分散していて、どこで何を設定すればよいのか分かりにくい
- 検知される事象の種類によって表示期間や消えるタイミングが違い、挙動を予測しづらい
- 一覧を見ても「何が起きていて、次に何をすべきか」が読み取りにくい
この機能はもともと従来型のプロセスでリプレイスを企画していたところでした。そこに AI-DLC を当ててみて、新しいプロセスでどこまで到達できるかを試す、という位置づけです。
事前に用意していた要件メモを Kiro に読み込ませ、生成された requirements.md をチーム全員でレビューするところから始めました。
ここで一番驚いたのはスピードです。今回は、事前に用意した要件メモをもとに、AI との対話で要件整理の初稿を約1時間半で作成しました。通常、この範囲の洗い出しから関係者レビューまでには1週間以上かかることもあります。参加していた QA エンジニアからも「普段は上流に関わりたくても時間が取れなかったが、この速度で言語化とビジュアル化ができるなら関われる」という声が出ていました。
一方、後半はかなり苦戦しました。「システムが検知する前に、ユーザーが設定する必要はあるのか？」という論点で意見が割れ、Kiro を放置したまま人間同士の議論が長時間続いてしまったのです。
- 事前に設定してから検知する案：管理者が対象を有効化し、その後に判定・保存する
- 常に判定して表示時に制御する案：システムが常に判定・保持し、ユーザーは一覧の表示やフィルターだけを操作する
どちらにも理があり、しかも全員が想像で話しているので平行線でした。AI を使えばもっと速く決められたはずの場面で、結局一番時間を溶かしたのが人間同士の議論だったのは、率直に反省しています。
初日の夕方には各社が持ち回りで中間報告を行う時間がありました。そこで私たちがこの課題を挙げたところ、AWS のソリューションアーキテクトの方から「意思決定は戻れる。情報が足りないなら、モックを作って確かめればいい」とフォローをいただきました。他社の発表を聞いても、「AI を置いてけぼりにして人間同士で議論してしまう」という現象はどのチームでも起きていたようでした。
この一言を受けて、Kiro にモックを作らせ、それを見ながら方針を決めるやり方に切り替えました。最終的に「まず常時判定を仮説として進め、技術的・運用的に成立しなければ戻す」と仮置きして、次のフェーズに進むことができました。
Day 2：設計からコード生成・デプロイまで
2日目は残っていたユーザーストーリーを仕上げてから Inception の後半（アプリケーション設計、作業単位への分割）を進め、午後は Construction に入りました。
- 午前：ユーザーストーリー完了、アプリケーション設計のレビュー、作業単位（Unit）の生成
- 午後：Unit 1（バックエンド）の機能設計を経て、バックエンド／フロントエンドの2チームに分かれて並行作業。コード生成からビルド・デプロイ着手まで進行
2日間の到達点は次のとおりです。
- ユーザーストーリー4本と受入基準の定義
- アプリケーション設計・機能設計・インフラ設計のドキュメント一式
- バックエンドのコード生成とデプロイ着手（ユニットテストはローカルで通過）
- フロントエンドのコード生成とビルド完了、画面プロトタイプ
やってみて分かったこと
決めるまでのリードタイムは確実に縮む
一番大きな効果はリードタイムの短縮でした。普段の開発では、確認や合意形成がどうしても非同期になります。「聞く → 待つ → 返ってくる → 手戻る」の往復が積み上がって、要件定義に1週間以上かかることも珍しくありません。それが AI-DLC では、関係者が同じ場でその場で意思決定していくため、この往復がほぼ消えます。意思決定に必要な情報を集めるスピードも上がるので、これは工数の話というより、決めるまでのリードタイムの話です。
一方で、上流が速くなった分、総合テストや品質保証、監査対応といった工程を今のやり方のままにしておくと、そこが新たなボトルネックになります。AI-DLC は組織やプロダクトの事情に合わせて運用を組み立てる前提の方法論だと思うので、品質保証の枠組みをどう組み込むかは、私たちの側で考えて整えていく必要があると感じています。
完璧を目指さず、抽象度を下げながら前に進める
2日間で実感が変わった学びのひとつです。
進めていくうちに、最初のフェーズでは大枠だけを固め、後のフェーズで徐々に具体化していく、という進み方が自然だと感じました。細部まで決め切ってから次に進む必要はなく、抽象度を段階的に下げていけばいい。実装の型や UI の細部のように後から変えやすいものは、Inception の段階であれば仮置きでどんどん前に進めてよいはずです。
慎重になるべきは、ユーザーストーリーの前提や要件の解釈そのものです。ここがズレたまま後工程に進むと、設計やコード生成がすべて間違った前提の上に積み上がってしまいます。
AI があることでやり直しのコスト自体が下がっている感覚もありますが、これはまだ肌感覚の話です。以前なら「戻れない決定」だったものが、AI 時代には「戻れる決定」に変わっているケースもあるかもしれません。それでも、ユーザーストーリーの前提のようにすべての後工程の土台になる決定は、引き続き慎重に扱う価値があると感じました。
情報が足りない議論は、モックを作って確かめる
初日にハマった「事前設定か、常時判定か」の議論は、まさにこの典型でした。空中戦になっているときは、たいてい全員が想像で話しています。AI を置いてけぼりにして人間だけで長時間話し込んでも、想像と想像がぶつかるだけで決着しません。
「イメージはこうだよね？」を口頭で揃えるのは難しいので、短時間でモックを作って具体物を見ながら話すほうが早い。Inception の途中でもモックを作っていい、という選択肢を得られたのは大きな収穫でした。
意外とみんな AI に聞かない、頼るときは「背景」まで渡す
これはチーム全体の反省です。
「あの仕様どうなってたっけ？」を確認するとき、私は画面を探したり既存の実装を追ったりしていました。冷静に考えるとコードは Kiro に渡してあるので、そのまま聞けばよかったのです。議論が煮詰まったときも同じで、人間同士で話し続けるより先に AI に投げるべき場面が何度もありました。チームで話した結果、「5分議論して結論が出なければ AI に投げる」くらいのルールを決めて運用するのが良さそう、という結論になりました。
ただ、投げ方にも工夫が必要でした。異なるロールのメンバーで進めたので、意見がぶつかる場面が多くありましたが、議論が着地しなかった原因のひとつは、その人が持っている考えの背景を伝えられていなかったことだと思っています。結論だけを言うと平行線になるので、「結論＋そう考えた理由（観点）」をセットで出す。そしてそれを Kiro にどんどん入力してまとめさせる。この形にすると議論の文脈が残り、後から AI も適切な提案ができるようになります。
エンジニア自身が、顧客の運用を理解していく必要がある
参加メンバーはシステム理解は深いものの、顧客の実運用については想像で深掘りしてしまう場面がありました。メンバーごとに業務経験に基づく「正しさ」があるため、それぞれが正解を主張して落とし所を作りにくくなります。
想像同士をぶつけている限り、この手の議論に決着はつきません。落とし所を作るには、想像ではなく実際の運用を知っている必要があります。AI-DLC のスピードで意思決定していくなら、その場にいるエンジニア自身が顧客の実運用をどれだけ理解しているかが、議論の質をそのまま左右します。モックがすぐ作れるようになったからこそ、それを持ってユーザーヒアリングに同席するなど、エンジニア自身が仮説検証のサイクルを回していく機会を増やしたい、という話になりました。
おわりに
2日間ずっと決めることの連続で、頭の使いどころが普段とまったく違いました。糖分の補給が必須だったのは、たぶん私だけではないと思います。
AI-DLC のフレームワーク自体は個人開発で触っていたので、流れは知っていました。それでも今回チームでやってみて分かったのは、いろんな役割の人がそれぞれの立場で必要な情報をインプットしていくことでいろんな可能性が検討できて、決められる人も揃って同期で進めることで、ものごとがどんどん進むということです。
今後に向けて、午前中をプロダクト開発の時間として確保して、複数チーム・数十人規模の全開発メンバーが同期的にプロダクト開発に入れる体制を作りました。上流が速くなった分、品質保証や監査対応がボトルネックにならないよう、やり方自体を検証・検討しています。
イベントで作ったものは本プロジェクトの正式なインプットとして引き継ぎ、リリースに向けて引き続き開発を進めています。
最後までお読みいただき、ありがとうございました。
