技術DDのレッドフラッグ一覧：撤退・条件付き・許容の三分類で判断する
技術デューデリジェンス（技術DD）で最も難しいのは、所見を「見つけること」ではなく「見つけた所見をどう判断するか」です。同じ「自動テストがほとんど存在しない」という所見でも、ある案件では致命的な撤退理由になり、別の案件では許容範囲の軽微な課題にとどまります。本稿では、技術DDの所見を 撤退（Deal Breaker）・条件付き（Conditional）・許容（Acceptable） の三分類で仕分けるための判断フレームワークを、領域別のレッドフラッグ一覧・組み合わせ効果・投資ステージ別の重み付けとともに解説します。技術DDの全体像は技術デューデリジェンスの全体像と7つの評価軸、確認すべき項目の網羅的なチェックリストは投資家が実施すべき技術デューデリジェンスの全項目を参照してください。
レッドフラッグを「撤退・条件付き・許容」で仕分ける理由
技術DDのレポートには、しばしば発見した課題が列挙されるだけで終わってしまうものがあります。しかし投資委員会やディール担当者が本当に必要としているのは、「この所見がディールの継続可否にどう影響するか」という判断です。所見を放置せず、次の三分類のいずれかに位置づけることで、レポートが意思決定に直結する道具になります。
- 撤退（Deal Breaker）：是正が技術的・時間的・法的に不可能、または是正コストが取引価値を上回る。ディールを進める前提条件を崩す所見
- 条件付き（Conditional）：是正可能だが、クロージング前提条件・表明保証・エスクロー・是正計画のいずれかで契約に反映すべき所見
- 許容（Acceptable）：事業モデル・投資ステージ・成長計画を踏まえると、現時点でのディール継続に支障がない所見
この三分類のポイントは、同じ所見でも案件によって分類が変わるという前提に立つことです。分類の基準は所見そのものの深刻度ではなく、「その企業のコンテキストにおいて是正可能かどうか」にあります。
領域別レッドフラッグ一覧：三分類の目安
以下は、技術DDで頻出する所見を領域別に三分類した一覧です。実際の判断では個社の事業モデル・投資ステージ・保有データの機微性によって分類が変動するため、あくまで一次仕分けの目安として使ってください。
| 領域 | 撤退級の所見 | 条件付きの所見 | 許容範囲の所見 |
|---|---|---|---|
| コード・アーキテクチャ | コア機能の大部分がAI生成またはコピペで、誰も設計意図を説明できず、かつ説明できる人材が離脱予定 | モノリスでスケール限界が近いが、リプレース計画と工数感を経営陣が具体的に把握している | 自動テストのカバレッジが低いが、対象が変更頻度の低い周辺機能に限定される |
| インフラ・運用 | 本番環境のシークレットがGit履歴に平文で残り、長期間ローテーションされていない | 単一リージョン・単一SaaS依存だが、移行コストと移行計画が明文化されている | 特定クラウドへのロックインはあるが、移行コストが事業規模に対して小さい |
| セキュリティ | 規制対象データ（医療・金融等）を扱いながら暗号化・監査ログ・脆弱性管理のいずれも未整備 | ペネトレーションテスト未実施だが、実施計画とスケジュールが具体化している | 依存ライブラリに中程度の脆弱性があるが、放置期間が短くパッチ計画がある |
| 組織・人材 | コアロジックを唯一理解する創業エンジニアが、買収後の継続関与を拒否し移管計画もない | キーパーソン依存が強いが、一定期間のリテンション契約とドキュメント化計画がある | コミットの集中度は高いが、コードベース自体が小規模で引き継ぎが容易 |
| IP・法務 | コア機能にGPL系ライセンスのOSSが分離不可能な形で組み込まれ、ソースコード開示義務のリスクが高い | OSSライセンス管理台帳が存在しないが、監査の結果重大な汚染は見つからず整備計画で対応可能 | 特許出願は薄いが、競合優位の源泉が技術以外（データ・営業実行力）にある |
撤退級の共通点：「是正の主体か手段が失われている」
撤退級に分類される所見に共通するのは、深刻度そのものよりも「是正しようにも、それを担う人材・時間・法的手段のいずれかが失われている」という構造です。技術負債は多くの場合、時間とコストをかければ返済可能ですが、キーパーソンの離脱や法的な既成事実（ライセンス汚染の既成事実化）が絡むと、是正の選択肢自体が消滅します。技術負債そのものの評価軸は「技術負債」の正体とスタートアップで問題になるパターンで詳しく整理しています。
条件付きの実務上の意味：契約への落とし込みが前提
条件付きに分類した所見は、DDレポートに書いて終わりにせず、契約条項として反映して初めて機能します。クロージング前提条件（CP）として是正を求めるか、表明保証で担保するか、エスクローで金銭的にヘッジするか、クロージング後の是正計画としてマイルストーン管理するか——所見の性質によって適切な手段は異なります。
単独なら許容、組み合わさると撤退になるパターン
三分類の運用で最も見落とされやすいのが、個々の所見は許容範囲でも、組み合わさると撤退級に増幅するケースです。技術DDのレポートが所見をリスト形式で並べるだけだと、この相互作用が見えなくなります。
- テスト不在（単独では許容）＋ キーパーソン依存（単独では条件付き）＋ 設計ドキュメント皆無：個別には対処可能でも、組み合わさると「コードの正しさを検証する手段」と「コードの意図を知る人間」の両方が同時に失われる状態になり、離脱が起きた瞬間に開発が事実上停止します。単独評価では条件付きの2件でも、組み合わせでは撤退級に引き上げるべきです。
- OSSライセンス管理台帳の不在（単独では条件付き）＋ 海外規制産業への展開計画（単独では許容）：国内向けの現状では軽微でも、海外展開時にライセンス監査を求められる商習慣がある場合、台帳不在が展開計画そのものを遅延させるリスクに変わります。
- 単一リージョン依存（単独では許容）＋ SLA未定義（単独では許容）＋ ミッションクリティカルな契約基盤としての位置づけ：可用性要求が低い事業では両方とも許容範囲ですが、買収側が当該プロダクトを自社の基幹インフラに組み込む前提のディールでは、組み合わせが事業継続計画（BCP）上の撤退級リスクになります。
実務上は、所見をマトリクスで並べ、「同じ人材・同じ工程・同じ顧客セグメントに影響する所見同士」をグルーピングして相互作用を確認する工程を、個別評価の後に必ず挟むことを推奨します。
レッドフラッグの重みは投資ステージで変わる
同じ所見でも、投資ステージによって重みは大きく変わります。
- シード・アーリーステージ：プロダクトの方向転換が前提のため、コード品質・アーキテクチャの完成度に関する所見は許容範囲が広くなります。一方で、個人情報の取り扱いや資金の使途に関わる法務・セキュリティの根本的欠如は、ステージに関わらず撤退級として扱うべき絶対的な下限線です。
- シリーズB〜グロースステージ：事業計画通りのスケールが投資テーゼの中核になるため、スケーラビリティの構造的欠陥・組織のキーパーソン依存は重みが跳ね上がります。プロダクトの複雑性が増している分、外部委託コードの構造的負債（引き継げる人材がいない状態）も条件付きから撤退級に近づきやすくなります。
- バイアウト・事業会社によるM&A（PMI前提）：買収後に既存の技術資産へ統合することが前提になるため、法務リスク（IP・ライセンス）と組織の継続性（キーパーソンの雇用継続）の重みが最大化します。表明保証・エスクロー等の契約的ヘッジ手段が使えるバイアウト特有の事情もあり、条件付きに分類できる範囲がVC投資よりも広い一方、統合コストの見積もり誤りは即座に撤退級の判断材料になります。
このステージ依存性を踏まえると、技術DDチームは「一般的なチェックリスト」だけでなく、案件ごとの投資テーゼ（何を前提に成長シナリオを描いているか）を事前にヒアリングした上で重み付けを調整する必要があります。
まとめ
技術DDのレッドフラッグは、リストアップした時点では単なる「見つかった問題」でしかありません。それを「撤退・条件付き・許容」の三分類に落とし込み、さらに組み合わせ効果と投資ステージによる重み付けを加えることで、初めて投資委員会が使える意思決定材料になります。重要なのは、所見そのものの深刻度ではなく、その企業のコンテキストにおいて是正の主体・手段・時間が残されているかどうかです。
投資後に顕在化しやすい技術リスクのパターンは投資後に発覚しがちな技術リスク10選、技術DDの評価軸全体は技術デューデリジェンスの全体像と7つの評価軸を参照してください。個別案件でのレッドフラッグの分類・重み付けについて第三者の視点が必要な場合は、TiedPro 投資家向けサービスまたはお問い合わせからご相談ください。