SaaS M&A 技術DD完全ガイド｜コード・クラウド・セキュリティ・OSS・AIを売却前に整える

SaaS M&A 技術DDは、ソースコードを読んで品質に点数を付けるだけの調査ではありません。買い手が知りたいのは、売上を支えるシステムを自社が安全に引き継ぎ、顧客を失わず、想定した投資額と期間で伸ばせるかです。売り手にとっては、技術の弱点を隠す場ではなく、既知のリスク、代替策、改善費用、担当者を証拠とともに示し、価格調整や契約条件に発展する不確実性を減らす場です。

SaaSでは、コード、クラウドアカウント、データ、ドメイン、CI/CD、監視、顧客別設定、運用手順、開発者の知識が一体となってサービスを作ります。リポジトリだけ譲渡できても、DNSを移せない、創業者個人のクラウド契約が残る、復元試験をしていない、外注コードの権利が会社に移っていない、といった状態では、買い手は事業継続リスクを負います。反対に、技術負債が残っていても、影響範囲と返済計画を説明でき、顧客価値を壊さず改善できるなら、直ちに売却不能とは限りません。

本稿は、IPA「非機能要求グレード2018」、NIST Cybersecurity Framework 2.0、NIST Secure Software Development Framework、経済産業省「サイバーセキュリティ経営ガイドライン Ver.3.0」「SBOM導入に関する手引 Ver.2.0」、個人情報保護委員会のガイドライン、SPDX・OSIの公式資料等を参照し、売却前90日、Day1、買収後100日までを一つの流れに整理します。各資料への適合を認証する記事ではなく、案件固有のリスクに応じて専門家と確認するための実務ガイドです。

SaaS M&A 技術DDとは何を判断する手続か

財務DDが売上、利益、運転資本、債務の質を確かめるのに対し、技術DDは、その数字を生み続ける技術基盤の再現性を確かめます。対象はプログラムの美しさだけではありません。顧客がログインし、データを処理し、結果を受け取り、請求が発生し、障害時に復旧するまでの全経路が対象です。さらに、買収後に親会社のID、データ基盤、請求、営業、監視へ接続できるかも評価します。

買い手の投資委員会は、主に四つを判断します。第一は、重大事故やサービス停止により既存ARRが毀損しないか。第二は、技術資産と権利を法的・実務的に引き継げるか。第三は、計画した新機能、顧客増、海外展開に耐えられるか。第四は、改善・統合に必要な追加投資が買収モデルへ織り込まれているかです。技術チームの回答は、評価額、表明保証、補償、前提条件、エスクロー、PMI予算へつながります。

コードレビュー、セキュリティ診断、技術DDの違い

したがって、直近の診断報告書に「重大指摘なし」と書かれていても、技術DDは終わりません。診断範囲に管理画面、API、バッチ、クラウド設定が入っていたか、検出後に本番へ反映したか、再診断したか、診断後のリリースで新たな問題が生じていないかを確認します。逆に、診断で指摘があっても、悪用条件が限定され、暫定緩和が機能し、修正計画が進んでいるなら、その事実を評価できます。

技術課題を価格へ直結させすぎない

買い手が「全面リプレースに2億円かかるから価格を2億円下げる」と主張しても、それだけで妥当とは限りません。現行アーキテクチャで事業計画を達成できるなら、全面リプレースは買い手独自の統合方針かもしれません。必要な是正と、買い手が選択する高度化を分けます。売り手は、現状維持費、必須是正費、成長投資、買い手固有の統合費を別表にし、二重計上を避けます。

一方、契約した可用性を満たせない、重大な権限不備がある、コードの権利を移せない、復旧不能、顧客データが混在するといった問題は、現在価値へ直接影響します。指摘を感情的に否定せず、発生確率、影響、期限、代替策を示し、必要ならクロージング前是正、価格調整、特別補償、TSAのどれで処理するかを交渉します。

最初に合意する調査範囲・基準日・証拠

技術DDが長引く典型的な原因は、質問数の多さではなく範囲の曖昧さです。対象プロダクト、法人、国、顧客セグメント、本番環境、開発環境、過去のサービス、受託部分、買収対象外事業との共有資産を最初に定義します。株式譲渡なら法人に残る資産が中心ですが、事業譲渡や会社分割では、移管対象を一件ずつ特定する必要があります。

基準日と「現在」「将来」「過去」を分ける

構成図、ユーザー数、クラウド費、脆弱性、担当者は日々変わります。各資料に基準日、作成者、更新頻度、対象範囲を付けます。「現在の本番」「クロージング時点の予定」「買収後の目標」を一つの図へ混ぜると、買い手は実装済みと誤解します。将来計画には承認済みか、予算化済みか、未着手かを示します。

インシデントは、直近だけを切り取らず、少なくとも会社が合理的に追跡できる期間の一覧を作ります。発生日、検知日、封じ込め、復旧、原因、顧客影響、通知、再発防止を記載し、件数定義を明らかにします。軽微なアラートまで「事故ゼロ」に含めるのか、顧客影響のある事象だけ数えるのかで意味が変わるからです。

資料ではなく証拠の連鎖を作る

「バックアップを毎日取得」という規程だけでは、復元可能性は分かりません。バックアップジョブの成功ログ、保持ポリシー、別アカウント・別リージョンの状態、復元試験記録、実測復旧時間までつなぎます。「全員MFA」なら、IdPの設定、対象者一覧、例外アカウント、直近レビュー記録を提示します。規程、設定、運用記録が一致して初めて、買い手は統制が機能していると判断できます。

証拠には機密性があります。ソースコード、顧客名、認証情報、診断報告書を最初から全候補へ開示しません。NDA、買い手の競合性、取引確度に応じて、概要、匿名化サンプル、閲覧限定、クリーンチーム、最終候補への原本という段階を設けます。秘密を守ることと、都合の悪い事実を伏せることは別です。

技術DD全体を一枚で管理するリスク台帳

質問回答をメールとスプレッドシートへ散らすと、同じ課題に異なる説明が生まれます。技術、法務、財務、個人情報、PMIを横断する一つのリスク台帳を作ります。最低限、ID、領域、事実、証拠、影響を受ける顧客・機能、発生可能性、影響度、暫定措置、恒久対応、費用、期限、担当者、売買契約上の扱いを持たせます。

色は絶対的な安全度ではありません。同じ脆弱性でも、インターネット公開、管理者権限、機微データ、悪用実績の有無で評価が変わります。また、「修正済み」はコードをマージした時点ではなく、本番反映、再テスト、監視、顧客影響確認まで定義します。期限超過を自動的に赤へ上げる等、誰が見ても同じ判定になる基準を置きます。

コード資産・知的財産・開発履歴の確認

コード資産のDDは、行数や言語の新しさより、会社が権利を持ち、再現可能な手順で、安全に変更・配布できるかを見ます。対象にはアプリ本体だけでなく、モバイルアプリ、SDK、CLI、Infrastructure as Code、データパイプライン、機械学習モデル、学習コード、管理スクリプト、テスト、ドキュメント、デザイン資産、設定テンプレートが含まれます。

リポジトリ台帳とプロダクト対応表

すべてのGit組織・リポジトリを列挙し、所有者、用途、現役・休止、プロダクト、デプロイ先、機密度、主要言語、最終更新、ブランチ保護、レビュー要件、バックアップを記録します。「old」「test」と名付けられたリポジトリが本番バッチを動かしている例もあるため、名前だけで除外しません。コンテナレジストリ、パッケージレジストリ、アプリストア、DNS、証明書、署名鍵も同じ台帳へ関連付けます。

