# SDDで品質は上がるのか？〜SDDとバイブコーディングでの比較〜

こんにちは！技術改善Divに所属している中西です。今回はSDDとバイブコーディングの両方で開発をする機会があったので、それぞれの手法の違いについてまとめたいと思います。

背景：なぜSDDを試したのか
やってみたこと：同じ題材を2方式で実装
わかったこと①：動作確認のサイクルが減った
わかったこと②：仕様書の不備が、そのまま実装のバグになった
わかったこと③：仕様書のレビュー負荷が想像以上にあった
結局、SDDで品質は上がるのか？
おわりに

背景：なぜSDDを試したのか

当初、私が所属するチームではSDDを導入しておらず、AIを使用した開発はほとんどバイブコーディングによるものでした。

バイブコーディングは、AIに「こういうものを作って」と指示しながら、生成されたコードを少しずつ動かして仕上げていく開発スタイルです。スピード感があり、小さなツールや実験的なコードを書くには相性が良く、自然とこのスタイルが主流になっていました。

一方で、昨年末にはSDD（Spec-Driven Development）という開発手法を耳にする機会が増えてきました。SDDをざっくり言うと、「最初に仕様書を書き、その仕様をもとにAIにコードを生成させる」という、仕様を起点に開発を進めるアプローチです。

「試してみたい」「でも本当に効果があるのか？」そんな話がチーム内で出てきたタイミングで、今回SDDを試してみる機会がありました。

そこで気になったのは、次の問いでした。

SDDで品質は上がるのか？

今回はこの問いに対して、自分が実際に試して感じたことを書いていきたいと思います。

やってみたこと：同じ題材を2方式で実装

検証にあたって、まずはできるだけシンプルな題材を選ぶことにしました。今回題材にしたのは、自社で運用しているサービスに対する 疎通確認スクリプト です。

具体的には、CSVファイルに記載された対象エンドポイントごとに、オンプレ環境とクラウド環境それぞれの経路からHTTPリクエストを送り、レスポンスを確認するというものです。普段の業務ではシェルスクリプトでさっと書いてしまうレベルの、小さな運用ツールです。

「SDDって、もっと大きな機能向けじゃないの？」という声もあるかもしれません。ですが今回は最初の検証として、あえて「シェルスクリプトでも書けるくらい小さなもの」を選び、両方の手法を比較したいという狙いがありました。

比較の条件は以下のように揃えています。

同じ題材（疎通確認スクリプト）を、SDDとバイブコーディングそれぞれで実装する
実装言語はGoに統一
開発に使うAIエージェントも同じものを使用

こうして、同じものを2通りで作ってみる実験が始まりました。

わかったこと①：動作確認のサイクルが減った

まず一番に感じたのは、SDDの方が 動作確認のサイクルが少なくて済んだ ということです。

バイブコーディング側は、最初の動作確認までは早く到達できました。ところが、いざ動かしてみると想定外のエラーが連発します。今回の題材だと、SSHの多段接続でConnection timed outが繰り返し発生したり、認証周りで詰まったりとトラブルが続きました。結果として、「動かしてみる → 直す → また動かしてみる」というサイクルを何度も回す必要がありました。

一方でSDD側は、仕様書を先に詰めてから実装に入るため、実装中に「あれ、ここどうするんだっけ？」と迷う場面が少なく、手が止まりにくい感覚がありました。仕様で決めたことに沿って進められるため、バイブコーディングのときに発生していたような細かい試行錯誤の繰り返しは、大幅に減ったように感じます。

また、動作確認の仕方そのものにも違いがありました。バイブコーディングでは、実装が想定通りに動いているか確認するために、生成されたコードを読んで挙動を追う必要がある場面が多くありました。一方SDDでは、「仕様書に書いたとおりに動いているか？」という観点で自然言語ベースに照らし合わせて確認できる場面が多く、コードを目で追って挙動を確かめる際の認知負荷 が下がった印象です。

