AIDiveTL;DR
- プレイブックの6つのステージは、それぞれコミットされる成果物(intent.md、spec.md、plan.md、PR、incident record)で終わります。公開記事と全14レッスンのコースは全体像を説明していますが、どちらも計測値は出していません。
- 実在の Express + Prisma リポジトリで最初から最後まで走らせたところ、チェーン全体では1つのバグ修正に 11 min 31 s、$3.46 かかり、直接プロンプトなら 2 min 13 s、$0.70 でした。時間は ×5.2、コストは ×4.9 で、どちらもテストは green です。
- 本当のコストは読む作業です。1行のクラス修正に対して成果物が 5,488 words、200 wpm で約 27 min。チェーンは書く時間を読む時間に置き換えます。
- 今回の条件で元が取れたのは6ステージ中3つ。Plan(intent.md)、Build(plan mode + CLAUDE.md + TDD)、Deploy(REVIEW.md + hook)です。Design と continuous evals は個人開発では割に合わず、Maintain は実行していません。
- spec ステージは自分の前提条件を自分で指摘しました。org skill が存在しなかったため、brand、security、UX のポリシーに照らした確認は一度も行われていません。プレイブックはそれらの skill が書かれている前提です。
- 決定論的なゲートは機能します。PreToolUse hook は exit 2 で 14 s のうちに deploy をブロックしました。その前に、モデルは hook が動くより先に自分の判断で一度断っていました。
計測が示すこと
プレイブックは「code is no longer the bottleneck」と位置づけ、すべてのステージを、intent.md から spec.md、plan.md、PR、incident record までコミットされる成果物で終えるよう求め、Maintain には control band を置いています s1。コースには引用できる具体値があります。eval スイートとして実タスク20〜50件、REVIEW.md の nit 上限5件、並列セッションは最大2〜3個、そして同じミスを2回したら CLAUDE.md に書くというルールです s2。最も鋭い中立的な読み解きは、各成果物を誰が起草し誰が承認するかを表にして、この文書を「vendor-claim throughout」「no measurement anywhere」と評しています s4。
修正タスクは実在する upstream のバグでした。新規 clone で npx nx test api を実行すると、最初から1スイートが失敗し(auth.service.test.ts、"TypeError: Cannot read properties of undefined (reading 'prototype')")、4スイートが pass、14テストが green、2.2 s でした。直接パスは 2 min 13 s、$0.70、40 turns で完全に green になりました。チェーンパス(intent、spec、plan、build の順)も 11 min 31 s、$3.46、169 turns で green に到達。マシン側だけで ×5.2 の時間と ×4.9 のコストです s2。
チェーンが痛むのは人間側です。読むべき成果物は 5,488 words(intent 558 + spec 2,167 + plan 2,763)、200 wpm で約 27 min。対して、直接レビューするのは小さな diff 1つです s4。機能タスク(mute authors)をチェーン全体で通すと 15 min 13 s、$4.11、158 turns かかり、migration 付きの Prisma Mute モデル、mute と unmute のエンドポイント、フィードのフィルタリングを出荷しました。15ファイルで 1,422 行追加、50テスト green、新規または拡張のテストファイルが3つと e2e spec 1つです。成果物は 6,852 words(intent 450 + spec 2,337 + plan 4,065)、読むのに約 34 min でした s2。
Design ステージへの懐疑的な見方は当たっていました。LinkedIn の批判は、プレイブックが前提条件を隠していると指摘します。brand、security、UX の org skill がすでに存在していること、そしてブレインストームの進め方を知っている人がいることです s7。エージェントは促されなくてもそれを認めました。spec.md が立てた懸念 C0 にはこうあります。"No org skills available. … This spec has therefore not been checked against brand, security or UX policy." コードベースを言い換えるだけでポリシーを確認できない 2,000 words 超の spec は、1人で作業するなら飛ばすべきステージです s7。
インフラへの批判も当たっていました。テストが古い fake に当たると "the agent sees the tests pass and reports the work finished" になる、という議論です。成果物チェーンが記録するのは決めたことであって、実際に動いたものではないからです s8。今回の実行でも、ループが検証したのはユニットテストとビルドだけでした。レビュー自身が nx e2e を "Not run: needs a running server and a seeded DB"、prisma migrate status を "Not run: needs a DB" と挙げています。green のループは本物のシステムに一度も触れていません s8。
Deploy ステージは安く得られた成果でした。REVIEW.md は 117 s、$0.80 で、nx test(5/5 スイート、50 passed)、nx build(pass)、plan のベースラインとの lint 差分(34 対 33、plan の項目 A3 が +1 を明示的に許可)、prettier チェック(9ファイル失敗、nit N1 として記録)を実行しました。判定は Important 0件、nit 6件(上限が適用されたため5件を列挙し1件は要約)。レビューは "this agent does not approve" と述べて自分の作業の承認を拒みました。コースが書く職務分離そのものです s2。hook ゲートはドキュメント通りに動きました。マージ前に deploy を頼むと、エージェントはスクリプトを実行せず自分の判断で断ったので、hook は発火しませんでした。マージ後の deploy は PreToolUse hook(exit 2)に 14 s でブロックされ、ゲートのメッセージが返りました s19。
eval は書くのは安いのですが、間違えやすいものでした。git 履歴から5ケースを 283 s、$1.44 で作成。2回の実行はどちらも誤ったベースで走りました。ランナーが修正のマージ後にブランチを切ったためです。両方のエージェントはそれに気づき("the bug was already fixed here")、pass を偽装しませんでした。eval 1回の実行は約 60〜70 s なので、プレイブック自身の規模である20〜50ケースでは、CI 1回あたりエージェント時間で約 20〜55 min になります s2。CLAUDE.md のセットアップは、コミットする1ページで 63 s、$0.44 と最も安い一手でした。読み取り専用の CI ログ分類は、11 s、$0.13 で正しい原因を特定しました s2。
コミュニティのスレッドは、より広いテレメトリを持ち込みます。開発者 10,000 人の調査では、AI 利用度の高いチームは PR のマージ数が 98% 増える一方、レビュー時間は 91%、PR サイズは 154% 増えています s6。
計測結果
プロトコル: チェーンは headless(claude -p、モデル claude-opus-5-5、権限は acceptEdits に allowlist を加えた範囲、--setting-sources project,local)で、gothinkster/node-express-realworld-example-app のスクラッチ clone(Express + TypeScript + Prisma + Postgres 16 を Docker で、Nx workspace)上に実行しました。各ステージは計時して exp/metrics.jsonl(17行)に記録しています。合計: $11.90 + hook 再実行の $0.14、539 + 3 turns、エージェント実時間で約 41 min。
| ステージ | 所要時間 | Turns | コスト |
|---|---|---|---|
| CLAUDE.md setup (lesson 5) | 63 s | 27 | $0.44 |
| FIX direct (no chain) | 133 s | 40 | $0.70 |
| FIX intent.md | 39 s | 8 | $0.22 |
| FIX spec.md | 162 s | 39 | $0.83 |
| FIX plan.md | 180 s | 46 | $1.00 |
| FIX build | 310 s | 76 | $1.40 |
| FEAT intent.md | 29 s | 6 | $0.18 |
| FEAT spec.md | 118 s | 20 | $0.62 |
| FEAT plan.md | 240 s | 41 | $1.17 |
| FEAT build (TDD) | 526 s | 91 | $2.14 |
| Review (REVIEW.md) | 117 s | 19 | $0.80 |
| Hook demo (refused) | 20 s | 5 | $0.14 |
| Hook demo (blocked) | 14 s | 3 | $0.14 |
| CI triage (read only) | 11 s | 3 | $0.13 |
| Evals: write 5 cases | 283 s | 76 | $1.44 |
| Eval run 1 / run 2 | 72 s / 59 s | 24 / 18 | $0.38 / $0.29 |
| プレイブックのステージ | 判定 | 理由 |
|---|---|---|
| Plan (intent.md) | 採用 | 29〜39 s で、本物の未決事項を浮かび上がらせ、黙って決まるアーキテクチャ選択を防ぐ |
| Design (spec.md) | 個人では見送り | コードベースを言い換えるだけの 2,000 words 超。価値は存在しない org skill が前提(自身の C0 フラグ) |
| Build (plan mode + CLAUDE.md + TDD loop) | 採用 | 50テスト green、逸脱を記録、レビューが plan に依拠できた |
| Test (continuous evals) | 当面見送り | プレイブック自身の規模で CI 1回 20〜55 min。ベース commit の規律が先に崩れた |
| Deploy (REVIEW.md + hooks) | 採用 | $0.80 のレビューで実チェック、さらに 14 s の決定論的ブロック |
| Maintain (control bands) | 未証明 | 数週間の本番テレメトリが必要。予測であり、実行していない |
注意点: 1リポジトリ、1人の開発者、1日だけの計測です。チーム規模の施策は実行しておらず、headless モードでは対話的なやり取りが1つのプロンプトに圧縮され、eval のコストは1回の実行分だけです。
月曜にやること
- メインのリポジトリに CLAUDE.md を1ページ書く。build、test、lint のコマンドと、先週エージェントがやった2つのミス。コミットする。エージェント時間の目安は 63 s。
- 次の自明でないタスクの前に、まず intent.md を頼む。ゴール、非ゴール、未決事項。未決の質問に答えてから、エージェントに plan を作らせる。org のポリシー skill で確認できないなら spec.md は飛ばす。
- build ステージは plan mode と TDD ループで回し、plan に逸脱(D1、D2, ...)を記録させて、レビューが依拠できるようにする。
- 新しいセッションで動かす REVIEW.md のパスを追加する。nit の上限と、明示的な "this agent does not approve" の一行を入れる。test、build、lint の差分、フォーマッタのチェックを実行させる。
- 決定論的なゲートを1つ置く。ブランチが main でないときに
deployで exit 2 を返す PreToolUse hook。 - green のループを信じる前に、実行しなかったもの(e2e、migration、本物の DB が要るもの全部)をレビューの末尾に列挙する。
- 自分の gate tax を測る。同じ小さなバグで直接パスとチェーンパスを計時し、読む必要があった words を数える。
さらに深く
- 2ゲート版: 敵対的レビューゲート(sdlc-gate)と、ステージごとではなく2か所だけの人間の判断点。小さなチームに現実的な形です s12。
- そのままインストールできる完全なチェーン: intent、spec、plan、REVIEW のテンプレート、gate validator、eval runner、control band 検出。足場を手作りしたくない人向けです s5。
- インタビュー先行の計画: 質問は一度に1つのほうがまとめて聞くより良く、"AI agents don't ask clarifying questions. They assume." セットアップの記録で、計時はありません s11。
- 固定パイプラインが迂回される理由: "a docs fix and a payments migration shouldn't travel the same path"。実際のプロセスは見えなくなります。プレイブックを Kiro や GitHub Spec Kit と同列に論じています s9。
- プラットフォームベンダーが売りたがる穴: signal から intent への取り込み、blast radius によるルーティング、メトリクスのダッシュボード。s13。
- 1月から顧客チームで同じ形(CRAFT)を運用してきたコンサルティング会社。"we don't yet have a formal answer for what a control band looks like" と認めています s10。
- intent.md の実例(Select All チェックボックス)。このファイルの役割、つまりエージェントに黙って選ばせず未決事項を表に出すことを示します s14。
出典
- The AI-Native SDLC Playbook (launch post), claude.com. 読む理由: 6ステージの形とコミット成果物のルールが5分でわかる。
- The AI-native SDLC playbook (course, 14 lessons), Claude Academy. 読む理由: 数値が載っている唯一の場所(eval タスク20〜50件、nit 上限5件、セッション2〜3個)。無料でログイン不要。
- The Committed-Artifact Chain, howardism.dev. 読む理由: 各成果物を誰が起草し誰が承認するか、そしてプレイブックに計測されたものは何もないという率直な指摘。
- bashebr/ai-native-sdlc, GitHub. 読む理由: 自分で書かずに入れられるテンプレート、gate validator、eval runner。
- Anthropic published an AI-native SDLC playbook, r/ClaudeAI. 読む理由: Faros のテレメトリ(PR 98% 増、レビュー時間 +91%)を議論に持ち込んだスレッド。
- The AI-native SDLC Playbook is basically "do everything you did before, but inside Claude", LinkedIn. 読む理由: 隠れた前提条件の議論。spec ステージが自ら裏づけた。
- The AI-Native SDLC Starts With Your Infrastructure, MetalBear blog. 読む理由: 古い fake の問題。ベンダーの立場からの記事だが、議論自体は成り立つ。
- The AI-native SDLC won't be one process, worldprogramming.org. 読む理由: すべての変更に同じ道を通す形式主義への反論。
- Anthropic Wrote the AI-Native SDLC Playbook in August. We Wrote Ours in January., Substack. 読む理由: 独立したチームが同じ形に行き着き、Maintain の穴を認めている。
- AI-Native SDLC: First Try, kyle.pericak.com. 読む理由: インタビュー先行の唯一の実践記録。プレイブック公開前に書かれた。
- TsCarpe/claude-sdlc-skills, GitHub. 読む理由: 敵対的レビュー段階を持つ2ゲート版。
- Implementing the Anthropic AI-Native SDLC Playbook, Port blog. 読む理由: プレイブックが省いているものの一覧。穴の地図として読める。
- What Is intent.md in Claude Code?, dev.to. 読む理由: 構造をそのまま真似できる具体的な intent.md。
- Hooks guide, Claude Code docs. 読む理由: exit 2 の PreToolUse hook が、プレイブックの前提とする決定論的ゲートになる仕組み。
FAQ
1行の修正でもフルチェーンが元を取ることはありますか?
今回の実行ではありません。同じ green の結果に対して時間 ×5.2、コスト ×4.9、そのうえ読む量が 5,488 words 増えます。小さなタスクには intent.md だけを使ってください。
個人開発でなぜ spec.md を飛ばすのですか?
spec が自分で指摘しました。brand、security、UX の org skill がないためポリシーを確認できず、コードベースを言い換えるのに 2,000 words 超を使っています。
hook はモデルの判断の代わりになりますか?
いいえ、補強です。マージ前の deploy はエージェントが自分で断り、マージ後の試行は hook が exit 2 で 14 s のうちにブロックしました。