はじめに

2026年5月18日からの3日間、AWSが主催する「AI-DLC Unicorn Gym」というイベントに参加しました。

このイベントはサンプルアプリを作るハンズオンではなく、実際の業務課題をテーマに、AI-DLCの一連のフェーズを体験しながら新規サービスを開発するというスタイルです。

テーマは「通常2〜3ヶ月かかる開発規模のもの」が推奨されていて、それをAI-DLCで進めると3日間でどこまで到達できるのか、というものでした。

そもそもAI-DLCって何？

AI-DLC（AI-Driven Development Lifecycle）とはAI 駆動開発ライフサイクルのことです。

ざっくり言うと、AIがプランを作って、人間がレビューして、AIが実行する——このサイクルを回しながら開発を進める手法です。

「AIに全部任せる」じゃなくて、判断と責任は人間が持つというのが根底にある考え方です。AIはあくまで提案と実行を担う、という役割分担になってます。

3つのフェーズ

AI-DLCは3つのフェーズ（Inception, Construction, Operation）で構成されています。
今回イベントではInceptionフェーズから、ConstructionフェーズのIaCを使ってテスト環境へのデプロイまでを体験することができました。

aidlc-workflows

AI-DLCを実践するためのルールセットが aidlc-workflows としてGitHubで公開されています。

これをプロジェクトの .kiro/steering/ に置いておくと、AIコーディングエージェントに「AI-DLCを使って〜」と指示するだけで、各フェーズの段取りで進めてくれます。

作業ログは aidlc-docs/audit.md に自動で記録されて、進捗状況は aidlc-docs/aidlc-state.md で管理されます。複数人で作業する場合でも、操作する人が交代するときは、このファイルを引き継ぐだけでコンテキストが維持できるのが便利でした。

今回取り組んだテーマ

今回のテーマは社内アプリインフラの構築自動化です。

開発環境の払い出しを手作業でやっていた業務を、Webアプリから申請するだけで自動的に環境が構築される仕組みに変える、というものです。通常なら2〜3ヶ月かかる規模の開発を、3日間でどこまで進められるかに挑戦しました。

チームはビジネスメンバーとエンジニアが混在した構成で参加しました。

3日間の体験レポート

Day 1 — Inceptionフェーズ：「何を作るか」を全員で決める

簡単にやりたいことだけ伝えるとKiroが質問してくれる

最初のプロンプトはシンプルで、「AI-DLCを使って」の後にやりたいことを簡単に列挙するだけです。

これだけ入力すると、Kiro（AWSのAIコーディングエージェント）がプロジェクトの要件を引き出すための質問リストを自動生成してくれます。今回は21問の質問が出てきました。

質問の内容はかなり幅広くて、

ライフサイクルの範囲（新規作成だけ？変更・廃止まで含む？）
利用者の範囲（パイロット段階？全社展開？）
技術スタック（得意な言語・フレームワークは？）
非機能要件（リードタイムの目標は？監査レベルは？）

みたいな感じです。

しかも、回答に矛盾があるとKiroが再確認してくれます。
例えば「完全自動化したい」と答えたのに「既存資産を使う」と答えると、「この2つ、矛盾してませんか？」って突っ込んでくれます。

ビジネスメンバーがいると全然違う

このフェーズで一番感じたのが、ビジネスメンバーがその場にいることの価値です。

「利用者の価値って何だろう？」「MVPってなに？」——こういった質問は、エンジニアだけでは判断できないのですが、ビジネスメンバーがその場にいることで、確認がその場で完結します。

実際の現場では「有識者の空き時間を抑えて会議を設定し回答をもらう、その後ドキュメント化しながら確認事項がでてきたら会議を設定して……」というやりとりが何度も発生しますが、ビジネスメンバーが一緒に考えてくれるので待ち時間もなく、確認事項はkiroが質問してくれてその場で解決できました。これは体験してみると本当に快適でした。

全員で同じ画面を見ながら進めると認識がそろう

全員が同じ画面を見ながら議論するモブワーク形式で進めたので、チーム全員が同じ情報を持った状態で話し合えました。

「自分はこう理解してた」というズレが早い段階で解消されるのは、後工程での手戻りを防ぐ意味でも大きかったです。

レビューは正直しんどい。でも——

Kiroが生成するドキュメントの量がけっこう多いです。要件定義・ユーザーストーリー・アーキテクチャ設計等々……これを全員でレビューするのは、正直しんどかったです。

ただ、自分たちだけでドキュメント作成をするともっと時間がかかるし、kiroに「ここをこう直して」というだけで、嫌な顔ひとつせず目をパチパチしながらすぐに修正してくれるのでドキュメント化はすごく楽ちんでした。

Day 2 — Constructionフェーズ前半：「どう作るか」を設計して、並列で動く

3日間で終わらせるためにスコープを絞る

3日間で動くものを作るために、MVP（実用最小限の製品）を意識してスコープを絞ることが大事でした。

最初の設計では10個のユニット（作業単位）に分割されていたんですが、3日間で終わらせるために3個に集約しました。このスコープ縮小をKiroに伝えると、関連するドキュメントを丸ごと修正してくれました。

