空間データM&Aのデューデリジェンス｜ARアンカー・施設マップを承継する実務

結論：空間体験を五つのゲートで評価する

空間コンピューティング事業の資産は、単一のファイルとして引き渡されるとは限らない。端末には環境を再認識する情報があり、基盤サービス側にはアンカーを解決する仕組みがあり、自社DBにはアンカーIDと設備名の対応があり、顧客側には設置場所と業務手順があり、契約書には撮影・保存・利用の範囲が書かれている。どれか一つを欠くと、残りがそろっていても現場体験を再現できない。

五つのゲート

第一は存在のゲートで、対象データが完全な台帳とともに実在するかを確かめる。第二は権限のゲートで、譲渡企業が買い手へ承継し、買い手が同じ目的で利用できるかを契約と法令から調べる。第三は支配のゲートで、組織、プロジェクト、サービス用アカウント、署名鍵、課金、配信ストア資格を移せるかを見る。第四は再現のゲートで、買い手環境と代表端末を使い、同じ場所でアンカーが解決するかを実測する。第五は商流のゲートで、顧客が契約を継続し、必要な通知や同意を受け入れるかを確認する。

通過できないサイトは価値と費用を分ける

全サイトを一律にゼロ評価する必要はない。契約の追加同意で直せるサイト、現地再スキャンで直せるサイト、鍵やクラウドのプロジェクトの移管で直せるサイト、顧客が情報持出しを認めず承継できないサイトを区別する。価値評価では通過確率を掛け、是正できるものは費用と所要期間を控除し、直せないものは将来粗利から除外する。DD報告書にも「違反」「不備」「承継不能」「要同意」「要再取得」「要実機検証」を別の列で残す。

一般的な企業価値評価との役割分担

顧客集中、売上倍率、利益調整等の周辺テーマはVR業界のM&Aコラム一覧で確認できる。本稿で行うのは、サイト別売上のうち、空間レイヤーを本当に承継できる比率を算出することだ。アプリ開発力やブランドが高くても、買収後に再撮影・再配置が必要なら、その費用と停止期間を別途織り込む。

なぜアプリが動いても事業承継に失敗するのか

一般的なソフトウェアDDでは、リポジトリ、ビルド、依存関係、テスト、クラウド構成を確認する。それらは必要だが、空間サービスでは十分ではない。検証環境で画面が表示されても、顧客施設に戻ったときに目標位置を識別できなければ、案内矢印、設備マニュアル、訓練コンテンツは正しい場所に現れない。収益を支えるのはコードの実行だけでなく、コードと現実の場所を結ぶ対応関係である。

改装と環境変化が資産を劣化させる

棚の入替え、設備交換、壁面塗装、照明、季節装飾、工事養生、人の混雑は、視覚特徴や位置合わせへ影響する可能性がある。買い手は「登録済みアンカー数」を価値指標にせず、最終検証日、現場変更、端末・OS・SDK版、照度条件、再解決実績を一緒に読む。古いアンカーがDBに残り続けていても、顧客が現在使えなければ収益資産とは呼びにくい。

業務上の意味が別DBにある

基盤サービスが保持する識別子と姿勢だけでは、それが「第3製造ラインの非常停止ボタン」なのか「展示室Bの作品解説」なのか分からないことがある。意味情報、顧客ID、表示内容バージョン、言語、表示条件、期限、権限は自社DB又は顧客テナントへ置かれる。買収対象に片方しか含まれないと、技術的にはアンカーを解決できても業務用途を復元できない。DDでは照合に使う共通の識別子と参照整合性を実データで確かめる。

社内デモと顧客本番を分ける

譲渡企業のオフィスで行うデモは、開発者の端末、既存ログイン、既知の位置、安定したネットワークを使うため成功しやすい。買い手が知りたいのは、別の管理者、別の端末、権限を限定した本番アカウント、通常の現場条件でも再現できるかである。デモ成功を証拠とせず、観察者、手順、入力、結果、失敗理由、再試行を記録した再現試験へ置き換える。

空間データ資産を七層に分ける

「空間マップ」という一語は広すぎる。契約、プライバシー、保存、移管、評価の結論を出すには、最低でも七層へ分解する。データ辞書には名称だけでなく、形式、生成主体、場所、目的、識別可能性、契約根拠、保持期間、書き出し手段を記載する。譲渡企業が独自名称を使う場合も、七層のどこに対応するかを明らかにする。

入力・幾何・意味の三層

入力層にはカメラのカラー映像、奥行き、位置、慣性、時刻等がある。幾何層には特徴点、平面、周辺空間のメッシュ、部屋の境界、三次元特徴マップ等がある。意味層には壁、床、棚、設備、通路、禁止区域といった分類や、作業員が入力した名称がある。入力を保存せず派生メッシュだけ残す設計と、未加工の映像を長期保存する設計では、契約・プライバシー・漏えい影響が大きく異なる。

アンカー・対応・コンテンツの三層

アンカー層は現実空間の姿勢や識別子、対応層は空間内の基準点 IDと顧客・施設・設備・表示内容 IDの照合・結合、コンテンツ層は表示する3Dモデル、文章、動画、作業手順、言語差分である。3Dアセットの著作権はUnity・Unreal・3Dアセットの権利と技術DDへ委ね、本稿では対応表が承継対象に含まれるかだけを見る。

運用・証拠の第七層

最後は利用ログ、位置の照合結果、位置ずれ、再スキャン、権限拒否、削除、苦情、顧客承認といった運用証拠である。この層がないと、登録件数の多さを利用価値へ変換できない。利用回数だけではなく、どのバージョンのどの空間内の基準点が、どの端末・施設で成功又は失敗したかを追える粒度が望ましい。ログに個人や機密情報が含まれる場合は、必要最小限の抽出と閲覧制限を行う。

一つのアンカーのデータ来歴を作る

全件を最初から精査するより、代表的な一つのアンカーを入口から出口まで追うと、台帳と実装の断絶が見つかりやすい。対象は売上が大きく、直近に利用され、買収後も継続予定で、複数のシステムを通るものを選ぶ。データ来歴票は、監査人が同じ手順をたどって同じ結果を得られる内容にする。

取得時点を記録する

取得者、顧客、施設、区域、日時、端末、OS、アプリビルド、SDK、利用許可状態、ネットワーク、照明、取得目的、撮影範囲、現場承認者を記録する。住居、病院、教育施設、製造現場のように第三者又は機密物が映り得る場所では、撮影禁止区域、マスキング、未加工の映像の保存有無、立会者も追加する。後日、誰が何を許可したかを口頭説明だけに依存しない。

加工と保存を記録する

端末内で一時処理されるもの、基盤サービスへ送られるもの、自社APIが受け取るもの、顧客テナントへ保存するものを別行にする。圧縮、特徴の抽出、メッシュの簡略化、意味を示す分類名、座標変換、匿名化と呼ぶ処理を、入力・出力・実行場所・ソフトウェアバージョンと結ぶ。「匿名化済み」という社内ラベルだけでは個人識別可能性や再識別リスクの結論にならない。

利用・更新・削除を記録する

どのユーザーがどの目的で位置を照合し、どのコンテンツを表示し、最後に成功した日、更新期限、顧客契約終了日、削除予定日を追う。空間内の基準点 IDの削除、基盤サービス上のデータ削除、自社DBの対応表削除、バックアップ消去、分析ログ削除が同時に行われるとは限らない。削除要求を一つの対応記録から全保存先へ伝播できるか、サンプルで確認する。

保存場所と支配主体を地図にする

データフロー図は矢印だけでなく、各箱の支配主体を示す。譲渡企業法人、親会社、創業者個人、顧客、再委託先、基盤サービス提供者のどれが契約者・管理者・課金者なのかを色ではなく文字で記載する。買収対象会社が利用していても、親会社の組織配下又は創業者の個人アカウントにあれば、取引対象として移せるとは限らない。

端末内データ

