2026年のCRDT・ローカルファーストエンジン徹底比較 — Yjs / Automerge 3 / Loro / Replicache / Liveblocks / Zero

プロローグ — Ink and Switchの7つの理想、7年後

2019年4月、Ink and Switch研究所が「Local-first software: You own your data, in spite of the cloud」というエッセイを発表した。マーティン・クレップマン、ピーター・ヴァン・ハーデンバーグ、マーク・マクグラナハンの共著である。彼らはクラウドSaaSが生み出した「自分のデータなのに自分で扱えない」という矛盾を指摘し、7つの理想を掲げた。

1. No spinners — 高速な動作（UIはローカルで即座に応答する）
2. Your work is not trapped — 複数デバイスからアクセスできる
3. The network is optional — オフラインでも動く
4. Seamless collaboration — コラボレーションが可能
5. The Long Now — 長期保存ができる
6. Security and privacy by default — エンドツーエンド暗号化
7. You retain ultimate ownership — データの所有権を握る

2019年には野心的なビジョンだった。2026年現在、7つのうち4〜5つを同時に満たす実プロダクションのスタックが存在する。CRDT（Conflict-free Replicated Data Type）エンジンが成熟し、モバイル・ウェブの両側でオフラインファーストのパターンが標準となった。

本稿はその陣営の主要8エンジンを正確に比較する。

• Yjs — コラボエディタ（TipTap, BlockNote, Lexical, ProseMirror）の事実上の標準
• Automerge 3 — カラムナストレージで約10倍の圧縮
• Loro 1.0 — Rust製の新顔。ムーバブルツリー、リッチテキスト、高性能
• Replicache → Reflect → Zero — Rocicorp（Aaron Boodman）による進化
• Liveblocks — マネージド版Yjs。2024年シリーズA
• ElectricSQL — PostgresとSQLiteの双方向同期
• PowerSync — 同じアイデア、オフラインファーストを強調
• Tinybase — オプションでCRDT付きの小さなインメモリDB

それぞれが何ができて何ができないか、どんなトレードオフがあるか、そして韓国と日本市場で何が起きているかを整理する。

1. なぜ2026年に再びローカルファーストなのか

2019年のエッセイから6〜7年経った。再燃を支える要因は3つある。

1. WASMとTypeScriptの成熟。 Loro、Automerge、Yjsはすべて、WASMまたは純粋なJSビルドを提供する。5年前にはブラウザでCRDTを動かすこと自体が実験だった。今は1MBのWASM塊に収まる。

2. SQLiteの復権。 Cloudflare D1、Turso、libSQL、SQLite-on-WASM（@sqlite.org/sqlite-wasm）が同時に台頭した。すべてのクライアントがローカルSQLiteを持つという前提が、再び現実的な基準線になった。

3. AIコパイロットの登場。 Cursor、Linear、Notion AIのようなツールが「オフラインでも動く、速い、コラボもできる」をSaaSの当たり前にした。サーバまで200msのRTTはもう許容されない。

4. モバイルファースト市場の存在。 インドネシア、インド、ベトナムなど、ネットワークが不安定な市場ではオフライン動作が交渉不可能な要件となった。PowerSyncはここから育った。

7つの理想のうち、2026年時点でも本当に難しいのは2つだ。

• The Long Now（長期保存） — CRDTのメタデータは無際限に増える。トゥームストーンのガベージコレクションは未解決のまま。
• エンドツーエンド暗号化 — CRDTのマージロジックとE2EEを両立させるのは難しい。Automerge陣営が挑戦中。

2. CRDTの基礎 — ステートベース vs オペレーションベース

CRDTは2つの系統に分かれる。

ステートベースCRDT（CvRDT — Convergent）

全体の状態をまるごとマージする。マージ関数は可換、結合的、冪等でなければならない。つまり、どんな順番で何回マージしても同じ結果になる。

代表的なデータ構造:

• G-Counter（grow-only counter）
• PN-Counter（positive-negative counter）
• LWW-Register（last-write-wins）
• OR-Set（observed-remove set）

長所: 単純。メッセージが一度でも届けば収束する。 短所: ペイロードが大きい。全体の状態を送る必要がある。

オペレーションベースCRDT（CmRDT — Commutative）

