業務変革

オペレーショナルトランスフォーメーション（OT ）は、高度なコラボレーションソフトウェアシステムにおけるさまざまなコラボレーション機能をサポートするためのテクノロジーです。OTはもともと、プレーンテキスト文書の共同編集における一貫性の維持と同時実行の制御のために発明されました。その機能は拡張され、その用途は、グループの元に戻す、ロック、競合解決、操作の通知と圧縮、グループ認識、HTML/XMLおよびツリー構造の文書編集、共同オフィス生産性ツール、アプリケーション共有、共同コンピュータ支援メディア設計ツールを含むように拡大されました。^{[1] 2009年にOTは、} Apache WaveとGoogle Docsのコラボレーション機能のコア技術として採用されました。

操作変換は、 1989年にC. EllisとS. Gibbs ^[2]によってGROVE（GRoup Outline Viewing Edit）システムで初めて導入されました。数年後、いくつかの正確性の問題が特定され、これらの問題を解決するためのいくつかのアプローチ^{[3] [4] [5] [6]}が独立して提案され、その後10年間、熱心な研究者のコミュニティによってOTの拡張と改善の継続的な取り組みが続きました。1998年には、CEとOTの研究者間のコミュニケーションとコラボレーションを促進するために、共同編集に関する特別興味グループ^[7]が設立されました。それ以来、SIGCEは、ACM、CSCW、GROUP、ECSCWなどの主要なCSCW（Computer Supported Cooperative Work）会議と連携して、毎年CEワークショップを開催しています。

操作変換を利用するコラボレーション システムでは通常、複製されたドキュメント ストレージが使用されます。このストレージでは、各クライアントが独自のドキュメントのコピーを持ちます。クライアントは、ロックフリーでブロッキングのない方法でローカル コピーを操作し、変更は残りのクライアントに伝播されます。これにより、インターネットなどの高遅延環境でもクライアントの高い応答性が確保されます。クライアントは、別のクライアントから伝播された変更を受信すると、通常、変更を実行する前に変換します。この変換により、アプリケーションに依存する一貫性基準 (不変条件) がすべてのサイトで維持されます。この操作モードにより、 Webなどの高遅延環境での同時ドキュメント編集などのコラボレーション機能を実装するのに特に適したシステムになります。

OT の基本的な考え方は、次のような単純なテキスト編集シナリオを使用して説明できます。2 つの共同サイトで複製された文字列「abc」を含むテキスト ドキュメントと、2 つの同時操作があるとします。

1. O1 = Insert[0, "x"] (位置 "0" に文字 "x" を挿入する)
2. O2 = Delete[2, "c"] (位置 "2" の文字 "c" を削除する)

2 人のユーザーがそれぞれ共同サイト 1 と 2 で生成した OT です。2 つの操作が O1 と O2 (サイト 1) の順序で実行されるものとします。O1 の実行後、ドキュメントは "xabc" になります。O1 の後に O2 を実行するには、O2 を O1 に対して変換して、O2' = Delete[3, "c"] にする必要があります。この位置パラメータは、O1 によって 1 文字 "x" が挿入されたため 1 増加します。"xabc" に対して O2' を実行すると、正しい文字 "c" が削除され、ドキュメントは "xab" になります。ただし、O2 を変換せずに実行すると、文字 "c" ではなく "b" が誤って削除されます。OT の基本的な考え方は、以前に実行された同時操作の効果に応じて編集操作のパラメータを変換 (または調整) し、変換された操作が正しい効果を達成してドキュメントの一貫性を維持できるようにすることです。

OT の機能の 1 つは、共同編集システムにおける一貫性の維持をサポートすることです。研究コミュニティでは、共同編集システム全般を対象としたものや、OT アルゴリズムに特化したものなど、さまざまな一貫性モデルが提案されています。

エリスとギブスの1989年の論文「グループウェアシステムにおける並行処理制御」^[2]では、共同編集システムには2つの一貫性特性が必要であるとされています。

• 因果関係の保持: コラボレーションのプロセス中に、因果的に依存する操作の実行順序が自然な因果関係と同じであることを保証します。 2 つの操作間の因果関係は、Lamport の「以前に起こった」関係によって正式に定義されます。 2 つの操作が因果的に依存していない場合、それらは同時実行されています。 2 つの同時実行操作は、2 つの異なるドキュメント コピーに対して異なる順序で実行できます。
• 収束: 静止時に共有ドキュメントの複製コピーがすべてのサイトで同一であることを保証します (つまり、生成されたすべての操作がすべてのサイトで実行されている)。

