個人開発の売却を止めるアカウント名義
個人開発で作ったサービスを売る、という話が確実に増えています。ひとりで書いて、ひとりで運用して、ひとりで黒字にした。誇っていい話です。ところが、いざ譲渡の段になって交渉が止まる場所は、コードの品質でも、月商の数字でもなく、もっと拍子抜けするところにあります。名義です。
「このアカウント、名義変更できますか」。この一言に答えられないまま数週間が溶けていく事態が、個人開発の売却の現場で繰り返し起きています。しかも厄介なのは、この壁が努力や誠実さでは越えられない種類のものだということです。売り手がどれだけ渡したいと思っていても、渡せないものは渡せない。プラットフォーム側が「それはあなた個人に貸しているものです」と言えば、その時点で議論は終わります。
この記事では、個人名義のまま育ててきた資産が、なぜ譲渡の段で詰まるのか、その詰まり方には何種類あるのか、そして売ると決める前のどのタイミングで何をしておけば救われるのかを、実務の順序で整理していきます。
個人開発の資産は「持っている」のではなく「借りている」
まず前提を揃えます。個人開発のサービスは、たいてい次のようなパーツでできています。ストアのデベロッパーアカウント、クラウドの請求アカウント、決済事業者の加盟店アカウント、ドメインのレジストラ登録、ASPの媒体登録、コードを置いているリポジトリ、それから細々とした各種SaaSの契約。
ここで重要なのは、これらのほとんどが「モノ」ではなく「契約」だということです。サーバーの中のファイルは所有物ですが、そのサーバーを動かす権利は契約です。ドメインも、買い切ったように見えて実体は期限付きの使用権です。そして契約には必ず当事者がいて、個人開発の場合、その当事者の欄にはあなたの本名が入っています。
事業を売るという行為は、この契約の束をまるごと相手側へ付け替える作業にほかなりません。コードを渡すのは、その中のごく一部でしかない。（コードさえ渡せば終わりだと思っていると、渡したあとで永遠に終わらない引き継ぎが始まります）
そして、契約の付け替えができるかどうかを決めるのは、売り手でも買い手でもありません。契約の相手方、つまりプラットフォーム側です。ここが個人開発の売却における最大の非対称性で、取引の当事者ではない第三者が、取引の成否を握っているという構造になっています。交渉のテーブルには座っていないのに、拒否権だけを持っている相手がいる。この事実を最初に飲み込んでおかないと、あとの話がすべて楽観に振れます。
名義の壁には3つの高さがある
「名義変更できますか」という質問に対する答えは、実は3種類しかありません。この3分類を持っているかどうかで、売却準備の解像度がまるで変わります。
レベル1: 移管の仕組みが用意されている
プラットフォーム側が、資産を別アカウントへ移す公式の手続きを持っているケースです。アプリのストア移管、リポジトリの transfer 機能、ドメインのレジストラ間移管などがここに入ります。
該当すれば、あとは手順の問題です。ただし「仕組みがある＝すんなり通る」ではありません。移管には必ず条件があり、条件を満たしていない申請は問答無用で弾かれます。安心してよい層ではありますが、安心して確認を飛ばしていい層ではありません。
レベル2: 移管の仕組みがなく、アカウントごと渡すしかない
資産単位で移す手段がなく、アカウントのログイン情報ごと引き渡す以外に方法がないケースです。個人開発ではここが圧倒的に多く、そして後述するとおりここが一番の地雷原です。
レベル3: 規約上そもそも譲渡できない
最も重いのがこれです。利用規約に「本契約上の地位および権利義務を第三者に譲渡してはならない」という趣旨の条項があり、事業者の書面同意なしには権利の移転そのものが認められていない。多くのクラウド事業者・決済事業者の規約には、この種の譲渡制限条項が入っています。
ここで一度、なぜプラットフォームがそんな意地の悪い条項を置いているのかを考えておく価値があります。彼らが個人開発者の売却を妨害したいわけではありません。理由は逆で、アカウントの売買が、長らく不正利用の温床だったからです。凍結を食らったアカウントの中の人を入れ替えて再利用する、審査を通った加盟店アカウントを転売する、実績のあるアカウントを買って詐欺の信用に使う。こうした手口に対抗するため、プラットフォームは「中の人が変わること」を検知して止める方向へ進化してきました。
つまり、あなたが完全に誠実に、正当な事業譲渡として名義を移そうとしたとしても、その挙動はシステムから見ると不正利用者の挙動と区別がつきません。ログインする端末が変わり、IPが変わり、連絡先が変わり、出金先の口座が変わる。悪意の有無は、そこには映りません。これが、誠実さでは越えられない壁だと最初に書いた理由です。相手は人ではなく、ルールと検知ロジックなのですから。
本当に怖いのは、レベル3の資産を、レベル2のやり方（＝IDとパスワードを渡す）で移してしまうケースです。技術的には動きます。動いてしまうのが厄介で、規約違反の状態が誰にも指摘されないまま数ヶ月が過ぎ、ある日アカウントが凍結される。そのとき買い手は、「買ったはずのもの」を規約違反の状態で運用していた側として立たされます。凍結の理由を問い合わせても、契約上の当事者ではない買い手には、そもそも問い合わせる資格すらない場合があります。
「アカウントごと渡す」が最悪の解決策である理由
レベル2の実務、つまりアカウントの認証情報をそのまま引き渡す方式は、一見すると合理的に見えます。名義変更ができないなら中身ごと渡せばいい。実際、個人開発の小規模な譲渡ではこれが常用されています。
ですが、この方式には構造的な欠陥が4つあります。
- 二要素認証が売り手個人に紐づいている: 認証アプリも、SMSの届く番号も、リカバリコードの送り先も、売り手個人のものです。パスワードを渡しても、ログインの最終関門は売り手の手の中に残ります。買い手は事業を買ったはずなのに、ログインのたびに売り手へ連絡することになる
- 本人確認が済んでしまっている: 決済やストアのアカウントは、売り手の身分証・住所・銀行口座で審査を通過しています。中の人が入れ替わったことを、プラットフォーム側は知りません。知られた瞬間に、話が変わります
- 売り手の人生が事業に接続されたままになる: 個人のメールアドレス、個人のクレジットカード、個人の携帯番号。これらが事業の請求や通知の宛先として残り続けます。売り手は売ったあとも、他人の事業のために自分の与信を貸し続けることになる
- 規約違反のリスクを買い手が背負う: 前述のレベル3に該当していた場合、その違反状態を引き受けるのは、日々それを運用している側、つまり買い手です
要するにこの方式は、問題を解決したのではなく、問題を先送りにして買い手の側へ置いてきただけです。だから経験のある買い手は、この構造を見つけた瞬間に価格を下げます。「アカウントは全部渡します」という説明は、実務家の耳には「事業と売り手がまだ切れていません」と聞こえるからです。そして、売ったあとも売り手が呼び出され続けるこの構造は、無給サポート地獄の入り口そのものでもあります。
領域別に、名義はどこで詰まるか
抽象論だけでは動けないので、個人開発でよく使う領域ごとに、詰まり方を並べます。
ストア（App Store / Google Play）
アプリ単位で別アカウントへ移す公式手続きは両社とも用意されているため、資産としてはレベル1です。ただし移管には条件があり、他のアプリとリソースを共有していると申請が通りません。そして重要なのは、デベロッパーアカウントそのものを他人へ譲渡することはできないという点です。個人名義の登録タイプで長年運営してきた場合、渡せるのはアプリであってアカウントではない、という区別を最初に理解しておく必要があります。（なお Android では署名鍵の所在が名義とは独立に致命傷になり得ますが、それはまた別の話です）
決済（Stripe など）
ここは事実上レベル3です。決済アカウントは、売り手個人の本人確認と、売り手個人の銀行口座と、売り手個人の与信の上に成り立っています。中の人が変わるという事象は、決済事業者にとって「審査の前提が変わった」という意味であり、名義変更というより新規申込みに近い扱いになります。Stripeのようなサービスで入金が止まる話が何度も出てくるのは、この構造が理由です。
個人開発の売却で最も現金に直結するのがここです。入金先の口座が売り手個人のままだと、買い手の事業が売った商品の代金が、売り手の口座に入り続けます。（これを「あとでまとめて振り込みますね」という運用で回そうとする取引が、現実にあります。善意でやっていても、これは他人の売上金を個人口座で預かっている状態です）
ドメイン
レジストラ間の移管手続きがあるのでレベル1ですが、実務上の罠が多い領域です。移管ロックの解除、認証コードの取得、そして登録者情報を変更すると一定期間（一般に60日）他社への移管がロックされるというルール。「先に名義だけ変えておきますね」という善意の一手が、その後の移管を2ヶ月止めることがあります。ドメイン移管の落とし穴は、たいてい順序を間違えた瞬間に発動します。
ASP・アフィリエイト
ここもレベル3寄りです。提携はASPと媒体主個人との間の契約であり、報酬の支払先も個人の口座です。運営者が変わったという事実は、多くのASPで提携審査の前提が崩れる事象として扱われます。アフィリエイト提携の名義変更が通らず、買収の翌月に収益の柱が消えるパターンは、個人メディアの譲渡で最も再現性の高い事故のひとつです。
クラウド・SaaS
個人のクレジットカードで払われているクラウド請求は、名義の問題であると同時に与信の問題です。主要なクラウド事業者の規約には譲渡制限条項があり、アカウントそのものの売買は原則として想定されていません。加えてSaaSの契約は、プラン・座席数・過去のキャンペーン価格が個人の契約履歴に紐づいていることがあり、名義や契約を作り直した瞬間に条件が現行の定価に戻ることがあります。移管はできたが月額が倍になった、という結末です。
リポジトリ
コードの置き場所は移管機能があるのでレベル1です。ただし移管されるのはリポジトリであって、CIのシークレットも、デプロイ鍵も、連携アプリの認可も付いてきません。「コードは渡した」と「動くものを渡した」の間には、この距離があります。
売る前にやる「名義の棚卸し」
やることは単純です。難しい作業はひとつもありません。
まず、事業に関係する全アカウントを1枚の表に書き出します。サービス名、登録名義、登録メールアドレス、二要素認証の紐付け先、支払い方法、そして「そのアカウントが止まると事業の何が止まるか」。この6列です。この表を作るだけで、たいていの人は自分でも把握していなかったアカウントを2つか3つ見つけます。（3年前に作ったきり請求だけが静かに走っているものが、必ず1つはあります）
次に、各行に対して先ほどの3レベルを判定します。判定の根拠は、記憶や想像ではなく、そのサービスの利用規約とヘルプページです。「たぶん変えられるはず」で進めた案件が、クロージングの直前で止まります。
そして、レベル2とレベル3に印を付けます。これが、あなたの事業とあなた個人が癒着している箇所の一覧です。売却の準備とは、この癒着を、交渉が始まる前に剥がしておく作業のことにほかなりません。
剥がし方は、ほとんどの場合ひとつしかありません。事業用の器を先に作り、そちらへ移し替えておくことです。事業専用のメールアドレスとそれ用のドメイン、事業用の支払い手段、事業用の電話番号、そして規模によっては法人格。「売れそうになってから考えよう」では遅い理由は単純で、移し替えそのものに審査期間や再申込みが必要になり、そのあいだ事業が止まったり収益が落ちたりするからです。買い手を待たせながらやる作業ではありません。
この棚卸しには副次的な効果もあります。事業譲渡の形をとる場合、譲渡対象資産の一覧をこの表からそのまま起こせます。「サービス一式」という書き方で契約してしまうと、何が含まれていたのかを後から争う余地が残ります。名義の表は、そのまま契約書の別紙になる資料です。
買い手が見ているのは利益ではなく「移管可能性」
買い手側の目線に立つと、話はさらにはっきりします。
個人開発の案件を検討するとき、経験のある買い手が最初に確かめるのは、月商でもコードの綺麗さでもありません。「この事業は、売り手がいなくても動くのか」という一点です。そして名義は、その質問に対する最も直接的な答えになります。名義が全部売り手個人であるということは、この事業はまだ売り手から独立していないという意味だからです。
だから確認は、質問ではなく実物で行うべきです。
- アカウント一覧を、上記の6列の形で出してもらう。口頭の「全部渡せますよ」で安心しない
- 各アカウントの譲渡可否は、売り手の見解ではなく規約の該当箇所で確認する。売り手も善意で誤解している
- 二要素認証の紐付け先を1件ずつ潰す。ここが残っていると、クロージング後も売り手への依存が続く
- 入金経路の付け替え完了を、代金の支払い条件に紐づける。「あとで変えます」を許すと永遠に変わらない
もうひとつ、双方が必ず決めておくべきなのが移行期間の扱いです。現実には、引き渡し当日に全アカウントの付け替えが完了することはまずありません。審査待ちのもの、月末締めを待つもの、年間契約の更新日まで動かせないものが必ず残ります。だから「しばらくは旧名義のまま運用する」という期間が生まれること自体は、避けられません。
問題は、その期間を誰も期限として定義しないまま始めてしまうことです。期限のない移行期間は、移行しません。売り手は「そのうち連絡が来るだろう」と思い、買い手は「動いているから急ぎではない」と思い、気づけば1年後も売り手のカードでクラウド代が引き落とされている。移行期間は、対象・期限・その間に事故が起きたときの責任範囲を、必ず紙に書いてから始めるべきものです。
査定への織り込み方も単純です。レベル1しかない事業は、この論点で減点する理由がありません。レベル2が混ざっている事業は、移管作業のコストと、失敗した場合の扱いを契約で決める話になります。そしてレベル3が中核収益に噛んでいる事業は、その収益は買収後に存続しない前提で評価するのが妥当です。「たぶん交渉すれば通ります」という期待値を、価格に入れてはいけません。交渉相手は、そのテーブルに座っていないのですから。
名義は、売るときの問題ではなく、作るときの問題
ここまで読んで「今から直すのは面倒だ」と思った方がいるはずです。実際、面倒です。ただ、面倒さの総量は時間が経つほど増えます。アカウントは増え、依存は深くなり、思い出せない紐付けが積み上がっていく。今日が一番少ない日です。
そして、いちばん大事なことを書きます。名義を整えるのは、売るための作業ではありません。事業が自分の人生から独立して動く状態を作る、という作業です。それは売却の準備であると同時に、病気になったとき、燃え尽きたとき、まったく別のことをやりたくなったときに、自分自身を助ける準備でもあります。個人開発の最大の弱点は、作った人が動けなくなった瞬間に全部が止まることで、名義の癒着はその弱点を最も濃く体現しています。
ひとりで作ったものが、ひとりの名前で走り出すのは当たり前です。悪いことでもありません。ただ、それを事業として誰かに手渡せる形にするには、どこかで自分の名前を外す工程がいります。その工程を、売却を決めた日ではなく、今日やっておく。個人開発の売却で失われている価値のかなりの部分は、この一手間の有無で決まっています。
あなたが平日の夜中に書いたコードには、正当な値段がつくべきです。その値段を守るのは、コードの美しさでも、アーキテクチャの筋の良さでもなく、名前の付け替えという、どうしようもなく地味な事務作業のほうです。
アカウントの名義と権利の所在を整理できたら、次に気になるのは「では、いくらで売れるのか」という数字でしょう。スマホアプリ売却の無料査定で、大まかな売却額の目安を確認できます（登録不要）。
