アプリ事業M&Aの技術引き継ぎ完全ガイド｜App Store・Google Play・GitHub・クラウドを止めない承継設計

2026年7月17日2026年7月18日

アプリ業界M&Aの実務コラム

アプリ開発・SaaS・受託開発会社の経営者が、売却準備と承継後の事業継続を具体的に進めるための実務情報です。

対象読者

この記事は、自社で育てたスマートフォンアプリ、Webアプリ、SaaS、業務支援サービスの売却を検討している経営者、事業責任者、CTO、ひとり開発者、受託開発会社のオーナーを対象にしています。とりわけ、売却後も利用者への提供を止めたくない、少人数で構築したため自分しか分からない設定が多い、AppleやGoogleのアカウントを会社のほかの事業でも使っている、クラウドや外部APIが複雑に結び付いている、という方のための実務編です。

技術引き継ぎは、パスワード一覧を渡す作業ではありません。アプリを動かしている「権利」「アカウント」「データ」「人」「運用判断」を分解し、誰が、いつ、どの根拠で支配できる状態にするかを設計するプロジェクトです。買い手がソースコードを受け取っても、本番環境を再現できなければ事業は承継できません。逆に、すべてを一夜で買い手名義へ変えると、障害時に戻せず、譲渡企業と買い手の双方が危険を負います。

結論サマリー

最初に「移る資産」「移らない資産」「移るが再設定を要する資産」を一枚の台帳にします。

株式譲渡では法人にひも付く契約やアカウントが原則として法人内に残りやすい一方、支配権・担当者・保証関係は変わります。事業譲渡では対象を個別に特定し、相手方同意や新規契約が必要になる場面が増えます。

App StoreやGoogle Playの「アプリ移管」と、クラウド、決済、ドメイン、顧客データ、サポート窓口の移管は別工程です。ストア移管だけで承継は完了しません。

T-60から資産棚卸しと依存関係の可視化を始め、T-30で移管方式とロールバック条件を固定し、T-7で変更凍結、Day 0で権利移転、Day 1で監視、30日で初回リリース、90日で旧権限を閉じる流れが基本です。

最初の障害に誰が何分以内に対応するかまで合意して初めて、技術引き継ぎは「完了」と言えます。

Apple、Google、GitHub、AWS、Google Cloudなどの仕様・資格条件・手順は変更されます。実行時点の公式資料と管理画面表示を必ず確認してください。

1. 技術引き継ぎの目的は「所有」ではなく「継続可能な支配」

M&A契約で知的財産権の譲渡条項を書いても、それだけでは利用者にアプリを届け続けられません。買い手が翌朝からできるべきことは、障害の検知、原因調査、設定変更、ビルド、審査提出、課金照合、問い合わせ回答、個人情報事故への対応です。この一連の行為を自社の権限と予算で実行できる状態を、本稿では「継続可能な支配」と呼びます。

たとえば、GitHubのリポジトリを渡しても、署名鍵が元社員のMacだけにあり、CI/CDのSecretが読めず、Firebaseの本番プロジェクトへ買い手が入れないなら支配は移っていません。AWSのルートユーザーを共有しても、登録メールと電話番号が譲渡企業個人のままなら、復旧経路は譲渡企業に残っています。ドメインを移しても、DNSの権威サーバーや証明書更新ジョブを把握していなければ、数か月後の期限切れで停止します。

したがって完了判定は「ファイルを渡した」ではなく、買い手だけで平時運用と緊急対応を一巡できたかで行います。最低限、買い手がテスト環境で修正をビルドして配布し、監視アラートを受け、バックアップから復元し、問い合わせに回答するリハーサルを実施します。譲渡企業は横で見守りますが、手を出さない時間を設けます。そこで止まった箇所が、引き継ぎ資料の不足です。

2. 株式譲渡と事業譲渡で技術実務はどう変わるか

株式譲渡

株式譲渡では、アプリを運営する法人そのものは同一です。法人名義のクラウド契約、ストア登録、雇用契約、顧客との利用契約は、契約上のチェンジ・オブ・コントロール条項などに別段の定めがなければ、法人の中に残るのが基本的な出発点です。ただし「何も変えなくてよい」という意味ではありません。取締役、実質的支配者、請求先、銀行口座、管理者、二要素認証、緊急連絡先、親会社ポリシーは変わります。ベンダーの規約や契約が支配権変更時の通知・同意を求める場合もあるため、契約ごとの確認が必要です。

技術面の利点は、本番環境の器を維持しやすいことです。一方で、譲渡企業が複数事業を同じAWSアカウント、GitHub Organization、Apple Developerアカウントで運用していると、買い手に法人全体の資産が見えてしまいます。クロージング前にアプリ事業の境界を作るカーブアウト作業が必要です。株式譲渡だから境界整理が不要なのではなく、「法人内に残す資産」と「譲渡企業側へ退避する資産」の向きが事業譲渡と逆になることがあります。

事業譲渡

事業譲渡では、契約に列挙した資産・負債・契約を個別に移します。コード、商標、ドメイン、アプリのストア上の地位、顧客データ、サブスクリプション、外注契約、クラウド環境が自動で一括移転するわけではありません。譲渡可能性、相手方の同意、個人情報の取扱い、税務上の扱い、従業員の転籍などを専門家と確認します。

技術実務では、共有アカウントから対象事業を切り出すことが中心です。方法は三つあります。第一は、既存のプロジェクトやアカウントをそのまま買い手へ移す方式。第二は、買い手の新規環境へデータと設定を複製して切り替える方式。第三は、一定期間は譲渡企業環境で運用し、移行サービス契約に基づいて段階的に分離する方式です。可用性、規約、費用、セキュリティ、分離の難しさを比較して選びます。

判断表

論点	株式譲渡で起きやすいこと	事業譲渡で起きやすいこと	譲渡企業が用意する証拠
法人名義の契約	法人内に継続。ただし支配権変更条項を確認	個別承継または新規契約	契約書、規約版、窓口、同意状況
ストア	同一法人なら管理者変更が中心	アプリ移管の資格確認と手続	アプリID、チームID、商品ID、実績
クラウド	アカウント継続が可能でも他事業分離が必要	アカウント移管か再構築	構成図、請求、IAM、IaC、バックアップ
顧客データ	管理主体は同じ法人だが方針変更を確認	移転根拠、通知、同意要否を確認	データ台帳、規約、同意記録、削除規程
人材	雇用主は原則同じ	転籍は個別同意などの検討が必要	職務表、契約、引き継ぎ時間、属人性
知的財産	法人保有なら残る	対象権利を特定して移す	登録簿、職務著作・譲渡証憑、OSS台帳

これは一般的な技術整理であり、法的効果は案件の契約、規約、法域、取引形態によって異なります。弁護士、税理士、弁理士などの専門家と個別に確認してください。

3. 最初に作る「技術資産・依存関係台帳」

台帳はアカウント一覧より広く作ります。各行を一つの資産またはサービスとし、少なくとも次の項目を持たせます。

資産名と用途
本番・ステージング・開発の区分
現在の契約名義、請求名義、支払手段
所有者、管理者、実務担当者、緊急連絡先
ログイン方式、二要素認証、復旧先。ただし秘密値そのものは安全な保管庫へ分離
ほかの資産との入力・出力・認証関係
利用データの種類、保存地域、保持期間、暗号化方式
月額・従量費、更新日、最低契約期間、解約予告期間
移管可否、同意要否、移管手順、想定日数
移管時の停止リスクとロールバック方法
契約上の対象・除外と、譲渡対価に含むか否か
完了証跡のURL、スクリーンショット、承認者

依存関係は「利用者端末→ストア→API→データベース」の主経路だけでは足りません。パスワード再設定メール、プッシュ通知、SMS認証、地図、広告計測、クラッシュ解析、カスタマーサポート、請求書、監視通知、バックアップの保存先まで矢印で結びます。一見すると周辺的なメール配信サービスが、ログイン復旧に必須であることは珍しくありません。

三分類を付ける

