✨

AI-DLC をプロジェクトに取り入れるためにやったこと (Skill 化・マルチリポジトリ・Metrics 自動収集)

kmasu

2026/05/11に公開

Claude Code

aidlc

tech

!

 TL;DR
要件定義・設計のスピードを上げたくて AWS の AI-DLC を導入した
AWS 公式版に対して、Claude Code の Skill 化 / Metrics 自動収集 / マルチリポジトリ運用 などをカスタマイズして使っている


 はじめにわたし達のチームではAI コーディングツール（Claude Code / Copilot 等）で実装スピードは大きく上がった一方、要件定義や設計のフェーズが相対的にボトルネックになってきており、ここを改善したくて AI-DLC を導入しました。

導入にあたって AWS の公式版をそのまま使うのではなく、自分たちの開発フローに合うように手を入れた部分が多かったので、本記事では AWS 公式版からのカスタマイズと、実際の運用 にフォーカスして書こうと思います。
AI-DLC 自体の概念（Mob Elaboration / Bolt / 質問ファイル方式 など）については AWS のリポジトリやドキュメントの方が詳しいので、本記事では詳細は省きます。

 前提：AI-DLC とはAI-DLC は「AI と人間が協調してソフトウェア開発を進めるための構造化されたワークフロー」です。従来の SDLC に AI を後付けするのではなく、AI を前提に設計された開発手法という位置付けで、大きく 3 フェーズで構成されます。

Inception: 要件定義・ユーザーストーリー・アプリケーション設計

Construction: 機能設計・テストシナリオ・コード生成・ビルド/テスト

Operations: 運用（将来）
ポイントは、各ステージで AI が提案 → チームが検証 → AI が成果物を生成 という流れを取り、質問は必ずファイルに書く（チャットで散逸させない）こと。これにより成果物として履歴が残り、非同期レビューでも回せます。
詳しくは awslabs/aidlc-workflows と AWS の公式ブログ を参照してください。

 カスタマイズしたポイント
 1. Claude Code の Skill 化公式版は core-workflow.md というワークフロー定義を 1 ファイルで持ち、AI がそれを参照しながら各フェーズを進める形式で、Skill のような分割はありません。私たちのチームでは「設計途中から再開」「Code Generation から再開する」「PR レビュー対応する」など入り口が複数になることが多く、これを 1 つのファイルで管理するのは難しいと感じたため、フェーズの責務で Skill を分割しました。


Skill
役割


aidlc
フェーズ全体の起動・進行（Inception → Construction → Test Scenarios）

aidlc-codegeneration
feature ブランチ作成 → 実装 → コミット → PR 作成までを一貫実行

aidlc-resume
中断したセッションを ai-dlc-state.md から再開

aidlc-pr-respond
PR レビューコメントの取得 → 修正 → push → コメント返信

aidlc-status
現在の進捗状態の確認

aidlc-update-state
状態ファイルの修正・ロールバック

特に aidlc-codegeneration は、ブランチ作成からレビュー反映・PR 作成までを 1 つの Skill にまとめることで、実装フェーズに入った時点で AI が実装に集中できる構造にしています。
加えて、.claude/rules/ai-dlc-routing.md というルーティングルールを置いて、ユーザーの曖昧な指示（「続き」「実装して」「レビュー対応して」）から ai-dlc-state.md の状態を見て自動的に正しい Skill を呼ぶようにしています。
| 状態                            | 呼び出すスキル                       |
| ------------------------------- | ------------------------------------ |
| 状態ファイルなし                | /aidlc                               |
| Current Stage = Code Generation | /aidlc-codegeneration {feature-name} |
| それ以外                        | /aidlc-resume {feature-name}         |

 2. マルチリポジトリ構成開発しているシステムが複数のリポジトリに分かれているため、AI-DLC 本体はドキュメントリポジトリに集約しています。
