00.Introduction

はじめに

M&AのデューデリジェンスにAIを活用する動きは、ここ2〜3年で急速に広がりました。大量のドキュメントを横断して論点を抽出したり、市場データを素早く収集・整理したりする用途では、AIは明確に人間の作業時間を削減します。

ただし「AIで何でもできる」というわけではない。特にビジネスDD(BDD)における対象会社の本質的な評価や、経営陣・キーパーソンへのヒアリングで得る定性情報の解釈は、AIが苦手とする領域です。使える場面と使えない場面を整理せずに導入すると、スピードは上がっても精度が下がるという逆効果になることがあります。

DDにおけるAI活用の本質は「情報処理の効率化」です。AIは大量の情報を速く処理できますが、「この情報が買収判断にとって重要かどうか」という評価は、業界知識と経験を持つ人間が担います。AIと専門家の役割分担を設計することが、活用の前提になります。

01.Section 01

AIがDDで実際に使える工程——情報収集・論点抽出・仮説検証

AIが最も効果を発揮するのは、「大量の情報から必要なものを拾い出す」作業です。人間が1日かけてやる文献調査や資料の読み込みを、AIは数分でこなせる。この速度差を活かせる工程は、DDの中に複数あります。

  • 市場規模・競合動向の情報収集と一次整理
  • 契約書・財務資料など大量ドキュメントの横断検索
  • 業種別のリスク論点リストの初稿作成
  • 公開情報をもとにした対象会社のプロファイリング
  • ヒアリング議事録の要点抽出と論点整理

これらに共通するのは「読み込む量が膨大だが、何を拾うかの基準が比較的明確」という性質です。条件を絞った検索や、定型に沿った整理であれば、AIは人間の作業時間を1/10以下に圧縮することがあります。

DD実務に引きつけると、AIに任せても事故りにくいのは「正解が外部の文書側にあり、人間が突合で誤りを検出できるタスク」だと筆者は線を引いています。具体的には、情報開示要求リスト(IRL)の初稿作成、開示資料と要求項目の突合チェック、契約書からの特定条項の抜き出し、許認可・規制の一覧化(規制マッピング)の下書き——いずれも「あるべき項目」が外側で定義でき、出力の正否を後から照合できます。逆に、正解が対象会社の内側(経営陣の意図、顧客が乗り換えない本当の理由、数字の異常値の背景)にしかないタスクは、照合先がないため誤りに気づけず、AIに渡すと事故ります。

  • 経営陣の人物評価・信頼性の判断
  • 顧客インタビューから得る定性的な肌感覚
  • 財務数値の「異常値」の背景にある意図の読み取り
  • 業界特有の慣行・暗黙知の評価
  • 買収価格交渉における判断

たとえば規制マッピングでも、「どの法令が対象になるか」を列挙させるところまではAIで足りますが、「その許認可が承継できるか・取り直しになるか」はM&Aスキームと運用実態に依存し、最後は人間が当局や顧問に当てて確認する。AIの出力は照合可能な下書きまで、というのが現場での落としどころです。

/ Field Notes — 現場から

AIのリスク初稿が立派すぎて、逆に最初のヒアリングが後回しになった案件

金属加工の受託メーカーのビジネスDDで、リスク調査の初稿をAIに作らせたところ、財務・規制・オペレーションを網羅した40ページ超のレポートが3時間で上がってきました。リスクマトリクスの体裁まで整っていて、正直「これで初回報告はいける」とチーム内の空気が一瞬傾いたのを覚えています。

引っかかったのは、レポートをめくっていた財務担当が「売掛金の相手先が妙に集中している」と漏らした一言でした。そこから経理資料を当たり直すと、売上の大半が創業者の古い取引関係で続いている数社に寄っていて、しかも基本契約書がないものまであった。AIはこの集中を「リスク」として立てていなかった——元になる情報が開示資料にも公開情報にも無く、突合する相手がいなかったからです。判断が転んだのはAIの精度ではなく、立派なレポートが先に出たことで「まず開示資料を疑う」というヒアリングの初動が後ろにずれかけた点でした。結局、初回報告を1週間ずらして取引先ヒアリングを前に倒し、そこで属人性の深さが見えた。完成度の高い初稿ほど、検証の順番を狂わせる方向に効くことがあります。

02.Section 02

ビジネスDD×AI——調査範囲を広げながら深みを落とさない使い方

ビジネスDD(BDD)でAIが最も効果を発揮するのは、市場・競合の情報収集フェーズです。対象会社が属する市場の規模・成長率・主要プレイヤーを把握する作業は、以前であれば調査会社のレポートを購入するか、アナリストが数日かけて行うものでした。AIを使えば、一次情報の収集と整理を数時間に短縮できます。

具体的には、複数のウェブサイトから大量の一次データを自動取得し、そのままスプレッドシートに一覧化するという作業が、AIを使えばほぼ自動で完結します。業界ニュース・プレスリリース・規制情報・価格データ——従来はリサーチャーが手作業で収集・入力していたものを、AIが構造化されたデータとして出力できる。競合10社の情報を横並びにした比較表を人間が作れば半日かかるところを、AIは数十分で叩き台を生成します。この「一次データの取得から一覧化まで」を短時間でこなせることが、BDDの初期フェーズで特に効いてきます。

