中小企業・スタートアップのM&A DD設計｜大手に頼らない自走DDの作り方

筆者が相談を受ける案件でも、ここ数年は中堅・中小企業やスタートアップが当事者となるM&Aが目立ってきました。かつては大企業が主役という印象だった取引の相談が、今は筆者の周辺でもそうした規模の会社から寄せられることが増えている、という肌感覚です。事業承継、競合対策、成長の加速——理由はさまざまですが、M&Aの実務、とりわけデューデリジェンス（DD）の部分で詰まってしまうケースが目立ちます。

理由はシンプルです。DDは本来、複数の専門領域にまたがる調査と判断の連続です。ビジネス・財務・法務・ITの各観点から対象会社を掘り下げ、見逃せないリスクを洗い出す。これを限られた期間と人員でこなすのは、社内にDDを「型」として持っている組織でなければ、想像以上に消耗します。

「どちらでもない選択肢」は、設計次第で作れます。コストの問題ではなく、DDの工程をどう割り振るかの問題です。その実務的な考え方を中心に書きます。

多くの企業でDD実務が曖昧に終わる背景には、構造的な問題があります。意欲や準備の問題ではなく、そもそも「何を、どこまで調べれば判断できるか」の設計が最初からない状態でスタートしてしまうことが根本にあります。

担当者がDD経験を持たないままゼロから始めると、「何を見れば十分か」の基準がないまま膨大な資料を抱えて時間切れになります。財務は専門家に任せたが、ビジネスの評価は「感覚」で進めた——後からビジネスモデルの構造的な問題が浮かんでくるのは、このパターンです。

もう一つよく聞くのが、質問票（IRL）を作ったことがなく、対象会社に「何を聞けばいいか分からない」状態で交渉が進んでしまうケースです。IT系のDDをほぼ省略した結果、買収後にシステムの老朽化や外部ベンダー依存が表面化する——こちらも、中小企業の案件で繰り返し見てきた光景です。

自社対応のDDにかかるコストは、給与換算すれば数十万円に見えることがあります。ただ、それは見えている部分だけです。

表面に出てこないコストの実態

• 担当者の兼務負荷：通常業務を抱えながらDDに対応する場合、どちらも中途半端になりやすい。M&Aの担当者として業務に集中できない期間に生じる機会損失は、金額として見えにくいが実際には大きい
• 論点の見落としコスト：調査経験がない担当者が見落とした論点は、買収後に「発見」される。その対応費用は、DDを適切に実施していれば防げたコストとして事後的に認識される
• 意思決定の品質低下：「とりあえず調べた」という状態でクロージングに進むと、価格交渉においても条件設定においても判断の根拠が薄くなる。結果的に交渉力が落ちる

だとすれば、どこを外に出すか

全部を外注する必要はありません。DDの工程は大きく三層に分けられます。

• 情報収集・整理・分析の初期工程：資料の仕分け、財務データの読み込み、公開情報の収集など。ここは経験よりも「量をこなす体力」が必要な部分で、AIとの相性がいい工程です
• 論点の設定・質問票の設計：何を聞くかを決める作業。ここに経験値の差が出やすく、AIが初稿を作り、専門家がレビューする設計が有効です
• 判断・評価・交渉：マネジメントインタビューの解釈、リスクの重み付け、最終的な投資判断。ここは人間の経験と判断が必須です。省略できる工程ではありません

どこまで自社でやり、どこから専門家を使うかを最初に設計しておくこと——これが、中小・スタートアップのDD設計の核心です。

AIがDDで何かを変えるとすれば、それは「情報の量を処理する速さ」です。判断する仕事ではない。この区別を押さえておかないと、AI活用は期待外れに終わります。

AIが効果を発揮するのは、「情報の量が多く、処理に時間がかかる」工程です。大手ファームでジュニアスタッフが数週間かけていた作業が、大幅に短縮できます。これにより、専門家の時間を「判断が必要な箇所」に集中させる構造が作れます。

ただ、「情報処理はAI、判断は人間」という分け方は綺麗すぎて、実務ではもう少し厄介です。引っかかるのは、AIが最も得意に見える「◎」の工程ほど、事実誤認が紛れ込んだときに気づきにくいという点です。財務データの数値抽出で、AIが脚注や単位（千円／百万円）の切り替わりを読み違える、複数年度の表を一行ずらして拾う——こういう誤りは、出力が自信たっぷりの数字の羅列で返ってくるぶん、目視で見つけるのが難しい。市場リサーチでも、存在しない統計や古い数字をもっともらしい出典名つきで生成することがあり、これを真に受けると論点設計そのものがズレます。

つまりAIを入れると専門家の総工数が単純に減るわけではなく、「読み込みの工数」が「AI出力の検算・裏取りの工数」に置き換わる、というのが実態に近い。筆者の進め方では、AIが抽出した財務の主要数字は必ず原資料の該当ページに突き合わせ、AIが挙げた統計や出典は一次情報をたどれたものだけ採用する、という前提でレビュー時間を最初から見込んでおきます。ここを「AIがやったから速いはず」と圧縮すると、かえってDD全体の信頼性を落とします。AIで効くのは「人間がゼロから書く工数」が消えることであって、「人間が確認する工数」が消えることではありません。

「自走DD」は、すべてを自社でやることではありません。自社が判断の主体として動ける状態を作った上で、AIと専門家を必要な工程に組み込む——前のセクションまでで、その骨格は描けます。ただ、骨格どおりに進めても結果がブレるのは、たいてい設計の「中身の詰め」が甘い箇所です。崩れやすいポイントを、工程の順に挙げておきます。