買い手へは、顧客機能からリポジトリ、ビルド、実行環境、データストア、担当者へたどれる対応表を示します。一つの機能が複数法人の共通基盤を使う場合、買収後も使えるのか、複製するのか、一定期間TSAで提供するのかを明確にします。事業譲渡で共有リポジトリを丸ごと渡せない場合は、履歴、秘密情報、他事業コードを分離し、ビルド可能性を検証します。

従業員・役員・外注先の権利帰属

会社が費用を払った事実と、著作権その他の権利を会社が取得したことは同じではありません。雇用契約、職務発明規程、業務委託契約、発注書、検収、秘密保持、著作権譲渡、再委託条件を原本で確認します。創業前に書かれたコード、共同創業者が退職時に持ち出したリポジトリ、大学・前職の成果、顧客との共同開発、補助金案件は特に権利関係が複雑です。

外注先が汎用ライブラリを再利用する権利を留保している場合、対象SaaSが独占的に保有する部分を切り分けます。権利の不足が判明したら、遡及的な譲渡・確認書、ライセンス許諾、代替実装、対象範囲除外を検討します。署名を集めるだけでなく、対象成果物、リポジトリ、期間、対価、人格権不行使、第三者素材の申告を具体化し、弁護士へ確認します。

再現可能なビルドとリリース来歴

買い手は、ソースから本番と同等の成果物を作れるか確認します。ローカルPCにしかない依存パッケージ、失効した証明書、手作業の設定、個人アカウントの秘密鍵が必要なら、引継ぎ後にリリースできません。クリーンな環境で、依存取得、テスト、ビルド、署名、デプロイ、ロールバックを実行し、使用したコミットと成果物のハッシュを結びます。

タグ、リリースノート、変更申請、承認者、CIログ、本番デプロイ記録を対応させます。緊急修正で本番だけ変更した履歴がある場合、リポジトリへ戻っているかを確かめます。生成物の来歴を守ることは、開発速度の証明にもなります。誰が、何を、どの承認で本番へ出したかが追える企業は、買収後の権限移行を計画しやすくなります。

アーキテクチャとテナント分離を顧客価値から評価する

技術DDの構成図は、四角と矢印を描くだけでは足りません。外部入口、認証、主要サービス、キュー、バッチ、データベース、オブジェクトストレージ、分析、通知、管理画面、外部API、ネットワーク境界、リージョンを示し、どこにどのデータが流れるかを重ねます。各要素に所有アカウント、担当者、SLA、単一障害点、監視、バックアップを付けます。

モノリスかマイクロサービスかでは決めない

モノリスは必ず負債、マイクロサービスは必ず先進的、という評価はできません。顧客数、チーム規模、変更頻度、障害分離、監査要求に対して適切かを見ます。少人数チームが多数のサービスを手動運用すれば、複雑性が可用性を下げることがあります。整理されたモノリスに十分なテストと分離境界があれば、買収後の拡張に耐える場合もあります。

重要なのは、変更の影響範囲と回復可能性です。主要機能の依存グラフ、直近12か月の変更失敗率、ロールバック時間、障害の波及範囲、データスキーマ変更の手順を示します。将来の分割計画は、顧客価値や開発ボトルネックへ結び付けます。「流行だから刷新する」という計画は、PMI費用を増やすだけです。

テナント分離をUIではなく全経路で確認する

マルチテナントSaaSでは、ユーザーが別社の画面へ移れないだけでは不十分です。API、検索、エクスポート、キャッシュ、キュー、ログ、バックアップ、分析基盤、サポートツール、管理者機能でテナントIDが一貫して強制されているかを確認します。URLのIDを変えるテストだけでなく、認可ミドルウェア、行レベル制御、暗号鍵、ストレージパス、非同期ジョブのコンテキストを追います。

テナント分離の方式は、共有DB・共有スキーマ、共有DB・個別スキーマ、個別DB、個別アカウント等があります。どれが正解かではなく、顧客契約、機微性、規模、運用能力と整合するかです。大企業向け専有環境が手作業で作られている場合、設定差分、パッチ遅延、監視漏れ、原価を顧客別に確認します。サポート担当者の代理ログインや本番データ閲覧には、承認、最小権限、記録、期限を設けます。

スケーラビリティは負荷試験と単位原価で示す

「オートスケール対応」は能力の証明になりません。想定ユーザー、同時接続、API毎秒、ジョブ件数、データ量、ピーク時間を定義し、実測負荷試験と本番メトリクスを示します。制限に達する最初の要素、劣化の仕方、復旧、レート制限、バックプレッシャーを確認します。顧客が10倍になったとき、売上よりクラウド費が速く増えないかも重要です。

顧客・機能単位で、コンピュート、DB、ストレージ、転送、外部API、生成AIトークン、監視、サポート工数を配賦します。大口顧客が高売上でも、専有環境と大量転送で粗利が低い場合があります。買い手の成長モデルには、技術上の容量だけでなく、限界粗利と増強リードタイムを入れます。

クラウドアカウント・IAM・秘密情報の引継ぎ

クラウドDDは設定スキャンだけでなく、誰の契約で、誰が支払い、誰が管理し、買収後に誰がアクセスできるかを確認します。ルート・組織管理アカウントが創業者個人メール、旧会社のカード、外部MSPにひも付いていると、株式譲渡でも実務上の支配移転が難しくなります。事業譲渡ではアカウント自体を移せないサービスもあるため、契約条件と移行手順を各提供者へ確認します。

クラウド資産台帳を請求と一致させる

AWS、Azure、Google Cloud等の主要基盤だけでなく、CDN、DNS、IdP、メール配信、監視、エラー追跡、コードホスティング、CI、証明書、決済、顧客サポート、分析、生成AI APIまで列挙します。法人名義、契約プラン、リージョン、データ種別、管理者、請求、更新日、解約影響、移管可否、再委託を記録します。クレジットカード明細とSaaS台帳を突合し、誰も把握していないShadow ITを探します。

予約、長期コミット、ボリュームディスカウント、無償クレジットは、買収後も承継できるとは限りません。現在の月額だけでなく、割引前単価、満了日、最低利用、為替、データ搬出費を示します。環境別・顧客別のタグが不十分なら、請求エクスポートとリソース棚卸しから配賦ルールを作り、推計部分を明示します。

IAMは人数ではなく権限経路を確認する

社員一覧とクラウドユーザー一覧を照合し、退職者、共有ID、休眠キー、サービスアカウント、外部委託、緊急用アカウントを確認します。SSOとMFAの適用率だけでなく、SSOを迂回できるローカルアカウント、APIキー、CI用長期鍵、クロスアカウントロールを追います。管理者権限は付与理由、承認者、期限、利用ログを持たせます。

買収前にすべての権限を一気に変更すると障害を起こす恐れがあります。Day1に必要な緊急統制と、100日で行うIdP統合を分けます。最初に退職者削除、ルート保護、MFA、鍵の棚卸し、ログ保全を行い、その後ロール設計、短期認証、特権アクセス管理へ移します。買い手の標準へ合わせる場合も、バッチや顧客連携が依存する資格情報を事前にテストします。

秘密情報と暗号鍵はローテーション可能性まで見る

ソース、Wiki、チケット、チャット、コンテナイメージ、CIログに秘密が残っていないかを検査します。検出した値は削除だけでなく失効・再発行します。データベース接続、外部API、署名鍵、暗号鍵、Webhook、OAuthクライアントを台帳化し、所有者、保管先、利用先、最終更新、ローテーション手順を付けます。

保存時・通信時の暗号化を確認する際は、「暗号化あり」で終えません。鍵管理者、鍵とデータの分離、顧客別鍵の有無、復号権限、監査ログ、失効、バックアップ、鍵喪失時の復旧を確認します。買収後に法人・アカウントを移す場合、暗号鍵を輸出・再暗号化できるか、顧客契約や規制に制約がないかを専門家と検討します。

