AI固有デューデリジェンスの評価項目：moat・モデル依存・データ権利・eval体制

買収候補のAIスタートアップからデモを見せてもらった。応対の草案が数秒で生成され、社内ナレッジをまたいだ検索も的確に効く。会議室では「これは強い」と全員がうなずいた。しかし帰りの電車で、技術に明るい部長がぽつりと言う。「あれ、外部のAIをそのまま呼んでるだけだったら、うちが同じものを3か月で作れませんかね」。誰も即答できない。デモの画面は本物の強みなのか、それとも海外の基盤モデルにきれいな皮をかぶせただけなのか。そこが分からないまま、数億円の判断が近づいてくる。

AI SaaSの買収では、通常のソフトウェアデューデリジェンス（コード品質・体制・セキュリティ・契約）に加えて、AI特有の論点を別枠で見る必要がある。参入障壁（moat）が本物か、基盤モデルへの依存がどれだけ危ういか、学習に使っているデータの権利は適法か、モデルが更新されたときに品質を守れる検証（eval）の仕組みがあるか。この4点はプロダクトのデモを何時間眺めても表に出てこない。AIテックデューデリジェンスでは、まさにこの見えない層をコードと規約と面談から確かめる。非エンジニアの買い手が自分で最低限おさえておくための評価項目を、危険な兆候と具体的な質問まで落として整理していく。

AI固有で見るべき4項目を一枚で

まず全体像を早見表にする。左から「項目」「何を見るか」「危険な兆候」。ここで自社の候補企業を当てはめ、赤信号が灯る列を先に見つけてほしい。詳しい読み方はこの後の各節で補う。

moatが本物か：デモではなく「模倣コスト」で測る

moatの判定は「すごいかどうか」ではなく「自社が同じものを作るのに、何を、どれだけ集める必要があるか」で考えると外しにくい。基盤モデルを呼ぶだけの機能は、競合も数か月で並べる。逆に、長年ためた業務データや、そのドメインでしか作れない検索評価データセット、現場のワークフローに深く埋め込まれた導線は、後発が金で買えない。ここが厚いほど買収価値は高い。

具体的に見る対象は3つに絞れる。ひとつは独自データの規模と鮮度で、たとえば「12万ペアの検索評価データがあり、自社顧客の実応対から継続的に増えている」なら模倣コストは高い。ふたつめは基盤モデルの出力に足している後処理で、自社学習したリランカーや独自の検索ロジックが挟まっていれば、それは技術資産になる。みっつめは乗り換えコストで、顧客の業務手順に組み込まれているほど、競合が同機能を出しても離脱は起きにくい。この3つのどれも薄いなら、そのプロダクトは「基盤モデルの薄いラッパー」に近い。

基盤モデル依存：単一依存そのものより「抽象化層の有無」

AIプロダクトが外部の基盤モデルを使うこと自体は普通で、そこを責めても意味がない。問題は依存の「構造」にある。危ういのは、特定の海外大手1社のAPIを呼ぶコードがアプリ全体に直接散らばっていて、モデルを差し替える緩衝材（抽象化層）が無い状態。この構造だと、提供者の値上げ・仕様変更・提供終了がそのまま事業に直撃し、対応は全面改修になる。

買い手が確かめるのは「単一のモデルに寄っているか」と「その依存が1か所に閉じているか」の2軸だ。単一依存でも、モデル呼び出しが1つの層に集約されていて差し替えが設定変更で済むなら、リスクは管理できる。逆に複数モデルに対応していても、それが場当たりの分岐でコードに散っているなら保守は重い。抽象化層の有無は、開発責任者に「モデルを別提供者に替えるとき、どのファイルを何行いじりますか」と聞けば数分で見当がつく。「全部です」に近い答えなら、後述の是正費用を見込んでおく。

データ権利：学習に使う同意が「適法に取れているか」

