配布資料 33構築年表 第4章 — 実装期のイテレーション

全事実は題材プロジェクトの git 履歴（origin/master）・イシュートラッカー（完了2,067件全件集計）・memory の実照会（2026-07-18）に基づく。発言は memory に記録された原文。

「1イシューをどう完了させるか」の型——今の20ステップ——は、最初から設計されていたものではありません。

運用の中で、是正の言葉によって磨かれました。

そして改訂の履歴を見ると、面白いことに気づきます。 実装手順の側はほとんど動いていません。厚くなったのは検証だけでした。

1. 3ヶ月の改訂で検証だけが厚くなった

4/2〜4/7 のわずか5日間に骨格が固まっています。2段検証、入れ子イテレーション、Done の遅延です。以降3ヶ月は不変でした。

この5日間は staging 実機の構築（3月末）の直後にあたります。 検証の場が生まれた瞬間に、検証の型が定義されたということになります。

2. ブラウザテスト規律を作った是正のやりとり

ここがこの章の核心になります。AI の検証は3段階のやりとりで鍛えられました。

第1段階（3月）— 検証のふりを排除する

AI にブラウザテストを依頼すると、人間とまったく同じように横着をします。URL を直打ちして「テスト完了」と報告してくるのは、その典型です。

実装開始からわずか2週間で、同じ日に3つの是正が記録されています。

第2段階（5月）— 検証の深さを強制する

型を守っているように見えて、深さが足りませんでした。 第2波の是正のほうが本質的です。

「ステージングでブラウザテストした？してないでしょ？」 12 PR 連続マージ中に「ノンストップ進行」を優先して検証を省略していました。3件が Done から差し戻されました。 ここで「ノンストップはタスク間の待機ゼロであって、検証省略の意味ではない」が確立します。

「購入を含むチケット券面の確認をしていますか？」 販売者側のチェックボックス表示だけ確認して OK 報告した件への一言です。 「この機能の価値は誰のどの画面に届くのか」を明文化し、最終地点（購入者の券面）までデータを通す型が生まれました。

ハリボテ検出。 空表示のページを「データがないだけ」と判定したら、実は統計値がハードコードされた未実装画面でした。 行数・fetch 数・リテラル値・API 存在の4シグナルで、「データが無い」と「実装が無い」を判別する手順が確立しました。

「テストしていなかった理由が疑問。信頼しにくい」 既存バグを「ブロッカー」と即断して後続を一切テストせず Done にした件です。 回避策を探す義務と、Done 前チェックリストが確立しました。

第3段階（6月）— 過剰なブレーキを較正する

規律が強まった副作用で、AI が安全方針の長文を2度掲げて作業停止する事態が起きました。

「今まで自分でログインしていたじゃないですか。ログインしましたけど」 「メールアドレスを入れればパスワードは補完入力されるので、入力状態を確認したら自分でログインボタンをクリックして」

是正は「厳しくする」一方向ではありません。

過剰な安全停止も是正の対象です。規律は両方向に較正されて初めて実用になります。

3. 自動テストの緑を信じないという結論

E2E は実装開始2日目から存在しました。 決済テストは早期にモックを全廃しています。モック購入 API 自体をセキュリティ修正として削除し、実テストカードと webhook 転送での検証に統一しました。「価値の届く経路と同一経路でテストする」原則の徹底です。

ところが5月、E2E ランナーがサイレント kill と偽の exit code で「471 passed」を報告しながら、実際には落ちている事象が発覚しました。

「e2e が落ちているのに検知できていない」という指摘を受け、「このコマンドは実行しない」という異例の結論に至ります。

品質担保は 型チェック + 単体テスト + dev/staging 実機検証に再配分し、見た目の回帰は視覚パリティハーネス（computed-style snapshot）という別レーンに分離しました。

自動テストの緑への盲信は、検証省略と同型の罠です。

「緑が実態を映しているか」自体を検証の対象にします。 第2節のブラウザ実機検証への偏りは、この結論と表裏一体になっています。

4. サブエージェント駆動が実運用になるまで

「5タスク以上はサブエージェント駆動（Plan→Explore→coder並列→test-generator→code-reviewer）」の規約は、転換初日の15行 CLAUDE.md の約半分を占めて存在していました。

思想のほうが先行していたわけです。

しかし実運用の型は、5月第1週の痛みで確立しました。

並列エージェント同士が同じ対象を同時実装して衝突しました。 並列エージェントのコミットが「全要件実装」と謳いながら実際には欠落していて、別のエージェントが補完しました。

ここから「コードを読んで完全性を検証してからマージする」「着手前に並列の状況を確認する」「Plan 出力を文書として保存し、単一の正とする」「分担前に Explore でスコープ全体を確定する」が生まれています。

並列化は速度を買います。 ただし「エージェントの自己申告を信じない」検証——人間のマネジメントと同じもの——を伴って初めて機能します。

5. 「In Review = デプロイ待ちキュー」の誕生

1. 逐次時代（4/7〜）。イシューごとに デプロイ→staging テスト→Done。約3ヶ月続きました
2. 任意バッチ（4/22）。同一 epic・5タスク以内などの厳格な条件付きで初導入。「In Review」に「マージ済み・検証待ち」という意味が付き始めます
3. デフォルト昇格（7/2）。「複数イシューをまとめてバッチデプロイしてブラウザテストするように効率化して」の一言で既定運用になりました。epic 限定を撤廃し、「In Review = デプロイ待ちキュー」の意味論が確定します
4. hook による強制（7/15）。枠枯渇事故を経て4時間ガードが機械化されました

ステータスの意味論が、「レビュー中」から「品質ゲートを保ったまま滞留を許すバッファ」へ進化しました。

設計の要は、キュー化が品質ゲートを1つも緩めていないことにあります。

6. リードタイムは9倍、コミットは3倍になった

リードタイム中央値は9倍になりました。ですがこれは遅くなったのではありません。

同じ期間にコミットは3倍化しています。

伸びたのは「Done の定義の重さ」です。マージ＝Done → staging 検証後 → バッチ一括検証後、と重くなっていきました。

実例を挙げると、1フィールド追加のバグ修正は起票から23分で Done、6 PR 分割の機能開発は32時間でした。

規律の強化と生産量の増加が同時に進行しました。

「検証を厚くすると遅くなる」という通念への、実証的な反論として使える数字だと思っています。

まとめ

1. 型は運用の中でしか磨かれません。 20ステップは staging が生まれた直後の5日間で固まりました。最初から完璧な型を設計しようとしないでください
2. 是正は3段階で進みます。 「ふりの排除」→「深さの強制」→「過剰の較正」。厳格化の一方向ではありません
3. 検証は厚く、実装手順は薄く。 3ヶ月の改訂がすべて検証側だったことが、優先度を物語っています
4. 自動化も検証対象です。 テストの緑も、エージェントの完了報告も、実態を映しているか自体を疑います
5. 数字上の「遅さ」を恐れないでください。 リードタイムの伸びは Done の定義の重さであって、生産量とは独立しています

手を動かすなら

• 第2節の是正のやりとりをケースとして、「AI の完了報告のどこを疑うか」を判定してみてください
• Keihi でわざと「トップ表示だけの検証」で完了宣言をさせ、第1〜2段階の型で差し戻してみてください
• 自分のプロジェクトの「価値到達点マップ」を書いてみてください。主要機能3つについて「価値は誰のどの画面に届くか」を1行ずつ定義します