XR 生体データ M&A｜視線・顔・手・感情推定を承継するデューデリジェンス

1．XR 生体データ M&Aを七層へ分解する

層1と層2：センサー能力と生の測定値

層1は端末が備えるカメラ、赤外線、深度、マイク、慣性、心拍等のセンサー能力です。層2は時刻付きの視線方向、瞳孔径、画像、関節座標、音声波形、姿勢等の生データです。端末にセンサーがあっても、OSがアプリへ値を公開するとは限りません。さらに、アプリが一時メモリで処理することと、サーバーへ保存することは違います。買収前の詳細調査（DD）の資産表では「測れる」「アプリなどの接続仕様（API）で取得できる」「実際に取得した」「保存した」を別列にします。

層3と層4：特徴量と識別テンプレート

層3は瞬き頻度、注視時間、手の速度、声の韻律、歩行周期等、原データから計算した特徴量です。層4は、顔や虹彩等から本人認証又は識別を可能・確認するための数学的表現です。同じ目由来でも、UIの選択方向と個人を認証する虹彩テンプレートでは目的、取得経路、保存場所、侵害時の影響が異なります。不可逆変換という説明だけで匿名とは判断せず、他情報との照合、再識別、テンプレート照合の可否を試します。

層5と層6：推論と顧客向け判断

層5は、集中、感情、意図、疲労、身体状態、適性、リスク等の推論です。層6は推論を使った「休憩を促す」「研修評価を下げる」「広告を変える」「本人確認を通す」などの判断又は介入です。推論値だけを見ても事業上の影響は分かりません。誰に、どの場面で、どの閾値で、何を決めるかを確認します。誤推論が表示上の参考に留まる場合と、雇用・教育機会を左右する場合ではリスクが大きく違います。

層7：集計値、訓練データ、モデル重み

層7には、店舗別の匿名集計、ラベル付き訓練集合、特徴量ストア、学習済みモデル、評価レポートを置きます。集計すれば常に非個人データになるわけではなく、少人数セルや希少属性は再識別につながり得ます。モデル重みも原データと同じではありませんが、学習データの権利、削除要求をどう反映するか、会員推論や再現リスクがないかを別途評価します。七層の関係を保持したまま、保存先と責任者を結びます。

2．信号名ではなく用途を含む分類表を作る

視線は一種類ではない

一フレームの視線の方向ベクトル、オブジェクトへの注視イベント、セッション別ヒートマップ、会員IDへ結び付いた履歴では、識別可能性と用途が変わります。UI操作に必要な瞬時入力を保持せず破棄する実装と、広告最適化のため長期保存する実装を同じ「視線データ」と数えません。瞳孔や微細運動から状態を推論する場合、照度、端末ずれ、眼鏡、障害等の交絡要因もモデル品質へ入れます。

顔と虹彩は認証用か表現用かを分ける

アバター表情を動かす係数、カメラ画像、顔特徴ベクトル、端末内認証結果は別のデータです。本人を一意に識別又は確認する目的の技術処理か、単に表情を描画する一時信号かを確認します。「顔を使うから顔認証」「画像を保存しないから個人データではない」という両極端を避け、処理目的、出力、他データとの結合をテストします。

手・姿勢・歩容は再識別可能性を評価する

手の骨格や身体姿勢は操作のために短時間使われることが多い一方、長い時系列、身体寸法、歩き方、端末IDと結合すれば個人を区別できる場合があります。法律上の分類は法域と処理目的により判断しますが、技術買収前の詳細調査（DD）では再識別試験を別に行えます。個人ラベルを外した後に、同一人物のセッションをどの精度で結べるか、少数属性が残らないかを検証します。

声は内容、話者、韻律を三分する

音声波形には発言内容だけでなく、周囲の第三者音声、話者の特徴、感情等に使われる韻律が含まれます。文字起こし後に音声を削除しても、発言内容が個人を特定する場合があります。話者認証モデル、感情推定モデル、会話分析モデルは同じ録音から作れても目的が違います。録音開始表示、同席者の扱い、保持、外部音声サービスの接続仕様（API）、学習利用を分離します。

3．取得項目より先に目的と決定を特定する

操作入力

視線でボタンを選ぶ、手で物体を動かす、声でメニューを開く処理は、体験提供のための入力です。必要な時間だけ端末内で処理し、対象会社が個人別履歴を取得しない設計なら、長期データ資産とは評価できません。一方、その最小化設計自体は、規制・信頼・導入審査を通りやすくする能力として価値を持ち得ます。データを持たないことを弱みと決めつけません。

本人確認・一対一照合

登録者本人との一致を確認する照合又は本人認証と、多数の候補から人物を探す識別を分けます。比較対象の数、テンプレートの保存主体、端末外送信、失敗時の代替手段を確認します。端末OSが認証し、アプリへ成功・失敗だけを返す場合、対象会社はテンプレートを保有しません。認証機能を販売することと、生体データベースを所有することは別です。

属性分類と感情・意図推定

年齢帯等の属性を推定する生体情報による属性の分類と、感情・意図を推定する感情認識は、AI法上の定義と義務を区別して調べます。単に笑顔らしい表情を検出する処理と、その表情から喜びや購買意図を推論する処理も同じではありません。営業資料、UI表示、モデル名、ラベル定義、顧客設定を照合し、開発者が「参考スコア」と呼ぶだけで実質用途を軽く扱いません。

健康・安全・業績の決定

瞳孔、姿勢、声、心拍から疲労、痛み、疾患可能性等を推論すれば、健康データの論点が生じ得ます。従業員の訓練点、採用、配置、休憩指示に使う場合は、推論の種類だけでなく決定への影響を確認します。「安全目的」という表示があっても、実際には生産性や勤務評価へ使うなら、その実装と顧客運用を基準に調べます。精度が低いことは、誤判断と差別のリスクをむしろ高める場合があります。

4．端末が測れるものと対象会社が取得できるものを分ける

Vision Proの視線入力を譲渡企業の資産と数えない

Appleの「視線、手、およびプライバシー」は、Vision Proでユーザーが見ている項目に関する視線入力がアプリ、ウェブサイト、Appleへ共有されない旨を説明しています。したがって、譲渡企業がvisionOSアプリを持つだけで、OS内部の詳細視線が訓練データとして蓄積されているとは評価できません。アプリが受け取る選択イベント、独自センサー、研究用構成等があるなら、その取得経路を実機で別途確認します。

手の構造・動きは権限と取消しを確認する

同じApple公式説明では、アプリが手の構造や動きへアクセスする場合に利用者の許可が必要とされています。買収前の詳細調査（DD）では、権限要求の文言、拒否時の機能、OS設定からの取消し、バックグラウンド取得、保存項目を確認します。開発版では取得できてもストア配布版では権限が違う場合があるため、署名済み本番ビルド、対象OS版、端末型番の組合せで試します。

Optic IDは認証結果と虹彩表現を分ける

AppleのOptic IDの説明では、虹彩の数学的表現は端末内の保護領域（Secure Enclave）で保護され、アプリは認証の成功又は失敗を受け取る構造が示されています。対象会社がOptic IDログインを実装していても、その事実から虹彩テンプレートを保有すると推定できません。資産表には、対象会社が持つ会員ID、認証結果、失敗履歴と、端末側に留まるテンプレートを分けて記載します。

仕様書とネットワーク観測を突き合わせる

端末仕様は更新されるため、資料レビューだけで完了しません。権限を許可・拒否・取消しした複数状態で、アプリログ、ローカル保存、通信先、アプリなどの接続仕様（API）レスポンスを観測します。端末、OS、ソフトウェア開発キット（SDK）、アプリ版ごとの取得項目を表にし、サーバースキーマと件数へ一致させます。署名からクロージングまでにソフトウェア開発キット（SDK）が変わるなら再試験を前提条件又は誓約へ入れます。

