この記事で分かること
結論：Technology DDとは「ITシステムの隠れた将来投資」をクロージング前に発見し、金額化する手続き
Technology DD（テクノロジーDD、テックDD）とは、PEファンドが買収対象企業のソフトウェア・ITシステムを、コードベース・アーキテクチャ・セキュリティ・開発組織・ライセンスコンプライアンスの5軸で検証し、投資後に必要になる追加投資やリスクをクロージング前に洗い出すITデューデリジェンスの一分野です。財務DDがP&Lと貸借対照表の実力を検証するのに対し、Technology DDが検証するのは「事業計画に織り込まれていない、システム側の将来キャッシュアウト」です。老朽化した基幹システムの刷新費用、脆弱性対応の遅れ、オープンソースライセンスの違反リスクは、いずれも決算書には表れませんが、投資後に確実にキャッシュを要求してきます。
対象はソフトウェア企業に限りません。製造業の生産管理システム、金融機関のコアバンキング、小売業のPOS・在庫管理など、IT依存度が高い事業であれば業種を問わず検討対象になります。本記事は買収規模（バイアウト）の中堅・中小IT企業やIT依存度の高い一般事業会社を主な対象に、技術DDの実務を扱います。なお、AI企業のVC・グロース投資DDは対象がアーリー〜グロースステージのスタートアップで、単位経済性や技術的優位性そのものが投資テーゼの検証対象になる点で本記事とは目的が異なります。本記事が扱うのは、すでに事業として稼働しているITシステムの運用リスクとしての技術負債であり、成長ステージのスタートアップにおける技術の競争優位性評価とは論点が別だと理解しておくと整理しやすくなります。
発見事項の翻訳先（3方向）
① 価格控除・特別補償（金額・発生とも確度が高いリスク）
② 将来Capex（事業計画のCapex前提を修正しEV評価に反映）
③ 統合計画（PMI・カーブアウトのTSA・システム統合コストとして実行段階で管理）
なぜ必要か：実施体制とタイミングの制約
Technology DDが独立した専門DDとして扱われる理由は単純で、財務DDや法務DDの担当者には、コードベースの品質やクラウドインフラのコスト構造を評価する専門性がないためです。中堅PEファンドの多くは社内に専任のテック人材を置いていないため、外部の技術DDベンダー（システムインテグレーターの専門部隊やIT監査系のブティックファーム）を起用するのが一般的です。IT・ソフトウェア投資に積極的なPEファンドほど、こうした技術DDベンダーとの継続的な関係を持っている傾向があります。
実施のタイミングには構造的な制約があります。VDR公開から一次入札・二次入札を経てクロージングに至るプロセスの中で、技術DDに割り当てられる期間は通常2〜4週間程度です。この短期間で、ソースコードレビュー、開発責任者へのインタビュー、インフラ構成のドキュメントレビュー、可能であればステージング環境へのアクセスを組み合わせて評価を行います。委託開発の比重が高い企業では、委託先が保有するソースコードの開示範囲が契約上制限されている場合があり、DD開始前にこの制約を確認しておく必要があります。
範囲設定は重要性基準で絞り込みます。すべてのシステムを均等に見るのではなく、事業のトップラインを直接支える基幹システムと、更新投資額が大きくなりそうなレガシー資産を優先します。対象システムの棚卸（自社開発かパッケージかSaaSか、オンプレミスかクラウドか、保守ベンダーとの契約形態）を最初のステップとして行い、この棚卸結果をもとに評価の優先順位を決めます。発見事項は最終的に他のDD領域（財務・法務・税務）の指摘事項と合わせてDD横断の赤旗優先順位付けのプロセスに載せ、投資委員会向けの論点整理に統合されます。
評価5軸の全体像
以下は5つの評価軸の主な確認項目・典型的な赤旗・発見時の翻訳先の目安を整理したものです。次節以降で各軸を掘り下げます。
| 評価軸 | 主な確認項目 | 典型的な赤旗 | 翻訳先の目安 |
|---|---|---|---|
| ①コードベース・技術的負債 | 静的解析による複雑度・重複率、テストカバレッジ、CI/CDの成熟度、言語・フレームワークのサポート状況 | サポート終了（EOL）言語の継続使用、テスト自動化ゼロ、属人的なデプロイ手順 | 将来Capex |
| ②アーキテクチャ | モノリシック／マイクロサービス構成、マルチテナント設計、クラウド従量課金コストの弾力性 | 事業計画の成長率にインフラの限界が追いつかない、単一障害点の存在 | 将来Capex |
| ③セキュリティ・インシデント履歴 | 脆弱性対応リードタイム、ペネトレーションテスト実施歴、第三者認証の取得状況、過去のインシデント開示 | 重大脆弱性の放置、未開示のインシデント、認証の未取得 | 将来Capex／特別補償 |
| ④開発組織 | キーマン依存度、外注比率、ドキュメンテーション、採用力・離職率 | アーキテクチャ判断が特定個人に集中、ドキュメント不在 | 統合計画（リテンション） |
| ⑤ライセンスコンプライアンス | OSSライセンスの棚卸（SBOM）、コピーレフト条項の混入、商用ソフトウェアの契約条件遵守 | コピーレフトライブラリの商用組込、ライセンス契約の超過利用 | 価格控除・特別補償 |
アーキテクチャのスケーラビリティ：成長計画とインフラの限界を突き合わせる
アーキテクチャ評価の核心は「今動いているかどうか」ではなく「事業計画通りに成長したときに耐えられるか」です。モノリシック構成のシステムは初期の開発速度は速い一方、機能追加やスケールアウトのたびに変更範囲が全体へ波及しやすく、成長局面で開発速度そのものがボトルネックになりがちです。SaaS企業であれば、顧客ごとにデータベースを分離するシングルテナント構成か、共有インフラの上で論理分離するマルチテナント構成かによって、顧客数増加時のインフラコストの伸び方が大きく変わります。SaaS企業の収益モデリングで置く成長シナリオの顧客数・取扱高の前提と、アーキテクチャが物理的に耐えられる上限とを突き合わせる作業がここでの中心になります。
クラウドインフラのコスト構造も併せて確認します。従量課金型のクラウドサービスは、設計次第で売上の伸びに対してインフラコストが線形以上に増える「非効率なスケール」を起こすことがあります。過去のインシデント記録や負荷試験の結果があれば、ボトルネックが具体的にどこにあるか（データベース、外部API連携、バッチ処理）を特定でき、更新投資の優先順位づけに使えます。ボトルネックが特定の1コンポーネントに集中している場合は、全面刷新ではなく部分的な改修で対応できる可能性があり、将来Capexの見積り精度に直結します。
セキュリティとインシデント履歴
セキュリティ評価では、個別の脆弱性の有無そのものよりも脆弱性管理のプロセスが機能しているかを見ます。深刻度の高い脆弱性が発見されてから修正が本番環境に反映されるまでのリードタイム、依存ライブラリの更新頻度、外部からのペネトレーションテストの実施履歴が代表的な確認項目です。世界的に参照されるウェブアプリケーションの脆弱性分類であるOWASP Top 10や、国内ではIPAの脆弱性対策情報が、DDベンダーが用いる評価軸の共通言語になっています。
第三者認証（ISMS・SOC2等）の取得状況は、それ自体が安全性を保証するものではありませんが、組織としてセキュリティ体制を運用管理できているかの代理指標として使われます。より重視すべきは、過去のセキュリティインシデントが売り手から開示されているかどうかです。個人情報保護法上の通知義務が生じる規模の漏えいがあれば、法務DDと連携して開示状況・対応履歴を確認します。未開示のインシデントが後から判明した場合、表明保証違反として補償請求の対象になり得ます。セキュリティ体制の是正投資（監視基盤の導入、脆弱性対応の外部委託契約）は多くの場合、確度の高い将来Capexとして事業計画に織り込みます。
開発組織の評価：キーマン依存と実行力
どれだけコードの品質が高くても、それを保守・拡張できる組織がなければ資産価値は維持できません。開発組織の評価では、アーキテクチャ判断や重要な意思決定が特定の個人（多くはCTOや創業エンジニア）に集中していないか、その人物が離脱した場合に事業継続にどの程度の影響が出るかを確認します。ドキュメンテーションの整備状況は、キーマン依存度を測る簡便な代理指標になります。仕様書もコメントもなく特定の人物の頭の中にだけ設計思想がある状態は、その人物が抜けた瞬間に開発速度が大きく落ちるリスクを意味します。
外注比率も確認対象です。開発の大部分を外部委託に依存している場合、委託先との契約継続性・知的財産権の帰属・ソースコードの完全な引き渡しが可能かを確認する必要があります。開発組織に関する発見事項は、価格に直接反映するというより、投資後の統合計画（リテンション設計・採用計画・ドキュメンテーション整備）のインプットとして扱うのが実務上の型です。キーマンの残留・交代・補強という経営体制全体の設計は、開発組織に限らない論点として扱われます。
ライセンスコンプライアンス：OSSとSaaS契約のCoC条項
ライセンスコンプライアンスは見落とされやすいものの、発見された場合の影響が価格に直結しやすい領域です。オープンソースソフトウェア（OSS）のライセンスには、MITやApacheのような利用制約の緩い「パーミッシブ型」と、GPLのように派生物のソースコード開示を義務づける「コピーレフト型」があります。商用配布するソフトウェアにコピーレフト型のライブラリが組み込まれている場合、理論上はそのソフトウェア自体のソース開示義務が発生し得るため、置換や再実装が必要になります。この棚卸を体系的に行うための業界標準がSBOM（ソフトウェア部品表）で、国際規格として認定されたSPDXのような形式が広く採用されています。対象会社がSBOMを保有していない場合、DDベンダーによるソースコードスキャンで代替する必要があり、その分コストと時間がかかります。
もう一つの論点は商用ソフトウェア・SaaSベンダーとの契約条件です。契約上のライセンスシート数やAPIコール数の上限を超過して利用している事例は珍しくなく、発覚した場合はベンダーからの遡及請求リスクを伴います。また、自社が買収されることでベンダー側のチェンジ・オブ・コントロール（CoC）条項に抵触し、契約の再締結やライセンス費用の再交渉が必要になるケースもあります。加えて、自社開発ソフトウェアの開発費用を会計上どこまで資産計上（資本化）しているかも財務DDとの接点になります。研究開発費とソフトウェアの資産計上の方針が積極的すぎる場合、EBITDAや資産が実態より良く見えている可能性があり、技術DDと財務DDの双方でクロスチェックする価値があります。
カーブアウト案件：スタンドアロンコストとTSA
事業会社の一部門を切り出すカーブアウト案件では、対象事業が親会社の共通基幹システム（ERP、認証基盤、社内ネットワーク、データセンター）に相乗りしていることが通常です。切り出し後、対象事業は自前のシステムを新たに構築するか、当面は親会社のシステムを一定期間借り続けるかを選ぶ必要があり、後者の橋渡しの仕組みがTSA（トランジション・サービス・アグリーメント）です。技術DDでは、対象事業がどのシステムをどの程度の割合で親会社と共有しているかを棚卸し、切り離しに要する期間と投資額を見積ります。
親会社側に残ってしまい削減しきれない共通費用はスタンドアロンコスト（座礁コスト）と呼ばれ、TSA期間終了後も対象事業の収益性に影響を与え続けることがあります。技術DDの段階で切り離しに必要なシステム投資額を見積もっておかないと、TSA期間が終わった時点で想定外の追加投資が必要になり、投資後のバリューアップ計画そのものが狂う原因になります。カーブアウト案件の技術DDは、単独では読み切れない部分が多いため、財務・法務のカーブアウト論点と合わせて検討する必要があります。
発見事項の翻訳：設例で見る価格・Capex・統合計画への反映
以下は説明用の仮設例です。実在の案件ではありません。自社開発の業務系SaaSを主力事業とする中堅IT企業（非上場）を想定し、EBITDA 400百万円に対してEV/EBITDA 8.0倍、すなわちEV 3,200百万円で価格の入口が合意されたところから始めます。
技術DDの発見事項
技術DDベンダーの報告書では、主に4件の論点が指摘されました。第一に、基幹SaaSのバックエンドがサポート終了間近の言語バージョンで構築されたモノリシック構成であり、段階的な刷新に24か月・180百万円の投資が必要と見積もられました。第二に、自動テストカバレッジが35%にとどまりCI/CDも未整備であることから、品質基盤への投資として40百万円が見積もられました。第三に、脆弱性対応の平均リードタイムが90日と長く、ペネトレーションテストも未実施であったため、監視基盤導入と体制整備に60百万円が見積もられました。第四に、SBOMによる棚卸の結果、商用配布コードにコピーレフト型ライブラリが組み込まれていることが判明し、置換に15百万円が必要と見積もられました。これら4件はいずれも金額・発生の確度が高く、事業計画のCapex前提を修正する形で扱うことになりました。
将来Capexとしての技術的負債合計
180（基幹システム刷新）＋ 40（品質基盤）＋ 60（セキュリティ体制）＋ 15（OSSライセンス是正）＝ 295百万円
これとは別に、過去の商用ミドルウェアの契約シート数超過利用が発覚しました。ベンダーからの遡及請求リスクはレンジ60〜120百万円、中央値90百万円と見積もられましたが、これはすでに発生している可能性のある偶発債務であり、将来投資とは性質が異なります。金額の幅が大きく発生時期も読めないため、価格控除ではなく特別補償で処理し、請求権の存続期間と上限額（キャップ）を区切って売り手に負担させる方向で整理しました。実効性を担保するため、対価の一部を一定期間エスクローに留保することも合わせて検討されます。
EVへの反映
技術的負債295百万円は、買い手の事業計画において向こう2年間のCapexを押し上げる前提として織り込まれます。DCFやLBOモデル上のフリーキャッシュフローがその分圧縮されるため、買い手はEVの入口をその分引き下げるよう主張します。ここでは説明のため、割引効果を無視してCapex増分をそのままEVから減額する簡便な計算で示します。
調整後EV
3,200（当初EV）− 295（技術的負債の将来投資額）＝ 2,905百万円
検算：2,905 ÷ 400（EBITDA）＝ 7.26倍（当初8.00倍からの調整幅は0.74倍）
ライセンス超過利用の遡及リスク90百万円（中央値）はEVの調整には含めず、特別補償・エスクローという契約上の受け皿で別途手当てします。仮にこれもEVから機械的に控除してしまうと、発生するかどうか分からないリスクの分だけ売り手の手取りを不可逆に減らすことになり、金額の確実性に見合わない処理になってしまいます。
統合計画に振り分けられる項目もあります。基幹システム刷新（180百万円）はAdd-on買収が続く場合、買収先システムとの統合コストと合わせて実行段階の計画に組み込まれ、開発組織のリテンション施策や採用計画はPMIの100日プランの初期タスクとして管理されます。カーブアウト案件であれば、システム切り離しのタイムラインはTSA終了期限と連動させる必要があります。発見事項を価格・Capex・統合計画のどこに落とすかを最初から固定しておくことで、DD終盤の交渉が「何を主張しているのか」があいまいなまま感情的にこじれるのを避けられます。なお、より一般的な負債性項目の価格控除・SPA振り分けの枠組みはDebt-like Items完全ガイドを参照してください。
よくある質問（FAQ）
Technology DDはすべての買収案件で必要ですか。
必須ではありません。IT依存度が低く、システムが標準的なパッケージソフトウェアで完結している事業であれば、財務DDや法務DDの範囲内で簡易的に確認する程度で足りることもあります。逆に自社開発システムが事業の中核を担う企業や、カーブアウト案件、システム統合を伴うAdd-on買収では、専門の技術DDを別立てで実施する重要性が高くなります。
技術的負債の金額見積りはどこまで信頼できますか。
短期間のDDで得られる情報は限られるため、見積りには相応の幅があります。実務では単一の金額ではなくレンジで示し、確度の高い項目は将来Capexとして事業計画に反映し、確度の低い項目は投資後の詳細調査（PMI初期のシステム監査）に先送りするという二段構えで扱うのが一般的です。
SaaS企業以外にも技術DDは当てはまりますか。
当てはまります。製造業の生産管理システムや金融機関のコアシステムのように、事業の根幹をITシステムが支えている企業であれば、業種を問わず評価対象になります。評価する具体的なシステムの性質は業種ごとに異なりますが、コードベース・アーキテクチャ・セキュリティ・組織・ライセンスという5軸の考え方自体は共通して使えます。
技術DDベンダーはどのように選べばよいですか。
対象企業が使っている技術スタック（言語・クラウド基盤・業界特有のシステム）に対応した実績があるかを確認します。あわせて、限られたDD期間内でソースコードレビューとインタビューを完了できる体制があるか、報告書が投資委員会向けに金額ベースで整理される形式になっているかも重要な選定基準です。
まとめ
Technology DDは、コードベース・アーキテクチャ・セキュリティ・開発組織・ライセンスコンプライアンスの5軸で、決算書には表れないITシステムの将来キャッシュアウトを洗い出す手続きです。発見事項をそのまま列挙するだけでは投資判断に使えず、金額と発生確度に応じて価格控除・将来Capex・統合計画のいずれかに翻訳して初めて意味を持ちます。カーブアウト案件ではスタンドアロンコストとTSA、Add-on買収ではシステム統合コストという形で、投資後のバリューアップ計画にも直接つながります。技術DDの発見事項は、単発の指摘事項としてではなく、事業計画とLBOモデルのCapex前提を修正する材料として扱うことで初めて価格交渉の武器になります。
出典・参考（2026年8月確認）
- OWASP,「OWASP Top 10」 owasp.org
- 独立行政法人情報処理推進機構（IPA）,「脆弱性対策情報」 ipa.go.jp
- SPDX（Software Package Data Exchange）公式サイト spdx.dev
※本記事は教育目的の一般的な解説であり、法務・税務・投資助言ではありません。設例は理解のための仮設例です。
