「雰囲気で指示するだけでコードが量産できる」vibecoding（バイブコーディング） は、短期の生産性を大きく上げる一方で、AIのデフォルトの出力がセキュリティを前提にしていないことが問題になっています。平文パスワード保存や未検証の入力のままの表示など、そのまま本番に載せると危険なパターンが含まれがちです。
この記事では、vibecodingをする際に「セキュアなプロンプト」で脆弱性を減らす具体的な手法を、IT技術者がそのまま試せる形でまとめます。OWASP Top 10やMITREの考え方をプロンプトに組み込み、入力検証・秘密管理・認証を強制する設計と、コピーして使えるプロンプト例を中心に説明します。vibecodingのリスクや技術的負債については、「10倍速」の代償——vibecodingが積み上げる技術的負債を、IT技術者の自分事として整理するで整理しているので、あわせて読むと全体像がつかめます。
なぜ「プロンプトの設計」でセキュリティが変わるのか
AIは指示が曖昧だと、動くが危ないコードを平気で出力します。Kasperskyの検証では、セキュリティを明示したプロンプトを使った場合に脆弱性が約70%減少したという結果が報告されています（The Hacker News: Secure vibe coding）。「何を書くか」だけでなく、「どういう前提で書かせるか」 をプロンプトで指定することが、そのままセキュリティの差になります。
その土台になるのが、プロンプトを層に分けて設計する考え方です。
基本原則：3層で積み上げる「レイヤード・プロンプト」
セキュアなvibecodingの基盤は、Context（文脈）・Task（タスク）・Review（レビュー） の3層でプロンプトを組むことです。Supabaseのベストプラクティスでも、この構造が推奨されています（Supabase: Vibe coding best practices）。
Context Layer（文脈層）——最初に「前提」を決める
最初のブロックで、OWASP Top 10や言語ごとのセキュリティルールを明示します。「この前提の下でコードを書く」とAIに伝えることで、平文パスワード保存や未サニタイズ表示といったデフォルト不安全な出力を抑えられます。
例として、次のように書けます。
「このコードは本番環境を想定する。OWASP Top 10（インジェクション、XSS、認証の不備、機密データの露出など）に配慮し、入力は検証・サニタイズすること。秘密情報はハードコードせず、環境変数またはシークレット管理を使用すること。」
ここで用語を具体的に出す（OWASP、XSS、サニタイズなど）ことが重要で、曖昧な「安全に」だけでは効果が薄れます。
Task Layer（タスク層）——やりたいことを書く
そのうえで、実装したい機能や仕様を指示します。「ユーザー入力を表示するフォーム」「APIキーで外部サービスを呼ぶ処理」など、いつものvibecodingの指示をこの層に書きます。文脈層でセキュリティの前提が入っているので、タスク層の指示だけでも、ある程度セキュアな方向に生成されやすくなります。
Review Layer（レビュー層）——生成後に自分で点検させる
コード生成後、「セキュリティ観点で自己レビューせよ」と命じる層です。「生成したコードについて、OWASP Top 10の観点で脆弱性を洗い出し、問題があれば修正版を出せ」のように、見直しと修正までプロンプトに含めます。これにより、1回の生成で完結させず、生成→レビュー→修正のループをプロンプト設計に組み込めます。
この3層を意識するだけでも、「雰囲気で書かせて後で泣く」事態をかなり減らせます。以下では、文脈層やレビュー層にそのまま貼れる、具体的なセキュア・プロンプトを分野別に紹介します。
手法1：入力検証・サニタイズを強制するプロンプト
不正入力をブロックし、XSS（クロスサイトスクリプティング）やSQLインジェクションを防ぐには、「すべてのユーザー入力を検証し、必要な場合以外は拒否する」ことをプロンプトで明示します。
LinkedInで紹介されている実務向けの例（Esila Dzekpo: 5 Secure Vibe Coding Prompts）をベースに、次のような英文プロンプトをContext Layerに置けます。
Validate and sanitize all user inputs. Reject scripts, HTML, SQL, and special characters unless explicitly required. Encode user-generated content before rendering. Use libraries like DOMPurify for JS or bleach for Python.
意味するところを日本語で整理すると次のとおりです。
-
Validate and sanitize all user inputs.
すべてのユーザー入力を検証し、サニタイズする。型・長さ・形式をチェックし、危険な文字列は除去またはエスケープする。 -
Reject scripts, HTML, SQL, and special characters unless explicitly required.
スクリプト、HTMLタグ、SQL断片、不要な特殊文字は、仕様で明示的に許可している場合以外は拒否する。 -
Encode user-generated content before rendering.
ユーザーが入力した内容を画面に出す前にエンコードする（HTMLエスケープなど）。これで意図しないスクリプト実行を防ぐ。 -
Use libraries like DOMPurify for JS or bleach for Python.
言語に応じた既存ライブラリを使う。JavaScriptならDOMPurify、Pythonならbleachのように、実績のあるサニタイズ庫を指定することで、手書きの正規表現ミスを減らせる。
この一文をプロンプトの冒頭に置いておくだけで、フォーム処理や検索窓、ユーザーコメント表示といった箇所で、悪意ある入力を無効化しやすくなります（同上LinkedIn）。
手法2：秘密・認証情報のハードコードを禁止するプロンプト
APIキーやトークンをソースに直書きすると、GitHubへのコミットやログ経由で漏洩します。「秘密はコードに書かず、環境変数やシークレット管理を使う」 ことをプロンプトで強制します。
Cloud Security Allianceのセキュアvibecodingガイド（CSA: Secure vibe coding guide）やLinkedInの実例（同上）を踏まえた、コピー可能なプロンプトは以下です。
Never hardcode API keys, secrets, tokens, or credentials. Use environment variables (e.g., process.env.API_KEY). Ensure secrets are not logged, displayed, or stored in frontend. Implement bcrypt for passwords with 12+ rounds.
各句の意図は次のとおりです。
-
Never hardcode API keys, secrets, tokens, or credentials.
APIキー、秘密情報、トークン、認証情報をソースコードに直書きしない。 -
Use environment variables (e.g., process.env.API_KEY).
実行環境の環境変数（Nodeならprocess.env.API_KEYなど）から読み込む。本番ではVaultやクラウドのシークレット管理と組み合わせる想定。 -
Ensure secrets are not logged, displayed, or stored in frontend.
秘密情報をログに出力しない、画面に表示しない、フロントエンドやCookie・localStorageに保存しない。 -
Implement bcrypt for passwords with 12+ rounds.
パスワードはbcryptなどでハッシュ化し、コスト係数（ラウンド数）は12以上にする。平文保存を禁止することを明示しています。
この指示を入れておくことで、GitHubへのキーコミットや、トークンがログ・フロントに流れる事態を防ぎやすくなります。
手法3：サーバーサイド認証と最小権限を強制するプロンプト
権限チェックをクライアント任せにすると、UIの改ざんやリクエストの捏造で特権昇格が起きます。認可と重要なビジネスロジックはサーバーで行い、クライアントには依存しないことをプロンプトで指定します。
Infisicalのvibecodingセキュリティプレイブック（Infisical: Vibe coding security playbook）やLinkedInの例（同上）を参考にしたプロンプトは以下です。
All authorization, role checks, and sensitive business logic must be enforced server-side. Do not rely on client-side validation. Implement least-privilege access: deny by default unless explicitly allowed. Use JWT with secure signing.
要点は次のとおりです。
-
All authorization, role checks, and sensitive business logic must be enforced server-side.
認可（誰が何をしてよいか）、ロールチェック、機密にかかわるビジネスロジックは、すべてサーバー側で実行する。 -
Do not rely on client-side validation.
クライアント側のチェックは利便性やUX用とし、セキュリティの根拠にはしない。 -
Implement least-privilege access: deny by default unless explicitly allowed.
最小権限の原則。デフォルトは拒否し、明示的に許可された場合だけ許可する。 -
Use JWT with secure signing.
認証にJWTを使う場合は、改ざん検知のため署名を必ず使い、アルゴリズムと秘密鍵の管理を適切に行う。
これにより、UI改ざんや不正リクエストによる不正アクセスをサーバー側でブロックする設計を、AIに一貫して出させやすくなります。
手法4：ログ・エラー処理をセキュアにするプロンプト
ログやエラーメッセージに秘密やスタックトレースを出すと、情報漏洩や攻撃の手がかりになります。本番ではログを安全にし、ユーザー向けメッセージは汎用的にすることをプロンプトで指定します。
Cloud Security Allianceのガイド（同上CSA）やLinkedInの例（同上）を踏まえたプロンプトは以下です。
Log errors securely without including secrets, tokens, user inputs, or stack traces in production. Use generic error messages for users (e.g., "Invalid input"). Include audit logs for auth failures.
意味の整理です。
-
Log errors securely without including secrets, tokens, user inputs, or stack traces in production.
本番のログには、秘密・トークン・生のユーザー入力・スタックトレースを含めない。内部用の詳細は別チャネルや権限限定で扱う。 -
Use generic error messages for users (e.g., "Invalid input").
ユーザー向けには「入力が不正です」のように汎用的なメッセージにし、内部構造やパスを推測させない。 -
Include audit logs for auth failures.
認証失敗（ログイン失敗、権限不足など）は監査ログに残す。攻撃検知や事後分析に使えるようにする。
この指示で、攻撃検知を可能にしつつ、内部情報の露出を抑えるバランスを、生成コードに反映させやすくなります。
手法5：Multi-Step（多段階）プロンプティング——生成のあとにレビューを回す
一度のプロンプトで「完璧なコード」を出させるより、生成→セキュリティレビュー→修正の流れをプロンプトで組み込む手法です。Dev.toの実践記事（Devin Rosario: How to secure vibe-coded applications in 2026）では、この多段階プロンプティングでクリティカルな脆弱性が約69%減少した（Tenzaiの検証）と紹介されています。
ステップ1（生成）
上記の手法1〜4のいずれか（または複数）をContext Layerに置き、そのうえでTask Layerに「〇〇機能を実装して」と書いてコードを生成させます。
ステップ2（レビュー）
生成したコードをそのまま次のプロンプトに渡し、Review Layerとして次の英文を渡します。
Act as a security engineer. Review this code for OWASP Top 10 vulnerabilities (injection, XSS, broken auth, etc.). List issues and rewrite securely. Check for path traversal, RCE, crypto failures.
意訳と使い方です。
-
Act as a security engineer.
セキュリティエンジニアの視点で見るよう役割を指定する。 -
Review this code for OWASP Top 10 vulnerabilities (injection, XSS, broken auth, etc.).
渡したコードをOWASP Top 10（インジェクション、XSS、認証の不備など）の観点でレビューする。 -
List issues and rewrite securely.
問題点を列挙し、安全な形に書き直したコードを出力する。 -
Check for path traversal, RCE, crypto failures.
パストラバーサル、リモートコード実行（RCE）、暗号の誤用や弱い設定も確認する。
この2ステップにすると、自己修正のループがプロンプト設計に組み込まれ、単発の生成より脆弱性を減らしやすくなります（同上Dev.to）。
手法の使い分け——何に、何を当てるか
ここまで紹介した手法と、対象とする脅威・推奨ツール・適用例を一覧にすると、次のとおりです。The Hacker Newsのセキュアvibecodingガイド（The Hacker News: Secure vibe coding）を参考に整理しています。
| 手法 | 対象とする脅威 | 推奨ツール・フレーム | 適用例 |
|---|---|---|---|
| 入力検証・サニタイズ | XSS、インジェクション | DOMPurify（JS）、bleach（Python） | フォーム処理、検索、コメント表示 |
| 秘密の非ハードコード | キー・トークン漏洩 | 環境変数、Vault等 | APIコール、DB接続、外部連携 |
| サーバーサイド認証 | 特権昇格、不正アクセス | JWT/OAuth、サーバー側認可 | エンドポイント、管理機能 |
| セキュアなログ・エラー | 情報暴露、攻撃の手がかり | Winston（Node）等、監査ログ | エラーハンドラ、認証失敗時 |
| Multi-Stepレビュー | 全般的な脆弱性 | Claude/Cursor等の複数ターン | プロダクトコード全体の見直し |
実務では、プロンプトで生成→SnykやSonarQubeでスキャン→人間が最終レビューという流れにすると、さらに安心です。Invictiのチェックリスト（Invicti: Vibe coding security checklist）でも、こうしたワークフローが推奨されています。また、Wiz Researchが公開しているGitHubリポジトリ（claude.mdなどのテンプレート）をシステムプロンプトやContextにロードする運用も、2026年頃からよく言及されています（Vibe Coding Framework: Security-focused prompts）。既存のセキュリティ指向プロンプトを流用することで、自前の文脈層を厚くしやすくなります。
すぐ試せる——Redditの「コピペ用」セキュリティプロンプト
実務で「今日から使える」ようにまとまったコピペ用のセキュリティプロンプトが、Redditのr/vibecodingで共有されています（Reddit: Copypaste security prompts for vibe coding）。この記事で紹介した入力検証・秘密管理・認証・ログ・Multi-Stepの考え方と対応しており、Webアプリをvibecodingする際の文脈層としてそのまま貼って使えます。まずはここから試し、自社のスタック（言語・フレーム・OWASPの重点項目）に合わせて文言を足していくのがおすすめです。
まとめ——短期の速さを維持しつつ、脆さを減らす
vibecodingは短期の生産性を高める一方で、AIのデフォルト出力はセキュリティを前提にしていないため、そのまま本番に載せると脆弱性や技術的負債が増えがちです。セキュアなプロンプト手法は、次のように整理できます。
第一に、3層（Context・Task・Review）でプロンプトを組むこと。 最初にOWASPや言語のセキュリティルールを明示し、そのうえでタスクを指示し、生成後にセキュリティレビューと修正までプロンプトに含めます。
第二に、入力検証・秘密の非ハードコード・サーバーサイド認証・セキュアなログを、それぞれ具体的な英文プロンプトで文脈層に置くこと。** ここで紹介した5つのプロンプトをそのままコピーし、対象とする機能（フォーム、API、認証、エラーハンドラ）に応じて使い分けられます。
第三に、生成→レビュー→修正のMulti-Stepを習慣にすること。** 1回の生成で終わらせず、「OWASP Top 10でレビューし、問題があれば書き直せ」と続けるだけで、クリティカルな脆弱性をかなり減らせるという検証結果もあります。
「速さ」はそのままに、脆さを減らす。そのために、プロンプトの設計と、スキャン・人間レビューとの組み合わせを、明日からのvibecodingに取り入れてみてください。
作成日：2026年3月17日