端末へ永続化される空間内の基準点、一時保存データ、位置などの調整、端末内の DB、ダウンロード表示内容について、端末所有者、MDM、利用者アカウント、バックアップ、初期化、紛失、交換時の復旧を確認する。顧客所有端末にしか残らない情報は、譲渡企業の資料共有室へ書き出しできない可能性がある。反対に譲渡企業所有の共有端末へ複数顧客の情報が混在すれば、事業の切り出し時の分離が必要になる。

自社と顧客のクラウド

同じサービスでも、自社の複数顧客で共用する方式のSaaS、顧客専用プロジェクト、顧客VPC、自社内のサーバー、通信なしで利用する配布物で構成が違う。契約上の処理の受託者／処理の再委託先、管理者権限、記録の保存、バックアップ、暗号化鍵、書き出し、終了時返却を構成別に確認する。顧客専用環境が買収対象外の運用会社に依存する場合は、TSA又は新契約がないと継続できない。

基盤サービス上のデータ

基盤サービスが生成・保持する情報は、自社DBの通常バックアップに含まれないことがある。APIで何を一覧・書き出し・削除できるか、プロジェクトを移動できるか、認証方式と利用枠は何か、サービス終了又は非推奨化の方針は何かを調べる。契約書に「全データを引渡す」と書くだけでは、基盤サービスが書き出しを提供しない情報を物理的に引き渡せない。

visionOSの周辺空間内の位置追跡と周辺環境の認識

AppleのARKit データへのアクセス公式資料は、手の動きの追跡と周辺環境の認識を機微な情報としてシステムがアクセス制御し、利用者が拒否又は後から取消しできることを説明している。画像の追跡、平面の検出、周辺空間の再構成を使う場合は、利用理由を示す`NSWorldSensingUsageDescription`が必要になる。DDではInfo.plistの文字列だけでなく、拒否時の機能、アプリ内説明、権限変更後の状態を実機で見る。

周辺空間内の位置追跡は同じ言葉ではない

同じ公式資料には、周辺空間内の位置追跡は周辺環境の認識と異なり権限の許可を要しないとの注記がある。したがって「空間に関する全機能が同じ利用許可」という説明は正確でない。どの提供者とAPIをどの機能で呼ぶかをソースコードと実行環境で特定し、機能別のデータ取得、利用許可、代替操作を一覧にする。

Full Spaceという実行条件

AppleはARKit データが、アプリがFull Spaceを提示し他のアプリが隠れているときに利用できると説明する。買い手は権限が許可済みかだけでなく、ウィンドウ／立体表示領域／没入型の体験の遷移、セッション開始・停止、裏側での動作、復帰、別利用者での挙動を確認する。UIの統合作業でFull Spaceの使い方を変えると、買収前のデモと同じデータへのアクセスを得られない可能性がある。

拒否と取消しは例外ではない

利用許可拒否をエラー画面で終わらせるサービスは、利用可能ユーザーと契約SLAを狭める。Appleは代替手段や依存コンテンツの適切な遷移を検討するよう説明している。DDでは、許可前、拒否、許可、設定から取消し、利用セッション中取消し、再許可の状態遷移を試す。アクセシビリティ入力や手動配置が実用になるかも、顧客継続率と再設計費へ反映する。

Apple 空間内の固定基準点と業務メタデータ

Appleの空間内の固定基準点公式資料は、空間内の固定基準点を使い、利用者が移動するときや利用セッションをまたいで実世界の座標空間の特定点を追跡する方法を示す。ARKitが追加した空間内の基準点を追跡し、同じ場所へ戻った際に更新を受け取れることは有用だが、M&Aで必要なのは「基盤サービスが追跡する」事実と「事業上の意味を買い手が復元できる」事実を分けることだ。

識別子と意味を照合・結合する

空間内の基準点の識別子・位置・姿勢に対し、施設、部屋、設備、表示内容、言語、有効性、顧客権限をどのDBで関連付けるかを確認する。照合に使う共通の識別子が手入力、CSV、複数DBの複合キーに依存すると、欠損や重複が起きやすい。代表サイトから空間内の基準点一覧を出し、対応表の孤児、重複、無効表示内容、退去済み施設、削除済み顧客を抽出する。

周辺だけが見える条件を試す

空間内の基準点は現場環境と無関係な通常レコードではない。端末の現在位置や空間の再設定、実世界の座標原点の変化によって更新の扱いが変わる。買い手は空間内の基準点一覧が管理画面へ表示されることだけを確認せず、別端末・別日・再起動・Digital Crown等による空間再配置後の挙動を検証する。位置のずれを誰が検知し、顧客へ再配置を依頼するかも運用資産である。

部屋の追跡を使う製品

Appleの部屋の追跡公式サンプルでは、RoomTrackingProviderに周辺環境認識の利用許可と利用理由が必要とされる。部屋境界や現在の部屋を業務ロジックへ使うサービスでは、利用許可だけでなく、部屋変更、扉、複数階、模擬実行非対応、端末要件をテスト表へ加える。譲渡企業の対応端末表が実装と一致するかも調べる。

ARCore Cloud Anchorの登録と位置の照合

GoogleのCloud Anchors公式資料によると、Cloud Anchorは現実の場所へ結び付けたAR体験を複数端末・利用者・時点で共有するための仕組みである。登録時、ARCoreは端末内の空間内の基準点周辺のデータをクラウドの接続先へ送り、固有IDを返す。位置の照合時、同じ環境でカメラを向け、周辺空間の視覚的な特徴と作成済み三次元特徴マップを比較して位置・姿勢を得る。

IDリストだけでは再現証拠にならない

Cloud Anchor IDがDBに1万件あることは、1万件が現在解決できることを意味しない。IDの有効期限、関連プロジェクト、権限の許可、現場変化、撮影品質、端末対応、利用枠、ネットワークがそろう必要がある。DDではID件数を「登録」「有効期限内」「直近成功」「要再取得」「失敗」「顧客終了」に区分する。

登録品質を過去へさかのぼる

登録には中心周辺を複数の角度・位置からカメラでマップする過程がある。作業者の熟練、計測範囲、照明、表面の模様、動く物体、立入制限が品質に影響し得る。譲渡企業の作業手順、研修、品質指標、再試行、現場承認を確認し、地域担当ごとの失敗率を比較する。特定担当者だけが高い成功率を持つなら、人材承継と手順化を価格や従業員の定着策へつなげる。

位置の照合品質を顧客体験へ変換する

平均位置の照合時間だけでは足りない。初回成功率、90又は95 百分位数、失敗後の代替動作、手動検索、誤った設備へ表示する危険、利用者の姿勢・導線を測る。工場保守では位置ずれが作業ミスへ、店舗ナビでは待ち時間が離脱へつながる。業務別に許容値を決め、同じ指標を一律適用しない。

TTL・認証・クォータを収益継続へ結ぶ

ARCore Session公式参照は、Cloud Anchorの`ttlDays`について、APIキーを使わない認証では最大365日、APIキー認証では最大1日と説明する。これは2026年8月22日時点の仕様であり、記事読者は案件時点の最新版を確認する必要がある。DDではTTLを単なる技術パラメータではなく、契約期間と更新運用へ結ぶ。

契約期間とTTLを突き合わせる

3年契約で空間内の基準点 TTLが365日なら、更新又は再登録の運用が必要になる。誰が期限を監視し、いつ更新し、失敗時に現地対応し、費用を負担するかを確認する。更新作業が一人のPCで動く、日程表期限の通知だけに依存する、顧客契約が終わっても自動更新する、という状態は将来費用と保持期間の不一致を生む。

認証方式と鍵を確認する

GoogleのARCore API 権限の許可公式資料は、地理空間機能とクラウド上の空間基準点の機能が、Google Cloud上のARCoreの接続機能と認証情報を使うこと、iOSではAPIキーを使わない認証が推奨され、サービス用アカウントと署名処理が必要になることを説明する。サービス用アカウント、秘密鍵、認証トークンの発行先、トークンの宛先、定期更新、事故の履歴を資料共有室へ入れ、アプリ側に不要なAPIキーが残っていないかを調べる。