各変更をオペレーションとして送る。オペレーション自体が可換でなければならない。メッセージはexactly-onceで配信する必要がある。

代表的なデータ構造:

• RGA（Replicated Growable Array） — コラボテキストの土台
• Treedoc
• LSEQ
• Logoot

長所: ペイロードが小さい。デルタだけが流れる。 短所: インフラがより難しい。損失と重複に対処しなければならない。

実エンジンの系統図

要点は一行。CRDTは「どのデータモデル」かによって系統が分かれる。リッチテキストのコラボエディタが欲しいならYjs、Automerge、Loroが候補。JSONツリー同期ならAutomergeかLoro。単純なLWWで十分ならReplicacheやTinybaseで軽くまとめる。

3. Yjs — 事実上の標準となったコラボエディタのエンジン

Yjsは2017年にKevin Jahnsの博士論文として始まったプロジェクトだ。2026年現在、コラボエディタの世界で事実上の標準となっている。

なぜYjsが標準になったか

1. YATAアルゴリズム — Yet Another Transformation Approach。RGAの派生でメモリ・性能の両面で優秀。
2. 共有データ型のプール — Y.Doc、Y.Text、Y.Array、Y.Map、Y.XmlFragment。コラボエディタが必要とする共有型がすべて揃っている。
3. エディタアダプタのプール — y-prosemirror、y-tiptap、y-codemirror.next、y-quill、y-lexical、y-blocknote。新しいエディタが登場すると、すぐにアダプタが追随する。
4. トランスポートに依存しない — WebSocket、WebRTC、libp2p、IndexedDB。同期チャネルは利用者が選ぶ。

TipTap + Yjsの一片

最もよく使われるパターン。TipTapエディタの2インスタンスがリアルタイムで同期する。

import { Editor } from '@tiptap/core'
import StarterKit from '@tiptap/starter-kit'
import Collaboration from '@tiptap/extension-collaboration'
import CollaborationCursor from '@tiptap/extension-collaboration-cursor'
import * as Y from 'yjs'
import { WebsocketProvider } from 'y-websocket'

const ydoc = new Y.Doc()
const provider = new WebsocketProvider('wss://demos.yjs.dev', 'my-room', ydoc)

const editor = new Editor({
  extensions: [
    StarterKit.configure({ history: false }), // Yjsが自前のundoを提供
    Collaboration.configure({ document: ydoc }),
    CollaborationCursor.configure({
      provider,
      user: { name: 'Alice', color: '#f783ac' },
    }),
  ],
  element: document.querySelector('#editor')!,
})

この30行でコラボエディタが動く。ブラウザを2つ開いて同じルームに入ると、即座に同期する。

Yjsの限界

• ツリーの移動（move）サポートが弱い — Y.Mapの入れ子では本当のmovable treeを表現しづらい。Notionのようなブロックエディタでブロックを別の親の下に移動させると、同時編集の衝突が綺麗に解けない。
• メタデータの累積 — 古いドキュメントほどメタデータが大きくなる。Y.encodeStateAsUpdateで圧縮できるが、コストが高い。
• 数値型が弱い — カウンタやセットのような型は一級市民ではない。自分で実装することになる。

この2つの限界がまさに、Loroが登場した理由である。

4. Automerge 3 — カラムナストレージで10倍圧縮

Automergeはマーティン・クレップマン本人が主導するプロジェクトだ。Yjsと同時期に始まったが、Automergeは「JSONツリー全体をマージできる汎用CRDT」を目指した。汎用的とはつまり重いということでもある。

2025年のAutomerge 3による激変

Automerge 2まではメモリ使用量とドキュメントサイズが大きな弱点だった。2025年秋にリリースされたAutomerge 3でこれが一気に反転した。

• カラムナストレージ — Apache Parquetからの着想。同じ種類のopsが列ごとに集まると圧縮率が爆発的に上がる。
• ドキュメントが平均10倍小さく — 同じ編集履歴に対してAutomerge 2と比べて約10倍縮む。
• 高速なマージ・ロード — メモリ使用量が50〜70%削減。

Automerge 3のスケルトン

import * as A from '@automerge/automerge'

// ドキュメント作成
let doc1 = A.from({ tasks: [] as Array<{ title: string; done: boolean }> })

