AI時代の技術DDは何が変わるか：LLMをプロダクトに活用するスタートアップへのアプローチ

LLM（大規模言語モデル）をプロダクトに活用するスタートアップを技術DDする機会が増えています。このとき、従来の7軸評価（アーキテクチャ・コード品質・インフラ・セキュリティ・開発プロセス・技術組織・競合優位性）をそのまま適用しても、リスクの全体像は見えません。

結論を先に述べます。AIをプロダクトに活用するスタートアップには、従来の技術DDでは捕捉できない4つの追加論点があります。①LLMの利用形態（API利用／Fine-tuning／自前モデル）を正確に分類する、②プロンプト管理の品質と知財上の含意を評価する、③LLM由来のコスト変動リスクと評価系の有無を確認する、④AIが想定外の振る舞いをしないための安全機構の設計を検証する——この4点を従来の軸に重ねることで、AI時代の技術DDが完成します。

何が変わったのか：従来のDDとの差分

従来の技術DDが前提としていたのは、「自社エンジニアが書いたコード」が技術資産の中心だという世界観です。コードの品質・アーキテクチャの設計・テストカバレッジ——これらはソースコードとCI/CDの設定を読むことで評価できました。

LLMが変えたのはその前提です。今やプロダクトの中核的な振る舞いが、自社のコードではなくOpenAIやAnthropicのAPIから返ってくる結果で決まる場合があります。「プロンプトが資産」になり、「モデルの挙動」がプロダクト品質を左右します。

この変化が技術DDにもたらす具体的な影響は3つあります。

評価対象の拡張：コードだけでなく、プロンプト・評価データセット・ファインチューニング用データが評価対象に加わります。これらは従来のソースコードレビューでは目に入りません。

リスク構造の変化：技術リスクに「外部APIへの依存リスク」「モデルのバージョンアップによる挙動変化リスク」が追加されます。これはクラウドサービスへの依存と似ていますが、振る舞いの予測可能性が低い点で異なります。

競合優位性の評価軸の変化：「自社でモデルをファインチューニングしているか」「独自のデータ資産があるか」が、差別化の源泉として重要性を増しています。「ChatGPTのAPIを叩いているだけ」のアーキテクチャと、「自社データで継続学習しているモデルを持つ」アーキテクチャでは、競合模倣可能性が根本的に異なります。

LLM利用形態の3分類：評価の起点

技術DDを開始するときの最初の問いは「このプロダクト、LLMをどう使っているか」です。回答を以下の3類型に当てはめることで、その後の評価論点が整理されます。

類型1：API利用型

OpenAI・Anthropic・Google等が提供する汎用モデルのAPIを呼び出す形態です。現在の主流であり、多くのAIスタートアップがここに該当します。

強み：開発速度が速く、最新モデルへの追従コストが低く、インフラ管理も不要です。

固有リスク：

API依存リスク：利用規約の変更、価格改定、サービス終了の影響を直接受けます。特に「このAPIがなければプロダクトが成立しない」構造になっている場合、バリュエーションへの影響は大きくなります。
ベンダーロックイン：OpenAI固有のFunction calling仕様やContext windowの特性に依存したコードは、他モデルへの移行コストが高くなります。
モデルバージョン管理：APIのモデルバージョンを明示的にピン留めしているかを確認します。「最新モデル自動適用」の設定では、モデルアップデートで本番の挙動が突然変わります。

確認項目：どのAPIプロバイダに依存しているか、ベンダー切り替えの試算があるか、API費用の月次推移と売上に対する比率。

類型2：Fine-tuning型

汎用モデルを自社データで追加学習させた形態です。OpenAI・Google Cloudなどが商用Fine-tuningサービスを提供しています。

強み：特定ドメインの精度が汎用モデルより高くなりやすく、自社データが学習に組み込まれることで一定の差別化が生まれます。

固有リスク：

学習データの品質と著作権：Fine-tuningに使ったデータのライセンス・著作権処理が適切かを確認します。スクレイピングデータや第三者コンテンツをそのまま使っている場合、IP上のリスクを抱えます。
陳腐化のサイクル：ベースモデルが更新されるたびにFine-tuningをやり直す工数が発生します。この更新サイクルに追従できる体制があるかが論点です。
評価の難しさ：Fine-tuningの効果を定量的に測定するベンチマークが存在するかを確認します。「感覚的に良くなった」では品質保証になりません。

