自治体・観光・教育・製造のXR事業承継｜地域案件を引き継ぐ契約・端末・運用実務

2026年8月11日2026年10月23日

自治体・観光・教育・製造分野のXR事業は、アプリや3Dデータだけを渡しても承継できません。発注者との契約、年度予算、現地で築いた信頼関係、撮影許諾、UnityやUnreal Engine等の開発環境、クラウドとアプリストアのアカウント、ヘッドマウントディスプレイの保守、外注先のノウハウまでが一体となって、初めて継続可能な事業になります。本稿では「XR事業事業承継」を検討する経営者と実務担当者に向け、地域案件を止めずに引き継ぐための契約・端末・運用実務を体系的に解説します。

近畿経済産業局は、近畿地域の自治体・支援機関によるVR・AR・MR活用促進の取り組みを紹介し、観光、健康、中小企業の生産・設計支援などへの社会実装を挙げています。つまり地域XRは一つの業界ではなく、公共調達、観光コンテンツ、学校教育、製造現場といった異なる商慣行を横断する事業です。事業承継では、この違いを一括して「XR制作」と処理せず、案件ごとの継続条件を読み解く必要があります。

なお、本稿は公表資料と一般的なM&A・システム承継実務を基にした解説であり、個別案件の法務・税務・会計判断を代替するものではありません。契約条項、補助金の交付要綱、入札参加資格、エンジンやアセットの利用規約は案件と時点によって異なります。譲渡前には弁護士、公認会計士・税理士、社会保険労務士、情報セキュリティ担当者等へ確認してください。

記事内の比較・確認表
対象分野	収益・契約で見る点	技術・運用で見る点
自治体	年度予算、公募・入札、検収、再委託、補助金条件	成果物の権利、運用手順、庁内セキュリティ、担当者引継ぎ
観光	施設・DMOとの契約、繁閑差、周遊や来訪の効果測定	撮影許諾、多言語更新、現地回線、端末衛生、予備機
教育	教材更新、学校年度、研修・サポート範囲	児童生徒データ、教員操作、利用時間、安全配慮
製造	PoCから本導入への移行、工場横展開、保守責任	CAD・点群の機密、端末キッティング、オフライン動作、現場手順

1．XR事業事業承継とは「再現できる事業」を渡すこと

XR事業の承継対象は、目に見えるアプリ、映像、3Dモデルだけではありません。顧客課題を聞き出す営業方法、要件を体験設計へ翻訳する判断基準、撮影や計測の段取り、端末を現地で安定稼働させる手順、障害時の連絡網、更新を利益に変える契約構造までが事業です。買い手が翌日から同じ品質で提案、制作、納品、保守できる状態を「再現できる事業」と呼ぶと、承継範囲を考えやすくなります。

たとえば観光施設向けARガイドのリポジトリを買い手へ渡しても、文化財の画像利用許諾が譲渡企業にしか認められていなければ公開を継続できない可能性があります。工場研修VRの実行ファイルがあっても、元となるCADデータの利用目的が限定され、ソースコードを再ビルドするSDKが個人アカウントにひも付いていれば更新できません。学校向けメタバースを引き継いでも、児童生徒のアカウント発行、保護者への説明、教員向け研修、問い合わせ受付の方法が文書化されていなければ、授業日に運用が止まります。

したがって、XR事業の価値評価では「成果物一覧」と「運用能力一覧」を分けて作ります。成果物一覧にはソースコード、ビルド、3D・2D・音声素材、設計書、テスト記録を記載します。運用能力一覧には、誰が何を判断するか、現地設営に何時間かかるか、端末故障時に何台の予備機を出せるか、発注者の稟議時期はいつか、外注先の得意分野は何かを記載します。後者が欠けると、形式上は譲渡できても実務上の価値が大きく下がります。

事業資産を七つの層に分ける

実務では、承継対象を①顧客・契約、②知的財産・コンテンツ、③ソフトウェア・ビルド、④クラウド・アカウント、⑤端末・現地設備、⑥人材・外注ネットワーク、⑦地域との関係資本の七層に分けると漏れを発見しやすくなります。どの層にも「所有者」「利用者」「移転方法」「移転できない場合の代替策」「有効期限」「毎月または毎年の費用」を付けてください。

特に七層目の関係資本は、貸借対照表に現れにくい一方で地域案件の継続率を左右します。自治体担当者、DMO、観光協会、学校管理職、工場の安全衛生担当、地場の映像会社、機材運送会社、文化財管理者などとの信頼は、契約書を渡すだけでは承継されません。譲渡公表前後の説明順序、譲渡企業の経営者による同行、現地キーパーソンの紹介、問い合わせ窓口の並走期間をPMI計画へ入れる必要があります。

2．地域XR案件が通常のSaaS承継より複雑な理由

売上が年度と実証事業に左右される

自治体や公的機関の案件は、単年度予算、入札・公募、補助金の採択、議会や庁内手続の影響を受けます。前年に受注したから翌年も同額が自動更新されるとは限りません。事業計画では、継続契約を確定売上のように扱わず、予算化済み、仕様検討中、提案依頼前、採択待ち、随意契約の可能性あり、といった段階に分けます。「担当者との関係が良好」という定性的情報と「次年度予算が成立した」という客観的事実を混同しないことが重要です。

PoCの売上と本導入の売上も分けます。PoCは企画・開発費が中心で高い粗利に見えても、本導入では端末調達、現地設置、回線、利用者支援、保守が増えます。反対に初年度開発が赤字でも、複数年度の保守や横展開で回収するモデルもあります。案件別損益には、営業工数、無償のデモ制作、出張、撮影許可取得、端末キッティング、現地立会い、再撮影、クラウド転送量を含めてください。

検収と効果測定がプロダクト価値を左右する

地域案件では、納品物が動作するだけでなく、仕様書に定める成果、報告書、操作マニュアル、研修、利用ログ、アンケート集計までが検収条件になることがあります。実証事業で用いたKPIが「体験人数」だけなのか、「周遊促進」「理解度向上」「作業時間短縮」「事故リスク低減」まで含むのかで、必要なデータ設計が異なります。買い手は過去の検収記録と未解決事項を確認し、同じ測定を再現できるかを評価します。

効果の断定には注意が必要です。公表資料で「期待する」「めざす」と記載された効果を、実証済みの成果として記事や提案書へ書き換えてはいけません。譲渡資料でも、体験者数や継続率など実測値、発注者の評価、譲渡企業の推測を区別します。信頼できる買い手ほど、この区別が明確な資料を高く評価します。

地域の現場は通信・人員・設備条件が一定でない

都市部のオフィスで動くXR体験が、山間部の観光施設、歴史的建造物、学校の無線LAN、電波遮蔽の多い工場で同じように動くとは限りません。通信帯域、電源、照度、床面、周囲の騒音、利用者導線、衛生、スタッフ人数、搬入時間を案件ごとに記録します。クラウド接続が切れた場合のオフライン動作、コンテンツの事前配布、ログの後送、端末時刻の同期など、地域運用の設計が価値になります。

承継時には「現地カルテ」を作ると効果的です。施設図面、機材配置、ネットワーク測定、危険箇所、搬入口、保管庫、担当者連絡先、利用ピーク、清掃方法、過去の障害、復旧手順、次回訪問時の注意点を一案件一冊にまとめます。個人情報や機密情報を含むため、閲覧権限と譲渡時の取り扱いも定めます。

3．分野別に見るXR事業承継の実務

3-1．自治体案件：契約より前に「調達の資格」を見る

自治体案件では、契約の承継可能性だけでなく、買い手が次回の入札や公募へ参加できるかを確認します。地域、業種、格付け等の入札参加資格、同種業務の実績、配置技術者、共同企業体や協力会社の条件が仕様書や公募要領に定められる場合があります。譲渡企業の実績が買い手の実績として当然に扱われるとは限りません。会社分割、株式譲渡、事業譲渡のどの手法を選ぶかによっても説明の仕方が変わるため、発注者の運用と専門家の見解を確認します。

再委託にも注意が必要です。公共の業務委託仕様書では、主たる部分の再委託を禁じたり、その他の再委託について事前の書面承認を求めたりする例があります。XR会社が3D制作、撮影、サーバー運用、音声収録を外部へ依頼している場合、譲渡後の外注体制が既存承認の範囲に入るかを確認します。買い手が内製化する場合も、担当者や作業場所の変更通知が必要かを契約書で確認してください。