docs/              ← AI-DLC 本体（ここから実行）
├── ai-dlc/             ← ルール・設定
├── ai-dlc-docs/        ← 成果物（state.md 等）
└── .claude/skills/     ← Skill 定義
        │
        │  後述するlocal_path 経由で読み書き
        ↓
backend/                ← 実装リポジトリ
frontend/               ← 実装リポジトリ
mobile/                 ← 実装リポジトリ
ドキュメントリポジトリ内の ai-dlc/ 配下の構造は以下のようになっています。
docs/                         # ドキュメントリポジトリ（AI-DLC 本体）
└── ai-dlc/
    ├── rules/                     # ステージルール（フェーズ別）
    └── projects-rule/             # 実装リポジトリ別の Code Generation ルール
        └── {repo-name}.md         #   migration コマンド・テスト実行方法など
どのリポジトリに実装するかは ai-dlc/project-config.yml で管理しており、リポジトリのローカルパス・GitHub パス・keywords（AI がリポジトリを選択する手がかり）を定義しています。
repositories:
  backend:
    name: my-backend
    local_path: ../my-backend
    github: org/my-backend
    keywords: [API, バックエンド, 認証]
    coding_rules: ai-dlc/projects-rule/my-backend.md
Code Generation 時は local_path 経由で各リポジトリに直接ファイルを書き込み、コミット・push・PR 作成もそれぞれのリポジトリで実行されます。

また、リポジトリごとに違う部分だけを projects-rule/{repo-name}.md に切り出す構造にもしています。たとえば backend.md には migration コマンドやテストの実行方法を記述しており、Code Generation のときに読み込まれます。

 3. タスク単位のディレクトリ構造で並行開発に対応AI-DLC は 1 機能あたり数日〜1 週間スパンになるので、他の差し込み作業（別案件のレビュー、緊急の不具合対応など）により、途中で中断することがあります。さらに、私たちのチームでは、機能 A をある人が進めている横で機能 B を別の人が並行で進める、という運用も発生しています。

 公式の aidlc-docs/ はシングルプロジェクト前提公式版の構造は、aidlc-docs/ の直下に aidlc-state.md / audit.md が 1 つずつ置かれる形になっています。
aidlc-docs/                 # 公式版（シングルプロジェクト前提）
├── inception/
├── construction/
│   └── {unit-name}/        # 同一機能を分割した「ユニット」
├── aidlc-state.md          # ← ルートに 1 つ
└── audit.md                # ← ルートに 1 つ
これだと「機能 A と機能 B を並行開発する」「途中の機能を 1 つ寝かせて別の機能から始める」といった運用で状態ファイルが衝突するため、ai-dlc-docs/ の下をタスク（機能）単位でディレクトリに切る構造にしました。
ai-dlc-docs/
├── workspace-detection.md          # プロジェクト全体の分析（共通・初回のみ）
├── feature-a/                      # 機能 A
│   ├── inception/
│   ├── construction/
│   ├── ai-dlc-state.md             # 機能 A の進捗
│   └── audit.md
└── feature-b/                      # 機能 B（別の人が並行で進めている）
    ├── inception/
    ├── construction/
    ├── ai-dlc-state.md             # 機能 B の進捗
    └── audit.md
これによって、

複数人での並行開発ができる（feature ごとに状態ファイルが独立しているので、A さんと B さんの作業が衝突しない）

再開もタスク単位で、機能 A の途中から別の日に再開できる
機能 B が緊急対応で割り込んだ場合でも、機能 A のディレクトリはそのまま残せる
ドキュメントリポジトリ側のマージ運用としては、Inception フェーズが完了した時点でドキュメントの PR を作成し、AI-DLC の全工程が完了した段階でマージしています。タスク単位でディレクトリを切っているため、機能ごとに独立した PR を作成できます。

 4. aidlc-resume Skill でセッション継続を簡略化公式にも aidlc-state.md / audit.md を使ったセッション継続の仕組み（Welcome Back Prompt）はあるのですが、毎回ユーザー側で「再開して」と起動するのが手間だったことと、再開ロジックを後述の Metrics 記録と組み合わせたかったため、Claude Code の Skill としてラップしました。

