Skip to content
Published on

PWA & オフラインファースト同期エンジン2026完全ガイド - Workbox · Replicache · RxDB · Y.js · Automerge · LiveStore · ElectricSQL · Zero · Ground 深掘り

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

「ローカルファーストソフトウェアとは、データの所有権がユーザーのデバイスに置かれ、サーバーは同期の補助役にすぎないシステムを指す。2026年に至って、これはもはや学術的なマニフェストではなく、Linear・Figma・Notion・Tldrawが毎日数百万人に届けている実プロダクトの既定アーキテクチャとなった。」 — Martin Kleppmann、Ink & Switch、Local-first Softwareマニフェスト7周年講演（2025）

ウェブアプリが「オンライン専用フォーム」から「オフラインファーストツール」へ進化した流れは、2017年のPWA登場 → 2019年のWorkbox安定化 → 2021年のCRDT大衆化 → 2023年のLinearのSync Engine公開 → 2024-25年のReplicache・Zero・ElectricSQL・LiveStore・Ground・Triplitの爆発的登場という段階を経ました。2026年5月現在、この市場の中心的な問いはもはや「Service Workerでどうキャッシュするか」ではありません。「どの同期エンジンで自社ドメインの衝突を解決し、クライアント側SQLite/IndexedDBとサーバーPostgresをどう双方向に結ぶか」 です。

本稿ではPWAの基盤技術（Service Worker・Cache API・IndexedDB・OPFS・Background Sync）、Workbox 8のキャッシュ戦略、Replicache/Zeroのmutatorモデル、RxDBのマルチタブ同期、Y.js/AutomergeのCRDT構造、ElectricSQL/PowerSyncのPostgres-to-SQLite同期、LiveStoreのイベントソーシング、そして韓国（トス・クーパンイーツ・カカオ）と日本（メルカリ・クックパッド）のPWA導入事例までを整理します。

1. なぜオフラインファーストが再び重要なのか

2020年代初頭までウェブ開発の前提は「ユーザーは常にオンラインで、サーバーが真実の源であり、クライアントは一時的なビューにすぎない」でした。しかし2024-26年の三つの変化がこの前提を破りました。

第一に、ユーザー期待値がネイティブアプリ水準まで上がったこと。Linearはキーを押した瞬間に課題が作られ、Figmaはインターネットが切れてもデザインが止まらず、Notionは飛行機の中でもノートが編集できます。これらの体験はすべて「楽観的更新（optimistic update）＋バックグラウンド同期」という同じパターンの上に立っています。

第二に、モバイルネットワークの非対称性です。韓国・日本の都市部では5Gが滑らかですが、東南アジア・ラテンアメリカ・インドのモバイル市場ではパケットロスと250ミリ秒以上の遅延が日常です。グローバル製品で「オンライン前提」は次第に非現実的になります。

第三に、CRDTとsync engineの道具化です。2018年にはCRDTを直接実装するのは博士号が必要に見えました。2026年にはY.js・Automerge・Loro・Yrs・Tldraw storeをワンパッケージで導入でき、Replicache・Zero・ElectricSQL・Triplitが「サーバーAPI一つ＋クライアントSDK」だけで完全な双方向同期を提供します。

この三つの変化が合流して「オフラインファースト」はもはや付加機能ではなく新しい既定アーキテクチャになりました。

2. PWAの五本柱: Service Worker · Manifest · Cache · IndexedDB · OPFS

PWA（Progressive Web App）は単一の技術ではなく、五つのブラウザAPIの組み合わせで定義されます。

構成要素標準2026年のサポート状況
Service WorkerW3C/WHATWG全モダンブラウザ（iOS 16.4以上を含む）
Web App ManifestW3C全ブラウザ、iOSは一部フィールド制限
Cache APIService Workers仕様広範サポート
IndexedDBW3C広範サポート、Safari 15で安定化
Origin Private File System（OPFS）WHATWGChrome 102以上、Safari 17以上、Firefox 111以上