成果物の著作権条項は案件ごとに読みます。発注者へ権利を移転する条項、従前から保有する汎用部品を受託者に留保する条項、著作者人格権を行使しない条項、第三者権利を侵害しない保証などが組み合わされます。「代金を受領したから全て譲渡企業の資産」「発注者へ納品したから何も再利用できない」という一律判断は危険です。プロジェクトごとに、新規開発部分、既存フレームワーク、外部アセット、発注者提供素材を色分けした権利表を作成します。

さらに、変更契約、仕様変更の議事録、検収前の指摘、保証期間、瑕疵対応、情報セキュリティ要求、事故報告義務も承継します。契約上の地位を移転するには相手方の同意が必要となることが多いため、事業譲渡契約の締結だけで顧客契約が自動的に移ると考えないでください。発注者へいつ説明し、誰の決裁を得て、どの書式を使うかをクロージング条件にします。

3-2．観光案件：場所と物語の許諾を分けて管理する

観光XRでは、景観、文化財、伝統芸能、地域の人物、祭礼、店舗、交通など、現地の権利と協力がコンテンツの核になります。撮影した会社が映像ファイルを保有していても、撮影場所の利用条件、出演者の肖像・実演、音楽、台本、古写真、商標、キャラクター等の利用許諾が別に存在します。オンライン配信、アプリ内利用、広告利用、多言語化、二次編集、利用地域、期間、事業承継時の移転を許諾書で確認します。

歴史情報の正確性と更新責任も資産です。誰が監修し、どの資料を根拠にしたか、地域で異なる説をどう表現したか、修正依頼を誰が承認したかを残します。生成AIによる翻訳や音声を用いた場合は、原文、校閲者、固有名詞辞書、利用したサービス、生成物の権利条件を記録します。買い手がブランドだけを引き継ぎ、地域への説明を省くと、技術的には動いても地域から支持されないサービスになりかねません。

運用面では、繁忙期と閑散期、悪天候時の代替体験、端末の貸出・回収、充電、消毒、紛失、外国人旅行者への説明、眼鏡利用者への調整、車いす利用者の導線を確認します。屋外ARならGPS精度、日照、通信、端末発熱、OS更新により見え方が変わります。季節ごとの現地テスト記録と、施設スタッフが迷わない一枚物の対応表を引き継ぎます。

DMOや観光協会を介した案件では、契約相手と実際の運用主体が異なる場合があります。費用を負担する自治体、素材を提供する施設、接客する店舗、システムを管理する事業者、集客する旅行会社の役割を図示します。問い合わせ窓口や障害時の優先順位が曖昧だと、譲渡後に「誰も止める判断ができない」状態になります。

3-3．教育案件：授業日に安全に使えることが価値

学校向けXRでは、技術の新しさ以上に、限られた授業時間の中で準備でき、児童生徒が安全に利用し、教員が自力で復旧できることが重要です。端末台数、充電時間、同時接続、アカウント発行、コンテンツ配信、教室の机配置、装着補助、体調不良時の中止基準、衛生、授業後のデータ消去を標準手順へ落とします。特別支援、年齢、視力、酔いやすさ、聴覚・言語上の配慮も発注者と協議した記録を残します。

児童生徒の氏名、音声、映像、チャット、行動ログ、視線、身振り、端末識別子を扱う場合、取得目的、必要性、保存期間、アクセス権、第三者提供、委託先、削除方法を明確にします。視線や身体動作は体験改善に有用でも、収集すればよいわけではありません。目的に必要な最小限へ絞り、匿名化・仮名化の可否、教員が閲覧できる範囲、保護者や本人への説明を案件ごとに設計します。

教育コンテンツに既存の著作物を使う場合、「学校で使うから常に自由」とは限りません。文化庁が案内する授業目的公衆送信補償金制度は一定の授業利用を円滑化する制度ですが、対象となる教育機関、授業の過程、利用態様等には条件があります。XRアプリの一般公開、学校外イベント、有料販売、広告への転用まで当然に含まれるとは断定できません。権利者から個別許諾を得た範囲と制度に基づく利用を分けて管理します。

津山市教育委員会、万作の会、NTT西日本、NTTスマートコネクトによる公表事例では、教育委員会が企画・運営や学校調整、文化団体が学習コンテンツ提供と制作協力、通信事業者側がICT活用支援やシステム企画・開発を担う役割分担が示されています。この例からも、教育XRはシステム単体ではなく、教育内容、現場調整、文化的監修、授業実施支援の連携で成立すると分かります。承継では役割ごとの合意と連絡経路を再構築します。

3-4．製造案件：機密、安全、設備変更を一体で引き継ぐ

製造XRには、設計レビュー、作業訓練、保全支援、遠隔支援、ショールーム、デジタルツインなどがあります。CAD、設備図面、作業手順、事故情報、工場内写真は営業秘密や輸出管理、顧客機密に関わる可能性があります。譲渡企業のクラウドへ一括保存されている場合、誰のデータで、どの地域のデータセンターにあり、誰がダウンロードできるかを確認します。事業譲渡のデータルームへ入れる前にも顧客同意やマスキングが必要な場合があります。

現場安全の要件はソフトウェア仕様と同じくらい重要です。保護具とHMDの干渉、歩行型体験の範囲、設備稼働中の利用禁止、誘導員の人数、緊急停止、衛生、騒音下の音声指示、暗所や高温環境での端末性能を記録します。教育訓練用VRが実際の安全教育を置き換えるのか補完するのかも、顧客との合意に従います。効果を誇張せず、適用範囲と残るリスクを明示します。

設備は改修されるため、納品時の3Dモデルと現場がずれます。変更情報を誰が受け取り、どの版へ反映し、いつ再検証するかが保守契約の中心です。買い手はモデル更新の単価、元CADからの変換手順、ポリゴン削減、座標系、機密部分の除去、端末別の性能調整を確認します。モデルがあるだけでなく、更新可能なパイプラインがあることが価値になります。

工場ネットワークがインターネットから分離されている場合、ライセンス認証、アプリ配布、ログ回収、遠隔保守が通常と異なります。オフラインインストーラー、署名済みパッケージ、媒体持込みの申請、ウイルス検査、保守員の入場教育までが運用資産です。買い手の標準クラウドへ安易に統合せず、顧客のセキュリティ規程を基準に移行設計を行います。

4．PoC、本導入、多拠点展開、保守を別事業として分析する

地域XRの収益構造は四段階に分けると見通しがよくなります。第一段階はPoCで、課題仮説、体験設計、最小コンテンツ、評価方法を作ります。第二段階は本導入で、品質保証、マニュアル、端末、研修、アクセシビリティ、セキュリティを整えます。第三段階は多拠点展開で、テンプレート化、量産、現地パートナー育成、監視を行います。第四段階は保守・更新で、OSやSDKの追随、コンテンツ差し替え、端末交換、問い合わせを継続します。

売上台帳には各段階を明示し、案件コードを連結します。PoCから本導入へ進んだ割合、本導入までの平均期間、失注理由、横展開先、保守更新率を算出すると、買い手は営業パイプラインを現実的に評価できます。反対に、PoC件数だけを大きく見せても、単発で終了する理由が説明できなければ事業価値は伝わりません。

原価も段階別にします。企画者、エンジニア、3Dアーティスト、映像撮影、音声、現地ディレクター、運送、端末、クラウド、外注、保証引当の実績工数を案件へ配賦します。経営者が無償で担ってきた提案や現地調整は、買い手の体制では人件費になります。経営者工数をゼロ原価のまま将来利益へ延長しないことが、誠実な売却資料につながります。

補助金を活用した案件では、交付対象経費、財産処分制限、報告義務、収益納付、取得財産の管理など、制度と交付決定ごとの条件を確認します。譲渡や端末移転が「財産処分」に該当するかは個別判断です。採択された事実だけで自由に事業資産を移せると考えず、交付元への事前相談が必要かを専門家と確認してください。

5．契約の棚卸しは「相手・対象・期間・移転」で行う

顧客契約

顧客契約一覧には、契約名、相手方、契約期間、更新条件、対価、検収、保証、SLA、再委託、個人情報、知財、秘密保持、損害賠償、解除、反社会的勢力、準拠法、地位移転制限を記載します。注文書、基本契約、仕様書、提案書、質問回答、議事録、変更合意が一体で契約内容を構成する場合があるため、契約書だけを一覧にしないでください。