IPA非機能要求グレードでRTO・RPOと運用品質を言語化する

IPA「非機能要求グレード2018」は、非機能要求を網羅的に分類し、要求レベルを段階的に確認するためのツール群です。公式説明では、グレード表、項目一覧、六つの大項目を示す樹系図、プロジェクトに合わせて調整できる活用シート等が提供されています。M&A専用基準ではありませんが、売り手と買い手が「高可用性」「十分速い」といった曖昧語を具体的な要求へ変えるのに有用です。

RTOとRPOを契約・実測・目標に分ける

RTOは、停止後にどの時間までに業務・サービスを復旧させるかという目標です。RPOは、どの時点までのデータ復旧を目指すかという目標です。売り手は、顧客契約のSLA、社内BCPの目標、現行構成の設計値、直近試験の実測を分けます。たとえば「RTO4時間」が規程にあっても、復元試験に9時間かかり、DNS切替を試していないなら、実力を4時間と表現できません。

機能ごとに優先順位を付けます。ログイン、主要取引、データ参照、管理画面、分析、通知、請求が同じRTOとは限りません。依存するIdP、DNS、決済、外部APIの復旧条件も含めます。RPOゼロを求めるなら、同期複製だけでなく誤操作・論理破壊が複製されるリスク、ポイントインタイム復旧、イミュータブルバックアップを検討します。

バックアップは「取得」から「復元」へ

データベース、オブジェクト、設定、Infrastructure as Code、秘密情報、監査ログ、顧客別ファイルについて、対象、頻度、保持、暗号化、保存先、削除保護を示します。本番と同じアカウントの管理者がバックアップも削除できるなら、ランサムウェアや内部不正への耐性は限定されます。別アカウント、別リージョン、変更不能期間等を事業リスクに応じて設計します。

復元試験では、空の環境に必要な基盤を作り、バックアップから復元し、アプリを起動し、整合性を確認し、所要時間を測ります。DBだけ戻っても、暗号鍵、DNS、キュー、検索インデックス、外部連携が戻らなければサービスは復旧しません。失敗も記録し、原因、再試験日、実測RTO・RPOを更新します。デモ用の小さいデータだけで成功した結果を、本番規模へそのまま適用しません。

可用性・性能・運用を一つの費用モデルにする

可用性を高めるほど、冗長化、監視、待機系、訓練に費用がかかります。すべてを最高レベルにするのではなく、顧客影響、契約、売上、代替手段に応じて決めます。月次稼働率は、計画停止、部分障害、性能劣化、外部サービス障害をどう数えるか定義し、監視データと顧客問い合わせを突合します。

性能は平均だけでなく、p95・p99、ピーク、エラー率、タイムアウト、バックログを見ます。運用は、アラート件数、夜間呼出し、平均検知時間、平均復旧時間、再発率、手動作業、変更失敗を追います。これらをクラウド費、オンコール工数、顧客解約、SLAクレジットへつなぐと、改善投資の優先順位を説明できます。

サイバーセキュリティを経営リスクとして評価する

NIST Cybersecurity Framework 2.0は、組織の規模や業種を問わず、サイバーセキュリティの取組を理解、評価、優先付け、伝達するための高水準の成果体系です。CSF 2.0は、Govern、Identify、Protect、Detect、Respond、Recoverの六つの機能で構成され、特定製品の導入方法を一律に指示するものではありません。技術DDでは、この六機能を使うと、診断や防御製品だけに偏らず、経営責任、資産、検知、対応、復旧まで確認できます。

経済産業省「サイバーセキュリティ経営ガイドライン Ver.3.0」も、サイバーセキュリティを企業リスクマネジメントの一部として扱い、経営者が認識する三原則と、担当幹部へ指示すべき重要10項目を示しています。三原則には、経営者のリーダーシップ、クラウドや委託先を含むサプライチェーン全体への目配り、平時・緊急時の関係者とのコミュニケーションが含まれます。DD回答をCTO一人へ丸投げせず、取締役会が残留リスクを理解し、予算と責任者を決めているかが問われます。

Govern・Identify：責任、許容度、資産を見える化する

取締役会・経営会議で、どのリスクを誰が受容し、どの頻度で報告するかを示します。情報セキュリティ方針、リスク評価、例外承認、委託先管理、インシデント報告線、教育、監査が対象です。CISOという肩書がなくても、意思決定者、実務責任者、緊急連絡先が明確であれば説明できます。反対に、認証取得時だけ作った規程が現場と一致しない状態は、形式的統制として指摘されます。

資産はサーバ台数ではなく、事業に重要な機能、データ、第三者サービス、人材を含めます。各資産に、所有者、機密性・完全性・可用性、顧客影響、依存先、復旧優先度を付けます。顧客一覧とシステム台帳が別々に存在する場合、大口顧客が依存する専用連携や、特別SLAを構成図へ反映します。

Protect・Detect：最小権限と検知能力を証拠で示す

防御では、ID、MFA、端末、パッチ、ネットワーク、暗号化、秘密、バックアップ、教育を確認します。ただし、統制の有無だけでなく、対象率と例外を見ます。「端末管理導入済み」なら、全従業者・委託先端末のうち何台が登録され、暗号化、画面ロック、OS更新、紛失時ワイプが有効かを示します。例外端末には理由、データアクセス範囲、期限を付けます。

検知では、アプリ、クラウド監査、IdP、DB、WAF、エンドポイントのログをどこへ集め、誰が、いつ、何を見ているかを確認します。ログ保存だけでは検知になりません。重大ルールのテスト、誤検知調整、アラートからチケット・オンコールへの流れ、営業時間外の対応を示します。攻撃者がログを消せない保管、時刻同期、顧客別追跡、個人データの過剰記録にも注意します。

Respond・Recover：机上手順ではなく演習結果を見る

インシデント対応計画には、宣言基準、指揮、技術封じ込め、証拠保全、法務・個人情報、顧客連絡、広報、保険、外部専門家を含めます。連絡先が退職者のまま、クラウドサポート契約が切れている、夜間の意思決定者がいない、といった実務上の穴を演習で探します。ランサムウェア、認証情報漏えい、テナント間データ露出、依存先停止等、SaaS固有のシナリオを使います。

演習後は、検知までの時間、連絡、判断、復旧、顧客説明の詰まりを課題化します。「毎年演習」という予定ではなく、実施日、参加者、シナリオ、発見事項、是正完了を提示します。買収発表からクロージングまでは攻撃者の関心が高まる可能性もあるため、異常監視、フィッシング教育、特権変更、公開情報管理を強化します。

安全な開発とCI/CDをNIST SSDFで点検する

NIST SP 800-218 Secure Software Development Framework（SSDF）Version 1.1は、セキュア開発の高水準な実務を、Prepare the Organization、Protect the Software、Produce Well-Secured Software、Respond to Vulnerabilitiesの四群に整理しています。特定の開発手法へ置き換えるものではなく、既存SDLCへ統合できる共通語彙です。ソフトウェアの購入者が供給者との対話に使えることも公式説明に明記されています。

Prepare：セキュリティ要件をチームの仕事にする

顧客契約、法令、社内リスク、プロダクト特性からセキュリティ要件を定義し、設計、実装、テスト、リリースへ落とします。開発者教育、セキュリティ責任、例外承認、必要ツール、予算を準備します。セキュリティ担当が最後に診断するだけでは、修正費が高くなり、リリース判断も属人化します。チケットテンプレートやDefinition of Doneへ認証、認可、ログ、秘密、依存関係、テストを組み込みます。

