Vibe Codingが生む“資産価値ゼロ”の事業

2026年現在、月商1,000万円規模のSaaS案件が市場に並ぶようになった。創業者は非エンジニア、開発期間は3か月、人件費はほぼゼロ。コードはCursor・Claude Code・Devin等のAIエージェントが書いている。財務諸表は美しい。粗利率は80%を超え、解約率も低く、グロースもしている。仲介業者の査定は「EBITDAの5倍で1.5億円」と出る。

しかし、買い手側のエンジニアがリポジトリを開いた瞬間に、全く違う風景が立ち上がる。同じ機能のコードが3か所に重複して存在し、テストカバレッジはゼロ、エラーハンドリングは「try-except: pass」の山、データベーススキーマは正規化どころか同じ情報が4つのテーブルにバラバラに保存され、認証ロジックの一部は平文でAPIキーをログ出力している。動いてはいる。しかしこれは、5年後の事業継続を担保する「資産」と呼べる代物ではない。

本稿では、Vibe Coding（雰囲気でAIに書かせるコーディング）によって生まれた事業を、買収側のバリュエーション視点でどう評価すべきかを正面から扱う。コード資産がゼロに近い前提で事業価値を測り直すロジック、例外的にVibe Codingでも価値が残る3条件、そして売り手・買い手がそれぞれ取るべきスタンスまで、現場の感覚に即して整理する。読み終える頃には、「動いているSaaS」と「価値のある事業」の間にある深い断絶が、はっきり見えるはずだ。

1. Vibe Codingとは何か ── 2025〜2026年に起きた開発文化の地殻変動

1-1. 「動けばOK」のフィーリング駆動開発 ── 設計図なしで建ったビル

Vibe Coding（バイブコーディング）は、2025年頃から急速に普及した開発スタイルを指す言葉だ。創業者またはエンジニアが、設計図・要件定義書・ER図・テストケースといった事前の構造化作業をほとんど行わず、「こういう機能が欲しい」という雰囲気（バイブ）をAIエージェントに伝え、生成されたコードを動作確認だけして本番に投入する、という流れになる。

このアプローチには合理的な側面がある。MVPの立ち上げ速度は劇的に向上し、非エンジニア創業者がプロトタイプを自力で作れるようになり、検証サイクルが数日単位に短縮された。しかし「動く」と「保守可能」は、まったく別物だ。建築に例えるなら、設計図と構造計算なしで建てたビルがその瞬間に倒れないというだけの話であり、5年後・10年後の安全性や増築可能性は別問題になる。

1-2. AIエージェントの「最尤生成」が生む構造的負債 ── 同じ問題に毎回違う解を出す

AIエージェントは「過去のコード資産」を蓄積した学習データから、その場で最も尤もらしい解を確率的に生成する。これは、同じ要件でも生成タイミングや会話履歴によって解が変わるということを意味する。1か月目に書かせた認証ロジックと、3か月目に書かせた認証ロジックが、設計思想・命名規則・依存ライブラリ・エラーハンドリング方針のすべてで一致しない、というケースが日常的に起きる。

結果として、コードベース全体を貫く「一貫した設計思想」が存在しないまま、機能だけが積み上がっていく。これは技術的負債というより、もはや「技術的乱雑」と呼ぶべき状態であり、後から読み解いて統一する作業は、ゼロからの書き直しと工数的に大差ない。

1-3. ドキュメンテーションの空洞化 ── 「コード自体がドキュメント」という最悪の言い訳

Vibe Coding環境では、設計ドキュメント・API仕様書・運用手順書といったドキュメント類が著しく薄くなる傾向がある。創業者は「コードを読めば分かる」「ChatGPTに聞けば説明してくれる」という前提で開発を進めるが、買収後に新しいエンジニアがそのコードベースに合流した瞬間、この前提は崩壊する。

新しいエンジニアがAIに「このコードベースの設計思想を説明して」と聞いても、AIはそのコードベースを学習しているわけではないため、当てずっぽうの解説しか返さない。「コードに固有のローカルな意思決定」を引き継ぐ媒体がどこにも残っていない状態が、Vibe Codingの最大の遺産だ。

2. なぜVibe Codingコードは「資産」として評価できないのか ── 4つの構造欠陥

2-1. 欠陥1：再現性のなさ ── 同じコードを書き直せない

会計上、無形固定資産として計上できるソフトウェアの要件には「将来の経済的便益が見込まれること」「合理的な金額測定が可能であること」が含まれる。Vibe Codingのコードベースは、後者の「合理的な金額測定」が極めて困難だ。同じ機能を再構築するのに必要な工数の見積もりが立たない。

具体的には、ベテランエンジニアにレビューさせても「これを書き直すのにどれくらいかかりますか」という問いに対して、「1人月かもしれないし、6人月かもしれない」というレンジでしか答えられない事態が起きる。再構築コストが見積もれないということは、その資産価値も見積もれないということであり、これがバリュエーションで「コード資産ゼロ評価」に帰結する根本理由だ。

2-2. 欠陥2：保守容易性の崩壊 ── 機能追加の限界費用が逓増する