継続中案件では、未請求作業、前受金、検収待ち、保証対応、追加要望、赤字見込みを明示します。事業譲渡の基準日をまたぐ場合、どちらが作業し、売上と原価をどちらへ帰属させ、返金や損害対応を誰が負担するかを定めます。契約移管の同意が得られない案件については、譲渡企業が一定期間履行し買い手へ再委託する案も考えられますが、顧客契約の再委託制限や情報管理を確認した上で設計します。

外注・パートナー契約

XR制作ではフリーランスや小規模スタジオの専門性が重要です。発注書がなくチャットだけで進めた案件、成果物の権利帰属が明記されていない案件、著作者人格権への対応がない案件を洗い出します。譲渡企業が買い手へ成果物を譲渡できる権利を本当に取得しているか、再許諾や改変が可能かを確認します。過去に口頭合意で済ませてきた場合、譲渡直前に一方的な確認書を送らず、関係を損なわない説明と合意形成を行います。

協力会社の価値は単価表だけでは測れません。対応可能な地域、撮影機材、得意な3D表現、緊急対応、機密管理、代替人員、繁忙期、支払条件をまとめます。ただし、個人の評価や連絡先を買い手へ開示する際は個人情報と秘密保持に配慮します。最終契約前は匿名化し、必要性が高まった段階で範囲を限定して開示する方法があります。

賃貸借・保守・通信契約

HMD、PC、カメラ、ルーターがリースやレンタルの場合、所有権は譲渡企業にありません。契約の名義変更、残存期間、中途解約金、設置場所制限、保険、返却条件を確認します。端末を顧客へ貸し出している場合、現物の所在、シリアル番号、同梱品、損傷、顧客側の責任、回収時期を台帳と照合します。

SIM、固定回線、VPN、電話番号、ドメイン、証明書、クラウド契約には移転できないものがあります。買い手名義で新規契約し、一定期間並行稼働する計画を立てます。特に証明書、APIキー、署名鍵の更新はアプリの継続配布に影響します。秘密情報をメール添付で渡すのではなく、保管庫とアクセスログを用いて安全に引き継ぎます。

6．知的財産は「作った人」ではなく権利の連鎖で確認する

XR成果物は、プログラム、シナリオ、画面、3Dモデル、写真、360度映像、音楽、ナレーション、ロゴ、データベースなど複数の著作物を含みます。さらに、商標、意匠、特許、営業秘密、肖像・パブリシティ、施設利用条件が重なります。「当社が制作した」という説明だけでなく、従業員の職務著作、役員・創業者の個人制作、外注成果、顧客提供素材、市販アセット、オープンソースを区分します。

権利台帳では、資産ID、ファイル場所、作成者、作成日、契約根拠、権利者、利用可能範囲、改変可否、再許諾可否、表示義務、期間、地域、譲渡手続を記載します。著作権の譲渡条項では、日本の著作権法第27条・第28条に関する扱いが明示されているか、著作者人格権について合意があるかを専門家が確認します。条文の有無だけで結論を出さず、契約締結時の事情と対象成果物を照合します。

商号、サービス名、ロゴ、ドメイン、SNSアカウントが一体で利用されている場合、ブランド移行計画を作ります。地域の愛称や自治体ロゴは自由に譲渡できないことがあります。譲渡後も旧会社名がアプリ内、プライバシーポリシー、利用規約、ストア表示、サポートメール、動画クレジットに残るため、検索可能な文字列と画像を一覧化し、修正担当と期限を決めます。

オープンソースと購入アセット

Gitリポジトリから依存ライブラリ一覧、ライセンス、バージョン、改変有無、著作権表示を抽出します。GPL等のコピーレフト型ライセンスと独自コードの組み合わせは配布方法に影響する可能性があります。表面的なパッケージ名だけでなく、ビルドに含まれるネイティブライブラリ、サンプルコード、フォント、音声コーデックも対象です。脆弱性と保守終了の確認を兼ねたSBOMを作ると、承継後の更新計画に役立ちます。

Unity Asset Store、Fab等から購入したアセットは、ファイルを保有していることと、別法人が利用できることが同義ではありません。Unityのエディター利用権は公式条件上、非独占・譲渡不可として定められ、組織や認定ユーザーに関する条件があります。Unreal EngineのEULAにも非移転のライセンスや席、配布方法に関する条件があります。規約は更新され得るため、購入アカウント、ライセンス種別、対象法人、席数、プロジェクトでの利用形態を確認し、買い手が必要なライセンスを取得する前提で費用を見積もります。

7．データとプライバシーを承継する前に「本当に必要か」を問う

ユーザーアカウント、問い合わせ、決済、視聴履歴、位置情報、音声、映像、アバター、チャット、視線、姿勢、空間マッピングは、XR運用で生じ得るデータです。M&Aだから全データを当然に買い手へ渡せるとは限りません。取得時の利用目的、プライバシーポリシー、委託か第三者提供か、国外移転、保存期間、本人からの請求対応を確認します。事業承継に必要なデータと、古く不要なデータを分け、不要なものは適切に削除します。

個人情報保護委員会のメタバース関連報告書は、アバターを介した交流や各種データ利用に伴う課題を整理しています。実務では、現実の個人とアバターの結び付き、録音録画の周知、未成年者、行動・視線等からの推知、第三者が同じ空間へ持ち込む情報を検討します。法的評価は利用態様で異なるため、センシティブに見えるデータを一括して「匿名ログ」と呼ばず、再識別可能性とアクセス範囲を確認します。

データ移行は、抽出、暗号化、転送、受領確認、旧環境削除、バックアップ削除までを一つの手順にします。ハッシュ値や件数で完全性を検証し、誰がいつ実行したかを記録します。顧客ごとのデータ分離ができていない場合、買い手へ移せる対象だけを抽出する工数が大きくなるため、DD段階でサンプル移行を試します。

サービス終了や契約終了時の削除も承継義務です。REALIVE360の公表されたサービス終了案内では、終了日時、対象アプリ、専用サイトアカウントの削除が告知されました。この例は、プロダクトのライフサイクルにおいて、利用終了とデータ削除のコミュニケーションが運用の一部であることを示します。譲渡時も、旧運営会社から新会社への変更、利用規約・窓口の変更、選択肢を利用者へ分かりやすく伝えます。

8．ソースコードは「ビルドできる」ことを実演して渡す

リポジトリのコピーだけでは承継完了になりません。譲渡前にクリーンなPCまたは隔離したビルド環境で、READMEだけを頼りに環境構築し、同じ成果物を生成できるかを確認します。OS、Unity・Unrealの正確なバージョン、モジュール、SDK、JDK、NDK、Xcode、Visual Studio、パッケージ、環境変数、シークレット、サーバーAPI、ビルドオプションを固定します。

Git LFSの大容量データ、別ストレージの3D素材、外注先だけが保有する編集前データ、個人PC上のプロジェクトが欠けやすい点です。ブランチ戦略、リリースタグ、過去版、未マージ変更、既知の不具合、テスト端末を整理します。生成AIやクラウドビルドを用いる場合、入力データの扱い、出力の再現性、サービス停止時の代替も記録します。

アプリ署名鍵、iOSの証明書・プロビジョニング、Androidの署名、ストアの組織アカウントは重要です。秘密鍵を失うと更新配布に重大な影響が出る可能性があります。個人名義の開発者アカウントをそのまま共有せず、プラットフォームが用意する組織移管やアプリ移管の条件を最新の公式情報で確認します。アプリID、バンドルID、プッシュ通知、課金商品、審査履歴、プライバシー表示も一緒に移行します。

技術デューデリジェンスで行う再現テスト

買い手は、①新規開発者のアカウント作成、②リポジトリ取得、③依存関係復元、④開発ビルド、⑤署名付きリリースビルド、⑥テスト環境への配布、⑦主要操作の実機テスト、⑧ログ確認、⑨ロールバックを実演してもらいます。譲渡企業の本番秘密情報を無制限に開示せず、マスキングした環境や第三者専門家を利用して検証します。

評価結果は「動いた／動かない」だけでなく、手作業、所要時間、属人判断、ライセンス不足、脆弱性、更新期限を記録します。技術負債は譲渡価格を下げる材料だけではありません。必要投資が具体化されれば、買い手は統合予算を確保しやすく、譲渡企業も不確実性による過度な価格調整を避けられます。

9．HMD・カメラ・PCを「台数」ではなく稼働能力で評価する

端末台帳にはメーカー、モデル、シリアル、購入日、保証、所有者、設置場所、利用案件、OS・ファームウェア、管理アカウント、付属品、バッテリー状態、損傷、簿価を記載します。QuestやPICO等、同じ名称でも世代や容量が異なれば動作と部品が異なります。稼働機、予備機、修理中、廃棄予定を区別し、現物確認します。

