CRDTが切り拓くリアルタイム共同編集の未来——Figma・Notion・Google Docsを支える技術

この記事では、CRDT（Conflict-free Replicated Data Types）の基本概念から実践的な導入方法まで解説します。Figma、Notion、Google Docs等のリアルタイム共同編集技術の仕組みを理解し、実際のプロダクトに適用するための知識を提供します。

はじめに — 読者の痛みを共感し、解決を約束

複数人が同時に編集すると、変更が上書きされたり、競合が発生したりした経験はありませんか？チームでドキュメントを共同編集しているとき、誰かの更新が失われてしまったり、保存したはずの内容が反映されていなかったりといった問題に直面したことがあるはずです。

従来の解決策はどれも不完全でした。中央サーバーを介した同期はネットワーク遅延の影響を受け、ロック機構はユーザー体験を損ないます。手動マージは時間がかかり、オフライン編集は事実上不可能でした。これらの問題は、分散システムにおける根本的な課題に起因しています。

ここで登場するのがCRDT（Conflict-free Replicated Data Types）です。CRDTは、競合解決なしで自動的にデータをマージし、オフライン編集を可能にし、スムーズな同期を実現する分散データ型です。Figma、Notion、Google Docs、Linearといったモダンなコラボレーションツールが採用しているこの技術は、リアルタイム共同編集体験を根本から変革しました。

この記事では、CRDTの基本概念から実践的な導入方法まで、包括的かつ実用的な知識を提供します。エンジニアがCRDTを理解し、実際のプロダクトに適用できるように、数学的基盤から主要ライブラリの比較、実装パターン、パフォーマンス課題とその解決策までを詳しく解説します。

CRDTとは何か？ — 初心者にもわかる説明

CRDT（Conflict-free Replicated Data Types）は、分散システムにおいて複数のレプリカが並列に更新を行っても、競合を自動的に解決して最終的に一貫した状態に収束するデータ構造・アルゴリズムです。

CRDTの定義

CRDTは、「競合解決なし複製データ型」と直訳されます。その名の通り、複数のレプリカが並列に更新しても、競合を手動で解決する必要なく、自動的に最終的に同じ状態に収束するデータ型を指します。

なぜCRDTが必要なのか

分散システムには、ネットワーク分断、遅延、並列更新といった課題が常に存在します。CAP定理に基づくと、システムは可用性（Availability）、一貫性（Consistency）、分断耐性（Partition Tolerance）のうち、2つを同時に満たすことができません。CRDTはAPシステムとして設計され、可用性と分断耐性を優先しつつ、一貫性を最終的整合性（Eventual Consistency）で達成します。

従来の解決策には問題がありました。Operational Transformation（OT）は実装が複雑で、オフライン編集が困難です。ロック機構はユーザー体験を損ない、スケーラビリティも限定的です。CRDTはこれらの問題を根本的に解決します。

CRDTの数学的基盤

CRDTは以下の数学的概念に基づいています：

• 半順序（Partial Order）: 各操作に一意の識別子を付与し、因果関係を表現
• 有向非巡回グラフ（DAG）: 操作の依存関係をグラフとして表現
• 収束性（Convergence）: 任意の2つのレプリカが十分な更新を受け取ると、同じ状態に収束することを数学的に保証
• 可換性（Commutativity）: 操作の適用順序が最終状態に影響しない性質

Mermaid図解: CRDTのマージプロセス

graph LR
    A[Replica A: abc] -->|send update| S((Server))
    B[Replica B: def] -->|send update| S
    S -->|merge| A
    S -->|merge| B
    A -->[after merge] C[State: abcdef]
    B -->[after merge] C
    C -->[convergence] D[Final State: abcdef]

この図は、2つのレプリカが独立して更新を行い、サーバー経由でマージされて最終的に同じ状態に収束するプロセスを示しています。

CRDTの種類

CRDTは主に3種類に分類されます：

• State-based（CvRDT）: 状態全体を交換してマージ
• Operation-based（CmRDT）: 操作のみを伝播
• 混合型: 2つのアプローチを組み合わせて最適化

CRDTの2つのアプローチ — 比較表

State-based CRDT（CvRDT）

定義と仕組み

State-based CRDT（CvRDT、Convergent CRDT）は、レプリカ全体の状態を定期的に交換し、各レプリカが受け取った状態と自らの状態をマージ関数で統合するアプローチです。

