Anthropic公式のClaude Codeプレイブックを初めて実測した

AnthropicはClaude Code向けにAIネイティブSDLCのプレイブックを公開しました。6つのステージがあり、それぞれがコミットされるファイルで終わります。内容は無料コースとして教えられています。中心にある主張は、コードはもうボトルネックではなく、ボトルネックを管理するのはコミットされた成果物の連鎖だ、というものです。ところが文書そのものには、時間もコストもベンチマークも、計測と呼べるものが一切ありません。そこで実在のリポジトリで初めて時間を計った検証を行いました。計測付きのClaude Codeセッションを16回、すべてのゲートに値段を付けた結果、判定はちょうど連鎖の真ん中で割れました。途中、2分で済む修正をフルチェーンに通して儀式のコストを算出し、さらに私たち自身のデプロイが2回止められました。そのうち1回は、たった4行のシェルスクリプトによるものでした。

検証環境は、計測付きのClaude Codeセッション16回、計算コスト約$12、実在のリポジトリ1つです。プレイブックは6つのステージ、つまり計画、設計、実装、テスト、デプロイ、保守で進みます。各ステージはコミットされるファイルで終わり、次のステージがそのファイルを読みます。intent、spec、plan、プルリクエスト、インシデント記録です。コミットが監査証跡になります。Anthropicはこれを14レッスン、約1時間の無料コースとして提供しており、想定しているのはレビューゲートを持つ企業です。私たちは、開発者1人の現場に持ち込んでも残るものを検証しました。

リポジトリはRealWorldのデモアプリ(Express、TypeScript、Prisma、Postgres)です。実際のテストを備えた本物のプロジェクトで、クローン直後の状態ではスイートが1つ壊れています(通るスイートは4つ、緑のテストは14件、実行時間は2秒)。このバグは後で対照群になります。採点ルールは、ゲートの出力が出荷されるものを変え、しかもそのコストより安く済むなら、そのゲートは元を取る、というものです。

入場券となるのは、リポジトリ直下に置くメモリファイルです。コマンド、規約、アーキテクチャ、モデルが繰り返す間違いを、1ページ未満にまとめます。私たちのものは63秒、$0.44で書いてコミットしました。方法面での正直な注意点が1つあります。ヘッドレス実行では、プレイブックのインタビューが単一のプロンプトに圧縮されます。

最初のゲートは、誰かが設計に入る前にアイデアを記録します。機能リクエストは、フィードを埋め尽くす投稿者を読者がミュートできるようにしたい、というものでした。プレイブックはこの成果物を、モデルと一緒に書き、あなたが所有するproto-specと呼び、起点として3つを認めています。アイデア、起票されたチケット、インシデントアラートです。テンプレートは5つのセクションで、見出しが考える作業を担います。問題、提案する成果、影響を受けるユーザーとシステム、制約、未解決の質問です。作業のループは5つの動きです。説明し、ブレインストームし、テンプレートから生成し、修正し、コミットします。

intent.md	時間	コスト
投稿者ミュート機能	29 s	$0.18
壊れたテストスイート	39 s	—

価値は一番下の未解決の質問にあります。ミュートした投稿者のお気に入りはどうなるのか。その人のページには引き続き到達できるのか。これらは、コーディングエージェントなら黙って決めてしまう判断で、それが記録され日付も付きます。ファイルはコミットされるので、作成者とタイムスタンプはチャットが消えても残ります。プロダクトオーナーは、承認する前に下書きを修正します。このステージについてAnthropic自身が掲げる目標は、要件の引き出しを数週間ではなく数時間で行うことです。1人なら1分未満で終わります。

ゲート2は、コースのプロンプト1つでintentをspecに変えます。intentを読み、要件と設計のspecを作り、使えるスキルを適用する、というものです。ここで言うスキルとは、ブランド、セキュリティ、UXのポリシーを担うはずのスキルです。2分後には、約2,300語の手堅いspecができました。エンドポイント、データモデル、フィードの挙動、エッジケースが揃っています。プロンプトが求めるとおり、満たせなかった点もきちんと記録されていました。

ひねりは、モデル自身が書いた懸念事項にあります。「C0. 組織のスキルが存在しない。このspecはどのポリシーとも照合されていない。」このステージの前提は、ほとんどの環境に存在しないファイルを当てにしています。解説動画はこの前提条件を飛ばしますが、エージェントはそれを文章にしました。2つ目の指摘はもっとおとなしいものでした。未解決の質問のデフォルト値は、実装に入る前にプロダクト側の承認が要る、というものです。

レッスンは組み合わせについて厳格です(specとintentは一緒にコミットし、実装へ進む判断は人間が承認する)。さらに読むコストもあり、specあたりプロダクトオーナーの約12分がかかります。プレイブックは手戻りも追跡します。実装開始後の日付が付いたspecのコミットは、マイナスとして数えられます。ポリシーを整備済みのチームなら、このゲートがそのポリシーを実行する場所になります。1人の現場では、今の環境では守れない約束に対して支払っていることになります。

ゲート3はプランモードで、基準は厳しいですが役に立ちます。会話を一度も見ていないエンジニアが、プランだけから実装できること。プランモードは読む側の半分を自ら強制します。プランが承認されるまで、モデルはファイルを編集できません。私たちのプランは約4,000語、所要4分でした。変更されるファイル、作業の順序、リスク、確認方法が書かれ、specからの逸脱が3つラベル付きで記録されています。この逸脱は、後のレビューで再び登場します。

実装はループで回ります。失敗するテストを書き、通るようにし、対象は1つで、すべて緑でなければタスクは終わりません。ループは保護されています(コードを直すエージェントが、そのコードのチェックを弱めてはならない)。さらに検証役と組み合わされます。新しいコンテキストで行う2つ目のチェックで、コードを書いたセッションに左右されません。

