AI-DLC Unicorn Gym に参加してきました

Author:

2026-02-16

はじめに

こんにちは。Belong でバックエンドエンジニアをしている ke-no です。 2026 年 2 月 4 日から 2 月 6 日にかけて、AWS が主催する AI-DLC Unicorn Gym ワークショップに株式会社 Belong として参加してきました。実際に新規開発案件で AI-DLC を実践するにあたって、多くの学びや気づきがあったため、本記事で共有できればと思います。

今回のワークショップの主題である AI-DLC は大きく分けて下記の 3 つのフェーズで構成されています。

Inception: 何を作るかを明確にするフェーズ
Construction: どう作るかを決めて実装するフェーズ
Operation: 実際に動かして改善するフェーズ

AWS AI-DLC Unicorn Gym では、3 日間かけて 3 フェーズ全体の流れを体験できたので、後のセクションで詳しくご紹介します。
AI-DLC についての詳細や、具体的に何が嬉しいのか？プロンプトは何を使うのか？といった疑問をお持ちの方は、弊社 CTO の下記記事をぜひご覧ください。

AWS AI-DLC Unicorn Gym について

AWS AI-DLC Unicorn Gym は、AI-DLC の実践的な理解を深めることを目的としており、参加者は実際の案件ベースで AI-DLC を用いた開発を体験することができます。

今回のワークショップには 6〜7 社が参加し、各社 3〜5 名のチーム編成で、全体で 30 名ほどの規模でした。私たちのチームは PdM 1 名、フロントエンドエンジニア 2 名、バックエンドエンジニア 2 名という構成で、参加しました。

ワークショップ中は 3 日間とも 10:00 ~ 17:30 の終日開催となり、各日程でのおおまかなスケジュールは下記の通りです。

1 日目:
- Introduction
- AI-DLC Hands-on
- Inception (Mob Elaboration)
2 日目:
- Inception (Mob Elaboration)
- Construction (Mob Construction)
3 日目:
- Construction (Mob Construction)
- Operation
- Closing

1 日目午前中の座学的な内容以外は、チームごとに分かれて実際に AI-DLC での開発を進める形となっていました。

余談ですが、今回の会場である目黒セントラルスクエアの 17F は AWS Startup Loft Tokyo として、AWS アカウントを持っているスタートアップ企業や開発者向けに無料で利用できるスペースとなっているようで、開放的で快適な環境でした。
エレベーターのドアが Amazon の段ボール柄になっていたのが個人的な推しポイントです。

1 日目: Introduction と Inception フェーズ

1 日目の午前中は Introduction と AI-DLC Hands-on からスタートし、AI-DLC の基本的な考え方や進め方についての座学を受けました。
ある程度基本的なことは理解しているつもりでしたが、実際のプロンプトの他、AI に決めさせない、迷ったらメリットデメリットを含めて推奨案を出させる、などの細かいポイントを学ぶことができました。
特に、AI-DLC において重要なのは AI の生成物をハブとして役割の垣根を超えた協働を促進することであり、PdM が何に価値を感じているのかをエンジニアが理解し、PdM は繰り返し改善をしていく前提でフェーズ分けをする姿勢を持つことが重要ということが強調されていたのが印象的でした。

午後からは各社持ち寄った開発テーマを基に、実際に Inception フェーズに取り組みました。
本記事で詳細までは記載できませんが、私たちは、既存プロダクトをベースとしながら、新たな価値提供を目指した開発というテーマで、にこスマ買取に関する新しい機能の PoC を開発することにしました。
各社、既存プロダクトの機能追加や新しいツールの開発など、多様なテーマが扱われていました。

Inception フェーズは「何を作るか」を明確にするフェーズです。
AI-DLC においては、この Inception フェーズが最も重要なフェーズと言っても過言ではありません。
前提となるインプットを基に、AI によってユーザーストーリーや Unit of Work（作業単位）を生成しますが、インプットが不十分であったり抽象的であると、どんどん議論が広がりすぎてしまい、収拾がつかなくなってしまいます。
そのため、やりたいことを明確にした上で、機能単位でそれがどういう価値を提供するのかなど、具体的に伝えられるように事前に準備をしておくことがとても重要です。

