Vibe Codingで作られた案件の時限爆弾パターン
「Cursorで6ヶ月かけて作りました。月次売上は安定していて、コードも綺麗に整理されています」
そう言って送られてきたGitHubリポジトリを開くと、確かに美しかった。命名規則は統一されていて、コメントも丁寧に書かれている。ESLintの警告もない。一見すると、腕の立つエンジニアが丁寧に設計した、引き継ぎやすいシステムに見えた。
ところが「決済処理のこの部分、どういう意図でこの実装を選んだんですか」と聞いた瞬間、返ってきたのは少し間の空いた「……ちょっとAIに聞いてみます」という一言だった。（AIに聞かないと自分のコードを説明できないのか、という事実に数秒かかって気づいた。）
2026年現在、M&A市場に「Cursor/Claude Codeで作りました」と添えられた売り案件が急増している。個人開発者がAIエージェントを使って短期間で複雑なシステムを構築し、それを売却しようとするケースが珍しくなくなった。動いているし、コードは綺麗。でも引き継いだ翌月に本番障害が起きた瞬間、「なぜそうなっているのか」を誰も説明できない、という状況が現実に発生している。
本記事では、Vibe Codingで生まれたシステム特有の「時限爆弾パターン」を7つ解剖し、買収前に実施すべき技術的DDの具体的な手順と、契約設計による負債ヘッジの論点を整理する。
1. 「Cursor/Claude Codeで作りました」案件が、なぜ2026年に急増しているのか
1-1. Vibe Codingが破壊した「エンジニアリングの参入障壁」と、その代償
2023年頃から顕在化し始め、2025〜2026年にかけて一気に加速した「Vibe Coding」と呼ばれる開発スタイルがある。設計書もUMLもなく、「こういうものを作って」とAIエージェントにプロンプトを投げ、出てきたコードをそのまま本番に反映させていく開発の手法だ。CursorやClaude Code、GitHub Copilotといったツールの急速な進化が、これを現実のものにした。
かつては「Webアプリを一から作って運用する」という行為は、相応のエンジニアリング知識がなければ到達できない領域だった。データベースの設計、APIの設計、セキュリティの考慮、インフラの構築。これらを自力でこなせない人間は、エンジニアを雇うか、外注するしか手段がなかった。
Vibe Codingはその参入障壁を実質的に消し去った。エンジニアリングの教育を受けていない人間が、本格的なSaaSやWebサービスを「動くレベル」まで構築できるようになった。これ自体は革命的な変化であり、私も否定するつもりは一切ない。問題は、「動かせる」ことと「理解している」ことは、まったく別の話だという点だ。
M&Aの文脈でこれが深刻になるのは、「動いていて売上もある」という事実が、「設計意図が存在する」という証拠にならないからだ。コインランドリーが動いていても、なぜその配管がそこにある理由を知らなければ、壊れたときに誰も直せない。その「知らない」が、売り手の頭の中にではなく、AIとの消えたセッションログの中にある。これが2026年のM&A市場で起きている変化だ。
1-2. 「作れる人」と「説明できる人」の間に広がった断絶
人間が書いたコードには、どれだけ汚くても「書いた人の思考の痕跡」が残る。変数名の癖、処理を分割した判断の跡、コメントが書かれている箇所と書かれていない箇所のパターン。これらは言うなれば設計者の脳の化石であり、引き継ぐ側のエンジニアは化石を手がかりに「なぜこういう構造なのか」を積み上げられた。
Vibe Codingで生成されたコードには、その化石がない。構文的に正しく、命名規則も統一され、見た目はむしろ美しい。しかし「なぜこのアーキテクチャを選んだのか」「なぜここでこのライブラリを使っているのか」という問いに、コード自体が答えを持っていない。答えを知っていたのはAIとのセッションの中の「文脈」であって、そのセッションはすでに消えている。
従来の属人化リスクは「知識がその人の頭の中にある」問題だった。解決策は引き継ぎ期間を設けてドキュメントを整備することだ。しかしVibe Codingの属人化は「知識がどこにも残っていない」問題に変質している。売り手に聞けば「当時こういうプロンプトで作った」という事実は教えてもらえるが、「このエラーがなぜ起きているのか」の技術的な根拠は、売り手本人も答えられない。
2. Vibe Codingシステム特有の7つの時限爆弾
2-1. 【爆弾①】誰も理解していないDB設計：AIが選んだスキーマの論理的欠陥
Vibe Codingで最初に爆発しやすいのが、データベース設計だ。AIエージェントはプロンプトに書かれた「今作る機能」の要件に対して「もっともらしいスキーマ」を生成する。しかしそのスキーマには、将来の機能追加や運用上の制約が一切考慮されていないことが多い。
典型的なパターンとして、正規化が不十分なまま本番運用されているケースがある。データの重複が発生し、整合性が崩れていくが、ユーザー数が少ない初期フェーズでは気づかない。買収後にユーザーが増えた段階でクエリが重くなり、データ修正のための移行コストが膨大になって初めて発覚する。また、外部キー制約が設定されておらず参照整合性が保証されていないケース、インデックス設計がなく特定のクエリが想定外のフルスキャンになっているケースも頻出する。
DB設計の問題が特に厄介なのは、アプリケーション側のコードをどれだけ美しく書き直しても、スキーマを根本から変えない限り解決しない点だ。そしてスキーマの大幅な変更は、大量のデータが入った本番環境では、ダウンタイムを伴う重大な作業になる。
2-2. 【爆弾②】「その時点で流行っていた」ライブラリの依存地獄
AIエージェントは、学習データの時点で一般的に使われていたライブラリを「もっともらしい選択肢」として提案する。これは悪意のある行為ではなく、統計的な判断の結果だ。しかし問題は、「その時点で一般的」なライブラリが、「長期的にメンテナンスされる」ライブラリとは限らないという点だ。
Vibe Codingのシステムでは、依存ライブラリが無計画に積み重なっていることが多い。新しい機能を追加するたびに「必要そうなライブラリ」をAIが都度選択した結果、似たような役割のライブラリが複数入り込んでいる（たとえばHTTPクライアントが3種類共存しているなど）。バージョンが固定されておらず、本番環境と開発環境で動作が異なる事象が発生しているケース、EOL（サポート終了）を迎えたバージョンが使われ続けているケースも珍しくない。
npm auditやpip-auditを走らせると、クリティカルな脆弱性が数十件ヒットするシステムが、売値数百〜数千万円の案件として出回っている。依存関係の棚卸しは、DDの初動で必ず実施すべき作業だ。
2-3. 【爆弾③】正常系しかないテストコード：エラーハンドリングの完全欠落
テストコードが存在すること自体は良いことだ。しかしVibe Codingで自動生成されたテストコードは、正常系（ハッピーパス）しかカバーしていないケースが非常に多い。「入力が正しい場合は正しく動く」ことは確認されているが、「入力が不正な場合」「ネットワークが切れた場合」「外部APIがエラーを返した場合」といった異常系への対応が、テストにも、そして実装にも存在しない。
これは本番で何を意味するか。ユーザーが想定外の操作をした瞬間に、エラーが握りつぶされてサイレントに失敗したり、アプリ全体がクラッシュしたりする。決済処理の途中でエラーが発生して金は引き落とされたが商品は処理されなかった、といったトラブルが、ユーザー数の増加とともに表面化してくる。
テストコードのカバレッジ率だけを見るのでは不十分だ。どんなケースをテストしているかの「質」を見なければ、このリスクは見えない。
2-4. 【爆弾④】「プロンプト履歴」しか残らない設計書問題
なぜこのアーキテクチャを選んだのか。なぜこのテーブル設計になったのか。なぜここでこの外部サービスを使っているのか。こうした設計上の意思決定を記録したドキュメント（アーキテクチャ決定記録、ADRとも呼ばれる）は、Vibe Codingのシステムにはほぼ存在しない。
存在するのは、せいぜいREADMEの「セットアップ手順」と、GitHubのコミットメッセージだ。しかしそのコミットメッセージも「Add user authentication」「Fix bug」「Update」といった機械的で均質なものが並んでいるだけで、「なぜその実装を選んだか」の文脈は一切ない。
引き継いだエンジニアがシステムを改修しようとしたとき、ドキュメントのないシステムでは「変更するとどこに影響が出るか」の把握から始めなければならない。この「現状把握コスト」が、Vibe Codingシステムでは人間が設計したシステムの数倍になることがある。引き継ぎ直後の工数を過小評価すると、PMIが計画通りに進まずキャッシュフローが狂う。
2-5. 【爆弾⑤】IaCなき本番インフラ：サーバーに眠る「秘伝のタレ設定」
インフラの構成をコードで管理する「IaC（Infrastructure as Code）」という考え方がある。TerraformやAnsibleを使って「本番環境の構成」をコードとして記述し、バージョン管理する手法だ。これが整備されていれば、同じ環境を別の場所で再現することができる。
Vibe Codingのシステムでは、このIaCがほぼ整備されていない。AWSのコンソールをGUIでポチポチと操作しながら設定した内容が、どこにも記録されていない。Nginxの設定ファイルにローカルで手書きした内容が、なぜかその設定になっているのかも不明。本番サーバーには「触ったら何が起きるかわからないので触れていない」設定ファイルが存在する。
この「秘伝のタレ」状態のインフラは、買収後に本番サーバーが何らかの理由でアクセス不能になった場合、環境の再構築に膨大なコストが発生する時限爆弾だ。サーバーが吹き飛んでも同じ環境を1時間以内に再現できるシステムと、「とりあえず動いているから触らない」サーバーとでは、障害時のダウンタイムコストが桁違いになる。
2-6. 【爆弾⑥】AIが統計的に再現する「過去の脆弱性パターン」
AIが生成したコードに脆弱性が含まれることがある、という話は2023年頃からすでに指摘されていたが、2026年現在もこの問題は解消されていない。AIは学習データに存在した「過去に書かれた脆弱なコードのパターン」を、文脈によっては再現してしまう。
具体的には、SQLインジェクション対策が不完全なクエリ生成、XSS対策が欠落したフォーム処理、適切なバリデーションなしにユーザー入力を処理するロジックなどが典型例だ。AIが生成したコードだからといって、自動的にセキュアであるという保証はどこにもない。むしろ「動いている」という事実が、脆弱性の存在に気づく機会を奪っている。
個人情報を扱うサービスや決済機能を持つシステムでこうした脆弱性が存在した場合、買収後に発覚すれば表明保証違反として売り手への請求根拠になりうるが、そもそも個人情報漏洩が先に起きてしまったら取り返しがつかない。
2-7. 【爆弾⑦】個人ユースで設計されたスケール限界と「突然の死」
Vibe Codingで作られたシステムの多くは、「今の自分のユーザー数で動けばいい」という前提で設計されている。同時接続数が10人程度の個人サービスを前提とした設計が、買収後に本格的なマーケティングを展開して100倍のアクセスが来た瞬間、文字通り「突然死」するケースがある。
Vibe Codingのシステムがスケールしない典型的な理由は、N+1クエリ問題（ループ内で毎回DBアクセスが発生する）、セッション管理がシングルサーバー前提になっている（複数サーバーへのスケールアウトが不可能）、非同期処理が実装されておらず重い処理が同期的にレスポンスを詰まらせる、といった構造的な問題だ。これらはコードを読んでいるだけでは発見しにくく、負荷テストを実施して初めて表面化する。
買収後に「ユーザーを増やす」ことを事業計画に組み込んでいる場合、このスケール設計の欠如は直接的に事業計画の達成を阻害する。
3. Vibe Coding DDの実務 ── 買収前に必ず実行すべき5つの確認
3-1. GitコミットパターンとPRレビューログで「AI依存度」を数値化する
Gitのコミット履歴は、そのシステムがどのように作られてきたかを正直に映し出す。Vibe Codingのシステムには、コミット履歴に特有のパターンが現れる。最初に確認すべきはコミットの「密度と分布」だ。
人間が試行錯誤しながら積み上げてきたシステムのコミット履歴は、細かな修正と機能追加が時系列に沿って積み重なっている。一方でVibe Codingのシステムでは、「短期間に大量のファイルが一括でコミットされる」「コミットメッセージが機械的に均質すぎる」「PRのレビューコメントがほぼ存在しない」といったパターンが現れる。
git log --stat で変更ファイル数の推移を確認し、git shortlog -s -n でコミッターの偏りを確認する。GitHubのPull Requestsを開いてレビュアーの存在とコメントの有無を確認する。「他者の目線によるレビューがない」開発プロセスは、想定外の動作を引き起こすコードが素通りしていた可能性を示す。
また、コミット日時のパターンも手がかりになる。深夜や早朝に集中してコミットが積み重なっていれば、一人の開発者がAIエージェントとのセッションで一気に作り上げた可能性が高い。これは優劣の話ではなく、「どのように作られたか」を把握するためのファクトとして捉えるべき情報だ。
3-2. 売り手に「このバグを直してください」と実際に依頼してみる
DDの終盤で最も効果的な確認が、売り手に対して意図的に小さな修正依頼を投げることだ。実際には存在しないダミーの不具合でもよいし、「○○の画面でこういう動作になっているのですが、これは意図した仕様ですか」という確認ベースの問い合わせでも構わない。重要なのは「このシステムを売り手がどの深度で理解しているか」を、回答の速度と精度で測ることだ。
自分のコードを本当に理解している売り手なら、「あそこの処理はこういう意図で実装したので、おそらくこのパラメーターが原因です」という回答がすぐに返ってくる。一方、AIに任せていた部分の話になった途端に回答が遅くなる、「確認してみます」と言ったきり数日後に「ChatGPTに聞いたところ……」という返信が来る、といったケースは、引き継ぎ後のサポートが実質的に機能しないと判断すべきシグナルだ。
この確認は、書面上のDDでは決して見えない情報を与えてくれる。売り手の技術的な説明責任能力を、契約前に実地で検証できる唯一の機会だと考えていい。
3-3. ライブラリのEOLリスクと脆弱性スキャンの具体的手順
依存ライブラリの棚卸しは、DD初動で必ず実施する。Node.js系なら npm audit、Python系なら pip-audit、Ruby系なら bundle audit を走らせ、既知の脆弱性を洗い出す。重要度を「Critical」「High」「Medium」に分類し、特にCritical判定のものは修正コストと公開リスクを買収価格に反映する根拠として使う。
同時に確認すべきなのが、ランタイム（Node.js、Python、PHPなど）と主要フレームワークのEOL（End of Life）状況だ。EOLを迎えたランタイムは、以降のセキュリティパッチが提供されない。古いバージョンへの依存が発覚した場合、バージョンアップのために必要な改修コストを技術的負債として定量化する。
またGitHubのDependabot Alertsが有効になっているかどうかも確認ポイントだ。有効になっていないシステムは、既知の脆弱性が報告されても通知を受け取れない状態で運用されていたことを意味する。
3-4. 別環境での構築再現テスト：ローカルで動かせなければ詰みの確認
DDの段階で、売り手の環境とは別の環境でシステムを動かしてみることを強く推奨する。これは「動くかどうか」を確認する作業ではなく、「再現できるかどうか」を確認する作業だ。
確認すべき項目は以下だ。ローカル開発環境の構築手順がREADMEに記載されているか。DockerやDocker Composeなど、環境を再現するための仕組みが整備されているか。本番環境のインフラ設定がIaCとして管理されているか、あるいはサーバー内に「手作業の設定」が残っていないか。
特に注意すべきが「本番サーバーにしか存在しない謎の設定ファイル」問題だ。VPSや共有サーバーで長年運用してきたシステムに頻出する。本番サーバー内の /etc 以下に手書きで追記された設定、売り手しか知らないSSHの鍵管理、cronジョブの存在。これらは引き継ぎ後に初めて発覚することが多く、発覚したタイミングで売り手とのサポート期間が終わっていれば、それだけで詰む。
3-5. 「技術的負債スコア」を値下げ交渉の根拠として使う
技術的DDで発見した問題は、定性的な懸念事項として伝えるだけでは交渉力を持てない。発見した負債項目を「対応工数（人日）×エンジニア単価」で定量化することで、価格交渉の具体的な根拠として使える。
たとえばDB設計の抜本的な見直しが必要なら30人日、脆弱性対応に10人日、ドキュメント整備に15人日、インフラのIaC化に20人日。合計75人日×エンジニア単価8万円＝600万円の技術的負債が存在する、という形で数値化する。これを買収価格から減額するか、売り手が引き継ぎ後のサポートとして対応する義務を契約書に盛り込むかを交渉する。
「コードが綺麗に見える」という印象論で価格が決まっているVibe Coding案件に対して、技術的負債の定量評価は強力な交渉ツールになる。財務DDが精査するIMの数字と同様に、技術的負債も「価格に折り込むべきリスク」として扱う姿勢がこれからのM&Aには必要だ。
4. Vibe Coding案件の契約設計 ── 負債を価格とルールでヘッジする
4-1. 引き継ぎサポート義務の明文化：「誠実に対応」では詰まる理由
技術的DDでリスクを把握した上で買収を進める場合、そのリスクを契約条件に反映させることが最後の防衛線になる。まず必ず盛り込むべきなのが、売り手の引き継ぎサポート義務の具体的な条件だ。
よくある落とし穴は「引き継ぎは誠実に対応します」という抽象的な合意だけで終わるケースだ。「誠実」の定義は人によって異なるため、いざとなると「メールに返信しているので対応している」と主張される可能性がある。「引き継ぎ期間は6ヶ月、技術的な問い合わせには5営業日以内に回答する義務を負い、月4時間を上限とした技術相談に無償で応じる。緊急の本番障害発生時は24時間以内に初期対応する」といった具体的な数字と条件を契約書に明記することが、後々のトラブルを防ぐ唯一の手段だ。
Vibe Codingのシステムでは、売り手の「説明できる範囲」が通常のM&Aより狭い可能性がある。だからこそ、その範囲を事前に明確にしておく必要がある。「AIに聞けばわかること」と「売り手にしかわからないこと」を整理した上で、後者についての義務を契約に落とすことが現実的なアプローチだ。
4-2. 表明保証条項に「設計意図の説明可能性」を入れる
M&Aの契約書には通常、「売り手が保証する事実」を列挙した表明保証条項が盛り込まれる。ここにVibe Coding案件特有の保証項目を追加することが、2026年以降の技術者DDの新しい論点になりつつある。
具体的には以下のような条項を検討すべきだ。「売り手は、対象システムの主要なアーキテクチャ選択、データベース設計の意図、および外部APIへの依存関係の選定理由について、書面またはオンライン会議にて説明できることを保証する」。あるいは「対象システムの本番環境を再現するために必要な全設定情報・認証情報・環境変数が、契約締結時点で文書化されていることを保証する」といった条項だ。
これらの保証が事実と異なった場合に補償請求の根拠となる。Vibe Codingで作られたシステムを「エンジニアチームが設計した」と売り手が誤解させた場合、表明保証違反として事後的に問える条項を持っているかどうかが、買収後の法的手段の有無を分ける。
4-3. 瑕疵担保から見た「設計意図の欠如」の射程
民法上の瑕疵担保（現行法では契約不適合責任）は、「引き渡されたものが契約の内容に適合しない場合」に売り手の責任を問う規定だ。Vibe Codingで生まれた技術的負債が「契約不適合」に当たるかどうかは、契約書にシステムの品質要件をどう記載したかによって変わる。
漠然と「安定稼働しているWebサービス」として合意した場合、後からDB設計の欠陥やスケール限界を理由に請求しようとしても、「稼働はしていた」という事実で切り返されるリスクがある。これを防ぐには、契約書の目的物の定義に「本番環境での再現可能性」「主要機能のテストカバレッジ」「既知の重大な脆弱性の不存在」といった技術要件を具体的に盛り込む必要がある。
弁護士がM&Aの契約書を作成する際、技術要件の定義は法律の専門外になるため、技術者DDの担当者がドラフトした技術要件定義を弁護士に渡して契約書に反映させる、という連携が不可欠だ。法律と技術の橋渡しができる人間が買い手側にいない場合、この連携が抜けてしまう。
Vibe Codingが普及した今の市場では、「コードの見た目の美しさ」と「システムの引き継ぎ可能性」は完全に分離した概念になった。財務DDが「黒字かどうか」だけでは企業価値を測れないように、技術的DDも「動いているかどうか」だけでは引き継ぎリスクを測れない。買い手に必要なのは、コードの外観に惑わされず設計の文脈が存在するかどうかを見抜く目です。
