Amazon Web Services ブログ

9 社合同 AI-DLC Unicorn Gym 大阪 ── AI と開発した 3 日間で見えた、人間の仕事

みなさん、こんにちは。ソリューションアーキテクトの池田、ポール、佐山です。

2026 年 5 月 18 日〜20 日の 3 日間、AWS 大阪オフィスにて「合同 AI-DLC Unicorn Gym」を開催しました。H2O Retailing、パナソニックコネクト、パナソニックデジタル、村田製作所、東洋紡、ギフトパッド、シャープ、ダイキン工業、近鉄情報システム(順不同、敬称略)の 9 社 10 チームから計 75 名のビジネスメンバー・開発メンバーが参加し、3 日間 AI 駆動の開発プロセスを実践しました。

本記事では、9 社 75 名が 3 日間 AI-DLC をどう体験したのか、参加者の声を交えてレポートします。

AI-DLC Unicorn Gym 集合写真

AI-DLC (AI-Driven Development Lifecycle) とは

AI 駆動開発ライフサイクル (AI-DLC) は、AI を開発プロセスの中心に据えた開発手法です。AI をアシスタントとして後付けで使うのではなく、要件定義・設計・実装の主役を AI が担い、人間は意図のすり合わせと重要な判断に集中する── この役割分担により、従来は数ヶ月かかっていた要件定義から実装までを数日に圧縮します。

プロセスは Inception(要件を練る)・Construction(実装する)・Operations(運用する)の 3 フェーズ。鍵となるのが、チーム全員で 1 つの画面を囲んで AI と対話する「モブエラボレーション」(Inception)と「モブコンストラクション」(Construction)です。AI が要件案やコードを素早く提示し、ビジネス・開発メンバーがその場で検証・判断する。この共同作業が、開発速度の向上だけでなく、ビジネスと開発のギャップを埋め、チーム全員の認識を揃える効果をもたらします。今回の Unicorn Gym では主にこの 2 つを 3 日間で集中実践しました。

詳しくは AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築11 社合同 AI-DLC Unicorn Gym で体験した開発のパラダイムシフト、および AI-DLC ホワイトペーパー をご参照ください。

AI-DLC の概要図

9 社 10 チームが持ち込んだテーマ

各社はビジネスメンバーと開発メンバーの混成チーム(6〜8 名)で、実際のビジネス課題をテーマに持ち込みました。営業支援ツール、現場の点検・検査業務のデジタル化、環境データの集計・可視化、社内インフラの払い出し自動化、グループウェア間のデータ連携など、テーマは多岐にわたります。新規開発だけでなく、既存システムへの機能追加に取り組んだチームもありました。AI を使わない従来の開発手法で見積もると平均して十数人月かかる規模のものです。

「色々取り組んでいるがうまくいかない」「スクラムに限界を感じている」「AI を使わないと間に合わない、AI を積極的に取り入れると決めてメンバーを連れてきた」「開発プロセスが定まらない」── 業界はバラバラでも、開発の壁にぶつかっている点では共通していました。近鉄情報システムでは CTO 自らが参加し、コーディングエージェントを操作して開発に加わるなど、各社の取り組み姿勢もさまざまでした。Spec 駆動開発を実践しているチームもあれば、AI をチームで使うのは初めてというチームもありました。

会場の雰囲気も印象的でした。パナソニックデジタルはオレンジのチーム T シャツを全員で着用して一体感を演出。シャープのメンバーは「服装自由」を活かして着物で参加するなど、普段の業務とは違う特別な 3 日間にしようという空気が会場に満ちていました。

Day 1: Inception ── 同じ画面を囲んで、要件を練り上げる

午前は AI-DLC の概要と Hands-on。午後から「モブエラボレーション」に突入しました。

モブエラボレーションとは、チーム全員が 1 つの画面を囲み、AI と対話しながら要件を練り上げる共同作業です。ビジネスメンバーも開発メンバーも同じ場で AI の提案を検証し、判断し、修正していく。このプロセスを通じてチーム全員のコンテキストが揃い、その共通認識が Construction フェーズにそのまま引き継がれます。

モブエラボレーション中のチームの様子

半日で多くのチームがユーザーストーリー作成からモックアップ確認まで到達。

