1. HOME
  2. ブログ
  3. アプリ・システム開発の基礎知識
  4. オフラインファーストPWAとCRDTを活用したリアルタイム共同編集機能の基礎知識
BLOG

ブログ

アプリ・システム開発の基礎知識

オフラインファーストPWAとCRDTを活用したリアルタイム共同編集機能の基礎知識

オフラインファーストPWAのメリットと要件

近年、スマートフォンやタブレット端末の普及に伴い、ユーザーは常に安定したインターネット接続を持つわけではありません。業務やフィールドワーク向けの業務システム開発においては、ネットワークが断続的に切断されても主要機能を使い続けられるオフラインファーストの設計が求められています。PWA(Progressive Web App)は、ブラウザベースでありながらネイティブアプリのようにホーム画面へのアイコン表示、プッシュ通知、バックグラウンド同期などが可能です。まず要件定義では次の項目を整理しましょう。

  • オフライン時の機能一覧:データ参照、入力、編集、一覧表示など、どこまでオンラインと同等のUXを保つか

  • データ同期モデル:オンライン復帰時に自動同期/手動同期/プッシュ通知同期のいずれを採用するか

  • ストレージ選定:IndexedDB/Cache API/localStorage/Service Workerキャッシュの組み合わせと容量要件

  • セキュリティ要件:オフライン時のデータ暗号化/認証トークンの有効期限管理

  • 対応端末とブラウザ:iOS Safari、Android Chrome、Desktop Chrome/Firefox/Edgeのサポート範囲

これらを要件定義書に落とし込み、見積もり依頼の際には各機能ボリュームとストレージ要件を一覧で提示すると、Web開発会社やアプリ開発会社に正確な工数を算出してもらいやすくなります。

CRDTによるリアルタイム共同編集の仕組み

オフラインファースト環境下でリアルタイム共同編集を実現するには、衝突(コンフリクト)を自動で解消できるデータ構造が必要です。CRDT(Conflict-free Replicated Data Type)は、各クライアントが独立して変更を行い、オンライン復帰時に差分をマージして一貫性のとれた状態を保証します。代表的なCRDTとしては以下の種類があります。

  • G-Counter / PNCounter:単純なカウンター型の加算/減算

  • G-Set / 2P-Set:要素の追加/削除の管理

  • LWW-Element-Set:最終更新タイムスタンプ(Last-Write-Wins)による優先

  • RGA(Replicated Growable Array):テキストエディタ向けの配列型

  • Map CRDT:オブジェクト/ドキュメント構造のネストに対応

典型的な実装例として、Automerge.jsやYjsといったライブラリがあり、ブラウザとNode.jsの両環境で動作します。PWAのService WorkerやIndexedDBと連携し、ローカルでの変更履歴をPersistentに保持。オンライン復帰時にはWebSocketやWebRTC DataChannelを通じてサーバー及び他クライアントに変更をブロードキャストし、CRDTライブラリが自動的に差分をマージしてUIを更新します。

要件定義では「同時編集最大ユーザー数」「更新頻度(1秒あたりの変更回数)」「同期遅延許容値(最大◯秒)」を明示し、開発会社選びの際に「CRDT搭載コスト」「リアルタイム通信インフラ費用」を見積もり比較できるようにしておくと、コスト削減と費用対効果が見やすくなります。

PWAアーキテクチャと技術スタック

オフラインファーストPWAにCRDTベースの共同編集を組み込む際の推奨アーキテクチャは以下のとおりです。

  1. クライアント層

    • フレームワーク:React/Vue 3 Composition API/Svelte

    • データ管理:Yjs(Awareness API含む)/Automerge

    • ストレージ:IndexedDB via Dexie.js

    • ネットワークレイヤ:Service Worker で Cache API + Background Sync + WebSocket

  2. リアルタイム通信層

    • プロトコル:WebSocket or WebRTC DataChannel

    • サーバー:Node.js + ws または mediasoup/signalhub for WebRTC

    • 負荷分散:nginx+Sticky Session Or Redis Pub/Sub for Scale-out

  3. 同期サーバー/永続化層

    • ドキュメント保存:CouchDB/MongoDB + CRDT Persistence Adapter

    • メッセージブローカー:Redis Streams/Apache Kafka for Durable Sync

    • APIサーバー:Express / Fastify / NestJS with JWT Authentication

  4. 認証・認可

    • 認証:OAuth2.0+OpenID Connect(Keycloak, Auth0, AWS Cognito)

    • 認可:RBAC or ABAC with Claims-Based Access Control in JWT

  5. CI/CD・インフラ

    • Infrastructure as Code:Terraform for AWS / GCP

    • コンテナ:Docker Compose for Local, Kubernetes (EKS/GKE) for Prod

    • CI/CD:GitHub Actions or GitLab CI with Lint/Test/Build/Deploy pipeline

