サイボウズが AI-DLC Unicorn Gym を開催——kintone/Garoon 開発メンバー42名がAIネイティブ開発手法を2日間で体験

記事のサマリー（TL;DR）

• サイボウズとAWSが2025年8月17〜18日にAI-DLC Unicorn Gymを共同開催、kintone・Garoon開発者ら42名が参加
• 全体満足度は5点中4.31、「働き方が変わる可能性がある」との回答は平均4.08と高水準
• 課題はAIへの大規模コードベースの理解支援・生成コードのQA体制不足・既存スプリントとの共存

kintone・Garoon を運用する国内開発チームが注目すべき AI-DLC の実効性

サイボウズが国内の主要 SaaS プロダクトである kintone・Garoon の開発チームを対象に AI-DLC を試行したことは、同製品を業務基盤として利用している国内企業にとっても無関係ではありません。AI-DLC の手法が今後サイボウズ製品の開発速度や仕様決定プロセスに影響すれば、機能リリースサイクルや API の変更頻度にも波及します。また、kintone を Rails 等で独自 UI 拡張している開発チームにとっては、AI-DLC の「仕様を対話形式で Markdown に記録する」アプローチは要件定義フローへの部分的な導入が現実的な選択肢になります。既存コードベースが大規模なほど「AIにコンテキストを理解させる基盤」が先決になるという今回の知見は、kintone 連携カスタマイズを抱える現場でも同様の課題として参照できます。

詳細

AI Catalyst チームとは

サイボウズの開発本部では以前から「AIやっていきチーム」を中心に、エンジニアが AI コーディングツールを業務利用できる環境整備を進めてきました。ただし、活用が個人主導にとどまり、チーム全体へのボトムアップな展開が進まないという課題が残っていました。

そこで2025年第1四半期（1Q）から新設されたのが AI Catalyst チーム です。チーム名の「Catalyst（触媒・促進者）」は英語の意味と、日本語で「語りスト」とも読めるダブルミーニングを採用しています。

AI-DLC とはどのような開発手法か

AI-DLC（AI-Driven Lifecycle） は AWS が提唱する開発手法で、従来の「既存プロセスを AI でサポートする」アプローチとは異なります。AI の能力を最大限に引き出せるよう、開発プロセス全体を再設計したものです。

人間の役割はAIのプランや実装に対する「検証と意思決定」に集約され、プランニング・タスク分解・実装はAIが担います。

全体は以下の3フェーズで構成されます。

• Inception：ビジネス上の目的を要件・ユーザーストーリー・作業単位（Units）へと細分化
• Construction：Inception のコンテキストをもとにアーキテクチャ・ドメインモデル・実装コード・テストコードを生成
• Operation：前2フェーズのコンテキストを引き継いでインフラ構築・デプロイを実施

ワークフローには OSS の awslabs/aidlc-workflows が使われており、今回のイベントは v1 を使用（開催時点で v2.0 もすでに GA 済み）。

開催の経緯

サイボウズとAWSは毎月定例 MTG を実施しており、2025年1月に AWS 側から AI-DLC の紹介を受けたことが発端でした。その後、AI Catalyst チームが3月に正式発足したタイミングで「開発プロセス全体を AI 前提で再設計したAI-DLCを、一つの型として体験する価値がある」と判断し、開催準備を本格化させました。

開催概要

本来は3日間のプログラムですが、業務との兼ね合いや出張者の都合を考慮してAWSと協議のうえ2日間の短縮版として実施しました。

各チームのタスクは当日前に事前準備として決定。「新機能追加で仕様策定から始めるタスク」「既存機能のWebViewからネイティブ実装への移行」「kintone 管理画面への機能追加」など、多様な内容が用意されました。

1日目：ハンズオンと Inception フェーズ

午前中は AWS による AI-DLC 解説と、全員参加の「ECサイト」をお題にしたハンズオン。エンジニア以外の職種を含む全42名が各自のPC上でAI-DLCの開発体験を共有しました。

