仕様駆動開発の機械検査を、決定的に動くCLIへ切り出してみた

「仕様駆動開発」というアプローチがある。実装を始める前に、要件定義書、設計書、実装計画を人間が固めて、それを根拠にエージェント AI に開発を任せるやり方だ。AWS の Kiro という AI IDE がこれを広めたが、ツールの実装上は「計画書の形式が整っているか」と「内容が妥当か」を分けて扱う工夫が不足していた。SpecBind というツールは、この問題を「機械的なチェックを CLI に切り出す」ことで解決した。形式は自動化し、内容は人間の承認に結び付ける。エージェントが計画を飛ばして突っ走れないよう、検査か状態遷移のどこかで止まる仕組みになっている。

新しいのは、仕様書の使い方だ。一般的には「計画書は使い捨て、リリースしたら片付ける」と考えるが、SpecBind では Requirements、Design、Contract は永続的に保持される。次の変更では、それを「現在の姿」として更新する。このため、差分ではなく「今どうなっているか」を丸ごと書く必要がある。さらに承認は単なるハンコではなく、「この時点でのこの入力に対する承認」として記録される。上流の仕様が変われば、下流の承認は自動的に無効化される。形式だけ整った意味不明な仕様書も、意図を隠した中身だけの実装も、仕組みで防ぐ。

中小企業が AI エージェントに開発を任せるなら、「作ってから見る」という危険な発想は捨てるべきだ。計画書を先に固定し、その計画が実装に反映されたかを自動チェックし、ズレを見つけたら実装ではなく計画の指示を直す。この順番を仕込みで強制することが、使えるものを作らせるコツになる。