長所

• 複製ロバスト: どのレプリカから同期しても最終的に同じ状態に収束
• 配信保証が不要: 操作の正確1回配信を前提としない
• シンプルな実装: マージ関数が可換であれば実装は比較的簡単

短所

• 状態サイズが大きくなる傾向: 特にテキストエディタ等、履歴が蓄積される場合
• ネットワーク帯域の消費が大きい: 状態全体を転送するため
• 初期ロード時間が増加: 完全な状態を読み込む必要がある

代表例

• G-Counter（増分カウンター）
• PN-Counter（増減カウンター）
• LWW-Element-Set（Last-Write-Winsセット）

用途

• ローカルファーストアプリ
• オフライン重視のシナリオ

Operation-based CRDT（CmRDT）

定義と仕組み

Operation-based CRDT（CmRDT、Commutative CRDT）は、操作自体を他のレプリカに伝播するアプローチです。操作が重複なく配信されることを前提（正確1回配信）として設計されています。

長所

• 伝播データが小さい: 操作のみを伝播するため
• ネットワーク帯域の消費が小さい: 状態全体よりもデータ量が少ない
• 最適化技術と相性が良い: デルタ圧縮などの最適化技術が適用可能

短所

• メッセージ配信の信頼性要件が高い: 正確1回配信が必要
• 複雑な実装: 配信保証の実装が必要
• 配信の重複や欠落に対処: メッセージの重複排除や再送メカニズムが必要

代表例

• RGA（Replicated Growable Array）
• LWW-Register（Last-Write-Winsレジスター）

用途

• リアルタイム共同編集
• WebSocket/WebRTCを用いた同期

比較表

混合型アプローチ

多くの実装は2つのアプローチを組み合わせています：

• Yjs: 主に操作ベースだが、スナップショットで状態ベースの利点を活用
• Automerge: 状態ベースを基盤としつつ、デルタ更新で効率化
• Loro: ネットワーク伝播には操作ベース、ロード時にはスナップショット活用

この混合型アプローチにより、各手法の長所を活かしつつ、短所を補完した最適な同期を実現しています。

主要ライブラリ比較（Yjs vs Automerge vs Loro） — 独自比較表

リアルタイム共同編集を実現するために、いくつかの主要なCRDTライブラリが存在します。ここでは、Yjs、Automerge、Loroの3つのライブラリを比較します。

Yjs

特徴

Yjsは最も広く採用されているCRDTライブラリで、週間90万以上のダウンロードを誇ります。操作ベースCRDTで、YATA（Yet Another Transformation Algorithm）を採用しています。豊富なエコシステムを持つのが特徴で、プロバイダやエディタバインディングが充実しています。

サポートするデータ型

• Y.Text（テキスト編集、リッチテキスト対応）
• Y.Array、Y.Map、Y.Set、Y.XmlFragment

長所

• 軽量: gzipped約20KBのバンドルサイズ
• オフライン編集: バージョンスナップショット、Undo/Redoをサポート
• 豊富な採用事例: Linear、Notion、JupyterLab、AppFlowy、Proton Docs等

パフォーマンス（N=6000）

• 文字追加: 188ms
• ドキュメントサイズ: 6,031 bytes
• ランダム位置挿入: 131ms

URL

https://yjs.dev/

Automerge

特徴

AutomergeはInk & Switchによって開発された、学術的検証に基づいた設計のライブラリです。状態ベースCRDTで、アイソトニックマージを採用しています。型安全なAPI（TypeScript/Rust）を提供しています。

サポートするデータ型

• Automerge.Text、Automerge.List、Automerge.Map

長所

• 型安全なAPI: TypeScript/Rustでの型安全性を保証
• バージョン管理システムとの統合: Gitのような履歴管理が容易
• データの不変性と検証可能性: 学術的アプリケーションに適している

パフォーマンス（N=6000）

• 文字追加: 365ms
• ドキュメントサイズ: 3,992 bytes（最もコンパクト）
• 解析時間が長い傾向（初期ドキュメント非空時）

URL

https://automerge.org/

Loro

特徴

Loroは多言語対応（Rust、JavaScript（WASM）、Swift）で、高度な機能セットを提供するモダンなCRDTライブラリです。混合型で、Fugueアルゴリズムを採用しています。

サポートするデータ型

• LoroText（Fugueベース）
• MovableTree、MovableList、LWW-Map
• Rich Text CRDT（ローカルでロックフリー）