売り手は、規程そのものより、直近の要求定義、脅威モデル、設計レビュー、教育記録、例外チケットを示します。すべての小変更に重い審査を課す必要はありません。決済、管理者、ファイル取込、外部公開API等、リスクの高い変更を自動で識別し、必要なレビューを増やす仕組みが実務的です。

Protect：コード、ビルド、成果物を改ざんから守る

リポジトリのMFA、ブランチ保護、レビュー必須化、署名、CI権限、シークレット管理、成果物レジストリ、監査ログを確認します。開発者がレビューなしで本番ブランチへ直接pushできる、CIが本番管理者鍵を長期保持する、外部Forkから秘密を読める、といった経路を脅威モデルで検証します。退職者の個人アカウントにリポジトリ所有権が残らないよう、法人管理へ移します。

成果物とソースの対応、依存パッケージ、ビルド環境の来歴を保存します。緊急対応の例外はゼロにするのでなく、承認、期限、事後レビューを記録します。買収時には、買い手がリポジトリへアクセスした瞬間から安全になるわけではありません。権限マッピング、監査ログ保全、鍵のローテーション、CI接続先変更を順序立てます。

Produce：脅威モデル、レビュー、テストを変更へ結び付ける

認証、認可、入力、セッション、暗号、エラー、ログ、ファイル、API、管理者、テナント分離について設計原則を定めます。SAST、DAST、依存関係スキャン、秘密検出、IaCスキャン、コンテナスキャンは、それぞれ対象と限界が異なります。一つのツールで「セキュア」を証明せず、変更リスクに応じて組み合わせます。

スキャン結果は、重大度だけでなく、インターネット到達性、実行経路、権限、データ、悪用可能性、既存防御で優先付けします。誤検知として閉じた記録にも理由と承認を残します。テスト失敗を無視してリリースできる権限、品質ゲートの例外回数、未修正期間を示すと、プロセスが実際に機能しているか分かります。

Respond：脆弱性を受け付け、直し、再発を防ぐ

公開連絡先、脆弱性報告の受付、トリアージ、CVE等の外部情報監視、顧客通知、修正版配布、根本原因分析を確認します。報告者へ法的威嚇をせず適切に調整できる体制、サポート窓口からセキュリティ担当へのエスカレーション、休日対応が重要です。外部ライブラリの脆弱性は、SBOMと実際の利用経路を使い影響を判定します。

修正SLAは、CVSSだけで一律に決めません。既に悪用されているか、公開面か、管理者権限か、顧客データへ到達するか、暫定緩和があるかを含めます。修正後は同種バグを検索し、テスト、コーディング標準、設計を更新します。DDでは、未処理件数だけでなく、発見から判断、修正、検証までのリードタイムと再発率を見ます。

ログ・脆弱性・インシデント履歴を隠さず評価可能にする

買い手が警戒するのは、過去に事故があった会社より、事故を検知できず、記録もなく、同じ問題を繰り返す会社です。売り手は、脆弱性一覧、ペネトレーションテスト、バグ報奨・外部報告、クラウドアラート、顧客問い合わせ、障害記録を同じ分類へ寄せます。「障害」「セキュリティ」「不具合」の名称が違っても、機密性、完全性、可用性へ影響した事象は横断して確認します。

ログの存在ではなく、答えられる質問を定義する

監査ログで、誰が、いつ、どのテナントの、どのデータへ、どの操作をしたかを追えるか確認します。管理者の権限変更、代理ログイン、エクスポート、削除、APIキー発行、設定変更は優先度が高い操作です。アプリログへパスワード、アクセストークン、本文、個人データを過剰に出力していないかも調べます。ログはセキュリティ証拠である一方、新しい漏えい源になり得ます。

保存期間は、顧客契約、調査に必要な期間、費用、個人データ最小化を踏まえて決めます。アプリ、クラウド、IdP、WAF、DBの時刻を同期し、相関できるIDを設けます。運用担当が本番とログ保管先の両方を削除できる場合は、権限分離や変更不能化を検討します。DD中は、買収前の証拠を保持する必要があるため、通常の自動削除を変更する場合も法務と調整します。

脆弱性バックログを「重大件数」だけで見せない

各脆弱性に、発見元、対象バージョン、影響資産、到達性、必要権限、機微データ、既知悪用、暫定緩和、担当、期限、再テストを付けます。同じCVEでも、依存パッケージが実行経路にない場合と、外部公開APIから到達できる場合では優先度が違います。ただし「到達不能」という判断は、根拠となる構成・コード・テストを保存し、依存更新時に見直します。

長期未修正があるときは、件数を隠すより、なぜ残ったかを説明します。互換性、顧客専用環境、サポート終了OS、代替パッケージ不在など理由を分類し、リスク受容者と期限を示します。根本的な更新がクロージング後になるなら、ネットワーク制限、機能停止、監視強化等の暫定措置と、PMI予算を用意します。

過去事故の説明は時系列と再発防止で行う

事故説明は、発見、初動、封じ込め、原因特定、復旧、通知、再発防止の時系列で作ります。影響人数や件数が調査中だった時点の数字と、確定後の数字を混同しません。顧客・当局への通知要否は、当時の法令、契約、専門家判断を示します。未通知だった事実を「問題なし」と短く書くのでなく、判断根拠をデータルームへ置きます。

再発防止は、担当者への注意だけでなく、設計、権限、テスト、監視、教育、手順の変更へ落とします。完了した対策は設定やチケットで証明し、未完了は期限と残留リスクを示します。買い手は事故そのものに加え、組織が学習できるかを見ています。

OSS・SBOM・ソフトウェアサプライチェーンのDD

現代のSaaSは多数のOSS、コンテナイメージ、OSパッケージ、SDK、ホステッドAPIで構成されます。依存関係を使うこと自体は問題ではありません。何を、どのバージョンで、どの用途に使い、どのライセンス義務と脆弱性があり、更新責任を誰が持つかを把握していないことがリスクです。手作業の表を一度作って終わりにせず、ビルドとリリースへ結び付けます。

SBOMは在庫表であり、安全証明書ではない

経済産業省「SBOM導入に関する手引 Ver.2.0」は、ソフトウェア供給者と調達者の双方を想定し、脆弱性管理プロセス、導入範囲を考えるフレームワーク、契約上の要求・責任・費用・権利等を扱っています。SBOMを作成する目的は、部品一覧を納品することではなく、影響を受ける製品を迅速に特定し、対応を判断することです。

SBOMには、少なくともコンポーネント名、バージョン、供給者、識別子、依存関係、ライセンス等を、採用形式と案件目的に応じて含めます。SPDXやCycloneDX等の形式を選んでも、内部パッケージ、静的リンク、コンテナのベースイメージ、ビルド時だけ使う部品、フロントエンド、モデル・データ等の範囲は自動的に決まりません。対象プロダクト、リリース、生成日時、ツール、欠落の可能性を記録します。

買い手へ提出する前に、SBOMを実際の成果物と照合します。ロックファイルだけから作ると、本番イメージに残るOSパッケージや、動的に取得した部品を逃すことがあります。反対に、開発専用依存を本番リスクとして数えることもあります。ソース、ビルド、コンテナ、実行環境の複数視点を比較し、差異を説明します。

SPDX識別子とライセンス原文を一致させる

SPDX License Listは、ライセンス・例外の標準的な短縮識別子、正式名称、ライセンス本文、恒久URLを提供します。OSIの承認済みライセンス一覧も参照できます。ただし、パッケージのメタデータに「MIT」と書かれているだけで、その配布物全体が同じ条件とは限りません。LICENSE、NOTICE、COPYING、ソースヘッダー、依存先、フォント・画像・モデルを原文で確認します。

