Vibe Coding（バイブコーディング）のセキュリティと⁠は？危険性と対策方法を徹底解説

Vibe Codingとは何か、なぜこんなに速いのか

Vibe Coding は『自然言語で意図を渡し、大きな実装単位を AI に任せる』開発です

Vibe Coding は、細かいコードを書く代わりに、自然言語で「何を作りたいか」「どう直したいか」を伝え、AI agent や coding assistant に広い実装を任せる開発スタイルを指します。最近の研究でも、Vibe Coding は人間が詳細実装を逐一制御せず、AI に比較的大きな裁量を渡す新しい開発パラダイムとして扱われています。つまり、補完ツールの延長ではなく、仕様の解釈からファイル作成、修正、場合によってはデプロイ直前の整形までを AI にまとめて委ねる点が特徴です。

速さの理由は明確です。UI の雛形、API 呼び出し、状態管理、フォーム、テストコード、設定ファイルを一気に出せるため、従来なら数時間から数日かかる往復が短時間で回ります。しかも人間側は「何をしたいか」を文章で伝えるだけでも前へ進めるので、細部の設計負荷が一時的に下がります。その結果、試作品や新機能を驚くほど短期間で形にできるのが Vibe Coding の魅力です。

ただし、この速さは「仕様が正しく固まっている」「何を browser に置いてはいけないか決まっている」「どの host が外へ出るか分かっている」ことを保証しません。AI は曖昧な指示からも動くものを出せますが、動くことと安全であることは別です。とくに公開サービスでは、機能が先に見えて境界条件が後回しになるため、コードが動いている間に管理面や staging がそのまま残る危険があります。

ここで重要なのは、Vibe Coding を禁止対象として語らないことです。AI を使った開発自体は今後も増えますし、実際に productivity は上がります。問題は「AI に任せること」ではなく、AI に任せた結果として、人間が確認すべき境界まで省略してしまうことです。したがって本記事では、Vibe Coding を broad な AI 一般論ではなく、公開前の確認工程が抜けやすい実装運用として整理します。

速く作れるほど『安全に見える錯覚』も強くなります

Vibe Coding が厄介なのは、速く動くものが出るほど「このままでも十分ではないか」という錯覚が強くなることです。画面が表示され、API も応答し、社内 demo では問題なく見えると、チームはつい「後で直す」を積み残したまま次へ進みます。しかし公開サービスで危ないのは、機能停止よりも、動いている裏で秘密情報、管理画面、preview host、未管理 endpoint が外へ残ることです。

既存の フロントエンドのAPIキー露出とは？ や クライアントシークレット漏えいとは？ で扱っている個別リスクは、まさにこの「動くから通してしまう」流れの中で入り込みやすくなります。Vibe Coding の危険性は、個別の flaw が新しいわけではありません。むしろ、昔からある実装ミスが、速い開発サイクルの中で一気に量産されやすくなることにあります。

なぜ Vibe Coding ではセキュリティ確認が抜けやすいのか

モデルは機能要求だけでも答えますが、security constraint がないと安全側を保証しません

Veracode の 2025 GenAI Code Security Report↗ は、100 を超えるモデルを対象に、security-specific guidance を与えない条件でコード生成を評価しています。その結果、全体では secure code になったのは 55% で、逆に言えば45% のタスクで既知の security flaw が混入しました。しかも report は、新しい大規模モデルほど機能は良くても、security quality は大きく改善していないと示しています。

これは Vibe Coding の実務感とよく一致します。人間が AI に渡す指示は「この機能を動かしたい」「この画面を作りたい」が中心で、prepared statement を使うか、CORS をどう絞るか、ログをどう sanitize するかまで毎回明示していないことが多いからです。つまり AI は悪意を持って危険なコードを書くのではなく、機能要求しか渡されていないので安全条件を自力で補完し切れないのです。

