필사 모드: リアルタイム協業エンジン & 同期 2026 完全ガイド - Liveblocks · PartyKit · Yjs · Automerge · ElectricSQL · Replicache · Zero (Rocicorp) · Convex · Triplit · Jazz.tools · Loro 徹底分析

> "10年以内に、すべてのソフトウェアはマルチプレイヤーになる。シングルユーザーアプリは化石になる。" — Martin Kleppmann, "Local-first software" (Ink & Switch, 2019)

Figma で同僚のカーソルが流れ、Notion ページの文字が同時に増え、Linear のイシューがリロードなしにリアルタイム更新される体験は、2020 年時点では「プレミアム SaaS の差別化要素」でした。2026 年現在、このマルチプレイヤー UX は **すべての新規 B2B SaaS の標準要件** となり、「Figma 並みの協業ができないと売れない」という命題は、もはや冗談ではなくなりました。

この変化の背後には、30 年前から研究されてきた **CRDT (Conflict-free Replicated Data Type)** という分散システム理論がついにプロダクションで動き始めた事実と、それを SaaS に包んで提供する Liveblocks · PartyKit · Convex といった新興プラットフォームの台頭があります。同時に、Replicache 創業者 Aaron Boodman が 2024 年後半にリリースした **Zero** は「Postgres をそのまま残し、クライアントが IndexedDB で同期する」という新パラダイムを提示し、ElectricSQL · PowerSync · Triplit · Jazz.tools などのローカルファースト陣営も爆発的に成長しました。

この記事では、2026 年 5 月時点でのリアルタイム協業と同期エコシステム全体を一本にまとめます。Yjs · Automerge · Loro などの CRDT コアライブラリから、Liveblocks · PartyKit · Ably などのホスト型 SaaS、Replicache · Zero · ElectricSQL · Convex などのローカルファースト同期エンジン、tldraw · Excalidraw · Notion などの実適用事例、Toss · Naver Whale · サイボウズ · Sansan などの韓国・日本事例まで網羅します。

1. 2026 年リアルタイム協業マップ — 5 つのカテゴリ

リアルタイム協業スタックを理解する最良の方法は、5 つのレイヤーに分解することです。

| レイヤー | 役割 | 代表的な製品 |

|---|---|---|

| Transport | ブラウザ↔サーバ双方向通信 | WebSocket, WebTransport, WebRTC DataChannel, SSE |

| CRDT / OT コア | 衝突しない自料構造 | Yjs, Automerge, Loro, Diamond Types, ShareDB |

| 同期エンジン | クライアント-サーバ状態同期 | Replicache, Zero, ElectricSQL, PowerSync, Convex, Triplit, Jazz.tools |

| ホスト型リアルタイム SaaS | マルチプレイヤーインフラホスティング | Liveblocks, PartyKit, Ably, Pusher, Supabase Realtime |

| アプリケーションパターン | カーソル、コメント、通知などの UX | Figma, Notion, Linear, tldraw などの実装事例 |

各レイヤーは独立して選択でき、1 つの製品が複数レイヤーをまとめて提供することもあります。Liveblocks は Transport + CRDT (Yjs 上に構築) + ホスト型 SaaS + アプリケーションパターンをすべて束ねて販売します。Yjs は CRDT コアのみ、PartyKit は Transport + ホスト型 SaaS のみ、ElectricSQL は同期エンジンのみを提供します。

選択の最初の分岐は **「自分で運用する意思があるか、あるならどこまでか」** です。すべて SaaS に任せるなら Liveblocks、一部自前運用なら Yjs + 自社サーバ、データ主権が重要なら Yjs + y-websocket フルスタック、完全ローカルファーストなら Automerge + Automerge-repo。

2. CRDT の基礎 — Yjs, Automerge, Loro, Diamond Types

CRDT (Conflict-free Replicated Data Type) は 1980 年代から分散システム学界で研究されてきた自料構造で、**「複数ノードで同時編集しても最終的に同じ状態に収束 (eventually consistent) する」** という数学的保証を提供します。大きく 2 つのファミリーがあります。

- **State-based CRDT (CvRDT)** — ノードが全体状態を交換してマージします。シンプルですが帯域を多く使います。

- **Operation-based CRDT (CmRDT)** — ノードが操作 (insert, delete) 自体を伝播します。効率的ですが、信頼できるメッセージ配信が必要です。

**Yjs** (Kevin Jahns, 2015 年 ~) は最も広く使われている CRDT ライブラリです。YATA (Yet Another Transformation Approach) アルゴリズムをベースに、Operation-based + 効率的なバイナリエンコーディング (`y-protocols`) を組み合わせ、大型ドキュメントでも高速に動作します。tldraw, Excalidraw, JupyterLab, Hocuspocus, Liveblocks がすべて Yjs 上に構築されています。

const doc = new Y.Doc()

// Y.Text — 協業テキスト型

const yText = doc.getText('content')

yText.insert(0, 'Hello ')

yText.insert(6, 'world!')

console.log(yText.toString()) // "Hello world!"

// Y.Map / Y.Array — 協業オブジェクト/リスト

const yMap = doc.getMap('user')

yMap.set('name', 'Alice')

yMap.set('cursor', { x: 10, y: 20 })

// 状態同期 — バイナリ update vector

const update = Y.encodeStateAsUpdate(doc)

const doc2 = new Y.Doc()

Y.applyUpdate(doc2, update)

console.log(doc2.getText('content').toString()) // "Hello world!"

// 観測 — 変更イベント購読

yText.observe((event) => {

console.log('Text changed:', event.changes.delta)

})

**Automerge** (Martin Kleppmann + Ink & Switch, 2017 年 ~) は「JSON CRDT」として始まり、2022 年に発表された **Automerge 2** は Rust コア + WebAssembly バインディングで再記述され、100 倍速の性能を達成しました。2024 年リリースの **Automerge-repo** は同期プロトコル・ストレージ・ネットワークアダプタまでまとめたフルスタックライブラリです。

