Unity・Unreal・3Dアセットの権利と技術DD｜VR/XR M&Aで見落とせないチェックポイント

VR・AR・MR・メタバース事業のM&Aでは、決算書だけを読んでも企業価値の核心には届きません。製品を動かすUnity／Unreal Engineの利用条件、3Dモデルや音源のライセンス、外注先との著作権契約、ソースコードとビルド環境、ストア用アカウント、端末運用、取得データまでが一本の鎖としてつながっているからです。本稿では、譲渡企業・買い手が「何を、どの証拠で、どこまで確かめるか」を、VR M&A 技術DDの実務に沿って解説します。

1．VR M&A 技術DDが通常のソフトウェアDDと違う理由

一般的なSaaSでもソースコード、クラウド、個人情報、OSSは重要です。しかしXR製品では、それに3Dモデル、テクスチャ、モーション、音声、空間マップ、端末固有SDK、レンダリングパイプライン、HMDの配備手順などが加わります。一つの体験を構成する要素が多く、しかも要素ごとに権利者や更新主体が異なります。キャラクターは外部クリエイター、背景はマーケット購入、音声は素材サイト、人物モーションは演者、点群は測量会社、アプリは自社と再委託先の共同開発という構造も珍しくありません。

そのため、画面上の完成品だけを見て「自社開発」と判断するのは危険です。買い手が欲しいのはAPKや実行ファイルのコピーではなく、改修、再ビルド、配布、顧客サポートを継続できる事業です。たとえばソースコードが揃っていても、有料プラグインの購入主体が元従業員個人であれば、新しい法人で開けない可能性があります。反対に、ライセンスが適切でも、使用中のエンジンバージョンやパッケージの固定情報がなく、同じ成果物を作れなければ保守価値は下がります。

DDの目的は違反を探して責めることではありません。「買収後に誰が、どの契約と環境を使い、どの費用を払い、どの品質でサービスを続けるか」を可視化することです。未整理な事項は、補正費用と所要期間を見積もれる単位まで分けます。重大性は、権利侵害の可能性だけでなく、代替困難性、顧客影響、停止時間、再制作費、契約解除リスク、ブランドへの影響を総合して判断します。

株式譲渡では会社という法主体が存続するため、契約やアカウントが形式上そのまま残ることがあります。ただしチェンジ・オブ・コントロール条項、利用規約上の支配変更、キーパーソン退職、個人名義アカウントなどを確認せず「株式譲渡だから安全」とは言えません。事業譲渡では、資産・契約・許諾を個別に移す必要が生じやすく、承継可否の調査がさらに重要です。最終判断は取引形態、準拠法、各契約の文言によって異なるため、弁護士・会計士・技術専門家と個別に確認してください。

2．最初に作る「技術・権利・運用」の三層台帳

資料請求を無秩序に始めると、数千のファイルと多数の契約に埋もれます。最初に製品・案件単位の一覧を作り、各行に技術、権利、運用の三層をひもづけます。対象は販売中の製品だけではありません。保守中の旧版、顧客専用フォーク、展示用デモ、研究試作、ストア非公開アプリ、営業動画に使う素材も含めます。売上がなくても、第三者権利や秘密情報を抱える成果物はリスクの発生源になります。

技術欄には、リポジトリURL、既定ブランチ、最新リリースタグ、エンジンと正確なバージョン、レンダリング方式、対象OS・HMD、主要SDK、バックエンド、CI/CD、担当者を記録します。「Unity 2022」では足りず、パッチバージョン、LTSか否か、利用パッケージのロック情報まで必要です。Unrealではエンジンのソース改変の有無、バイナリ版かソースビルドか、プラグインとターゲットプラットフォームを確認します。

権利欄には、著作者・権利者、取得方法、自社制作・業務委託・購入・顧客提供の区分、契約書・発注書・請求書・購入履歴へのリンク、ライセンス種別、使用範囲、再許諾・改変・配布・承継に関する条件を記録します。3Dモデルならメッシュだけでなく、テクスチャ、フォント、モーション、音声、ロゴ、写真、スキャン元の建物・文化財・人物の許諾も確認します。権利台帳は法務部だけの表ではなく、UnityやUnrealのプロジェクト内のパスと対応して初めて機能します。

運用欄には、ビルド担当、配布者、障害一次対応、端末初期化、アカウント管理、月次費用、更新周期、SLA、顧客との役割分担を置きます。技術的に動く製品でも、現地スタッフだけが知るキャリブレーションや衛生管理、予備機交換、施設ネットワーク設定が失われれば事業は止まります。地域の観光施設、学校、工場、医療・福祉現場では、営業時間、年度予算、入札・補助事業、現地回線、端末持ち出し規程などが保守方法を左右します。

三層台帳の利点は、問題がどこに波及するか見えることです。たとえば特定のアバターSDKが更新停止なら、技術欄では代替実装、権利欄では現行利用条件、運用欄では顧客更新計画を同時に追えます。台帳の一行ごとに「証拠あり」「要確認」「是正中」「対象外」を付け、未確認を曖昧な空欄にしないことが、短いDD期間での品質を上げます。

3．Unity本体とAsset Storeの確認

3-1．エディターの利用条件と席数

Unityの公式Editor Software Termsでは、適用条件と料金の遵守を前提に、Offering Identificationに定めたAuthorized Usersの人数に応じてUnity Editorを社内利用する権利が示されています。したがってDDでは、契約プラン名だけでなく、対象期間の組織売上・資金調達等とプラン適格性、割り当てユーザー、更新日、未払い、利用するエディターバージョンを照合します。料金体系や規約は変更され得るため、過去の解説記事ではなく、対象バージョンに適用される規約と現在の公式ページを確認します。

買収で従業員や開発会社の所属が変わると、同じ席数でよいとは限りません。子会社、関連会社、独立した委託先がプロジェクトを扱う場合は、契約主体と利用者の関係を図にします。買い手はクロージング後の体制を仮置きし、必要なプラン・席数・追加費用をランレートに反映します。譲渡企業は管理画面のスクリーンショットだけでなく、請求書、契約主体、割当一覧、利用端末、退職者の解除記録を準備すると説明が早くなります。

3-2．Asset Store購入物は「買ったから自由」ではない

Unity Asset Storeの公式FAQは、掲載物の多くが第三者パブリッシャーによるもので、利用者はそのパブリッシャーからライセンスを得ると説明しています。また、標準EULAのほか非標準ライセンスやRestricted Assetがあり得るため、パッケージ名だけで一律処理できません。商品ページ、購入時の条件、注文番号、ライセンスタイプを個別に保存します。販売終了したパッケージは当時の証拠が取得しにくいため、早期にエクスポートしてデータルームへ置きます。

公式FAQでは、Extension型はプロジェクトでインストールする人ごとの席が問題になり、Single EntityとMulti-Entityの選択、独立委託先や企業グループとの関係も説明されています。特に重要なのは、Multi-Entityだから顧客まで当然にカバーされるわけではないという点です。受託開発で譲渡企業が買った素材を顧客のプロジェクトへ納品した、委託先が自己アカウントで買ったツールを自社リポジトリへ入れた、買収後は別法人の開発チームが触る、といった場面は重点確認します。

