はじめに
League of Legends（LoL）を実際にプレイしながら人狼ゲームを同時進行できるWebアプリ「LOL人狼」を、AWSが提唱する**AI-DLC（AI-Driven Development Life Cycle）**という開発手法に沿って、Claude Codeと一緒に作りました。
実際に公開しているサイトはこちらです。
この記事では、
- AI-DLCとはどういう考え方の開発手法か
- 今回何を作ったか
- 実際にどんな流れで開発が進んだか（うまくいったこと・つまずいたこと）
をまとめます。
AI-DLCとは
AI-DLCは、AWSが提唱している「AIエージェントが開発の主体となり、人間はチームの一員としてレビュー・承認を行う」という開発ライフサイクルのモデルです。従来の「人間が設計・実装し、AIが補助する」のではなく、AIが要件定義から設計・実装・テストまでを一貫して推進し、人間は各フェーズの節目で意思決定・承認を行うという役割分担が特徴です。
今回のプロジェクトでは、このAI-DLCの考え方をルールファイル（.aidlc-rule-details/）とプロジェクト指示書（CLAUDE.md）としてリポジトリに落とし込み、Claude Codeがそれに従って動く形で運用しました。
AI-DLCのルールセット自体はAWSが公開しています。
3つのフェーズ
AI-DLCは大きく3つのフェーズで構成されます。
- INCEPTION（構想）: 何を作るか・なぜ作るかを固める。要件分析、ユーザーストーリー、ユニット分割など
- CONSTRUCTION（構築）: どう作るかを固めて実装する。機能設計、非機能要件、インフラ設計、コード生成、ビルド＆テスト
- OPERATIONS（運用）: デプロイ後の運用・監視。今回使ったルールセットではプレースホルダー扱いで、具体的な手順は定義されていません
各フェーズはすべて「必須」ではない
AI-DLCの特徴は、フェーズを機械的に全部やるのではなく、リクエストの複雑さやリスクに応じてAIが必要なステージだけを選んで実行する「アダプティブ」な設計になっている点です。例えば：
- ユーザーストーリー作成は「新機能」「複数ユーザー影響」があるときだけ実行し、単純なバグ修正ではスキップ
- アプリケーション設計は新規コンポーネントが必要なときだけ実行
今回のようなグリーンフィールド（新規）プロジェクトでは、INCEPTIONのほぼ全ステージ、CONSTRUCTIONは4つの「ユニット」それぞれに対してフル実行、という判断がされました。
進め方の作法
各ステージには共通して次のようなお作法がありました。
- AIがステージの成果物（要件定義書・設計書など）をMarkdownで生成
- 疑問点があれば、選択式（A/B/C/D/E、Eは自由記述）の質問をユーザーに投げる
- ユーザーが回答し、AIが矛盾がないか確認
- 完了メッセージを提示し、ユーザーの明示的な承認（「承認して続行」）を待ってから次のステージへ
- すべてのやり取りを
audit.mdに監査ログとして記録
「AIが一気に作って提示する」のではなく、「小さく提案→承認→次」を繰り返す進め方です。
今回作ったもの：LOL人狼
コンセプト
LoLの試合中に並行して遊べる人狼ゲームです。
- 各チーム（レッド/ブルー、最大5人ずつ）の中に人狼が0〜5人ランダムに紛れ込む
- 村人（人狼以外）には2つの「クエスト」が割り当てられ、LoLをプレイしながらこっそり遂行する
- 試合に負けたチームで人狼当ての投票を行い、村人・人狼それぞれの勝利条件を判定する
画面はentrance（入口）→lobby（ロビー）→role（役職確認）→judgment（判定・投票）→VoteCounting（集計）→result（結果）の6画面で構成しています。
技術スタック
| 区分 | 技術 |
|---|---|
| フロントエンド | React 18 + TypeScript + Vite |
| 状態管理 | Zustand |
| ルーティング | React Router v6 |
| バックエンド | Firebase Firestore（リアルタイムDB）+ Anonymous Auth |
| ホスティング | Firebase Hosting |
| 単体テスト | Vitest + React Testing Library |
| プロパティベーステスト | fast-check |
| E2Eテスト | Playwright + Firebase Emulator |
| CI/CD | GitHub Actions（main→productionのPRマージで自動デプロイ） |
無料枠内で運用できることを目標にした構成です（実際にはFirestore APIの利用にBlazeプランへの切替が必要という誤算もありましたが、無料枠を超えなければ課金は発生しない形で運用しています）。
開発の流れ
INCEPTIONフェーズ
最初に私から投げたのは、ルール・勝利条件・画面遷移をざっくり書いた自然言語の企画文だけでした。そこからAI-DLCの各ステージが進みます。
- Workspace Detection: 既存コードなし → グリーンフィールドと判定
- Requirements Analysis: 企画文をもとに要件定義書のドラフトを生成。曖昧な点（同数投票の扱い、ルームコードの形式など）を選択式の質問で確認。実際に「ルームコードは3文字以上ならなんでもあり」のような回答を受けて要件を修正するやり取りがありました
- Workflow Planning: 後続でどのフェーズをどの深さで実行するかの計画を提示・承認
- Application Design: 技術スタック（Zustand vs Redux、フォルダ構成、役職割り当てをクライアント側でやるかサーバー側でやるか）を選択式で決定
- Units Generation: 実装を4つのユニットに分割
このとき決まったユニット分割が以下です。
| ユニット | 概要 |
|---|---|
| Unit 1: Firebase基盤 | Firestoreデータモデル・セキュリティルール・型定義 |
| Unit 2: 入口・ロビー | entrance/lobby画面、入室・チーム選択 |
| Unit 3: ゲームロジック | role画面、役職・クエスト割り当て |
| Unit 4: 投票フロー | judgment/VoteCounting/result画面、投票集計 |
依存関係（Unit1が全ユニットの土台、Unit2で早期に動くものを作る）を踏まえて実装順が決められました。
CONSTRUCTIONフェーズ
ユニットごとに次のループを回します。
Functional Design（機能設計）
→ NFR Requirements（非機能要件・技術選定）
→ NFR Design（非機能要件の実装パターン）
→ Infrastructure Design（実インフラへのマッピング）
→ Code Generation（計画→実装）
各ステージの完了時には「変更を依頼する / 次のステージへ進む」の2択で承認を取り、次に進みます。4ユニット分（Firebase基盤→入口・ロビー→ゲームロジック→投票フロー）をこの順で一つずつ完成させていきました。
全ユニットの実装が終わったあとに、最後のBuild and Testステージでlint・型チェック・単体テスト・E2Eテストの実行手順をまとめ、ここまででCONSTRUCTIONフェーズが完了しました。
OPERATIONSフェーズ（＝実質ここからが本番）
AI-DLCのOPERATIONSフェーズはプレースホルダーのため、具体的な手順は定義されていません。基本機能が完成した後の
- クエスト内容の充実（最終的に44件に拡充、カテゴリ分類・一括ON/OFF機能の追加）
- スマホ向けレスポンシブ対応
- SEO対応（meta/OGP/sitemap.xml/Search Console登録）
- ルール説明ページ・プライバシーポリシーページの追加
- 本番環境でのバグ調査・修正（後述）
- GitHub ActionsによるCI/CD整備
といった作業は、AI-DLCの型に沿った「設計書を書いて承認を取って」という進め方ではなく、普通のチャットで「これを直して」「これを足して」と依頼し、都度テストして反映するという、より軽量なやり取りに自然と切り替わりました。
感じたこと
よかった点
- 要件の曖昧さを早期に潰せた: 「ルームコードの形式」「同数投票の扱い」のような、後で仕様揺れになりがちな点を、コードを書く前の選択式の質問でつぶせたのは大きかったです。実装後にここが揺れると手戻りが大きい部分でした。
- ユニット分割が実装順として機能した: 「Unit2（入口・ロビー）を早めに動く状態にする」という優先度づけのおかげで、早い段階で実際にブラウザ2枚で動作確認できるものができ、後続ユニットの土台としての手戻りリスクを下げられました。
- プロパティベーステスト（PBT）が要件段階で強制されていた: 投票集計やクエスト抽選のような「入力パターンが多いロジック」に対して、人間が手で書きがちな数パターンのテストだけでなく、fast-checkによる網羅的なテストが最初から組み込まれ、実際に細かいエッジケースを拾えていました。
-
やり取りが全部記録に残る: 各ステージの質問・回答・承認をAIが
audit.mdに逐一記録してくれていたおかげで、今回のようにあとから開発の流れを詳細に振り返って記事に書き起こすことができました。「なぜこの仕様にしたか」という意思決定の経緯も後から追えるので便利でした。
つまずいた点・気づいたこと
- OPERATIONS＝プレースホルダーの重み: 基本機能の実装（INCEPTION〜CONSTRUCTION）はきっちり型に沿って進みましたが、実際にはその後の「ブラッシュアップ」「本番運用しながらの微調整」のほうが物量として多くなりました。AI-DLCが手厚くカバーしているのは開発ライフサイクルの前半部分で、公開後の継続的な改善サイクルは別枠で自分たちのやり方を作る必要がありました。
- 設計書だけでは防げない不具合がある: 例えば「ローカル用の環境変数ファイルが本番ビルドに混入し、本番サイトが存在しないFirebaseエミュレータに接続しようとして認証が失敗する」という不具合や、「Firestoreの楽観的更新とリアルタイムリスナーのタイミング競合でレーン選択がまれに巻き戻る」という不具合は、設計書のレビューでは気づけず、実際に本番相当の環境で動かして初めて発覚しました。上流の設計と、実環境での動作確認は補完関係にあり、どちらかだけでは足りないと感じました。
-
承認ループは記録に強いが重さもある: 各ステージの完了ごとに監査ログ（
audit.md）へタイムスタンプ付きで記録しながら進める方式は、後から「なぜこの仕様になったか」を追える点で優れていますが、個人開発でユーザー自身がPMもレビュアーも兼ねる場合は、やり取りの往復がやや重く感じる場面もありました。
余談：私は一行もコードを書いていない
今回のプロジェクトを通して、私自身は一切コードを書いていません。要件を伝え、選択式の質問に答え、各ステージの成果物を確認して承認する、という関わり方だけで、動くWebアプリが本番環境まで公開されました。
プログラマーという職業が不要になっていく流れを肌で実感すると同時に、正直なところ少し怖さも感じています。
まとめ
AI-DLCは、「AIに丸投げで作らせる」のでも「人間が全部指示する」のでもなく、要件・設計の節目ごとに人間が判断を差し込める構造化されたAI協働という点に一番の価値を感じました。一方で、公開後の運用フェーズはAI-DLCの型の外側にあるため、そこは通常の「対話しながら素早く直す」開発スタイルとうまく使い分けるのが実用的だと感じています。