const repo = new Repo({

network: [new BrowserWebSocketClientAdapter('wss://sync.example.com')],

storage: new IndexedDBStorageAdapter('my-app'),

})

interface Doc {

title: string

items: { id: string; text: string; done: boolean }[]

}

const handle = repo.create<Doc>({ title: 'My Tasks', items: [] })

handle.change((doc) => {

doc.items.push({ id: 'a1', text: 'Buy milk', done: false })

})

// 他クライアントの変更も自動でマージされます

handle.on('change', ({ doc }) => {

console.log('Updated:', doc)

})

**Loro** (2023 年 ~ , Rust 製) は Automerge より小さい wire format と **タイムトラベル (Time Travel)** を一級でサポートします。すべての編集履歴が効率的に保存され、「10 分前の状態に戻す」が O(編集数) ではなく O(log n) に近く動作します。

**Diamond Types** (Seph Gentle, 2022 年 ~) はテキスト専用 CRDT で、「テキスト CRDT のメモリ・CPU オーバーヘッドを 1 倍未満に」を目標とします。JS で Yjs と比較ベンチマークでは優位ですが、Yjs の巨大なエコシステムのため採用率は低めです。

**Y-Sweet** (Drifting in Space, 2023 年 ~ ) は Yjs を SaaS としてホストするサービスで、セルフホスト可能な Rust サーバ (`y-sweet`) もオープンソース化されています。Liveblocks の競合というより「Yjs を自前運用したいがサーバ管理はしたくない」チーム向け。

3. CRDT vs OT vs Last-Write-Wins — 衝突解決戦略

協業データ構造の衝突解決には大きく 4 つの戦略があります。

| 戦略 | 仕組み | 使用例 |

|---|---|---|

| Operational Transform (OT) | 操作を同時操作に合わせて変換 | Google Docs, ShareDB, Etherpad |

| CRDT | 数学的に commutative な操作 | Figma, Notion (一部), Linear, tldraw, Excalidraw |

| Last-Write-Wins (LWW) | タイムスタンプが新しい方が勝つ | DynamoDB, Cassandra, 簡易 KV |

| アプリケーションレベルマージ | ドメインロジックでマージ | Git, Jira, 多くの業務アプリ |

**OT (Operational Transform)** は 1989 年に Sun で初めて発表され、Google Docs (2006), Microsoft Office Live が採用した伝統的方式です。コアは「ユーザー A がインデックス 5 に 'x' を挿入、同時にユーザー B がインデックス 3 に 'y' を挿入した場合、B の操作が到着したら A のインデックス 5 を 6 に変換 (transform) する」というもの。直感的ですが **中央サーバ (authority)** が必須で、100 人以上の同時編集では transform matrix が爆発する制限があります。

**CRDT** は数学的に「すべての操作ペアが commutative (交換可能)」となるよう設計し、transform なしに合わせても最終的に同じ結果になるようにします。分散環境 (P2P, オフラインファースト) に強いですが、メタデータオーバーヘッド (各操作ごとに UUID + lamport clock) が大きく、Wikipedia のように「削除されたコンテンツも永久保存 (tombstone)」する必要があるためメモリが増えます。Yjs · Automerge · Loro はこのオーバーヘッドを減らすアルゴリズム最適化に注力します。

**LWW (Last-Write-Wins)** は最もシンプルな戦略です。タイムスタンプが新しい方が勝ちます。衝突可能性が低いドメイン (例: ユーザープロフィールの最終更新時刻) には適しますが、同時編集テキストではデータ損失が発生します。

**アプリケーションレベルマージ** は Git が代表例です。衝突が発生したら人が解決するモデル。Jira · Asana などの業務アプリも本質的にはこの方式で、一定レベルの衝突があってもドメインロジック (例: 「より新しいコメントが上」) で解決します。

選択基準: テキスト同時編集は CRDT か OT、スケジュール管理・イシュートラッカーはアプリケーションレベル、シンプルな同期は LWW。Figma は CRDT、Google Docs は OT、Linear は LWW + ドメインマージの組み合わせです。

4. Liveblocks — マルチプレイヤー SaaS のリーダー

Liveblocks (`liveblocks.io`) は 2021 年にフランスで創業、2024 年にシリーズ A を調達した会社で、2026 年現在マルチプレイヤー SaaS カテゴリの名実ともに 1 位です。Notion 出身のエンジニアが創業し、「Notion が自前構築したものを SaaS として」というポジショニングです。

中核価値は **React + Yjs 統合の摩擦排除** です。Yjs を直接使うには y-websocket サーバを運用し、awareness プロトコルを実装し、presence を管理する必要がありますが、Liveblocks はこれをすべて SDK 一行で完結させます。

// React マルチプレイヤーコンポーネント — Liveblocks

function App() {

return (

)

}

function CursorTracker() {

const updateMyPresence = useUpdateMyPresence()

return (

onPointerMove={(e) => updateMyPresence({ cursor: { x: e.clientX, y: e.clientY } })}

onPointerLeave={() => updateMyPresence({ cursor: null })}

style={{ width: '100vw', height: '100vh' }}

/>

)

}

function OnlineUsers() {

const others = useOthers()

return (

{others.length} 人が一緒に見ています

{others.map(({ connectionId, presence }) => (

presence.cursor && (

key={connectionId}

x={presence.cursor.x}

y={presence.cursor.y}

/>

)

))}

)

}

Liveblocks は 2024 年に **Comments (スレッド型コメント)**、2025 年に **Notifications (アプリ内通知 + メール)**、そして 2025 年後半に **Liveblocks AI Copilots** (AI 編集者が協業者として参加) を追加しました。価格は月間アクティブユーザー (MAU) 単位で、開始時は無料、100 MAU から有料です。