普段、開発とビジネスが面と向かって議論する機会がほとんどない。やってみたら、開発側がビジネスを理解しようとする姿勢が自然に生まれた(H2O Retailing)

Day 1 の共有会で印象的だったのは、こんな声です。

何もわかっていない AI に教えながら進めることで、メンバー全員の知識ラインが揃った。結果として良い要件定義になった(東洋紡)

AI に説明する行為そのものが、チーム内の認識合わせになっていた。これは狙い通りでもあり、想像以上に効果的でした。

タスクを AI に任せて、判断を人間に回されるプロセスが結構大変。判断力が成果物に直結する(近鉄情報システム)

AI に委ねるほど、人間の判断力が試される。この実感は 3 日間を通して繰り返し語られることになります。

自分で体験しないと効果がわからない。人に聞くのではなく自発的に新たな体験をしていきたい(東洋紡)

AI-DLC は説明を聞いて理解するものではなく、やってみて初めて腹落ちする── 多くの参加者がそう語っていました。

Day 2: Construction ── コードは出る。でも判断が追いつかない

2 日目は朝からグループワーク。各チームのペースで Inception を仕上げ、Construction フェーズへ入っていきます。

Inception の仕上げとして取り組むのがユニット分割です。ユーザーストーリーを独立して開発できる単位(ユニット)に切り分け、チーム内を 2〜3 のサブチームに分けて並行開発に入る準備をします。

Construction 中の開発風景

午前の共有会では、Inception フェーズの速さに驚く声が上がりました。

いつもなら 1 ヶ月、2〜3 スプリントかかることが 4 時間でできた。めっちゃしんどかった(パナソニックデジタル)

午後、並行開発が本格化すると「I/F 合意の壁」が見えてきます。

単体テストは通っていたのに、結合したらつながらない箇所があった(シャープ)

I/F のつめが甘くて手戻りが発生した(村田製作所)

AI がコードを高速に吐き出しても、チーム間の合意が足りなければ結合で引っかかる。開発全体の速度を決めているのはコード生成ではなく、人間の判断と合意形成だ── 複数のチームが同じ気づきに至っていました。

AI がわかったつもりで勝手に再定義してきて時間を食った。レビューをサボると後で痛い(ダイキン工業)

AI の出力は必ず人間が検証する、というプロセスの重要性が裏付けられました。

うまくいったパターンとして共有されたのは「最初から大きく扱わず、ミニマルに絞る」「チーム全員で共通認識を作ってから分かれる」の 2 点。

社内で AI を使った開発を検討していたが明確な手順が定まっていなかった。今回の AI-DLC は開発手法としてかなり参考になった。この手法を軸に社内の既製品に対してどうアプローチするか考えていきたい(ダイキン工業)

自社への持ち帰り方が具体的に見え始めたチームもありました。

Day 2 のクロージング時点で、多くのチームがコード生成・ローカル動作確認まで進んでいました。

Day 3: 仕上げと成果発表

最終日は朝から Construction の追い込みです。ユニットの結合、テスト、デプロイ。「動くもの」を 3 日間の集大成として仕上げにかかります。

16 時からは成果発表会。各社が到達した地点を全体に共有しました。

Day 3 成果発表会の様子

全 10 チームがデモを実施しました。全チームが動くアプリケーションを画面に映して見せるところまで到達しています。

発表を通じて見えたのは、成果の大きさだけではありません。各チームが共通して語ったのは以下のような気づきでした。

  • Inception フェーズで要件を丁寧に練り上げたチームほど、Construction がスムーズに進んだ
  • ユニット分割の前に、チーム全員で共通のインターフェース定義を固めておくと結合時の手戻りが激減する
  • 既存システムへの機能追加にも AI-DLC は適用できる。AI-DLC Workflow にはリバースエンジニアリングのフェーズが組み込まれており、既存コードの構造を AI に理解させた上で新機能の設計に入る流れがカバーされている
  • AI の出力が速いからこそ、人間のレビューと判断がボトルネックになる。でも、チーム全員で同じものを見ながら判断を重ねるこのプロセスは強い

