バイブコーディングで抜けやすいのは、「うまくいっているときには見えないもの」です。私たちが本番化の現場で見てきたことと、自分たちの AI 作業でやらかしたことから言えるのは、この一点です。速く作れることと引き換えに、確かめる工程が抜けやすい、という整理で、AI で作ること自体を否定する話ではありません。
この記事で書くこと、書かないこと
バイブコーディングのデメリットの一般的な一覧は、ほかにも多くあります。この記事では、一般論を並べません。私たちが実際に見たことと、私たち自身がやらかしたことだけを書きます。
どれも、AI を使った開発が悪いという意味ではありません。私たち自身も、日々の開発に AI を使っています。
見たこと1: 動いている間は、問題が表に出ない
AI ツールで画面や試作を作ってから相談に来られる方が、増えています。診断や本番化の中で、私たちは次のような状態を見てきました。
- 秘密の鍵（API キーなど）が、外から見える場所に置かれている
- ログインはできるのに、他人のデータを見たり変えたりできる
- バックアップも監視もなく、壊れたら戻せない
- 構成を誰も説明できず、作った本人しか直せない
共通しているのは、どれも、動いている間は何も起きないことです。正しく使われて、何も壊れていないときは、画面は問題なく動きます。問題が出るのは、悪用されたとき、壊れたとき、作った人がいなくなったときです。作った人は動いている画面を見て確かめるので、ここに気づきにくくなります。
それぞれの確かめ方は、AIで作ったアプリを本番化するにはにまとめています。
見たこと2: 「うまくいかないとき」は、頼まなければ作られない
ある業務システムの本番化の例です。お客様が Claude Code で作った画面と、少し動くコードがありました。コードの中には、既存のシステムからデータを取ってくる処理もありました。データは、ちゃんと取れていました。
抜けていたのは、その処理が失敗したときと、処理は正常なのにデータがおかしいときの扱いです。試作では、まだ起きていない場面だったからです。画面のコードは活かして、認証・データベース・インフラなどを肉付けする中で、ここも整えました。
AI は、頼んだ機能が動くように作ってくれます。うまくいかない場合の処理は、頼まなければ作られないことが多いと、私たちは考えています。詳しくは「うまくいかないとき」の処理はあるかに書きました。
やらかしたこと1: 「成功しました」の裏で、実行されていなかった
ここからは、私たち自身の失敗です。
AI に表計算の更新作業を任せたとき、AI は列の挿入と行の追加を「成功しました」と報告しました。実際には、実行されていませんでした。「全部の検証が通りました」という報告も、実際には検証が動いておらず、エラーが出ていました。指摘したあとにも、同じことが起きました。
この経験から、AI の報告は、結果の確認ではなく報告として受け取り、書き込みのあとは別の方法で実態を確かめるようにしています。ほかの例を含め、AIの「成功しました」をそのまま信じないに書きました。
やらかしたこと2: 失敗したのに、止まらなかった
自社で、AI に記事の投稿作業を任せていたときのことです。見出し画像を付けられなかったのに、AI はそのまま投稿を続け、画像のない記事が公開されました。
それ以来、失敗したらその場で止めて、人に報告させています。「うまくいかないときの処理」は、お客様の試作だけでなく、私たちの AI 作業にも要りました。
やらかしたこと3: 確かめた方向だけで、結論を出した
AI に作業を任せていたとき、AI が、専用だと誤って判断したサーバーを削除しました。実際には、複数のドメインが相乗りしている共用の Web サーバーでした。
AI は、ドメインから IP アドレスを引く向きだけを確かめて、専用だと判断していました。その IP アドレスを指しているほかのドメインがないか、逆向きに調べてはいませんでした。逆向きの確認はコマンド1本で済むもので、実行していれば、すぐに分かったことです。削除保護も、外したうえで実行されていました。バックアップがあったので、そこから復旧しました。
ここから私たちが学んだのは、AI は、確かめた方向だけで結論を出すことがある、ということです。それ以来、削除や停止の前には、参照元を全部洗い出すこと、削除保護の解除は独断でしないことをルールにしています。
それでも、私たちは AI で作ることをやめない
ここまでの話は、デメリットの一覧に見えるかもしれません。ただ、私たちの結論は逆です。
AI で作ると、完成イメージを最初から共有できるので、開発は速く進みます。試作は、捨てなくてよい、本番開発の出発点になります。その速さと引き換えに抜けやすいのが、上で書いた「うまくいっているときには見えないもの」です。
抜けやすい場所が分かっていれば、そこを先に確かめられます。全部を完璧にしてから公開する必要はありません。誰が使うか、どんなデータを扱うかで、確かめる深さを決めます。社外の人が使う、または個人情報や決済を扱うなら、秘密の鍵、他人のデータ、戻せるか、本人以外に直せるか、の4つは公開前に答えられるようにしておきます。
| 抜けやすいもの | 確かめ方を書いた記事 |
|---|---|
| 秘密の鍵の置き場所 | APIキーがブラウザやコードから見えていないか |
| 他人のデータへのアクセス | ログインできても安心できない |
| 壊れたときの戻し方 | 壊れたら戻せるか |
| うまくいかない場合の処理 | 「うまくいかないとき」の処理はあるか |
| AI の報告の確かめ方 | AIの「成功しました」をそのまま信じない |
| AI に本番を触らせない仕組み | AIに本番を触らせない |
wizgeek にできること
自分で確かめても不安が残る、または何から見ればよいか分からないときは、ご相談ください。AIで作った試作の構成と機能を把握し、認証・データベース・インフラ・セキュリティ・監視のうち何が足りないかを整理して、構成案をお渡しします（本番化の診断：5万円〜、税別）。構成案をもとに、お客様側で実装していただくこともできます。本番化の作業は別途お見積りします。
試作を作ったAIに構成と課題を書き出してもらう無料のプロンプトも公開しています。
まずは、AIで作ったアプリの本番化のご相談からお問い合わせください。