実録⑥:止まったAndroidアプリをAIで再生

AI導入事例

「アプリは動いている。ただ、通知だけが何年も届いていない」——そんな相談から始まりました。会員制のBtoCサービス向けAndroidアプリ。ストアには公開され、起動もするのに、お知らせのプッシュ通知だけが、いつの間にか一通も飛ばなくなっていたのです。今回は、作った人も資料もいない「触れないモバイルアプリ」を、会員資産と署名鍵を一切引き継いだままAIで作り直した記録です。

一番こわいレガシーは、落ちるアプリではありません。
落ちないまま、大事な機能だけが静かに止まっているアプリです。

「動いてはいる」の下で、通知は数年前に止まっていた。

このアプリの正体は、ネイティブの殻の中で既存のWebサービスを表示するWebViewラッパー+プッシュ通知、という構成でした。画面は既存Web資産の使い回しなので生きている。問題は通知です。送信の仕組みが旧世代の配信基盤に依存しており、その基盤が提供終了になった時点で、経路そのものが消滅していました。データベースには新方式のトークンを保存する列だけが追加されていて、そこへ何も書き込まれない——配線が途中で途切れたまま放置されていたのです。

約14,000登録端末(全体)
約3,200Android端末
2016年既存署名鍵の発行年
1回必要な再リリース

「触れない」の中身は、8割が"作り直しの怖さ"だった。

実際に踏んだ壁は、コードの難しさより「引き継ぎの怖さ」でした。とくにAndroidは、ひとつ間違えると既存ユーザーが更新できない別アプリになってしまいます。

通知の送信基盤が、世代ごと消えていた通信経路旧世代の配信サービスが終了し、送る側の経路が存在しない。まず「現代の経路」に載せ替えるところからのスタートでした。
作った人も、設計資料もいないアプリ残っていたのは古いソースだけ。AIエージェントで構造を読み解き、「殻+WebView+通知」という骨格を把握してから再設計。ゼロからではなく、現物を理解して作り直す進め方です。
署名鍵を引き継げないと、全ユーザーが更新できないアプリAndroidは同じ署名鍵で署名したものだけが「更新」として届く。約10年前・2016年発行の鍵を探し出して継承し、証明書の指紋が完全一致することを確認。新規インストールではなく更新として配信できる状態を確保しました。
登録APIが暗号化通信を必須にしていた通信経路旧サーバは平文接続を弾く設定。端末登録が通らない原因の多くはここでした。検証を無効化して回避せず、アプリ側を暗号化通信前提に統一して解決。
ビルド環境が現行のストア要件に追いついていないアプリ古い実行環境ではストアが受け付けない。ビルド基盤(ビルドツール・言語・実行環境)を最新へ引き上げ、署名済みの配布形式で出力できるところまで再整備しました。

残すもの/作り直すものを、はっきり分けた。

やることは「全部を新しくする」ではありません。活かせる資産はそのまま活かす。分解すると、こうなります。

項目これまで作り直し後
通知の経路旧世代の配信基盤
(提供終了・送れない)
現行の配信基盤(FCM)に載せ替え
アプリの殻世代の古いネイティブ実装最新のネイティブ実装で再生成
画面(中身)既存Webサービスを表示そのまま継続(会員資産を維持)
署名鍵2016年発行同一の鍵を継承(更新として配信)
会員・端末データ約14,000端末が登録済みそのまま引き継ぎ

再構築そのものはAIエージェントで一気に進めました。作り直したアプリは、仮想端末で通知トークンの取得 → サーバへの登録 → 実際に通知が届くまでの一連を最後まで通し、往復が成立することを確認しています。出力は、そのまま配布できる署名済みの形式です。

「作り直し」と「再リリース」は、最小に設計する。通知の復活は、実はサーバ側の載せ替えだけでも点火できるよう準備しました。アプリの再リリースは一度で済ませ、以降は端末を触らずに通知を運用へ戻せる——「ユーザーに何度も更新をお願いしない」ことが、会員数が多いサービスほど効いてきます。

動かないと言われたアプリの多くは、全損ではありません。止まっている一部の配線と、引き継ぐべき鍵さえ押さえれば、現物を活かしたまま現代の基盤へ戻せます。iOS編(実録⑦)では、会員の多数を占めるもう一方のプラットフォームと、両OS共通の"古いサーバのまま通知を現代化した"話を書きます。

※本記事は実案件をもとに、企業・サービスを特定できない範囲で一般化して記述しています。数値は2026年8月時点の実測に基づく概数です。所要期間・作業内容はアプリの構成により異なります。

カテゴリー:

タグ:

🌐 日本語