仕様駆動開発で時間は減りません
縮んだのはバグの振れ幅です

「AIで速くなったはずなのに」と感じている方へ

開発チームにAIコーディング支援を入れて、実装は確かに速くなったのに、設計やレビューが重くなった気がする。仕様駆動開発を検討しているが、効果を数字で説明できない。発注側で、開発会社から「仕様駆動開発で速くなります」という提案を受けた。そのどれかに当たる方に向けて書いています。

仕様駆動開発を勧める記事でも、否定する記事でもありません。1チームが1年分のデータで確かめたら、速くなったのではなく、読めるようになっていたという話です。

仕様駆動開発とは

仕様駆動開発（SDD）とは、構造化した自然言語の仕様書を先に書いてレビューで確定させ、その仕様書を起点にAIへ実装させる開発の進め方です。設計そのものをPRとしてレビューし、マージしてから実装に入ります。

ラクスの楽楽精算モバイルアプリ開発チームは、2026年7月15日の同社イベントで、この進め方を導入してからの1年分のデータを公開しました（仕様駆動開発、導入半年。「本当に速くなってるの?」にデータで答える、ラクス技術広報による発表レポート、2026年8月7日）。

AIを使い始めてから、このチームには3つの問題が起きていました。

• 意図のよく分からないコードが混ざるようになった
• レビューの負荷に偏りが出るようになった
• テストフェーズになって初めて「考慮漏れ」に気づく事故が増えた

「速くはなったけれど、何か別のものを払っている感覚があった」。この違和感が出発点です。最初に試したのは設計書をAIに書かせる時短で、仕様駆動開発という言葉に出会ったのはその後でした。飛びついた後で、なぜ他のやり方ではなく仕様を中心に置くのかを整理しています。

実装は速くなり、判断が上流へ移りました

データを掘ることになったきっかけは、上司の「それは本当に速くなっているのか。設計に時間をかけている分、トータルでは遅くなっていないか」という問いと、メンバーの「設計フェーズが大変になった」という声でした。感覚で「速くなっています」と返しても説得力がないので、1年分を調べたと発表者は説明しています。

指標1 時間は移っただけで、総量は変わりません

実装フェーズの数字は確かに速くなっていましたが、その正体は意思決定の前倒しでした。複数ある実装方針のどれを採るかという判断は、以前は実装しながら決めることもありました。今は設計の時点で決めます。AIが選択肢を出してくれる分、考えるのが楽になった場面はありますが、最終的に人が決め、レビューと関係者の合意を取る必要がある点は変わりません。

上流（設計）が増え、下流（実装・テスト）が減り、合計は変わらない。仕様駆動開発は時短策ではない、というのが発表者の見立てです。

指標2 レビューの量は同じで、場所が変わりました

1つのPRに対する他者のコメント数は、中央値がずっと1で横ばいでした。レビューの総量は減っていません。変わったのは中身で、実装PRで「この仕様はどうなっているのか」と揉めることが減り、その議論が仕様レビューの場へ前倒しされました。楽になったのではなく、議論する場所が移った、と発表では整理されています。

指標3 バグは件数ではなく振れ幅が縮みました

バグの発生件数そのものは、劇的には変わっていません。変わったのは、1件の重さと、最悪のケースです。

対応時間は、着手からテスト完了までのリードタイムです。以前は1スプリントで20件を超える「バグの大爆発」が起きることがあり、それが最大でも8件程度に収まるようになりました。発表者が「これが大きい」と挙げたのは、この最大値の方です。なお、この集計はテストまで完了したスプリントのみが対象で、サンプル数は多くありません。発表者自身が、断定ではなく傾向として見てほしいと数字の限界を語っています。

買っていたのは、予測可能性でした

3つの指標を並べると、こうなります。

• 時間は、上流へ移っただけで総量は同じ
• レビューは、仕様レビューの場へ移っただけで総量は同じ
• バグは、件数が横ばいで、振れ幅だけが縮んだ

