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

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

このガイドの内容

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

モバイルバックエンドがWebサイトと異なる対応事項とは？

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

• 複数のクライアントバージョンが同時に存在する。サーバーは引き続きサポートするすべてのアプリバージョンに応答しなければなりません。フィールド名の変更や新しい必須パラメータの追加は、一夜にして数千のインストール済みアプリを壊す可能性があります。
• 途中で失敗するネットワーク。リクエストがサーバーに届いたにもかかわらず、レスポンスが途中で失われることがあります。アプリがリトライした際、不用意なバックエンドでは2つ目の注文や2回目の決済が発生してしまいます。
• サーバーから離れた場所での作業。フィールドスタッフ、出張者、地下にいるショッパーはシグナルなしでアプリを開き、動作することを期待します。そして後から変更が届き、他の人のデータを上書きしないことを期待します。

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

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

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

同じバックエンドがWebサイト、パートナー、内部システムにも対応する場合のルールについては、エンタープライズシステム統合ガイドをご覧ください。

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

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

• 読み取りキャッシュ付きオンラインのみ。アプリは最後に取得したデータを表示し、オフライン中の変更をブロックします。価格、在庫、必ず最新でなければならないデータに適しています。
• 書き込みキュー。変更は送信キューに保存され、接続が回復したときに順番に送信されます。Androidのオフラインファーストガイドでは、分析イベントやログなどのデータにこのパターンを挙げています。
• ローカルファーストデータ。アプリはローカルデータベースに対して読み書きし、同期プロセスがサーバーと変更をやり取りします。Androidのガイドでは、ローカルソースを「アプリにとっての正規の真実のソース」と呼んでいます。メモ、点検記録、フィールド記録に適しています。
• マネージド同期サービス。プラットフォームがローカルデータベースとサーバーのコピーを同期させ、競合処理を提供します。その代わりに、そのデータモデルの採用が必要です。

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

競合とその解決方法

一方がオフラインの間に2人が同じレコードを変更した場合、どちらかを優先しなければなりません。フィールドごとに書面で決め、最初のビルド前に行ってください。

• 最後の書き込みが勝つ。各変更にタイムスタンプを付け、新しい方を保持します。シンプルで、プロフィールや下書きのように1人が所有するデータに適しています。
• サーバーがルールを決める。デバイスが見たバージョンとレコードのバージョンが一致する場合のみ、バックエンドが変更を受け入れます。一致しない場合、アプリは現在の状態を表示してユーザーに確認を求めます。
• フィールド単位でマージする。異なるフィールドへの変更は両方とも反映されます。同じフィールドへの競合のみルールが必要です。
• オフライン禁止。決済、在庫予約、承認はオンライン中にサーバーで確認されます。アプリの他の部分がどうであれ変わりません。

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

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

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

プッシュ。Firebase Cloud Messagingは、自らをクロスプラットフォームのメッセージングソリューションと定義しており、システムが表示する通知メッセージとアプリが処理するデータメッセージを提供しています。アプリの同期をトリガーするにはデータメッセージを、ユーザーが必ず確認すべき情報には通知を送り、ユーザーが意図を理解したタイミングで許可を求めてください。

セキュリティ。OWASP Mobile Application Security Verification Standardは、ストレージ、暗号化、認証、ネットワーク通信、耐性に関するコントロールをグループ化しています。サーバー側では、アプリが表示・非表示にかかわらず、すべてのエンドポイントが自らユーザー権限を確認します。

バックエンドルート：選択肢と選定基準

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

Netbaseのモバイルバックエンド構築方法

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

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

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

このガイドの限界とは？

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

次のステップ

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

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