// 変更 — トランザクションの中で素のJSのように書ける
doc1 = A.change(doc1, (d) => {
  d.tasks.push({ title: '論文を読む', done: false })
  d.tasks.push({ title: 'CRDT記事を書く', done: false })
})

// 別の場所のレプリカ
let doc2 = A.clone(doc1)
doc2 = A.change(doc2, (d) => {
  d.tasks[0].done = true
})

doc1 = A.change(doc1, (d) => {
  d.tasks.push({ title: 'コードレビュー', done: false })
})

// マージ — どちら側からでも可能
const merged = A.merge(doc1, doc2)
console.log(merged.tasks) // 3つのタスク、最初のものはdone: true

Automerge Repo

Automerge 3時代でより重要な変化は@automerge/automerge-repoだ。単なるライブラリではなく、ドキュメントストアと同期プロトコルをセットで提供する。

• IndexedDBアダプタ — ブラウザの永続ストレージ
• BroadcastChannelアダプタ — 同一ブラウザ内のタブ間同期
• WebSocketアダプタ — サーバ同期
• 将来的にlibp2p、WebRTCアダプタ

Yjs対Automerge — 率直な比較

コラボエディタを書くならYjs。一般的なJSONドキュメント同期ならAutomerge。

5. Loro 1.0 — Rust製の新標準候補

Loroは2023年末に登場したRust製のCRDTライブラリだ。2025年に1.0が正式リリースされ、この陣営の新たな標準候補として浮上した。Zixuan Chen率いるチームが開発する。

なぜLoroが注目されるか

1. Movable Treeが一級市民 — ツリーノードを別の親の下に移す操作を、並行性安全に処理する。Notion・Linearのようなブロックエディタの最も難しい問題。
2. Fugueテキストアルゴリズム — RGAの派生で、split-lineのような難しいパターンでユーザの意図をより良く保存する。
3. Rust → WASM — 中核はRustで、WASM・NAPI・UniFFIを通してすべての言語に行き渡る。JS、Swift、Kotlin、Python、Rust。
4. リッチテキストを一級市民として — Y.Textのような型がY.XmlFragmentで迂回するのに対し、Loroは最初からリッチテキストを狙った。
5. タイムトラベル — ドキュメントの任意時点に巻き戻し・再生できる。

Loroのスケルトン

import { LoroDoc, LoroList, LoroMap, LoroText } from 'loro-crdt'

const doc = new LoroDoc()
doc.setPeerId(BigInt('0x1234567890abcdef'))

const tasks: LoroList = doc.getList('tasks')
const task1: LoroMap = tasks.insertContainer(0, new LoroMap())
task1.set('title', '論文を読む')
task1.set('done', false)

const note: LoroText = task1.setContainer('note', new LoroText())
note.insert(0, '読書中...')

// シリアライズ・デシリアライズ
const snapshot = doc.exportSnapshot()
const docCopy = new LoroDoc()
docCopy.import(snapshot)

Loroのムーバブルツリー

const tree = doc.getTree('blocks')
const root = tree.createNode()
const block1 = tree.createNode(root.id)
const block2 = tree.createNode(root.id)

// block2をblock1の子に移動 — 並行性安全
tree.move(block2.id, block1.id)

Yjsの上で同じことを実装すると、衝突発生時にサイクルや迷子ノードが発生する。Loroはアルゴリズムレベルでこれを保証する。

Loroの限界

• エディタアダプタが少ない — 2026年5月時点でProseMirror、TipTap、CodeMirrorのアダプタはベータ段階。Yjsほど成熟していない。
• 公式サーバコンポーネントの不在 — y-websocketのような標準サーバがない。自前で書く必要がある。
• コミュニティの規模 — Yjsほど大きなエコシステムではない。エッジケースに当たるとGitHubのissueを自分で開くことになる。

それでも、2026年に新しいコラボツールを始めるなら、まずLoroを検討するのが合理的だ。アルゴリズムがより正しく、データモデルがより豊かで、未来志向だ。

6. Replicache → Reflect → Zero — Rocicorpの進化

Aaron BoodmanはGmail OfflineとGoogle Gearsを作った人物だ。彼がRocicorpを起こして作ったライブラリ群は、コラボエディタではなく「B2B SaaSのsync engine」を狙った。つまりLinear、Notion、Figmaのバックエンドである。

