App Store・Google Play所有権移管の壁
「アプリの売上は月800万円、ストア評価は4.7、ダウンロードは累計300万。これを事業ごと買いたい」── スマホアプリ事業のM&Aで、買い手がまず見るのはこの3つの数字だ。しかし契約直前になって、誰も確認していなかった一行が交渉を止める。「このアプリ、Apple Developerアカウントは誰の名義ですか」。返ってきた答えが「創業者の個人名義です」だった瞬間、その案件は技術的DDの本丸に突入する。
スマホアプリ事業の移管は、Webサービスのそれとは構造が根本的に異なる。AppleとGoogleという二つのプラットフォーマーが、配信・課金・ユーザーとの契約のすべてを握っており、事業の所有権を移すには両社それぞれの「アプリ移管プロセス」を通過しなければならない。そしてこの移管には、満たさなければ移管自体が拒否される条件が複数存在する。条件を満たさないアプリは、買収後も旧名義のアカウントに取り残されたまま、アップデートも課金も旧オーナーの手を借り続けることになる。
本稿では、App StoreとGoogle Playそれぞれのアプリ移管の実態、移管をブロックする技術的・契約的条件、署名鍵やサブスクリプションといった「移せば終わりではない」領域、そして名義・契約構造をバリュエーションにどう織り込むかを、買い手・売り手双方の実務目線で整理する。
1. なぜスマホアプリは「アカウントごと」移管できないのか
1-1. 配信・課金・ユーザー契約をプラットフォーマーが握る構造
WebサービスであればDNSとサーバーの所有権を移せば事業は移る。しかしスマホアプリは、配信経路（App Store / Google Play）も、課金（App内課金・サブスクリプション）も、エンドユーザーとの契約関係も、すべてAppleとGoogleが仲介している。事業者が持っているのは「Developerアカウントの中にあるアプリ」という権利であって、配信基盤そのものではない。
このため、事業を移すには「Developerアカウントを丸ごと譲渡する」か「アプリ単位で移管プロセスを通す」かの二択になる。前者はアカウントが個人名義か法人名義か、株式譲渡か事業譲渡かで可否が分かれ、後者は両プラットフォームが用意する移管機能の条件をクリアする必要がある。「アプリの権利を買った」と「アプリを運営できる状態を引き継いだ」の間には、深い溝がある。
1-2. 個人名義アカウントという時限爆弾
最も危険なのが、Developerアカウントが創業者の個人名義（Individual）で作られているケースだ。個人名義アカウントは法人への名義変更が原則できず、アプリ移管プロセスで別アカウントに移すしかない。さらに個人名義のApple IDに二要素認証が紐づき、その電話番号が創業者個人のものである場合、創業者の協力なしには何も操作できない。
買収後に創業者と関係が悪化したり、連絡が取れなくなったりすると、アプリのアップデートが永久にできなくなる。OSのバージョンアップでアプリがクラッシュするようになっても、ストアの審査に出すことすらできない。個人名義アカウントの事業は、創業者個人への依存度がそのまま事業継続リスクになる。
2. App Store（Apple）のアプリ移管 ── App Transferの条件
2-1. App Transfer機能で移せるもの・移せないもの
Appleは「App Transfer」という機能を公式に提供している。これにより、あるDeveloperアカウントから別のアカウントへ、アプリを単位として移管できる。移管されるのは、アプリ本体・既存のレビューと評価・TestFlightのビルド・App内課金の商品・既存のサブスクリプション加入者だ。ユーザーから見れば、アプリは同じものとして継続し、再ダウンロードも不要だ。
しかし移管には厳格な前提条件がある。受け取り側が有効な有料Developer Programアカウントを持っていること、移管対象アプリが他アプリとBundle IDを共有していないこと、最新の契約（Paid Applications Agreement等）が両者で受諾済みであること、などだ。これらを一つでも欠くと、移管ボタンは押せない。
2-2. 移管をブロックする「使用中の機能」
見落とされがちなのが、特定の機能・エンタイトルメントを使っているアプリは移管できないという制約だ。Apple Payを利用しているアプリ、特定のpasskit、Wallet、一部のApp Groupsを共有している構成、Bundle IDがワイルドカードになっている古い構成などは、App Transferが拒否される。
こうしたアプリは、移管前に該当機能の構成を整理する必要があり、場合によってはコードとプロビジョニングプロファイルの修正、再リリースを伴う。「App Transferがあるから大丈夫」と言うエンジニアは、自社アプリが移管可能な構成かを実際に検証していないことが多い。DD段階で、対象アプリのCapabilities一覧を取得し、移管阻害要因を洗い出すことが必須だ。
3. Google Playのアプリ移管 ── 移管トークンとアカウント前提
3-1. アプリ転送プロセスの流れ
Google Playは「アプリを別のデベロッパーアカウントに移行する」プロセスを提供している。移行元アカウントで移行を開始し、Googleが発行する移行トークン（transaction ID）と移行先アカウント情報を用いて、アプリを別アカウントに移す。移行後もアプリのインストールベース・評価・レビューは維持される。
ただし、移行元・移行先の両アカウントが有効であること、未払いの問題がないこと、移行先がアプリ配信に必要な契約に同意済みであることが前提だ。法人アカウントの場合はD-U-N-S番号など組織情報の整合も問われる。移行の途中でアカウントの状態に不備があると、プロセスが止まる。
3-2. Play App Signingと署名鍵 ── 最大の地雷
Androidアプリ移管で最も深刻なのが署名鍵の問題だ。Androidアプリは署名鍵で更新の同一性を担保しており、署名鍵を失うとアプリの更新が永久に不可能になる。Google Playの「Play App Signing」に登録済みであれば、署名鍵はGoogleが管理しているため移管に伴うリスクは小さい。問題は、Play App Signingを使わず、アップロード鍵を開発者自身が管理しているケースだ。
この場合、署名鍵（keystoreファイルとパスワード）が創業者の個人PCにしか存在せず、バックアップもないという事態が現実に起きる。鍵が失われれば、そのアプリは二度と更新できず、新しいパッケージ名で作り直すしかない。作り直せばインストールベースも評価もゼロからになる。DDでは、署名鍵の保管場所・バックアップ・Play App Signing登録の有無を必ず確認する。
4. 「移せば終わり」ではない周辺資産
4-1. サブスクリプション・App内課金の収益連続性
App TransferやPlay移管で既存のサブスクリプション加入者は引き継がれるが、課金まわりには注意点がある。Apple・Googleとエンドユーザーの課金契約はプラットフォーム側に残り、事業者は手数料控除後の支払いを受け取る立場だ。移管に伴い、支払いを受ける銀行口座・税務情報・契約の受諾状態をすべて移管先で再設定する必要がある。
この再設定が完了するまで、売上の入金が一時的に止まる、あるいは旧アカウントに着金してしまうことがある。サブスクリプション型アプリのM&Aでは、課金の入金経路が切り替わるタイミングを精密に設計しないと、数週間分の売上が宙に浮く。決済アカウントの再審査（Stripe等）と同じ構造の問題が、ストア課金でも起きる。
4-2. プッシュ通知証明書・Firebase・外部SDKの紐付け
アプリ本体が移管できても、それを支える外部サービスの紐付けは自動では移らない。APNs（Apple Push Notification service）の証明書・鍵、FirebaseプロジェクトのオーナーシップとBundle ID紐付け、分析SDK・広告SDK・課金管理SDK（RevenueCat等）の管理アカウント、ディープリンク基盤など、アプリの裏側には無数の外部依存が存在する。
これらの紐付けが旧オーナーのアカウントに残ったままだと、移管後にプッシュ通知が止まる、分析データが取得できなくなる、広告収益の入金先が変わらない、といった事態が起きる。アプリ移管の棚卸しは、ストア内の作業だけでなく、アプリが依存する外部サービスのアカウント移管まで含めて初めて完了する。
5. 名義・契約構造をバリュエーションにどう織り込むか
5-1. 移管可能性スコア ── 「明日アップデートを出せるか」
アプリ事業のバリュエーションで最初に問うべきは、「買収翌日に、買い手の管理下でアップデートを審査に出せる状態にできるか」だ。Developerアカウントが法人名義で、Play App Signingに登録済みで、App Transferの阻害要因がなく、署名鍵がバックアップされている事業は、移管リスクが小さく減点幅も小さい。
逆に、個人名義アカウント・署名鍵が個人PCのみ・移管不能なCapabilities使用・外部SDKの紐付け不明、といった事業は、移管失敗時に事業継続そのものが断たれるため、価値の相応な割引と、移管完了を条件とするクロージング設計が必要になる。移管可能性は、アプリ事業における可用性リスクそのものだ。
5-2. クロージング条件への組み込みとアーンアウト
アプリ移管は契約調印からクロージングまでの間に完了するとは限らず、AppleやGoogleの処理に時間がかかる。このため、「アプリ移管の完了」と「署名鍵・外部サービスの引き継ぎ完了」を明確なクロージング条件、あるいはクロージング後の表明保証事項として契約書に明記する。
移管に創業者の継続的協力が不可欠な場合は、一定期間の業務移管支援（トランジションサービス）を契約に含め、その達成度をアーンアウトの支払い条件に紐づけるのが実務的だ。移管が技術的に創業者依存である事業ほど、対価の一部を移管完了に連動させてリスクを分担するのが合理的な設計になる。
結論：アプリの価値は「ストアの数字」ではなく「移管できる構造」に宿る
ダウンロード数・評価・売上といった見える数字は、アプリ事業の魅力を語る。しかしその魅力を買い手が確実に引き継げるかどうかは、Developerアカウントの名義、署名鍵の保管、移管プロセスの通過可能性、外部サービスの紐付けという、財務諸表に一切現れない構造に依存している。ここが詰んでいる事業は、どれだけ数字が良くても「買えるが運営できない」リスクを抱える。
アプリ事業を売る側にとっては、移管可能な構造を整えておくこと自体が強力な加点要素になる。法人名義への移行、Play App Signingへの登録、署名鍵のバックアップ、外部サービスのアカウント整理 ── これらを済ませた事業は、買い手の技術DDで「移管リスクの低い事業」として評価される。技術的DDの本質は、プラットフォーマーが握る構造の中で、事業の所有権がどこまで確実に移るかを見極める作業にある。
