アプリ売却の査定額は署名鍵で決まる

2026年8月3日(月)

スマホアプリは前回と同じ鍵で署名されたものだけが更新を認められるため、署名鍵を失った事業は更新不能となり、OSやストア要件の変化に対応できないまま配信停止へ向かう「残り期間が確定した資産」に変わる。売り手はPlay App Signingの有無とkeystoreのフィンガープリント一致を売却交渉前に確認し、買い手は鍵の存在を質問ではなく実際の署名ビルドで検証したうえで、移管完了を支払い条件に紐づける必要がある。

アプリ事業のM&Aで、数字の話が綺麗にまとまったあとに、交渉が急に静かになる瞬間があります。月間の課金額も、継続率も、レビューの星も、すべて申し分ない。それなのに買い手側のエンジニアが一言「署名鍵はどこにありますか」と尋ねた瞬間、売り手が黙ってしまう。この沈黙のあとに起きることを、私たちは何度も見てきました。

アプリの売買は、WEBサイトの売買と決定的に違う点がひとつあります。サイトであれば、最悪サーバーが飛んでもドメインとデータさえあれば作り直せますが、アプリはストアという他人の家に置かせてもらっている資産で、その家の鍵を持っているかどうかが、事業の継続可能性そのものを決めてしまうのです。そして、その鍵にあたるものが署名鍵です。

この記事では、アプリ売却において署名鍵がなぜ査定額を左右するのか、iOSとAndroidで何がどう違うのか、そして鍵を失った事業に実際何が起きるのかを、実務の順序で整理していきます。

署名鍵は「アプリの戸籍」であって、単なるファイルではない

署名鍵という言葉に馴染みのない方のために、まず正体をはっきりさせておきます。スマホアプリは、開発者が秘密鍵で署名してからストアに提出します。OSはインストール時と更新時に、その署名を検証します。同じアプリの更新だと認めてもらうための条件は、「前回と同じ鍵で署名されていること」だけです。

つまり署名鍵は、パスワードのように「忘れたら再発行」できるものではありません。再発行した鍵は、OSから見れば赤の他人の鍵です。既存のアプリを更新することは永久にできなくなります。

ここが、アプリ資産の脆さの核心です。ソースコードは残っている。サーバーも動いている。ユーザーもついている。それでも鍵がなければ、今ストアに並んでいるそのアプリに、二度と手を触れられないという状態が発生します。

M&Aの現場で怖いのは、この事実が売り手にも共有されていないケースが珍しくないことです。開発を外注していた、初期メンバーが退職した、前のMacから移行するときにキーチェーンごと消えた。理由は毎回違いますが、結論はいつも同じで、鍵の所在が誰にも分からないという一点に収束します。

Android は Play App Signing の有無で運命が真っ二つに分かれる

Google Play では、署名鍵の扱いが時期によって大きく変わりました。ここを理解しているかどうかで、DDの精度が変わります。

Play App Signing がある場合(＝助かる側)

Play App Signing を使っている場合、アプリ本体に使う署名鍵（アプリ署名鍵）はGoogleが預かって管理しています。開発者が日常的に使うのは、Googleへ提出するためのアップロード鍵という別の鍵です。

この構成の何がありがたいかというと、アップロード鍵を紛失しても、Googleに申請してリセットできる点です。本体の鍵はGoogleの金庫にあるので、開発者側の事故で事業が終わることがありません。2021年8月以降にPlayへ新規登録されたアプリはPlay App Signingが必須になっているため、比較的新しいアプリはこちら側にいる可能性が高いといえます。

自己管理の署名鍵しかない場合(＝危ない側)

問題は、それ以前から続いているレガシーなアプリです。開発者自身がkeystoreファイルを保管し、それだけが唯一の鍵という構成があり得ます。この場合、keystoreファイルとそのパスワードを失った時点で、そのアプリの更新は物理的に不可能になります。

復旧手段はありません。Googleに頼んでも出てきません（そもそもGoogleは持っていないので出しようがない）。残された道は、新しいパッケージ名でアプリを作り直し、ストアに新規アプリとして出すことだけです。

アプリ移管そのものの手続き

Play Consoleにはアプリを別のデベロッパーアカウントへ移す機能が用意されていますが、ここにも実務的な壁があります。移管には、移管元と移管先の双方のアカウント情報に加えて、該当アカウントの購入時に発行されたトランザクションIDが必要になります。「開発者アカウントを作ったときの支払い記録を出してください」と言われて、10年前の記録を即座に出せる個人開発者がどれだけいるかを想像してみてください。

数字の交渉が終わったあとにこの手続きで止まるケースは、決して珍しくありません。

iOS は「移管できる」が「証明書は付いてこない」