健全なコードベースでは、機能を1つ追加するコストは規模に対してほぼ一定に保たれる。Vibe Codingのコードベースでは逆で、機能を追加するたびに、既存機能との干渉・既存バグの誘発・テストの不存在による回帰検証コストが指数関数的に増えていく。これは経済学でいう「限界費用の逓増」が、ソフトウェア領域で発生している状態だ。

買収後3〜6か月で、新機能追加が事実上不可能になる事業は珍しくない。「成長率の高い事業を買ったつもりが、買収後に成長エンジンが停止する」という構造的なミスマッチが、Vibe Coding事業の買収では頻発する。財務DDでは見えないこのリスクが、バリュエーションの中核を支える「将来CF成長率」を実質ゼロにする。

2-3. 欠陥3：セキュリティの穴 ── 「動くコード」と「安全なコード」の溝

AIエージェントは「動くコード」を最尤生成するが、「安全なコード」を最尤生成するとは限らない。SQL Injection対策の漏れ、認証バイパス可能なルーティング、平文でログに出力されるAPIキー・パスワード・カード番号、CORS設定の過剰な緩和、Cookie/SessionのSameSite未設定など、セキュリティの基本要件が抜けているケースが少なくない。

これらは「動作確認」だけでは絶対に見えない。事業が拡大し、悪意ある第三者の標的になった瞬間に、セキュリティインシデントとして顕在化する。買収後にデータ漏洩を起こした場合、改正個情法下では1事案あたり数千万〜億単位の損害賠償と、ブランド毀損による事業継続困難に直面する。この潜在リスクを評価に織り込むと、コード資産は「資産」ではなく「潜在負債」になる。

2-4. 欠陥4：依存関係の透明性ゼロ ── 何を使っているか創業者本人が知らない

AIエージェントはコードを書く際に、必要なライブラリを自動でインストールし、`package.json` や `requirements.txt` に追記する。Vibe Coding創業者は、「動いている」ことだけを確認し、そこにどんなライブラリが、どんなライセンスで、どんなバージョンで含まれているかをほぼ把握していない。

結果として、コードベースには100〜300個の依存ライブラリが含まれており、そのうち何割かはGPL系の感染性ライセンス、何割かはセキュリティ脆弱性が報告済み、何割かはメンテナーが撤退して半廃棄状態、何割かは商用利用に制限がある──といった状況になる。買収後にライセンス監査を行うと、事業継続そのものに法的疑義が生じるケースがある。

3. バリュエーションでの扱い ── 「コード資産ゼロ評価」への帰結

3-1. EBITDA倍率の補正 ── 通常案件の40〜60%まで割り引く

Vibe Coding比率が高い事業のバリュエーションは、通常のSaaS案件に適用されるEBITDA倍率（4〜8倍が標準）から、大幅な割り引きが必要になる。経験則として、コードベースの大半をAIエージェントが生成し、人間によるレビュー・リファクタリングがほぼ入っていない事業は、標準的なEBITDA倍率の40〜60%程度の補正後評価になる。

月商1,000万円・年間EBITDA3,000万円の事業を例に取ると、通常評価で1.5億〜2.4億円のところが、Vibe Coding補正後は0.6億〜1.4億円のレンジに沈む。この差は単なる感覚ではなく、買収後5年のTCO（書き直しコスト・セキュリティ事故対応・機能追加困難の機会損失）を保守的に見積もった結果として正当化できる。

3-2. 評価対象の置き換え ── コードではなく「顧客リスト」「ブランド」「データ」

Vibe Coding事業のバリュエーションでは、コード資産がほぼゼロ評価になる代わりに、「コードを書き直しても残るもの」に評価軸を移す。具体的には、顧客リスト（既存契約と更新率）、ブランド・SEO資産（自然検索流入とドメイン権威性）、蓄積データ（学習データやユーザー行動データ）、運用ノウハウ（マーケティング・カスタマーサポート知見）。

これらが揃っている事業は、「コードは書き直し前提」だが事業としては成立する。逆に、コード資産以外に評価できるものがほとんどない事業は、Vibe Codingコード自体が事業の中核を支えているということであり、買収後の事業継続リスクが極めて高い。「中身がブラックボックスの機械が動いているだけの事業」を高値で買う合理性は、どこにもない。

3-3. アーニングアウト条項の活用 ── リスクを売り手側に分散させる

Vibe Coding事業の買収では、買収価格の一部を「アーニングアウト（Earn-out）」として、買収後の事業継続実績に連動させる契約構造が有効だ。具体的には、買収価格の50%を一括支払い、残り50%を買収後12〜24か月の売上維持・成長達成度に応じて分割支払いとする。

これにより、Vibe Codingコードベースの隠れた問題が買収後に顕在化した場合のリスクを、売り手側にも分担させられる。売り手側にとっては不利な条件に見えるが、「コードに自信がある」のであれば応じるはずだ。逆にアーニングアウトを強硬に拒む売り手は、コードベースに不安を抱えている可能性が高い。

4. 例外：Vibe Codingでも評価できる事業の3条件

4-1. 条件1：コード自体が事業価値の中核でない事業

