# AIで作ったアプリに、人によるセキュリティ診断は必要？ — 要る人・要らない人の判断表と、費用・時期・頼み方

> Claude Code・Cursor・Lovable で作ったアプリに、お金を払って人の診断を入れるべきか。預かるデータで決まる判断表、AIの自己チェックで足りる範囲と足りない範囲、公開フェーズ別の頼む時期、相場と金額が増える条件、鍵や顧客データを渡さずに見てもらう方法を、非エンジニア向けにまとめました。

- 公開日: 2026-10-12
- 著者: 友田 陽大
- タグ: バイブコーディング, セキュリティ, 脆弱性診断, 個人開発, Supabase, 発注
- URL: https://tomodahinata.com/blog/ai-app-security-review-need-cost-timing
- カテゴリ: AIで作ったアプリの運営
- 総合ガイド: https://tomodahinata.com/blog/ai-app-pre-launch-guide-for-non-engineers

## 要点

- 人による診断が要るかは、アプリの出来ではなく「何を預かるか」で決まる。自分だけが使うアプリや、他人のデータを保存しないアプリなら、無料のチェックとAIでの修正で十分なことが多い
- Claude Code の /security-review や Supabase の Security Advisor は、鍵の露出やRLS（誰がどの行を見てよいかの設定）の付け忘れのような「答えがコードの中にある」問題に強い。一方「誰がどのデータを見てよいか」の正解はコードの外（あなたの頭の中）にあるため、人が照合する必要がある
- 筆者が公開リポジトリ1,000件を調べた一次調査では、RLSを設定済みの994件のうち9.2%が「ログインした人なら誰でも全行を読める」設定を含んでいた。これが穴かどうかは、アプリの意図を知らないと判定できない
- 頼むなら「本物の顧客データを入れる前」が最も安く効果が高い。決済開始・ファイルアップロード追加・法人への販売の前も同じ節目
- 診断を頼むときに、鍵の値や顧客データを渡す必要はない。コード、データベースの構造（データ抜き）、テスト用アカウント2つ、「誰が何をしてよいか」の表があれば始められる

---

**結論から書きます。Claude Code・Cursor・Lovable などAIで作ったアプリに、お金を払って人のセキュリティ診断を入れるべきかは、アプリの出来ではなく「何を預かるか」で決まります。** 自分だけが使うアプリや、他人のデータを保存しないアプリなら、無料のチェックとAIでの修正で足りることが多いです。他人の個人情報を業務で預かる、お金が動く——そうなる**前に**一度だけ、人の目を入れる価値があります。

この記事では、あなたのアプリがどちらに当たるかを判断表で決め、頼む場合の時期・相場・渡すものまでを順に説明します。

先にお断りしておくと、筆者は「公開前ライト診断」という有料の診断を提供しています。だからこそ、**診断が要らないケースを先に、はっきり書きます**。全員に有料診断が必要だという話ではありません。

---

## 1. 判断表 — あなたのアプリに、人の診断は要るか

人の診断が要るのは、他人の個人情報やお金を預かる場合です。判断の問いは「漏れたら、誰に謝ることになるか」。謝る相手が自分だけなら、急ぐ必要はありません。

| あなたのアプリの状況 | おすすめ | 理由 |
| --- | --- | --- |
| 自分と家族・仲間内だけが使う | 人の診断は不要 | 漏れて困る他人のデータが無い |
| 公開するが、ログインもデータ保存も無い（計算ツール、紹介ページなど） | 人の診断は不要。鍵の露出だけ確認 | 盗まれる中身が、APIキー（外部サービスの合鍵）くらいしか無い |
| 他人がログインし、その人のメールアドレスなどを保存する | 無料チェックとAIで直す。迷う項目が残ったら人に | 「他人のデータが見えないか」の確認が要るが、多くは自力で確かめられる |
| 顧客名簿・予約・問い合わせなど、他人の個人情報を業務で預かる | **本物のデータを入れる前に**人の診断 | 漏れたときの影響が自分の外に出る |
| 決済がある、お金や在庫が動く | **決済を始める前に**人の診断 | 二重課金や不正な注文は、後から取り消すほうが高くつく |
| 病歴・健康状態など、特に配慮が必要な情報を扱う | 人の診断を強くおすすめ | 漏れたときの影響が最も重い類型の一つ（下記） |
| 複数の会社やチームが一つのアプリを共有する／法人に売る | 設計まで見る監査 | 会社同士のデータの壁は、ツールでは確かめられない |