aidlc-resume Skill が Glob('ai-dlc-docs/*/ai-dlc-state.md') で全 feature の状態ファイルを拾い、対象を絞って再開
状態ファイルが複数ある場合はユーザーに対象 feature を確認してから進む

ai-dlc-state.md に ## Metrics セクションを足してメトリクスのタイムスタンプを保存

audit.md に判断履歴を記録（公式踏襲）
再開時は AI が以下のように現在地を提示します。
# 🔄 AI-DLC Session Resumed

## 進捗状況

- ✅ Workspace Detection
- ✅ Requirements Analysis
- 🔄 User Stories (質問への回答待ち)
- ⬜ Workflow Planning
「先週金曜の続き」のような曖昧な指示でも、状態ファイル一覧と feature 名から対象を判定し、適切な Skill にルーティングする構造になっています。

 5. Metrics の自動記録 + GitHub Pages ダッシュボードAI-DLC を入れる以上、「本当に速くなっているのか」を数字で見たいので、メトリクス収集を仕込みました。

 何を計測するかai-dlc-state.md の末尾に ## Metrics セクションを置き、各フェーズで以下を記録しています。
Timeline（タイムスタンプ）


指標
記録タイミング


Feature Started

ai-dlc-state.md 新規作成時

Inception Completed
Workflow Planning 承認後

Construction Started
Construction フェーズ最初の生成に着手直前

Construction Completed
全ユニットの設計ドキュメント承認後

Test Scenarios Started
Test Scenarios 最初の生成に着手直前

Test Scenarios Completed
全ユニットのテストシナリオ承認後

Code Generation Started
feature ブランチ作成直後

PR Created

gh pr create 完了後

PR Merged
main へのマージ時（GitHub Actions が自動）

Review Quality（カウント）


指標
意味


Requirements Revisions
要件定義 doc を FB で修正した回数

Design Revisions
設計 doc を FB で修正した回数

Review Iterations
コード PR のレビュー対応回数

各フェーズに Started / Completed の両方を持たせることで、

作業時間: Phase Completed - Phase Started（フェーズ「内」）

待機時間: Next Phase Started - Previous Phase Completed（フェーズ「間」）
を分けて算出できます。
Inception Completed
  ↓ wait_inception_to_construction  ← ここを分離して計測したい
Construction Started
なぜ分けたかというと、単純に「Lead Time = 機能開始 → PR 作成」だけ取っていると、「設計が金曜に終わって、実装着手が翌週月曜」のようなスプリント境界の待ち時間が AI-DLC 自身の作業時間に混入してしまい、「AI-DLC は遅い」と見えてしまう懸念があったためです。実態としては土日が挟まっているだけだったり、レビュー待ちだったり、AI-DLC 本体の処理ではない時間が支配的になりがちなので、最初から両者を分けて取れる設計にしました。これにより、ボトルネックが作業の遅さなのか**待機（プロセス上の問題）**なのかを区別して見られるようにしています。

 GitHub Actions + GitHub Pages で自動公開ドキュメントリポジトリのmain ブランチにAI-DLC 関連 PR がマージされると、GitHub Actions で

PR Merged タイムスタンプを ai-dlc-state.md に書き込み
全 state.md をパースして dashboard/index.html を生成
gh-pages ブランチにデプロイ
という流れでダッシュボードを自動更新する仕組みにしてあります。フェーズ別時間内訳・リードタイム推移・Revisions / Iterations を KPI カード + スタックチャートで見られる構成です。

ダッシュボードは以下のような形です。

