【通算104｜要求AI 21】工程別に修正コストを測ったら、「文書を読み直すトークン数」がコスト爆発の正体だった
前回（通算103）、軽い技術スタックでも「要件を1つ足す方が、ゼロから全部作るより高い」という直観に反する結果が出た。但し「なぜ高いのか」は不明だった。今回、工程別にトークン数とコストを測り、原因を突き止める。
修正は、そのたびに"既にあるドキュメント"をLLMに読ませ直す。だから修正を重ねるほどトークン数が膨らむ。 これがコスト逆転の正体だった。
どの工程のコストとトークン数が高いかを調べたら、全ての工程で高かった。SDDの問題ではなく、LLMを使う上での常識を忘れていた。
今回もYWT（やったこと・わかったこと・次にやること）で、事実と解釈を分けて書く。途中の手順ミスも含めて正直に残す。
LLMには Claude を利用しているが、Codex でも同様と考えている。
やったこと
103の仮説を確かめるため、同じFR-016（接待交際費は金額にかかわらず経理承認を必須）を題材に、2つのテストを行った。
テストA（修正）：初回ビルド済みの軽量システムに、FR-016を後から追加。analyze → clarify → plan → converge → implement の各工程のあいだに /usage を挟み、工程別にコストとトークン数を測る。
テストB（作り直し）：FR-016を最初から含んだ仕様で、ゼロから構築（plan → tasks → implement）。狙いは仮説「コストの原因がトークン数なら、一気に作り直した方が安い」の検証。
環境は使い捨ての git ブランチで分け、/usage で消費トークン数を計測。
途中で失敗に気づく：
/speckit-clarify のつもりが /speckit-specify を打ってしまい $0.19 を無駄にした（すぐ中断、ファイルは無傷）。clarrify とタイプミスもした。
テストBの implement が、テストAの implement より時間がかかると途中で気づいたが、とりあえず最後まで走らせた（後述）。
わかったこと
implement は比較から外している
implement 工程は両テストで"やっていること"が違う：
テストB：59タスクの実装と実行。
テストA：9タスクのパッチを当てるだけ。
テストBの implement の実行時に ALL YES で走れせてしまった
テストAとテストB（implement 手前）工程毎のコスト、読み込みトークン、出力トークン、API時間
トークンは、渡すドキュメント量に比例する。
修正なので、渡すトークンが多くなる。
修正のための工程のトークンで増える。
二つの要因で、トークン増、コスト増が発生していた。
次にやること
トークンを減らすには、既知の対策を探す。
見落としや思考停止を起こさない工夫を行う。IDEとテキストベースだけで要件定義をするのは限界を感じるため。
タグ
#AIエージェント #SpecKit #スペック駆動開発 #要件定義 #要求定義 #ClaudeCode #システム開発 #トークン #SE #生成AI
