はじめに — 「バイブコーディング」のセキュリティ問題
2026年、AIとの対話だけでアプリを作る「バイブコーディング」が急速に広がっています。AIコーディングツールに指示を出すだけで、動くWebアプリができてしまう。素晴らしい時代です。
しかし、動くことと安全であることは別の話です。
AIが生成したコードには、セキュリティ上の問題が潜んでいることがあります。Supabaseのanon keyがフロントエンドに露出していたり、ソースマップが本番で公開されていたり、セキュリティヘッダーが一切設定されていなかったり。さらに深刻なケースでは、データベースのRow Level Security（RLS）が正しく設定されておらず、誰でもデータにアクセスできる状態のまま公開されていることもあります。
バイブコーダーの多くは非エンジニアで、「動いたからOK」と思ってデプロイしてしまう。セキュリティの知識がないのは非難すべきことではありません。むしろ、ツール側がその知識をカバーすべきです。
ZERONOVA LABでは93個の無料ツールを公開してきましたが、OGPチェッカーやSEO監査ツールといった「品質向上系」が中心で、「バイブコーディング×セキュリティ」という領域にはまだツールがありませんでした。2026年2月28日、Vibe Auditの企画から実装・公開までを1日で完了させました。
この記事では、なぜこのツールを作り、どんな設計判断をし、何を学んだかを開発日記から振り返ります。
着想 — 競合分析から見えた空白地帯
Vibe Auditの企画にあたって、まず市場調査をしました。バイブコーディング向けのセキュリティツールとして知られているサービスがすでに存在していました。
Vibe Audit（バイブコーディング向けセキュリティ診断）を企画から実装・公開まで1日で完了した。「バイブコーディング」という2026年に急成長しているトレンドに対して、セキュリティ診断ツールを早期にポジション取りする判断。
2月28日の開発日記にこう書きました。バイブコーディング向けのセキュリティツールという市場は、まだ黎明期です。2026年に入ってから急速に需要が高まっていますが、ツールの数は限られています。
市場調査で分かったのは、既存のツールには3つの限界があることでした。
1つ目は、外部スキャンのみという点。URLを入力してHTML/JSを解析するだけで、ローカルコードの監査機能がない。ソースコードに埋め込まれた秘密情報やRLS（Row Level Security）の設定ミスは、外部からは見えません。バイブコーダーが最も犯しやすいミスは、Supabaseのanon keyをフロントエンドに露出させたまま公開することです。これは外部スキャンで検出できますが、service_roleキーのハードコードは見えません。
2つ目は、修正方法の不足。「漏れてます」と指摘するだけで、「どう直すか」の具体的なコード修正は提供しない。非エンジニアのバイブコーダーにとって、指摘だけでは何も改善できません。「セキュリティヘッダーが不足しています」と言われても、何をどこに書けばいいのか分からない。
3つ目は、Supabase特化という制約。Firebase、Neon、他のBaaSには対応していない。バイブコーダーはSupabaseだけを使っているわけではありません。
PM-AI 対話: 差別化の方向性
Zeronova.envの管理、RLS設定、APIルートの認証チェックをコードベースから直接分析します。Phase 2はAIエージェント前提なので、修正方法をClaude Codeにコピペするだけで改善できます。Zeronovaこの「外部スキャン × 内部監査 × 改善ガイドの三位一体」が、Vibe Auditの設計思想になりました。単なるスキャナーではなく、「問題の発見から修正まで一気通貫でサポートする」ツール。バイブコーダーがセキュリティの専門知識なしに、安全なコードを公開できる世界を目指す設計です。
Phase 1: 外部スキャンツールを1日で作る
Phase 1の外部スキャンツールは、URLを入力するとWebサイトのセキュリティを8カテゴリで診断するツールです。
検出対象:
- Supabase URL + anon key の露出
- Firebase設定の露出
- ソースマップの公開
- APIキー（OpenAI / Stripe / AWS / Google Maps）の露出
- セキュリティヘッダー（6種）の欠落
- CORSの設定ミス
- HTTPSリダイレクトの不備
スコアリング: 100点満点からの減点方式。Critical（-20点）、High（-10点）、Medium（-5点）、Low（-2点）。
アーキテクチャは既存の93個のツールと同じパターン、つまりServer Component（SEO用テキスト）+ Client Component（フォーム操作）+ API Route（サーバーサイド処理）です。ただし、外部URLにアクセスしてHTML/JSを解析する処理が入るため、OGPチェッカーやリンク切れチェッカーと同じ「外部フェッチ型」の実装が必要でした。
なぜ1日で完成できたのか
「セキュリティ診断ツールを1日で？」と思うかもしれません。ゼロから作ったわけではないからです。93個のツールを作ってきた中で、外部フェッチ型のアーキテクチャパターン、フォームUI、結果表示コンポーネント、API Routeの雛形が蓄積されていました。Vibe Auditはこれらの資産の上に、セキュリティ特有のスキャンロジックを乗せた形です。
とはいえ、実装して終わりではありませんでした。
実装後のレビューサイクルが手厚くなった。バグ修正5件→UX最適化12項目→SEO強化10項目→ガイドライン準拠チェック2件。
2月28日の開発日記の記述です。バグ修正5件には、Supabaseのservice_roleキーの誤検出パターンの修正や、POSTレスポンスのキャッシュ制御が含まれます。特にキャッシュ制御は重要で、セキュリティスキャン結果がブラウザにキャッシュされると、前回のスキャン結果が表示され続ける問題がありました。
UX最適化12項目は、スキャン中のプログレスバー、結果セクションのトグルアニメーション、修正方法のコピーボタン、検出項目ごとの深刻度バッジなどを含みます。SEO強化10項目では、FAQ構造化データの追加やmeta descriptionの最適化を行いました。
これは93個目のツール。3ヶ月前に最初のツール（OGP画像ジェネレーター）を作ったときは、実装後のレビューなんてほぼやっていませんでした。ツール数が増えるごとに、品質保証のプロセスが自然に進化していることを実感します。
倫理設計 — 「データを取得しない」という判断
Vibe Auditの設計で最も重要だった判断は、ユーザーデータを取得しないことでした。
既存ツールはテーブルのサンプルデータを取得するが、Vibe Audit はアクセス可能性の確認のみ。第三者のサイトに悪用されたときのリスクを考えると、データ取得しない方針が正しいと判断した。
2月28日の開発日記の記述です。既存ツールはSupabaseテーブルのサンプルデータ（最大3行）を実際に取得して「丸見えです」と表示します。インパクトは絶大ですが、第三者のサイトに対して使われた場合、データ漏洩のリスクを伴います。
Vibe Auditは意図的に「アクセスできるかどうか」の確認のみに留めています。データの中身は見ません。
| 原則 | 具体的な実装 |
|---|---|
| 自己診断専用 | 「自身が管理するサイトに対してのみ実行してください」をUIに明記 |
| 秘密情報のマスク | APIキーは先頭4文字 + 末尾4文字のみ表示 |
| データ不保持 | スキャン結果はサーバーに保存しない |
| 攻撃手法の非開示 | 「どう検出したか」の技術詳細は非公開、修正方法のみ提供 |
| 読み取り専用 | INSERT / UPDATE / DELETE は実行しない |
| レート制限 | 5スキャン/分/IPで大量スキャンを防止 |
| 同意確認 | スキャン前に利用規約への同意チェックボックスを必須化 |
この倫理設計は、ツールとしての機能を多少制限します。「データの中身を見せた方がインパクトがある」のは事実です。しかし、セキュリティツールが悪用される可能性を考えると、安全側に倒す判断が正しいと確信しています。
Phase 2: MCP Serverへの統合 — ローカルコード監査
Phase 1（外部スキャン）の公開翌日、2026年3月1日にPhase 2（ローカルコード監査）をMCP Serverに統合しました。ZERONOVA LAB MCP Server v0.6.0 としてnpm公開です。
なぜMCP Serverなのか
外部スキャンだけでは、コードベースに埋め込まれた問題は検出できません。.envファイルが.gitignoreに含まれているか、Supabaseのservice_roleキーがコード内にハードコードされていないか、APIルートに認証チェックがあるか。これらはソースコードを直接分析しなければ分かりません。
MCP Serverならユーザーのローカルマシン上で実行されるため、コードベースのファイルに直接アクセスできます。しかも結果はAIエージェント（Claude Code等）に返されるので、「問題を検出 → 修正コードを生成 → 適用」までをAIが一気通貫で実行できます。
5つのTier 1ツール
MCP Serverに追加した5つの内部監査ツール:
check_env_exposure—.envファイルの管理状態を確認。.gitignoreの設定漏れ、コミットされた秘密情報を検出check_rls_config— SupabaseのRLS設定をSQLマイグレーションから分析。USING(true)のようなアンチパターンを検出check_api_auth— Next.js App Router / Pages RouterのAPIルート認証を分析。20以上の認証パターンを認識check_client_secrets— クライアントサイドコードに埋め込まれた秘密情報を検出。NEXT_PUBLIC_環境変数の誤用も対象check_injection_risk— SQLインジェクション、XSS、コマンドインジェクションのリスクパターンを検出
これら5つのツールを統合するrun_vibe_auditワークフローで、1コマンドで100点満点のセキュリティスコアを算出します。MCP Serverの「Workflow as a Tool」パターンの応用です。
PM-AI 対話: file-scannerのセキュリティ設計
Zeronova../攻撃）やシンボリックリンクを経由した意図しないファイル読み取りが怖い。MCP Serverはユーザーのマシンで動くから、セキュリティは万全にしたい。../を含むパスをブロック）、シンボリックリンクのブロック、1MBのファイルサイズ制限、100ファイルのスキャン上限を設けています。これらの制限はすべての内部監査ツールに適用されます。ZeronovaGitHub Push Protectionとの格闘
Phase 2の開発で最も苦労したのは、予想外の場所でした。
npm 公開の過程で GitHub Push Protection に苦労した。テストファイルに Stripe API キーのダミーパターン（
sk_test_*）を含んでいるため、公開リポにプッシュしようとするとブロックされる。
3月1日の開発日記です。セキュリティ診断ツールのテストには、「この文字列がStripeのAPIキーとして検出されるか」を確認するテストケースが必要です。当然、テストファイルにはダミーのAPIキーパターンが含まれます。
ところがGitHubのPush Protectionは、テストファイル内のダミーパターンも「秘密情報の漏洩」として検出し、pushをブロックしました。String.fromCharCodeで動的に構築しても検出されました。
セキュリティツールを作っているのに、テスト用のダミー秘密情報がセキュリティに引っかかるという皮肉。
最終的には、テストフォルダを.gitignoreに追加し、「ローカルでテスト実行 → npm publish」というワークフローに落ち着きました。テストコードはnpmパッケージには含まれず、GitHubリポジトリにもpushされません。正直、疲れました。でもこの皮肉な体験こそが、「セキュリティツール開発のリアル」です。
「バイブコーダー」の定義とターゲティング
Vibe Auditの設計で考慮すべきだったのは、「バイブコーダー」というターゲットの特性です。
バイブコーダーの多くは、プログラミングを本業としない人たちです。デザイナー、マーケター、起業家など、AIの力を借りてアイデアをプロトタイプに変える人たちです。セキュリティの知識はほとんどない場合が多い。
これはツールの設計に大きく影響します。「CSPヘッダーが未設定です」と報告しても、何のことか分からない。「XSS脆弱性が検出されました」と言われても、それが何を意味するのか理解できない。
そこで、すべての検出項目に3つの情報を付与しました。何が問題か（平易な日本語での説明）、なぜ危険か（悪用シナリオの具体例）、どう直すか（コピペ可能な修正コード）。特に「どう直すか」は、バイブコーダーがClaude Codeに「この修正を適用して」と指示するだけで改善できる粒度で記述しています。
セキュリティツールは「怖がらせるツール」ではなく「直せるツール」であるべきだ。これがVibe Auditの設計哲学です。
テスト戦略 — 281テストの構築
Phase 2のMCP Server統合では、テストの設計に特に力を入れました。
82テストを追加。累計281テストに。file-scannerのセキュリティテスト、各Tier 1ツールのユニットテスト、Tier 2統合テストを含む。
3月1日の開発日記です。セキュリティツールのテストは、通常のツールより慎重さが求められます。「検出すべきものを正しく検出し、検出すべきでないものを検出しない」。この両方を担保しなければなりません。
テストは3層で構成しました。第1層はfile-scannerのセキュリティテスト（パストラバーサル防止、シンボリックリンクのブロック、ファイルサイズ制限）。第2層は各Tier 1ツールのユニットテスト（check_env_exposureが.gitignoreの不備を正しく検出するか等）。第3層はrun_vibe_auditの統合テスト（5つのツールが正しく連携してスコアを算出するか）。
この3層構造が、後のGitHub Push Protection問題でテストフォルダを.gitignoreに追加する際にも役立ちました。テストの信頼性が確保されていたからこそ、「ローカルでテスト → npm publish」のワークフローに安心して移行できたのです。
Vibe Auditで自分のサイトを診断した結果
Phase 2の公開後、最初にやったのは自分のプロジェクトへのrun_vibe_auditの実行でした。いわゆるドッグフーディングです。結果は0/100点。
正直、驚きました。自分が作ったツールに、自分のプロジェクトが「最も危険」と判定されたのですから。
これについては「偽陽性との向き合い方 — セキュリティ診断ツールの精度設計」に詳しく書きましたが、大半が偽陽性でした。公開APIルートの「認証なし」検出、JSON-LD用のdangerouslySetInnerHTMLのXSSリスク検出など、コンテキストを加味すれば問題ないものばかりです。
ただし、ルート.gitignoreに.envパターンが未設定という本物の問題も1件見つかりました。「0点だけど価値はあった」という体験です。この体験は、セキュリティツールの偽陽性をどう扱うかという設計思想を根本から考え直すきっかけになりました。
学び — バイブコーディング時代のセキュリティツール設計
1. 「外部×内部」の二段構えが差別化になる
外部スキャンだけ、内部監査だけ、では不十分です。Vibe Auditが提供する価値は、ブラウザで簡単に外部チェック → MCP Serverで深いコード監査、という段階的なアプローチにあります。
2. 倫理設計がツールの信頼性を決める
セキュリティツールは悪用されるリスクと常に隣り合わせです。「データを取得しない」「攻撃手法を開示しない」「レート制限を設ける」という制約は、ツールの機能を制限しますが、長期的な信頼性を担保します。
3. AIエージェント前提の設計が「修正」まで到達させる
MCP Serverで結果をAIエージェントに返すことで、「問題の検出」だけでなく「修正コードの生成と適用」まで到達できます。非エンジニアのバイブコーダーにとって、これは「指摘されるだけ」と「直してもらえる」の決定的な差です。
4. セキュリティツールのテストはセキュリティに引っかかる
これは完全に予想外でした。ダミーの秘密情報パターンをテストに含めると、GitHub Push Protectionに阻まれます。テストコードの管理戦略は、セキュリティツール開発の初日から考慮すべきです。
5. 93個のツール資産があったからこそ
1日で完成できた理由は「急いだ」からではありません。93個のツールで培ったアーキテクチャパターン、UIコンポーネントの再利用、API Routeの雛形。これらの蓄積があったからこそ、セキュリティ固有のロジックに集中できました。資産の蓄積が開発速度を指数関数的に加速させるという実感があります。
Vibe Auditは「バイブコーディング×セキュリティ」という、2026年に最も需要が高まるであろう領域への早期ポジション取りです。外部スキャンとMCP Serverによる内部監査の組み合わせで、バイブコーダーが安全にプロダクトを公開できる世界を目指します。
企画から公開まで1日、MCP Server統合まで2日。この速度で動けたのは、93個のツールで蓄積したアーキテクチャパターンと、Claude Codeとの協業で確立した「方針決定 → 即実装 → レビューサイクル」のワークフローがあったからです。速さは「急いだ」のではなく「蓄積があった」結果です。
関連記事:
Zeronova（ゼロノバ）
Product Manager / AI-Native Builder
Web/IT業界19年以上・20以上のWebサービスを担当したPdM。東証プライム上場企業の子会社代表として事業経営を経験。現在はAIを駆使して企画から実装まで完結させる個人開発を実践中。