そのまま移る：対象アカウントやプロジェクトを、規約と契約に従って所有・管理ごと移せるもの。
移らない：譲渡企業の法人共通基盤、個人アカウント、譲渡禁止契約、他事業のデータが混在するもの。
移るが再設定が必要：アプリ本体は移るが、鍵、Webhook、請求、OAuth同意画面、サービスアカウント、組織ポリシーなどを更新するもの。

この分類に「未確認」を許すことが重要です。不明な資産を無理に移管すると決めつけず、公式サポートへの問い合わせ担当と期限を置きます。譲渡企業が早期に不明点を開示すると、買い手は代替策を用意できます。クロージング直前に発覚するより、価格や保証条件への悪影響を抑えられます。

4. App Store Connect／Apple Developerの承継

Appleの公式ヘルプは、アプリ移管後もApp Storeでの提供を維持し、評価やレビューを引き継げる一方、移管前後に譲渡元と譲受先がそれぞれ行う作業があると説明しています。アプリが移管基準を満たすか、関連機能や契約に固有条件がないかを確認し、譲渡元が開始、譲受先が受諾する流れです。詳細はApple公式「Overview of app transfer」およびリンク先の最新ページを実行時点で確認してください。

実務では、アプリのレコードだけを見るのではなく、Bundle ID、Team ID、証明書、Provisioning Profile、APNs、Sign in with Apple、キーチェーン共有、Associated Domains、App Groups、Game Center、CloudKit、TestFlight、アプリ内課金、サブスクリプション、App Store Server Notifications、共有シークレット、APIキー、レポート取得ジョブを一つずつ確認します。どの項目が移管に伴って維持され、どれが譲渡元または譲受先で再発行・再設定を要するかは、利用機能とその時点の仕様で異なります。

譲渡企業の事前チェック

Apple Developer Programの契約状態と、Account Holderが手続可能な状態か。
未処理の契約、税務、銀行情報、審査中バージョン、契約に影響する未解決事項がないか。
アプリ固有の識別子、SKU、Bundle ID、Apple ID、各環境のTeam IDを台帳に記載したか。
自動更新サブスクリプションとアプリ内課金の商品ID、価格、無料トライアル、猶予期間、通知URL、照合手順を記録したか。
プッシュ通知証明書またはトークン認証鍵を使う全サーバーを特定したか。
Sign in with Appleなど、移管後にユーザー識別子や鍵の移行対応を要する機能を洗い出したか。
Xcode Cloud、TestFlight外部テスター、クラッシュレポート、分析レポートをどう保全するか決めたか。
買い手が受諾に必要な組織情報と権限を準備したか。

典型的な障害例

アプリの移管自体は完了したのに、バックエンドが古いAPNs鍵を参照し続け、通知が届かなくなることがあります。別の例では、サーバー通知のURLや認証情報が更新されず、サブスクリプションの解約・更新イベントを取り込めません。利用者は課金済みなのに権限が付与されないため、売上と信用の双方を損ないます。移管前にサンドボックスで通知を発生させ、移管直後に本番の少額・社内テスト取引を照合する計画が必要です。

Apple関連の完了条件は、管理画面上の所有だけではありません。買い手のCIから署名付きビルドを生成でき、TestFlightへ上げられ、プッシュと課金通知を受け、次の審査提出に必要な役割がそろった状態です。

5. Google Play Consoleの承継

Google Playでは、別のデベロッパーアカウントへアプリを移管する公式手順があります。Google Play Consoleヘルプは、移管前に両アカウントの登録・状態を確認し、必要情報を用意して申請する流れと、移管に関連する項目を案内しています。実際の要件、移る情報と移らない情報、処理期間は変更され得るため、申請時点の日本語公式ページとコンソール表示を正としてください。

確認対象には、パッケージ名、デベロッパーアカウントID、登録取引ID、Google Play App Signing、アップロード鍵、アプリ署名鍵の管理方式、サービスアカウント、Google Play Developer API、Android Publisher API、サブスクリプション、定期購入の通知、リアルタイムデベロッパー通知、Google Cloud Pub/Sub、ライセンス、Play Integrity API、Firebase連携、広告SDK、ストア掲載情報、審査上の宣言が含まれます。

「鍵がある」と「リリースできる」は違う

Androidでは、Google Play App Signingを利用しているか、誰がアップロード鍵を保有するか、CIがどのキーストアを使うかを区別します。秘密値は平文のスプレッドシートに載せず、買い手側のSecrets管理へ登録し、アクセスログを残します。譲渡前に買い手環境で署名までのドライランを行い、譲渡後は内部テストトラックへ最小変更版を配布します。アップロード鍵の紛失や担当者退職が判明した場合は、直前まで待たず公式サポート手順を確認します。

よくある連携漏れ

Play Consoleのアプリは移っても、リアルタイム通知のPub/Subトピック、BigQuery連携、Firebaseプロジェクト、サービスアカウントの鍵、Google Cloudの請求先は別管理である場合があります。譲渡企業の共有Google Cloud組織に残すのか、プロジェクトごと移すのか、新規作成して接続し直すのかを明示します。ストア移管の日とクラウド移行の日が異なる場合、暫定的にどちらがイベントを受けるか、二重処理をどう防ぐかまで決めます。

6. GitHub Organization／Repositoryの承継

GitHubはリポジトリ移管の公式手順を公開しています。GitHub Docs「Transferring a repository」によれば、移管には権限や移管先の条件があり、リポジトリに関連する項目の扱いも確認が必要です。リポジトリURLのリダイレクトがあっても、それを恒久的な移行設計にしないでください。名称競合や将来の変更を想定し、全依存先を正式URLへ更新します。

コード承継の対象はGit履歴だけではありません。Issues、Pull Requests、Projects、Wiki、Releases、Packages、Container Registry、Actions、Deploy keys、Webhooks、Environments、Branch protection rules、Rulesets、CODEOWNERS、GitHub Apps、Dependabot、Secrets、変数、LFSオブジェクト、フォーク関係、外部CIとの接続を確認します。秘密値は多くの場合、画面から元の値を読み戻せません。譲渡企業が買い手へ値を「見せる」のではなく、新しい秘密値を買い手環境で発行し、切替後に古い値を失効させる方式が安全です。

Organizationごと渡すか、Repositoryを切り出すか

対象事業専用のOrganizationで、契約や請求も分離されているなら、所有者と請求管理の承継が候補になります。他事業のコードやメンバーが混在するなら、対象Repositoryを買い手Organizationへ移し、PackagesやActions依存を再構成します。モノレポの場合、履歴を保った分割が難しく、共通ライブラリの権利や継続提供も論点になります。共通部分を複製して譲渡するのか、ライセンス供与するのか、サービスとして一定期間提供するのかを契約と技術の両面で決めます。

買い手による再現テスト

クリーンな端末または一時環境で、READMEの手順だけを使い、依存取得、ビルド、単体テスト、静的解析、コンテナ作成、ステージング配備まで行います。「譲渡企業のノートPCでは動く」は証拠になりません。必要なランタイム、パッケージレジストリ、プライベート依存、環境変数、ライセンスファイルがすべて台帳化されているかを確認します。失敗ログは削除せず、引き継ぎ課題として所有者と期限を付けます。

7. AWSのアカウント境界を設計する

AWSでは、買い手のAWS Organizationsへアカウントを移す方法と、買い手の新規アカウントへワークロードを再構築・移行する方法を比較します。AWSは別組織へのアカウント移行に関する公式資料を公開しています。組織からの離脱・招待、請求、サポート、組織ポリシーなどの前提を実行時点で確認してください。

アカウント単位で移せると、ARN、リソースID、データ、エンドポイントを維持できる可能性が高まり、停止リスクを抑えられます。しかし、Service Control Policies、組織のCloudTrail、Security Hub、GuardDuty、AWS Backup、IAM Identity Center、共有VPC、Transit Gateway、Route 53、KMS、請求割引、Marketplace契約などが親組織に依存していると、単純な移籍では済みません。移管先で同等統制が働くか、検出とバックアップに空白が生じないかを検証します。

AWSチェックリスト

