LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

オフラインファーストとは — ローカル書き込み優先・復帰時同期の設計思想

オフラインファースト対応モバイルアプリの開発外注とは、ネットワーク不通の状態でもアプリが正常に動作し、接続回復時にサーバーとデータを同期する「オフラインファースト設計」を持つアプリを、専門の外部パートナーに委託して開発することを指します。

オフラインファーストの根幹にある考え方は「ネットワークは常につながっている前提にしない」というものです。通常の「オンライン前提アプリ」はAPIリクエストが失敗するとデータを保存できませんが、オフラインファーストアプリはまず端末内のローカルストレージにデータを書き込み、接続が戻った時点でサーバーに送信します。

この設計は、競合解決（コンフリクト）やデータ整合性の維持など、通常のアプリ開発には登場しない技術的難所を伴います。外注を成功させるには、これらの難所を正確に理解した外注先の選定と要件定義が不可欠です。

オフラインファーストが必要な現場 — フィールドサービス・物流・医療介護など

オフラインファースト設計が特に価値を発揮する現場は、通信環境が不安定または通信自体が禁止される業務が伴う場所です。以下に代表的な利用現場を挙げます。

フィールドサービス・設備点検：電気・ガス・水道などのインフラ点検、空調・エレベーターの保守作業は、地下・トンネル・山間部など電波の届きにくい場所で行われます。作業員が現場でタブレットに点検結果を入力し、事務所に戻ったときやWi-Fiに接続したときに一括でサーバーへ送信する用途に適しています。

物流・倉庫管理：大型倉庫の内部や冷凍倉庫では電波が遮断されることがあります。入荷・出荷・棚卸しの作業をオフラインで続けながら、休憩時や業務終了後に同期するフローが業務継続性を担保します。

医療・介護の訪問サービス：訪問看護・訪問介護では、患者宅のWi-Fi環境や屋外移動中のモバイル電波に左右されず、ケア記録の入力が行えることが求められます。記録漏れは医療上のリスクに直結するため、オフライン時でも記録できる設計が求められます。

建設・土木の現場管理：建設現場は電波状況が流動的で、鉄筋コンクリートの建物内や地下での作業中は通信が途切れます。進捗報告・危険確認・図面参照をオフラインで行えるアプリは現場効率を大きく改善します。

共通するのは「その場でデータを記録できなければ業務が止まる、または情報が失われる」という性質です。通信環境が安定したオフィス向けシステムとは異なる設計思想が求められます。

ローカルDBの選択肢 — SQLite・Realm・WatermelonDB・Room・Core Data

オフラインファーストアプリは端末内にローカルデータベース（ローカルDB）を持ち、そこを「まず書く先」とします。代表的なローカルDBを以下に整理します。

ローカルDBの選定はプラットフォーム（iOS・Android・クロス）と、その後の同期基盤の選択と密接に連動します。外注先が「なぜそのDBを選んだか」を技術的に説明できることが、選定品質の判断基準になります。

同期方式と競合解決戦略 — LWW・バージョン管理・CRDTを正しく選ぶ

オフラインファースト設計の技術的な核心は「同期方式の設計」と「競合解決（コンフリクト）戦略の選択」にあります。ここを誤ると、データの消失・矛盾・業務上の重大ミスにつながります。

同期方式の分類

同期方式には大きく分けて3種類があります。

一方向同期（プル型）はサーバーから端末へのみデータを配信する方式です。マスターデータの配布（製品カタログ・マニュアル・地図データ）に向いています。端末側の書き込みは起きないため競合解決の問題が発生せず、実装難易度は低いです。

一方向同期（プッシュ型）は端末からサーバーへのみデータを送信する方式です。センサーデータのアップロードや点検結果の報告など、「端末が書いてサーバーに集める」だけで完結する用途に向いています。複数端末が同じレコードを書き換える可能性がなければ競合解決は単純になります。

双方向同期はサーバーと端末が互いに書き込み、双方向で差分をやりとりする方式です。複数ユーザーが同じデータを参照・更新するグループウェア的なアプリや、チームで共有する点検票・作業記録に必要です。実装難易度は大幅に上がり、競合解決の設計が不可欠になります。

競合解決の主要戦略

双方向同期で複数の端末が同じデータを同時に書き換えた場合、「どちらを正とするか」を決めるのが競合解決です。代表的な戦略を以下に整理します。

Last-Write-Wins（LWW）は「タイムスタンプが最も新しい書き込みを採用する」シンプルな方式です。実装が容易ですが、端末の時計のズレがあると意図しない上書きが起きるリスクがあります。また、後から届いた変更が先に届いた有効な変更を消してしまう「失われた更新」の問題が発生することがあります。業務影響が軽い項目や、一人のユーザーしか編集しないレコードには適していますが、複数人が同じレコードを同時編集するシナリオには不向きです。

バージョン管理（楽観ロック）はレコードにバージョン番号や更新トークンを付与し、更新時に「読み込んだ時点のバージョンと一致するか」を確認する方式です。一致しない場合は競合と判定してエラーを返し、アプリ側でユーザーに再確認を促します。データの一貫性は高い一方で、競合が頻発する環境ではユーザーの操作負担が増えます。

