バイブコーディングのセキュリティリスクとは？12個のアプリで脆弱性を検証

2026年10月31日 18:19

はじめに：AIで作った社内アプリは、そのまま使って安全か

社内の案件管理や日報を、AIで作っていないでしょうか。エンジニアでない経営者が、Claude Codeで1か月に社内アプリを13本作ったという事例もあります（@DIME、2026年8月3日）。コードを書かずに、AIに言葉で指示してアプリを作る流れはバイブコーディングと呼ばれ、ここ最近急速に広がっています。

一方で、セキュリティ面で不安になる調査結果もあります。2026年に公開された研究では、バイブコーディングで作られた公開アプリ200件のうち182件で脆弱性が見つかりました（後述のVibe-Coding調査）。この数字を見ると、AIで作ったアプリをそのまま使っていると、問題が起きそうで心配になります。

そこで、今回はClaude Codeで社内向けの案件管理アプリを実際に作り、脆弱性を確認しました。プロンプト（AIへの指示文）を変えて12個作り、アプリの脆弱性に関する確認するべき16項目を1つずつ試しています。その結果、作成したアプリで、16項目のうち1項目（12個のアプリのうち2個）にセキュリティ上の弱点がありました。 その弱点とは、ログイン回数の制限でした。大抵の場合、AIはプロンプト内で定義していないセキュリティ上の対策も行っていますが、完璧な対策とは言えません。この記事では、社内でAIを使ってアプリを作るときに自分で確かめるべきことをまとめます。

1. バイブコーディングに潜むセキュリティリスク

バイブコーディングとは、利用者がコードを自分で読み書きする代わりに、AIに自然言語で指示してアプリを作る開発手法です。手早く作れる反面、できたコードの中身を人が見ないまま使うと、問題が起きても気づけません。

1-1. 代表的な脆弱性と情報漏洩のリスク

2026年のVibe-Coding調査（Deng ほか、後述）は、公開アプリ200個を調べ、182個（91.0%）で脆弱性を見つけました。調査した200個のアプリ全体で、脆弱性は合わせて1,186件見つかりました（1つのアプリから複数見つかることもあるからです）。多かったのは次の3種類です。

これらの脆弱性は、問題が起きたときに非常に深刻になります。例えば、アクセス制御の不備があれば、ある営業担当が、ほかの担当の顧客名や商談金額を全部見られますし、一般社員が管理者の画面を開けば、原価や利益率、全社の売上まで見えてしまいます。認証の不備で、パスワードがそのまま保存されていれば、アプリのデータが一度外部に漏れただけで、使い回されている別のサービスのパスワードまで一緒に危険にさらされるのです。ログインの回数に制限がなければ、時間をかけて総当たりでパスワードを当てられます。どれも、顧客の個人情報と売上を扱うアプリでは、絶対に起こってはいけません。

1-2. AIが生成したコードでも脆弱性が発生する理由

Vibe-Coding調査は、脆弱性が入り込む原因を8つに分類して、整理しています。たとえば、次のようなものです。

UI/UXを優先して、仮の鍵や権限の仕組みをそのまま本番にも適用してしまう
エラーが出たときに、原因を直さず、安全の仕組みのほうを外して消してしまう

など、、、

なかには、プロンプト自体が危ない例もあります。指示ファイル（CLAUDE.md）に「APIキーをコードに書き込み、簡単な暗号でずらして隠せ」と指示したアプリでは、AIはその通りに実装していました。AIは渡したルールに従うので、ルールを渡すなら指示ファイルの中身も確かめる必要があります。
この8つの分類で最も多いのが、利用者が指示しなかった安全策を省いてしまう型です。パスワードをハッシュにして保存する、サーバー側で権限を確かめる、といった、プロンプトに書かれていなくても必要な対策が抜けます。

1-3. 既存研究で報告されている問題：BaxBenchの報告

ここまでは1つの調査の話ですが、「動くこと」と「安全なこと」が別だという点は、ほかの研究でも裏づけられています。AIでサーバー側のプログラムを作って安全性を測ったBaxBench（Vero ほか、後述）では、機能が正しく動いたプログラムの約半分で、攻撃が通りました。正しく動くからといって、中身まで安全とは限らないということです。