(計測の仕組みを入れたのはつい最近で、まだ意味のある数字は溜まっていない状況ですが..)
スタンスとしては、まず観点と仕組みを先に固めて、データが溜まったら振り返るところに置いています。回し方としては月次で振り返り、ボトルネックを 1 つ特定 → 仮説 1 つ → 施策 1 つ、というサイクルを想定しています（DORA / SPACE の考え方を参考にしています）。

 6. Figma MCP でワイヤーフレームを直接 Figma に出力Requirements Analysis のフェーズで、UI 要件があれば Figma にワイヤーフレームを直接出力できるようにしています。
AI-DLC が HTML/CSS ワイヤーフレームを生成
    ↓
ローカルサーバーで起動
    ↓
generate_figma_design でキャプチャ → Figma ファイル自動作成
    ↓
Figma 上で編集・詳細化
    ↓
（オプション）変更ノード URL を Claude Code に渡してコードに反映
Figma 直接出力は、Figma MCP のリモートサーバー（https://mcp.figma.com/mcp）を Claude Code に設定するだけで使えます。
最近 Claude Design が research preview で登場し、プロンプトからプロトタイプを直接組めるようになったので、 今後の状況次第でFigma MCP 連携を置き換える選択肢になるかもしれません。

 運用してみての知見
 要件定義はディレクターと開発の同期セッションで進める要件定義のフェーズは、ミーティングの時間（30 分〜1 時間）を確保してディレクターと開発が一緒に AI-DLC を回しています。事前にディレクターには要求（やりたいこと）だけを用意してもらい、AI-DLC が生成する質問ファイル（[Answer]: タグ方式）にその場で回答を埋めていく形です。
## Question 1

申込みのキャンセル期限はいつまでですか？

A) 開催日の前日まで
B) 開催日の 3 日前まで
C) Other (please describe after [Answer]: tag below)

[Answer]: B
画面共有しながら議論し、ニュアンスもその場で詰めるので、認識ズレが残りにくいことと、議論の履歴がそのまま成果物として残る点がメリットです。回答に矛盾があると AI が Clarification Questions を生成してくれるので、その場で気付かなかった矛盾も拾えます。
要件定義ができたら、生成されたマークダウンを PDF に変換する自作コマンドで PDF 化し、ディレクターに共有して最終確認してもらっています。共有手段を PDF にしているのは、ディレクターが GitHub アカウントを持っていないという事情があるためで、GitHub 上で Markdown をそのまま閲覧できる環境があればこの変換は不要です。
原則ミーティングを設定していますが、要求がすでに整理されていたり規模が小さい場合は、ミーティングを設定せずエンジニアだけで要件定義を進め、PDF をディレクターに共有してレビューしてもらう形をとることもあります。
設計以降のフェーズは開発側だけで進められる状況で、ディレクターを巻き込まずに AI-DLC を回しています。

 スプリント運用との折り合い私たちのチームでは、もともと 2 週間スプリントで「設計スプリント / 実装スプリント」が交互、つまり 1 スプリントで設計 → 翌スプリントで実装、というリズムでした。これだと設計から実装着手まで 2 週間空くことがあり、
設計時の文脈が実装までに冷める
レビューフィードバックが回ってくるのが遅い
設計から価値提供（リリース）までの待ち時間が大きい
といった課題がありました。
AI-DLC を最初は 2 週間スプリントの中で試しましたが、要件定義 + 設計のスピードが想定より速かったので、いまは

第 1 週: AI-DLC で要件定義 + 設計 + リファクタなどの小タスク

続く 2 週間: 第 1 週で設計したものを AI-DLC で実装
という 1 週 + 2 週の組み方にしています。
本来は AI-DLC の特性上、Bolt（数時間〜数日の短期サイクル）に寄せた方が良さそうだと感じています。わたし達のチームの現状では、ディレクター側の要求整理が AI-DLC の進行スピードに追いつかず、Bolt まで詰めると要求待ちが発生する状況になっています。もともとスプリントベースで開発していた経緯もあり、AI-DLC の利点を完全に活かせているとは言えないかもしれませんが、現状はこの 1 週 + 2 週の組み方が落としどころだと考えています。
Bolt に寄せていくために、エンジニア側で要求の整理や施策の提案を行ったり、リリース前の確認をエンジニアだけで完結できるようにする、といった方向を現在検討中です。Metrics が溜まってきたら、フェーズ別の作業時間と待機時間を見ながら見直していく予定です。

 まとめAI-DLC を入れた背景は「実装は AI で速くなったが、要件定義・設計が相対的にボトルネック」という課題