同時操作は異なる順序で実行される可能性があり、編集操作は一般に可換ではないため、異なるサイトにあるドキュメントのコピーは発散（不一致）する可能性があります。最初のOTアルゴリズムは、グループテキストエディタで収束を実現するためにEllisとGibbsの論文^[2]で提案されました。状態ベクトル（または従来の分散コンピューティングのベクトルクロック）を使用して、優先順位プロパティが保持されました。

CCIモデルは、共同編集システムにおける一貫性管理として提案されました。^{[4] [8]} CCIモデルでは、3つの一貫性プロパティがグループ化されています。

• 因果律の保存: CC モデルの場合と同じです。
• 収束: CC モデルの場合と同じです。
• 意図の保存: 任意のドキュメント状態に対する操作の実行の効果が、操作の意図と同じであることを保証します。操作 O の意図は、O が生成されたドキュメント状態に O を適用することによって達成できる実行効果として定義されます。

CCI モデルは、意図の保存という新しい基準で CC モデルを拡張します。収束と意図の保存の本質的な違いは、前者はシリアル化プロトコルによって常に達成できますが、後者は操作が常に元の形式で実行された場合、どのシリアル化プロトコルでも達成できない可能性があるということです。シリアル化できない意図の保存プロパティを実現することは、大きな技術的課題でした。OT は、共同編集システムで収束と意図の保存を実現するのに特に適していることがわかりました。

CCI モデルは、ドキュメントの種類やデータ モデル、操作の種類、またはサポート技術 (OT、マルチバージョン管理、シリアル化、元に戻す/やり直し) に依存しません。特定のデータおよび操作モデルや特定のアプリケーション向けに設計された技術 (OT など) の正確性検証を目的としたものではありません。^[4]では、意図の保持の概念が 3 つのレベルで定義および改良されました。まず、共同編集システムの一般的な一貫性要件として定義されました。次に、一般的な OT 機能の操作コンテキスト ベースの変換前および変換後の条件として定義されました。最後に、共同プレーン テキスト エディターでの 2 つの基本操作 (文字列の挿入と削除) に対する OT 機能の設計をガイドする特定の操作検証基準として定義されました。

意図保存の条件は、形式的証明の目的でCCIモデルでは正式に指定されていませんでした。SDT ^[9]とLBT ^[10]のアプローチは、証明可能な代替条件を形式化しようとしています。これら2つのアプローチで提案されている一貫性モデルは、次の形式条件で構成されています。

• 因果関係: CCモデルと同じ定義
• 単一操作効果: 任意の実行状態で任意の操作を実行すると、その生成状態と同じ効果が得られます。
• 複数操作の効果: 任意の2つの操作の効果関係は、両方の操作が任意の状態で実行された後も維持されます。

上記の CSM モデルでは、システム内のすべてのオブジェクトの全順序を指定する必要があります。実質的に、指定は挿入操作によって導入される新しいオブジェクトに限定されます。ただし、全順序の指定には、挿入の同点 (つまり、2 つの現在の操作によって同じ位置に挿入される新しいオブジェクト) を解消するなどのアプリケーション固有のポリシーが必要です。その結果、全順序はアプリケーション固有のものになります。さらに、アルゴリズムでは、変換関数と制御手順で全順序を維持する必要があり、アルゴリズムの時間/空間の複雑さが増します。

一方、CAモデルは許容性理論に基づいています。^[11] CAモデルには2つの側面があります。

• 因果関係: CCモデルと同じ定義
• 許容性: すべての操作の呼び出しは、その実行状態で許容されます。つまり、すべての呼び出しは、以前の呼び出しによって確立された効果関係 (オブジェクトの順序) に違反してはなりません。

これら 2 つの条件は収束を意味します。すべての協力サイトは、同じ順序の同じオブジェクト セットがある状態に収束します。さらに、順序は、操作が生成されたときの効果によって効果的に決定されます。2 つの条件はオブジェクトの順序に追加の制約も課すため、実際には収束よりも強力です。CA モデルと設計/証明アプローチは、2005 年の論文で詳しく説明されています。^[11]オブジェクトの全体的な順序を一貫性モデルで指定してアルゴリズムで維持する必要がなくなり、アルゴリズムの時間/空間の複雑さが軽減されます。

