非エンジニアのためのバイブコーディング:2026年に安全に作れるもの

2026年、非エンジニアがバイブコーディングで安全に作れるものは大幅に増えました。ただし、はっきり線を引けます。その線より下にあるのは、プロトタイプ、ランディングページ、社内ツール、ログインとデータベースを備えたシンプルなアプリです。線より上にあるのは、独自の決済ロジック、医療や金融の記録、複数の企業が共用するアプリ、そして本格的なトラフィックを受けるものです。これらは今もエンジニアが必要です。

利用者層はすでに広がっています。Lovableによると、ビルダーの80%が自分を非技術者だと答えており、ウェブサイトだけでなく、社内ツール、CRM、ストアフロントにも使われています(The Next Web)。そして失敗も一緒に増えました。今年、UpGuardは、こうしたアプリの多くが基盤にしているバックエンドSupabase上で、インターネット上の誰でも読めるテーブルを持つデータベースを16,326件見つけました(UpGuard)。Veracodeは4年にわたり100以上のAIモデルをテストしており、AIが書いたコードのセキュリティ合格率は平均56%だとしています。同社の言葉を借りれば「変わっていません」(Veracode)。

被害の大半は、コードを読まなくても確認できるひとつのミスに行き着きます。尋ねてきた相手に誰でもデータの行を渡してしまうデータベースです。これを直し、秘密鍵をブラウザに置かないようにすれば、創業者、マーケター、アナリストが作りたいもののほとんどは問題なく作れます。

2026年のバイブコーディングとは

作りたいものを普通の言葉で伝えると、ツールがコードを書き、ライブプレビューで操作を確かめ、次の変更を頼む。この繰り返しです。非エンジニア向けのツールは、いまや画面づくりをはるかに超えています。データベース、サインアップの仕組み、ホスティングまで作るので、午後いっぱいプロンプトを書けば、実際のアカウントを持つアプリができあがります。

この図は、出口がひとつだけあるループとして読んでください。みんなが飛ばしてしまうのが、その出口です。

破線の矢印がテストから出ているのには理由があります。生成されたコードは読んでも判断できませんが、動作なら判断できます。2つ目のアカウントから1つ目のアカウントのレコードが見えないか、ログインなしでページが開かないか、といった点です。テストがお金、他人の非公開データ、本格的なスケールに触れるなら、そこで手を止めて、コードを読める人に頼んでください。

今年は大きな動きがありました。Lovableは1回のビルドメッセージを最大10時間実行できるようになり、タスクが終わるまで動き続ける/goalコマンドも追加しました。こちらは料金がかなり高めです(Lovable changelog)。Replitは並列エージェントを備えたAgent 4をリリースし、AIはFree Modeと有料のPower・Maxモードで動くようになりました。VercelはGitHubのブランチとプルリクエストを軸にv0を作り直し、同社のプロダクト責任者は、実際の作業の90%は既存のコードベースの変更だと述べています。WixのBase44は独自モデルBase1をトレーニングしました。創業者は、いずれ最先端モデルよりも高速かつ低コストで顧客に提供できるようになると見込んでいます。

Google AI Studioは、アプリにデータベースやログインが必要だと判断し、承認すると両方のためにFirebaseをセットアップします。従来のビルダーであるFirebase Studioは終了予定のため、それを前提にしたチュートリアルはすでに古くなっています。

リスクのはしご:自分だけで作れるもの

リスクは2つの要素で上がります。アプリが誰のデータを持つか、そしてお金が動くかどうかです。架空のレコードだけのプロトタイプは、何も漏らしようがありません。他人のメールアドレスを預かるサインアップアプリは漏らす可能性があり、今年も多くの事例がありました。

このはしごは、よくあるプロジェクトをリスクで並べたものです。下の3段は誰でも作って構いません。琥珀色の段は、今年の漏えいの大半が起きた場所です。

クリックできるプロトタイプ、問い合わせフォーム付きのランディングページ、チーム限定の社内ツールが最適なゾーンです。プロトタイプは、チケットを切る前に「これを作るべきか」の答えをくれます。営業や運用チーム向けの社内トラッカーは、誰も信用していないスプレッドシートの代わりになります。ワークスペース限定でログイン付きにしておけば、悪用しうるのは同僚だけです。簡単な自動化もこの段ですが、n8nやZapierのようなワークフローツールなら、アプリを作らずに済むことも多いです(ワークフロー自動化ボードも参照)。