注意してほしいのは、国への報告義務は「下の段だけの話」ではないことです。個人情報保護委員会は、事業者が国に報告しなければならない漏えいを4つの類型で示しています。

1. 要配慮個人情報（病歴など）が含まれる漏えい
2. 不正に使われると財産的な被害が出るおそれがある漏えい（クレジットカード情報など）
3. 不正アクセスなど、不正な目的の行為によるおそれがある漏えい
4. 本人の数が1,000人を超える漏えい

**人数の条件が付いているのは4つ目だけです。** 報告の期限は、発覚から3〜5日以内に速報、30日以内に確報です（不正な目的によるおそれがある場合の確報は60日以内）。データベースの設定ミスを突かれて少人数のデータが抜かれた場合でも、報告が必要になり得るということです。**他人の個人データを預かった時点で（表の3段目も含めて）、この義務は生じ得ます。** 下の段ほど優先度が上がるのは、義務の有無ではなく、漏れたときの被害の重さが違うからです。詳しい要件は、記事末尾の参考文献にある個人情報保護委員会のページで確認してください。法務まわり全体の確認は[AIで作ったアプリの法務チェックリスト](/blog/ai-app-legal-checklist-japan)にまとめています。

---

## 2. Claude Code に「安全？」と聞くだけでは足りないのか

**半分は足ります。** AIや無料ツールは、答えがコードの中にある問題を見つけるのが得意です。足りないのは、答えがコードの外——あなたの頭の中にある問題です。

### AIとツールに任せてよいもの

- **鍵の書き込み**：APIキーがコードに直接書かれていないか、ブラウザに送られていないか
- **RLSの付け忘れ**：RLS（データベースで「誰がどの行を見てよいか」を決める仕組み）が無効なテーブル。Supabase の Security Advisor は、RLSが無効な公開テーブルを「URLを知る誰でもデータを読み・編集・削除できる」としてエラー表示します
- **典型的な注入**：入力欄からデータベースの命令を書き換えられる、画面に他人のスクリプトを埋め込まれる、といった型が決まった問題
- **古い部品**：脆弱性が知られている部品（ライブラリ）を使っていないか

Claude Code には `/security-review` という確認コマンドがあり、公式ドキュメントでは「今のブランチ（作業の枝分かれ）の変更」を対象にしたセキュリティ確認と説明されています。変更分を見る機能なので、アプリ全体は一度も見ていない可能性があります。全体を見せたいときは「このリポジトリ全体をセキュリティの観点でレビューして」と明示して頼んでください。コードを読める開発者が、この範囲を自分の手で順に潰していく手順は、開発者向けの[AI生成コード（vibe coding）の脆弱性診断](/blog/ai-generated-code-vulnerability-assessment-vibe-coding-security-guide)にまとめています。

### 人が照合する必要があるもの

自動のレビューについて、作っている側自身がこう書いています。

- 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セキュリティ実態調査](/blog/supabase-rls-security-field-study)に全部載せています。

### AIに確認させるなら、こう聞く

「安全ですか？」と聞くと、AIは「はい、対策済みです」と答えがちです。代わりに、**一覧を出させて、あなたが正解と照合する**形にします。

```text
このアプリの全テーブルについて、次の表を作ってください。推測で埋めず、
コード・SQL・RLSポリシーの該当箇所（ファイル名と行）を根拠として示してください。

| テーブル | 未ログインの人ができること | ログイン中の利用者Aが、利用者Bの行に対してできること（読む/作る/変える/消す） | 管理者だけができること | 根拠 |

根拠が見つからない欄は「不明」と書いてください。
service_role キー（全権限の鍵）を使っている箇所も、すべて一覧にしてください。
```

返ってきた表のうち、**「利用者AがBの行に対してできること」の欄が、あなたの想定と1つでも食い違えば、そこが直すべき箇所です。** 照合できない欄が多い、あるいは「不明」だらけなら、そこから先が人に頼む価値のある部分です。

---

## 3. いつ頼むか — 公開フェーズ別の節目