午後からは6チームに分かれて実際のタスクに着手。各チームは6〜8名でモブ体制を組み、一人のドライバーの画面を全員で見ながら AI からの質問に答えていきました。ドライバー画面の共有には、急遽 Zoom を立ち上げて各自のPCで閲覧するという参加者の機転が活かされました。

Inception フェーズでは AI が要件に対してかなり細かく質問してくるため、最初はどのチームも対応に戸惑う場面がありました。AWS のサポート担当から「5分以上AIを遊ばせないこと！」というアドバイスが出され、判断に迷う場面では AI に質問の意味を確認したり、方針を相談したりしながら、各チームが AI との関わり方を調整していきました。

モブ形式の利点として、長年運用されているプロダクトの仕様について「当時の事情を知っているメンバーが必ず1人はいる」という場面が複数回確認されました。普段はリモートワークが多いサイボウズにとって、全員がオフラインで集まることでモブの強みを最大化できた形です。

2日目：Construction フェーズと成果発表会

2日目は同じチーム構成で Construction フェーズへ。AI がコードを生成し、ビルドやテストを実行する時間が中心になるため、モブの一部メンバーが手持ち無沙汰になる場面も見られました。チームによってはドライバーを2名体制にして Construction を並列実行したり、1日目の振り返りや AI-DLC の感想を共有したりしていました。

成果発表会では各チームが「どこまで実装できたか」と「AI-DLC を体験した感想」を発表。発表用資料も人間は作成せず、AI に作業を振り返ってもらい HTML 形式で生成。最後に開発本部 本部長の佐藤氏から全体講評が行われ、イベントは閉幕しました。

参加者アンケート結果

定量評価

良かった点（定性）

• フェーズごとに質問形式で仕様が固まっていく体験。曖昧な仕様がAIとの対話を通じて言語化され、ペルソナや受け入れ基準まで出力される。やり取りがすべて Markdown で記録されるため後から追跡・再開が可能
• PM・デザイナー・エンジニアが早期から一緒に検討できること。モック（HTML/CSS）を素早く生成して関係者間でイメージを共有できた
• 小さめのチーム構成（2-pizza チーム規模）が AI-DLC と相性が良い
• 開発サイクルの短縮効果を実感した

課題に感じた点（定性）

• PM・デザイナーがフルタイムで関与する場面が意外と少なく、待ち時間が発生した
• AI からの質問量が多く、回答し続けることが負担。経験の浅いメンバーには「良い仕様を評価するスキル」が必要でハードルが高い
• 既存コードベースが大規模なプロジェクトでは、AIにコンテキストを理解させるための基盤整備が先決
• 生成コードの品質担保・QA の仕組みが現時点で未確立。実運用へ持ち込むにはレビュー体制の設計が別途必要

今後の社内開発に活かせそうな点

• 「仕様を対話形式で言語化するプロセス」だけを切り出し、リファインメントの前段階を支援する Skills やツールとして部分的に導入できる可能性
• Markdown でやり取りを記録する特性は、既存の開発フローに部分的に組み込むだけで「決定の記録」という価値を提供できる

今後の社内開発への導入が難しいと思われる点

• スプリント運用・既存 Skills・ナレッジベースとの共存、フェーズごとの参加者調整など複数チームから共通の課題が挙がっており、既存プロダクトへそのまま持ち込むには相応の調整が必要
• 生成コードのQA体制が未確立のため、そのまま実運用に移行するにはレビュー設計を別途整備する必要がある

aidlc-workflows v2 について

今回のイベントでは awslabs/aidlc-workflows の v1 を使用しました。開催時点では v2.0 もすでに GA されており、AWS の担当者によると「v2.0 では AI エージェントが v1 よりも自律的に動作する方向になっている」とのことです。参加者アンケートで課題として挙がった点の一部は、v2 で改善されている可能性があります。