進化の順番。

1. Replicache（2020〜） — クライアントがSQLiteライクなローカルDBを持ち、サーバにmutationを送り、pullでサーバ状態を受け取る。CRDTではない。LWWと明示的な衝突解決。
2. Reflect（2022〜） — Replicacheの上にCloudflare WorkersとDurable Objectsを使ってリアルタイムマルチプレイを乗せた。
3. Zero（2024年末〜） — まったく新しいアーキテクチャ。ZQLというクライアント側クエリ言語、Postgresを一級市民として、IVM（Incremental View Maintenance）。

Replicacheのアイデア

import { Replicache } from 'replicache'

const rep = new Replicache({
  name: 'user-123',
  licenseKey: 'YOUR_LICENSE_KEY',
  pushURL: '/api/replicache/push',
  pullURL: '/api/replicache/pull',
  mutators: {
    async createTask(tx, args: { id: string; title: string }) {
      await tx.set(`task/${args.id}`, { title: args.title, done: false })
    },
    async toggleTask(tx, id: string) {
      const task = await tx.get(`task/${id}`)
      if (task) await tx.set(`task/${id}`, { ...task, done: !task.done })
    },
  },
})

// 使い方
await rep.mutate.createTask({ id: 'a1', title: 'Replicacheの記事を書く' })

mutatorsはクライアントとサーバの両方で動く。サーバが正解の状態を知ったら、クライアントの楽観的mutationをリベースする。

Zeroの新しさ

Zeroは2024年末からベータで公開され、2026年5月時点で1.0直前だ。

• ZQL — クライアントで使うクエリ言語。SQLに似ているが、リアクティブ。useQueryで結果をサブスクライブする。
• Postgresを直接見る — サーバは素のPostgres。Zeroはその上にIVM層を載せる。
• 再エントリなしのリアルタイム — サーバでデータが変わると、クライアントのすべてのZQL結果が自動更新される。

import { Zero } from '@rocicorp/zero'

const z = new Zero({
  userID: 'user-123',
  server: 'wss://my.zero.dev',
  schema,
})

// リアクティブクエリ
const tasks = z.query.task
  .where('userId', '=', 'user-123')
  .where('done', '=', false)
  .orderBy('createdAt', 'desc')

const view = tasks.materialize()
view.addListener((data) => {
  console.log('更新されたタスクリスト:', data)
})

Replicache陣営のトレードオフ

• CRDTではない — 衝突は明示的に解決する。同時テキスト編集のようなものは自分で解く必要がある。
• サーバが真実の源 — オフライン動作は可能だが、最終的にサーバが決める。
• データモデルが行ベース — JSONツリーやリッチテキストのようなドメイン型はユーザが定義する。

Linearがこのパターンの最も有名なユーザだ。大規模B2B SaaSでサーバ側の権限・整合性を諦めたくないが、高速なUIは欲しい、という場面で候補となる。

7. Liveblocks対Partykit対y-redis — マネージドコラボバックエンド

CRDTライブラリは絵の半分だ。残り半分はドキュメントをどこに保存し、誰がピア間の同期メッセージをルーティングするかである。

Liveblocks

フランスのスタートアップ。2024年にBoldstart主導でシリーズA。マネージドコラボバックエンドの1番手。

• そのままのYjs — ユーザが書いたYjsコードがLiveblocksの上でそのまま動く。
• 固有の共有型 — LiveObject、LiveList、LiveMap — Yjs抜きで単純なコラボが必要な時に使う型。
• コメント・通知 — Notion風コメント機能がSDKに組み込まれている。
• @liveblocks/react — Reactフックのプール。
• Threads、Inbox — 事前構築済みのコメントUIコンポーネント。

価格はMAUベース。1万MAUまで無料、それ以上は有料。

Partykit

Sunil Pai（元Cloudflare・Reactコアメンバー）が始めた。2024年にCloudflareが買収。

• Cloudflare Durable Objectsの上に構築 — ルーム単位の永続状態とグローバルルーティング。
• Yjs統合 — y-partykitアダプタ。
• 任意のコードが書ける — LiveblocksがクローズドなAPIなら、Partykitはユーザがサーバロジックを書く。
• 安い — Cloudflareの料金モデルそのまま。CRDTのマネージド陣営で最も安い。