**頼むなら「本物の顧客データを入れる前」が、最も安く、最も効果があります。** データが入る前なら、設定を直すだけで済みます。データが入った後だと、直す作業そのものに慎重さが要り、すでに見えてしまったかもしれないデータの確認も必要になります。

| フェーズ | 人の診断 | 補足 |
| --- | --- | --- |
| 試作・自分だけで触っている | 不要 | この段階で払うお金は、仕様が変わると無駄になりやすい |
| 仲間内のβ版（データは架空） | 基本は不要 | 無料チェックで穴を潰しておくと、後の診断が安くなる |
| **本物の顧客データを入れる直前** | **最も効果が高い節目** | 判断表の下3段に当たるなら、ここで |
| 決済を始める直前 | 推奨 | 二重課金の防止は[決済の二重課金の記事](/blog/ai-app-payment-double-charge-prevention)も参照 |
| ファイルのアップロード機能を足すとき | 推奨 | 他人のファイルを開けないか、が新しく問題になる |
| 法人に売る・セキュリティの質問票を渡されたとき | 推奨 | 「第三者の確認を受けたか」を問われることがある |
| 権限まわりの大きな機能追加の後 | 推奨 | 招待・チーム・管理者機能などは、作り直しで条件が崩れやすい |
| すでに公開して実データが入っている | 今すぐ | まず無料チェック。鍵が露出していたら、診断より先に作り直す |

鍵の作り直し方は[APIキーが他人に見える理由の記事](/blog/ai-app-api-key-exposure-explained)にあります。

---

## 4. 診断で何を見てもらうのか

AIで作ったアプリなら、外から叩く診断より「コードと設定を読む診断」のほうが費用対効果で勝ちやすい、というのが筆者の考えです。まず言葉を整理します。

- **脆弱性診断**：動いているアプリに外から通信を送り、穴があるか確かめる。中身は見ないことが多い
- **ソースコードレビュー**：コードとデータベースの設定を読んで確かめる
- **監査（設計レビュー）**：上の2つに加え、「誰が何をしてよいか」の設計そのものが妥当かまで確かめる

Claude Code や Lovable で作ったアプリは、コードとデータベースの設定がすべて手元にあります。そのため、外から叩くだけの診断より、**コードと設定を読む方法のほうが、少ない費用で多くの穴に届きやすい**のです。

公開前に最低限見てもらいたいのは、危険な順に次の4つです。

1. **データベースの権限（RLS）**：他人の行が見えないか。説明は[RLSを非エンジニア向けに説明した記事](/blog/supabase-rls-explained-for-non-engineers)へ
2. **鍵の露出**：全権限の鍵がブラウザに送られていないか
3. **所有者チェック**：ログインしているだけで、他人のデータを操作できないか。詳しくは[「ログインしてる風」と本物の認可の記事](/blog/ai-generated-login-vs-real-authorization)へ
4. **決済の二重処理**：同じ支払いが二度処理されないか

複数の会社が使うアプリなら、会社同士のデータの壁、全権限の鍵（service_role）を使う処理の経路、業務ルールの悪用（割引の重ね掛けなど）まで広がります。開発者向けに監査の中身を詳しく書いたものが[セキュリティ監査は何を見るのか](/blog/nextjs-supabase-security-audit-scope-when-needed-guide)です。

---

## 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〜（税別） | ライト診断は「致命的な穴の有無の判定」に範囲を絞ったもの | [料金と範囲](/aegis/audit) |

金額を押し上げる条件は、おおむね次のとおりです。見積もりを取る前に、自分のアプリがどれに当たるかを数えておくと話が早くなります。

- **テーブルの数と、利用者の役割の数**：役割（一般・管理者・スタッフなど）が増えるほど、「誰が何をしてよいか」の組み合わせが増える
- **複数の会社が使うか**：会社同士の壁の確認が加わる
- **決済・ファイル保存・外部サービスとの連携（Webhook）の有無**
- **データベース内の関数**：特に、権限を飛び越えて動く関数（`SECURITY DEFINER`）
- **動いている本番に通信を送って確かめるか**：コードを読むだけより手間がかかる
- **修正まで頼むか、直した後の再確認を含むか**
- **納期の急ぎ**

一般的なWebアプリの診断費用の読み方は、発注者向けに書いた[Webアプリ脆弱性診断の費用・相場](/blog/web-application-vulnerability-assessment-cost-pricing-guide)で詳しく扱っています。

---

