読了時間 7分

「レビューして」でエンジニアが実際に見る20項目 — 10は自分で、10を頼む

エンジニアに「レビューして」とだけ送ると「何を？」と返ってきます。公開前に実際に見ているのは20項目。そのうち10項目は自分で今日確かめられ、残りの10項目だけを頼めば見積もりも具体的になる。全項目と、そのまま送れる依頼文。

動画で見る

結論から

エンジニアに「レビューしてください」とだけ送ると、返ってくるのは「何を見ればいいですか？」です。エンジニアが公開前に実際に見ているのは、決まった20項目。そのうち10項目は、あなた自身が今日確かめられます。残りの10項目だけを頼めば、見積もりも返事も具体的になります。

この記事で伝えたいのは、この一点だけです。

  • 20項目は4つの箱に分かれる：「誰が見えるか」「秘密（キー）」「入力と乱用」「運用」
  • 各箱の半分は、ブラウザと管理画面だけで確かめられる（◯印）。残りはコードの中を見る必要がある（●印）
  • 「レビューして」ではなく、「◯は確認済み、●の10項目を見てください」と送る。これが依頼になる
  • 一覧の下に、そのまま送れる依頼文を置いた

動画版（約2分半）は本文の上に埋め込んであります。

エンジニアが「レビュー」で実際に見る20項目

① 20項目の全体：4つの箱

エンジニアによって順番や言い方は違いますが、AIで作ったアプリを公開前に見るとき、中身はほぼこの20項目に収まります。◯は自分で確かめられるもの、●はコードを読む必要があるものです。

箱A：誰が見えるか（アクセス制御）

  1. ◯ URLの数字を1つ変えて、他人のデータが見えないか（→ 5分チェック①）
  2. ◯ シークレットウィンドウで /admin を開いて、管理画面が出ないか（→ 5分チェック②）
  3. ◯ ログアウトした状態で、アップロード画像やPDFのURLを直接開けないか
  4. ◯ Supabase の全テーブルで RLS が「Enabled」になっているか（管理画面で色を見るだけ）
  5. ● 管理用のAPI（削除・一括操作・エクスポート）が、画面と同じ権限確認をしているか

箱B：秘密（キー・パスワード）

  1. ◯ 公開URLで F12 → Sources → 「sk-」「service_role」を検索して、0件か（→ APIキーの記事）
  2. ● .env やキーが、Git の履歴に残っていないか（いま消しても履歴には残る）
  3. ◯ Supabase の service_role キーが、フロントのコードに無いか（6と同じ検索）
  4. ● 各キーの権限が最小か（読み取りだけでよい所に、削除もできるキーを使っていないか）
  5. ● ログやエラー通知に、個人情報やキーが出力されていないか

箱C：入力と乱用

  1. ● 入力チェック（必須・文字数・形式）が、画面だけでなくサーバー側にもあるか
  2. ◯ ログイン画面と問い合わせフォームを10回連打して、止められるか（レート制限）
  3. ● 検索・AI機能に、SQLインジェクション／プロンプトインジェクションの入口が無いか
  4. ◯ ファイルアップロードに .exe や 100MB のファイルを入れて、拒否されるか
  5. ● 外部から呼べるAPIの範囲（CORS・認証なしで叩けるエンドポイント）

箱D：運用

  1. ◯ 全ページが https で開き、鍵マークが付いているか
  2. ● データベースのバックアップがあり、実際に戻せるか
  3. ◯ 存在しないURL（/aaa）や変な入力でエラーを出したとき、内部の情報（ファイルパス・SQL）が画面に出ないか
  4. ● 使っているパッケージに既知の脆弱性が無いか（npm audit 相当）
  5. ● 異常（急なアクセス増・エラー増）に気づける通知があるか

◯を数えると10個、●も10個です。

② なぜこの20項目なのか：事故は、ここから起きている