長所

• 高速ドキュメントロード: スナップショット活用による高速な初期ロード
• タイムトラベル: 履歴を遡って閲覧
• Gitのようなバージョン管理: リアルタイム編集との統合

パフォーマンス（N=6000）

• 文字追加: 120ms（最速）
• ドキュメントサイズ: 6,162 bytes
• Prepend操作: 81ms（最速）

URL

https://loro.dev/

比較表

選択基準

• Yjs: 軽量でエコシステムが豊富、Webアプリで一般的
• Yrs: 高性能が必要、Rust互換性
• Loro: 高機能、多言語対応、バージョン管理が必要
• Automerge: 学術的検証、型安全、バージョン管理システムとの統合

リアルタイム共同編集のアーキテクチャ — Mermaidフロー図

全体像

graph TB
    subgraph Clients[クライアント]
        A[Client A]
        B[Client B]
        C[Client C]
    end

    subgraph Network[ネットワーク]
        D[WebSocket/WebRTC]
        E[Signaling Server]
    end

    subgraph Server[サーバー]
        F[CRDT Document Store]
        G[Awareness Manager]
    end

    A --> D
    B --> D
    C --> D
    D --> E
    D --> F
    F --> G
    G --> A
    G --> B
    G --> C

クライアント-サーバーモデル（WebSocket）

実装

クライアントはWebSocketで中央サーバーに接続し、サーバーは更新をブロードキャストします。

実装例

• Y-websocket: 単純なインメモリバックエンド
• Hocuspocus: スケーラブルで認証・永続化対応
• Y-hub: 分散型WebSocketバックエンド

長所

• 既存の認証メカニズム（Cookie、Bearer Token）を活用
• 権限管理が容易
• クライアント間の直接通信が不要（NAT越え不要）

短所

• 中央サーバーが必要（単一障害点）
• P2P機能に比べて遅延が大きい可能性

P2Pモデル（WebRTC）

実装

シグナリングサーバー経由でピア接続を確立し、データはピア間で直接交換します。

実装例

• Y-webrtc: シグナリングサーバー付きP2P同期
• Matrix-CRDT: Matrixプロトコルをバックエンドとして使用

長所

• 低遅延（サーバーを経由しない）
• エンドツーエンド暗号化が容易
• サーバー負荷が低い

短所

• NAT越えの問題（STUN/TURNサーバーが必要）
• ピア数が多い場合のスケーラビリティ課題

混合アプローチ

WebSocket + WebRTC

• WebSocketをシグナリングと初期同期に使用
• WebRTCで直接通信

デバイス間同期

• 同一ブラウザのタブ間: BroadcastChannel API
• オフライン→オンライン: IndexedDBから同期

マネージドサービス

• Liveblocks Yjs: 完全ホスト型WebSocketインフラ
• Velt Yjs: マネージドYjsバックエンド
• PartyKit: マルチプレイヤーアプリ向けクラウド

同期プロトコルの例（Y-websocket）

1. 初期接続:
   • クライアントがWebSocket接続を確立
   • サーバーから現在のドキュメント状態を受信
2. 更新伝播:
   • クライアントがローカルで変更を適用
   • 更新をWebSocketでサーバーに送信
   • サーバーが他のクライアントにブロードキャスト
3. 認識情報:
   • カーソル位置、選択範囲を同期的に共有
   • ステータス（接続、編集中等）を通知
4. 再接続:
   • 指数バックオフで再接続試行
   • 未送信の更新を保持

実践：Yjsではじめる共同編集 — ステップバイステップのコード例

ここでは、Yjsを使って実際にリアルタイム共同編集を実現するためのステップバイステップガイドを提供します。

Step 1: インストール

まず、必要なパッケージをインストールします。

npm install yjs y-websocket

Step 2: 基本的なセットアップ

基本的なYjsドキュメントとWebSocketプロバイダを設定します。

import * as Y from 'yjs'
import { WebsocketProvider } from 'y-websocket'

// ドキュメントの作成
const doc = new Y.Doc()

// WebSocketプロバイダの作成
const wsProvider = new WebsocketProvider(
  'ws://localhost:1234',
  'my-roomname',
  doc
)

// テキストオブジェクトの取得
const ytext = doc.getText('my-text')

// 変更の監視
ytext.observe((event, transaction) => {
  console.log('Text changed:', ytext.toString())
})