利用枠と課金を顧客別に配賦する

利用枠超過は全顧客へ同時影響する可能性がある。プロジェクト別利用枠、実績、利用の集中時、再試行、一定時間内の利用回数制限、警報、課金、顧客別利用を確認する。買収後に顧客を一プロジェクトへ統合すると、買収前には起きなかった集中が生じる。統合効果を見込む場合も、利用枠申請、割引、サポート、監視、元の状態への復元の費用を計画へ含める。

ARCoreが処理する位置・映像・アンカーデータ

GoogleのARCore 個人情報の保護公式資料は、開発者がApp Storeのデータの収集・共有申告に責任を負うとした上で、ARCoreが常時又は特定API利用時に扱うデータを区分している。端末 ID、性能、API 利用と、Geospatial利用時の正確な位置情報、Cloud Anchor 登録・位置の照合時の映像、Cloud Anchor データは同じ保持・目的ではない。

登録と位置の照合の映像処理を分ける

公式資料では、Cloud Anchor 登録時の映像は一時保存後に自動削除対象、位置の照合時は即時・メモリー内処理で終了後保持しないと説明される。一方、登録されたCloud Anchor データはサービス提供のため作成・保存される。譲渡企業のアプリ自身がカメラの画像を保存・送信していれば基盤サービスの説明だけでは足りないため、通信の取得記録、開発キットの呼び出しをまとめる実装、利用分析、異常終了の報告を実装で確認する。

正確な位置情報と施設内情報を分ける

Geospatial APIを使う屋外ナビと、Cloud Anchorを使う屋内設備支援では、位置の種類と顧客期待が違う。住所、緯度経度、施設コード、部屋、空間内の基準点、利用者の移動経路を別項目として棚卸しし、単独・結合時の識別可能性を判断する。位置を「匿名」と呼んでいても、勤務先、時間、端末 IDと合わせて特定人へ結び付く可能性がある。

利用者への公式通知を実機で見る

ARCoreの利用者プライバシーに関する要件は、ARCore利用を目立つ形で開示し、Cloud Anchors又はGeospatial API起動に関連してGoogleがカメラ・位置等のセンサーデータを処理する旨を示す通知を求める。DDでは現在のアプリだけでなく、旧バージョン、他社ブランドでの提供版、顧客専用ビルド、iOS／Androidの表示差を確認する。配信ストア申告とアプリ内表示が同じデータの流れを説明しているかも照合する。

Meta Passthrough Camera APIで対象が広がる

MetaのPassthrough Camera API公式資料は、2026年4月21日更新時点で、Quest 3／3Sの前方RGB カメラへアクセスし、画像認識や機械学習へ使う仕組みを説明している。Horizon OS v74以降、カメラ利用許可、周辺映像の透過表示有効化等の条件があり、物体認識、案内、研修結果の共有、端末外で動く大規模言語モデルの例も示される。周辺空間 APIの抽象化された情報だけを扱っていた会社がRGBへ拡張すると、DD対象も変わる。

カメラへのアクセスの有無を製品版ごとに調べる

営業資料に「AIで周囲を理解」と書いてあっても、実装が周辺環境の分類なのか、カメラの画像をアプリが取得して独自又は第三者モデルへ送るのかでデータフローは異なる。Quest アプリ設定・宣言ファイル、利用許可、実行中の許可画面、Unity／Unreal 拡張機能、Androidの基本機能に直接接続する部分、機械学習モデルによる推論場所、画像保存、不具合調査用の画像取得をビルドごとに確認する。実験用の開発分岐や顧客PoCも、本番へ混入していないかを見る。

施設の秘密が画像へ入る

工場の制御盤、病院の掲示、店舗の売上画面、住宅内の持物、人物、名札がカメラの画像へ入る可能性がある。目的が設備認識でも、入力には目的外の情報が含まれ得る。端末内で直ちに破棄する設計と、クラウドへ送信して再学習に使う設計を分け、顧客契約、通知、保持、アクセス、処理の再委託先、国外処理を確認する。

API更新を新規価値と規制費へ分ける

新しいカメラへのアクセスは製品機能と学習データを増やせる一方、同意、契約、審査、保存領域、モデル運用、漏えい影響も増やす。買い手は実施計画上の売上だけをDCFへ入れず、必要な顧客再許諾、データの最小化、端末側での推論、審査、保険、運用費を同じ想定へ置く。まだPoCなら、成功確率と規制是正費を別にし、既存収益へ混ぜない。

個人情報・個人関連情報を施設単位で判定する

個人情報保護委員会の通則ガイドラインは、個人情報、個人データ、個人関連情報等を区別し、義務が異なるため注意を求める。空間データを「顔を消したから非個人情報」「座標だけだから対象外」と一括しない。譲渡企業が保有する他情報との容易照合性、顧客が受け取った後の識別可能性、継続的な位置、映り込み、端末・アカウントとの結合をデータの流れの段階ごとに見る。

住宅・医療・教育・職場でリスクが変わる

住宅の部屋のメッシュは居住者の生活状況、病院の映像は患者や診療情報、学校は児童生徒、工場の移動経路は従業員の勤務へ結び付くことがある。同じSDK出力でも、場所と目的で権利利益への影響が異なる。施設類型、利用者、第三者の立入り、撮影時間、識別子、顧客の他DBを整理し、重要類型を法務・個人情報の保護専門家へ上げる。

事業承継後の利用目的を広げない

通則ガイドラインは、合併、分社化、事業譲渡等で事業を承継し個人情報を取得した場合、承継前の利用目的達成に必要な範囲内で扱う限り、目的外利用にならないと説明する。一方、必要範囲を超える利用には原則として事前同意が必要である。買い手が全施設メッシュを汎用AIの学習、別顧客の設計、広告へ使う計画は、買収前の目的に当然含まれない。

DD開示そのものを最小化する

買い手が技術価値を確かめるために未加工の映像全件を受け取る必要は通常ない。まずデータ項目定義書、件数、保持、契約、集計指標を開示し、次に匿名化や必要箇所のマスキングを行ったサンプル、最後に必要な限定データを情報を隔離して扱う担当チーム又は管理された環境で確認する。目的、閲覧者、複製、記録、破談時削除、専門家利用をNDAと手続き案内書へ置き、譲渡企業の通常運用を買収検討によって拡張し過ぎない。

営業秘密・限定提供データを自動認定しない

施設の点群や設備配置は価値が高く、顧客が秘密として扱うことが多い。しかし価値が高いことと、法律上の営業秘密に該当することは同じではない。経済産業省の営業秘密管理指針は、2025年3月31日最終改訂版で、秘密管理性、有用性、非公知性を実態に即して説明する。契約の秘密情報表示だけでなく、アクセス、表示、教育、退職、持出し、委託先管理を見る。

秘密管理性を施設データへ当てはめる

顧客ごとに分離された利用領域の権限、プロジェクト分離、ダウンロード制限、ファイル名、画面表示、API 認証用情報、作業者端末、端末などに保存した通信不要の複製、サポートアクセス、バックアップ、退職者アカウントを確認する。「秘密情報」フォルダーへ置いていても、全社員が共有URLで取得でき、誰も秘密と認識しない状態なら、管理実態の検討が必要になる。反対に厳格な統制があっても、買い手への開示方法を誤ると顧客契約違反を生じ得る。

限定提供データの三要件を確認する

経済産業省「限定提供データと利活用」は、価値あるデータが著作権又は営業秘密で保護されない場合があることを背景に、限定提供データの要件を案内する。限定提供データに関する指針と合わせ、業として特定の者へ提供、電磁的方法による相当量の蓄積、電磁的管理等を個別に検討する。施設メッシュ一件を持つだけで自動的に該当すると書かない。

顧客の秘密と譲渡企業の資産価値を区別する