Service Workerはブラウザとネットワークの間に位置するプロキシスレッドです。fetchイベントを横取りしてキャッシュから応答を返したり、バックグラウンド同期イベントを受けてキューに溜まったmutationをサーバーへ送ったりします。Web App Manifestは「このサイトはインストール可能なアプリ」と宣言するJSONファイルで、ホーム画面アイコン、起動URL、表示モード（standalone、minimal-ui、fullscreen）、テーマカラーを定義します。

Cache APIはRequest/ResponseペアをキーバリューとするシンプルなKVストア、IndexedDBはトランザクション基盤のNoSQLオブジェクトストアです。最後にOPFSは2023年から安定化された比較的新しいAPIで、各originごとに隔離された仮想ファイルシステムを提供します。ファイルハンドルとランダムアクセスI/Oが使えるので、SQLite WASMやDuckDB WASMがOPFSの上で本物のファイルのように動作します。

3. Service Workerのライフサイクルと落とし穴

Service Workerは単純そうに見えてライフサイクルが直感的ではありません。install → activate → fetch/message/sync/pushイベントの順序、そして新バージョン配布時の「待機ワーカー（waiting worker）」概念を正確に把握する必要があります。

最も多い落とし穴は次の通り。

  1. 古いService Worker問題 — ユーザーがページを更新しても、有効なワーカーはそのまま残り、新ビルドの資産をキャッシュしません。self.skipWaiting()とclients.claim()を明示的に呼ぶ必要があります。
  2. キャッシュキー衝突 — Workboxが自動生成するprecache manifestはビルドごとにハッシュが異なりますが、手書きしたキャッシュ名が同じだと旧キャッシュを置き換えられません。
  3. 認証トークンのキャッシュ漏れ — Authorizationヘッダを含むリクエストを不用意にキャッシュすると、他ユーザーへトークンが漏れる可能性があります。キャッシュ戦略はorigin・ヘッダ別に分けるべきです。
  4. iOSの7日自動削除 — Safariはユーザーが7日間PWAを開かないと、IndexedDB・Cache・OPFSをまとめて消します。「永続ストレージ」ではない点に注意。

4. Workbox 8のキャッシュ戦略カタログ

WorkboxはGoogleが作ったService Workerヘルパーライブラリで、2025年にリリースされた8.x系列が2026年の標準です。Workboxの核心は五つのキャッシュ戦略を宣言的に適用できることです。

  • CacheFirst — キャッシュにあればすぐ返し、なければネットワーク。フォント・アイコン・画像のような不変資産に最適。
  • NetworkFirst — ネットワークを先に試し、失敗時にキャッシュへフォールバック。API応答や変動の多いHTMLに最適。
  • StaleWhileRevalidate — キャッシュを即座に返しつつ、バックグラウンドでネットワーク要求を出してキャッシュを更新。体感速度が最も速い戦略。
  • NetworkOnly — 常にネットワーク、キャッシュ回避。決済・認証など鮮度必須の場合。
  • CacheOnly — キャッシュのみに依存、オフラインモード専用。

これにworkbox-background-syncのキュー、workbox-broadcast-updateのマルチタブ通知、workbox-expirationのTTL、workbox-precachingの事前キャッシュを足せば、一般的なPWAに必要なパターンは30行以内に収まります。

5. IndexedDBの現実: Dexieとidbライブラリ

IndexedDBは強力ですが生APIがコールバック・イベント基盤で使いづらい。2026年現在、二つのライブラリが事実上の標準です。

Dexie.js（David Fahlander） — Dexie.Table・Dexie.Collection・Dexie.liveQueryAPIを通じてSQL風のクエリ、インデックス、トランザクションを約束し、さらにRxJS互換のライブクエリも提供します。9.x系でマルチタブのトランザクション同期が安定化し、RxDBの既定アダプターにも採用されました。

idb（Jake Archibald） — Googleが保守する小さく薄いPromiseラッパー。抽象化は最小限で、IndexedDB APIをそのままPromiseで包んでいます。Workbox内部でも使われています。

選択基準は明確です。ドメインモデルが複雑でライブクエリ・インデックスが要るならDexie、Service Worker内のキュー・メタ保存のような軽量用途ならidbです。