20項目は「思いつく限り並べた」ものではなく、実際にAI製アプリで起きた事故の入口です。

  • 2025年5月に公開された CVE-2025-48757 は、Lovable で作られたアプリの Supabase に RLS（項目4）が無く、ログインしていない人がデータベースを直接読める状態を指摘したものです。報告では、ショーケースに載っていた 1,645 本を調べて 170 本（約10%）に深刻な不備があり、氏名・メールアドレス、APIキー、決済情報が読める状態でした。CVSS は 8.26（High）。プラットフォーム側の「修正版」は無く、各アプリが自分で RLS を付けるしかありません
  • 2026年2月の Lovable ショーケースの成績閲覧アプリ（18,697件）は、項目5（管理APIの権限確認）が逆向きに書かれていた事例です
  • Moltbook（2026年1月、150万件のトークン）は項目4と8。個人サイトの APIキー漏えいは項目6と7

つまり◯の10項目だけでも、実際に起きた事故の大半を自分で先に見つけられます。エンジニアの時間は、●の「コードを読まないと分からない10項目」に使うのが、いちばん安い順番です。

③ 自分でやる10項目：所要時間の目安

  • 1〜3（URL・/admin・画像URL）：各5分。シークレットウィンドウと、もう1つのアカウントがあれば足りる
  • 4（RLS）：Supabase の Table Editor を開き、各テーブルの「RLS disabled」の赤い表示が無いか。2分
  • 6・8（キー検索）：F12 → Sources → ⌘⇧F で「sk-」「service_role」「eyJ」。3分
  • 12（連打）：ログイン画面で間違ったパスワードを10回。フォームを10回送信。止まらなければ未対策。3分
  • 14（アップロード）：.exe にリネームした画像と、大きい動画ファイルを上げてみる。2分
  • 16（https）：全ページの鍵マーク。1分
  • 18（エラー画面）：/aaa /admin/aaa ?id=abc を開いて、画面にファイルパスや SQL が出ないか。2分

合計30分弱です。結果を「◯：合格／✗：未対策／？：分からない」の3種類でメモしてください。それが次の依頼文になります。

④ 頼む10項目：そのまま送る依頼文

「AIで作った予約アプリの公開前レビューをお願いします。20項目のうち、自分で確認できる10項目（URLのID切替・/admin・画像URL・RLS・フロントのキー検索・連打・アップロード・https・エラー画面）は確認済みで、結果は次のとおりです：〔◯✗？を書く〕。残りの10項目、①管理APIの権限確認 ②Git履歴のキー ③キーの権限範囲 ④ログの個人情報 ⑤サーバー側の入力検証 ⑥SQL／プロンプトインジェクション ⑦CORSと公開API ⑧バックアップと復元 ⑨依存パッケージの脆弱性 ⑩異常検知の通知、を見て、直すべき点と概算をください。リポジトリと公開URLは別途送ります。」

この文の効果は3つあります。見る範囲が決まっているので見積もりが出せる。◯の結果があるので、エンジニアは重複確認を省ける。「？」が付いた項目は、そこだけ追加で見てもらえる。逆に、この依頼に「全部見ないと分かりません」「まず要件定義から」と返ってきたら、AI製アプリのレビューに慣れていない相手です。

よくある質問

20項目、全部やらないと公開できませんか。

◯の10項目で✗が出たものは、公開前に直してください（どれも「他人のデータが見える」「キーが漏れる」に直結します）。●は、ユーザーが数人のうちは後回しにできるものもあります（17・19・20）。ただし決済を入れる前、ユーザーが100人を超える前には、●も一度は見てもらってください。

Lovable の「セキュリティスキャン」で足りませんか。

Lovable は公開前に無料のスキャンを行い、RLS の未設定などを指摘します。項目4・6・8あたりはそれで拾えます。ただし項目5（管理APIの権限が逆向き）のような「動くけれど判断が間違っている」コードは、自動スキャンでは見つからないことがあります。2026年2月の事例がそれです。

エンジニアの知り合いがいません。

この記事の依頼文をそのまま、VibeCode本番化の無料相談に送ってください。●の10項目を見るのが、まさにこのサービスの診断です。◯の結果が添えてあれば、初回の返事が具体的になります。

関連記事