ルートユーザーのメール、電話、MFA、復旧経路を買い手管理へ変更する手順がある。
IAMユーザーの長期アクセスキーを棚卸しし、可能なものをロールと短期資格情報へ置換した。
Organizations、SCP、委任管理者、集中ログ、セキュリティ監視の依存を図示した。
KMSキーのキーポリシー、暗号化対象、削除待機、クロスアカウント利用を確認した。
S3バケットポリシー、CloudFront OAC、WAF、証明書、Route 53の関係を確認した。
RDS、DynamoDB、ElastiCache、OpenSearchなどの復元テストと所要時間を記録した。
Lambda、ECS、EKS、EC2の配備元、イメージレジストリ、AMI、起動テンプレートを特定した。
SESの送信ドメイン、サンドボックス状態、抑制リスト、DKIM、苦情処理を引き継ぐ。
Budgets、Cost Anomaly Detection、タグ、原価配賦、Reserved InstancesやSavings Plansの扱いを確認した。
サポートプラン、重大障害時の連絡方法、第三者MSPの契約を確認した。

再構築方式を選ぶ場合は、Infrastructure as Codeを先に整備し、データ同期期間を設けます。DNS切替の前に新旧環境へ同じリクエストを流すシャドーテストや、読み取りだけ新環境で検証する段階を置くと安全です。ただし二重書き込みは整合性事故を生むため、責任あるアーキテクトが設計し、停止窓、再試行、重複排除を定義します。

8. Google Cloud／Firebaseの承継

Google Cloudのプロジェクトを組織間で移行する場合、公式資料はプロジェクト移行がリソース階層上の親を変えるメタデータ操作である一方、移行先の継承IAM、組織ポリシー、クォータ、共有VPC、カスタムロールなどの影響を確認する必要があると説明しています。Google Cloud公式「Migrate projects between organization resources」を起点に、準備、実行、例外、事後作業の最新ページを確認してください。

Firebaseは一つの管理画面に見えても、実体はGoogle Cloudプロジェクトと複数サービスの組合せです。Authentication、Firestore、Realtime Database、Cloud Storage、Cloud Functions、Cloud Run、Hosting、Remote Config、Crashlytics、Analytics、Cloud Messaging、App Check、Extensions、BigQuery Export、サービスアカウント、OAuthクライアント、請求アカウントを分解します。

移管前に必ず見るポイント

Firebase Authenticationのプロバイダー設定と、メール送信ドメイン、SMS課金、OAuthのクライアントID・シークレット、許可済みリダイレクトURIを確認します。FirestoreとStorageはセキュリティルールとインデックスをエクスポートし、エミュレーターまたはステージングでテストします。Cloud Functionsはソース、ランタイム、環境変数、Secret Manager、トリガー、リージョン、サービスアカウントを記録します。Analyticsや広告連携は、プロパティの権限とデータ共有設定が別管理であることがあります。

プロジェクトIDが同じでも、親組織が変わると継承ポリシーが変わり得ます。移行直後に外部IP、許可リージョン、サービス利用制限、鍵作成制限、ドメイン制限が変わり、デプロイだけ失敗することがあります。Day 0の確認には「現在動いている」だけでなく、「次の配備が通る」「新しい担当者がログを読める」「請求アラートが買い手へ届く」を含めます。

9. DNS、ドメイン、CDN、TLS証明書

アプリはストアから配信されていても、API、Webサイト、Universal Links、メール、サポート、プライバシーポリシーがドメインに依存します。ドメイン登録者、レジストラ、DNSホスティング、権威ネームサーバー、DNSSEC、CDN、WAF、TLS証明書、証明書自動更新、WHOIS連絡先、更新用クレジットカードを分けて記録します。

ドメイン移管とDNS切替を同日に行う必要はありません。通常は、まず買い手にDNSの共同管理権限を与え、ゾーンをエクスポートし、TTLを段階的に短くし、新環境を検証します。次に必要なレコードだけを切り替え、安定後に登録者やレジストラを移します。すべてを同時に変えると、問題が登録者変更なのかDNSなのかCDNなのか判別しにくくなります。

レコード点検表

種別	見落とすと起きること	確認方法
A／AAAA／CNAME	APIやWebが到達不能	新旧応答、ヘルスチェック、TTL
MX	顧客メールが受信不能	外部から送受信、迷惑メール判定
SPF／DKIM／DMARC	なりすまし判定、到達率低下	DNSと送信サービス双方を照合
TXT認証	SaaSのドメイン所有確認が失効	由来と削除可否を台帳化
CAA	新しい証明書を発行できない	利用CAと自動更新ジョブを確認
NS／DS	DNSSEC不整合で名前解決不能	レジストラとDNS事業者を同時確認
Universal Links関連	アプリ内遷移がWebへ逃げる	実機でインストール前後を検証

ロールバックは旧環境を残すだけでは足りません。TTLが長い利用者、CDNキャッシュ、モバイル回線のDNSキャッシュを考慮し、新旧双方が一定期間リクエストを安全に処理できるようにします。証明書更新期限は90日以降に事故を起こしやすいため、移管後最初の自動更新が成功したログまで完了証跡にします。

10. CI/CD、証明書、署名鍵、Secrets

CI/CDは技術資産を事業価値へ変える生産ラインです。GitHub Actions、GitLab CI、Bitbucket Pipelines、CircleCI、Jenkins、Xcode Cloud、Codemagic、Fastlaneなど、どのサービスで何が起動し、どの権限でどこへ配備するかを一本の図にします。ワークフロー定義がリポジトリにあっても、ランナー、接続資格情報、環境保護ルール、承認者、キャッシュ、プライベートパッケージは外にあります。

秘密情報は「一覧をExcelで渡す」方式を避けます。秘密を次の三群に分類します。

再発行できるもの：APIキー、サービスアカウント、Webhook署名秘密など。買い手側で新規発行し、動作確認後に旧値を失効します。
移行手続が必要なもの：ストア署名、暗号化鍵、利用者ID連携など。公式手順と影響を確認し、二者承認で扱います。
再発行が困難なもの：データ復号に必要な鍵、古い署名資産など。ハードウェアまたは専用保管庫で厳格に移し、複製・受領・消去の証跡を残します。

Secretsのローテーション順序を誤ると停止します。基本は「新値発行→両方を受けられる移行状態→新値配備→利用確認→旧値無効化」です。データベースの資格情報を一つしか持てない場合は、短い停止窓か代理レイヤーを検討します。Webhookは送信側と受信側の変更順を合わせ、一定期間は新旧署名を検証できる設計が有効です。

11. 決済、サブスクリプション、売上照合

決済は最も「動いているように見えて壊れる」領域です。課金画面が成功しても、Webhookが届かず利用権が付かない、解約が反映されない、返金が会計へ流れない、売上が旧法人の口座へ入り続けることがあります。AppleとGoogleのアプリ内課金に加え、Stripe、PayPal、決済代行、銀行振込、請求書発行、クーポン、アフィリエイト、税計算を一つの収益フローとして確認します。

譲渡企業は商品ID、プラン、通貨、価格、税区分、無料期間、割引、従量課金、日割り、更新日、失敗時再試行、猶予期間、返金、チャージバック、未収金、前受収益を説明します。買い手は契約上の債権・債務の帰属と、技術上の入金先・台帳を一致させます。クロージング時刻をまたぐ取引を誰の売上とするか、遅延到着するイベントを誰が処理するかを事前に決めます。

Day 0決済テスト

新規購入が成功し、レシートまたは取引IDが保存される。
Webhookが正しい環境へ一回だけ届き、署名検証される。
利用権が付与され、別端末で復元できる。
解約・返金・更新失敗が正しい状態遷移になる。
売上レポート、決済台帳、銀行入金の照合担当が買い手側にいる。
顧客サポートが取引を検索し、返金ルールに沿って回答できる。

本番テストでは個人情報と会計処理が発生します。テスト用アカウント、少額取引、取消方法、証跡保管を経理・法務と合意して行います。

12. メール、SMS、地図、広告、OAuthなど外部サービス

外部SaaSは契約主体と技術主体がずれていることがあります。登録は譲渡企業法人でも、APIキーは開発会社が持ち、請求は代表者個人カード、ドメイン認証は別担当、という状態です。以下をサービスごとに確認します。