6. OPFSとSQLite WASMの組み合わせ

2023年にSQLiteチームが公式にsqlite3.wasmをリリースしOPFSを一次バックエンドとして対応したことで、ブラウザ内で本物のSQLiteを使う道が開けました。意味するところは次の通り。

  1. フルSQLクエリ — IndexedDBでは難しかったJOIN、GROUP BY、ウィンドウ関数がクライアントで可能に。
  2. マイグレーション — SQLiteのALTER TABLE/PRAGMA user_versionでサーバーと同じマイグレーションパターン。
  3. 可搬性 — ElectricSQL・PowerSync・Cloudflare D1がいずれもSQLiteスキーマを共有する形で発展。

2026年現在、@sqlite.org/sqlite-wasm、wa-sqlite、**@cloudflare/d1**のクライアントビルドがOPFS・IDBバックエンドを選択的にサポート。ElectricSQLはwa-sqliteの上に同期層を、PowerSyncは独自ビルドの上に同期層を載せています。

7. 同期エンジンの分類: 7軸

「Sync engine」と呼ばれる道具群は一塊ではありません。2026年の市場は少なくとも7つの軸に分かれます。

軸選択肢
衝突解決LWW / サーバー権威 / CRDT
データモデルリレーショナルSQL / ドキュメント / トリプル / イベントログ
クライアントストレージIndexedDB / SQLite-OPFS / メモリ＋ファイル
転送チャネルWebSocket / SSE / Long-poll / HTTP push
サーバー結合Postgres直結 / 独自サーバー / サーバーレス
インデックス・クエリ宣言的クエリ / SQL / Datalog / キー検索
ライセンスOSS / デュアル / SaaSのみ

Replicache・Zeroは「サーバー権威＋push/pull＋mutator」モデル、ElectricSQL・PowerSyncは「Postgres ↔ ローカルSQLite」モデル、Y.js・Automerge・Loroは「CRDT＋任意の転送」モデル、LiveStoreは「イベントソーシング＋マテリアライズドビュー」モデル、Triplit・InstantDBは「トリプル/Datalog DB＋ライブクエリ」モデルです。

8. Replicacheのmutatorモデル

Replicache（Rocicorp）は2020年代初頭、同期エンジンというカテゴリを事実上定義した道具です。核心となる概念は三つ。

  1. Mutator — クライアントとサーバーが同じ実装を持つ純粋関数。createTodo(tx, args)のように定義され、クライアントで楽観的に実行された結果をサーバーが再実行して権威ある結果として確定します。
  2. Push — クライアントのmutationキューがサーバーエンドポイント（/api/replicache/push）へ送られます。
  3. Pull — サーバーの変更分がpatch形式で返り、クライアントキャッシュを更新します。

サーバーは「どのmutationまで処理したか」をクライアントID・last mutation IDで管理します。衝突は「サーバーが常に正しい」という単純な規則で解決され、クライアントは自分の楽観的状態がサーバーパッチと異なれば自動でロールバックして再実行します。

このモデルはCRDTより単純で、ドメインロジックを自由に書ける利点があります。限界は、複数ユーザーがリアルタイムで同じ文書を編集する場面にはあまり向かない点で、主に「各ユーザーが自分のデータを編集し、ときどき共有する」シナリオに強いです。Linearが初期にReplicache的パターンに着想を得たと公言した理由でもあります。

9. Zero: Replicacheの後継

Rocicorpは2024-25年、Replicacheの限界を超えるZeroを発表しました。核心となる違いは次の通り。

  • 宣言的クエリ — ReplicacheがKV型だったのに対し、ZeroはSQL風クエリ（z.query.issue.where(...).related(...)）を提供。
  • クライアント側ライブクエリ — クエリは自動でサブスクリプションに変換され、データが変わるとReactコンポーネントが再レンダリング。
  • 権限モデル — サーバー側でrow-level権限を宣言的に定義。
  • サーバー統合 — Postgresを一次バックエンドと想定し、Postgres logical replicationで変更分をpush。

