はじめに：「動いた」は「大丈夫」じゃない
バイブコーディングを始めた非エンジニアが最初に体験するのは、あの強烈な達成感です。「こんなアプリが欲しい」とAIに話しかけるだけで、数分後には画面の中で実際に動くものができあがる。あの瞬間の興奮は本物ですし、否定する気は一切ありません。
ただ20年以上コードを書いてきた立場から正直に言うと、「動いた」という事実と「使っても安全」という事実は、まったく別の話です。エンジニアがコードを書くとき、画面上の動作確認と同じくらい、あるいはそれ以上の時間を「動いているけど壊れている部分」を潰すことに費やしています。その作業がバイブコーディングでは完全にすっ飛ばされます。
これは批判ではなく、構造の話です。だからこそ、いくつかのポイントを事前に知っておくだけで、バイブコーディングの活用範囲は安全かつ大きく広がります。本記事では「ここだけは押さえておけ」という急所を、現場目線で具体的に解説します。
その１：APIキーをコードに直接書くな
バイブコーディングで外部サービス（OpenAIやGoogle MapsのAPIなど）を使う場合、AIが生成するコードにはしばしばAPIキーが直接文字列として埋め込まれます。たとえばこんな形です。
const apiKey = "sk-xxxxxxxxxxxxxxxxxxxxxxxx";
これをGitHubなどに公開した瞬間、世界中からそのキーが使われる状態になります。APIキーによっては従量課金のサービスもあり、数時間で数十万円の請求が来たという事例は現実に起きています。これはセキュリティの話である以前に、金銭的リスクの話です。
やるべきこと： APIキーは必ず環境変数（.envファイル）に書いて、コードからはprocess.env.API_KEYのように呼び出す形にしてください。GitHubに公開するときは.gitignoreに.envを追加することをAIに指示すれば、設定してくれます。「APIキーを環境変数で管理する形にして」と一言添えるだけで、生成されるコードが安全な構造になります。
その２：ユーザーからの入力は必ず疑え
フォームやテキストボックスからユーザーが何かを入力するアプリを作るとき、その入力をそのままデータベースに保存したりHTMLに表示したりするコードをAIは平気で生成します。エンジニアの世界では「ユーザー入力を信用するな」は常識中の常識ですが、AIはこれを自発的に守ってくれません。
具体的に何が起きるかというと、たとえば悪意のあるユーザーが入力欄に<script>alert('hack')</script>と入力したとき、それをそのまま表示するアプリはそのスクリプトを実行してしまいます。これがXSS（クロスサイトスクリプティング）と呼ばれる攻撃で、ブラウザを乗っ取られたり、個人情報を盗まれたりする原因になります。
やるべきこと： AIに「ユーザー入力のサニタイズとバリデーションを実装して」と必ず指示してください。また、データベースを使う場合は「SQLインジェクション対策を含めて」と伝えると、パラメータ化クエリなど適切な実装を出してくれます。
その３：認証と認可を後回しにするな
「まず動くものを作って、後でログイン機能をつける」というアプローチはバイブコーディングでよく起きます。しかし、これは見た目以上に危険です。認証なしで作り込んだデータ構造やAPIは、後から認証を追加する際に根本的な設計変更が必要になるケースが多く、AIに「後で認証を追加して」と頼むと、継ぎ接ぎだらけの脆弱な実装が生まれやすいのです。
特に他人のデータを扱うアプリ——たとえば「複数の社員が入力した情報を管理する」ようなもの——では、「Aさんが自分のデータしか見られない」という認可の制御が重要です。認証（ログインできるか）と認可（何にアクセスできるか）は別物であり、どちらが欠けても問題が起きます。
やるべきこと： アプリを作り始める最初の指示に「認証が必要か・複数ユーザーを想定するか」を明示しましょう。「複数ユーザーが使う想定で、自分のデータだけ見える設計にして」と最初から伝えることで、設計段階から考慮された実装になります。
その４：エラーメッセージをそのままユーザーに見せるな
AIが生成したコードには、エラーが起きたときにシステムの内部情報をそのまま画面に表示するものが少なくありません。データベースのテーブル名、ファイルのパス、ライブラリのバージョン情報——これらは攻撃者にとって非常に有益な情報です。内部構造がわかれば、そこを狙ったピンポイントの攻撃が可能になります。
また、エラーハンドリングが甘いコードは予期しない状況で突然クラッシュします。本番で使い始めた後に「急に動かなくなった」「データが消えた」という事態になってから原因を調べるのは、コードを読めない非エンジニアには非常に難しい作業です。
やるべきこと： 「エラーが起きたときはユーザーにはシンプルなメッセージだけ表示し、詳細はログに記録する形にして」と指示してください。エラー処理を後から加えるのではなく、最初から組み込んでもらうことが重要です。
その５：本番で使うなら必ずバックアップを設定しろ
バイブコーディングで作ったアプリでデータを蓄積し始めると、そのデータに価値が生まれます。しかし、AIが生成したコードにデータのバックアップ処理が含まれていることはほとんどありません。ストレージが壊れる、誤操作で全削除してしまう、サービスのプランを変えたらデータが消えた——こういった事態は現実に起きます。
| 用途 | データ重要度 | 推奨バックアップ方法 |
|---|---|---|
| 個人の実験・検証 | 低 | 不要（再作成可能） |
| 社内の業務ツール | 中 | 週次エクスポート（CSVなど） |
| 複数人が使う共有ツール | 高 | 自動バックアップ設定必須 |
| 顧客情報・決済データ | 非常に高 | エンジニアによる設計が必要 |
やるべきこと： 使っているサービス（SupabaseやFirebaseなど）のバックアップ機能を有効にするか、「定期的にデータをCSVエクスポートできる機能をつけて」とAIに指示するだけでも保険になります。
その６：「動いているコード」を無計画に改造し続けるな
バイブコーディングの最大の落とし穴の一つが、「少し機能を追加して」「ここを直して」を繰り返すうちに、コードが誰も全貌を把握できないスパゲッティ状態になることです。AIは毎回の指示に従って局所的に修正しますが、全体の設計を俯瞰して「この変更は別の場所に悪影響を与えないか」を考えてくれるわけではありません。
ある機能を直したら別の機能が壊れた、ということが頻繁に起きるようになったら、それはコードが限界に近づいているサインです。そのタイミングで「全体を整理してリファクタリングして」とAIに頼んでも、問題が複雑すぎて解決しないことが多々あります。
やるべきこと： 「ちょっとした修正」を10回繰り返す前に、一度「今のコード全体をレビューして、整理が必要な箇所を教えて」と確認を挟む習慣をつけましょう。また、大きな変更を加える前には必ずコードをコピーして手元に保存しておくことを忘れずに。
まとめ：たった６つを守れば、バイブコーディングは強力な武器になる
ここまで挙げた注意点を整理します。
- APIキーは環境変数で管理し、コードに直書きしない
- ユーザーの入力は必ずサニタイズ・バリデーションを指示する
- 認証と認可は最初の設計段階で組み込むよう指示する
- エラーメッセージは内部情報を隠し、ログに記録する形にする
- データを蓄積するなら必ずバックアップの仕組みを設ける
- コードの改造を重ねる前に定期的に全体の見直しを挟む
これらはエンジニアが新人に最初に叩き込む「当たり前のこと」です。ただし、それがバイブコーディングの文脈では自動的に守られないというだけの話です。逆に言えば、この６点を意識するだけで、バイブコーディングの安全性は格段に上がります。
AIを使いこなすことと、リスクを理解することは矛盾しません。むしろ、リスクを知っているからこそAIを最大限に活用できるのです。