確認項目：学習データのソースと著作権処理、Fine-tuningの更新頻度と体制、評価データセットの設計。

類型3：自前モデル型

独自のモデルアーキテクチャを設計・学習させる形態です。リソース要件が大きいため、大手テック企業・専門AI研究機関・特定ドメインで独自データを大量に保有する企業に限定されます。

強み：競合模倣が最も困難で、データ・モデル・推論パイプラインのすべてが自社資産になります。

固有リスク：

組織依存リスク：モデル開発・維持に特殊なML/MLOpsスキルセットが必要で、キーパーソン依存が生まれやすい構造です。
インフラコスト：学習・推論のGPU費用はスケールに応じて急増します。Unit Economicsが成立しているかの確認が必要です。
開発速度：汎用APIと比較して開発サイクルが遅くなる構造的な制約があります。

スタートアップがこの類型を主張する場合、「本当に自前モデルか」の検証が重要です。Hugging Faceの公開モデルをほぼそのまま使いながら「独自AI」と説明するケースも存在します。

4つの追加評価論点

類型の分類が終わったら、以下の4論点を確認します。これらは類型を問わず共通して問うべき項目です。

論点1：プロンプト管理

LLMをプロダクトに活用する場合、プロンプト（LLMへの指示文）がプロダクト品質を左右する重要な資産になります。プロンプトの管理状況は以下で確認します。

バージョン管理：プロンプトはコードと同様にGitで管理されているか。「Notionに書いてある」「エンジニアの手元に散在している」状態はリスクです。
A/Bテストと評価サイクル：プロンプトを変更したとき、その効果を定量的に測れる仕組みがあるか。感覚的な改善ループは品質の担保になりません。
知財上の含意：プロンプト自体は現時点では特許保護が難しく、営業秘密として管理されるのが現実的です。競合に模倣されたとき、何が参入障壁になるかを問います。

論点2：評価系（Eval）の存在

LLMの出力は確率的であり、「正解」が一意に定まらないタスクが多くあります。このため、LLMをプロダクトに活用している場合の品質保証には専用の評価設計が必要になります。

評価系のない組織は、本番で起きた問題を偶発的にしか発見できません。確認すべき項目は以下です。

ゴールデンデータセット（期待する入出力ペアの集合）が整備されているか
モデルアップデート・プロンプト変更の前後で自動評価が走るCIパイプラインがあるか
ユーザーからのネガティブフィードバックを評価改善ループに組み込む仕組みがあるか

評価系の有無は、開発プロセスの成熟度の指標になります。技術力が高い組織ほど、この部分に早期から投資している傾向があります。

論点3：コスト構造とスケール特性

API利用型・Fine-tuning型いずれの場合も、LLMに起因するコストは使用量に比例して増加します。このコスト構造が事業モデルと整合しているかを確認します。

Unit Economicsの成立：1ユーザーあたり・1リクエストあたりのLLMコストと、対応する収益の関係が試算されているか。
コスト上限の設計：ユーザー1人あたりのAPI呼び出し上限設計があるか。上限なしの設計は、ヘビーユーザーが存在した際にコスト爆発を引き起こします。
モデル価格変動リスク：APIプロバイダの価格改定への感応度がわかるか。過去の改定実績（多くの場合は値下がり方向）も参照しながら評価します。

論点4：安全機構とガードレールの設計

AIが想定外の振る舞いをしないための仕組みが設計されているかは、近年ますます重要な評価軸になっています。ここでいう「安全機構」は倫理的なAI利用という文脈だけでなく、プロダクトの品質・信頼性・法的リスクを守るための実装設計として評価します。

確認すべき項目は以下です。

