アプリ救済 ─ iOS/Androidアプリの審査落ち・クラッシュ・引き継ぎを直す

## 「アプリが直せない」状態は、Webよりはるかに深刻になる

iOSとAndroidのアプリは、Webサイトと違って「とりあえずソースを直してアップする」ができません。署名証明書、プロビジョニングプロファイル、App Store Connect/Google Play Console のアカウント、そして審査というゲートを全部通過しないと、1行の修正もユーザーに届きません。修正不可能な状態を放置すると、Webと違って取り返しがつかなくなる速度が速いのです。

制作会社が撤退して半年が経ったあるBtoC事業者の事例では、クラッシュ率が4.2%まで上がっているのに修正を出せず、レビュー★は1.8まで下落していました。原因はソースコードではなく、配信証明書（Distribution Certificate）の有効期限切れと、Apple Developer Program の更新が止まっていたことでした。原因が技術側ではなく契約側にあるパターンが、アプリ救済の半分を占めます。

## 救済が必要になる典型的な3パターン

ひとつは、制作会社や元担当者と連絡が取れなくなったケースです。ソースコードのGitリポジトリへのアクセス権、Apple Developer のアカウント所有者、Google Play Console の管理権限が宙に浮き、誰も更新できない状態に陥ります。Apple Developer Program は組織のD-U-N-S番号と紐づいているため、アカウント譲渡には数週間〜数ヶ月かかります。Google Play は譲渡そのものが原則できず、別アカウントから「アプリ移管」申請を行う運用です。どちらも数日では終わりません。

もうひとつは、Apple App Store の審査リジェクトが解けないケースです。ガイドライン2.5.1のIDFA不適切使用、4.0のデザイン違反、5.1.1の個人情報取扱い不備、Sign in with Appleの実装漏れ、Privacy Manifest（PrivacyInfo.xcprivacy）の未実装など、リジェクト理由は年々細分化しています。実装を直すのではなく、Resolution Center での反論で解決するケースも増えました。テンプレ反論を3回繰り返してリジェクトされ続け、相談に来られるパターンが頻発します。

3つめは、SDK のサポート切れや OS バージョン要件の引き上げにより、一晩でクラッシュ率が跳ね上がるケースです。Firebase Crashlytics の Crash-free users が99%を切ったら、24時間以内に動かないと売上を失います。iOS 18・Android 15対応の遅れ、minSdkVersion 引き上げ、targetSdkVersion 必須対応（毎年8月）、Firebase の旧SDK廃止が直近の頻発トリガーです。Google Play は targetSdkVersion を満たさないアプリを段階的に新規ダウンロード停止にする運用に変わっており、放置すると配信が止まります。

## ai-rescue.jp の対応範囲

ネイティブアプリ（Swift/Kotlin）、Flutter、React Native、Xamarin、Cordova/Ionic まで、過去案件で触れている技術スタックで救済します。クロスプラットフォームは特に放置されやすく、ビルドツールチェーン（Flutter SDK、Node、Xcode、Android Studio）のバージョンが揃わずビルドすら通らない、というケースが多いため、最初の3日は環境再構築と「とにかくビルドが通る状態」を作ることに使います。古いプロジェクトほど、まず動くものを作る部分に最も時間を要します。

審査対応では、Apple Resolution Center とのコミュニケーション代行も行います。テンプレ的な英文反論ではなく、ガイドラインの該当条項とアプリ実装の対応関係を整理した上で、Apple のレビューチームに「これは違反ではない」と納得させる文章を作る作業です。実装側を直す方が早いのか、反論で押す方が早いのか、その判断から関わります。Google Play 側の Policy Violation 解除も同様に対応します。

引き継ぎ対応では、アカウント名義変更（個人開発者→法人、旧法人→新法人）、証明書とプロファイルの再発行、Git リポジトリの所有権移管、TestFlight・内部テスト配信の権限再構築、CodeMagic や Bitrise の CI 引き継ぎまで含めます。Apple の組織アカウント譲渡は申請から完了まで3〜6週間、その間も既存ユーザーへの配信を止めない構成を組みます。Apple Account Holder の変更だけで終わらせず、Team Agent や App Manager の権限設計まで作り直すのが原則です。

## 進め方と費用感

最初の48時間で「何が壊れているのか」を切り分けます。ソース側か、署名側か、アカウント側か、SDK側か、ストア側か。技術的な障害なのか、契約・権限の障害なのか。この切り分けが終わるまでは、修正には手を付けません。順序を間違えるとビルド成功＝公開可能ではなく、二度手間になります。

最短は緊急対応の3〜5日復旧で、配信証明書再発行・緊急ホットフィックスのリリースまで。標準的な引き継ぎ＋安定化プロジェクトは2〜3ヶ月で、SDK更新・OS要件対応・CI/CD（Xcode Cloud か GitHub Actions + Fastlane）の再構築まで含めます。費用感は、緊急対応 38万円から、引き継ぎ＋安定化プロジェクト 180万円から、保守顧問契約 月額18万円からです。

実装の継続が困難と判断した場合は、PWA への置き換えやネイティブからのリプレイス提案も行います。ユーザー数や課金構造によっては、アプリを残すよりWebに統合した方が運用負荷も売上も健全になるケースがあります。アプリ内課金（IAP）の30%手数料を回避してWebに移すか、逆にプッシュ通知と決済の即時性のためにアプリを維持するか、事業の収益構造から判断します。残すべきか畳むべきか、その判断材料の提示までが救済の仕事です。