AI駆動開発が生む技術負債リスク：投資家・DD担当者のための評価フレームワーク

AI コーディングツールの普及で「エンジニアの生産性が10倍になった」という言説が増えています。しかし生産性向上の裏面として見落とされているのが、AI 駆動開発特有の技術負債リスクです。

結論を先に述べます。バイブコーディングを中心とした AI 駆動開発スタイルが生む技術負債は、従来のスタートアップが蓄積してきた負債とは発生メカニズムが根本的に異なります。「誰もコードの設計意図を理解していない」「テスト不在が当初から組み込まれている」「属人化が人ではなくプロンプト履歴に移行している」——この3パターンが複合すると、コードベースはソースコードレビューだけでは評価しきれない状態になります。投資家・M&A担当者が従来の技術DDをそのまま適用しても、リスクの全体像は見えません。

バイブコーディングとは何か：定義と実態

バイブコーディング は、2025年にAI研究者のAndrej Karpathyが提唱した開発スタイルを指す言葉です。LLM（大規模言語モデル）が生成したコードを、深く理解・検証せずに採用しながら開発を進める手法を指します。Karpathyは「コードをほぼ見ない。エラーが出たらそのままLLMに貼って直してもらう」という開発体験をそう呼びました。

その後「バイブコーディング」は広義に使われるようになり、現在は以下の2つの意味合いで混在しています。

狭義（Karpathy的定義）: LLM との対話でプロトタイプを超高速で立ち上げる探索的開発スタイル。コードの細部を把握せず、動いたら次に進む。
広義（業界での用法）: GitHub Copilot・Cursor・Claude Code などのAIコーディングアシスタントを多用しながら開発する手法全般。コード生成の比重が高く、エンジニアがレビュアー的役割に変化している状態。

投資・DD文脈で重要なのは、スタートアップがどちらの意味でAI駆動開発を行っているかを把握することです。狭義のバイブコーディングが本番プロダクトの中核コードに使われている場合、リスクプロファイルが大きく変わります。

図1：バイブコーディングの類型と技術負債リスクの差異

AI駆動開発特有の技術負債パターン

従来の技術負債の発生メカニズムは「速度優先のトレードオフ」「知識・経験の不足」「環境変化への追随遅れ」の3分類で整理できます（「技術負債」の正体とスタートアップで問題になるパターン参照）。AI駆動開発はこれらに加えて、固有の負債パターンを生みます。

パターン1：設計意図の空洞化

従来の技術負債では「コードを書いた人がいる」という前提がありました。設計が悪くても、当時の意図を持った人間が存在し、ヒアリングやドキュメントから背景を復元できる可能性があります。

バイブコーディングが生む負債の本質的な問題は、コードを「書いた人」がいないことです。LLMが生成したコードをそのまま採用した場合、誰もそのコードの設計意図を説明できません。「なぜこの設計か」「他の選択肢とのトレードオフは何か」という問いへの答えが、プロンプト履歴の中にしか存在しない——あるいは、プロンプト履歴すら残っていないケースがあります。

設計意図の空洞化が進むと、後続の開発者は「動いているコードの意味が分からないが、触ると壊れるかもしれない」という状態に陥ります。これは従来の属人化より深刻で、「誰かに聞く」という選択肢がそもそもない状態です。

パターン2：テスト不在の定着

AIコーディングツールはコード生成は得意ですが、テスト設計は「言われなければ書かない」挙動をとることが多いです。バイブコーディングでは「まず動かす」が優先されるため、テストの作成が後回しになります。

問題はここからです。従来の開発では「テストを書く時間がなかった」という経緯を開発者が認識しており、負債として意識されます。しかしAI駆動開発では「AIが書いたコードだから大丈夫」という（根拠のない）安心感が生まれやすく、テスト不在が問題として認識されないまま定着するケースがあります。

テストのないコードベースにさらにAIが変更を加え続けると、回帰バグが蓄積しても検出できない状態が続きます。チームの規模が小さいうちは「なんとなく動いている」で乗り越えられても、スケール時に一気に問題が顕在化します。

パターン3：プロンプト依存の属人化

従来の属人化は「特定のエンジニアしか分からないコード」という形を取りました。そのエンジニアが在籍していれば、知識を引き出せます。

AI駆動開発では属人化の形が変わります。「このプロダクトは誰が作ったか」ではなく「どんなプロンプトで作ったか」が重要な情報になりますが、プロンプト履歴が組織的に管理されているケースはまれです。

担当者が転職すると、後任者には「ChatGPTで作りました」という情報しか残らないことがあります。コードの振る舞いを再現するためのプロンプトも、コンテキストも、どのモデルを使ったかも不明——という状態がAI時代の新しい属人化リスクです。

パターン4：セキュリティホールの見えにくさ

LLMはセキュリティ上の考慮が不十分なコードを生成することがあります。SQLインジェクション対策の欠如、不適切な認証実装、ハードコードされた認証情報——これらは従来のコードレビューで発見できますが、バイブコーディング的な開発ではレビューが省略されやすいです。

