「AIに指示したらアプリが動いた。でも、このまま顧客や社員に使わせてよいのか分からない」。バイブコーディングやノーコードでアプリを作れるようになった今、公開する前のセキュリティ対策が、作る人の仕事になりました。実際、Webアプリの代表的な弱点をまとめた OWASP Top 10 の2025年版では、「設定の誤り（設定不備）」が前回の5位から2位に上がり、調べたアプリのすべてに何らかの設定の誤りがあったとされています。
本記事では、AIで作ったアプリに多い穴5つ、公開前に自分で確かめる手順と確認表、Bubble・Lovable・Claude Code などツール別の設定、AI機能を組み込んだときの注意、公開後の運用と漏えいが起きたときの対応を解説します。ノーコード全般のセキュリティの基本は、「ノーコード セキュリティの基本と実践」で解説しています。
「動いた」と「守られている」は別です。公開する前に、ログアウトした状態で自分のアプリを開いてみてください！
※本記事の統計・制度・各ツールの設定名と初期状態は、2026年10月7日時点の公的機関の資料と各社の公式ドキュメントにもとづきます。ツールの設定名や初期状態は変わることがあるため、操作の前に公式ページで確かめてください。
バイブコーディング・ノーコードで作ったアプリは、なぜ危ないのか
AIが作ったアプリが危ないのは、AIが「動くこと」を優先して作る一方で、「誰が見られるか」「鍵をどこに置くか」「誰に公開するか」「入力をどう確かめるか」という守りの設定は、作る人が決めないと決まらないからです。
バイブコーディングとは？
AIに言葉で指示して、コードやアプリを作ってもらう作り方のことです。Lovable・Bolt・v0・Replit のようなAIアプリビルダーや、Claude Code・Codex のようなコーディングエージェントで行います。本記事では、Bubble などのノーコードツールにAIで作らせる場合も含めて扱います。
「動く」と「守られている」は別
IPA の「情報セキュリティ10大脅威 2026」では、組織向けの脅威の3位に「AIの利用をめぐるサイバーリスク」が初めて入りました。解説書は、AIサービスであっても「基盤インフラにおける設定ミスや認証不備といった従来型の脆弱性は依然として重要な攻撃経路になりえます」とし、「AIの生成したプログラムコードには脆弱性が含まれる場合がある」と書いています。AIを使っていても、昔からある設定ミスやログインの不備といった弱点（脆弱性）が狙われる、ということです。
ツールの公式ドキュメントも同じことを言っています。Bubble のマニュアルは、利用者の端末に届いたデータは、画面に表示していなくても利用者から見える、と説明しています。つまり「画面で隠す」は守りにならず、データ側で「誰が見られるか」を設定する必要があります。
突かれるのは基本的な穴
攻撃者が突くのは、高度な脆弱性より基本的な設定の穴です。OWASP Top 10:2025 では、1位が「アクセス制御の不備」（見てよい人を絞る設定の漏れ。他人のデータが見える・操作できる）、2位が「設定不備」（設定の誤り）です。個人情報保護委員会の令和7年度の年次報告も、不正アクセスによる漏えいの原因として、脆弱性の放置、推測されやすいID・パスワードと並べて「設定ミスによりデータベースへのアクセス制御が不適切な状態になっていたこと」を挙げています。
総務省の「クラウドの設定ミス対策ガイドブック」には、ファイル共有の公開範囲を誤って「リンクを知っているインターネット上のすべての人」にした例や、申込フォームの設定ミスで他の参加者の個人情報が見えた例が載っています。同じガイドブックは「デフォルト値が安全とは限らない」とも書いています。
設定不備（Security Misconfiguration）とは？
初期設定のまま使う、不要な機能を有効にしたまま公開する、公開範囲を広くしすぎるなど、設定の誤りや漏れで生まれる弱点のことです。コードの欠陥ではなく、設定で起きるので、非エンジニアでも見つけて直せます。
中小企業も狙われている
「小さな会社のアプリは狙われない」とは言えません。警察庁の2025年の報告では、ランサムウェアの被害226件のうち中小企業が約6割を占め、復旧に総額1,000万円以上かかった組織が5割を超えました。不正アクセスの認知件数は7,190件で前年より約34%増え、検挙した手口で最も多かったのは「パスワードの設定・管理の甘さにつけ込んで入手」でした。
東京商工リサーチの調査では、2025年に上場企業とその子会社が公表した個人情報の漏えい・紛失事故は180件で、原因の64.4%が「ウイルス感染・不正アクセス」です。一方、IPA の2024年度の調査では、中小企業の約7割がセキュリティ対策に「投資していない」か「わからない」と答えています。
バイブコーディングで作ったアプリに多い「穴」5つ
AIで作ったアプリに多い穴は、①他人のデータが見える ②鍵が画面やコードに残る ③公開範囲が「全員」のまま ④ログインや管理画面の素通り ⑤入力のチェックがない、の5つです。どれも、コードを読めなくても設定を見れば確かめられます。
穴 | 起きること | AIがやりがちな原因 |
|---|---|---|
他人のデータが見える | 会員が別の会員の情報を見たり、書き換えたりできる | 動かすことを優先して、「誰が見られるか」の設定（Bubble のプライバシールール、Supabase の RLS）をしない、または全員に許可する |
鍵が画面やコードに残る | 外部サービスの鍵（APIキー）が盗まれ、他人の利用料を払わされる・データを取られる | 鍵を、利用者のブラウザに届くコードや、誰でも見られる GitHub の置き場（公開リポジトリ）に書く |
公開範囲が「全員」のまま | 社内用のアプリやデータに、URLを知る人なら誰でも入れる | ツールの公開設定やデータベースの公開設定を、初期状態のまま公開する |
ログインや管理画面の素通り | ログインなしで会員ページや管理画面が開く | テスト用にログインを外したまま、テスト用の全許可のルールのまま公開する |
入力のチェックがない | フォームに細工した文字列を入れられ、データを抜かれる・書き換えられる | 入力のチェックを画面側（ブラウザ）だけで行う、入力をそのままデータベースへの命令に使う |
穴1 他人のデータが見える（権限の設定漏れ）
最も影響が大きいのが、データの権限の設定漏れです。Bubble ではプライバシールール、Lovable や Bolt などが連携する Supabase では RLS（行レベルセキュリティ）がこれにあたります。Supabase の公式ドキュメントは、公開しているデータの表（テーブル）で RLS を有効にしていないと、プロジェクトのURLを知っている人なら誰でもデータを読み書きできる状態になると説明しています。Lovable の公式ドキュメントも、RLS ポリシーの欠落が、アプリのデータが外部に見えてしまう最も多い原因だとしています。
OWASP が1位に挙げる「アクセス制御の不備」の典型が、URL や、画面の裏でやり取りされるデータの番号（ID）を書き換えて、他人のデータを開く手口です。対策は、画面ではなくデータ側で「このデータは誰が見られるか」を決め、許可していないものは断る設定にすることです。
認可（アクセス制御）とは？
ログインした人が「何を見てよいか・何を変えてよいか」を判定する仕組みのことです。ログイン（本人確認）とは別のもので、ログインできても他人のデータが見えるなら、この設定が足りていません。
プライバシールールと RLS とは？
データの行ごとに「誰が見られるか・変えられるか」を決める設定のことです。Bubble では「プライバシールール」、Supabase などのデータベースでは「RLS（Row Level Security）」と呼びます。画面の表示条件とは別に、データ側で効きます。
穴2 鍵（APIキー）が画面やコードに残る
AIにサービスを連携させると、APIキーを扱います。OpenAI の公式ヘルプは、APIキーをブラウザやスマホアプリなど利用者の手元で動く部分に置かないよう明記しています。GitHub も、コードの置き場（リポジトリ）が非公開でも、鍵をコードに書かないよう求めています。Bubble では、外部サービスとつなぐ API Connector で鍵の欄を private にすると、鍵はサーバー側にだけ保存され、利用者からは見えません。
鍵が漏れると、他人があなたの契約で AI を使い、その利用料があなたに請求されることがあります。OpenAI は、インターネット上に公開された鍵を見つけると、すぐに無効化するとしています。見つかるまでの間に使われる分を防ぐには、鍵を公開しないことと、利用料の上限の設定が必要です。
APIキー（シークレット）とは？
外部のサービスを呼ぶときに使う、合言葉のような文字列のことです。パスワードと同じで、見られた時点で他人が使えます。コードや画面に書かず、ツールの「Secrets」や「環境変数」に入れて、サーバー側からだけ使います。
穴3 公開範囲が「全員」のまま
ツールやデータベースには「誰がアクセスできるか」の設定があり、初期状態が広い側になっているものがあります。公式ページに明記されている例を挙げます。
- Bubble：外から呼び出せるワークフロー（API workflow）は、作った時点で外部に公開される設定になっている
- Lovable：Free と Pro のプランで公開したアプリは、リンクを知る人なら誰でも開ける
- Bolt と Replit（個人用の作業スペース）：公開時の初期設定が Public
- Dify：作った Web アプリは初期状態で公開
- Google スプレッドシート：共有を「リンクを知っている全員」にすると、URL が広まれば誰でも見られる
社内だけで使うつもりのアプリでも、公開範囲が「全員」なら、URL を知った人は誰でも入れます。
穴4 ログインや管理画面の素通り
AIは、動作を確かめるためにログインを一時的に外したり、「全員に許可」のテスト用ルールを書いたりすることがあります。それを戻さずに公開すると、会員ページや管理画面が素通りになります。Firebase の公式ドキュメントは、テストモードのルールは誰でもデータを読み書きできる状態だと説明しています。Bubble のテスト版（公開前に確かめるための、アプリの別の版）もユーザー名とパスワードで守れますが、初期値のままだと Bubble の点検機能（Security dashboard）が問題として知らせます。
穴5 入力のチェックがない
フォームの入力欄に細工した文字列を入れると、データベースの中身を抜かれたり（SQLインジェクション）、ほかの利用者のブラウザで勝手な処理が動いたり（クロスサイト・スクリプティング）することがあります。どちらも、IPA の「安全なウェブサイトの作り方」が、届け出の多い脆弱性や影響の大きい脆弱性として取り上げている項目です。OWASP は、画面側（ブラウザ）だけの入力チェックはすり抜けられるので、サーバー側でも確かめるよう勧めています。
AIで作ったアプリを公開前に自分で確かめるには？（非エンジニア向けの手順）
専門知識がなくても、次の4つは自分で確かめられます。①ログアウトした状態で開く ②画面の中身に鍵や他人のデータが混ざっていないか見る ③フォームに変な値を入れる ④ツールのスキャン機能を使う、の順です。
手順1 ログアウトした状態で開く
ブラウザのシークレットウィンドウ（プライベートウィンドウ）で、次のURLを直接入力します。
- 会員だけが見るページ（マイページ、ダッシュボード）
- 管理者だけが見るページ（管理画面、設定画面）
- 他人のデータのURL（自分のデータのURLの、ID の部分を別の数字に変えたもの）
ログインしていないのに中身が表示されたら、穴1か穴4です。Supabase の公式ブログの公開前チェックリスト（2025年8月）にも、ログアウトした状態で非公開ページのURLを直接開く確認が入っています。
手順2 画面の中身に鍵や他人のデータが混ざっていないか見る
ブラウザで右クリック→「ページのソースを表示」を開き、ページ内検索（Windows は Ctrl＋F、Mac は Command＋F）で「sk-」、「key」、「token」、「secret」 を探します。長い英数字の文字列が見つかったら、穴2の可能性があります。
Bubble の公式チェックリストも、ページの要素やワークフローに機密情報を置かないよう求めています。
次に、ブラウザの開発者ツール（Windows は F12、Mac は Command＋Option＋I）を開き、「ネットワーク」タブを選んだまま、自分のデータを表示するページを操作します。サーバーから届いたデータ（応答）の中に、自分以外の人の名前やメールアドレスが入っていたら、穴1です。
手順3 フォームに変な値を入れる
入力欄に、空のまま、長い文章、記号（「'」 「"」 「<」 「>」）、HTMLタグ（「<b>test</b>」）、他人のIDを入れて送信します。エラーの画面にデータベースの内部の情報が出たり、入れたタグがそのまま画面に効いたりしたら、穴5です。
手順4 ツールのスキャン機能を使う
多くのツールに、セキュリティの問題を検出する機能があります。使えるプランは製品によって異なります。
ツール | スキャン機能（公式の名称） | 使える条件（2026年10月7日時点） |
|---|---|---|
Bubble | Security dashboard（20以上の項目を検出） | Starter 以上の有料プラン |
Lovable | Quick scan（公開時に自動）、Deep scan（手動） | 無料プランでも実行できる。「Block publishing with critical issues」は初期設定でオフなので、オンにする |
Bolt | Security Audit（データベースの設定の検出）、公開時の security audit（検出と自動修正） | Security Audit タブは全プラン。公開時の security audit は有料プラン |
Replit | 有料プラン（アプリが使っている部品＝依存パッケージの点検は無料） | |
Supabase | Security Advisor（RLS が無効なテーブルを警告） | プランの記載なし |
Claude Code | 「/security-review」 コマンド | Claude Code を使えるプラン（無料プランでは使えない） |
Codex | Pro・Business・Enterprise・Edu |
Lovable や Codex の公式ページも、スキャンや AI のレビューは人のレビューの代わりではないとしています。とくに「他人のデータが見える」設定の穴は、スキャンが見つけられないことがあるため、手順1と手順2は自分の目で確かめてください。
AI にレビューを頼むときは、次のように具体的に指示します。コピーして、そのまま使えます。
AI に貼るセキュリティ確認の指示文（例） |
|---|
このアプリのセキュリティを確認してください。①ログインしていない人や、別の利用者が、他人のデータを見たり変えたりできる箇所 ②APIキーやパスワードが、ブラウザ側のコードや公開リポジトリに含まれている箇所 ③テスト用に緩めたままの権限や公開設定 ④入力のチェックがブラウザ側にしかない箇所、を、該当するファイル名と設定名を添えて列挙してください。直し方も提案してください。 |
AI の回答は、見落としや誤りを含むことがあります。列挙された箇所を自分で開いて確かめ、直したあとに手順1〜3をもう一度行います。
ツールのスキャンが「問題なし」でも、他人のデータが見える設定は見つけられないことがあります。手順1と2は自分の目で確かめてください！
公開範囲は段階で広げる
いきなり一般公開せず、公開する相手を段階で広げると、穴が見つかったときの影響を小さくできます。
段階 | 公開する相手 | この段階で確かめること |
|---|---|---|
1 | 自分だけ | 手順1〜4。テスト用のデータで動かす |
2 | 社内の数人 | 権限の違う人（管理者・一般）で、見えてはいけないものが見えないか |
3 | 顧客の一部 | 本番のデータを入れる前に、バックアップと戻し方、問い合わせ先を決める |
4 | 一般公開 | 作成者アカウントの2段階認証、利用料の上限、ログの確認方法 |
公開前チェック表のひな形
下の表は Opt.dev で作成したひな形です。表計算ソフトに写し、公開の前に「確かめること」を1行ずつ確認して、結果と対応を記入して使います。
確かめること | 確かめ方 | 「×」のときの対応 |
|---|---|---|
ログアウトした状態で、会員ページ・管理画面が開かない | シークレットウィンドウでURLを直打ち | ログイン必須の設定を戻す。公開範囲を絞る |
URLのIDを変えても、他人のデータが出ない | 自分のデータのURLのIDを変える | プライバシールール・RLS を、データの持ち主だけに絞る |
ページのソースに鍵がない | 「sk-」 「key」 「token」 「secret」 で検索 | 鍵を Secrets・環境変数に移し、漏れた鍵は無効化して作り直す |
応答に他人のデータが混ざらない | 開発者ツールの「ネットワーク」で応答を見る | データ側の権限を絞る。必要な項目だけ返す |
公開範囲が、想定した相手だけになっている | ツールの公開設定、データベースの公開設定 | Private・社内限定・パスワードなどに変える |
テスト用の設定を戻した | ログインの省略、全許可のルール、テストモード | 本番の設定に戻し、テスト用の設定は削除 |
権限の設定が、全部のデータ（テーブル）にある | Bubble のプライバシールール、Supabase の RLS の一覧 | 設定のないデータに追加。Security Advisor などで再確認 |
フォームに変な値を入れても壊れない | 空・長文・記号・HTMLタグ・他人のID | サーバー側の入力チェックを足す |
作成者アカウントの2段階認証がある | ツールと、Google・Microsoft などの管理アカウント | 2段階認証（できればパスキー）を有効にする |
バックアップと戻し方が分かる | 復元できる期間と手順を公式ページで確認 | ツールの復元機能（戻せる期間はプランで異なる）か、定期的な書き出し |
次のようなときは、外部に相談するのも一つの方法です。確認表が途中でもかまいません。
- 設定の場所が分からず、○か×か判断できない
- 「×」が付いたが、直し方が分からない
- 顧客の個人情報や決済を扱うので、自分の確認だけでは不安
- AIに直させたら、別の画面や機能が動かなくなった
AI・ノーコードで作ったアプリの公開前チェックの無料相談
Bubble公式認定エージェンシー（Silver Agency）の Opt.dev が、使っているツール・公開する相手・困っている項目をお聞きし、点検と直す順番を整理します。点検・修正の作業の範囲と費用は、お話を伺ってからご案内します。
無料で相談してみる
ツール別に何を確かめる？公開前の設定一覧
どのツールにも「誰が見られるか」「鍵の置き場所」「公開範囲」の設定があります。初期状態が安全側か危険側かはツールで違うので、使っているツールの行を確かめてください。かっこの中は、画面で探すときの設定名（公式の表記）です。
ツール | 公開前に確かめる場所 | 初期状態で注意すること（公式ページに明記のあるもの） |
|---|---|---|
Bubble | データの見える範囲（Data › Privacy のプライバシールール）／外から呼べるワークフローの公開設定（Settings › API と、各 API workflow の Expose as a public API workflow）／テスト版のパスワード | 外から呼べるワークフローは、作った時点で公開される。API token はプライバシールールを無視して全データを見られる。点検機能（Security dashboard）は Starter 以上 |
Lovable | 公開前の点検（Quick scan・Deep scan）／重大な問題があるときに公開を止める設定（Block publishing with critical issues）／Supabase の RLS／鍵の保管場所（Secrets）／公開範囲 | 重大な問題があっても、警告だけで公開できる（止める設定は初期状態でオフ）。Free・Pro は、公開したアプリをリンクを知る人なら誰でも開ける |
Bolt | 公開範囲（Public／Private）／点検機能（Security Audit）／鍵の保管場所（Secrets） | 公開範囲の初期設定は Public。公開時の自動点検と修正は有料プラン |
v0・Vercel | 鍵の名前の頭に「NEXT_PUBLIC_」を付けない／公開したページをログインやパスワードで守る設定（Deployment Protection） | 「NEXT_PUBLIC_」を付けた鍵はブラウザに届き、誰でも見られる。新しいプロジェクトは、公開したページにログインが必要な設定（Vercel Authentication）が初期状態でオン。本番のURL（「*.vercel.app」）は公開される |
Replit | 公開範囲（Who can access）／鍵の保管場所（Secrets）／重大な問題があるときに公開を止める設定（Block publishing of critical vulnerabilities） | 個人用の作業スペース（ワークスペース）は、公開範囲の初期設定が Public。AI による点検は有料プラン |
Claude Code・Codex | AI に読ませないファイルの指定（Claude Code の permissions.deny に「Read(./.env)」のように書く）／点検コマンド（「/security-review」）／Codex のネットワーク接続 | Claude Code の自動で進めるモード（auto mode）は「安全を保証しない」と公式が明記。Codex のネットワーク接続は初期状態でオフ |
Supabase | すべての表（テーブル）の RLS／鍵の使い分け（secret key をブラウザに置かない）／点検機能（Security Advisor） | 画面から作った表は RLS がオン、命令文（SQL）で作った表はオフ。2026年10月30日から、既存のプロジェクトでも新しく作る表は外部（Data API）に自動で公開されなくなる |
Firebase | データの読み書きのルール（Security Rules）。テストモードのまま公開しない | テストモードは誰でも読み書きできる（期限付き）。AI が作ったルールの確認は利用者の責任、と公式が明記 |
GitHub | 鍵のファイル（「.env」）を上げない設定（「.gitignore」）／鍵の混入を止める機能（push protection） | 公開リポジトリでは、鍵の検出と混入を止める機能が無料。非公開リポジトリでは有料 |
サーバー側とブラウザ側とは？
アプリの処理のうち、利用者のブラウザで動く部分（ブラウザ側）と、ツールのサーバーで動く部分（サーバー側）のことです。ブラウザ側に届いたものは、画面に出ていなくても利用者から見えます。鍵や権限の判定は、サーバー側に置きます。
環境変数（Secrets）とは？
鍵やパスワードを、コードに書かずにツールに預けておく仕組みのことです。Lovable・Bolt・Replit は「Secrets」、Vercel は「Environment Variables」、Bubble は API Connector の private パラメータがこれにあたります。
Bubble で確かめる3か所
Bubble で作ったアプリは、次の3か所を公開前に確かめます。
1. データの見える範囲（Data › Privacy のプライバシールール）：データの種類ごとに、誰が見られるかを決めます。プライバシールールで止められるのは、主に「見る・探す」ことです。ワークフローでの書き換え（Make changes to a thing）は止まらないので、ワークフローの条件（Only when）で本人だけに絞ります。
2. 外から呼べるワークフロー（Settings › API と、各 API workflow の設定）：外から呼び出せるワークフロー（API workflow）は、作った時点で公開される設定です。外から呼ばせないものは、各ワークフローの公開の設定（Expose as a public API workflow）を外し、呼ばせるものは認証（Authentication）を設定します。外部サービスに渡す API token は、プライバシールールを無視して全データを見られるので、外に渡さないでください。
3. パスワードとテスト版（Settings › General）：利用者のパスワードの条件、利用者向けの2段階認証（Growth 以上）、テスト版を守るユーザー名とパスワード（初期値から変える）を確かめます。
Bubble AI で作ったアプリも同じです。Bubble の公式ブログは、Bubble AI Agent（ベータ）が、機密情報を含みそうなデータ型にはプライバシールールを既定で付けられるとしたうえで、「AIは間違えることがあるので、ルールがアプリの要件に合っているか確認する」よう書いています。公式の公開前チェックは、プライバシールールの見直し、漏れた鍵の点検、公開ページの点検、権限ごとの見え方の確認、通信の暗号化（HTTPS）の確認、不正利用への対策の6項目です。
これから Bubble での開発を会社に頼む場合に、開発会社へ伝えることは「Bubbleのセキュリティは大丈夫？開発前に知っておきたい対策と、開発会社に相談すること」で解説しています。
AIコーディングツールで作るとき
Lovable・Bolt・v0・Replit で作ったアプリは、裏側のデータベースの設定が守りの中心です。Supabase を使う場合、画面から作った表（テーブル）は RLS がオンですが、AI が命令文（SQL）で作った表はオフのことがあります。すべての表で RLS がオンになっていて、読む・書く・消すといった操作ごとにルールがあるかを確かめてください。Supabase は2026年10月30日から、既存のプロジェクトでも新しく作る表を外部（Data API）に自動で公開しない仕様に変わります。
Claude Code や Codex で作る場合は、AI に渡す権限も確かめます。Claude Code の設定（permissions.deny）に、鍵が入ったファイル（「.env」など）を指定すると、Claude Code のファイル読み取りや、cat などのよく使うコマンドでは読めなくなります。別のプログラムを使った読み取りまで止めるには、AI の作業範囲を区切る機能（サンドボックス）を有効にします。Codex は、ネットワークへのアクセスが初期状態でオフです。コードを GitHub に置くなら、鍵のファイルを上げない設定（「.gitignore」 に 「.env」 を書く）をし、公開リポジトリでは鍵の混入を止める機能（push protection）を使います。
AI機能を組み込んだアプリでは何に気をつける？
アプリに AI を呼ぶ機能（チャット、要約、自動返信など）を入れると、「AI に入れる情報」と「AI にさせる操作」という2つの入口が増えます。
AI に入れてはいけない情報は？
IPA の「AI利用者のためのセキュリティ豆知識」は、最初の対策として「クラウドAIに営業秘密は教えない」を挙げ、サービスの規約と設定を確かめて、入力を学習の対象から除外するよう勧めています。入力した情報の扱いは、製品・プラン・設定によって異なります。OpenAI と Anthropic は、API 経由の入出力を既定ではモデルの学習に使わないとしていますが、個人向けのチャットのプランでは設定によって学習に使われることがあります。
個人情報を AI に入れる場合は、個人情報保護委員会の注意喚起のとおり、利用目的の範囲内かを確かめ、提供事業者がそのデータを学習に使わないことを確認してください。
外から来た文章で AI が動かされる
AI にメールや Web ページを読ませると、その中に仕込まれた指示で AI が動かされることがあります（間接プロンプトインジェクション。用語の説明は「AIエージェントとは？」を参照してください）。OWASP の LLM アプリ向け Top 10（2026年版）では、1位が「プロンプトインジェクション」、2位が「機密情報の漏えい」、3位が「過剰な自律性」（AI に権限を持たせすぎること）です。IPA の解説書も、これを完全に防ぐ技術的対策は知られていない、としています。
対策は、入口を小さくすることです。
- AI に渡す情報を、その処理に必要なものだけに絞る
- 送信・削除・購入・外部への投稿は、AI だけで実行させず、人が承認してから実行する
- AI を呼ぶ API キーはサーバー側に置き、利用料の上限（OpenAI の Monthly spend limit、Anthropic の Spend limits など）を設定する
AI に権限を渡しすぎない
IPA の産業サイバーセキュリティセンターの人材育成プログラムの成果物「生成AIおよびAIエージェントを安全に活用するための手引書」には、メールの読み書きと削除の権限を与えた AI エージェントが、数百通のメールを削除した例が載っています。原因は、過剰な権限と、実行前の人の承認を仕組みとして組み込んでいなかったことでした。OWASP の AI エージェント向けのチートシートも、ツールごとに最小の権限を与え、メールの送信・データベースの削除・送金など、影響の大きい操作や取り消せない操作は、人の承認を必須にするよう勧めています。
公開後の運用と、漏えいが起きたらどうする？
公開したあとは、作成者のアカウントを守ること、戻せる状態を保つこと、漏えいが起きたときの手順を決めておくことの3つが要ります。
公開後に続けること
- 作成者アカウントの2段階認証：ツールのアカウントと、Google・Microsoft などの管理アカウントに2段階認証を設定します。IPA はパスキーの利用を、総務省はパスワードの使い回しをやめ、パスワード管理ツールを使うことを勧めています。定期的な変更は不要です
- 共同編集者の権限：退職や契約終了のときに、アカウントを削除します。Bubble の Collaborators は Growth 以上で使えます
- バックアップと戻し方：復元できる期間はツールとプランで違います。Bubble は、データベースを過去の時点に戻せる期間がプランによって異なります。復元できないツールでは、定期的にデータを書き出します
- 利用料の上限：AI や外部サービスの利用に上限を設定し、鍵が漏れたときの被害を抑えます
- 鍵の更新：鍵を作り直す手順を決め、漏えいの疑いがあれば即座に無効化します
- 設定の見直し：ツールの仕様変更で初期設定が変わることがあります。IPA の「情報セキュリティ6か条」の4番目は「共有設定を見直そう！」です
漏えいが起きたら何をする？
個人データの漏えいが起きたときの流れは、次のとおりです。
流れ | やること | 期限・備考 |
|---|---|---|
1 止める | 公開を止める、鍵を無効化する、アカウントのパスワードを変える | すぐに |
2 範囲を確かめる | 何のデータが、いつから、誰に見える状態だったかを記録する | ログと設定の履歴から |
3 報告する | 速報は概ね3〜5日以内、確報は30日以内（不正な目的の場合は60日以内） | |
4 通知する | 本人へ、概要・項目・原因などを分かりやすい方法で通知する | 事態に応じて速やかに |
5 再発を防ぐ | 原因になった設定を直し、確認表に項目を足す | — |
報告と本人への通知は、2022年4月1日から、すべての個人情報取扱事業者の義務です（個人情報取扱事業者に、会社の規模の要件はありません）。対象は、要配慮個人情報（病歴や信条など、特に配慮が要る情報）を含むもの、財産的な被害のおそれがあるもの、不正な目的によるもの（不正アクセスなど）、1,000人を超えるものの4つの類型です。2026年7月17日に公布された改正法（公布から2年以内に施行）では、課徴金の導入や罰則の引き上げが決まっています。
漏えい等報告とは？
個人データの漏えい・滅失・毀損（外に漏れる・なくす・壊す）が起きたとき、個人情報保護法にもとづいて個人情報保護委員会へ報告し、本人へ通知する義務のことです。報告の対象になる4つの類型と期限が決まっています。
困ったときの相談先
- ノーコードや AI の開発に詳しい会社：アプリの設定の点検と直し方は、使っているツールに詳しい開発会社に相談します。次の章で、自分で直せる範囲と外部に頼む範囲を整理します
- サイバーセキュリティお助け隊サービス：中小企業向けに、相談窓口・異常の監視・駆けつけ支援・簡易なサイバー保険をひとまとめにした、IPA の制度に登録されたサービスです。基本の類型（1類）では、ネットワーク監視型は月額1万円以下（税抜）が価格の要件です（価格の要件を緩めた2類サービスもあります）
日頃の対策に取り組んでいることを示す制度として、IPA の SECURITY ACTION もあります。相談窓口ではなく、「情報セキュリティ6か条」などに取り組むことを自ら宣言する制度です。宣言すると、補助金の申請要件を満たす場合があります。
SECURITY ACTION とは？
中小企業が、情報セキュリティ対策に取り組むことを自ら宣言する IPA の制度のことです。一つ星は「情報セキュリティ6か条」への取り組み、二つ星は自社診断と基本方針の公開を宣言します。IPA が認定する制度ではないので、「宣言した」と表現します。
自分で直せる範囲と、専門家に頼む範囲は？
設定の確認と変更は自分でできます。コードの中の弱点を漏れなく探す作業と、顧客データ・決済・医療など影響の大きいアプリの診断は、専門家に頼む範囲です。
作業 | 自分で | ツールのスキャンで | 専門家に |
|---|---|---|---|
権限・公開範囲・鍵の置き場所の確認と変更 | ○ | △（検出のみ） | — |
ログアウト・ID書き換え・変な値の確認 | ○ | — | — |
コードの中の弱点を漏れなく探す | — | ○（警告のみ、見落としあり） | ○ |
顧客データ・決済・医療情報を扱うアプリの診断 | — | — | ○ |
社内ルールと運用（誰が止める・誰が鍵を持つ） | ○ | — | △（整理の支援） |
外部に頼むときは、使っているツールに詳しいかに加えて、何を点検するか、直したあとにどう確かめ直すか、確かめられなかった項目をどう報告してもらえるかを確認します。設定の記録と手順書が残るか、公開後の見直しをどの頻度で行うかも確かめておきましょう。
依頼するときは、目的・対象・頼みたいこと・今回は含めないことを1〜2文で伝えると、話が早く進みます。
依頼の例（想定例です） |
|---|
顧客向けに公開する前に、Bubble で作った会員サイトの「誰が見られるか」の設定を点検し、問題のある箇所の修正と、別の利用者のアカウントでの確認までお願いしたい。新しい機能の追加は今回は含めない。 |
AI を使ったアプリ開発の進め方は「AI×ノーコードでアプリ開発」で、Bubble AI の機能と注意点は「Bubble AI完全ガイド」で解説しています。
設定を直してもらったら、別の利用者のアカウントで開いて「見えないこと」を確かめた結果まで受け取ってください！
バイブコーディングのセキュリティに関するよくある質問
Q. バイブコーディングで作ったアプリは危険？
作り方そのものより、公開前の設定で決まります。AI は動くことを優先して作るため、権限・鍵・公開範囲の設定は作る人が確かめる必要があります。本記事の手順1〜4と確認表を使えば、非エンジニアでも主な穴は自分で見つけられます。
Q. AI に入力してはいけない情報は？
営業秘密、顧客の個人情報、パスワードや APIキーです。IPA は「クラウドAIに営業秘密は教えない」を最初の対策に挙げています。入力した情報の扱いは製品・プラン・設定によって異なるので、業務で使う前に、学習に使われない設定やプランになっているかを公式ページで確かめてください。
Q. Bubble・Lovable・Claude Code で作ったアプリは安全？
ツール自体に安全対策はありますが、アプリの安全は設定次第です。Bubble はプライバシールールと API の公開設定、Lovable は Supabase の RLS と公開範囲、Claude Code は AI に与える権限と鍵の置き場所が要点です。初期状態が危険側の設定もあるので、「ツール別に何を確かめる？公開前の設定一覧」の表で確かめてください。
Q. 情報漏えいで一番多い原因は？
東京商工リサーチの2025年の調査では、上場企業の漏えい事故の64.4%が「ウイルス感染・不正アクセス」でした。個人情報保護委員会は、不正アクセスの原因として、脆弱性の放置、推測されやすいパスワード、設定ミスによるアクセス制御の不備を挙げています。AIで作ったアプリでは、「誰が見られるか」の設定漏れと、鍵が見える場所に残ることが、この「設定ミス」にあたります。
Q. 公開前に最低限やることは？
ログアウトした状態で会員ページと管理画面が開かないこと、URL の ID を変えても他人のデータが出ないこと、ページのソースに鍵がないこと、公開範囲が想定した相手だけになっていること、の4つです。これだけで、多い穴5つのうち4つを確かめられます。
Q. 漏えいしたら何をすればよい？
まず公開を止めて鍵を無効化し、何のデータがいつから誰に見える状態だったかを記録します。要配慮個人情報を含む、財産的な被害のおそれがある、不正アクセスによる、1,000人を超える、のいずれかに当たれば、個人情報保護委員会への報告（速報は概ね3〜5日以内）と本人への通知が義務です。
まとめ｜バイブコーディングのセキュリティは「権限・鍵・公開範囲」を自分の目で確かめることから
バイブコーディングのセキュリティ対策は、コードを読むことではなく、権限・鍵・公開範囲の設定を自分の目で確かめることから始まります。要点を振り返ります。
- AIで作ったアプリに多い穴は、他人のデータが見える・鍵が残る・公開範囲が全員・ログインの素通り・入力のチェックなし、の5つ
- 公開前に、ログアウトして開く・ソースと応答を見る・変な値を入れる・スキャンを使う、の4つを自分で行う
- ツールの初期状態は安全側とは限らない。使っているツールの設定を公式ページで確かめる
- AI 機能を入れたら、渡す情報を絞り、送信・削除・購入は人が承認する
- 作成者アカウントの2段階認証と、戻せる状態を保つ。漏えいが起きたら、止めて・記録して・報告する
今の状況 | 次の一手 |
|---|---|
AIでアプリを作った直後 | 手順1〜4と確認表を一通り行う。テスト用の設定を戻す |
社内で使い始める | 公開範囲を社内限定にし、権限の違う人で見え方を確かめる |
顧客に使わせる | 本番データを入れる前に、バックアップ・戻し方・漏えい時の手順を決める |
AI 機能を入れた | 渡す情報と操作の範囲を絞り、利用料の上限を設定する |
まずは、シークレットウィンドウで自分のアプリの会員ページを開くところから始めてみてください。
本記事の情報は2026年10月7日時点のものです。各ツールの設定名と初期状態、制度の条件は変わることがあるため、操作や申請の前に公式ページで確かめてください。
AI・ノーコードで作ったアプリの公開前チェックの無料相談
Opt.dev では、公開前の点検、権限設定の点検と修正、公開後の設定の見直し、AIで作ったアプリの作り直しや機能追加まで相談を受け付けています。無料相談では、使っているツールと困っている項目をお聞きし、進め方を整理します。点検・修正などの作業の範囲と費用は、お話を伺ってからご案内します。
無料で相談してみる
引用元
- 公的機関：IPA「情報セキュリティ10大脅威 2026」 ／ 同 解説書（組織編） ／ IPA「安全なウェブサイトの作り方」 ／ IPA「中小企業の情報セキュリティ対策ガイドライン」 ／ IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」 ／ IPA「AI利用者のためのセキュリティ豆知識」 ／ IPA「生成AIおよびAIエージェントを安全に活用するための手引書」 ／ IPA「インターネットサービスへの不正ログインによる被害が増加中」（2025年8月28日） ／ IPA「サイバーセキュリティお助け隊サービス」 ／ IPA「サイバーセキュリティお助け隊サービス 制度説明資料」 ／ IPA「SECURITY ACTION」 ／ IPA「SECURITY ACTION 制度概要」 ／ IPA「2024年度 中小企業における情報セキュリティ対策に関する実態調査」 ／ IPA「2024年度 中小企業における情報セキュリティ対策に関する実態調査」概要説明資料 p.5 ／ 総務省「クラウドの設定ミス対策ガイドブック」 ／ 総務省「安全なパスワードの設定・管理」 ／ 警察庁「サイバー空間をめぐる脅威の情勢等」 ／ 警察庁「令和7年におけるサイバー空間をめぐる脅威の情勢等について」 ／ 警察庁「不正アクセス行為の発生状況」 ／ 個人情報保護委員会「漏えい等報告・本人への通知の義務化について」 ／ 個人情報保護委員会「漏えい等の対応とお役立ち資料」 ／ 個人情報保護委員会「改正法の概要」（2026年7月） ／ 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」 ／ 個人情報保護委員会 令和7年度年次報告
- 国際団体・調査会社：OWASP Top 10:2025 ／ OWASP「A01 Broken Access Control」 ／ OWASP「A02 Security Misconfiguration」 ／ OWASP Top 10 for LLM Applications 2026 ／ OWASP Cheat Sheet Series ／ OWASP「Input Validation Cheat Sheet」 ／ OWASP「AI Agent Security Cheat Sheet」 ／ 東京商工リサーチ「上場企業の個人情報漏えい・紛失事故（2025年）」
- Bubble：Security ／ Security checklist ／ Protecting data with privacy rules ／ Bubble「Client-side and server-side」 ／ Bubble「API Connector security」 ／ Bubble「Workflow API security」 ／ Bubble「Data API security」 ／ Bubble「App security」 ／ Bubble「Security dashboard plan features」 ／ Bubble「Collaborators」 ／ Bubble「Restoring database backups」 ／ Bubble「Data tab」 ／ 公式ブログ「AI-Generated Code Security」 ／ 公式ブログ「No-Code Security」 ／ Bubble「Opt.dev」（公式の開発会社紹介ページ）
- AIコーディングツール：Lovable「Security」 ／ Lovable「Connect to Supabase」 ／ Lovable「Publish」 ／ Lovable「Project security view」 ／ Lovable「Privacy and security settings」 ／ Lovable「Secrets」 ／ Bolt「Security Audit」 ／ Bolt「Publishing your project」 ／ Bolt「Secrets」 ／ v0「Security」 ／ Vercel「Deployment Protection」 ／ Vercel changelog（2023年11月2日） ／ Vercel「How to lock down deployments」 ／ Replit「Security overview」 ／ Replit「Who can access your app」 ／ Replit「Project Security Center」 ／ Replit「Secrets」 ／ Dify「Web App Settings」 ／ Claude Code「Security」 ／ Claude Code「Commands」 ／ Claude Code「Permission modes」 ／ Claude Code「Configure permissions」 ／ Codex「Agent approvals & security」 ／ Codex「Security Review」
- データベース・共通：Supabase「Row Level Security」 ／ Supabase「Advisors」 ／ Supabase「API keys」 ／ Supabase「Hardening the Data API」 ／ Supabase changelog（2026年4月28日） ／ Supabase 公式ブログ「The Vibe Coding Master Checklist」（2025年8月16日） ／ Firebase「Firebase Security Rules」 ／ Firebase「Avoid insecure rules」 ／ Firebase「Basic Security Rules」 ／ Firebase「Add Firebase to your Google AI Studio app」 ／ GitHub「Secret scanning」 ／ GitHub「Keeping your API credentials secure」 ／ GitHub「Push protection」 ／ OpenAI「Best Practices for API Key Safety」 ／ OpenAI「Keeping your OpenAI account secure」 ／ OpenAI「Your data」 ／ OpenAI「Spend limits」 ／ Anthropic「Authentication」 ／ Anthropic「Is my data used for model training?」 ／ Anthropic「Mitigate jailbreaks and prompt injections」 ／ Google ドライブ ヘルプ「ファイルを共有する」 ／ Google「2段階認証プロセスを有効にする」