CRDT（Conflict-free Replicated Data Type）は数学的な特性を利用して、どの順序でマージしても同じ結果になることを保証するデータ構造です。リアルタイムコラボレーション（NotionやFigmaのような複数人同時編集）に採用されており、自動マージによりユーザーに競合を意識させない体験を実現できます。ただし、実装の複雑さが大きく、すべてのデータ型に適用できるわけではないため、採用の判断は慎重に行う必要があります。

サーバー権威（Server Wins）はサーバー側の状態を常に正として、端末の変更を送信しても受け入れられないリスクを受容する方式です。在庫引き当て・座席予約のように「先に確保した方が正」となるビジネスロジックに適合することがあります。

競合解決の設計ミスは、公開後の重大なデータ不整合につながります。外注先が各戦略のトレードオフを説明した上で、業務要件に合わせた選択を提案できるかが技術力の目安です。

同期基盤の選択肢 — Firebase・Couchbase・PouchDB＋CouchDB・独自API

ローカルDBとクラウドを接続してデータを同期する「同期基盤」の選定も、外注費用と開発難易度を左右します。代表的な選択肢を整理します。

Firebase Cloud Firestore（Googleのオフライン対応BaaS）は、SDKレベルでオフラインキャッシュと自動同期が組み込まれているため、単純な同期ユースケースであれば実装コストを大幅に抑えられます。ただし、キャッシュサイズの上限・複雑な競合解決のカスタマイズ・大量データの集計クエリには制約があります。スタートアップや中規模の業務アプリの一般的な同期要件に向いています。

Couchbase Mobile（Couchbase Lite + Sync Gateway）は、企業向けの本格的なオフライン同期に実績のあるソリューションです。端末上のCouchbase Liteがローカルストレージとして機能し、Sync Gatewayを経由してサーバーのCouchbase Serverと双方向同期します。競合解決のカスタマイズ自由度が高く、医療・製造・フィールドサービスの厳しい要件に対応した導入実績があります。ライセンスコストとサーバー構築の工数が必要な点は留意が必要です。

PouchDB＋CouchDB（CouchDBプロトコル）はオープンソースの組み合わせです。CouchDBはコンフリクト検出と多版同時管理（MVCC）を標準で持つデータベースで、PouchDBはブラウザ・React Native上で動作するJavaScriptのローカルDBとして機能します。CouchDBプロトコルに対応したサーバー（Apache CouchDB・IBM Cloudant等）との同期が可能です。オープンソースであるためライセンスコストを抑えられますが、運用管理は自社で担う必要があります。

独自APIによる同期ロジックは、REST APIやGraphQL APIを自前で実装して同期を行う方式です。ビジネスロジックに完全に合わせた設計ができる反面、差分検出・競合解決・再試行制御などをすべて自前で実装する必要があり、開発工数が大きくなります。既存バックエンドへの組み込みや、上記の同期基盤が要件に合わない場合の選択肢です。

同期基盤の選定はアプリの規模・要件・将来の拡張性と一体で判断する必要があります。外注先が複数の選択肢を比較提示できる体制かどうかが、技術選定の品質を左右します。

外注費用の相場と費用を決める要因

以下の費用レンジはいずれも市場参考値であり一次資料に基づく確定値ではありません。実際の費用は要件・体制・外注先によって大きく異なります。複数社から見積もりを取ることが実態把握の前提です。

費用に影響する主な変数を4点整理します。

①競合解決の複雑さ：一方向同期のみであれば競合解決は不要ですが、複数ユーザーが同じレコードを同時編集するシナリオが増えるほど設計・テスト工数が積み上がります。CRDTの実装は特に高コストです。

②オフライン継続時間の要件：数時間のオフラインか数日か、また同期間隔（ほぼリアルタイムか業務終了時の一括か）によってデータ量の設計と同期処理の負荷が変わります。

③テストの難しさ：オフラインファーストアプリのテストは、ネットワーク断・復帰・競合発生・同期失敗・端末スリープなど多数の状態遷移をシミュレーションする必要があります。この検証工数は通常のアプリ開発の1.5〜2倍程度になることがあります。費用見積もりにテスト工数が明示されているかを確認してください。

④ストレージ容量の設計：端末に蓄積するデータ量が大きい場合（大容量の図面・写真・動画を含む業務など）、ストレージ管理・古いデータの自動削除・圧縮の実装が追加工数として発生します。

外注の進め方 — オフライン要件定義が進行を左右する

オフラインファーストアプリの外注では、「オフライン要件の洗い出し」を要件定義の最初に置くことが手戻りを防ぐ上で重要です。以下に典型的な5ステップを整理します。

1. ステップ1：オフライン要件の洗い出し
   「オフライン中に何を読めればよいか」「何を書けなければならないか」「オフラインが許容される上限時間は何時間か」「複数人が同じデータを同時に書き換えるシナリオはあるか」の4点を業務担当者と一緒に確認します。この問いへの答えが技術選定全体の方向性を決めます。
