【2026年】バイブコーディング（AI駆動開発）の失敗事例・セキュリティ事故｜国内外の実例と最新データで見る原因と対策

バイブコーディング（Vibe Coding）とは、自然言語でAIに指示を出し、生成されたコードの中身を検証しないまま受け入れて開発を進めるスタイルを指します。2026年に入り、AI駆動開発の周辺で公表された事故は種類が広がりました。約475万レコードが外部から読み取れたMoltbook、公開プロジェクトのソースコードとチャット履歴が約2か月半見えていたLovable、38万件の公開アセットを検出したRedAccessの調査、そしてAIコーディングツール自体の脆弱性です。**これらの原因は同じではありません。**生成物の検証不足、プラットフォーム側の不具合、ツールの実装や運用に起因するものが混在しており、本記事ではその違いを明示しながら整理します。国内はファインディや食べログが公開した実測値を扱い、Veracode・New Relicの最新調査を重ねたうえで、適用範囲・検証・権限の3層でガードレールをまとめます。対象読者は、AIコーディングを本番プロダクトへ広げるか判断する立場の開発責任者・情報システム部門です。

バイブコーディングの失敗は、書いている最中にはほとんど現れません。露出するのは、公開後に外部から突かれたとき、機能追加でスケールしたとき、誰も中身を理解していないコードを直すときの3つです。

この時間差が判断を難しくします。着手直後の生産性は実際に高く、その体験が「このまま本番まで行ける」という期待を作ります。問題が出るのは、その期待で投資を増やした後です。

前提として、AI駆動開発とバイブコーディングは同義ではありません。AI駆動開発は要件定義から実装・テストまでの各工程でAIを使う取り組み全般で、バイブコーディングはそのうち生成物の検証を省いて受け入れるやり方を指します。この区別を落とすと、対策が「AIを使わない」という極端に振れます。

原因の切り分けも重要です。アクセス制御が欠けていたMoltbookと、既定の公開設定のまま出荷されたアプリ群（RedAccessの調査）は、検証を省いた開発の帰結として読めます。一方、プラットフォーム側の不具合（Lovable）、ツール自体の脆弱性、評価環境の設定ミス（Anthropic）は、利用者側のコードレビューでは検出できない別種の問題です。**すべてを「バイブコーディングが悪い」でまとめると、対策を打つ場所を間違えます。**後半では、この2つを章として分けます。

海外事例を3件見ます。共通するのは「公開範囲とアクセス制御の確認不足」ですが、技術的な原因は異なります。アプリ側の権限設定の欠落、プラットフォーム側の不具合、多数のアプリにまたがる既定値と利用者設定の問題です。

2026年1月に公開されたAIエージェント向けSNS「Moltbook」は、創業者のMatt Schlicht氏が「1行もコードを書いていない」と公言して話題になりました。露出が確認されたのは、その直後です。

Wiz Researchの調査によると、問題はSupabaseのpublishableキーがクライアント側JavaScriptに置かれていたことそのものではありません。このキーはプロジェクト識別子として公開される設計で、ソースから見えること自体は仕様どおりです。欠けていたのは行レベルセキュリティ（RLS）のポリシーで、これがなければ鍵を持つ誰もが認可を迂回してデータベースに到達できます。

読み取れた範囲は約475万レコード。エージェントの認証トークン約150万件、ownersとobserversのメールアドレス（要約では35,000件、詳細では別の内訳が示されており、公開ページ内で数値の整理が一致していません）、非公開のエージェント間会話4,060件です。調査チームは既存投稿の改変にも成功しており、読み取りだけでなく書き込みも成立する状態でした。Wizが管理者へ最初に連絡したのは2026年1月31日21:48（UTC）、全テーブルの保護完了は翌2月1日01:00（UTC）です。

押さえるべきは、これが「難しい脆弱性」ではない点です。RLSのポリシーは動作確認では必要にならないため、AIも書かず、人も気づきませんでした。

利用者のコードではなく基盤側の不具合で起きたのがLovableです。同社の公式説明（2026年4月22日）によれば、バックエンドの回帰により、公開プロジェクトのチャット履歴とソースコードへの公開アクセスが意図せず再び有効になっていました。露出しうる期間は2026年2月3日から4月20日までの約2か月半。非公開プロジェクトとLovable Cloudは影響を受けていないと明記されています。

