はじめに
AIがコードを書くこと自体は、もう珍しくなくなりました。
Cursor や Claude Code を使えば、実装速度が上がる。PR が短時間で作られる。ここだけを見ても、2026年ではそれほど新しい話ではありません。
今回気になったのは、その先でした。
実装が速くなるほど、lint、test、SIT、build、survey、review、修正、再実行といった検証側の重さが目立つようになりました。
「AIにどれだけ速くコードを書かせられるか」ではなく、
どの時点で、どの粒度の検証を、誰に実行させれば、最終成果物を安全に clean にできるのか
こっちの方が次のボトルネックなのではないか。
Human-on-Exception を実際に回してみたところ、この疑問がかなり具体的になりました。
今回やったこと
対象は家計簿アプリの開発です。
前回の記事のスクリーンショット通り、Issueを作成し、
Human-on-Exception の実装 Prompt を Issue ごとに新しい Cursor context window から実行しました。
今回、通常フローに対して加えた例外は1つだけです。
- 実装者AI自身の自己レビューはスキップしてよい
- make による機械検証は残す
- PR 作成後に @codex review で独立レビューを依頼する
狙いは、自己レビューだけを局所的に外しても、AIがそれを「検証全部を省略してよい」と拡大解釈しないかを見ることでした。
結果として、各 PR では make lint、make test、make smoke が実行され、PR 作成後には Codex の独立レビューも走りました。
つまり今回の範囲では、
既存ルール + 局所例外
として指示を合成できました。
自己レビューを外したからといって、機械検証や独立レビューまで勝手に消えることはありませんでした。
実装速度はかなり出た。でも、そこは今回の主題ではない
新規実装された主な PR は3本でした。
| PR | 規模 | 作成時刻 |
|---|---|---|
| #9 | 27 files / +2,576 / -12 | 14:44 |
| #10 | 31 files / +2,147 / -21 | 14:57 |
| #11 | 33 files / +1,535 / -17 | 15:07 |
3本合計で 91 changed files / +6,258 / -50。
DB、backend、frontend、system / contract tests、4点セット docs、Pack をまたぐ縦切りの実装が、10〜13分程度の間隔で PR になりました。
もちろん、行数や PR 本数は価値の尺度ではありません。
むしろ今回重要だったのは、実装が速くなったことで、その後ろにある検証工程のコストが相対的に目立ち始めたことです。
Total Tokens 36.4M。でも95.2%は Cache Read だった
Cursor の usage export を集計すると、Total Tokens が記録された13 run の合計は次の通りでした。
| 区分 | Tokens | Total 比 |
|---|---|---|
| Total | 36,407,858 | 100% |
| Cache Read | 34,657,280 | 95.2% |
| Fresh Input | 1,495,764 | 4.1% |
| Output | 254,814 | 0.7% |
最初に Total Tokens だけ見ると「3600万 token も使ったのか」と見えます。
ただ、実際には 95.2% が Cache Read でした。
なので Total Tokens の巨大さを、そのまま「毎回それだけ新規に読ませた」と解釈するのは雑です。
一方で、Cache Read もゼロコストではありません。
長い Agent trajectory の後半で大きくなった context を何度も再利用すると、各 turn で cache read が積み上がります。
今回の Cursor credit 消費は、残高推移からおよそ $28程度と推定しています。
1つのAgentに全部やらせると、後半が重くなる？
現在の実装フローは大まかにこうです。
Issue / Rules → design → implementation → tests作成 → full make → failure修正 → PR → independent review
安全側ではあります。
ただし、実装後に full test や survey を走らせ、長いログを読み、失敗を修正し、もう一度実行する。
これを同じ Agent context で続けると、後半の turn ほど大きな context を抱え続けることになります。
そこで次に考えているのが、verification を
実行主体 × タイミング × 粒度
の3軸に分けることです。
「誰がテストするか」だけではなく、
- いつ検証するのか
- どの範囲を検証するのか
- どの revision の証拠なのか
を分離して考えます。
子Issueは局所、最終統合headで強く検証する
候補は、子 Issue と final integration を二層に分ける形です。
child
implement → local verification → child PR → independent review → provisional integration → context終了
final integration
latest integrated head → full SIT → full make / build / smoke → docs / survey → cross-Flow regression → independent review → fix / re-verify → clean になるまで収束
重要なのは、子 Issue で verification をゼロにすることではありません。
子では、その変更の AC を直接証明する局所的な evidence に寄せる。
一方で repo-wide な検証や、複数 child を統合したときにしか見えない不整合は、latest integrated head で強く確認する。
という考え方です。
「子PRがclean」と「最終成果物がclean」は別
子 PR が全部 green でも、統合後に問題が出ることは普通にあります。
- ancestor branch の修正が descendant に影響する
- 複数 child を統合したときだけ API / schema / migration / transaction の不整合が出る
- docs / route / test evidence の整合が崩れる
- child の検証証拠は、その時点の head に対する証拠でしかない
- integration merge 後に初めて CI が落ちる
つまり、
child が individually clean でも、latest integrated head が clean とは限らない
ということです。
そのため最終的な correctness は、PR1本ごとではなく最終的に統合された revisionに対して成立している必要があります。
次に比較したい3方式
次は少なくとも3方式を比較したいと考えています。
| 方式 | Child | Integrated head |
|---|---|---|
| A: 現行 | full required verification + review | integration verification |
| B: targeted | lint / static / unit / integration / affected SIT + review | full SIT / full make / survey + review |
| C: Epic-only SIT | unit / integration + SIT artifact 作成 + review | 初回 SIT execution + full verification + review |
現時点の第一候補は B です。
局所的な欠陥は child で早く拾いながら、repo-wide verification は integrated head に集約します。
C の方が token や wall-clock を減らせる可能性はあります。
ただし DB、auth、transaction、cross-boundary defect の発見が遅くなる可能性もあります。
ここは「思想的にどっちが正しいか」ではなく、A/B で測る予定です。
AI開発を「1PRいくら」で測るのをやめたい
AI開発では、
- 何分でPRを作れたか
- 1時間に何本PRを出せたか
- 何行生成したか
- 1 Issue 何ドルだったか
といった数字に目が行きやすいです。
でも今回、この測り方だと評価単位を間違える可能性があると思いました。
PR を高速に作れても、その後に統合テスト、レビュー、fix、re-review、re-verify が大量に発生するなら、そこまで含めないと開発コストとは言えません。
今回から比較単位を、
latest integrated head が full verification を通過し、独立レビューの valid / unclassified finding が残らず、merge 可能になるまでの総 token / cost / latency
に置きたいと考えています。
つまり、AI開発の unit economics を PR生成単価ではなく、clean integrated outcome までの総額で見るということです。
reviewer に全部投げればいいわけでもなかった
検証工程を分ければ全部解決、というわけでもありません。
実際、Codex 側の修正タスクでは Docker CLI が存在せず、make lint / make test / make smoke を完走できないケースがありました。
そのため、
「実装者が検証しなくていい。reviewer が全部やればいい」
ともまだ言えません。
reviewer の実行環境が required commands を満たさないなら、CI を deterministic verification authority にする方が自然かもしれません。
誰に担当させるかより、
どの環境で、どの revision に対して、どの evidence を成立させるか
の方が重要そうです。
今のところの結論
今回確認できた範囲では、AIに実装を任せること自体より、その後の verification architecture の方が面白い問題になってきました。
速くコードを書けるようになると、
「人間が最後に全部見る」
だけでなく、
「各PRで毎回すべての検証を回す」
という設計も、本当に最適なのかを考える必要が出てきます。
ただし、検証を弱くすればよいという話でもありません。
目標は verification を減らすことではなく、
局所では局所の evidence を取り、最終 integrated head では強い evidence を成立させる
ことです。
次は A / B / C を実際に比較し、
- total token / cost
- elapsed time
- defect discovery timing
- review finding 数と severity
- fix / re-verify 周回数
- regression / missed defect
を測ります。
AIがコードを書くのが当たり前になった後、
開発速度を決めるのは、コード生成能力より verification の設計かもしれない。
まだ仮説です。
なので、次も測ります。