競合分析では、各社の決算資料・プレスリリース・採用情報を横断的に読み込み、戦略の方向性や注力領域を推定する作業にAIが有効です。競合がどのキーワードで採用を強化しているかを見るだけで、事業の重点が見えることがあります。

汎用AIツールとDD固有の論点設計の差

ただし、汎用のAIツールをそのままBDDに使っても、DD固有の論点設計がなければ調査の抜け漏れは防げません。先ほどの金属加工の案件で売上の集中がリスクとして立たなかったのは、その情報が開示資料にも公開情報にも無く、AIに照合する相手がなかったからです。BDDで実際に効くのは、業種ごとに「ここは公開情報では絶対に拾えないからヒアリングで埋める」という穴をあらかじめ知っていて、AIに任せる範囲とヒアリングで取りにいく範囲を最初に切り分けておくことです。製造業なら主要顧客の集中度と取引の属人性、SaaSなら解約率の実態と契約更改の交渉力——こうした「AIが構造的に拾えない論点」のリストを案件の頭で用意できるかどうかが、調査の抜けを防ぐ分かれ目になります。筆者の整理では、AI導入で事故るのは性能不足よりも、この切り分けを設計しないまま「とりあえずAIに調べさせた」ケースが多い。

BDDにおけるAI活用の限界

一方、顧客インタビューやエキスパートインタビューから得られる情報はAIでは代替できません。「顧客がその会社に発注し続ける理由」「他社に乗り換えない本当の理由」は、対話の中でしか出てこない。筆者の経験では、BDDで最も重要な発見の多くがインタビューの場での「ちょっと気になる一言」から始まっています。AIはインタビューのアジェンダ作成や事後の要点整理には使えますが、インタビュー自体の代わりにはなりません。

/ Field Notes — 現場から

AIが見落とした「採用情報に隠れていた撤退サイン」

SaaS企業のビジネスDDで、競合他社の動向をAIで調査していたところ、主要競合の1社が過去6ヶ月間、エンジニア採用を大幅に縮小していることが採用データの変化から分かりました。これはAIが大量の求人情報を横断的に比較したことで初めて見えた変化で、人間が通常のリサーチをしていたら気づかなかった可能性が高い情報でした。

この発見を受けて専門家がさらに掘り下げたところ、その競合が事業の一部から撤退を検討しているという情報が業界関係者へのヒアリングで浮上しました。競合の撤退は対象会社にとってシェア獲得の機会になりうる——という論点が、AI活用なしには見えていなかった可能性があります。AIが情報の「入口」を作り、専門家がそこを深掘りした好例です。

03.Section 03

IT-DD×AI——ドキュメント横断とリスク抽出での活用

ITデューデリジェンス(IT-DD)は、AIと相性がいい領域の一つです。対象会社から提出されるシステム仕様書・契約書・セキュリティポリシー・障害報告書などのドキュメントを横断的に読み込み、リスク論点を抽出する作業は、AIの得意とするところです。

特に有効なのは、大量の契約書から特定の条項(チェンジオブコントロール条項や自動更新条項など)を探し出す作業です。数十本のベンダー契約を人間が1本ずつ読んでいくと数日かかる作業が、AIを使えば数時間に短縮できます。抽出精度は100%ではないため、重要な契約については専門家が最終確認を行う必要がありますが、スクリーニングとしての役割は十分果たせます。

IT-DDでAIが苦手なこと

ソースコードの品質評価や、特定のシステムが「業務上どれだけクリティカルか」という評価は、AIだけでは難しいです。コードの読み取り自体はAIが得意ですが、「このコードが実際の業務フローのどこに位置しているか」を判断するには現場知識が必要で、エンジニアによる実地確認が不可欠です。筆者の経験では、AIに「このモジュールは何をしているか」を説明させると流暢な回答が返ってきますが、それが基幹処理なのか年に数回しか動かない補助バッチなのかは、実際の運用頻度や障害時の影響範囲を運用担当に当てて初めて分かることが多い。コードの内側を読むのとシステムの重要度を測るのは別の作業で、後者は照合する相手が現場にしかいません。

/ Field Notes — 現場から

60本の契約書を2時間でスクリーニングした実例

電子カルテ会社のIT-DDで、対象会社のベンダー契約が60本以上あり、そのすべてにチェンジオブコントロール条項が含まれているかを確認する必要がありました。人手でやれば2〜3日かかる作業でしたが、AIに契約書を読み込ませて条項の有無をスクリーニングしたところ、2時間で一次リストが完成しました。

そのリストを元に、法務担当者が要確認と判断した15本を重点的にレビューする形にしたところ、最終的な確認作業が半日で完了しました。AIのスクリーニングには2件の見落としがありましたが(専門家のレビューで発見)、全体の作業時間は大幅に短縮されました。AIの出力を「完成品」ではなく「叩き台」として扱う設計が、この運用を成立させていました。

04.Section 04

「AIに依頼した」が失敗するパターン——品質低下の構造的な原因