目的の言語化でつまずくのは、一文に「できない」からではなく、一文が当たり障りなく書けてしまうからです。「事業の将来性を見極める」と書けば一見筋は通りますが、これでは何を黒と判断するかが決まらない。筆者がレビューで戻すのは、目的の文に「だから今回は◯◯を最優先で確認し、××は見ない」という捨てる対象が入っているかどうかです。捨てるものが書けていない目的は、実質的に「全部見る」と言っているのと同じで、後で範囲が膨らみます。

スコープ決めの失敗は、領域の取捨選択よりも「深度の読み違え」で起きます。よくあるのは、IT-DDを"やる/やらない"の二択で考えてしまうこと。実際にはIT-DDの中にも、契約・ライセンスの棚卸しのように一日で終わる確認と、コードやインフラの技術的負債のように専門家が数日かける確認が混在しています。ここを一括りに「IT-DDは軽く」と決めると、軽くてよい部分と命取りになる部分を一緒に削ってしまいます。

AIと専門家の割り当てで転ぶのは、割り当て表を作った後の「引き継ぎ」です。AIが出した初稿を専門家に渡すとき、どんな前提・どんな資料を食わせて生成したものかを添えないと、専門家は出力を信用してよいか分からず、結局ゼロから見直すことになります。AIの出力は「成果物」ではなく「専門家への申し送り付きの素材」として回す——この一手間を省くと、AIを入れた意味が消えます。

IRLと最終判断については、前のセクションとも重なるので深追いしませんが、ひとつだけ。マネジメントインタビューに専門家を入れる価値は「鋭い質問をする」ことより、相手の答えに対してその場で追撃の質問を組み立てられることにあります。台本どおりの質問はAIでも作れますが、返ってきた答えの不自然さを察知して二の矢を放てるかどうかが、DDの結論を分けます。

「全体を見てほしい」という依頼をすると、専門家も広く動かざるを得ず費用が膨らみます。逆に「ここだけ確認してほしい」と言えるほど、依頼の費用は下がり、返ってくる答えの精度は上がります。

論点を設計する前に確認しておきたいのは、まず買収の目的を一文で言語化できているかどうかです。シナジー狙いなのか、事業承継なのか、競合排除なのかによって、調べるべき論点はまったく変わります。次に「ここが黒なら撤退する」という条件を先に決めておくこと。これがないまま進むと、調査範囲が際限なく広がります。

対象会社のビジネスモデルで最もリスクが高い部分——顧客集中・依存サプライヤー・人的依存など——を仮説として持った上で、ビジネスDD・IT-DD・財務DD・法務DDのどの領域を専門家に頼み、どの工程をAIで処理するかを役割分担として文書化しておく。この準備があるかどうかで、専門家への依頼費用と、返ってくる調査の精度が大きく変わります。

規模が小さい案件ほど、DDの失敗が事後の損失に直結しやすいのが実態です。よく遭遇するパターンを挙げておきます。

PATTERN 01

「終わった」と思ったDDが終わっていなかった

資料を一通り確認して報告書を出した時点で完了と判断したが、論点の重要度の判断ができておらず、後から問題が出てきたケース。完了基準は「資料を全部見たか」ではなく「Go/No-Goを左右する論点それぞれに、白か黒か（あるいは追加調査が要るか）の結論が付いたか」で引く。論点リストの一行ごとに結論欄を作り、空欄が残っているうちはDD完了とは呼ばない、という運用にすると曖昧な"なんとなく完了"が防げます。

PATTERN 02

スコープ外の追加請求で費用が跳ね上がった

見積もりに含まれていない作業が「追加論点」として次々請求された。依頼時に「何が含まれて何が含まれないか」を文書化し、固定費用かタイムチャージかを事前に確認することが必須です。

PATTERN 03

IT-DDを省略してPMI後に発覚した

SaaSや製造業でも、基幹システムの依存構造・老朽化・セキュリティのリスクはPMI後の大きなコスト要因になります。IT-DDは「IT企業だけのもの」ではありません。

PATTERN 04

担当者のDDスキルに依存しすぎた

社内に経験者がいた案件でも、その人が異動・退職するとノウハウが引き継がれない。属人化を避けるには、その人の頭の中にある判断を「使った質問票・論点リスト・判断の根拠メモ」として案件ごとに残す。次の案件はそれを叩き台に修正する形にすれば、担当者が代わっても型が組織に残ります。再現できる成果物が手元に積み上がっているかが、属人か組織かの分かれ目です。

PATTERN 05

「信頼できる人」への依頼が品質を保証しなかった

関係性の深さと、DDの実務能力は別の話です。顧問の会計士や付き合いの長い士業に「ついでに見てほしい」と頼むと、本業の片手間になりやすく、専門外の領域は深く突けません。依頼先を選ぶときは「直近で同種・同規模のDDを何件、どの工程まで自分の手で回したか」を一件ずつ具体的に聞く。関係の長さではなく、その問いに具体で答えられるかで見極めます。

PATTERN 06

論点の数を絞れずに時間切れになった

「できる限り全部調べたい」という姿勢は理解できますが、期限が迫るとレポートが未完成のまま意思決定を迫られます。核心論点の見つけ方は単純で、「これが想定と違ったら買収をやめるか、価格を下げるか」と自問して、答えがイエスになる項目だけを残す。顧客集中度・キーパーソン依存・主要契約の継続性のように、結果次第で意思決定がひっくり返る論点を三つ前後に絞り、残りは時間が余ったら見る"後回し枠"に明示的に振り分けておくと、時間切れでも判断に必要な部分は埋まります。