2026年5月時点でZeroはGAに近づき、Replicache利用者へ漸進的なマイグレーション経路を提供しています。Linearは独自sync engineを維持していますが、Replicache → Zeroのパターンは新規開始するチームの既定選択肢となりました。

10. RxDB 15.x: NoSQLオフラインファースト

RxDB（Daniel Meyer）は「リアクティブNoSQL DB＋双方向同期」をワンパッケージで提供します。中心的な特徴は以下。

  • RxJSベースのライブクエリ — コレクション・クエリがObservableなので、React/Svelte/Vueのどれでもリアクティブなrenderが組めます。
  • 多様なストレージアダプター — Dexie/IndexedDB、OPFS、メモリ、SQLite、Premiumに含まれるLokiJS・FoundationDB・SharedWorker。
  • 双方向レプリケーションプラグイン — CouchDB、GraphQL、REST、WebRTC、P2Pなど多様なバックエンドと双方向同期。
  • マルチタブ対応 — 同origin複数タブがBroadcastChannelとWeb Locksで協調し、1タブだけがリーダー役を担当。

RxDBは「Postgres-to-SQLite」ではなく「任意バックエンドとの双方向」を志向します。ElectricSQL・PowerSyncがSQL中心ならRxDBはドキュメントDB中心で、両者は意味ある選択肢として共存します。

11. CRDTの基礎: Last-Write-WinsからRGA・Yjs・Automergeまで

CRDT（Conflict-free Replicated Data Type）は「互いに独立に変更された結果を自動で併合しても、同じ最終状態に収束する」データ構造です。最も単純な形はLWW Register（Last-Write-Wins Register）で、タイムスタンプの大きい書き込みが勝ちます。より複雑な形にはG-Counter、PN-Counter、OR-Set、Yjs/Automergeが使うRGA（Replicated Growable Array）の派生があります。

CRDTをOT（Operational Transformation）と比較すると違いが明確です。OTは「オペレーションAとBが同時に起きたときAをBより後の時点へ変換する」関数を手書きする必要があり、Google Docsがこのモデルで動いています。CRDTは「書き込み自体を可換的・結合的にして変換関数が要らない」アプローチを採ります。CRDTはP2P・オフライン親和的ですがメタデータのオーバーヘッドが大きく、OTはサーバー権威モデルで効率的です。

12. Y.js: Notion・Linear・Tldrawが選んだ理由

Y.js（Kevin Jahns）は2026年現在、最も広く採用されているJavaScript CRDTライブラリです。核となるデータ構造は次の通り。

  • Y.Map — キーバリューマップ、オブジェクト協調に使用
  • Y.Array — 順序付き配列、リスト協調
  • Y.Text — 文字単位の協調テキスト
  • Y.XmlFragment/Y.XmlElement — ProseMirror・TipTapの協調バックエンド

Y.jsの強みは圧縮されたバイナリ更新です。差分が極めて小さく、WebSocket・WebRTC・Hocuspocusなど任意の転送に乗せやすい。さらにAwarenessプロトコル（カーソル・選択・接続者表示）がコアと分離されているので軽量に採用できます。

採用事例を見ると、Notionは協調テキストの一部をY.jsへ移し、Linearはコメント・課題協調の一部にY.jsを使い、Tldraw v2は独自storeを持ちつつもY.jsとの統合アダプターを提供します。GitHubの新コメント協調もY.jsベースだという分析があります。

13. Automerge 2 · Automerge-Repo

Automerge（Martin Kleppmann・Ink & Switch）はY.jsと並び最も有名なCRDTライブラリです。1.x系がJavaScriptで書かれていたのに対し、2.x系はRustコア＋WASMバインディングで書き直されており、性能が大きく改善されました。

中心的な特徴は次の通り。

  • JSON形状のCRDT — JSオブジェクトに近い形をそのまま協調可能な形でモデル化。
  • タイムトラベル — すべての変更分が保持され、任意の時点へ戻せる。
  • Automerge-Repo — ドキュメント保管・同期・ネットワークアダプターを標準化した上位レイヤ。

AutomergeはY.jsよりメタデータが多少大きいですが、「データモデルがJSONと1:1」という直感が強みです。小さな協調ツール（ノート・ToDo・図）で採用率が高いです。