多数端末の運用では、MDMや各ベンダーの法人向け管理機能、キオスク設定、Wi-Fi配布、アプリ配信、遠隔ロック、初期化、利用ログが重要です。管理契約の対象法人、端末数、更新日、費用、管理者権限を確認します。買い手のMDMへ移す際は、初期化が必要か、アプリデータが消えるか、現地訪問が必要かを少数台で検証します。

衛生・安全手順も承継対象です。フェイスクッション交換、清掃剤、レンズを傷めない方法、感染症流行時の間隔、装着補助、転倒防止、年齢・体調への案内、利用中止基準を施設ごとに確認します。メーカーの安全情報と顧客施設の規程を基にし、「VRは危険」「必ず安全」と一律に断定しない運用にします。

端末の寿命はプロダクトの寿命に直結します。OSサポート、ストア配布、部品、バッテリー、性能要件が変わるため、二年から三年程度の更新シナリオを複数用意します。ただし具体的な寿命はモデルと使用状況で異なります。移行先機種でのレンダリング性能、入力方式、視野、管理機能、利用者体験をテストし、端末更新費を事業計画へ含めます。

10．クラウドとアカウントは「管理者を増やす」前に構造を図示する

クラウド構成図には、本番・検証・開発環境、リージョン、ネットワーク、データベース、ストレージ、CDN、認証、監視、バックアップ、外部APIを記載します。月額費用だけでなく、イベント時の転送量、動画エンコード、ログ保持、予約インスタンス、割引契約、障害時の復旧目標を確認します。顧客別に分離されているかも重要です。

ルート管理者が創業者個人のメールや携帯電話に依存している場合、MFAを解除せず安全に組織管理へ移行します。共有パスワードを一覧表にして渡す方法は避け、パスワードマネージャーや権限委譲機能を使います。退職者のアカウント、長期未使用キー、公開リポジトリの秘密情報を検査し、クロージング直前と直後にアクセス権を再確認します。

ドメイン、DNS、メール、サポートチケット、分析、決済、動画配信、地図、音声合成、翻訳など、XRサービスは多くのSaaSに依存します。各サービスについて契約者、請求先、管理者、利用規約、データ所在、解約時のエクスポート、代替手段を一覧化します。無料枠や個人プランに支えられた原価は、法人承継後に増える可能性があります。

11．人とノウハウ：キーパーソンを拘束するのでなく、判断を共有する

XR事業は、顧客の曖昧な要望を体験へ変換できるプロデューサー、端末の癖を知るエンジニア、現地で事故なく進行するディレクターなど、少人数の判断へ依存しがちです。M&A準備では、その人を「残る前提」で価値評価するだけでなく、判断の入力、選択肢、基準、出力を文書化します。たとえば「酔いを減らす」は、移動方法、フレームレート、カメラ、利用時間、対象者、検証結果の組み合わせで説明します。

従業員の承継は、手法や雇用契約により必要手続が異なります。事業譲渡では個別の雇用承継同意が必要となるのが一般的です。早過ぎる発表は不安を生み、遅過ぎる説明は信頼を損ないます。誰へいつ、雇用条件、勤務地、評価、開発環境、案件継続をどう説明するかを計画し、質問へ一貫して答えます。秘密保持を理由に現場へ全く準備時間を与えない設計は、技術移行を危うくします。

引継ぎは録画だけで終えません。買い手担当者が実際に提案書を作り、ビルドし、端末を設定し、現地リハーサルを行い、譲渡企業がレビューする「逆向きの実演」を組み込みます。30日で観察、60日で共同実施、90日で買い手主導と段階を分け、未解決事項をチケット化します。

12．譲渡手法は「何を移し、何を残すか」から選ぶ

株式譲渡は法人自体が継続するため、契約や許認可、従業員が形式上は維持されやすい一方、過去の債務やリスクも法人内に残ります。ただしチェンジ・オブ・コントロール条項、補助金、入札資格、プラットフォーム規約などは別途確認が必要です。事業譲渡は対象資産・負債を選びやすい反面、契約、知財、従業員、アカウントを個別に移す実務が増えます。会社分割にも法定手続や契約上の論点があります。

どの手法が常に優れているわけではありません。公共案件の継続性を優先するのか、別事業のリスクを切り離すのか、顧客同意を何件得る必要があるか、税務、許認可、従業員、期間、秘密保持を比較します。「税率だけ」「契約が楽そう」だけで決めず、七層の資産が各手法でどう移るかを表にしてください。

譲渡企業が準備するデータルーム

第一に、案件別採算表です。顧客名を必要に応じ匿名化し、三期程度の売上、外注、クラウド、端末、旅費、担当工数、粗利、更新可能性を示します。第二に、契約・公募・検収資料です。第三に、権利台帳と素材一覧です。第四に、リポジトリ・ビルド・インフラ文書です。第五に、端末・アカウント台帳です。第六に、組織・外注・地域関係図です。第七に、事故、障害、クレーム、脆弱性と対応記録です。第八に、30日・60日・90日の移行計画案です。

資料には基準日、作成者、情報源、確定／見込み／未確認の区分を付けます。分からない事項を空欄のままにせず「未確認、確認先は○○、予定日は○月」と書くと、買い手はリスクを管理できます。譲渡企業に不利な情報を隠すと、最終契約の表明保証、補償、信頼関係に影響します。中小企業庁の中小M&Aガイドライン第3版も、最終契約の不履行や当事者間のトラブルを踏まえた対応を解説しています。

買い手のデューデリジェンス

ビジネスDDでは、顧客集中、年度依存、PoCから本導入への転換、競合、価格、地域展開を確認します。財務・税務DDでは、案件別原価、進行基準・検収、前受・未払、補助金、資産計上、端末在庫を確認します。法務DDでは、契約移転、知財、個人情報、労務、紛争を確認します。技術・セキュリティDDでは、ビルド再現、脆弱性、クラウド、データ、端末、障害対応を実演します。

質問票を送るだけでなく、案件の流れに沿ったウォークスルーを行います。ある観光AR案件を選び、受注、契約、素材許諾、制作、テスト、ストア公開、現地設置、検収、請求、保守まで証憑をたどります。別の教育案件と製造案件でも同じ確認を行うと、標準化されている部分と例外が見えます。

13．企業価値は売上高だけでなく「継続できる粗利」と移行費で考える

XR事業の評価では、過去売上をそのまま将来へ延ばさないことが大切です。単発PoC、端末販売、受託開発、保守、ライセンス、コンテンツ課金を分け、それぞれの継続確度と粗利を見ます。自治体案件は年度ごとの再調達リスク、観光は季節・来訪者、教育は導入校と研修、製造は設備更新と機密要件を織り込みます。

正常収益を作る際は、経営者の無償労働、相場より安い外注、個人アカウントの無料枠、先送りした端末更新、未実施のセキュリティ対策を調整します。一方、買い手の既存営業網、データセンター、サポート、コンテンツを組み合わせたシナジーは、誰が実現コストを負担するかを区別します。譲渡対象事業だけで生む価値と、買い手固有のシナジーを混ぜない方が交渉は明確になります。

譲渡価格以外にも、運転資金、未収金・前受金、端末在庫、移行費、TSA、アーンアウト、役員・従業員の継続、保証上限が経済条件を左右します。アーンアウトを用いる場合、公共予算や買い手の営業判断など譲渡側株主・経営者が制御できない要因をどう扱うか、売上・粗利の定義、費用配賦、情報閲覧権を具体化します。

14．クロージング前後180日の実務ロードマップ

譲渡準備：クロージングの180〜90日前

案件、契約、権利、技術、端末、アカウント、人の棚卸しを開始します。重要顧客とキーパーソンへの説明方針を決め、欠けた契約やビルド文書を補います。この段階で数字を美しく見せるために保守を削ったり、必要な更新を止めたりすると事業が傷みます。通常運営を維持しながら、再現可能性を高めます。

基本合意から最終契約：90〜30日前

DDで判明した課題を、クロージング前提条件、価格調整、補償、移行タスクへ分類します。顧客同意の取得順、従業員説明、外注先再契約、プラットフォーム申請、クラウド移行を工程表へ落とします。秘密保持と独占交渉の範囲を守り、発注者の調達公正性を損なう働きかけをしないことも重要です。

クロージング直前・当日