2. ステップ2：技術選定（ローカルDB・同期基盤・競合解決方式）
   ステップ1の要件をもとに、ローカルDB・同期基盤・競合解決戦略の組み合わせを決定します。外注先が複数の選択肢をトレードオフ込みで提示できることが理想的です。
3. ステップ3：同期設計ドキュメントの確認
   「どのデータがオフライン対象か」「競合が発生したときの処理フロー」「同期失敗時のリトライ方針」を文書化した設計ドキュメントを外注先に作成してもらい、発注前にレビューします。この文書が存在しない提案には慎重な判断が必要です。
4. ステップ4：開発・単体テスト・結合テスト
   ローカルDB実装・同期ロジック実装を進めながら、各ステップでネットワーク断・復帰・競合発生のテストを実施します。テスト項目に「オフライン状態でのCRUD操作」「長時間オフライン後の同期」「競合発生時の解決確認」が含まれているかを発注者が確認できる体制が望ましいです。
5. ステップ5：リリースと運用保守体制の確立
   リリース後もOSバージョンアップ・同期基盤のアップデートへの追随が必要です。競合解決ロジックのバグが本番環境で発見された場合の緊急対応フローを、リリース前に合意しておくことが重要です。

ステップ1のオフライン要件洗い出しを省略または曖昧にしたまま開発を進めると、後から「複数人が同じレコードを書き換えるシナリオが実はある」と判明し、競合解決ロジックの大規模改修が発生することがあります。この手戻りは費用と納期の両面で大きな影響を持ちます。

内製で要件定義を行う場合には、同期設計・競合解決・分散システムの知識を持つエンジニアが必要です。これらの専門知識が社内にない状態では、要件の抜け漏れリスクが高まります。外注先に要件定義フェーズから参加してもらい、共同でオフライン要件を定義する進め方が有効です。

同期実績・競合解決設計力で見極める外注先の選び方

オフラインファースト対応アプリの外注先選定では、「同期設計と競合解決の実装経験があるか」が通常のモバイル開発外注よりも重要な確認ポイントになります。

確認ポイント1：オフライン同期の実際の納品実績
「オフラインファースト設計で開発した案件の具体的な実績があるか」を確認します。現場系アプリや業務系アプリの同期実装実績が、技術力の有無を判断する出発点です。実績が言葉だけの説明にとどまる場合は、使用したローカルDB・同期基盤・競合解決の方式を具体的に確認してください。

確認ポイント2：競合解決戦略を説明できるか
「LWW・バージョン管理・CRDTのどれがどのような要件に向くか」を技術的に説明できるかどうかが、設計力の指標です。「とりあえずFirebaseを使えば大丈夫」という回答しか得られない外注先では、複雑な競合解決が要件に含まれる案件への対応に難がある可能性があります。

確認ポイント3：テスト設計にオフライン状態が含まれているか
見積もりや提案書に「ネットワーク断・復帰・競合発生シナリオのテスト」が明記されているかを確認します。これが含まれていない場合、リリース後に本番環境で競合バグが発見されるリスクがあります。

確認ポイント4：要件定義から保守まで一貫対応できるか
オフライン要件の洗い出しは業務理解と技術知識の双方が必要です。技術選定段階からオフライン設計の適否を含めて提案できる体制かどうかを確認してください。複数の下請けベンダーを跨ぐ体制では、同期ロジックの責任範囲が曖昧になりやすい点に注意が必要です。元請（プライムベンダー）として要件定義から保守まで一気通貫で担えるパートナーを選定することが、品質リスクを低減する上で有効です。

まとめ：オフラインファースト外注の3つの判断軸

本稿では、オフラインファースト対応モバイルアプリの開発を外注する際の技術的な背景・費用構造・進め方・外注先の選び方を整理しました。要点を3つに集約します。

第一に、競合解決（コンフリクト）の設計が費用と品質の分岐点です。一方向同期に留まる場合と、双方向同期＋CRDT実装が必要な場合では費用規模が数倍異なります。複数ユーザーが同じレコードを同時書き換えするシナリオがあるかどうかを要件定義で早期に確認することが、予算計画の精度を高めます。

第二に、オフライン要件の洗い出しを要件定義の最初に置くことです。「何をオフラインで読み書きする必要があるか」「オフライン継続の許容時間」「複数人同時編集のシナリオ」の3点を最初に固めると、ローカルDB・同期基盤・競合解決方式が絞り込めます。これを後回しにした場合、開発後半での大規模改修リスクが高まります。

第三に、同期実装・競合解決の実績がある外注先を選ぶことです。通常のモバイル開発実績だけでは、オフライン同期の品質を担保できません。競合解決戦略を技術的に説明でき、テスト設計にオフラインシナリオが含まれているかを確認することが、後工程の手戻りリスクを抑える鍵になります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Google「Firebase公式ドキュメント — Cloud Firestore でのオフライン データへのアクセス」（https://firebase.google.com/docs/firestore/manage-data/enable-offline）
2. *2　出典：Couchbase「Couchbase Mobile公式ドキュメント」（https://www.couchbase.com/products/mobile/）
3. *3　出典：Apache Software Foundation「Apache CouchDB公式ドキュメント」（https://docs.couchdb.org/en/stable/）

Tweet