AIを使って技術DDを自分たちで進める実践ガイド：資料・手順・質問例・限界・依頼の判断基準

技術デューデリジェンス（技術DD）の相当部分は、AIを使えば投資担当者や事業会社の担当者が自分たちで進められる。外部に委託する前に、まず自分たちで一次調査を行い、専門家の判断が必要な論点を絞り込む。この順序にすると、委託する場合でも範囲が明確になり、委託しない場合でも投資判断の根拠が残る。

本稿は、そのための手順を一つにまとめた実践ガイドである。評価軸の詳細や個別の論点は既存の記事に譲り、ここでは「何を用意し、どの順で進め、どこで止まるか」を示す。

1. このガイドの対象

• シード〜シリーズB程度のソフトウェア／AIスタートアップへの投資を検討しているVC・CVCの担当者
• 事業提携や小規模なM&Aを検討している事業会社の担当者
• 社内にCTOや技術顧問がいない、またはいても毎回は頼れない組織

大型M&AやITシステム統合を伴う案件、ハードウェアやディープテックが中心の案件は、本稿の範囲を超える。それらは最初から専門家の関与を前提にしたほうがよい。

2. AIと人の役割分担

前提として、AIと人の役割を分けておく。

段階	AIに任せられること	人が行うこと
一次調査	資料の読み込み、要約、評価軸ごとの論点の洗い出し	調査範囲と評価軸の決定
証拠の整理	主張と根拠の対応表づくり、資料間の矛盾の検出	根拠の信頼性の判断
質問の準備	追加ヒアリングの質問案の作成	質問の取捨選択、ヒアリングの実施
実態の検証	（できない）	現場のエンジニアとの対話、画面・ログ・コードの確認
判断	所見の分類の下書き	撤退・条件付き・許容の最終判断と、その責任

AIは「何を確かめるべきか」を速く洗い出す道具であって、「確かめた」ことにはならない。この区別が、本稿全体の前提である。

3. 必要な資料

対象企業に依頼する資料と、公開情報から集める資料に分ける。最初からすべてが揃うことはないので、「受け取れなかった」こと自体も記録する。

対象企業に依頼する資料

1. システム構成図とインフラ構成（クラウドの利用サービス、環境の分け方）
2. 主要な技術スタックと外部サービス・OSSの一覧
3. 開発体制（人数、役割、外部委託の有無、主要メンバーの在籍期間）
4. 開発プロセス（レビュー、テスト、デプロイの頻度と方法）
5. 過去1〜2年の主な障害・セキュリティインシデントとその対応記録
6. 技術ロードマップと、既知の技術負債の一覧
7. AIプロダクトの場合：利用モデル、評価データと評価手順、推論コストの推移（読み方は LLMプロダクトの粗利構造）

公開情報

• 採用ページ、技術ブログ、登壇資料、公開リポジトリ
• サービスの利用規約・プライバシーポリシー
• ステータスページや障害の公表履歴

どの資料を依頼すべきかの網羅的な一覧は 投資家が実施すべき技術デューデリジェンスの全項目 を使う。

4. 進め方：5つの手順

手順1：評価の範囲と重みを決める

まず、この案件で何を判断したいのかを一文で書く。「プロダクトが次の2年の成長に耐えられるか」なのか、「技術チームが事業計画を実行できるか」なのかで、重みを置く評価軸が変わる。7つの評価軸とステージ別の重みは 技術デューデリジェンスの全体像と7つの評価軸 を参照する。

AIの使いどころ：事業計画と提出資料をAIに読ませ、「この事業計画が前提にしている技術的な条件」を列挙させる。そこから評価軸の優先順位を人が決める。

手順2：資料を読み、主張と根拠を対応させる

提出資料から「対象企業が主張していること」を抜き出し、それぞれに根拠があるかを確認する。

AIの使いどころ：資料をAIに読ませ、次の形式の表を作らせる。

主張	根拠となる資料・箇所	根拠の種類	未確認の点
例：月間100万リクエストに対応できる	構成図 p.3	自己申告	負荷試験の結果が未提出

「根拠の種類」は、自己申告・第三者の記録・実物の確認の3段階に分けておくと、後の判断がしやすい。

手順3：ヒアリングで確かめる

手順2で「未確認」になった点を、ヒアリングで確かめる。ソースコードを見なくても、質問の設計次第で多くのことが分かる。質問の組み立て方は ソースコードを見ずに技術力を見抜く方法 に詳しい。組織面は エンジニア組織の健全性をどう評価するか を使う。

質問例

• 直近で本番障害が起きたとき、検知から復旧まで誰が何をしましたか。そのとき残した記録を見せてもらえますか。
• 今月リリースした変更のうち、レビューを経ずに本番に出たものはありますか。
• いま退職すると開発が止まる人は誰ですか。その人の仕事を代われる人はいますか。
• 技術負債として認識しているものを3つ挙げてください。それぞれ、いつ・どう返す予定ですか。
• （AIプロダクトの場合）モデルを変更したとき、品質が下がっていないことをどう確かめていますか。

AIの使いどころ：資料の矛盾点や曖昧な記述から、追加の質問案を作らせる。ただし、どの質問を誰に聞くかは人が選ぶ。経営者と現場のエンジニアに同じ質問をして、答えのずれを見るのが有効である。

手順4：所見を分類する

見つかった所見を「撤退・条件付き・許容」の三つに分ける。分類の基準と領域別の例は 技術DDのレッドフラッグ一覧 にまとめている。投資後に表面化しやすいパターンは 投資後に発覚しがちな技術リスク10選 が参考になる。