配布についても、素材を製品へ埋め込めば何でもよいわけではありません。公式FAQは、Asset Store外の十分な独自創作を含み、素材配布を超える目的・機能を持つ製品に組み込む考え方や、エンドユーザーが素材を個別に抽出できないことを説明しています。ユーザーが3D空間を編集し素材を書き出せるUGC型サービス、テンプレート販売、素材カタログ、SDKをランタイムに含む製品は、通常の完成アプリとは論点が異なります。必要ならパブリッシャーに別途許諾を取り、回答を記録します。

実務では、プロジェクトのPackages、Assets、Package Manager、manifest／lock情報から購入・導入物を抽出し、購買台帳と突合します。ファイル名を変えたりフォルダを移動したりした素材も、GUIDやメタデータ、テクスチャの類似性、担当者ヒアリングで追います。「無料素材」「試作品にしか使っていない」という説明も証拠なく除外しません。無料でも条件はあり、試作品が営業映像や顧客デモへ転用されることがあるためです。

3-3．Unityプロジェクトで確認する技術項目

Unityはアセットと.metaファイルの対応が参照関係を支えます。リポジトリに.metaが不足すると、別環境で参照切れが起こる可能性があります。ProjectSettings、Packages、必要なAssetsを取得し、LibraryやTempのような生成物との区別を確認します。レンダリングパイプライン、シェーダー、Addressables、Input System、XR Plug-in Management、OpenXR、各HMDベンダーSDK、ネイティブプラグイン、iOS／Androidの依存関係を一覧にします。

エディターを起動できるだけでは合格ではありません。ライセンス認証後にパッケージ解決が完了するか、警告・コンパイルエラーがないか、主要シーンが欠損なく開くか、対象端末向けに署名付きビルドが作れるか、ログイン・決済・分析・音声通信など外部機能が動くかを確認します。品質評価では平均フレームレート、メモリ、発熱、ロード時間、クラッシュ率、トラッキング喪失時の復帰、ネットワーク切断時の挙動を、顧客利用条件に近い端末で計測します。

4．Unreal Engine、Fab、Epic提供コンテンツの確認

4-1．エンジンとコンテンツを分けて読む

Unreal Engine EULAは、Engine Code、Examples、Starter Content等からなるLicensed Technologyと、Epic運営マーケットプレイス等から得るContentを区別しています。つまり「Unrealで使えるもの」を一つの規約でまとめて判断できません。エンジン本体、Starter Content、Fab等で取得したコンテンツ、MetaHuman関連、第三者プラグイン、独自契約素材を分類し、それぞれに適用される条件を確認します。

公式EULAでは利用形態によりロイヤルティ、Seat subscription、またはその双方が問題となり得ます。映像等のNon-Engine Products、特定顧客向けの利用、一般販売するRoyalty Product、社内・受託開発では論点が変わるため、売上を会社全体の一行で見るのではなく製品・配布形態ごとに整理します。過去の売上報告、リリース通知、控除対象、カスタムライセンスの有無も確認し、未確定事項はEpicまたは専門家へ照会します。

UnrealのソースコードやEngine Toolsを含む配布には特有の制限があります。改変エンジンを顧客へ渡した、プラグインとしてEditor／Developerフォルダのコードを含めた、デバッグ目的でエンジンソースを外部共有した、といった履歴を調べます。EULAには互換性のないライセンスとの組み合わせに関する規定もあるため、GPL等のOSSを「無料だから」と安易に静的結合していないか、構成と配布方法を技術・法務双方で確認します。

4-2．Fab等のコンテンツと取得証拠

Fabや旧マーケットプレイスから得た3Dモデル、マテリアル、環境、アニメーション、サウンド、プラグインは、Epic Content License Agreementその他の個別条件に照らします。ライセンス層、取得時期、購入アカウント、対象プロジェクト、ソース形式での共有、生成AI関連の表示・条件など、対象コンテンツに応じた確認が必要です。規約改定やサービス統合があるため、DD実施時点の公式条件と取得時点の記録を併記します。

買い手はVaultやライブラリ画面だけでなく、プロジェクトに実際に入っている素材と照合します。Megascans、MetaHuman、サンプルプロジェクト由来素材などは、名前や出所が曖昧になりやすい領域です。エンジンの利用条件とコンテンツの条件を混同せず、他エンジンへの移植、素材単体の再配布、顧客へのソース納品、グループ会社での共同利用が許されるかを個別に確認します。

4-3．Unrealプロジェクトで確認する技術項目

Unrealの.uassetや.umapは主としてバイナリで、一般的なテキストマージが難しいため、公式ドキュメントでもチェックアウト／ロックを伴うソース管理が説明されています。Perforce、SVN、Git LFS等の選定そのものより、全資産が管理対象に入り、履歴・ロック・バックアップ・復元が機能しているかが重要です。ContentだけでなくConfig、Plugins、Source、必要に応じてビルド環境関連ファイル、エンジン改変差分を確認します。

検証では、指定エンジンを用意し、プロジェクト生成、C++コンパイル、シェーダーコンパイル、Cook、Package、署名、対象HMDでの起動まで実行します。Derived Data CacheやIntermediateが残っているため偶然動く状況を避け、クリーンな端末・新しいワークスペースで試します。Blueprintだけに見える製品でも、マーケットプラグインやネイティブSDKがビルドを左右します。専用サーバー、Pixel Streaming、クラウド配信を含む場合は、インフラ構成とデプロイ手順まで再現対象です。

5．外注成果物と著作権契約

5-1．代金を払った事実と著作権の帰属は同じではない

XR企業では、プログラム、UI、3DCG、撮影、ナレーション、音楽、モーション、シナリオを複数の外部人材へ発注します。請求書に「制作費」とあっても、それだけで必要な著作権がすべて移転したとは断定できません。基本契約、個別契約、仕様書、発注メール、検収記録、納品物をつなぎ、誰が何を作り、どの権利をどの範囲で許諾・譲渡したかを確認します。

日本の著作権法第27条は翻訳・翻案等、第28条は二次的著作物の利用に関する原著作者の権利を定めています。著作権法第61条第2項との関係から、著作権譲渡契約で第27条・第28条の権利を明示する実務が重視されます。また著作者人格権は譲渡できないため、改変、氏名表示、公開方法を想定した不行使合意の有無を確認します。ただし契約の有効性・解釈は個別事情によるため、条項があるだけで機械的に安全と判断せず専門家が精査します。

3Dモデルは一人の成果物とは限りません。原画、キャラクターデザイン、モデリング、リギング、モーション、衣装、テクスチャに別々の作成者が関与します。実在人物を基にすれば肖像・パブリシティ、声を使えば実演・音源、建物や美術品をスキャンすれば施設規約・所有者との契約なども問題になります。文化財、学校、医療機関、工場内で撮影・スキャンした地域案件では、撮影許可と商用二次利用、M&A後の利用主体まで確認します。

5-2．顧客案件で「何を納品し、何を再利用できるか」

受託XR開発は、顧客ごとに権利条件が違います。成果物の全権利を顧客へ移したのに共通モジュールとして他案件へ転用している、逆に自社基盤を留保したつもりが契約上は成果物一式を譲渡している、といった不一致が企業価値を左右します。契約における成果物の定義、既存知財、汎用ノウハウ、OSS・市販素材、改変物、派生成果物、ソースコード納品、エスクローを確認します。

一つのリポジトリに複数顧客の素材や秘密情報が混在している場合、買い手への開示自体がNDA違反になる可能性があります。データルームへ上げる前に顧客情報を区分し、必要に応じて匿名化、閲覧者制限、クリーンチーム、同意取得を用います。成約後の統合では、共通基盤と顧客固有部分を分離し、アクセス権を再設計します。