// テキストの挿入
ytext.insert(0, 'Hello, World!')

このコードは、Yjsドキュメントを作成し、WebSocketプロバイダを通して他のクライアントと同期します。テキストオブジェクトの変更を監視し、変更が発生するとログに出力します。

Step 3: リッチテキストエディタとの統合

Quillのようなリッチテキストエディタと統合する例です。

import * as Y from 'yjs'
import { WebsocketProvider } from 'y-websocket'
import { QuillBinding } from 'y-quill'
import Quill from 'quill'

const doc = new Y.Doc()
const ytext = doc.getText('quill')
const wsProvider = new WebsocketProvider(
  'ws://localhost:1234',
  'my-roomname',
  doc
)

const editorContainer = document.createElement('div')
document.body.appendChild(editorContainer)

const editor = new Quill(editorContainer)
const binding = new QuillBinding(ytext, editor, wsProvider.awareness)

このコードは、YjsのテキストオブジェクトをQuillエディタとバインドし、リアルタイム共同編集を可能にします。

Step 4: オフライン編集のサポート

IndexedDBを使用してオフライン編集をサポートします。

import * as Y from 'yjs'
import { WebsocketProvider } from 'y-websocket'
import { IndexeddbPersistence } from 'y-indexeddb'

const doc = new Y.Doc()
const ytext = doc.getText('my-text')

// IndexedDBへの永続化
const idbProvider = new IndexeddbPersistence('my-roomname', doc)

// WebSocketプロバイダ
const wsProvider = new WebsocketProvider(
  'ws://localhost:1234',
  'my-roomname',
  doc
)

// オフラインからの同期を監視
idbProvider.whenSynced.then(() => {
  console.log('Loaded from IndexedDB')
})

このコードは、ドキュメントをIndexedDBに永続化し、オフライン中に編集された内容をオンライン復帰時に自動的に同期します。

Step 5: カーソル位置の共有

他のユーザーのカーソル位置やステータスを共有します。

import { Awareness } from 'y-protocols/awareness'

const awareness = wsProvider.awareness

// ユーザーの状態を設定
awareness.setLocalStateField('user', {
  name: 'Alice',
  color: '#ff0000'
})

// 他のユーザーの状態を監視
awareness.on('change', () => {
  const states = awareness.getStates()
  states.forEach((state, clientID) => {
    if (state.user) {
      console.log(`User ${state.user.name} is connected`)
    }
  })
})

このコードは、現在のユーザーの名前と色を設定し、他のユーザーの接続状態を監視します。

Step 6: Undo/Redo

Undo/Redo機能を実装します。

import { YUndoManager } from 'yjs/y-undomanager'

const undoManager = new YUndoManager([ytext])

// Undo
undoManager.undo()

// Redo
undoManager.redo()

このコードは、YUndoManagerを使用してUndo/Redo機能を実装します。

実際のプロダクト事例（Figma, Notion等）

Figma

実装

Figmaは独自の分散アーキテクチャを採用しています（公式情報は非公開）。

特徴

• マルチプレイヤー機能でリアルタイム同期
• オフライン編集をサポート
• Canvas上の図形、テキスト、画像等の複雑なオブジェクト管理
• Vector、Layer、Componentの階層構造を同期

推測される技術

• CRDTまたは類似の競合解決アルゴリズム
• WebSocket/WebRTCベースの通信
• 楽観的UI更新（ローカル即時反映）

URL

https://www.figma.com/

Notion

実装

NotionはYjsをベースにした共同編集を採用しています（非公式情報、業界レポート等から推測）。

特徴

• ブロックベースのエディタ（Blockを採用）
• リッチテキスト、チェックボックス、画像、コード等の多様な要素
• 関連ページ、コメント、タグ等のメタデータ同期

アーキテクチャ

• Yjs.TextまたはY.XmlFragmentをリッチテキストに適用
• Y.Arrayでブロック構造を管理
• WebSocketバックエンド（自社またはY-websocket互換）

URL

https://www.notion.so/

Google Docs

実装

Google DocsはOperational Transformation（OT）からCRDTへの移行が報じられています。

歴史

• 初期: OT（Operational Transformation）ベース
• 近年: CRDTまたはハイブリッドアプローチにシフト（業界レポート等）

特徴

• コメント、提案モード、履歴
• 複数のファイル形式（ドキュメント、スプレッドシート、スライド）
• 高度なテキスト整形機能