譲渡企業が保管していても、顧客が提供した施設情報又は顧客のためだけに作成した派生データで、終了時返却・削除又は他目的利用禁止が定められていれば、自由に再利用できない。企業価値は保有データ量ではなく、契約上許された用途と継続顧客から生じる。顧客の秘密管理を強化する費用は必要でも、秘密を汎用データ資産として二重計上しない。

データ所有ではなく利用権限を読む

空間データのDDで「誰のものか」という質問だけを置くと、担当者は所有権、著作権、契約上の使用権、クラウドアクセス、秘密管理を混ぜて答えやすい。経済産業省のAI・データ契約ガイドライン（データ編）は、データが無体物で所有権の対象ではなく、利用権限を契約で定め得るという整理を示す。資料は2019年12月の1.1版であり、新しい法令の代替ではなく契約項目の補助線として使う。

十二の動詞で権限を分解する

取得、閲覧、保存、複製、加工、結合、分析、学習、第三者提供、国外処理、M&A承継、返却・削除を契約ごとに確認する。「利用できる」だけでは、派生メッシュを別案件へ使えるか、買い手のグループ会社へ移せるか、モデルの学習へ投入できるか、再委託できるかが分からない。元データ、加工データ、統計、モデル、改善知見も別行にする。

創出への寄与と契約文を照合する

顧客が場所と設備情報を提供し、譲渡企業が端末・ソフトウェア・人員で計測し、基盤サービスが特徴マップを生成する。複数者が寄与しても、そこから単一の「所有者」が当然に決まるわけではない。注文書、利用規約、DPA、SOW、検収、データ方針、基盤サービスの利用条件を読み、寄与、費用、目的、派生利用、秘密、終了を一致させる。営業担当の口頭約束も例外一覧へ残す。

アクセス可能性を権利の代わりにしない

管理者アカウントでダウンロードできることは、契約上利用・譲渡できることを意味しない。反対に契約上権利があっても、基盤サービスの書き出し制限又は失効した認証情報で技術的に取得できないことがある。DD 報告は「法的な利用許可」「契約利用許可」「技術的なアクセス権限」「実際に利用できる能力」の四列を分け、いずれかが未確認なら結論を限定する。

顧客契約を十二の動詞で監査する

契約監査は代表契約一枚では足りない。標準条件、旧版、顧客ひな型、個別SOW、PoC、自治体調達、研究共同契約、他社ブランドでの提供、再販売業者経由で条項が違う。売上上位だけでなく、データ量、機密性、技術依存、更新時期、支配権の変更、顧客類型を組み合わせて抽出した事例を選ぶ。契約書の保管場所と売上台帳を照合し、契約が見つからない施設を明示する。

取得・保存・処理の根拠

カメラ、奥行き、位置、施設図面、資産管理台帳を誰がどの目的で提供又は取得するか、未加工データと派生データの保存場所・期間、再委託・国外処理、顧客の監査権、安全対策の一覧、事故通知を読む。撮影許諾が「導入作業」に限定されれば、将来の再計測又は改善学習を別に確認する。顧客が従業員・来訪者への説明を担う条項だけで、譲渡企業自身の義務が全て消えると考えない。

再利用・学習・製品改善の根拠

顧客データをサービス提供だけに使えるのか、匿名又は集計結果で製品改善に使えるのか、派生した特徴を他顧客へ使えるのか、モデルへ残せるのかを区分する。匿名化の定義、再識別禁止、顧客固有情報の除外、利用拒否、終了後の扱いも確認する。「品質向上」という広い語で全ての二次利用を正当化しない。

M&Aと終了時の根拠

譲渡・承継、支配権の変更、事前通知・同意、競合買い手、再委託先、グループ会社、事業譲渡、契約解除、返却、削除、証明書、バックアップ、法定保持を読む。株式譲渡で法人が同じでも支配権の変更解除や競合制限が発動する場合があり、事業譲渡では契約・データ・許諾を個別移管する必要があり得る。顧客別に「不要」「通知」「同意」「禁止」「不明」を付ける。

株式譲渡・事業譲渡・カーブアウトの差

取引構造は空間データの移し方を変える。株式譲渡では対象法人が契約者・クラウドのプロジェクト管理責任者のまま残りやすいが、親会社組織、グループ共通基盤、創業者アカウント、顧客の支配権の変更は別問題である。事業譲渡では、契約、従業員、端末、IP、データ、アカウント、利用許可を列挙して移す。カーブアウトは、共有DBと共有プロジェクトから対象施設を分離する作業が加わる。

株式譲渡の確認点

法人同一性だけで「何も変更なし」と結論しない。取締役会・管理者変更、SSO ドメイン、本人認証提供者、料金の請求、グループ DPA、親会社処理の再委託先、サポート、保険、顧客競合制限を調べる。買い手グループが別国からデータへアクセスするなら、従前目的と契約、越境、アクセス管理を再評価する。買収後の基盤サービス統合は取引完了後の新しい処理になり得る。

事業譲渡の確認点

顧客契約の譲渡同意と、事業承継に伴う個人情報の取扱い、施設秘密、基盤サービスアカウントの譲渡可能性を別々に検討する。譲渡対象表にはDB名だけでなく、分離された利用領域、プロジェクト、クラウドの保存領域、一覧表、空間内の基準点識別名の管理範囲、鍵、ドメイン、証明書、携帯端末向けアプリ、配信ストア一覧、サポート対応記録を含める。除外資産が必要な機能を支える場合は利用許諾又はTSAを準備する。

カーブアウトの境界テスト

顧客 IDで行を抽出できても、共用のモデル、集計結果マップ、全体共通の特徴索引、バックアップ、記録、監視には複数事業が混在することがある。論理的な分離が契約・安全対策要件を満たすか、物理的な複製が必要か、モデル再学習が必要かを判断する。分離完了を譲渡企業自己申告だけでなく、記録件数、ハッシュ値、アクセス試験、削除報告、顧客の抽出事例で検証する。

Google Cloud プロジェクトの移行を誤解しない

Google Cloudのプロジェクトの移行公式資料は、買収を移行理由の一つとして挙げ、プロジェクトを組織リソース間で移す操作を説明する。これはデータそのものの移転ではなく、クラウド資源の階層上の親を変更する付随情報の操作であり、プロジェクトID・番号、データとクラウド資源、直接付与されたIAMの役割は維持される。一方、親となる組織の変更によってセキュリティの状態が直ちに変わる点が重要である。

変わらないものを検証する

プロジェクトの識別子・番号、プログラム内に固定記述した接続先、APIキーの参照、サービス名、保存領域、データベース、仮想マシンなどが継続するという一般仕様を、対象の構成に当てはめる。移行の前後で、管理対象の一覧、サービスの稼働状態、空間基準点の登録・照合、認証トークンの発行、携帯端末用アプリ、ウェブ管理画面、警報を比較する。仕様上は停止時間が想定されなくても、自社固有の依存関係や組織の管理方針によって障害が起こる可能性を試験する。

変わるものを先に再構築する

移行元の組織・フォルダーから継承したアクセス権限は失われ、移行先の組織の管理方針が適用される。組織単位の利用上限、独自の役割・権限、ドメイン制限、クラウドサービスの境界制御、ログの転送先、鍵管理サービスへのアクセス、利用を許可する地域などの違いを移行計画に盛り込む。プロジェクトへ直接付けた権限が残ることを理由に、過剰な管理者権限をそのまま引き継がない。

料金の請求・割引・サポートを価格へ入れる

公式資料では料金の請求アカウントは元のものへ接続したままで、自動的に買い手へ切り替わらない。企業割引、約束済みの利用、Marketplace 購入、サポート区分は移行後に同じ条件にならない可能性がある。譲渡企業の粗利益を買い手が再現できるか、SKU別利用を新価格で再計算する。交渉・再購入が必要なら一時的な費用と継続的な費用水準を分ける。

鍵・アカウント・課金・組織ポリシーを移す

