AI-DLC（AI-Driven Development Lifecycle）とは、AWS が 2025 年に提唱した、AI エージェントを前提に開発ライフサイクル全体を再設計する方法論です。「AI にコードを書かせる」の一歩先、つまりチケットの粒度・品質ゲート・計測までをまるごと AI 前提に作り替えます。
日本でも Developers Summit 2026 Summer のセッションなどで注目が集まっていますが、公開されている情報の多くは概念紹介にとどまっています。本記事では、Monstarlab が AI-DLC を Claude Code プラグインとして実装し、自社での運用から複数のクライアント案件まで実践して得た知見と実測データを紹介します。答えたい問いはひとつ——「概念は分かった。で、現場でどう回すのか」です。
なお、本記事で紹介する社内実装と実測データは、公式リファレンス実装が v1 系だった 2026 年前半のものです。2026 年 7 月に公式の 2.0 が GA となったことを受けた私たちの現在地は、記事末尾の今後の方針にまとめています。
AI-DLCとは何か
AI-DLC は、AWS の Whitepaper『AI-Driven Development Lifecycle』（Raja SP, 2025 年 7 月）で提唱された開発方法論です。従来の「AI 支援コーディング（AI-assisted coding）」は、既存プロセスに AI を足すアプローチでした。AI-DLC は逆です。要件定義からデプロイまでのライフサイクルそのものを AI ネイティブに再設計します。AWS はこの方法論を Inception / Construction / Operations の 3 フェーズで定義し、リファレンス実装として awslabs/aidlc-workflows を公開しています。2026 年 7 月に GA となった 2.0 では、実装側のフェーズ構成が 5 段階に拡張されました。
従来の開発プロセスと比べると、変わるのは「速さ」ではなく「単位と構造」です。
| 観点 | 従来型 | AI-DLC |
|---|---|---|
| チケット粒度 | 人間の 1〜3 営業日 | AI のコンテキストウィンドウ単位（Atomic Spec） |
| ライフサイクル | 線形（要件→設計→実装→テスト→リリース） | 循環型 7 段階（Agent Loop） |
| チケットの鮮度管理 | 定例会議で棚卸し | AI が自動で再現検証（AI Janitor） |
| Definition of Done | 手動チェックリスト | フックによる強制 + 自動検証 |
| 品質指標 | なし、または主観 | MTTV / Churn / AI-Confidence などの定量指標 |
なぜ従来のチケット運用はAIエージェントと噛み合わないのか
従来のチケットは「人間の営業日」を単位に設計されており、AI エージェントの作業単位である「1 セッション（コンテキストウィンドウ）」と粒度が合わないからです。
AI エージェントをチーム開発に入れたことのある方なら、次のような場面に覚えがあるはずです。
- 大きすぎるチケットを渡すと、AI は途中でコンテキストを失って迷走する
- AI が量産する PR を人間がレビューしきれず、レビューが律速になる
- 「AI で速くなった気がする」が、誰もそれを数字で示せない
これらは個別のツールの問題ではなく、プロセスの構造問題です。チケットの粒度、完了の定義、品質の測り方が人間前提のままなので、AI を入れた分だけ摩擦が増えます。だから私たちは、ツールを足すのではなく、プロセス側を作り替えるアプローチを取りました。
事例: MonstarlabはAI-DLCをどう実装したか
ここからは、私たちが 2026 年前半に構築し運用してきた社内実装を、事例として紹介します。AWS の Whitepaper を起点にした Claude Code 向けの opinionated なプラグインで、スラッシュコマンド 21 個、ナレッジベースとなるスキル 6 個、品質ゲートを強制する自動フック 17 本で構成されます。社内プロジェクトに加えクライアントワークでも適用してきました（改訂履歴は執筆時点で 261 バージョン）。
前提として、スキルやハーネス（フック・計測の土台）はプロジェクトの特性に合わせたチューニングが必要になる、と私たちは考えています。その上で、開発プロセスの部分——チケットの粒度、ライフサイクル、品質ゲート、計測——については、プロジェクトを問わず通用する最適な形を目指して作り込んでいます。
なぜ自分たちで実装したのか（2026 年前半時点）
私たちが実装に着手した時点で、AWS 公式のリファレンス実装（v1 系）は Markdown のルール文書を配布する形式でした。エージェントを選ばない代わりに、ルールを守らせるのはモデルの解釈に委ねられます。私たちが必要としていたのは、レビュー漏れや計測漏れを人間の注意力に頼らずに防ぐ仕組みでした。そこで、Claude Code のフック機構に踏み込む道を選びました。
| 軸 | awslabs/aidlc-workflows（v1 系） | Monstarlab 実装 |
|---|---|---|
| コア姿勢 | Methodology first（ルール文書を配布、インストール不要） | Opinionated framework（プラグインとしてインストール） |
| 対応エージェント | 主要な IDE / エージェント全般に汎用対応（Kiro、Cursor、Claude Code、GitHub Copilot ほか） | Claude Code に深く統合 |
| 実行時の強制 | Markdown ルールによる誘導 | フックによる強制（PreToolUse / PostToolUse / Stop） |
| 再現性の担保 | Markdown ルールでモデルのばらつきを抑制 | Markdown ルール + Python ヘルパーで判定ロジックを決定論化 |
| 計測 | なし | セッションメトリクス、DORA、AI-Confidence の自動収集 |
汎用性を取るか、特定エージェントへの深い統合を取るか。私たちは後者を選び、その分「品質ゲートを人間の注意力に頼らない」仕組みに投資しました。
実装全体を貫く原則はひとつです。人間は「何を作るか」の意思決定と最終レビューを担い、AI は「どう作るか」の実行を担う。そしてアカウンタビリティは常に人間が持つ。
Agent Loop: AIと人間で回す循環型7段階
Agent Loop は、1 つのチケットが生まれてから完了するまでの循環型ライフサイクルです。肝は、各段階に担当（AI / 人間 / CI）とタイムボックスが決まっていることです。
| # | 段階 | 担当 | タイムボックス | やること |
|---|---|---|---|---|
| 1 | Triage | AI | 1 時間 | 分類・重複検知・優先度推定 |
| 2 | Spec Definition | 人間 | 2 営業日 | Atomic Spec の記述（後述） |
| 3 | AI Planning | AI（読み取り専用） | 30 分 | 実装計画の生成と人間の承認 |
| 4 | AI Implementation | AI | 4 時間 | コード + テスト + PR 作成 |
| 5 | Auto-Verification | CI | 30 分 | Lint / テスト / セキュリティスキャン |
| 6 | Human Review | 人間 | 4 時間 | ロジック検証・ハルシネーション検出 |
| 7 | Done | - | - | メトリクスの記録 |
運用して分かった要点が 2 つあります。
4 時間ルールは分割不足の検知器になる。 4 時間は短すぎると感じるかもしれません。私たちも最初はそう思っていました。しかし運用してみると見え方が変わります。4 時間で終わらない実装は、AI が遅いのではなく、Spec の分割が足りないシグナルなのです。ここで頑張らせずに Spec Definition へ差し戻します。
この 4 時間という数字は、AI の能力限界から決めたものではありません。人間のサイクルに合わせた設定です。エージェントを放置して、どれだけ長いタスクをこなせるか——いまはそこに注目が集まっていますし、技術的にはできるようになりつつあります。それでも私たちは、長時間の一気通貫に賭けていません。AI-DLC は軌道修正が起きる前提のプロセスだからです。要件は日々変わり、外部の条件でやり直しも発生します。巨大なコンテキストでサブエージェントを束ね、人間の確認を挟まずに一気に仕上げる手法は、方向が正しいうちは強力です。しかし方向を確かめる人間がボトルネックである限り、確認できないまま進んだ距離は、そのままやり直しの距離になります。並列化が問題なのではありません。人間が確認と判断を回せる刻みで仕事が届くこと。4 時間はその刻みです。
差し戻しは失敗ではなく正常フロー。 線形プロセスでは手戻りは事故ですが、Agent Loop では各段階から前段階への差し戻し条件をあらかじめ定義しておきます。差し戻しの回数（Churn）も計測対象なので、「どこで詰まりやすいか」がデータで見えます。
効果は数字に出ました。修正対応の完了までの時間（TTC: Time to Correct）は、レビュー指摘を同一セッション内で修正しきる「Same-Session Close」ルールの導入前後の計測で 19.4 時間から 0.1 時間 になりました。1 人 + AI エージェントの Solo 構成での計測値です。指摘から修正までの間にコンテキストスイッチを挟まない。プロセス上の工夫はそれだけで、コードを書く速さは何も変えていません。
Atomic Spec: AIが1セッションで完結できる仕様の書き方
Atomic Spec とは、AI エージェントが 1 セッションで「理解 → 計画 → 実装 → テスト」を完結できる最小の仕様単位です。次の 5 要素を必須とします。
- Context — なぜこの変更が必要か
- Current Behavior — 現在どう動いているか
- Expected Behavior — どう動くべきか
- Constraints — 触ってはいけない場所、守るべき制約
- Verification — 何をもって完了とするか
分割の目安は「対話 3 ターン以内・変更ファイル 5 個以下・PR 差分 300 行以下」です。この基準を超えそうなら、実装前にチケットを割ります。
5 要素と言われても、ピンとこないかもしれません。マイクロサービス構成の EC システムを想定したサンプルで、書き方がどう変わるかを見比べてみます。
Before（従来のチケット）:
タイトル: 注文が二重になることがあるので直す
本文: たまに同じ注文が 2 件登録されている。CS に問い合わせが
来ているので急ぎで調査してほしい。
After（Atomic Spec）:
タイトル: 注文 API のリトライ起因の二重登録を冪等化で防止
## Context
- モバイルアプリがネットワークタイムアウト後にリトライすると、
注文が二重登録されることがある
- 発生は月数件。そのたびに CS 対応が発生している
## Current Behavior
- `POST /orders`（`src/orders/api/create_order.py`）は
同一内容のリクエストを区別しない
- タイムアウト後のクライアントリトライで、同じ注文が 2 件作成される
## Expected Behavior
- クライアントが付与する `Idempotency-Key` ヘッダで重複を検知する
- 同一キーの 2 回目以降のリクエストには、初回と同じレスポンスを返す
## Constraints
- API の後方互換を維持する
（`Idempotency-Key` なしの既存クライアントは現行挙動のまま）
- 在庫サービス・決済サービスの API 契約は変更しない
- 変更対象は次の 3 ファイルに限定する:
- `src/orders/api/create_order.py`（ヘッダ処理の追加）
- `src/orders/repository/idempotency_store.py`（新規）
- `tests/orders/test_create_order.py`
## Verification
- [ ] `pytest tests/orders/` が全件 PASS
- [ ] 同一 `Idempotency-Key` で `POST /orders` を 2 回実行すると
注文が 1 件・レスポンスが同一、を検証するテストを追加
- [ ] キーなしリクエストの既存テストが無変更で PASS（後方互換の確認）
Before のまま AI に渡すとどうなるか。すべてのリクエストにヘッダを必須化して既存クライアントを壊す、という「直したが壊した」修正が返ってきがちです。この修正の急所は、後方互換と隣接サービスの契約——つまり触ってはいけない境界にあります。それは Constraints に書かれてはじめて AI に伝わります。5 要素のうち実務で最も効くのが、この Constraints です。
形式にも意味があります。変更対象をファイルパスで特定し、Verification は AI がそのまま実行できるコマンドとチェックリストで書く。人間のレビュアーも、チェックボックスを上から潰すだけで完了確認ができます。Spec の品質は、この具体度で決まります。
そして、アトミックに割ることの効能は「AI が 1 セッションで完結できる」ことだけではありません。チケットが十分小さく、触るファイルがソースコード構造のレベルで特定され、前提条件（何が終わっていれば着手できるか）が書かれている——この 3 つが揃うと、チケット同士の依存関係がグラフとして見えてきます。触るファイルが重ならないチケットは並列に走らせられる。同じファイルに触るチケットや、他のチケットの完了を前提とするチケットは、順に処理するしかない。どれから着手すべきかは、グラフの上流から決まります。1 つのエージェントに直列で任せる段階から、複数のエージェントを並列に駆動する段階へ進むとき、Atomic Spec はそのスケジューリングの土台になります。
もっとも、状況は動いています。サブエージェントの仕組みが成熟したいまは、並列で走らせるか順に処理するかというスケジューリング自体を AI が考えられるようになりました。ならばチケットに書き出す意味は薄れたのか。そうは考えていません。AI がエージェント内部で立てた計画は、外からは見えないのです。Atomic Spec を GitHub のチケットとして持っておけば、何が終わり、何が進行中で、どこで詰まっているかを、人間がいつもの Issue ボードで確認できます。実行は AI に任せても、進捗の可視性はチームのものであるべき——それがチケットに書き続ける理由です。
品質はレビューの根性ではなく仕組みで守る
AI が実装量を増やすほど、人間のレビュー注意力が律速になります。私たちはレビューを頑張る代わりに、17 本の自動フックで品質ゲートを機械化しました。
- Spec 品質スコアリング — Spec の 5 要素充足度を 0〜5 で自動採点し、低スコアの Spec では実装を始めさせない
- Churn 検知 — 同一チケットの差し戻しが 3 回で警告、7 回で強制差し戻し
- Fix-Loop サーキットブレーカー — 同じ修正の失敗ループを検知して停止
- Diff サイズガード — PR 差分が閾値を超えたら分割を促す
設計哲学は「warn-never-block」です。原則は警告にとどめて人間の判断を残し、強制ブロックは規制ドメインなど本当に必要な場面に限定します。ゲートが厳しすぎると人間がゲートを迂回し始め、仕組み全体が形骸化するからです。
もうひとつ、レビューの盲点対策として cross-model review を併用しています。同一モデルは盲点も共有するため、実装と同じモデルにレビューさせても見逃しが重なります。別ベンダーのコーディングエージェントに独立視点でレビューさせることで、契約レベルの欠陥（インターフェース不整合など）の検出率を上げています。
実案件でどう機能したか — クライアントPoCでの適用
この仕組みは社内のドッグフーディングだけでなく、複数のクライアント案件でも運用しています。その一つが、数名の Pod 構成・数週間のスケジュールで回した PoC 案件です。体制には特徴がありました。メンバーは全員が他案件との兼務で、稼働率は 10〜50%。合計しても常勤換算でおよそ 1.4 人分です。しかも計画時点の試算では、AI を使わない従来見積もりに換算すると、必要工数が有効稼働の約 1.5 倍。数字の上では成立しない計画からのスタートでした。
それでも、PM からエンジニアまで全員が Claude Code を使う AI 駆動開発で、デモの期日を一度も動かさずに本番デプロイまで完遂しています。開発フローの実績は、マージされた PR が 31 件。PR 作成からマージまでの中央値は 16.4 時間で、65% が 24 時間以内に完了しています。兼務中心の体制でこの回転が出たことは、「AI が PR を量産してもレビューは律速にならなかった」ことの裏付けでもあります。
成立しない計画を成立させた鍵は、見積もりの解像度です。計画時に全タスクを 14 件の Issue に分解し（サイズ・優先度ラベル付き）、「AI で一律 3 倍速」のような雑な圧縮率ではなく、タスクタイプ別に圧縮率を見積もりました。なお、これは破綻を避けるために意図的に保守側へ倒した計画時の見積もり値です。
| タスクタイプ | AI 圧縮率（計画時の保守的な見積もり） | 例 |
|---|---|---|
| コード生成 / スキャフォールド | 3〜4 倍 | 画面、エージェントの制御フロー実装 |
| API 統合 / 設定 | 2〜3 倍 | 外部サービス接続、デプロイ設定 |
| バグ修正 / UI 調整 | 1.5〜2 倍 | エラー処理、メッセージング |
| 環境設定 | 1.0〜1.2 倍 | クラウド権限、サービスアカウント設定 |
| PM / イベント作業 | 1.0 倍（AI 適用不可） | 会議、調整 |
この見積もりから得た教訓は 2 つあります。
- 環境設定と PM 作業は AI では圧縮されない。 コードは AI が生成できても、クラウドの権限設定や関係者調整は人間の作業として残ります。「全部が 3 倍速になる」前提の計画は必ず破綻します
- 圧縮率は事前には確定できないので、2 段構えにする。 保守的シナリオ（2 倍）と楽観的シナリオ（3 倍）の両方でスコープ案を事前設計しておき、初期スプリントの手応えを見てから後続スプリントのスコープを判断しました
実務の体感では、スキャフォールドのような AI 向きのタスク単体の圧縮は、この保守的な見積もりを上回ることが珍しくありません。ならば全体もそれだけ速くなるかというと、なりません。プロジェクト全体の短縮率は必ずそれより控えめな数字になります。個々のタスクが何倍速くなっても、プロジェクトの完了時期は「AI で速くならない仕事」が決める——タスク単体の圧縮率と全体の短縮率を混同しないことが、AI 駆動開発の見積もりで最も重要な構造理解です。
バイブコーディングと何が違うのか — トレーサビリティが動的な意思決定を可能にする
AI に自然言語で指示してコードを書かせる、という見た目は同じでも、AI-DLC とバイブコーディングの本質的な違いは要件のトレーサビリティにあります。バイブコーディングは 2025 年に生まれた言葉で、生成されたコードの中身を確認せず「雰囲気」で開発を進めるスタイルを指します。探索やプロトタイピングでは強力です。しかし要件と実装の対応関係が残らないため、「すべての要件が実現されたか」を後からチェックできません。仕様変更が来たときに、どこを直せばよいかも分かりません。
AI-DLC では、要件（PRD）→ ストーリー → Issue → PR の対応関係をトレーサビリティマトリクスとして維持します。手間に見えますが、更新は AI に任せられるため運用コストは従来ほど高くありません。前述のクライアント PoC では、このトレーサビリティが 2 つの動的な意思決定を可能にしました。
ビジネス要件に従ってスケジュールを切り直せた。 週次のクライアント合意でスコープが動くたびに、トレーサビリティマトリクスを増分更新し、要件と Issue の対応を保ったままスプリント計画を切り直しました。「どの要件を落とし、どれを残すか」が要件単位で明示的に意思決定でき、落とした要件は落としたと記録に残ります。雰囲気でコードが増えていくバイブコーディングでは、この判断自体が不可能です。
アーキテクチャを影響の小さい場所で変更できた。 プロジェクト中盤に、設計変更イベントが起きました。クライアント側で開発が続く中核モジュールの改訂版を、途中で受領することになったのです。受領原本と自社実装を分離するアーキテクチャを最初から取っていたため、コア部分の差し替えを周辺レイヤーに波及させずに吸収できました。変更の影響範囲が要件単位でトレースできるからこそ、「どこで変更を受け止めるか」を選べます。
バイブコーディングを否定したいわけではありません。個人の探索やプロトタイプ 1 週目までは、トレーサビリティの維持コストのほうが高くつくこともあります。分水嶺は説明責任の有無です。クライアントに納品する、チームで引き継ぐ、要件の実現を保証する——そのどれかが発生した瞬間に、トレースできる開発プロセスが必要になります。
AI駆動開発の効果をどう測るか — DORA Four Keysの再定義
「AI で開発は速くなったのか」に答えるため、私たちは DORA Four Keys を AI-DLC 向けに再定義して運用しています。効果の計測を個人の心がけに委ねず、仕組みとして残すための再定義です。
| DORA 指標 | AI-DLC での再定義 | 何を測るか |
|---|---|---|
| Deployment Frequency | VDF（Value Delivery Frequency） | 価値の届く頻度 |
| Lead Time for Changes | SVLT（Spec-to-Value Lead Time） | Spec 起票から価値到達まで |
| Change Failure Rate | Rework Rate | マージ後の手戻り率 |
| Time to Restore | TTC（Time to Correct） | 指摘から修正完了まで |
これらの上流に置いているのが AI-Confidence という複合指標です。Spec 品質・CI 結果・セッションのターン数実績・レビュー結果の 4 要素を重み付けして 0〜1 で算出します。運用上の因果は「Spec 品質 → AI-Confidence → VDF」という一方向のチェーンです。仕様の質がすべての上流にある——それが数字で確認できます。
次の実測値は、いずれもこのプラグイン自体の開発を 1 人 + AI エージェントの Solo 構成のスプリントで運用した際の計測値です。条件の異なるチーム開発へそのまま外挿できる数字ではありません。「この解像度で測れる」ことの実例です。
- AI-Confidence の平均は 0.874（マージ済み PR 5 件、PR 本文への自己申告値を canonical source として集計）
- ターン数予測のキャリブレーションは 167 セッションの実績分布に基づいて閾値を更新
- API コストの内訳では 64.8% が cache-read（プロンプトキャッシュの効果が支配的）
- レトロスペクティブのアクション完了率は 27/30 = 90% をベースラインとして運用
数字そのものより、「この解像度で測れる状態を作ること」が導入の成果だと考えています。測れないものは改善できません。
役割はどう変わるか
AI-DLC の導入はエンジニアだけの話ではありません。ただし、役割名を付け替える組織変更をイメージすると実態とずれます。実際に起きるのは、日々の仕事の中身が少しずつシフトしていくこと。次の表は、そのシフトの方向に概念的な名前を付けた整理です。
| 従来の役割 | シフトの方向（概念的な呼び名） | 変化の中身 |
|---|---|---|
| プロダクトオーナー | Value Orchestrator | 「作った（Output）」と「価値が出た（Outcome）」の 2 層で Done を管理 |
| スクラムマスター | Agent Orchestration Coach | AI と人間のワーキングアグリーメントを設計・運用 |
| プロジェクトマネージャー | AI Strategy Architect | 機能起点から AI ケイパビリティ起点の計画へ |
肩書きが変わらなくても、このシフトは既に始まっています。先の PoC で PM 自身が Claude Code で Issue を書いていたのは、その一例です。共通する原則は最初に述べたとおり、「アカウンタビリティは常に人間が持つ」です。
導入は何から始めるべきか
全部を一度に導入する必要はありません。私たちの経験では、次の順番が現実的です。
- チケットを Atomic Spec 形式に書き直す — ツール導入ゼロで今日から始められ、効果が最も大きい
- Agent Loop のタイムボックスを導入する — 特に 4 時間ルール。分割不足が可視化される
- 計測を始める — まず TTC と Rework Rate の 2 つで十分
- 品質ゲートを自動化する — 運用が回り始めてから、フックで機械化する
実際、社内で最初に定着した AI 活用もこの入口でした。チケット作成は時間がかかるうえ、5 要素のフォーマットに沿って書き切るのは慣れるまで負担が大きい。そこで「フォーマットに沿ったチケットの下書きを AI に書かせ、人間は中身を確認して直す」ところから始めました。何を作るかを考える仕事は残りますが、書く負担が消えるだけで、運用を続ける心理的なハードルは大きく下がります。
この入口はソフトウェア開発チームにとどまりませんでした。社内のデータチーム（アナリティクスエンジニア）にも同じやり方が広がり、ダッシュボード開発やデータ分析のプロジェクトでも、チケット作成からの AI 活用が回っています。コードを書く仕事かどうかは、入口の条件ではないのです。
よくある質問
Q. バイブコーディングとはどう違いますか？
要件のトレーサビリティの有無が本質的な違いです。バイブコーディングは要件と実装の対応関係が残らないため、要件の実現を後から検証できず、仕様変更時の影響範囲も特定できません。AI-DLC は要件 → Issue → PR の対応を維持するので、スコープ変更や設計変更を要件単位で意思決定できます。探索・プロトタイプにはバイブコーディング、説明責任が発生する開発には AI-DLC という使い分けです。
Q. AI-DLCとスクラムは併用できますか？
できます。AI-DLC はチケットの粒度とライフサイクルの再設計であり、スプリントやレトロスペクティブといったスクラムのイベント構造とは直交します。私たちもスプリント運用の中で Agent Loop を回しています。
Q. AWSのaidlc-workflowsとこの記事の実装は何が違いますか？
同じ Whitepaper を起点とする並列の実装です。2026 年 7 月に GA となった公式の 2.0 は、Claude Code を含む各ハーネス向けのネイティブ配布となり、フックによる強制や決定論的なステート管理を備えました。エンジン層の機能差は解消されつつあります。現在も残る違いは、組織レベルの計測とプロセス改善、チーム運営のセレモニー、チケットシステムとの統合、そして上流の要件モデリング手法です。私たちはこの上位レイヤーに投資を集中させ、公式のエンジンを使うプロジェクトでも同じ層が乗るように切り出していく方針です。詳細は今後の方針を参照してください。
Q. 小規模チーム（1〜3人）でも導入できますか？
できます。むしろ 1 人 + AI エージェントの構成は Agent Loop が最も回しやすい形です。本記事の詳細メトリクスは Solo 構成で計測したものですし、数名の Pod 構成でもクライアント PoC で運用済みです。メトリクスの目標値はチーム規模（Solo / Pod / Squad）ごとに別の閾値を使います。
Q. 実測データはどのような環境で計測したものですか？
2 系統あります。①TTC や AI-Confidence などの詳細メトリクスは、この仕組み自体の開発を 1 人 + AI エージェントの Solo 構成で運用した際の計測値です。②タスクタイプ別圧縮率と工期短縮は、数名の Pod 構成で数週間運用したクライアント PoC での実績・見積もり実務の値です。いずれも統制実験ではなく実運用の計測であり、規模と条件を本文に明記しています。
Q. どのメトリクスから計測を始めるべきですか？
TTC（指摘から修正完了までの時間）をおすすめします。計測が簡単で、プロセス改善（Same-Session Close など）の効果が最も分かりやすく数字に出ます。
Q. Claude Code以外のエージェントでも実践できますか？
方法論（Atomic Spec、Agent Loop、DORA 再定義）はエージェント非依存です。実装から入る場合、公式の 2.0 は Claude Code のほか Kiro、Codex CLI、opencode に対応しているため、選択肢は以前より広がっています。本記事で紹介したフックによる強制は Claude Code のプラグイン機構に依存していますが、上位レイヤー（計測・セレモニー・上流モデリング）はエンジン非依存の形へ切り出していく方針です。
今後の方針 — AWS公式実装2.0のGAを受けて
ここまでの事例は、公式リファレンス実装が v1 系だった 2026 年前半の判断に基づくものです。その前提が、2026 年 7 月に変わりました。
GA となった AI-DLC Workflows 2.0 は、Markdown ルールの配布ではありません。ハーネス中立なコアから各実行環境向けのネイティブ配布を生成する構成に変わり、Claude Code 向けにもエージェント定義とフックが同梱されます。5 フェーズ 32 ステージ、14 エージェント、TypeScript による決定論的なステートマシンと監査ログ。フックによる強制も、決定論的な判定も、公式が持つようになりました。
| 軸 | awslabs/aidlc-workflows 2.0 | Monstarlab 実装 |
|---|---|---|
| 配布形態 | ハーネス別のネイティブ配布（Claude Code / Kiro / Codex CLI / opencode ほか） | Claude Code プラグイン |
| 実行時の強制 | フック同梱、ステート遷移とレビュー範囲を決定論的に強制 | フックによる強制 |
| 工程の粒度 | 5 フェーズ 32 ステージ、14 エージェント、9 スコープ | 循環型 7 段階（Agent Loop） |
| 監査 | 74 種のイベントによる監査ログ | セッションメトリクス（jsonl） |
| 計測・改善 | 監査ログの記録まで | DORA 再定義、AI-Confidence、TTC などの派生指標と改善サイクル |
| チーム運営 | 対象外 | スプリント計画、レトロ診断、ダイジェスト、エージェント較正 |
| チケット連携 | 生成物はリポジトリ内で完結 | GitHub Issues / Projects V2 / Linear / Jira を正とする運用 |
| 上流の要件手法 | 汎用的な Ideation | RDRA / Event Storming / 戦略的 DDD / ICONIX 派生の段階的導出 |
私たちにとってこれは、方向性の裏づけでもあります。フックによる強制も決定論的な判定も、AI-DLC を実運用に載せるには必要だと考えて先行投資してきた要素であり、公式 2.0 が同じ設計にたどり着きました。そしてエンジン層は今後、フルタイムの開発体制とコミュニティを持つ公式が最も速く進化させていく領域になります。私たちが同じものを並行して作り込む理由は薄れました。
一方で、表の下半分は埋まっていません。公式のロードマップを読む限り、これらは未着手なのではなく、そもそも射程の外にあります。監査ログは「何が起きたか」の記録までで、そこから DORA 指標を導いてスプリントの改善に回す部分は含まれません。チケットを契約や合意の単位として扱う統合もありません。要件を業務構造から段階的に導く手法も、汎用的な Ideation にとどまります。ツールを提供する立場と、デリバリーの説明責任を負う立場とでは、必要になる層が違うのだと理解しています。
そこで私たちは、方針を切り替えることにしました。エンジン層は公式に譲り、その上に乗る 3 つの層——上流の要件モデリング、組織の計測とプロセス改善、デリバリー実務——に投資を集中させます。
この方針には、実装上の制約がひとつ付きます。これらの層を特定のエンジンに依存しない形に切り出すことです。公式のエンジンを使うプロジェクトでも、私たちのプラグインを使うプロジェクトでも、同じ計測層・同じ上流手法が乗る状態を目指します。公式が採用されるほど私たちの層の出番が増える構造にする、という判断です。
本記事で紹介した Atomic Spec・Agent Loop・DORA 再定義という方法論、そして実測データの読み方は、エンジンがどれであっても変わらず使えます。事例のエンジン部分は過去形になっても、方法論と計測は現役です。
まとめ
AI 駆動開発の律速は「AI がコードを書く速さ」ではなく、仕様の粒度・品質ゲート・計測というプロセスの側にあります。AI-DLC はそのプロセスを AI 前提に再設計する方法論であり、概念だけでなく現場で運用可能です。
エンジンをどれにするかは、もはや本質的な選択ではなくなりました。公式の 2.0 が Claude Code を含む複数のハーネスに対応した今、実装から入るハードルは下がっています。残る難所は、要件をどう構造化するか、成果をどう測って改善に回すか、チームがどう運営するか——つまりエンジンの上に乗る層です。
まずはチケット 1 枚を Atomic Spec に書き直すところから始めてみてください。
参考資料
- AWS DevOps Blog: Open Sourcing Adaptive Workflows for AI-Driven Development Life Cycle
- AWS 公式リファレンス実装
- DORA Four Keys
Author
その他おすすめ記事
FastAPI × Diffusers でローカル完結の「顔属性変換」学習アプリをつくる
生成 AI を「使う」だけでなく「アプリに組み込む」とどうなるのか。これを手を動かして理解したくて、人物写真をアップロードすると顔の属性（性別的な見た目）だけを別の性別に変換する学習用 Web アプリを個人で作りました。外部の画像生成 API には一切頼らず、推論まですべてローカルで完結させているのが特徴です。本記事では、その構成と実装上の判断、つまずいた点を技術寄りに整理して共有します。 なぜ「ローカル完結」にこだわったのか 顔写真は最もセンシティブな個人データのひとつです。学習目的とはいえ、自分や知人...
AIで生演奏のピッチ検出を試してみた
さて。このAI全盛期、我が社でも例に漏れずAIをうまく使っていこうという流れがきているため、AIを使った技術の検証をしてみようと思います。 どうせなら自分に身近なテーマを、ということで長らく趣味で習っているヴァイオリンのピッチ判定ができたら面白そうです。 調べてみたところいくつか使えそうなAIモデル(CREPE、Basic Pitch)があったため使えるか検証していきます。 また、比較用としてAIを使っていない従来の方式のaubioも試してみましょう。 はてさて、全てうまく動くでしょうか...。 環境構...
