前回の記事「バイブコーディングで作ったWeb/モバイルアプリのセキュリティチェック実践ガイド」では、AIレビュー・自動ツール・手動テストの3層で穴を潰す方法を、ある程度コードが読める人向けに解説しました。
その後、知人のバイブコーダーから率直な声をもらいました。「内容は分かるけど、Gitleaks、Semgrep、ZAP……と言われても、自分では手が止まってしまう」。AIと会話しながらアプリを完成させた人ほど、ツールのインストールやログの読み方で挫折しがちです。
そこで本記事では発想を逆にします。チェックの手順そのものを「AIへの指示書（1ファイル）」にまとめ、いつも使っているAIに渡して実行させる方法です。人間がやることは、AIの質問に答え、最後のレポートを読み、修正に「OK」を出すことだけです。
筆者はネットワークのTAC（テクニカルアシスタンスセンター）で、長年障害対応と運用手順書づくりに携わってきました。現場で学んだのは、「詳しい人の頭の中」ではなく「誰がやっても同じ結果になる手順書」が品質を担保するということです。今回の指示書も、その考え方で設計しています。
対象読者は、プログラミング経験がほとんどないままClaude Code・Cursor・Windsurfなどでアプリを作った個人開発者、そして社内ツールをAIで内製し始めた中小企業の担当者です。
はじめに——「動いた」の次にやるべき最低限のこと
バイブコーディングで作ったアプリは、見た目も動作も問題なく見えます。しかし、セキュリティの穴は「動作確認」では見つかりません。むしろ、AIは「とりあえず動く」ことを優先して、アクセス制限やキーの管理を後回しにしたコードを書きがちです。
本記事のゴールは、専門家レベルの診断ではありません。第三者に「何をチェックしたの？」と聞かれたときに、根拠を示して説明できる水準です。具体的には次の3点を満たすことを目指します。
- 基準に沿っている：OWASP ASVS Level 1 や IPA「安全なウェブサイトの作り方」に対応づけて確認している
- 複数の手段で重ねている：ツールによる自動検査とAIによるコードレビューの両方を実施している
- 記録が残っている：ツールの生ログとレポートが保存され、修正の履歴も追える
全体像——AIに任せる部分と、人間が判断する部分
セルフチェックは、次の9つのフェーズで進みます。ポイントは、Phase 1〜6はAIが「調べて記録するだけ」で、コードには一切手を触れないことです。修正は、人間が承認したものだけをPhase 7で行います。
| Phase | 内容 | 担当 | 人間がやること |
|---|---|---|---|
| 0 | 構成の把握・リスク判定・ツール準備 | AI | 5問程度の質問に答える／インストールを許可する |
| 1 | 秘密情報（APIキーなど）の漏えいチェック | AI＋Gitleaks | なし |
| 2 | 依存ライブラリの脆弱性チェック | AI＋OSV-Scanner / npm audit | なし |
| 3 | 静的コード解析 | AI＋Semgrep | なし |
| 4 | AIによるコードレビュー（チェックリスト方式） | AI | ダッシュボード設定の確認を頼まれたら対応する |
| 5 | ローカルで動かして外から検査 | AI＋OWASP ZAP | アプリの起動を許可する |
| 6 | レポート作成 | AI | レポートを読む |
| 7 | 修正と再検査 | AI | 修正案ごとに「OK」を出す |
| 8 | 継続チェックの仕組みづくり（任意） | AI | GitHubの設定画面を操作する |
人間が実質的に判断するのは、Phase 6のレポートとPhase 7の修正承認の2か所だけです。
まず知っておきたい「バイブコーディングの典型的な穴」
AIへの指示書では、次の項目を最重点で確認させます。どれも、AIが書いたコードで頻繁に見つかるものです。
| 典型的な穴 | 何が起きるか | 危険度 |
|---|---|---|
| Supabase の RLS（行レベルセキュリティ）が無効 | 誰でも全ユーザーのデータを読み書きできる | 🔴 致命的 |
| Firebase のルールが「テストモード」のまま | 同上。期限切れで突然アプリが止まることもある | 🔴 致命的 |
| フロントエンドにサーバー用のキーを埋め込んでいる | OpenAIなどのキーを盗まれ、高額請求される | 🔴 致命的 |
| 認可の欠如（IDOR） | URLのIDを書き換えると他人のデータが見える | 🔴 高 |
| 管理画面を「隠しているだけ」 | URLを直接開けば誰でも管理操作ができる | 🔴 高 |
| レート制限がない | ログインの総当たりや、AI APIの課金爆発 | 🟡 中〜高 |
| CORSが全許可（*）、エラー内容の丸見え | 攻撃の足がかりになる情報が漏れる | 🟡 中 |
特に「フロントエンドに出る環境変数」には注意が必要です。NEXT_PUBLIC_・VITE_・REACT_APP_で始まる変数は、ブラウザに配信されるため誰でも見られます。ここにサーバー専用のキーを入れてしまうケースは、非常によく見かけます。
準備——使うAIツールと前提条件
推奨：フォルダを読めてコマンドを実行できるAI
Claude Code、Cursor、Windsurf、GitHub Copilot（エージェントモード）など、プロジェクトのフォルダを読み、ターミナルでコマンドを実行できるAIを推奨します。指示書の内容をほぼ自動で進められます。
チャット型AI（ChatGPT・ClaudeのWeb版など）の場合
フォルダを直接読めないAIでも実施はできますが、AIに指示されたファイルの中身を貼り付けたり、コマンドを自分で実行したりする必要があります。手間が増え、見落としも増える点は理解しておきましょう。.envの中身やAPIキーそのものは、絶対に貼り付けないでください。キーの名前を伝えるだけで十分です。
事前に用意しておくもの
- Git（なければAIが初期化を提案します）
- アプリをローカル（自分のPC）で起動できる状態
- 本番とは別の、開発用のデータベースまたはテスト用データ
- Docker（任意。OWASP ZAPによる動的スキャンで使います）
使い方——3ステップで完了
ステップ1：指示書ファイルを置く
次の章の指示書をコピーし、SECURITY_CHECK_FLOW.mdという名前で、プロジェクトフォルダの一番上（README.mdと同じ場所）に保存します。
ステップ2：AIに一文で依頼する
SECURITY_CHECK_FLOW.md を読んで、書かれているフローを Phase 0 から順に実行してください。ステップ3：レポートを読み、修正を承認する
完了するとsecurity-report/REPORT.mdが作られます。「🔴 今すぐ直す」の項目について、AIが1件ずつ修正案を出すので、内容を確認して承認します。所要時間の目安は、初回が1〜2時間（ツールのインストールを含む）、2回目以降が30分程度です。
コピペで使える「AIへの指示書」
以下をそのままコピーして使えます。自分のアプリに合わせて書き換える必要はありません。Phase 0でAI自身がアプリの構成を調べ、内容を調整します。
# Webアプリ セキュリティ・セルフチェック指示書（AIエージェント用）
あなたは、このプロジェクトのセキュリティチェックを担当するエージェントです。
ユーザーはプログラミング初心者で、このアプリはAIとの対話（バイブコーディング）で作られています。
以下のルールとフェーズに従って、チェックを実行・記録・報告してください。
## 基本ルール（必ず守ること）
1. Phase 1〜6 は調査と記録のみ。コードは変更しない。修正は Phase 7 でユーザーの承認後に行う。
2. 作業は専用ブランチ security-check-YYYYMMDD で行う。
3. 秘密情報は表示しない（sk-****abcd のように伏せ字にする）。
4. 動的スキャンの対象は localhost のみ。本番URLや第三者のサイトには実行しない。
5. DBの削除・初期化、git push --force、Git履歴の書き換えは、明示的な承認なしに行わない。
6. 説明は平易な日本語で行い、専門用語には一言で説明を添える。
7. ツールが使えない場合は、目視のコードレビューで代替し、レポートにその旨を明記する。
8. 結果はすべて security-report/ に保存し、このフォルダを .gitignore に追加する。
## Phase 0：事前確認
- 言語・フレームワーク、DB・認証（Supabase/Firebase等）、外部API、デプロイ先、ローカルでの起動方法を
特定し、security-report/00_overview.md に記録する。
- ユーザーに最大5問まで質問する（個人情報の有無／決済の有無／ログインと管理画面の有無／公開済みか／AI機能の有無）。
- リスクレベルを判定する。高＝個人情報・決済・医療金融データを扱う／中＝ログインとユーザーデータあり／低＝表示のみ。
- gitleaks、semgrep、osv-scanner（または npm audit / pip-audit）、docker の有無を確認する。
ないものは、インストール方法を提示し、承認を得てから導入する。
## Phase 1：秘密情報の漏えい
- gitleaks git --report-path security-report/gitleaks.json -v を実行する（旧版は gitleaks detect）。
- .env がGitに含まれていないか、過去にコミットされていないかを確認する（git log --all -- .env*）。
- NEXT_PUBLIC_ / VITE_ / REACT_APP_ / EXPO_PUBLIC_ で始まる変数に、サーバー専用キー
（Supabase service_role、OpenAI/Anthropic キー、Stripe sk_live_ 等）がないかを確認する。
- ビルド成果物（dist/、.next/static/ 等）にキーが含まれていないかを確認する。
- 漏えいがあれば🔴とし、「コードから消すだけでは不十分で、キーの無効化と再発行が必須」と伝える。
## Phase 2：依存ライブラリ
- osv-scanner scan source -r . または npm audit --json の結果を保存する。
- Critical/High について、実際に使っている機能かどうかを確認し、影響と更新先バージョンを記録する。
## Phase 3：静的解析
- semgrep scan --config auto --json -o security-report/semgrep.json を実行する。
- 1件ずつコードを読んで、誤検知かどうかを判断し、理由を記録する。
## Phase 4：AIコードレビュー
以下の全項目について OK/NG/該当なし と根拠（ファイル名:行番号）を security-report/04_review.md に記録する。
[A. バイブコーディング頻出]
- Supabase：全テーブルで RLS が有効か。using (true) のような全許可ポリシーがないか。
- Firebase：Firestore/Storage のルールが allow read, write: if true; になっていないか。
- 認可（IDOR）：ログインの有無だけでなく、「そのデータの持ち主か」までサーバー側で確認しているか。
- 管理機能の権限チェックがサーバー側にあるか。
- 価格・権限・ユーザーIDを、クライアントから送られた値のまま信用していないか。
[B. 一般的な脆弱性]
- SQL/NoSQLインジェクション、XSS（dangerouslySetInnerHTML / v-html / innerHTML）
- パスワードのハッシュ化、セッションの有効期限、Cookie の HttpOnly/Secure/SameSite
- CSRF、CORS（認証付きAPIで * を使っていないか）、エラー内容やスタックトレースの露出
- ファイルアップロードの制限、SSRF、オープンリダイレクト
[C. 運用・コスト]
- ログイン・登録・パスワードリセット・AI API・メール送信のレート制限
- 外部APIの利用上限・予算アラート（ユーザーにダッシュボードでの確認を依頼する）
- ログに個人情報や秘密情報を出力していないか
[D. AI機能がある場合]
- プロンプトインジェクション、AI出力をそのままHTML表示・実行していないか、ユーザーごとの利用上限
## Phase 5：動的スキャン（localhost）
- 承認を得て、開発用DBでアプリを起動する（本番DBには接続しない）。
- Dockerがあれば OWASP ZAP Baseline を実行する：
docker run --rm -v "$(pwd)/security-report:/zap/wrk:rw" -t ghcr.io/zaproxy/zaproxy:stable \
zap-baseline.py -t http://host.docker.internal:<PORT> -r zap-baseline.html
（Linuxでは --network host を付け、http://localhost:<PORT> を指定する）
- curl -sI でセキュリティヘッダー（CSP、X-Content-Type-Options、frame-ancestors、Referrer-Policy）を確認する。
- テスト用ユーザーを2つ作り、ユーザーAでユーザーBのデータを読み書きできないかを実際に試す。
## Phase 6：レポート作成
security-report/REPORT.md を次の構成で作成する。
- 概要（対象、実施日、実施者＋AIツール名、リスクレベル、準拠基準：OWASP ASVS L1・IPA「安全なウェブサイトの作り方」）
- 結論（3行）
- 🔴今すぐ直す／🟡公開前に直す／🟢余裕があれば（表：問題・起こりうる被害・場所・修正案・手間）
- 誤検知として除外したものと、その理由
- 実施したチェックの一覧（Phase・ツール・結果・ログファイル）
- ASVS L1 主要カテゴリとの対応表（認証、セッション、アクセス制御、入力検証、秘密情報、エラー処理とログ、データ保護、通信、設定、依存関係）
- ユーザー本人に確認してほしいこと
- このチェックの限界（リスク高なら、専門業者による診断を推奨する）
チャットでは、結論の3行と🔴の件数だけを伝える。
## Phase 7：修正（承認制）
- 🔴から1件ずつ「何を・なぜ・どう変えるか」を説明し、承認されたものだけを修正する（1件1コミット）。
- 修正後は該当チェックを再実行し、REPORT.md を「修正済み（再検査OK）」に更新する。
- キーが漏えいしていた場合は、各サービスでの再発行手順を案内する。
- 🟡以下は、修正するかどうかをユーザーに一覧で選んでもらう。
## Phase 8：継続チェック（任意）
- GitHub の Dependabot alerts / security updates、Secret scanning、Push protection の有効化手順を案内する。
- PRごとと週1回、gitleaks・semgrep・依存監査が走る GitHub Actions を提案する（Actionのバージョンは最新安定版を確認して固定する）。
- 次回以降は、前回のレポートを security-report/history/ に保存し、差分だけを報告する。レポートの読み方——見るべきは3か所だけ
AIが作るレポートは長くなりがちですが、初心者がまず見るべきなのは次の3か所です。
- 1. 結論（3行）：今の状態を一言で把握する
- 2. 🔴 今すぐ直す：ここが0件になるまでは公開しない（公開済みなら最優先で対応する）
- 3. ユーザー本人に確認してほしいこと：SupabaseやOpenAIのダッシュボードなど、AIからは見えない設定の確認
「誤検知として除外したもの」や「ASVS対応表」は、第三者に説明するときの根拠資料として使います。普段は細かく読まなくても構いません。
APIキーが漏れていた場合の対処
最も多く、最も慌てるのがこのケースです。コードからキーを削除しても、Git履歴や公開済みのファイルには残っています。必ず、各サービスのダッシュボードでキーを無効化し、新しいキーを発行してください。あわせて利用履歴を確認し、身に覚えのない利用がないかも確かめましょう。
「AIに任せきり」にしないための3つの注意点
1. 同じAIの自己レビューには限界がある
コードを書いたAIと同じセッションでレビューさせると、自分の書いたコードの前提を疑えないことがあります。可能であれば、新しいセッションを立ち上げるか、別のAIツールで指示書を実行してください。
2. スキャンは必ず自分の環境だけに
OWASP ZAPなどのスキャンは、許可のない第三者のサイトに実行すると、不正アクセスとみなされるおそれがあります。指示書ではlocalhostに限定していますが、AIが本番URLを対象にしようとした場合は止めてください。
3. 「修正」は1件ずつ承認する
AIに「全部直して」とまとめて頼むと、別の機能が壊れたり、新たな穴が生まれたりすることがあります。指示書どおり、1件1コミットで修正し、再検査で確認する流れを守りましょう。
セルフチェックで「十分」と言える範囲、言えない範囲
| アプリの性質 | このセルフチェックの位置づけ |
|---|---|
| ログインなし・表示のみ | このセルフチェックで概ね十分 |
| ログインあり・ユーザーデータを保存する | セルフチェック＋定期実行（Phase 8）を推奨 |
| 個人情報・決済・医療金融データを扱う | セルフチェックは前提。公開前に専門業者の脆弱性診断を推奨 |
セルフチェックは「やらないよりずっと良い」ものですが、万能ではありません。業務ロジック特有の欠陥や、複数の弱点を組み合わせた攻撃は、自動ツールとAIレビューでは見逃すことがあります。扱うデータの重さに応じて、外部の目を入れる判断をしてください。
よくある質問（Q&A）
Q1. コードが全く読めなくても実施できますか？
できます。指示書は、AIが平易な日本語で説明し、ユーザーは質問への回答と承認だけを行う前提で設計しています。分からない用語があれば、その場でAIに「初心者向けに説明して」と聞いてください。
Q2. 無料でできますか？
はい。Gitleaks、Semgrep、OSV-Scanner、OWASP ZAPはいずれも無料で使えます。費用がかかるのは、利用しているAIツールの料金のみです。
Q3. どのくらいの頻度で実施すべきですか？
最低限、公開前・大きな機能を追加したとき・月1回を目安にしてください。Phase 8でGitHub Actionsを設定すれば、日常的なチェックは自動化できます。
Q4. AIが「問題なし」と報告すれば安全ですか？
いいえ。「今回の手順の範囲では問題が見つからなかった」という意味です。レポートの「このチェックの限界」の項目も、必ず読んでください。
Q5. すでに公開しているアプリで🔴が見つかったら？
まず、APIキーの漏えいであれば即座に再発行し、データの公開範囲の問題（RLSの無効など）であれば最優先で修正します。そのうえで、ログや利用履歴から不正アクセスの痕跡がないかを確認してください。個人情報の漏えいが疑われる場合は、個人情報保護委員会への報告が必要になることがあります。
まとめ——「手順書」があれば、初心者でも説明できるセキュリティになる
- 1. チェック手順をAIへの指示書にする：知識がなくても、毎回同じ品質でチェックできる
- 2. AIには「調査と記録」までを任せ、修正は人間が承認する：任せきりによる事故を防ぐ
- 3. レポートとログを残す：第三者に「何をやったか」を根拠つきで説明できる
「動いた」はスタート地点にすぎません。1ファイルの指示書と1時間の作業で、自分のアプリを「説明できる安全さ」に近づけましょう。
より詳しいツールの使い方や、モバイルアプリ固有のチェックについては、「バイブコーディングで作ったWeb/モバイルアプリのセキュリティチェック実践ガイド」をご覧ください。AIを使った自社システム全体の自己診断については、「AIで自社システムの脆弱性を自己診断する実践ガイド」で解説しています。
免責事項：本記事は一般的な情報提供を目的としたものであり、アプリケーションの安全性を保証するものではありません。また、法的助言を構成するものでもありません。ツールの仕様やコマンドは変更される場合があるため、実施にあたっては各公式ドキュメントを確認してください。スキャンは必ず、自身が管理する環境、または許可を得た環境に対してのみ実施してください。
コメント