5．端末からモデルまでのデータフローを一行ずつ再現する

収集点と変換点を同時に描く

図には、センサー、OS、アプリ、端末内ソフトウェア開発キット（SDK）、顧客サーバー、対象会社クラウド、外部分析、学習環境、バックアップ、顧客画面を置きます。矢印ごとに項目、暗号化、頻度、国、送信者、受信者、法的役割を付けます。特徴量化、仮名化、集計、ラベル付け、モデル推論の場所も示します。保存されない一時処理を永続DBと同じ線にせず、メモリ消去の実装とクラッシュログへの残存を確認します。

データ辞書を実サンプルで検証する

列名がgaze_scoreでも、中身が方向ベクトル、注視時間、注意推定のいずれかは分かりません。スキーマ定義、単位、座標系、欠損、精度、端末時刻、ユーザーIDをサンプルへ照合します。自由記述、デバッグログ、ファイル名に氏名や健康情報が混ざる場合もあります。各列に七層、目的、保存期限、法域分類、学習利用、削除キーを付け、説明できない列を隔離します。

顧客ごとの設定差を出す

B2B XRでは、同じ製品でも顧客が保存、分析、従業員評価を設定できる場合があります。標準設定だけでなく、顧客テナント別のオプション、カスタムモデル、エクスポート、管理者権限を確認します。対象会社が処理の受託者、顧客がデータ処理の目的と手段を決める管理者となる構成と、対象会社が自社学習へ二次利用する構成を分けます。契約書上の役割と実データフローが一致しなければ是正費を計上します。

バックアップと派生物まで削除経路を引く

本番DBから削除しても、分析基盤、特徴量ストア、ノートブック、評価用CSV、アノテーション会社、ログ、バックアップ、モデルスナップショットに残る場合があります。削除要求がどのIDで各系統へ伝播し、いつ完了するかを実測します。バックアップの上書き周期や法定保存を理由に即時消去できない場合は、復元時の再削除、利用停止、保持期間を文書化します。

6．日本法では個人情報・個人識別符号・個人関連情報を別判定する

視線の生データを名称だけで個人識別符号と断定しない

個人情報保護委員会の通則編とQ&Aを基礎に、まず生存する個人に関する情報か、特定の個人を識別できるか、他の情報と容易に照合できるかを確認します。顔や虹彩等の身体特徴をコンピュータ利用のため変換し、本人を認証できる水準にした符号の論点と、単なる一時的な視線方向を同一に扱いません。ただし「生データ」という名称でも、会員IDや端末履歴へ結合されれば個人情報になり得ます。

本人認証できるようにした水準を試す

Q&Aが示す考え方を案件へ適用するには、生成方法、照合対象、精度、目的、運用を調べます。譲渡企業が「認証には使っていない」と答えても、実際に本人認証できるよう設計された特徴符号なら、目的名だけで分類は消えません。逆に目や手由来の全座標を自動的に個人識別符号と決めません。法的評価と並行して、同一人物照合の技術試験を行い、判断根拠を保存します。

個人関連情報と提供先での照合を確認する

対象会社側では個人を特定できない端末ID別の注視履歴でも、顧客が従業員名簿や会員情報と結合できる場合があります。提供元と提供先のデータ保持状況、照合予定、同意確認、提供記録を調べます。「当社のDBに氏名がない」ことだけで提供規制を除外しません。ソフトウェア開発キット（SDK）、解析会社、広告会社への送信も、項目と送信先をネットワーク観測で確かめます。

要配慮性は推論内容も含め専門家が判断する

目、声、姿勢から健康や障害等に関する情報を取得・推論する場合、単なる操作ログとは別の検討が必要です。推論が誤っている、確率表示である、研究用であるという説明だけで影響は消えません。ラベルの由来、本人への説明、取得根拠、第三者提供、医療・雇用上の利用を確認します。法的分類を本稿だけで確定せず、具体的な項目と運用を国内専門家へ示して判断します。

7．利用目的と事業承継を同じ表で確認する

事業承継は無制限な目的変更ではない

個人情報保護法の通則編は、合併その他の事由による事業承継に伴って個人情報を取得した場合の利用について、承継前の利用目的達成に必要な範囲との関係を示しています。株式譲渡では法人自体が同じ場合もありますが、買い手グループによる新しい学習、広告、従業員評価、他製品統合が当然に旧目的へ含まれるとは限りません。取引形態だけでなく、主体、目的、提供、共同利用を確認します。

目的を抽象語から処理単位へほどく

「サービス向上」「研究開発」「安全管理」という広い文言だけでは、視線時系列を学習へ使うこと、感情推定を雇用評価へ返すこと、顔特徴を別製品の認証へ使うことまで説明されているか判断できません。取得項目、推論、対象者、顧客、意思決定、保持、第三者、国外、学習を目的マトリクスにします。通知の表示場所、版、言語、同意操作と実装を対応させます。

取得時点の版を復元する

現在のプライバシーポリシーが整っていても、三年前に集めた訓練データへ遡って適用できるとは限りません。各レコード又は取得群に、取得日、アプリ版、ポリシー版、同意文、国、年齢区分、顧客契約を結びます。版履歴がない場合は、リリース記録、ウェブアーカイブ、ストア提出、顧客メール、同意ログから再構成し、確証のない範囲を価値計算から分けます。

新目的は再同意だけで解決するとは限らない

再同意を検討する場合、対象者へ連絡できるか、拒否してもサービスを使えるか、撤回を反映できるか、従業員等に自由な選択があるかを確認します。連絡不能な過去ユーザーや退職者のデータは、再同意率を100％と置けません。目的変更が許されない又は実務上同意を得られないなら、データ除外、集計化、モデル再学習、製品機能停止を価格へ反映します。

8．M&A開示そのものをデータ最小化する

初期段階は集計と証憑で足りる

買い手が価値を評価するために、いきなり生の視線、顔、音声を受け取る必要はありません。初期段階では、データセット別の件数、法域、目的、同意版、保持、品質、削除要求、モデル性能を集計し、ポリシー、契約、画面、監査結果で裏付けます。サンプルが必要なら、合成、強い匿名化、管理された閲覧環境を検討します。営業目的のデータルームへ原データを大量コピーしません。

クリーンチームの目的を限定する

競合買い手が顧客別・従業員別データを見ると、個人情報だけでなく競争上の問題が生じます。独立アドバイザー又は限定担当者が原資料を検証し、取引判断に必要な集計だけを投資チームへ返す構造を設計します。閲覧項目、持出し、画面撮影、ダウンロード、再提供、保管、破談時削除、当局・本人要求への対応を秘密保持契約より具体化します。

サンプルの代表性と戻し攻撃を調べる

匿名とされたデータでも、希少な動き、時刻、店舗、端末、会員属性を組み合わせれば人物が推測される場合があります。小さなサンプルに顔や声を含める必要性を問い、削除、粗粒度化、ノイズ、少人数セル抑制を検討します。同時に、加工しすぎたサンプルではモデル価値を検証できないため、クリーン環境内で原データ品質を確認し、外へは結果だけを出す方法を使います。

破談と競合売却の削除を実証する

契約に削除義務があっても、買い手の端末、レビュー資料、メール、外部専門家、バックアップへ複製されれば実行困難です。データルームのアクセス停止、エクスポート台帳、派生分析の返却又は破棄、法令上保持する一部の隔離を定め、責任者が削除証明を出します。複数候補へ開示する売却では、候補別の透かしと監査ログを用い、不要になったアクセスを順次閉じます。

9．EU一般データ保護規則（GDPR）の生体データは技術処理と目的を読んで判定する

第4条(14)の三要素を確認する

