個人開発アプリの価値を消すストア規約
アプリ事業のM&Aで、売上の話が一段落したあとに、買い手のエンジニアがふと挟んでくる質問があります。「直近でリジェクトを受けたのは、いつですか」。月商でもDAUでもコードの行数でもなく、審査に落ちた話です。
これが妙な質問に聞こえるとしたら、アプリという資産の性質がまだ腹に落ちていないのかもしれません。個人開発のアプリは、ひとりか数人で、しばしば本業の隙間の時間を削って、それでも何年も動き続けるものを作り切ってきた成果です。ところがその成果は、自分の敷地ではなくストアという他人の家の中に置かれていて、家のルールは、住人の事情とはまったく無関係に、家主の都合で書き換わります。
しかも書き換わったルールは、その瞬間から、昨日まで許されていた実装に対しても効きます。この記事では、ストア規約と審査基準の変更が、個人開発アプリの売却でなぜ価値の前提そのものになるのか、そして買い手が「今審査を通っているか」ではなく何を見ているのかを、実務の順序で整理していきます。
審査を通っているという事実に、明日の保証は含まれていない
まず、ストア規約というものの正体をはっきりさせておきます。あれは法律ではありません。プラットフォーム事業者と開発者の間の契約であり、その契約には、事業者側が一方的に内容を変更できるという趣旨の条項が含まれています。開発者にできるのは、変更後の条件を受け入れるか、ストアから出ていくかの二択だけです。交渉のテーブルは、そもそも用意されていません。
ここまでは、多くの方が感覚として分かっています。問題はその次です。規約が変わったとき、既存のアプリが「そのまま」でいられる時間には限りがあるという点が、実務ではしばしば見落とされます。
ストアに並んでいるアプリは、放っておけば当面は配信され続けます。ただし、次にアップデートを提出した瞬間、そのビルドは提出時点の最新基準で審査されます。規約の改定は、アプリを直接撃ち抜くのではありません。開発者が自分のアプリに手を触れようとした、まさにその瞬間に発動する仕掛けになっている。
これが厄介なのは、改修する自由と規約遵守が、セットで人質に取られるからです。クラッシュを直したいだけ、新しいOSに対応したいだけ、そういう話であっても、現行基準に触れる箇所を抱えたままでは審査を通せません。「バグ修正のついでに、収益の中心にある機能を作り替えなければならない」という順序が発生する。この順序を、売却交渉のまっただ中で踏むことになったら何が起きるかは、想像がつくと思います。
個人開発者に足りないのは、能力ではなく「帯域」
誤解のないように書いておきますが、これは個人開発者の技術力の話ではありません。むしろ逆で、ひとりでストアに出して、審査を通して、何年も更新を続けてきた人の技術力は、組織の中で分業している開発者よりも確実に広い範囲をカバーしています。設計もUIも課金導線もサポート対応も全部ひとりでやってきたのだから、当たり前です。
構造的に薄いのは、能力ではなく帯域のほうです。
規約への追随という作業は、コードを書く仕事とは別種の労働です。まず改定の告知に気づく必要がある。次に、その改定が自分のアプリのどこに当たるのかを読解する必要がある。当たっていたなら、どう直せば通るのかを判断する必要がある。直した上で再提出して、落ちたらまた読解に戻る。このループのうち、コードを書く工程は全体の一部にすぎません。残りは、読む・判断する・待つ・問い合わせるという、開発とはまるで筋肉の違う作業です。
企業なら、この筋肉を別の人が持っています。誰かが改定を追い、誰かがリスクを判定し、誰かが法務に確認する。個人開発では、それが全部、同じひとりの、同じ可処分時間の上に乗ります。新機能を作る時間と、規約を読む時間が、同じ財布から出ていく。そして多くの場合、新機能を作るほうが楽しいし、短期の売上にも効きます（規約を読む土曜日と、機能を作る土曜日を並べられたら、そりゃ後者を選びますよね）。
だから追随は、意思の弱さではなく、配分の問題として後回しになります。買い手が個人開発アプリを見るときに警戒しているのは、まさにこの構造です。作った人を疑っているのではありません。ひとりの時間の上に乗っている限り、追随は必ず後回しになるという力学を知っているだけです。
価値が消えるのは、規約の隙間に立っている部分から
では、規約の変更で実際に何が撃たれるのか。ガイドラインの全条項を心配する必要はありません。危ないのは、事業の売上が規約の明文で守られていない場所に立っている場合だけです。代表的な4か所を挙げます。
1. グレーゾーンに依存した機能
ストアのガイドラインは、禁止事項の網羅的なリストではありません。原則があって、いくつかの例示があって、あとは審査の運用で決まる。だから「明文で禁止されていない」は「まだ書かれていないだけ」と区別がつきません。
個人開発のアプリでヒットしているものほど、この隙間を上手く見つけていることがあります。それは目の付けどころの良さであり、才能でもあるのですが、買い手の目線に置き換えると話は変わります。売上の中心がグレーの上に立っているなら、その売上はガイドラインの一行で消える売上だからです。査定は、消えない売上と消える売上を、同じ倍率では括りません。
売り手が確認すべきは、「今通っているか」ではなく、「この機能は、ガイドラインのどの記述に守られているか」を言えるかどうかです。言えなければ、そこはグレーです。通っている理由が「まだ誰も問題にしていないから」であるとき、それは根拠ではなく運です。
2. 課金の外部誘導
決済まわりは、ストアにとって収益そのものです。したがって、最も改定が激しく、最も地域差が大きく、規制当局や訴訟の動きに引きずられて条件が動いてきた領域でもあります。「今この実装が通っている」ことの保証としての価値が、他のどの領域よりも低いと考えたほうが、実務に合います。
ここで問題になるのは、手数料を回避している分の利益です。外部の決済へ寄せることで浮いた手数料は、そのまま利益に乗ります。ところがその利益は、規約が動けば消えます。同じ利益額でも、ストアの中で完結している課金と、規約の運用に寄りかかった課金では、資産としての質が違う。これはアプリ内課金の比率によって売却の相場が変わるのと同じ話で、額ではなく質の問題です。
さらに厄介なのは、規約対応が実装の変更だけでは済まないことです。外部決済を前提に組んだ価格設計は、ストア内の課金へ戻した瞬間に手数料分の粗利が消えます。直せば通る、ただし直すと儲からない。この状態のアプリを買い手が見つけたとき、値段は「直したあとの利益」で計算されます。当然です。
3. データ収集の同意設計
プライバシー領域は、この10年、一貫して厳しくなる方向にしか動いていません。緩んだ例が思いつかないという意味で、ここは数少ない「予測がつく」領域です。トラッキングの許諾、収集項目の申告、第三者提供の開示。要求は増えることはあっても、減りません。
個人開発で最も多いのは、自分では集めていないつもりなのに、入れたSDKが集めているケースです。広告、解析、クラッシュレポート、プッシュ通知。それぞれのSDKが何を送信しているかを、開発者が完全に把握しているとは限りません。そしてストアへの申告は、SDKの挙動も含めて開発者の責任として行うものです。
申告と実態がずれていた場合、これは単なるリジェクトでは終わらない性質の問題になります。同時に、収集していたデータの扱いは改正個人情報保護法の側からも問われます。ストアの審査と国内法はまったく別のルールですが、同じ実装が両方に同時に刺さるのがこの領域の特徴です。買い手が最も嫌うタイプのリスクで、理由は単純です。買収後に発覚したとき、売り手はもういないからです。
4. 年齢レーティング
忘れられがちですが、これが一番静かに効きます。レーティングは、開発者が質問票に答えることで決まる自己申告です。そして申告と実態がずれるのは、悪意がなくても起きます。
典型は、あとから機能が育ったケースです。リリース時は単機能だったのに、ユーザーの要望に応えてコメント欄をつけ、チャットをつけ、外部リンクを貼れるようにした。ひとつずつは小さな改善で、どれも正しい判断でした。ただ、その積み重ねの結果、アプリはユーザー生成コンテンツを扱うアプリに変わっています。一方で、レーティングの質問票への回答は、リリース時のまま更新されていない。
ここを指摘されると、レーティングは引き上げられます。すると、審査に通る通らない以前に、ストア上での露出の条件が変わります。フィルタから外れる、特定の年齢層に表示されなくなる、地域によっては掲載の条件が変わる。売上が落ちるのに、コードは1行も壊れていない。買い手から見れば、原因の見えない減収です。
「更新できなくなる」は、鍵を失うより静かに来る
ここまでの4か所に共通する終着点は、同じです。アップデートを提出できない状態です。
アプリが引き継げなくなる経路として広く知られているのは、署名鍵を失うケースでしょう。あれは物理的に不可能になる話で、分かりやすい。鍵がない、だから更新できない、以上、という明快さがあります。
規約による更新停止は、それより静かで、それゆえ発見が遅れます。鍵と違って、提出はいつでもできるのです。ただ通らないだけで。しかも通らない理由は、直せば消えます。つまり「やろうと思えばできる。ただし今の売上を壊す改修と引き換えに」という、条件付きの生存になる。
この状態を放置すると、どうなるか。OSのメジャーアップデートが来ます。ストアが要求するAPIレベルの下限が上がります。依存しているSDKがサポートを終了します。これらには全部、公表された期限があります。期限が来たときに更新を提出できないアプリは、その時点で配信の要件を満たさなくなります。
他人のプラットフォームの上に事業を建てているという意味で、これはAPIの利用停止で事業が止まる構造とまったく同じ形をしています。違うのは、アプリの場合、逃げ場がストアの外にないことだけです。
買い手が見ているのは「今の合否」ではなく「直せる作りか」
ここが、この記事で最も伝えたい一点です。
買い手のエンジニアが技術的DDで審査まわりを見るとき、「現在ストアで配信されている」ことは前提であって、評価の対象ではありません。配信されているのは当たり前で、されていなければ買収の話が始まっていない。評価しているのは、その先です。
規約が変わったとき、このアプリは直せるのか。直せるとして、どれくらいの時間と、どれくらいの売上の犠牲で直せるのか。追随可能性という一点だけを見ています。そしてこの追随可能性は、だいたい次の3つに分解できます。
ひとつめは、改修の局所性です。規約に触れる部分が、コードのどこにあるか。課金の導線が1か所にまとまっているアプリと、画面ごとに散らばっているアプリでは、同じ改定に対して必要な工数が桁で変わります。「3日で直せる」と「3か月かかる」の差は、開発者の腕の差ではなく、構造の差です。そして構造は、引き継いだあとも変わりません。だから買い手はここを見ます。
ふたつめは、判断の記録です。なぜこの実装で通したのか。過去にリジェクトされたとき、どう直したのか。個人開発では、これが本人の頭の中にしか存在しないことがほとんどです。そして頭の中にあるものは、譲渡の対象に含められません。買い手は、アプリと一緒に「なぜこうなっているか」を買えないまま、次の規約変更に直面することになります。
みっつめは、追随の実績です。これは意外に思われるかもしれませんが、リジェクトの履歴は、あったほうが評価されることがあります。落ちて、直して、通した記録は、その開発者とそのコードが、規約の変化に一度は耐えたという証拠だからです。
逆に、リジェクトが一度もない履歴は、2通りに解釈できます。堅牢に作ってきたのか、それとも審査に触れるような更新を、そもそもしてこなかったのか。冒頭の「直近でリジェクトを受けたのは、いつですか」という質問は、これを確かめています。何年も更新していないアプリは、審査に落ちようがありません。それは無事なのではなく、まだ何も試していないだけです。
追随可能性は、売り手が自分で測れる
買い手に指摘される前に、自分で確認できます。順に挙げます。どれも、難しい作業ではありません。
1. 売上を「守られている売上」と「隙間の売上」に分ける。 機能ごとに、ガイドラインのどの記述が根拠になっているかを書き出してみてください。書けない機能がグレーです。全部書ける必要はありません。グレーの上にどれだけの売上が乗っているかを、自分が把握していることが重要です。把握していれば交渉で説明できます。把握していなければ、買い手が先に見つけます。
2. 期限が公表されている変更への立ち位置を確認する。 OSのサポート期間、APIレベルの下限、使っているSDKのEOL。これらは公表されています。対応済み・着手中・気づいていないの3段階のうち、自分がどこにいるか。最悪なのは3つめですが、これは調べれば10分で2つめに移動できます。
3. リジェクト履歴を時系列で並べる。 ストアのコンソールに残っています。いつ落ちて、何日で通したか。ここには「規約変更に追随してきた事業」の実績が、そのまま記録されています。売り手が提出できる、数少ない客観的な証拠です。
4. レーティングの質問票に、今もう一度答えてみる。 リリース時の答えと変わるなら、そこはズレています。5分で終わる作業で、しかも一番見つかりやすい種類のズレです。
5. 入れているSDKの一覧と、それぞれが送信しているデータを突き合わせる。 申告の内容と一致していますか。ここは正直に言って面倒です。ただ、面倒だからこそ誰もやっておらず、だからこそ買い手が最初に見ます。
この5つは、いずれも交渉が始まる前に済ませておくべきものです。交渉のテーブルで初めて発覚すると、技術的な不備そのものより、「把握していなかった」という事実のほうが価格に効きます。
なお、ガイドラインの個別の条項は改定が頻繁で、この記事を読んだ時点と、あなたが確認する時点で内容が違っている可能性が十分にあります。必ず現行の原文を、自分の目で確認してください。人の書いた記事で確認を済ませてはいけない領域です（この記事も含めて、です）。
規約が変わるのは事故ではなく、仕様
ここまで書いてきたことは、要するにひとつです。ストア規約は変わります。それは事故ではなく、ストアという場所の仕様です。
この前提に立つと、アプリの価値の測り方が変わります。「今、月にいくら稼いでいるか」は、その事業が今日まで生き延びてきたことの証明にはなりますが、明日も生き延びる証明にはならない。証明になるのは、変化が来たときに、直せる場所に立っているかどうかのほうです。
そして、ここが大事なところなのですが、追随可能性は、売るためだけの準備ではありません。規約が変わった日に3日で直せるアプリを持っている人は、売らないという選択もできます。3か月かかるアプリを持っている人は、規約が変わった日に、売るか畳むかを迫られる。選択肢を持てるかどうかの話であって、出口の準備の話ではないのです。
ひとりで、あるいは数人で、何年も動き続けるものを作り切ったこと自体は、まぎれもない実力です。それが他人の家のルール一行で消えるのは、控えめに言って理不尽です。理不尽ですが、家主は変わりません。
だとしたら、やることはひとつだけです。自分のアプリのどこが他人のルールに寄りかかっているのかを、他人に指摘される前に、自分で知っておく。それだけで、規約が変わった日は「終わりの日」ではなく「作業の日」に変わります。その差が、あなたのアプリの値段です。
プラットフォーム規約のリスクを踏まえたうえで、では実際いくらで売れるのか。スマホアプリ売却の無料査定で、想定売却額のレンジを試算できます（登録不要）。