アーキテクチャ

• 推定: RGA（Replicated Growable Array）またはLWW（Last-Write-Wins）ベースのCRDT
• WebSocketを用いたリアルタイム同期
• クライアントサイドで競合解決

URL

https://docs.google.com/

その他の採用事例

• Linear: プロジェクト管理ツール、Yjsを採用
• JupyterLab: 共同編集ノートブック、Yjsを採用
• AppFlowy: Notionのオープンソース代替、Yjsを採用
• Proton Docs: エンドツーエンド暗号化された共同ドキュメント、Yjsを採用

パフォーマンス課題と解決策

CRDTにはいくつかのパフォーマンス上の課題がありますが、それぞれに対する解決策も存在します。

ドキュメントサイズ肥大化

原因

各操作が一意の識別子とメタデータを持つため、履歴が蓄積されます。削除されたデータも履歴として保持されるため（再挿入やUndo/Redoのために）、ドキュメントサイズが肥大化します。

影響

• 初期ロード時間が増加
• ネットワーク転送量が増加

解決策

• デルタ圧縮: 差分のみを伝播（Loro、Yrs）
• スナップショット: 定期的な完全状態スナップショットを作成し、履歴を圧縮
• ガベージコレクション: 一定時間経過した操作のメタデータを削除
• Shallow Snapshot: 最近の履歴のみを保持（Loro）

メモリ使用量

原因

完全な履歴をメモリに保持するため、複雑なデータ構造（ツリー、リッチテキスト）でメモリ使用量が増加します。

影響

• ブラウザのメモリ制限を超える可能性
• パフォーマンス低下

解決策

• 遅延ロード: 必要な部分のみをメモリにロード
• 永続化: IndexedDBやLocalStorageに履歴を保存
• WASM化: 高効率なメモリ管理（Yrs、Automerge）

GC（ガベージコレクション）の複雑さ

課題

どの操作を削除しても安全か判断が困難です。他のレプリカが参照している可能性があるため、慎重な設計が必要です。

解決策

• 参照カウント: 各操作の参照を追跡
• バージョンベースGC: 特定のバージョン以降の履歴のみを保持
• プルーニング: 定期的に不要な操作を削除

パフォーマンスベンチマークの傾向

Yjs vs Loro vs Automerge（N=6000）

ネットワーク帯域

• 操作ベースの方が状態ベースよりデータ量が小さい傾向
• デルタ圧縮でさらに削減可能

Local-Firstソフトウェアの未来

Local-Firstの理念

定義

Local-Firstソフトウェアは、ユーザーがデータを所有し、ローカルで編集が可能なソフトウェアです。

原則

• データはクラウドではなくユーザーのデバイスに保存
• オフラインでも機能が動作
• プライバシーとセキュリティを重視

Ink & Switchの提唱

Ink & Switchは2019年に「Local-first software: You own your data, in spite of the cloud」というエッセイでLocal-Firstの理念を提唱しました。CRDTはLocal-First実現の技術基盤として重要です。

CRDTとLocal-Firstの統合

オフライン編集

各デバイスが独立して更新可能で、ネットワーク接続時に自動同期します。

プライバシー

エンドツーエンド暗号化が可能で、データはローカルに保持されます。

バージョン管理

Gitのような履歴管理とリアルタイム編集の統合（Loro）、タイムトラベル機能（Loro、Automerge）が可能です。

Local-Firstアプリの例

• AFFiNE: プライバシー優先のオープンソースナレッジベース
• AppFlowy: Notionのオープンソース代替
• Automerge: Local-Firstアプリ構築用ライブラリ
• Loro: バージョン管理とリアルタイム編集の統合

Local-Firstの利点

1. ユーザーによるデータ制御: クラウドプロバイダーへの依存を減少
2. オフライン機能: 接続状況に関わらず編集可能
3. 速度: ローカル操作はクラウドより高速
4. セキュリティ: エンドツーエンド暗号化が容易

課題

• 同期の複雑さ: CRDTの実装とデバッグが困難
• ストレージ: ローカルデバイスの容量制限
• ユーザー体験: 同期ステータスの表示、競合解決の可視化

よくある質問（FAQ） — AI検索対策

Q: CRDTとOperational Transformation（OT）の違いは何ですか？