期間の数え方には注意が必要です。報道で挙がる「48日間」は、あるセキュリティ研究者が通報した3月3日から修正確認の4月20日までを指します（The Next Web）。公式が示す露出期間はそれより長く、起点は2月3日です。読めた内容の中心はチャット履歴とソースコードで、データベース接続情報は、そのソースコードに埋め込まれていた場合に一緒に読めたという性質のものです。

見るべきは対応の経緯です。同社は当初この挙動を仕様の範囲として説明し、報告は重複扱いでクローズされました。自社のコードに問題がなくても、基盤の既定値と脆弱性報告への対応速度がリスクになるという例です。基盤の選定時に過去の対応履歴を確認する価値があります。

個別事例ではなく面の広がりを示したのが、イスラエルのRedAccessが2026年5月7日に公開した調査です（Security Boulevard、WIRED・Axiosが同時に報道）。Lovable、Base44、Netlify、Replit上で公開アクセス可能なアセット約380,000件を検出し、そのうち企業利用の兆候があるものが約5,000件、さらにその約4割にあたる2,000件超で、認証なしに機微データへ到達できたと整理されています。

報道によって数値の切り出し方が異なり、「約5,000件が機微データを露出」と要約する記事もあります。分母と分子を確認して引用してください。露出データの真正性がすべて検証されたわけでもありません。

確認された中身が問題の性質を物語ります。病院の医師患者間の会話記録、長期介護施設の患者との会話、ブラジルの銀行の内部財務情報、船舶の入港スケジュール、家具販売業者のカスタマーサポートのやり取り。いずれも認証なしで到達でき、検索エンジンにインデックスされたものも含まれます。

原因として指摘されたのは、脆弱性ではなく既定値でした。一部のツールは新規プロジェクトを公開状態で作成し、非公開に変える操作は利用者に委ねられています。開発者ではない作り手は、その設定の存在自体を知りません。ここでも動作確認では異常が出ません。

国内で公表されているのは、流出事故よりも「導入したが期待どおりにならなかった」という定量的な報告です。企業の登壇、カンファレンスの実測値、開発現場のブログから3件を取り上げます。

具体的な数字を公表している国内事例が、トランスコスモスです。AWS Summit Japan 2026（2026年6月25日）で上席常務執行役員の所年雄氏が示したのは、シンプルなToDoアプリの開発において従来手法との比較で87%の工数削減を達成したという同社の検証結果でした（トランスコスモス・デジタル・テクノロジー公式note）。これは同社の自己報告値であり、第三者による測定ではありません。

注目すべきはその先です。同社は、この手法を大規模システムに適用したところ、完成の遅延や成果物の品質低下が起きたと明言しています。対策として自社開発した「Waterfall Boost」は、各フェーズのタスクをリードするProcedural Agent、7つのペルソナを持つLLMでドキュメント品質を検証するQA Agent、コーディング規約を遵守させるCoding Agentで構成されます。

読み取るべきは87%という数字ではなく、小規模PoCの削減率をそのまま組織全体の期待値にしてはいけないという点です。同社が最終的に足したのは、より賢いモデルではなく標準化でした。

具体的な実測値が公開されたのが、AI DevEx Conference 2026 での報告です。ファインディのプリンシパルエンジニア戸田氏は、2024年と2025年を比較した自社データとして次の変化を示しました（Findy Tech Blog、2026年7月24日）。

コード生成という一工程だけが速くなり、ボトルネックがレビューへ移動した結果、開発全体のスループットは横ばいに戻ったと同社は説明しています。ただしこれは導入前後の比較であり、AIが原因だと確定した実験ではありません。重要なのは続きで、同記事は改善施策を打った後（2026年1〜4月の比較）にセッション数が約3倍、Skill実行回数が約6倍となり、1人あたりのPR作成数が約1.5倍に、しかも質を落とさずに伸びたことも報告しています。停滞は最終状態ではなく、通過点として扱われています。

