バイブコーディングとAI仕様駆動開発の違い〜「動くもの」と「壊れないもの」は別物だった
「バイブコーダーに発注したら、本番で火を噴いた」。
そんな趣旨の投稿が、最近よく流れてきます。数日で魔法のようにプロトタイプが立ち上がった。ところが本番に向けて仕様を足し始めた途端、直すたびに別の場所が壊れる「モグラ叩き」が始まった、という話でした。
AIを駆使した開発方法は様々ありますが、両者には明確な違いがあります。
- 雰囲気重視の「バイブコーディング
- 仕様をしっかり固めてAIの動作範囲を決めて進める「AI仕様駆動開発」
「AIで”とりあえず動くもの”を作る力」と、「現場で壊れずに動き続けるものを作る力」は、まったくの別物です。
両者の違いを改めて記事にすることにしました。
「速さ」は、本物だった
バイブコーディングという言葉が、この1〜2年で一気に広がりました。きっちり仕様を書かず、AIとの対話の勢いだけで、思いついたものをその場で形にしていく作り方です。
私も最初に触れたときは、正直、息をのみました。頭の中にあったアイデアが、数時間後には画面の上で動いている。手を動かす前に、もう触れる。これは魔法のようでした。
とくに、まだ世に出すかどうかも決まっていないアイデアを試すとき。
いわゆる試作品（プロトタイプ）づくりでは、この速さは何物にも代えがたい武器になります。私たちも、お客様との打ち合わせの場で、その場で画面を立ち上げて見せることがあります。言葉で30分説明するより、動く画面を5分さわってもらうほうが、話が早い。
だから、バイブコーディングそのものを否定する気は、まったくありません。むしろ、仮説を確かめる段階では強力な相棒なのです。
動くものと、壊れないもの
本番に向けて仕様を足し始めた途端、景色が変わります。
冒頭で触れた投稿も、まさにそこでつまずいていました。データの保存のしかたを一つ変えただけで、つながっていたはずの機能が次々とエラーを吐く。一つの画面を直すと、まったく関係ないはずの別の画面のレイアウトが崩れる。少し変わった操作をされると固まってしまう。直すたびに、別のどこかが壊れる。
これは、作り手の腕が悪いという話だけではない、と私は思っています。
「とりあえず動く」ことと、「現場で壊れずに動き続ける」ことは、設計の深さがまるで違うからです。
動くものは、決められた一本道をなぞれば動きます。けれど本番は、想定していない入力、同時に使う何十人もの利用者、後から足される仕様・・・道なき道の連続です。そこで効いてくるのが、何かおかしくなったときの逃がし方や、画面と画面のつながりをあらかじめほどいておく設計。表からは見えない部分こそが、壊れにくさを決めるのです。
プロトタイプとして見れば、よくできていた。けれど本番のシステムとして見ると、土台や仕組みが全く足りていない。そういう案件を、私は何度も見てきました。
「AI駆動開発」も、ピンキリだ
ここで一つ、整理したいことがあります。
「AIを使った開発」とひとくくりにされがちですが、その中身はピンキリです。
「AIで作りました」と言っても、勢いで書かせたものと、設計を人間が握ったうえでAIに作らせたものとでは、できあがるものの寿命がまるで違うのです。
前者が、いわゆるバイブコーディング。後者を、私たちはAI仕様駆動開発と呼んで、はっきり分けて考えています。
両者を分ける一番の境目は、技術の新しさではありません。
作っているもの全体の姿と、部品どうしのつながりを、資料として落とし込み、仕組み化できているか。
ここに尽きます。
AIは、頼まれた部分を驚くほど速く書きます。けれど、システム全体をどう組み立て、どことどこが支え合っているのか・・・その地図までは、黙っていては持ってくれません。
地図を持たないまま部品だけを足し続けると、いつか必ず、つじつまが合わなくなる。
安く速くできる、という言葉だけで発注先を選ぶと、この地図を誰も持っていない現場に当たることがあります。それが、火傷の入口になりやすいと感じています。
堅いAI駆動開発に共通する、4つの条件
では、本番に耐えるAI駆動開発には何が要るのか。私が現場で大事にしているのは、次の4つです。
一つ目は、作り始める前に「完成の合格ライン」を言葉で決めておくこと。どう動けば正解で、どんな操作をされたら何を返すのか。これを先に書き出してから作ります。完成の基準を先に文章にしてから組み立てるこの進め方は、ATDD・BDDと呼ばれる考え方 に近いものです。
二つ目は、AIが安全に作業できる土台と手すりを、先に整えておくこと。よく使う部品をあらかじめ共通化しておく、危ない書き方は機械が自動で止める、といった仕組みです。AIに何でも自由にやらせるのではなく、走ってよい範囲を先に敷いておく。私たちはこれをハーネスエンジニアリング（暴れ馬を手綱でなだめるように、AIが安全に走れる制御の仕組みを先に設計する取り組み）と呼んでいます。
三つ目は、品質を最後でチェックするのではなく、工程の途中で確かめ続けること。コードを書くたびに自動で検査が走り、おかしければその場で気づける。最後にまとめて直そうとすると、直したこと自体が新しい不具合を生む・・・そんな無限ループに、はまらずに済みます。
四つ目が、いちばん大事かもしれません。全体の地図と部品のつながりを、人間が設計し、握り続けること。AIは優秀な作り手ですが、何を作るべきかを決めるのは人間の仕事です。ここを丸ごと預けた瞬間に、モグラ叩きが始まる。
派手な技術は要りません。むしろ地味なこの4つを、最初に手間をかけて積むかどうか。それだけで、半年後の景色が変わります。
私たちが現場でやっていること
こうした考え方を、テイルウインドの受託開発に落とし込んでいます。
中心にあるのは、業務でよく出てくる機能を、再利用できる「積み木」として育てておく発想です。会社ごとに毎回ゼロから作るのではなく、確かめ済みの積み木を組み合わせる。そのうえで、完成の合格ラインを先に決め、品質を工程の中で担保する。AIの速さを、整えた土台の上で安全に走らせるイメージです。
AIで「とりあえず動くもの」は、もう誰でも作れる時代になりました。だからこそ、価値の在りかが、静かに移っていくのだと思います。
速く作れること自体は、もう武器になりにくい。けれど、壊れたものを直し続ける苦しさは、AIがどれだけ進んでも変わりません。だからこそ、壊れずに使い続けられることにこそ、これからの価値が宿るのだと思います。
この変化は、発注する側と作る側の関係も、静かに変えていくのかもしれません。
「安く速く作ってもらう」関係から、「壊れないものを一緒に設計する」関係へ。
もし、外注したシステムの品質に心当たりや不安があれば。
あるいは、これからAIを使った開発を考えているなら。ぜひお気軽にご相談くださいませ。
よくある質問とその答え
バイブコーディングとAI駆動開発は、どう使い分ければいいですか？
試作品やアイデア検証など「捨ててもいい段階」は勢い重視のバイブコーディングが向きます。本番として使い続けるものは、設計を人間が握るAI駆動開発に切り替えるのが安全です。
どこまでAIに任せて、どこから危ないのですか？
部品単位の実装はAIに任せて大丈夫です。危ないのは、全体の構成と部品どうしのつながり（地図）まで丸ごと預けてしまうこと。ここは人間が握り続ける工程です。
“速いだけ”の作り手か、堅い作り手かは、どこで見極められますか？
「完成の合格ラインを先に決めますか」「全体の設計図は誰が持ちますか」「直したときの検査はどう回しますか」。この3つを尋ねて、言葉に詰まらないかどうかが一つの目安になります。