移転対象資産の最終リスト、契約同意、知財譲渡書類、端末現物、アカウント権限、データ移行、請求先、問い合わせ窓口を照合します。切替判定会議では、技術、顧客、法務、財務の責任者がGo／No-Go条件を確認します。サービス停止が許されない場合はロールバック条件と旧環境の維持期間を決めます。

最初の30日

顧客と現場の安心を優先し、大規模な統合を急ぎません。障害・問い合わせを共同で処理し、譲渡企業の暗黙知を記録します。買い手側のセキュリティ基準を適用しつつ、端末やアプリを一斉変更して授業や観光シーズンへ影響させないよう、案件カレンダーを見て移行します。

31〜90日

買い手主導で提案、ビルド、現地運用を実施します。案件別粗利、SLA、問い合わせ、障害、更新率を共通指標へ統合します。重複SaaSやクラウドを整理する場合は、権利、データ、性能を検証してから実施します。地域パートナーとの面談を終え、新しい責任者と連絡経路を定着させます。

91〜180日

PoCから本導入への転換、他地域への横展開、端末更新、共通基盤化を検討します。ここで初めてシナジー計画を本格実行します。譲渡企業のブランドを残すか統合するかも、検索流入、顧客認知、地域の信頼、商標、運用費を測って判断します。計画に合わない場合は、当初仮説を守るより修正する方が健全です。

15．譲渡企業側のセルフチェック30項目

案件別の売上、原価、工数、粗利を三期分説明できる。
PoC、本導入、多拠点、保守の売上を分けている。
次年度案件を予算化、提案、採択待ち等の段階で管理している。
契約、仕様書、変更合意、検収資料が案件単位でそろっている。
契約上の地位移転と再委託の制限を確認した。
補助金・交付金の条件と取得財産を確認した。
ソース、3D、映像、音声、文書の所在を把握している。
従業員、外注、顧客提供、市販素材の権利を区分した。
撮影、肖像、施設、文化財、音楽の許諾範囲が分かる。
商標、ドメイン、SNS、ストア表示の名義を把握した。
OSSと購入アセットの一覧がある。
Unity、Unreal、各SDKの版と利用条件を記録した。
クリーン環境でビルドを再現できる。
Git LFSや別ストレージの素材が欠けていない。
署名鍵と証明書を安全に管理している。
本番、検証、開発のクラウド構成図がある。
全SaaSの契約者、管理者、請求、解約方法が分かる。
ユーザーデータの目的、保存期間、削除方法を説明できる。
端末台帳と現物が一致する。
貸出、リース、顧客所有を区別している。
MDM、Wi-Fi、アプリ配布の手順がある。
現地設営、衛生、安全、障害の手順がある。
事故、クレーム、脆弱性を隠さず記録している。
キーパーソンの判断を文書化している。
重要な外注先・地域パートナーとの契約と関係が安定している。
顧客への説明順と同意取得を計画した。
従業員への説明と雇用承継を計画した。
30日・60日・90日の移行計画がある。
譲渡後も譲渡側に残る義務を把握した。
未確認事項を未確認と明示している。

16．買い手が見逃しやすい10のレッドフラッグ

第一は、売上の大半が一人の担当者との関係だけに依存することです。第二は、発注者の予算成立前なのに受注確定として扱うことです。第三は、成果物の編集前データを外注先しか持っていないことです。第四は、個人名義のクラウド・ストア・エンジンライセンスです。第五は、実機でビルドできる人が一人しかいないことです。

第六は、端末台帳と所在が合わないことです。第七は、補助金取得端末を通常在庫のように扱うことです。第八は、児童生徒や利用者のログを無期限に保管することです。第九は、顧客別の赤字を全社利益で隠すことです。第十は、「地域との信頼」を理由に契約・同意・手順の不備を軽視することです。レッドフラッグは直ちに取引中止を意味しません。影響、是正可能性、費用、期限を評価し、条件へ反映します。

17．四つの実務シナリオで考える承継

シナリオA：文化財ARガイド

譲渡企業は自治体から開発を受託し、地域の古写真、学芸員監修の解説、商店のクーポンをAR表示しています。承継では、自治体契約、古写真の許諾、解説の権利、店舗参加合意、地図API、アプリストア、現地マーカー、アクセス分析を分けます。買い手が全国展開したくても、素材許諾が当該地域・当該事業だけなら別地域へ転用できません。一方、汎用AR基盤を譲渡企業が保有し再利用できる契約なら、そのテンプレートが横展開価値になります。

シナリオB：観光施設のHMD体験

施設スタッフが十台のHMDを毎日運用し、譲渡企業は四半期ごとにコンテンツを更新しています。承継では、端末所有、保証、MDM、充電・衛生、予備機、施設内ネットワーク、スタッフ研修、映像権利、保守SLAを確認します。クロージングを繁忙期直前に設定すると、再登録や初期化が営業へ影響します。閑散期に少数台からMDMを移し、譲渡企業が一回の繁忙日を共同支援する計画が現実的です。

シナリオC：学校の協働メタバース

アバター、音声、チャットを使う授業サービスを複数校へ提供しています。承継では、教育委員会・学校の契約、保護者等への説明、児童生徒ID、ログ、NGワード、教員管理画面、授業支援員、ネットワーク制限、教材権利を確認します。買い手が一般向けメタバース基盤へ統合すると、学校が求めるアクセス制限やログ管理が変わる可能性があります。機能の多さでなく、教育目的と安全要件を満たすかで判断します。

シナリオD：工場訓練VR

顧客設備のCADを変換し、危険作業を訓練するVRを納品しています。承継では、CADの利用許諾、秘密保持、持出制限、編集データ、変換ツール、設備更新、訓練監修、安全上の免責、オフライン配布を確認します。顧客データを買い手の海外クラウドへ移せない場合、オンプレミスまたは国内環境を維持するコストを評価します。譲渡企業の汎用訓練エンジンと顧客固有データを論理・契約の両面で分離できれば、承継が進めやすくなります。

18．業界用語を事業承継の言葉へ翻訳する

PoCは概念実証であり、本番品質や継続採算が証明されたことを意味しません。デジタルツインは現実空間や設備をデジタルで表現・連携する幅広い概念で、リアルタイム性や精度は案件ごとに異なります。空間コンピューティングも製品・企業により用法が異なるため、提案書では具体機能を書きます。

6DoFは頭や端末の回転に加え位置移動を扱う方式、3DoFは主に回転を扱う方式を指します。承継では体験方式だけでなく、必要なプレイスペース、端末、制作工数へ翻訳します。スタンドアロンHMDは単体動作が可能でも、管理、配信、認証にネットワークや外部サービスを要する場合があります。

リポジトリはソースの保管場所ですが、LFS、外部アセット、秘密情報、ビルド環境が別なら単体で完全ではありません。CI/CDはビルド・テスト・配布の自動化で、設定と資格情報の承継が必要です。MDMは端末管理の仕組みで、契約と登録方式によって移行手順が異なります。

19．情報セキュリティを「買い手の標準へ寄せる」前に確認すること

XRサービスのセキュリティは、Web管理画面だけを脆弱性診断すれば終わりではありません。HMDやタブレット、撮影PC、現地ルーター、クラウドAPI、ストア配布、保守員の端末、外注先の編集環境まで攻撃面が広がります。資産台帳とデータフローを重ね、どの端末がどの情報へ到達できるか、認証が切れたときに何が見えるか、紛失時に遠隔消去できるかを確認します。管理画面の管理者だけMFAを設定し、共有端末の保守アカウントが初期パスワードのままなら、全体として十分とはいえません。

買い手の情報セキュリティ基準が譲渡企業より厳しい場合、統合は望ましい方向ですが、一斉適用が現場を止めることがあります。たとえば端末証明書を変更するとオフライン施設で再登録できない、送信先制限をかけると動画CDNへ到達できない、ログ保存期間を延長すると顧客との合意を超える、といった矛盾が生じます。基準差分を、直ちに是正、移行期間中の例外、システム刷新の三つに分け、例外には責任者と期限を付けます。

インシデント履歴では、漏えいが起きたかだけでなく、端末紛失、誤配信、権限設定ミス、クラウド費用の異常、撮影禁止区域の映り込み、児童生徒の不適切な発言、体験者の転倒などを含めます。原因、影響、顧客報告、再発防止、未完了措置を残します。ゼロ件という回答が、記録制度がないためなのか、実際に報告対象がなかったのかを区別することがDDの品質を高めます。

20．品質保証とアクセシビリティを承継条件に入れる