わかったこと②：仕様書の不備が、そのまま実装のバグになった

仕様書はちゃんと詰めたつもりでした。ところが、いざ実装させて動かしてみると、思っていた以上にバグが残っていたのです。原因を辿っていくと、仕様書そのものに穴があることが多くありました。

特に詰めが甘かったのは、SSHで踏み台サーバを経由する部分です。仕様書には「SSHで接続する」程度しか書いていなかったのですが、実際には踏み台を経由する多段の接続が必要で、認証情報の渡し方や接続順序など、もっと細かい手順まで踏み込んで書いておくべきでした。

これは、SDDというアプローチの本質を考えさせられる体験でした。SDDは「AIに仕様通りに作らせる」性質上、仕様書の不備はほぼそのまま実装のバグになります。逆に言えば、SDDで品質を上げたいのであれば、仕様書を書く力こそが問われるということです。

「SDDを使えば品質が上がる」というよりは、「SDDで品質を上げるには、仕様書を書く力が必要」。この感覚は、実際にやってみるまで持てていませんでした。

特に、SSHのような 機能の核 になる部分については、仕様書の段階で具体的な手順まで踏み込んで書いておくべきだった、というのが今回の大きな学びです。

わかったこと③：仕様書のレビュー負荷が想像以上にあった

もう1つ、想像していなかったコストがありました。それが、 仕様書のレビュー負荷 です。

SDDで開発を進めると、1つの機能に対して仕様書・計画書・データモデル・タスク一覧など、複数のマークダウンファイルが自動生成されます。今回試した小さな疎通確認スクリプトでも、関連ドキュメントは複数のファイルに及び、1つのファイルだけで数百行になることもありました。

つまり、コードのレビュー負荷が下がる代わりに、それなりの分量の 仕様書を読む作業 が新たに発生するということです。

これは、わかったこと①で書いた「自然言語で確認・レビューができる」というSDDの利点の、ちょうど裏返しのコストだと感じました。

1か所あたりの認知負荷は、確かにコードを読むより低い
ただし量が多いので、トータルの確認時間は決して小さくない

特にレビュアー視点で見ると、「何百行もの仕様書を、どこまで読み込めばよいのか」という新しい悩みも出てきます。

「SDD＝レビューが楽になる」という単純な話ではなさそう、というのが今のところの率直な感想です。

結局、SDDで品質は上がるのか？

ここまでの体験を踏まえて、最初に立てた問いに戻ります。

SDDで品質は上がるのか？

自分なりの今の答えはこうです。

品質が上がる側面は確かにある。ただし、SDDは「仕様書を書く力・読む力」が問われる手法である。

良かった点は、動作確認のサイクルが減ることと、仕様書が成果物として残ることです。仕様書があると、後から見返したり、レビューや認識合わせに使ったりできるメリットもあります。

一方で、仕様書の品質がそのまま実装の品質に直結するため、仕様を曖昧に書いていると結局バグまみれになります。また、生成される仕様書の量が多いので、レビューにかかる時間も決して小さくありません。

そう考えると、SDDが活用できそうな場面・バイブコーディングが向いていそうな場面が、自分の中で少し見えてきました。

一般的にも、SDDは中規模〜大規模なシステムや、長期的に保守するプロダクトに向いていると言われているようです。今回の体験を踏まえても、その整理にはおおむね納得感がありました。

ここまでの内容を整理すると、次のような対比になります。

観点	SDD	バイブコーディング
良さ	動作確認のサイクルが減る／仕様書が成果物として残る	スピード感があり、立ち上がりが早い
コスト	仕様書の品質が実装の品質に直結する／仕様書のレビュー負荷が大きい	エラー対応で試行錯誤の繰り返しが多い
向く場面	規模が大きく、長く保守する前提のコード／仕様をしっかり詰めてから実装に進めたい場面	小さく試したい、使い捨てに近いコード／動かしてから方向性を判断したい場面