Liveblocks、リアルタイム共同編集を開発者向けAPIへ分解した設計

Liveblocksは2021年にローンチしたが、物語の出発点はその数年前にGuillaume SallesとSteven Fabreが出会った時にさかのぼる。出典

創業のきっかけ

二人が向き合ったのは、共同編集やリアルタイム状態を一から作ると、プロダクトチームが本来の体験設計に集中できないという問題だった。

Steven Fabreは「Webをもっとcollaborativeにしたい」という方向性を掲げている。出典

転機と苦労

リアルタイム機能は、接続状態、権限、競合解決、通知を同時に扱う必要がある。

LiveblocksはそれらをSDKとサービスとして切り出し、導入の複雑さを下げた。出典

成長と成功

共同編集だけでなく、コメント、presence、通知、AIとの協働へと対象を広げた。

Liveblocks 3.0は人とAIが同じアプリで働く方向を明示している。出典

現在

Liveblocksの示唆は、難しい分散システムをAPIに隠し、プロダクトチームがユーザー体験へ投資できる余白を作ることにある。

Liveblocksは、共同編集・コメント・presenceを実装したいプロダクトチームに刺さる。

同期、権限、オフライン復帰を個別に作る痛みをSDKへ移せるためだ。出典

特にデザインツール、ドキュメント、AIアプリでは共同作業が価値そのものになる。

機能単体ではなく、導入速度と信頼性を買う市場だと考えられる。

同期・権限・共同編集を本番品質で運用する知見とSDKの蓄積が参入障壁になる。

弱い。

利用者が増えるほど同一文書の協働価値は上がるが、サービス全体のネットワーク効果よりプロダクト内の協働効果が中心だ。

共同編集、コメント、presence、AI collaborationを必要とするSaaSのプロダクト・エンジニアリングチーム向け。

単独ユーザー向けの単純なフォームには向かない。

難しいrealtime基盤をAPIとして切り出したこと、Reactなど既存stackへ組み込みやすいこと、コメントやAIへ拡張したことが要因だ。出典

開発者向けdocsと無料枠を入口にし、利用が深くなったチームへ有料プランを提案できる。

realtimeは接続品質、権限、競合解決の失敗がそのままUXの不信につながる。

利用量増加に伴うコストとベンダーロックインも検討課題だ。出典

また、単純なCRUDアプリには過剰で、導入価値が出るユースケースを見極める必要がある。

無料枠とdocsで開発者を獲得し、プロトタイプから本番へ移る段階で有料化する。

GitHubや技術コンテンツは比較検討の早い開発者に届く。出典

AI協働を追加することで、新しいアプリカテゴリにも接点を作る一方、基盤の信頼性との両立が必要になる。

主要チャネル: content, github, developerCommunity, sales

難しいインフラを抽象化するだけでは足りず、導入後のプロダクト体験まで見えるAPIが必要だ。

無料枠は試用を促し、docsは営業資料としても機能する。

日本では社内文書、設計レビュー、顧客との共同作業など、権限管理が重要な場面から導入しやすい。

AI導入では人の承認と監査ログを最初から設計すると、単なるチャットとの差別化になる。