さらに問題なのは、生成されたコードが一見正しく見えることです。LLMが生成するコードは構文的に正しく、変数名も整っており、コメントも付いています。表面的な品質が高いため、人間のレビュアーが「大丈夫そう」と判断しやすい。しかし実際のセキュリティ設計の妥当性は、コードの見た目とは別の問題です。

図2：AI駆動開発固有の技術負債4パターン

レビュー不足・テスト不足・属人化の連鎖

上記4パターンは単独で発生するのではなく、連鎖して悪化します。典型的な劣化サイクルは以下の通りです。

初期フェーズ: バイブコーディングで高速にプロトタイプを構築。テストなし、レビュー省略。
拡張フェーズ: 動いているコードの上にAIで機能を追加。誰もコード全体を把握していないが、追加自体はできる。
チーム拡大時: 新メンバーが加わっても「コードの全体設計を知っている人がいない」ため、引き継ぎが機能しない。
問題顕在化: バグが出ても根本原因を追えない。修正するとほかが壊れる。テストがないので安全に変更できる範囲が分からない。

この連鎖が始まると、後から健全化するコストは指数的に増加します。設計意図の復元・テストの後付け・セキュリティ監査——それぞれに大きなリソースが必要であり、並行して事業開発を進めながら実行するのは困難です。

技術DDの全体像と7つの評価軸では「コードベースの評価は結果ではなくプロセスを見る」という原則を示していますが、AI駆動開発の評価はまさにこのプロセスの確認が核心になります。

健全なAI駆動開発のガードレール

バイブコーディングやAI駆動開発が「悪い」という話ではありません。問題はガードレールなしで本番プロダクトに適用することです。以下の条件が整った組織では、AIコーディングツールは真に生産性を高めます。

ガードレール1：AIを「下書き生成」として位置づける

AIが生成したコードは「提案」として扱い、エンジニアが意図を理解した上で採用する文化が必要です。「AIが書いたから正しい」ではなく「AIの提案をエンジニアが評価して採用した」という責任の所在が明確な状態が基準です。

コードレビューでは「この実装を選んだ理由を説明できるか」を問うことで、AI生成コードの盲目的採用を防ぐことができます。

ガードレール2：テスト先行（またはテスト同時）の徹底

AI駆動開発でもTDD（テスト駆動開発）の思想は有効です。「AIにテストを書かせてから、実装をAIに書かせる」というフローにすることで、テスト不在の定着を防ぎます。

AIはテストコードの生成も得意であり、「この関数のユニットテストを書いて」という指示でテストを先行させることは十分に実践可能です。

ガードレール3：プロンプトとコンテキストの記録

プロンプト依存の属人化リスクへの対処として、重要な設計決定に関わったプロンプトやAIとの対話ログを組織資産として管理することが有効です。

GitHub Issues・PR の説明・ADR（Architecture Decision Records）の中に「なぜAIのこの提案を採用したか」を記録するだけでも、コンテキストの損失を大幅に減らせます。

ガードレール4：セキュリティの専門的レビュー

AI生成コードのセキュリティレビューは、通常のレビューより高い専門性が求められます。生成コードが「見た目として正しい」ため表面的なレビューでは問題を見落としやすく、認証・入力バリデーション・シークレット管理などの領域は別途専門家の確認が必要です。

ガードレール5：エージェントハーネスの導入

上述の4つのガードレールを組織の文化・慣習として定着させるより根本的なアプローチが、エージェントハーネスの導入です。エージェントハーネスとは、AIエージェントが動作するためのルール・権限・フック（事前後処理）・スキルを体系化した実行環境のことです。

具体的には以下の要素で構成されます。

コンテキストファイル（CLAUDE.md / AGENTS.md）: リポジトリごとにAIエージェントが守るべきルール・設計方針・禁止事項を記述する。AIはコードを書く前にこのファイルを参照し、プロジェクト固有の制約の中で動作する。
フック（Pre/PostToolUse）: AIがコード変更を行う前後に自動で走るスクリプト。「変更後は必ずテストを実行する」「特定のファイルへの書き込みは人間の確認を必要とする」といったゲートを自動化できる。
スキル定義: 繰り返し行う作業（コードレビューの観点・デプロイ前検査・品質チェックなど）をプロンプトとして定型化し、AIが毎回同じ品質基準で実行できるようにする。
権限制御: AIが操作できるリポジトリ・ブランチ・コマンドの範囲を明示的に定義し、意図しない変更の適用範囲を最小化する。

エージェントハーネスが整備されていると、バイブコーディング的な開発スタイルを採用しても「ガードレールがコードに焼き込まれている」状態になります。個人の注意力や文化に依存するガードレール1〜4とは異なり、仕組みとして強制される点が本質的な違いです。

投資・DD文脈では、対象企業が CLAUDE.md や AGENTS.md のようなエージェント向け設定ファイルを持っているか、CIと連動したフックが存在するかを確認することで、AI駆動開発のガバナンス成熟度を短時間で評価できます。これらのファイルは通常 Git リポジトリに含まれているため、リポジトリへのアクセスがあれば直接確認できます。