さらに印象的だったのが、当初の全体設計は別ファイルとして残してくれたこと。MVPのドキュメントと全体設計のドキュメントを分けて管理してくれたので、「3日間で作るもの」と「将来作るもの」の区別がはっきりしました。スコープを縮小しても、全体の設計が消えないので、最初はどう考えてたっけ？とKiroに聞くとMVPとは区別して回答してくれました。

ユニット分割で並列作業できる

Kiroが作業をユニットに分割してくれることで、チームが並列で動ける体制を作れました。

今回は3ユニットに分割して、こんな感じで進めました。

ユニット	担当	内容
MVP-U1	チーム1（画面）	申請フォーム・確認画面・一覧画面
MVP-U2	チーム2（バックエンド）	申請受付・DB保存
MVP-U3	チーム2（バックエンド）	外部API連携・自動化処理

並列作業を成立させるために、最初に「契約」を決めました。DBスキーマ・APIエンドポイント仕様を先に合意してから、各チームが独立して実装を進める、という流れです。

技術的なことはKiroに聞けばいい

フレームワークの選定・DB設計・API設計といった技術的な判断も、Kiroが選択肢と理由を提示してくれます。

「なぜこのフレームワークやツールを選ぶのか」を説明してくれるので、専門外の領域でも判断しやすくなります。エンジニアにとっては「自分が知らない選択肢を教えてもらえる」、ビジネスメンバーにとっては「技術的な議論に参加できる」という効果がありました。
慣れ親しんだ技術を使おうとしたら、Kiroにもう古い技術だから非推奨（避けるべき技術）だよ。って言われたのは少しショックを受けました。

Day 3 — Constructionフェーズ後半：「動くものを作る」

コード生成の速さに驚く

設計書をもとにKiroがコードを生成する速さ、体験してみると本当に驚きます。

画面テンプレート・バックエンドAPI・リポジトリ層・設定ファイル——これらが設計書の内容に沿って一気に生成されます。今回はPython（FastAPI）+ Jinja2テンプレート + SQLiteという構成で、申請フォームから外部API連携まで動く状態になりました。

動作環境へのデプロイもKiroにお任せ

アプリのデプロイ環境（ローカルやテスト環境）の構築もKiroに依頼すればすぐに構築することができました。
ローカル環境には実行すべきコマンドの提案をしてくれ、テスト環境にはTerraformでIaC化も一瞬で作成することができました。
ローカル環境に関しては、最初は手順を教えてくれていましたが、「コマンド実行して」と伝えると、次からコマンド実行依頼が来るので、内容確認して許可するだけで環境のセットアップが完了しました。

AI-DLCを体験して思ったこと

🙆 良かったこと

変更が入ったときのドキュメント修正が楽

スコープを縮小したとき、「関連するドキュメントも全部直して」や「矛盾しているところない？」と伝えたら、Kiroが関係するファイルを洗い出して一括で修正してくれました。

通常の開発だと「あのドキュメント直し忘れてた」という修正漏れがよく起きますが、AIに任せると漏れが格段に減りそうです。

「AI駆動開発 = 一人でやるもの」じゃなかった

正直、参加前は「AI駆動開発ってエンジニアが一人でAIと対話しながら進めるもの」というイメージがありました。でも実際は違って、ユニット分割をしておけばチームで並列作業できます。AI-DLCはチーム開発と相性がいいんだな、と気づきました。

ざっくりした依頼でも汲み取ってくれる

「コミプして！」（コミット＆プッシュして、の略）みたいなざっくりした依頼でも、ちゃんと意図を汲み取って動いてくれます。AIって正確な指示じゃないと動かないイメージがありましたが、思ったより柔軟でした。

🙅 しんどかったこと・気になったこと

ドキュメントと実装がズレてくる

開発が進むにつれて、実装がドキュメントより先行する場面がありました。
Kiroの動きは把握しつつ「これ決めてから実装にはいっている？」や「ドキュメント間で矛盾はない？」と聞きながら進めないと、後からドキュメント間や実装と乖離が生じることありそうです。
（これは指示の仕方が悪かったのかもしれません）

AIが万能なわけじゃない

デプロイ環境の構築でライブラリのバージョン依存エラーが発生して、何度もトライアンドエラーが必要でした。AIが生成したコードが一発で動くとは限らないので、「AIと一緒に問題を解決していく」という感覚が大事です。

まとめ

3日間でInceptionフェーズからConstructionフェーズまで、動くアプリとインフラを作り上げることができました。通常2〜3ヶ月かかる規模の開発を3日間でここまで進められたのは、AI-DLCというプロセスとAIコーディングエージェントの組み合わせがあってこそです。

このイベントを通じて感じたのは、AI-DLCはエンジニアだけのものじゃないということです。ビジネスメンバーが参加することで、要件の精度が上がって、開発の方向性がブレにくくなります。

AIの利用に関しては、まだまだ社内情報の取り扱い云々で利用が難しいところもありますが、
要件整理の部分に関してはAI-DLCのInceptionフェーズを行うことで各段にスピードアップと精度を上げることができると感じたので、すぐにでも取り入れていこうと思います。
また開発以外においてもAI-DLCの考えをもとに、AIと共同して業務を進める意識を持っていこうと思います。

この記事はAI-DLC Unicorn Gym（2026年5月18日〜20日、AWS関西支社）への参加レポートです。