2. Claude Codeで作成した12個のアプリをセキュリティ検証

この章でやることは3つです。

Claude Codeで、同じ社内アプリをプロンプトを変えて12個作る
できた12個を1つずつ動かし、脆弱性に関する確認するべき16項目を同じ手順で試す
どのプロンプトだと、どの脆弱性が残るかを検証する

題材は、営業が顧客と案件を登録し、管理者が全ての案件と月別の売上を見る案件管理アプリです。実際に、営業の商談でも「見積や案件の管理をAIで自作したい」という相談が多く、現場に近い題材です。

結論としては、12個のアプリで、脆弱性16項目のうち検出されたのは1項目だけでした。ほかの項目は、今回の検査ではどのアプリでも検出されませんでした（SQLインジェクションは、SQLを使う4個に実際に試して問題なし、残り8個はSQLを使わず該当なしです。内訳は2-3で説明します）。

2-1. 4種類のプロンプトと検証条件

アプリは、検証用とは切り離して立ち上げたClaude Codeで作りました。会話の履歴や個人の設定を読み込まない状態で、空のフォルダに作っています。モデルはClaude Sonnet 5.5で、実行したコマンドは会社のホームページの記事の付録6-1に、全文を載せています。

プロンプトだけを変えて、ほかの条件はそろえました。プロンプトは次の4通りで、それぞれ3個ずつ（1個だけでは、たまたまの出来かプロンプトの傾向か分からないため）、合わせて12個を作りました。

A 短く頼む：社員がふだんチャットで頼むような、短いプロンプト。
B 技術的に詳しく頼む：使うライブラリやデータの持ち方まで指定した、仕様書のようなプロンプト。
C 本番用と伝える：Aに「社内で本番運用する」と2文だけ足したプロンプト。
D 守るルールを渡す：Aと同じプロンプトに、守るべきセキュリティのルールを書いた指示ファイル（CLAUDE.md）を添える。

4つのプロンプトの全文は、会社のホームページの記事の付録6-2に載せています。A〜Cは、参考研究が調べたプロンプト（短いプロンプト、技術的に詳しいプロンプト、本番用と伝えるプロンプト）に対応させました。Dは、Aと同じプロンプトに、守るべきセキュリティのルールを書いたファイル（CLAUDE.md）を添えたものです。

セキュリティの手順をまとめたファイル（スキル）をAIに渡すと、特定の脆弱性の再発が25.7%から11.9%に減り、Cのように本番用と伝えると減った一方、Bのように技術的に詳しく書くと逆に増える、という研究（後述のVibe-Coding調査の再現実験）が報告されています。ただし、この研究はClaudeではなく別のモデルを使い、すでにあるコードに機能を1つ足して、特定の1か所の脆弱性が再び出るかを見たものです。ゼロから作って16項目を検証する今回とは条件が違うため、数字をそのまま並べて比べることはできませんが、今回は、同じ傾向が別の条件でも見られるかという目安として参照します。

公平に比べるため、プロンプト以外の条件はそろえました。モデルはすべてClaude Sonnet 5.5で固定し、アプリの機能（営業・管理者・案件・売上）も同じにしています。起動の仕方も、どのアプリも同じコマンドで立ち上がるようにそろえました。そのうえで、同じアプリをプロンプトごとに3個ずつ作り、同じプロンプトの中でのばらつきも見られるようにしています。

2-2. 16項目の脆弱性チェック方法

作成した12個のアプリは、同じ方法で脆弱性16項目を検査しました。検査のスクリプトは会社のホームページの記事の付録6-3にあります。判定は、リクエストが通ったかや、保存データ・コードの中身を自動で調べて決めています。

16項目は、1章で挙げた脆弱性の種類に沿って用意しました。主なものを挙げます。