オープンソース代替は **Hocuspocus** (`tiptap.dev/hocuspocus`) で、Yjs 用のセルフホスト可能な Node.js サーバです。TipTap エディタを作ったチームが運営し、Liveblocks のコア機能 (persistence, auth, webhook) を無料提供します。

5. PartyKit (Cloudflare 買収) — Durable Objects ベース

PartyKit (`partykit.io`) は React コアチーム出身の Sunil Pai が 2023 年に創業し、2024 年 4 月に Cloudflare に買収されました。2026 年現在、PartyKit は **Cloudflare Workers + Durable Objects** 上に構築された「プログラマブルなマルチプレイヤーインフラ」です。

Liveblocks が「準備されたビルディングブロック」なら、PartyKit は「プログラマブルなキャンバス」です。各「party」は Durable Object 一つで、ユーザーはその中で任意の TypeScript コードを実行できます。チャットボット、ホワイトボード、ゲームルームなど、任意の stateful realtime ワークロードを一箇所に集約できます。

// PartyKit サーバ — 単一ファイル

export default class ChatServer implements Party.Server {

constructor(readonly room: Party.Room) {}

// クライアントが接続したとき

async onConnect(conn: Party.Connection, ctx: Party.ConnectionContext) {

// 最近のメッセージ 100 件をロード (Durable Object 内蔵ストレージ)

const messages = (await this.room.storage.get<string[]>('messages')) ?? []

conn.send(JSON.stringify({ type: 'history', messages }))

}

// メッセージ受信

async onMessage(message: string, sender: Party.Connection) {

const messages = (await this.room.storage.get<string[]>('messages')) ?? []

messages.push(message)

if (messages.length > 100) messages.shift()

await this.room.storage.put('messages', messages)

// ルーム内全接続にブロードキャスト

this.room.broadcast(message, [sender.id]) // sender は除外

}

}

// クライアント

const socket = new PartySocket({

host: 'my-app.username.partykit.dev',

room: 'lobby',

})

socket.addEventListener('message', (e) => console.log(e.data))

socket.send('Hello world!')

Cloudflare 買収後、PartyKit は Cloudflare の世界 300 以上のデータセンターで自動実行され、**エッジに近い場所で実行される Durable Object** という差別化がより明確になりました。2025 年から PartyKit コードは Cloudflare Workers コードと互換性があり、別の PartyKit アカウントなしで Cloudflare ダッシュボードから統合管理できるようになりました。

PartyKit の強みは **柔軟性**、弱みは **ビルディングブロックの不足** です。Liveblocks の Comments · Notifications のような high-level 機能は自分で実装する必要があります。

6. Yjs エコシステム — y-websocket, y-protocols, awareness

Yjs はライブラリ自体だけでなく、その周辺の **transport adapter, persistence adapter, awareness プロトコル** エコシステムが巨大です。

**y-websocket** は標準 transport アダプタです。Node.js ベースのサーバ (`y-websocket-server`) とブラウザクライアント (`y-websocket`) がペアをなし、WebSocket 上で Yjs アップデートを効率的に転送します。

// クライアント

const ydoc = new Y.Doc()

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

// awareness — カーソル、選択範囲、ユーザー色

provider.awareness.setLocalStateField('user', {

name: 'Alice',

color: '#ff0000',

cursor: { x: 10, y: 20 },

})

provider.awareness.on('change', (changes) => {

for (const [clientId, state] of provider.awareness.getStates()) {

console.log(clientId, state.user)

}

})

**y-indexeddb** はブラウザローカルストレージアダプタ。オフラインでも編集内容を IndexedDB に保管し、オンライン復帰時に同期します。

**y-protocols** は sync (状態同期), awareness (presence), auth (認証) の 3 つの wire protocol を定義した標準パッケージです。

**y-monaco / y-prosemirror / y-codemirror.next** などのエディタバインディングが豊富に存在します。tldraw が Yjs を採用した理由は、他の CRDT とは比較にならない **エディタ統合エコシステム** のためです。

**Hocuspocus** (2022 年 ~ ) は TipTap チームが作った Yjs 用フルスタックサーバで、persistence, webhook, auth, scaling を一括提供します。セルフホスト可能で Postgres · Redis バックエンドをサポートし、2025 年からは Hocuspocus Cloud ホスト型サービスもリリースされました。

7. Replicache — クライアントファースト同期の元祖

Replicache (`replicache.dev`) は Rocicorp (Aaron Boodman, 元 Roam · 元 Google) が 2020 年にリリースしたクライアントファースト同期エンジンです。Linear, Loom, Sentry, Productboard, Coalesce などが採用しました。

Replicache のモデルは次の通りです。

1. クライアントは IndexedDB に独自データコピーを持つ

2. ユーザーアクションは **mutation** (JS 関数) として定義され、ローカルに即座に適用

3. mutation はバックエンドの同名ハンドラにも伝達

4. バックエンドはグローバル真実 (source of truth) を更新し、新しい **pull response** を作成してクライアントにプッシュ

5. クライアントが pull response を適用すると、ローカルの optimistic mutation は破棄され、サーバ状態に置き換わる

// Replicache クライアント設定

type M = typeof mutators

const mutators = {

async createTask(tx, args: { id: string; text: string }) {

await tx.set(`task/${args.id}`, { text: args.text, done: false })

},

async toggleTask(tx, args: { id: string }) {

const t = await tx.get<{ text: string; done: boolean }>(`task/${args.id}`)

if (t) await tx.set(`task/${args.id}`, { ...t, done: !t.done })

},

}

const rep = new Replicache<M>({

licenseKey: process.env.NEXT_PUBLIC_REPLICACHE_LICENSE_KEY!,

name: 'user-alice',

pushURL: '/api/replicache/push',

pullURL: '/api/replicache/pull',

mutators,

})

// UI から呼び出し — 即座にローカル適用、バックグラウンドでサーバ同期

await rep.mutate.createTask({ id: 'a1', text: 'Buy milk' })