メール：送信ドメイン、IPレピュテーション、DKIM、バウンス、苦情、テンプレート、配信停止、抑制リスト。
SMS・電話：送信番号、本人確認、国別規制、テンプレート審査、レート制限、緊急連絡。
地図・位置情報：API制限、請求、利用規約、キャッシュ、位置情報同意、割当量。
広告・計測：広告アカウント、SDK、同意管理、IDFA・広告ID、コンバージョン、売上帰属。
OAuth：クライアントID、秘密、同意画面、確認済みドメイン、リダイレクトURI、公開アプリ審査。
AI・分析：学習・ログ利用条件、データ保存、モデル、利用上限、出力監視。
カスタマーサポート：メール取り込み、チャット、FAQ、チケット履歴、録音、SLA。

OAuthのクライアントを買い手名義で作り直すと、既存のリフレッシュトークンがそのまま使えない場合があります。利用者に再ログインを求める可能性、同意画面の再審査、段階的移行を検討します。外部サービスの仕様は変わるため、公式ドキュメントだけでなくサポート窓口に案件固有の可否を確認し、その回答をデータルームに保存します。

13. 監視、バックアップ、障害対応

引き継ぎ初日にアプリが動いていても、アラートが譲渡企業のSlackにしか届かなければ買い手は障害を知れません。監視対象、閾値、通知先、当番、エスカレーション、ステータスページ、保守ベンダー、復旧手順を引き継ぎます。メトリクスだけでなく、ログ、トレース、クラッシュ、合成監視、ジョブ遅延、証明書期限、請求急増、セキュリティ検知を含めます。

バックアップは「設定済み」ではなく「復元できた」で評価します。データベースのスナップショット、オブジェクトストレージ、設定、Secrets、ソース、監査ログについて、RPO、RTO、保存期間、保存地域、暗号化鍵、削除権限を記録します。ランサムウェアや誤操作を想定し、本番管理者でも消しにくい保管先を検討します。買い手の担当者がステージングへ復元し、件数・ハッシュ・主要画面を確認する演習を行います。

最初の障害対応を契約前に練習する

想定シナリオは「APIの5xx率上昇」「決済通知の停止」「ログインメール不達」「証明書期限切れ」「DB接続枯渇」などから選びます。アラート発生から、一次切分け、顧客影響判定、暫定回避、社内外連絡、復旧、再発防止までを時計で測ります。譲渡企業が答えを言わず、買い手がRunbookを使って進めます。30分で連絡先が見つからない、権限申請に翌営業日かかる、ログ保存が短く原因を追えない、といった弱点をクロージング前に直します。

14. OSS、ライセンス、SBOM

アプリは多数のオープンソースソフトウェア、SDK、フォント、画像、学習済みモデル、商用ライブラリで構成されます。買い手はコードを取得すると、ライセンス順守、脆弱性対応、著作権表示、ソース提供義務などの運用も承継します。譲渡企業は依存パッケージの名前・バージョン・取得元・ライセンス・利用箇所・修正有無・脆弱性・更新責任を整理します。

SBOMは構成要素を機械可読に把握する助けになります。IPAは「SBOM導入・運用の手引き」などを公開しています。形式を作ること自体が目的ではなく、脆弱性が公表された際に「どの製品・バージョン・顧客へ影響するか」を迅速に判断する運用まで設計します。

OSS確認手順

各リポジトリ、コンテナ、モバイルアプリ、サーバーレス関数から依存を抽出する。
ロックファイルと実際のビルド成果物を照合し、開発依存と本番同梱を区別する。
ライセンス表示、NOTICE、改変、静的・動的リンク、配布形態を専門家と確認する。
商用SDKの契約名義、利用数、譲渡可否、最低期間、監査条項を確認する。
重大脆弱性の通知先、評価期限、修正版リリース責任をRACIへ入れる。
SBOMをリリースごとに更新し、署名・保管・閲覧権限を決める。

買い手から指摘される前に不足を示し、改善計画を提示する方が信頼につながります。古い依存があること自体より、誰も影響を判定できないことが大きなリスクです。

15. 個人情報とデータ承継

データは「DBをコピーすれば移る」ものではありません。氏名、メール、端末識別子、位置情報、行動ログ、課金履歴、問い合わせ、録音、広告識別子、Cookie、認証情報について、取得目的、同意、保存場所、第三者提供・委託、国外移転、保持期間、削除請求、バックアップ残存を台帳化します。匿名化・仮名化したデータも再識別可能性と契約上の扱いを確認します。

事業譲渡では、個人情報の承継根拠、利用目的の範囲、通知や公表、プライバシーポリシー変更、委託先との契約を法務専門家と検討します。株式譲渡でも、利用目的や提供先、アクセス主体、統合後の利用が変わるなら同様に検討が必要です。M&Aの秘密保持と、利用者への適切な説明を両立するため、通知時期・文面・問い合わせ窓口を契約日程に組み込みます。

技術面では、データエクスポートの暗号化、受渡経路、ハッシュ照合、アクセスログ、買い手側取込後の権限、譲渡企業側残存データの削除・法定保管を決めます。「譲渡企業はすべて削除」と一文で済ませず、本番、レプリカ、分析基盤、ログ、バックアップ、ローカル端末、チケット、メール添付まで対象を分解します。削除証明の範囲と、障害調査・法的義務のため残す例外を合意します。

16. 開発端末、社内ネットワーク、物理資産

小規模なアプリ会社では、署名用Mac、検証端末、SIM、ハードウェアMFAキー、NAS、ルーターに重要資産が残ります。端末を譲渡する場合、所有権、リース、資産番号、暗号化、MDM、Apple ID・Googleアカウント、ローカル鍵、ブラウザセッション、顧客データを確認します。端末を渡さない場合は、必要な証明書や設定を安全に移し、譲渡企業端末から消去した証跡を残します。

検証端末はOSバージョン、機種、画面サイズ、地域設定、アクセシビリティ、課金テストアカウントと対応づけます。古いOSでしか再現しない障害があるなら、端末そのものが運用資産です。SIMや電話番号が二要素認証、SMS送信、ストア登録に使われていないかを確認します。代表者個人の電話番号に依存している場合は、法人管理の番号と複数人で復旧できる方式へ移します。

17. 顧客サポートと運用知識

コードにない知識が事業を守っています。「この顧客だけ旧料金」「このCSVは月末に手作業で直す」「審査リジェクト時はこの説明を出す」「障害時に大口顧客へ先に電話する」といった暗黙知です。チケット分類、返信テンプレート、エスカレーション、返金権限、本人確認、迷惑行為対応、障害告知、SLA、営業時間を文書化します。

譲渡企業は頻出問い合わせを件数、原因、解決時間、再発防止とともに渡します。買い手は、実際の匿名化チケットを使って回答演習を行います。技術担当者しか答えられない質問は、プロダクト仕様書に記載するか、管理画面の機能として実装します。サポートツールを新規契約へ移す場合、過去履歴の検索性、添付、顧客IDの対応、削除要求の追跡を検証します。

18. RACIで責任の空白をなくす

RACIは、各作業について実行責任者Responsible、最終説明責任者Accountable、協議先Consulted、報告先Informedを定める表です。譲渡企業・買い手・開発会社・M&Aアドバイザー・弁護士・クラウド支援会社が関わるほど、「誰かがやるだろう」が増えます。一つの作業に最終説明責任者を原則一人置き、期限と証跡を結びます。

作業	R：実行	A：最終責任	C：協議	I：報告
App Store移管資格確認	譲渡企業CTO	譲渡企業代表	買い手技術、法務	PMO
買い手クラウド受入準備	買い手SRE	買い手CTO	譲渡企業技術、クラウド支援	経営・PMO
顧客データ移転判断	法務・セキュリティ	各社経営責任者	DPO、技術、専門家	サポート
DNS切替	買い手SRE	統合責任者	譲渡企業SRE、CDN事業者	全関係者
Day 0障害判定	当番責任者	買い手CTO	譲渡企業CTO、サポート	経営・顧客窓口
旧Secrets失効	買い手セキュリティ	買い手CISO	譲渡企業技術	監査・PMO
譲渡企業残存データ削除	譲渡企業管理者	譲渡企業代表	法務、買い手	監査

