モバイルアプリのバックエンド・APIとオフライン同期：動き続けるアプリのアーキテクチャ

このガイドは、アプリのサーバーサイドを計画しているCTO・テクニカルリード・プロダクトオーナーを対象としています。モバイルプロダクト開発ガイドでは、ディスカバリーからスケールまでの全体像を簡潔に解説しています。このページでは、バックエンド・APIコントラクト・オフライン同期をより詳しく説明します。アプリ自体の開発方法については、ネイティブ vs クロスプラットフォームモバイル開発で比較しています。

目次

• Webサイトとは異なる、モバイルバックエンドが対応すべき課題
• モバイルクライアント向けAPIコントラクト
• オフライン同期：4つのモデル
• 競合と解決ルール
• サインイン・プッシュ・デバイスセキュリティ
• バックエンドの選択肢と選定基準
• AI機能とバックエンド
• ビルドプラン
• Netbase JSCのモバイルバックエンド開発
• 存在する納品実績と存在しない納品実績
• このガイドの限界
• よくある質問
• 次のステップ

Webサイトとは異なる、モバイルバックエンドが対応すべき課題

Webサイトはデプロイした瞬間にすべての訪問者に反映されます。しかしモバイルアプリはそうではありません。ユーザーは自分のタイミングでアップデートし、まったく更新しない人もいます。これにより、バックエンドには3つの重要な影響があります。

• 複数のクライアントバージョンが同時に存在する。サーバーは、サポート対象のすべてのアプリバージョンからのリクエストに応答する必要があります。フィールド名の変更や新しい必須パラメータの追加は、インストール済みの数千件のアプリに一夜にして影響を与える可能性があります。
• 途中で失敗するネットワーク。リクエストがサーバーに届いても、レスポンスが返ってこないことがあります。アプリがリトライした場合、バックエンドの実装が不適切だと注文が二重に作成されたり、決済が二重に実行されたりする可能性があります。
• サーバーから離れた場所での作業。現場スタッフ・出張者・地下にいる買い物客は、電波のない状態でアプリを開いても動作することを期待します。そして後から自分の変更が反映され、他の人の変更を上書きしないことを期待します。

モバイルクライアント向けAPIコントラクト

APIをWebフロントエンドの副産物としてではなく、独自のルールを持つプロダクトとして扱ってください。

• 意図的にバージョン管理する。フィールドは自由に追加できますが、サポート対象のアプリバージョンが参照している間は削除も名前変更もしてはいけません。破壊的な変更は新バージョンで行い、サポート最小バージョンを公開し、古いアプリにはバックエンドからアップデートを促してください。
• 画面に合わせてレスポンスを整形する。Backend for Frontend（BFF）レイヤーは、1つの画面に必要なデータのみを組み立てる薄いサービスで、低速ネットワークでのラウンドトリップを削減し、内部システムをアプリから隠蔽します。
• カーソルでページネーションする。オフセットではなくカーソルでリストをページングすることで、ユーザーがスクロール中に追加されたレコードが二重表示されたりスキップされたりしません。
• 作成リクエストをリトライ安全にする。RFC 9110ではPOSTを冪等ではないと定義しています。そのため、すべての作成リクエストはデバイス上で生成された冪等性キーを含み、サーバーはキーと結果を保存して、リトライには最初の結果を返します。
• デバイスに必要なものだけを送る。デバイスごとに画像をリサイズし、レスポンスを圧縮し、アプリの最終同期マーカー以降に変更されたレコードのみを送信します。
• アプリが対処できるエラーを返す。安定したエラーコードにより、アプリはリトライすべきか、再認証すべきか、停止すべきかを判断できます。

同じバックエンドがWebサイト・パートナー・内部システムも提供する場合、それらのフローのルールはエンタープライズシステム統合ガイドに記載しています。

オフライン同期：4つのモデル

データの種類ごとにモデルを選択してください。カタログ・ドラフトフォーム・決済ではそれぞれ異なる保証が必要です。

• オンライン専用（読み取りキャッシュあり）。アプリは最後に取得したデータを表示し、オフライン時は変更をブロックします。価格・在庫など、常に最新である必要があるデータに適しています。
• 書き込みキューイング。変更は送信キューに保存され、接続が復帰したときに順番に送信されます。Androidのオフラインファーストガイドでは、アナリティクスイベントやログなどのデータにこのパターンを推奨しています。
• ローカルファーストデータ。アプリはローカルデータベースに読み書きし、同期プロセスがサーバーと変更をやりとりします。Androidのガイドではローカルソースを「アプリの正規の情報源」と呼んでいます。メモ・点検記録・現場記録に適しています。
• マネージド同期サービス。プラットフォームがローカルデータベースとサーバーコピーを同期させ、競合処理を提供します。ただし、そのデータモデルを採用するコストが伴います。

同期はオンデマンド（プル）またはサーバーからアプリへの変更通知（プッシュ）で実行されます。Androidのガイドでは、短い切断期間にはプル、長いオフライン期間や関連データにはプッシュを推奨しています。

競合と解決ルール

2人が同じレコードを変更し、一方がオフラインだった場合、どちらかを優先する必要があります。最初のビルド前に、フィールドごとに書面でルールを決定してください。

• 最後の書き込みが優先。各変更にタイムスタンプを付け、新しいものを保持します。プロフィールやドラフトなど、1人が所有するデータに適しています。
• サーバーのルールが優先。デバイスが参照したときと同じバージョンのレコードである場合のみ、バックエンドが変更を受け入れます。それ以外の場合はアプリが現在の状態を表示し、ユーザーに確認を求めます。
• フィールド単位のマージ。異なるフィールドへの変更はどちらも保存され、同じフィールドへの競合がある場合のみルールが必要です。
• オフライン不可。決済・在庫予約・承認は、アプリの他の部分がどうであれ、オンライン中にサーバーで確認されます。