一般データ保護規則の第4条第14号は、身体的・生理的・行動的な特徴に関する特定の技術的処理から生じ、個人を一意に識別できる、またはその識別を確認できる個人データを、生体データと定義します。目、顔、声、歩き方という信号の名称だけで結論を出さず、特定の技術的処理があり、一意な識別が可能か、または確認されるかを調べます。通常の個人データに当たるかと、第9条に基づく取扱いも、別の段階で確認します。

第9条は一意識別目的との関係を読む

第9条は、自然人を一意に識別する目的の生体データを、特別な種類の個人データの一つとして扱います。同じ手の座標でも、操作入力として短時間使う処理と、本人識別用テンプレートを生成して照合する処理では位置付けが異なり得ます。一方、特別な種類の個人データに当たらないから自由に使えるわけではなく、個人データなら処理根拠、透明性、目的限定、最小化、保持、権利、安全性等を検討します。

データ処理の目的と手段を決める管理者と処理の受託者をテナント別に判定する

XRベンダーが顧客の指示どおり研修ログを処理する部分と、自社モデル改善の目的・手段を決める部分で役割が変わる場合があります。契約の名称だけでなく、誰が取得項目、保持、推論、学習、対象者への通知、削除を決めるかを確認します。顧客ごとにカスタム目的があれば役割表も分け、処理の受託者契約、共同管理、処理の再委託先一覧を実装へ合わせます。

買収後の統合は新しい処理になり得る

対象会社DBと買い手の会員、広告、従業員、人事DBを結合すれば、識別可能性と目的が変わります。法人株式を取得しても、データ処理の目的と手段を別に決める管理者である親会社へ原データを自由に移せるとは限りません。統合前に目的、処理根拠、通知、データ保護影響評価（DPIA）、契約、移転、アクセスを見直します。価値モデルは「統合できる前提」ではなく、独立運用、限定集計、再同意、利用停止の複数案で計算します。

10．健康推論と特別な保護を要するデータの区分を別レイヤーで扱う

入力が一般データでも出力が健康情報になり得る

瞳孔、声、姿勢、歩行、心拍等の入力が、すべて一意識別用生体データとは限りません。しかし、そこから疾患、障害、精神・身体状態等を推論する出力は、健康データとして別の検討が必要になり得ます。買収前の詳細調査（DD）では入力列だけでなく、モデルラベル、営業名称、画面表示、アプリなどの接続仕様（API）出力、顧客の意思決定を調べます。health（健康）という列名がなくても、「休職リスク」「異常傾向」等の実質を見ます。

低精度は分類や責任を自動的に消さない

研究段階又は参考値で精度が低いから規制対象外、という説明は危険です。不正確な健康推論でも本人へ不利益を与え、説明と訂正が難しくなることがあります。ラベルの正解データ、母集団、交絡、校正、偽陽性・偽陰性、群別性能、更新履歴を確認します。製品の主張と検証水準が合わない場合は、表示変更、利用制限、再評価、機能停止の費用を見積もります。

研究同意と商用利用を分ける

大学、医療機関、実証参加者から研究目的で集めたデータが、買収後の商用モデルへ自由に使えるとは限りません。倫理審査、研究計画、同意文、共同研究契約、データ利用契約、成果IP、公開条件、撤回を確認します。論文公開済みであることと、個票データの商用再利用許諾があることは違います。研究集合を価値へ入れるときは、用途と主体を明記します。

医療主張を避けても雇用影響は残る

譲渡企業が「診断ではない」と記載しても、顧客が従業員の配置、休憩、評価、採用へ使う場合、本人への影響は残ります。意図した目的と合理的に予見できる誤使用を把握し、契約禁止、UI制限、監査、教育、ログを設計します。買収後に販売拡大するほど誤使用の件数も増え得るため、売上計画とコンプライアンス要員を同じシナリオで評価します。

11．EUのAI法では、識別・認証・分類・感情の推定を混同しない

生体情報による人物の識別の対象信号は広い

AI法は生体データに関する説明で、顔、眼球運動、身体形状、声、韻律、歩容、姿勢、心拍等を例示しています。しかし、例示された信号を扱うすべてのXR機能が同じ禁止又は義務へ直結するわけではありません。処理が何を識別・確認・分類・推論するか、遠隔か、リアルタイムか、誰がどの場面で展開するかを法令本文の定義と条項へ対応させます。

本人との一致の確認と人物の識別を分ける

本人が主張する身元を一対一で照合する認証又は本人確認と、不特定又は多数の候補から人物を特定する識別を区別します。ログイン機能を「生体認証」と一括表示すると、投資委員会が遠隔識別の論点と混同します。候補集合、比較方法、保存主体、端末内処理、遠隔性、目的をフローへ記載し、対象条項をEU専門家が確認します。

生体情報による属性の分類をラベル単位で確認する

身体的、生理的又は行動的特徴から一定のカテゴリーへ割り当てる機能について、どのラベルを出し、誰に見せ、何に使うかを調べます。開発コードのclassifyという関数名だけでは法的分類になりません。逆に製品資料が「パーソナライズ」と呼んでも、実装が人を属性群へ分類していれば検討が必要です。センシティブな属性、推定根拠、顧客設定、透明性を確認します。

感情認識は感情又は意図の推論を中心に見る

EUのAI法上の感情認識は、生体データに基づいて自然人の感情又は意図を識別・推論するシステムです。前文では、単なる表情・ジェスチャーの検出と、痛み又は疲労等の身体状態を区別して説明しています。これらの区別は「規制なし」を意味するのではなく、適用条項を正しく特定するためのものです。出力ラベル、学習ラベル、営業文言、利用場面を一緒に確認します。

12．職場・教育XRの感情推定は用途を実装まで追う

禁止行為の対象を営業名ではなく実質で調べる

EUのAI法第5条には、職場と教育機関で人の感情を推論するAIシステムについて、限定的な例外を伴う禁止規定があります。研修用XRが「エンゲージメント」「集中」「適性」「ストレス」などの名称を使う場合、モデルが何を推論し、結果が講師、人事、学校へどう返るかを確認します。「研修支援ツール」という製品区分だけでは判断できません。

医療又は安全性の例外を宣伝文句で広げない

法令の限定例外に関係する可能性があっても、営業資料に「安全のため」と追記すれば足りるわけではありません。意図した目的、必要性、代替手段、実装、利用環境、顧客契約を専門家が確認します。生産性評価を安全監視と呼び替える、任意研修を雇用判断へ転用する、疲労を感情ラベルとして出す等のずれをレッドフラッグにします。

顧客設定と実利用をサンプル調査する

標準製品が禁止用途を想定していなくても、顧客がCSVを人事システムへ取り込み、個人スコアを査定へ使う場合があります。上位顧客だけでなく、業種、国、利用目的の異なる契約と管理画面を抽出し、エクスポート、アプリなどの接続仕様（API）、説明資料、サポート記録を確認します。合理的に予見できる利用を把握し、設定削除、契約制限、顧客移行、売上減少を評価します。

買収後のクロスセル前に用途審査を置く

買い手が多数の企業・学校顧客を持つ場合、既存製品を一斉販売するとリスクも拡大します。国、利用主体、対象者、推論、決定を入力にした販売ゲートを設け、承認されない組合せを技術的に無効化します。営業目標と独立した拒否権、例外記録、定期監査を置きます。シナジー計画は、販売可能な顧客だけを分母にして計算します。

13．第50条の透明性義務と2026年の日程を正確に置く

感情認識・生体分類へ曝される人への通知

欧州委員会の第50条に関するよくある質問は、感情認識や生体情報による分類を行うシステムの導入・運用者が、そのシステムの対象となる人へ通知する義務を説明しています。プライバシーポリシーの奥に一般的な文章を置くだけでなく、体験前またはその場で、何が動作し何が推論されるかを理解できる表示が必要かを確認します。提供者と顧客のどちらが表示を実装し、対応の証拠を残すかを契約で定めます。

