LLM API依存度で測る事業の脆弱性指数
「うちのプロダクトはGPTを使ったAI要約機能が売りです」── 2026年、こう語るSaaSは珍しくない。むしろLLMを使っていない新興SaaSの方が少ない。しかし買い手側の技術DDでこの一言を聞いたとき、私が次に必ず問うのは「では、そのGPTが明日5倍に値上げされたら、御社の粗利はどうなりますか」「そのモデルが半年後に廃止されたら、何週間で別モデルに切り替えられますか」だ。この二つの問いに即答できない事業は、自社の脆弱性を測定していない。
LLM API依存は、それ自体が悪いわけではない。問題は、依存の「度合い」と「切り替え可能性」が定量化されないまま、事業価値だけが評価されている点にある。同じ「AI機能搭載SaaS」でも、単一プロバイダーに完全ロックインされ、プロンプトもファインチューニングも特定モデルに最適化され尽くした事業と、抽象化レイヤーを挟んで複数プロバイダーを数日で切り替えられる事業とでは、リスクプロファイルが全く異なる。
本稿では、LLM API依存を「脆弱性指数」として定量化する枠組みを提示する。切り替えコストを構成する要素の分解、価格改定・モデル廃止・ToS変更という三大外部リスク、そして買い手・売り手が依存度をバリュエーションにどう反映すべきかを、現場目線で整理する。
1. LLM API依存はなぜ「脆弱性」なのか
1-1. 事業の中核機能が他社のロードマップに従属する構造
自社開発の機能であれば、仕様も価格も廃止時期も自社が決められる。しかしLLM API依存の機能は、モデルの性能・価格・提供継続のすべてがプロバイダー側のロードマップに従属する。プロバイダーが価格を上げれば原価が上がり、モデルを廃止すれば作り直しを強いられ、利用規約を変えれば特定用途が禁止される可能性がある。
これは、事業の中核損益が「自社がコントロールできない第三者の意思決定」に晒されているということだ。粗利の大部分がLLM API経由の機能に依存している事業は、その第三者リスクをバリュエーションに織り込まなければ、過大評価になる。脆弱性指数とは、この従属の度合いを数値化する試みだ。
1-2. 「動いている」と「移せる」は別問題
多くのAI機能搭載SaaSは「今、動いている」。だが買い手が問うべきは「このプロバイダーから離れられるか」だ。プロンプトが特定モデルの癖に合わせて何百行も調整され、出力フォーマットが特定モデルのfunction calling仕様に密結合し、評価スイートが一つのモデルの挙動を前提に組まれている場合、別モデルへの移行は「APIキーを差し替える」では済まない。
移行には、プロンプトの再設計、出力パーサーの作り直し、品質評価のやり直し、回帰テストという一連の工程が必要になる。「OpenAIをAnthropicに替えるだけでしょう」と言うエンジニアは、自社が一度もその移行を試したことがない。脆弱性指数は、この「移せなさ」を可視化する。
2. 切り替えコストを構成する5つの要素
2-1. プロンプトの最適化深度とポータビリティ
第一の要素は、プロンプトがどれだけ特定モデルに最適化されているかだ。少数のシンプルなプロンプトで動いている事業は移行が容易だが、特定モデルの推論癖・トークナイザ・コンテキスト長を前提に精密にチューニングされたプロンプト群は、別モデルでは同じ品質が出ない。プロンプトの本数・複雑度・モデル固有テクニックの使用量が、移行コストを直接押し上げる。
DDでは、プロンプトがバージョン管理され、テスト可能な形で外部化されているかを確認する。プロンプトがコード中に文字列でハードコードされ、誰がいつ何のために調整したか記録がない事業は、移行どころか現状維持すら属人化している。
2-2. ファインチューニング・埋め込みのプロバイダーロック
第二の要素は、ファインチューニング済みモデルや埋め込み（embedding）のプロバイダー依存だ。特定プロバイダーでファインチューニングしたモデルは、そのプロバイダーでしか動かない。別プロバイダーに移るには学習データを再投入してファインチューニングをやり直す必要があり、学習データが残っていなければそれすら不可能だ。
埋め込みも同様で、あるモデルで生成したベクトルは別モデルのベクトル空間と互換性がない。プロバイダーを替えれば、ベクトルDBに蓄積した全データの再埋め込みが必要になる。ファインチューニングと埋め込みは、LLM依存の中でも特にロックインが強い領域だ。
2-3. 抽象化レイヤーの有無
第三の要素は、プロバイダーを抽象化するレイヤーが設計されているかだ。複数プロバイダーを統一インターフェースで扱う抽象化（自前のアダプタ層、あるいはLiteLLM等の利用）が入っていれば、プロバイダー切り替えはアダプタの差し替えで済む可能性が高い。抽象化がなく、各所でプロバイダーのSDKを直接呼んでいる事業は、切り替え時に全呼び出し箇所を改修する必要がある。
抽象化レイヤーの存在は、それ自体が技術的成熟度の指標であり、「プロバイダー依存リスクを設計時点で認識していた事業」というシグナルになる。バリュエーションの加点要素として評価できる。
3. 三大外部リスク ── 価格・廃止・規約
3-1. 価格改定リスク ── 原価が一夜で変わる
LLM APIの価格は、プロバイダーの判断で改定される。値下げの方向に動くことも多いが、特定の高性能モデルが想定より高コストで維持され、価格が据え置かれる、あるいは新モデルへの移行を促す価格設計が敷かれることもある。粗利の大部分がトークン課金に連動する事業は、価格改定が原価率を直撃する。
DDでは、過去12ヶ月のトークン消費量と支払額の推移、ユーザー数増加に対するトークンコストの伸び方（線形か非線形か）を必ず確認する。1ユーザーあたりのLLMコストが収益単価に対して高い事業は、価格改定とヘビーユーザーの両方に対して脆弱だ。
3-2. モデル廃止リスク ── サンセットの強制移行
プロバイダーは旧モデルを廃止（サンセット）し、新モデルへの移行を促す。廃止が告知されると、事業者は限られた期間内に新モデルへ移行し、プロンプトと品質を作り直さなければならない。新モデルが旧モデルと同じ挙動をする保証はなく、移行に伴う品質劣化が顧客離反を招くこともある。
モデルのバージョンが固定（pinning）されているか、廃止告知に対する移行プロセスが整っているかをDDで確認する。特定の旧モデルにしか出せない品質に事業が依存している場合、そのモデルの廃止は事業価値の毀損に直結する。モデル廃止は「いつか必ず来る」前提で、移行可能性を評価する。
3-3. 利用規約・データポリシー変更リスク
第三のリスクは、利用規約やデータ利用ポリシーの変更だ。プロバイダーが特定用途を制限したり、出力の使用条件を変えたり、データの取り扱い方針を改定したりすると、事業の根幹が成り立たなくなる可能性がある。特に、規制業界（医療・金融・法務）向けにLLMを使う事業は、規約変更の影響を受けやすい。
DDでは、現在の利用が規約に完全準拠しているか、エンタープライズ契約でデータの学習利用が除外されているか、リージョンやコンプライアンス要件を満たしているかを確認する。規約のグレーゾーンで運用している事業は、規約変更一つで事業停止に至るテールリスクを抱えている。
4. 脆弱性指数の算出とバリュエーションへの反映
4-1. 指数の構成 ── 依存度×切替不能度
脆弱性指数は、大きく「依存度」と「切替不能度」の積で捉える。依存度は、粗利のうちLLM API経由機能が支える比率、ユーザー単価に占めるLLMコスト比率で測る。切替不能度は、前述の5要素（プロンプト最適化深度・ファインチューニング/埋め込みロック・抽象化レイヤーの有無・出力フォーマット密結合・評価再現性）から評価する。
依存度が高く切替不能度も高い事業は、脆弱性指数が最も高い。逆に、依存度が高くても抽象化が効いていて数週間で切り替えられる事業は、指数を相応に下げられる。重要なのは、依存度の高さそのものではなく、依存に対する切り替え余地があるかどうかだ。
4-2. バリュエーション補正とリスク低減の打ち手
脆弱性指数の高い事業は、第三者リスクを織り込んでバリュエーションを補正する。具体的には、価格改定シナリオ（例：トークン単価が2倍になった場合）での粗利感応度を試算し、モデル廃止時の移行工数を見積もり、これらをDCFのリスク要因として反映する。
売り手側がバリュエーションを守るには、買収交渉前に抽象化レイヤーを導入し、複数プロバイダーでの動作実績を作り、プロンプトと評価スイートを外部化・文書化しておくことが有効だ。「いつでも別プロバイダーに移れる」という実証は、それ自体が脆弱性指数を下げ、事業価値を守る投資になる。
5. DDチェックリスト ── 買い手・売り手の実務
5-1. 買い手が確認すべき項目
買い手は次を確認する。①粗利に占めるLLM依存機能の比率、②ユーザー単価対LLMコスト、③利用プロバイダーと契約形態（従量/エンタープライズ）、④モデルバージョンの固定状況と廃止エクスポージャー、⑤抽象化レイヤーとフォールバック設計の有無、⑥プロンプト・評価スイートの外部化と再現性、⑦ファインチューニング/埋め込みのロック状況と学習データの保全。
これらを通じて、脆弱性指数を定量化し、価格改定・モデル廃止のシナリオ感応度を試算する。「AI機能がある」という定性評価で止まるDDは、最も重要な第三者リスクを見落としている。
5-2. 売り手が整えるべき開示
売り手は、LLM依存を「管理されたリスク」として提示できる状態を作る。トークン消費とコストの推移データ、プロバイダー契約書、抽象化レイヤーの設計ドキュメント、複数プロバイダーでの動作検証結果、プロンプトと評価スイートのリポジトリを開示できれば、買い手の技術DD工数を短縮し、脆弱性に対する不安を払拭できる。
逆に、これらを開示できない事業は「AIで動いているが、なぜ動いているか誰も説明できない」ブラックボックスとして、買い手に強い警戒を抱かせる。LLM依存を可視化・文書化できる事業は、それ自体がバリュエーションの土俵に堂々と乗れる事業だ。
結論：依存の有無ではなく、依存からの「出口」が価値を決める
2026年において、LLM APIを使わない選択肢は現実的でない。問われるのは依存しているかどうかではなく、その依存をどれだけ測定し、管理し、必要なときに出口を取れる構造にしているかだ。脆弱性指数とは、事業が自社の従属性を直視しているかを映す鏡であり、指数を測定すらしていない事業は、自らの最大のリスクに目を閉じている。
買い手にとって、脆弱性指数の算出は買収後の事業継続リスクを見積もる作業であり、売り手にとっては、抽象化と文書化を通じて指数を下げ、事業価値を守る経営課題だ。技術的DDの本質は、こうした「数字に載らない従属性」を数字に翻訳し、価格交渉のテーブルに乗せる作業にある。LLM API依存は、その最前線の論点の一つだ。