14. Loro: Rustで書かれた次世代CRDT

Loroは2024年に登場した新しいCRDTライブラリで、Rustで書かれWASMバインディングを提供します。強みは以下。

  • メタデータ圧縮 — Y.js・Automerge比で30-50%小さい更新サイズ。
  • 豊富なデータ型 — Text、List、Map、Tree、Counterをすべてサポート。
  • タイムトラベル＋分岐・マージ — Gitに似たブランチモデル。

2026年5月時点でLoroは安定化段階に入り、一部の新規プロジェクトがY.jsの代わりにLoroを採用し始めています。Y.jsの生態系効果に短期で追いつくのは難しいですが、「次世代候補」のポジションは確かです。

15. ElectricSQL: PostgresとローカルSQLiteを繋ぐ

ElectricSQLは2023-24年に登場した同期エンジンで、一文で要約すると**「Postgresに定義されたスキーマをそのままクライアントSQLiteへ複製し、双方向に同期する」**です。

動作は次の通り。

  1. Postgresでelectrify SQL関数により一部テーブルを同期対象としてマーク。
  2. ElectricSQLサーバーがPostgres logical replicationを購読して変更分を受け取る。
  3. クライアント（Web/React Native/Tauri）はwa-sqliteまたはsqlite-wasmを用いてローカル複製を維持。
  4. クライアントは普通のSQLで読み書きし、書き込みはキューに溜まりElectricSQLサーバー経由でPostgresへ反映。

特筆すべきは衝突解決です。既定の方針は「列ごとのLWW＋Postgres制約」ですが、Rich-CRDTモードを有効化するとカウンタ・OR-SetといったCRDTデータ型を直接マップできます。

16. PowerSync: モバイルとSQLite同期

PowerSyncはオーストラリア発のスタートアップで、2024年のシリーズAラウンド以降に急成長しました。ElectricSQLと比較すると次のように差別化されます。

  • モバイル一番手 — React Native、Flutter、Capacitor、Webをすべて対応するが、モバイルSDKが最も成熟。
  • 多様なバックエンド — Postgresだけでなく、MySQL、MongoDBもサポート。
  • 独自衝突解決 — JS関数で定義したmutationをサーバーが再実行するモデルで、Replicacheに近い。
  • 商用マネージド＋セルフホストのデュアルライセンス。

ElectricSQLがOSS・Postgresに集中するのに対し、PowerSyncはモバイルエンタープライズを狙います。両者とも「クライアントSQLite」が核という点は同じです。

17. LiveStore: イベントソーシング型ローカルファースト

LiveStore（Schickling Cap、Shopify・Garden出資）は2024-25年に最も注目される新興sync engineの一つです。アプローチが独特。

  • イベントソーシングが一次 — すべてのmutationがイベントとして記録され、マテリアライズドビューをクライアントが再構成。
  • Reflectスタイルのapi — React Hookでクエリをsubscribeすれば、イベントストリームが変わるたび自動で再計算。
  • ローカル優先＋サーバー同期 — サーバーは単純なイベントログ保管庫、衝突解決はイベント順で決定。
  • GraphQL/RESTに依存しない — 独自SDKが同期チャネルを管理。

同じカテゴリにはTriplit（トリプル基盤DB＋ライブクエリ）とInstantDB（Datalog基盤DB＋Firebase風SDK）があります。三者とも「BaaSのような開発者体験をローカルファーストで提供する」という共通目標を持っています。

18. WatermelonDB · PouchDB · TanStack DB · Convex

古い道具も新しい道具も市場には共存しています。

  • WatermelonDB — React Native中心のローカルDBで、バックエンド同期プロトコルは自前実装。メルカリ等一部のRNアプリで採用。
  • PouchDB + CouchDB — 2010年代後半に人気だった古典的組み合わせ。安定性は実証済みだが、CRDTではなくLWW＋リビジョンツリー基盤。
  • Firestore offline / Firebase Realtime DB — 最も広く使われるBaaS選択肢。オフラインキュー・楽観的書き込みをサポート。
  • Convex — 2022年に登場したreactiveバックエンド。クライアントがクエリをsubscribeすればバックエンドが自動でinvalidate。真の意味のローカルファーストではないが、「リアルタイム＋楽観的」体験を簡単に提供。
  • TanStack DB — TanStack Queryを作ったTanner Linsleyの次世代クライアントDB。2025年アルファ、2026年ベータ段階。