プロジェクトの移行が成功しても、アプリが使うすべての認証情報が移るとは限らない。ソースコード内の秘密情報、開発・配信基盤、携帯端末向けアプリの署名、Appleの開発チーム、Google Play、Metaの開発者組織、名前解決の設定、証明書、メール、サポート用サイト、利用分析、異常終了の報告、大規模言語モデルの提供者を依存関係図に加える。各項目に管理責任者、契約者、管理者、復旧方法、多要素認証、請求、移転の可否、有効期限、認証情報の更新を記載する。

秘密鍵をそのまま渡さない

取引完了で譲渡企業の秘密鍵を圧縮ファイルにして渡すだけでは、過去複製と退職者アクセスを解消できない。買い手環境で新しい鍵・サービス用アカウントを作り、並行稼働、段階切替、失敗時元の状態への復元、旧鍵無効化、記録監視を行う。顧客アプリに埋め込まれ即時更新できない認証情報は、携帯端末向け公開・配信実施間隔と利用中バージョンを考慮して移行期間を設計する。

人のアカウントを役割へ置き換える

創業者個人や退職予定者だけが管理責任者の場合、パスワードの共有では継続性を確保できない。会社のメール、管理グループ、緊急用のアクセス手段、多要素認証の端末、物理的な認証キー、復旧用の連絡先を買い手の管理へ移し、必要最小限の権限と二者による承認を設定する。顧客環境へのサポート用アクセスも、個人アカウントから、役割に応じた期限付きのアクセスへ変える。

移管を一つの取引記録にする

誰がいつ何を変更し、前後の状態、対応記録、承認、試験、元の状態への復元、残作業を記録する。プロジェクト、鍵、DNS、配信ストア、顧客通知を別担当チームが扱うと順序依存が見えにくいため、切り替え対応手順書にまとめる。成功条件はログイン可能ではなく、代表施設で登録／位置の照合、コンテンツの表示、記録の保存、料金の請求、警報、サポートが端から端まで動くこととする。

データルームをサイト単位で組み立てる

空間データDDの資料共有室は、法務フォルダー、技術フォルダー、財務フォルダーを完全に分離すると、同じ施設の証拠がつながらない。顧客・施設・サービスを共通IDで管理し、契約、注文、空間内の基準点、データの流れ、プロジェクト、利用、事故、粗利益を参照できる索引を作る。機微データそのものは権限を分けても、付随情報で所在と確認状況を見えるようにする。

施設別管理台帳の必須列

顧客、施設、国、利用想定、契約 ID、開始／終了、年間売上、端末、OS、アプリビルド、SDK、空間内の基準点種類、件数、稼働中の件数、最終成功した位置の照合、TTL、クラウドのプロジェクト、データの区分、利用許可、譲渡・承継、支配権の変更、削除、管理責任者を置く。空欄をゼロとみなさず、不明、適用対象外、未試験を別値にする。

根拠資料の該当箇所へ直接リンクする

各列は契約ページ、管理画面の記録、書き出し、試験結果、記録の検索結果、請求書等へリンクする。画面の記録だけでは時点と全件性が弱いため、可能なら読み取り専用アクセス、CSV、API 書き出し、ハッシュ値、問い合わせ定義を併用する。個人情報や秘密を含む資料は必要箇所を伏せるか、又は情報を隔離して扱う環境へ置き、閲覧者・ダウンロードを記録する。

更新責任を明示する

DD期間中も新規施設、空間内の基準点更新、契約更新、事故、API 変更が起きる。基準日、更新実施間隔、区切りの時点、差分報告者、契約締結／取引完了時の再確認を決める。静的資料共有室を一度提出して終わりにせず、最終契約の添付明細と同じIDで更新できるようにする。

サンプル施設の選び方

全施設で現地試験を行うのは現実的でない。無作為抽出した事例だけでも、高リスク又は高売上施設を取り逃す。売上、粗利、業種、機密性、基盤サービス、端末、地域、築年・改装、空間内の基準点年齢、失敗率、契約例外、担当者を軸に母集団を区分別に分け、目的別の事例を選ぶ。選定理由と母集団対象範囲を投資委員会へ示す。

必ず含める施設

売上上位、解約予告、事故・苦情、直近改装、古いSDK、期限接近、顧客専用クラウド、特別契約、住宅・医療・教育等の機微環境、創業者だけが設定できる施設を含める。同じ顧客の複数施設がひな型展開されていても、一施設の成功を全てへ外挿せず、地域又は担当チームを変える。

通常施設も含める

問題案件だけを選ぶと平均移行費を過大評価する。中位売上、標準契約、標準端末、直近利用、通常担当者の施設を選び、標準的な想定を測る。新規導入から長期運用まで導入からの経過期間による顧客群を分け、撮影品質と運用成熟の差を見る。

顧客参加の方法

現地訪問や買い手端末の使用は、秘密保持、撮影規約、安全、競争上の情報、従業員・来訪者個人情報の保護へ影響する。譲渡企業主導実演、第三者専門家、情報を隔離して扱う担当チーム、匿名施設、取引完了の前提条件後の試験等から段階を選ぶ。顧客にM&Aを知らせる時期は契約・取引秘密保持と整合させ、無断で試験しない。

現地再現テストの手順

現地試験は成功動画を撮る行事ではなく、再現可能な実験として設計する。試験計画に目的、対象空間内の基準点、端末、OS、アプリビルド、SDK、アカウント、利用許可、ネットワーク、環境条件、期待値、失敗分類、観察者、開始・終了時刻を記載する。譲渡企業が普段使う端末だけでなく、買い手管理の初期化済み端末又は新規利用者の設定を含める。

準備段階

契約・施設ルールに従い、現場責任者、撮影範囲、立入、安全、第三者の映り込み、ネットワーク利用を確認する。空間内の基準点 IDと表示内容の期待一覧を事前に確定して変更を止め、試験直前の譲渡企業修正は変更記録へ残す。アプリ導入、認証情報、利用許可は対応手順書に従い、開発者の暗黙知を使った手作業を別欄へ記録する。

実行段階

初期状態からの起動、通常起動、別日再訪、権限拒否・取消し、ネットワーク遅延・切断、端末再起動、OS更新候補、照度・混雑、入口違いを試す。空間内の基準点を見つけるまでの時間、再試行、誤位置、表示内容バージョン、代替動作、サポート介入を測る。結果だけでなく画面録画、アプリの記録、API 対応、クラウド記録、観察メモを同じ試験 IDへ結ぶ。

復旧段階

失敗後に遠隔の設定変更、空間内の基準点再登録、現地再計測、表示内容再配置、アプリ更新のどれが必要かを確認する。復旧時間には技術者作業だけでなく、顧客調整、入館、夜間作業、端末配送、検収を含める。同じ原因が他施設へ広がるかを母集団に照らし、抽出した事例の失敗を単独事故で閉じない。

解決率・位置ずれ・孤児率を測る

空間サービスの重要指標は、有効な空間基準点の数だけでは不十分である。最低でも、照合の成功率、照合にかかる時間、位置・向きの誤差、誤った基準点との照合、参照先を失った基準点、有効期限切れ、再登録、権限による拒否、手動での代替対応、問い合わせ件数を、拠点・バージョン・端末別に測る。分母を明示し、成功した利用だけを集計しない。

成功率の分母を固定する

試行とはアプリ起動、カメラ開始、空間内の基準点要求、顧客が表示を求めた時点のどれかを定義する。利用者が途中離脱した利用セッションを除くと数字が良く見えるため、途中離脱も別指標にする。初回の試行、30秒以内、最終的な成功を分け、業務SLAに合うものを採用する。

位置ずれを用途別に評価する

展示解説の数十センチメートルずれと、設備の操作箇所を示す保守支援のずれは影響が異なる。平行移動、回転、遮蔽、奥行き、物体誤認識を測り、危険な誤表示は単なる平均誤差へ埋めない。安全への影響が大きい用途は、誤位置時に表示を抑止する条件と人による確認を検証する。

孤児空間内の基準点を財務へ結ぶ