あるチームは「従来 6 ヶ月を見込んでいた開発が 3 日で形になった。特に要件定義のスピードが劇的に変わった」と振り返り、別のチームは「明日の社内ミーティングで、早速プロジェクトに適用したいと提案するつもり」と語っていました。3 日間の体験が、そのまま翌日からのアクションに直結している── 参加者が自社に持ち帰れる手応えを得られたことが何よりの成果です。

AWS セッション・懇親会・Lightning Talks

成果発表の後は AWS の井形(Data&AI 事業開発マネージャー)によるミニセッション「AWS Japan の事業開発マネージャーが生成 AI(Kiro)を使って業務効率化をした話」を実施しました。

AI-DLC が製品ライフサイクルの「作る力」をカバーするのに対し、GTM(Go-To-Market)は「届ける力」をカバーする。Build が速くなるほど、次のボトルネックは「誰に、どう届けるか」に移る。そして AI-DLC の考え方── AI に作業を任せ、人間は方向性と判断に集中する──は、GTM の領域にもそのまま当てはまる、という内容でした。3 日間で動くものを作った参加者にとって、「この先どう活かすか」を考えるきっかけになるセッションでした。

クロージングの後は懇親会 + Lightning Talks。3 日間を共にした 10 チームのメンバーが、業界を越えて AI 駆動開発の実体験を語り合う時間です。この場での会話が、各社の持ち帰りをさらに厚くしたはずです。

懇親会の様子

Lightning Talks の様子

3 日間を終えて

AI はやっぱり自分の鏡だと思った。AI が理解できていないということは、自分がそこまでの解像度でインプットできていないということ(パナソニックコネクト)

アプリ開発は 100% AI-DLC で進めたいと思えた。AI の成果物をレビューするために、私たちの知識を高めることも必要だと感じた(H2O Retailing)

個人で Kiro を触っていた時よりはるかに学びが多く、これは絶対に現場に適用すべきだと確信した(パナソニックデジタル)

イベント後のアンケート(61 名回答)では、全体満足度は 5 点満点中 4.57 点。回答者の 96.7% が「満足」または「非常に満足」と評価しました。「AI-DLC はあなたの働き方を変える可能性があるか」という問いには 91.8% が 5 段階中 4 以上で回答。85.2% が継続的なフォローアップを希望しており、3 日間が「終わり」ではなく「始まり」として受け止められていることがわかります。

おわりに

AI がコードを書いてくれるようになると、人間の仕事は変わります。手を動かしてコードを書くことから、何を作るか決めること、設計の方向性を判断すること、チーム間の認識を揃えることへ。人間の役割は「作業」から「意思決定」に集中していきます。

AI-DLC がモブで集まることを重視するのはそのためです。ビジネスメンバーと開発メンバーが同じ場に集まり、AI が揃えた材料をもとにその場で判断を重ねていく。意思決定に集中できる環境を作ることで、チーム全体の開発サイクルが速くなる。3 日間で参加者が体感したのは、まさにこの変化でした。

参加いただいた 9 社がこの体験を各社の現場に持ち帰り、それぞれの形で活かしていかれることを楽しみにしています。
参加企業からもレポートが公開されていますので、あわせてご覧ください。

今回の AI-DLC Unicorn Gym は AWS 大阪オフィスで開催しました。前回の東京開催に続き、関西でも各社のチームが集まり、AI-DLC の実践を共にしました。AWS は地域を問わず、お客様の AI による開発プロセスの変革の挑戦に伴走していきます。

著者について

池田 敬之 (Takayuki Ikeda)

関西の製造業のお客様を担当するソリューションアーキテクトです。クラウド × データ × AI でお客様のビジネスを支援しています。好きなサービスは Amazon Bedrock AgentCore と Strands Agentsです。休日はキックボクシングで汗を流した後、愛犬と散歩といったコンボで英気を養うのが定番コースです。

ポール (Paul Nobuo Okada)

製造業のお客様を担当するソリューションアーキテクトです。サーバーレスの活用や AI 駆動開発ライフサイクル (AI-DLC) を日本のお客様への布教する活動もしてます。好きな AWS サービスは AWS サポートです。趣味はDTMとベース、最近ドラムも始めました。ただ、メンバー探しだけが難航しています。

佐山 朝葉 (Sayama Asaha)

ソリューションアーキテクト。製造業のお客様をご支援しています。