5-3．不足契約の直し方

過去の外注契約が不足していても、直ちに価値がゼロになるとは限りません。作成者と成果物を特定し、確認書や追加譲渡・許諾契約を締結する、該当素材を買収対象から外して再制作する、利用範囲を限定する、代替ライブラリへ置き換える、対価を追加で支払う、といった是正案があります。重要なのは「後で何とかする」ではなく、対象ファイル、相手方、必要権利、交渉状況、費用、期限、失敗時の代替策を是正台帳にすることです。

連絡不能の元委託先、権利者がさらに再委託した素材、海外法が関係する契約は時間がかかります。譲渡企業はM&A開始前から重要製品順に調査し、買い手は署名・クロージングの条件に織り込むべきか判断します。軽微な素材は価格調整や補償で受け、コアキャラクターや基盤コードのように代替困難なものはクロージング前の解消を求める、というリスクベースの優先順位が実務的です。

6．OSS、SDK、プラグインとソフトウェア構成

XRアプリは、エンジンの上に多数のOSS・商用SDK・無償SDKを積み上げます。音声通信、アバター、物理演算、認証、分析、広告、決済、地図、AI、動画再生、圧縮などを網羅すると、経営者が認識する数より実際の依存物が大幅に多いことがあります。package manifest、lock file、Gradle、CocoaPods、UPM、NuGet、npm、サブモジュール、Pluginsフォルダ、バイナリのスキャン結果を統合し、SBOMに近い一覧を作ります。

各依存物について名称、バージョン、取得元、ライセンス、著作権表示、改変、リンク・組込方法、配布物への包含、既知脆弱性、更新状況、代替可否、社内責任者を記録します。MITやApache-2.0のように比較的利用しやすいライセンスでも、著作権表示やライセンス文の同梱等の条件があります。GPL、LGPL、AGPL、MPL等は、結合・改変・ネットワーク提供などの状況で義務が変わり得ます。「OSSだから無料」「ソースを公開していないから問題ない」という判断は避け、構成と利用形態を専門家が確認します。

Unreal Engine EULAにはNon-Compatible Licensesに関する規定があり、特定のライセンスで覆われたコード等との組み合わせが制限される例が示されています。エンジン規約とOSS条件を別々に読んで終わらず、両方を同時に満たせる構成かを確認します。Unityでも、Asset StoreのSDK、パブリッシャー独自条件、外部サービス規約、OSSが一つのプラグインに混在する場合があります。

脆弱性評価ではCVSSの点数だけを並べません。HMDが閉域で動くのか、インターネット公開APIがあるのか、管理者権限を持つのか、個人データへ到達できるのか、悪用容易性、修正バージョン、テスト負荷を確認します。サポート終了SDKや古いAndroid APIは、次回ストア審査やOS更新で配布継続を妨げる可能性があります。買収時点で動いていても、半年後に更新できない「技術的負債」を、更新ロードマップと費用へ置き換えることがDDの役割です。

7．リポジトリとビルド再現性

7-1．ソースコードの「完全性」を証明する

リポジトリが存在するだけでは十分ではありません。売上を生む最新版とリポジトリの状態が一致するか、リリースタグが打たれているか、顧客別フォークがローカルPCだけに残っていないか、履歴に秘密鍵・個人情報・顧客素材が混入していないかを確認します。GitHub、GitLab、Bitbucket、Azure DevOps、社内Git、Perforceなど複数系統がある場合は、全組織・全プロジェクト・アーカイブを棚卸しします。

Git LFSは大容量ファイル本体の代わりにポインタをリポジトリへ置く仕組みです。そのため通常のGit cloneが成功しても、LFSオブジェクトが欠ければ3Dモデルや動画は取得できません。請求停止、容量超過、退職者個人のLFS、移行失敗、古いコミットのオブジェクト欠損を確認します。検証者は履歴を含めて必要オブジェクトを取得し、ハッシュ、容量、復元テストを記録します。バックアップも「設定済み」ではなく、別管理者が復元できた日時を証拠にします。

アクセス権では、組織所有者が一人だけ、個人メールが管理者、退職者のSSH鍵が有効、委託先が全顧客を閲覧可能、といった状態を是正します。管理者二名以上、会社管理のメール、MFA、最小権限、緊急アカウント、退職時手順、監査ログ保持を確認します。買収公表前に一斉移行すると情報漏えいにつながるため、署名からクロージングまでの権限切替計画を時系列で作ります。

7-2．クリーンビルド試験の設計

技術DDの中心はクリーンビルドです。日常開発機はキャッシュ、手動配置SDK、保存済み認証、ローカルパッチに依存しているため、担当者の画面共有でビルドできても承継性は証明できません。買い手側または独立検証者が、空の端末や再作成可能な仮想環境でREADMEだけを頼りに環境を構築します。ネットワーク制限、OS、CPU／GPU、エンジン、IDE、JDK、Android SDK／NDK、Xcode、証明書、環境変数まで記録します。

成功条件は「ビルド完了」に留めません。リリース版と同じapplication ID、バージョン、署名方式で成果物を作り、ハッシュを保存し、対象HMDへ配備します。ログイン、チュートリアル、主要体験、保存、同期、オフライン復帰、管理画面、課金や計測など重要シナリオを実行します。再現できない場合は、手順不足、依存物消失、権限不足、コード欠損、環境差分に分類し、担当・期限・費用を置きます。

完全なバイト単位の再現性はプロジェクトによって難しく、必ずしも全案件の必須条件ではありません。時刻やビルドID、圧縮、シェーダー等で差が出るためです。重要なのは、同じ機能と承認可能な品質を持つリリース候補を、特定個人の記憶に依存せず作れることです。規制産業、医療用途、訓練記録を扱う案件では、より厳密な構成管理・検証記録が必要になり得ます。

7-3．CI/CDとリリース承認

CI/CDがあれば安心ではなく、実行主体と秘密情報を確認します。GitHub Actions、GitLab Runner、Jenkins、Unity Build Automation、クラウドビルド等の設定、ランナー、課金、キャッシュ、アーティファクト保持、承認者を棚卸しします。個人PC上のセルフホストランナーや、退職予定者だけが知るJenkinsは事業継続上の弱点です。

本番リリースに誰の承認が必要か、緊急修正はどう行うか、元に戻せるかを確認します。ストア審査用ノート、プライバシー表示、年齢区分、権限申告もリリース工程の一部です。CIの成功率、平均所要時間、失敗原因、手動作業を数回分観察すると、見かけ上の自動化と実際の運用差が見えます。

8．アカウント、署名鍵、ストア、クラウド

XR事業の停止原因はコードだけではありません。Meta、PICO、Apple、Google、Steam、PlayStation等の開発者アカウント、Unity／Epic組織、クラウド、ドメイン、DNS、証明書、CDN、分析、エラー監視、メール配信、決済、サポートツールを「デジタル鍵台帳」にします。各サービスについて契約主体、所有者、請求先、管理者、MFA端末、回復手段、利用製品、月額、更新日、承継方法を記載します。

個人名義や元経営者の携帯番号に依存するアカウントは、クロージング前後の移行失敗リスクが高い項目です。単にパスワードを渡す行為は規約違反やセキュリティ事故になり得るため、各サービスの正式な組織移管、管理者追加、アプリ移管手順を使います。移管に審査や日数が必要なら、TSA（移行サービス契約）や暫定運用を設計します。

