「AI が作って動いた」≠「公開しても安全」
AI に頼んで Web アプリを作る「バイブコーディング」が広がる中、動作確認だけで公開して大規模な脆弱性が露呈する 事故が頻発しています。最も有名な事例の 1 つが東大生限定マッチングアプリ「UTopia」で、ログイン未状態でも個人情報（実名・大学メールアドレス・顔写真・出身高校等）が JSON で取得可能、本人確認ステータスをクライアント側で改ざん可能、課金状態も同様といった、認証・認可の根本的な不備が露呈しました。
動作するかは目視で分かりますが、セキュリティ穴は 知識がないとそもそも気づけません。AI に「セキュリティ完璧か？」と聞いて「はい」と返ってきても、それは保証ではありません。
本稿では、バイブコーディングで作った Web アプリを公開する前に 必ず実施すべき認証・認可テスト 7 項目 を中小事業者の経営者・現場担当者向けに整理します。
※ 本稿は 2026 年 5 月時点の情報です。各事例は本文中に一次情報源 URL を明記しています。
前提：認証と認可の違い
| 用語 | 意味 | 例 |
|---|---|---|
| 認証（Authentication） | この人は本当にこの人か | パスワード・SMS 認証・生体認証 |
| 認可（Authorization） | この人にはどこまで見せていいか | 管理者のみ削除可能・本人のみ閲覧可能 |
両者は別物で、両方が機能して初めて安全です。UTopia の事例では「認可」が機能しておらず、ログイン未状態でも個人情報 API が叩けたのが事故の本質でした。
公開前テスト 7 項目チェックリスト
1. ❑ 非ログイン状態での全 API エンドポイント直叩きテスト
ハマり所: ログイン後の画面では正常に動くが、API エンドポイントを直接 URL で叩くと認証なしで個人情報が返ってくる。
対策:
- 全 API エンドポイントを一覧化
- ログアウト状態 / 別タブ / curl コマンドで全エンドポイントに直接アクセス
- 「401 Unauthorized」または「403 Forbidden」が返ることを確認
- 個人情報・課金情報・管理機能エンドポイントは特に重点的に
テスト手順例:
# ログイン不要で叩いて 401 が返るか
curl -X GET https://your-app.com/api/users/123/profile
curl -X GET https://your-app.com/api/admin/users
curl -X POST https://your-app.com/api/admin/delete -d '{"id":1}'2. ❑ 別ユーザーになりすまして他人のデータを閲覧テスト
ハマり所: 自分のデータは正しく見えるが、URL の ID を変えると他人のデータが見える。
対策:
- ユーザー A でログイン → ユーザー A のプロフィール URL を確認（例:
/users/100） - URL の ID を別ユーザーの ID に変更（例:
/users/200） - 別人のデータが見えたら 認可バグ確定
テスト手順例:
- アカウント A で
/api/orders/1にアクセス → A の注文が見える（OK） - アカウント A で
/api/orders/999（B の注文）にアクセス → 403 が返ること
3. ❑ 本人確認・課金状態の偽装テスト
ハマり所: 「本人確認済み」「有料プラン契約済み」のフラグがクライアント側だけで判定されている → 開発者ツールで偽装可能。
対策:
- 「本人確認済み」フラグはサーバー側で都度検証
- 「有料プラン」判定もサーバー側で都度検証
- フロントエンドの
localStorage/cookieの値を改ざんしてもサーバーは騙されない設計
テスト手順:
- ブラウザ開発者ツールで
localStorageの値を「無料 → 有料」に改ざん - 有料機能が使えるようになるなら サーバー側検証が抜けている
4. ❑ 管理者機能への一般ユーザーアクセステスト
ハマり所: 管理画面の URL を一般ユーザーが推測してアクセスすると操作可能。
対策:
/admin配下の全ページ・全 API を一般ユーザーで叩いて 403 が返ることを確認- 管理者専用の DELETE / UPDATE 操作も一般ユーザーで試行
テスト手順例:
# 一般ユーザーのトークンで管理 API を叩く
curl -H "Authorization: Bearer <user_token>" https://your-app.com/api/admin/users
# → 403 が返ることを確認5. ❑ Supabase / Firebase の RLS（Row Level Security）設定テスト
ハマり所: BaaS（Backend as a Service）で RLS を有効化していない、または設定が緩い → クライアントから直接 DB を叩いて全データ取得可能。
対策:
- Supabase: 全テーブルで RLS を有効化、適切なポリシーを設定
- Firebase: Security Rules を本番デプロイ前に必ず確認
- ANON キー（公開キー）で全テーブルから SELECT できないかテスト
テスト手順:
// ANON キーで叩いて全データ取得できないか
const supabase = createClient(URL, ANON_KEY)
const { data } = await supabase.from('users').select('*')
// → 自分以外のレコードが返ってきたら RLS バグ6. ❑ ファイルアップロード制限テスト
ハマり所: 画像アップロードのつもりが、拡張子・MIME タイプ検証が甘くて任意ファイルがアップロードされ、サーバー上で実行可能。
対策:
- 拡張子チェック（クライアント側）+ MIME タイプ検証（サーバー側）の両方
- アップロードファイルを実行可能な場所に置かない（公開ディレクトリ直下を避ける）
- ファイルサイズ制限（DoS 対策）
テスト手順:
- 画像アップロード機能に
.html.php.jsなどの実行可能ファイルをアップロード - アップロード成功後、そのファイル URL に直接アクセスして実行されないか確認
7. ❑ レート制限・無限リトライ防止テスト
ハマり所: ログイン試行回数制限なし → ブルートフォース攻撃可能。API 呼び出し回数制限なし → 高額請求発生。
対策:
- ログイン試行: 5 回失敗で 15 分ロックなど
- API 呼び出し: 1 ユーザーあたり毎分 60 回など
- AI 系 API（OpenAI / Anthropic）はハードリミット必須
テスト手順:
# 100 回連続でログイン試行してロックされるか
for i in {1..100}; do
curl -X POST https://your-app.com/api/login -d '{"email":"x@x.com","password":"wrong"}'
done
# → 5 回目以降は 429 Too Many Requests が返ることを確認なぜバイブコーディングで認証・認可が抜けるのか
構造的な原因
- AI は「動くコード」を優先して生成する
- 認証・認可は「動作には影響しない」ため、明示的に指示しないと省略される
- セキュリティ要件は 業務文脈 に依存し、AI が自動推論するのが難しい
- 「動いた → 完成」と人間が判断してしまう
AI に依頼する時のプロンプト改善案
Web アプリを作って。要件は X。
セキュリティ要件として以下を必ず実装：
- 全 API エンドポイントで認証必須
- 個人情報の閲覧は本人 + 管理者のみ
- 管理者機能は別の認可スコープ
- レート制限（ログイン 5 回失敗で 15 分ロック、API 60 回/分）
- ファイルアップロードは MIME タイプ検証
- Supabase RLS を全テーブルで有効化、ポリシーも実装
公開前に上記 7 項目のテスト手順を提示して。チェックリストの使い方
| フェーズ | 対象項目 | 目安期間 |
|---|---|---|
| 設計フェーズ | 1, 2, 3, 4, 5（要件として組み込む） | 計画段階 |
| 実装フェーズ | 6, 7（実装時に組み込む） | 実装中 |
| テストフェーズ | 1〜7 全項目 | 公開前 1〜3 日 |
| 本番稼働後 | 7（モニタリング継続） | 月次 |
Optiens の取り組み
Optiens では、自社開発した小説推敲ツール（/novel-review）や AI 活用診断フォーム（/free-diagnosis）で、本稿の 7 項目テストを公開前に必ず実施しています。Supabase RLS は全テーブルで有効化、認証・認可の境界は二重で実装、レート制限とハードリミットを併用する設計です。
御社でバイブコーディング・AI 駆動開発で作成した Web アプリの公開前セキュリティレビューが必要な場合、本稿 7 項目を 設計レビュー → テスト実施 → 修正提案 で支援する 無料 AI 活用診断 をご用意しています。具体的な脆弱性診断・修正実装は 詳細レポート（¥5,500税込） でお届けします。
まとめ
公開前認証・認可テスト 7 項目：
- 非ログイン状態での API 直叩きテスト
- 別ユーザーになりすまして他人のデータ閲覧テスト
- 本人確認・課金状態の偽装テスト
- 管理者機能への一般ユーザーアクセステスト
- Supabase / Firebase の RLS 設定テスト
- ファイルアップロード制限テスト
- レート制限・無限リトライ防止テスト
そして全体を貫く原則は 「動いた ≠ 安全。動作確認とセキュリティテストは別物」 です。
関連記事:
- 【経営者向け】AI 駆動開発で発生した 4 大セキュリティ事故と対策
- 「.env を AI から守る」── 機密情報の正しい隔離設計
- AI エージェントの「ハーネス」設計 ── 暴走を防ぐ 5 つの実装パターン
出典:
- UTopia 脆弱性解説: https://blog.technophere.com/utopia-security-vulnerability/
- Supabase Row Level Security 公式: https://supabase.com/docs/guides/auth/row-level-security
- Firebase Security Rules 公式: https://firebase.google.com/docs/rules
- OWASP API Security Top 10: https://owasp.org/API-Security/
- Optiens 自社運用知見（小説推敲ツール・無料 AI 活用診断の RLS / 認証実装）