実装の結果	値
エージェント時間	約9分、91ターン
コスト	約$2
変更	15ファイル、Mutesテーブル、エンドポイント2つ、両方のフィードでフィルタリング
テスト	5スイート、50テスト、独立した再実行ですべて緑
初回でのマージ	あり

注意点が1つあります。緑が証明するのは、ループに含まれているものだけで、それ以上ではありません。エンドツーエンドのテストは一度も実行していません。稼働中のサーバーとシードされたデータベースが必要だからです。古いモックに向けたループも、同じように緑に光ります。チーム規模では、worktreeでの並列セッションが加わります(上限は2〜3とされている)。こちらは検証していません。

デプロイのゲートは2層構造で、どちらも私たちに「ノー」と言いました。第1層は、リポジトリ直下に置いた文書化済みのポリシーに従ってdiffを読みます。パスは3つで、バグ、セキュリティ、specとプランに対するコンプライアンスです。「Important」は、壊れた挙動、データ漏えい、ポリシー違反のために取っておかれます。nitは最大5件で、残りは件数にまとめられます。ポリシー自身がノイズに上限を設けています。レビューは2分、$0.80で、実際のチェックも走らせました。テスト、ビルド、プランに記録されたベースラインに対するlint、9ファイルにわたるフォーマットです。判定は、Importantの指摘がゼロ、nitが6件(上限を1件超えた分は要約)でした。最後に、こちらが促していない一文で締めくくられていました。このエージェントは承認しない。承認は、ブランチ保護の裏にいる人間のコードオーナーが持つ。

第2層がゲートそのものです。デプロイを依頼すると、モデルは自分から拒否しました。機能が出荷用ブランチに入っていなかったからです。これは判断であって、強制ではありません。そこでマージしてもう一度頼むと、4行のシェルスクリプトが14秒で答えました。ブロック、リリース承認が必要です、と。終了コード2はツール呼び出しを止め、理由はモデルに戻ります。パイプライン側にも同じ処理を適用しました。壊れたビルドをヘッドレスで11秒、$0.13でトリアージし、ログを読み、原因を正確に特定し、ファイルには触れずに差分を提案しました。確定的な仕組みは、丁寧なお願いに勝ります。ただしhookはパターンの精度が全てで、私たちのhookが一致するのは1つのスクリプトだけでした。

同じバグ、同じ壊れた状態から出発して、道を2つ試しました。対照実験です。道1は、とにかく直す。道2は、intentから実装までのフルチェーンです。

	直接修正	フルチェーン	倍率
所要時間	2:13	11:31	×5.2
コスト	$0.70	$3.46	×4.9
ターン数	40	169	—
結果	スイート緑	スイート緑	同一

機械にかかる費用は、小さいほうの半分です。チェーンは、1行の修正のために約5,500語の成果物を書きました。1回見れば済むdiffに対し、人間が読むのに約27分かかる計算です。チェーンは、書く時間を読む時間に変換します。これがゲート税です。

プレイブックには、さらに継続的な課金が加わります。継続的なevalです。実際のタスク20〜50件を、設定を変えるたびに再実行します。各ケースは過去の実タスクで、プロンプトは当時のまま、変更前のコミットから実行し、確認可能な受け入れ基準を付けます。過去の履歴から5ケースを書くのに5分かかりました。ただ、正しく走らせるのはそう簡単ではありません。最初のハーネスは2ケースを間違ったコミットに向けてしまい、2つのエージェントは合格を偽装せずにそれを指摘しました。1ケース約1分とすると、スイート全体の実行にはエージェント時間で最大1時間かかり、本番のインシデントはすべて、恒久的な回帰evalとしてスイートに加わることになっています。規制の厳しいチームなら、その読む作業こそが成果物です。1人の現場では、単なるオーバーヘッドです。

6つのゲートのうち3つは、自分のコストを回収します。

ステージ	判定	根拠
計画	採用	40秒で、誰も聞かなかった質問が手に入る
実装	採用	プランモードとテストループで、緑のテスト50件を出荷
デプロイ	採用	実際のチェック付き$0.80のレビューと、14秒の確定的ブロック
設計	1人ならスキップ	整備していないポリシーの分まで請求される
テスト(継続的eval)	後回しでよい	1回の実行に最大1時間、狙いを外しやすい
保守	未証明	数週間分の本番テレメトリが必要

保守は、紙の上ではよくできています。確定的なスクリプトが管理帯を監視し、逸脱があれば新しいintentファイルが書かれます。ただ、それを証明するには私たちの手元にない本番テレメトリが要ります。Anthropic自身の文書は、あるアナリストの言葉を借りれば、どこにも計測が載っていません。ここにあるのは最初の数字で、限界も明白です。リポジトリ1つ、開発者1人、1日です。

外部のデータを見ると、圧力は現実のものです。Farosは1,200以上のチーム、1万人を超える開発者を追跡しました。導入率の高いチームはマージするプルリクエストが98%多く、レビュー時間は91%延び、平均的なプルリクエストの規模は2倍を超えています。最新のDORAレポートも同じ傾向で、AIによってスループットは上がり、安定性は下がっています。ボトルネックはレビューに移りつつあり、プレイブックはまさにそこを狙っています。コミュニティ版はすでに、チェーンを人間の判断2回にまで切り詰めています。1つはテンプレートとゲート台帳を提供し、もう1つは人間を設計とテストだけに置いています。元を取る3つのゲートを採用し、残りはチームが育ってから広げましょう。Anthropic自身の結びの一文が、最もふさわしい墓碑銘です。ループは回り続け、人間の判断はその上に立ち続ける。