入力バリデーション：ユーザーから渡されるプロンプトに対して、インジェクション攻撃や意図しない指示の埋め込みを防ぐフィルタリングが実装されているか（プロンプトインジェクション対策）。
出力検証（ガードレール）：LLMの出力を本番サービスに反映する前に、有害コンテンツ・誤った数値・個人情報の混入等を検出・フィルタリングする仕組みがあるか。ガードレールライブラリ（NeMo Guardrails・Guardrails AI等）の採用状況も確認します。
人間による承認フロー（HITL）：高リスクな判断（医療・金融・法律等のドメイン）をAIが自律的に実行する設計になっていないか。Human-in-the-Loop（HITL）の設計が適切かを評価します。
異常検知とアラート：本番環境でのAI出力をモニタリングし、挙動の急変（精度劣化・応答時間異常・有害出力の増加）を検知してアラートを上げる仕組みがあるか。
テストハーネスの整備：LLMの挙動を再現可能な形でテストする環境が整っているか。確率的な出力を持つLLMのテストは、従来の単体テストとは異なる設計が必要です。モックLLM・シード固定・挙動スナップショットといった手法が適切に使われているかを確認します。

この論点が手薄なスタートアップは、リリース後に予期しない事故（誤情報の大量生成・セキュリティインシデント・規制対応の遅れ）を引き起こすリスクを持っています。特に医療・金融・教育・採用など高感度ドメインで事業を営むスタートアップは、投資条件の交渉材料として安全機構の整備状況を明示的に組み込むことを推奨します。

評価のアウトプット：投資・買収判断への橋渡し

これらの評価をどう投資判断に使うかについて整理します。技術DDの目的は3つのアウトプットに集約されます——クリティカルリスクの特定、条件交渉の材料、PMI計画の設計根拠——という原則はAI時代でも変わりません。

AI特有の論点では、以下を特に意識してアウトプットを構成するとよいでしょう。

クリティカルリスクとして扱うべき事項：利用しているAPIが利用規約上プロダクトの用途を制限している場合（例：競合他社向けサービスへの利用禁止条項）、学習データに著作権上の問題がある場合、安全機構が未整備なまま高感度ドメインで本番稼働している場合、キーパーソン1名のみがモデルの仕組みを理解している場合。

バリュエーション調整材料：「独自データ資産があると主張しているが、実際はパブリックデータのみ」「Fine-tuningと言いながら汎用モデルをほぼそのまま使用」という発見は、主張される競合優位性の前提を崩す可能性があります。

PMI計画への反映：評価系が未整備なら投資後の早期改善項目に。API依存度が高いなら、ベンダーリスク分散計画を投資後100日プランに組み込みます。安全機構が不十分な場合は、整備のロードマップを投資条件に紐づけることも有効です。

従来DDとのチェックリスト対応

技術DDの全項目チェックリストの各軸に、以下の確認項目を追加することで、LLMをプロダクトに活用するスタートアップへの適用が可能になります。

追加確認項目	確認先	重要度
LLM利用形態の類型（API/FT/自前）	アーキテクチャ図・エンジニアヒアリング	◎
APIプロバイダへの依存度	インフラコスト内訳・利用規約	◎
プロンプトのバージョン管理状況	リポジトリ確認	○
評価データセットとCIパイプラインの有無	CI/CDパイプライン・テストコード	○
学習データのライセンス・著作権処理	データ調達記録・法務書類	◎
1リクエストあたりのLLMコスト試算	Unit Economics資料	○
モデルバージョンの明示的な固定	API呼び出しコード	△
プロンプトインジェクション対策の実装	セキュリティ設計書・コードレビュー	◎
出力ガードレールの実装状況	アーキテクチャ設計・ライブラリ選定	○
テストハーネスの整備状況	テストコード・CI設定	○
HITL設計の有無（高感度ドメインの場合）	仕様書・運用フロー	◎

重要度◎は「これが未整備ならクリティカルリスク」として扱い、投資条件や価格調整の材料になりえます。

まとめ

AI時代の技術DDは、従来の7軸評価に「LLM利用形態の分類」「プロンプト管理」「評価系とコスト構造」「安全機構の設計」の4論点を追加することで完成します。これらの追加論点は、AIをラッパーとして使うだけのスタートアップと、真に独自性と堅牢性を持つAIスタートアップを見分けるための判断軸でもあります。

「AI活用している」という主張をそのまま受け取るのではなく、どの類型でどのリスクを抱えているかを分解して評価する習慣が、LLMをプロダクトに活用するスタートアップの技術DDの基本姿勢になります。