- AIに手伝わせて作ったアプリはきちんと動きます。しかし顧客に公開する前の段階では、まだ誰も侵入を試していません。
- 情報漏えいが起きやすい箇所は5つあり、経営者でもコードを読まずに、質問するだけで確かめられます。
- 顧客の名前や電話番号、利用履歴を保存するアプリなら、実データを受け付ける前に5つすべての確認を済ませておくべきです。
動いているだけでは、安全かどうかはわからない
たとえば、チームの若手がAIツールで予約システムを作り、週末だけで完成させたとします。試しに予約やキャンセルをして、レポートも開いてみると、すべて問題なく動きます。ただ、この試し方でわかるのは、普通に使う人がきちんと使えるかどうかだけです。わざと想定外の使い方をする人が、システムに何をできるのかという点は、まだ誰も確認していません。
バイブコーディングとは、普段の言葉で指示を出し、コードはすべてAIに書かせる作り方です。指示を出す人は、できあがったコードをたいてい読みません。ツールのほうも、画面が動くまで指示どおりに作り続けるように設計されています。指示の中でアクセス権限、パスワードやキーといった秘密情報の保管、ユーザーが入力したデータのチェックに触れていなければ、できあがるコードにもそうした対策はたいてい入っていません。画面は見栄えがよく、どのボタンもこれまでどおり押せるので、何かが欠けていると気づくきっかけがありません。
ソフトウェアセキュリティ企業のVeracodeは、100を超える言語モデルに80種類のコーディング課題を解かせ、2025年7月に結果を公表しました。生成されたコードは課題どおりに動いていたにもかかわらず、45%の課題でセキュリティ上の脆弱性を含んでいました。同じ年には脆弱性CVE-2025-48757も公表されています。バイブコーディング向けのプラットフォームLovableで作られた170を超えるアプリが、データの権限ルールを設定していなかったために、ログインしなくても外部の人がデータベースの中身を読んだり書き換えたりできる状態になっていた、というものです。
プラットフォーム側は、権限ルールの設定は各アプリの所有者の責任だと反論しました。経営者の立場で言い換えると、データが漏れたときに顧客へ説明しなければならないのは自社であり、アプリを作ったツールは責任を負わない、ということです。
バイブコーディングのアプリで情報が漏れやすい5つの箇所
内装工事を終えたばかりの店を思い浮かべてください。店構えはきれいで、レジも使えます。けれども、裏口に鍵がかかっているか、合鍵がどこに置いてあるか、レジの引き出しを誰が開けられるかは、まだ誰も見て回っていません。この表の5項目が、アプリにとっての裏口です。どの項目にも、アプリを作った人にその場で聞ける質問があります。
| 確認する箇所 | 漏れているときの症状 | 経営者が確かめるための質問 |
|---|---|---|
| データの閲覧権限 | ある顧客としてログインし、リンク末尾の番号を変えると、別の顧客のデータが見えてしまう | リンク末尾の番号を変えたら、他の人の予約票が見えますか？今ここで試して見せてください。 |
| システムの鍵 | データベースや決済サービスへの接続キーがWebページのコードに埋め込まれていて、開けば誰でも見られる | 料金を払って使っているサービスのキーはどこに保管していて、誰が見られますか？ |
| データベース | 外部の人がアプリを通さずにデータベースへ直接命令を送り、テーブルを丸ごと読み出せる | アプリの画面を通さずにデータベースにアクセスする経路はありますか？テーブルごとに、どんなルールでアクセスを制限していますか？ |
| ユーザーが送ってくるデータ | 入力欄がどんな文字列でも受け付け、アップロード欄がどんな種類のファイルでも受け付ける | 誰かがおかしな命令を入力したり、画像ではないファイルをアップロードしたりしたら、システムはどう動きますか？ |
| 既製のコード部品（ライブラリ）と利用記録 | 脆弱性のあるバージョンのコード部品を使っていて、何か起きても、さかのぼって確認できる記録が残っていない | 明日「データが漏れている」と連絡があったら、誰がいつ入ってきて何をしたのか、さかのぼって調べられますか？ |
1つ目の項目は、最もよく見つかるうえに、最も気づきにくいものです。ソフトウェアのセキュリティに取り組む非営利団体OWASPは、Top 10のリストで、アクセス制御の不備をWebアプリケーションのリスクの第1位に挙げています。ログインの仕組み（認証、Authentication）はユーザーが誰なのかを確かめ、権限の設定（認可、Authorization）はそのユーザーが何を見てよいかを決めます。AIは前者をたいてい一通り作ります。画面に表れる部分だからです。後者はアプリがデータを取り出すすべての箇所にルールを書く必要があり、ルールが抜けていても、それを知らせる画面はありません。
2つ目と3つ目は、たいてい一緒に起こります。短期間で作ったアプリはWebページから直接データベースにつなぐことが多く、その接続キーが全ユーザーのブラウザに送られてしまいます。最近のデータベースは、すべてのテーブルに行単位の権限ルール（行レベルセキュリティ、Row-Level Security）を設定していれば、こうした接続方法にも対応できます。先ほどのLovableの件は、このルールがないテーブルが原因でした。
開発チーム向け · 技術チェックリスト
データの参照IDを受け取るすべてのエンドポイントで、サーバー側の認可（Authorization）をチェックします。全テーブルで行レベルセキュリティを有効にしてポリシーを設定し、シークレットはバンドルとリポジトリの履歴から取り除いてシークレットマネージャーに移します。入力欄にはすべてパラメータ化クエリと入力値検証を適用し、アップロードできるファイルの種類とサイズを制限します。ログイン画面にはレート制限をかけます。CIでは依存関係スキャン（Dependency Scan）とシークレットスキャンを実行し、個人データの閲覧と変更は監査ログに残します。
架空のケース
理学療法クリニックと、番号を書き換えられる予約票リンク
3院を展開する理学療法クリニックが、分院のマネージャーにAIツールで予約システムを作らせました。システムは患者にSMSで予約票のリンクを送り、リンクの末尾には1042のような予約票の通し番号がついています。ある患者がこの番号を1041に変えてみたところ、別の患者の名前、電話番号、症状が表示されました。患者はその画面のスクリーンショットを撮り、クリニックのSNSページに送ってきました。
クリニックはシステムを1週間止め、予約をノートに手書きする運用に戻しました。修正そのものは数日で済んでいます。予約票を開けるのは本人とその分院のスタッフだけにするルールをサーバー側に追加し、通し番号をランダムなコードに変え、閲覧の記録を取り始めました。答えられなかったのは、それ以前に誰かが他人の予約票を何回開いていたのかという点です。旧システムが記録を一切残していなかったからです。健康に関する情報はタイの個人情報保護法（PDPA）でセンシティブデータにあたるため、クリニックは誰に報告する義務があるのかを法律顧問に判断してもらう必要がありました。
実データを受け付ける前に、5つの扉を確認する
- アプリが保存するデータをすべて書き出し、個人データやお金に関わる項目に印をつけます。
- テスト用アカウントを2つ作ります。1つ目でログインし、2つ目のアカウントで受け取ったリンクをすべて開いてみます。
- コードを読める人に、Webページのコードとコードの変更履歴から、パスワードやキーなどの秘密情報を探してもらいます。
- データベースの権限ルールをテーブルごとに見せてもらいます。ルールのないテーブルは、誰でも開ける状態とみなします。
- 1つの質問で事故を想定してみます。昨日誰かがデータを持ち出していたとしたら、今日、何を見ればそれに気づけるでしょうか。
各項目の結果は、確認した日付と確認者の名前とともに記録し、公開前に会社として確認した証拠として保管します。この方法で基本的な脆弱性は見つけられますが、専門家によるペネトレーションテスト（侵入テスト）の代わりにはなりません。決済を受け付けるアプリや、センシティブなデータを保存するアプリは、もう一段先まで進める必要があります。
どこまで深く確認するかは、アプリが扱うデータで決まる
どの家にも戸締まりは必要ですが、金庫まで要る家は一部です。アプリも同じで、確認の深さはデータの価値と機密性に合わせるべきです。小さなツールに必要以上の対策をするのも、お金のかけどころを誤ることになります。
営業チームの中で使う価格計算ツールのように、顧客データを扱わない社内ツールなら、バイブコーディングで作ってそのまま使って構いません。確認が必要なのは、会社の秘密情報がコードに埋め込まれていないかどうかだけです。顧客の名前、電話番号、メールアドレスを保存するアプリは5つの扉をすべて確認し、さらに公開前に、作った本人ではないエンジニアに権限と秘密情報の扱いをレビューしてもらうべきです。
支払いを受け付けるアプリや、健康情報、金融情報、身分証のコピーを保存するアプリには、それ以上の対策が要ります。設計の段階から脅威モデル（Threat Model）を作っておくべきです。誰がどこから攻撃してくる可能性があり、何が損なわれるのかを前もって洗い出す作業です。そのうえで公開前に外部のテスト担当者にペネトレーションテスト（Penetration Test）を依頼し、システムを大きく変えたときにも繰り返します。
社内文書を読み込むチャットボットがアプリに組み込まれている場合は、プロンプトインジェクション（Prompt Injection）というリスクも加わります。ユーザーが命令文を紛れ込ませ、本来は見る権限のないデータをAIに明かさせる手口です。効果のある防ぎ方は、AIの権限を、質問している本人の権限と同じ範囲に絞ることです。
次のどれか1つでも当てはまれば、実データの受け付けはまだ早い
- システムの秘密情報がどこに保管されているか、チームの誰も答えられない
- あるテスト用アカウントから、別のアカウントのデータが開ける
- 権限ルールが設定されていないテーブルがデータベースにある
- 顧客データを誰が閲覧・変更したかを、システムが記録していない
- 事故が起きたときに連絡を受ける担当者を、名前で挙げられない
費用の面では、公開前に確認して直すほうが、事故の後に直すより安く済みます。事故の後でも修正費用そのものは変わらず、そこにシステム停止中の損失、顧客対応に追われるチームの時間、法的な対応の負担が上乗せされるからです。タイのPDPAは、データ管理者に対し、侵害を知った時点から72時間以内にタイ個人情報保護委員会事務局へ通知するよう定めています。ただし、その侵害がデータ主体の権利を脅かすおそれのない場合は除かれます。実際の対応の詳細は、自社の法律顧問に確認してください。
誰でもバイブコーディングできるなら、エンジニアチームはどこで必要なのか
AIは指示されたことをこなします。そして、セキュリティの問題の多くは、指示を出す人が思いつきもしなかった部分にあります。攻撃を受けている本番システムを実際に守った経験のある人は、作り始める前に何を確認すべきか、完成後にシステムに対して何を試すべきかを知っています。
今年は優れた開発チームも、ほかの人たちと同じようにAIでコードを書いています。違いはコードの周りの工程にあります。作業に入る前に権限を設計し、AIが書いたコードをエンジニアが読んでからシステムに取り込み、変更のたびに脆弱性スキャンのツールを走らせます。さらに、引き渡し資料には担当者の名前が載っていて、事故が起きたときにはその人に電話できます。
経営者が見せてもらうべき指標は多くありません。深刻度別の未対応の脆弱性の数、深刻度の高い脆弱性を塞ぐまでにかかった日数、直近の確認日、情報漏えいを想定した対応訓練の結果です。こうした数字に誰も答えられないなら、この分野はまだ誰も見ていないということです。
完成済みアプリのセキュリティ点検と強化、または設計段階からの組み込み
どのデータが損なわれては困るのかを一番よく知っているのは、経営者と社内のITチームです。法律が何を求めているかを示すのは、会社の法律顧問です。DNA Makerはまず、こうした方々と一緒に、アプリがどんなデータを保存し、データがどこを通り、誰が何を見るべきかを洗い出します。そのうえで、データフロー図、役割別の権限表、人の承認が必要な箇所の一覧として書き起こします。
すでにバイブコーディングで作ったアプリについては、この記事の5項目に沿ってセキュリティレビューを行い、深刻度順に並べた脆弱性レポートをお渡しします。修正は元の開発チームと一緒に進めることも、私たちが引き取ることもできます。新しいシステムでは、権限、秘密情報の保管、入力データのチェック、利用記録をはじめからアーキテクチャに組み込みます。コードはAIの力を借りて書きつつ、すべてエンジニアがレビューし、パイプラインでコードと外部ライブラリをスキャンします。公開前には、外部のペネトレーションテスト担当者が検査できる状態まで整えます。顧客データの受け付けを控えたアプリがあれば、そのリンクと、アプリが保存するデータの一覧を持って、私たちのエンジニアにご相談ください。公開前にどこを直すべきかがわかります。
SOFTWARE ENGINEERING GLOSSARY
ソフトウェア開発用語集
開発チームとセキュリティの話をすると、次の用語が出てきます。いちばん右の列は、その項目を実際に誰かが管理しているかを確かめるための質問です。
| 用語 | 意味 | わかりやすい例 | 開発チームへの質問 |
|---|---|---|---|
| Authentication | システムに入る前に、ユーザーが誰なのかを確かめること。パスワード、SMSで届くコード、顔認証などを使う | 患者が電話番号と、SMSで届いたコードを入力して予約票を開く | どのユーザー層に二段階認証を求めていますか？パスワードを忘れたときは、どうやってアカウントを復旧しますか？ |
| Authorization | 本人確認が済んだあとで、ユーザーごとにどのデータを見たり変更したりできるかを決めるルール | 患者は自分の予約票だけ、スタッフは所属する分院の予約票だけを開ける | データを取り出すたびに、サーバー側で権限ルールをチェックしていますか？そのテストは誰が担当していますか？ |
| Secret Management | データベースのパスワードや決済サービスのキーといったシステムの秘密情報をコードの外に保管し、見られる人を限定する方法 | SMS送信サービスのキーは秘密情報の保管システムにあり、Webページのコードには含まれていない | 秘密情報が漏れたら、何分以内に新しいものへ切り替えられますか？誰が作業しますか？ |
| Row-Level Security | ユーザーごとに、読んだり変更したりできるデータの行を決める、データベース内のルール | 予約票のテーブルが、ログイン中の患者本人の行だけを返す | このルールがまだ設定されていないテーブルはありますか？あるなら、その理由は何ですか？ |
| Threat Model | 誰がどこからシステムを攻撃しうるか、何が損なわれるかを前もって洗い出し、どこから守るかを決める作業 | 患者、退職したスタッフ、外部の人のそれぞれが、どの経路で治療記録にたどり着けるかをチームで洗い出す | このシステムのリスクの上位3つは何ですか？それぞれの責任者は誰ですか？ |
| Penetration Test | 取り決めた条件のもとで専門家に実際にシステムへの侵入を試してもらい、悪意のある人より先に脆弱性を見つけること | 外部のテスト担当者がアカウントなしで患者データへのアクセスを試み、何ができたかを報告する | 最後にテストしたのはいつで、どこまでを対象にしましたか？見つかった脆弱性はすべて塞ぎましたか？ |
| Dependency Scan | システムが取り込んでいる既製のコード部品に、脆弱性が公表済みのバージョンが含まれていないかを調べること | ファイルのアップロードを処理するコード部品に脆弱性があるとツールが知らせ、チームが本番反映の前に更新する | このスキャンはコードを変更するたびに実行されていますか？通知は誰が受け取りますか？ |