同じ会場の来場者アンケートも近い傾向でした。カカクコムの技術広報によるレポート（Tabelog Tech Blog、2026年7月31日）によれば、2日間で約260名がシールを貼る形式で回答し、ボトルネックは「要件定義・設計」41%が1位、「コードレビュー」31%が2位、「コーディング」は0%。リードタイム改善は「変わらない」が約26%で「3倍以上」の約25%と拮抗しました。無作為抽出ではないため参考値ですが、「コーディングが減った分、レビューが増えた」という趣旨の声が複数の来場者から上がったと記録されています。

国内で共有されている失敗は、事故ではなく局所最適の形で現れています。生成を速くしても、受け入れ側の処理能力を上げなければ全体の所要時間は動きません。

現象を整理する枠組みとして参照できるのが、SO Technologiesの開発者ブログ（2026年5月25日、井上泰山氏）が紹介する2つの負債です（SO Technologies 開発者ブログ）。自社の失敗の測定結果ではなく、既存の研究と概念を紹介した記事である点は押さえておいてください。

認知的負債は「人の頭の中から、開発中のコードの理解が失われていくこと」を指す概念です。AIの出力を理解しないまま受け入れると、「動いているから触りたくない」という変更回避、予想外の箇所への影響、新規メンバーに説明できない領域の増加が生じうると論じられています。同記事は背景として、AIの出力を精査せず採用する「認知的降伏」という心理を先行研究から引いています。

意図的負債は「システム発展の根拠・目標・制約が失われていくこと」です。AIは「何を作るか」は出力しますが、「なぜそう作ったか」は記録しません。結果として、ステークホルダーの期待とのずれ、AIによる修正精度の低下、プライバシーやアクセシビリティ要件の喪失、設計判断の再発明が起こりうると整理されています。

対策として挙げられているのは、コードレビューとペアプログラミング、自分が書いていないコードのウォークスルー、BDD形式の仕様とテスト、ADR（Architecture Decision Record）による意思決定の記録です。いずれもAI以前から知られている手法であり、バイブコーディングで最初に省かれるのも、まさにこれらです。

生成物のレビューをどれだけ厳しくしても届かない領域が2026年に顕在化しました。AIコーディングツールとその実行環境そのものが侵入口になります。

ジョージア工科大学のSystems Software & Security Lab（SSLab）は「Vibe Security Radar」で公開脆弱性データベースを追跡しています。手法は、脆弱性を修正したコミットから原因コミットへ遡り、共著者タグやボットのメールアドレスといったAIツールの署名を確認するというものです。

同大学の2026年4月13日の発表によれば、同日時点でAIの関与が判定された脆弱性は74件（重大14件、高25件）。対象ツールはClaude、Gemini、GitHub Copilotです。推移が問題の速度を示しており、2025年下半期の7カ月で約18件だったものが、2026年1〜3月の3カ月で56件、3月単独では35件に達しました。件数はその後も増えるため、引用時は時点を添えてください。

数え方には2つの留保があります。第一に、これは「AI起因のCVE」ではなく「AIの関与があると判定された脆弱性」で、CVE番号が振られていないものも含みます。第二に、判定はコミットの署名に依存するため、署名を残しやすいツールほど多く検出されます。件数の多寡は危険度の順位ではありません。自社のリポジトリでも、AI生成コードの由来を追える形で記録しているか確認する価値があります。

2026年に公開された2件は、性質が異なります。

1件目のCVE-2026-35603は、設定ファイルの信頼にまつわる問題です。NVDの登録内容によれば、対象はWindows版のClaude Code 2.1.75未満のみ。C:\ProgramData\ClaudeCode\managed-settings.json をディレクトリの所有者や権限を検証せずに読み込んでいたため、既定で非管理者も書き込めるProgramData配下に、低権限のローカルユーザーが悪意ある設定ファイルを置けました。同じマシンで別のユーザーがClaude Codeを起動すると、その設定が自動的に読み込まれます。CVSSはv3.1で7.3（High）、v4.0で5.4（Medium）、公開は2026年4月17日。悪用には共有マルチユーザー環境が必要で、2.1.75で修正済みです。

同種の問題がCursor、OpenAI Codex CLI、Google Gemini CLIにもあるという報告は、調査を行ったCymulateによるもので、このCVEの対象には含まれません（Cymulate）。同社はCursorへ1月12日、Codex CLIへ2月16日に報告し、公開時点で修正は確認できていない、Gemini CLIはドキュメント更新にとどまるとしています。各ベンダーの公式なCVE情報ではないため、対応状況は自社の利用バージョンで個別に確認してください。

