【2026年版】バイブコーディングで作ったWeb/モバイルアプリのセキュリティチェック実践ガイド——AIレビュー×自動ツール×手動テストの3層で穴を潰す

Claude CodeやCodexを使った「バイブコーディング」で、Webアプリやモバイルアプリを数日〜数週間で作れるようになりました。ところが、こうして作ったアプリは「動くこと」は確認されていても、「攻撃されたときにどうなるか」は誰も確認していないことがほとんどです。

筆者は長年ネットワーク運用・技術サポートの現場で、設定ひとつの見落としが大きなインシデントにつながる場面を見てきました。AIが書いたコードも同じです。見た目は整っていても、認可チェックの抜けやAPIキーの埋め込みといった「よくある穴」が残っていることは珍しくありません。

本記事では、バイブコーディングで作ったWeb/モバイルアプリを対象に、AIによるレビュー・従来型の自動ツール・自分の手による検証の3層でセキュリティチェックを行う実践手順を解説します。個人開発者や、社内ツールをAIで内製し始めた中小企業の担当者を想定しています。

目次
はじめに——なぜバイブコーディング製アプリは危ないのか
全体像——3層・5段階でチェックする
AI生成コード特有の「よくある穴」
1. 特に注意したい3つのポイント
第1層：AIによるセキュリティレビュー
第2層：従来型の自動ツール
1. まずはこの3コマンドから
Webアプリ固有のチェック
1. OWASP ZAPによる動的診断
2. Web特有の確認項目
モバイルアプリ固有のチェック
1. iOSアプリで最低限確認したいこと
2. MobSFによる診断
Supabase/Firebaseなど BaaS利用時の重点項目
第3層：手動での認可テスト
1. 2アカウント・テスト
実施手順のまとめ——この順番で潰す
AIだけでどこまで診断できるのか
1. 発展：AIを「診断のオーケストレーター」にする
セキュリティチェックリスト
よくある質問（Q&A）
まとめ
参考リンク

はじめに——なぜバイブコーディング製アプリは危ないのか
全体像——3層・5段階でチェックする
AI生成コード特有の「よくある穴」
第1層：AIによるセキュリティレビュー
第2層：従来型の自動ツール
Webアプリ固有のチェック
モバイルアプリ固有のチェック
Supabase/Firebaseなど BaaS利用時の重点項目
第3層：手動での認可テスト
実施手順のまとめ——この順番で潰す
AIだけでどこまで診断できるのか
セキュリティチェックリスト
よくある質問（Q&A）
まとめ
参考リンク

はじめに——なぜバイブコーディング製アプリは危ないのか

バイブコーディングでは、開発者は「こういう機能がほしい」と自然言語で伝え、AIがコードを書きます。開発者がチェックするのは主に画面が期待どおりに動くかどうかです。

しかし、セキュリティ上の問題の多くは画面には現れません。たとえば次のようなケースです。

画面上は自分のデータしか表示されないが、APIを直接呼べば他人のデータも取得できる
アプリは正常に動くが、バイナリの中にOpenAIやStripeの秘密キーがそのまま入っている
課金済みかどうかをアプリ側だけで判定しており、通信を書き換えれば有料機能が使える

これらは「動作テスト」では見つかりません。攻撃者の視点で、意図的に確認しにいく工程が必要です。

もう一つ重要なのは、AIが生成したコードを、同じAI・同じセッションにレビューさせるだけでは不十分という点です。書いた本人（AI）は自分の前提を疑いにくく、同じ見落としを繰り返す傾向があります。

全体像——3層・5段階でチェックする

本記事では、次の3層を組み合わせることを推奨します。

層	役割	得意なこと	苦手なこと
AIレビュー	コード全体の文脈を読んだ監査	認可漏れ・設計上の問題の指摘	誤検知、実行環境の設定ミス
従来型ツール	ルールベースの網羅的スキャン	秘密情報・既知の脆弱性・危険なパターン	ビジネスロジックの欠陥
手動検証	実際に動かして攻撃してみる	認可回避・課金回避などの実証	網羅性、手間

作業の流れとしては、次の5段階に分けると整理しやすくなります。

段階	チェック内容	主なツール
① コード解析	危険な実装、脆弱性	Claude Code、Codex、Semgrep、CodeQL
② 依存ライブラリ	既知の脆弱性、不審なパッケージ	OSV-Scanner、npm audit、Dependabot
③ 秘密情報	APIキー・認証情報の漏洩	Gitleaks、TruffleHog、GitHub Secret Scanning
④ 動的診断	実際のアプリへの攻撃テスト	OWASP ZAP、MobSF
⑤ 権限・設計検証	認証回避、データ漏洩、権限昇格	AIレビュー＋手動テスト（Burp Suite等）