上述の通り、私たちのテーマは既存プロダクトをベースとした新規開発でした。
そのため、PdM・エンジニア双方である程度のベース知識があり、要件的な部分は取捨選択がメインになるくらいで、実はサクサクと進むんじゃないかという期待がありました。
しかし、実際にフェーズを進めていくと予想以上にその場で決めるべきことが多いことに気づかされました。
ビジネスの目的、想定ユーザー数、KPI、技術的制約、予算、スケジュールなど、通常は暗黙知として共有されている情報も、AI-DLC では全て明文化する必要があります。
特にエンジニアの観点からすると、開発をする際のビジネス的な判断はこういうことなんだなというのを、改めて実感する良い機会となりました。
普段の業務でこのような背景情報まで丁寧に共有する時間は確保しにくいものですが、個々のメンバーがサービスや機能の背景を理解していることは、AI-DLC に限らず重要だと感じました。

ワークショップ 1 日目では、ある程度ユーザーストーリーが洗い出せた段階で HTML/CSS/JavaScript を用いた簡単なモックアップを作成して動きを見た上で、認識が概ね合っていることを確認して終了しました。

2 日目: 続く Inception フェーズ

2 日目も引き続き Inception フェーズを進めました。
お昼明けまでに個々の作業単位である Unit の分割まで進めることが目標でしたが、想像以上に AI からの出力が多く、ユーザーストーリーの精査に時間がかかってしまいました。

1 日目に作成したモックアップがある程度の指針にはなっていたものの、モックの構成や UI/UX はあくまで参考とし、Unit の分割は別軸で考える必要があると感じました。
AI-DLC では、度々人の目でのレビューが発生しますが、レビュー疲れをなるべく軽減するためにもこの Unit の単位を大きすぎないようにすることが重要です。

今回 Unit の分割についてはドメイン駆動設計をベースに、同時に作業できる単位を意識して作成しました。
並行して実装できる複数の作業 Unit にストーリーをグループ化し、各 Unit には単一で構築できる高い凝集性を持つユーザーストーリーが含まれるようにしました。

最終的に、Inception フェーズではユーザーストーリーの一覧と、それに紐づく Unit of Work を作成し、この後のフロント・バックエンド間の共通認識としての OpenAPI ファイルを作成した時点で 2 日目が終了となりました。

OpenAPI や Protobuf などを使用したインターフェース定義は、必須という訳ではないですが、結合の際の共通認識として非常に有用だと感じました。この辺りは、プロジェクトの状況に応じて柔軟に選択していくのが良いと思います。
また、フェーズを進行するにあたり、ファシリテートを行う人（ドライバー）がいると良いですが、ドライバー役の人は AI とのやり取りや議論の整理、全体の進行管理などを同時に行う必要があり、かなり消耗するため適宜交代しながら進めるのが良いと感じました。

3 日目: Construction フェーズ、そして閉会へ

3 日目からは、いよいよ Construction フェーズに入りました。
Inception フェーズで明確にした「何を作るか」を基に、「どう作るか」を決めて実装していくフェーズです。

私たちのチームでは、Construction フェーズを以下のような流れで進めました。

ドメインモデル設計: ビジネスロジックを表現するクラスやモジュールの設計、各モデル間の関係性の図示
技術選定: 言語、フレームワーク、データベースや非機能要件などの決定
コード・テスト設計: 上記のドメインモデルを基に、各コンポーネントのコード構成やテストケースを設計
実装: AI によるコード生成と人間によるレビュー・修正

まず Unit から具体的なドメインモデルを生成する作業に取り組み、その後技術選定を行い、技術的なことは別のファイルでまとめる形で進めました。
このあたりの進め方については、どのようにするのが良いのかはまだ模索中です。

弊社では、技術スタックとして主に TypeScript/Next.js と Go を使用することが多いため、今回もこの構成をベースとしました。
ディレクトリ構成などは、大枠の方針を早めに決めておくと AI もそれに沿った実装を行ってくれるため、特に慣れた構成であればあるほどスムーズに進むと感じました。

午後からは、実際に Unit ごとにフロントエンド・バックエンドの実装に入りました。
全体的にドメインモデルをベースに進めたこともあり、バックエンドのコード生成は非常にスムーズで、一度でそのまま利用できるレベルのものが多かったです。(この辺りは Go の静的型付けによるビルドエラーの早期発見も寄与していそうです)