アカウントを持つ顧客向けアプリが琥珀色の段です。ツールはこれを問題なく作れます。問題は、データベースのルールがひとつ間違っているだけで全ユーザーが一度に露出することです。作ったら、本物のユーザーが登録する前に、エンジニアにレビューを依頼してください。

上の2段はエンジニアの領域です。まず決済です。Stripeのホスト型チェックアウトを開く購入ボタンなら問題ありません。カード情報はStripeに直接送られ、アプリを通らないからです。Stripe自身のセキュリティガイドは、カードデータを直接扱う事業者はPCI DSSの300以上のセキュリティ要件を満たす必要があるかもしれないと警告しています。従量課金や、複数の企業が1つのデータベースを共有するアプリは、どちらも認可ロジックに依存します。AI製アプリで破綻が見つかり続けているのが、まさにそこです。

もうひとつは規制対象のデータです。LovableのエンタープライズFAQによると、同社はBAA(業務提携契約)を結ばず、HIPAAに準拠しておらず、保護対象の医療情報をアップロードしないよう求めています。医療、金融、子どものデータには法的な義務が伴い、公開前のスキャンではカバーしきれません。

いま重要なツールと、それぞれの課金方法

この読者層のニーズのほとんどは5つのビルダーでカバーできます。違いは、作れるものよりも課金の仕組みと、乗り換えやすさにあります。Boltとv0が、Lovable、Replit、Base44と並びます。価格は各社の料金ページにある、最初の有料プランです。

ほとんどの非エンジニアには、Lovableが無難な第一候補です。メッセージごとのコストの例を公開しており、公開のたびにセキュリティ問題をスキャンし、コードは無料プランを含むどのプランでもGitHubに同期できます。Base44は、コードを一切見たくない人向けですが、後述のハンドオーバーの節で触れる注意点がひとつあります。Replitは、アプリ、スライド、データダッシュボードをひとつのワークスペースで扱いたい人に向いており、Free Modeは始めるうえでもっとも手軽な方法です。Boltは、使うときだけ集中して作る人向けです。使い切れなかった有料トークンが1か月繰り越されるからです。v0は、すでに会社でVercelにデプロイしていて、エンジニアがプロジェクトを引き継ぐ場合に向いています。

従来のノーコードにも、ビジュアルエディタで似た領域をカバーするものが2つあります。Bubbleはウェブアプリとモバイルアプリを作れ、Glideはスプレッドシートをアプリに変えます。下のライブボードで、カテゴリ全体の現在のランキングを確認できます。また、AIアプリビルダーまとめでは、その中の十数種をさらに詳しく取り上げています。

このボードには開発者向けのビルダーも含まれています。ツール探しにはボードを、予算の検討には表をお使いください。

クレジットが想定より早く減る理由

いまやこれらのツールはどれも、送ったメッセージではなく、AIが行った作業に対して課金します。小さな修正なら公平ですが、曖昧な依頼では高くつきます。

Lovableは最も分かりやすい例を公開しています。「ボタンをグレーにして」は0.50クレジット、「認証を追加して」は1.20、「画像付きのランディングページを作って」は2.00で、プランモードのメッセージは1クレジットです(Lovable)。1回のビルドメッセージが何時間も動くようになったため、Lovableは1メッセージが20クレジットを超えた時点で一度確認のために停止します。この設定は引き上げたりオフにしたりできます。Proの追加購入は50クレジットで$15、つまり1クレジットあたり$0.30で、100クレジットのプラン内の$0.25より割高です。

ほかのツールも、名前は違っても仕組みは同じです。Boltのヘルプセンターによると、トークン消費の大半はプロジェクトファイルの読み込みと同期によるもので、同じプロンプトでもアプリが大きくなるほど高くなります。v0は、チャット履歴とソースファイルを入力トークンとして数えます。Base44は、メッセージごとの固定コストはなく、一般的な変更は約0.5〜4クレジットだとしています。ReplitのFree Modeは枠内なら無料ですが、PowerとMaxモードは月ごとのクレジットを消費し、追加のクレジットパックは購入から6か月で失効します。

Lovableの料金の階段を見ると、予算にどう響くかが分かります。

ボリュームディスカウントはほとんどありません。800クレジットまではどの階層も1クレジットあたり$0.25で、2,000クレジットの階層でも$0.24です。プロンプトの量を2倍にすれば請求も2倍になるので、効くのは無駄なメッセージを減らすことです。