ここで重要なのは、Vibe Coding を「AI が未熟だから危険」とだけ片付けないことです。レポートが示す本質は、モデルが security constraint を自動で埋める前提に立つと危険だという点です。つまり対策は「もっと賢いモデルを使う」より、何を安全条件として明示するかを開発側が先に固定することにあります。

さらに recent research の Is Vibe Coding Safe?↗ も、低監督の agent-driven coding をそのまま production quality とみなすのは危険だと示しています。Vibe Coding は prototyping や探索に向いていても、公開サービスに必要な review と verification を飛ばしてよい根拠にはなりません。読者が押さえるべきなのは、AI が速く書けることと、企業が安全に公開できることは別問題だという点です。

レビュー負債は『コード量』ではなく『判断の見落とし』として積み上がります

人手開発では、書いたコード量が増えるほどレビュー負債がたまるイメージを持ちやすいですが、Vibe Coding ではそれだけではありません。問題は、AI が判断した境界条件や前提が、diff だけでは追いにくいことです。たとえば「この API は front-end から直接叩いてよいのか」「この preview URL を残してよいのか」「この生成コードはどの package を暗黙に追加したのか」といった判断は、画面が動くと見落とされやすくなります。

つまりレビュー負債は、コードの長さより、人間が自分で決めたつもりになっているが、実際は AI が決めた部分に宿ります。NCSC の Guidelines for secure AI system development↗ も、AI システムでは secure design・secure development・secure deployment・secure operation を lifecycle 全体で見るべきだとしています。Vibe Coding で危ないのは、まさに development の速さに引っ張られて、deployment と operation の境界確認が遅れることです。

加えて、チーム内での責任移譲も起きやすくなります。AI が書いたから開発者は細部を見ず、レビュー担当は「本人が確認しているはず」と思い、PM は demo が通ったので前へ進める。こうして、誰も明示的に危険な判断をしていないのに、誰も境界を引き直していない公開サービスが出来上がります。Vibe Coding のリスクは、悪意よりも責任の薄まり方にあります。

Vibe Coding で起きやすいセキュリティ事故

API key、client secret、管理系 endpoint が browser 側へ残りやすくなります

一番起きやすいのは、front-end へ置いてはいけない値や処理が、そのまま browser 側に残ることです。AI に「API から結果を返す検索画面を作って」と頼むと、動かすために直叩き実装を出しやすく、そこへ key や token を埋め込むことがあります。これが公開されると、配信物や通信から値が再利用され、課金、検索、外部送信、管理系操作の責任境界が崩れます。ここは既存の APIキー露出 と client secret 漏えい の深掘り先ですが、Vibe Coding では「まず動かす」過程で一気に入り込みやすい点が主役です。

さらに AI は、管理画面や内部 API を見つけやすい命名の route、緩い CORS、デバッグ向けの verbose log、テスト用 credential の残置も同時に生成することがあります。これらは一つずつ見ればよくある実装ミスですが、Vibe Coding では複数が短時間でまとめて入り込み、しかも review が機能差分中心だと見落とされます。結果として、browser から見えるもの全部が本番品質だと誤認される状態になりがちです。

staging、preview URL、Swagger/OpenAPI、古い login page がそのまま残ります

もう一つ大きいのが、コードの脆弱性よりも公開面の置き去りです。Vibe Coding では新しい機能を切り出すたびに preview 環境、検証 host、仮の subdomain、OpenAPI docs、管理画面、サンプルページが増えやすくなります。これらは開発者にとっては便利でも、公開後に残れば attack surface です。しかも repo review だけでは、最終的にどの host と path が internet-facing なのか は見えません。

既存の シャドーAPI、管理画面・開発環境の露出リスク、外部接続点は見えているか？ が扱う論点とつながる部分です。ただし本記事の主役は、それらが「なぜ増えたか」です。Vibe Coding では速い反復の代償として、作った接点の棚卸しが追いつかず、公開面が雪だるま式に増えることが起きやすいのです。