OTは複数のコンポーネントからなるシステムです。OTシステムを設計するための確立された戦略の1つ^{[2] [3] [4] [5] [12] [13]}は、高レベルの変換制御（または統合）アルゴリズムを低レベルの変換機能から分離することです。

変換制御アルゴリズムは、次の事項を決定することに関係しています。

1. 因果的に準備された新しい操作に対してどの操作を変換する必要があるか
2. 変換の順序

制御アルゴリズムは、対応する変換関数のセットを呼び出します。これらの関数は、操作の種類、位置、およびその他のパラメータに従って、ある操作を別の操作に変換する方法を決定します。これらの 2 つの層の正確さの責任は、一連の変換プロパティと条件によって正式に指定されます。制御アルゴリズム、機能、および通信トポロジが異なる OT システムでは、異なる変換プロパティのセットを維持する必要があります。OT システムをこれらの 2 つの層に分離することで、異なるデータおよび操作モデルを持つさまざまな種類のアプリケーションに適用できる汎用的な制御アルゴリズムを設計できます。

もう一つの代替アプローチは^[11]で提案されました。彼らのアプローチでは、OTアルゴリズムは2つの形式化された正しさの基準を満たしていれば正しいとされます。

1. 因果関係の保存
2. 許容性の維持

これら 2 つの基準が満たされている限り、すべてのサイトですべての操作が実行された後、データ レプリカは (追加の制約付きで) 収束します。収束を達成するために、実行の全体的な順序を強制する必要はありません。彼らのアプローチは、一般的に、まずいくつかの変換関数の十分な条件を特定して証明し、次にそれらの十分な条件を保証する制御手順を設計することです。このようにして、制御手順と変換関数は相乗的に機能して、正確性、つまり因果関係と許容性の維持を実現します。彼らのアプローチでは、TP2 などの変換プロパティを満たす必要はありません。なぜなら、(包括的な) 変換関数がすべての可能なケースで機能する必要がないからです。

各 OT システムには、2 つの基本モデルが存在します。ドキュメント内のデータ オブジェクトを操作でアドレス指定する方法を定義するデータ モデルと、OT 関数によって直接変換できる操作のセットを定義する操作モデルです。異なる OT システムには、異なるデータ モデルと操作モデルがある場合があります。たとえば、最初の OT システム^[2]のデータ モデルは単一の線形アドレス空間であり、その操作モデルは、文字単位の挿入と削除という 2 つの基本操作で構成されています。基本操作モデルは、共同 Word ドキュメント処理^[14]と 3D モデル編集^[15]をサポートするために、3 番目の基本操作更新を含むように拡張されました。基本的な OT データ モデルは、複数の線形アドレス指定ドメインの階層に拡張され、^{[16] [17] [18]}、幅広いドキュメントをモデル化できます。アプリケーション固有のデータ モデルを OT 準拠のデータ モデルにマッピングするには、多くの場合、データ適応プロセスが必要です。^{[19] [20]}

OT システムでアプリケーション レベルの操作をサポートするには、次の 2 つのアプローチがあります。

1. 汎用操作モデルアプローチ：挿入、削除、更新という3つの基本操作の変換関数を考案する。^[19]このアプローチでは、アプリケーション操作をこれらの基本操作にマッピングするための操作適応プロセスが必要です。このアプローチでは、OT操作モデルは汎用的であるため、変換関数をさまざまなアプリケーションで再利用できます。
2. アプリケーション固有の操作モデルアプローチ：アプリケーション操作の各ペアに対して変換関数を考案する。^{[20] [21]} m個の異なる操作を持つアプリケーションの場合、このアプリケーションをサポートするにはmxmの変換関数が必要である。このアプローチでは、変換関数はアプリケーション固有であり、異なるアプリケーションで再利用することはできない。

さまざまな OT 機能が、さまざまな機能を持つ OT システム向けに設計され、さまざまなアプリケーションで使用されています。さまざまな OT システムで使用される OT 機能は、名前が異なる場合がありますが、次の 2 つのカテゴリに分類できます。