Android署名鍵、iOS証明書・プロファイル、サーバーTLS、APIキー、OAuthクライアント、Webhook secret等は、漏えいと紛失の双方を確認します。リポジトリ履歴やチャットに平文で残っていないか、ローテーション可能か、鍵管理サービスを使うか、バックアップ・復旧者がいるかを調べます。既存アプリと同一IDでアップデートする鍵を失うと、ユーザーへ新アプリとして再配布せざるを得ない場合があります。

クラウドDDでは請求額だけでなく、アーキテクチャ、リージョン、可用性、監視、バックアップ、復元、IaC、管理者、委託先、ログ保持を確認します。オンライン展示会や多人数メタバースはイベント日に負荷が集中するため、平月平均よりピーク時の同時接続、動画転送、音声通信、待機室、障害時縮退を見ます。契約上約束するSLAと実際の構成が一致するか、クラウドクレジット終了後の原価も試算します。

9．空間・行動・生体関連データの確認

XRは、氏名やメールアドレス以外にも、頭部・手の動き、視線、音声、アバター、プレイエリア、空間マップ、カメラ映像、端末ID、IPアドレス、行動ログを扱います。データの法的評価は取得内容・目的・識別可能性・他情報との照合によって変わるため、「匿名の座標だから個人情報ではない」と一括判断しません。個人情報保護委員会の法令・ガイドラインやメタバース関連報告、顧客の業界規制、国外移転を確認します。

データフロー図では、HMD・スマートフォン・センサーから何を取得し、端末内、譲渡企業のクラウド、HMDベンダー、分析SDK、顧客環境のどこへ送るかを示します。項目、粒度、頻度、目的、同意画面、保存期間、削除、暗号化、アクセス者、第三者提供・委託、国外移転、学習利用を記録します。録音・録画、視線ヒートマップ、空間スキャンは、営業資料に書かれていない実装が残っていないかコードと通信ログで確かめます。

M&Aでは、株主変更または事業譲渡に伴うデータの取扱いも論点です。株式譲渡と事業譲渡では法主体の継続性が異なり、プライバシーポリシー、顧客契約、同意文言、委託契約を個別に読む必要があります。買い手が別目的で分析やAI学習へ使うなら、当初目的との整合を再評価します。データを「資産」として評価する前に、利用可能な範囲、品質、偏り、削除義務、再同意の費用を見積もります。

学校・未成年者向け、医療・福祉、防災訓練、従業員評価などは、利用者が自由に拒否しにくい場面があります。必要最小限、代替手段、説明の平易さ、保護者・施設との役割、事故時連絡を慎重に設計します。カメラが周囲の人や機密設備を撮影する可能性、現場スタッフが個人端末へログを保存する可能性も運用テストで確認します。

10．HMD・周辺機器・現場運用

VR案件では、ソフトウェアと端末の組合せが商品です。Quest、PICO、VIVE、PCVR、スマートグラス等について、モデル、世代、台数、シリアル、所有・リース、購入日、保証、バッテリー状態、付属品、予備機、設置場所を台帳化します。生産終了やOSサポート、交換部品、コントローラー互換性、ケーブル調達を確認し、保守契約期間中に必要台数を維持できるか試算します。

多拠点展開では、MDMや組織管理、キオスクモード、アプリ配布、Wi-Fi設定、OS更新の保留・検証、ログ取得、遠隔支援、初期化、紛失時ワイプが重要です。十台のデモと数百台の常設運用では必要能力が違います。管理コンソールの契約主体と席数、端末の登録状況、担当者、更新失敗率、現地作業時間を確認し、クロージング時に端末が新組織へ再登録を要するかを調べます。

現場手順は文書と観察で検証します。充電、レンズ保護、衛生カバー、清掃剤、装着補助、眼鏡利用、転倒防止、境界設定、ケーブル養生、利用中止基準、体調確認、子どもへの対応、故障切り分け、発送を確認します。医療助言ではありませんが、利用者の安全や機器メーカーのガイダンスに沿った手順があるかは事業継続の重要事項です。

地域施設では、担当者が兼務で毎日IT対応できない、通信が弱い、端末を夜間別室に保管する、繁忙期に交換できないなど固有条件があります。本社でのデモ成功だけで評価せず、代表的な現場を訪問し、開館から終了までの運用を追います。地域の保守パートナー、配送日数、代替機の配置、交通費を含む実原価を案件採算へ戻します。

11．案件採算と保守債務

技術DDは費用と収益へ接続して初めてM&A判断に使えます。XR案件の売上をPoC、本導入、追加拠点、コンテンツ更新、端末販売・レンタル、保守、イベント運営、ライセンスに分け、直接工数、外注、クラウド、SDK、端末、移動、現場対応を対応づけます。PoCが高粗利に見えても、本導入を前提に無償追加開発を続けている場合があります。案件別損益と工数記録を契約・リポジトリ履歴と突合します。

売上認識の妥当性は会計専門家の領域ですが、技術チームは検収条件と完成度を説明できます。未完成機能、顧客環境依存、無償保証、ソース納品、脆弱性修正、OS追随、端末交換、コンテンツ更新の約束を拾います。「保守費をもらっていないが関係上対応している」顧客は、将来負担として可視化します。

自治体・観光協会・DMO・学校等の案件では、年度予算、入札参加資格、類似実績、補助事業の期間、再委託承認、成果物利用条件、事業終了後の保守財源を確認します。M&Aによる商号・支配変更で届出や承認が必要か、次年度も同じ契約が続く保証があるかを区別します。地域の関係者との信頼は価値ですが、特定経営者一人に集中していれば引継ぎ計画が必要です。

12．DDの進め方と検証手順

12-1．第1週：スコープと重要度

最初に売上、顧客数、戦略性、権利の複雑さ、停止影響から上位製品を選びます。全ファイルを同じ深さで見るのではなく、コア製品はサンプルではなく全件、低重要デモは代表サンプルというように範囲を合意します。質問管理表には質問、背景、要求証拠、回答、追加質問、重要度、責任者、期限を持たせます。

キックオフには経営者だけでなく、テックリード、3D責任者、インフラ、営業・PM、法務・総務、経理、現場運用担当を参加させます。一人の回答で完結させず、契約上の説明と実装・運用が一致するか確認します。秘密性が高い顧客は段階開示にし、初期は匿名化した契約一覧、意向表明後に原本という設計も検討します。

12-2．第2〜3週：証拠収集と実機試験

権利台帳、依存物一覧、アカウント一覧を作りながら、リポジトリ解析、クリーンビルド、実機シナリオ、クラウド構成レビューを並行します。資料だけの法務班とコードだけの技術班に分断せず、共通IDで発見事項を結びます。例として「R-017 外注アバター」は、契約不足、該当ファイルパス、使用製品、売上、代替工数を一枚で追います。

顧客案件は契約書、提案書、仕様書、議事録、検収、請求、チケット、コードを一つの流れで確認します。仕様上は端末五十台でも実台帳は四十二台、契約は四半期更新でも担当者は無期限対応と認識、といった差異が見つかります。差異は誰かの誤りと決めつけず、事実、影響、追加証拠、暫定評価を分けて記録します。

12-3．最終週：再現・反証・経営翻訳

重要発見事項は譲渡企業に反証機会を設けます。購入履歴がない素材も、顧客提供や別アカウント取得の証拠が後から出ることがあります。逆に説明だけでクローズせず、証拠の所在と妥当性を記録します。未確定は未確定として確率・最大影響・期限を示します。