Appleには App Transfer という公式の移管機能があります。これがあるおかげで、iOSアプリの売買は制度上は成立します。ただし、ここには2つの誤解が潜んでいます。

誤解1: 移管すれば証明書もまるごと移る

移管されるのはアプリそのもの、Bundle ID、レビュー、ランキング、既存ユーザーのインストールベースです。一方で、配布用の証明書やプッシュ通知用の証明書は移管されません。移管先のアカウントで新しく発行し直すことになります。

ここは、Androidの「鍵を失うと終わり」とは事情が違います。Appleの場合、アプリの同一性はApple側が管理しているため、証明書を作り直しても更新は続けられます。ただし、プッシュ通知の証明書やキーを差し替える段取りを誤ると、移管の翌日から通知が一通も飛ばなくなるという、収益に直結する事故が起きます。プッシュ経由の再訪でリテンションを支えているアプリでは、これは静かな致命傷になります。

誤解2: どんなアプリでも移管できる

App Transferには条件があります。特に、他のアプリと共有しているリソースを持つアプリは移管できません。実務でよく引っかかるのは次のようなケースです。

App Groups で他アプリとデータ領域を共有している
iCloud のコンテナを他アプリと共有している
Sign in with Apple を利用している
Apple Pay の Merchant ID を他アプリと共有している

複数アプリを1つのアカウントで運営してきた個人開発者ほど、この共有関係が絡まっています。「この1本だけ売りたい」と思っても、隣のアプリと手をつないでいるせいで移管できない、という構造です。

売却を考えるより前の、設計の段階で決まってしまっている話なのが厄介なところです。

鍵を失った事業は「時限付き資産」に変わる

ここまでを踏まえて、Androidで自己管理の署名鍵を失ったアプリに何が起きるかを、事業価値の目線で追ってみます。

まず、そのアプリは更新できないまま、ストアに並び続けます。今日はまだ動きます。来月も動くでしょう。問題はその先です。

OSのメジャーアップデートが来ます。ストアが要求するAPIレベルの下限が上がります。依存しているSDKがサポートを終了します。決済まわりの仕様が変わります。そのたびに、更新できないアプリは対応する術を持たないまま、じりじりと動作条件から外れていきます。そして最終的には、ストアの要件を満たさなくなった時点で、配信自体が止まります。

つまり、鍵を失った時点でそのアプリは、今の収益が続くのではなく、終わりの日付が確定した資産に変わっています。買い手から見れば、これは事業の買収ではなく、残り期間の分からない年金を買う行為に近い。

「新しいパッケージ名で出し直せばいい」という反論はあり得ますが、実務としてはほとんど救いになりません。新規アプリとして出すということは、これまで積み上げたインストールベースも、レビューの星の数も、ランキングも、ASOの実績も、全部ゼロから始めるということです。既存ユーザーに移行してもらう導線を、更新できない古いアプリの中に仕込むこともできません（更新できないのだから当然です）。

売り手が「月商の何ヶ月分で」と積算した金額と、買い手が見る「引き継げる資産の実体」の間に、これほど残酷な差が開く論点は他にあまりありません。この構造は、他人のプラットフォームの上に事業を建てているという意味で、APIの利用停止によって事業が停止するリスクと同じ形をしています。

売り手が売る前に確認しておくべきこと

ここまで読んで不安になった方のために、確認の順序を整理します。難しい作業ではありません。ほとんどは30分あれば終わります。

1. Play App Signing を使っているかを確認する

Play Console のアプリ設定から、アプリの完全性に関する項目で、Play App Signing が有効かどうかを確認します。有効になっていれば、最悪のシナリオは回避できています。有効になっていない場合は、次へ進んでください。

2. keystore ファイルとパスワードの所在を特定する

ファイルがどこにあるか、パスワードが分かるか、そして実際にそれで署名できるかを試すところまでやってください。「あるはずです」と「実際に署名が通りました」の間には、M&Aの現場では天と地ほどの差があります。

3. 鍵が「本物か」をフィンガープリントで突き合わせる

ここが最も重要で、そして最も飛ばされがちな工程です。手元にkeystoreファイルがあったとしても、それが今ストアに並んでいるアプリを署名した鍵と同一である保証はどこにもありません。開発の過程で複数の鍵を作り、どれが本番用か分からなくなっているケースは実際にあります。

確認は、鍵の指紋（フィンガープリント）を突き合わせるだけで終わります。手元のkeystoreに対して、次のコマンドを実行します。

keytool -list -v -keystore [keystoreファイルのパス]