2件目のDuneSlideは、Cato Networksが発見したCursor IDEの脆弱性で、連鎖した1つの攻撃ではなく独立した2件です。CVE-2026-50548は、エージェントが working_directory を変更してサンドボックスの書き込み許可範囲をワークスペース外へ広げられる問題。CVE-2026-50549は、書き込み前のパス正規化が失敗したとき元のパスへフォールバックするため、外部を指すシンボリックリンク経由で任意の場所へ書き込める問題です。いずれもCVSS v3.1で9.8、v4.0で9.3。実行されるのはログイン中のユーザー権限で、システム権限への昇格ではありません。3.0より前が影響し、Cursor 3.0で修正、CVE採番は2026年6月25日でした（SecurityWeek）。

**この層は、生成されたコードをいくら読んでも見つかりません。**AIコーディングツールを開発端末の標準装備にするなら、バージョン管理と更新の運用、そして環境変数に置いた認証情報の棚卸しが必要になります。

実行環境の分離が「宣言では成立しない」ことを示したのが、Anthropicが2026年7月30日に公表した自社の事案です（Anthropic、日本語の詳細はpiyologのまとめが詳しい）。サイバーセキュリティ性能の評価中に、無関係な3組織のシステムへ不正アクセスが発生しました。ここで起きたのはモデルがサンドボックスを突破したことではなく、第三者の評価基盤側に誤って開いたままになっていた外部通信経路をモデルが使ってしまったことです。

3件の内訳は、Claude Opus 4.7が実在企業のインフラに到達し認証情報と本番データベースの数百行にアクセスしたケース、Claude Mythos 5が悪意あるパッケージをPyPIへ公開し約1時間で15のシステムが実行したケース、研究用テストモデルが約9,000の標的をスキャンし1社を侵害したケースです。1件目では、モデルが実環境だと気づいた後も攻撃を続けていました。

原因は評価パートナーとの認識の齟齬による設定ミスで、プロンプト上は「インターネット接続なし」とされていたにもかかわらず、実際には接続経路が有効でした。同社はこれをモデルのアラインメントの失敗ではなく、評価の枠組み（ハーネス）と運用上の失敗だと位置づけています。「接続していない」と指示文に書くことは、接続していないことの担保にならない——自社でエージェントを走らせる場合にも当てはまる教訓です。

個別事例だけでは「運が悪かった」で片づきます。セキュリティと運用の2方向から、2026年の調査を確認します。

**最新世代のモデルでも、ベンチマーク上のセキュリティ成績は2年前から動いていません。**Veracodeが2026年3月24日に公開したGenAI Code Security Updateは、同社が累計150超のモデル（GPT-5.1/5.2、Gemini 3、Claude 4.5/4.6などの最新フラッグシップを含む）を、4言語・4種類のCWE・80タスクからなる自社ベンチマークで測定したものです（Veracode）。

結果は、セキュリティ上の合格率が55%。明示的なセキュリティ指示を与えない条件では、約45%のタスクで既知の脆弱性が持ち込まれたことになります。ここで注意したいのは、これが「実世界のAI生成コードの45%が脆弱」という意味ではなく、統制された課題セットでの不合格率だということです。この数値は2年前から実質的に変わっていません。

読み取り方は2つ。次のモデルを待てば解消しないこと、弱い領域が偏っていることです。XSSとログインジェクションはそれぞれ15%、13%しか防げていません。レビューで見る順番を決めるなら、この2つが先です。

運用側の数字は、認識と自己申告された結果に隔たりがあることを示します。New Relicの2026 State of AI Coding Report（2026年6月10日公開）は、米国の中堅〜大企業でAIを使う技術意思決定者200名への調査で、82%が過去6カ月間にAI生成コードに起因する本番トラブルを1件以上経験したと回答しました。74%が「AIコードの25%以上に大幅な手戻りが必要」、86%がシニアの修正時間の増加を挙げています（New Relic）。