AI SaaSは顧客データを使ってモデルや検索を改善することが多い。ここで見るのは、その二次利用の根拠が利用規約や同意で適法に取れているか。よくあるグレーは、規約に「サービス改善に利用することがある」とだけ書き、学習利用の明示もオプトアウト手段もないケース。実務では動いていても、買収後に顧客から問われたり規約を締め直したりする場面で、無償だったデータ活用に急ブレーキがかかる。プロダクトの強みが独自データにあるほど、この一文の弱さは価値の根を揺らす。

非エンジニアの担当でも確認はできる。「学習・改善にどのデータを使っていますか」「その根拠は規約のどの条項ですか」「顧客が拒否する手段はありますか」の3つを並べて聞き、規約の実物と突き合わせる。答えと文言がずれるなら黄信号として記録し、法務と是正の要否を詰める。ここは技術者観点で論点を洗い出す領域で、最終的な適法性の判断は専門家に委ねるのが筋になる。

eval体制：モデル更新で品質が落ちないと言い切れるか

基盤モデルは提供者側の都合で更新される。プロンプトを直すこともある。そのたびに出力の質が下がっていないかを機械的に確かめる仕組みが回帰evalだ。これが無いと、ある日の更新で回答精度が静かに劣化し、解約が増えて初めて気づく、という事態が起きる。買い手として見るのは、評価用のデータセットがあるか、指標と合格ラインが決まっているか、更新時に自動で回る運用になっているか。

危険なのは「担当者が更新のたびに手で数件試して問題なさそうなら出す」という運用。属人的で再現性がなく、担当者が抜けたら品質保証そのものが消える。eval体制の欠如は多くの場合ディールブレーカーではなく、買収後に整備すべきPMI課題として費用計上する対象になる。

サンプル案件で4項目を通してみる

ここからはサンプル案件で流れを追う。登場する企業も数値もすべて架空だが、AI固有DDで実際に起きる見え方を再現している。対象はコンタクトセンター向けのRAG型応対支援SaaS（回答草案の生成・ナレッジ検索・応対要約）。ARR約1.84億円、顧客62社、月次解約率0.8%、NRR108%と、事業として顧客に定着した優良プロダクトだった。デモの印象は良く、初見では「薄いラッパー」には見えない。

実際にコードと規約を読むと、moatは存在した。検索評価データセットが12万ペアあり、基盤モデルの出力に自社学習した軽量リランカーを重ねていた。ここは薄いラッパーではない。しかし、その基盤モデルは海外大手1社のAPIに単一依存で、呼び出しを吸収する抽象化層がなかった（F-01）。加えて、顧客データの学習利用の根拠が包括同意のみでオプトアウトを欠く規約上のグレー（F-02）、そしてモデル更新時の回帰evalが存在しない（F-05）。moatは黒でも、依存とデータ権利とeval体制で黄信号が並んだ。総合はディールブレーカーなしの「条件付き推奨」に落ち着いた。

主要な発見と是正費用のレンジをサンプル案件の数値で示す。金額はあくまでこのサンプルでの見積で、実案件は個別に変わる。

基盤モデル依存が単なる「単一依存」ではなく「単一依存かつ抽象化層なし」で赤になった点に注目してほしい。同じ単一依存でも、差し替えが1か所で済む構造なら判定は軽くなる。危険を決めるのは依存先の数ではなく、依存の閉じ込め方だった。

モデル値上げが粗利をどれだけ削るか

基盤モデル依存の怖さは、原価構造に効いてくる。サンプル案件では推論原価がARR比23%を占め、粗利率は約65%だった。ここで基盤モデルのAPI価格が動いたときの感応度を試算すると、価格が現状から30%上がると推論原価はARR比29.9%に膨らみ、粗利率は約58%へ下がる。粗利で約7ポイントの悪化だ。抽象化層がなく他モデルへ逃げられない状態では、この値上げを事業側でほぼ吸収するしかない。moatが本物でも、依存構造が原価の自由度を奪っていた。