デバイス・ユーザー・バージョン・結果のサーバー同期ログを保持し、サポートがレコードに何が起きたかを説明できるようにしてください。

サインイン・プッシュ・デバイスセキュリティ

サインイン。モバイルアプリはシークレットを保持できません。IETF RFC 8252はネイティブアプリをパブリッククライアントに分類し、OAuthにはPKCE拡張を必須とし、サインインページは組み込みWebビューではなくシステムブラウザで開く必要があります。有効期限の短いアクセストークンとプラットフォームのセキュアストレージに保存したリフレッシュトークンを使用し、上位のバイオメトリック認証を提供してください。

プッシュ。Firebase Cloud Messagingはクロスプラットフォームメッセージングソリューションとして自身を説明しており、システムが表示する通知メッセージとアプリが自身で処理するデータメッセージがあります。アプリに同期を指示するにはデータメッセージを送信し、ユーザーが見るべき内容には通知を使用し、ユーザーが理解できるタイミングで許可を求めてください。

セキュリティ。OWASP モバイルアプリケーションセキュリティ検証標準（MASVS）は、ストレージ・暗号化・認証・ネットワーク通信・耐性のコントロールグループをまとめています。サーバー側では、アプリが何を表示・非表示にしているかにかかわらず、すべてのエンドポイントがユーザーの権限を自身で確認します。

バックエンドの選択肢と選定基準

4つの基準で判断します：今日データを所有しているのは誰か、プロダクトのオフライン動作はどの程度か、アプリが接続するシステムの数、そしてバックエンドを夜間に運用するのは誰か。バックエンドがストア・ERP・CRMとも連携する必要がある場合は、ERP・CRM・ECシステム統合アーキテクチャでフローを先に設計してください。Netbase JSCのシステム・API統合サービスがそのレイヤーを構築します。

Netbase JSCのモバイルバックエンド開発

Netbase JSCは、バックエンドプラットフォームページに記載のスタックで、長年採用を続けているReact Nativeを使用したクロスプラットフォームアプリを開発しています。3名から30名のチームにアナリスト・アーキテクト・開発者・QA・デザイナーが揃い、通常はディスカバリーから1〜2週間以内に作業を開始します。Netbase JSCのほとんどのプロジェクトはディスカバリー後に合意された請負契約で納品され（専任チーム vs 請負を参照）、カスタム開発ではクライアントがそのために作成されたIPを所有します。セキュリティ対策として、セキュアコードレビュー・転送中のTLS・保存時のAES・ロールベースのアクセス制御・管理ダッシュボードのMFAをカバーしています。モバイルアプリ開発サービス、または再利用可能なビルディングブロックが適する場合はモバイルプロダクトアクセラレーターをご覧ください。

存在する納品実績と存在しない納品実績

• 存在する実績。RBマーケットプレイス実績では、APIの監査後にマーケットプレイス独自のAPIを基に構築されたカスタマーショッピングアプリが記録されています。プッシュ通知・サーバーと同期するウィッシュリスト・オフラインブラウジングを備え、AndroidとiOSは拡張スコープとして含まれています。Dey Page実績では、WebディレクトリーのバックエンドとWebディレクトリーと同じバックエンドを持つiOSとAndroid向けのReact NativeアプリとしてReact Nativeアプリが記録されています。電話OTPアカウント・プッシュ・ディープリンクを備えており、オフライン同期付きの現場キャプチャはモバイルWebアプリで動作します。リワードショップ実績では、クライアント独自のアプリ向けモバイルUIコンポーネントとWebhookおよびスケジュール同期によるクライアントシステムとの同期が記録されています。クライアント名は公開されていません。
• 存在しない実績。これらの実績には、ダウンロード数・使用状況・稼働時間・同期量・エラー率は公開されておらず、RBマーケットプレイス実績にはフレームワーク名の記載もありません。どれかの同期モデルやバックエンドルートがより優れていることを証明するものとして提示されていません。

このガイドの限界

• プラットフォームに関する記述は、アクセス日時点のAndroid・IETF・Firebase・OWASPのページに基づいています。プラットフォームは変化するため、現在のバージョンを確認してください。
• 同期モデルはビジネス・コマース・現場アプリに適しています。リアルタイムコラボレーションやゲームには独自の設計が必要です。
• セキュリティ対策はリスクを低減しますが、特定のアプリやバックエンドについて保証するものではありません。

よくある質問

既存のWebバックエンドでモバイルアプリに対応できますか？多くの場合、バージョン管理・キャッシュ・各画面向けのレスポンス整形を追加する薄いモバイルレイヤーを介して対応できます。コアが遅すぎたり安全に変更できない場合のみ、再構築を検討してください。

旧アプリバージョンをどれくらいサポートすべきですか？意味のある割合のユーザーがまだ使用している間はサポートしてください。サポート最小バージョンを公開し、バージョンを上げる前に警告を出してください。

すべてのアプリにオフラインモードが必要ですか？いいえ。データ種別ごとに判断してください。読み取り用のキャッシュは安価ですが、オフラインでの変更にはキュー・競合ルール・より多くのテストが必要です。

リトライリクエストによる重複注文を防ぐにはどうすればよいですか？デバイス上で生成された冪等性キーをサーバーが最初の結果と共に保存することで、リトライは2件目の注文を作成せず、その結果を返します。

次のステップ

アプリがオフラインで保持する必要があるデータ・読み取り元システム・現在使用中のアプリバージョンをお知らせください。ソリューションレビューを予約し、APIコントラクトとデータ種別ごとの同期モデルをマッピングします。モバイルアプリ開発またはNetbase JSCのインサイトもご覧いただけます。

関連サービスとソリューション