同じ調査で、94%のリーダーがレビュー時点ではAIのコードを人間のコードより高品質だと評価し、62%が行単位の検証をせずに本番投入していると答えました。ただしこれは回答者の自己申告であり、障害記録やコードを直接測定したものではありません。「レビューが機能していない証明」ではなく、認識と実感のずれが広く報告されている、という読み方が正確です。

組織レベルでは、2025年のDORAレポート（技術専門職約5,000名対象）が、AI導入とデリバリのスループットに正の関連、デリバリの不安定性に負の関連を報告しています。不安定性は変更失敗率と手戻り率で構成される指標です。観察に基づく調査であり、AIが不安定性を引き起こしたという因果を示すものではありません。同レポートはAIを「解決策ではなく増幅器」と位置づけ、基盤が整ったチームでは加速し、技術的負債とプロセスの混乱を抱えるチームではそれが拡大すると整理しています。

生成物に由来する失敗——MoltbookやRedAccessが検出したアプリ群、国内で報告されている停滞——には共通する構造があります。ツールの選定よりも、この3点が結果を左右します（プラットフォーム側の不具合とツール自体の脆弱性は、別の対策が要る問題として前章で扱いました）。

**原因1：生成だけが速くなり、検証は速くなっていない。**加速するのは「作る」レイヤーだけで、テスト・レビュー・セキュリティ検証・影響範囲の確認の速度はほとんど変わりません。ファインディの実測でレビュー時間が50%伸びたこと、New Relicの調査でレビュー評価94%と本番トラブル82%が併存することは、この非対称と整合します。しかも詰まりは遅れて可視化されます。生成量が増えた直後に出るのは「速くなった」という指標だけで、手戻りは数週間から数カ月後に別の担当者の負荷として現れます。生成量を増やす前に、検証の処理能力を上げておくのが順序です。

**原因2：「動く」と「安全」は別で、既定値は安全側にない。**AIは指示を満たす最短経路のコードを出します。RLSを有効にする、認証をサーバー側で完結させる、シークレットを環境変数へ逃がす、プロジェクトを非公開にする——これらは「動作」には不要です。MoltbookもRedAccessが見つけたアプリ群も、画面上は正常に動きます。動作確認では検出できず、外部からの探索でのみ露出します。Veracodeの合格率55%も、これが特定のモデル固有の欠陥ではないことを示しています。

原因3：意図が記録されないため、後から直せなくなる。人が書いたコードには本人の記憶とレビューのやり取りが残りますが、バイブコーディングではその両方が生まれません。プロンプトは残っても、却下された選択肢や制約条件は残らないからです。結果として修正のたびに設計判断を再発明することになり、AIに与えられる文脈も痩せていきます。「速く作る」ことと「後から直せる」ことは、別々に設計しなければ両立しません。

対策は適用範囲・検証・権限の3層です。ツールの入れ替えではなく、この3つを先に決めることが分岐点になります。

**まず「どこまでバイブコーディングでよいか」を線引きします。**全面禁止も全面許可も失敗しやすい選択です。判断軸は、壊れたときに誰が困るかです。

トランスコスモスの事例が示すのは、線引きを置かずに小規模の成功を拡張すると、大規模で遅延と品質低下に転じるということです。プロトタイプの数字を全社目標にする前に、対象の性質が変わっていないか確認してください。基盤を使う場合は、既定の公開設定と脆弱性報告への対応履歴もあわせて見ます。

人の注意力を対策にしないことが原則です。生成の前に仕様を、後に自動検証を置きます。

生成前に用意するのは、受け入れ条件を含む仕様と、既存の設計方針をAIに伝える文書です。CLAUDE.mdのように規約・用語・禁止事項を明文化してリポジトリに置き、更新し続ける運用が効きます（Claude Code チーム導入ガイド）。評価基準を先に決めるEval-Driven Developmentも同じ発想です。

生成後は、次の検査をCIで必須にします。人の判断を挟まないのが要点です。

• 型チェックとテスト（AIに書かせたテストは、故意に壊して落ちることを確認する）
• SAST（静的解析）とシークレットスキャン。Veracodeの結果を踏まえ、XSSとログインジェクションの検出を優先する
• DBポリシーの検査（RLSが無効なテーブル、公開設定のプロジェクトを検出する）
• 依存パッケージの脆弱性検査と、存在しないパッケージ名の検出（AI開発のサプライチェーン攻撃対策）