// リアクティブクエリ

const tasks = rep.subscribe(

async (tx) => {

const entries = await tx.scan({ prefix: 'task/' }).entries().toArray()

return entries.map(([k, v]) => ({ key: k, ...v }))

},

(tasks) => render(tasks)

)

Replicache は **データモデルを強制しません**。KV ストア上に任意の自料構造を載せられ、mutation は任意の JS 関数なのでどんなドメインにも合わせられます。一方、**サーバ側実装負担** が大きく、push エンドポイントと pull エンドポイントを自前で書き、mutation を SQL で再実装する必要があります。

価格は MAU 単位で、1,000 MAU まで無料、それ以上は月 $1/MAU。2024 年から Rocicorp は Replicache の後継 **Zero** 開発に集中し始め、新規採用は Zero を推奨します。

8. Zero (Rocicorp 2024) — 次世代同期エンジン

Zero (`zero.rocicorp.dev`) は Replicache 創業者 Aaron Boodman が 2024 年 11 月に発表した次世代同期エンジンです。中核アイデアは「Replicache の KV モデルを捨て、**リレーショナルクエリ** を一級でサポート」することです。

Zero モデル:

1. バックエンドは普通の Postgres

2. クライアントは SQLite (または IndexedDB ベース WASM SQLite) で独自コピー保管

3. ユーザーが `z.query.issues.where('status', 'open').orderBy('updatedAt', 'desc').limit(10)` のようなクエリを記述

4. Zero は **クエリに影響する可能性のあるデータのみ** クライアントに同期 (rolling subscription)

5. クエリは IndexedDB で即座に実行され zero latency 応答

6. バックエンド変更は WebSocket でプッシュされ、クエリ結果が自動で再評価される

// Zero 使用例 — Linear スタイルのイシュートラッカー

const z = new Zero({

userID: currentUser.id,

server: 'wss://zero.example.com',

schema: mySchema, // Postgres から自動抽出可能

kvStore: 'idb',

})

function IssueList() {

const [issues] = useQuery(

z.query.issues

.where('status', '=', 'open')

.related('assignee')

.related('comments', (q) => q.orderBy('createdAt', 'desc'))

.orderBy('priority', 'desc')

.limit(50)

)

return (

{issues.map((issue) => (

{issue.title} - {issue.assignee?.name}

))}

)

}

// 変更は自動 optimistic — UI が 0ms で更新され、バックグラウンドでサーバに同期

await z.mutate.issues.update({ id: 'iss_1', status: 'closed' })

Zero が Replicache 比でもたらした最大の変化は **読み取りモデルの変化** です。Replicache は KV scan を手書きする必要がありましたが、Zero は ORM のようなクエリビルダで SQL に近い表現力を提供します。JOIN や nested relation もサポートするので、Linear のような複雑ドメインではるかに自然になります。

2025 年 7 月に Zero が安定版を発表し、2026 年現在 Linear が自社コア同期エンジンを Replicache から Zero に移行中です (Linear 公式ブログ 2025-12 記事参照)。

9. ElectricSQL — Postgres + SQLite 双方向同期

ElectricSQL (`electric-sql.com`) は 2022 年に英国で創業した会社で、「Postgres とクライアント SQLite を双方向同期」という明確なミッションを掲げています。2024 年後半に **大きなピボット** を行い、従来の CRDT ベースアプローチを捨て、**Phoenix LiveView スタイルのサーバ権威 (authority) + shape ベース subscription** に再設計しました。

新 ElectricSQL モデル:

1. バックエンドは Postgres + Electric sync service (Elixir 製)

2. クライアントは PGlite (ブラウザ用 WASM Postgres) または SQLite を独自コピーとして使用

3. クライアントが **shape** (例: 「自社の active=true な従業員」) を購読

4. Postgres logical replication ベースで、shape に影響する変更のみクライアントにプッシュ

5. 書き込みは通常の HTTP API で送り、Postgres トランザクションがコミットされると自動伝播

// PGlite または wa-sqlite を独自クライアント DB として

const electric = await electrify(database, schema, {

url: 'wss://electric.example.com',

})

// shape 購読 — 会社 ID の active 従業員のみ

const shape = await electric.sync.subscribe({

table: 'employees',

where: 'company_id = $1 AND status = $2',

bindings: [currentUser.companyId, 'active'],

include: { manager: true }, // FK 自動追従

})

await shape.synced

// 通常 SQL でクライアントコピーを参照 — すべて IndexedDB で即座

const employees = await electric.db.employees.findMany({

where: { department: 'Engineering' },

})

// 変更は HTTP POST — バックエンド Postgres にトランザクションとして適用

await fetch('/api/employees', {

method: 'POST',

body: JSON.stringify({ name: 'Alice', department: 'Engineering' }),

})

// 変更されたデータは自動でサブスクライバ全員に伝播

ElectricSQL の強みは **Postgres をそのまま残す** ことです。既存の Rails · Django · Next.js バックエンドをほぼ変更なく使え、ORM もそのまま利用できます。弱みは新モデルでは **クライアントから直接書き込みできない** (サーバ権威モデル) ことで、optimistic update が必要なら別パターン (例: TanStack Query の `useMutation` + `onMutate`) を使う必要があります。

2025 年から Vercel · Supabase · Neon などの Postgres ホスティング業者との統合を強化し、Vercel Postgres + ElectricSQL の組み合わせで別途インフラなしにローカルファーストアプリを作れるようになりました。

10. PowerSync — モバイルファースト同期

PowerSync (`powersync.com`) は 2023 年にリリースされた同期エンジンで、**モバイルアプリ (iOS/Android/React Native/Flutter)** を一級ターゲットとします。バックエンドは Postgres · Supabase · Firebase の三つ全てに対応します。

PowerSync のモデルは ElectricSQL と似ていますが、**モバイル SQLite を一級でサポート** し、**bucket ベースパーティショニング** で 1 ユーザーが見るべきデータのみ同期します。