• 包含変換（または順方向変換）：IT(Oa, Ob) または、これは操作 Oa を別の操作 Ob に対して変換し、Ob の影響が効果的に含まれるようにします。これは、たとえば、異なるノードでの 2 つの挿入の場合です。${\displaystyle T(op_{1},op_{2})}$
• 排他変換（または逆変換）：ET（Oa、Ob）または、これは操作Oaを別の操作Obに対して変換し、Obの影響が効果的に排除されるようにする。これは、たとえば、異なるノードでの挿入と削除の場合である^[22]${\displaystyle T^{-1}(op_{1},op_{2})}$

例えば、操作ins(p, c, sid)を持つString型を考えます。ここでpは挿入位置、cは挿入する文字、sidは操作を生成したサイトの識別子です。次の包含変換関数を書くことができます。^[23]

T(ins( ),ins( )):-${\displaystyle p_{1},c_{1},sid_{1}}$${\displaystyle p_{2},c_{2},sid_{2}}$
 if ( ) は ins( )を返します${\displaystyle p_{1}<p_{2}}$${\displaystyle p_{1},c_{1},sid_{1}}$
 そうでない場合は、(かつ) は ins( )を返します。${\displaystyle p_{1}=p_{2}}$${\displaystyle sid_{1}<sid_{2}}$${\displaystyle p_{1},c_{1},sid_{1}}$
 それ以外の場合は ins( )
を返す${\displaystyle p_{1}+1,c_{1},sid_{1}}$

次のような排他変換関数を書くこともできる: ^[23]

${\displaystyle T^{-1}}$(ins( ),ins( )) :-${\displaystyle p_{1},c_{1},sid_{1}}$${\displaystyle p_{2},sid_{2}}$
 if ( ) は ins( )を返します${\displaystyle p_{1}<p_{2}}$${\displaystyle p_{1},c_{1},sid_{1}}$
 そうでない場合は、(かつ) は ins( )を返します。${\displaystyle p_{1}=p_{2}}$${\displaystyle sid_{1}<sid_{2}}$${\displaystyle p_{1},c_{1},sid_{1}}$
 それ以外の場合は ins( )
を返す${\displaystyle p_{1}-1,c_{1},sid_{1}}$

OT システムの中には、IT 機能と ET 機能の両方を使用するものもあれば、IT 機能のみを使用するものもあります。OT 機能設計の複雑さは、さまざまな要因によって決まります。

• OTシステムの機能性：OTシステムがdo（一貫性維持）、undo、ロック、^[24]認識、アプリケーション共有、^{[19] [25] [26] [27]}などをサポートしているかどうか。
• OT システムにおける正確性の責任: 満たすべき変換特性 (CP1/TP1、CP2/TP2、IP2、IP3、RP)、ET が使用されるかどうか。
• OTシステムの操作モデル: OT操作モデルが汎用的なもの(例: 基本的な挿入、削除、更新)か、アプリケーション固有のもの(対象アプリケーションのすべての操作)か。
• OT システムのデータ モデル: 各操作のデータが文字単位 (個々のオブジェクト)、文字列単位 (オブジェクトのシーケンス)、階層的、またはその他の構造であるかどうか。

OTシステムの正確性を保証するためのさまざまな変換特性が特定されています。これらの特性は、変換制御アルゴリズム^{[4] [5] [13] [20] [28] [29]}または変換関数^[30]によって維持できます。OTシステムの設計が異なれば、これらのコンポーネント間の責任分担も異なります。これらの特性の仕様と、それらを必要とする前提条件を以下に示します。

次の 2 つの特性は、収束の達成に関連しています。