XRの品質は、画面解像度やフレームレートだけでは測れません。利用者が説明を理解できるか、酔いや疲労を訴えたときに中止できるか、字幕・音声・色・操作方法が対象者に合うか、施設スタッフが交代しても設営できるかを含みます。案件ごとに対象者、利用時間、姿勢、移動方式、入力、音量、明るさ、言語、介助をテスト項目へ落とします。テスト結果は端末モデルとアプリ版を付け、再現できる形にします。

障害の重大度も共通化します。授業開始時に一台だけ起動しない場合、観光施設の全台が更新待ちで止まる場合、工場訓練の表示が実設備と異なる場合では影響が違います。受付時間、初動、代替手段、現地派遣、復旧、報告書の基準を契約と運用手順で一致させます。譲渡企業が厚意で行ってきた夜間対応を、買い手が正式なSLAとして負うのかも明確にしてください。

アクセシビリティは「全ての人が必ず同じ体験をできる」と約束することではありません。対象者と利用環境を把握し、字幕、音量調整、座位モード、コントローラー代替、色だけに依存しない表示、付き添い用のミラー画面、非XRの代替教材などを合理的に設計します。既存案件で寄せられた要望と対応可否を引き継ぐことで、買い手は一から関係者へ聞き直さず改善を続けられます。

21．表明保証・補償でXR固有のリスクを言語化する

最終契約の表明保証では、一般的な権限、財務、税務、労務、紛争に加え、対象事業が使用するソフトウェアとコンテンツの権利、顧客契約、個人情報、OSS、外部サービス、端末所有、補助金、セキュリティ事故を検討します。「全て適法」「一切問題なし」という広過ぎる文言は、譲渡側（株式譲渡では売主）が合理的に確認できる範囲や開示資料との関係を巡る争いになり得ます。重要性、認識限定、期間、上限、免責額、個別補償を取引リスクに合わせて交渉します。

開示資料では、例外を具体的に記載します。たとえば「全知財を保有する」という保証に対し、市販アセット、顧客提供素材、OSS、外注著作物を別紙で示します。これは価値を下げるためではなく、買い手が必要ライセンスや同意を取得できるようにするためです。開示した事実がどの保証の例外になるか、単にデータルームへ置けば開示したことになるかは契約で定義します。

クロージング後に判明した不具合の負担も決めます。譲渡前の納品物に対する無償保証、譲渡後のOS更新による不具合、買い手の改変、第三者プラットフォームの仕様変更を区別します。原因が複合する場合の調査協力、費用負担、顧客への一次回答を定めておくと、責任の押し付け合いで復旧が遅れる事態を避けられます。

22．TSAと移行支援を「何時間でも対応」から卒業させる

移行期間の業務支援契約、すなわち移行サービス契約は、譲渡後に譲渡企業が一定期間、クラウド、請求、開発、顧客対応、端末保守等を支援する取り決めです。支援項目、期間、対応時間、担当者、料金、経費、優先順位、成果物、責任、終了条件を具体化します。「合理的な範囲で協力する」だけでは、譲渡企業の新事業と買い手の期待が衝突します。

サービスごとに終了基準を置きます。クラウド支援は買い手環境でバックアップ復元と監視確認ができた時点、ビルド支援は買い手担当者が署名付きリリースを生成した時点、顧客支援は主要顧客との三者面談と新窓口での問い合わせ完結を確認した時点、と定義できます。単に三か月経過で終了するより、成果と期限を組み合わせた方が双方の行動が明確になります。

創業者が譲渡後も顧問として残る場合、肩書きと意思決定権を明確にします。顧客が旧経営者へ直接依頼し続けると、新体制が育ちません。最初は同行し、次に買い手が主説明、最後は旧経営者が参加しない段階へ移します。地域の信頼を守りながら窓口を移すには、突然消えるのでも永久に残るのでもない設計が必要です。

23．ステークホルダーへの説明は「誰に先に言うか」が事業価値を左右する

説明対象は、従業員、主要顧客、自治体・教育委員会、協力会社、素材権利者、端末設置施設、金融機関、プラットフォーム事業者です。全員へ同時に同じ文章を送るのではなく、契約同意が必要か、運用に影響するか、情報漏えいリスク、地域での影響力を踏まえて順序を決めます。上場会社や公的機関が関わる場合、公表ルールや公平性にも配慮します。

説明内容には、なぜ承継するのか、サービスは継続するか、契約主体と請求先はどう変わるか、担当者・窓口、個人情報、端末、今後の日程を含めます。買い手の規模や実績を並べるだけでなく、現場で何が変わらず、何を改善するかを示します。不確定事項は予定と確認時期を伝え、安心させるために断定し過ぎないことが重要です。

地域では噂が正式発表より早く広がることがあります。説明用FAQ、問い合わせ記録、回答責任者を準備し、従業員や現場スタッフが異なる説明をしないようにします。批判的な質問を封じず、「地元から撤退するのか」「データは地域外へ出るのか」「保守料金は上がるのか」といった懸念へ事実で答えます。回答できない事項は持ち帰り期限を示します。

24．事業承継後のKPIは受注額と技術指標をつなぐ

承継直後のKPIは、売上だけでは遅行指標になります。顧客同意取得率、未移管契約数、買い手単独ビルド率、端末移管率、重大障害、問い合わせ初動、権利確認済み素材率、従業員・外注継続率を週次で確認します。数字が改善していても、現場の回避策で成り立っていないかをコメントで補います。

90日以降は、PoCから本導入への転換率、保守更新率、一案件当たり粗利、現地訪問回数、端末稼働率、クラウド原価、リリース頻度、復旧時間、顧客満足を追います。教育では授業実施率、観光では体験可能日、製造では訓練実施や更新所要時間など、顧客目的に沿った指標を選びます。ただし技術利用と社会的効果の因果を安易に断定せず、測定条件を残します。

買い手の既存事業とのシナジーは、共同提案件数、既存顧客へのクロスセル、本導入化、共通基盤による原価改善で測れます。「大手の顧客基盤があるから伸びる」という仮説を実績へ置き換えるには、誰がどの顧客へ何を提案し、何が障害だったかを記録します。伸びない場合はプロダクト、価格、営業対象、体制のどこを修正するかを議論します。

25．小規模XR会社が今日から整えられる標準資料

第一は案件台帳です。顧客、分野、段階、金額、粗利、契約、検収、次回予算、権利、端末、担当を一行で俯瞰します。第二は権利台帳、第三は端末台帳、第四はアカウント台帳、第五はリリース台帳です。最初から完璧なシステムを導入せず、更新責任者と月次確認日を決める方が継続します。

第六は現地カルテ、第七は障害台帳、第八はビルド手順、第九はデータフロー、第十は役割分担表です。資料をM&Aのためだけに作ると更新が止まります。新人教育、見積、保守、BCP、セキュリティに使える形へし、日常業務で差分を見つけます。承継しない場合でも、社内の属人化を減らし、休職・退職・災害への備えになります。

月一回、一件の案件を選び、契約からビルド、端末、請求まで資料をたどる「承継可能性レビュー」を行う方法があります。担当者以外が手順を説明できるか、権利根拠へ到達できるか、予備端末が動くかを確認します。見つかった欠落は担当と期限を決め、重要度の高いものから直します。小さな積み重ねが、交渉時に慌てて資料を作るコストを減らします。

26．案件ごとの承継難易度を点数ではなく五段階で仕分ける

多数の案件を短期間で整理するには、契約、権利、技術、端末、データ、人材の六軸を五段階で評価します。第一段階は資料がそろい買い手単独で運用可能、第二段階は軽微な同意や設定変更で移行可能、第三段階は顧客同意・再契約・再ビルド等の作業が必要、第四段階は権利不明や主要人物依存があり是正計画が必要、第五段階は現状のまま移転困難、というように定義します。数字を足して一つの総合点にするより、どの軸が弱いかを残す方が対策へつながります。

たとえば契約は第一段階でも、購入アセットの法人移行が未確認なら権利は第三段階、個人署名鍵しかないなら技術は第四段階となります。平均点にすると重大リスクが埋もれるため、一つでも第四・第五段階があれば経営会議で扱います。是正できない場合は、対象案件を譲渡範囲から除く、価格へ反映する、譲渡企業が契約終了まで履行する、代替コンテンツへ置換する選択肢を検討します。

仕分けには「根拠」と「次の行動」を必ず添えます。「権利2」とだけ書かず、「外注契約で再許諾可、購入フォントのみ買い手が再購入、担当○○、期限○月」と記載します。週次で更新履歴を残すと、DD質問への回答と移行工程が同じ資料になり、譲渡企業・買い手・専門家の認識差を減らせます。