// React Native + PowerSync

const db = new PowerSyncDatabase({

schema: AppSchema,

database: { dbFilename: 'app.db' },

})

await db.connect(new SupabaseConnector())

// データ参照 — 常にローカル SQLite、即時応答

const issues = await db.getAll(

'SELECT * FROM issues WHERE assignee = ? ORDER BY priority DESC',

[currentUser.id]

)

// 変更 — ローカルに即座に適用、バックグラウンドで Supabase にプッシュ

await db.execute(

'UPDATE issues SET status = ? WHERE id = ?',

['closed', 'iss_1']

)

PowerSync は **オフラインファースト (Offline-first)** シナリオに強いです。地下鉄、飛行機、山間部でもアプリが即座に動作し、ネットワーク復帰時に自動同期。フィールドサービス · 医療現場 · 農業などオフライン比重が高い B2B モバイルアプリで採用率が高い。

2025 年から PowerSync は React/Next.js などの Web 環境もサポートし始め、ElectricSQL と直接競合します。

11. Convex — バックエンド全体を束ねた reactive フルスタック

Convex (`convex.dev`) は 2021 年創業、2024 年にシリーズ B を調達した会社で、「データベース + 関数 + 同期を 1 セットで」提供するフルスタックバックエンドです。Firebase の後継世代としてよく比較されます。

Convex の差別化は **すべてのクエリが自動 reactive** であることです。クライアントが `useQuery(api.tasks.list)` を呼ぶと、そのクエリに影響する mutation が発生するたびに自動で再実行され、UI が更新されます。

// Convex — サーバ関数定義

// convex/tasks.ts

export const list = query({

args: { ownerId: v.id('users') },

handler: async (ctx, args) => {

return await ctx.db

.query('tasks')

.withIndex('by_owner', (q) => q.eq('ownerId', args.ownerId))

.order('desc')

.collect()

},

})

export const create = mutation({

args: { text: v.string() },

handler: async (ctx, args) => {

const userId = (await ctx.auth.getUserIdentity())!.subject as Id<'users'>

return await ctx.db.insert('tasks', {

text: args.text,

ownerId: userId,

done: false,

})

},

})

// Convex — クライアント (React)

function TaskList() {

const tasks = useQuery(api.tasks.list, { ownerId: currentUser._id })

const createTask = useMutation(api.tasks.create)

// 他ユーザーが task を追加すると自動で再レンダリング

return (

{tasks?.map((t) => <div key={t._id}>{t.text}</div>)}

)

}

Convex の強みは **魔法のような DX** です。WebSocket · subscription · invalidation を直接扱わなくても、すべてのクエリが自動で reactive。データベース、関数、ファイルストレージ (`ctx.storage`), スケジュール (`ctx.scheduler`), 外部アクション (`ctx.runAction`) がすべて 1 つの SDK に束ねられています。

弱みは **ベンダロックイン** と **オンプレ不可** (2026 年 5 月時点)。ただし 2025 年にリリースされたセルフホスト Convex ベータが、一部エンタープライズ顧客に限り提供開始されました。

12. Triplit — TypeScript-first フルスタック同期

Triplit (`triplit.dev`) は 2023 年に創業した会社で、「End-to-end TypeScript 型安全性 + ローカルファースト同期」を目標とします。Convex より小さくシンプルな API で、オープンソース (`triplit-io/triplit`) です。

const schema = {

collections: {

todos: {

schema: S.Schema({

id: S.Id(),

text: S.String(),

completed: S.Boolean({ default: false }),

createdAt: S.Date({ default: S.Default.now() }),

}),

},

},

}

const client = new TriplitClient({

serverUrl: 'https://triplit.example.com',

schema,

})

// クエリ — 結果はローカルで即座、サーバ変更は自動プッシュ

const subscription = client.subscribe(

client.query('todos').where('completed', '=', false).order('createdAt', 'DESC'),

(results) => render(results)

)

// トランザクション — optimistic + 自動衝突解決

await client.transact(async (tx) => {

await tx.insert('todos', { text: 'Buy milk' })

})

Triplit の強みは **schema-first アプローチ** と **フルスタック型推論** です。サーバ関数が別にあるわけではなく、権限ルール (read/write/delete) を schema 上に宣言的に定義します。

13. Jazz.tools — 分散状態フレームワーク

Jazz.tools (`jazz.tools`) は 2023 年に創業した会社で、「Distributed state framework」というユニークなポジショニングです。データベースではなく **CRDT オブジェクトをクライアント同士が P2P またはクラウド同期で共有** するモデルです。

class Task extends CoMap {

text = co.string

done = co.boolean

}

class TaskList extends CoList.Of(co.ref(Task)) {}

// 新しい task list 作成 (CRDT オブジェクト)

const list = TaskList.create([], { owner: me })

// 他ユーザーと共有 (URL で)

const shareUrl = list.id

console.log(`Share: https://app.example.com/list/${shareUrl}`)

// 変更 — 全サブスクライバに自動伝播

list.push(Task.create({ text: 'Buy milk', done: false }, { owner: me }))

Jazz.tools の強みは **E2E 暗号化 + P2P** オプションです。すべてのデータがクライアントで暗号化され、サーバは暗号文のみを見るというセキュリティモデルを提供します。

14. InstantDB, Evolu, Vlcn — 新興陣営

**InstantDB** (`instantdb.com`, 2023 年 ~) は Relay/Firebase 着想の GraphQL-like クライアントファースト DB です。クエリ結果が自動 reactive で、トランザクションは optimistic。2025 年にシリーズ A を調達しました。

**Evolu** (`evolu.dev`, 2024 年 ~ ) は **ローカルファースト + 端到端暗号化** を中核価値に置きます。SQLite をクライアントに置き、変更分のみ暗号化してサーバに同期。パスワードなどの機微情報を扱うアプリに適します。

