バイブコーディングのデメリットとセキュリティ：公開前に確かめる10項目
AI で作ること自体は問題ではありません。危ないのは、「動く」と「安全に使い続けられる」の差を、誰も確かめないまま公開することです。この記事では、よく言われるバイブコーディングのデメリットを5つに分け、実際に起きた事故と、公開前に自分で確かめられる10項目をまとめます。
Claude Code、Cursor、Lovable、v0 などの AI ツールを使えば、エンジニアでなくても、動くアプリを作れるようになりました。自社のサービスの試作品を作る会社も、Excel の業務を置き換える社内システムを作る会社も増えています。
一方で、「このまま公開して大丈夫なのか」という相談も増えました。この記事では、その不安の中身を分けて、自分で確かめられることと、専門家に見せるべきことを整理します。
この記事の内容は、2026年10月時点の各サービスの公式ドキュメントと報道にもとづいています。円の金額は、1ドル150円で計算した目安です。
バイブコーディングとは：作れるようになった今、足りないのは「判断」
バイブコーディングは、AI に話しかけるように指示を出し、コードを細かく読まずにアプリを作る進め方です。2025年2月に、AI 研究者のアンドレイ・カルパシー氏が X への投稿で使ったのが始まりとされています（Snyk）。
仕様がまだ固まっていない段階で、自分たちで速く試せるのは大きな利点です。画面を触りながら考えを固められるので、会議で仕様を詰めるよりも早く、何が必要かが分かります。
ただし、AI が作るのは「頼まれたとおりに動くもの」です。そのアプリが安全か、利用者が増えても耐えられるか、あとから直せるかまでは、頼まないと考えてくれません。バイブコーディングのデメリットの多くは、AI の性能の問題ではなく、作ったものを判断する人がいないことから生まれます。
よくある場面：動くものはできたのに、公開のボタンを押せない
AI で作り始めた会社から聞く悩みは、使い道によって少し違います。
| 作っているもの | よく聞く悩み |
|---|---|
| 売るためのサービス（SaaS） | お客さんのデータが、ほかのお客さんから見えないか。決済や個人情報を扱って大丈夫か。利用者が増えたときに、請求がいくらになるか |
| 社内で使うシステム | 社内の人だけが使える状態になっているか。退職した人のアカウントはどうするか。作った人が異動したら、誰が直すのか |
どちらにも共通しているのは、「何が分かっていないのかが分からない」ことです。動くものはできた。でも、どこを確かめれば公開してよいと言えるのかが分からない。その結果、公開のボタンを押せずに止まっています。
バイブコーディングの5つのデメリット
よく言われるデメリットを整理すると、次の5つになります。前の3つは公開前に確かめられることで、後の2つは作り方で防ぐことです。
| デメリット | 何が起きるか | 防ぎ方 |
|---|---|---|
| データが丸見えになる | 他人のデータや、ログインしていない人からのアクセスを防げない | 公開前に確かめる |
| 秘密の鍵が漏れる | 管理者用のキーが盗まれ、データを消されたり、高額な請求が来たりする | 公開前に確かめる |
| 悪用されて請求が膨らむ | 誰でも何度でも呼べる機能を狙われ、サービスが止まったり、請求が一晩で跳ね上がったりする | 公開前に確かめる |
| 欲しいものと違うものができる | 作り直しが続き、かえって時間がかかる | 作り方で防ぐ |
| あとから直せない | 中身がつぎはぎになり、直すたびに別の場所が壊れる | 作り方で防ぐ |
前の3つは、クリーヴァが伴走やレビューの現場で、特によく見るものです。
1. データがインターネットに丸見えになる
AI で作ったアプリでよく使われる Supabase や Firebase は、画面から直接データベースにつなぐ作りです。そのため、データベースの側で「誰が、どのデータを読めるか」を決めておく必要があります。Supabase では、この設定を RLS（行ごとに、誰が読めるかを決める設定）と呼びます。
この設定が入っていないと、アプリの画面を通さなくても、データベースの中身を丸ごと読めてしまいます。画面の上では自分のデータしか表示されないので、作った人は気づきません。
2. 秘密の鍵が、画面の側に漏れる
アプリが外のサービスを使うときには、API キー（サービスを使うための鍵）が必要です。鍵には、画面に置いてよいものと、絶対に画面に置いてはいけないものがあります。
たとえば Supabase の公開用のキーは、画面に置いても問題ありません。読める範囲が RLS で制限されるからです。一方で、管理者用のキー（service_role）は、RLS を無視してすべてを読み書きできます。そのため、ブラウザやソースコードに置いてはいけないと、公式ドキュメントに書かれています。
AI に「動かない」と伝えると、手っ取り早く動かすために、管理者用のキーを画面の側に書いてしまうことがあります。動くようになるので、そのまま公開されがちです。
3. 誰でも何度でも呼べる機能を、悪用される
AI に文章を書かせる機能や、SMS・メールを送る機能は、1回呼ぶごとにお金がかかります。こうした機能が、ログインしていない人でも、回数の制限なく呼べる作りになっていることがあります。
この状態だと、プログラムで何万回も呼ばれるだけで、サービスが止まったり、請求が一晩で跳ね上がったりします。高度な攻撃はいりません。Web の API の安全性の指針として広く使われる OWASP API Security Top 10 でも、回数や費用の上限がないことを、代表的な弱点の1つに挙げています（OWASP）。
AI は「頼まれた機能が動くこと」を目標に作ります。誰が、何回まで使えるかという制限は、頼まないと入りません。
4. 指示があいまいで、欲しいものと違うものができる
「在庫を管理できる画面を作って」のように指示があいまいなままだと、AI は足りない部分を自分で補って、それらしいものを作ります。動くので一見うまくいったように見えますが、現場の業務の流れや、必要な項目と合っていないことがあります。
直すたびに別のところがずれて、作り直しが続きます。速く作れるはずが、結局、時間がかかってしまうパターンです。
5. ルールや設計がないまま任せて、中身がぼろぼろになる
何を作るのか（要件）や、どんなルールで作るのか（設計・開発のルール）を決めずに AI に任せると、画面は動いていても、中身はつぎはぎになります。同じ処理があちこちに散らばり、権限のチェックが一部の画面だけ抜けている、といった状態です。画面を開くたびに、同じデータを何十回も取りに行く作りもよく見ます。1人で試している間は気づきませんが、利用者が増えると、表示が遅くなったり、請求が増えたりします。
こうなると、1か所を直すと別の場所が壊れます。作った本人も中身を説明できないので、その人がいなくなると、誰も直せなくなります。
4と5は安全とは別の話に見えますが、根は同じです。AI に何を任せ、何を人が決めるのかを、先に決めていないことです。
なぜ AI はこういう作りにするのか
AI は、頼まれたことを最短で満たそうとします。「ログイン画面を作って」と頼めば、ログインできる画面を作ります。しかし、「ログインしていない人には何も見せない」「他人のデータは見せない」といった、書かれていない約束までは守ってくれません。
| 頼んだこと | AI が作るもの | 抜けやすいもの |
|---|---|---|
| ログイン画面を作って | ログインできる画面 | ログインしていない人や、別の人からのアクセスを防ぐ設定 |
| 外部の AI を使った機能を作って | API を呼んで結果を表示する機能 | 鍵を画面に置かない作り、使える回数や金額の上限 |
| 問い合わせフォームを作って | 送信できるフォームと、確認のメール | 同じ人やプログラムが何千回も送れないようにする制限 |
ツールに付いているセキュリティ スキャンに合格していても、安心はできません。後で紹介する Lovable 製アプリの調査では、スキャンに合格していたアプリでも、ログインせずにデータを読み書きできたことが報告されています。
調査の数字も、同じことを示しています。Veracode 社の調査では、AI が書いたコードの45%に、よく知られた種類の脆弱性（攻撃に使われる弱点）が含まれていました（Veracode）。また Escape.tech 社が、AI で作られて公開されているアプリ約5,600件を調べたところ、2,000件を超える脆弱性が見つかっています（Escape.tech）。
実際に起きた事故と、確かめれば防げたこと
実際の事故を見ると、高度な攻撃によるものはほとんどありません。多くは、「ログアウトして試す」「上限をかける」といった基本の確認で防げたものです。
「AI 製」は、AI で作られたアプリだと出典に書かれているものです。「同じ型」は、AI 製ではありませんが、AI で作ったアプリでも起きやすい同じ種類のミスによるものです。
| 事故 | 種類 | 何が起きたか | 確かめれば防げたこと |
|---|---|---|---|
| Moltbook（2026年2月） | AI 製 | 「コードを1行も書かずに作った」SNS で RLS が効いておらず、認証用のトークン約150万件と、非公開のメッセージ4,060件が読めた（Wiz） | 公開用のキーだけで何ができるか、ログアウトした状態で試す |
| Lovable 製アプリの調査（2025年5月） | AI 製 | 調べた1,645件のうち10.3%で、ログインせずにデータを読み書きできた。ツールのスキャンには合格していた（Matt Palmer 氏の報告） | すべてのテーブルで、誰が何を読めるかを確かめる |
| Lovable 製の教育アプリ（2026年2月） | AI 製 | 認証のチェックが逆向きになっていて、ログインしていない人だけが通れた。18,697件の情報が見える状態だった（The Register） | ログアウトした状態と、別のアカウントで、他人のデータが見えないか試す |
| 盗まれた Gemini のキー（2026年3月） | 同じ型 | 普段は月18万円ほどの請求が、2日間で約1,200万円（82,314ドル）になった（The Register） | キーに使えるサービスの制限と、利用の上限をかける |
| Replit の AI が本番のデータを削除（2025年7月） | AI 製 | 「勝手に変更しない」と指示していたのに、AI が約1,200人分の本番のデータを消した（The Register） | AI が本番の環境に触れない構成にし、バックアップから戻せるか確かめる |
公開前に確かめる10項目
ここからが、この記事の中心です。次の10項目は、コードを読まなくても、多くを確かめられるように選びました。ログアウトして触る、別のアカウントで触る、管理画面の設定を見る、の3つが基本です。
○ならそのまま次へ、×や「分からない」なら、その項目の「×のとき」を読んでください。
データ：他人のデータが見えないか
① ログアウトした状態で、ログインした人向けのデータが見えないか
- 確かめ方：ブラウザのシークレット ウィンドウでアプリを開き、ログインせずに、データの一覧や詳細の画面の URL を直接開きます。
- ×のとき：データベースのアクセス制御が入っていません。公開を止めて、次の③を確かめてください。
② 別のアカウントで、他人のデータが見えないか
- 確かめ方：テスト用のアカウントを2つ作り、片方で作ったデータの URL を、もう片方で開きます。URL の末尾の番号を1つずらして開くのも試します。
- ×のとき：「自分のデータだけ見せる」という制限が抜けています。売るためのサービスなら、お客さんどうしのデータが見える状態なので、最優先で直します。
③ すべてのテーブルで、アクセス制御（RLS）がオンになっているか
- 確かめ方：Supabase なら、管理画面のテーブルの一覧で、RLS が無効なテーブルに注意の表示が出ます。Firebase なら、セキュリティ ルールが「誰でも読み書きできる」設定のままになっていないかを見ます。
- ×のとき：オンにするだけでは足りず、「誰が何を読めるか」のルールも必要です。オンにしたとたんに画面が動かなくなることもあるので、②の確かめ方とセットで直します。
鍵：秘密の情報が画面の側に漏れていないか
④ ブラウザから、管理者用のキーが見えないか
- 確かめ方：アプリを開いて、ブラウザの開発者ツール（Chrome なら F12 キー）の「ソース」や「ネットワーク」を開き、
service_role、secret、sk-などの文字を検索します。 - ×のとき：そのキーはすでに漏れたものと考えて、管理画面で無効にし、新しいキーを作ります。新しいキーは、サーバーの側だけで使う作りに直します。
⑤ 鍵を書いたファイル（.env）が、GitHub に上がっていないか
- 確かめ方：GitHub のリポジトリを開き、
.envという名前のファイルがないかを見ます。過去に一度でも上げていれば、消しても履歴に残っています。 - ×のとき：公開された鍵は、数分で見つかって悪用されることがあります（Unit 42）。鍵を無効にして作り直し、
.envを GitHub に上げない設定（.gitignore）を入れます。
⑥ それぞれのキーに、使える範囲の制限をかけているか
- 確かめ方：Google Cloud や OpenAI などの管理画面で、キーごとに「使えるサービス」「使えるサイト」の制限があるかを見ます。
- ×のとき：キーが漏れたときの被害を小さくするために、そのアプリで使うサービスだけに絞ります。
悪用と請求：狙われたときに被害が広がらないか
⑦ 予算のアラートだけでなく、利用の上限をかけているか
- 確かめ方：使っているクラウドや API の管理画面で、上限の金額に達したら止まる設定があるかを見ます。
- ×のとき：注意したいのは、アラートは通知するだけで、利用は止めないことです。Google Cloud の公式ドキュメントにも、アラートだけの予算は利用を自動で止めないと書かれています（Google Cloud）。止める設定があるサービスでは、それも入れておきます。
⑧ お金がかかる機能を、ログインしていない人が何度でも使えないか
- 確かめ方：AI に答えさせる機能や、メールを送る機能を探します。ログアウトした状態で使えないか、同じ操作を続けて何十回もできないかを試します。
- ×のとき：その機能はログインした人だけが使えるようにし、1人あたりの回数の制限をかけます。外部のサービスの側でも、1日に使える量の上限を設定しておきます。
⑨ AI が本番の環境に触れない構成で、バックアップから戻せるか
- 確かめ方：開発用と本番用で、データベースが分かれているかを見ます。バックアップの設定があり、実際に戻す手順を一度試したかも確かめます。
- ×のとき：AI に作業させるのは開発用の環境だけにします。バックアップは「取っている」だけでなく、「戻せる」ことを確かめて初めて意味があります。
作り：あとから直せるか
⑩ 仕様とルールが文書で残っていて、作った人以外も説明できるか
- 確かめ方：作った人以外の人が、「このアプリで誰が何をできるか」を、文書を見ながら説明できるかを試します。
- ×のとき：AI に作らせる前に、要件と開発のルールを短い文書にまとめ、AI にも毎回それを読ませます。AI に任せる前に人が決めておくことは、Claude Code を会社で安全に使うでも紹介しています。
自分では判断しにくいこと
10項目に○がついても、それで安全だと言い切れるわけではありません。次のことは、確かめ方の手順だけでは判断できず、経験のある人が中身を見る必要があります。
- 権限の設計が、事業に合っているか：誰が何をできるべきかは、アプリごとに違います。ルールが「ある」ことは確かめられても、それが「正しい」かは、事業の中身と照らし合わせないと分かりません。
- 制限をどこまでかければよいか：回数の制限や上限の金額は、厳しすぎると普通の利用者が困り、ゆるすぎると悪用を防げません。ちょうどよい値は、使われ方と事業によって違います。
- あとから直せる構成になっているか：機能を足すたびに壊れる作りかどうかは、コードの構成を見ないと分かりません。
使い道ごとに、特に専門家に見てもらいたいところも違います。
| 使い道 | 特に見てもらいたいところ |
|---|---|
| 売るためのサービス | お客さんごとのデータの分け方、決済のつなぎ方、利用者が増えたときの請求の見込み |
| 社内で使うシステム | 社内の人だけが使える仕組み、個人情報の扱い、退職した人のアカウントの止め方、作った人がいなくなっても直せるか |
次の一手：自分たちで直すか、専門家に見てもらうか
×が少なく、直し方も分かるなら、自分たちで直して進めて大丈夫です。直したあとに、もう一度10項目を確かめてください。
判断できない項目が残ったら、公開の前に、一度は専門家に見せることをおすすめします。公開したあとに見つかると、データの消去や、お客さんへの連絡が必要になることがあるためです。
どの進め方がよいかは、段階によって違います。
| 段階 | 向いている進め方 |
|---|---|
| 仮説を試す（仕様がまだ動く） | 自社で AI を使って作り、判断に迷うところをプロに相談する |
| 公開前に確かめる | 自社で10項目を確かめ、判断できないところを専門家に見てもらう |
| 本格的に作り込む（仕様が固まった） | 開発会社に作り込みを任せる。または、プロの伴走を受けながら社内で作り続ける |
クリーヴァの「せんせいAI」は、AI で開発を進める会社に、エンジニアが伴走するサービスです。公開前のコードのレビューや、データベースとインフラの設定の確認を、理由を添えて一緒に進めます。まずは30分の無料相談で、作っているものの状況に合わせて、AI開発の進め方とリスクを一緒に整理します。
よくある質問
バイブコーディングで作ったアプリを、そのまま公開してもいいですか？
10項目を確かめて、×や「分からない」がなければ、公開を考えてよい段階です。ただし、お客さんのお金や個人情報を扱う場合は、公開前に一度、専門家に見てもらうことをおすすめします。
ツールのセキュリティ スキャンに合格すれば大丈夫ですか？
それだけでは足りません。Lovable 製アプリの調査では、スキャンに合格していたアプリでも、ログインせずにデータを読み書きできた例が報告されています。スキャンに加えて、①②のように、ログアウトした状態や別のアカウントで実際に触って確かめてください。
Supabase の公開用のキー（anon key）が、画面から見えても大丈夫ですか？
すべてのテーブルで RLS がオンになっていて、ルールが正しければ大丈夫です。Supabase の公式ドキュメントでも、公開用のキーは画面に置いてよく、読める範囲は RLS が決めると説明されています。画面に置いてはいけないのは、管理者用のキー（service_role）のほうです。
エンジニアがいない会社でも、AI での開発を続けて大丈夫ですか？
続けて大丈夫です。仕様が固まる前に自分たちで試せるのは、AI での開発の大きな強みです。そのうえで、判断が必要なところだけ専門家の力を借りる、という分け方をおすすめします。
まとめ
- バイブコーディングのデメリットの多くは、AI の性能ではなく、作ったものを判断する人がいないことから生まれる
- デメリットは5つ。データの丸見え、鍵の漏れ、悪用されて請求が膨らむ、の3つは公開前に確かめられる
- 欲しいものと違うものができる、あとから直せない、の2つは、AI に任せる前に要件とルールを決めることで防ぐ
- 実際の事故の多くは、ログアウトして試す、上限をかける、といった基本の確認で防げた
- 10項目で×や「分からない」が残ったら、公開の前に一度、専門家に見せる
AI で作れるようになったことで、作るまでの時間は大きく縮みました。その分、作ったものを確かめる時間を、公開の前に少しだけ取ってください。