①〜③は比較的簡単に自動化できます。一方、④と⑤は実際にアプリを動かして確認する必要があり、ここを省くと重大な穴が残りやすくなります。

AI生成コード特有の「よくある穴」

まずは、AIが書いたコードで特に多い問題を把握しておきましょう。チェックの優先順位を決める指針になります。

問題	具体例	危険度（目安）
認可の不備（IDOR）	`/api/orders/123` のIDを書き換えると他人のデータが見える	Critical
秘密情報の漏洩	APIキーをフロントエンドやアプリに直書き、`.env`をコミット	Critical
BaaSのルール設定ミス	SupabaseのRLS無効、Firebaseの `allow read, write: if true`	Critical
クライアント側だけの検証	課金状態や権限をアプリ側だけで判定	High
認証不備	ログインせずにAPIを呼び出せる	High
入力処理	SQL/NoSQLインジェクション、XSS、ファイルアップロードの無検証	High
設定の甘さ	CORS `*`、スタックトレースの露出、Webhook署名の未検証	Medium〜High
レート制限なし	APIを大量に呼ばれてAI APIの利用料が膨らむ	Medium〜High
ログ	個人情報やトークンをログに出力	Medium〜High
依存パッケージ	古いバージョン、AIが幻覚した存在しない名前のパッケージ	Medium〜High

※危険度は例示です。実際には影響範囲や悪用のしやすさによって変わります。

特に注意したい3つのポイント

1. 認可（Authorization）の欠如
AIは「ログイン機能」は書いても、「このリソースの持ち主はリクエストしたユーザーか」という所有者チェックを忘れやすい傾向があります。認証（あなたは誰か）と認可（それをしてよいか）は別物です。

2. クライアントに置いた秘密は「公開済み」
WebのJavaScriptはブラウザで誰でも読めますし、モバイルアプリもIPA/APKから文字列を抽出できます。クライアントに埋め込んだAPIキーは、公開したものと考えるべきです。

3. スロップスクワッティング（slopsquatting）
AIが「それっぽい名前」の存在しないパッケージを提案し、攻撃者がその名前で悪意あるパッケージを公開しておく手口です。見覚えのないパッケージが追加されていたら、公式リポジトリやダウンロード数を確認しましょう。

第1層：AIによるセキュリティレビュー

Claude Codeの /security-review を使う

Claude Codeには組み込みの /security-review コマンドがあり、セキュリティ上の懸念点を洗い出させ、そのまま修正まで依頼できます。

ただし、このコマンドは現在のブランチの未コミット・保留中の変更を主な対象とします。既存コード全体を監査したい場合は、次のように明示的に依頼する方が確実です。

全体監査のプロンプト例

あなたはWeb/モバイルアプリケーションのセキュリティ監査担当者です。

このプロジェクト全体を対象に、OWASP ASVS 5.0（Web）および
OWASP MASVS（モバイル）を参考にしたセキュリティレビューを実施してください。

特に以下を確認してください。
1. 認証・認可の不備（IDOR、他ユーザーのデータへのアクセス）
2. APIキー・秘密情報の漏洩
3. SQL/NoSQL Injection
4. XSS
5. CSRF
6. セッション・トークン管理
7. ファイルアップロード
8. 外部API呼び出しとWebhook署名検証
9. 課金・権限判定がサーバー側で行われているか
10. エラーメッセージによる情報漏洩

結果は以下の形式で出力してください。
- 深刻度（Critical/High/Medium/Low）
- 問題のあるファイルと行番号
- 脆弱性の説明
- 悪用された場合の影響
- 推奨修正方法
- 検証方法

コードは変更せず、まず監査レポートを作成してください。

ポイントは最初はコードを修正させず、問題点の洗い出しだけをさせることです。AIの指摘には誤検知も含まれるため、レポートを見て本当に脆弱性があるかを確認してから修正に進みます。

PRごとに自動化する

GitHubを使っているなら、Anthropic公式の GitHub Action anthropics/claude-code-security-review を導入すると、PRが作成されるたびに自動でセキュリティ観点の分析が行われます。誤検知が多い場合は、プロジェクト内の .claude/commands/security-review.md を編集してチェック内容をカスタマイズできます。

