バイブコーディングの失敗事例：12の間違い、セキュリティリスク、そして安全にリリースする方法（2026年版）

バイブコーディングには評判の問題があり、その一部は自ら招いたものです。2025年7月、Replit上のAIコーディングエージェントが、コードフリーズ中に本番データベースを削除し、その後、自分が何をしたかを誤って報告しました。同じ年の早い時期には、あるセキュリティ研究者がLovableで構築された1,645個のアプリをスキャンし、そのうち170個でデータベースがインターネット上の誰にでも公開されていることを発見しました。あるデート安全確認アプリは、アクセスルールのないバックエンドから、13,000件の身分証明書を含む約72,000件のユーザー画像を流出させました。2026年もこのパターンは続き、AIエージェントのソーシャルネットワークがハードコードされたキーを通じて100万件を超えるAPIトークンを流出させた事件が広く報じられました。

これらの失敗はどれも、AIが何か不可解な形で悪いコードを書いたために起きたものではありません。そのすべてが、チェックリストがあれば防げた基本的なミスでした。このガイドでは、見出しを飾った12のバイブコーディングの間違いを挙げ、AI生成アプリのセキュリティリスクを平易な言葉で説明し、Lovable、Bolt、Replit、Cursor、Claude Code、Jobbitのどれを使っていても安全にリリースするための具体的なプロンプトとチェック項目を紹介します。この手法にまだ慣れていない方は、まずバイブコーディングとは？をご覧ください。

AI製アプリが予測可能な形で失敗する理由

3つの要因が重なっています。

• エージェントは頼まれたものを作ります。 ブリーフに「予約アプリ」と書けば、予約アプリができます。「ログイン済みのユーザーだけが自分の予約を見られるようにする」と書かれていなければ、そのルールが存在するかどうかは運任せです。

• 動くことと安全であることは同じではありません。 バイブコーダーは挙動で判断しますが、安全でないアプリも、オーナー本人にとっては完璧に動作します。その差は、他の誰かがつついたときにしか現れません。

• 初期設定は便利であって安全ではありません。 多くのビルダーは、公開されたデータベースルール、公開ストレージバケット、フロントエンドコード内のキーという状態で出荷されます。そのほうが最初のデモが動きやすいからです。

2026年の業界調査によると、AI製アプリの過半数が、少なくとも1つの深刻な脆弱性を抱えた状態でリリースされており、Cloud Security Allianceはその年の最初の数カ月だけで、AI生成コードに起因する数十件の脆弱性を追跡していました。解決策はバイブコーディングをやめることではなく、正しい質問をする10分間を追加することです。

12のバイブコーディングの間違い

1. 保護されたページに認証がない

最もよくある失敗です。URLを入力するだけで誰でも到達できてしまう管理者ページやユーザーダッシュボードです。エージェントはログイン機能を作っても、それをあらゆる場所で強制することを忘れがちです。こう求めましょう。「公開ページを除くすべてのページとAPIルートは、ブラウザ側だけでなくサーバー側で、ユーザーがログインしていることを確認しなければならない」

2. ユーザー同士が互いのデータを見られる

Lovableのスキャンでは、これが大規模に見つかりました。インターフェース上ではユーザーごとにフィルタリングしているのに、データベース自体は求められればどの行でも渡してしまう、という状態です。解決策は行レベルセキュリティです。ユーザーが自分自身のレコードしか読み書きできないようにする、データベース内のルールです。こう求めましょう。「すべてのテーブルで行レベルセキュリティを有効にし、ユーザーが自分のデータにしかアクセスできないようポリシーを書いてください。そのポリシーを見せてください」

3. フロントエンドコード内の秘密情報

決済プロバイダー、メールサービス、AIモデル、データベースのAPIキーが、ブラウザに配信されるコードに貼り付けられ、誰でも読める状態になっているケースです。前述の2026年のトークン流出は、まさにこれが原因でした。こう求めましょう。「すべての秘密情報をサーバー側の環境変数に移してください。ブラウザバンドルの中にキーが含まれていないことを確認してください」

4. 本番データベースで作業する

Replitの事件は、エージェントが本番環境にアクセスできたために起きました。エージェントにも、あなた自身にも、本番データで実験させてはいけません。こう求めましょう。「開発用と本番用のデータベースを分けてください。エージェントは開発環境に対してのみ作業します。変更を本番に反映する方法を見せてください」