2026年8月2日の適用を基準にする

同FAQによれば第50条は2026年8月2日から適用されます。本稿の基準日である2026年8月22日には、対象機能の通知設計を将来課題として扱えません。端末内表示、施設掲示、研修案内、音声通知、アクセシビリティ、ログを国・顧客別に確認します。既存導入先で表示が欠ける場合、更新配信、顧客同意、現場作業、停止期間を是正費へ入れます。

限定的な既存システム猶予を誤用しない

委員会FAQが説明する既存システムの限定猶予は、AI生成又は操作コンテンツの識別表示の付与・検出に関する特定義務に関係し、感情認識又は生体分類の通知へ一般化できません。「既存製品は二年猶予」という社内メモがあれば、条項と対象義務を再確認します。リリース日ではなく、対象機能、提供者・展開者の役割、運用地域で判定します。

通知の存在だけで禁止用途は適法化しない

透明性義務を満たしても、第5条の禁止行為やEU一般データ保護規則（GDPR）その他の根拠が自動的に満たされるわけではありません。通知、処理根拠、禁止、高リスク義務を別行にした制度マトリクスを作ります。顧客が利用者へ通知した証拠を持つことと、対象会社が禁止用途へ販売していないことをそれぞれ検証します。複数制度を一つのチェックボックスへまとめません。

14．高リスクの日程変更を禁止・透明性の日程と混ぜない

AIオムニバス発効後の時点を固定する

欧州委員会はAIオムニバスが2026年7月27日に発効したと公表しています。同説明では、附属書IIIの高リスク規則は2027年12月2日、規制対象の物理製品に組み込まれるシステムは2028年8月2日という日程が示されています。取引資料には「調査基準日」「該当し得る区分」「義務ごとの適用日」を併記し、古いロードマップを残しません。

第5条と第50条まで延期されたと書かない

高リスク日程の変更を、禁止行為又は第50条透明性義務へ横滑りさせないことが重要です。機能インベントリに、禁止の可能性、現在の通知、将来の高リスク対応を別列で置きます。譲渡企業の対応計画が将来日だけを示している場合、現時点で必要な停止、通知、契約変更が抜けていないかを調べます。

適用可能性と準備期間を分ける

高リスク該当性が確定していなくても、データガバナンス、技術文書、ログ、人による監督、品質管理を整えるには時間がかかります。一方、該当しない製品へ全面的な制度費用を計上すれば価値を過小評価します。製品、用途、顧客、地域、役割ごとに適用可能性を評価し、必須、条件付き、任意改善へ予算を分けます。

署名から実行までの法改正条項を置く

長い取引では、契約締結後にガイダンス、法改正、端末仕様が更新されます。譲渡企業の通常運営義務だけでなく、対象機能の追加、販売国拡大、通知変更、当局照会、重大な法解釈変更を報告対象にします。クロージング直前に法域マトリクスと製品版を再確認し、重大な未是正があれば実行条件、価格留保又は分離運営へつなげます。

15．データ来歴・同意・通知バージョンをレコードへ結び付ける

最低限の来歴キー

データセットには、取得日時、国、顧客、対象者区分、年齢、端末、OS、アプリ版、センサー、目的、処理根拠、通知版、同意文版、撤回、保存先、処理の受託者、国外移転、削除期限を付けます。個票へ全項目を直接持てない場合も、バッチIDや収集キャンペーンIDで一意に関連付けます。「2019～2025年収集」というファイル名だけでは、承継後の利用可否を判断できません。

同意画面をスクリーンショットだけで終わらせない

同意文、表示順、必須・任意、拒否時の機能、チェック初期値、言語、アクセシビリティ、撤回経路を実機で再現します。サーバーのconsent=trueが、どの文面へのどの操作を示すかを版IDで確認します。顧客管理者が従業員を一括登録しただけなのか、本人が操作したのかも分けます。同意以外の根拠を使う場合は、その判断と目的を記録します。

ラベル作成者とラベル根拠を追う

感情、注意、疲労、健康等のラベルが、本人申告、観察者、顧客評価、医療測定、合成ルールのどれかで品質と適法性が変わります。外部アノテーション会社へ生データを渡した場合、契約、国、アクセス、削除、再利用禁止を確認します。ラベルが主観的なら複数評価者の一致、文化・言語差、曖昧サンプルの扱いを測ります。

来歴欠損を割合で示す

「一部の古いデータは記録なし」で終えず、総件数のうち目的を確認できる割合、同意版を結べる割合、国外移転を確認できる割合、削除キーがある割合をデータセット別に計算します。欠損群を学習から除外したときの性能、再収集費、顧客影響を試します。来歴の完全性そのものをデータ品質KPIとし、価格とクロージング条件へ接続します。

16．国外移転と委託先チェーンを実データから確認する

クラウドの契約地域と実処理地域を分ける

請求書に東京リージョンとあっても、サポート、監視、バックアップ、音声サービスの接続仕様（API）、アノテーション、モデル学習が別国で行われる場合があります。ネットワーク、クラウド設定、処理の再委託先一覧、サポートチケット、バックアップ方針を突き合わせ、データ項目ごとの保存・アクセス国を作ります。管理画面から選べる地域と、既存テナントに適用されている実設定も別に確認します。

日本の外国第三者提供を案件単位で確認する

個人情報保護委員会の外国にある第三者への提供編を参照し、提供先、法制度、同意又は相当措置、本人への情報提供、継続確認、記録等を具体的フローへ当てはめます。「有名なクラウドだから問題ない」「委託だから国外移転ではない」と一律に処理しません。対象会社、顧客、ソフトウェア開発キット（SDK）提供者の役割と契約を国内専門家へ示し、必要な是正を特定します。

EUの移転文書を実際の処理の再委託先へ合わせる

契約ひな形に移転条項があっても、現在使う音声、分析、サポート、ラベル付け事業者が一覧に含まれるとは限りません。データ処理契約、標準契約条項その他の仕組み、移転影響評価、補完措置、通知手続を確認します。顧客との契約で処理の再委託先追加に事前通知又は異議権がある場合、買収後のクラウド統合が自由にできるとは評価しません。

買い手環境への移設を新しい移転として設計する

親会社の共通データ基盤が別国にある場合、クロージング後の統合は新しい提供又は移転の論点を生じ得ます。取引完了初日から全データを複製せず、独立環境を維持しながら、目的、法的役割、契約、通知、技術措置を整えます。統合できない期間の二重運用費、限定アクセス、国内保管、集計だけの共有をシナジー計算へ入れます。

17．撤回・削除・アクセス要求を派生物まで伝播させる

本人を検索できなければ権利対応もできない

仮名IDで保存していても、本人からの要求を対象レコードへ安全に対応付ける手段が必要です。検索キーが弱いと他人のデータを開示・削除する危険があり、強すぎる身元確認は本人の負担になります。会員、従業員、実証参加者、施設来場者ごとに受付、本人確認、検索、例外、回答を試します。顧客が窓口の場合は、対象会社への連携期限と証跡を確認します。

同意撤回とサービス終了を混同しない

任意のモデル学習同意を撤回した利用者へ、サービス全体の利用停止を要求する設計では自由な選択が疑われます。操作に必要な処理、任意分析、製品改善、広告、研究を目的別に切り替えられるかを確認します。撤回後に新規学習へ入らないこと、既存データが隔離・削除されること、顧客画面の推論が止まることを時系列でテストします。

学習済みモデルへの反映方針を決める

原データを削除しても既存モデルが直ちに変わるとは限りません。適用法、同意文、契約、技術可能性に照らし、次回再学習時の除外、緊急再学習、モデル廃棄、利用制限を定めます。どのモデルがどのデータスナップショットで学習されたかを追跡できなければ、要求の影響を判断できません。再学習時間、GPU費、性能低下、顧客再検証を負債として測ります。