• CP1/TP1 :同じ状態で定義されている同時操作とのすべてのペアについて、変換関数 T が CP1/TP1 プロパティを満たすのは、次の場合のみです。ここで、は、その後に続く操作のシーケンスを表します。ここで、2 つの操作シーケンスが同等であることを示します。CP1 /TP1 前提条件: CP1/TP1 は、OT システムで任意の 2 つの操作を異なる順序で実行できる場合にのみ必要です。${\displaystyle op_{1}}$${\displaystyle op_{2}}$${\displaystyle op_{1}\circ T(op_{2},op_{1})\equiv op_{2}\circ T(op_{1},op_{2})}$${\displaystyle op_{i}\circ op_{j}}$${\displaystyle op_{i}}$${\displaystyle op_{j}}$${\displaystyle \equiv }$
• CP2/TP2 :同じドキュメント状態に対して定義されている3 つの同時操作およびごとに、変換関数 T が CP2/TP2 プロパティを満たすのは、次の場合のみです。 CP2/TP2 は、2 つの同等な操作シーケンスに関して変換された 2 つの操作間の等価性を規定します。 を の操作シーケンスに対して変換すると、およびによって形成されるシーケンスに対してを変換した場合と同じ操作が生成される必要があります。CP2/TP2 の前提条件: CP2/TP2 は、OT システムで 2 つの操作が許可され、2 つの異なるドキュメント状態 (またはコンテキスト) で IT 変換される場合にのみ必要です。${\displaystyle op_{1},op_{2}}$${\displaystyle op_{3}}$${\displaystyle T(op_{3},op_{1}\circ T(op_{2},op_{1}))=T(op_{3},op_{2}\circ T(op_{1},op_{2}))}$${\displaystyle op_{3}}$${\displaystyle op_{2}}$${\displaystyle T(op_{1},op_{2})}$${\displaystyle op_{3}}$${\displaystyle op_{1}}$${\displaystyle T(op_{2},op_{1})}$${\displaystyle op_{1}}$${\displaystyle op_{2}}$

次の 3 つのプロパティは、目的のグループ元に戻す効果を実現することに関連しています。

• IP1 : 任意のドキュメント状態 S とシーケンス が与えられた場合、 が成り立ちます。これは、シーケンスがドキュメント状態への影響に関して単一の恒等演算 I と同等であることを意味します。このプロパティは、OT システムで正しい元に戻す効果を実現するために必要ですが、IT 機能とは関係ありません。${\displaystyle op\circ {\overline {op}}}$${\displaystyle S\circ op\circ {\overline {op}}=S}$${\displaystyle op\circ {\overline {op}}}$
• IP2 : プロパティ IP2 は、シーケンスが他の操作の変換に影響を与えないことを表します。変換関数が IP2 を満たすのは、次の場合のみです。つまり、シーケンスに対する変換の結果は、恒等操作 I に対する変換の結果と同等です。IP2前提条件: IP2 は、OT システムで、操作を 1 組の do 操作と undo 操作に対して1 つずつ変換できる場合にのみ必要です。${\displaystyle op\circ {\overline {op}}}$${\displaystyle T(op_{x},op\circ {\overline {op}})=op_{x}}$${\displaystyle op_{x}}$${\displaystyle op\circ {\overline {op}}}$${\displaystyle op_{x}}$${\displaystyle op_{x}}$${\displaystyle op\circ {\overline {op}}}$
• IP3 :同じドキュメント状態 (またはコンテキスト) で定義された2 つの同時操作とがある場合、および の場合。変換関数が IP3 プロパティを満たすのは の場合のみであり、これは変換された逆操作が変換された操作 の逆と等しいことを意味します。IP3前提条件: IP3 は、OT システムで、同時であり、 と同じドキュメント状態 (または とコンテキストが同等) で定義されている操作に対して逆操作を変換できる場合にのみ必要です。${\displaystyle op_{1}}$${\displaystyle op_{2}}$${\displaystyle {\overline {op_{1}}}'=T({\overline {op_{1}}},T(op_{2},op_{1}))}$${\displaystyle {\overline {op_{1}'}}={\overline {T(op_{1},op_{2})}}}$${\displaystyle {\overline {op_{1}}}'={\overline {op_{1}'}}}$${\displaystyle {\overline {op_{1}}}'}$${\displaystyle {\overline {op_{1}'}}}$${\displaystyle {\overline {op_{1}}}}$${\displaystyle op_{2}}$${\displaystyle op_{1}}$

さまざまなOT制御アルゴリズムが、さまざまな機能とさまざまなアプリケーションを備えたOTシステム向けに設計されています。OT制御アルゴリズムの設計の複雑さは、複数の要因によって決まります。重要な差別化要因は、アルゴリズムが同時実行制御（do）やグループundoをサポートできるかどうかです。^{[3] [8] [12] [29] [31]}さらに、OT制御アルゴリズムの設計によって、次のようなトレードオフが異なります。

• 制御アルゴリズムと変換機能の間で正確性の責任を割り当てること、および
• OT システムの時空間複雑度。

