[AI-DLC v2感想]AI DLC v2の中身をみて、AI駆動開発で重要なエッセンスを抽出抽出ぅ！

Transcript

1. EPISODE / AI-DLC v2 AIで10倍速くなるチームと 10倍遅くなるチームの差 AWS が 100 社以上で見つけた "あるもの" ── AI-DLC Workflows 2.0 を読む 週末 1
2. 今日の問い AI を使って開発が 10倍速くなるチーム と、 なぜか 10倍遅くなるチーム がある。 同じツール。同じプロンプト。 ──なのに、結果が真逆。 何が、その差を作っているのか？ 2
3. 今日の約束 AI 生産性を分けているのは AI の腕じゃない。 合格条件を機械可読に書けた量 と 暗黙知をプロンプトに育てた量 だ。 これを 自分の言葉で誰かに説明できる ようになって帰る。 そして明日の朝、出社して 5 分でできる行動を 1 つ 持ち帰る。 3
4. 今日の題材 AI-DLC Workflows 2.0 Specification AWS Labs が 2026 年に v2 ブランチで公開した 7 ページのホワイトペーパー 公式リポジトリ：awslabs/aidlc-workflows (v2 branch) ライセンス：MIT-0 2026 年 4 月時点：pre-release / breaking changes 注意 AI-DLC Workflows 2.0 Specification（AWS Labs / 2026） 4
5. 話の地図（30分の歩き方） 1. かいち体験談 ── レビュー・修正ループに溶ける時間 2. AWS が見たデータ ── 10倍と "10倍遅い" は同じ実証から 3. v1 の振り返り ── 1年でぶつかった 3 つの壁 4. v2 の核心 ── 3 コンパートメント・モデル 5. 意外な既視感 ── 20年前の XP と、構造がそっくり 6. 明日からの一歩 ── 5 分でできる行動 1 つ 5
6. 体験談：成長したシステムで起きること AI コーディングエージェントにタスクを投げる ↓ 成果物を確認 → レビュー → 「ここ違う」 → 修正指示 ↓ また書く → また見る → また直す ↓ グルグル、グルグル、結局 結構な時間が経つ 新規の小機能 → 速い。 既に成長したシステム（Brownfield） → しんどい。 6
7. 同じ指摘を、来週も、再来週も、別の PR でも 毎回出る指摘の例 「この層から DB を直接触らない」 「この命名はうちの規約じゃない」 「ここはトランザクションで包む」 「ログにユーザー名を出さない」 特徴 毎回 口頭 で渡す どこにも 明文化 されていない でも、知っている人は知っている 新しい AI セッションは、また忘れる "採点" が、人間の頭の中にある。 7
8. AWS が見たデータ（v1 ベース） 100 社以上の実証で観測された数字 指標 結果 生産性 10〜15 倍 開発速度 40〜60% 改善 欠陥 40〜60% 削減 ROI 300〜500% ※ 同じ実証データに、もうひとつの事実が隠れている → AWS re:Invent 2025 — DVT214 / AWS DevOps Blog 8
9. もうひとつの事実 ── "遅くなる" チーム 同じ AI コーディングアシスタントを入れて、 むしろ開発が 遅くなった ベテラン開発者の RCT METR（研究機関）が行ったランダム化比較試験 "AI で速くなる" を、研究レベルで疑った報告 つまり ── AI を入れた瞬間に二極化 する AWS re:Post / METR RCT (要再検証) 9
10. AI-DLC v1 とは（2025年7月） SDLC 全工程に AI を組み込む方法論 ただし思想は ── 「AI に任せる」 ではなく 「AI と一緒にプロセスを回す」 AI Powered Execution AI が詳細計画を立て、自分から質問しに 来る Human Oversight 最終決定は人間。重大判断は委ねない AI-DLC v2 Specification / 1. 背景と目的 10
11. v1 の 3 フェーズ フェーズ 焦点 キーワード Inception ビジネス意図 → 要件 Mob Elaboration Construction アーキ・コード・テスト Mob Construction Operations インフラ・運用 (チーム監督下) Mob とは "チーム全員でワーワー" のこと。AI が出した案を、チーム全員で検証・ 調整する協働モード。 AWS DevOps Blog — AI-DLC 11
12. v1 が変えた言葉 従来 Sprint 週単位の作業サイクル v1 Bolts 時間〜日単位の濃い作業 従来 Epic 大きな機能の塊 v1 Units of Work AI が一気に駆け抜けられる粒度 12
13. v1 で何が起きたか ── そして、立ち止まる 1 年間、100 社以上で運用 10〜15 倍の生産性、ROI 300〜500% の事例 そして AWS は、自分の方法論に対して 3 つの反省 を、自分から公 開した。 これが、めちゃくちゃ正直で、めちゃくちゃ面白い。 13
14. 反省①：ステージの粒度が粗すぎた v1 は Build & Test を 1 つのステージ として扱った ところが、ほぼ 全ての顧客 がこれを分けていた： Build / Code Review / Functional Test / Security Test / ... "prescriptive stage definitions proved too opinionated" (規定的なステージ定義は、意見が強すぎた) Specification / Lessons from v1 14
15. 反省②：AI が "自分の出力" を採点できなかった v1 のステージは 成果物 を出す。 でも、その成果物を「合格」とする 基準 は、ステージ自身が持っていなかっ た。 標準、チェックリスト、ポリシー── ぜんぶ レビュワーの頭の中か、AI が見ない文書の中にあった。 → 修正指示は 毎回、人間から来た。ルールが書かれていたとしても。 15
16. 反省③：ツール共通化が "最大公倍数" に縮約された v1 は Markdown ルール を全ツール（Kiro / Q Developer / Cursor / Cline / Claude Code / Copilot / Codex）に配布 共通にしたせいで 各ツール固有の強みが使えなかった： Claude Code の skill-scoped hooks Cursor Composer のマルチファイル編集 Copilot Workspace の PR ネイティブループ Kiro の spec-kit diff 表示 → ポータビリティの代償が、ツールネイティブな優位性 だった 16
17. v2 のスローガン Humans codify the judgement. AI orchestrates and self-verifies — deterministically. 人間は判断を 体系化 する。 AI は采配と自己検証を 決定論的に 実行する。 17
18. v2 を理解するメタファー 「新人エンジニアを 自走させる ための社内マニュアル 整備」 新人さんに、仕事を回してもらうために必要なもの： 1. 依頼業務の 入力と成果物の形 を渡す 2. 「どこまでできたら合格か」の チェックリスト を渡す 3. 「ハマったら聞きに来てね」の ストップ条件 を渡す 4. 先輩が修正したら社内 Wiki に 追記 する v2 は、これと 同じことを AI 相手にやる 方法論。 18
19. v2 の中心構造：3 コンパートメント・モデル v2 では、すべての作業単位（Skill）が 3 つの "箱" を持つ契約として定義さ れる。 箱 名前 意味 1 What 入力・出力・中間成果物 2 How Do We Know It's Right 後置条件（合格基準） 3 What Did We Learn 実行時の学びの捕捉 Specification / Principle 4 19
20. Compartment 1：What（入力・出力） 「何が入って、何が出るか」 を 宣言的 に書く 例：コードレビュー Skill inputs: - pull_request - repository_context outputs: - review_comments - approval_status 命令的な手順 (do X then Y) ではなく、"型" として書く。 中間成果物が必要なら、それも明示的に列挙する。 20
21. Compartment 2：OK ライン ── v2 の魂 「どうやって正しいと判るか」 後置条件（Post-Conditions）= AI が 自己採点 に使う合格基準 例： 「N+1 クエリを発生させないこと」 「DB アクセスは Data Access Layer 経由であること」 「公開エンドポイントには認証が必須であること」 「本番環境で CloudFormation スタックを消すコードパスは存在しないこと」 これがあるから、AI が "自分でチェック" できる。 21
22. Compartment 3：実行時の学びを捕まえる 「何を学んだか」 人間の 修正・上書き・例外受容 を、新しい後置条件の候補として自動で拾う "あなた、要件ドキュメントの特定セクションを、3 回連続で書き直してますね。 これ、ルールに追加します？" ── と、AI が 聞いてくる。 これを Compound Engineering（複利エンジニアリング）と呼ぶ。 使うほどに、人間介入の頻度が 下がっていく。 22
23. 体験談との接続 "これ、来週も再来週も同じ指摘してる" この時間が どこに消えていたか の正体： → Compartment 2 が、無かった。 → ルールが 人間の頭の中 から出てきていなかった。 → だから AI は 毎回 0 から 採点を待っていた。 "採点" を、機械が読める場所に置けていなかった。 23
24. OK ラインの 2 種類 ① LLM 判定型 自然言語で書く合格基準 用途： ニュアンス系 コードレビュー品質 可読性 設計の妥当性 ② 決定論的 Executable スクリプト / linter / static analysis 用途： 白黒つけたい セキュリティ no-go zone 命名規約 本番削除禁止ルール Specification / 3. Structure 24
25. AWS は "自分の AI" を疑っている 同じ LLM が候補を生成し、そのあと自然言語で書かれた後置条件に対して評価 すると、 文字面は満たすが意図は満たさない出力に収束するリスクがある 同じ脳みそが、自分のテストを、自分で採点する。 → 答案用紙の自己採点。 だから ── LLM 判定型 "だけ" の Skill は、自分の判定では止まらない。必ず人間が見 る、という設計。 Specification / Skill Definitions 25
26. 自律化の境界線 AI が自走できるのは、 「AI が改変できないチェッカーで 合格を判定できた範囲」 だけ。 これが、v2 が引いた境界線。 Executable で OK ラインが書ける範囲 → AI が自走 LLM 判定しかできない範囲 → 人間が最終確認 OK ラインが書けていない範囲 → 全部、人間に来る（v1 の今） 26
27. 仕掛け①：Halting Condition（停止条件） すべての自己修正ループに 最大反復数 または トークン上限 を 義務とし て 書く 「2 時間ハマったら、先輩に聞きに来てね」を、仕様で全 Skill に強制。 AI が halting condition 内で収束できない → 無限ループに入る前に、必ず人間にエスカレート "ループするAIを設計で禁ずる" ── 多くの AI フレームワークが "がんばらせる" 方向 に寄る中で、これは珍しい。 27
28. 仕掛け②：Compound Engineering（再掲） 人間の介入そのものが ルール集を太らせる 例： 同じ修正を 3 回 → AI が「ルール候補」として提案 同じ設計上書きを繰り返す → ガードレール候補として提案 人間が承認 → アクティブルールに昇格 使うほどに、Compartment 2 が 自動で水分補給 されていく。 28
29. 仕掛け③：4 つのプリミティブ ① Skill ライブラリ 3 コンパートメント契約を持つ作業単位 ② Persona-Agents Skill を束ねた専門家ロール （アーキ・開発者・セキュリティ等） ③ Orchestrator ツール非依存。 Skill を adaptive に並べる ④ Package Manager 各ツール固有の構造に翻訳 (Kiro / Claude Code / etc) Orchestrator は rigid なパイプラインではない。プランは可変、実行中に適応する。 Specification / 5. Orchestrator 29
30. 9 つの原則 ── 一覧（参考） # 原則 一言で 1 人間の判断は機械に蒸留できる 採点を機械化する 2 意図は曖昧から始まる（でOK） AI は質問する 3 AI は自己修正する解探索器 Halting Condition 必須 4 三コンパートメント・モデル What / OK / 学び 5 全ステージが三コンパートメントに収まる 設計にも、運用にも 6 ステージ分解 > 単一ショット圧縮 1 プロンプトでは無理 7 自律化は安全な漸進で ビッグバンではない 8 拡張性は最初から 追加・置換・新規 9 実践からの学び Compound Engineering Specification / 2. Principles 30
31. ブレーキ：批判的視点 v2 はまだ Pre-release 動作するのは Kiro IDE / Kiro CLI のみ "breaking changes 注意" と公式に明記 Q Developer / Cursor / Claude Code は将来計画 外部評価者からの指摘： 学習機構の実装は不透明 理論的基礎が薄く、cookbook 寄り 実証検証はこれから（10〜15 倍は v1 ベース） それでも "採点を機械に渡す" という設計思想 は、AI コーディングの本質を突いてい る。 Peter Tilsen / Data Science Collective 31
32. ここで、意外な既視感 このホワイトペーパーを読んでて、ずっと既視感があった。 Kent Beck が 20 年前に提唱した エクストリーム・プログラミング (XP) 3 つの価値：シンプルさ / コミュニケーション / フィードバック 「これ、v2 と 同じこと、言ってない？」 Kent Beck『Extreme Programming Explained』(2000, 2nd ed. 2004) 32
33. v2 と XP の構造的相似 XP のプラクティス v2 のメカニズム 自動テスト 守れた範囲だけ、変化を恐れずに済む Compartment 2 (Executable) 機械可読な合格条件で AI が自走する ペアプロ 暗黙知をチーム内で共有・浸透 Compound Engineering 人間の修正をプロンプトに昇格させる YAGNI / シンプルさ いま必要なものだけ書く Adaptive Workflow rigid なパイプラインを否定 小さく・速く・継続的に Halting Condition ハマる前に止めて、人間に渡す XP は人間チーム内の分担、v2 は人間と AI の分担。 登場人物は違うが、構造は同じ。 33
34. AHA Moment AI 生産性を分けていたのは、AI の腕じゃなかった。 合格条件を 機械可読 に書けた量 ＋ 暗黙知を プロンプト に育てた量 この合計が、AI の自走範囲 を決める。 34
35. 言い換え v2 が言ってるのは、要するに フローを設計するな。 "合格" と "暗黙知" を 設計しろ。 v1 はフローを示した。v2 は "規格" を提供している。 35
36. 明日からの一歩 ① 5 分で終わる課題 1. 直近 1 週間で書いた PR レビューコメント を 3 つ読み返す 2. その中で "3 回以上、似た指摘をしている" ものを 1 つ選ぶ 3. リポジトリ直下の CLAUDE.md / .cursor/rules / AGENTS.md に 1 行 書き下す それが、あなたの組織にとっての 最初の Compartment 2 ルール。 36
37. 明日からの一歩 ② 1 ヶ月、続けたい習慣 人間が AI 出力を 直した差分 を、メモに残しておく 3 個、5 個、10 個と溜まっていく 同じ修正が複数回出てきたら、Compartment 2 に昇格 あなたの組織が、初めて OK ラインを機械に渡し始める 瞬間 これが Compound Engineering の入り口。 37
38. 自律化はビッグバンではなく、安全な漸進で 原則 7 ── Autonomous Development in Safe Increments "AI が全部やってくれる世界" も来ないし、 "人間が全部見てる世界" も持続しない。 私たちが言葉にできた範囲だけ、 AI と分担できる。 38
39. クロージング AI を速くするのは、AI の腕じゃなく、 私たちが言葉にできた範囲 と プロンプトに育てた範囲 です。 ホワイトペーパー、和訳しました。 エピソードの概要欄に置いておきます。 ここまで聴いてくださって、ありがとうございました。 「ひまじんプログラマーの週末エンジニアリングレッスン」 、また次回。 39