RACIは契約書の責任分担と矛盾させません。移行支援契約に営業時間、時間上限、成果物、緊急対応、追加費用、免責、知的財産、再委託を定め、RACIは日々の実行表として運用します。

19. T-60からDay 90までのカットオーバー計画

T-60〜T-31：発見と境界確定

全資産台帳、データフロー、構成図、契約一覧、費用一覧、権限一覧を作ります。買い手がクリーン環境でビルドし、ステージングを再現します。ストア、クラウド、決済、外部APIへ移管可否を問い合わせます。共有アカウントと個人依存を特定し、取引対象・除外・一時利用を契約担当へ返します。重大な未解決事項は価格だけでなく、前提条件、補償、移行サービスへ反映します。

T-30〜T-8：二重化とリハーサル

買い手のID基盤、Secrets保管庫、監視通知、請求、サポート窓口を用意します。新しい鍵を発行し、可能な範囲で新旧併用します。データ移行の時間と差分量を測り、バックアップ復元、DNS切替、ストア操作、初回リリースをリハーサルします。ロールバックの判断者、判断期限、データ巻戻し方針を合意します。顧客・従業員・ベンダーへの通知文を準備します。

T-7〜T-1：変更凍結と最終判定

緊急修正以外のリリース、スキーマ変更、料金改定、キャンペーン、主要SDK更新を凍結します。凍結例外は統合責任者が承認します。未完了項目を赤・黄・緑で判定し、赤が残る場合の延期または代替策を経営が決めます。連絡網、会議URL、電話、ステータスページ、ベンダーのサポート番号を一枚にします。旧環境のバックアップを取得し、復元可能性とハッシュを確認します。

Day 0：権利移転と統制切替

契約上のクロージング確認後、予定した順序で管理権限、請求、ストア、ドメイン、クラウド、サポートを切り替えます。作業者と承認者を分け、各操作の時刻、画面、チケット番号を記録します。監視ダッシュボードにエラー率、レイテンシ、購入、ログイン、通知、問い合わせ量を並べます。無関係な大規模変更を同時に行いません。

Day 1〜7：ハイパーケア

買い手を一次対応、譲渡企業を期限付き二次支援とし、毎日短いレビューを行います。未処理Webhook、売上差異、配信失敗、権限エラー、問い合わせ傾向を確認します。旧Secretsを一気に消すのではなく、アクセスログで利用がないことを確認して順次失効します。最初の本番リリース候補を、小さく可逆的な変更として準備します。

Day 8〜30：初回リリースと独力運用

買い手のアカウント、端末、CI/CD、署名、承認だけで初回リリースを行います。変更は表示文言、ログ追加、軽微な不具合修正など影響を限定し、ビルドからロールバックまでの経路を確かめます。譲渡企業が操作しない障害演習とバックアップ復元を実施します。残課題、暫定権限、技術負債を新しい運用バックログへ移します。

Day 31〜90：分離完了と監査

譲渡企業のユーザー、鍵、VPN、端末、転送メール、共有チャットを閉じます。移行サービスの成果物と工数を確認し、未解決項目の所有者を買い手へ一本化します。最初の月次請求、サブスクリプション更新、証明書更新、バックアップ世代交代、脆弱性対応を買い手が完遂したか確認します。譲渡企業側の残存データを合意した範囲で削除し、例外保管を記録します。

20. ロールバックは「戻す対象」を分ける

ロールバックには、アプリバージョン、API配備、データベース、DNS、認証、決済、権限、組織移管という異なる層があります。すべてを同じ時点へ戻せるとは限りません。ストアや組織間移管は、ボタン一つで即時に戻せないことがあります。そこで「技術ロールバック」と「業務継続の代替措置」を分けます。

たとえばDNSを旧APIへ戻せても、新環境で受けた注文データは旧DBにありません。単純に戻すと注文が消えます。書き込み停止、差分抽出、重複排除、顧客告知を含むデータ計画が必要です。認証障害では、旧環境へ戻すより、新規ログインだけ一時停止して既存セッションを維持する方が影響を抑えられる場合があります。決済障害では購入ボタンを止め、既存利用者の権利を維持する方針が考えられます。

ロールバック判断票

質問	例
判断期限はいつか	DNS切替後60分、データ差分が安全に統合できる間
誰が決めるか	買い手CTO。連絡不能時の代行者も指定
発動条件は何か	5xxが5分平均5％超、購入不整合が規定件数超
戻す層はどこか	APIだけ、DNSだけ、リリースだけ。権利移転は維持
失う可能性のあるデータ	切替後の注文、問い合わせ、セッション
利用者への説明	影響、回避策、復旧見込み、次回更新時刻
再実行の条件	原因特定、修正、再リハーサル、経営承認

21. 初回リリースを承継の受入試験にする

初回リリースは新機能競争ではなく、承継経路の試験です。要件を小さくし、コードレビュー、テスト、署名、内部配布、審査、段階公開、監視、停止を買い手チームだけで通します。譲渡企業は質問への回答にとどめ、実操作は買い手が行います。

受入基準は、再現可能なビルド、テスト成功、成果物の署名検証、SBOM生成、承認ログ、ストア提出権限、リリースノート、監視ダッシュボード、クラッシュ率、問い合わせ対応まで含めます。iOSとAndroidの一方だけを先に実施する場合も、もう一方の期限を残します。Webアプリはカナリアまたは段階公開を使い、戻し方を実演します。

22. データルームに置く技術証跡

良い資料は、口頭説明を置き換え、買い手の確認時間を短くします。ただしパスワードや本番データを無制限に置いてはいけません。段階的な開示、閲覧権限、透かし、アクセスログ、秘密情報の別経路を設計します。

推奨フォルダー

システム全体図、ネットワーク図、データフロー図
技術資産・契約・費用・権限台帳
リポジトリ一覧、ビルド手順、テスト結果、リリース履歴
クラウド構成、IaC、監視、バックアップ、復元結果
ストア設定、課金商品、通知、審査・障害履歴
セキュリティ方針、脆弱性診断、インシデント、アクセスレビュー
OSS・商用ライセンス・SBOM・著作権証憑
データ台帳、規約、プライバシーポリシー、委託先
サポートRunbook、FAQ、SLA、主要顧客固有運用
移行計画、RACI、リハーサル結果、完了証跡

古い図を美しく整えるより、更新日と現状との差分を明記する方が有用です。「未確認」「手作業」「単一障害点」を隠さず、改善案、費用、期限を付けます。買い手がリスクを定量化できれば、不確実性を理由に価格を大きく保守化する必要が減ります。

23. 障害例から学ぶ設計上の要点

障害例A：所有者メールが退職者の個人アドレス

管理画面には入れていたため問題視されませんでしたが、不審ログインでロックされ、復旧メールが退職者へ送られました。対策は、契約名義、所有者、復旧経路、日常管理者を別項目で棚卸しし、法人管理のグループメール、複数人MFA、緊急コードの保管を整えることです。

障害例B：サブスクリプション通知の二重処理

新旧バックエンドが同じ通知を受け、利用期間延長が二重に記録されました。対策は、イベントIDによる冪等性、処理主体の切替時刻、キューの滞留確認、旧受信側の読み取り専用化です。M&A移行を機に、日常の再送にも耐える設計へ直せます。

障害例C：クラウド移籍後に次のデプロイだけ失敗

稼働中リソースは正常でしたが、移行先組織のポリシーで外部コンテナ取得が禁止され、新しいビルドが配備できませんでした。対策は、移行前に継承ポリシーとクォータを差分比較し、買い手環境から実際に配備する受入試験を行うことです。

障害例D：DNSのTXTを不要と判断して削除

用途不明のTXTを整理したところ、メール送信サービスのドメイン認証が外れ、到達率が急落しました。対策は、レコードの由来、担当サービス、追加日、削除確認先を台帳にし、未知のレコードを推測で消さないことです。

障害例E：バックアップはあるが鍵がない

