目次
目次
はじめに
開発部の松本です。
2026年6月16日、ヌーラボはワークフロー自動化ツール Nulab Flowbase をリリースしました。その1ヶ月後となる7月16日に麻布台ヒルズの Amazon オフィスにて開催された AWS 主催のプログラム「AI-DLC Unicorn Gym」にヌーラボのメンバー8人で参加し、AWS が提唱する開発手法である AI-DLC を使って Flowbase に新しい機能を追加する、ということを体験しました。
この記事では AI-DLC Unicorn Gym の2日間の参加レポートを通して、実際のプロダクト開発に AI-DLC を適用してみてわかったことを紹介します。
なお、今回体験したのは AI-DLC ワークフローの v1 です。7/22 に v2 が出ましたが、この記事の内容は参加時点 (2026年7月16日) の v1 を使っているものとしてご理解ください。
AI-DLC Unicorn Gym とは
AI-DLC (AI-Driven Development Life Cycle) は AWS が提唱している開発ライフサイクルです。2025年7月に AWS の DevOps ブログで発表され、同年11月にはワークフロー定義が awslabs/aidlc-workflows としてオープンソース化されました。
ざっくり言うと、AI をコーディングの補助としてではなく開発プロセスの中心に据えて、要件定義から実装までを AI との対話で進めていく手法です。プロセスは次の3つのフェーズに分かれています。
- Inception: 要件定義、ユーザーストーリー、実装計画
- Construction: 設計、コード生成、テスト
- Operation: デプロイ、運用 (今回のプログラムでは対象外でした)
特徴的なのは進め方で、プロダクトマネジャー (PdM)・デザイナー・エンジニアといったステークホルダーが全員で同じ画面を囲み、AI の質問や提案をその場で検証しながら進めます (AWS はこれを Mob Elaboration と呼んでいます)。モブプログラミングの要件定義版のようなもの、と言えばイメージしやすいと思います。
導入はリポジトリにある core-workflow.md をプロジェクトルートに CLAUDE.md としてコピーし、AI-DLCの詳細情報を .aidlc-rule-details としてプロジェクトルートにコピーしておくだけです。後は Claude Code に指示するとワークフローが始まります (Claude Code 以外にも Cursor や GitHub Copilot などにも対応しています)。AI とのやりとりの成果物は、すべて aidlc-docs/ ディレクトリに Markdown として蓄積されていきます。
Unicorn Gym は、AWS がチーム制のハンズオン形式で開催しているプログラムです。AI-DLC をテーマにした回は2025年から各社で開催されているようで、AWS ブログにも開催レポートがいくつも公開されています。今回は AWS のソリューションアーキテクトの方々が全体の進行と各チームの伴走をしてくださいました。
「シンプルな EC サイトを構築したいです」で一周してみる
初日の最初の2時間は、肩慣らしのハンズオンです。「シンプルな EC サイトを構築したいです」というお題で AI-DLC を一周体験しました。
Claude Code を起動して指示を伝えると、AI はいきなりコードを書き始めるのではなく、まず確認質問を Markdown ファイルに書き出してきます。選択肢付きの質問が並んでいて、人間はそれに回答を書き込んで「回答しました」などと返信すると、AI が回答を踏まえた計画を提示し、人間が承認すると次のステージへ進んでいきます。
感心したのは、質問に矛盾した回答をしたときの挙動です。対象範囲の質問で「商品一覧・商品詳細表示」だけを選び、別の質問で決済機能を含めないと回答したところ、次のような確認が返ってきました。
回答を確認しました。1点、大きな矛盾点があるため確認させてください。
(中略) この組み合わせだと、このプロジェクトは実質「商品を並べて見せるだけのカタログサイト」であり、ユーザーが実際に商品を購入する手段 (カートに入れる・注文する) がありません。一般に「ECサイト」という言葉は購入フローを含む意味で使われることが多いため、この点だけ確認させてください。
回答を鵜呑みにして進むのではなく「あなたの言う EC サイトにはカートがありませんが、いいですか?」と確認してきて、着手前に矛盾を検出するという AI-DLC の設計思想を最初の2時間で体感できました。
このハンズオンは各メンバーがそれぞれの手元で進めたのですが、できあがった EC サイトを見比べると、同じお題から始めたとは思えないほど仕上がりが違いました。質問への答え方と注文の付け方で、こんなに差が出ます。
まずは素の HTML に近い、質実剛健な商品一覧。
こちらはカード UI で商品一覧らしい見た目になっています。
そして「某 EC サイト風にしてほしい」と注文したメンバーの手元では、セールバナーやランキングまで備えたそれらしい画面ができあがっていました。
ここまで2時間ほどで、コードをほとんど読まずに質問への回答と承認だけでつくることができました。
本番: リリースしたばかりの Flowbase に機能を追加する
基本的な進めかたがわかったところで、いよいよプログラムの本番である実プロダクトへの機能追加です。残りの時間はほぼすべてこれに充てられました。題材は、1か月前にリリースされたばかりのヌーラボの新サービス Nulab Flowbase です。
Flowbase は定型業務をワークフロー化できる、Backlog と連携するプロセス管理ツールです。業務が特定の担当者に依存して属人化してしまう問題を、手順書ではなく「仕組みで回す」ことで解決しようとしています (サービスの詳細は基本操作ガイドをご覧ください)。
事前に用意していた Flowbase の理想の利用ジャーニーマップ (ユーザーが最初のワークフローを作って回しきるまでの流れを描いたもの) を元に、現状で体験が途切れている箇所から取り組むテーマを抽出しました。参加メンバーは2チームに分かれ、一方は承認まわりの機能追加を、もう一方はオンボーディング時のワークフローからのテンプレート作成機能を担当しました (私は後者のチームに参加しました)。
最初のハンズオンの EC サイトと大きく違うのは、こちらがリリースしたばかりの実プロダクトだという点です。ゼロから作る greenfield ではなく、すでに大きなコードベースが存在する brownfield への機能追加になります。AI-DLC は対象が brownfield だと認識すると Reverse Engineering というフェーズを自動で実行して、既存ソースコードの解析から始めてくれます。まずはこの解析で AI に Flowbase を理解してもらいます。
モブで要件を固め、ユニットに分かれて実装する
Inception フェーズでは、AI が投げてくる確認質問にチーム全員で答えていきます。時にはホワイトボードに図を描くことで認識を合わせながら、選択式の質問に一つずつ回答していきます。
一つひとつの回答がそのまま仕様の決定となるので、普段なら実装しながら徐々に決めていくことを、着手前に全部決めます。なのでシンプルに質問に答え続けるだけですが、ずっと考え続けることになり、これが意外としんどいです。
途中には手戻りもありました。私たちのチームが作ろうとしていたオンボーディング機能は「初回起動したユーザーにワークフローを選んで作ってもらう」というものだったのですが、Flowbase には初回起動時に発動する GUI のガイドツアーが既に存在していました。同じ「初回起動」というトリガーに紐づく機能が既にあることについて、我々とAIとの認識がずれたまま進んでしまったのです。
一方で、オフラインで全員が揃っているからこそ手戻りせずに済んだ場面もありました。テンプレートからワークフローを一括作成するために新しい API を作ろうとしたところ、「AI から JSON でワークフローを作る仕組みがもうあるから、それが使えるはず」とメンバーから指摘があり、そこから方針転換することができました。AI が既存コードの調査ではバックエンドに既存のワークフロー登録 API があることに気付いていなかったのですが、人間の知識で手戻りを防いだ形となりました。
モデル選びでも学びがありました。私たちのチームは1日目を Claude Sonnet 5で進めていたのですが、2日目に Fable 5 に切り替えたところ、提案の質が変わったように感じました。自分たちでは気づいていなかった部分の指摘も出てくるようになり、チームの振り返りでも「最初から Fable でやっていたら違ったかな?」という声が出たほどです。
最初の課題が Construction フェーズに進んだタイミングで、私たちのチームは新しい課題に取り組んでいき、複数のドライバーが別々の課題を並行して進めることで AI の待ち時間も減らせて、2日間で取り組んだテーマは合計で5つになりました。到達点はそれぞれ、3つがとりあえず動くところまで、1つが Construction の途中まで、1つが Inception の途中まで (前提として必要な機能があまりに多いことが Inception で分かって、途中で見切りました) となりました。
プログラム締めくくりの報告会では PdM が成果を発表し、実装した機能はデモ動画で紹介しました。
AI-DLC はどこで効いて、どこで効かないのか
2日間を通して感じた AI-DLC の価値は、「速く書けること」よりも「着手前に認識を揃えて矛盾を潰せること」にあると思いました。チームの振り返りでも、AI-DLC は手戻りを前工程で消すための前倒し投資だ、という整理が出ました。LLM の出力という共通の土台を全員で眺めることで、ふわっとした改善希望 (モヤモヤと呼んでいたレベルのもの) からでも、PdM・デザイナー・エンジニアがコンテキストを揃えながら仕様を固めていけます。これは想像以上に効きました。
その象徴が、2日目に行った「公開」機能についての検討です。Flowbase には「公開」というボタンがあるのですが、これが分かりにくいのではないか、というモヤモヤがメンバーの間にありました。そこで AI に「『公開』ボタンが分かりにくいのでは? 『公開』と別に『共有』という概念があり、『公開』という概念がそもそも必要なのか」と、思っていることをほぼそのまま投げてみました。
AI はまず Flowbase の関連コードを30分ほどかけて調査し、その分析を踏まえた確認質問を返してきました。質問に答えていくと、最初 AI はボタンの呼称 (ラベル) の比較検討へ話を向けようとしたので、「ラベルの話ではなくて、UX としての機能概念のすり合わせをしたい」と軌道修正を入れました。すると最終的に、「問題は『公開』という語の選び方ではなく、実装の内部モデルをそのままユーザーに見せていること」という本質にたどり着いたのです。「公開」を押しても実際には見える範囲は何も変わらない (「共有」ではそれが変わる) のに、「公開」という言葉が可視性の変化を連想させてしまう、という分析でした。
そうやって、私たち自身も何が問題なのかをうまく言語化できていない状態から、半日で問題の本質の特定から概念モデルの再設計案、ユーザーストーリーの生成、最終的には実装までたどり着くことができました。人間側にあったのは「なんか分かりにくい」というモヤモヤと、議論の方向を直す数回の口出しだけでした。
ただ、この成功が AI-DLC ならではのものかは怪しいとも思っています。brownfield を認識して自動でコード調査が走る、質問が文書化されてモブの議論の土台になる、という AI-DLC ならではの恩恵は確かにありました。とは言え、本質を特定したのは最新AIモデル (Fable 5) の分析力ですし、ワークフロー自体はむしろボタンの呼称比較という手前の議論に向かいかけて、人間側で軌道修正しています。ですので、「着手前の認識合わせのために AI を使う」という型として AI-DLC のプロセスは機能はしましたが、本当に効果があったのは高性能な言語モデルとの対話そのものだったと思います。
では、その型としての AI-DLC はどうだったかと言うと、いくつか気になる癖も見えてきました。
一つ目は調査 (Explore) の弱さです。AI-DLC は Inception で要件の矛盾を潰すことに意識が向きすぎているのか、既存コードの調査が浅い印象を受けました (前述のワークフロー登録 API の見落としはその実例)。今回は完全な brownfield が対象だったので、aidlc-docs にプロダクトの情報が蓄積されれば緩和されていく可能性はありますが、別途リサーチ用のエージェントや検証用のエージェントを走らせるのがよさそうだと感じました。
二つ目は UI/UX の扱いです。AI-DLC の設計系のステージはアーキテクチャ寄りのコンポーネント設計を指向しているらしく、ワイヤーフレームやモックアップのような画面の見た目を決める工程はありません。フロントエンド寄りのストーリーは UI が決まらないと具体的な開発を進めにくいので、デザインが絡む部分は別のアプローチ (Claude Desktop を使ってデザインをモブで作るなど) を組み合わせる必要があると感じました。ただし開発中の v2 では、ワイヤーフレーム/モックアップ専用のステージ (Rough Mockups / Refined Mockups) や UX/UI デザイナー役のエージェントが追加されているようで、この問題は v2 導入によって緩和されるかもしれません。
まとめると、AI-DLC は無条件に開発が速くなるようなワークフローではなく、関係者を集めて認識を揃える価値が大きい機能、つまり抽象度が高く、先に決めるべきことが多い機能に、高性能なモデルと組み合わせて使ってこそ効くように感じられました。
PdM・デザイナー・エンジニアの目にはどう映ったか
まず、全員が一致したのは「とにかく疲れる」ということでした。PdM からは「がっつり1日中頭を使う。並列で見られるのは2つが限界」、エンジニアからは「普段は実装しながら考えることを最初に全部決めるので疲れる」「今まで長い時間に分散していた脳の負荷を、短時間に集中してかけている感じ」という声が出ました。要件定義から実装までが速く進むのは間違いないのですが、その分、人間の意思決定が短時間に高密度に要求されるためです。
PdM は、AI-DLC でステータスが定義されているので「今どこにいるか」が見えることを評価する一方、承認操作の多さや、何を確認すればよいのかの観点が分かりにくいことを課題に挙げていました。また「PdM・デザイナー・エンジニアが集まってやるべき機能には向くが、1人で進められるタスクは AI-DLC のプロセスを通さないほうがよさそう」という使い分けの意見も挙げていました。
デザイナーは「意思決定できる人・実装できる人・コンテキストがある人が一緒に合意形成しながら進むので、コミュニケーションコストが最初の30%くらいにギュッと凝縮されそう」と表現していました。そして、難易度や抽象度の高い課題ほど効果がありそうだ、としつつも、複雑な UI/UX が必要な場合は、ある程度の事前準備がないと確認質問が無限に発生して Inception が進まなくなる懸念を挙げていました。
エンジニアからは「表面的な進め方は SDD (Spec-Driven Development) と大差ない、というか SDD である。大切なのは、少人数でステークホルダーや PdM を含む開発関係者が集まって密度高く議論するところ」という指摘がありました。AI を議論の中心に据えることで、各工程の考慮漏れやメンバー間の認知のギャップを埋められる、というわけです。成果物の品質については「プロダクションレベルには遠く、8人2日で5つプロトタイピングした、くらいの感覚」という冷静な評価もありました。もう一方のチームでは「AI に回答した内容と違うものが設計に混入している場合があった」そうで、生成されたドキュメントは根気よく読み込んでレビューする必要がある、という報告もありました。自然言語で書かれた設計ドキュメントをレビューするより、コードになった時点でレビューしたい、という声もありました。
ちなみに、他社の参加レポートを読んでも「AI の生成速度に人間のレビューが追いつかない」「とにかく疲れる」という感想は共通しているようです。疲労対策として、AI の提案に積極的にリアクションして場のエネルギーを保つ「モチベーター」という役割を置いたチームのレポートもありました。
次に試すなら
今回の振り返りから、次に AI-DLC (あるいは類似のワークフロー) を回すときに試したい工夫をまとめました。
- リサーチ用エージェントを併走させる: Inception と並行して既存コードの調査専用のエージェントを走らせ、調査不足を補う
- 要望は画像で渡す: 雑な日本語だけではすり合わせが進まないこともあり、モックのスクリーンショットを渡すのが一番早い場合もある
- フェーズの区切りごとに高性能モデルでレビューさせる: 設計ドキュメントの不完全さをレビューすることで補う (他の参加企業でも実践されていた)
- デザインを「決める工程」と「実装する工程」に分ける: AI-DLC が拾わない視覚デザインの確認はワークフローの外に自分たちで枠組みを作る
- 最初から高性能なモデルを使う: モデルの質は提案の質に直結したため
- ワークフロー自体をカスタマイズする: 「AI-DLC ワークフローをただ使うのではなく、カスタマイズすることが大事」と主催の AWS の方も言っていた
おわりに
AI-DLC Unicorn Gym に参加して、新プロダクトの Flowbase に AI-DLC で機能を追加した2日間の取り組みを紹介しました。
ステークホルダーを含めた全員で認識を揃えながら、要件定義から実装までが一気に進んでいく体験は新鮮でした。8人で2日間に5つの機能をプロトタイプまで持っていけたこと、そして「着手前に矛盾を潰す」という進め方の手応えは、持ち帰る価値のあるものだったと思います。AI-DLC をそのまま常用するかはさておき、ここで掴んだ勘所は普段の開発プロセスにも持ち込めるはずです。また、今回体験した AI-DLC ワークフローは v1 なので、リリースされた v2 も試してみたいと思います。
余談ですが、今回はメンバーの一人が Claude Code の言語設定を関西弁にしていました。真剣な概念設計の議論の合間に「回答したで」「ええで」などAIとのやりとりが関西弁で進んでいく様子をみんなで眺めるのは、同じ画面を囲んだ対面での作業ならではの出来事だと感じました。
さらに余談ですが、麻布台ヒルズでは Amazon が「コミュニティバナナスタンド」という取り組みをしていて、10時と14時に無料でバナナを配っています。2日目の14時頃、ヌーラボメンバー全員で35階の会場から1階まで下りて、バナナをもらいに行きました。また、オフィスで飲めるコーヒーは美味しいのに安くて量もあって非常によかったです (2日で5杯しか飲めなかったのですがもっと飲みたかった)。1日目にはバナナシェイクも注文できたようで、飲んだメンバー曰く滅茶苦茶おいしかったそうです (私は飲み損ねました……)。