MIT、BSD、Apache-2.0のような許諾型でも、著作権表示、ライセンス文、NOTICE、特許条項等の確認が必要です。GPL、AGPL、LGPL等は、結合方法、改変、配布、ネットワーク提供等の具体的事実によって論点が変わります。「SaaSだから義務なし」「コンテナだから分離」と一律に判断せず、利用形態、提供物、顧客契約をOSSに詳しい弁護士と評価します。

ライセンス台帳を製品リリースへ結び付ける

コンポーネント、バージョン、ライセンス式、利用箇所、改変、配布物、通知対応、承認者、代替可能性を台帳化します。`GPL-2.0-only`と`GPL-2.0-or-later`のような違い、複数選択、例外を曖昧な「GPL系」にまとめません。商用ライブラリ、フォント、地図、データセット、学習済みモデルも、利用量、再配布、支配権変更、譲渡の条件を確認します。

未承認OSSが見つかったら、即座に「利用禁止」とするのでなく、義務、製品影響、代替費用、顧客への提供形態を評価します。通知ファイルの追加、ソース提供手順、購入ライセンス、依存更新、代替実装等の是正策を比較します。買い手には、発見日時、暫定措置、法務判断、解消期限を示します。

依存関係の脆弱性対応を日常運用にする

新しいCVEをSBOMへ照合し、対象リリース、実行経路、顧客影響を判定します。自動更新は有用ですが、互換性テストなしで本番へ入れると障害になります。サポート終了パッケージ、放置されたライブラリ、フォーク、独自パッチを特定し、更新頻度と代替候補を示します。重要部品のメンテナが一人、署名・配布経路が弱い等、プロジェクトの持続性も考慮します。

SBOMの鮮度を測るため、どのリリースに対応するか、生成が成功したか、未知ライセンス・未知バージョンが何件か、重大脆弱性の判断に何時間かかったかを追います。買収後も同じ手順を再実行できるよう、ツール設定と出力だけでなく、例外判断のルールを引き継ぎます。

個人データ・顧客データ・越境処理を技術と契約でつなぐ

SaaSのデータDDでは、プライバシーポリシーを読むだけでなく、実際のデータフローを作ります。収集画面、API、Cookie・SDK、取込ファイルから、保存、変換、分析、サポート、バックアップ、削除、外部提供までを追います。各データに、本人・顧客、利用目的、法的位置付け、保管国、委託先、保持期間、アクセス者、暗号化、削除方法を付けます。

安全管理措置は規模・性質・リスクに応じて説明する

個人情報保護委員会「個人情報保護法ガイドライン（通則編）」は、個人データの漏えい、滅失、毀損の防止その他の安全管理のために必要かつ適切な措置を求めています。その内容は、漏えい等による本人の権利利益への影響、事業規模・性質、データの性質・量等に起因するリスクに応じるとされています。技術DDでは、組織的、人的、物理的、技術的措置と外的環境の把握を、実装・運用証拠へ結び付けます。

「クラウド事業者が認証取得済み」だけでは、自社の設定と運用は説明できません。自社が担うIAM、暗号鍵、ネットワーク、ログ、端末、データ削除、委託先監督を明確にします。顧客が管理者となりSaaS会社が委託を受ける構造では、DPA、処理指示、再委託先、事故通知、削除・返却、監査対応と実際のシステムを一致させます。

事業承継でも利用目的と契約を確認する

通則編は、合併、分社化、事業譲渡等の事業承継に伴う個人データ提供について、提供先が第三者に該当しない場合を示す一方、承継後も承継前の利用目的の範囲内で利用する必要があると説明しています。したがって「M&Aだから自由に統合できる」とは言えません。買い手のCRM、分析、AI学習、クロスセルへ使う計画が既存の利用目的・契約に収まるか、法務と確認します。

DDのために顧客データ原本を候補先へ渡すことも、必要性と範囲を検討します。売上・利用分析は匿名化・集計・仮名化で目的を達成できないか、クリーンチームで制限できないかを先に考えます。データルームの閲覧、ダウンロード、透かし、アクセスログ、削除証明を設定し、案件中止時の返却・削除をNDAへ入れます。

委託・再委託・外国での取扱いを台帳化する

個人情報保護委員会の通則編は、委託先の適切な選定、委託契約、取扱状況の把握を含む必要かつ適切な監督を示します。また、外国で個人データを取り扱う場合は、その外国の制度等を把握した上で必要かつ適切な措置を講じることを示しています。海外リージョンだけでなく、外国にいるサポート担当者が国内サーバへアクセスする経路、再委託先も確認します。

クラウド、メール、サポート、分析、エラー追跡、生成AI、翻訳、バックアップ等について、事業者名、サービス、データ、目的、国、契約、再委託、監査資料、事故通知、削除を記録します。Webサイトに掲載する再委託先一覧と実際の請求・ネットワーク通信を突合します。買収後に親会社の標準ツールへ移す場合、データ移行と旧サービス削除の証拠を残します。

保持・削除・バックアップの矛盾を解く

アプリ画面で削除しても、分析、検索、ログ、バックアップ、サポート添付、開発コピーに残ることがあります。削除要求が各システムへ伝播する設計、保持期間、法令・契約上の例外、バックアップから再出現しない手順を確認します。開発・テスト環境へ本番個人データを複製している場合、目的、マスキング、アクセス、期限を見直します。

退会直後の完全物理削除が技術的にできない場合は、利用停止、論理削除、バックアップの自然満了、復元時の再削除等を正確に説明します。プライバシーポリシー、顧客契約、実装の表現をそろえます。具体的な適法性はデータ種類、役割、契約、国により異なるため、技術チームだけで結論を出しません。

生成AI・機械学習を含むSaaSの技術DD

AI機能のDDでは、モデル精度だけでなく、学習・評価データの権利、個人データ、外部モデル利用条件、プロンプト、出力、監視、費用、モデル更新を確認します。「AI搭載」というマーケティング表現と、実際に自社モデルを学習するのか、第三者APIへ入力するのか、ルールベースなのかを分けます。買い手は、機能価値と同時に、再現性、契約変更、供給停止、単価上昇のリスクを評価します。

AI資産台帳をモデル・データ・評価へ分ける

モデル名・版、提供者、利用目的、入力、出力、ホスティング、ファインチューニング、埋め込み、ベクトルDB、プロンプトテンプレート、ガードレール、評価セット、責任者を台帳化します。学習済み重みを保有する場合は、作成手順、基盤モデル、データ、計算環境、ライセンス、再学習費用を付けます。外部APIなら、入力の学習利用、保存期間、リージョン、サブプロセッサ、SLA、終了時の移行性を契約原文で確認します。

プロンプトやRAGの文書も知的資産です。顧客データ、社内文書、第三者コンテンツが混ざる場合、テナント分離、権限継承、引用、削除を確認します。ベクトルDBから削除しただけで、キャッシュや評価ログへ残らないかも追います。外部モデルへ秘密情報を送る機能は、入力フィルタ、利用者教育、契約、ログ最小化を組み合わせます。

学習データの来歴と利用権を証拠化する

データセットごとに、取得元、取得日、利用目的、同意・契約、ライセンス、個人情報、機微性、加工、品質、保持、削除要求への対応を記録します。公開Webから取得できることと、学習利用・商用利用できることは同じではありません。顧客から預かったデータを「サービス改善」に使えるかも、契約文言と説明、実際の処理により判断が必要です。

データ来歴が不明な場合、全件を同じ危険度にせず、モデルへの寄与、再収集可能性、除去・再学習費、出力リスクを評価します。利用停止、対象モデルの隔離、合成データへの置換、権利取得、再学習等を比較します。問題を開示せず買い手へ移すと、表明保証だけでなく、モデル価値そのものへの疑義になります。

精度ではなく利用場面別の失敗を測る