これらのスタック構成を要件定義書に落とし込み、各コンポーネントの導入工数とライセンス費用、クラウドリソース見積もりを含めると、発注時点でWebシステム開発費用や見積もり依頼コストの透明性が向上します。

オフラインデータ同期とバックグラウンド同期戦略

オフライン時に行われたCRDT変更の永続化にはIndexedDBを利用し、Service WorkerのBackground Sync APIでオンライン復帰をトリガーします。同期戦略は以下の二通りがあります。

  • プッシュ型同期:端末がオンラインになった瞬間に変更を即座にサーバーへ送信

  • プル型同期:定期的にサーバーへ問い合わせて差分を取得・マージ

リアルタイム性を重視する場合はプッシュ型を採用し、変更ごとに小さなパケットを送受信します。帯域制限やコスト制約が厳しい場合は、プル型で5秒~30秒間隔のバッチ同期を実装すると良いでしょう。要件定義では「最大同期遅延」「バッチ同期間隔」「帯域幅上限」を数値化し、アプリ開発会社への見積もり資料に明記してください。

UI/UX設計の留意点

リアルタイム共同編集機能を提供する際のUX課題として、他ユーザーの編集中領域を視覚的に示す「カーソル・ハイライト表示」や「変更履歴の再生機能」が挙げられます。YjsのAwareness APIを用いれば、各クライアントの接続状況やカーソル位置、選択範囲などを共有でき、ユーザーごとに固有カラーを割り当ててUIに反映できます。また、オフライン状態では編集モードを切り替え、再同期時にコンフリクトが起きたフィールドだけをハイライトし、ユーザーが手動で解決できる仕組みを検討します。

UX改善施策としては、編集保留中の変更がある場合にステータスバーで通知し、ユーザーがオンライン復帰後に同期ボタンを押すことで視覚的に操作できるようにすることも有効です。これらのUI/UX機能を要件に含め、開発予算シミュレーションに反映してください。

セキュリティとデータ保護

