バイブコーディングの注意点｜動いたものを信じすぎない

バイブコーディングは試作に強い

バイブコーディングは、AIに自然言語で指示しながら、雰囲気でアプリやWebページを作っていく開発スタイルです。

細かい設計書を先に書かなくても、「こんな画面にしたい」「このCSVを集計したい」「このフォームから送信したい」と伝えれば、AIがすぐにコードを出してくれます。この速さは大きな魅力です。

画面設計、ライブラリ選定、コード作成、エラー修正に時間がかかっていたものが、数回のやり取りで動くところまで進むことがあります。作りながら考えるには、とても向いています。

ただし、危ないのは、作った本人も中身を説明できないまま、動いたものを採用してしまうことです。

動くものはすぐできる

AIを使うと、簡単なWebページ、管理画面、CSV処理、フォーム、検索機能くらいなら、かなり速く形になります。画面もそれなりに整い、ボタンも動き、サンプルデータも表示されます。ここで「もうできた」と感じやすいのが罠です。

実際には、一度うまく動いただけかもしれません。入力が空だったらどうなるか、件数が多かったらどうなるか。別のブラウザで動くか。権限のない人がURLを開いたらどうなるか、データを消したら戻せるか。

こうした確認が抜けたまま、見た目だけで完成扱いしてしまうことがあります。

AIが作ったコードの責任はAIに戻せない

AIが出したコードであっても、公開したり業務で使ったりすれば、その責任は使う側に残ります。

フォームから個人情報が漏れる、APIキーが見える場所に入る、削除ボタンでデータが完全に消える、管理画面に誰でも入れる。こうした問題が起きても、「AIが作ったから」では済みません。特に危ないのは、AIがもっともらしい実装を出すことです。

ログイン画面や保存処理、エラー処理らしきものがあっても、実際には安全ではない、権限を見ていない、例外に弱い、ということがあります。

バイブコーディングでは、コードを書く速度より、出てきたコードを説明できるかが重要になります。

仕様が会話の中に散らばる

バイブコーディングでは、AIとの会話の中で仕様が変わっていきます。「この項目も追加」「ここは削除」「管理者だけ見えるように」「スマホでも見やすく」「CSV出力もつけて」と指示を重ねるうちに、最終的な仕様がどこにもまとまっていない状態になりがちです。

会話の履歴を見れば分かるように見えても、実際には古い前提や矛盾した指示が残ります。業務で使うものなら、最低限、次のことは別に残しておくべきです。

会話ログを仕様書代わりにするのは危険です。

データの置き場を決めないまま作ると危ない

バイブコーディングでは、とりあえず localStorage に保存する、とりあえずJSONファイルに書く、とりあえずGoogle Sheetsに入れる、という実装が出やすいです。試作ならそれでよい場合もあります。しかし、業務で使うならデータの置き場は重要です。

localStorage なら端末を変えると使えません。ブラウザのデータ削除で消えます。Google Sheetsなら共有権限や編集履歴の管理が必要です。サーバーやデータベースなら、バックアップ、権限、保守が必要です。

保存先を決めずに作ると、あとから「このデータはどこにあるのか」「誰が見られるのか」「消えたら戻せるのか」が分からなくなります。

画面が先にできるぶん、データの正本が曖昧になりやすい。ここは特に注意が必要です。

セキュリティは見た目では分からない

画面がきれいでも、安全とは限りません。ログイン画面があるように見えても、実際には誰でもAPIを叩けることがあります。管理者だけのボタンが隠れていても、URLを直接開けば操作できることがあります。APIキーがフロント側のコードに入っていて、ブラウザから見えてしまうこともあります。セキュリティの問題は、見た目では分かりません。

業務で使うなら、認証、権限、外部公開、APIキー、入力チェック、ログ、バックアップを確認する必要があります。特に個人情報や顧客情報を扱うものは、試作段階でも実データを入れない方が安全です。

エラー対応が雑なまま残る

AIが作るコードは、正常に動く流れを優先していることがあります。入力が正しく、通信が成功し、ファイルが存在し、データ形式が合っている前提では動く。しかし、現場では例外が起きます。

空欄で送信する、変な文字が入る、ファイル形式が違う、通信が切れる、同じデータを二重登録する、削除してはいけないものを消す、権限のない人が操作する。こうしたケースでどうなるかを見ないと、実用にはなりません。

バイブコーディングでは、「動くようにして」だけでなく、「失敗したときにどうするか」も指示する必要があります。

修正を重ねるほど、壊れ方が見えにくくなる

AIに何度も修正を頼むと、最初は便利です。しかし、場当たり的な修正を重ねると、同じ処理が複数箇所に増え、不要な変数や古い関数が残り、別の機能に影響する修正が入ることがあります。

本人がコードを追えていない場合、どこを直したのか、なぜ動いているのか、次にどこを触ると壊れるのかが分からなくなります。

バイブコーディングで作ったものを残すなら、途中で一度、構造を整理する時間が必要です。ファイルの役割、データの流れ、主要な関数、設定値、外部サービスとの接続を確認しておくべきです。

業務利用に進める前に確認すること

試作として作ったものを、業務利用に進める前には確認が必要です。

これらに答えられない状態なら、まだ業務利用に進めない方がいいです。動いているかどうかより、説明できるかどうかが重要です。

まとめ

バイブコーディングは、試作を速くするには強い方法です。AIに指示しながら、画面や処理をすぐに形にできるため、アイデアを試すには向いています。

しかし、動いたものを信じすぎると危険です。仕様が会話に散らばり、データの置き場が曖昧になり、セキュリティが見えないまま進み、作った本人も中身を説明できない状態になることがあります。バイブコーディングで大事なのは、AIに作らせることではありません。

出てきたものを人間が説明できる状態にすることです。何を作ったのか、どのデータを扱うのか、どこに保存しているのか、誰が使えるのか、壊れたらどう戻すのか。そこまで答えられて、はじめて業務に近づけられます。