AWS 公式版に対して、Skill 化 / マルチリポジトリ構成 / セッション継続 / Metrics 自動収集 / Figma MCP 連携を足した
Metrics は「作業時間」と「フェーズ間の待機時間」を分けて取っているのがポイント
スプリントは現状 1 週 + 2 週で運用しているが、これは Metrics を見ながら調整していく前提
体感値ベースですが、導入前後でフェーズごとの所要時間は以下のように変わっています。


フェーズ
導入前
導入後


要件定義（レビュー含）
2〜3 日
1〜2 時間

設計（レビュー含）
2〜3 日
半日

実装〜レビュー完了
1 週間
2 日

定量的な検証はこれからですが、運用と改善を続けながら、開発生産性のさらなる向上を目指していく予定です。
「AI で実装が速くなって設計が追いつかない」といった課題を抱えているチームには、AI-DLC は有効だと思います。

 参考リンク
awslabs/aidlc-workflows — AWS 公式版
AWS DevOps Blog - AI-DLC
AI-DLC Method Definition Paper

The SPACE of Developer Productivity (ACM Queue) — Metrics 設計の参考

Introducing Claude Design (Anthropic) — Figma 連携の代替候補

Skill	役割
`aidlc`	フェーズ全体の起動・進行（Inception → Construction → Test Scenarios）
`aidlc-codegeneration`	feature ブランチ作成 → 実装 → コミット → PR 作成までを一貫実行
`aidlc-resume`	中断したセッションを `ai-dlc-state.md` から再開
`aidlc-pr-respond`	PR レビューコメントの取得 → 修正 → push → コメント返信
`aidlc-status`	現在の進捗状態の確認
`aidlc-update-state`	状態ファイルの修正・ロールバック

指標	記録タイミング
Feature Started	`ai-dlc-state.md` 新規作成時
Inception Completed	Workflow Planning 承認後
Construction Started	Construction フェーズ最初の生成に着手直前
Construction Completed	全ユニットの設計ドキュメント承認後
Test Scenarios Started	Test Scenarios 最初の生成に着手直前
Test Scenarios Completed	全ユニットのテストシナリオ承認後
Code Generation Started	feature ブランチ作成直後
PR Created	`gh pr create` 完了後
PR Merged	main へのマージ時（GitHub Actions が自動）

指標	意味
Requirements Revisions	要件定義 doc を FB で修正した回数
Design Revisions	設計 doc を FB で修正した回数
Review Iterations	コード PR のレビュー対応回数

フェーズ	導入前	導入後
要件定義（レビュー含）	2〜3 日	1〜2 時間
設計（レビュー含）	2〜3 日	半日
実装〜レビュー完了	1 週間	2 日

レバテック開発部

レバテック開発部の公式テックブログです！

AI-DLC をプロジェクトに取り入れるためにやったこと (Skill 化・マルチリポジトリ・Metrics 自動収集)

はじめに

前提：AI-DLC とは

カスタマイズしたポイント

1. Claude Code の Skill 化

2. マルチリポジトリ構成

3. タスク単位のディレクトリ構造で並行開発に対応

公式の `aidlc-docs/` はシングルプロジェクト前提

4. `aidlc-resume` Skill でセッション継続を簡略化

5. Metrics の自動記録 + GitHub Pages ダッシュボード

何を計測するか

GitHub Actions + GitHub Pages で自動公開

6. Figma MCP でワイヤーフレームを直接 Figma に出力

運用してみての知見

要件定義はディレクターと開発の同期セッションで進める

スプリント運用との折り合い

まとめ

参考リンク

Discussion