【通算102｜要求AI 19】完成したシステムに、要件を1つ追加——追加要件だけのテストができず、コストもかかった

2026年8月1日 21:47

前回（通算101）、仮説を立てた。
Spec Kitを“要件定義の道具”に使えないか？

今回、それを実際にやってみた。完成済みの経費申請システムに、要件を1つ足す。やったこと・わかったこと・次にやること、の順で書く。
これは、過去記事で紹介した技術KIのYWT(やったこと・わかったこと・次にやることの頭文字)でシンプルに伝える方法。

やったこと

題材は前回まで（通算100）で作った経費システム——108タスク、301テスト、実際に動く。——これに、こういう要件を1つ足した。

接待交際費は、金額にかかわらず経理の承認を必須にする（5万円未満でも上長承認だけでは完了させない）。

追加した要件

手順は以下のとおり。

gitでベースラインを固定。「301テスト全通過の完成状態」をコミットしておき、別ブランチで要件を追加して実行。失敗しても、元に戻せるようにしてから始めた。
Spec Kitの工程を順に回す：analyze（整合チェック）→ clarify（曖昧さ潰し）→ plan（設計）→ tasks（タスク化）→ implement（実装）。
開始と終了で /cost で、金額・トークン・時間を測った。

わかったこと

(1) 仮説通りに追加要件で再構築

「specに1行足して plan→tasks を回す」をやってみた。すると——未着手タスク0、コード変更0。既存のタスクが全部「完了済み」と判断された。新しい要件が拾われないまま、終了。

ところが、/speckit-analyze（成果物どうしの整合チェック）が、それを最重要（CRITICAL）で検出した。「仕様は16要件になっているのに、実装は未対応」と。

さらに /speckit-clarify が、私の曖昧な1行ついて確認してきた。「その費目はどう識別する？」「再提出で費目を変えたら、判定はどうする？」——そして、私が気づいていなかった点を見つけた。

会議費で出して差し戻し → 接待交際費に変えて再提出 → 上長承認だけで完了

要件の漏れ

これが通ってしまうと、「接待交際費は必ず経理」というルールではなくなる。このミスを、コードを書く前の、要件の段階で指摘してきた。

Spec Kitは、実装する前に、要件の曖昧さと漏れを見つけるツールとして働いた。 仮説は、確かめられた。

Spec Kitの指摘に回答後、planが設計を更新し、tasksが差分20タスクを足し、implementが実装した。テストは301本 → 331本、すべて緑（この331本は、私自身の環境でも回し直して一致を確認した）。

(2) しかし、思ったより時間とコストが高い

Claude Opus 5 ベースで算出。

コスト：約$31（従量API換算での金額）
時間：約34分、そのうち実装だけで約28分

引っかかったのは、要件はたった1つなのに、実装フェーズ（28分）は、初回の全108タスクの実装（45分）の、およそ6割。 15要件を作った初回に対して、1要件の追加が、1/15ではなく6割。「これだけ？」の変更が、初回並みにかかった。

(3) 影響範囲だけのテストではなかった

「implementが結局、全部作り直すからでは？」と最初は思った。だが、成果物を見るとそうではない。実行されたのは新規20タスクだけ（既存108はスキップ）。変更は影響箇所（判定関数と、その呼び出し3か所、API、該当テスト）に集中し、33ファイル・正味900行あまり。6,800行を書き直したわけではない。コードは、狙い撃ちの差分だった。

コストの正体は、テストが「影響範囲だけ」に絞れなかったこと。1行の変更を確かめるのに、影響のない大半まで含めて331本のテスト一式が走る。特にE2E（実ブラウザ）は1回で3.7分。書いて・走らせて・直す、たびに、毎回全部。だから、変更は差分でも、テストは初回と同じ全体分かかった。

これは、要件定義の"あるある"でもある。要件が途中で変わったとき、それが既にあるコードやテストにどこまで及ぶかは、読みにくい。 その影響範囲を調べること自体に、コストがかかる。今回、Spec Kitの analyze と plan は影響範囲を予想できていた——影響は「どこに及ぶか」は示せた。それでも、テストはその範囲に絞られず、全体を実施。

もうひとつ、経験的に大きいのがデータベースだ。今回の変更は、費目マスタに列を1つ足すマイグレーションを含んでいた。DBが絡むと、実DBを立て（Docker）、マイグレーションを流し、統合テストとE2Eを回す——影響範囲が一気に広がる。変更がDBに触れるか触れないかで、コストは大きく変わる。

つまりコストの理由は、「全部作り直すから」ではない。「変更は小さくても、テストと技術スタック（Typescript,Docker,DBなど）が、重いから」だ。

次にやること

1. 要件定義のフェーズは、"軽い実装"に替える。 前回、Spec Kitの出力を「要件を引き出すためのプロトタイプ」と割り切ったので、重い技術スタックで作る必要はない。