【通算101｜要求AI 18】Spec Kitを“要件定義の道具”に使えないか？——実装を完了したあとで、悩んだ末の仮説

2026年7月31日 21:13

前回、Spec Kitは経費申請システムを最後まで実装した。

108タスク、301のテスト、しかも実際に動く（通算100）。Kiroがクレジット切れで「実装前で終了」を、Spec Kitはやってのけた。——はずが、この続きを書こうとして、私は数日、考えた。きれいな結論から書くと嘘になるので、たどった順に書く。

承認が、だんだん面倒になってきた

実装中、Spec Kitは、都度、承認を求めてくる。「この設計でいいか」「このタスクを実行していいか」。最初は、内容を確認して、承認していた。だが途中で気づいた。仕様を書いたのはSpec Kit、それを実装するのもSpec Kitだ。 私が最初に要求を渡したあとは、仕様も設計もタスクも、ぜんぶSpec Kitが書いている。だから承認を求められても、私に言えることは「はい(Yes)」しかない。

だから途中でやめた。Shift+Tab を押して、確認を挟まず最後まで走らせた。そして、できたものを確かめたら——動くものが、できていた。

ネットでは、「ドキュメントの扱い」に様々な意見があった

並行して、私はSpec Kitの評価記事をリサーチした。昨年末あたりから、いろんなプロジェクトで試した評価がネットに増えている。評価の多くが一点に集まっているのに気づいた。Spec Kitが吐き出す大量のドキュメントを、どう扱うか。大きく以下の２点。

「ドキュメントは残さなくていい。最新のコードだけ見ればいい」
「ドキュメントとコードが食い違っているのはまずい」

意見は割れていた。SDDという考え方自体、出てきてまだ1年ほど。こなれていないのは当然だ。

ドキュメント量を調べたら、たしかに多い

Spec Kitが書いたドキュメント量を数えた。人が書いた要求＝仕様書は154行。そこからSpec Kitが起こした設計ドキュメント（調査・データモデル・API仕様など）は、2,600行超。コードとテストまで合わせると、1万行超。全体で、およそ1万5千行。

そして——もっと詳しい要件を足せば、この量はさらに増える。 それは、数えるまでもなく分かった。

このドキュメントの膨張を扱わないと、この記事を書く意味がない。

数日間、考えたが、どっちも正しい

要件定義の本を引っぱり出して読んだり、自分の過去の経験を振り返ったり、過去に書いたnote記事を読み返したりした。それでも答えが見えない。2〜3日、放っておいた。

note記事のタイトルを見て、気づいた

「要件AI」の現状を検証したいたはずが、実装の議論で悩んでいる！

そのままコード使うのか？

Spec Kitは、まだ完成度の高いツールではない。そのツールが書いたドキュメントを「どう保存し、どう整合を保つか」に何日もかけて悩むこと自体、的外れだった。本当の問いは——そもそも、Spec Kitが実装したコードを、そのまま使うのか？

気づいたのは、ドキュメントの問題は、Spec Kitを「今の開発のやり方」にそのまま持ち込もうとするから。出てきたコードもドキュメントも「納品する成果物」だと思うから、「全部レビューするのか、保存するのか」の議論になる。

動くプロトタイプと割り切れば、利用方法が変わるのでは？

では、実装をプロトタイプ＝検証のためのツールと割り切ったら、どうか。

自分も要件定義の工程で、UIのモックやプロトタイプを使っていた。早いうちに動くものを見せると、相手から要件が引き出せる。「あ、これだとこの場合が困る」が、実物を前にすると出てくる。頭の中の議論では出てこない。これは経験上、確信がある。

Spec Kitの実装を、要件を引き出すためのツールとみなす。すると、ドキュメントを保存するかどうかの議論は、意味がない。

“development”に、引きずられていた

たぶん、SDD＝Spec-Driven Development の「開発」という言葉に引きずられていた。だから、出てきた実装を「作った本体」として扱おうとしていた。

だが、これを要件定義の工程で、要件を確かめるためのツールと考える。AIを使って、安く・速く動くものを作り、動かして、要件の漏れや間違いを見つける。50点の要件定義でとりあえず作って動かし、直して60点、また直して……と、要件の“質”を段階的に上げていく。 実装は、要件を固めるための叩き台だ。

ただし、これは悩んだ末の“仮説”

はじめから「Spec Kitは要件定義のツール」と考えていたわけではない。当初の目的は「Kiroでできなかった実装を、作り切れるか」の確認だった。その後、ドキュメントの山を前に数日悩み、行き詰まり、要件定義の原点に戻って、ようやくここに辿り着いた。だから、今のところの仮説だ。

しかも、肝心の「作って→直して→要件を詰めていく」の後半は、まだ試していない。一度できた実装に要件を足したら、どのくらいの速さと安さで作り直せるのか。思ったのと違えば、元に戻せるのか。そこは、次に自分で確かめる。

今日のまとめ

当初の目的は「Kiroでできなかった実装を、Spec Kitで作り切れるか」だった。それは果たせた（通算100）
仕様も実装も同じAIが書くので、途中の承認は「はい(YES)」しか返せない。Shift+Tabで確認を省いて走らせても、動くものはできた
ネットの議論はSpec Kitの「大量のドキュメントをどう扱うか」だった。実際に数えると、仕様書154行→設計ドキュメント2,600行超、全体で約1万5千行。要件を足せばさらに増える
数日悩んだ末に、note記事タイトルで間違いに気づいた。
実装コードをそのままは使わない、ネットの議論に引きずられていた
実装をプロトタイプ＝要件を引き出す道具と割り切れる、
安く速く動くものを作り、50点→60点と要件の質を上げる——これが今の仮説
未検証：要件を足して作り直す速さ・コスト、バージョン管理。次に自分で確かめる