オフラインデータも含めた全データを保護するため、IndexedDB上のデータをAES-GCMで暗号化し、Service Worker経由で復号を行う仕組みを導入します。また、CRDT変更履歴も暗号化対象に含め、盗難や紛失時のリスクを軽減。通信時にはTLS1.3を強制し、WebSocket Secure(wss://)でエンドツーエンド暗号化を担保します。

認証トークンは短時間有効のAccess Tokenと、長期間有効だがRefresh Tokenを組み合わせたOAuth2.0のPKCEフローを採用。オフライン時はAccess Tokenの期限切れを検知して自動Refreshを試みるか、再認証画面を表示するポリシーを設計段階で決定し、見積もり依頼時に「セキュリティ実装工数」として提示できるよう整理します。

テスト戦略と品質保証

オフラインファーストPWAとCRDTを組み合わせた共同編集機能では、ユニットテストに加え、オフライン・オンライン両状態での動作を検証する統合テストが不可欠です。まずユニットテストでは、IndexedDBに保存された編集履歴の読み書き、CRDTライブラリの差分生成/マージロジック、Service Workerのインストール・アクティベーション、プッシュ通知ハンドラなど、各モジュール単位で網羅的に検証します。

次に統合テストでは、PuppeteerやPlaywrightでブラウザをヘッドレス起動し、オフライン状態でテキスト編集→オンライン復帰→差分同期→他クライアント反映までのE2Eシナリオを自動化します。さらに、AutomergeやYjsが生成するCRDTメッセージのスキーマ検証、WebSocketサーバーへの接続切断・再接続テスト、IndexedDBストレージ容量オーバー時のエラー処理も含め、品質ゲートを設けてCIパイプライン上で常時実行します。

CI/CDパイプライン構築

開発効率と品質を両立するため、GitHub ActionsやGitLab CIを用いて以下のワークフローを自動化します。プルリクエスト作成時にLint(ESLint/Stylelint)→ユニットテスト→統合テスト→ビルド(Webpack/Vite)→PWAのService Workerキャッシュ有効性テスト→プレビュー環境デプロイを実行。ステージングへの自動デプロイ後、CypressによるE2Eテストがすべてパスしない限り、本番環境へのマージを許可しないGatekeeperを設定します。

本番デプロイ時はBlue/GreenやCanaryリリースを行い、ユーザーセッションへの影響を最小化。Release Notes自動生成ツール(Conventional Commits+semantic-release)を組み込み、バージョン管理と依存関係の更新履歴を一元化します。これにより、Webシステム開発フロー全体を標準化し、見積もり依頼時には「CI/CDパイプライン構築工数」「E2Eテスト自動化工数」として正確に提示できます。

パフォーマンスチューニングとスケーラビリティ

PWAのオフラインキャッシュは、初回ロードサイズを400KB以下に抑え、Service Workerで必要なアセットを部分的にプリキャッシュすることで、起動時間を2秒以内に最適化します。CRDT処理はWebAssemblyモジュール(Automerge-WASM)を利用し、差分計算をメインスレッドから移すことでUIスレッドのブロックを回避。変更量が大きい場合には、操作履歴を分割コミットし、パフォーマンス劣化を防止します。

リアルタイム同期サーバー(WebSocket)は、水平スケールを考慮してnginx+Node.jsクラスター構成とし、Redis Pub/Subを利用したステートレス設計を採用。同時接続ユーザー数1万セッションを目標に、1インスタンスあたり2,000セッションをサポートする構成を検証。これらの性能要件を要件定義に含めることで、見積もり比較時に「スループット要件」「スケールアウト要件」を明確に伝えられます。

運用保守とモニタリング

運用フェーズでは、SentryやLogRocketを組み込み、クライアントエラーやクラッシュレポートをリアルタイム収集。Service Workerの更新失敗やオフライン同期エラーもキャプチャし、Slack連携で開発チームに通知します。また、PrometheusとGrafanaを用い「プッシュ同期失敗率」「Service Worker更新成功率」「CRDT同期レイテンシ」「IndexedDBストレージ使用量」などを可視化し、障害兆候を早期に検知。PagerDuty連携でオンコール体制を構築し、MTTR(平均復旧時間)を30分以内に短縮します。

運用ドキュメントとしては、Confluenceに「IndexedDB再初期化手順」「Service Workerキャッシュクリア手順」「CRDTマージコンフリクト解消ガイド」を整備。これらRunbookの整備工数を見積もり依頼資料に含めることで、運用保守コストの見通しを明確化可能です。

コストシミュレーションと予算管理

初期開発費用は以下の要素で試算します。

  • 要件定義・アーキテクチャ設計:300万円

  • PWA基盤構築(Service Worker/IndexedDB):400万円

  • CRDT統合開発(Yjs or Automerge):500万円

  • UI/UX設計(共同編集UI):200万円

  • CI/CD・テスト自動化:200万円

  • ドキュメント・Runbook整備:150万円
    合計:約1,750万円

ランニングコストはホスティング(Kubernetes/EKS or Cloud Run)月額15万~25万円、CDNキャッシュ帯域月額10万~20万円、モニタリングツール月額5万〜10万円を見込んでおり、年間約360万~660万円の予算を試算。AWS BudgetsやGCP Budgetsと連携し、予算使用率80%超でSlack通知を発信する仕組みを構築し、開発予算のオーバーランを未然に防止しています。

システム 開発会社 選び方 予算 費用 相場 発注

オフラインファーストPWA+CRDT共同編集機能の受託先選定では、以下の観点で要件定義書とWBSを提示し、複数社から見積もりを取りましょう。

  1. PWA開発実績:Service Worker/IndexedDB実装経験

  2. リアルタイム通信:WebSocket or WebRTC構築事例

  3. CRDT統合:Yjs/Automerge導入経験+パフォーマンスチューニングノウハウ

  4. CI/CD自動化:E2Eテスト/プレビュー環境構築経験

  5. 運用監視:Sentry/Prometheus/Grafana統合ノウハウ

相場感は、小規模(1,200万~1,800万円)、中規模(2,000万~2,800万円)、大規模(3,000万~4,500万円)を目安に、固定価格型と時間単価型の両面で比較し、コスト削減と品質保証を両立できるパートナーを選定してください。

まとめ

オフラインファーストPWAとCRDTを活用したリアルタイム共同編集の基礎知識として、要件定義からアーキテクチャ設計、オフラインデータ同期、UI/UX設計、テスト戦略、CI/CD、パフォーマンスチューニング、運用保守、コストシミュレーション、開発会社選定のポイントまでを網羅的に解説しました。安定したオフライン体験とリアルタイムコラボレーションを実現するための技術要素を整理し、見積もり依頼時には本記事の要素分解を活用して最適なパートナーとともにプロジェクトを推進してください。

お問合せ

不明点やお見積りの依頼などお気軽にください。




問い合わせを行う

関連記事