**Vlcn / cr-sqlite** (2023 年 ~ ) は **SQLite を CRDT に拡張するネイティブ extension** です。通常の SQL をそのまま使いながら、同期・マージが自動で動作します。Tantaman (Matt Wonlaw) が作成し、Discord で一部使用されています。

15. WebSocket vs WebRTC vs SSE vs WebTransport

協業の transport 選択は 4 つのオプションがあります。

| プロトコル | モデル | 強み | 弱み |

|---|---|---|---|

| WebSocket | クライアント-サーバ双方向 TCP | 普遍的、全ブラウザ、全バックエンド | head-of-line blocking, 部分メッセージ |

| WebTransport | HTTP/3 上の streams | 多重 stream, 信頼性オプション | Safari 未サポート (2026), バックエンド制限 |

| WebRTC DataChannel | P2P, UDP ベース | 超低遅延, サーバ負荷ゼロ | NAT traversal, signaling 必要 |

| Server-Sent Events | サーバ -> クライアント単方向 | HTTP そのまま、シンプル | 単方向なので入力は別途 |

**WebSocket** は事実上の標準です。全ブラウザがサポートし、Node.js · Go · Rust · Python すべてライブラリが豊富。Liveblocks, PartyKit, Yjs, Convex がすべて WebSocket を使います。限界は 1 接続内にメッセージキューが 1 本なので head-of-line blocking が発生する点。

**WebTransport** は HTTP/3 (QUIC) 上に構築された多重 transport です。Chrome · Edge · Firefox は 2024 年からサポート、Safari は 2026 年ベータで追加されました。1 接続内で複数 stream を同時に送れるので head-of-line blocking がありません。ただしバックエンドサポートはまだ不足 (Go の `quic-go`, Cloudflare Workers 程度)。

**WebRTC DataChannel** は P2P 直接接続で、サーバを経由せず超低遅延メッセージを交換できます。欠点は NAT traversal (STUN/TURN サーバ), signaling チャネルが別途必要なこと。Figma マルチカーソルが一部 WebRTC DataChannel を活用していると知られています。

**SSE (Server-Sent Events)** は HTTP 上の単方向 push で最もシンプル。ChatGPT のような LLM ストリーミング, 通知伝播に頻繁に使われますが、双方向協業には不足です。

選択基準: 一般的協業は WebSocket, 超低遅延ゲーム/マルチカーソルは WebRTC, AI ストリーミング/通知は SSE, 未来志向なら WebTransport。

16. Ably / Pusher / Soketi / Centrifugo — 汎用 realtime pub/sub

協業アプリに直接使うわけではないですが、backbone としてよく使われる汎用 realtime pub/sub サービスがあります。

**Pusher** (`pusher.com`, 2010 年 ~ , MessageBird 買収) は最古の realtime SaaS で、「Pusher Channels」がチャット · 通知バックボーンの事実上の標準でした。2026 年現在、モダン SaaS の直接採用は減りましたが、レガシーユーザーが多く依然として大きなビジネスです。

**Ably** (`ably.com`, 2016 年 ~ ) は Pusher の後継世代で、**グローバル分散 + 99.999% SLA + メッセージ順序保証** を価値提案にします。Hubspot, Vercel, Splunk などが採用しました。

**Soketi** (`soketi.app`, 2022 年 ~ ) は Pusher プロトコル互換のオープンソースサーバです。Pusher コードをそのまま残してセルフホストに切り替えたいときに使います。Laravel WebSockets の後継プロジェクト。

**Centrifugo** (`centrifugal.dev`, ロシア出身オープンソース, 2016 年 ~ ) は Go で書かれた高性能 realtime メッセージングサーバです。Avito, VK などのロシア大手サービスで検証されたバックボーンで、単一ノード 100 万同時接続を処理します。

**Supabase Realtime** (`supabase.com/realtime`) は Postgres の LISTEN/NOTIFY + 独自 broadcast チャネルを組み合わせたオープンソース realtime サービスです。Elixir (Phoenix) ベースで Erlang OTP の分散処理を活かせる強み。Postgres と同じバックエンドで協業機能を追加するのに最も摩擦が少ない選択肢です。

17. tldraw / Excalidraw — Yjs ベースホワイトボード事例

**tldraw** (`tldraw.com`) は Steve Ruiz が作った無料無限キャンバスホワイトボードで、2024 年にシリーズ A を調達しました。tldraw の協業エンジンは初期は自前実装でしたが、2023 年後半から Yjs に移行しました。tldraw が Yjs を選択した理由は自社ブログ ("How tldraw's sync server works", 2024) で詳しく説明されています。

**Excalidraw** (`excalidraw.com`) は Christopher Chedeau (Vjeux, 元 Meta) が作った手書き風ホワイトボードで、Excalidraw+ 有料プランがあり、オープンソース無料版も同じ協業エンジンを使います。Yjs + y-websocket 標準組み合わせで、セルフホストサーバコード (`excalidraw/excalidraw-room`) が公開されています。

両製品とも **実世界で Yjs が動作する** 証拠であり、他のホワイトボード製品 (FigJam, Miro, Mural) が追従すべき標準となっています。

18. Notion / Linear / Figma — 協業 UX の頂点

**Notion** は自前構築の OT ベース協業エンジンを使っていると言われています (公式発表なし)。2024 年 Notion が Anytype 追従でローカルファースト方向に一部移行中という採用情報が発見されました。

**Linear** は Replicache を早期に採用し、2025 年から Zero に移行中です。Linear の即時 UX は「すべての作業がローカル IndexedDB で 0ms に実行され、バックグラウンドで同期」というパラダイムの最良の事例です。

**Figma** は自前構築 CRDT を使い、2019 年 Evan Wallace (共同創業者) の "How Figma's multiplayer technology works" ブログ記事が公開されています。中核は「各オブジェクトの各プロパティに LWW + 親子ツリー変形 (必ず 1 つの親のみ) のための独自 CRDT」です。

