LOIを交わし、対象はAI応対支援のSaaS。プロダクトのデモは驚くほど滑らかで、経営会議でも評判は上々です。財務DDは会計士が、法務DDは弁護士が回している。ところが技術の中身については、誰も見ていない。デモの裏側でどんなモデルが動き、そのモデルは誰のものか、開発を支えているのは何人なのか。質問しようにも、何を聞けばいいのかが分からない。

買い手として一番怖いのは、契約書に判子を押したあとで「実は中核技術が外部依存で、価格の根拠が崩れていた」と気づくことです。AIテックデューデリジェンス(AI Tech DD)は、この見えない部分を技術者の目で先に開けておく調査です。何を・どの順で調べ、どう評価し、その結果を価格交渉と買収後の統合(PMI)にどうつなげるか。この記事で全体像を通しでたどります。より詳しいサービス内容はAIテックデューデリジェンスのページにまとめています。

財務DDと法務DDでは、なぜAIの中身が見えないのか

財務DDは決算数値の正しさを、法務DDは契約や許認可の適法性を確かめます。どちらも過去の「結果」を検証する仕事で、非常に重要です。しかしAIプロダクトの価値は、決算書に載らない場所に宿っています。推論を支える基盤モデルが自社のものか他社からの借り物か。学習に使ったデータを本当に使ってよかったのか。開発が特定の一人に依存していないか。これらは仕訳にも契約書にも現れません。

たとえば「粗利率65%」という数字が財務DDで確認できたとして、その原価の中身が外部APIの従量課金なら、提供元が価格を上げた瞬間に粗利は崩れます。財務DDは「今の数字が正しいか」を見ますが、AIテックDDは「その数字が明日も続くのか」を技術構造から見ます。守備範囲が重なっていないので、片方だけでは判断材料が足りません。

テックDDで開ける7つの領域と、信号機での見立て

AIテックDDは、対象の技術を7つの領域に分けて調べます。各領域を緑・黄・赤の信号機で評価するのが実務のコツです。緑は問題なし、黄は買収後に手当てが要る(PMI課題)、赤は価格や契約条件に反映すべき論点、という共通言語をつくると、非エンジニアの経営陣とも同じ絵を見て話せます。それぞれの領域で「具体的に何を見るのか」を先に一覧にします。

領域この領域で見ること赤信号の例
アーキテクチャ・技術スタック構成が拡張に耐えるか、負債の量、モジュール分離の度合いスケール時に作り直しが必要な密結合
AI固有リスク独自の強み(moat)の有無、基盤モデルへの依存、学習データの権利、eval体制単一の外部モデルに抽象化層なしで直結
コード品質・開発プロセス静的解析の重大指摘、テスト網羅、レビュー文化、CI/CDCritical指摘が放置、テストがほぼ無い
セキュリティデータ分離、認証認可、prompt injection対策、脆弱性管理顧客データが共有領域で混在している
インフラ・原価構造推論原価のARR比、クラウド費、モデル価格改定への感応度推論原価が高く、価格改定で粗利が急落
組織・キーパーソンコミット分布、バス係数、採用・定着、ドキュメント整備中核の開発が特定1名に集中
規制・コンプライアンスデータ二次利用の同意、認証取得、ライセンス適合同意設計が包括的すぎて是正が要る

信号機の色は、そのまま次のアクションに翻訳します。赤は「価格を下げるか、売り手に直させてから買うか」の判断へ。黄は「買った後に自分たちで直す前提で、費用を予算化しておく」対象へ。緑は「安心して評価根拠にできる」材料へ。全部を減点で見るのではなく、色ごとに打ち手を決めるための地図として使います。

AI固有の4つの論点は、なぜ他のDDで抜け落ちるのか

7領域のうち、AIプロダクト特有で、かつ他のDDから最も抜け落ちやすいのが次の4つです。デモの滑らかさとは無関係に価値を左右するため、技術者が意図して開けにいかないと見えません。

独自の強み(moat)が本物か、見た目だけか

外部モデルのAPIを呼ぶだけの「薄いラッパー」なら、同じものを誰でも数週間で作れます。逆に、自社で集めた評価データや独自にチューニングした検索の仕組みがあれば、それは簡単に真似できない資産です。ここの見極めは、デモを何回触っても分かりません。コードとデータの中を見て初めて判別できます。

基盤モデルへの依存が、原価と継続性のリスクになっていないか

