hsb.horse
モバイルアプリのドメイン変更が発生したとき、旧バージョンを使い続けるユーザーに対してどう対応しているだろうか。
私はこれまでWebフロントエンドとバックエンド、現在はAWS中心のインフラエンジニアとして働いてきた。Web開発の自由度の高さを知っている分、モバイルアプリの審査やリリースサイクルの制約が気になる。さらにインフラの視点から見ると、古いドメインを維持し続けるコストとリスクも気になる。
この記事では、複数のレイヤーから見たモバイルアプリの課題を整理し、起動時にメタデータを取得するアプローチを提案する。ベンダー依存を避けつつ運用負荷を下げる構成だ。
各レイヤーから見たモバイルアプリの課題
インフラエンジニア視点
インフラとアプリの直接的な接点はFQDNだ。サービスが長く続くと、このドメイン管理が負債になりうる。
BFFのリアーキテクチャなどで新規ドメインを発行すると、旧ドメインは維持しつつ新ドメインへリダイレクトする必要が出る。DNSレコードを保持し続け、不要なホストが稼働し続ける。エンドポイントはいつでも障害点になりうる。消せるなら消したいが、旧アプリバージョンのユーザーがいる限り消せない。
Webフロントエンドエンジニア視点
Webフロントエンドの強みはデプロイの自由度だ。審査もインストールもない。キャッシュを無視してリロードすれば最新版が届く。小さい修正なら1日に何度もリリースできる。
モバイルアプリは審査があるため、この自由度は得られない。リリースしたいときにリリースできるという感覚が、モバイル開発では通用しない。
バックエンドエンジニア視点
BFF側の課題はAPI互換性の維持だ。バージョニングをどう設計しても、古い実装を残し続ける必要がある。これも消したいが消せないコードが蓄積していく構造だ。
提案する構成：起動時メタデータ取得
以下の構成を考えている。
meta.example.com というドメインを用意し、CloudFrontとS3で配信する。パスにバンドルIDを使い、その配下に metadata.json を配置する。
meta.example.com/├── com.example.app-a/│ ├── metadata.json│ └── metadata.sha256├── com.example.app-b/│ ├── metadata.json│ └── metadata.sha256└── com.example.app-c/ ├── metadata.json └── metadata.sha256アプリ起動時にこのJSONを取得し、バックエンドや静的アセットのエンドポイントを動的に設定する。取得したメタデータはローカルにキャッシュし、適切な再検証間隔を設定する。
metadata.jsonのスキーマ例：
{ "$schema": "https://meta.example.com/schemas/metadata/v1.json", "bundle_id": "com.example.app-a", "sha256": "xxxxxxxx", "revalidate_interval": 604800, "backend": { "host": "https://api.example.com", "ping": "/health", "retry": { "max_retries": 5, "backoff_factor": 2 } }, "static_assets": { "host": "https://cdn.example.com" }, "maintenance_mode": { "enabled": false, "begin": "2026-02-14T00:00:00Z", "end": "2026-02-14T03:00:00Z", "message": "メンテナンス中です" }}この方式のメリットは、バックエンドのドメイン変更やメンテナンス告知をインフラ側だけで完結できる点だ。アプリ側は起動時にメタデータを取得するだけで、ハードコードされたエンドポイントに縛られなくなる。
CloudFrontのキャッシュTTLを1日から1週間程度に設定すれば、頻繁な更新はない想定でコストも最小限に抑えられる。Cache Bustingの仕組みも検討しておく必要がある。
既存ソリューションとの比較
Firebase Remote Config
Firebase Remote Configは現状無料で提供されている。機能的には十分だ。ただし以下の懸念がある。
まず将来的な有料化リスクだ。Googleのサービスは無料から有料に移行するケースが過去にある。予算計画に影響を与える可能性がある。
次に管理コストだ。アプリごとにFirebaseプロジェクトを作成することになる。管理するアプリが増えれば増えるほど、プロジェクト数と権限管理の複雑性が増す。大企業で複数アプリを運用する場合、この管理工数は無視できない。
自前実装のトレードオフ
CloudFront+S3の自前実装は初期構築コストがかかる。ただし長期的なベンダーロックインリスクを避け、複数アプリの設定を一元管理できる。スキーマの進化も自分たちでコントロールできる。
S3であれば、最悪JSONファイルを作ってGUIのコンソールからドラッグ＆ドロップでファイルをアップロードするだけで、更新する仕組みができてしまう。最初期の段階では、これが一番手軽でいいと考えている。ただ、後々ロールバックの戦略などを検討するにあたって、更新方法を絞って適切に行えるようにする必要があると思う。
考慮事項とスコープ外
考慮事項
後方互換性 スキーマはv1→v2へ進化する。旧アプリが新スキーマを読めない問題は、スキーマ設計で後方互換性を保つことで対応する。
セキュリティ JSON改ざんリスクは社内セキュリティの管理次第だ。権限最小の原則でS3バケットを管理し、CloudFrontの署名付きURLなども検討する。
スコープ外とする事項
ロールバック戦略 JSON更新ミスが全ユーザに即反映されるリスクはある。ロールバック戦略は別途検討が必要だ。
クライアントのネットワークエラーハンドリング 初回起動時のJSON取得失敗や、オフライン時の動作はアプリ側の責務だ。アプリ側で最適なハンドリングを行うべき。
オフライン前提のアプリ この方式は起動時のネットワークアクセスを前提としている。オフラインが基本となるアプリには向かない。
実際の運用シーン
この方式が有効なのは以下のケースだ。
ドメイン変更が発生したとき。旧ドメインを維持し続ける必要がなくなり、JSONを更新するだけで新エンドポイントに誘導できる。
メンテナンス告知が必要なとき。metadata.jsonのmaintenance_modeを有効にするだけで、アプリ側がメンテナンス画面を表示してくれる。停止を伴う作業の前にユーザーへの伝達が確実に行える。
複数アプリの設定を統一管理したいとき。ドメインは1つに集約しつつ、アプリごとにパスを切ってメタデータを配置する。管理ポイントを減らせる。
所感と問いかけ
このアプローチはあくまで後ろのレイヤーから見た運用効率の話だ。モバイルアプリ開発の現場経験が豊富なエンジニアから見れば、足りていない視点やより良い方法があるかもしれない。
みなさんの現場では、ドメイン変更やメンテナンス告知をどう解決しているだろうか。Firebase Remote Configなどの既存サービスを使っているか、それとも自前実装をしているか。もしこの方式に対する懸念や改善案があればぜひ知りたい。