## 6. 頼む前に、無料でできること

次の4つを順に済ませると、診断が要らないと分かることもありますし、頼む場合も範囲が絞れて安くなります。

1. **20問のセルフ診断**：[公開前セルフ診断（無料・登録不要）](/vibe-coding/checkup)に、はい／いいえ／わからない で答えると、危険な順に並んだ結果と、AIに貼れる修正指示が出ます。回答はブラウザの外に送られません
2. **Supabase の Security Advisor**：ダッシュボードで警告が出ていないか確認する。ERROR が出ていたら最優先で直す
3. **Claude Code の `/security-review`**：出てきた指摘をAIに直させる
4. **第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） | コードを渡す前に結ぶ | 無料相談の段階なら、コードを渡さずに画面と説明だけで進められることも多い |

「誰が何をしてよいか」の表は、次の形で十分です。完璧でなくて構いません。分からない欄は「分からない」と書いてください。それ自体が、診断で確かめるべき箇所の目印になります。

| データ | 未ログインの人 | 本人 | 同じ会社・チームの他の人 | 管理者 |
| --- | --- | --- | --- | --- |
| 例：予約 | 見られない | 見る・作る・取り消す | 見る | 全部 |
| 例：プロフィール | 名前だけ見られる | 見る・変える | 名前だけ見る | 見る |

**ステージング環境（本番とは別の試験用環境）が無くても、診断はできます。** コードと構造を読む方法なら、本番に触れません。本番に通信を送って確かめる場合は、対象・日時・使うテスト用アカウントを事前に書面で決め、本物の顧客データを書き換えない方法に限るのが原則です。

引き継ぎ全般の準備（外部サービスの一覧の作り方など）は[エンジニアに相談・引き継ぐときの準備](/blog/handing-over-ai-app-to-engineer)にまとめています。

---

## 8. 依頼先の選び方 — 頼む前に聞く7つの質問

「どこが一番か」は、あなたのアプリと予算で変わります。代わりに、どこに頼む場合でも使える質問を挙げます。筆者のサービスを選ぶかどうかとは関係なく使ってください。

1. **何を見て、何を見ないかを、書面で示してもらえますか？** 範囲の外は、診断を受けても安全とは言えません
2. **自動ツールの結果を、人が一件ずつ確かめていますか？** 第2章のとおり、ツールは言い過ぎもします。確かめていない一覧は、あなたが選り分ける羽目になります
3. **指摘ごとに、危険度と再現の手順が付きますか？**
4. **コードが読めない私でも分かる説明と、直し方の指示が付きますか？** AIに貼れる形だと、自分で直せます
5. **直した後の再確認は含まれますか？ 別料金ですか？**
6. **Supabase や Next.js のような、私のアプリの構成を見た経験はありますか？**
7. **本番環境に通信を送りますか？ 送るなら、どの範囲で、どう合意しますか？**

逆に「これで100%安全です」と保証する依頼先には注意してください。診断は、決めた範囲の中で見つかった問題を報告するものです。範囲の外や、将来の変更までは保証できません。客観的な目安としては、IPA の「情報セキュリティサービス基準適合サービスリスト」に脆弱性診断の区分があります（ただしリストには「IPAによるいかなる保証等をも意味するものではありません」と明記されています）。

筆者の公開前ライト診断の納品物がどういう形かは、[架空のアプリで作ったレポートの見本](/vibe-coding/sample-report)で確認できます。依頼する・しないにかかわらず、「診断の結果はこういう形で返ってくる」という目安になると思います。

---

## まとめ — AIで作ったこと自体は、問題ではない

AIを使って作ったことは、何も間違っていません。AIは実装を確実に速くします。問題になるのは、作ったAIと同じAIに「大丈夫？」と聞くだけで、「誰がどのデータを見てよいか」という、あなたにしか答えられない部分まで確認した気になることです。

- 預かるものが自分のデータだけなら、無料のチェックとAIで足ります
- 他人の個人情報やお金を預かるなら、本物のデータを入れる前に一度、人に照合してもらう
- 頼むときは、鍵もデータも渡さずに、コード・構造・テスト用アカウント2つ・「誰が何をしてよいか」の表を渡す

自動でできる確認は自分で済ませ、人が見る価値のある境界だけを専門家に渡す。それが、いちばん安く、いちばん確実な順番です。