一方でフロントのコード生成は苦戦しており、フロント・バックエンドのどちらかに寄らず、品質を保ちやすい設計方針は模索する必要があると感じました。
具体的なコード生成に関しては、並行して実行できるような部分もあれば、依存により順番に進める必要がある部分もあり、適切な Unit 分けができていたかは正直よく分かっておらず、この点は経験を積む必要があるなと感じました。

また、AI は承認を受けると即座に次のコンポーネントを生成しますが、人間はそれをセキュリティやパフォーマンス、保守性の観点でレビューし続けなければなりません。
使用するモデルによっては古い情報に基づいたコードが生成されることもあり、MCP などの仕組みを活用して外部コンテキストを適切に読み込ませることで、より良いアウトプットに繋がるのではと感じました。

Operation フェーズについて

ワークショップでは時間の都合上、ここまで実際に進めることはできませんでしたが、AI-DLC の 3 つ目のフェーズとして「実際に動かして改善する」Operation フェーズが存在します。
Construction フェーズで生成されたコードを本番環境へデプロイして終わりではなく、運用しながら継続的に改善していくサイクルの一部として捉えることが重要とのことでした。

成果発表会と閉会

3 日目の最後には各社の成果発表会が行われました。
各社が様々な気づきを共有し、開発スピードの向上、Mob 開発による合意形成、既存システムへの適用など、それぞれの観点で AI-DLC の効果を実感していました。
レビュー疲れについての言及も多い中で、寝ている間に複数実行しておいて起きて確認してみた...という方もいたり、AI に乗ってみて方針が違ったらすぐロールバックしてみたチームもあったり、活用の工夫も様々でした。

3 日間の AI-DLC 体験を通じて得た学び

3 日間のワークショップを通じ、実際の案件ベースで AI-DLC を体験することで、理解が深まったと感じました。自分の中でもベストプラクティスは模索中な部分が多いですが、習うより慣れろというのがまさにその通りだと思ったので、気になっている方はぜひスモールに実践してみることをお勧めします。

AI-DLC の全体的な流れとして、docs/inception/user_stories_plan.md のような plan ファイルを作成し、人間がそれをレビュー・承認した上で、AI によって各種成果物が生成されていきます。この際、AI からの質問はターミナルや GUI ツール上ではなく、ファイル上の [Question]/[Answer] セクションでやり取りを行います。 [Question]/[Answer] もドキュメントの一部となり、別セッションで作業をする際や、プロジェクトが中断した場合でも後から振り返りやすい形となるのは良い点だと感じました。

また、AI は人と比べてかなりの速度でファイルを作成することができます。そのため、作成されたファイルを破棄して再生成することも容易であり、短いスパンでのイテレーションが可能となっています。
人間相手だと再作成は気まずい空気になりがちですが、AI 相手であれば気軽にやり直しができるのは大きなメリットです。

ここまで長くなりましたが、以下に私たちがワークショップを通じて得た主な学びを箇条書きでまとめます。

AI-DLC は単なる効率化手法ではなく、AI の生成物をハブとして PdM/Engineer/Designer など、職種・役割の垣根を越えた協働を促進すること
Inception フェーズにはしっかり時間を使うこと。Unit of Work の切り方がその後の成否を大きく左右する
Construction フェーズではフロント・バックエンドの繋ぎ込みで時間がかかりがちなので、OpenAPI など共通仕様を早めに決めておくと良し
想像以上にレビューは疲れるので、スコープの調整やイテレーションの工夫が重要。レビュー筋を鍛えよう
AI の生成速度はとても速いため、方針に沿わなくなったら無理に続けずロールバックして再生成する判断も重要
技術的な判断を行うための技術力は引き続き必須であり、エンジニアの日々の勉強はこれからも続く
まずは小規模でも実際のプロダクトベースで AI-DLC を体験してみる

おわりに

3 日間という短い期間でしたが、AI-DLC の可能性と課題の両方を実際に体験できた、非常に濃密なワークショップでした。
これから AI-DLC を実際にやっていく/やっていきたい方の参考になれば幸いです。

最後に、株式会社 Belong やアメリカ側法人の We Sell Cellular では、AI-DLC のような手法を活用しながら一緒に働く方を募集しています。ぜひキャリアページをご確認いただければ幸いです。