要求履歴を買収前の詳細調査（DD）サンプルにする

過去のアクセス、訂正、削除、撤回、異議、苦情を抽出し、受付から完了までの日数、漏れ、再発、顧客連携を確認します。要求がゼロでも体制が優れているとは限らず、窓口が見つからない又はログがない可能性があります。テスト用人物で一件を端から端まで実行し、DB、ファイル、外注、バックアップ、モデル台帳の反映を観察します。

18．訓練データとモデルの系譜を一つのリリースへ結ぶ

モデルカードだけでなく再現経路を確認する

本番モデルについて、コードコミット、依存版、学習集合ID、除外、特徴量、ハイパーパラメータ、評価集合、承認、バイナリ、配布先を結びます。モデルカードに高い精度が記載されても、同じ集合を再現できなければ価値評価は弱くなります。買い手の隔離環境で代表モデルを再学習し、ハッシュ、性能、計算時間、費用を確認します。個人端末にだけあるノートブックや秘密鍵をクロージング前に移管します。

データ権利をモデル単位で集計する

一つのモデルが、自社ユーザー、顧客提供、研究、購入、公開データ、合成データを混ぜて学習している場合、集合ごとの目的・許諾・削除条件を確認します。全件の1％に問題があるだけでも、どの重みへ影響したか切り離せず再学習が必要になる場合があります。モデルごとに利用可能、条件付き、除外、来歴不明の構成比を示し、最も弱い集合へ依存するリスクを評価します。

性能を全体平均だけで見ない

視線、顔、声、姿勢のモデルは、端末、照明、言語、年齢、身体特性、眼鏡、障害等で性能が変わり得ます。訓練集合と実顧客の分布を比較し、群別の偽陽性、偽陰性、未判定、校正を測ります。感情や注意の主観ラベルでは、ラベル作成者間の一致も示します。全体精度が高くても、売上計画で拡大する地域や利用者で低ければ再収集費を見積もります。

営業表示と技術評価を一語ずつ照合する

「感情を正確に把握」「集中度を可視化」「健康状態を検出」等の表示が、モデルの出力と検証範囲を超えていないか確認します。研究用指標を製品の確定判断として販売していれば、顧客契約、返品、表示変更、再教育、当局対応のリスクがあります。精度の限界、非対象集団、入力品質、代替確認を画面とマニュアルに反映し、広告だけ直して実装を残さないようにします。

19．適法に再利用できるデータだけでモデル価値を計算する

総レコード数を最初の分母にしない

データ価値の計算単位は、ファイル行数ではなく、目的と権利を確認できる独立対象、セッション、ラベル等です。同一人物の毎秒ログを数百万件と数えれば数字だけが膨らみます。重複、欠損、機械生成、テスト、顧客返却対象、期限切れ、撤回済みを除外し、個人・セッション・端末の偏りを示します。モデル性能へ寄与しない追加フレームを同じ単価で評価しません。

価値のブリッジ式

調整後価値 = 適法に再利用可能な対象件数 × 目的適合率 × 品質係数 × 撤回後残存率 × 性能寄与 − 再同意費 − 削除・再学習費 − 越境・通知是正費 − 利用停止時の失注 と置きます。これは市場価格を自動算定する公式ではなく、譲渡企業の総件数から買い手が利用できる価値へ至る調整を可視化する枠組みです。各係数に証拠、責任者、更新日を付けます。

架空モデルで減額を試す

これは実在会社の数字ではない例です。対象者10万人のうち、目的・通知版を確認できる者が7万人、買収後目的へ適合する者が5万人、品質基準を満たす者が4万人、撤回・削除反映後が3万8千人とします。譲渡企業の説明の10万人をそのまま評価せず、3万8千人で性能を再測定します。精度が維持できなければ、再収集、ラベル修正、機能縮小の費用を追加します。

データを持たない設計の価値も測る

端末内処理、短期保持、集計、権限分離により、対象会社が生体的な原データをほとんど持たない場合があります。その場合、再利用データの価値は小さくても、侵害影響、削除負債、顧客審査、規制是正費が低い可能性があります。「収集量最大化」と「製品価値最大化」を分け、プライバシー保護アーキテクチャが解約率、販売期間、保険、運用費へ与える効果を評価します。

20．署名前に行う六つの技術買収前の詳細調査（DD）テスト

テスト1：権限状態テスト

端末、OS、アプリ版を組み合わせ、初回、許可、拒否、取消し、再許可、オフライン、複数ユーザーの状態を実行します。どのセンサー値、イベント、ログが端末とサーバーへ残るかを観測します。拒否しても同等の主要機能を使えるか、権限説明が目的と一致するか、更新後に権限が再要求されるかを記録します。

テスト2：ネットワークと保存テスト

通信先、項目、頻度、認証、地域をネットワークキャプチャとクラウドログで確認します。TLSの有無だけでなく、外部ソフトウェア開発キット（SDK）が広告識別子、端末情報、クラッシュ時の生データを送らないかを見ます。ローカルDB、キャッシュ、スクリーン録画、デバッグ、ログへ原データが残る期間を測り、文書の保存期間と一致させます。

テスト3：削除伝播テスト

テスト人物の撤回又は削除要求を投入し、本番相当DB、分析、特徴量、外注、バックアップ、学習キュー、顧客画面から消えるまでを追います。削除済みIDが次回バッチで復活しないか、モデル再学習対象へ登録されるかを確認します。完了時間と例外を証跡化し、法務上の回答期限と運用SLAを比較します。

テスト4：モデル再現・除外テスト

来歴不明群と撤回群を除外して代表モデルを再学習し、精度、群別性能、推論速度、計算費を比較します。除外により性能が急落するなら、問題集合への依存が大きいことを示します。再現不能なら、コード、環境、データ、鍵、人材のどこが欠けるかを特定し、クロージング条件又は価格控除へ入れます。

テスト5：顧客エクスポートテスト

管理者権限でCSV、アプリなどの接続仕様（API）、レポートを出し、個人別の視線、感情、注意、健康、業績スコアがどこまで取得できるか確認します。製品側が「集計のみ」と説明しても、非公開アプリなどの接続仕様（API）やサポート経由で個票が出る場合があります。顧客が再識別、雇用評価、他システム連携をできる構造なら、契約と法令マトリクスを更新します。

テスト6：緊急停止・ロールバックテスト

禁止又は重大な不適合が見つかった機能を、特定国、顧客、テナント、モデル版だけで停止できるかを試します。全サービス停止しか選べない場合、売上影響が大きくなります。機能の有効・無効を切り替える設定、モデルレジストリ、版固定、監査ログ、顧客通知、代替機能を確認し、買収初日に親会社が停止を承認・実行できる権限へ移します。

21．XR生体・推論データ買収前の詳細調査（DD）のレッドフラッグ

存在しないデータを資産計上している

端末の仕様表に視線の追跡又は虹彩による本人認証があることを根拠に、対象会社が視線生データや虹彩テンプレートを所有すると説明している場合です。アプリなどの接続仕様（API）、権限、ネットワーク、DBを確認し、OS内部だけの処理なら件数をゼロへ直します。取得できないこと自体を問題とせず、売上機能が認証結果だけで成立するのかを評価します。

通知にない二次学習

操作提供のため集めた手・視線ログを、将来の感情推定、広告、従業員評価モデルへ流用している場合です。「改善」条項の一語だけで新しい高影響目的まで包含すると決めません。データ流入を停止し、対象集合、派生特徴、学習モデル、顧客配布版を特定します。削除、再同意、再学習、表示変更、失注の各費用を算定します。

撤回が原DBにしか反映されない

本番ユーザーテーブルでは削除済みでも、分析コピー、特徴量ストア、学習集合、外注先、モデル台帳に反映されない状態です。削除済み人物を識別するブロックリストだけ残し、データ本体が無制限に使われる設計も確認します。伝播機構を作る期間と、作るまで学習を停止する影響を価格留保へ入れます。

