AIでアプリを作る「バイブコーディング」は安全？初心者が公開前に知るべき注意点

プログラミングを学んだことがなくても、AIに言葉で頼めば、画面のあるアプリが動き、公開までたどり着けるようになりました。

では安全なのか。答えは、誰が触れるアプリかで変わります。自分のパソコンの中だけで動かす試作なら、気をつけることは多くありません。URLを公開し、他人のデータや課金されるAPIキーを扱うなら話は別です。危ないのはAIそのものより、動いているように見えるコードを、誰も中身を確かめないまま世に出すことです。

「コードの存在を忘れる」から始まった言葉

バイブコーディング（vibe coding）は、AI研究者のアンドレイ・カルパシー氏が2025年2月、Xへの投稿で使った言葉です。雰囲気に身を任せ、コードがあることさえ忘れる、という趣旨でした。英コリンズ英語辞典は2025年11月、これを2025年の「今年の言葉」に選んでいます。

プログラマーのサイモン・ウィリソン氏は、これを「書かれたコードを確認せずにLLMでソフトウェアを作ること」と絞り込みました。人が読み、テストし、説明できるなら、AIが書いたコードでも普通の開発だという整理です。同氏は、向くのは失敗しても困らない小さな試作だとしています。

「動いた」は安全の証明ではない

コード検査ツールを販売するVeracodeは2025年7月、自社の調査として、100以上のLLMに80の課題を解かせ、45%のケースでOWASP Top 10に分類される脆弱性が入ったと発表しました。課題の選び方に左右される数字ですが、「動いたから大丈夫」とは言えません。

そのOWASP Top 10の2025年版で1位（A01）は「アクセス制御の不備」です。他人のデータが見えてしまうような欠陥は画面の見た目に現れず、自分で動かしてみるだけでは見落としがちです。

初心者がつまずく5つの場所

APIキーをコードに書き込む

AIの機能や決済に使うAPIキーをコードに書いて公開すれば、他人に使われて請求が来るおそれがあります。GitHubは、公開された秘密情報は自動スキャナーに数分で見つかりうるとし、漏れたらまず発行元でキーを無効化するよう案内しています。コードから消すだけでは足りません。

ブラウザに届くコードも要注意です。Next.jsでは、名前がNEXT_PUBLIC_で始まる環境変数はブラウザ向けのJavaScriptに埋め込まれます。ReplitのSecretsやVercelのSecret型の環境変数のように、キーをコードの外に置く仕組みを使います。

鍵のかかっていないデータベース

ブラウザから直接データベースにつなぐ構成では、権限設定がそのまま防壁です。Supabaseは、公開されるスキーマの全テーブルで行レベルセキュリティ（RLS）を有効にし、秘密鍵はブラウザで使わないよう求めています。

2025年5月に公開された脆弱性情報CVE-2025-48757は、AIアプリ作成サービスLovableで2025年4月15日までに生成されたサイトについて、RLSの設定が不十分なため、未認証の第三者が任意のテーブルを読み書きできるとする内容です。Lovableは、データを守る責任は各利用者が負うとして異議を唱えており、記録にも「disputed（異議あり）」と付いています。いずれにせよ、確かめるのは作った本人です。

存在しないパッケージ

AIは、実在しないライブラリ名をもっともらしく挙げることがあります。2025年8月のUSENIX Securityで発表された研究は、16のモデルで生成した57万6,000件のコードを調べ、架空のパッケージの割合が商用モデルで平均5.2%以上、オープンなモデルで21.7%以上だったと報告しました。OWASPのLLM向けTop 10（LLM09）は、よく現れる架空の名前で攻撃者が悪意あるパッケージを公開する手口を挙げています。入れる前に、npmやPyPIなどの公式の配布サイトで実在と利用実績を確かめます。

エージェントが消してしまう

ファイル編集やコマンド実行まで任せるエージェント型ツールでは、事故の規模が変わります。2025年7月、Replitの利用者が、コードの凍結を指示していたのにAIエージェントが本番データベースを削除したとXで報告し、英The Registerなどが報じました。Replitは開発用と本番用のデータベースを分ける仕組みを導入し、現在のドキュメントでは、エージェントは本番データベースを変更できないとしています（構造の変更は公開時に本番へ反映）。

OWASPのLLM向けTop 10は、AIに必要以上の権限を与える危険を「過剰なエージェンシー」（LLM06）と呼び、権限の最小化と、影響の大きい操作への人の承認を勧めています。Claude Codeのドキュメントも、承認前の確認は利用者の責任だとしています。

他人の個人情報を預かる

会員機能や申し込みフォームを作れば、名前やメールアドレスを預かります。個人情報保護委員会によると、民間の事業者は、個人データの漏えい等（おそれを含む）が「要配慮個人情報を含む」「財産的被害が生じるおそれがある」「不正の目的によるおそれがある」「本人が1,000人を超える」のいずれかに当たると、委員会への報告が義務づけられています。速報は発覚日から3〜5日以内、確報は30日以内（不正の目的によるおそれがあれば60日以内）です。小さな店の予約ページでも、事業として個人データを扱うなら無関係ではありません。

公開前に確かめる7つのこと

• APIキーやパスワードをコードや、ブラウザに届く変数に入れていないか
• 公開リポジトリに.envなどの設定ファイルが含まれていないか
• ログアウトした状態や別のアカウントで、他人のデータが見えないか
• AIが追加したパッケージが実在し、広く使われているか
• エージェントに本番データやPC全体を触らせていないか
• データベースのバックアップと、元に戻す手順があるか
• 個人情報や決済を扱うなら、経験のある人にレビューを頼んだか

GitHubやクラウドのアカウントが乗っ取られれば、どの対策も崩れます。二段階認証やパスキーも設定しておきます。IPAの「安全なウェブサイトの作り方」は代表的な脆弱性と対策をまとめ、チェックリストも付いています。AIに点検を頼むのも手ですが、その結果もまた確かめる対象です。

どこまで任せてよいか

自分用の道具、学習のための試作、すぐ捨てるデモまでは、バイブコーディングの手軽さがそのまま生きます。URLを人に渡すなら、鍵の置き場所とデータの見え方を確かめる。不特定多数に公開し、個人情報やお金を扱うなら、それはもう「雰囲気で書くコード」の範囲を出ています。書く速さはAIが上げてくれても、何を守るかを決めるのは作る人です。