y-redis / y-mongodb-provider

セルフホスト陣営。YjsドキュメントをRedisやMongoDBに永続化する。

• 最も安く、最も時間がかかる。
• クラウド利用が少ない、あるいはセキュリティ・法規制でマネージドが使えない時。

意思決定マトリクス

8. ElectricSQL対PowerSync — PostgresとSQLiteの双方向同期

少し違う陣営。テキストやJSONツリーのCRDTではなく「リレーショナルDB自体をクライアントに複製する」アプローチ。

ElectricSQL

ベルギー・EUベースのチーム。Postgresの上にlogical replicationを乗せて、クライアントのSQLiteにデータを流す。クライアント側の変更は上流に送られてマージされる。

• サーバ: Postgres + Electricサービス — ElectricはElixirで書かれた同期ゲートウェイ。
• クライアント: SQLite — @electric-sql/clientライブラリ。
• Shape — 同期の単位。SQL where節で部分データのみを取得する。
• 2024年のピボット — ローカルファーストのフルスタックフレームワークから「Postgres → SQLite同期エンジン」に簡素化された。

import { ShapeStream } from '@electric-sql/client'

const stream = new ShapeStream({
  url: 'https://api.example.com/v1/shape',
  params: {
    table: 'tasks',
    where: 'user_id = $1',
    params: ['user-123'],
  },
})

stream.subscribe((messages) => {
  for (const m of messages) {
    console.log(m.headers.operation, m.value)
  }
})

PowerSync

オーストラリアベースのチーム。モバイル優先。ElectricSQLと似たアイデアだが強調点が違う。

• クライアント優先 — React Native、Flutter、iOS、AndroidのSDKが一級。
• バックエンドDBの自由度 — Postgresだけでなく、MongoDBやMySQLもサポート進行中。
• PowerSync rules — SQLライクなルールで、どの行がどのユーザに同期されるかを定義する。

どちらの陣営をいつ使うか

この陣営の限界: 同時テキスト編集やツリー移動のようなCRDT固有の問題は解決しない。それはYjsとLoroの領域。

9. Tinybase — 小さなインメモリDB + オプショナルCRDT

TinybaseはJames Pollack単独で作っているライブラリだ。「10KBのインメモリデータベース + オプションでCRDT」がコンセプト。2023〜2025年の間に急成長した。

なぜTinybaseが興味深いか

• シンプル — setRow、getRow、delRow。Reduxストアのような抽象化に、リアクティブクエリを乗せた。
• 小さい — minifiedで50KB未満。
• CRDTはオプション — デフォルトはLWW。必要ならYjsアダプタを付ける。
• インデクサ・メトリクス・チェックポイント — 基本機能が豊富。
• 2025年のMergeableStore — Tinybase自体に軽量CRDTマージが入った。Yjsを噛まさずに単純LWWで同期可能。

Tinybaseのスケルトン

import { createStore, createMergeableStore } from 'tinybase'

const store = createMergeableStore('store-1')

store.setTable('tasks', {
  t1: { title: '論文を読む', done: false },
  t2: { title: 'CRDT記事を書く', done: false },
})

store.setCell('tasks', 't1', 'done', true)

// 別のクライアントとマージ
const otherStore = createMergeableStore('store-2')
otherStore.setTable('tasks', {
  t3: { title: 'コードレビュー', done: false },
})

const merged = store.merge(otherStore)
console.log(merged.getTable('tasks')) // t1, t2, t3 すべて見える

TinybaseはYjs・Loroのような汎用CRDTエンジンの代替ではない。より小さく、より単純な、別の陣営だ。

10. どのエンジンを選ぶか — 意思決定フレームワーク

以下の決定木は2026年5月時点で私が推奨する優先順位だ。

コラボテキストエディタ（Notion・Linear・Slab系）

1. Yjs + TipTap / BlockNote / Lexical — 最速で開始。アダプタが豊富。
2. Loro + ProseMirror — 2026年の新規プロジェクトなら評価する価値あり。アルゴリズムがより正しい。
3. Automerge 3 — JSONドキュメント同期が核心なら。