無駄の大半は修正ループから生まれます。AIが何かを壊し、その修正がまた別の何かを壊し、そのたびに課金されます。先に計画を立てると効果的です。Lovableのプランモードのメッセージは一律1クレジットで、Boltも、プランモードは何も変更しないのでトークン消費が少ないとしています。ボタン操作も有効です。Boltによると、ボタンでバージョンを公開・復元するのは無料ですが、AIに頼むとトークンを使います。セッションがおかしな方向に進んだら、プロンプトで切り抜けようとせず、チェックポイントまで戻してください。

下の見積もりツールに、自分の使い方を入れてみてください。Lovableのコスト例に基づいているため、見積書ではなく予算の目安として扱ってください。

初期設定では月に約162クレジットが必要で、$50の階層でまかなえます。やり直しを60%まで上げると、安いほうの選択肢である$25プラン+追加購入でも$70まで上がります。上限も設定しましょう。Lovableの自動チャージは「上限なし」ではなく月ごとの支出上限を指定でき、Replitでも含まれるクレジットを超える支出に上限を設定できます。クレジット制がまだ分かりにくければ、AIツールの料金モデルの解説記事でクレジット、シート、トークンを順に説明しています。

インシデントの記録が指すひとつのミス

今年のインシデント報告を並べてみると、同じ失敗が繰り返し出てきます。巧妙なハッキングではありません。尋ねてきた人には誰にでも答えてしまうデータベースです。

UpGuardの調査では、Supabaseの兆候を示すドメインが約30万件あり、そのうち16,326件のデータベースで読み取り可能なテーブルが露出し、半数以上に個人データの兆候がありました(UpGuard)。その説明は具体的です。コーディングエージェントがSupabaseとやり取りする方法であるAPI経由で作ったテーブルには、デフォルトで行レベルセキュリティが有効にならないのです。SupabaseのセキュリティチーフはTechCrunchに対し、プロジェクトはデフォルトで安全であり、セキュリティは責任共有だと述べました。

AIエージェント向けのSNS、Moltbookは、創業者が「コードを1行も書いていない」と語っていましたが、ページ内にSupabaseのキーを置いたまま、行レベルセキュリティのポリシーなしで公開されました。Wizの研究者は、150万件のAPIトークン、3万5,000件のメールアドレス、数千件の非公開メッセージにアクセスできました。チームは連絡を受けて数時間後にパッチを当てました(Wiz)。

研究者のTaimur Khan氏によると、Lovableでホストされたあるアプリが、1万8,697件のユーザーレコードを露出させ、その数千件は学生アカウントでした。同氏はアクセスチェックが逆に書かれていることを発見しました。「ガードは通すべき人をブロックし、ブロックすべき人を通している」(The Register)。Lovableは、公開前に無料のセキュリティスキャンを提供しており、それに対応するかどうかはユーザー次第だと述べ、脆弱なデータベースはLovableがホストしておらず、プロジェクトにはLovableが生成していないコードが含まれていたと説明しました。

プラットフォーム側も無傷ではありません。年の後半には、無料のLovableアカウントで、他人の公開プロジェクトからソースコード、データベースの認証情報、AIのチャット履歴を取得できることを研究者が示しました。Lovableは当初、この挙動は意図的で仕様どおりだと説明しました。その後、ドキュメントが不明瞭だと指摘するだけでは不十分だったと認め、「改善します」と述べ、公開プロジェクトのチャットにアクセスできないようAPIにパッチを当てたと発表しました(The Register)。セキュリティ企業のRedAccessは、Lovable、Base44、Replit、Netlifyで作られた一般公開のアプリを約38万件確認し、そのうち約5,000件が機密データを露出していたとしています。ReplitのCEOは、公開アプリにアクセスできるのは想定どおりの挙動であり、プライバシーはワンクリックで設定できると応じました。

研究結果も、反対側から同じことを示しています。Veracodeの長期テストは、モデルが賢くなってもほとんど改善していないことを示しています。

Veracodeの2026年のラウンドで最良だったモデルでさえ、セキュリティ課題の3つに1つ近くで失敗し、コーディング特化モデルも汎用モデルより優れてはいません。スタートアップのTenzaiによる別の調査では、5つのコーディングエージェントで15個のアプリを作らせ、69件の脆弱性が見つかりました。最も深刻なのは認可とビジネスロジックに関するもので、古典的なインジェクションのバグはまったく出てきませんでした。これはインシデントの内容と一致します。AIは動くコードを書きますが、指示しない限り、誰に使わせるべきかは考えません。

行レベルセキュリティを平易に説明すると