平均精度一つでは、顧客リスクを説明できません。利用場面、言語、顧客属性、入力長、データ鮮度に分け、誤答、幻覚、拒否、偏り、情報漏えい、プロンプトインジェクション、不適切出力を評価します。人が確認するのか、自動で意思決定・送信するのかにより必要統制が変わります。評価セットの由来、版、期待結果、閾値、失敗例を保存します。

モデルやプロンプトの更新前後で回帰試験を行い、誰がリリースを承認したかを記録します。顧客へ説明した性能、制限、免責と実測を一致させます。外部モデルが予告なく更新される場合、版固定、監視、ロールバック、代替モデルを検討します。AI出力への利用者フィードバックが個人データや機密を含むこともあるため、二次利用と保持を定めます。

公的ガイドを統制設計の入口にする

経済産業省・関係機関のAI事業者ガイドラインは、AI開発者、提供者、利用者等がリスクに応じた取組を検討するための資料です。また、個人情報保護委員会は生成AIサービスの利用に関する注意喚起を公表しています。最新版、対象、法令・契約との関係を確認し、自社の役割へ当てはめます。

ガイドライン名を一覧にするだけで適切な運用にはなりません。ユースケース承認、禁止用途、データ分類、ベンダー審査、評価、監視、事故対応、利用者説明を、実際の機能と担当へ落とします。AIの法規制・指針は更新されるため、DD基準日とクロージング時点で最新版を再確認し、対象国の専門家へ相談します。

キーパーソン・開発生産性・運用属人性のDD

技術資産は人から完全に分離できません。創業者一人だけがデプロイ、障害対応、顧客別設定、請求バッチを理解している場合、買い手は退任リスクを見ます。ただし、人数が少ないこと自体を低成熟と決めつけません。自動化、単純な構成、良いドキュメントにより、小規模チームが安定運用できることもあります。

組織図ではなく責任と代替可能性を描く

機能領域ごとに、最終責任者、実装者、レビュー者、オンコール、代替者、習熟期間を示します。社員だけでなく、業務委託、派遣、親会社・関連会社、外部MSPを含めます。稼働時間、契約期限、競業、知財、買収後の継続意思を人事・法務DDと連携して確認します。本人の意思を推測で記載せず、適切な時期と方法で確認します。

退職者が残した領域、単独承認、休日に連絡がつかない外注先、特定言語の一人担当を可視化します。引継ぎは文書のページ数でなく、別担当者が手順を実行できたかで測ります。ペア作業、録画、ゲームデイ、ローテーション、Runbook実行を通じて、暗黙知を検証可能にします。

開発生産性をコミット数で判断しない

コミット、行数、チケット数は、分割方法や自動生成で変わり、個人評価には不適切です。プロダクト価値に対するリードタイム、デプロイ頻度、変更失敗、復旧時間、レビュー待ち、計画外作業をチーム単位で見ます。大規模な機能を少ないコミットで完成させる場合もあり、数字の背景を確認します。

ロードマップの達成率は、未達理由を顧客要望、障害、採用、依存先、技術負債へ分解します。経営が優先順位を頻繁に変えた結果を、開発チームの能力不足としません。買い手は、統合後に誰を残し、どこへ採用し、どの意思決定を変えるかを判断します。

残留・移行条件を価格と別に設計する

キーパーソンの残留ボーナス、雇用条件、役割、権限、評価、勤務場所を、売買対価と区別して設計します。創業者へアーンアウトを課すなら、プロダクト、人員、価格、販売、クラウド移行を買い手が変更した際のKPI影響を契約で扱います。知識移転の成果物、期間、完了判定を曖昧な「合理的な協力」に留めないことが重要です。

技術負債を買収価格とPMI予算へ翻訳する

技術負債は、古い言語やモノリスというラベルではありません。将来の変更速度、障害、セキュリティ、原価、採用、顧客要件に追加コストを生む設計・実装・運用上の選択です。すべての負債を返す必要はなく、事業計画を妨げる順に扱います。

負債を五つの経済影響へ分ける

1. 売上保全：障害、性能、セキュリティ、契約不適合により解約・返金・失注へつながる負債。
2. 成長制約：顧客数、データ量、国、製品追加の上限となる負債。
3. 粗利圧迫：過剰クラウド費、手動運用、顧客別カスタム、外部API単価を増やす負債。
4. 開発遅延：テスト不足、密結合、環境差分により変更リードタイムを長くする負債。
5. 人材リスク：一人しか理解しない、採用困難、サポート終了技術に依存する負債。

各項目に、影響を受けるARR・顧客、発生確率、現在の回避工数、是正案、見積り幅、依存関係を付けます。金額を一点で断定せず、前提と幅を示します。たとえばDB分割は、コード変更だけでなく、データ移行、二重書込み、検証、顧客停止、ロールバックを含みます。

必須是正・維持・高度化・統合を分ける

必須是正は、現在の顧客約束や合理的な安全性を満たすために必要な対応です。維持投資は、バージョン更新や証明書、通常の監視等です。高度化は、新市場・大企業要件へ進む投資です。統合は、買い手のIdP、請求、データ基盤、ブランドへ合わせる費用です。この四区分を混ぜると、売り手固有の欠陥として過大な価格控除を受けたり、買い手がPMI予算を見落としたりします。

複数案を比較します。全面刷新、段階的置換、境界で包む、現状維持と監視強化、外部サービス利用のそれぞれに、費用、期間、顧客リスク、可逆性を付けます。買収後すぐの全面刷新は、担当者の退職と顧客移行が重なるため、技術的に理想でも取引全体では危険な場合があります。

バックログと会計・事業計画をつなぐ

開発チケットを、顧客要望、障害、セキュリティ、負債、規制、運用へ分類し、直近の投入割合を示します。経営計画では新機能100％の前提なのに、実際は保守・障害で半分を使っているなら、買収モデルの開発能力を調整します。逆に、自動化で保守比率が下がっているなら、その推移は価値の証拠になります。

見積りは、担当者の楽観値だけでなく、過去類似作業、外部見積り、スパイク結果を使います。買い手が別技術へ統一する場合、現行チームが未経験であることも織り込みます。技術DDの結論は「負債5,000万円」ではなく、「この事業計画を実現するには、いつ、どの能力へ、どの幅の投資が必要か」です。

売り手が準備する技術データルーム

SaaS M&A 技術DDで評価を安定させるには、質問を受けてから資料を作るのでなく、証拠の所有者と更新頻度を決めたデータルームを用意します。フォルダ番号と索引を一致させ、各資料に基準日、対象、機密区分、作成者を付けます。空欄は「なし」「未確認」「対象外」「後日提出」を区別します。

ソースコードの開示は段階的にする

初期段階は、言語・規模・テスト・主要依存・開発プロセスの概要、第三者レビュー結果等で説明します。最終候補へは、閲覧専用環境、限定リポジトリ、クリーンルーム、監査ログを使います。競合買い手には、顧客固有ロジック、価格、秘密鍵、未公開ロードマップを必要以上に見せません。取得目的に対して必要な範囲を、アドバイザー・弁護士と決めます。

コードを渡す前に秘密情報を検査し、履歴に残る鍵を失効します。個人データや顧客データのfixtureを除去・匿名化します。案件中止時のコピー削除、解析成果物、AIコード解析サービスへの再入力禁止等もNDA・手順で扱います。

デモは正常系だけでなく運用を見せる

製品デモでは、顧客オンボーディング、権限、主要処理、請求、監査、エクスポート、削除まで通します。技術デモでは、変更を一件作り、テスト、レビュー、デプロイ、監視、ロールバックを見せます。障害対応デモでは、アラートからRunbook、エスカレーション、復旧まで追います。録画された理想手順だけでなく、現在の本番運用との差を説明します。