A: CRDTは競合解決を自動的に行い、オフライン編集が容易です。OTは操作の変換が必要で、オフライン編集が困難かつ実装が複雑です。オフライン編集が必要ならCRDT、シンプルな同期ならOTが適しています。

Q: YjsとAutomerge、どちらを選ぶべきですか？

A: Yjsは軽量でエコシステムが豊富で、Webアプリで一般的です。Automergeは学術的検証、型安全、バージョン管理システムとの統合が可能です。WebアプリならYjs、バージョン管理が必要ならAutomergeが適しています。

Q: オフライン編集はどのように実現されていますか？

A: ローカルデータベース（IndexedDB、LocalStorage）に永続化し、オフライン中に更新をローカルで適用します。オンライン復帰時に自動同期します。

Q: ドキュメントサイズの肥大化はどう対処しますか？

A: デルタ圧縮、定期的なスナップショット、ガベージコレクション、Shallow Snapshot（Loro）などの手法で対処します。

Q: 複数のデバイス間でどのように同期されますか？

A: WebSocket（クライアント-サーバーモデル）、WebRTC（P2Pモデル）、または混合（WebSocketでシグナリング、WebRTCで直接通信）を使用します。

Q: CRDTはどんなアプリケーションに適していますか？

A: リアルタイム共同編集（Google Docs、Notion、Figma）、ローカルファーストアプリ（AFFiNE、AppFlowy）、分散システム（Matrix、nostr-crdt）、コラボレーティブIDE（JupyterLab、Eclipse Theia）などに適しています。

Q: CRDTの学習コストは高いですか？

A: 基本的な概念はシンプルですが、実装とデバッグは複雑です。ライブラリ（Yjs、Automerge、Loro）を活用すれば学習コストを低減可能です。

Q: CRDTはセキュリティに配慮されていますか？

A: エンドツーエンド暗号化が可能（secsync、Matrix-CRDT）、Fine-grained access control（Keyhive）、プライバシー優先のLocal-Firstアプリと相性が良いです。

Q: CRDTのパフォーマンスはどの程度ですか？

A: N=6000の文字追加で120-365ms、ドキュメントサイズは数千バイト〜数万バイト、実世界の編集データセットで数秒〜数十秒です。ライブラリとシナリオに依存します。

Q: CRDTの今後の展望は？

A: マルチプラットフォーム対応（Rust、WASM、Swift）、高度な機能（タイムトラベル、バージョン管理）、パフォーマンス最適化（デルタ圧縮、GC）、産業への普及（プロダクト標準化、エコシステム成熟）が期待されています。

まとめ — 次のアクション

まとめ

• CRDTはリアルタイム共同編集の基盤技術: 競合解決なしで自動マージ、オフライン編集、スムーズな同期を実現します。
• 主要なライブラリ: Yjs（軽量・エコシステム豊富）、Automerge（学術的検証・型安全）、Loro（高機能・多言語対応）などが存在します。
• 実装パターン: WebSocket（クライアント-サーバー）、WebRTC（P2P）、混合（シグナリング+直接通信）のアプローチがあります。
• 課題と解決策: ドキュメントサイズ肥大化（デルタ圧縮、スナップショット）、メモリ使用量（遅延ロード、WASM化）、GC（参照カウント、バージョンベース）などの課題と解決策があります。
• Local-Firstの未来: ユーザーによるデータ制御、オフライン機能、プライバシーとセキュリティが実現されます。

次のアクション

1. Yjsを試す:
   • https://yjs.dev/docs/getting-started
   • デモ: https://demos.yjs.dev/
2. Automergeを試す:
   • https://automerge.org/docs/
   • GitHub: https://github.com/automerge/automerge
3. Loroを試す:
   • https://loro.dev/docs/tutorial/get_started
   • GitHub: https://github.com/loro-dev/loro
4. Local-Firstを学ぶ:
   • Ink & Switch: https://www.inkandswitch.com/local-first/
   • Local-First Conf: https://www.localfirstconf.com/
5. コミュニティに参加する:
   • Yjs Discord: https://discord.gg/T3nqMT6qbM
   • Loro Discord: https://discord.gg/tUsBSVfqzf
6. アプリケーションを構築する:
   • リアルタイム共同編集機能を追加
   • オフライン編集を実現
   • Local-Firstアプリを開発

関連記事

• 基盤モデルのためのゲーム理論：類似性推論が切り拓く合理的協調への新たな道