すべてのVibe Coding事業が無価値というわけではない。コードが事業価値の中核を担わない事業形態であれば、Vibe Codingで構築されていても十分な評価が可能だ。具体的には、コンテンツメディア・ECサイト（在庫管理・物流が中核）・サービス業のオンライン窓口・社内業務効率化ツール（外販していない）など。

これらの事業では、コードは「事業を支える便利な道具」であって「事業そのもの」ではない。道具なら書き直せばいい。買収後に新しいエンジニアが入って、まともなコードベースに書き換えても、事業の本質的な価値（顧客・ブランド・コンテンツ・サービス品質）は維持できる。

4-2. 条件2：人間によるレビュー・リファクタリングが入っている事業

Vibe Codingという表現自体に過剰反応する必要はない。実態として「AIが書いたコードを、ベテランエンジニアが厳しくレビューし、リファクタリングして本番投入している」事業は、Vibe Codingというよりも「AI支援開発」と呼ぶべきもので、コード品質は十分に高くなる。

この区別は、Gitのコミット履歴とプルリクエストのレビュー記録を見れば一目で分かる。コミットがすべて単一の作者で、レビューコメントがゼロ件の事業はVibe Coding。一方、複数の作者がレビューを通してマージしている事業はAI支援開発。同じ「AIで書いた」と説明されても、運用実態は天と地ほど違う。

4-3. 条件3：自動テスト・CI/CDが整備されている事業

テストカバレッジが一定水準（70%以上が目安）で確保されており、CI/CDパイプラインが回っている事業は、コード品質が一定の機械的チェックを通過していることを意味する。テストがあるということは「振る舞いの仕様が明文化されている」ということであり、これは買収後の改修・拡張において最も重要な資産になる。

逆に言えば、テストカバレッジゼロのVibe Coding事業は、「コードに仕様がない」状態であり、買収後にエンジニアが新機能を追加しようとすると、既存機能を壊さない保証が一切得られない。これは事業継続性の観点で致命的な欠陥だ。

5. 売り手・買い手のチェックポイント

5-1. 売り手側 ── 売却前にやるべき「コード資産の翻訳」3項目

Vibe Codingで事業を立ち上げた創業者が、出口戦略で適正な評価を受けたいのであれば、売却前にやるべきは次の3点だ。①ベテランエンジニアによるコードレビュー・リファクタリング、②主要機能の自動テスト追加（最低限の正常系・異常系）、③設計ドキュメント・運用手順書の整備（実装と整合した内容）。

これらは数百万円〜1,000万円程度の投資で実施可能だが、結果として買収価格を数千万円押し上げる効果がある。「コードはAIが書いたから0円」と評価される事業を、「コードに人間のレビュー実績がついた事業」として再ポジショニングできるか──ここが出口戦略の分水嶺になる。

5-2. 買い手側 ── DD段階での見極めポイント5項目

買い手側がVibe Coding事業を見極めるためのチェックリストは、①Gitコミット履歴の作者構成とレビュー記録、②テストカバレッジ率と実行頻度、③依存ライブラリ数とライセンス・脆弱性監査結果、④主要機能の単体動作確認とコードの可読性レビュー、⑤創業者本人による主要機能の口頭解説（説明できない領域はリスク）。

これらを技術DDの初期段階で実施することで、買収価格交渉における「Vibe Coding補正」の妥当性が定量的に判断できる。財務DDだけでは絶対に見えない領域であり、ここに技術的DDの本質がある。

5-3. 中間合意としての「コード資産棚卸し合意書」 ── 取引の透明性を確保する

売り手と買い手のあいだで、コード資産の状態についての中間合意を文書化する慣行が、2026年現在の業界で徐々に広がりつつある。具体的には、コードベースの規模・依存ライブラリ・テストカバレッジ・既知のバグ・直近6か月のインシデント履歴を、売り手側が表明保証する形で書面化する。

これにより、買収後に表明と異なる重大な問題が発覚した場合、買い手側が損害賠償を請求できる根拠が確保される。「コードはAIが書いたので保証できません」という説明は通用しない。事業として売却する以上、その事業を構成する技術資産について最低限の表明保証を行うのは、健全な取引慣行だ。

結論：AIが書いたコードは、バランスシートに載らない

Vibe Codingで構築された事業は、財務諸表の上では他のSaaSと変わらない美しさで見える。しかし、その下にある「コード資産」は、再現性も保守容易性もセキュリティ品質も依存関係透明性も欠いた、評価不能の存在だ。会計学的にも、バリュエーション実務的にも、これを「資産」として計上することには無理がある。

ただし、これはVibe Codingが「悪」だという話ではない。検証目的のMVP立ち上げ、社内業務効率化、コードが事業の中核を担わない領域では、Vibe Codingは劇的に合理的な選択肢だ。問題は、Vibe Codingで生まれた事業を「コード資産が積み上がった事業」として高値で売買しようとする時に発生する。売り手も買い手も、コード資産の実態を直視した上で、適正な価格と取引条件にたどり着く。これがAI時代のM&Aにおける、もっとも実務的な誠実さだ。