WordPressの共同編集、3つの同期エンジンを比較

WordPressのコア開発チームは2026年10月14日、複数人で同時に投稿を編集する「リアルタイム共同編集（RTC）」の土台となる3つの同期エンジンを、テスターに向けて紹介する記事を公開しました。どれを採用するかはまだ決まっておらず、実験用プラグインで実際に触って感想を寄せてほしい、という呼びかけです。方式ごとに「速さ」「競合の扱い」「外部ツールとの相性」が大きく違うので、プラグインやWP-CLIでコンテンツを書き換える開発者には、他人事ではありません。

ブラウザだけの統合が抱えるセキュリティの穴
yjs-server、DE-RTC、intent-logを比べる
通信方式の選択肢と、ホスティングの制約
試す前に確認したい要件と設定
出典

ブラウザだけの統合が抱えるセキュリティの穴

背景には、9月18日にMake WordPress Coreで公開された方針転換の記事があります。現在のGutenbergのRTC実験は、編集内容の統合をブラウザだけで行います。各ブラウザが投稿のコピーを持ち、変更はCRDT（競合が起きないよう設計されたデータ構造）で同期され、保存されるまでブラウザのメモリ上にしか存在しません。この記事は、その方式ではサーバーが「誰が何を書いたか」を判断できないと指摘しています。

例として挙げられているのが、コンテンツの「洗浄」です。生のHTMLを入れる権限のない投稿者がscriptタグを含むブロックを追加し、それが管理者のエディターに同期されます。管理者が別の箇所の誤字を直して保存すると、投稿は管理者の権限で更新されてしまい、セキュリティのチェックをすり抜けるおそれがある、という説明です。そこで、WordPress本体（サーバー）を同期の中心に置く「server-aware」な共同編集へ向かう、というのが同記事の提案です。

yjs-server、DE-RTC、intent-logを比べる

10月14日の記事では、実験プラグイン「gutenberg-sync-engines」に入っている3つのエンジンが、次のように整理されています。

yjs-server：ブラウザがYjsで変更を統合し、バイナリの更新をサーバーへ送ります。サーバーは検証してから他の参加者に配ります。更新が速く、Google Docsのようなカーソル表示ができ、マージの競合も起きません。一方で、2人が同じブロックの設定を同時に変えると警告なしに片方が優先され、同じ文を同時に書き換えると誰も書いていない混ざった結果になり得ます。しかも、その場合に誰にも警告が出ません。ブラウザ側（JS）とサーバー側（PHP）で同じ実装を保つ必要もあります。
DE-RTC（Distributed Editing）：WordPressの通常の保存に近い方式です。既定では10秒ごとに投稿全体を自動保存の仕組みで送り、サーバーが、開始時点の版、自分の更新版、サーバー上の現在の版の3つを使って統合します。重ならない変更は自動でまとまり、競合したブロックは確認待ちに回されます。リアルタイムではなく、更新の間隔でしか他人の変更が見えません。ただし、プラグインやスクリプト、WP-CLIのコマンドのような外部ツールも、元の版を指定すれば参加でき、安価なホスティングにも向くとされています。
intent-log：ブラウザが「ブロック1を20文字目で分割した」のような、ブロック単位の操作の記述を送り、サーバーがログを管理して、操作変換（operational transform、OT）で同時の操作をまとめます。ブロックの移動なども意味を保ったまま扱え、人が読める履歴も残ります。弱点は、1つの投稿につき一度に1件の更新しか処理できない点、OTの実装が難しい点、JSとPHPの二重実装が必要な点です。

記事の比較表では、更新の速さはyjs-serverとintent-logが「速い」、DE-RTCは「速くない」、同時に衝突した場合の扱いはyjs-serverが「黙って統合（片方が勝つ）」、DE-RTCとintent-logが「確認待ち」、サーバーの処理量はintent-logが最も少なく、yjs-serverは投稿が大きくなるほど増えるとされています。

通信方式の選択肢と、ホスティングの制約

エンジンとは別に、変更を運ぶ「トランスポート」も用意されています。ポーリング（既定は5秒で、1〜25秒で調整可能）、WebRTCの補助チャネル付きポーリング、Server-sent events（SSE）、別プロセスで動かすSSE、WebSocketの5種類です。SSEやWebSocketは、長時間の接続を許すホスティングや、別プロセスを動かせるサーバーが必要です。別プロセスのサービスなどが応答しなくなっても、ポーリングがいつでも代わりになる設計だと説明されています。

記事のコメント欄には、共有ホスティングの多くはSSEもWebSocketも使えないため、どのエンジンが選ばれても、一般的なサイトはポーリングになるのではないか、という指摘も出ています（この投稿者は、関連サービスを運営していると明記しています）。

試す前に確認したい要件と設定

試すための要件は、WordPress 7.0以上と、在席を管理するPresence APIプラグインです。プラグインは、同期エンジンを入れ替えられるように修正したGutenbergのコピーを内蔵しているため、ほかのGutenbergプラグインを有効にしたままでは動きません。エンジンとトランスポートは、設定の「Collaboration」から選びます。記事は、3つのエンジンすべてに磨き込みが必要で、バグもあり得るとしたうえで、設計の大きな違いが作業にどう影響するかについての意見を特に求めています。意見はGitHubのissueか、WordPress Slackの#feature-realtime-collaborationに送ります。

個人的には、速さを取るか、外部ツールとの連携を取るかが分かれ目だと思います。記事の比較表では、yjs-serverは外部ツールの変更がライブの編集セッションと統合されないため、WP-CLIやバッチで本文を書き換えるサイトは注意が必要です。一方、DE-RTCとintent-logは、元の版を指定すれば外部ツールも参加できる設計です。どちらかが採用されれば、自作ツールに版の指定を加える対応が要るかもしれません。同じ投稿を複数人が同時に編集する媒体では、yjs-serverで片方の変更が警告なしに失われないか、事前に試しておきたいところです。