レビュー精度を上げる3つのコツ

書いたセッションとは別のセッションでレビューさせる：できれば別モデルを使います。Claude Codeで書いたコードをCodexに、Codexで書いたコードをClaude Codeにレビューさせるクロスレビューは効果的です。
攻撃者視点で依頼する：「あなたは攻撃者です。このAPIで他ユーザーのデータを取得する方法を探してください」と頼むと、認可漏れが見つかりやすくなります。
ツールの結果を渡して検証させる：後述のSemgrepやGitleaksの検出結果をAIに渡し、「本当に悪用可能か」「修正方法は何か」を判断させると効率的です。

なお、LLMベースのレビューはSASTツールや人間によるセキュリティレビューの代替ではありません。次の従来型ツールと必ず併用してください。

第2層：従来型の自動ツール

無料で揃うツールを中心に、目的別に整理します。

目的	ツール例	備考
シークレット検出	Gitleaks、TruffleHog	git履歴も含めてスキャンする
静的解析（SAST）	Semgrep、GitHub CodeQL	危険な実装パターンを検出
依存関係の脆弱性	OSV-Scanner、npm audit、Dependabot、Snyk	既知の脆弱性（CVE）を検出
動的スキャン（DAST）	OWASP ZAP	ステージング環境に対して実行
コンテナ・IaC	Trivy、Checkov	Dockerfileやクラウド設定の不備
モバイル	MobSF	IPA/APKの静的・動的解析

まずはこの3コマンドから

macOSであれば、Homebrewで導入してすぐに実行できます。

# 導入
brew install gitleaks semgrep osv-scanner

# 秘密情報の検出（git履歴も対象）
gitleaks git .

# 静的解析
semgrep scan --config auto .

# 依存ライブラリの脆弱性
osv-scanner -r .

Gitleaksで過去のコミットにキーが見つかった場合、ファイルを削除するだけでは不十分です。履歴に残っているため、該当キーは必ず無効化（ローテーション）してください。

これらのツールはGitHub Actionsに組み込んで、CIで毎回自動実行するのがおすすめです。一度きれいにしても、次のバイブコーディングで同じ穴が再発することはよくあります。

Webアプリ固有のチェック

Webアプリでは、OWASPが公開しているASVS（Application Security Verification Standard）5.0がチェック基準として参考になります。要件が体系的に整理されているため、AIへの監査依頼の基準としても使えます。

OWASP ZAPによる動的診断

ZAPは、実際に稼働しているWebアプリに対して脆弱性を調べるツールです。次のような問題を検査できます。

XSS、SQL Injection
セキュリティヘッダー（CSP、HSTSなど）の不足
Cookieの属性（Secure、HttpOnly、SameSite）の不備
一部の認証・セッション管理の問題

最初は通信を観察するだけの受動スキャンから始め、実際に攻撃リクエストを送る能動スキャンは自分が管理するテスト環境で実施してください。本番環境や他者のサービスに対して無断で攻撃テストを行うのは避けるべきです。

Web特有の確認項目

CORSが * になっていないか（特に認証付きAPI）
本番環境でデバッグモードやスタックトレースが表示されないか
dangerouslySetInnerHTML や v-html にユーザー入力を渡していないか
Stripe等のWebhookで署名検証をしているか
フロントエンドのビルド成果物（JSバンドル）に秘密キーが含まれていないか

モバイルアプリ固有のチェック

iOS/Androidアプリでは、OWASPのモバイル向け基準MASVSと、そのテストガイドMASTGをチェックリストとして使うのが定番です。

分野	確認事項
データ保存	機密情報を安全に保存しているか
暗号化	適切な暗号化方式を使っているか
認証	認証を回避できないか
通信	HTTPSや証明書検証が適切か
プラットフォーム	iOS/Androidの権限設定が最小限か
コード	危険な実装や脆弱なライブラリがないか
改ざん耐性	アプリの解析・改ざんへの対策
プライバシー	個人情報を適切に扱っているか

iOSアプリで最低限確認したいこと

ATS（App Transport Security）：Info.plistで NSAllowsArbitraryLoads などの例外を広く開けていないか
トークンの保存先：UserDefaultsではなくKeychainに保存しているか
ログ：print やログに個人情報・トークンを出力していないか
課金検証：StoreKitのトランザクション検証をサーバー側（App Store Server API）で行っているか
バイナリ内の文字列：ビルド済みバイナリに strings コマンドをかけて、APIキーが出てこないか