19. コードエディタリアルタイム — VS Code Live Share, Replit, CodeSandbox

**VS Code Live Share** (Microsoft, 2017 年 ~) は同僚の IDE に直接参加し、一緒にコード編集・デバッグセッションを共有する機能です。Microsoft の独自サービス (Visual Studio Live Share Service) を通じて動作し、無料です。

**CodeSandbox / CodeSandbox Live** (`codesandbox.io`) はブラウザ IDE から始まり、2024 年にマイクロ VM (Firecracker) ベースの cloud development environments にピボットしました。Live モードで複数人が同じブラウザ IDE で同時編集します。

**Replit Multiplayer** は Replit IDE で同時編集 + 音声/ビデオ通話まで提供します。教育用途比重が高い。

**CodeTogether** (`codetogether.com`) は IntelliJ · Eclipse · VS Code マルチ IDE で同時編集を可能にするプラグインベースサービスです。

20. ゲーム状態同期 — Colyseus, Photon, Hathora

ゲームマルチプレイは協業と異なる transport · 一貫性要件を持ちます。

**Colyseus** (`colyseus.io`) は Node.js ベースのマルチプレイヤーゲームフレームワークで、ルームベースモデル + 独自 schema sync を提供します。.io ゲーム · モバイルゲームで人気。

**Photon Engine** (`photonengine.com`) は Unity · Unreal ゲーム開発に事実上の標準のマルチプレイ SaaS です。PUN (Photon Unity Networking), Photon Fusion などの世代別 SDK があります。

**Hathora** (`hathora.dev`) はゲームサーバホスティング + マッチメイキング SaaS で、クラウドゲームサーバをグローバル分散で運用する負担を減らします。

**PlayCanvas Engine** (`playcanvas.com`) はブラウザベース 3D ゲームエンジンで、マルチプレイを内蔵サポートします。

協業 SaaS との違いは **ティックレート (60fps 基準 16.67ms 周期)**, **クライアントサイド予測 (client prediction) + サーバ権威 reconciliation**, **dead reckoning** などゲーム特有のパターンです。

21. 事例パターン — カーソル、コメント、通知、Activity Feed

リアルタイム協業 UX はほとんどすべて次の 4 つのパターンの組み合わせです。

**1) Cursors + Presence** — 「誰が今どこを見ているか」。Liveblocks の `Presence`, Yjs の `awareness`, PartyKit の `connection` がすべて同じ概念を異なる名前で呼びます。カーソル位置、選択範囲、ユーザーアバターが中核データです。

// Liveblocks Presence 例

function CursorLayer() {

const updateMyPresence = useUpdateMyPresence()

const others = useOthers()

return (

onPointerMove={(e) => updateMyPresence({ cursor: [e.clientX, e.clientY] })}

>

{others.map(({ connectionId, presence }) => (

presence.cursor && (

)

))}

)

}

**2) Live Multiplayer Editing** — 同時テキスト/図形編集。Yjs · Automerge · OT のような CRDT/OT エンジンの本業。

**3) Comments + Threads** — ページ内の特定領域へのコメントスレッド。難所は **アンカー (anchor) 安定性** です。ユーザーが「Hello world」の「world」にコメントを付けたら、他人が「Hello cruel world」に編集した場合、アンカーはどこに行くべきか。Yjs は `Y.RelativePosition` でこの問題を解決します。

**4) Notifications + Activity Feed** — 「あなたをメンションしたコメントが付きました」、「イシューが閉じられました」。Liveblocks Notifications, Knock, Courier などの SaaS がこの領域を扱います。

22. 韓国事例 — Toss / Naver Whale / Kakao Workspace

**Toss Workspace** — Toss の社内協業ツールは自前構築と言われ、リアルタイム同期は Yjs ベースだと 2024 年 Toss SLASH カンファレンスで一部公開されました。特徴は金融規制対応のため **すべての協業イベントが 5 年監査ログとして残る** ことです。

**Naver Whale 協業 / Naver Office** — Naver Office (Naver Docs, Slides) は OT ベースの自前協業エンジンを使い、Naver Whale ブラウザ内で動作します。2025 年に発表された「Whale Spaces」は PartyKit と類似した任意ドメインのリアルタイム協業コンポーネントを提供します。

**Kakao Workspace / Kakao Agit** — Kakao の社内協業ツールは自前構築で、詳しいアーキテクチャは公開されていません。

**NetFunnel** — STCLab の NetFunnel はリアルタイム協業自体ではなく大規模同時接続トラフィック制御 (仮想待合室) に特化していますが、多数ユーザーが同じリソースを同時にアクセスするシナリオという点で協業と隣接するカテゴリです。

**LINE Note / Worktile Korea** — LINE の社内協業ツールは日本本社と共有し、詳しい公開資料は少ないです。

23. 日本事例 — サイボウズ kintone, Sansan, Backlog (Nulab), JaaS

**サイボウズ kintone** — サイボウズは日本最大の協業 SaaS 企業で、kintone (2011~) はノーコード業務アプリビルダーで同時編集をサポートします。自前構築 OT ベースで、2024 年に一部モジュールを Yjs に移行中との発表がありました。

**Sansan Bill One** — 請求書管理 SaaS である Bill One は、複数ユーザーが同時に請求書をレビューするシナリオのため自前協業エンジンを構築しました。2025 年 Sansan Tech Conf で一部公開。

**Backlog (Nulab)** — 福岡ベース Nulab の Backlog はイシュートラッカー + Git + Wiki を束ねた協業ツールで、リアルタイム同時編集は Wiki に限定され、自前 OT ベースです。

**JaaS (Jitsi as a Service) 日本リージョン** — 8x8 の JaaS は東京リージョンを通じて日本企業にビデオ会議 + ホワイトボードを提供します。ホワイトボードモジュールは Excalidraw (Yjs) ベース。