暗号化バックアップを買い手へ渡したものの、復号鍵が譲渡企業組織のKMSから使えませんでした。対策は、バックアップと鍵の可用性を別々に検証し、買い手が復元してデータを読めるところまで試すことです。

24. データベース、キュー、検索、バッチの「見えない状態」を渡す

画面とAPIが同じ応答を返しても、内部状態が正しく承継されたとは限りません。データベースには主データのほかに、未処理ジョブ、遅延キュー、検索インデックス、キャッシュ、セッション、集計途中データ、外部連携の再試行状態があります。クロージング直前のスナップショットだけを移すと、注文は入っているのに通知ジョブが欠ける、解約イベントを再送できない、検索結果だけ古い、といった不整合が生じます。

最初に各ストアの「正本」を決めます。会員状態はRDB、検索表示は検索エンジン、セッションはRedis、分析はデータウェアハウス、というように、同じ項目が複数箇所にある理由と再生成方法を明記します。派生データをすべて移すより、正本から再構築した方が安全な場合があります。ただし再構築に数日かかる、API割当量を超える、過去の変換ロジックが失われている場合もあるため、実測します。

状態別の受入確認

対象	確認する状態	譲渡企業が説明すること	買い手の試験
RDB	件数、外部キー、レプリカ、シーケンス	正本、整合性制約、手動修正履歴	リストア後の件数照合と主要取引再現
オブジェクト	世代、メタデータ、公開範囲	命名、ライフサイクル、削除	ランダム抽出のハッシュと権限確認
キュー	未処理、失敗、可視性タイムアウト	冪等性、再送、破棄条件	重複イベントと毒メッセージ処理
検索	インデックス版、同期遅延	再構築方法、同義語、辞書	全件再索引と代表検索の比較
キャッシュ	TTL、無効化、セッション	消してよい領域、温め方	全消去時の負荷とログイン維持
バッチ	前回・次回、排他、締め時刻	営業日、再実行、手補正	途中失敗からの再開と二重計上防止
分析基盤	到着遅延、再処理、個人情報	指標定義、除外、保存期間	前月値の再計算とダッシュボード照合

タイムゾーンも重要です。ストア売上は地域や締め時刻が異なり、サーバーはUTC、経理は日本時間、利用者は各地域ということがあります。Day 0を「日付」だけで定めず、秒単位の基準時刻、夏時間、イベント発生時刻と受信時刻のどちらで帰属させるかを決めます。

データ移行後は総件数だけでなく、業務上重要な不変条件を検証します。「有料会員数は課金中契約数と一致する」「注文合計は明細合計と一致する」「削除済み利用者は検索・分析にも出ない」「一つの外部取引IDは一度だけ計上される」といった条件です。差異が出たら、許容範囲、原因、補正方法、承認者を記録します。

25. IAMとセキュリティ統制を二段階で切り替える

M&Aの情報管理では、交渉中の秘密保持と、クロージング後の迅速な支配移転を両立させます。早くから買い手へ本番管理者権限を渡すと、未成立時の情報漏えい・操作リスクが高まります。一方、Day 0まで何も見せないと、買い手は受入試験ができません。そこで権限を「閲覧・検証段階」と「運用・変更段階」に分けます。

検証段階では、匿名化した構成、読み取り専用ログ、ステージング、限定データ、画面共有、第三者レポートを用います。本番データへアクセスが必要な場合は、目的、対象、時間、端末、ダウンロード可否、監督者、ログを定めます。クロージング条件が満たされた時点で、買い手の法人IDに管理権限を付与し、譲渡企業側の権限は期限付きの支援用ロールに変更します。共有IDは避け、誰が何をしたか追える状態を保ちます。

権限レビューの観点

人：現役社員、退職者、業務委託、開発会社、会計、サポート、緊急用アカウント。
機械：CI/CD、サービスアカウント、Bot、監視、バックアップ、データ連携、RPA。
経路：VPN、踏み台、ゼロトラスト、IP許可、端末証明書、SSH鍵、リモート管理。
特権：ルート、Organization Owner、請求管理、鍵管理、監査ログ削除、バックアップ削除。
復旧：メール、電話、MFA、回復コード、本人確認書類、ドメイン所有証明。
期限：一時権限の自動失効、譲渡企業支援終了日、退職者削除日、鍵ローテーション日。

クロージング直後に全鍵を同時ローテーションすると、依存を見落とした際に原因が分からなくなります。危険度と利用頻度で順序を付けます。外部公開された可能性のある長期キー、退職者のキー、ルート復旧経路を優先し、アプリ内部に埋め込まれ更新に審査を要する値は計画的に移します。各ローテーション後に監視し、旧値が使われたログがあれば呼び出し元を特定します。

セキュリティ事故の責任分界も切替時刻を定めます。侵害がDay 0以前に始まり、Day 10に発見される場合があります。ログの保全、調査協力、当局・利用者への連絡、費用負担、サイバー保険の通知を法務・保険担当と確認します。技術チームは、ログの時刻同期、保存期間、改ざん防止、証拠取得の手順を用意します。

26. 日次・週次・月次運用をカレンダーごと引き継ぐ

文書がそろっても、定期作業の時期を逃すとサービスは止まります。そこで「運用カレンダー」を作り、周期、締切、休日対応、入力、出力、承認者、失敗時対応を記録します。買い手の会計・労務・セキュリティの周期と統合し、最初の一周を完了するまで譲渡企業の知見を利用します。

日次運用

朝に前日売上、決済差異、エラー率、バックアップ、ジョブ失敗、問い合わせ滞留、ストアレビューを確認します。担当者の「いつもの見方」を録画だけで済ませず、異常とみなす閾値、除外する既知ノイズ、誰へ連絡するかを文章にします。休日にしか起きないバッチや、月初だけ増える負荷も履歴から説明します。

週次運用

リリース会議、脆弱性確認、依存更新、容量予測、サポート傾向、広告費、解約理由を見ます。買い手は譲渡企業の指標名をそのまま受け取らず、SQLや集計条件まで確認します。「アクティブ」の定義がログインか取引かで企業価値の読み方が変わるためです。ダッシュボードに注釈を付け、障害、キャンペーン、計測変更の影響を残します。

月次・年次運用

ストア・決済・銀行の照合、請求書、前受収益、クラウド予算、アクセスレビュー、バックアップ長期保管、SLA報告、ライセンス更新を行います。年次ではDeveloper Program、ドメイン、証明書、商標、保険、外部監査、ペネトレーションテスト、データ削除、BCP訓練などがあります。更新通知メールだけに依存せず、買い手のチケットシステムへ期限を登録します。

最初の90日以内に到来しない年次作業も、買い手が実行できるか机上演習します。たとえばドメイン更新が10か月後でも、登録者メールと支払手段を今確認します。署名証明書の更新が半年後なら、CSR作成、承認者、配備箇所を今記録します。期限が遠い資産ほど、引き継ぎ完了後に忘れられます。

27. 技術スケジュールを契約条件へ翻訳する

技術チームが「移管できる」と言うとき、法務は何をもって完了かを確認する必要があります。反対に契約書が「一切のシステムを引き渡す」と書いても、技術側は対象を実行可能な単位へ分解しなければなりません。資産別の技術台帳と契約別紙を同じ識別番号で結びます。

契約に反映を検討する代表的な項目は、譲渡対象・除外資産、知的財産の帰属、第三者ライセンス、個人情報、データの形式と基準時刻、移行支援、前提条件、クロージング後のアクセス、残存データ削除、障害時協力、表明保証、補償、秘密保持、費用です。具体的な文言と法的効果は弁護士へ相談します。

技術未解決事項をすべて表明保証へ押し込むと、譲渡企業は制御できない将来リスクまで負うおそれがあります。代替として、クロージング前の是正条件、対価の一部留保、特定補償、移行サービス、買い手による受容、価格調整など複数の方法があります。何が事実として確認済みで、何が推定で、何が未確認かを分けると、適切な交渉手段を選びやすくなります。

技術完了証明の例