最終報告はエラー数を並べず、事業への意味に翻訳します。「重大脆弱性一件」ではなく「認証前APIから顧客イベント資料へ到達する可能性があり、公開停止または七営業日の改修・顧客通知判断が必要」のように、条件付きで伝えます。確定事実、合理的推測、推奨策を明確に分けます。

13．発見事項を価格・契約・PMIへつなぐ

発見事項の出口は概ね五つです。第一はクロージング前の是正。コアIPの追加譲渡、管理者移行、重大脆弱性修正などです。第二は価格への反映。再制作・追加ライセンス・端末更新・人員採用の必要費を事業計画へ入れます。第三は表明保証・補償。過去の権利侵害や未払ライセンス等について範囲、上限、期間を交渉します。第四は前提条件・解除条件。重要顧客同意やアプリ移管が得られない場合を定めます。第五はPMI計画。緊急ではない負債を100日計画へ移します。

単純に是正費用を企業価値から引くだけでは不十分です。コア技術が再現不能なら売上継続確率や成長率に影響し、顧客集中と組み合わされば大きなリスクになります。一方、整理不足でも強いチームが短期間で修正でき、顧客満足と継続率が高ければ、条件設計で取引可能なこともあります。譲渡企業の回答速度、証拠の整合、問題を隠さず改善する文化は、PMI実行力の判断材料です。

価値向上につながる証拠も拾います。複数端末へ移植できる抽象化、再利用可能な基盤、明確な権利、完全自動ビルド、障害対応履歴、案件別採算、低いキーパーソン依存、継続的な顧客更新は、将来キャッシュフローの確度を高めます。ただし「独自AI」「特許級」「業界唯一」などの表現は、登録・性能比較・契約上の独占性がない限り断定しません。

14．譲渡企業が90日前から整える資料

90〜61日前：全体像を一枚にする

製品・案件一覧、リポジトリ、エンジン版、主要顧客、売上、保守期限、担当者を一枚にまとめます。完全でなくてよいので空欄を「不明」と記載し、調査担当を置きます。同時に会社管理でないアカウント、退職者権限、請求停止、期限切れ証明書を洗い出します。事業売却の事実を広く知らせず、必要最小限のチームで進めます。

60〜31日前：権利と再現性を固める

売上上位製品からAsset Store／Fab／素材サイト購入物、外注契約、顧客契約、OSSをひもづけます。別担当者がクリーンビルドし、欠けた手順をREADMEへ反映します。アカウントの会社名義化、MFAバックアップ、鍵のローテーション計画を進めます。問題は削除して隠さず、是正前後の記録を残します。

30日前〜開示：説明可能なデータルームへ

フォルダは製品単位と共通基盤に分け、目次、版、基準日、責任者を付けます。契約書は署名済み原本、変更契約、個別発注まで一組にします。個人情報・顧客秘密・秘密鍵はそのまま置かず、権限分離、墨消し、クリーンチームを使います。質問への回答は口頭だけでなく、根拠ファイルをリンクします。

DD前の整理は、問題をゼロに見せるためではありません。事実と対応策が短時間で伝わる状態を作ることです。譲渡企業が自ら重要リスクを開示し、費用・日程・代替案を示せれば、買い手は不確実性に過大な割引を置かずに済みます。VR企業の譲渡準備については、VR M&A総合センターのトップページから秘密保持を前提に相談できます。

15．素材種別ごとの権利確認をさらに深掘りする

3Dモデル、CAD、点群

3Dデータの権利確認では、完成した.fbx、.blend、.max、.ma、.glbだけを対象にしません。原画、CAD、写真測量の原画像、スキャン、点群、リトポロジー、UV、テクスチャ、リグ、シェイプキー、LOD、衝突判定データまで生成経路を追います。顧客から「使ってよい」と渡されたCADに、設備メーカーや設計者の権利・営業秘密が含まれることもあります。受領時の目的が提案用映像に限定されていれば、買収後の製品化や他顧客への再利用が許されるとは限りません。

文化施設、観光地、商業施設、工場を3D化した場合は、撮影・測量許可、立入条件、公開範囲、施設名・ロゴ、セキュリティ上非公開とすべき設備を確認します。ドローン、LiDAR、360度撮影には、場所と方法に応じて別の法令・施設規程が関係し得ます。DDでは「法的に撮影可能だったか」を抽象的に聞くだけでなく、申請書、許可メール、撮影日、範囲、成果物の商用利用条件を証拠化します。

データの再利用性も価値評価に影響します。元の高解像度データと最適化済みモデルが揃い、変換手順と単位系、座標系、スケール、命名規則が明確なら、別端末や別案件への展開がしやすくなります。逆に実行ファイル内の圧縮済みデータしかなく、原本・制作ファイル・設定が欠ける場合は、見た目が同じでも技術資産としての柔軟性が低くなります。

アバター、人物、モーション、音声

アバターは、デザイン、モデル、衣装、モーション、声、名称、ロゴが権利の束です。演者との契約では、収録媒体、利用地域、期間、広告利用、改変、合成音声・AI学習、二次商品化、契約終了後のアーカイブ、M&A後の利用主体を確認します。古い契約に生成AI利用が書かれていない場合、当然に学習へ使えると推測せず、当初目的と追加同意を検討します。

モーションキャプチャでは、演者の実演に加え、スタジオやオペレーターが成果物へ持つ権利、機材ソフトの出力条件を確認します。市販モーションを修正した場合は、元素材の条件と自社修正部分を分けます。音声はナレーター、声優、作曲者、原盤、効果音ライブラリの関係を整理し、配信・展示・広告・海外利用の範囲を見ます。買い手は著名性だけでなく、契約更新費、代替可能性、炎上・活動終了時の差し替え計画も事業リスクとして評価します。

フォント、UI、動画、生成AI出力

フォントは小さく見えて頻繁に問題となる素材です。デスクトップ用ライセンスでアプリへ埋め込んでいないか、WebフォントのPV条件、ゲーム・アプリ利用、サーバー生成、ロゴ利用、再配布を確認します。UIキット、アイコン、写真、動画テンプレートも同様です。納品された画像へ統合済みなら許されるが編集可能テンプレートの顧客納品は不可、という条件もあり得るため、利用態様を見ます。

生成AIを用いたコード、画像、3D、音声については、利用したサービス、プラン、利用規約、入力データ、出力後の人手修正、第三者権利の確認、顧客への説明を記録します。出力物の権利が一律に保証されるとは限らず、機密のCADや個人情報を外部サービスへ入力した問題も別にあります。生成AI使用を理由に即座に排除するのではなく、重要資産か、再制作可能か、学習・入力の根拠は何かを個別評価します。

16．品質・セキュリティ・アクセシビリティを数値で確かめる

VRの品質はスクリーンショットでは判断できません。DDでは対象端末、利用時間、空間、人数、回線を定義して試験します。フレームレートの平均だけでなく下位パーセンタイル、フレーム落ち、CPU・GPU時間、メモリピーク、温度、電池消費、起動・シーン遷移時間、クラッシュ・ANRを測ります。基準は製品用途と端末によって異なるため、数字だけで合否を断定せず、顧客の期待、メーカー推奨、既存SLAと比較します。