基盤サービスには存在するが自社DBに意味がない、DBにはあるが基盤サービスで解決できない、表示内容が削除済み、契約終了後も残る、といった孤児を分類する。孤児率はデータ品質だけでなく、保存領域、個人情報の保護、顧客信頼、再取得工数へ影響する。整理・削除が自動化されていない場合は、件数×一件当たり調査・削除時間でPMI費を見積もる。

赤旗を原因別に分類する

赤旗を「重大」「中」「軽微」だけで並べると、対処法と価値影響が見えにくい。権限欠缺、技術再現不能、アカウント支配欠如、証憑不足、運用集中、個人情報の保護・秘密、顧客継続の七類型へ分ける。同じ事象が複数類型にまたがる場合は、根本原因とその後の工程への影響を矢印で示す。

直しにくい赤旗

顧客契約がM&A承継を禁止し同意見込みが低い、施設データを終了時削除済み、基盤サービス書き出しも再登録権限もない、重要顧客が競合買い手を拒否する、といった事象は費用だけで解消できない。対象売上の除外、取引対象範囲変更、顧客との三者契約、価格調整、条件不成就を検討する。

費用で直せる赤旗

台帳欠損、古い空間内の基準点、管理責任者アカウント集中、通知旧版、認証鍵の更新未実施、監視不足は、一定の期間と顧客協力があれば是正できる可能性がある。必要人日、外部費、現地訪問、公開・配信、顧客同意、再試験、不測の事態への備えを算出し、譲渡企業是正、価格の減額、第三者への預託、取引完了後の義務のどこへ配分するか決める。

証拠がない赤旗

違反又は失敗が確認できない一方、成功証拠もない状態を「問題なし」としない。不明母集団、不足している契約、記録のない試験、口頭利用許可は、不確実性として評価する。追加DD期限を定め、解消しない場合の前提、価格、表明、抽出方法制限を報告へ明記する。

空間データの評価モデル

空間データM&Aでは、空間データを独立した無形資産のように一括評価するより、契約別将来キャッシュフローへ「承継可能性」と「技術再現性」を掛ける方が、判断に使いやすい。基本式は、`Σ（施設別将来粗利 × 顧客継続確率 × 契約承継確率 × 技術移行成功率）－ 是正・再取得・移管・継続保守費`である。各確率を一つの主観点数へまとめず、証拠と管理責任者を付ける。

将来粗利を施設へ割り当てる

契約請求額から端末再販売、現地作業、クラウド API、サポート、表示内容更新、移動、第三者の利用許諾を控除し、空間層が失われた場合に残る売上を分ける。包括契約なら、機能別利用、顧客聞き取り、サービス提供費用、更新理由を使い、空間データ寄与を範囲で示す。全売上を空間内の基準点資産へ帰属させない。

成功確率の根拠

契約承継は条項、顧客意向、取引構造、過去同意実績から、技術移行は抽出した事例試験、稼働中の割合、基盤サービス移転、鍵、バージョン、改装から評価する。顧客継続はNPSではなく、更新、利用者、解約予告、予算、競合、買い手の評判を組み合わせる。楽観・標準・厳しい想定で前提を変え、二重にリスク割引しない。

費用と期間を同時に置く

同意の再取得、再計測、空間基準点の更新、クラウド移行、新しい鍵、アプリの公開、現地での受入確認、データ整理、法務確認、個人情報の取扱い通知、移行支援契約の費用を一時費用として見積もる。有効期間の更新、監視、サポート、利用上限の確保、出張、利用許諾の費用は継続費用として見積もる。必要に応じて、停止期間中の失注、サービス品質保証に基づく返金・料金調整、作業完了までの運転資金も含める。

三つのモデル案件で計算する

以下は実在企業の数値ではなく、評価方法を説明する仮定例である。倍率や率を市場標準として使わず、案件の契約・試験・顧客意向から置き換える。数値の目的は、データ量と企業価値を直結させず、通過確認段階と是正費を可視化することにある。

工場保守ARの例

年間粗利4,000万円のうち、対象20工場の空間内の基準点機能へ2,800万円が依存すると仮定する。契約承継確率95%、抽出した事例に基づく技術移行成功率85%、顧客継続90%なら、単純期待粗利は2,034万円相当となる。全工場の再計測費700万円、夜間入場・検収300万円、クラウド移管200万円、予備費を控除する。位置ずれが安全へ影響する設備は別途厳しい想定へ置く。

商業施設ナビの例

50施設のうち、改装履歴が新しく直近位置の照合成功がある30施設、古いが更新可能な15施設、契約上データ持出し不可の5施設に分ける。最初の30は高い成功率、15は再計測費と停止率、5は将来粗利ゼロで評価する。総空間内の基準点件数を均等割りせず、来館利用、広告契約、施設更新、改装予定を施設別に反映する。

住宅AR配置の例

住宅内メッシュを買い手が汎用モデル学習へ使う成長計画があるが、従前通知と契約がサービス提供に限定されていると仮定する。既存顧客サービスの継続価値と、未確定な二次利用価値を分ける。再同意率を楽観的に置かず、同意しない顧客データの削除・モデル再学習、問い合わせ対応、基盤サービス審査を費用想定へ置く。二次利用が実現しなくても既存事業が成立するかを確認する。

表明保証を抽象語で終わらせない

「対象会社は全データを適法に所有する」という表明は、空間データの複雑な権限を正確に表さない。別紙の施設・データの区分・契約・プロジェクトへ紐付け、取得、保存、利用、加工、第三者処理、譲渡、削除、秘密、個人情報、基盤サービスの利用条件を個別に開示する。譲渡側（株式譲渡では売主）が合理的に確認できる範囲、譲渡企業の認識に関する条件や留保、重要性、期間、例外を取引リスクに応じて設計する。

完全性・再現性の表明

資料共有室へ出した施設別管理台帳の完全性、稼働中の／期限切れ区分、空間内の基準点と表示内容の対応、重要な未記録施設、移管に必要な認証情報・文書、直近試験の正確性を扱う。将来の基盤サービス性能を保証させるのではなく、過去事実と開示資料、既知の失敗、譲渡企業支配下の移管行為を区別する。

契約・顧客の表明

重要契約の有効性、譲渡・承継／支配権の変更、データ利用・再委託・国外処理、終了時返却・削除、顧客からの違反通知、競合制限、口頭例外を確認する。全顧客の同意取得を一文で表明させるより、同意不要・通知・同意・未確認の添付明細を取引完了の前提条件と結ぶ。

事故・請求・削除の表明

許可されていない取得、施設秘密の持出し、個人データ事故、空間内の基準点誤表示、顧客苦情、削除要求、規制当局照会、保険請求、基盤サービス一時停止を対象期間と重要性で開示する。既知問題には一般補償だけでなく、是正手順、費用上限、顧客対応、特別補償を検討する。

クロージング条件と価格留保

価値の前提が取引完了前に確認できるなら、単なる取引完了後の義務ではなく条件又は支払いの仕組みへ置く。重要顧客同意、クラウドのプロジェクト移行承認、買い手アカウントでの代表施設試験、管理者移管、TSA締結、認証鍵の更新計画、データ分離完了を候補にする。全てを条件にすると取引確実性を下げるため、重大度と代替策で選ぶ。

客観的な完了基準

「合理的に満足する形で移管」だけでは争いになりやすい。対象施設、端末、ビルド、試行数、成功率、位置許容、表示内容一致、記録、顧客承認、第三者確認を添付明細へ置く。基盤サービス障害による停止、施設閉鎖、顧客遅延等、当事者支配外の事象と最終期限を定める。

代金の一部留保と業績などに応じた追加対価

移管可能性が高いが取引完了前に全試験できない場合、施設又は顧客別の代金の一部留保を設け、移管の成功・同意取得・契約更新に応じて留保代金を支払う方法がある。業績などに応じた追加対価を売上だけにすると買い手の統合判断と譲渡企業報酬が衝突するため、操作可能性、会計方針、顧客配分、基盤サービス変更、費用、情報権、紛争手続を明確にする。