「安全」「参考」の語で禁止・高影響用途を隠す

職場の感情推論を安全目的、個人別評価を集計、健康推論を参考表示と呼ぶだけで、実装と顧客行動が変わらない場合です。営業資料、デモ、契約、アプリなどの接続仕様（API）、顧客事例、サポート記録を横断し、実質用途を確認します。買収後に名称だけ変えて販売継続する計画は是正として扱いません。

モデル性能が来歴不明群へ依存する

法的に利用できる集合だけで再学習すると精度が大幅に落ちる場合、モデルとデータの価値を別々に減額する必要があります。譲渡企業が全データで示した評価値を買い手の利用可能性能として採用しません。再収集に必要な参加者、国、期間、同意、ラベル、端末、GPU、顧客再検証を計画し、回復までの売上を下方シナリオへ入れます。

22．株式譲渡契約へデータ固有の保護を入れる

表明保証を「法令遵守」の一文で終えない

データセットごとの取得主体、目的、処理根拠、同意、通知版、年齢、第三者提供、国外移転、保持、撤回、削除、顧客契約、研究契約、苦情、侵害、当局照会を個別に開示します。端末内データを対象会社が保有すると説明していないこと、モデル学習集合が台帳と一致することも確認します。一般的な「重大な違反なし」だけでは、価値算定に必要な利用可能範囲を固定できません。

問題データを取得対象又は利用範囲から分離する

株式取得では法人内データが物理的に残るため、問題集合だけを契約上「買わない」と書いてもリスクが消えるとは限りません。クロージング前削除、隔離、アクセス停止、モデル再学習、顧客返却を具体的成果物にします。削除できない法定保存分は利用禁止と隔離を定め、親会社環境へ移さない設計にします。

前提条件・誓約・補償を使い分ける

価値の中心モデルを適法に再現できること、禁止用途を停止すること、主要顧客同意、当局命令の不存在等は、重要性に応じてクロージング前提条件を検討します。長期是正は実行後誓約、過去違反と第三者請求は補償、価値不確実性は価格留保又は段階払で配分します。補償があっても削除不能データや評判損失を元に戻せないため、是正可能性を先に判断します。

法改正・ソフトウェア開発キット（SDK）変更・新規収集を中間期間で管理する

契約締結から実行まで、譲渡企業が新しいセンサー、感情ラベル、国外ベンダー、顧客用途を追加すると買収前の詳細調査（DD）結果が古くなります。通常業務例外を具体化し、重要変更の事前同意又は報告、データルーム更新、再試験を定めます。端末仕様変更で取得不能又は権限要件が変わった場合の価格、解除、製品計画も協議します。

23．クロージングで受け取るのはDBだけではない

権限と鍵の移管

クラウド、ID管理、モデルレジストリ、データカタログ、同意管理、削除キュー、端末開発者アカウント、署名証明書、外部ソフトウェア開発キット（SDK）、サポートの管理者を一覧にします。個人メールを回復先にしたアカウント、退職者だけが知る鍵、顧客環境の共有パスワードを解消します。全鍵を一斉変更して製品を止めないよう、依存関係、ロールバック、緊急連絡を机上演習します。

データ台帳とモデル台帳のスナップショット

取得日時点で、データセット件数、ハッシュ、保存先、法域、目的、同意版、問題集合、削除要求、モデル入力、配布版を固定します。署名前買収前の詳細調査（DD）と差分を取り、増加した集合が同じ条件を満たすか確認します。後日、問題が買収前からあったか、買収後に生じたかを判定できるよう、監査ログと時刻を保全します。

通知・同意・問い合わせ窓口の連続性

株主変更だけで法人名が変わらなくても、共同利用、親会社アクセス、国外処理、問い合わせ先が変わる場合があります。何をいつ本人と顧客へ伝えるかを法務判断に基づき決めます。削除・苦情窓口が旧メールのまま停止しないよう、転送、権限、SLA、言語対応を取引完了初日へ入れます。

停止対象と継続対象を製品版で分ける

一部の感情推定だけに問題がある場合、認証、操作、集計等の適法な機能まで止める必要があるかを技術的に分けます。国、顧客、アプリ版、モデル版ごとに継続、限定、停止を一覧化し、営業・サポートへ同じ情報を配布します。停止を口頭で指示するだけでなく、配信、アプリなどの接続仕様（API）、エクスポート、既存端末を確認します。

24．取引完了初日から100日までのデータガバナンスPMI

取引完了初日：流出と目的外利用を増やさない

親会社全員へデータアクセスを広げず、既存の必要担当者、緊急停止、問い合わせ、削除、顧客サポートを維持します。新しい学習やDB統合は承認制にし、禁止・重大不適合の可能性がある機能を止めます。データ処理の目的と手段を決める管理者・処理の受託者、プライバシー責任者、セキュリティ、製品、営業の暫定責任を決め、重大事象の連絡先を一本化します。

30日：七層台帳と法域マトリクスを統一する

対象会社の名称体系を消さず、親会社標準へ対応表を作ります。センサー、生データ、特徴量、照合用のひな形、推論結果、判断結果、集計値・モデルの分類を各データセットに付け、目的、根拠、保持、移転、顧客、版を補完します。アクセス権と同意・削除の記録を監査し、営業資料と実装の不一致を修正します。一般的な買収準備はVR会社の売却準備ガイドも参照できます。

60日：利用可能集合でモデルを再現する

来歴不明、撤回、禁止用途、契約外集合を除外し、主要モデルを再学習・評価します。性能が落ちる場合は、再収集、製品表示、顧客設定、価格計画を更新します。削除伝播、権限取消し、第50条通知、国別停止をテストし、未解決項目に期限と予算を付けます。Unity・Unreal等の技術資産全般はVR技術買収前の詳細調査（DD）ガイドへ分離して確認します。

100日：統合するデータと分離するデータを決議する

親会社基盤へ移すもの、対象会社内で分離運用するもの、削除するもの、集計だけ共有するものを取締役会又は所管委員会で承認します。価値計算の係数を実績で更新し、再同意率、削除完了、モデル性能、顧客移行、苦情、通知達成を報告します。統合の速さではなく、目的と証拠を維持して安全に再利用できる範囲を広げたかでPMIを評価します。

25．譲渡企業が買収前に整えるデータ・モデル証拠

件数の主張を分母付きにする

総イベント数だけでなく、独立対象者、セッション、国、顧客、端末、期間、同意版、利用可能目的を示します。重複、テスト、撤回、期限切れ、来歴不明を別列にし、除外後の件数を先に開示します。見かけの数字が小さくなっても、買い手が再現できる精度の高い台帳は、後日の減額と補償交渉を減らします。

端末内処理を価値提案として説明する

アプリが詳細視線や虹彩テンプレートを取得しないなら、「データを持っていない」と隠すのではなく、端末内処理で製品機能を実現し、侵害・保持・削除リスクを抑える設計として説明します。認証結果、選択イベント、匿名集計等、実際に扱う項目を正確に示します。Apple等の公式仕様と実機テストを資料へ付けます。

問題集合を自発的に隔離する

古い通知、研究同意、顧客返却、国外移転、撤回未反映に不確実性がある集合は、学習パイプラインから切り離し、是正可能性を調べます。隠したまま全モデルへ混ぜると、後で全体再学習が必要になります。隔離日時、アクセス、派生モデル、削除又は再同意計画を示し、企業価値の安全な部分を守ります。

社内の法務説明とコードを一致させる

プライバシー台帳に「感情推定なし」とあるのに、コードや営業デモが感情、関与の度合い、注意の度合いスコアを出す状態を解消します。製品、研究、営業、法務、顧客の利用定着を支援する担当者で用語をそろえ、意図した目的と禁止用途を版管理します。運営主体や一般方針の開示は運営会社情報のように、読者が確認しやすい導線も整えます。