買い手管理者が対象サービスへログインし、権限表と一致した。
買い手CIで特定コミットから再現可能な成果物を生成した。
ステージングと本番の主要ユーザーフローが受入基準を満たした。
バックアップを買い手側で復元し、整合性条件を満たした。
ストア、クラウド、ドメインなど第三者の移管受付・完了通知を保存した。
新旧Secretsの切替と旧値失効を監査ログで確認した。
譲渡企業権限と残存データの閉鎖を、例外一覧を除き確認した。

証拠はスクリーンショットだけでなく、チケット、ログ、ハッシュ、署名済みチェックリスト、第三者メールを組み合わせます。画面表示は後から変わるため、実施日時、実施者、対象ID、結果を残します。

28. 小規模チーム・ひとり開発の現実的な進め方

専任SREや法務がいない事業では、理想的な資料を一度に作るのは困難です。優先順位は、停止すると売上・データ・利用者へ直結する経路から付けます。第一週はドメイン、ストア、クラウド、リポジトリ、決済の所有と復旧経路。第二週はクリーンビルド、監視、バックアップ復元。第三週はデータ、外部API、サポート、定期作業。第四週はRACI、Day 0、ロールバックのリハーサル、というように区切ります。

資料は新しい文書を大量に作るより、現に使うRunbookと自動出力を整えます。構成図をコードやクラウド情報から更新し、依存一覧をビルドで生成し、アクセスレビューを定期チケット化します。動画は操作の文脈を伝えるのに有効ですが、検索しにくく更新されにくいため、要点、前提、失敗時対応を短い文書でも残します。

代表者が開発者を兼ねる場合、自分が突然連絡不能になった想定で「一週間代理運用」を実施します。別の人がアラートを受け、問い合わせに答え、定期ジョブを確認し、ステージングへ配備します。止まった箇所を順に直せば、M&Aのためだけでなく、日常の経営リスクを減らせます。

外部開発会社へ依存する場合は、ソースと成果物だけでなく、契約上の著作権、再委託、担当者、環境、アカウント、保守時間、引き継ぎ協力を確認します。買い手が同じ会社との継続を希望しても、契約は自動承継されない場合があります。早い段階で秘密保持に配慮しながら継続条件と代替要員を検討します。

29. 企業向けアプリ固有のSSO・テナント・監査を引き継ぐ

BtoBアプリでは、一般ユーザーのログインだけでなく、顧客企業ごとのテナント、管理者、SSO、SCIM、IP制限、監査ログ、保存期間、個別契約があります。買い手は、コードとDBを受け取っても、各社の設定・約束を理解できなければ更新や障害対応ができません。

テナント台帳には、契約ID、プラン、ユーザー数、認証方式、IdP、証明書期限、属性・グループ対応、プロビジョニング、ドメイン、IP、データ地域、保持、監査、個別機能を載せます。顧客担当者の個人情報は権限を限定し、初期の買い手候補へ無制限に開示しません。

SSOは、SAMLやOpenID Connectという方式名だけでは足りません。Entity ID、リダイレクトURI、証明書、メタデータ、署名、暗号化、時刻ずれ、緊急ローカル管理者、退職者削除を確認します。アプリやドメインの所有主体が変わることで識別子を変える場合、顧客側の変更作業とテストが必要です。全顧客をDay 0に変えず、旧設定を維持できる期間と段階移行を検討します。

SCIMなどの自動プロビジョニングでは、買い手のテストで誤った無効化を大量実行しないよう、ステージングまたは限定グループを使います。監査ログは誰が何を閲覧・変更・エクスポートしたかを保持し、買い手のSIEMへ接続しても顧客契約の保存期間を守ります。

マルチテナントでは、一社の設定変更やデータ処理が他社へ影響しないことが最重要です。データ移行後、テナント境界、キャッシュキー、検索インデックス、ファイルパス、バックアップ復元をテストします。顧客別の暗号鍵を使う場合は、鍵とデータの対応を失わないようにします。

企業顧客への変更管理

大口顧客は、運営会社変更、データ取扱い、再委託、インフラ、サポート、脆弱性窓口について事前説明や審査を求める場合があります。営業・法務・セキュリティが同じ回答を使い、未決定事項を確定のように伝えません。買い手の統制が強化になる場合も、実装完了時期を正確に示します。

30. クラウド費用・請求・割当量をサービス停止リスクとして扱う

技術引き継ぎでは、請求を経理事項として後回しにしがちです。しかし支払カードの失効、請求アカウントの切断、予算上限、クォータ不足は、コード不具合と同じようにサービスを止めます。クラウド、ストア、メール、SMS、地図、監視、CDN、ドメイン、証明書について、請求主体、支払手段、締め日、税、通貨、上限、アラートを台帳化します。

譲渡企業の企業契約やボリューム割引が、買い手へそのまま移るとは限りません。AWSのSavings Plans、Reserved Instances、Enterprise Discount、Google Cloudの契約、外部APIの個別単価、メールの専用IPなどを確認します。買い手の契約へ統合すると単価が下がる場合も、最低利用やサービスクレジットが変わる場合もあります。

費用は月額合計だけでなく、サービス・テナント・機能・環境・データ転送へ分けます。無料枠や譲渡企業の他事業との共用で低く見えていた費用を、独立運用へ正常化します。買い手環境へデータを出す際のエグレス、二重稼働、ログ保存延長、サポートプラン、セキュリティツールも移行予算へ入れます。

請求切替の確認

新しい支払手段と請求先を、本番停止前に検証した。
請求連絡、予算超過、カード失敗、契約更新が複数の買い手担当へ届く。
クォータ、レート制限、送信上限、同時実行、ストレージ上限を新旧で比較した。
譲渡企業側へ遅れて届く利用料・返金・税の精算方法を決めた。
二重稼働終了日と、旧リソース削除前のログ・バックアップ保存を決めた。
想定外費用が発生しても、自動停止で顧客影響を出す前に承認できる。

Day 30とDay 90に、実際の請求を予算と照合します。移管直後はログ量、データ同期、キャッシュ再構築で費用が一時増えることがあります。異常な鍵漏えい・不正利用との違いを監視します。

31. カットオーバー総合リハーサルの台本

個別テストが成功しても、同じ日に複数作業が重なると失敗します。総合リハーサルでは、本番と同じ参加者、順序、連絡、判断で、ステージングまたは複製環境を切り替えます。開始時刻と終了時刻を記録し、計画に余白を入れます。

リハーサル開始前

対象バージョン、データ時点、バックアップ、担当者、連絡網、変更凍結を確認します。買い手の管理者がログインし、MFAと緊急復旧を試します。監視ダッシュボード、問い合わせ窓口、ベンダーサポートを開いておきます。

実行順序

まずデータ差分を同期し、書き込みの扱いを確認します。次にSecretsと外部接続を新環境へ向け、内部ヘルスチェックを行います。DNS・CDNまたはルーティングを限定割合から切り替えます。ログイン、検索、保存、購入、通知、メール、管理画面、バックアップを代表ユーザーで試します。ストア操作が本番でしかできない場合は、画面・入力・承認・撤回条件を机上で読み合わせます。

障害注入

一つの依存を意図的に失敗させ、買い手が監視で検知し、Runbookを使い、意思決定者へ連絡できるかを見ます。メール不達、Webhook重複、DB接続拒否、証明書警告、権限不足などです。本番データを危険にしない環境で行います。

終了判定

機能成功だけでなく、未処理キュー、売上照合、ログ、アラート、問い合わせ、費用、データ整合を確認します。失敗は誰かを責めず、台本、権限、時間、依存の不足として記録します。重大な赤が残れば、本番日を延期する権限を経営者が持ちます。

総合リハーサルを一度で合格させる必要はありません。二回目で譲渡企業の助言を減らし、三回目は買い手だけで完了する形が理想です。本番Day 0では、リハーサル後に追加された変更を明示し、未知の作業を混ぜません。

32. 譲渡企業の最終チェックリスト

事業境界

対象アプリ、Web、API、管理画面、データ、ブランドを契約上の資産と対応づけた。
共通基盤・共通コード・共通社員について、譲渡、ライセンス、一時提供、除外を決めた。
株式譲渡または事業譲渡に応じ、移るもの・移らないもの・再設定するものを分類した。
ベンダー同意、通知、譲渡禁止、支配権変更条項を専門家と確認した。