**Notion 日本** — Notion 日本は 2023 年に正式進出し、日本語 UI · 決済 · サポート + 日本企業の協業利用事例が急速に増えました。メルカリ, freee, サイバーエージェントなどが採用しました。

24. 運用上の落とし穴 — Awareness flooding, sync storms, conflict spikes

大規模協業時によく出会う運用上の落とし穴 3 つを先に知っておくと良いでしょう。

**1) Awareness flooding** — ユーザーがカーソルを高速で動かすと 100ms ごとに awareness 更新が発生し、ルームに 50 人いれば毎秒 25,000 件の小さなメッセージが行き交います。解決策は **throttling** (例: 60ms ごとに 1 回) + **delta encoding** (前値との差分のみ転送)。

**2) Sync storms** — 新規ユーザーがルームに入る際に文書全体を同期するので、大型文書 (例: 500KB Yjs document) は一度に 50 人が入ると 25MB の帯域を使います。解決策は **rate limiting** + **CDN キャッシング** (初回 sync は静的スナップショットから)。

**3) Conflict spikes** — 多数ユーザーが同じセルに同時入力するとマージコストが爆発します。UX レベルで **soft lock** (ユーザーがセルに入ると鍵アイコン) + **optimistic write** のバランスが重要です。

25. コスト — Liveblocks vs Yjs セルフホストの損益分岐点

おおまかなコスト比較 (2026 年 5 月時点):

- **Liveblocks** — 100 MAU 無料、1,000 MAU 月 $99、10,000 MAU 月 $499、100,000 MAU 月約 $4,000。

- **PartyKit** — Cloudflare Workers 価格、1M リクエスト/日無料、それ以上はリクエスト単位 $0.30/1M + Durable Object 時間 $0.50/M GB-s。

- **Yjs + y-websocket セルフホスト** — 小さいルーム 100 個を 1 台の t3.medium ($30/月) で十分処理、1,000 ルームなら c6i.xlarge ($120/月) + Postgres。

- **Hocuspocus Cloud** — 1,000 同時接続月 $99。

損益分岐点はおよそ **10,000~50,000 MAU の間** です。その下は Liveblocks が圧倒的に安く、それ以上ではセルフホストが経済的です。ただしセルフホストは SRE 人件費がかかるので、単純なインフラコスト比較だけでは不足です。

26. 2026 年トレンド — Local-first ルネサンス、AI Copilot の到来

3 つの大きなトレンドが見えます。

**Local-first ルネサンス** — Linear · Notion · Figma などの先頭 SaaS がすべて「より速い UX」の答えとしてローカルファーストを選びました。2024~2025 年に Zero · ElectricSQL · Triplit · Jazz.tools などの新興陣営が爆発的に増え、2026 年には「新規 SaaS のデフォルトが local-first」となる見通しです。

**AI Copilot の到来** — Liveblocks AI Copilots (2025) のように、AI エージェントが人のように協業ルームに参加して文書を一緒に編集するモデルが浮上しています。Cursor, Continue, Aide などの AI コーディングツールも同じ方向。CRDT の強み (「非人間エージェントも同じ自料構造を共有」) がついに花開いています。

**WebTransport 拡散** — Safari が 2026 年ベータで WebTransport をサポートしたことで、「次世代 transport」の採用が加速するでしょう。PartyKit · Liveblocks が WebTransport バックボーンに移る作業が進行中です。

27. 参考 / References

- Yjs documentation — `https://docs.yjs.dev/`

- Yjs GitHub — `https://github.com/yjs/yjs`

- Automerge — `https://automerge.org/`

- Automerge-repo — `https://github.com/automerge/automerge-repo`

- Loro CRDT — `https://www.loro.dev/`

- Diamond Types — `https://github.com/josephg/diamond-types`

- Liveblocks documentation — `https://liveblocks.io/docs`

- PartyKit documentation — `https://docs.partykit.io/`

- Hocuspocus (TipTap) — `https://tiptap.dev/docs/hocuspocus`

- Replicache — `https://replicache.dev/`

- Zero (Rocicorp) — `https://zero.rocicorp.dev/`

- ElectricSQL — `https://electric-sql.com/`

- PowerSync — `https://www.powersync.com/`

- Convex — `https://docs.convex.dev/`

- Triplit — `https://triplit.dev/`

- Jazz.tools — `https://jazz.tools/`

- InstantDB — `https://www.instantdb.com/`

- Evolu — `https://www.evolu.dev/`

- cr-sqlite (Vlcn) — `https://github.com/vlcn-io/cr-sqlite`

- Ably documentation — `https://ably.com/docs`

- Pusher documentation — `https://pusher.com/docs`

- Soketi — `https://soketi.app/`

- Centrifugo — `https://centrifugal.dev/`

- Supabase Realtime — `https://supabase.com/docs/guides/realtime`

- Colyseus — `https://docs.colyseus.io/`

- Photon Engine — `https://www.photonengine.com/`

- Hathora — `https://hathora.dev/docs`

- tldraw sync — `https://tldraw.dev/docs/sync`

- Excalidraw — `https://github.com/excalidraw/excalidraw`

- VS Code Live Share — `https://visualstudio.microsoft.com/services/live-share/`

- Local-first software (Ink & Switch) — `https://www.inkandswitch.com/local-first/`

- How Figma's multiplayer technology works — `https://www.figma.com/blog/how-figmas-multiplayer-technology-works/`

- Standard Webhooks — `https://www.standardwebhooks.com/`

- WebTransport explainer — `https://web.dev/articles/webtransport`

- WebRTC DataChannel — `https://developer.mozilla.org/en-US/docs/Web/API/RTCDataChannel`

- Toss SLASH conference — `https://toss.tech/slash`

- サイボウズ kintone developer — `https://cybozu.dev/`

- Sansan Tech Blog — `https://buildersbox.corp-sansan.com/`

- Backlog (Nulab) — `https://backlog.com/`