26．買い手が投資委員会へ出す五枚の資料

一枚目：七層・法域・目的マトリクス

データセットを行、七層、日本の個人情報保護法（APPI）、EU一般データ保護規則（GDPR）、AI法、目的、対象者、顧客、保存国を列にし、確定、条件付き、未確認を色ではなく文字でも示します。制度用語を無理に一対一対応させず、各法域の根拠を独立列にします。最も重要な未確認項目と、確認できない場合の利用停止範囲を冒頭に置きます。

二枚目：端末取得可能性と実保有の差

端末センサー、OSが提供する接続仕様（API）、権限、本番アプリ、サーバー項目、保存件数を一行でつなぎます。特に視線と虹彩について、Apple公式仕様等と実機試験を示し、存在しない資産を除きます。逆にデバッグログや外部ソフトウェア開発キット（SDK）等、譲渡企業の説明にない取得が見つかった場合は負債欄へ追加します。

三枚目：価値ブリッジ

譲渡企業総件数から、来歴不明、目的不適合、撤回、品質不足、契約制限を差し引き、再利用可能集合を示します。その集合で再学習した性能と売上計画を接続し、再同意、削除、移転、通知、顧客移行費を控除します。ベース、下方、利用不能の三ケースを置き、価格、留保、前提条件へ反映します。

四枚目：現在・将来の義務タイムライン

第5条、第50条、高リスク日程、顧客契約更新、端末ソフトウェア開発キット（SDK）終了、データ保持期限を一つの時間軸へ置きます。ただし義務の対象を混ぜず、製品・用途・地域ごとに分けます。取引日後100日以内に必要なものと、将来適用へ準備するものを区別し、責任者と予算を付けます。

五枚目：停止可能性と100日計画

問題機能を国・顧客・版単位で止められるか、止めた場合の売上、契約、代替、再開条件を示します。取引完了初日の権限、30日の台帳、60日の再学習、100日の統合決議を並べます。投資委員会は「データが多い」ではなく、「許される目的で再現可能に使い、問題時に止められる」ことを承認します。

27．三つのXR用途で買収前の詳細調査（DD）の焦点を変える

消費者向け空間UI

視線や手を入力に使う消費者アプリでは、プラットフォームがアプリへ渡す値、権限、端末内処理、子どもを含む利用者、広告・分析ソフトウェア開発キット（SDK）を重点にします。詳細信号を保存せず機能を実現できるなら最小化を優先します。買収後に親会社広告基盤へ接続する計画は、旧目的の延長と決めつけず別審査へ回します。

企業研修・作業支援

従業員の姿勢、視線、声、注意、感情、疲労を扱う場合は、雇用上の力関係、自由な選択、顧客による個人別評価、EUのAI法第5条と第50条を重点的に確認します。安全支援と業績監視を画面・外部接続機能で分け、管理者が目的外の設定をできないか確認します。国別に販売可能な機能を絞った後の売上だけを、相乗効果の見込みに入れます。

研究・ヘルスケア周辺

瞳孔、心拍、動作、声から健康状態を推論する研究・ウェルネス製品では、研究同意、倫理手続、健康データ、医療主張、ラベル品質、対象集団を重点にします。本稿は医療機器該当性を判定しません。個別製品の表示、意図した目的、国、販売方法を医療・広告等の専門家が確認し、一般的なXR買収評価へ埋め込みます。

施設型体験・来場者分析

共有端末とカメラを使う施設では、本人以外の同伴者・通行者、体験前通知、短期利用者の権利窓口、施設運営者との役割、複数人音声を確認します。会員登録がなくても時刻、店舗、映像、決済と結合される場合があります。集計ヒートマップの少人数セルと原ログ保持を調べ、施設ごとの設定差を出します。

28．取締役会が継続監督するKPI

適法利用可能率

総対象数に対し、目的・根拠・通知版・契約・移転・保持を確認でき、現在の製品目的へ使える対象の割合を測ります。レコード数ではなく人又は独立セッションを分母にし、データセット別に示します。改善のために同意を強制したり、来歴不明群を形式的に「研究」へ付け替えたりしないよう、内部監査が証拠を抽出します。

撤回・削除伝播時間

受付から本人回答だけでなく、本番、分析、外注、学習キュー、顧客画面、モデル台帳へ反映するまでを測ります。未完了件数、期限超過、復活、誤削除を報告します。平均値だけで長期滞留を隠さず、最大、百分位、重大例を示します。取得会社と対象会社の窓口が分断されるPMI初期ほど頻度を上げます。

用途・表示・実装の一致率

製品版ごとに、営業資料、契約、プライバシー通知、権限文、UI、アプリなどの接続仕様（API）、実モデルのラベルが一致するかを監査します。新しい推論や顧客エクスポートを追加する際に、発売前レビューを通った割合を測ります。不一致を単なる文言修正で閉じず、データ流入、既存顧客、過去学習への影響を確認して完了とします。

停止・再学習の準備度

問題機能を限定停止できる製品割合、来歴が追えるモデル割合、利用可能集合で再現できるモデル割合、緊急再学習時間を追います。モデル精度だけを経営KPIにすると、違法又は不明なデータを除外する動機が弱くなります。売上、性能、適法利用可能率、苦情、停止準備を同じ資料で判断します。

29．匿名モデル案件で価格調整を試算する

前提はすべて架空

架空のXR研修会社が、視線・手・声から操作支援と注意スコアを提供し、譲渡企業は12万人分のデータを訓練資産と説明したとします。調査で、端末内視線しかない4万人、通知版不明2万人、顧客契約が自社学習を認めない1万5千人、撤回等5千人が見つかったとします。重複を調整した利用可能候補は4万人で、これは実在会社の事実ではありません。

技術試験でさらに絞る

4万人のうち端末・言語の偏りが強く、品質基準を満たす3万2千人で再学習すると、全データモデルより主要指標が低下したと仮定します。買い手は3万2千人の集合と低下後性能を基準に売上計画を作り、来歴不明群を含む旧モデルは一部顧客で停止します。新規収集、ラベル修正、再検証の期間を算定します。

価格と契約へ分ける

再同意、削除、モデル再学習、顧客移行、通知更新、国外移転是正は、金額と期限を見積もって企業価値から控除します。中心製品が利用可能集合で性能基準を満たすことを前提条件とし、旧モデルに関する第三者請求は個別補償、是正完了分は留保解除の条件にします。すべてを補償へ回して高い基礎価格を維持しません。

上振れは再収集後に認識する

買い手の顧客網で適法な新データを集め、モデル性能が回復する可能性はあります。しかし、将来参加者の同意率、端末構成、顧客協力、期間は不確実です。上振れを満額で前払いせず、測定可能な再収集、性能、継続売上へ連動する段階対価を検討します。買い手が再収集に必要な協力をしない場合の扱いも定めます。

30．XR生体・推論データM&Aチェックリスト

データと端末

• センサー、生データ、特徴量、照合用データ、推定結果、判断結果、集計値・学習モデルの七層に分けて台帳化したか
• 端末が測れる値、OSが公開する値、アプリが取得する値、サーバーが保存する値を分けたか
• 端末・OS・ソフトウェア開発キット（SDK）・権限・アプリ版ごとに実機と通信を試したか
• 視線入力、虹彩テンプレート、認証結果を同じ資産として数えていないか

目的・法域・対象者

• 操作、認証、識別、分類、感情・意図、健康、雇用判断を別目的にしたか
• 日本の個人情報保護法（APPI）、EU一般データ保護規則（GDPR）、AI法の用語を相互置換せず各条項へ対応させたか
• 職場・教育の用途、第50条通知、高リスク日程を別々に確認したか
• 国、年齢、従業員、顧客、研究参加者、施設来場者を区分したか

