こんにちは、AIニュースアプリ Morning AI 開発者の矢野哲平です。この記事では、仕様駆動開発（スペック駆動開発）というアプローチで、バイブコーディングの壁を超える方法について触れます。
AIを使った開発をする人が増えています。ここでいう開発は、iPhoneアプリを作るような開発もあれば、自分や自分のチームの業務を効率化するための小さな開発もあります。AIを使えば、これまでプログラミングをしたことがない人でも開発ができるようになりました。
ただ、AIにプログラミングをさせる場合、ゼロから動くものを作るのは簡単でも、そこから修正を加えていこうとすると途端に厳しくなります。ゼロイチは得意だけれど、そこから先の改良は苦手、というわけです。今回は、この課題を仕様駆動開発で克服する方法を紹介します。
この記事で解説するポイントは次の3つです。
- バイブコーディングの概要とデメリット
- その次におすすめしたい仕様駆動開発について
- 仕様駆動開発の具体的なアプローチ
バイブコーディングとは
まず、なぜ仕様駆動開発が注目されているのかを理解するために、バイブコーディングから説明します。
バイブコーディングは、簡単に言うとAIを使ったプログラミングの手法です。バイブス、つまり雰囲気やノリに身を任せてAIにプログラミングをしてもらいます。
これだけ聞くと「何を言っているんだ」と感じる人も多いと思います。私も最初に知ったときは正直そう思いました。もう少し説明すると、音声入力AIを使ってAIに話しかけ、作りたいものを伝えていくイメージです。「TODOアプリを作りたいです」と話しかけると、キーボードにほとんど触れることなく、音声の指示だけでTODOアプリができあがる。極端に言えば、ビール片手に話しかけるように指示していけば形になる、というわけです。
これは2026年に始まった話ではなく、すでに以前から実現していることです。バイブコーディングは2025年5月頃に登場し、ちょっとしたトレンドになりました。プログラミング経験のない人でも簡単に開発できるようになったことが、トレンドを後押ししたのだと思います。AIコーディングそのものの全体像については、AIコーディングエージェントとは？も参考になります。
バイブコーディングのデメリット
しばらくすると、こんな声も聞こえるようになりました。「とりあえず動くものは作れるけれど、そこから先の修正やバグ対応になると破綻することが多い」と。
つまり、ゼロイチのように動くものを作るのは向いているけれど、ブラッシュアップして改良していく運用になると厳しくなる、ということです。
原因はいろいろありますが、ひとえにコンテキスト不足だと思います。コンテキスト、つまりその開発における背景情報が足りていないのです。
仕様駆動開発とは
では、どうするか。それが仕様駆動開発です。
念のため補足すると、バイブコーディングが劣っていて仕様駆動開発が優れている、という話ではありません。ケースバイケースで使い分けるものだと捉えています。仕様駆動開発はバイブコーディングのデメリットを対策できますが、そのぶん手軽さは失われます。さっと動くものを作って検証したいときはバイブコーディングが今でも有効で、じっくり開発を進めたいときや、バイブコーディングで限界を感じたときに採用するのが仕様駆動開発です。
仕様駆動開発は、簡単に言うと仕様書を作り、その仕様書を最優先として開発を進めていくアプローチです。ここでいう仕様書とは、開発しているものの説明書のようなものです。どういったアプリを開発し、そのアプリにはどんな機能があるのか、といった情報を詳しく記載します。
両者の違いをざっくり言うと、こうなります。
- バイブコーディング: 仕様書を用意せず、その場その場の指示で開発を進める
- 仕様駆動開発: 仕様書を用意し、人もAIも仕様書を参照しながら開発を進める
これは日頃の仕事に置き換えるとイメージしやすいです。わざわざ文書化する必要のない小さなタスクは、パッとやるほうが早い。でも少し大きなプロジェクトになると、何をやるのかをしっかり文書化したほうが進めやすくなります。新しく配属されたスタッフに、プロジェクトの内容やルールを口頭だけで伝えるのはほぼ無理ですよね。「これを読めば全体が分かる」という資料があれば、仕事はずっと進めやすくなります。仕様駆動開発は、まさにこういうイメージです。
なぜ仕様書が必要なのか
ここで重要なのが、AIは常にゼロからスタートするという特性です。
たとえば、私が今日AIと一緒に何かを開発し、ある程度のところで作業を中断して、明日また再開するとします。私自身は「何を作っていて、次に何をすべきか」を頭の中で理解しています。でも、明日AIを起動すると、AIはゼロからのスタートになります。厳密には会話の途中から再開することもできますが、基本的にAIは、人間のように開発対象の情報を持ち越せません。つまりコンテキスト、背景情報が不足しているわけです。
しかも、人間側も完璧ではありません。来週再開する頃には忘れていることのほうが多いですし、開発するものが大きくなれば全体を把握するのは難しくなります。
こうしたケースに対応するために、仕様書をしっかり作成して、人もAIも参照できる情報源を作っておく。そして、その情報源を最優先に参照しながら開発を進める。これが仕様駆動開発の核です。
仕様駆動開発のやり方
では、具体的にどう進めるのか。アプローチはいろいろありますが、全体の流れはこうです。
- AIと相談しながら仕様書を作成する
- その仕様書をもとに開発計画を立てる
- 開発計画をもとにAIに実装してもらう
この時点ですでに動くものができるので、あとは必要に応じて修正やバグ対応をしていきます。このとき、機能を追加・削除したら、必ずその内容を仕様書に反映します。つまり、常に仕様書が正しく最新の状態になるように進めるのです。
これはけっこう面倒ですが、仕様書の情報が破綻すると全体がおかしな方向に進んでしまうので、常にチェックします。たとえばAIと新機能について壁打ちして、それを実装することになったら、「ここまで話した新機能を仕様書に反映してから実装してください」と指示します。こうして仕様書を常に最新に保ちます。
また、ある程度開発が進んだら、いったん手を止めて「現在のプログラムと仕様書を見比べて、齟齬がないか確認してください」と指示します。定期的に、仕様書と実装にズレが生じていないかをチェックするわけです。このチェックはAIに任せきりにせず、人間のチェックも必ず挟みます。プログラムを見て間違いを見つけるのは難しいですが、仕様書を見て間違いを見つけるのは比較的簡単です。
私自身は、仕様書をチェックするAIエージェントと、仕様書に反映するAIエージェントのように役割分担をして作業を進めています。こうした開発は普段使っているChatGPTやGeminiでもできますが、可能であればClaude CodeやCodex CLIのようなプログラムに特化したAIコーディングエージェントを使うと作業が楽になります。ChatGPTやGeminiの有料プランに加入していれば、それぞれCodex CLI、Gemini CLIをそのまま使えるので検討してみてください。
なお、いきなりiPhoneアプリを作って公開するのもいいですが、まずは自分が使うツールや、自分の業務を効率化するツールを作るのがおすすめです。私は最近、動画の無音部分を削除するツールや、ターミナルからGoogleタスクを操作できるツールを作りました。失敗してもバグが出ても誰にも迷惑がかからないので、まずは自分向けに作ってみるのが良いスタートです。
仕様駆動開発の課題
最後に、仕様駆動開発の課題にも触れておきます。仕様駆動開発を採用すればすべて解決するかというと、そうではありません。
確かにバイブコーディングに比べると開発のブレは少なくなります。バイブコーディングはその場の思いつきで指示を出すため、資料が残らず、AIも人間も迷子になりやすい。仕様駆動開発はその点を抑えられます。
ただ、まったく問題が起きないわけではありません。特に、開発するもののボリュームが大きくなったときです。私は基本的にspec.mdという仕様書を1枚作り、そこに情報を入れていくのが好きなのですが、作るものが大きくなると当然文字数も増えていきます。感覚的には、ある程度の分量を超えてくると、AIにとっても人間にとっても扱いが厳しくなってきます。
こういうときは、仕様書を分割します。デザイン関連の仕様書、データベース関連の仕様書、という具合に分けるのです。どう仕様書を管理し、いかに過不足なくAIに伝えるか。この設計が、けっこう悩みの種になってきます。
とはいえ、修正への対応や、規模の大きいものを作りたいときには向いているアプローチです。今まさにバイブコーディングで課題を感じている人は、一度この仕様駆動開発を試してみてはいかがでしょうか。
ちなみに、AIに仕様書から開発プランを作らせると、開発期間も見積もってくれます。面白いのは、その見積もりが従来の人間の開発手法をベースにしている点です。「フェーズ1から5まであって、合計で約1.5ヶ月くらい」と弾き出してくるのですが、いざ実装させると10分ほどで終わってしまう。AI自身も、AIを使った開発スタイルの見積もりはまだうまくできていないわけです。こういう事例を見ると、現時点であらゆるタスクの中で一番AIと相性がいいのは開発だな、と改めて感じます。
AIに任せきりにしない
最後に大事な点を一つ。AIがプログラムを書いてくれるなら、人間はもう知識を勉強しなくていいのかというと、私はそうは思いません。
私の失敗談を紹介します。AIと一緒に、マークダウンベースのタスク管理アプリを作っていました。いい感じにできたので欲を出して、iPhoneアプリでも使えるようにしたところ、情報の同期でつまずきました。パソコンで入力した情報がiPhoneに反映され、その逆も問題なく動く。簡単そうに思えたのですが、10回に1回くらいの割合で同期がうまくいかず、情報が上書きされてしまうケースが出てきたのです。
AIでとりあえず動くものは作れますが、こうした細かい部分の設計には、やはり専門的な知識や経験が必要だと改めて感じました。これは他のタスクにも言えることで、マーケティング知識ゼロの人がAIを使っても素晴らしい戦略がポンと出てくるわけではなく、深い知識と経験がある人のほうがAIをうまく使いこなせます。デザインも同じです。
そして、この仕様駆動開発の考え方は、開発以外のタスクにも応用できます。デザイナーがAIでプロジェクトを進めるなら、どんなデザインをやるのか、ブランドイメージやペルソナをドキュメントとして明記し、人もAIもいつでも参照できるようにしておく。AIは作業を再開するたびに知識がゼロに戻るので、途中からでもスムーズに全体を把握できるよう、ドキュメントを中心に設計するわけです。仕様書を最優先にこうした働き方を導入する例としては、Claude Coworkのようなデスクトップ型エージェントも相性が良いです。
まとめ
最後に、今回のポイントをまとめます。
- 仕様駆動開発は、仕様書を最優先とした開発手法です。人もAIも参照する仕様書をベースに開発を進めます。
- 機能の追加や修正など、すべての変更を常に仕様書に反映させます。
- バイブコーディングはサッとプロトタイプを作りたいときに、仕様駆動開発はじっくり腰を据えて開発したいときに。ケースバイケースで使い分けるのが良いと思います。