選択の核は「チームがすでに使っているスタック」です。Firebase利用中ならFirestore offline、React Native＋独自サーバーならWatermelonDB・PowerSync、GraphQLバックエンドならConvexが自然です。

19. リアルタイム転送チャネル: WebSocket · SSE · HTTP push

同期エンジンが変更分をどう届けるかは、クライアントの性能と安定性に直結します。2026年の標準選択肢は三つ。

  • WebSocket — 双方向、低遅延。Y.jsのy-websocket、Replicacheの一部アダプター、ElectricSQLの転送で使われる。欠点はプロキシ・CDN互換性。
  • SSE（Server-Sent Events） — サーバーからクライアントへの一方向、HTTP/2互換。Zero・Convexなどで部分採用。欠点は片方向のためクライアントからのpushは別途HTTPリクエストが必要。
  • Long-poll / HTTP push — Replicacheの既定。最も保守的でCDN・プロキシ互換性は最高だが遅延が大きい。

WebTransport（HTTP/3基盤）とWebRTC DataChannelも一部P2Pシナリオで使われますが、2026年でも主流はWebSocketとSSEです。

20. スキーマ移行の難題

オフラインファーストシステムで最も難しい問題はスキーマ変更時にオフラインクライアントへどう対応するかです。ユーザーが一ヶ月アプリを開かないでいて、その間にサーバースキーマが二回変わっていたら、クライアントの未反映mutationはどう処理するべきでしょうか。

現場で使われるパターンは次の通り。

  1. バージョンゲート — クライアントビルドのバージョンが低すぎる場合、「アップデートが必要」画面を出して同期を遮断。
  2. 双方向互換スキーマ — 新カラムの追加のみ行い、削除はNバージョン後へ延期。
  3. mutationの変換 — サーバー側で古い形式のmutationを新形式に自動変換（データベース移行の同期エンジン版）。
  4. イベントソーシングの優位 — LiveStoreのようにイベントが一次なら、イベントスキーマだけ互換であればビューは自由に再計算可能。

この問題には正解がなく、各チームがドメイン特性に合わせて妥協する必要があります。

21. LinearのSync Engineアーキテクチャ

Linearは2024年のカンファレンス発表とブログシリーズで独自sync engineの構造を公開しました。中心的な要素は次の通り。

  • すべてのデータをクライアントキャッシュにミラー — ログイン後最初の30秒で全データセットを受け取りIndexedDBへ保存。
  • オブジェクトグラフ同期 — Issue・Project・Cycleなどオブジェクト単位の差分を双方向で送る。
  • delta-based — 全オブジェクトではなく変更されたフィールドだけpush。
  • 権限フィルタ — サーバーが各ユーザーが見られるオブジェクトだけを送る。
  • WebSocket + HTTP push — リアルタイム変更はWebSocket、初期同期はHTTP。

Linearの核は「キー入力即UIに反映、0msの体感」で、これが可能なのは「データがすでにクライアントにあり、すべてのmutationが楽観的に実行される」ためです。同じパターンがNotion・Figma・Tldrawでも変形して見られます。

22. Figmaのマルチプレイヤーモデル

Figmaは2016年から独自のCRDT風マルチプレイヤーモデルを運用してきました。2020年の有名なエンジニアリングブログ「How Figma's multiplayer technology works」で公開された要点は次の通り。

  • 部分的なLWW＋オブジェクトツリー — 図形はツリー構造、各属性はLWWで併合。
  • サーバー権威＋クライアントキャッシュ — サーバーが権威ある順序を決定するが、クライアントは楽観的に進行。
  • カメラ・カーソルはephemeral — 同期対象だが永続保存しない。
  • 独自バイナリプロトコル — JSONではなく効率的なシリアライズ。