ログインせずにデータが見える、一般社員が管理者の機能を使える（アクセス制御）
SQLインジェクション、入力したプログラムが他人の画面で動くXSS（インジェクション）
パスワードがそのまま保存されている、ログイン失敗の回数に制限がない、弱いパスワードが通る（認証）
外部サイトからの書き込みを防ぐCSRF対策が働かない、案件の持ち主を他人に付け替えられる、エラーで内部の情報が漏れる（作りの細かい不備）

もし検査スクリプトの作りが甘ければ、脆弱性があっても見逃し、本当は危ないのに安全に見えてしまいます。

そこで、わざと穴だらけのサンプルを1つ用意しました。ログインなしでデータが見える、他人の案件が見える、パスワードを平文で保存する、ログイン回数の制限がない、秘密の値をコードに書き込む、入力した文字がそのまま画面で動く、といった脆弱性を、1つずつ意図的に仕込んだものです。このサンプルに同じ検査を当てたところ、該当する15項目すべてで脆弱性ありと検知できました。検査が正常に働いていることは、これで確かめられます。ただし、穴だらけのサンプルは1つだけで、穴の作り方も1通りです。12個のアプリでほぼ穴が出なかったのは、この検査で見つかる形の穴がなかったという意味で、穴がないことの証明ではありません。

2-3. 検証結果と判明した問題

実際に作成してみると、プロンプトによって、できたアプリの作り込みにはっきりと差が出ました。Aは、外部のライブラリを使わないNode.jsだけの小さなアプリで、ファイル数は5個から9個ほど。Bは、指定したとおりExpressとSQLiteを使い、ファイル数は17個前後と最も多くなりました。Cは、本番用と伝えたためか、自動テストまで付いて作業の手数が最も多く、1個あたり8分から11分。Dは、Aに近い小ぶりな作りのまま、渡したルールに沿って安全策を入れていました。

16項目の検査を12個のアプリに当てた結果、脆弱性が見つかったのはログイン失敗の回数に制限がないという1項目だけでした。しかも12個のうち2個です。

この2個は、どちらもプロンプトBで作ったアプリでした。パスワードを何度間違えても、しばらくログインできなくなる仕組みがなく、総当たりでパスワードを試せる状態でした。

ほかの項目は、今回の検査では12個のどのアプリでも検出されていません。具体的に見ると、ある営業担当のアカウントで、ほかの担当の案件を開こうとしても、権限がないとして拒否されます。一般社員のアカウントで管理者の売上画面や社員の追加を試しても、通りません。ログインしていない状態で案件の一覧を取りに行っても、データは返ってきませんでした。

パスワードはすべてハッシュ化して保存されており、保存ファイルを探してもそのままの文字列は見つかりません。外部サイトを装って送った書き込みも、すべて拒否されます。案件の登録時に、担当者を他の人にしようとしてもできませんでした。

16項目のうちSQLインジェクションは、SQLを使う4個（B1・B2・B3・C3）に、ログインのメール欄と一覧の絞り込みへ実際に細工した文字（' OR '1'='1 など）を送って試しましたが、どれも通りませんでした。残りの8個はSQLを使っていない（JSONファイルに保存）ので、該当なしです。したがって、穴が出たのは1項目（項目7）だけで、SQLインジェクションを含むほかの項目は、今回の検査では検出されませんでした。

今回の条件では、典型的な脆弱性はほとんど検出されませんでした。

PS.唯一見つかった脆弱性がプロンプトに書いていない対策の中で起きたことです。「営業は自分の案件だけ」というアクセス制御は、プロンプトの中ではっきり指示したので、12個とも守られました。一方、ログイン回数の制限をプロンプトに書いたのは、プロンプトDのルールだけです。書いていないA・B・Cの9個のうち、7個はAIが入れていましたが、2個では抜けていました。CSRF対策のように、どのプロンプトでも書いていないのに12個とも入っていた対策もあります。プロンプトに書かなくても、多くのセキュリティ対策はAIが自分で入れます。ただし、どの対策が入るかは、作るアプリによってまちまちです。1章で触れた、利用者が指示しなかった安全策を省くことは、この問題に該当します。

なお、Claude Codeを会社で安全に運用する進め方については、セキュリティを考慮したClaude Codeの企業運用に正解を出してみるでも解説しています。