回答できない質問はその場で推測せず、担当、期限、確認方法を記録します。後日の回答が最初の説明と変わった場合は、変更理由と証拠を明示します。買い手は完璧さより、情報の信頼性を見ています。

買い手面談で経営者・CTOが答えるべき質問

マネジメントインタビューでは、技術責任者だけでなく経営者が、事業計画と技術投資の関係を説明します。「全部CTOに任せている」「事故は聞いていない」という回答は、Governの弱さを示します。経営者は、重大リスク、予算、採用、顧客約束、買収後に必要な判断を理解しておく必要があります。

頻出質問を数字と証拠へ変える

• 顧客・処理量が3倍になったとき最初に詰まる箇所はどこか。増強費と期間はいくらか。
• 最も重大な未解決リスクは何か。誰が受容し、いつ見直したか。
• 創業者が明日不在でも、デプロイ、請求、障害復旧を誰ができるか。
• 最大顧客が依存する専用機能、SLA、データ所在は何か。
• 直近の重大障害・脆弱性から、設計と運用を何に変えたか。
• 買収後30日以内に変更してはいけないものは何か。その理由は何か。
• 年間ロードマップのうち、維持、負債、セキュリティ、新機能の配分はどうか。
• クラウド、外部API、AIの供給停止・価格上昇に代替策はあるか。

回答は、結論、根拠、限界、計画の順にします。「3倍まで大丈夫」ではなく、「直近負荷試験は現在ピークの2.4倍まで実施し、DB接続が最初の制約だった。設定変更で3倍を目標に再試験予定。5倍には読み取り分離が必要で、見積りはこの範囲」と説明します。未検証の数字を事実として言い切りません。

矛盾を事前に潰す

営業資料の「24時間365日」、契約のSLA、監視時間、実績が一致するか確認します。セキュリティ質問票の過去回答と現設定、プライバシーポリシーとデータマップ、財務のクラウド費と技術台帳も突合します。矛盾があれば正しい版、発生理由、是正を示します。DDで初めて発見されるより、売り手が先に説明する方が交渉を管理できます。

売却前90日で進める技術DD準備

90日は、システムを全面刷新する期間ではありません。重要な不確実性を見つけ、重大な穴を緩和し、残りを測定可能な計画へ変える期間です。事業、技術、法務、人事、財務を横断する責任者を置き、通常の顧客対応と開発を止めない稼働配分を決めます。SaaS売却の一般的な流れと技術準備を同じ日程で管理します。

1～30日：棚卸しと緊急リスクの封じ込め

最初の10日で、製品、リポジトリ、クラウド、SaaS、ドメイン、データストア、外部API、人員、契約を棚卸しします。請求明細、DNS、IdP、Git組織、クラウド組織を起点に、台帳漏れを探します。構成図とデータフローは現行本番を描き、将来像を別にします。各資料に所有者と基準日を付けます。

同時に、ルート・管理者MFA、退職者アカウント、公開ストレージ、漏えい秘密、期限切れ証明書、バックアップ失敗、重大既知脆弱性を確認します。顧客影響が高いものは、DD資料作成より先に封じ込めます。大きな変更は障害を招くため、変更管理、バックアップ、ロールバックを必ず用意します。

11～20日で、過去の事故、障害、診断、顧客質問票、監査、保険請求を収集します。表現と件数定義を統一し、未完了対策を台帳へ入れます。外注・退職者のコード権利、個人名義アカウント、共有資産を法務と確認します。重大な権利不足は、補完契約に時間がかかるため早く着手します。

21～30日で、RTO・RPO、SLA、容量、クラウド費、開発KPIの現状を測ります。証拠がないものは「未検証」とし、次の30日で行う試験を決めます。最初のリスク委員会でRed/Amber/Greenを暫定判定し、経営者が予算、開示、優先順位を承認します。

31～60日：実測、再現、契約との照合

クリーン環境でビルド・デプロイを再現し、バックアップから復元します。主要機能の負荷試験、テナント分離テスト、権限レビュー、秘密スキャン、依存関係スキャンを実施します。外部診断を行う場合、対象、認証済み範囲、API、クラウド、再診断を合意します。結果は買い手へ渡す前に事実確認し、改変せず原本と是正状況を分けます。

SBOMを生成し、成果物と照合します。ライセンス台帳、NOTICE、商用部品契約を法務と確認します。データマップを実通信、クラウド設定、再委託先一覧と突合し、保持・削除テストを行います。AI機能は、外部提供者の契約、入力保存・学習利用、データ来歴、評価結果を揃えます。

技術負債を事業影響へ翻訳し、必須是正、維持、高度化、統合に分けます。見積り幅、前提、担当能力、顧客停止を付けます。過去12か月の障害、変更、クラウド費、開発稼働を使い、買い手の事業計画へ入力できる数字にします。

この期間に、別担当者がRunbookでデプロイ、ロールバック、復元、顧客設定を実行します。失敗した手順を直し、再実行します。キーパーソンの知識移転計画と、買収後の役割案を作りますが、従業員への伝達時期・方法は機密保持と労務を考慮して専門家と決めます。

61～90日：買い手説明、Day1、契約処理へつなぐ

データルーム索引、Q&A、リスク台帳、マネジメントプレゼンテーションを完成させます。想定買い手別に、統合する領域、一定期間独立運用する領域、共有資産、TSAを整理します。買い手の標準が不明な時点で過剰に作り替えず、選択肢と依存関係を用意します。

Day1のアクセス、緊急連絡、ログ保全、リリース凍結、顧客対応を机上演習します。ドメイン、証明書、アプリストア、クラウド契約の移管は、提供者の審査と期間を確認します。変更できないアカウントは、新設・移行、TSA、再契約のどれかを決めます。

未解決Redは、クロージング前条件、価格、特別補償、エスクロー、TSA、案件範囲除外の候補として法務・FAへ渡します。技術チームが契約文言を単独で決めず、事実、影響、是正可能性を正確に提供します。通常の将来改善まで過度な表明保証に入らないよう、現状の開示と約束を区別します。

最終週には、資料の基準日を更新し、新しい事故、脆弱性、退職、クラウド変更がないか確認します。署名・クロージングの間が長い場合、定期更新と通知基準を合意します。DDは一度提出して終わる静止画ではなく、クロージングまで更新される管理プロセスです。

Day1と買収後100日の技術PMI

良い技術DDは、指摘一覧で終わらずPMIの入力になります。Day1にすべてを統合すると障害が起き、何も変えなければリスクが残ります。顧客継続、証拠保全、支配権、重大リスクを最初に守り、アーキテクチャ刷新やツール統一は事業優先度で段階化します。

Day1：止めない、失わない、誰が決めるかを明確にする

• 重大インシデントの指揮系統、24時間連絡、顧客・法務・広報への経路を一本化する。
• クラウド、Git、IdP、DNS、監視、アプリストアの管理権限を確認し、監査ログを保全する。
• 買収直前の構成、コード、SBOM、バックアップ、鍵、資産台帳のスナップショットを保存する。
• 危険な共有ID・退職者権限を止める一方、サービスアカウントを無計画に失効しない。
• リリース凍結の有無、緊急修正の承認、顧客問い合わせの担当を周知する。
• 買い手・売り手の方針が異なる領域は、暫定ルールと終了期限を定める。

Day1にブランドやログインを変える必要がなければ、顧客影響の少ない統制から始めます。セキュリティツールを二重導入する場合、アラートの責任と費用を決めます。TSAを使う共有基盤は、アクセス、SLA、変更、事故、終了支援を運用レベルへ落とします。

1～30日：事実を再検証し、優先順位を共同で決める

DDは限定アクセス・短期間で行われるため、取得後に本番権限で資産と設定を再確認します。買い手の基準を機械的に当てる前に、顧客契約、システム依存、売り手の運用理由を理解します。Red課題の緩和、キーパーソン面談、復元演習、費用ベースラインを優先します。