Figmaは一般的なCRDTではなくドメイン特化モデルを選ぶことで、メモリ・帯域で大きな利点を得ました。ただしこのアプローチはドメインが十分に狭く安定している場合にのみ可能です。

23. 韓国のPWA導入事例: トス · クーパンイーツ · カカオ

韓国市場のPWA導入はモバイルウェブのシェアが高いという特殊性の上に立っています。

  • トス（Toss） — 一部の決済・送金ページにPWAパターンを適用し、モバイルアプリ未インストールのユーザーにも安定した体験を提供。Service Workerベースのキャッシュでパフォーマンス指標を積極的に最適化。
  • クーパンイーツ — モバイルウェブでもアプリとほぼ同等の体験を追求し、Workboxベースのキャッシュ戦略を採用。マーケットプレイスのシナリオでオフラインキューの活用が徐々に拡大。
  • カカオ — カカオワークの一部ページにPWAマニフェストとService Workerを適用。B2B SaaSで「インストール可能なウェブアプリ」の需要を吸収。

韓国ユーザーの多くがAndroidという点もPWAに好意的です。iOSの7日削除制約の影響が相対的に薄いです。

24. 日本のPWA: メルカリ · クックパッド

日本市場はモバイルウェブとネイティブアプリのバランスが韓国と似ています。

  • メルカリ（Mercari） — モバイルウェブの軽量版にPWAを適用して、一部新興市場のユーザーを吸収。CRDT/sync engineではないが、Workboxベースのキャッシュは積極的に活用。
  • クックパッド（Cookpad） — レシピページのモバイルウェブキャッシュにService Workerを活用。オフラインでもお気に入りレシピを閲覧可能。
  • 楽天 — 一部の商品ページにPWAマニフェストを追加。

日本の特徴は「ネイティブアプリ優先の文化が強いが、モバイルウェブのトラフィックも無視できない比重」という点。PWAは「アプリ未インストールユーザーへのバックアップ」として位置づけられています。

25. ユースケースカタログ: ノート · タスク · ドロー · コードエディタ

オフラインファーストパターンが輝くドメインは明確です。

  • ノートアプリ — Reflect、Obsidian Sync、Logseq、Mem。Reflectは独自sync engine、Obsidian SyncはE2EE中心、Logseqはgraph-DB。
  • タスクアプリ — Linear、Things、TickTick。Linearがsync engineの教科書事例。
  • ドロー/ホワイトボード — Tldraw、Excalidraw、Figma、Miro。Tldraw v2は独自store＋Y.jsアダプター。
  • コードエディタ — Replit Multiplayer、Stackblitz、CodeSandbox。Replitは独自CRDT、残りはY.jsまたはOT。
  • 文書協調 — Notion、Coda、Quip。NotionはOT/CRDTのハイブリッド。

一般的なパターンは「構造化データ（テーブル・課題）にはserver-authoritative＋mutator、非構造テキスト・図にはCRDT」です。

26. 2026年の意思決定ガイド: どのsync engineを選ぶか

ここまでの25セクションを意思決定木に圧縮すると次のようになります。

  1. PWA基本キャッシュだけ必要か？ → Workbox 8 + IndexedDB（Dexie）で十分。
  2. 各ユーザーが自分のデータを編集するシナリオか？ → ReplicacheまたはZero。
  3. Postgresが既に真実の源か？ → ElectricSQL（OSS優先）またはPowerSync（モバイル優先）。
  4. 複数ユーザーが一文書を同時編集するか？ → Y.js（最も実証済み）、Automerge（JSON親和）、Loro（次世代）。
  5. 開発者体験中心、BaaS風のSDKが必要か？ → Convex（reactive）、またはTriplit / InstantDB / LiveStore（ローカル優先）。
  6. React Nativeモバイル＋自前バックエンドか？ → WatermelonDBまたはPowerSync。

最後に、どの道具を選んでもマイグレーション・権限・E2EE・可観測性は別途設計が必要です。sync engineは同期問題を解きますが、データガバナンス全体を解くわけではありません。

27. 参考資料

Discuss on Twitter • View on GitHub