27．価格交渉で守るべきは金額だけでなく実行可能性

譲渡企業は高い希望価格、買い手はリスクを反映した価格を提示しますが、議論を倍率だけにするとXR事業の実態が抜けます。案件別の正常粗利、受注確度、更新投資、端末更新、顧客同意、キーパーソン継続、移行費を共通モデルに置き、前提が変わった場合の感応度を示します。公共案件一件の失注を全売上消失と扱うのも、全件継続と扱うのも極端です。過去の継続率と次年度手続の進捗を分けます。

不確実性への対応は値引きだけではありません。顧客同意をクロージング条件にする、一定額をエスクロー等で留保する、移行完了で追加支払する、売上や粗利に連動するアーンアウトを設定する、TSA費用を明示する方法があります。どの方式にも税務・会計・法務の論点があるため、専門家と設計します。アーンアウトは譲渡側株主・経営者が影響できない買い手の営業方針、原価配賦、サービス統合で結果が変わらないよう定義を詰めます。

譲渡企業の経営者の残留条件も経済条件です。勤務日数、業務、権限、競業避止、知財、成果評価、退任条件を曖昧にしたまま「一年残る」と約束すると、期待がずれます。地域顧客の引継ぎに必要な期間と、買い手組織が自走する目標を置き、残留報酬と譲渡対価を区別します。従業員の処遇を価格交渉の後回しにすると、承継能力そのものが失われる可能性があります。

28．BCPとサービス終了計画も事業価値の一部

継続を前提とするM&Aでも、災害、プラットフォーム停止、主要端末の販売終了、顧客予算の縮小、権利更新不可に備えます。BCPでは、責任者不在、クラウドリージョン障害、現地回線断、端末一斉故障、アプリストア停止、外注先離脱のシナリオを作り、代替手順と復旧優先順位を決めます。地域の避難所や医療・教育に関わる場合、娯楽サービスと同じ復旧優先度ではない可能性があります。

復旧目標時間と復旧時点は、実際にバックアップから戻せるかを訓練します。3D・動画データは容量が大きく、バックアップがあっても復元に日数を要することがあります。ソースとデータベースだけでなく、アセット、署名、設定、端末アプリを含めた復元テストを行います。現地で代替端末へ入れるオフラインパッケージと、利用者へ停止を案内する連絡網も確認します。

サービス終了計画は失敗を前提にするものではなく、顧客と利用者への責任を明確にするものです。通知期限、契約精算、コンテンツのエクスポート、アプリ公開停止、アカウント・ログ削除、端末回収、ドメイン・証明書、問い合わせ保持、権利者への報告を定めます。終了後も保存が必要な会計・契約記録と、削除すべき利用者データを分けます。買い手が撤退判断をする場合も、この計画があれば地域への影響を抑えられます。

29．地域価値と事業価値を両立させる提案設計

地域XRは、受託金額だけでなく、文化継承、教育機会、観光周遊、安全教育、技能伝承といった目的を持ちます。ただし社会的意義を語るだけで採算が自動的に成立するわけではありません。誰の課題をどの機能で解決し、導入・運用にいくらかかり、誰が費用を負担し、どの指標で継続を判断するかを一枚にまとめます。譲渡企業が培ったこの翻訳能力は、買い手へ伝えるべき重要な無形資産です。

横展開では、共通八割・地域固有二割というように最初から固定せず、共通化できる基盤と、地域が保持すべき物語・素材・運用を見極めます。共通化し過ぎれば地域らしさを失い、個別対応し過ぎれば採算が崩れます。テンプレート部分の権利を誰が持ち、地域固有部分を他地域へ使わないことをどう保証するか、契約とリポジトリ構成を一致させます。

買い手が全国営業網を持つ場合でも、地域の意思決定を中央だけで完結させない仕組みが有効です。現地パートナー会議、コンテンツ監修窓口、年次レビュー、利用者フィードバックを残し、価格・品質・安全の最終責任は買い手が明確に負います。地域配慮を曖昧な善意にせず、役割、予算、会議、記録として運用へ埋め込むことで、成長と信頼を両立しやすくなります。

30．経営者が最初の一週間で行うアクション

初日は、売却を広く告知せず、社内で情報を扱う最小チームと専門家窓口を決めます。二日目は、全案件を売上順ではなく、継続中、保証中、提案中、休止、終了に分けます。三日目は、顧客契約、外注契約、許諾、補助金資料が保存された場所を一覧にします。四日目は、リポジトリ、クラウド、署名、ストア、端末の管理者を確認します。五日目は、属人化が最も強い案件一件でウォークスルーを行います。

六日目は、見つかった課題を「顧客や利用者へ直ちに影響」「譲渡前に是正」「価格・契約で対応」「譲渡後に改善」へ分けます。七日目は、経営者が売却理由、残したい価値、譲れない条件、希望時期、代替案を一ページに言語化します。この一週間で会社を売れる状態にはなりませんが、何が分からないかが見え、準備の順序を決められます。

候補先へ連絡する前に、社名を伏せた概要資料、秘密保持後に開示する資料、独占交渉後に開示する高度機密を区分します。顧客名、児童生徒データ、工場図面、ソースを初回説明で渡さないよう開示ルールを作ります。一方で抽象的な「独自技術」「強い関係」だけでは評価できないため、匿名化した案件構成、再現テスト結果、権利整理率など検証可能な情報を用意します。

31．機密性の高いXR資料を安全に開示する

XR会社のデータルームには、自治体の未公表施策、文化財の高精細データ、児童生徒の情報、工場図面、未発売製品、ソース、署名鍵などが入り得ます。候補先へ最初から全てを渡さず、匿名概要、秘密保持後の詳細、基本合意後の高度機密、クロージング時の秘密情報へ段階化します。各資料に所有者、機密区分、閲覧者、ダウンロード可否、開示根拠を付けます。

競合する買い手候補へは、顧客名、単価、設計、ソースの開示が取引不成立時に事業へ影響する可能性があります。外部専門家やクリーンチームに限定し、買い手の営業部門へは集計結果だけを返す方法を検討します。工場・学校等のデータは、顧客契約でDD目的の開示が許されるかを確認し、必要なら同意、マスキング、現地閲覧を使います。

署名鍵、クラウドルート資格情報、個人データの実物は、初期DDに通常必要ありません。構成図、アクセス管理、第三者による検証、隔離環境での実演で状態を確認できます。取引不成立時の返却・削除、バックアップ、専門家保有資料まで秘密保持契約へ入れ、削除証明を取得します。

32．切替リハーサルは「一件の案件」を最初から最後まで通す

クロージング前に、代表的な案件一件を選び、買い手側が新しい体制で運用するリハーサルを行います。自治体案件なら仕様照会、見積、再委託申請、制作、検収、請求、保守まで、観光なら撮影許諾、端末設置、繁忙日の問い合わせまで、教育なら授業準備、アカウント発行、授業後削除までを通します。顧客情報は必要に応じ匿名化します。

技術では、リポジトリ取得、ビルド、署名、端末配信、クラウド監視、障害復旧を実施します。運用では、誰へ連絡し、どの書式を使い、何時間で判断するかを確認します。財務では、注文・検収・請求・前受・外注支払を通します。三つを別々に成功させるだけでなく、同じ案件IDで資料がつながることを確認します。

見つかった欠落は、クロージング前に直すもの、TSAで補うもの、買い手が取得後に改善するもの、対象から除くものへ分類します。全てを完璧にしてから取引するのではなく、利用者や顧客へ重大な影響を与える条件を優先します。リハーサルの合格基準と未完了項目を両社の責任者が承認します。

33．地域の信頼を承継後一年で定着させる

クロージング後三か月で運用が安定しても、地域の信頼が新会社へ移ったとは限りません。半年・一年の節目に、自治体、DMO、観光協会、学校、工場、文化・撮影関係者、外注先とレビューを行います。契約の履行だけでなく、問い合わせの分かりやすさ、現地担当者の裁量、改善提案、次年度計画を確認します。

買い手が全国標準へ統合した結果、地域スタッフが判断できなくなっていないかを見ます。緊急時の中央承認が遅い、方言や固有名詞の修正に時間がかかる、端末を遠方倉庫へ送らなければならない等の問題は、顧客満足と粗利の両方へ影響します。一定の現地在庫、権限、パートナー契約を残す方が合理的な場合があります。