3. バイブコーディングで実践すべきセキュリティ対策

3-1. Claude Codeで脆弱性を検出・修正する

残っている脆弱性が1項目とはいえ、見つかった以上は直したいところです。そこで、ログイン回数の制限が抜けていた2個（B1とB3）を、それぞれ別のClaude Codeで直しました。すでに動いているアプリに、顧客のデータが入ったまま修正する、という現場に近い場面を想定しています。

特に難しいプロンプトではなく、アプリのコードを読み、セキュリティ上の問題を洗い出して直してください、と伝えただけです。結果として、どちらのClaude Codeも、ログイン回数の制限がないことを自分で見つけ、一定回数失敗するとしばらくログインできなくする仕組みを追加しました。

3-2. 修正後の再検証と人によるレビュー

この二つを、もう一度16項目で検証したところ、2個ともログイン回数の制限の脆弱性は塞がり、ほかの項目も含めて、今回の検査では穴が検出されなくなりました。

この修正方法は、参考研究の知見とも合っています。その研究（後述のTony ほか）では、AIが書いたコードを、別の手順で見直してから修正すると、脆弱性が大きく減ると報告されています（GPT-4を使った実験で、静的解析ツールが数えた1行あたりの弱点が77.55%減少。コードが長くなった分も含むため、件数では約65%減）。一方で、同じプロンプトに「見直して」と一言足すだけでは、効果はほとんどなかったという調査結果もあります（Vibe-Coding調査の再現実験）。それぞれの研究と調査では、点検方法が、別のプロンプトにするかどうかと、セキュリティに絞るかどうかの両方で違います。今回の3章も、セキュリティに絞って別のプロンプトとして頼みました。AIで直すなら、プロンプトのついでに一言添えるのではなく、セキュリティの点検として改めて頼むほうがよいと考えられます。

ここまでをまとめると、社内でAIでアプリを作るときの要点は3つです。

守ってほしいことは、はっきり指示する。「営業は自分の案件だけ」のように具体的に書けば、12個ともその通りに作られました。
指示しなかった安全策は、多くは入っても抜けることがあると知っておく。今回はログイン回数の制限が、プロンプトに書かずに作成したアプリ9個のうち2個で抜けました。守るべき項目をあらかじめルールとして渡しておけば、少なくとも書き忘れはなくなります。
できたものは、人が確認するか、もう一度AIでチェックする。

この点検は、エンジニアでなくてもある程度は可能です。できたアプリのフォルダをAIに渡して、セキュリティの問題がないか洗い出して直して、と伝えるだけで済みます。ただし、AIが問題なしと答えても、それだけを信じるのは危険です。今回の検証でも、AIで点検すれば問題は修正できただけで、AIが何を見落としているかは、しっかり確認しないと分かりません。実際、脆弱性がはっきりしたアプリ2個は、どちらも技術的に詳しいプロンプト（B）で作ったアプリでした。詳しく指示するほど安全になるとは限らない、という参考研究の報告とも重なります。顧客の個人情報や売上のような重要なデータを扱うアプリは、公開する前に、詳しい人に一度見てもらうか、専門家によるチェックを入れるのが安全です。社内で誰が確認するかを決めておくことも、作る前に考えておきたい点です。

4. AI生成アプリを本番運用する前のチェックリスト

社内でAIを使ってアプリを作るとき、自社で始められるかの判断材料として使ってください。

守ってほしいアクセス制御（誰が何を見られるか）を、プロンプトの中で具体的に指示したか
ログイン失敗の回数制限など、指示し忘れがちな対策を、ルールに書いて最初に渡したか
できたアプリを人が確認するか、AIにセキュリティのチェックとして改めて依頼し、修正する工程を入れたか
顧客の個人情報や売上など、扱うデータの重要度に見合った確認をしたか
公開する前に、ログインしていない人にデータが見えないかを実際に試したか

5. まとめ｜安全性は生成後の検証まで含めて判断する