AI活用が裏目に出るケースには、いくつかの共通した構造があります。問題はAI自体の性能よりも、使い方の設計に起因することがほとんどです。

よく見るパターン

  • AIの出力をそのまま報告書に転用する:AIが生成した文章は「それらしい」ため、内容の検証なく使われることがある。事実誤認や業界固有の誤りが混入するリスクがある
  • 論点設計をAIに任せる:「このDD案件で何を調べるべきか」という問いをAIに出すと、汎用的な論点リストが返ってくる。案件固有の重要論点は、業界知識と案件背景を持つ人間が設計する必要がある
  • ヒアリングの代わりに使う:公開情報から得られる情報には限界がある。「AIで調べたので現地調査は省略」という判断は、DDの品質を根本から損なう

これらに共通するのは、Section 01で引いた線——「正解が外部の文書側にあるか、対象会社の内側にしかないか」——を無視して、内側にしか答えがないタスクまでAIに丸投げしている点です。架空企業の混入のような派手な事故より、論点設計をAIに預けて「案件固有の重要論点が静かに一段落ちる」失敗のほうが、報告書の体裁が整っているぶん発見が遅れます。

/ Field Notes — 現場から

競合表の数字が「全部それらしい」せいで、専門家でも検証コストを読み違えた

物流系SaaSのビジネスDDで、競合8社の売上・調達額・従業員数を並べた比較表をAIに作らせました。問題は1社架空が混じっていたこと自体よりも、残り7社の数字も「桁とレンジがそれらしい」せいで、どれが裏取り済みでどれが推定かが表の上で見分けられなかったことです。実在企業でも、AIは未公開の調達額を「このくらいだろう」という値で平気で埋めてきます。

担当が出典を1社ずつ当て直す段になって、想定の倍近い時間がかかりました。最初に「この表のセルは、ソースURLが付いていないものは全部未確認とみなす」というルールを引いておけば、検証の的を絞れたはずでした。架空企業の混入そのものは個別確認で弾けますが、本当に効くのは「どのセルが検証待ちか」を出力の段階で可視化させる設計です。AIに表を作らせるときは、値より先に「出典が付いているか」を列で持たせるようにしてからは、この種の事故が目に見えて減りました。

05.Section 05

AI×専門家の分担ライン——DD-AXが設計している工程分担の考え方

DD-AXでは、AIと専門家の分担を「情報の処理速度」と「判断の質」という2軸で設計しています。大量の情報を速く処理する工程はAIが担い、その情報に意味を与え買収判断に繋げる工程は専門家が担う——この原則を案件ごとに具体的な工程に落とし込むことが、AIを使ったDDの設計の核心です。

費用の観点でも、この分担は合理的です。専門家が1時間かけてやっていた情報収集をAIが10分でこなせれば、専門家はその分だけ分析・判断に時間を使えます。同じコストでより深い分析ができる、あるいは同じ深さの分析をより安いコストで実現できる、という選択肢が生まれます。

ただし、「AIを使えば安くなる」という単純な話ではありません。AIの出力を検証するレビュー工程のコストを見落とすと、かえって工数が増えることもあります。AI活用のコスト試算は、ツールの料金だけでなく、レビュー工程の設計まで含めて考える必要があります。

/ Field Notes — 現場から

「AIで安くなる」と思ったら工数が増えた案件

あるクライアントが社内でAIツールを導入し、DDの一部を自社で対応しようとした案件で、実際の工数を後から計測したところ、AIなしの場合と比べて総工数が増えていました。原因は、AIが出力した資料の検証に想定以上の時間がかかったことでした。AIが生成した市場調査の数字が複数の情報源で一致しておらず、一つひとつを手作業で確認する必要が生じたのです。

AIツールの導入効果が出るのは、「何をAIに任せ、何を人間が確認するか」の設計が先にある場合です。ツールを入れることと、ツールを使いこなすことは別の話で、後者には一定の習熟と運用設計が必要です。

/ Summary

AIはDDを「速く」する。ただし、正しく設計した場合に限り

DDでAIを使えるかどうかは、工程の速さより「そのタスクの正解がどこにあるか」で決まります。IRL作成・開示資料の突合・条項抽出・規制マッピングの下書きのように、正解が外部の文書側にあって出力を後から照合できるタスクは、AIに任せて時間を圧縮できる。逆に、正解が対象会社の内側(経営陣の意図、顧客が離れない理由、数字の異常値の背景)にしかないタスクは、照合先がないぶん誤りに気づけず、人間が現場で取りにいくしかありません。

そして本記事で見た事故の多くは、AIの性能ではなく検証の「順番」と「可視化」でつまずいていました。立派な初稿が先に出ると開示資料を疑う初動が後ろにずれ、それらしい数字が並ぶと検証待ちのセルが見分けられなくなる。この線引きと段取りを案件の頭で設計しておくことが、スピードを品質低下に変えないための前提になります。

DD-AXが提供するのは、この「どこまでAIに渡し、どこから人間が照合するか」を案件ごとに設計したうえでの効率化です。AIだけでも人間だけでもなく、正解のありかで工程を切り分けます。