価格の減額と特別補償

承継不能施設は将来キャッシュフローから除外し、既知の過去違反・顧客請求・データ整理・削除は特別補償又は第三者への預託を検討する。同じリスクを買収価格と補償で二重回収しないよう、企業価値評価調整表と請求添付明細を照合する。税務・会計上の扱いは専門家へ確認する。

TSAと顧客再同意の実務

カーブアウト又は親会社共有基盤では、取引完了日に全システムを分離できないことがある。移行期間の業務支援契約（TSA）には、単に「IT支援」と書かず、対象プロジェクト、分離された利用領域、API、鍵管理、監視、事故、バックアップ、サポート、本人からの権利行使の請求、顧客通知、サービス水準、費用、終了・移行、削除を記載する。譲渡企業が顧客データへアクセスし続ける法的・契約的根拠も確認する。

再同意が必要かを顧客別に判断する

全顧客へ同じ同意依頼を送ると、不要な摩擦又は誤解を生む。契約譲渡・承継、支配権の変更、個人情報の保護目的、処理の再委託先、国外処理、施設規則を別々に判定し、「同意」「通知」「説明」「不要」「専門家確認」に分ける。顧客の一つの署名で全論点を処理できるとは限らない。

顧客説明資料を技術実装と一致させる

説明資料には、買い手、目的、保存先、基盤サービス、再委託、移行期間、安全対策、問い合わせ、削除、サービス停止の有無を平易に示す。契約で許された範囲より広い将来利用を営業資料へ書かず、技術担当チームのデータの流れ、契約の添付明細、サポート FAQを同じバージョンで管理する。承認済み文面と送信証拠を施設別管理台帳へ戻す。

TSA終了を先に設計する

開始条件より移行支援の終了条件が重要である。買い手プロジェクトで代表施設が成功し、全顧客の必要手続、記録・バックアップ移行、旧認証情報無効化、譲渡企業複製削除・保持例外、監査報告、未解決対応記録引継ぎが完了した状態を定義する。延長費を上げるだけでなく、譲渡企業協力不足、顧客遅延、基盤サービス制約の責任分担を決める。

取引完了初日に止めないもの・止めるもの

取引完了初日の目的は、全基盤サービスを即日統合することではなく、顧客サービス、データ保護、権限、事故対応を安定させることにある。現状維持が安全な機能と、旧管理責任者アクセスや無許可のデータ複製のように直ちに止める機能を分ける。変更の一時停止、例外承認、緊急連絡網、顧客対応の上位者への報告を取引完了前に承認する。

止めずに監視するもの

本番空間内の基準点位置の照合、TTL更新、顧客専用プロジェクト、重要な表示内容配信、サポート、監視は、依存を理解するまで無理に統合しない。譲渡企業管理者を即時全削除してサービスを止めるのではなく、買い手管理責任者追加、MFA、接続状況の確認、権限の縮小、複数人による承認を行い、切り替え日まで監視する。契約上譲渡企業アクセスを継続できるかも確認する。

直ちに止める候補

共有パスワード、退職者アカウント、個人クラウド、承認のない未加工の画像送信、契約終了顧客データの新規学習、不要な別の顧客領域へのアクセス、公開クラウドの保存領域、期限切れ証明書の回避設定は緊急度を評価する。ただし停止が顧客安全又は契約SLAへ与える影響を確認し、元の状態への復元と連絡を準備する。

引継ぎ初日の管理表

管理責任者、管理者、緊急時の特別アクセス、事故責任者、個人情報の保護責任者、基盤サービス連絡先、顧客連絡先、24時間監視、バックアップ、料金の請求、利用枠、鍵、空間内の基準点の重大な照合失敗の判断者を一枚にする。未完了移行とTSA依存を赤字にするのではなく、期限、対応の開始条件、代替、承認者を記載する。最初の営業日に代表施設の模擬試験又は現地試験を実施し、取引完了前比較の基準値と比べる。

100日PMIで再現性を標準化する

買収後統合の一般的な相談入口はVR M&A総合センターを参照し、本稿では空間データの再現性に限定する。100日で全施設を一つの基盤サービスへ移すことを成功指標にせず、台帳、権限、試験、更新、削除、顧客例外を買い手の標準管理へ載せる。高リスク施設から段階的に統合し、測定値が悪化したら止める。

0～30日

拠点台帳と管理対象の一覧をいったん固定して照合し、管理責任者のアカウント、鍵、請求、利用上限、有効期間、顧客ごとの例外を確定する。重要拠点の照合性能の基準値、有効期限切れ・参照先を失った空間基準点、未契約・契約書の欠損、元データの保存、退職者のアクセスを優先して調査する。新たな二次利用と大規模な基盤変更は、原則として変更審査の会議にかける。

31～60日

顧客ごとの通知・同意取得、鍵の更新、役割に応じたアクセス管理、監視、有効期間を管理する処理、削除の手順、基盤移行の試行を実施する。工場、店舗、住宅などの用途ごとに、成功の基準、位置誤差の許容範囲、代替手段を定め、問い合わせ記録へ試験番号を付ける。譲渡企業の熟練者から、データ取得、空間基準点の再登録、問題の切り分けと解決の手順を記録する。

61～100日

試行結果に基づいて段階的な移行計画を更新し、移行支援契約の終了、旧プロジェクト・鍵・複製データの削除、顧客の受入確認、継続費用を確認する。取締役会への報告には、稼働拠点、契約確認が済んだ割合、照合に関するサービス品質保証、参照先を失った基準点、移行の進捗、事故、顧客の解約、残る責任を載せる。100日経過時に残る例外には担当者と目標日を付け、通常のリスク管理台帳へ移す。

譲渡企業の準備チェックリスト

譲渡企業は「独自の空間認識技術」を抽象的に説明するより、買い手が一つの施設を再現できる証拠を先に整える。未整理データを急いで一つのフォルダーへ複製すると、顧客混在、重複、契約違反、日時の記録消失を招く。既存システムを保全し、索引と読み取り専用証拠を作る。

契約・権限

• 全顧客・施設を売上台帳と突合し、契約、SOW、DPA、撮影許諾、支配権の変更、譲渡・承継、終了時削除を施設別管理台帳へ記載する。
• 元データ、メッシュ、空間内の基準点、意味情報、統計、モデルについて、取得・保存・加工・学習・第三者処理・譲渡・削除の権限を分ける。
• 口頭例外、PoC、無償導入、共同研究、顧客ひな型、他社ブランドでの提供を標準契約へ混ぜず一覧化する。
• 個人情報、秘密、限定提供データの社内分類を根拠・保護措置・専門家確認状況とともに示す。

技術・運用

• 空間基準点の台帳に、利用基盤、プロジェクト、有効期間、最後に照合した日時、ビルド、端末、管理責任者、コンテンツとの対応関係、事故を追加する。
• システム構成、データの流れ、認証情報、クラウドの階層構造、請求、利用上限、配信ストア、名前解決の設定、開発・配信基盤を依存関係図にする。
• 代表施設の初期状態からの起動試験を別アカウント・別端末で実施し、手順、記録、失敗、復旧時間を保存する。
• 期限切れ、対応先のないデータ、契約終了、削除要求、改装施設を隠さず、是正計画と費用を提示する。

取引準備

• 株式譲渡、事業譲渡、事業の切り出しごとに移管対象と譲渡企業残存データを表にする。
• 重要顧客へ連絡できる時期、説明者、必要同意、競合買い手制限を取引担当チームで決める。
• 移行支援契約の対象、期間、サービス水準、費用、譲渡企業のアクセス権限、終了を確認する証拠について、取引完了前に案を作る。
• 生成画像や実演用の架空施設を実顧客データと明確に分離し、販売促進資料の権利表現を修正する。

買い手の検証チェックリスト