投資家・DD担当者が確認すべき3つの問い

技術DDでAI駆動開発のリスクを評価するとき、以下の3つの問いが核心になります。

問い1：「このコードの設計を誰が説明できますか？」

エンジニアリーダーやCTOに問います。コアとなるアーキテクチャや重要なビジネスロジックの設計について、「なぜこうしたか」を具体的に語れる人物が存在するかを確認します。

「AIが作ったので……」という回答が返ってくる部分が多いほど、設計意図の空洞化が進んでいます。具体的な設計判断の背景を語れないコードベースは、変更コストが見積もれない資産です。

問い2：「AIが生成したコードのレビュープロセスはどうなっていますか？」

コードレビューの運用を確認します。PRにおいてAI生成コードと手書きコードの扱いに差があるか、AIコーディングツールの利用ポリシーがあるか、テストの有無をレビュー基準に含めているかを問います。

「みんな好きなように使っています」という回答は、ガードレールが存在しないことを意味します。利用ポリシーが明文化されていなくても、暗黙のルールとして機能している場合はあるため、具体的な事例を聞くことが有効です。

問い3：「本番コードのうち、テストがないコードの割合はどのくらいですか？」

テストカバレッジの確認です。数値が分からない場合も多いため、「コアの決済・認証まわりにテストはありますか？」という具体的な問いに変換することが有効です。

AI駆動開発を行っている組織では、この問いへの答えが「よく分からない」になるケースが多く、そのこと自体がリスクシグナルです。テストの有無を把握していないということは、変更可能な領域と変更リスクの高い領域の区別がついていないことを意味します。

図3：AI駆動開発を評価する3つの問い

評価結果をどう投資判断に使うか

AI駆動開発を行っているスタートアップが「NG」というわけではありません。重要なのは、AIをガードレール付きで使っているか、リスクを認識した上で管理しているかです。

問題の低いケース: AIを補助ツールとして位置づけ、設計はエンジニアが判断し、レビューとテストが機能している組織。AI活用による開発速度の向上がある一方で、従来の開発品質基準は維持されている。

要注意ケース: AI生成コードへのレビューが形骸化しており、テストがほとんど存在しない。ただし、チームが問題を認識しており、改善ロードマップがある場合は条件交渉の材料として扱える。

高リスクケース: 設計意図を語れる人がいない、テストが皆無、プロンプト管理も存在しない、かつそのことを問題と認識していない。このような状態では、技術資産の価値評価そのものが困難になります。

LLMをプロダクトに組み込むスタートアップの評価論点はAI時代の技術DDは何が変わるかでも整理しています。バイブコーディングリスクはそこで述べたプロダクト組み込みのリスクとは別の問題であり、開発プロセス側のリスクとして独立して評価する必要があります。

まとめ

バイブコーディング / AI駆動開発が生む技術負債は、以下の特性を持ちます。

特性	従来の技術負債	AI駆動開発由来の負債
設計意図の所在	開発者の頭の中	不在（またはプロンプト履歴）
テスト不在の認識	「やるべきだったが時間がなかった」	「AIが書いたから問題ない」
属人化の形	人への依存	プロンプト・ツール・モデルへの依存
見た目の品質	低いことが多い	高いため見落としやすい

DD担当者・投資家がこれらのリスクを評価するためには、従来の「コードを読む」「テストカバレッジを確認する」に加えて、「設計判断のプロセスを確認する」視点が必要です。具体的には、先述した3つの問い——設計意図の語り手・レビュープロセスの有無・テストの実態——を軸に評価することで、AI時代の技術負債リスクの実態が見えてきます。

技術負債の分類と評価フレームワークの詳細は「技術負債」の正体とスタートアップで問題になるパターンを参照ください。また、技術DDの全体的な評価軸については技術デューデリジェンスの全体像と7つの評価軸でまとめています。

スタートアップの技術評価・技術DDの伴走支援についてはTiedPro 投資家向けサービス、またはお気軽にお問い合わせください。

よくある質問

Q. バイブコーディングを禁止すれば問題は解決しますか？

禁止は現実的でなく、かつ必要でもありません。問題はバイブコーディングそのものではなく、ガードレールのない採用です。AI生成コードへのレビュー義務付け・テスト基準の設定・設計判断の記録という3点を整備することで、AI駆動開発の生産性を維持しながらリスクを管理できます。

Q. AI駆動開発のリスクはコードレビューで発見できますか？

部分的には可能ですが、限界があります。設計意図の空洞化やプロンプト依存の属人化は、コードを読んでも顕在化しません。開発プロセス・チームの理解度・ドキュメントの状態を合わせて評価することが必要です。

Q. 投資後にAI駆動開発由来の負債を修正するにはどのくらいのコストがかかりますか？

状況によりますが、「設計を理解している人がいない」状態からの再設計は特にコストが高くなります。コードベース全体の理解に数週間、テスト整備に数ヶ月、セキュリティ監査と改修に別途期間が必要なケースがあります。投資前にリスクレベルを把握し、PMI計画に組み込むことを推奨します。