一年後には、譲渡企業の経営者の同行がなくても関係が続く状態を目標にします。新責任者が地域の目的と過去の判断を説明でき、問題時に誠実に報告し、次の提案を共同で作れることが承継の成果です。関係資本を「経営者個人の人脈」のままにせず、組織の会議、記録、約束、日常対応へ変換します。

34．共通基盤と顧客固有部分を切り分ける設計

地域XR会社では、一つのプロジェクトを複製して次案件を作るうちに、汎用機能と顧客固有データが同じリポジトリへ混ざりがちです。認証、画面遷移、コンテンツ配信、端末管理等は共通基盤にできても、自治体の素材、学校の教材、工場の設備モデルは契約と機密性が異なります。承継準備では、プログラム、設定、素材、データを機能単位で分け、どの案件から生まれ、誰が権利を持つかを記録します。

分離はフォルダーを分けるだけでは足りません。共通基盤を更新したとき各案件へどう反映するか、顧客固有の改修が基盤へ戻るか、テストをどこまで共通化するかを決めます。買い手が一案件だけを取得する場合、他顧客のコードやデータが混入しないパッケージを生成できることが必要です。譲渡企業が基盤を残して買い手へ利用許諾する場合は、期間、改変、再配布、保守、競合利用、終了時の扱いを契約へ落とします。

データベースも顧客識別子だけで分かれている状態と、契約・暗号鍵・バックアップまで環境分離されている状態では移行難易度が違います。抽出時に他顧客のログや個人情報が混ざらないかをテストし、件数と項目を顧客へ説明できるようにします。映像・点群・三次元モデルは大容量なので、移転時間、転送費、削除確認まで含めたサンプル移行を行います。

共通化率を高く見せることが常に価値ではありません。地域固有の監修や安全要件を無理に標準化すれば、顧客価値と契約適合性を失います。買い手は、共通化により品質と粗利が上がる部分、顧客ごとに維持すべき部分、将来廃止する重複部分を分けます。譲渡企業は、どこまでが再利用可能という事実で、どこからが買い手の開発仮説かを明確にします。

35．技術と端末の終了期限を一枚のロードマップにする

XRサービスは、アプリ本体が変わらなくても、モバイルOS、HMDのファームウェア、ゲームエンジン、SDK、クラウド、認証、アプリストアの変更で更新を迫られます。各依存先について、現在版、利用開始日、保守期限、次回更新、代替候補、検証端末、担当者を一覧化します。公式に保守期限が示されない場合は「未公表」とし、自社が想定する更新時期と混同しません。

ロードマップには顧客の予定を重ねます。観光繁忙期、年度末の自治体検収、学校の長期休暇、工場停止日に合わせ、更新・移行の試験時期を決めます。技術部門にとって最短の切替日でも、地域の現場には最悪の時期となることがあります。重大なセキュリティ修正を除き、利用ピークを避け、旧版へ戻せる期間を確保します。

端末の販売終了とサービス終了は同じではありません。予備機、修理、交換部品、後継機で一定期間を延ばせる場合もあれば、ストアやSDKの対応が止まり継続できない場合もあります。買い手は、既存端末を最後まで使う費用、後継機へ移す費用、非XRの代替体験へ変える費用を比較します。安全やセキュリティを犠牲にして延命しない判断基準も必要です。

譲渡価格の交渉では、次の一年に必要な更新だけでなく、三年程度の複数シナリオを示します。ただし将来の製品発売や規約変更を確実な事実として扱いません。確認済みの期限、メーカー等の公表予定、自社の想定、予備費を区別します。依存関係の終了期限が見えると、買い手は取得後の投資を予算化でき、譲渡企業も漠然とした技術不安による過度な値引きを避けやすくなります。

36．XR事業事業承継でよくある質問

Q1．売上規模が小さいXR事業でも事業承継を検討できますか。

検討できます。規模だけでなく、継続顧客、特定分野の知見、汎用基盤、権利処理済みコンテンツ、地域ネットワーク、専門人材が価値になる場合があります。ただしPoCだけで継続収益がない場合は、将来性を断定せず、何を買い手が再利用できるか、追加投資はいくらかを具体化してください。

Q2．自治体との契約は買い手へそのまま移せますか。

契約条項と譲渡手法、発注者の手続によります。事業譲渡では契約上の地位移転について相手方同意が必要となることが一般的で、入札資格や補助金条件も別に確認します。株式譲渡でも支配権変更の通知・同意条項があり得ます。早い段階で契約一覧を作り、説明時期を専門家と設計します。

Q3．UnityやUnreal Engineで作ったプロジェクトはファイルごと売れますか。

自社が権利を持つプロジェクト成果を譲渡できても、エンジン、購入アセット、プラグインのライセンスが別法人へ自動移転するとは限りません。公式規約は非移転、組織、ユーザー、席、配布等の条件を定めています。買い手が必要な契約を取得し、使用した全アセットを照合することが安全です。

Q4．HMDは帳簿の固定資産台帳だけ見れば十分ですか。

十分ではありません。顧客貸出、リース、予備、故障、付属品、管理アカウント、保証、OS、バッテリー、保管場所まで現物と照合します。端末があってもMDMから解除できない、アプリを再配布できない場合は稼働能力が下がります。

Q5．地域の撮影許諾は会社を売れば引き継がれますか。

許諾書の相手、目的、期間、媒体、地域、第三者利用、譲渡条項によります。口頭承諾は範囲を立証しにくいため、撮影場所、出演者、音楽、文化財、古写真などを分けて確認します。必要なら権利者へ事情を説明して再許諾を得ます。

Q6．個人情報を買い手へ渡すとき、何から始めますか。

まずデータ項目、取得目的、根拠となる表示・同意、保存先、委託先、保持期間を棚卸しします。承継に不要なデータは除外し、移転の法的整理、利用者への案内、暗号化、完全性確認、旧環境削除を計画します。未成年者、音声・映像・視線・行動等を含む場合は特に慎重に確認します。

Q7．買い手候補にソースコードを全部見せる必要がありますか。

初期段階で無制限に開示する必要は通常ありません。機密性に応じ、構成図、依存一覧、サンプル、第三者専門家のレビュー、隔離環境でのビルド実演へ段階化できます。最終判断に必要な検証可能性と、譲渡企業の営業秘密保護を両立させます。

Q8．承継準備にはどのくらいかかりますか。

案件数、契約、権利、技術負債、顧客同意により大きく異なります。最短期間を断定することはできません。まず二週間程度で七層の資産一覧と重大な欠落を把握し、その後、契約補完、ビルド再現、端末照合、移行計画を優先順位順に進める方法があります。譲渡意思が固まる前から日常管理を整えるほど、選択肢が増えます。

37．まとめ：地域XRの価値は、地域で再び動かせることにある

XR事業事業承継で売るのは、派手なデモ画面だけではありません。年度予算と調達を理解した営業、地域の権利者との合意、授業や観光現場の安全な運用、製造機密を守る設計、再現できるビルド、管理された端末、障害から復旧する人と手順を含む「継続可能な仕組み」です。

譲渡企業は、不確実なことを無理に確定へ見せず、確認済み・見込み・未確認を分けてください。買い手は、書類の有無だけでなく、受注から保守まで一件の案件を実演してもらってください。双方が地域の発注者、利用者、従業員、協力会社への影響を見ながら進めることで、M&Aは技術や顧客を途切れさせず次の成長へつなぐ手段になります。

承継の準備度は、資料のページ数ではなく、買い手側の担当者が根拠へ到達し、同じ判断と作業を再現できるかで測ります。案件台帳から契約、権利、ビルド、端末、現地カルテ、請求までを一つの案件IDでたどれる状態を作り、毎月更新してください。日常運営そのものが整えば、売却以外に共同事業、資本提携、社内承継を選ぶ場合にも役立ちます。

そして、地域の利用者にとって大切なのは運営会社の名称より、約束した体験や支援が翌年度も続くことです。譲渡契約の条件を地域現場の言葉へ翻訳し、誰がいつ何を引き継いだかを確かめられる状態まで作って、承継完了としてください。小さな運用変更も記録し、次の担当者が同じ品質で説明できるようにします。

準備を始める際は、最も売上の大きい案件だけでなく、最も古い端末、最も複雑な権利、最も属人化した現場を一件ずつ選んでください。難しい例を先に通すと、共通台帳や移行手順に必要な項目が見えます。確認結果を経営、技術、営業、現地運用で共有し、未解決事項に責任者と期限を置くことが、地域へ迷惑をかけない承継の第一歩です。

参考資料・公式リンク

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！

この記事を書いた人

VR M&A総合センター編集部