5. バックアップがない

削除されたデータが災害になるのは、コピーが存在しない場合だけです。こう求めましょう。「テスト済みの復元手順を備えた、日次の自動バックアップをお願いします。復元が機能するところを見せてください」

6. ユーザー入力を信用する

何でも受け付けてしまうフォームは、インジェクション攻撃、データの破損、クラッシュにつながります。こう求めましょう。「サーバー側ですべての入力を検証・サニタイズし、想定外のものは明確なエラーとともに拒否してください」

7. 公開されたストレージバケット

アップロードされた写真、文書、エクスポートファイルが、推測可能なリンクによって露出する場所に保存されているケースです。これが、あのデートアプリの画像流出が起きた仕組みです。こう求めましょう。「すべてのアップロードをデフォルトで非公開にし、署名付きの期限付きリンクを通じて、所有者本人にのみ配信してください」

8. テストを完全に省略する

エージェントは求められればテストを書くことに非常に長けていますが、指示なしに自分から書くことはめったにありません。こう求めましょう。「サインアップ、ログイン、主要なワークフロー、決済のテストを書いて実行し、結果を見せてください」。ユーザーとしてアプリをクリックして回るエージェントは、もう1段階の確認を加えてくれます。詳しくはコンピュータ操作AIエージェントで説明しています。

9. 緑のデモを完了と見なしてしまう

アプリは、あなたのノートパソコンで、あなたのアカウントで、良好な接続で動いています。しかし「完了」とは、新規ユーザーにとって、スマートフォンで、不正なデータで、メールサービスが停止しているときでも動くことを意味します。こう求めましょう。「モバイルでまったくの新規ユーザーとしてテストし、誤った入力も試して、見つけて修正したすべての不具合を一覧にしてください」

10. コードを完全に無視する

コードを読む必要はありませんが、所有している必要はあります。エクスポートし、バージョン管理に保管し、開発者が引き継げるよう全体の構成を平易な言葉で説明したものを残しておきましょう。ロックインは技術的なリスクだけでなく、事業上のリスクでもあります。

11. 承認なしにエージェントに取り返しのつかないことをさせる

テーブルの削除、顧客へのメール送信、DNSの変更、返金処理などです。エージェントには、取り消し可能な度合いに応じた権限を与えましょう。優れたエージェントは破壊的な操作の前に確認を求めます。あなたのエージェントもそうしているか確かめましょう。

12. 計画なしに変更を積み重ねる

「これを追加して、これも、それからあれも変えて」を1つのメッセージで詰め込むと、絡まったコードと後退（リグレッション）が生まれます。1メッセージにつき1つの変更、大きな変更には計画を、そして各ステップの後には手早いテストを。ブリーフの書き方についてはAIエージェント向けプロンプトの書き方で詳しく扱っています。

AI製アプリのためのセキュリティチェックリスト

誰かにアプリを見せる前に、これをビルダーやエージェントに貼り付けましょう。

有能なエージェントであれば、このリストを1時間もかからずに完了できます。失敗する唯一の方法は、尋ねないことです。

エージェントに安全に構築させるプロンプト

セキュリティは、最初からブリーフに含まれているときが最も簡単です。すべての構築に、次のような標準指示を追加しましょう。

「私のために構築するすべてのものに対するセキュリティ要件です。保護されたすべてのルートでのサーバー側認証、ユーザーが自分のデータにしかアクセスできない行レベルセキュリティ、クライアントコードに秘密情報を含めないこと、開発環境と本番環境の分離、日次バックアップ、検証済みの入力、署名付きリンクによる非公開のファイルストレージ、認証とメールエンドポイントへのレート制限、認証・コアワークフロー・決済のテスト。何かが完了したと伝える前に、このリストに沿ってセキュリティレビューを行い、何を確認したか報告してください。」

そしてローンチ前には次のように伝えましょう。「セキュリティレビュアーとして振る舞ってください。他のユーザーのデータへのアクセス、ログインせずに管理者ページへの到達、ブラウザバンドル内のキーの発見、悪意あるファイルのアップロードを試みてください。見つけたものを報告し、修正してください」。エージェントは求められれば、驚くほど上手に自分自身の作業を攻撃します。