たとえば demo のためだけに作った admin route、preview 用 subdomain、暫定の Swagger UI、beta host が残ったまま GA に進むケースは珍しくありません。AI が route や config を素早く作れるほど、人間側が「残すべきでない公開面」を意識して消し込まない限り、外から見える接点は増え続けます。これはコード品質というより、公開資産管理の失敗です。

依存関係、agent 権限、入力汚染の問題が同時に入ってきます

Vibe Coding は一つのモデル出力だけで完結しません。package を追加し、agent が browser や filesystem を触り、外部 docs や issue を要約し、場合によっては CLI から実行まで進みます。そのため、AI 任せ開発の危険はコード単体に留まりません。最近の GoodVibe↗ のような研究が、生成コードの security を強化する追加学習や guardrail を提案しているのも、素のままでは security outcome が安定しにくいからです。

実務では、この領域は 悪意ある package、プロンプトインジェクション、AIエージェントの過剰権限、サービスアカウント管理 に分けて見る必要があります。Vibe Coding の危険性は、それらを一つの記事で全部深掘りすることではなく、複数のリスクが同時に薄く入り込みやすいことを示す点にあります。だからこそ「AI を使ったら危険」ではなく、どの観点で review を分けるかが重要になります。

実際に確認されている露出事例は何か

ここで気になるのは、「本当にそれは机上の懸念なのか、それとも現実に事故へ近い状態が出ているのか」という点です。現時点では、Vibe Coding で作られた個別サービスの詳細な postmortem が大量に公開されているわけではありません。ただし、platform 側の脆弱性や、AI 任せ開発で作られたアプリ群に共通する露出パターンは、すでに複数の調査で確認されています。つまり、“固有名詞の大事故が少ないから安全” とは言えず、むしろ露出が増えている初期段階として捉える方が現実的です。

もっとも具体的なのは、Wiz Research が 2025 年に公開した vibe-coded applications 調査↗ です。ここでは、1 in 5 organizations が system-wide risk にさらされていたとされ、実際の匿名化事例として、client-side に埋め込まれた password、露出した API key、公開された Supabase table、認証なしで internet-facing になっていた internal app が示されています。これは単なる theory ではなく、「AI で速く作った結果として、どんな粗さが現実に残ったのか」を示す in-the-wild の例です。

さらに 2025 年 7 月には、Wiz が Base44 の critical vulnerability↗ を公開し、private app に対して hidden registration URL から unauthorized sign-up ができる問題を説明しました。これは開発者が個別に API key を埋め込んだような単発ミスではなく、Vibe Coding platform 側の trust boundary が崩れると、そこに乗っている private app 全体が巻き込まれることを示した事例です。AI で速く作る文化では platform 依存も大きくなるため、生成コードだけでなく、足場になっている platform の security も点検対象になります。

報道ベースでも、2026 年 2 月には Digital Watch が BBC 報道を引用し、Orchids の脆弱性↗ が unauthorized access や code / data tampering の足掛かりになり得ると整理しています。これは一次調査報告ではないため扱いは慎重にすべきですが、少なくとも「Vibe Coding platform の認証と入力処理が甘いと、開発者だけでなく利用者の project まで巻き込みやすい」という方向性を補強します。したがって、Vibe Coding の security を考えるときは、生成コードの review だけでなく、platform、権限、公開面、依存先をまとめて見る必要があるのです。

企業が最低限入れるべきガードレール

prompt より先に、受け入れ基準と境界条件を文章で固定します

Vibe Coding を安全に使う第一歩は、良い prompt を書くことではありません。最初に必要なのは、「この機能では browser に何を置かないか」「どの API は server-side 経由にするか」「どの host は外へ出してはいけないか」を先に固定することです。つまり仕様書の中に security acceptance criteria を入れ、AI への指示と review の両方が同じ境界を参照する状態を作ります。これがないと、モデルは機能要件だけを満たし、人間は動作確認だけで通しやすくなります。

