はじめに
最近、各種 LT やカンファレンスのセッションで「AI-DLC をベースにしている」という発表を見かけることが増えてきました。
気になって調べていくうちに、自分が個人開発している Fivia（アートボードに画像を集めて MCP 経由で AI に渡すツール）に実際に導入してみたら開発がどう変わるか試してみたくなりました。
今回はFiviaの「アートボードへの画像 URL 登録とローカル画像のアップロード」機能の開発を AI-DLC で進めた体験をまとめます。
AI-DLC とは
AI-DLC（AI-Driven Development Life Cycle）は AWS Labs が提唱する AI 主導のソフトウェア開発方法論です。awslabs/aidlc-workflows リポジトリで、各 AI ツール向けのプロンプト/ルールファイルが公開されています。
ソフトウェア開発を Inception（要件定義）・Construction（設計・実装）・Operations（運用） の3フェーズに分け、各フェーズの成果物をドキュメントとして残しながら進めます。「実装して」と雑に投げるのではなく、要件 → 設計 → コード生成 というサイクルを AI と一緒に回すイメージです。
詳しくは、以下のドキュメントを参照してください
Claude Code の Skill として設定する
AI-DLC の ドキュメント に含まれる aws-aidlc-rule-details/ をプロジェクト側の .aidlc-rule-details/ に配置するのが公式手順です。
これを Claude Code に認識させるとき、CLAUDE.md への追記か Skill 機能 かで迷いました。
.claude/
skills/
ai-dlc/
SKILL.md ← AI-DLC のワークフロー定義
最終的に、公式手順（CLAUDE.md への追記）ではなく 自分で Claude Code の Skill としてラップして使う ことにしました。CLAUDE.md に書くと常時ロードされますが、Skill なら 使いたいときだけ /ai-dlc で呼び出せる。「Using AI-DLC, ... というトリガーフレーズが必要なら、/ai-dlc と打つのと大して変わらない」という判断です。
.aidlc-rule-details/ は .gitignore に追加しておくことで、リポジトリへの影響を最小限に抑えられます。
実際にやってみた
起動はこれだけです。
/ai-dlc アートボードに画像URLの追加とローカル画像のアップロードをできるようにしたい
現時点の aidlc-workflows では Inception・Construction の2フェーズが実装されています。
Operations（デプロイ・運用監視）は方法論として定義されていますが、ワークフローとしてはまだ提供されていないので、
Inception・Construction の2フェーズについてやったことを紹介します。
Phase 1: Inception — 何を作るかを決める
Workspace Detection
まず AI が既存コードベースをスキャンし、ルーティング・コンポーネント構成・DB スキーマを読み取ってくれます。
「プロジェクト構成を説明して」から始めなくていいのが地味にありがたかったです。
Requirements Analysis
仕様を詰めるための質問されるドキュメントが生成されます。
## Question 1
「画像を追加」のUIをどのように配置しますか？
A) アートボード詳細ページのヘッダー横にボタンを追加する（Edit/Delete ボタンと並べる）
B) 画像グリッドの先頭に「+」カードを追加する
C) A と B 両方
X) その他（[Answer]: の後に記述）
[Answer]:
---
....
---
## Question 7
【拡張機能】プロパティベーステストを適用しますか？
A) はい — PBTルールをブロッキング制約として強制する
B) 部分的 — 純粋関数とシリアライズのみに適用
C) いいえ — スキップする（今回はCRUD中心のため不要）
X) その他（[Answer]: の後に記述）
[Answer]:
ここが思ったより丁寧でした。
自分が想定していたのは「ヘッダーにボタンを追加する」程度でしたが、
AI から「グリッド内に追加カードを設けますか？」と提案があり、それは考えていなかった発見でした。
個人開発だと仕様を誰かと議論する機会がないため、AI が「こっちにも追加しますか？」と能動的に提案・質問してくれる体験は想像以上に助かりました。
また、バックエンドの知識が乏しいので、Storage の RLS 設計や API のバリデーション周りも要件フェーズでたたき台まで自然に整理できたのは良かったです。
承認すると要件定義書（aidlc-docs/inception/requirements/requirements.md）が生成されます。
## FR-1: エントリーポイント
- ヘッダーの「画像を追加」ボタン
- グリッドの 16:9 「＋」カード
どちらも Dropdown で「URLを登録する」「ファイルをアップロード」を提示
## FR-2: URL登録モーダル
- url（必須）、alt / source_url / source_title（任意）
## FR-3: アップロードモーダル
- file（必須、ドラッグ&ドロップ対応）、alt（任意）
...
Workflow Planning
「何をどの順番で作るか」のプランも承認制で、気になる点はその場で修正できます。
Phase 2: Construction — どう作るかを決める
Code Generation Plan
実装前にチェックリスト形式の計画が提示されます。
- [ ] Supabase Storage バケット作成マイグレーション
- [ ] POST /api/me/artboards/[id]/images/upload
- [ ] AddImageByUrlModal コンポーネント
- [ ] UploadImageModal（ドラッグ&ドロップ）
- [ ] AddImageCard / AddImageButton
...
承認後、一気に実装が走ります。仕様が固まってからの実装フェーズは非常にスムーズで、成果物の質に大きな乖離もなく完了できました。
向いている場面・向いていない場面
個人開発には相性がいい
公式ドキュメントでは「ノーコード/ローコードで十分なシンプルなシステムは適用外」とされており、複数チームが関わる複雑なシステムを主な対象として想定しています。
ただし実際に使ってみると、個人開発との相性も非常にいいと感じました。
承認ゲートがあることで自分も仕様を整理できる、AI が能動的に提案してくれるため一人でもレビュー的なやり取りができる、複数機能を並行して進めやすいなど、一人開発特有の「誰とも議論できない」問題をある程度カバーしてくれます。
チーム導入はハードルが高い
AI-DLC では Sprint の代わりに Bolt（ボルト） という単位を使います。Bolt は「時間〜日単位」の短く集中した作業サイクルで、従来の Sprint（数週間）とは粒度がまったく異なります。チームの開発プロセス認識をガラッと変える必要があります。
明日からすぐ導入、とはいかないため、メンバーとの議論や、導入タイミングの見極めが必要です。
プロダクトが大きくなるほどそのコミュニケーションコストは増えていきます。
まとめ
AI-DLC は「雑に投げて雑に直す」ではなく、ちゃんと設計してちゃんと作るサイクルを AI と一緒に回す仕組みかなと思います。
食わず嫌いせずに一度試してみることをおすすめします。
.gitignore にルールファイルを追加しておけばリポジトリへの影響はほぼゼロなので、まず個人ベースで感触を掴んでから、チームに少しずつ広めていくのが現実的なアプローチだと思います。
AI-DLCでファーストドラフトを作り、コードレビューツールで穴を埋めるという流れは、品質担保の観点でも有効でした。
Claude Code をメインで使っているなら、Skillとして設定すれば /ai-dlc 一発で起動できます。
「この機能はきちんと詰めて作りたい」というときの選択肢として、ぜひ手元に持っておいてください。
最後まで読んでくださってありがとうございます！
普段はデザインやフロントエンドを中心にQiitaで記事を投稿しているので、ぜひQiitaのフォローとX(Twitter)のフォローをお願いします。