# ビルド済みアプリから怪しい文字列を探す例
strings YourApp.app/YourApp | grep -iE "sk-|api[_-]?key|secret|token"

MobSFによる診断

MobSF（Mobile Security Framework）はオープンソースのモバイルアプリ診断ツールで、IPAやAPKをアップロードするだけで静的解析・設定確認・秘密情報の検出などを行えます。ただし、iOSの動的解析は実行環境に制約がある点に注意してください。

FlutterやReact Nativeなどのクロスプラットフォームアプリの場合は、共通コードのレビューに加えて、iOS/Androidそれぞれのネイティブ設定（Info.plist、AndroidManifest.xmlなど）も確認が必要です。

Supabase/Firebaseなど BaaS利用時の重点項目

バイブコーディングでは、SupabaseやFirebaseをバックエンドに使うケースが非常に多くあります。この構成では、アプリの画面でアクセスを制限していても、APIを直接呼ばれれば意味がないという点を強く意識する必要があります。

① データベースのアクセス制御（RLS / Security Rules）

すべての必要なテーブルでRLS（Row Level Security）が有効か
他ユーザーのデータを読み取れないか、更新・削除できないか
匿名ユーザー（anon）に過剰な権限がないか
Firebaseのルールが if true のまま本番化されていないか

Supabaseのanonキーはクライアントに置く前提の公開キーで、安全性はRLSに依存します。一方、service_roleキーはRLSを無視できる管理者キーなので、絶対にクライアントに含めてはいけません。

② サーバー側の関数（Edge Functions / Cloud Functions）

リクエストごとに認証・認可しているか
入力データをサーバー側で検証しているか
レート制限があるか

③ アプリ内課金

購入結果をサーバー側で検証しているか
同じ購入を繰り返し利用できないか
無料利用回数をクライアント側の改ざんで増やせないか

④ AI APIを呼び出す機能

APIキーをアプリ内に保持せず、サーバー経由で呼び出しているか
想定外のモデルや処理をパラメータ書き換えで呼び出せないか
リクエストサイズや回数に上限があるか
悪意ある利用でAPI料金を膨らませられないか

第3層：手動での認可テスト

ここが最も効果が高い工程です。ツールやAIが見逃しやすい認可の穴は、実際に試すとあっさり見つかります。

2アカウント・テスト

テスト用にユーザーAとユーザーBの2アカウントを作成する
Burp Suite（Community版で十分）やProxymanでアプリの通信をインターセプトする
ユーザーAでログインし、データ取得・更新のリクエストを記録する
リクエスト内のIDをユーザーBのものに書き換えて送信する
Bのデータが返ってきたり、更新できたりしたら重大な認可漏れ

同様に、role や is_premium、price といったパラメータを書き換えてみるのも有効です。この2アカウント・テストだけでも、バイブコーディング由来の重大な穴の多くは見つかります。

実施手順のまとめ——この順番で潰す

個人開発であれば、最初から高価な診断サービスを使う必要はありません。重大度の高いもの（秘密情報・認可・課金）から順に潰していくのが効率的です。

Step	作業	使うもの
1	シークレットスキャン（漏れていたら即ローテーション）	Gitleaks、TruffleHog
2	依存関係スキャン	OSV-Scanner、npm audit
3	BaaSルール・認可の確認	RLS/Security Rulesの目視、AIレビュー
4	AIによる全体監査（別セッション・別モデル）	Claude Code、Codex
5	静的解析	Semgrep、CodeQL
6	動的診断	OWASP ZAP、MobSF
7	手動での認可テスト	Burp Suite、Proxyman
8	修正後の再診断とCIへの組み込み	GitHub Actions

最後にCIへGitleaks・Semgrep・Claude Codeのセキュリティレビューを組み込んでおけば、以後の変更で同じ穴が再発するのを防げます。

AIだけでどこまで診断できるのか

Claude CodeやCodexは、ソースコードを読んで脆弱性を見つけたり、テストコードを書いたりできます。しかし、コードレビューだけでは次のような問題を見落とす可能性があります。

実行環境やクラウド側のセキュリティ設定ミス
実際のAPIアクセス権限（BaaSのルールがコード外で管理されている場合など）
複雑なビジネスロジックの欠陥
実際に攻撃してみないと分からない問題

したがって、AIレビュー＋静的解析＋動的診断＋権限テストの組み合わせが有効です。

発展：AIを「診断のオーケストレーター」にする

