「だいたいこんな感じで」——その一言でAIに実装を始めさせたこと、心当たりはないだろうか。
#1では見積もりの数字を、#2ではプロセスの向きを扱った。#4では、できあがったコードをどう検品するかを扱う予定だ。だが検品は、あくまで対症療法である。この記事では、その手前——コードが書かれる前の「予防」の話をする。
AI駆動開発における「仕様の曖昧さ」がなぜ手戻りを生むのか、そして仕様駆動開発（Spec-Driven Development）という考え方が何を変えるのかがわかります。
2025年2月、Andrej Karpathy氏がX（旧Twitter）で「vibe coding（バイブコーディング）」という言葉を提唱した。コードの中身を細かく意識せず、思いついたことをそのままAIに伝えて実装させる——というスタイルだ。プロトタイプや個人開発には強力な武器だが、この進め方をチーム開発や本番システムにそのまま持ち込むと、危うさが表面化する。
問題は、バイブコーディングという手法そのものではない。曖昧な指示のまま、複数人が関わる開発に持ち込んでしまうことだ。「だいたいこんな感じ」という指示は、指示した本人の頭の中では明確でも、AIやチームメンバーにとっては複数の解釈が可能な、穴だらけの情報でしかない。
人間同士なら、曖昧な指示があっても会話の中で自然に確認し合い、認識のズレを埋めていく。だが、AIコーディングエージェントは基本的に、曖昧な指示を渡されても「なんとかそれらしい形」で実装を確定させてしまう。人間のように「これはAとBどちらの意味ですか」と、毎回律儀に聞き返してくれるとは限らない。
この点を裏付けるデータがある。2026年に発表された研究では、意図的に曖昧さを含む1,304件の関数レベルのコーディング課題を使い、複数のLLMの挙動を検証した。その結果、GPT-4を含む最先端モデルでも、要件が曖昧な場合は明確な場合に比べて性能が30%以上低下することが確認された。さらに、同じ曖昧な指示に対して、モデルが毎回異なる実装（例えば「しきい値以上を残す」と「しきい値以下を残す」という正反対の解釈）を生成してしまうケースも報告されている。
厄介なのは、AIが生成したコードは一見「動いている」ように見えてしまう点だ。曖昧さがそのまま実装され、意図とズレた挙動として本番環境まで残ってしまうことがある。
つまり、曖昧な仕様は、レビューで発見されるまで気づかれない「静かな地雷」として、コードの中に埋め込まれる。
この課題に対する一つの答えとして、2025年後半から急速に広がっているのが「仕様駆動開発（Spec-Driven Development、SDD）」という考え方だ。
従来の開発では、コードこそが正であり、仕様書はコーディングが始まると次第に参照されなくなる「形式的な書類」になりがちだった。仕様駆動開発では、この関係を逆転させる。仕様書を開発の中心（Single Source of Truth）に据え、AIコーディングエージェントはその仕様を理解したうえで、具体的なコードに落とし込む役割を担う。
この考え方を体現するツールも、すでに実用段階に入っている。2025年7月にAWSが公開したAI IDE「Kiro」は、要件定義・設計・タスク分割を経てから実装に進むワークフローを組み込んで登場し、同年11月に一般提供が始まった。同年9月には、GitHubが「Spec Kit」というオープンソースのツールキットを公開し、公開から1週間でGitHub上のスター数が16,000を超えるなど、大きな反響を呼んだ。
ソフトウェア開発の技術動向を分析するThoughtworks社のTechnology Radar（2026年版）でも、仕様駆動開発は「Assess（試す価値がある段階）」の技術として取り上げられている。同社は、用語の定義がまだ流動的であることや、成熟したエンジニアリング手法として定着しているのか、単なる呼び方の違いにすぎないのかを見極める難しさにも言及しており、過度な期待は禁物としつつも、注目すべき動きであることは間違いない。
#2で紹介したAWSの「AI-DLC」も、この文脈で捉え直すことができる。「AIが提案し、人間が承認する（AI proposes, human approves）」という原則は、実装の場面だけでなく、要件定義や設計の段階にこそ強く当てはまる。
曖昧さを実装の手前で潰してから、AIに任せる。
曖昧さが実装まで持ち越され、後から発覚する。
承認ゲートを実装の「後」に置くか「前」に置くかで、見つかる問題の種類が変わる。実装後に置けば、#4で扱うような「検品」の話になる。実装前に置けば、そもそも問題が生まれること自体を防げる。どちらも必要だが、順番を間違えると、防げたはずの手戻りをレビューで拾う羽目になる。
仕様駆動開発を導入しているかどうかより、発注する側が確認すべきなのは、次のような具体的な運用実態だ。
実装が進んだ後、最初の仕様書が放置されていないか。仕様と実装がズレたまま進んでいないかを確認する。
「なんとなく」で通っている要件がないか、AIに実装させる前に人が曖昧さを潰す工程があるかを確認する。
承認・レビューが実装後の検品だけに偏っていないか。要件・設計段階での承認ステップの有無を確認する。
仕様駆動開発は万能薬ではない。仕様書自体が肥大化し、どれが「正」なのか分からなくなるという新たな課題も報告されている。だが、「実装してから直す」より「実装する前に固める」方が、手戻りの総コストは小さくなる、という発想の方向性自体は理にかなっている。
この記事で見た「予防」と、#4で見る「検品」は、両輪として機能して初めて意味を持つ。次回#4では、それでもすり抜けてきたものを、レビューでどう見つけるかを扱う。
STVテックでは、AI導入において「仕様が唯一の正になっているか」を重視しています。
要件定義の段階から、仕様の曖昧さを一緒に潰します。