NCSC の secure AI guideline も、AI 開発では security must be a core requirement throughout the life cycle と整理しています。Vibe Coding でこの意味は、「あとで review するから今は速く作る」では足りないということです。速度が高いからこそ、最初に固定しておく設計条件 が必要になります。

review は『コードの正しさ』と『公開面の正しさ』を分けて行います

多くのチームは code review を diff review と同一視しがちですが、Vibe Coding ではそれでは足りません。必要なのは、機能と security を同時に見ることではなく、コードの正しさと公開面の正しさを別レーンで確認することです。前者では入力検証、認証、権限、依存関係、logging を見て、後者では domain、subdomain、preview host、Swagger、login page、staging、bucket、証明書、API docs を見ます。

この二段構えにすると、「コードは綺麗だが公開面が雑」「公開面は整理したが browser 直叩きが残る」という抜けを減らせます。Vibe Coding では生成物の幅が広いので、review も一つの checklist に押し込まず、開発レビューと外部観点の点検を意識的に分離した方が運用しやすくなります。

release gate に依存関係、権限、公開接点を入れると暴走しにくくなります

最終的に必要なのは、AI コーディングを特別扱いしない仕組み化です。package 追加時の review、agent や CLI の権限範囲、browser へ出してよい値、公開 docs と preview 環境の棚卸し、BFF の有無、監査ログ、rollback 手順を release gate に含めれば、AI を使っていても使っていなくても同じ基準で止められます。Vibe Coding の対策は、新しい神話を作ることではなく、速い開発でも抜けない gate を作ることです。

なぜ外部観点の公開面点検が必要なのか

code review は repo を見ますが、利用者は公開面を見ます

Vibe Coding の最大の盲点は、AI が作ったコードをどれだけ丁寧に review しても、実際に internet-facing になった接点までは自動では分からないことです。利用者や攻撃者が触るのは repo ではなく、公開中の host、login page、Swagger、preview URL、asset、API endpoint です。つまり code review がいくら良くても、公開接点の棚卸しがなければ、見えている attack surface を過小評価します。

特に Vibe Coding では、短時間で複数の機能、route、host、docs が増えるため、チームは「今どれが外へ出ているか」を見失いやすくなります。既存の 外部公開資産台帳 や サブドメイン監視 が役立つのは、この見失いを止めるためです。Vibe Coding は開発速度の話に見えますが、公開後は外部公開資産管理の問題として現れます。

AI が増やした接点は、公開後に差分で追う方が現実的です

すべてをリリース前に完璧に止めるのは現実的ではありません。だから公開後は、どの subdomain、login page、API host、docs、staging が増えたかを差分で追う運用が必要です。NCSC の AI threat assessment も、AI は intrusion の効率と規模を上げ、AI system 自体も新しい attack surface を増やすと指摘しています。開発側が Vibe Coding で接点を増やすなら、防御側も変化を継続的に拾う視点が必要になります。

その意味で Vibe Coding の安全性は、モデル品質だけでは決まりません。公開後にどれだけ早く「意図しない接点」を見つけ、責任者へ戻し、止められるかで決まります。だから企業では、AI コーディングの議論を開発 productivity だけで終わらせず、公開後の attack surface 運用まで含めて評価する必要があります。

Vibe Codingで作ったサービスを ASM診断 PRO で点検するなら

ASM診断 PRO は AI のコードレビュー製品ではありませんし、LLM の prompt や agent の権限を直接制御するツールでもありません。それでも Vibe Coding の文脈で意味があるのは、AI で速く作った結果として外へ出やすい接点を外部観点で見直せるからです。コードレビューだけでは、実際に公開されている login page、preview host、Swagger/OpenAPI、古い staging、用途不明の subdomain、公開ストレージは見落としやすくなります。

Vibe Coding で作ったサービスは、開発速度が高いぶん「動く状態」のまま接点が残りやすくなります。たとえば、社内検証のために一時的に出した host、AI が便宜上作った admin route、debug 用 API、preview URL が片付かないまま本番と並走することがあります。ここで重要なのは、AI で作ったこと自体を責めるのではなく、公開面の変化を人間が追い切れなくなる構造を認識することです。