AIの使いどころ：所見の一覧をAIに渡し、レッドフラッグ一覧の基準に沿って分類の下書きをさせる。分類の理由も書かせ、人がその理由に同意できるかで判断する。

手順5：判断と記録を残す

最後に、投資判断に使える形で記録をまとめる。最低限、次の4点を残す。

1. 何を判断しようとしたか（手順1の一文）
2. 確認できたことと、その根拠の種類
3. 確認できなかったこと（資料が出なかった点、ヒアリングで答えが曖昧だった点）
4. 所見の分類と、それに対する判断

3の「確認できなかったこと」を書き残すのが重要である。後から問題が表面化したとき、それが見落としだったのか、確認できないまま判断したのかを区別できる。

5. 証拠の管理

自分たちで進める技術DDでは、証拠の管理が甘くなりやすい。次のルールを最初に決めておく。

• 受け取った資料は、受領日と提供者を付けて一か所に保管する
• ヒアリングは、日時・相手・質問・回答の要旨を記録する
• AIに作らせた要約や表は、元の資料のどこに基づくかを必ず残す（AIの出力そのものを証拠として扱わない）
• 判断に使った情報と使わなかった情報を分ける

6. AIを使うときの秘密情報とコードの扱い

技術DDで扱う資料の多くは、NDAで守られた対象企業の秘密情報である。AIを使う前に、次を確認する。

1. NDAと同意の範囲：外部のAIサービスへの入力が、NDAで認められているか。必要なら対象企業の同意を得る。
2. ツールのデータ取扱い：利用規約とデータの取扱い設定を確認する。入力データが学習に使われないか、どこに・どれだけの期間保存されるか。社内で利用を認められたツールを使う。
3. 入力前の除去：認証情報（APIキー、パスワード、接続文字列）、個人情報、顧客名は入力前に取り除く。
4. ソースコード：コードを受け取った場合でも、全体をそのまま入力しない。必要な範囲に限り、対象企業と合意した方法で扱う。
5. 記録：何を、いつ、どのツールに入力したかを記録する。

これらを満たせない場合は、AIを使う範囲を公開情報と自社で作成した資料に限る。認証・認可・暗号化といった評価そのものの観点は セキュリティの基礎 を参照する。

7. AIによる評価の限界

次の条件では、AIの出力だけで判断してはいけない。

条件	理由	人が行う検証
提出資料だけで判断している	資料は対象企業が選んだもの	現場のエンジニアへのヒアリング
コード・本番環境を見ていない	設計資料と実装の乖離はAIには見えない	コードと構成の実物確認
運用の実態を評価している	障害対応やデプロイの実態は記録に残りにくい	具体的な質問、ログ・チケットの確認
人・組織を評価している	キーパーソン依存や離職リスクは文書に出ない	複数人との個別面談
AIプロダクトの性能主張を評価している	デモや自己申告の数値は再現性が不明	評価データと手順の開示、可能なら再実行
最新の技術動向・脆弱性を前提にしている	AIの知識には期限がある	一次情報（公式発表、脆弱性情報）での確認

AIは、もっともらしいが誤った説明を出すことがある（ハルシネーションとは何か）。数字や固有名詞は必ず元の資料で確かめる。

8. 専門家に依頼すべき条件

自分たちで進めた結果、次のどれかに当てはまったら、専門家への依頼を検討する。

1. 投資委員会や共同投資家から、独立した第三者の評価を求められている
2. ソースコード・インフラ・セキュリティを専門的にレビューしないと判断できない論点がある
3. AIプロダクトの評価で、モデル・データ・評価体制まで踏み込む必要がある
4. 「撤退」に当たりうるレッドフラッグの疑いがあるが、自分たちでは判定できない
5. 社内で評価すると利益相反が生じる、または評価に必要な時間を社内で確保できない

依頼する場合は、ここまでの記録（特に「確認できなかったこと」）を渡す。範囲が絞られているほど、依頼する側も受ける側も判断が速くなる。

ケーススタディ：シリーズAのSaaSへの投資検討（例）

以下は手順の使い方を示すための例であり、特定の案件ではない。

• 手順1：判断したいことを「現在の開発体制で、事業計画にある2年後の顧客数に対応できるか」と書いた。重みは拡張性（兆候の見方は スケーラビリティの限界を事前に察知する評価軸）と開発組織に置いた。
• 手順2：AIに資料を読ませて主張と根拠の表を作ったところ、「障害はほぼない」という主張の根拠が自己申告だけで、障害記録が提出されていないことが分かった。
• 手順3：経営者と現場のエンジニア2名に同じ質問をした。直近の障害対応について、経営者は「すぐ直った」と答えたが、エンジニアは「特定の1人しか本番環境を触れない」と答えた。
• 手順4：キーパーソン依存を「条件付き」に分類した。投資後に権限を分散する計画を条件にする判断である。
• 手順5：障害記録が出なかったことを「確認できなかったこと」として残した。

この例では、自分たちの調査で論点が「キーパーソン依存」と「障害記録の不在」に絞られた。インフラ構成の専門的なレビューが必要だと判断すれば、その範囲に限って専門家に依頼できる。

まとめ

• AIは一次調査と証拠の整理を速くするが、実態の検証と判断は人が行う
• 進め方は「範囲を決める → 主張と根拠を対応させる → ヒアリングで確かめる → 分類する → 記録する」の5手順
• 秘密情報とコードは、NDA・同意・ツールのデータ取扱いを確認してから扱う
• 自分たちで進めた結果、判断できない論点が残ったら、その範囲に絞って専門家に依頼する

関連する評価軸の詳細は AI時代の技術DDは何が変わるか と AIプロダクトの品質はどう担保されているか も参照してほしい。