ホスティング: Liveblocks（高速起動）→ Partykit（安価）→ y-redisセルフホスト（最も自由）。

モバイルオフラインファーストアプリ（医療・物流・現場）

1. PowerSync — Flutter / RNのSDKが一番手。
2. ElectricSQL — Postgres陣営なら候補。
3. WatermelonDB — NozbeチームのRN優先な代替。意外と安定。

ホスティング: Supabase + ElectricSQL、または自前Postgres + PowerSync。

B2B SaaSのインスタントUI（Linear系）

1. Zero — 2026年の新規プロジェクトの最も興味深い選択。ZQLが気に入れば。
2. Replicache — 1.x安定。大企業の採用実績あり。
3. Liveblocks + RDBMS — UIコラボだけが必要なら。

シンプルなマルチプレイサイドプロジェクト

1. Liveblocks — 30分で立ち上がる。
2. Partykit — Cloudflare Workers陣営なら。
3. Tinybase MergeableStore — 軽量陣営。

データモデル別ガイド

11. 韓国と日本市場のローカルファースト

韓国・日本のSaaS市場は2025〜2026年にかけてローカルファーストのパターンを積極的に採用し始めた。

韓国

• Notionクローン群 — Slidなどのノートツールが、Yjsをベースに作られている。SlidはLiveblocks候補だったがセルフホストに進んだという話。
• Kakao Workのコラボドキュメント — 2025年にベータ公開された機能はYjsベース。ProseMirror + y-prosemirror。
• Naverメモ — 2026年春のリニューアルでマルチデバイス同期を強化。Replicache系のアーキテクチャと推測される。
• Tossペイメントの加盟店ツール — オフライン対応の売上入力ツールがPowerSync候補。採用は非公開。

日本

• LINE Notes — 2026年初頭にマルチデバイスのコラボメモを公開。Yjs陣営のアダプタを内製したとの噂。
• Sansan / Eight — 名刺同期にSQLite-on-the-edge + 自社製CRDTを使うとJJUG 2025で発表。
• Mercari Mini — 2025年の海外展開試み。日本のオフラインモバイル決済環境でPowerSync採用を検討中。
• はてな / サイボウズ — 社内コラボツールでYjs陣営を部分採用。

両市場の共通点

• セキュリティ・法規制のため、マネージドSaaS（Liveblocks・Partykit）よりセルフホストを好む。
• キャリアモバイル網が良好で、ElectricSQL / PowerSyncの切迫感は東南アジアほど大きくない。
• コラボエディタ陣営はYjsが圧倒的。Loroは2026年に入ってようやく真剣に検討されるようになった。

12. 参考 / References

• Ink and Switch, "Local-first software: You own your data, in spite of the cloud" (2019) — https://www.inkandswitch.com/local-first/
• Martin Kleppmann, Adam Wiggins, Peter van Hardenberg, Mark McGranaghan, original local-first essay
• Yjs documentation — https://docs.yjs.dev/
• Kevin Jahns, "Near Real-Time Optimistic Replication" (YATA paper)
• Automerge 3 announcement — https://automerge.org/
• Loro documentation — https://loro.dev/
• Loro 1.0 release notes (2025)
• Fugue: A Generic Text Replication Algorithm — https://arxiv.org/abs/2305.00583
• Replicache documentation — https://doc.replicache.dev/
• Zero by Rocicorp — https://zero.rocicorp.dev/
• Liveblocks documentation — https://liveblocks.io/docs
• Partykit documentation — https://docs.partykit.io/
• ElectricSQL documentation — https://electric-sql.com/docs
• PowerSync documentation — https://docs.powersync.com/
• Tinybase documentation — https://tinybase.org/
• TipTap collaboration docs — https://tiptap.dev/docs/collaboration
• BlockNote documentation — https://www.blocknotejs.org/
• WatermelonDB — https://watermelondb.dev/
• "A move operation for replicated trees" — Kleppmann, Mulligan, Gomes, Beresford
• "CRDTs: The Hard Parts" — Martin Kleppmann talk
• JJUG CCC 2025 — Sansan / EightのCRDT登壇（日本語）

次回はこのうち2〜3エンジンを選び、同じコラボツールを実際に構築してみるhands-onを扱う。アルゴリズムではなく、実コードの隅で何が起きるかを。