この記事の目次
SaaSの買収で、財務や契約の資料がそろったあとに残るのが「このプロダクトは、買ったあとも動かし続けられるのか」という問いです。コードを読み、環境を触り、費用の中身を見る作業が技術DDです。この記事は、何をどこまで調べるか、見つかったものを価格・契約・改修計画のどこに振り分けるかを書きます。
この記事の結論
- 技術DDの目的は、買収後の改修費用と運用の継続性を見積もることです。コードの出来の良し悪しを採点する作業ではありません。
- 調べる対象は、ソースコードとOSS、インフラと復旧、脆弱性とアクセス管理、開発者依存と技術的負債、クラウド費用の5つです。
- 見つかった課題は、価格・契約条項・買収後の改修計画のどれに入れるかを決めて初めて、DDの結果になります。
この記事の対象：SaaS・Webサービスの買収を検討している方と、売却前に技術面の準備をしたいオーナー。
SaaSのM&A全体の見方（主要KPI・価値の源泉・DDの論点）は、SaaSのM&A DATAにまとめています。ハブの「DD」で挙げた「ソースコードの権利とOSS」「インフラの構成・費用・名義」「セキュリティ」「技術的負債」を、調べ方と判断の置き場所まで掘り下げるのがこの記事です。解約率や契約の引き継ぎなど、技術以外のDDの論点には触れません。
技術DDの目的は「いま安全か」より「買収後に誰がいくらで保守を続けられるか」の見積もり
結論： 技術DDで出したいのは、買収後の改修費用と、開発・運用を続けられる体制の見通しです。課題をゼロにする必要はなく、課題の大きさと置き場所を決めることが目的です。
SaaSは、売上が継続して入る前提で価値を見ます（ARRの数え方はSaaS ARR 企業価値で扱っています）。その売上が買収後も残るかどうかは、サービスが止まらず、直し続けられるかに左右されます。技術DDは、その前提を確かめる作業です。
| 避けたい判断 | こうすればOK |
|---|---|
| コードの綺麗さや使っている言語の好みで、良し悪しを決める | 「買収後に誰が直せるか」「直すのにいくらかかりそうか」を基準にする |
| 脆弱性が1件でも見つかったら買収を止める | 見つかった件数ではなく、内容・影響範囲・直す手間で、価格か契約か改修計画に振り分ける |
| 売り手の説明だけで「問題ない」と判断する | 資料と環境の実物で確かめ、確認できなかった項目は「未確認」として残す |
| 技術に詳しい人が一人で全部を見る | コード、インフラ、セキュリティで見る人を分け、結果を1枚の一覧にそろえる |
本記事の整理では、技術DDの確認項目を次の5つに分けます。以降の章はこの順に進みます。なお、この5分類は本記事の整理で、公的な資料が定めたDDの区分ではありません。
| 観点 | 買収後に困る場面 | 主な資料・環境 |
|---|---|---|
| ソースコードとOSS | コードを渡されても権利が不明、再構築できない | リポジトリ、依存関係の一覧、ライセンス一覧 |
| インフラと復旧 | 名義が移せない、障害から戻せない | クラウドのアカウント、構成図、障害記録、バックアップ |
| 脆弱性とアクセス管理 | 買収直後に事故が起き、対応を引き受ける | 診断結果、認証・権限の設定、更新の記録 |
| 開発者依存と技術的負債 | 特定の人がいないと保守できない | 設計書、運用手順、開発履歴、課題一覧 |
| クラウド費用 | 利益率が想定より低い | 請求明細、環境ごとの費用 |
ソースコードとOSSは、権利・所在・再現ビルドの3点で確かめる
結論： コードを見せてもらうだけでは足りません。権利が売り手にあるか、全てが1か所にあるか、買い手の手元でビルドして動かせるか、の3点を確かめます。
| 確認点 | 何を見るか | 確認できないときのリスク |
|---|---|---|
| 権利 | 自社の従業員が書いたコード、外注先・委託先が書いたコードの権利が誰にあるか。契約書の権利の定め | 買収後に、権利を持つ第三者から使用を止められる、または追加の対価を求められる |
| 所在 | 本番で動いているコードが、全てリポジトリに入っているか。社外のサービスや個人のアカウントに置かれたコードがないか | 個人のアカウントが閉じると、コードに触れなくなる |
| OSSライセンス | 使っているOSSの一覧と、ライセンス名、組み込み方 | ライセンスの条件に違反する使い方になっていて、公開や改変の義務が発生する |
| 再現ビルド | 新しい環境で、手順書どおりにビルドして起動できるか | 作った本人の端末でしか動かず、買収後に一から再構築になる |
| 依存の古さ | 使っているライブラリ・フレームワークが、保守の続いているものか | 更新できる人がいない、または更新に大きな手間がかかる |
権利とOSSライセンスは、法的な判断が絡む箇所です。ライセンスの条件の読み方や、外注先との権利の帰属は、弁護士に確認してください。同じ論点を、システム開発会社の譲渡という立場から整理した記事がシステム開発会社 M&A 契約 引継ぎです。ソースコードの著作権や、GitHub・AWSのアカウントの名義移転の考え方が載っています。
再現ビルドは、技術DDの中で最も確かめやすく、結果が分かりやすい項目です。買い手側のエンジニアが、売り手の立ち会いなしに、手順書だけで起動できるかを見ます。売り手にとっては、手順書を先に整えておけば、確認が早く済みます。
インフラは構成・名義・障害履歴・バックアップの「復元できた実績」を見る
結論： 構成図があることより、名義が事業側にあり、障害から戻せた記録とバックアップを復元できた実績があるかが、買収後の安心につながります。
| 確認点 | 何を見るか | 見つかりやすい課題 |
|---|---|---|
| アカウントの名義 | クラウド、ドメイン、決済、メール配信などの契約者が、会社か個人か | 個人名義のままで、移転に手続きが要る |
| 構成の把握 | 構成図があり、実際の環境と一致しているか | 図が古く、本番の全体像を誰も説明できない |
| 障害の履歴 | 過去の障害の日時、原因、復旧にかかった時間、再発防止の記録 | 記録がなく、同じ障害が繰り返されても気づけない |
| バックアップ | 取得の頻度、保管先、復元を試した記録 | 取っているが、復元を一度も試していない |
| 監視と連絡 | 異常に気づく仕組みと、誰に連絡が行くか | 通知先が前任者のまま |
米国標準技術研究所（NIST）のサイバーセキュリティフレームワーク2.0は、サイバーセキュリティの成果を6つの機能（GOVERN、IDENTIFY、PROTECT、DETECT、RESPOND、RECOVER）に分けています。RECOVERは「サイバーセキュリティインシデントの影響を受けた資産と業務が復元される」ことを指します。IDENTIFYには、データ・ハードウェア・ソフトウェア・システムなどの資産と、供給者を理解することが含まれます。本記事では、この6機能を、インフラ確認の見方の参考として使います。資産の一覧がそろっているか（IDENTIFY）、異常に気づけるか（DETECT）、戻せるか（RECOVER）、という順に問いを立てるためです。NISTの文書が、M&Aの技術DDの手順を定めているわけではありません。
経済産業省の「サイバーセキュリティ経営ガイドライン Ver3.0」は、経営者がCISO等に指示すべき10の重要事項のなかに、「事業継続・復旧体制の整備」（指示8）と「サプライチェーン全体の状況把握及び対策」（指示9）を挙げています。買収の場面では、売り手が使っている外部の事業者（クラウド、決済、メール配信など）への依存も、確認の対象に入れると、構成の全体が見えます。ただし、このガイドラインは経営者向けの指針で、買収時の確認項目を定めたものではありません。
脆弱性は「診断の有無」と「見つかったものを直した記録」で見る。診断自体は専門家に任せる
結論： 技術DDの担当者がコードを読んで全ての脆弱性を見つけることはできません。診断を受けた記録があるか、見つかったものをどう直したかの記録があるか、を確かめるのが現実的です。
情報処理推進機構（IPA）の「安全なウェブサイトの作り方」は、ウェブサイトの開発者や運営者に向けて、SQLインジェクション、クロスサイト・スクリプティング、CSRF、セッション管理の不備、アクセス制御や認可制御の欠落など11種類の脆弱性を取り上げ、それぞれについて根本的解決と保険的対策を示しています。改訂第7版（2021年3月31日更新）です。SaaSの場合、これらはログイン後の画面や、顧客ごとのデータの切り分けに直結します。
| 確認点 | 何を見るか | 補足 |
|---|---|---|
| 診断の記録 | 外部の診断を受けた日付、範囲、報告書 | 範囲が一部の画面だけなら、その旨を残す |
| 指摘の対処 | 指摘された項目が直されたか、直さない判断をしたか | 対処の記録がないものは、未対応として扱う |
| 認証と権限 | 管理画面や本番環境へ入れる人の一覧、多要素認証の有無、退職者のアカウントの削除 | 共有アカウントがあれば、誰が使ったか追えるか |
| 顧客データの分離 | 顧客Aが顧客Bのデータを見られない作りか | 権限の設計は、IPAの11種類のうち「アクセス制御や認可制御の欠落」に当たる論点 |
| 更新の運用 | OS・ミドルウェア・ライブラリの更新の頻度と記録 | 更新が止まっているものを一覧にする |
IPAの「情報セキュリティ10大脅威 2026」（2026年1月29日公表）の組織向けの脅威では、2位が「サプライチェーンや委託先を狙った攻撃」、4位が「システムの脆弱性を悪用した攻撃」です。順位は年ごとに変わるため、確認日（2026-10-18）時点で公表されている版の順位として読んでください。本記事の整理では、売り手が使っているライブラリや外部サービスの更新状況も、買収後に買い手が引き継ぐリスクとして確認の対象に入れます。
診断は、買い手が自分でするより、専門の事業者に依頼するほうが確実です。ただし、買収前の診断は、売り手の環境に負荷をかけたり、売り手の承諾が要ったりします。実施の可否、範囲、費用の負担は、秘密保持契約や基本合意の段階で取り決めます。個別の法的な扱いは弁護士に確認してください。
| 避けたい判断 | こうすればOK |
|---|---|
| 売り手が「診断は問題なかった」と言ったので、報告書は見ない | 報告書の日付と範囲を見て、現在のコードと環境に当てはまるかを確かめる |
| 買い手が売り手の本番環境に無断で脆弱性スキャンをかける | 実施の範囲と日時を、売り手と書面で合意してから行う |
| 見つかった全ての項目を、売買前に直すよう求める | 影響の大きいものは契約前に、残りは買収後の改修計画に入れる |
開発者依存と技術的負債は、「誰が」「どこまで文書になっているか」で見える化する
結論： 技術的負債の大きさは、コードの古さより、直せる人が残るか、直すための情報が文書になっているかで決まります。
ここでいう技術的負債とは、本記事の整理では「今は動いているが、直したり機能を足したりするときに余分な手間がかかる状態」を指します。定義は用いる人によって幅があり、公的な資料で定まった基準はありません。
| 確認点 | 何を見るか | 買い手の判断への影響 |
|---|---|---|
| 開発者の人数と役割 | 誰がどの部分を保守しているか。1人しか触れない領域はないか | 1人が抜けると止まる領域は、残留や引き継ぎ期間を条件にする候補 |
| 文書の有無 | 設計、データベースの構造、運用手順、障害時の手順 | 文書がない分は、買収後に調べ直す工数になる |
| 自動テスト | テストがあるか、実行されているか | テストがないと、改修のたびに手作業の確認が増える |
| 課題の一覧 | 売り手が把握している不具合・作り直したい箇所のリスト | 一覧がないと、買い手が全部を調べることになる |
| 依存の古さ | 保守が止まったライブラリ、サポートの終わった実行環境 | 更新の時期を、改修計画に入れる |
| 作り替えの要否 | 一部を作り直さないと、新機能や拡張ができないか | 作り替えは、費用と期間の見積りが大きくなる |
仮の数字で、見積りの形を示します。実際の事業や相場を示すものではありません。
| 項目 | 仮の工数（人月） | 仮の費用（1人月=100万円とした場合） |
|---|---|---|
| 設計・運用手順の文書化 | 2 | 200万円 |
| 更新が止まったライブラリの入れ替え | 3 | 300万円 |
| 自動テストの整備 | 1 | 100万円 |
| 合計 | 6 | 600万円 |
この表の費用は、工数に単価を掛けた単純な計算で、仮の数字です。実際の修正費用の水準は、一次資料で確認できていないため、本記事では示しません。買い手は、自社のエンジニアか外部の事業者に見積りを依頼し、売り手の説明と食い違う箇所を残します。
開発者依存の確認は、人事・雇用に絡みます。誰かに残ってもらう条件や、雇用の引き継ぎは、社会保険労務士や弁護士に確認してください。
クラウド費用は、請求の総額ではなく「何に比例して増えるか」の構造で見る
結論： 利益率を左右するのは費用の総額より、顧客や利用量に比例して増える費用と、固定の費用の区別です。この見方は本記事の整理で、公的な資料に定めはありません。
| 費用の種類 | 例 | 買い手が確かめること |
|---|---|---|
| 固定に近い費用 | 本番環境の基本構成、監視、バックアップの保管 | 顧客が増えなくても毎月かかる額 |
| 利用量に比例する費用 | データ保存量、通信量、外部APIの呼び出し | 顧客数・データ量が倍になったとき、費用がどう増えるか |
| 開発・検証用の費用 | 開発環境、検証環境、一時的な環境 | 使っていない環境が残っていないか |
| 外部サービスの費用 | メール配信、決済、認証、監視などの月額 | 契約者の名義と、買収後の契約の継続可否 |
| 割引・特約 | 予約や長期契約による割引 | 契約者が売り手の場合、割引が引き継げるか |
仮の数字で、確認の形を示します。ARRを年4,800万円（月400万円）とした仮の例です。実際の事業や相場を示すものではありません。
| 項目 | 仮の月額 | ARR月額に対する割合 |
|---|---|---|
| 本番環境 | 50万円 | 12.5％ |
| 開発・検証環境 | 20万円 | 5.0％ |
| 外部サービス | 10万円 | 2.5％ |
| クラウド・外部サービス合計 | 80万円 | 20.0％ |
この表で、買い手が次に見るのは、開発・検証環境の20万円のうち不要なものがないか、本番環境の50万円が顧客数に比例して増えるのかです。利益率の判断には、ARRに対する直接原価の割合を見ます（粗利との突き合わせはARRの記事で扱っています）。
調べた結果は、価格・契約条項・改修計画の3つに振り分けて初めてDDの結論になる
結論： 課題の一覧を作っただけでは、交渉に使えません。課題ごとに、価格に反映するか、契約で手当てするか、買収後に直すかを決めます。
| 振り分け先 | 向いている課題 | 具体的な形の例 |
|---|---|---|
| 価格 | 大きな改修費用が確実に見込まれる、直すまで売上が不安定になる | 見積りの費用を考慮して、価格の交渉材料にする |
| 契約条項 | 権利やセキュリティなど、将来に表面化するおそれのあるもの | 表明保証、補償、クロージング条件、特定の課題の対応期限 |
| 改修計画 | 買収後に直せば足り、価格に反映するほどではないもの | 買収後の最初の期間に行う作業として、工数と順番を決める |
| 買収の見直し | 権利の帰属が不明で、確認する方法がない | 確認できるまで先に進まない、または買収を見送る |
契約条項の書き方、表明保証や補償の範囲は、弁護士に確認してください。本記事は個別の契約の助言をしません。
仮の数字の改修見積り（上の600万円）を例にします。この金額を価格に反映するか、売り手に改修を済ませてから引き渡してもらうか、買収後に買い手が行うかは、当事者の交渉で決まります。どれを選ぶかは個別の条件で変わるため、本記事では金額の目安を示しません。
売り手の側は、次の準備をしておくと、買い手の確認が早く進みます。
| 準備 | 内容 |
|---|---|
| 名義の整理 | クラウド・ドメイン・決済・メール配信の契約者を、会社名義にそろえる |
| 一覧の作成 | 使っているOSSとライセンス、外部サービスと契約者、アカウントを持つ人の一覧 |
| 手順書 | 環境の構築、デプロイ、バックアップの復元、障害時の連絡の手順 |
| 記録 | 障害の履歴、診断の報告書とその対処、更新の記録 |
| 課題リスト | 把握している不具合と作り直したい箇所、その優先度 |
自社の場合を確認する 技術面を整える前に、自社の事業の価値の見え方を確かめたいとき → 事業価値を確認する
まとめ
- 技術DDは、買収後の改修費用と運用の継続性を見積もる作業です。ソースコードとOSS、インフラと復旧、脆弱性、開発者依存と技術的負債、クラウド費用の5つに分けて調べます。
- 脆弱性の診断は専門家に任せ、買い手は診断の記録と対処の記録を確かめます。クラウド費用は、固定の費用と、利用量に比例する費用を分けて見ます。
- 見つかった課題は、価格、契約条項、改修計画のどれに入れるかを決めます。権利や契約の判断は弁護士に確認してください。
よくある質問（FAQ）
Q1. 技術DDは、買い手のエンジニアだけで行えますか？ A. 資料の確認と再現ビルドは、買い手のエンジニアでも進められます。ただし、脆弱性の診断やOSSライセンスの条件の判断は、専門の事業者や弁護士に確認するほうが確実です。診断を実施するときは、売り手の承諾と範囲の取り決めが要ります。
Q2. 脆弱性が見つかったら、買収をやめるべきですか？ A. 件数だけでは決められません。内容、影響の範囲、直す手間を見て、価格、契約条項、買収後の改修計画のどれに入れるかを決めます。顧客データの分離が破れているなど、影響が大きく確認の方法もない場合は、買収の見直しを含めて判断します。
Q3. 技術的負債の大きさは、どう見積もりますか？ A. 本記事の整理では、文書がない分の調べ直し、更新が止まった部品の入れ替え、テストの整備などを、工数に分けて見積もります。修正費用の水準を示す一次資料は、本記事では確認できていないため、数字は示しません。買い手のエンジニアか外部の事業者による見積りが必要です。
Q4. クラウド費用は、どの数字を見ればよいですか？ A. 総額に加えて、環境ごと（本番、開発、検証）と、固定の費用か利用量に比例する費用かの区分を見ます。この区分は本記事の整理です。顧客数やデータ量が増えたとき、費用がどう増えるかを請求明細から確かめます。
Q5. IPAやNISTの資料は、技術DDの基準になりますか？ A. 買収時の技術DDの基準を定めた資料ではありません。IPAの「安全なウェブサイトの作り方」は脆弱性の種類と対策、NISTのサイバーセキュリティフレームワーク2.0は、サイバーセキュリティの成果を整理した枠組みです。本記事では、確認項目を考える際の参考として使っています。
Q6. 売り手は、売却前に技術面で何を準備すればよいですか？ A. 契約者の名義の整理、使っているOSSと外部サービスの一覧、環境構築とバックアップ復元の手順書、障害や診断の記録、把握している課題のリストです。個別の法的な判断が要る箇所は、弁護士に確認してください。
出典
- 情報処理推進機構（IPA）「安全なウェブサイトの作り方」 https://www.ipa.go.jp/security/vuln/websecurity/about.html
- 情報処理推進機構（IPA）「情報セキュリティ10大脅威 2026」 https://www.ipa.go.jp/security/10threats/10threats2026.html
- 経済産業省商務情報政策局サイバーセキュリティ課「サイバーセキュリティ経営ガイドライン Ver3.0のポイント」（IPA掲載資料） https://www.ipa.go.jp/security/seminar/ssf7ph00000081a1-att/METI_report.pdf
- NIST「The NIST Cybersecurity Framework (CSF) 2.0」（NIST CSWP 29、2024年2月26日） https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf