AI導入事例
同じサービスのiOSアプリは、会員の多数を占める主戦場でした。にもかかわらず、通知はAndroid以上に静かに沈黙していた——旧世代の通知経路が完全に途絶えていたのです。実録⑥（Android編）に続き、今回はiOS特有の詰まりどころと、両OSに共通する「古いサーバを触らずに通知を現代化した」話をまとめます。
「気づけない障害」こそ、最初に潰す価値があります。
利用者の大半がiOS。そのiOSで、通知は死んでいた。
iOSアプリもAndroidと同じく、ネイティブの殻で既存Webサービスを表示するWebViewラッパー＋通知という構成でした。通知の送信は旧世代の仕組みに依存しており、その経路が使えなくなった時点で配信は停止。利用者の多くがこちらにいるため、影響範囲は最大でした。ここを現代の配信基盤に載せ替えることが、今回の一番のリターンです。
iOSの詰まりは、"実機でしか出ない"ものばかりだった。
iOSは仮想端末やコードレビューでは分からない、実機で初めて表面化する問題が中心でした。
殻はSwiftで作り直し、中身と会員はそのまま。
iOSアプリはAIエージェントで、最新のネイティブ構成（Swift＋WKWebView＋現行の通知基盤）に作り直しました。プロジェクトの雛形生成から実機での確認までを回し、Macの実機ビルドで動作を確認。表示している中身（既存Webサービス）と、約14,000の登録端末という会員資産はそのまま引き継いでいます。
| 項目 | これまで | 作り直し後 |
|---|---|---|
| 通知の経路 | 旧世代の通知方式 （提供終了・送れない） | 現行の配信基盤＋新方式の認証鍵 |
| アプリの殻 | 世代の古いネイティブ実装 | Swift＋WKWebView で再生成 |
| 画面（中身） | 既存Webサービスを表示 | そのまま継続（会員資産を維持） |
| 実機の不具合 | 日本語の文字化け等 | フォント・バッジ・世代差を個別対応 |
古いサーバは、入れ替えずに現代化した。
両OSに共通する肝は、送信側のサーバでした。このサーバは非常に古い実行環境で動いており、現行の公式ツールがそのままでは使えません。そこで、認証に必要な署名処理を自前で実装して現行の配信基盤に接続。サーバを丸ごと入れ替えることなく、通知だけを現代の方式へ載せ替えました。
さらに送信側は、共有基盤から切り離した独立した配信サービスとして作り直し、管理画面から対象を選んで送れるようにしています。
「動かない」と言われたモバイルアプリでも、殻を作り直し、鍵と会員資産を引き継ぎ、古いサーバを現代化すれば、作り直しは一度きりで現行の運用へ戻せます。触れないと諦めていたアプリがあれば、まずは現物の解析からご相談ください。
※本記事は実案件をもとに、企業・サービスを特定できない範囲で一般化して記述しています。数値は2026年8月時点の実測に基づく概数です。所要期間・作業内容はアプリの構成により異なります。