結論から書きます。Claude Code・Cursor・Lovable などAIで作ったアプリに、お金を払って人のセキュリティ診断を入れるべきかは、アプリの出来ではなく「何を預かるか」で決まります。 自分だけが使うアプリや、他人のデータを保存しないアプリなら、無料のチェックとAIでの修正で足りることが多いです。他人の個人情報を業務で預かる、お金が動く——そうなる前に一度だけ、人の目を入れる価値があります。
この記事では、あなたのアプリがどちらに当たるかを判断表で決め、頼む場合の時期・相場・渡すものまでを順に説明します。
先にお断りしておくと、筆者は「公開前ライト診断」という有料の診断を提供しています。だからこそ、診断が要らないケースを先に、はっきり書きます。全員に有料診断が必要だという話ではありません。
1. 判断表 — あなたのアプリに、人の診断は要るか
人の診断が要るのは、他人の個人情報やお金を預かる場合です。判断の問いは「漏れたら、誰に謝ることになるか」。謝る相手が自分だけなら、急ぐ必要はありません。
| あなたのアプリの状況 | おすすめ | 理由 |
|---|---|---|
| 自分と家族・仲間内だけが使う | 人の診断は不要 | 漏れて困る他人のデータが無い |
| 公開するが、ログインもデータ保存も無い（計算ツール、紹介ページなど） | 人の診断は不要。鍵の露出だけ確認 | 盗まれる中身が、APIキー（外部サービスの合鍵）くらいしか無い |
| 他人がログインし、その人のメールアドレスなどを保存する | 無料チェックとAIで直す。迷う項目が残ったら人に | 「他人のデータが見えないか」の確認が要るが、多くは自力で確かめられる |
| 顧客名簿・予約・問い合わせなど、他人の個人情報を業務で預かる | 本物のデータを入れる前に人の診断 | 漏れたときの影響が自分の外に出る |
| 決済がある、お金や在庫が動く | 決済を始める前に人の診断 | 二重課金や不正な注文は、後から取り消すほうが高くつく |
| 病歴・健康状態など、特に配慮が必要な情報を扱う | 人の診断を強くおすすめ | 漏れたときの影響が最も重い類型の一つ（下記） |
| 複数の会社やチームが一つのアプリを共有する／法人に売る | 設計まで見る監査 | 会社同士のデータの壁は、ツールでは確かめられない |
注意してほしいのは、国への報告義務は「下の段だけの話」ではないことです。個人情報保護委員会は、事業者が国に報告しなければならない漏えいを4つの類型で示しています。
- 要配慮個人情報（病歴など）が含まれる漏えい
- 不正に使われると財産的な被害が出るおそれがある漏えい（クレジットカード情報など）
- 不正アクセスなど、不正な目的の行為によるおそれがある漏えい
- 本人の数が1,000人を超える漏えい
人数の条件が付いているのは4つ目だけです。 報告の期限は、発覚から3〜5日以内に速報、30日以内に確報です（不正な目的によるおそれがある場合の確報は60日以内）。データベースの設定ミスを突かれて少人数のデータが抜かれた場合でも、報告が必要になり得るということです。他人の個人データを預かった時点で（表の3段目も含めて）、この義務は生じ得ます。 下の段ほど優先度が上がるのは、義務の有無ではなく、漏れたときの被害の重さが違うからです。詳しい要件は、記事末尾の参考文献にある個人情報保護委員会のページで確認してください。法務まわり全体の確認はAIで作ったアプリの法務チェックリストにまとめています。
2. Claude Code に「安全？」と聞くだけでは足りないのか
半分は足ります。 AIや無料ツールは、答えがコードの中にある問題を見つけるのが得意です。足りないのは、答えがコードの外——あなたの頭の中にある問題です。
AIとツールに任せてよいもの
- 鍵の書き込み：APIキーがコードに直接書かれていないか、ブラウザに送られていないか
- RLSの付け忘れ：RLS（データベースで「誰がどの行を見てよいか」を決める仕組み）が無効なテーブル。Supabase の Security Advisor は、RLSが無効な公開テーブルを「URLを知る誰でもデータを読み・編集・削除できる」としてエラー表示します
- 典型的な注入：入力欄からデータベースの命令を書き換えられる、画面に他人のスクリプトを埋め込まれる、といった型が決まった問題
- 古い部品：脆弱性が知られている部品（ライブラリ）を使っていないか
Claude Code には /security-review という確認コマンドがあり、公式ドキュメントでは「今のブランチ（作業の枝分かれ）の変更」を対象にしたセキュリティ確認と説明されています。変更分を見る機能なので、アプリ全体は一度も見ていない可能性があります。全体を見せたいときは「このリポジトリ全体をセキュリティの観点でレビューして」と明示して頼んでください。コードを読める開発者が、この範囲を自分の手で順に潰していく手順は、開発者向けのAI生成コード（vibe coding）の脆弱性診断にまとめています。
人が照合する必要があるもの
自動のレビューについて、作っている側自身がこう書いています。
- Anthropic：自動のセキュリティレビューは、既存のセキュリティ対策や手動のコードレビューを「置き換えるものではなく、補うもの」
- Lovable：組み込みのツールは一般的な問題の発見を助けるが「完全な安全は保証できない」。機密性の高いデータや重要な機能を扱うアプリでは「専門家によるセキュリティレビューの追加を検討してほしい」
なぜ補いが要るのか。いちばん分かりやすいのが「所有者チェック」の問題です。
利用者Aが、URLの末尾の番号を1つ変えるだけで利用者Bの予約を見られる——これは典型的な事故です（IDOR、またはBOLAと呼ばれます）。ところが、このときアプリに届く通信は、形としては完全に正しいものです。ログインしていて、形式も正しい。おかしいのは「Aが見てよいのはAの予約だけ」というルールに反していることで、そのルールはコードではなく、あなたの仕様の中にあります。 同じAIが仕様を推測して書いたコードを、同じAIが同じ推測で確かめても、推測の誤りは見つかりません。（これは筆者の見解です。ただし上の2社の記述と同じ方向の話です）
「RLSが全部オン」でも、まだ判断が残る理由 — 1,000件の一次調査から
RLSの不備は、実際に事故として公表されています。2025年には、AIアプリ作成サービス Lovable で作られたアプリのRLS不備により、未ログインの人が任意のテーブルを読み書きできたとする脆弱性が CVE-2025-48757（深刻度 CRITICAL）として登録されました（ベンダーは異議を出しています）。では、RLSを有効にさえすれば済むのか。
筆者は、Supabase を使う公開GitHubリポジトリ1,000件のRLS設定を静的に解析しました。RLSを設定していた994件のうち 91件（9.2%）が、「ログインした人なら誰でも全行を読める」条件を含んでいました。
この9.2%は「9.2%が危険」という意味ではありません。お知らせ一覧のように、ログインした全員に見せてよいデータなら、その設定で正解です。「これは意図どおりか」を確かめる必要がある、という意味です。 そしてその確認は、アプリの仕様を知っている人にしかできません。RLSの付け忘れは自動で見つかっても、付いている条件が正しいかどうかは、別の問題として残ります。
同じ調査では、筆者自身のスキャナーの別のルールが、80件の検出のうち約68%（54件）を誤って「危険」と判定していたことも分かりました。一件ずつ実際の設定を読んで、初めて分かったことです。ツールは言い過ぎることがあります（見落としがどれだけあるかは、この調査では測っていません）。どの警告が本物かを選り分けるのも、人の仕事です。調査の方法と限界はSupabase RLSセキュリティ実態調査に全部載せています。
AIに確認させるなら、こう聞く
「安全ですか？」と聞くと、AIは「はい、対策済みです」と答えがちです。代わりに、一覧を出させて、あなたが正解と照合する形にします。
このアプリの全テーブルについて、次の表を作ってください。推測で埋めず、
コード・SQL・RLSポリシーの該当箇所（ファイル名と行）を根拠として示してください。
| テーブル | 未ログインの人ができること | ログイン中の利用者Aが、利用者Bの行に対してできること（読む/作る/変える/消す） | 管理者だけができること | 根拠 |
根拠が見つからない欄は「不明」と書いてください。
service_role キー（全権限の鍵）を使っている箇所も、すべて一覧にしてください。
返ってきた表のうち、「利用者AがBの行に対してできること」の欄が、あなたの想定と1つでも食い違えば、そこが直すべき箇所です。 照合できない欄が多い、あるいは「不明」だらけなら、そこから先が人に頼む価値のある部分です。
3. いつ頼むか — 公開フェーズ別の節目
頼むなら「本物の顧客データを入れる前」が、最も安く、最も効果があります。 データが入る前なら、設定を直すだけで済みます。データが入った後だと、直す作業そのものに慎重さが要り、すでに見えてしまったかもしれないデータの確認も必要になります。
| フェーズ | 人の診断 | 補足 |
|---|---|---|
| 試作・自分だけで触っている | 不要 | この段階で払うお金は、仕様が変わると無駄になりやすい |
| 仲間内のβ版（データは架空） | 基本は不要 | 無料チェックで穴を潰しておくと、後の診断が安くなる |
| 本物の顧客データを入れる直前 | 最も効果が高い節目 | 判断表の下3段に当たるなら、ここで |
| 決済を始める直前 | 推奨 | 二重課金の防止は決済の二重課金の記事も参照 |
| ファイルのアップロード機能を足すとき | 推奨 | 他人のファイルを開けないか、が新しく問題になる |
| 法人に売る・セキュリティの質問票を渡されたとき | 推奨 | 「第三者の確認を受けたか」を問われることがある |
| 権限まわりの大きな機能追加の後 | 推奨 | 招待・チーム・管理者機能などは、作り直しで条件が崩れやすい |
| すでに公開して実データが入っている | 今すぐ | まず無料チェック。鍵が露出していたら、診断より先に作り直す |
鍵の作り直し方はAPIキーが他人に見える理由の記事にあります。
4. 診断で何を見てもらうのか
AIで作ったアプリなら、外から叩く診断より「コードと設定を読む診断」のほうが費用対効果で勝ちやすい、というのが筆者の考えです。まず言葉を整理します。
- 脆弱性診断：動いているアプリに外から通信を送り、穴があるか確かめる。中身は見ないことが多い
- ソースコードレビュー：コードとデータベースの設定を読んで確かめる
- 監査（設計レビュー）：上の2つに加え、「誰が何をしてよいか」の設計そのものが妥当かまで確かめる
Claude Code や Lovable で作ったアプリは、コードとデータベースの設定がすべて手元にあります。そのため、外から叩くだけの診断より、コードと設定を読む方法のほうが、少ない費用で多くの穴に届きやすいのです。
公開前に最低限見てもらいたいのは、危険な順に次の4つです。
- データベースの権限（RLS）：他人の行が見えないか。説明はRLSを非エンジニア向けに説明した記事へ
- 鍵の露出：全権限の鍵がブラウザに送られていないか
- 所有者チェック：ログインしているだけで、他人のデータを操作できないか。詳しくは「ログインしてる風」と本物の認可の記事へ
- 決済の二重処理：同じ支払いが二度処理されないか
複数の会社が使うアプリなら、会社同士のデータの壁、全権限の鍵（service_role）を使う処理の経路、業務ルールの悪用（割引の重ね掛けなど）まで広がります。開発者向けに監査の中身を詳しく書いたものがセキュリティ監査は何を見るのかです。
5. 費用 — 相場と、金額が増える条件
相場は、範囲によって桁が変わります。 金額だけを並べて比べると判断を誤るので、「何を見て、何をしないか」と一緒に見てください。以下は2026年10月12日時点の公開情報で、品質の比較ではありません。
| 種類 | 公開されている価格の例 | 範囲の特徴 | 出典 |
|---|---|---|---|
| 無料ツール | 追加費用なし（利用中のプランの範囲内） | Supabase Security Advisor、Claude Code /security-review、Lovable の組み込みスキャンなど。仕様との照合はしない | 各公式ドキュメント |
| AI解析＋人の確認（行数課金） | 1行あたり一円（税抜）、最低1万円 | セキュリティを含む6観点。通常1週間以内 | フォレスト株式会社「コードドック」のプレスリリース |
| 診断＋リファクタリングまで含む清書型 | ライト30万円〜（5,000行まで、税別） | 診断・リファクタリング・レポート・レビュー会。修正やテストは上位プラン | IT Leaders の記事（トライビュー・イノベーション「バイブ清書」） |
| 企業向けWeb脆弱性診断 | ツール10万〜30万円／手動50万〜150万円／ハイブリッド60万〜200万円 | 企業システムを想定した一般的な相場 | cloudpack のコラム |
| 筆者のサービス（自社） | 公開前ライト診断 ¥29,800〜／スポット診断 ¥98,000〜／標準監査 ¥280,000〜／伴走・修正実装 ¥680,000〜（税別） | ライト診断は「致命的な穴の有無の判定」に範囲を絞ったもの | 料金と範囲 |
金額を押し上げる条件は、おおむね次のとおりです。見積もりを取る前に、自分のアプリがどれに当たるかを数えておくと話が早くなります。
- テーブルの数と、利用者の役割の数：役割（一般・管理者・スタッフなど）が増えるほど、「誰が何をしてよいか」の組み合わせが増える
- 複数の会社が使うか：会社同士の壁の確認が加わる
- 決済・ファイル保存・外部サービスとの連携（Webhook）の有無
- データベース内の関数：特に、権限を飛び越えて動く関数（
SECURITY DEFINER） - 動いている本番に通信を送って確かめるか：コードを読むだけより手間がかかる
- 修正まで頼むか、直した後の再確認を含むか
- 納期の急ぎ
一般的なWebアプリの診断費用の読み方は、発注者向けに書いたWebアプリ脆弱性診断の費用・相場で詳しく扱っています。
6. 頼む前に、無料でできること
次の4つを順に済ませると、診断が要らないと分かることもありますし、頼む場合も範囲が絞れて安くなります。
- 20問のセルフ診断：公開前セルフ診断（無料・登録不要）に、はい／いいえ／わからない で答えると、危険な順に並んだ結果と、AIに貼れる修正指示が出ます。回答はブラウザの外に送られません
- Supabase の Security Advisor：ダッシュボードで警告が出ていないか確認する。ERROR が出ていたら最優先で直す
- Claude Code の
/security-review：出てきた指摘をAIに直させる - 第2章の確認用プロンプト：返ってきた表を、自分の想定と照合する
判断表の上の3段に当たり、この4つで食い違いが無ければ、ここで終えて構いません。 下の段に当たる場合や、照合できない欄が残った場合に、次の章へ進んでください。
7. 頼むときに渡すもの・渡さないもの
診断のために、鍵の値や顧客データを渡す必要はありません。 ただ、何も考えずに「招待」すると、意図した以上の権限を渡してしまうことがあります。各サービスの公式ドキュメントで確認できた仕様をもとに、渡し方を整理します。
| 渡すもの | おすすめの渡し方 | 注意点（公式ドキュメントで確認） |
|---|---|---|
| コード | GitHub で招待する | 個人アカウントのリポジトリには、読み取り専用の招待がありません。 共同作業者は書き込みもできます。読み取りだけにしたい場合は、無料の Organization（組織）に移して Read 権限で招待するか、作業後に招待を外すと決めておく |
| データベースの構造 | supabase/migrations フォルダ、または supabase db dump の出力ファイル | Supabase の Read-Only メンバーは、SQLエディタで SELECT（データの読み出し）ができる＝本物の顧客データも見えます。プロジェクト単位の権限は Team／Enterprise プランのみ。supabase db dump は既定で構造だけを出力し、データを含みません。ただし auth・storage の設定は含まれないので、ファイル置き場の権限は別に伝える。コマンドが分からなければ、AIに「supabase db dump でデータ抜きの構造だけ出して」と頼めば作れます |
| ホスティング（Vercel） | 通常は不要。環境変数の「名前」の一覧と、本番URLで足りる | Vercel のチームの役割は Pro／Enterprise プランで使える機能（Pro には閲覧専用の Pro Viewer 枠がある）。無理にアクセスを渡さなくてよい |
| 鍵・パスワードの値 | 渡さない | どうしても必要なら、パスワード管理ツールの共有機能で渡し、作業後に作り直す。メールやチャットに貼らない |
| テスト用アカウント | 2つ（利用者A・利用者B） | 「AがBのデータを見られないか」を確かめるのに2つ必要。管理者がいるなら管理者用も |
| 「誰が何をしてよいか」の表 | 下の雛形を埋めて渡す | あなたにしか書けない、いちばん価値のある資料 |
| 秘密保持契約（NDA） | コードを渡す前に結ぶ | 無料相談の段階なら、コードを渡さずに画面と説明だけで進められることも多い |
「誰が何をしてよいか」の表は、次の形で十分です。完璧でなくて構いません。分からない欄は「分からない」と書いてください。それ自体が、診断で確かめるべき箇所の目印になります。
| データ | 未ログインの人 | 本人 | 同じ会社・チームの他の人 | 管理者 |
|---|---|---|---|---|
| 例：予約 | 見られない | 見る・作る・取り消す | 見る | 全部 |
| 例：プロフィール | 名前だけ見られる | 見る・変える | 名前だけ見る | 見る |
ステージング環境（本番とは別の試験用環境）が無くても、診断はできます。 コードと構造を読む方法なら、本番に触れません。本番に通信を送って確かめる場合は、対象・日時・使うテスト用アカウントを事前に書面で決め、本物の顧客データを書き換えない方法に限るのが原則です。
引き継ぎ全般の準備（外部サービスの一覧の作り方など）はエンジニアに相談・引き継ぐときの準備にまとめています。
8. 依頼先の選び方 — 頼む前に聞く7つの質問
「どこが一番か」は、あなたのアプリと予算で変わります。代わりに、どこに頼む場合でも使える質問を挙げます。筆者のサービスを選ぶかどうかとは関係なく使ってください。
- 何を見て、何を見ないかを、書面で示してもらえますか？ 範囲の外は、診断を受けても安全とは言えません
- 自動ツールの結果を、人が一件ずつ確かめていますか？ 第2章のとおり、ツールは言い過ぎもします。確かめていない一覧は、あなたが選り分ける羽目になります
- 指摘ごとに、危険度と再現の手順が付きますか？
- コードが読めない私でも分かる説明と、直し方の指示が付きますか？ AIに貼れる形だと、自分で直せます
- 直した後の再確認は含まれますか？ 別料金ですか？
- Supabase や Next.js のような、私のアプリの構成を見た経験はありますか？
- 本番環境に通信を送りますか？ 送るなら、どの範囲で、どう合意しますか？
逆に「これで100%安全です」と保証する依頼先には注意してください。診断は、決めた範囲の中で見つかった問題を報告するものです。範囲の外や、将来の変更までは保証できません。客観的な目安としては、IPA の「情報セキュリティサービス基準適合サービスリスト」に脆弱性診断の区分があります（ただしリストには「IPAによるいかなる保証等をも意味するものではありません」と明記されています）。
筆者の公開前ライト診断の納品物がどういう形かは、架空のアプリで作ったレポートの見本で確認できます。依頼する・しないにかかわらず、「診断の結果はこういう形で返ってくる」という目安になると思います。
まとめ — AIで作ったこと自体は、問題ではない
AIを使って作ったことは、何も間違っていません。AIは実装を確実に速くします。問題になるのは、作ったAIと同じAIに「大丈夫？」と聞くだけで、「誰がどのデータを見てよいか」という、あなたにしか答えられない部分まで確認した気になることです。
- 預かるものが自分のデータだけなら、無料のチェックとAIで足ります
- 他人の個人情報やお金を預かるなら、本物のデータを入れる前に一度、人に照合してもらう
- 頼むときは、鍵もデータも渡さずに、コード・構造・テスト用アカウント2つ・「誰が何をしてよいか」の表を渡す
自動でできる確認は自分で済ませ、人が見る価値のある境界だけを専門家に渡す。それが、いちばん安く、いちばん確実な順番です。