ファインチューニング済みモデルは誰のものか
「うちのAIは自社専用にファインチューニングしてあるので、汎用モデルとは精度が違います」── AI事業のM&Aで、売り手がバリュエーションの根拠として持ち出す常套句です。確かに、独自データで追加学習させたモデルは、その事業の競争優位そのものに見えます。ところが買い手のエンジニアが「では、そのモデルの重み（weights）を引き渡してください。学習を再現できる状態で」と一言尋ねた瞬間、話が止まる場面が、AI事業の買収現場で繰り返し起きています。
動いているモデルは、必ずしも引き渡せる資産ではありません。モデルの中核価値は「重み」という無形物に宿っており、その重みがどこに存在し、何を素材に、どのライセンスのベースモデルの上で作られたかが曖昧なまま放置されているケースが大半だからです。重みの所在、学習データの来歴、ベースモデルの商用条項── このいずれか1点が欠けただけで、「自社専用モデル」は譲渡対価を支える資産から、引き継げない・使い続けられない・最悪は権利侵害を抱えた負債へと姿を変えます。
本記事は、コード自体の権利を扱ったAIエディタで書かれた事業コードの権利帰属とは別の層、すなわち「学習を経て生まれたモデルの重み」という独立した資産に焦点を当て、その帰属・再現性・ライセンス適合性を移管DDの観点から剥がしていきます。なお本稿は法的助言ではなく、DDで検討すべき論点の整理です。
1. なぜ「動くモデル」が引き渡せない資産になるのか
1-1. 重みは「ソースコード」でも「データ」でもない第三のレイヤー
ファインチューニング済みモデルの実体は、数億〜数百億のパラメータからなる数値の塊（重み）です。これはソースコードのように人間が読んで再現できるものではなく、学習データそのものでもありません。学習という不可逆なプロセスを経て初めて生成される、第三のレイヤーの資産です。M&Aの表明保証や知財条項は通常「ソースコード」と「データ」を念頭に書かれており、その狭間にある重みは契約上の取り扱いが定義されないまま受け渡される傾向があります。買い手が「コードとデータは引き継いだ」と安心していても、競争優位の核である重みの帰属が宙に浮いている、という事態が起こり得ます。
1-2. 「APIで動いているから引き継げる」という誤解
対象事業が自社モデルを推論エンドポイントとして提供している場合、買い手は「APIが動いているのだから、アカウントを移せば引き継ぎ完了」と考えがちです。しかし、推論サーバーが動いている事実は、その重みファイルを買い手が独立して保有・再配置・再学習できることを何ら保証しません。重みが外部のホスティング型ファインチューニング基盤（クラウドのマネージドサービス）の中にしか存在せず、エクスポートできない契約形態だった、というケースは現実に存在します。動いているエンドポイントと、引き渡せる資産は、まったく別の概念です。
1-3. 再現できないモデルは「ブラックボックスの相続」になる
仮に重みファイルそのものを受け取れたとしても、それを再生成・改善できなければ資産としての寿命は限られます。ベースモデルが廃止される、追加学習が必要になる、不具合の原因を特定したい── そうした局面で学習を再現できなければ、買い手は「中身を理解できないブラックボックスを相続した」状態に陥ります。モデル資産の価値は「現在動くこと」ではなく「将来にわたって再現・改善できること」によって決まるという視点が、DDの起点になります。
2. 重みはどこにあるのか ── 所在と再現性の確認
2-1. チェックポイントの物理的所在を特定する
最初に確認すべきは、学習済みの重み（チェックポイント）が物理的にどこに保存されているかです。自社管理のオブジェクトストレージなのか、クラウドの学習基盤の内部領域なのか、あるいは個人の開発マシンやノートブック環境にしか残っていないのか。「最新の本番モデルの重みが、退職予定のエンジニアのローカル環境にしかない」という属人化は、AI事業のDDで頻繁に遭遇する盲点です。所在が特定できないモデルは、移管計画の対象にすら載せられません。
2-2. 学習レシピ ── ハイパーパラメータと前処理の文書化
重みファイル単体では再現性は担保されません。どのベースモデルに対し、どのデータセットを、どの前処理を施し、どの学習率・エポック数・LoRAランク等のハイパーパラメータで学習したか── この「学習レシピ」が文書化・バージョン管理されているかが、再現性の核心です。レシピが残っていれば、ベースモデルの更新や不具合対応の際に学習をやり直せます。逆にレシピが暗黙知として個人の頭の中にしかなければ、その人物が離脱した瞬間にモデルは更新不能の遺物になります。
2-3. 学習環境の再構築可能性
学習を再現するには、当時の学習環境（ライブラリのバージョン、GPU構成、依存関係）も必要です。フレームワークのバージョン差異だけで学習結果が変わることは珍しくなく、コンテナイメージや依存定義が保存されていなければ「同じレシピなのに同じモデルが作れない」事態が起こります。買い手は、重み・レシピ・環境の三点セットが揃って初めて「再現可能なモデル資産」として評価できる、という前提でDDを設計すべきです。
3. ベースモデルのライセンスが上流から効いてくる
3-1. ファインチューニングは「他人のモデルの上に建てた増築物」
ファインチューニング済みモデルの大半は、既存のオープンウェイトモデル（Llama・Gemma・Mistral・Qwen等）を土台にしています。これは他人の土地の上に増築した建物のようなもので、土台であるベースモデルのライセンス条件が、その上に乗る自社モデルの利用範囲を上流から規定します。自社で追加学習した部分の権利だけを見ても、土台のライセンスに違反していれば、モデル全体を商用利用し続けられないリスクが残ります。
3-2. オープンウェイトモデルに潜む商用条項
「オープン」という語感に反し、主要なオープンウェイトモデルのライセンスには商用利用に関する個別条項が含まれます。たとえば一定規模以上の月間アクティブユーザーを抱える事業者に追加の許諾を求める条項、出力をもとに競合モデルを学習させること（蒸留）を禁じる条項、特定用途を制限するアクセプタブル・ユース・ポリシーなどです。これらはベースモデルごとに異なり、バージョン改定で条件が変わることもあるため、DDでは「どのモデルの、どのバージョンの、どの時点のライセンスに同意して学習したか」を正確に棚卸しする必要があります。
3-3. 「ライセンスの連鎖」が表明保証に跳ね返る
M&A契約では、対象事業の知的財産が第三者の権利を侵害していないことを売り手が表明保証します。ベースモデルのライセンス違反は、この表明保証に抵触し得る論点です。商用利用が許されない条件で学習したモデルを中核資産として譲渡すれば、買収後にライセンス提供元から利用差し止めを受ける可能性があり、その時点でモデル由来の売上が前提から崩れます。商用LLM API契約の名義移管と同様に、ライセンスの適合性と移転可能性は、譲渡対価の前提条件として契約段階で検証されるべき事項です。
4. 学習データの来歴が重みの正当性を決める
4-1. 重みには「学習データの素性」が溶け込んでいる
ファインチューニングに使ったデータの権利関係は、学習を経て重みの中に不可分に溶け込みます。権利的に問題のあるデータで学習したモデルは、その重み自体が問題を内包すると捉えるべきです。スクレイピングで収集した第三者コンテンツ、利用規約で学習利用が禁じられたデータ、顧客から預かった個人データ── これらを学習素材に使っていた場合、重みを引き継いだ買い手が権利侵害やデータ保護の責任を承継するリスクがあります。データの保管リスクを扱ったベクトルDBに学習データを溜めた事業のDDが「保管」の問題なら、本論点は「学習を経て重みに固定された」より不可逆な問題です。
4-2. 来歴（provenance）の追跡可能性
学習データの来歴とは、各データがどこから来て、どの権利・同意のもとで使われたかの記録です。来歴が追跡できれば、買い手は「このモデルはクリーンなデータで作られた」と確認でき、必要なら問題データを除いて再学習する判断もできます。逆に来歴が記録されていなければ、モデルの正当性を後から証明する手段が存在しないため、買い手はリスクプレミアムを大きく織り込むか、その資産を評価対象から外さざるを得ません。
4-3. 削除請求への対応可能性
個人データを含むデータで学習している場合、データ主体からの削除請求にどう対応するかという論点が残ります。学習済みモデルの重みから特定の個人の影響だけを除去することは技術的に容易ではなく、「削除請求に応じられない構造のモデル」はデータ保護上の継続的なリスクとして買い手に承継されます。DDでは、学習データの同意取得状況と、削除請求への対応設計の有無を確認する必要があります。
5. 移管DDの実務 ── 重み・データ・パイプラインの引き継ぎ検証
5-1. 「重み・レシピ・データ・環境」の四点開示を求める
買い手DDの初手は、①重みファイル本体とその保存場所、②学習レシピ（ハイパーパラメータ・前処理）、③学習データとその来歴記録、④学習環境（依存関係・コンテナ定義）の四点開示を、LOI段階の条件として組み込むことです。この四点が揃わないモデルは「再現不能なブラックボックス」として、譲渡対価の根拠から外して評価する姿勢が、後の減額交渉や破談を避ける現実的な防衛になります。
5-2. ベースモデルのライセンス棚卸しと商用適合性の検証
使用している全ベースモデルについて、モデル名・バージョン・ライセンス種別・商用条項の有無・名義や事業形態の変更がライセンスに影響しないかを一覧化します。特にM&Aによる事業主体の変更が、ベースモデルの利用許諾の前提を崩さないかは要確認です。提供元の利用規約に「事業譲渡時の権利移転」に関する条項があるかどうかで、移管の可否が分かれます。
5-3. 引き継ぎ後の再学習リハーサル
可能であれば、クロージング前に買い手側の環境で小規模な再学習リハーサルを行い、開示された四点だけで実際にモデルを再現できるかを検証します。「ドキュメント上は揃っているが、実際にやってみたら再現できない」という乖離は、技術DDを本気で行わなければ表面化しません。再現できることを実地で確認して初めて、そのモデルは引き渡し可能な資産として確定します。
6. 売り手が「再現可能なモデル資産」として価値を守る
6-1. 学習レシピと来歴の文書化が、そのまま信頼の証明になる
売り手にとって、重み・レシピ・データ来歴・学習環境を整理し文書化しておくことは、単なる引き継ぎ準備ではありません。「このモデルは管理された手順で、クリーンなデータから、適法なベースモデルの上に作られた」という事実そのものが、買い手にとって最高の信頼材料になります。属人化したまま「精度が高いから価値がある」と主張するより、再現可能性を証明できる売り手のモデル資産のほうが、構造的に高く評価されます。
6-2. ライセンスの自主点検と是正計画
ベースモデルのライセンスや学習データに懸念がある場合、隠して譲渡を進めるより、自主点検の上で是正計画（許諾の取得・問題データを除いた再学習・代替ベースモデルへの移行）をセットで開示するほうが、最終的な手取りを守ります。買収後にライセンス違反が露呈すれば表明保証違反として対価返還を求められ得る一方、事前開示なら是正コストを織り込んだ着地が可能だからです。これはAI機能依存度のスコアリングと同じく、弱点を可視化して管理下に置くほうが価値を守るという逆説が働く領域です。
6-3. モデルを「動く実装」から「継承できる資産」へ
ここまで、重みという第三のレイヤーの特殊性、所在と再現性、ベースモデルのライセンス、学習データの来歴、移管DDの実務を順に剥がしてきました。共通するのは、モデルの価値は「今動いていること」ではなく「誰の手でも再現・改善でき、権利的に安全であること」によって決まるという事実です。財務DDはモデルが生む売上を見ます。しかし、その売上を支える重みが引き渡せるのか、再現できるのか、適法なのかを問うのは、コードを読み、学習を理解する人間だけです。動く実装を、継承できる資産に変える。その作業こそが、AI事業のモデルを譲渡対価に見合う本物の資産にします。