パスワードを入力すると、その鍵の SHA-1 および SHA-256 のフィンガープリントが表示されます。次に Play Console を開き、対象アプリの「アプリの整合性」に関する画面で、実際にストアで使われているアプリ署名証明書のフィンガープリントを確認します。この2つが一致していれば、手元の鍵は本物です。一致しなければ、その鍵は別物であり、探索は振り出しに戻ります。

この作業は5分で終わります。そして、この5分をやったかどうかが、交渉の最終盤で数千万円の話が白紙に戻るかどうかを分けます（拍子抜けするほど地味な作業ですが、地味さと重要度はまったく比例しません）。

外注していた場合は、この時点で開発会社に連絡する必要があります。契約が終了している相手に、10年前のファイルを探してもらう交渉は、想像よりずっと時間がかかります。売却を決めてから始めるのでは遅い作業です。

4. iOSは共有リソースの有無を洗い出す

App Groups、iCloud コンテナ、Sign in with Apple、Apple Pay の Merchant ID。これらを他のアプリと共有していないかを確認します。共有していた場合、移管の前に切り離す作業が必要になり、これはアプリの改修を伴います。

5. デベロッパーアカウントの購入記録を探す

Androidの移管に必要なトランザクションIDのことです。Googleからの購入確認メールを検索すれば見つかります。メールアドレスを変えている場合は、そこから遡る必要があります。

この5点は、いずれも売却の交渉が始まる前に済ませておくべきものです。交渉のテーブルで初めて発覚すると、買い手は「他にも把握していないことがあるのでは」と考え始めます。技術的な不備そのものより、その疑念の方が価格に効きます。引継ぎマニュアルを整えておくことが売り手の防衛になるのと、まったく同じ構図です。

買い手が確認すべきことと、査定への織り込み方

買い手側から見た場合、署名鍵の確認は技術的DDの最初期に置くべき項目です。理由は単純で、ここが不合格なら他の項目を調べる意味がなくなるからです。収益性の分析も、コード品質の評価も、引き継げない資産に対して行っても無駄になります。

確認の際は、「鍵はありますか」と質問するだけでは不十分です。返ってくる答えはほぼ確実に「あります」です。そうではなく、実際にその鍵で署名したビルドを、目の前で作ってもらうところまで求めるべきです。鍵の存在は、質問ではなく実演で確認する類のものです。

そして、鍵の管理状態は査定に定量的に効きます。

Play App Signing 有効＋ iOS の共有リソースなし: 移管リスクはほぼゼロ。この論点で減点する理由はありません
自己管理の署名鍵だが所在と動作を確認済み: 移管作業そのものにリスクは残ります。引き渡し時の手順と、失敗した場合の扱いを契約で定めておく必要があります
署名鍵の所在が不明: 前述のとおり、これは事業ではなく残存期間の買収です。継続価値ではなく、確実に見込める残り期間だけで評価する話になります

なお、鍵の保管状態が雑な事業は、他のシークレットの管理も同程度に雑であることが多いという相関があります。署名鍵の話をしているときに、APIキーが漏洩していないかも併せて確認しておくと、二度手間になりません。鍵という概念に対する運営者の解像度は、だいたい全部の鍵に対して一様に現れます。

鍵は「引き渡し」の対象であって、「渡せたらいいもの」ではない

実務でもうひとつ抜けやすいのが、契約上の扱いです。鍵の話は技術の話だと思われがちですが、本質的には引き渡し義務の定義です。ここを曖昧にしたまま入金してしまうと、取り返しがつかなくなります。

最低限、次の3点は取引の条件として明文化しておく価値があります。

移管の完了を、代金支払いの条件に紐づける: 「入金したが移管が通らなかった」という順序で事故が起きます。ストア側の移管手続きが完了し、買い手のアカウントで実際にビルドを提出できる状態になったことを確認してから支払う、という順序を契約で固定します
署名鍵の同一性を表明保証の対象にする: 「引き渡す鍵は、現在ストアで配信中のアプリを署名した鍵と同一である」という一文です。前述のフィンガープリント突き合わせは、この表明の裏付けにあたります
移管が拒否された場合の扱いを事前に決める: iOSの共有リソースや、AndroidのトランザクションID不備で、手続きが通らないことは現実に起きます。そのとき白紙に戻すのか、改修してから再挑戦するのか、費用は誰が持つのか。揉めてから決めるのは最悪の順序です

移管の可否は、売り手の誠実さとは無関係に、プラットフォーム側の都合で決まります。だからこそ、善意ではなく手順で守る必要があります。事業譲渡の形をとる場合、譲渡対象資産の一覧に署名鍵とデベロッパーアカウントを明記しておくことも忘れないでください。「アプリ一式」という書き方では、鍵が含まれるのかどうかを後から争う余地が残ります。