ASM診断 PRO を導入すると、そうした外から見える接点をまとめて洗い出し、どの host を止めるべきか、どの管理画面や API docs が露出しているかを整理しやすくなります。特に Vibe Coding では、機能要件の検証に意識が寄るため、公開面の棚卸しは後回しになりがちです。だからこそ、公開後の初期段階で無料の外部観点診断を挟み、コードではなく公開状態から粗さを見つける導線を作る価値があります。

既存の APIキー露出、client secret 漏えい、シャドーAPI、外部接続点の可視化 とつなげて見ると、AI コーディングで起きる問題を「コード品質」だけで終わらせず、公開運用の課題として整理できます。AI で速く作ったサービスほど、まずは外から見える状態を点検し、公開後に残った粗さを早めに潰す方が安全です。

よくある質問（FAQ）

Vibe Coding は危険だから企業では禁止した方がよいですか

一律禁止より、境界条件と review gate を明確にした方が現実的です。便利さが高いため、禁止だけでは個人利用や未承認利用へ流れやすく、結果的に見えないリスクが増えることがあります。

AI が書いたコードは全部 insecure だと考えるべきですか

そうではありません。問題は AI が書いたこと自体より、security constraint を与えず、公開前の確認も省略したまま本番に近づけることです。生成コードは review と testing を前提に扱うべきです。

一番最初に決めるべきガードレールは何ですか

browser に置いてはいけない値、server-side に寄せる処理、外へ出してはいけない host と docs の境界です。これを文章で固定すると、prompt と review が同じ基準を参照できます。

コードレビューだけでは足りないのはなぜですか

repo review では、実際に internet-facing になった host、preview URL、Swagger、古い staging までは見えません。Vibe Coding では接点の増加速度が速いため、外部観点の棚卸しが別途必要です。

Vibe Coding と相性の悪い実装は何ですか

front-end 直叩き API、browser に置く secret、管理系 endpoint の暫定公開、agent の広い権限、review なしの dependency 追加は特に危険です。どれも「とりあえず動く」実装として残りやすいからです。

まとめ

Vibe Coding のセキュリティを考えるとき、焦点は AI への賛否ではありません。重要なのは、自然言語から速く実装できるようになった結果、機能要求に対して security requirement と公開面確認が追いつかなくなることです。最新の report や research も、生成コードは機能面の向上ほど安全性が伸びていないこと、そして低監督の agent-driven coding をそのまま production quality と見なすのは危険であることを示しています。つまり Vibe Coding の問題は、AI が危険だからではなく、人間がどこを確認しなければならないかを曖昧にしやすいことです。

実務では、front-end に残る secret、preview host、Swagger/OpenAPI、古い staging、未管理 API、緩い agent 権限、雑な dependency 追加が典型的な事故の入口になります。どれも新しい脆弱性ではありませんが、Vibe Coding では「まず動かす」過程で短時間にまとめて入り込みやすくなります。だから対策は、もっと強いモデルへ期待することより、browser に置いてはいけない値、server-side に寄せる処理、公開してはいけない接点、review gate、外部観点の点検をあらかじめ決めておくことです。Vibe Coding を安全にするとは、速さを捨てることではなく、速い開発でも崩れない境界条件を持つことにほかなりません。

そして公開サービスでは、コードレビューだけで終わらせないことが重要です。利用者や攻撃者が見るのは repo ではなく、実際に公開された host、login page、preview URL、管理画面、API docs です。AI で速く作ったサービスほど、公開後の外部観点点検を一度挟み、今どの接点が外へ出ているかを棚卸しした方が、個別の flaw 修正より大きな再発防止になります。Vibe Coding を導入するかどうかより、Vibe Coding で増えた接点をどう可視化し、どう止めるか を決めたチームの方が、長期的には安全に速さを使いこなしやすくなります。