体験上の確認には、トラッキング喪失、境界外移動、座位・立位切替、左右の利き手、身長差、眼鏡、色覚、字幕、音量、コントローラー電池切れ、通信断、再ログイン、途中保存を含めます。酔いや不快感には個人差があるため、短い社内試験だけで安全を保証できません。利用時間、移動方式、加速度、カメラ揺れ、休憩案内、利用中止手順、インシデント記録を確認します。

セキュリティでは、Web／APIの一般的な試験に加え、端末の物理アクセス、デバッグビルド、ADB、ローカル保存、ディープリンク、ルームコード、音声チャンネル、アバター・UGC、管理者画面、イベント主催者権限を見ます。展示会端末に認証トークンが残る、共有HMDで前利用者の氏名が見える、ルームIDの推測で非公開会議へ入れる、ログに音声URLが残る、といったXR固有の利用場面をシナリオ化します。

マルチユーザー製品は、迷惑行為対策、ブロック、ミュート、通報、モデレーション、ログ、緊急退出、未成年者保護を確認します。機能があるだけでなく、通報を誰が何時間内に処理し、証拠をどの期間保存し、顧客と運営会社のどちらが判断するかを運用表にします。買収後に運営人数が変われば、モデレーション原価とリスクも変わります。

アクセシビリティは法的適合性だけでなく、市場の広さと顧客継続に関係します。字幕、文字サイズ、コントラスト、片手操作、座位利用、代替入力、音声以外の通知、VRを利用できない人向けの2D導線を確認します。自治体・教育・企業研修では参加者を限定しない設計が受注条件になることがあります。未対応を単なる機能不足ではなく、対象市場と改修工数に結びつけます。

17．チームと暗黙知のDD

XR開発は、エンジニア、テクニカルアーティスト、3Dデザイナー、UX、インフラ、現場運用が密接に連携します。組織図だけでなく、製品別RACI、レビュー者、障害対応者、顧客窓口、外注先を図にします。「Unity担当三名」でも、実際にリリース鍵を扱えるのが一名、シェーダーを直せるのが一名、顧客仕様を知るのが退職予定者なら、承継リスクは高いと言えます。

主要メンバーとの面談では、技術の優劣を試験するのではなく、日々の意思決定を聞きます。新しいSDKを採用する基準、障害の振り返り、顧客別変更の共通化、アセット購入の承認、セキュリティ更新、ドキュメント、若手育成を確認します。説明がコード・チケット・議事録と一致するかを見ることで、プロセスの実効性が分かります。

業務委託比率が高い場合、契約期間、単価、稼働、競業、引抜き、成果物権利、秘密保持、再委託、買収後の継続意向を確認します。委託先が重要リポジトリやクラウドを所有していると、単なる人員補充では解決しません。一方で地域の優秀な制作パートナーとの長期関係は強みになり得ます。個人関係だけでなく、会社間契約、複数窓口、引継ぎ資料で再現性を高めます。

リテンション施策は金銭だけではありません。買収目的、製品継続、役割、評価制度、開発文化、勤務地、リモート、顧客との関係を、開示可能な時期に丁寧に説明します。情報管理を守りながら、誰にいつ伝えるかを設計します。キーパーソンを囲い込むことが目的化すると他メンバーの離職を招くため、チーム単位の承継を重視します。

18．株式譲渡・事業譲渡・会社分割で技術DDの焦点はどう変わるか

株式譲渡では対象会社の法人格、資産、債務、雇用関係が原則として存続します。このためリポジトリや契約を物理的に移す作業は少なく見えますが、過去のライセンス違反、情報漏えい、権利不足なども会社内に残ります。チェンジ・オブ・コントロール通知、親会社変更に伴うプラン適格性、グループ利用範囲、買い手のセキュリティ基準への統合を重点確認します。

事業譲渡は承継対象を選べる一方、契約、知的財産、端末、アカウント、データ、従業員を個別に移す作業が増えます。Asset Store等のライセンスや開発者アカウントが譲渡可能か、顧客・外注先の同意、個人データの根拠、ドメイン・ストアアプリ移管、ソースから顧客秘密を分離できるかが重要です。移せない共通基盤は、ライセンス供与、複製、再開発、TSAのどれで支えるかを決めます。

会社分割その他の組織再編では法令上の承継効果が関係しますが、利用規約や技術運用まで自動で片付くとは限りません。どの手法が適するかは税務、法務、債権者、許認可、人事を含めた総合判断です。技術DD側は、対象資産・債務・担当者・契約の分離可能性を示し、手法選択に必要な事実を提供します。

カーブアウトでは、譲渡企業が属する企業グループの共通クラウド、ID基盤、素材ライブラリ、Git組織、ヘルプデスクをどこまで使っているかが重要です。クロージング後も一定期間使うなら、対象サービス、品質、費用、セキュリティ、終了条件をTSAへ明記します。TSA終了日から逆算して新環境構築、データ移行、再認証、顧客テストを計画します。

19．典型的な発見事項と現実的な是正案

ケースA：創業者個人アカウントに購入素材とアプリが集中

事実をサービス別に分け、正式な組織追加・移管手順、再購入、アプリ移管を確認します。パスワード一括引渡しではなく、会社メールとMFAへ変更し、二名管理にします。移管不可の素材は代替費用を見積もり、重要アプリはクロージング前の移管完了またはTSA・前提条件とします。

ケースB：最新版は退職予定者のPCにしかない

端末を保全し、会社の権限とプライバシーに配慮して対象プロジェクトを特定します。リポジトリへ戻し、リリース成果物との整合、秘密情報、顧客データを確認します。別担当者のクリーンビルドと引継ぎ面談を行い、必要に応じて限定的な移行契約を結びます。端末コピーだけで完了としません。

ケースC：外注3Dモデルの譲渡条項がない

利用している製品・広告・顧客を特定し、元委託先との追加契約を交渉します。必要範囲が全面譲渡でなく、買収後の改変・配布を含む永続許諾で足りることもあります。連絡不能なら、重要度に応じて再制作、差し替え、利用停止を選び、工数と公開影響を見積もります。

ケースD：顧客ごとの無償改修が利益を圧迫

チケットと工数を顧客別に集計し、契約上の保守範囲と差を示します。更新時にSLA・対象範囲・単価を再設計する、共通機能へまとめる、旧版サポートを終了する計画を作ります。買い手の共有基盤で効率化できるとしても、実現前から全額を相乗効果として評価しません。

ケースE：古い端末・SDKでしか動かない

現在の設置台数、故障率、予備機、メーカーサポート、顧客契約残存期間を調べます。短期は予備機確保、中期は新端末への移植PoC、長期は顧客更新を計画します。移植では入力、描画、性能、ストア審査、MDM、現地研修まで含む総費用を見ます。

ケースF：プライバシー表示にない視線ログを保存

取得を一時停止する必要性を評価し、項目、目的、識別性、保存先、提供先、利用実績を調査します。削除・通知・同意更新等は個別法務判断が必要です。コード修正だけで終えず、データ削除、顧客説明、再発防止レビュー、SDK設定の監視を行います。

20．クロージング後100日の技術PMI

Day 1で優先するのは、顧客体験を変えずに管理権を確保することです。緊急連絡網、オンコール、管理者、請求、鍵、ドメイン、クラウド、ストア、リポジトリの状態を確認し、移管証跡を残します。安全上必要な場合を除き、初日にエンジン版やアーキテクチャを一斉変更しません。変更凍結期間と緊急リリース手順を決めます。