推論を海外大手1社のAPIに単一依存し、モデルを差し替えられる抽象化層が無い場合、提供元の値上げや仕様変更が直撃します。原価が上がるだけでなく、最悪は提供停止で事業が止まる。財務の数字が良く見えていても、この一点で評価は変わります。

学習に使ったデータを、本当に使ってよかったのか

顧客データをモデルの改善に使っている場合、その同意が利用規約でどう取れているかが論点になります。opt-outの導線が無い包括同意だけだと、買収後に是正や説明責任が発生しかねません。これは技術者観点での論点指摘であり、最終的な法的判断は専門家と組みますが、そもそも「どこにその論点があるか」はコードとデータの流れを追わないと浮かびません。

品質を測る仕組み(eval)があるか

AIの出力品質は、モデルやデータを変えるたびに揺れます。回帰evalの仕組みが無いと、改善したつもりが劣化していても気づけません。買収後に開発を引き継いだ途端、品質が担保できなくなる典型的な原因がここです。evalの有無は、その会社が本気でAIプロダクトを運用してきたかの試金石にもなります。

サンプル案件で見る:発見から価格調整までの流れ

抽象論だけでは伝わりにくいので、当社の架空サンプル案件で通して見せます。対象は株式会社ツギテ(コンタクトセンター向けRAG型応対支援SaaS、ARR1.84億円、顧客62社)。買い手は中堅SIerという設定です。実働14営業日、面談6本、全4リポジトリ約14.6万行のうち約18%を精読しました。総合結論は条件付き推奨で、ディールブレーカー該当なし。ここで挙げる数字はすべて「サンプル案件では」の前提で、効果を保証するものではありません。

7領域の信号機はこう並びました。強い部分と手当てが要る部分が同時に見えるのがテックDDの姿です。公平のために書き添えると、このサンプルは月次解約率0.8%・NRR108%と、プロダクトが顧客業務に定着している優良な事業でもあります。

領域信号主な理由
アーキテクチャ・技術スタックモジュラー構成で拡張性は良好
AI固有リスク薄いラッパーではないが単一モデル依存+学習利用の規約グレー
コード品質・開発プロセス静的解析Critical3件、テスト整備不足
セキュリティベクタ索引の共有namespace、prompt injection対策の欠如
インフラ・原価構造推論原価ARR比23%、モデル価格改定への感応度が高い
組織・キーパーソンコミット71%がCTOに集中、検索パイプラインはバス係数1
規制・コンプライアンス顧客データ二次利用がopt-out欠如の包括同意のみ

この信号機のうち、価格に反映すべき赤級の論点が4件出ました。それぞれに是正費用の見積を付けます。是正費用は「買った後に直すのにいくらかかるか」で、価格に反映するか、クロージング前に売り手負担で直してもらうか(誓約事項)を選ぶための数字です。

発見事項区分是正費用の見積
F-01 単一基盤モデル依存×抽象化層なし赤・価格調整材料1,200〜1,800万円
F-02 顧客データの学習利用が規約上グレー赤・価格調整材料600〜1,000万円
F-03 AGPLライブラリ1件の混入赤・価格調整材料300〜500万円
F-04 コミット71%がCTOに集中/バス係数1赤・価格調整材料1,000〜2,000万円
是正費用の直接見積 合計(F-01〜F-04)3,100〜5,300万円

価格調整は、是正費用だけでは終わりません。直す費用に加えて、リスクが顕在化したときの損失見合い(モデル価格改定で原価が膨らむ、規約問題で解約が出る、キーパーソン退職で開発が止まる)を上乗せして幅で示します。サンプル案件では、是正費用3,100〜5,300万円とリスク見合い4,900〜8,700万円を合わせ、価格調整インパクトの概算は▲8,000〜14,000万円(▲0.8〜1.4億円)となりました。交渉で満額が通るわけではありませんが、仮に下限の半分でも数千万円で、これが根拠のある交渉材料になります。

原価の感応度も数字で押さえておきます。サンプル案件では推論原価がARR比23%、粗利率65%。ここで基盤モデルの価格が動くと粗利がどう振れるかを見ておくと、「明日も続く数字か」の判断ができます。

モデル価格の変化推論原価のARR比粗利率
▲30%(値下がり)16.1%71.9%
現状23.0%65.0%
+30%(値上がり)29.9%58.1%

モデル価格が+30%動くと粗利は約7pt悪化します。単一モデルに直結している以上、この振れは事業のものではなく提供元の都合で起きる。だからこそF-01の「抽象化層なし」が赤なのだと、数字と構造が一本の線でつながります。

社内エンジニアで内製する場合と比べてどうか