この方式で作られたアプリは、ブラウザから直接データベースに接続することがよくあります。使うのは、設計上公開されているキーです。見知らぬ人がそのキーですべてを読めないようにするのが行レベルセキュリティで、誰が何を読み書きできるかを行ごとに決める、データベース内のルールです。Lovableの内蔵バックエンドもBoltのデータベースも、Supabaseと同じモデルであるこのPostgresのルールを使っています。

Supabaseのドキュメントははっきり書いています。公開スキーマにあってRLSのないテーブルは「権限を付与されたどのロールからでも読み書きできる」(Supabase)。RLSを有効にすると、ポリシーが許可するまで公開キーでは何も見えません。ポリシー自体は短いものです。次のものは、ビルダーが注文テーブル用に書くはずの種類のポリシーで、ログイン中のユーザーが自分の行だけを読めるようにします。

create policy "Users read their own orders"
on orders for select
to authenticated
using ( (select auth.uid()) = user_id );

自分で書く必要はありません。ただし、すべてのテーブルにポリシーがあることは必ず確認してください。シークレットキー、つまり「サービスロール」キーはこのルールをすべて無視するので、ブラウザのコードには絶対に置かないでください。また、「このユーザーは管理者か」のような確認を含め、フロントエンドにあるものはすべて、使っている本人が書き換えられます。Lovableのドキュメントが、フロントエンドのコードにセキュリティ判断をさせてはいけないとしているのはそのためです。

安全な構築プロセスをステップごとに

この順序なら、ミスのコストを低く抑えられます。最後のステップまではダミーデータを使い、本物のユーザーが入るのは最後だけです。

1. 1最初のプロンプトの前に、1ページの仕様書を書く。誰が使うアプリか、5〜6個の画面、ユーザーの種類ごとに見て変更できる内容、対象外とするものを書きます。プランモードに貼り付けて、穴を探すようツールに頼みましょう。
2. 2ダミーデータでプロトタイプを作る。架空のレコードで画面とフローを作り、プロジェクトは非公開のまま、実際に使う人に見せます。方向転換は、変更のコストがメッセージ1通で済む今のうちにしましょう。
3. 3データモデルを平易な言葉で説明する。レコードの種類(顧客、注文、メモ)とそれぞれの持ち主を挙げ、ツールにテーブルを作らせたうえで、誰が行を読み書きできるかをテーブルごとに説明させます。答えが「誰でも」になっているものがあれば、先に進む前に直してください。
4. 4サインアップと権限を同じステップで追加し、ルールを読み返す。たとえばBase44は、「注文を送信した本人だけがそれを見られるようにする」のような文章でルールを書けます。
5. 52つのアカウントとダミーデータでテストする。AliceとBobとして登録します。Bobとして、Aliceのレコードを開いてみる、アドレスバーのレコード番号を書き換える、ログアウトした状態でアプリを使う、を試します。見えてはいけないものにBobが届いたら、コードがどうなっていようとバグです。
6. 6セキュリティの確認を行う。内蔵スキャンを使い、重大な指摘はすべて直したうえで、次の節のチェックリストを順に確認します。Boltのフル監査は、Publishメニューから実行する場合はトークンを消費しません。アプリが顧客の個人データを扱うなら、ここでエンジニアにレビューしてもらいます。
7. 7制限をかけて小さく公開する。まず少数の実ユーザーを招待し、支出上限を設定し、バックアップとロールバックが動くことを確認して、ダミーアカウントを削除します。

自分のアイデアがどの段にあたるか分かりませんか。下のツリーなら、3つ以内の質問で答えが出ます。

ツリーの結果がエンジニアへの相談になっても、プロトタイプは無駄になりません。動くモックアップと仕様書は、開発者に渡せる最も分かりやすい依頼内容です。

公開前のセキュリティチェックリスト

テストアカウント以外の誰かにリンクを渡す前に、これを実行してください。どれもコードを読む必要はありません。確認する設定、実行するスキャン、行うテストのいずれかです。

効果が大きいのは2項目です。すべてのテーブルの行レベルセキュリティは、ビルダーのデータベースまたはセキュリティ画面で確認できます。Boltは、全員を通してしまう「常に真」のルールにフラグを立てます。2つ目のアカウントでのテストは、上のLovableアプリで起きた逆向きのアクセスチェックのように、スキャナーが見逃すものを拾います。

残りはすぐ終わります。Boltは漏えいパスワード保護をデフォルトでオンにし、Lovableは公開前スキャンで、オフならフラグを立てます。Lovableでは、VITE_プレフィックスが付いた名前のものはブラウザに出てしまうので、秘密鍵には絶対に付けないでください。