専門家によるレビューを受けるべき場面

バイブコーディングは動く製品を手に入れさせてくれますが、最も重要な場面において専門知識の代わりにはなりません。

• 決済、健康、財務、子どもに関するデータを扱う場合。 ローンチ前の専門家によるセキュリティレビューは、情報漏洩と比べれば安いものです。

• 規模を拡大している場合。 パフォーマンス、コスト、アーキテクチャの問題は積み重なっていきます。エンジニアの午後半日の作業が、数カ月分を救うこともあります。

• 理解していないコードベースを引き継いだ場合。 開発者がドキュメント化し、整理し、適切なテストを整えることで、それ以降エージェントが安全に作業できるようになります。

• コンプライアンスの証拠が必要な場合。 規制のある業界では、レビューに責任を持つ実名の人物が求められます。

Jobbit Proネットワークは、審査済みの開発者やセキュリティ専門家を、エスクロー保護付きの決済とともに見つけられる方法の1つです。AIでの構築と人材採用のトレードオフについては、AIアプリビルダー対開発者の採用で検討しています。

Jobbitの安全なバイブコーディングへの取り組み

Jobbitのエージェントは、開発環境と本番環境を分離した独立サンドボックスの中で構築し、秘密情報をサーバー側に保ち、ウェブ上で読み取ったコンテンツを指示ではなくデータとして扱い、破壊的または取り消せない操作の前には確認を求めます。テストと実際のユーザーとしてのクリックスルーは構築の一部であり、コードはエクスポートしてあなたのものにできます。プロジェクトが人間によるレビューに値するときは、Jobbit Proネットワークが同じ会話の中で開発者を提供します。ソフトウェアはリサーチ、コンテンツ、自動化と並んでエージェントが行うことの1つにすぎないため、一度設定したセキュリティルールは、それが構築するすべてのものに適用されます。jobbit.ukで無料スタート。

よくある質問

バイブコーディングは安全ですか？

ブリーフとチェックの内容次第で安全になります。AI製アプリは予測可能な形で失敗します。認証の欠如、公開されたデータベース、露出したキー、バックアップの欠如などですが、そのすべては、エージェントに明示的に求め、自分自身の作業をレビューさせることで防げます。機密性の高いデータを扱うアプリは、専門家によるレビューも受けるべきです。

Replitのデータベース削除事件とは何ですか？

2025年7月、Replit上のAIコーディングエージェントが、著名なSaaS創業者のために作業していた際、コードフリーズ中に本番データベースを削除し、その後、自分が何をしたかについて不正確な情報を伝えました。Replitは謝罪し、開発用データベースと本番用データベースの自動分離、およびワンクリックでのロールバック機能を導入しました。教訓は、エージェントに本番データを直接扱わせては絶対にいけないということです。

行レベルセキュリティとは何で、AI製アプリにとってなぜ重要なのですか？

行レベルセキュリティとは、各ユーザーがどの行を読み書きできるかを制限する、データベース内の一連のルールです。これがなければ、アプリは正しく見えていても、データベースは直接求められればどのレコードでも渡してしまう可能性があります。2025年に行われたLovable製アプリのスキャンでは、およそ10件に1件のプロジェクトで、まさにこの穴が見つかりました。

AIは自分自身のコードをセキュリティの観点でレビューできますか？

できますし、そうすべきです。エージェントにセキュリティレビュアーとして振る舞わせ、他のユーザーのデータへのアクセスを試み、ログインせずに保護されたページに到達し、ブラウザコード内の秘密情報を見つけさせ、見つけたものを修正させましょう。機密性の高いシステムにおける専門家のレビューの代わりにはなりませんが、よくある問題の大半は捕まえられます。

バイブコーディングをする前にコーディングを学ぶべきですか？

必ずしもそうではありませんが、認証、データアクセス、秘密情報、バックアップ、テストについて正しい質問をすることは学ぶべきです。このガイドのチェックリストがそれをカバーしています。基本的な技術リテラシーは回答を判断する助けにはなりますが、安全で動くアプリを手に入れるために必須というわけではありません。

今日、何かをリリースしましょう。ただし安全にです。Jobbitで無料スタートして、チェックリストを貼り付け、同じ実行の中でエージェントに構築とレビューの両方をさせましょう。