30日までに、重大脆弱性、退職者権限、バックアップ、期限切れ、権利是正、サポート終了部品を処理します。顧客別の契約・採算・技術責任者を確定し、障害と要望の窓口を統合します。買い手基準との差をすべて即時是正するのではなく、サービス停止リスクと規制・契約を基に順序を付けます。

60日までに、開発・リリース標準、SBOM、アセット購入承認、外注契約テンプレート、データレビュー、端末運用を統一します。共通基盤化の候補を選び、小さな製品で移行を試します。過去のチームを否定する標準化ではなく、双方の良い方法を比較し、顧客価値と速度を落とさない設計にします。

100日までに、中期のエンジン更新、端末移行、クラウド最適化、製品統合、採用・育成、顧客更新を経営計画へ入れます。DDで置いた仮説と実績を比較し、相乗効果の進捗、想定外費用、解約、品質指標を取締役会等へ報告します。DD資料を保管庫で眠らせず、リスク台帳とロードマップへ移すことで初めて投資が回収されます。

21．データルームの作り方と証拠の粒度

技術資料は、買い手が迷わず事業単位で追える構造にします。最上位を「全社共通」「製品A」「製品B」「顧客案件」「端末・現場」に分け、各製品の中へ概要、アーキテクチャ、リポジトリ、ビルド、依存物、権利、契約、運用、セキュリティ、採算を置きます。同じ契約を複製せず、一意の文書IDとリンクで参照します。ファイル名に日付・版・署名状態を入れ、ドラフトと締結済みを混同しないようにします。

資料の基準日を明記することも重要です。ユーザー数、端末台数、脆弱性、アカウント管理者、クラウド費は日々変わります。「2026年7月末時点」のようにスナップショットを置き、DD中の重要変更は差分ログで知らせます。買い手側もダウンロードした古い表だけで判断せず、最終確認時に更新日と未解決事項を再確認します。

スクリーンショットは便利ですが、検索・再検証・完全性に弱い証拠です。管理画面の画面に加え、可能な範囲でCSVエクスポート、請求書、監査ログ、API出力を保存します。コード解析結果はツール名、版、対象コミット、設定、実行日時を残します。ビルド試験は端末、OS、エンジン、コマンド、結果、成果物ハッシュ、試験者を記録します。誰が再実行しても同じ範囲を検証できる粒度が目安です。

アクセス権は機密度で分けます。一般的な製品説明と匿名化KPI、顧客名・単価、ソースコード、個人データ、秘密鍵を同じ閲覧権にしません。秘密鍵や本番パスワードは原則データルームへ置かず、保有・移管手順と検証証跡を示します。顧客秘密を含むソースは、指定端末での閲覧、印刷・ダウンロード制限、クリーンチーム報告などを検討します。

質問回答にも証拠の型を使います。「問題ありません」ではなく、「契約C-014第8条、購入履歴A-022、対象ファイル一覧T-031により、製品Xでの利用を確認。事業譲渡時の承継可否は提供者へ照会中、回答期限は○日」と書きます。事実、譲渡企業の見解、未確認、是正を分けると、買い手は不確実性を正しく評価できます。

22．経営会議に伝わる技術DDレポートの書き方

経営会議は数百件の警告を読む場ではありません。冒頭に、投資仮説を支える事実、価値を毀損し得る事項、クロージング前に必要な判断、100日計画、想定費用を一ページで示します。各発見事項には、対象売上・顧客、発生条件、最悪影響、起こりやすさ、検出証拠、是正案、責任者を付けます。重大・高・中・低の定義を先に合意し、件数で企業を比較しません。

たとえば「Unity素材の購入証拠なし」を一律重大とせず、三つに分けます。営業デモの背景小物で再購入・差替えが一日なら低〜中、売上の半分を占める製品のコア環境で販売終了・権利者不明なら高、顧客が所有する素材で提供記録が見つかったならクローズ候補です。同じ見出しでも事業影響は大きく違います。

技術負債の費用見積りには幅を持たせます。必要人日だけでなく、テスト、ストア審査、顧客受入れ、端末交換、現地出張、停止リスクを含めます。社内人件費をゼロとせず、他の成長開発を遅らせる機会費用も示します。一方、買い手の既存基盤で削減できる費用は、統合前提と実現時期を明示し、最初から確定効果として差し引かないようにします。

不明事項は赤色に塗るだけでなく、解消に必要な行動を示します。「外注先へ追加契約案を送付、回答待ち」「Epicへカスタム契約適用範囲を照会」「顧客承認は基本合意後に取得」のように、次の判断可能日を置きます。DD期間内に答えが出ない場合、契約条件、保留金、補償、価格幅のどれで受けるかを提案します。

23．買い手が経営者・開発責任者へ聞くべき20の質問

1. 明日、現在のテックリードが不在でも本番修正を出せますか。実際に代行した人は誰ですか。
2. 売上上位三製品のリリース元コミットを今すぐ示せますか。
3. 過去一年でビルドが止まった最長期間と原因は何ですか。
4. 次のHMD・OS更新で動かなくなる可能性が高い機能は何ですか。
5. 最も置換が難しい外部SDK・プラグイン・素材は何ですか。
6. Asset Store／Fab等の購入承認と会社名義管理を誰が行いますか。
7. 外注先が権利を持つコア部分、外注先しかビルドできない部分はありますか。
8. 顧客へ譲渡した成果物と自社共通基盤をどのように分けていますか。
9. 現在認識する最大のセキュリティ・プライバシーリスクは何ですか。
10. 視線、音声、空間、動作データを何の目的でどこへ保存しますか。
11. 削除依頼を受けた利用者のデータを全システムから消す手順を実演できますか。
12. ストア、クラウド、ドメイン、署名鍵のうち個人名義のものは何ですか。
13. バックアップから最後に復元したのはいつで、何分かかりましたか。
14. 最も利益率の低い案件はどれで、技術・運用上の原因は何ですか。
15. 無償保守や口約束で続けている対応はどの顧客にありますか。
16. 端末の故障・紛失・OS更新で今年発生した顧客影響は何件ですか。
17. 自治体・施設案件で年度更新、再委託承認、権利条件に注意すべきものは何ですか。
18. 買収後三十日で変えてほしくない開発・顧客運用は何ですか。
19. 買い手の資本・販売網・技術を得たら最初に解消したい制約は何ですか。
20. DDでまだ質問されていないが、買い手が知るべきことは何ですか。

優れた回答は即答の流暢さではなく、事実と仮説を分け、証拠へつなぎ、分からない事項を調べる姿勢に現れます。買い手は面談を詰問にせず、譲渡企業が問題を率直に共有できる環境を作ります。隠れたリスクを早く発見することは、双方の取引成功に資するからです。

24．DDを企業価値向上へ変える運用習慣

M&Aの予定がなくても、月次で製品台帳、依存物、アカウント、端末、保守期限を更新すると、障害と退職への耐性が上がります。新しい素材・SDKは導入申請時に購入主体、ライセンス、用途、更新担当を登録し、プロジェクトパスと対応づけます。外注発注時には、既存知財と成果物、著作権、人格権、第三者素材、ソース・制作ファイルの納品を案件に合わせて定めます。

四半期ごとに代表製品のクリーンビルドと復元訓練を行い、担当者を交代します。年一回の形式的テストでは、エンジン更新や証明書切れに追いつけません。リリースのたびにコミット、エンジン、依存物、署名、成果物ハッシュ、変更点を記録すれば、DD時に過去を掘り起こす費用が減ります。