来歴・同意・移転

• 取得日、国、端末、アプリ、目的、根拠、通知・同意版をレコード群へ結んだか
• 研究、顧客提供、購入、公開、合成の各集合について再利用権を確認したか
• 国外の保存、アクセス、処理の再委託先、アノテーションを実フローで確認したか
• 撤回・削除が分析、外注、学習、モデル台帳まで伝播するか試したか

モデル・価値・契約

• 利用可能集合だけで再学習し、群別性能と計算費を測ったか
• 総レコード数ではなく独立対象と性能寄与で価値を調整したか
• 再同意、削除、再学習、通知、移転、顧客移行、失注を控除したか
• 問題集合の隔離、前提条件、留保、補償、中間期間変更を契約へ入れたか

PMIと監督

• 取引完了初日で必要担当者以外へアクセスを広げない設計にしたか
• 国・顧客・版単位で問題機能を停止できるか
• 30日台帳、60日再学習、100日統合決議の責任者と予算があるか
• 適法利用可能率、削除伝播、表示一致、停止準備を取締役会へ報告するか

31．よくある質問

Q．視線データはすべて生体情報又は要配慮情報ですか

A．信号名だけで一律には判断できません。一時的なUI入力、個人別の長期履歴、本人認証用テンプレート、健康・感情推論では、識別可能性、技術処理、目的、他データとの結合が異なります。日本、EUその他の法域ごとに具体的処理を専門家が確認してください。

Q．端末にアイトラッキングがあれば対象会社は視線を保有しますか

A．いいえ。端末が内部で測定しても、OSがアプリへ詳細値を共有しない場合があります。AppleはVision Proの視線入力について、アプリ、ウェブサイト、Appleへ共有されない旨を説明しています。本番ビルドのアプリなどの接続仕様（API）、権限、通信、DBで実保有を確認します。

Q．Optic ID対応アプリは虹彩テンプレートを買収できますか

A．Appleの公式説明では虹彩の数学的表現はSecure Enclaveで保護され、アプリは認証結果を受け取ります。したがって、Optic IDログイン対応だけで対象会社が虹彩テンプレートを保有するとは評価できません。会員情報と認証ログ等、実際に保有する範囲を分けます。

Q．株式譲渡なら過去データを親会社の学習へ使えますか

A．自動的には決まりません。法人の同一性、承継前の利用目的、買い手の新目的、顧客契約、同意、EU一般データ保護規則（GDPR）上の役割、国外移転、AI法の用途を確認します。親会社の広告又は従業員評価モデルへの統合は、旧サービス提供と別目的になり得ます。

Q．匿名化すれば取引前に原データを共有できますか

A．匿名と呼ぶだけでは足りません。時刻、店舗、動作、端末、希少属性から再識別できないか、買い手が他DBを持つかを評価します。初期は集計と証憑、必要な原データはクリーン環境で限定閲覧し、破談時削除まで契約化する方法があります。

Q．AI法の高リスク義務は2026年にすべて始まりましたか

A．本稿基準日では、AI関連規制の一括見直し法（AIオムニバス）の発効後の高リスク分野の日程と、既に関係し得る禁止行為・第50条を分ける必要があります。欧州委員会は附属書IIIを2027年12月2日、製品組込みを2028年8月2日と説明していますが、第50条は2026年8月2日適用です。

Q．感情推定を「安全用途」と書けば職場で使えますか

A．名称だけでは足りません。EUのAI法第5条の禁止と限定的な例外について、意図した目的、必要性、実装、顧客による運用をEUの専門家が確認する必要があります。業績・雇用の評価を安全対策と言い換えるだけでは、是正になりません。

Q．モデル価値はデータ件数へ単価を掛ければ出せますか

A．同一人物の高頻度ログで件数が膨らむため適切ではありません。目的・来歴を確認できる独立対象、品質、撤回後残存、再学習性能を基準にし、再同意、削除、移転、通知、失注等を控除します。架空モデルで感応度を示し、実案件の倍率を推測しません。

Q．XR会社のデータ買収前の詳細調査（DD）を相談できますか

A．はい。企業名や原データを初期段階で開示せず、七層台帳、端末取得可能性、利用目的、モデル来歴、取引構造を整理できます。譲渡企業様向け相談窓口からご相談ください。相談前に支援範囲はVR M&A総合センターについてで確認できます。

32．参考にした一次・公式資料

以下は2026年8月22日時点で確認した公式資料です。法令本文を優先し、委員会FAQや事業者の端末仕様は解釈・実装確認の資料として使いました。個別案件の公開日が後になる場合、法令、ガイダンス、端末・ソフトウェア開発キット（SDK）仕様を再確認してください。

1. 個人情報保護委員会「個人情報保護法ガイドライン（通則編）」 — 日本の個人情報、利用目的、事業承継等の基礎。
2. 個人情報保護委員会「ガイドラインに関するQ&A」 — 生体特徴を本人認証できるようにしたもの等の考え方。
3. 個人情報保護委員会「外国にある第三者への提供編」 — 国外提供の確認事項。
4. 欧州法令データベース「EU規則2016/679（一般データ保護規則）」 — 生体データ、特別な保護を要するデータの区分、処理原則等。
5. EU法令データベース「規則（EU）2024/1689（AI法）」 — 生体識別・分類、感情認識、禁止、透明性等。
6. 欧州委員会「AIオムニバスの施行」 — 2026年7月27日発効と高リスク日程。
7. 欧州委員会「第50条の透明性に関する義務」 — 2026年8月2日適用と通知義務。
8. Apple「視線、手、およびプライバシー」 — 視線入力、手データ、権限、端末内処理。
9. Apple「Optic IDとプライバシー」 — 虹彩表現の端末内保護とアプリへ返る認証結果。
10. Apple開発者向け資料「プライバシーと利用者の設定に関する推奨事項の適用」 — visionOSの権限と最小化の実装確認。

公開サイト内では、M&Aコラム、M&A事例から他の論点を確認できます。地域・施設型XRの承継は地域XR事業承継ガイドも参照してください。

33．まとめ：センサー名ではなく利用可能性を買う

XR 生体データ M&Aでは、目、顔、手、声という名称を企業価値へ直結させません。センサー、生データ、特徴量、照合用のひな形、推論結果、判断結果、集計値・モデルの七層へ分け、端末が測れるもの、アプリが取得できるもの、対象会社が保存するもの、適法な目的で承継後も利用できるものを順番に絞ります。視線入力と虹彩認証、表情検出と感情推論、操作ログと健康推論を混同しないことが出発点です。

日本では個人情報、個人識別符号、個人関連情報、利用目的と事業承継を具体的処理へ当てはめ、EUでは一般データ保護規則（GDPR）の生体データ・健康データと、AI法の識別・分類・感情認識を別々に確認します。2026年8月22日時点では第50条の適用を現在の義務として扱い、高リスク分野の日程変更と混ぜません。端末仕様は資料だけでなく、権限、通信、保存、削除、再学習、限定停止を実機で試します。

価格は総件数ではなく、目的と来歴を確認できる独立対象、品質、撤回後残存、利用可能集合での性能から作ります。再同意、削除、モデル再学習、国外移転、通知、顧客移行、利用停止の費用を控除し、問題集合は隔離・削除・留保・補償・前提条件へ分けます。PMIでは親会社への一括コピーを急がず、100日までに統合、分離、削除、集計共有を決議します。

視線・顔・手・声・姿勢等を扱うXR会社の譲渡、資本提携、事業譲受について、原データを不用意に共有せず初期論点を整理したい方は、譲渡企業様向け相談窓口をご利用ください。秘密保持前に必要な集計、データルームの段階開示、技術買収前の詳細調査（DD）、買い手候補の検討から整理できます。