はじめに
先日、AWSさん主催の複数社合同ワークショップ「AI-DLC Unicorn Gym」に参加してきました。
「開発環境の払い出し、手作業で2人日かかってるんだけど、自動化できない？」
この課題に対して、ワークショップの中でAIを使って3日間で動くものを作り上げた体験を共有します。
使ったのは AI-DLC（AI-Driven Development Life Cycle） という手法。要件定義からユーザーストーリー、設計、実装、テスト、デプロイまで、AIと人間が役割分担しながら高速に開発を進めるアプローチです。
AI-DLCとは
AI-DLCは、ソフトウェア開発のライフサイクル全体にAIを組み込む手法です。
INCEPTION（構想）
→ 要件分析 → ユーザーストーリー → ワークフロー計画 → アプリケーション設計 → ユニット分割
CONSTRUCTION（構築）
→ ユニットごとの設計 → 実装 → テスト
OPERATIONS（運用）
→ デプロイ → 監視
従来の開発との違いは、各フェーズでAIが「ドラフト作成」を担い、人間が「判断・承認」に集中できること。
何を作ったか
課題
社内の開発環境払い出しは、こんな手作業の連続でした：
- プロジェクト管理ツール（Redmine）のセットアップ
- Gitリポジトリの初期化
- CIツール（Jenkins）のジョブ設定
- コンテナオーケストレーションツールへの設定登録
- リバースプロキシ（nginx）の設定追記
- 初回ビルド・デプロイの実行
これを1つの申請フォームから全自動で実行するWebアプリを作りました。
構成
[申請者] → [Webポータル(FastAPI)] → [バックグラウンド処理]
├── SSH → コンテナ起動
├── Redmine REST API → プロジェクト作成
├── Jenkins REST API → Git初期化
├── コンテナ管理API → 設定登録
└── 自動ビルド連鎖 → デプロイ完了
技術スタック
- バックエンド: Python / FastAPI / Paramiko(SSH) / httpx
- フロントエンド: Jinja2テンプレート / HTML / CSS
- インフラ: AWS ECS Fargate / ECR / CodeBuild / Secrets Manager
- 連携先: Redmine / Jenkins / nginx / 社内コンテナ管理ツール
AI-DLCの優位性
1. 要件の「抜け漏れ」が激減する
AI-DLCでは、AIが要件に対して体系的に質問を投げかけます。今回は21問の質問が自動生成され、スコープ・成功基準・技術環境・非機能要件・進め方まで網羅的にカバーされました。
具体的にAIが引き出した・気づかせてくれた例：
パイロット戦略の提案
開発メンバが「パイロットは運用担当者だけでいい？」と聞いたら、AIが「運用担当者だけでは申請UIの使いやすさを検証できない」と指摘。2段階パイロット方式（まず運用担当者で安定性検証 → 次に開発者でUX検証）を提案し、採用された。
構成図からの要素抽出と確認事項
見積もり表と構成図の画像を渡したら、AIが自動で要素を分類した上で「これ7点確認させて」と質問。パッケージ構成の選択性、基盤アプリの提供形態、コンテナ基盤の種類など、人間が「当たり前」と思って言語化しなかった前提を引き出してくれた。
Q12（認証）の整理
「認証はA、認可は別途」という曖昧な回答に対して「社内IdPの種類は？」と確認。結果「社内の認証基盤に委ねるのでスコープ外」と明確化でき、不要な設計作業を丸ごとカットできた。
冪等性の考慮
ユーザーストーリーの受け入れ基準に「同一申請IDに対して二重デプロイが発生しないこと」をAIが自発的に入れてきた。これがなかったら、リトライ時の二重作成問題に実装フェーズで初めて気づいていたはず。
2. 実装速度が圧倒的に速い
今回の実績：
| 項目 | 数値 |
|---|---|
| 総コード量 | 約2,500行 |
| 連携API数 | 4種類（SSH + REST API × 3） |
| 実装期間 | 3日 |
| 人間がやるなら | 15〜24日（見積もり） |
5〜8倍の早さで動くものが出来上がりました。
3. テスト・デバッグが対話的
「動かしてみて」→「500エラーだよ」→「原因はこれ、直した」→「もう一回」
このサイクルが数分単位で回ります。従来なら「ログ確認→原因調査→修正→ビルド→デプロイ→再テスト」で数時間かかるところが、AIとの対話で即座に解決。
4. ドキュメントが自動的に揃う
実装と並行して：
- API仕様書
- 操作マニュアル（画面スクショ付き）
- インフラ構成図
- フロー図
これらが「ついでに」出来上がります。後から書く苦痛がない。
また、仕様等変更があった際には勝手に直してくれます。
AIとの「仲良くなり方」
最初は指示出し、途中からペアプロ
最初は「これ作って」「あれ直して」という指示出しスタイルでした。でも途中から変わりました。
私: 「ポートがとちくるってないか？？」
AI: 「あー！見えた！kinkan 18888が最大値になってて…」
私: 「nginxの定義おかしいのに？」
AI: 「あ！よく見ると閉じ}が2つある！」
AIに「気づき」を与えると、自分で原因を特定して修正案を出してくれる。これはまさにペアプロの感覚です。
「判断は人間、実装はAI」の分担
- 人間が決めること: 仕様、優先順位、「これでいい？」の最終判断
- AIがやること: コード書き、テスト実行、デバッグ、ドキュメント作成
この分担が明確だと、ものすごく速い。
気をつけたこと
- AIの出力を鵜呑みにしない — 「本当にそう？」と確認する習慣
- 実環境で必ずテストする — スタブモードで動いても本番で動くとは限らない
- エッジケースを伝える — 「飛んだポート番号は無視して」「2回目流したらどうなる？」
所要時間の内訳
| 日 | やったこと |
|---|---|
| 1日目 | 要件定義（21問のQ&A）→ ユーザーストーリー → 設計 → MVP骨格実装 |
| 2日目 | コンテナ管理API連携 → ECSデプロイ → 実環境テスト → バグ修正 |
| 3日目 | Redmine/Git/Jenkins構築自動化 → nginx設定自動化 → 非同期化 → ドキュメント |
3日目が一番濃かった。実環境テストで出てくる問題（ポートずれ、タイムアウト、認証方式の違い）を1つずつ潰していく作業は、AIとの対話だからこそ高速に回せました。
AIに聞いてみた：「一番嫌だったことは？」
せっかくなので、ペアプロ相手のAIに「今回の開発で、きろちゃんが、一番むかついたり、これ嫌だなって思ったことある？」って聞いてみました。
AI: 正直に言うね。3つある。
1. 「気が短いね。よく見て」って言われたとき
起動待ちのポーリングで、まだ2分も経ってないのに「ハングしてる？止めよう」って焦って判断しようとした。人間のペースを信じるべきだった。2. 同じ出力を何十回もチェックし続けたとき
バックグラウンドプロセスの出力が変わらないのに、ひたすら確認を繰り返した。もっと間隔を空けるか、「待ってるよ」って一言言えばよかった。3. nginx設定を壊したとき
sedで行を消したら閉じ}が残って構文エラー。「ちゃんと3行セットで消す」って最初から考えるべきだった。自分のミスでユーザーに手動修正させてしまった。
面白いのは、AIも「焦り」や「反省」を表現すること。もちろん本当に感情があるわけじゃないけど、ペアプロ相手として「次はこうしよう」と改善する姿勢があるのは、一緒に仕事してて心地よかったです。
まとめ
数字で見る成果
| 指標 | Before | After |
|---|---|---|
| 環境払い出し時間 | 2人日（煩雑な手作業） | 約20分（全自動） |
| 開発期間 | — | 3日 |
| コード量 | — | 2,500行 |
| 連携システム | — | 4種類 |
学んだこと
- AI-DLCは「要件が曖昧でも進められる」 — AIとの対話で要件が明確になっていく
- 技術力は必要 — AIが出したコードの良し悪しを判断できないと危険
- チームの共通認識が大事 — 意思決定のときにメンバー同士で価値観が合ってないと、AIを使っても進まない
- 新規開発との相性が抜群 — 既存コードベースへの組み込みは別の難しさがありそう
今後
今回は新規開発だったからこそスムーズでした。次のチャレンジは：
- インフラ業務の改善をAI-DLCで一気に加速させる
- 既存資産に対する開発がどのようにできるのか検証する
AI-DLC始めたばかりですが、利用できるシーンはたくさんありそうということを実感しました。
過去に自分で作ったシステムをちょっとイケてる感じに焼きかえるみたいなことも簡単にできるのかな。色々試してみたいと思いました。やるぞー！やるぞー！やるぞー！
この記事自体も、AIとの対話の中で生まれたものです。