スキャンには限界があり、ベンダー自身もそう認めています。Lovableのドキュメントは、自社のツールは「完全なセキュリティを保証できない」と述べ、機密データを扱うアプリには専門家によるレビューを勧めています。Base44のドキュメントはもっと簡潔で、アプリのセキュリティ設定の責任はユーザーにあるとしています。

プロジェクトを開発者に引き継ぐ

うまく動くバイブコーディングのアプリは、遅かれ早かれエンジニアが必要になります。レビューのためにも、引き継いで管理するためにもです。ハンドオーバーは初日から計画しておきましょう。

GitHubリポジトリは早めに接続してください。Lovableの双方向同期は全プランで使え、開発者はリポジトリをクローンして自分のエディタで作業を続けられます。Base44の双方向同期はBuilderプランからです。v0では接続したリポジトリが正となるソースになり、変更は元のブランチに直接ではなく作業用ブランチにプッシュされます。BoltもコミットをGitHubに同期します。

コードに含まれないものを把握しておきましょう。Lovableのドキュメントによると、Git同期にもコードのダウンロードにも、データベース内のデータは含まれません。他所でホストするためのガイドでは、ストレージのファイルは手作業で移すことになっています。Base44は、プラットフォームに縛られるものはなく、GitHub同期で完全なソースをエクスポートできるとしています。一方で開発者向けドキュメントには、エクスポートしたプロジェクトがデータやバックエンド関数のためにBase44独自のサービスへアクセスするSDKが載っています。これは私たちの解釈でBase44の主張ではありませんが、Base44から完全に移行するには、このレイヤーの置き換えが必要になるかもしれません。

開発者には、短いハンドオーバー資料を渡してください。

• 仕様書。すべての画面と、それぞれを使える人を記載したもの。
• リポジトリとビルダープロジェクトへのアクセス権。
• 各テーブルと、誰が読み書きできるべきかを平易な言葉で書いた一覧。
• 追加した連携と、それが使うシークレットの名前。値そのものはチャットやメールに書かないこと。
• 既知のバグ、プロンプトで入れた妙な回避策、これまでにプロジェクトで使ったクレジット。

新機能の前にセキュリティレビューを依頼しましょう。アクセスルール、サーバー側の関数、シークレットの置き場所を見てもらいます。多くの開発者は、CursorやClaude Codeのようなコーディングツールでリポジトリを開きます。これらがアプリビルダーとどう違うかは、コーディングアシスタントまとめとAIコーディングアシスタントとエージェントビルダーの比較で、市場全体のランキングはAIコーディングアシスタントボードで確認できます。

よくある質問

バイブコーディングツールが書いたコードは自分のものになりますか?

Lovable、Base44、Bolt、v0は、いずれも自分で管理するGitHubリポジトリにコードを同期できます。Base44はBuilderプランからです。ただし、コードを所有することと、稼働中のアプリを所有することは同じではありません。データ、保存したファイル、バックエンドサービスは、誰かが移行するまでプラットフォーム上に残る場合があります。

始めるなら、どのバイブコーディングツールがいちばん安いですか?

5つとも無料枠があります。Lovableの無料ユーザーには1日5ビルドクレジット(月上限30)が付き、ReplitのFree Modeは無料プランと有料の個人プランで使え、上限はプランによって決まります。有料プランでは、Base44のStarterが年払いで月額$16、Replit Coreが月額$20です。

バイブコーディングで作ったアプリで決済を受け付けられますか?

はい、ホスト型チェックアウトを使えば可能です。LovableのStripe連携はStripe Checkoutを開き、シークレットキーはアプリのコードではなくバックエンドのシークレットとして保存します。まずはサンドボックスキーとStripeのテストカードでテストしてください。従量課金、他のユーザーへの支払い、複数企業のアカウントへの課金は、エンジニアの領域です。

AIは自分のコードのセキュリティを確認できますか?

部分的には可能です。内蔵スキャンは、アクセスルールの欠落、露出したキー、脆弱なパッケージといった一般的な問題を拾います。ただし、スキャンではセキュリティを保証できないとベンダー自身が述べており、1万8,697件のレコードを漏らしたアプリも、公開前の無料スキャンを提供するプラットフォーム上にありました。スキャンは最低ラインであって、合格のお墨付きとは考えないでください。

Firebase Studioはどうなりましたか?

Googleは終了させる予定です。すでに新しいワークスペースは作成できず、2027年にクローズします。Googleは、既存のワークスペースをGoogle AI StudioまたはAntigravityに移行できるとユーザーに案内しています。FirestoreやAuthenticationなどのFirebaseサービスは、これまでどおり続きます。