さらに一歩進めて、AIエージェントにSemgrep・Gitleaks・OSV-Scanner・ZAPなどの実行と結果の統合を任せ、診断レポートまで自動生成させる構成も考えられます。

Claude Code / Codex
   ├── ソースコード解析
   ├── Semgrep 実行
   ├── Gitleaks 実行
   ├── 依存ライブラリ診断
   ├── ZAP / MobSF 実行
   ├── 検出結果の統合・重複排除
   └── セキュリティ診断レポート生成

ただし、ツールの実行権限は最小限に制限し、動的診断の対象やコード修正は人間が事前に承認する設計にしてください。AIエージェントが誤って本番環境に能動スキャンをかける、といった事故を防ぐためです。

セキュリティチェックリスト

カテゴリ	チェック項目	確認方法
秘密情報	クライアント・git履歴にAPIキーがない	Gitleaks、strings
秘密情報	漏洩したキーをローテーション済み	各サービスの管理画面
認可	他ユーザーのデータを読めない・書けない	2アカウント・テスト
認可	RLS/Security Rulesが全テーブルで有効	管理画面、AIレビュー
課金	購入検証をサーバー側で実施	コードレビュー、通信改ざんテスト
入力	インジェクション・XSS対策がある	Semgrep、ZAP
設定	CORS・エラー表示・セキュリティヘッダーが適切	ZAP
設定	レート制限がある	手動テスト
依存関係	既知の脆弱性・不審なパッケージがない	OSV-Scanner、Dependabot
モバイル	トークンをKeychainに保存、ATS例外なし	MobSF、コードレビュー
ログ	個人情報・トークンを出力していない	コードレビュー
運用	CIでスキャンを自動実行	GitHub Actions

よくある質問（Q&A）

Q1. 個人開発の小さなアプリでもセキュリティチェックは必要ですか？

必要です。攻撃者はアプリの規模ではなく、自動スキャンで「穴が開いているもの」を探します。特にAI APIのキーが漏れると、短時間で高額な利用料を請求されるケースがあります。最低限、シークレットスキャンと2アカウント・テストは実施してください。

Q2. /security-review を実行すれば十分ですか？

十分ではありません。主に変更差分を対象とするため、既存コード全体の監査は別途依頼が必要です。また、LLMによるレビューは誤検知・見落としの両方があるため、SemgrepやGitleaksなどの従来型ツールと手動テストを併用してください。

Q3. コードを書いたAIにそのままレビューさせてもいいですか？

やらないよりは良いですが、効果は限定的です。同じセッションでは同じ前提を引きずりやすいため、新しいセッション、できれば別のモデルにレビューさせるのがおすすめです。

Q4. SupabaseのanonキーがJSに入っているのは問題ですか？

anonキー自体はクライアントで使う前提の公開キーです。問題になるのはRLSが無効・不十分な場合です。一方、service_roleキーがクライアントに含まれている場合は重大な問題なので、すぐにキーを再発行してください。

Q5. 外部の脆弱性診断はいつ検討すべきですか？

個人情報や決済を扱うアプリ、企業の業務データを扱うアプリで本格的な保証が必要な場合は、リリース前やユーザー数が増えたタイミングで一度、第三者による専門的な診断を入れることを検討する価値があります。

まとめ

1. 「動く」と「安全」は別物
バイブコーディング製アプリは、画面に現れない認可漏れや秘密情報の埋め込みが残りやすい。攻撃者視点で確認する工程が欠かせません。

2. AIレビュー・自動ツール・手動テストの3層で見る
AIは別セッション・別モデルで攻撃者視点のレビューを。Gitleaks・Semgrep・OSV-Scannerで網羅的にスキャンし、2アカウント・テストで認可を実証します。

3. 重大なものから潰し、CIで再発を防ぐ
秘密情報・認可・課金の順に対処し、修正後はCIにスキャンを組み込んで、次のバイブコーディングで同じ穴を作らない仕組みにしましょう。

AIのおかげでアプリを作るスピードは劇的に上がりました。だからこそ、「作ったら確かめる」工程もAIとツールで仕組み化することが、これからの開発者に求められる基本動作になります。

参考リンク

関連記事：【2026年版】AIで自社システムの脆弱性を自己診断する実践ガイド

※本記事は2026年10月時点の情報に基づいています。各ツールの仕様・コマンドは変更される場合があるため、最新の公式ドキュメントをご確認ください。また、脆弱性診断は必ず自身が管理する環境、または許可を得た環境に対してのみ実施してください。