「技術DDくらい社内のエンジニアでやれないか」という声はよく出ます。試算してみると、内製が安いとは限りません。評価設計・コード調査・面談・報告書作成で、概ね2〜3名×3〜4週間、約2.5人月かかります。年収800万円のエンジニアを会社総コスト(給与の約3倍で人月約200万円)で換算すると、およそ500万円相当です。

金額が近くても、中身は大きく違います。内製ではその間、本業の開発が止まります。さらにAI固有の論点(moat判定、データ権利、モデル依存、eval体制)は、評価の経験が無いと質問リストの設計から手探りになり、肝心の赤信号を見落としがちです。費用が大差ないなら、本業を止めず、見立ての精度で差が出る外部の目を使う判断が立ちます。

見つけた発見を、交渉と統合にどう使うか

DDは報告書を受け取って終わりではありません。発見事項は、買収の3つの場面でそのまま道具になります。読んで終わりの報告書ではなく、後工程の作業物として使える形にしておくのが実務のポイントです。

使う場面発見の使い方サンプルでの具体
価格交渉是正費用とリスク見合いを根拠に価格調整を提示▲0.8〜1.4億円の調整レンジを算定根拠つきで提示
表明保証・誓約(SPA)赤の論点を売り手負担での是正条件や表明保証に落とす規約是正・ライセンス置換をクロージング前の誓約事項に
PMI 100日プラン黄の課題を買収後100日の優先順位つき作業計画に抽象化層導入・回帰eval整備・キーパーソン対策を計画化

減点調査に見えるDDですが、同時に「買収後の打ち手リスト」でもあります。サンプル案件では、面談から「ISMS未取得で年3件のエンタープライズ商談を失注している」という事実が出ました。平均単価297万円で換算すると約900万円/年の売上機会、粗利率65%で約580万円/年の利益貢献に相当します。認証取得の見積は800〜1,200万円。DDは「買った後に何をすれば伸びるか」まで示せる調査です。

よくある質問(FAQ)

財務DD・法務DDをやっていれば、テックDDは要りませんか

守備範囲が違います。財務DDは過去の数値の正しさ、法務DDは契約や許認可を確かめる調査で、いずれも重要です。ただしAIプロダクトの価値を左右する基盤モデルへの依存、学習データの権利、開発の属人性、品質を測る仕組みの有無は、そのどちらにも現れません。財務の数字が良くても、原価が外部APIの従量課金なら提供元の値上げで粗利が崩れます。技術構造からその継続性を見るのがテックDDの役割です。

調査にはどれくらいの期間がかかりますか

調査範囲によりますが、1案件あたり実働2〜4週間が目安です。サンプル案件では実働14営業日、面談6本、コード精読は全体の約18%でした。デモを触るのではなく、実際のコードとデータの流れ、コミット履歴、原価構造まで踏み込むため、この程度の期間を確保します。買収検討の初期段階なら、そもそもDDが必要な案件かどうかの見立てから相談していただけます。

技術に詳しくないのですが、報告書を読めますか

非エンジニアの経営企画・投資担当が読んで判断できる形にします。各領域を緑・黄・赤の信号機で示し、赤は価格や契約条件に、黄は買収後の予算に、緑は評価根拠にと、色ごとに次のアクションへ翻訳します。価格調整レンジや是正費用は金額の幅で提示するので、社内や経営会議での説明にそのまま使えます。

売り手側(売却を検討する立場)でも使えますか

使えます。売却前に自社へ同じ調査をかけて指摘事項を先に是正しておけば、買い手からの値引き要求を抑え、売却額を守りやすくなります。買い手向けと売り手向けで成果物の作り方は共通です。どちらの立場かを最初にお聞かせいただければ、調べる順序と報告の重点を合わせます。

中身を開けてから、判子を押すために

「デモは滑らかなのに、技術の中身は誰も見ていない」という不安を抱えたまま億単位の決断をするより、先に開けて色分けしてから交渉に臨むほうが、買い手として立場が強くなります。当社は、その技術の目利きと、経営が動ける形への翻訳を一緒に行います。サービスの詳細はAIテックデューデリジェンスのページに、サンプル報告書とあわせてまとめています。

いま検討中の案件が「そもそもテックDDをかけるべき案件か」の見立てだけでも構いません。30分の初回相談(無料)で、どこを開けるべきかの当たりから一緒に付けていきます。買収の初期段階ほど、開けておく価値があります。

あわせて読みたい

なぜテックDDが要るのか(背景の必読記事)