技術

買い手がクリーン環境でビルド、テスト、配備できた。
App Store、Google Play、GitHub、クラウドの最新公式要件を確認した。
ドメイン、DNS、CDN、証明書の自動更新を把握した。
CI/CDの外部依存、ランナー、Packages、Secretsを移した。
監視通知が買い手に届き、Runbookで一次対応できた。
バックアップを買い手環境へ復元し、RPO・RTOを測った。
OSS、商用SDK、フォント、画像、モデルの権利とSBOMを確認した。

データと顧客

個人情報の種類、目的、保存場所、保持、削除、委託先を台帳化した。
利用規約・プライバシーポリシーの変更と通知を専門家と確認した。
課金、返金、サブスクリプション更新、売上照合を試験した。
サポート履歴、FAQ、特別対応、エスカレーションを渡した。

Day 0以降

T-60からDay 90までの責任者、期限、証跡がある。
ロールバックの条件、期限、データ影響、意思決定者が決まっている。
買い手だけで初回リリースと障害演習を完了する日を決めた。
旧アカウント、鍵、転送、端末、残存データを閉じる条件がある。

33. よくある質問

Q1．アプリのソースコードを渡せば事業譲渡は完了しますか

完了しません。ビルド環境、ストア上の地位、署名、クラウド、DB、ドメイン、決済、顧客データ、外部API、監視、サポート、知的財産の根拠が必要です。買い手が自社権限だけでリリースと障害対応を行えるかを完了基準にしてください。

Q2．株式譲渡なら技術移行は不要ですか

法人は同一でも、管理者、支払、MFA、緊急連絡、親会社ポリシーが変わります。他事業と共有する資産の分離や、支配権変更条項の確認も必要です。事業停止を避ける計画は株式譲渡でも重要です。

Q3．AppleとGoogleの移管は同じ日に行うべきですか

必ずしも同日である必要はありません。要件、処理期間、審査状態、連携サービスが違うため、全体のカットオーバー計画で順序を決めます。一時的に所有者が分かれる期間のサポート、課金、リリース権限を明記します。

Q4．個人のApple IDやGoogleアカウントをそのまま渡せますか

個人アカウントの共有は、規約、復旧、セキュリティ、退職時管理の問題を生みます。公式の組織・移管機能と法人管理のIDを利用し、実行時点の規約を確認してください。秘密値をメールで送る方法も避けます。

Q5．GitHubのSecretsはリポジトリ移管で読めますか

秘密値は通常、登録後に平文で読み戻す前提ではありません。移管時の具体的扱いを公式資料で確認しつつ、原則として買い手が新しい値を発行して登録し、動作後に旧値を失効させます。

Q6．AWSアカウントごと売れば簡単ですか

ワークロードの識別子を維持しやすい利点はありますが、親OrganizationsのSCP、集中ログ、請求割引、共有ネットワーク、KMS、セキュリティ統制への依存があります。ルート復旧経路や他事業データの混在も確認が必要です。

Q7．Firebaseプロジェクトを渡せばGoogle連携も全部移りますか

一括とは限りません。OAuth、Analytics、広告、BigQuery、請求、サービスアカウント、組織ポリシーなどは別の管理・影響があります。機能別に権限とデータフローを点検します。

Q8．クロージング直前まで開発を続けてもよいですか

緊急修正を除く変更凍結期間を設けるのが安全です。大きなスキーマ変更やSDK更新を同時に行うと、障害原因と責任が判別しにくくなります。例外承認と反映記録を残します。

Q9．譲渡企業はいつアクセスを削除すべきですか

すべてをDay 0に消すのではなく、契約上の移行支援とリスクに応じて段階化します。ただし期限のない共有は避けます。買い手の独力運用、初回リリース、監視、復元を確認し、Day 90など明確な期限で閉じます。

Q10．バックアップの受渡しだけで十分ですか

不十分です。買い手が復号し、買い手環境へ復元し、件数・整合性・アプリ動作を確認する必要があります。鍵、保持、削除、個人情報、復元所要時間も併せて評価します。

Q11．技術負債が多いと売却できませんか

技術負債があることと、状態が分からないことは別です。影響、優先度、改修費、回避策、担当を示せれば、買い手は評価できます。隠した問題が後で見つかる方が、信頼、価格、表明保証へ大きく影響します。

Q12．移行支援は無償で含めるべきですか

一律ではありません。期間、営業時間、上限時間、成果物、緊急対応、追加費用、責任、再委託を明確にして、対価や譲渡条件と合わせて交渉します。善意の無期限支援は双方の責任を曖昧にします。

Q13．RTOとRPOはどう決めますか

停止による売上、利用者安全、契約SLA、データ再入力可能性、復旧費を基に経営が決め、技術が実現可能性と費用を示します。既存値をそのまま書くのではなく、実際の復元演習で測定します。

Q14．M&Aを利用者に知らせる必要がありますか

取引形態、利用規約、個人情報の扱い、サービス変更などによって異なります。秘密保持と適切な通知を両立する時期・文面を、法務専門家と検討してください。技術チームは通知先抽出と配信記録を支えます。

Q15．公式ドキュメントはいつ確認すればよいですか

基本設計時、リハーサル時、実行直前の少なくとも三回です。ストアやクラウドの要件は変更されます。本稿の手順やリンクも将来変わり得るため、実行時点の公式情報、管理画面、サポート回答を優先してください。

34. 売却価格を守るのは、止めないための説明力

買い手が恐れるのは、古い技術そのものより、どこを触ると何が止まるか分からない状態です。資産台帳、再現可能なビルド、復元試験、依存図、RACI、90日計画があれば、買い手は必要な投資と人員を見積もれます。不確実性が減ると、交渉は漠然とした不安ではなく、具体的な費用と条件に変わります。

譲渡企業にとって技術整理は、買い手のためだけの作業ではありません。売却が成立しなくても、退職、障害、災害、監査、次の資金調達に耐える体制が残ります。代表者しか知らない秘密を組織の資産へ変え、アプリの価値を「今日の売上」から「明日も再現できる仕組み」へ引き上げる作業です。

35. アプリ開発M&A総合センターへの相談

アプリ開発M&A総合センターでは、アプリ事業、SaaS、受託開発事業の売却を検討する譲渡企業のご相談を受け付けています。譲渡企業からは、着手金・中間金・成功報酬を含め、M&A仲介手数料をいただかない0円の支援方針です。まだ売却を決めていない段階でも、技術資産の境界、買い手に説明すべき資料、ストアやクラウドの引き継ぎ難易度から整理できます。

手数料を比べる際は、各社の料率だけでなく、最低成功報酬、算定基礎、段階料率、対象サービス、消費税、契約条件を確認してください。たとえば譲渡価格5億円に単純に5％を掛けると2,500万円ですが、これは算数上の例にすぎません。大手他社の実際の手数料は段階料率や最低報酬などで決まり、単純比較はできません。参考としてストライク社の公開手数料ページをご確認ください。

「売れる状態か分からない」「共有AWSから切り出せるか不安」「個人開発に近く資料がない」という段階こそ、早めの棚卸しが有効です。サービスを止めず、利用者と開発チームを守る承継計画を一緒に組み立てます。お問い合わせの際は、アプリの種類、主な売上モデル、開発体制、利用クラウド、売却希望時期を分かる範囲でお知らせください。

参考一次資料

免責事項

本記事は、アプリ事業M&Aに関する一般的な情報提供を目的とし、個別案件の法務、税務、会計、労務、知的財産、情報セキュリティその他の専門的助言を構成するものではありません。取引形態、契約、データ、利用サービス、法域により必要な対応は異なります。Apple、Google、GitHub、AWS、Google Cloudなどの仕様、規約、移管条件は変更される可能性があります。実際の取引・移管時には、最新の公式資料を確認し、弁護士、税理士、弁理士、公認会計士、情報セキュリティ専門家など適切な専門家へご相談ください。

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

URLをコピーしました！

URLをコピーしました！