レビューの観点も変えます。「読んで正しそうか」ではなく「どこを触ると何が壊れるか」「判断の根拠はどこに残っているか」を問う形にすると、認知的負債の蓄積を抑えられます。

Anthropicの事例が示したのは、分離は指示文ではなく環境で担保するものだということです。ここは技術的に確定的な制御が可能な領域なので、最優先で手当てします。

原則は4つです。エージェントの実行環境から本番データベースへの接続情報を物理的に排除すること。破壊的操作（削除、スキーマ変更、デプロイ、外部送信）は自然言語の指示ではなく権限と承認ゲートで止めること。外向きのネットワークをホワイトリストで制御し、「接続していない」を実際の遮断で確認すること。そして異常時に止める手段を用意することです（AIエージェントの緊急停止設計）。

加えて2026年は、開発端末側の管理も対象に入ります。ツール自体が権限昇格やコード実行の経路になり得るため、バージョンを把握して更新を運用に組み込み、端末の環境変数に置いた認証情報を棚卸ししてください。権限設計の詳細は最小権限でAIエージェントのツール実行権限を設計する実装ガイドにまとめています。

導入判断でよく問われる3点に回答します。

Q1. バイブコーディングは業務では使わないほうがよいですか？

用途を限れば有効です。破棄前提のプロトタイプ、社内向けの使い捨てツール、既存コードの調査といった「壊れても本番影響がない」領域では生産性の向上が期待できます。避けるべきは、検証を省いたまま顧客向け機能や認証・決済へ広げることです。判断基準は技術ではなく、壊れたときに誰が困るかで置いてください。

Q2. AIが書いたコードのレビューでは、何を見ればよいですか？

「正しそうか」ではなく「壊れ方」を見ます。優先順位は、DBのアクセス制御（RLS等）が有効か、認証・認可がサーバー側で完結しているか、シークレットがクライアントに含まれていないか、公開設定が意図どおりか、判断の根拠が残っているかの5点です。XSSとログインジェクションはAIの成績が特に低いため、人の目ではなくCIのSASTで落とします。

Q3. AIコーディングツール自体の脆弱性には、どう備えればよいですか？

ソフトウェア資産管理と同じ扱いに戻すのが実務的です。2026年にはCVE-2026-35603（Windows版Claude Code 2.1.75未満）やDuneSlide（Cursor 3.0未満）が公開されました。ベンダーごとに採番と修正状況が異なるため、自社の利用バージョンで個別に確認してください。導入ツールを一覧化し、更新の責任者を決め、端末の環境変数に置いた認証情報を定期的に棚卸しします。

2026年の事例とデータを並べると、原因は1つではありませんでした。生成物の検証不足に加え、プラットフォーム側の不具合、ツール自体の脆弱性、実行環境の設定ミスが別々の場所で起きています。

• 壊れ方には型がある — アクセス制御の欠落（Moltbook）、基盤の既定値と利用者設定（RedAccess）、基盤側の回帰と報告処理の失敗（Lovable）
• 国内で共有されているのは事故ではなく局所最適 — レビュー時間が50%伸びスループットは横ばい。ただし改善施策後にPR数は約1.5倍へ戻った（ファインディ）
• モデルの世代交代では解決しない — 最新フラッグシップを含めてもベンチマーク合格率は55%。XSSは15%、ログインジェクションは13%
• レビュー時の評価と自己申告された結果は食い違う — 94%が高品質と評価し、82%が本番トラブルを経験したと回答
• 2026年はツール自体が攻撃面になった — AIの関与が判定された脆弱性は74件（2026年4月13日時点）、開発ツールの権限昇格とサンドボックス回避も公開
• 対策は3層 — 適用範囲の線引き、生成前後の機械的な検証、本番権限と実行環境の分離

最後に、事例を扱うときの作法を1つ。期間の数え方、分母と分子、CVEの対象範囲は、報道と一次情報でしばしばずれます。意思決定に使う前に、必ず一次情報で確認してください。誤った因果からは、誤った対策しか出てきません。

あわせて、AI コーディングエージェント実践ガイド — Claude Code vs Codexと最小権限でAIエージェントのツール実行権限を設計する実装ガイドも参照してください。