ここから発表者は「SDDの本当の成果は速さではない」と言い切っています。開発の速度は、AIを勢いで使っていた1年前とほとんど同じ。得られたのは予測可能性で、裏を返せば、勢いで速度を出していた頃に払っていたのが予測可能性だった、という整理です。

怖いのはバグ修正にかかる時間ではなく、何件出るか読めないことだ、というのが発表の中の具体例です。2週間スプリントの7日目まで予定どおり進み、残業もせず帰れていたとします。それでもテストでバグが大量に出れば、残り数日で焦って直すか、次のスプリントへ送るかの判断を迫られ、計画が崩れます。仕様の検討が上流に寄った結果、この予想外の大爆発が起きにくくなり、立てた計画が計画として機能するようになりました。平均は変わらなくても、最悪のケースが消えた、という変化です。事故で開発が止まらないことは、顧客に安定したペースで価値を届け続けられることでもあり、発表では予測可能性を、働きやすさの話ではなく顧客への価値提供の土台と位置づけていました。

発注側は、見積もりの何を読み替えるか

ここまでは内製チームの話ですが、発注側にも同じ構図が来ます。開発会社が「仕様駆動開発で速くなります」と提案してきたとき、このデータに照らすと、確認する点が変わります。

聞くべきは総額が下がるかではなく、速くなった分が見積もりのどこへ移ったかです。実装の工数が減った分、仕様の策定とレビューの工数が増えます。見積書の実装の行だけが薄くなって、設計の行が以前と同じなら、上流の増分はどこかに隠れています。速くなった分の行き先を契約でどう扱うかは、開発が速くなった分は誰のものかと実装が速くなった今 受託開発は何を売るのかで整理しています。

もうひとつは、仕様レビューに発注側の時間が要ることです。このチームでは、レビューを上流へ寄せた結果、仕様レビューの方が渋滞する新しいボトルネックが生まれました。受託開発で仕様駆動を採るなら、仕様を確定させる判断と合意は発注側に回ってきます。速くなった代わりに、決める人の時間が前倒しで必要になります。要件を決める人の負荷が減らない話は、要件定義をAIに任せてもと重なります。

残っている課題も公開されています

発表は美談で終わっていません。積み残しとして3つが挙げられています。

• 時間とレビューの総量は移っただけで減っていない。その総量をどう削るかは宿題のまま
• レビューを上流に寄せた結果、仕様レビューが新たに混む
• 固まった仕様からテスト作成を軽くし、AIに任せられる部分を増やす接続はこれから

対策として挙げられたのは、仕様書を作る前の、個人がローカルで仕様を練る工程です。メンバーの「設計フェーズが大変」の実体は、モブレビューではなくこの前段でした。ここに検証のループを当てて、機械的に拾える考慮漏れはモブレビューの前に潰す。ただし、モブレビューそのものは人を育てる場として残す。自動化するのは生成の負荷で、残すのは人の判断と育成、という線引きです。発表の最後は、予測可能性をこの先の自動化を安全に広げるための足場と位置づけていました。読めないものは任せられませんが、振れ幅が小さく読めるものなら任せられる。その範囲を広げていけば、いずれ総量も縮む、という順番です。

数字の出どころと限界

この記事の数字は、ラクス技術広報が2026年8月7日に公開した発表レポートと、同時に公開された発表資料に基づきます。対象は1チーム、エンジニア6名、テストまで完了したスプリントのみの集計で、発表者自身がサンプルは少なめだと注記しています。別のチームや、別の規模の組織で同じ結果になるとは限りません。

同じ会社の全社的な数字（工程単位で30〜50%の削減、コードの95%をAIが実装）は工程を50%削ってもにあります。全社の工程単位では削減、1チームの総量では横ばいという2つの数字は、測っている範囲が違います。公表される生産性の数字がどの範囲を測ったものかを読み分ける方法は、AI開発の生産性200倍は何を測った数字かを参照してください。レビューの中身が変わる話はAIが作ったコードを人がレビューする理由に、機械に渡すレビューと人が残すレビューの決め方はレビューの4割を機械に渡した会社がありますにあります。