この試算はサンプル案件の前提（推論原価ARR比23%、粗利率65%）に基づく一例で、感応度の効き方は原価構造ごとに変わる。ただ「基盤モデルの価格改定が粗利に直結する」構造は、単一依存かつ抽象化層なしのAI SaaSに共通する。デモの画面では絶対に見えない、しかし買収後の利益を左右する層になる。

買い手が現場で使える確認質問リスト

専門家に依頼する前でも、初期の面談でこの質問を投げれば、そのプロダクトの地肌が見えてくる。相手の答え方（即答か、言葉を濁すか、規約の実物を出せるか）そのものが判断材料になる。

この4問で言葉が濁った項目は、そのまま詳細調査の起点にする。コードや規約に踏み込む段階では技術者観点の目利きが要るが、入口の見立てはこの質問だけでも十分に立つ。

よくある質問（FAQ）

基盤モデルを外部APIに頼っているAI SaaSは、買ってはいけないのですか

外部の基盤モデルを使うこと自体は今のAI SaaSでは一般的で、それだけで減点にはなりません。見るべきは依存の構造です。単一提供者に寄っていても、モデル呼び出しが1つの層に集約されていて差し替えが局所で済むなら、リスクは管理できます。危ういのは、呼び出しがコード全体に散らばり抽象化層がない状態で、値上げや仕様変更が全面改修に直結する場合です。

「薄いラッパー」かどうかは、非エンジニアでも見分けられますか

入口の見立てなら可能です。「基盤モデルの出力に独自で足している処理やデータは何か」「それを他社が再現するには何が要るか」を面談で聞き、独自データや自社学習の後処理を具体的に説明できるかを見ます。ここが薄いと基盤モデルの薄いラッパーに近くなります。ただし、その回答が実装と一致しているかはコードを読まないと確認できないため、判断の裏取りは技術DDで行います。

回帰evalが無いと、それだけで買収を見送るべきですか

多くの場合はディールブレーカーではなく、買収後に整備するPMI課題として費用計上する対象になります。サンプル案件でも回帰evalの不在は黄判定で、是正費用を見込んだうえで条件付き推奨に含めました。見送りを検討するのは、中核技術が実は外部依存で資産価値が無い、データの権利関係が修復困難、といったより重い発見が重なった場合です。

この評価は自社だけで完結できますか

面談での初期の見立てまでは自社で立てられます。一方、moatの裏取り（コードと独自データの精読）、依存構造の実測、規約と実装のずれの洗い出し、原価感応度の試算は、AI固有の評価経験がないと質問設計の段階から手探りになりがちです。社内エンジニアで内製すると評価設計から報告書まで概ね2.5人月ほどかかり、その間は本業の開発が止まります。専門家に出すか社内で抱えるかは、品質と本業への影響で比べるのが現実的です。

デモの向こう側を確かめてから、判断する

moatが本物か、依存が閉じ込められているか、データの根拠が適法か、更新で品質を守れるか。この4層はプロダクトの画面には映らず、しかし買収後の利益と安全に直結します。AIテックデューデリジェンスでは、コードと規約と面談から4層を確かめ、発見を是正費用と価格調整のレンジに翻訳して、経営が社内を説得できる形で渡します。「デモは良かったが、薄いラッパーかどうかだけ先に見立ててほしい」という段階からで大丈夫です。買収検討の初期に、DDが必要な案件かどうかの見立てからご相談ください。

あわせて読みたい

• AIテックデューデリジェンス完全ガイド：買収前にAIの中身をどう見極めるか
• テックDDチェックリスト：買い手が最初に確認する技術論点
• AIスタートアップの原価構造を読む：推論コストとモデル価格改定リスク
• コード品質と技術的負債の評価：静的解析・テスト・キーパーソン集中
• DDからPMIへ：技術の発見事項を100日統合計画に落とす