買い手は資料の存在確認だけでなく、相互照合と再演を行う。抽出した契約、施設別管理台帳、クラウド管理台帳、空間内の基準点書き出し、利用記録、請求書を共通IDで照合して結合し、母集団と抽出事例が母集団をどこまで覆うかを確認する。譲渡企業の本番環境を不用意に変更せず、読み取り専用、情報を隔離して扱う環境、専門家を使う。

最初の十問

1. 売上を生む施設はいくつあり、各施設の稼働中の空間内の基準点と直近成功日はいつか。
2. 元データ、加工後のデータ、空間基準点、意味情報、コンテンツ、操作記録はどこにあり、誰が管理責任者・管理者か。
3. 顧客契約は買い手への承継、同目的利用、再委託、国外処理、終了時処理をどう定めるか。
4. 利用基盤上で、データの書き出し、プロジェクトの移行、鍵の更新、削除、有効期間の更新を実行できるか。
5. 別端末・別アカウントで代表施設を再現した結果はどうか。
6. 改装、利用許可拒否、通信できない状態、期限切れ空間内の基準点時の代替動作は顧客業務を維持できるか。
7. 創業者又は特定技術者だけが知る取得・復旧手順は何か。
8. 個人情報、施設秘密、限定提供データの分類と保護に未解決点はあるか。
9. 取引完了後12か月の再計測、同意、移行、利用枠、サポート費はいくらか。
10. 承継不能ならどの売上・顧客・機能を失い、代替に何日かかるか。

専門家へ上げる対応の開始条件

住宅・医療・教育の未加工データの取得、従業員移動経路、顧客の競争上重要な施設、国外クラウド、無契約施設、データ再利用、モデルの学習、重要顧客同意、基盤サービス移管不能、重大誤表示、事故・当局照会があれば、個人情報の保護、契約、知財、情報セキュリティ、労働安全等の適切な専門家へ範囲を定めて相談する。専門家意見の前提と未確認事項を企業価値評価前提へ戻す。

よくある質問

Q1. 株式譲渡なら顧客の同意もデータ移管も不要ですか。

一律にはいえない。対象法人が同じでも、契約の支配権の変更、競合買い手、グループアクセス、処理の再委託先、国外処理、親会社クラウド、管理者・料金の請求変更が関係する。契約、データの流れ、買収後計画を顧客別に確認する。事業譲渡なら契約・データ・アカウントを個別に移す論点が増える。

Q2. Cloud Anchor IDの一覧を受け取れば十分ですか。

十分とは限らない。IDのTTL、プロジェクト、権限の許可、周辺特徴、現場変化、表示内容・設備との対応表、顧客権限、解決実績が必要になる。買い手環境で代表施設で位置を照合し、意味の正しい表示内容が許容位置へ表示されるところまで試す。

Q3. 施設を再撮影すれば権利問題も直りますか。

再撮影で技術品質を改善できても、撮影許諾、人物・秘密の映り込み、保存、再利用、国外処理、顧客業務停止の問題は別である。新たな取得は新たなデータ処理になり得るため、契約・通知・安全・入館・費用を確認する。

Q4. 点群やメッシュは譲渡企業の著作物ですか。

データの種類、創作性、契約、作成過程、法域により判断が変わり、一律に断定できない。著作権、営業秘密、限定提供データ、契約上の利用権、技術的なアクセス権限を分ける。M&Aでは「所有」とだけ書かず、買い手が必要な行為をできる根拠を確認する。

Q5. Apple Vision Proの周辺環境の認識利用許可があれば全ての環境データを取得できますか。

利用許可は必要条件になり得るが、全データの無制限取得を意味しない。API、提供者、Full Space、端末・OS、利用者の拒否・取消し、基盤サービス設計の制約がある。周辺空間内の位置追跡と周辺環境の認識も公式資料上区別されるため、実装機能ごとに調べる。

Q6. 登録空間内の基準点数をKPIとして買収価格へ使えますか。

補助指標にはなるが、そのまま価値ではない。契約継続、権限、TTL、直近位置の照合、位置精度、表示内容対応、改装、顧客利用、移管成功、更新費を反映する。期限切れ又は対応先のないデータを除き、施設別将来粗利へ成功確率を掛ける方が説明しやすい。

Q7. 基盤サービスの個人情報の保護説明を転載すれば自社の説明も十分ですか。

基盤サービスが処理するデータの説明は重要だが、自社アプリが追加で保存・送信・分析・学習するデータ、顧客契約、処理の受託者、保持を説明する責任は別に残る。実際のネットワーク・保存領域と通知・配信ストア申告を照合する。

Q8. noindexを付ければ既存記事との重複を解決できますか。

noindexは重複した低価値本文を作る免許ではない。本稿は既存の空間コンピューティング能力、3D IP、一般安全対策を繰り返さず、空間内の基準点来歴、契約動詞、プロジェクト移管、現地再現、評価式へ範囲を限定している。公開前に既存記事と表現・見出し・検索意図を再監査する。

参考資料・相談先・免責

以下は2026年8月22日に確認した一次・公式資料である。基盤サービスの仕様・URL・更新日は変わり得るため、案件の署名日、クロージング日、アプリ公開・配信日に最新版と契約条件を再確認する。引用ではなく、記事の判断根拠と検証入口として利用する。

基盤サービス・クラウドの公式資料

• Apple開発者向け資料：ARKitデータへのアクセス設定 — 周辺環境の認識、利用許可、Full Space、拒否・取消し。
• Apple開発者向け資料：現実空間の特定地点を追跡する方法 — 空間内の固定基準点の利用セッション間追跡。
• Apple開発者向け資料：室内追跡を使った、その場所に応じた体験の構築 — 部屋の追跡と周辺環境の認識。
• Google開発者向け資料：クラウドアンカー — 登録、三次元特徴マップ、固有ID、位置の照合。
• Google開発者向け資料：ARCoreのセッション — Cloud Anchor TTLと認証別上限。
• Google開発者向け資料：Google CloudでARCore APIを使用する方法 — プロジェクト、鍵を使わない認可、サービスアカウント。
• Google開発者向け資料：iOS向けARCoreアプリのプライバシーに関する質問 — 端末、位置、映像、Cloud Anchor データの処理。
• Google開発者向け資料：利用者のプライバシー要件 — アプリ内のARCore、Cloud Anchors、Geospatial 通知。
• Google Cloud：組織間でのプロジェクト移行 — プロジェクトの移行で維持・変更される事項。
• Meta Horizon OS開発者向け資料：周囲を映すカメラのAPI概要 — Quest 3／3S、RGBカメラ、機械学習・画像認識、権限。

日本の公的資料

• 個人情報保護委員会: 個人情報保護法ガイドライン（通則編） — 個人情報、個人関連情報、利用目的、事業承継。
• 経済産業省: 営業秘密管理指針 — 秘密管理性、有用性、非公知性。
• 経済産業省: 限定提供データと利活用 — 制度の公式入口と法定要件。
• 経済産業省: 限定提供データに関する指針 — 要件と具体的な考え方。
• 経済産業省: AI・データの利用に関する契約ガイドライン 1.1版データ編 — データ契約の設計。

相談と免責

空間データM&Aの相談では、最初に全データを送るのではなく、取引構造、対象事業、顧客・施設類型、基盤サービス、施設数、データの区分、予定日、主要な未確認点を整理すると、法務、個人情報の保護、技術、クラウド、財務の調査範囲を定めやすい。地域案件や顧客運用の承継全体は地域XR事業承継の契約・端末・運用実務、一般的な売却準備はVR会社の売却準備完全ガイドも参照できる。

本稿は一般的な情報提供であり、個別案件の法的意見、個人情報該当性、知的財産権又は営業秘密の鑑定、基盤サービスによる移管保証、企業価値算定、会計・税務・投資助言ではない。実際の契約、データ、システム、現場、法域、最新版の公式文書を確認し、必要に応じて弁護士、公認会計士、税理士、個人情報の保護・情報セキュリティ・クラウド・XR技術の専門家へ相談する。