案件別採算には開発工数だけでなく、現地設営、端末初期化、問い合わせ、無償改修、クラウドピークを入れます。営業・開発・経理が同じ案件IDを使うと、売上と技術負債の関係が見えます。高売上でも保守負担が増える契約は早めに更新条件を見直せます。

最後に、問題の報告者を責めない文化が重要です。購入証拠の不足、鍵の個人管理、手順の欠損を早く共有し、小さいうちに直す仕組みが企業価値を守ります。DD直前だけ資料を美しく整えるより、日常の記録と再現が一貫している会社の方が、買い手にとって予測可能です。

25．VR M&A 技術DD 実務チェックリスト

製品・コード

1. 販売・保守・実証・休止を含む全製品と顧客別版が一覧化されているか。
2. 本番リリースとリポジトリのタグ・コミットを対応づけられるか。
3. Unity／Unrealの正確なバージョンと適用規約を特定できるか。
4. クリーン環境から第三者がビルドできるか。
5. 主要HMD・OSの実機で重要シナリオが通るか。
6. 顧客別フォークと共通基盤が分離されているか。
7. LFS／Perforceの大容量オブジェクトと履歴が揃うか。
8. バックアップを別管理者が復元した記録があるか。
9. エンジン改変、ネイティブプラグイン、独自ビルドを把握しているか。
10. サポート終了SDKと更新ロードマップが明確か。

ライセンス・知的財産

11. Asset Store／Fab等の導入物と購入履歴を突合したか。
12. 購入主体が会社で、必要な席・法人範囲を満たすか。
13. 非標準・Restricted・カスタムライセンスを分けたか。
14. 完成製品から購入素材を個別抽出できない設計か。
15. 外注成果物ごとに契約・発注・検収・納品をつなげたか。
16. 著作権法第27条・第28条に関する契約文言を確認したか。
17. 著作者人格権不行使、改変、氏名表示の条件を確認したか。
18. 人物・施設・文化財・ロゴ・音声・音楽の許諾があるか。
19. 顧客へ譲渡済みの成果物を他案件で再利用していないか。
20. 自社既存知財と顧客固有成果物の境界が明確か。

OSS・セキュリティ・データ

21. パッケージ管理外のバイナリを含め依存物一覧があるか。
22. OSSのライセンス表示・ソース提供等の義務を履行したか。
23. エンジン規約とOSSライセンスを同時に満たすか。
24. 既知脆弱性を到達可能性・顧客影響で評価したか。
25. 秘密鍵・APIキーがリポジトリ履歴に残っていないか。
26. 取得データの項目・目的・保存・移転を図示したか。
27. 視線・動作・音声・空間マップ・カメラを含めたか。
28. プライバシー表示と実装・通信が一致するか。
29. 削除請求、契約終了、端末紛失時の削除を実行できるか。
30. 事業譲渡・利用目的変更時の根拠を個別確認したか。

アカウント・端末・運用

31. 全ストア・クラウド・ドメイン・分析の所有者を把握したか。
32. 会社メール、MFA、回復手段、予備管理者があるか。
33. アプリ移管の正式手順と所要日数を確認したか。
34. 署名鍵・証明書の保管、更新、復旧手順があるか。
35. HMDの型式、シリアル、所有、保証、設置場所が揃うか。
36. MDM、キオスク、OS更新、遠隔配布を承継できるか。
37. 予備機・故障・清掃・安全の現場手順があるか。
38. 地域拠点の回線、物流、保守パートナーを把握したか。
39. 障害対応の連絡網、SLA、エスカレーションが機能するか。
40. 特定個人だけが行える作業を特定し、移管計画を作ったか。

採算・契約・PMI

41. PoC、本導入、展開、保守を分けた案件別損益があるか。
42. 無償対応、未完了、将来更新の工数を見積もったか。
43. チェンジ・オブ・コントロール、譲渡、再委託条項を確認したか。
44. 自治体等の年度予算、補助条件、入札資格を確認したか。
45. 重要顧客・重要取引先の同意要否と伝達時期を決めたか。
46. 再購入・再制作・同意取得の費用と期限を置いたか。
47. 発見事項を価格、補償、前提条件、PMIへ振り分けたか。
48. クロージング当日のアカウント・鍵・当番移管表があるか。
49. 30・60・90日の技術負債解消計画を担当付きで作ったか。
50. 買収後も顧客体験を止めない連絡・移行計画があるか。

26．VR M&A 技術DDのよくある質問

DDで「保証できること」と「保証できないこと」

技術DDは、限られた期間とアクセスの中で重要な事実を確かめ、意思決定の不確実性を下げる作業です。将来の障害、第三者からの請求、規約改定、OS・HMD更新、全てのサイバー攻撃をゼロにすると保証するものではありません。サンプル調査なら対象外に問題が残る可能性があり、ソース解析だけでは現場運用、面談だけでは実装を完全に把握できません。

そこで報告書には、調査基準日、対象製品・版、閲覧資料、実施試験、サンプル範囲、アクセス制限、譲渡企業の説明に依存した事項を明記します。「問題なし」ではなく「対象コミットの依存物を指定ツールと人手で確認した範囲では重大な未対応を検出しなかった」のように、結論の範囲を表します。未検証を低リスクと混同しません。

法的結論は弁護士、会計・税務は各専門家、脆弱性試験は許可された専門家が担当し、技術チームは構成と実際の利用を説明します。複数専門家の報告が矛盾する場合、製品・ファイル・契約の共通IDへ戻って解消します。買い手経営者は最終的に、残るリスクを価格・契約・PMI・保険等のどこで受けるか判断します。

譲渡企業側も、DDを買い手だけの検査と考えず、買い手の技術基盤、セキュリティ、統合体制、予算、担当者を確認します。自社製品を誰が運営し、約束した顧客・人材・資本が提供されるかを具体化することで、成約後の失望を減らせます。双方が不確実性を正確に共有することが、取引の速度と信頼につながります。

また、規約・製品仕様・法令は調査後にも変わります。クロージングまで数か月空く場合は、重大脆弱性、エンジン・SDK規約、ストア審査、重要顧客、管理者、証明書期限を最終確認します。表明保証の基準日と実際の運用がずれないよう、通常業務で生じた変更を差分開示します。

成約しなかった場合の情報処理も事前に定めます。買い手が得たソース、顧客秘密、個人情報、技術レポートの返却・削除、バックアップ、専門家保管、残存知識の扱いをNDA等に沿って実行します。機密性の高い技術を安心して検証できる枠組みは、譲渡企業と買い手双方の利益を守ります。

まとめ：企業価値は「動く成果物」ではなく「引き継げる仕組み」に宿る

VR M&A 技術DDで見るべきものは、派手なデモの完成度だけではありません。Unity・Unrealの適用条件、マーケット素材、外注著作権、OSS、リポジトリ、署名鍵、ストア、クラウド、データ、HMD運用、案件採算を、一つの事業としてつなげて評価します。権利証拠とクリーンビルドが対応し、別担当者が顧客対応まで再現できる会社は、買収後の不確実性が小さくなります。

一方、未整理事項があっても、対象と影響が見え、再購入・再制作・追加同意・契約条件・PMIへ落とせれば交渉の余地があります。大切なのは問題をゼロに見せることではなく、正確に開示し、止めずに引き継ぐ計画を示すことです。