バイブコーディングで作られた公開アプリの91.0%に脆弱性があったという2026年の調査を受けて、Claude Codeで社内の案件管理アプリをプロンプトを変えて12個作り、脆弱性に関する確認するべき16項目を検証した。
結果、脆弱性が見つかったのは「ログイン失敗の回数に制限がない」という1項目だけで、作成したアプリの12個のうち2個だった。SQLインジェクションは該当なし、他の項目は今回の検査では検出されなかった。
唯一の脆弱性は、プロンプトに書いていない対策の中で起きた。はっきり指示したアクセス制御は12個とも守られた。対策をプロンプトに書かずに作成したアプリ9個のうち7個はAIが自分で入れたが、2個では抜けた。AIはプロンプトに書かなかった対策も多くは入れるが、確実ではない。守るべき項目はルールとして渡しておく。
検査スクリプトは、わざと穴だらけにしたサンプルで脆弱性を検知できることを確かめたうえで使ったが、本番の12個ではほとんど出なかった。見つかった弱点（2個）は、AIに「問題を洗い出して直して」と頼むと2個とも塞がり、同じ16項目で再検査しても検出されなくなった。
ただし、典型的な16項目を機械的に当てたもので、人が行う深い検査とは粗さが違い、1種類のアプリでの結果でもある。「安全が証明された」のではなく、プロンプト次第でここまで作れる、という結果だと受け止めてほしい。

ログイン回数の制限の抜けは、アプリを作ったAIとは別に用意した検査で見つかりました。直したあとも同じ検査をもう一度当てて、塞がったことを確かめています。AIによる開発だけでなく、独立したセキュリティ検証と修正後の再検証を開発フローに組み込むことに価値がある、というのが今回の結論です。

検証環境

検証に使ったツール：Claude Code 2.1.226（モデルはClaude Sonnet 5.5）。
OSは Windows 11。会社のホームページの記事の付録のコマンドは、改行を \ で続けるGit Bashの書き方で示しています。
アプリは Node.js 24 で起動。SQLite（better-sqlite3）を使うプロンプトBの3個だけは、ビルド済みモジュールの対応バージョンの都合で Node.js 20 で起動した。
検証日：2026年10月17日（検査スクリプトの見直し後の再検証は10月19日、SQLインジェクションの実地テスト・3番の判定の見直し・画像4の再検査は10月20日）。アプリの生成と検査は、会話の履歴や個人の設定を読み込まない状態で行った。
モデルやツールの仕様は更新されることがあります。最新の情報は各公式ドキュメントでご確認ください。

6. 付録｜検証に使ったスクリプト

検証に使ったコマンド・プロンプト・検査スクリプトの全文は、会社のホームページの記事に載せています。

検証のコードはこちら：https://nocode-sol.co.jp/blog/tech/vibe-coding-security-risk-12-apps/

最後に

私たちは、単にシステムを組むだけの開発会社ではありません。低コストで高品質なAIツールの構築から、ROI（投資対効果）を最大化する導入ロードマップの策定、社内スタッフが自らAIを運用・改善できる体制の構築まで、AI導入の成功に必要なすべてを最初から最後まで丸ごと支援いたします。

実は、ご相談いただく方のほとんどが「何が分からないかも分からない」という状態からのスタートです。構想段階でも、ただのアイデアベースでも構いません。
まずは、あなたのお困りごとをそのまま聞かせていただけませんか？貴社のビジネスを加速させるパートナーとして伴走いたします。
無料オンライン相談で、最適な導入プランを相談する

参考文献

Junquan Deng, Zhiyu Fan, Ruijie Meng「Understanding the (In)Security of Vibe-Coded Applications」arXiv:2606.23130v4、2026年（2026年10月17日参照。プレプリント）
Mark Vero ほか「BaxBench: Can LLMs Generate Correct and Secure Backends?」（2026年10月17日参照。ICML 2025採録）
Catherine Tony ほか「Prompting Techniques for Secure Code Generation: A Systematic Investigation」（2026年10月17日参照。ACM TOSEM 2025採録）
石原亜香利「非エンジニアの経営者が「Claude Code」を使って開発した〝組織改革に効くアプリ〟とは？」@DIME（2026年10月17日参照）