並行性制御のための既存のOT制御アルゴリズムのほとんどは、理論的根拠として因果関係/並行性の理論を採用している。因果的に関連する操作は因果順序で実行されなければならず、並行操作は実行前に変換されなければならない。しかし、並行性条件だけではすべてのOT変換条件を捉えることはできないことはよく知られていた。^{[3] [4] [5] [8] [32]}最近の研究では、操作コンテキストの理論がドキュメント状態の概念を明示的に表現するために提案されており、これを使用してOT制御アルゴリズムの設計と検証をサポートするためのOT変換条件を正式に表現することができる。^[29]

次の表は、いくつかの既存のOT制御/統合アルゴリズムの概要を示しています。

連続全順序は、欠落した要素を検出できる 厳密な全順序です。つまり、1、2、3、4、... は連続全順序ですが、1、2、3、5、... は連続全順序ではありません。

^{[10] [11]}で提案された変換ベースのアルゴリズムは、上記の代替一貫性モデル「CSM」と「CA」に基づいています。それらのアプローチは、表に記載されているものとは異なります。因果関係の保存にはベクトルタイムスタンプを使用します。その他の正確性条件は、「単一」/「複数」操作効果の関係の保存または「許容性」の保存です。これらの条件は、制御手順と変換機能が相乗的に保証します。彼らの作業では TP1/TP2 について議論する必要はありません。したがって、上記の表には記載されていません。

変換アルゴリズムを設計するための代替方法を模索する他の楽観的一貫性制御アルゴリズムもいくつか存在するが、上記の分類と特徴付けにはうまく適合しない。例えば、Mark and Retrace ^[35]

OTの正確性の問題により、WOOT、^[36]、 Logoot ^[37]、Causal Trees (CT) ^[38]などの変換不要のポストOT方式が導入されました。「ポストOT」方式は、文書をアトミック操作に分解しますが、一意のシンボル識別子、ベクトルタイムスタンプ、および/またはトゥームストーンの組み合わせを使用することで、操作を変換する必要性を回避します。

テキスト内のオフセットを通じて操作を定義するという古典的な OT アプローチは単純で自然なように思えますが、現実世界の分散システムでは深刻な問題が生じます。つまり、操作は有限の速度で伝播し、参加者の状態は異なることが多いため、結果として生じる状態と操作の組み合わせを予測して理解することは非常に困難です。Li と Li は、「複雑なケース カバレッジを考慮する必要があるため、2 つの文字単位のプリミティブ (挿入と削除) のみを扱う OT アルゴリズムの場合でも、形式的な証明は非常に複雑でエラーが発生しやすくなります」と述べています。^[39]

同様に、元 Google Wave エンジニアで Share.JS ライブラリの作者でもあるジョセフ・ジェントルは、「残念ながら、OT の実装は大変です。さまざまなトレードオフを伴うアルゴリズムが 100 万個あり、そのほとんどは学術論文に閉じ込められています。[…] Wave の作成には 2 年かかりましたが、今日書き直すとしたら、2 回目に書くのにほぼ同じくらいの時間がかかるでしょう。」と書いています。 ^[40]しかし、後に彼は「Web フレームワークと Web ブラウザの進歩により、今では Wave の実装に 2 年かかるとは思えません。」とコメントを修正しています。^[41]

OT が機能するには、データへのすべての変更をキャプチャする必要があります。「状態のスナップショットを取得することは通常簡単ですが、編集をキャプチャすることはまったく別の問題です。[…] 現代のユーザー インターフェイスの豊富さにより、特にブラウザーベースの環境ではこれが問題になる可能性があります。」OT の代替手段は差分同期です。^[42]

OT の別の代替手段は、競合のない複製されたデータ型のシーケンス型を使用することです。

• データ同期
• 共同作業可能なリアルタイムエディター
• 競合のない複製されたデータ型
• 一貫性モデル
• 楽観的複製

• OT FAQ: 運用変革に関するよくある質問と回答
• SIGCE: 共同編集に関する特別興味グループ
• 共同編集システムに関する国際ワークショップ
• 分散システムオンライン - 共同編集
• Google ドキュメントで OT を簡単に説明する
• Open Coweb フレームワークにおける OT の基礎

• Google Wave: ライブ共同編集
• Google テック トーク: リアルタイム共同編集システムの設計における課題と経験
• Microsoft Research の講演: リアルタイム共同編集システムにおける一貫性の維持