「動く」と「本番で守れる」は別物
AI に頼んでチャットでやり取りしながらシステムやアプリを作る「バイブコーディング（Vibe Coding）」が、エンジニアでない人にも広がっています。中小事業者が業務システムを自分で作ったり、フリーランスが LP・予約サイトを構築したり、用途は加速度的に拡大しています。
便利な反面、「動くこと」と「本番運用で守れること」のあいだには深い溝があります。この溝は、2026 年に話題化した複数の情報漏洩事案でも繰り返し可視化されました。とくに、SNS で短期間に注目を集めた直後にメンテナンス停止に追い込まれた個人開発系サービスの事例では、AI 駆動で短期構築されたサービスに対し、本番運用前提のセキュリティレビューが入らなかった ことが共通課題として浮き彫りになりました。
本稿では、こうした事案から繰り返し見られる典型的なセキュリティ問題を整理し、中小事業者が AI で業務システムを構築する際にどこを守るべきかを論点化します。
※ 本稿は公開された報道・SNS 上の解析情報をもとにした観察記事です。
典型的に見られるセキュリティ問題のパターン
近年、AI 駆動で短期構築された個人開発サービスを利用者やセキュリティ研究者が解析した結果、以下のような問題が繰り返し報告されています：
| 問題 | 内容 |
|---|---|
| 1. 個人情報の素抜け | 氏名・顔写真・登録メール等が、ログインなしで JSON 形式で取得可能になっていた |
| 2. 本人確認書類の閲覧 | マイナンバーカード等の画像へのアクセス制御が不十分で、URL から推測可能だった |
| 3. クライアント側認証 | メールアドレスの所属判定をブラウザ側で実施。サーバー側で再検証されていなかった |
| 4. 課金アイテム不正増殖 | クライアントから増殖操作が可能な実装になっていた |
| 5. 管理者キーの露出 | 本来非公開であるべき API キー類が公開リポジトリ等で確認できる状態だった |
これらは、いずれも「Web アプリの開発で 20 年以上前から知られている古典的な脆弱性」であり、ベテランエンジニアが一度でも触っていれば気付くレベルです。にもかかわらず本番にリリースされてしまう構造的背景があります。
なぜ「動く」だけで終わってしまうのか
AI 駆動開発（バイブコーディング）には、構造的に「動くが守れない」になりやすい特徴があります。
1. 後付け機能の見落とし
最初は「とりあえずマッチングアプリっぽいもの」を作ります。AI は親切に画面遷移・データ表示・検索機能を一気に組み立てます。この段階では、画面に表示するためのダミーデータが「誰でも見られる経路」に流れていても、ダミーなので問題ありません。
問題は、ここに ユーザー登録・ログイン機能を後付けした瞬間 に発生します。本来であれば「個人情報は認証後にしか流れないように、表示経路を全部組み替える」必要があります。しかし AI は「ログイン機能を追加してください」という指示には従いますが、最初に作った「誰でも見られる経路」までは見直しません。結果、認証を通っていない経路から個人情報が漏れたままになります。
2. 「クライアントを信用する」ミス
「東大のメールアドレスかどうか」を、ユーザーのブラウザ（クライアント）でチェックして「本物だ」と判定するコードを AI が書きがちです。一見動きますが、悪意あるユーザーはブラウザを改造して「自分は東大のメールアドレス保持者です」と詐称できます。本来は サーバー側で「実際にそのアドレスに認証メールが届くか」を確認する 必要があります。
3. データベースのアクセス制御の見落とし
近年は Supabase など「フロントエンドから直接データベースにアクセスする」設計が一般的になりました。便利ですが、Row Level Security（RLS）と呼ばれる行単位のアクセス制御を設定しないと、全データが誰でも読めてしまう 危険があります。AI は設計時に明示的に依頼しないと、この設定を抜かすことがあります。
4. 機密情報をリポジトリに置く
API キー・管理者パスワード・認証トークンなどを、ソースコードに直書きしてリポジトリに上げてしまう事故は AI 駆動開発でも頻発します。AI は「便宜的にここに書いておきますね」と例を出し、人間がそのまま本番で使うパターンがあります。
中小事業者が押さえるべき最低限の防衛線
社内でバイブコーディングを取り入れる、または外部に AI 駆動で構築を依頼する場合、最低限以下を確認してください。
A. 認証は必ずサーバー側で再検証する
「クライアントから送られてきた情報を信じる」のは、本人確認や権限判定では絶対に避けるべきです。サーバー側で改めて検証する設計を、構築段階で明示的に依頼してください。
B. データベースの行単位アクセス制御（RLS）を設定する
特に Supabase・Firebase 等の BaaS を使う場合は、テーブルごとに「誰がどの行を読み書きできるか」のルールを設定する必要があります。設定がゼロだと「全公開」になっている前提で考えてください。
C. 個人情報・本人確認書類は「持たない」を基本に
マイナンバーカード・運転免許証等の画像を「念のため保存」してはいけません。本人確認のために一時的に提示を受けたら、確認後にデータは破棄するのが原則です。長期保管にはセキュリティ要件が跳ね上がるため、よほどの体制がない限り「持たない」設計を選んでください。
D. API キー・パスワードは環境変数とシークレット管理に
ソースコード（git）にキーを書かない。.env ファイルや、Vercel・Supabase 等のシークレット管理機能を使う。「うっかりリポジトリに上げない」ための仕組み（.gitignore の徹底）を整える必要があります。
E. 本番リリース前の脆弱性レビュー
身近にエンジニアの知見がある人がいれば、1 度でいいので本番リリース前にレビューを受けてください。レビュー側に「これくらいなら問題ない」と判断してもらえるかどうかが、最低ラインの目安になります。
AI 駆動開発を、安全に業務へ取り入れるために
こうした事案は、AI 駆動開発の便利さと裏腹に、「動く・本番でも守れる・継続運用できる」の 3 段階のうち、最初の 1 段階で止まっているサービスがすでにリリースされてしまう時代に入ったことを示しています。
中小事業者が AI を業務に取り入れる際、特に 顧客情報・決済情報・本人確認書類 を扱うシステムでは、以下の役割分担が現実的です：
- 「動く」を作る：オーナーや現場担当が AI でプロトタイプを作る
- 「守れる」をレビューする：知見のある外部に短時間のセキュリティチェックを依頼する
- 「継続運用」を整える：監視・ログ・障害時対応を運用ルール化する
弊社（合同会社 Optiens）でも、AI を使った業務最適化の支援を提供する際、必ず「セキュリティ前提の構築」を念頭に進めています。AI で作るからこそ、見落としを後工程で拾える設計が必要です。
「AI で何かを作ってみたが、これを本番で使っていいのか不安」というご相談は、まずAI 活用診断（簡易版・無料）からご利用ください。業務の優先度と、最低限押さえるべきセキュリティ論点を整理してお返しします。
参考情報（公開ソース）
- 本稿は SNS（X 等）で公開された解析情報および各種メディア報道をもとに整理した観察記事です。
- 当該サービス運営側の公式発表は本稿時点で限定的であるため、断定的な表現は避けています。
- Supabase Row Level Security 公式ドキュメント: https://supabase.com/docs/guides/auth/row-level-security