統合アーキテクチャの原則を決めます。製品を独立成長、API連携、共通基盤化、機能吸収、段階終了のどれにするかで、ID、データ、請求、監視、人員の計画が変わります。法人統合とプロダクト統合を同じ日程にしません。

31～60日：共通統制と顧客価値の接点を作る

IdP、端末、特権管理、脆弱性、インシデント、委託先、データガバナンスの共通ルールへ移行します。売り手側の優れた運用を捨てず、買い手標準との差を比較します。例外は期限付きで承認し、顧客専用環境や旧技術を誰が支えるか決めます。

営業シナジーを技術へ落とします。SSO、API、データ連携、共通請求、クロスセルの最小実装を選び、セキュリティ・プライバシー・テナント分離を設計します。売上目標だけ先に置かず、統合開発と顧客移行の容量をロードマップへ入れます。

61～100日：投資判断と継続KPIを確定する

技術負債の必須是正、成長投資、統合費を再見積りし、経営会議で予算化します。中止する開発、維持する差別化、共通化する基盤を決めます。クラウド単位原価、変更リードタイム、障害、脆弱性、RTO実測、顧客移行、キーパーソン残留を継続KPIにします。

100日は完了日ではありません。複数年の刷新を無理に「完了」にせず、次四半期の成果、責任者、残留リスクを取締役会へ報告します。DD時の約束、売買契約の誓約、顧客通知、TSA終了条件を同じ台帳で追います。

成約を止めやすい技術論点と現実的な是正

技術課題の多くは、発見しただけで案件を止めるものではありません。止まりやすいのは、事業継続や権利に重大な影響があるのに、事実が不明、説明が変わる、担当と期限がない場合です。以下は一般論であり、案件ごとの重要性は顧客、契約、データ、取引構造で変わります。

是正の優先順位は、見栄えではなく顧客・取引リスクで決めます。コードフォーマット統一より、管理者MFA、権利、復元、テナント分離が先になることがあります。短期間で無理な刷新を行い、本番障害を起こす方が危険です。暫定緩和と恒久対応を分け、変更管理の下で進めます。

技術DDセルフチェック｜評価点より説明可能性を見る

次の質問に「はい」と答えられるかだけでなく、第三者が確認できる証拠があるかを見てください。点数は法令適合、安全性、成約、評価額を保証しません。未確認をゼロ点として責めるのでなく、確認順序を決めるために使います。

1. 全リポジトリ、クラウド、SaaS、ドメイン、証明書を法人名義と請求へ一致させている。
2. 外注・退職者を含むコード、データ、デザイン、モデルの権利帰属を原本で示せる。
3. 現行本番の構成図とデータフローに、テナント境界、国、外部委託を記載している。
4. ルート・管理者、共有ID、サービスアカウント、秘密、退職者を定期レビューしている。
5. 顧客契約のSLAと、実測稼働率、RTO・RPO、復元試験が整合している。
6. クリーン環境からビルド、テスト、デプロイ、ロールバックを再現できる。
7. 重大変更に脅威モデル、レビュー、テスト、承認を適用し、例外を記録している。
8. 脆弱性を継続検知し、到達性と事業影響で優先付け、再テストしている。
9. ログから管理者・顧客データの重要操作を追跡し、改ざん・過剰記録を抑えている。
10. SBOMとライセンス台帳をリリースへ結び、通知・脆弱性対応を更新している。
11. 個人データの収集から削除まで、利用目的、委託先、国、保持を説明できる。
12. AIモデル、外部API、学習・評価データ、プロンプト、出力監視を台帳化している。
13. 過去事故の影響、通知判断、根本原因、再発防止を時系列で提示できる。
14. 主要運用を二人以上が実行し、キーパーソン不在の演習を行っている。
15. 技術負債を売上保全、成長、粗利、開発、人材へ翻訳し、費用幅を示している。
16. Day1の権限・連絡・ログ保全と、100日の統合ロードマップを分けている。

12項目以上でも重大な一件が案件を左右する場合があり、8項目でも短期間で改善できる会社があります。合計点より、Red課題の数、顧客影響、是正可能性、説明の一貫性を見ます。自社の準備状況を案件化前に整理したい場合は、SaaS事業の価値チェックも活用し、財務KPI・契約・株主と技術を一緒に確認してください。

SaaS売却で技術DDを価値の証明に変える

技術DDは守りだけではありません。安定したテナント分離、短い復旧時間、再現可能な開発、顧客別単位原価、データ来歴、更新されたSBOM、代替可能な運用は、買い手が成長投資を実行できる根拠です。とくに、買い手の顧客基盤へ展開するときの容量、統合API、セキュリティ要求を先に示せれば、シナジーを抽象論から実行計画へ変えられます。

一方で、技術だけを整えても取引は成立しません。ARR・解約・粗利、顧客契約、知財、個人データ、株主、税務、人材条件と結合する必要があります。SaaS事業の売却支援では、売却を決める前の準備から、候補先、DD、条件交渉、PMIを一続きで考えることが重要です。

よくある質問

出典・参考資料

本記事は、以下の一次・公的資料を中心に参照しました。規格、法令、ガイドライン、提供サービスは更新されます。実案件では必ず最新版、原文、適用範囲を確認してください。

1. IPA「非機能要求グレード2018」紹介・ダウンロード。非機能要求項目、段階的な要求レベル、グレード表・項目一覧・樹系図・活用シート等。
2. NIST SP 800-218, Secure Software Development Framework Version 1.1。Prepare、Protect、Produce、Respondの四群からなるセキュア開発実務。
3. NIST Cybersecurity Framework 2.0。Govern、Identify、Protect、Detect、Respond、Recoverの六機能によるサイバーリスク管理。
4. 経済産業省「サイバーセキュリティ経営ガイドライン Ver.3.0」。経営者が認識する三原則と重要10項目。
5. 経済産業省「ソフトウェア管理に向けたSBOM導入に関する手引 Ver.2.0」公表ページ。脆弱性管理、導入範囲、取引・契約上の論点。
6. 個人情報保護委員会「個人情報保護法ガイドライン（通則編）」。安全管理措置、従業者・委託先監督、事業承継、外的環境の把握等。
7. 個人情報保護委員会「外国にある第三者への提供編」。外国にある第三者、委託・再委託等に関するガイド。
8. SPDX License List。標準的なライセンス識別子、名称、本文、恒久URL。
9. Open Source Initiative, OSI Approved Licenses。OSI承認済みライセンスの公式一覧。
10. 経済産業省「AI事業者ガイドライン」。AI開発・提供・利用に関するリスクベースの取組。
11. 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等」。

まとめ

SaaS M&A 技術DDの本質は、コードを採点することではなく、顧客価値を生む技術資産を、権利と運用を含めて安全に引き継げる状態へすることです。コード、クラウド、IAM、テナント分離、RTO・RPO、ログ、脆弱性、CI/CD、OSS・SBOM、個人データ、AI、キーパーソン、技術負債を、事業計画と顧客影響へ結び付けてください。

完璧なシステムを演出する必要はありません。既知の課題を一貫して開示し、証拠、暫定措置、恒久対応、費用、期限、責任者を示すことが、買い手の不確実性を下げます。売却しない場合でも、90日準備で作る資産台帳、復元記録、権限レビュー、データマップ、SBOM、属人性対策は、通常の経営品質を高めます。

SaaS M&Aセンターでは、技術だけでなく、財務KPI、契約、株主、候補先、条件、PMIを含めて売却準備を整理します。相談時点で診断や資料が完成している必要はありません。どこから確認すべきかを明確にするところから始められます。