Build Microsoft の先日終了した Build イベントで興味深いテクノロジ プレビューが Fluid Framework ですが、同社はそれが具体的にどのようなものであるかについてあまりうまく伝えていません。
Microsoft は 1 年前の Build 2019 で Fluid Framework を公開しました。これは Office 365 の機能として提供されており、これにより、書式設定されたテキスト、表、グラフ、リストなどのドキュメント コンポーネントを使用してリアルタイムのコラボレーションが可能になります。
これはWeb技術であるため、デスクトップ版Officeアプリケーションではまだ利用できません（将来的には利用可能になる予定です）。しかし、ブラウザで作業する場合、これらのコンポーネントをメールやその他のドキュメントに挿入し、他のユーザーが追加すると即座に更新されるのを確認できるという構想です。これはしばらくの間限定プレビューでしたが、BuildでMicrosoftは近日中にパブリックプレビューを公開し、フレームワークは1ヶ月以内にオープンソースとして公開されると発表しました。これにより、サードパーティが新しいコンポーネントを作成したり、Office以外のアプリケーションでこの技術を利用したりできるようになります。
これは、SharePoint Onlineで既に利用可能なマルチユーザー編集機能とどう違うのでしょうか？Microsoft 365エコシステムディレクターのマイク・アマーラン氏はThe Reg誌に対し、「Teamsのチャットやメールに埋め込める流動的なコンポーネントによって、信頼できる唯一の情報源に近づくことができます」と述べています。「これらのコンポーネントをチャット内に直接配置することで、ユーザーは最新バージョンを確認しやすくなります。ハイパーリンクに比べて、よりスムーズな操作が可能です。」
システムは誰がどのような変更を行ったかを記録し、コンポーネントの履歴を確認して、必要に応じて以前のバージョンに戻すことができます。
Fluid は、現在の実装では、SharePoint または OneDrive オンラインで作成できる新しいドキュメントタイプでもあり、これらは Fluid コンポーネントのコンテナです。この記事は Fluid に入力されています。Word のような膨大な機能は備えていませんが、クリーンでレスポンシブなエディターであり、基本的な右クリックによる書式設定が可能です。内部的には Markdown に基づいています。プラスアイコンをクリックすると、表、画像、タスクリスト、@メンションなどの要素を挿入できます。ただし、機能は非常に限られています。
現在の期待外れのプレビューに新しいコンポーネントを挿入する
しかし、このアイデアは新しいドキュメントタイプというよりは、特定の種類のドキュメントを編集するという概念からの脱却を目指しています。従来のモデルでは、「通常、多くの異なるアプリケーション間でタスクを切り替えていました」と、主任リードプログラムマネージャーのピーター・アレンスパック氏はBuild誌に語りました。「Fluid Frameworkを使えば、統合されたエクスペリエンスを実現できます。既存の作業環境にツールを統合できます。例えば、TeamsやOutlookでエンドツーエンドで作業できます。」
これは興味深い話ですが、Microsoftが概念実証デモから実用的なものへと進化するのに長い時間がかかっていることに不満の声が上がっています。例えば、あるコメントでは次のような不満が寄せられています。「実使用例はどこにあるのでしょうか？まだ開発段階なので、例がないのでしょうか？例えば、OneDriveのスプレッドシートからグラフをコピーしてメールに貼り付け、誰かが数字を更新するとメールの閲覧パネルでグラフが自動的に更新されるのはいつになるのでしょうか？あるいは、メール内のグラフから直接数字を更新できるなんて？1年後、2年後でしょうか？」
Fluid Framework の仕組み
Fluid Frameworkとは一体何なのでしょうか？その名前が示す通り、JavaScriptまたはTypeScriptを用いてリアルタイムコラボレーションアプリケーションを開発するためのフレームワークです。WebSocket APIを使用することで、クライアントは更新情報を通知され、オープンな通信セッションを介してサーバーに更新情報を送信できます。これは、HTTPのPOST/GETよりもはるかに高速で軽量です。
Fluid に関する最も詳しい情報は、この Build セッションにあります。Allenspach とシニア プログラム マネージャーの Tyler Butler が、その原理と仕組みについて説明しました。
Fluid（クライアント側）の核となるのは分散データ構造であり、これには多くのスマート機能が組み込まれている。
バトラー氏によると、Fluidには2つの重要な概念がある。1つ目は分散データ構造（DDS）で、「開発者が使用する主要な構成要素」である。これには文字列、配列、オブジェクトのリストなどが含まれる。Fluidコンポーネントは、ビジネスロジックや他のFluidコンポーネントと組み合わせたDDSの集合体である。このフレームワークでは、開発者はDDSにデータを保存し、その状態を自動的にサーバーに保存して、他のクライアントに変更を通知することができる。また、コンポーネントの履歴を参照するメソッドも用意されており、すべての変更の完全な記録がサーバー上に保存される。
ビルド中の質疑応答セッションで、プリンシパルプログラムマネージャーのニック・シモンズ氏は、C#開発者がアプリケーションでFluidを使用できるかどうかについて質問を受けました。「Fluid FrameworkはJavaScriptランタイムで動作するように設計されています」とシモンズ氏は答えました。「ただし、C#プロジェクトでJavaScriptランタイムをホストすることは可能です。」これは、Fluidが実際には.NET開発者向けではないことを示唆しているのかもしれません。MicrosoftはSignalRという.NET向けのリアルタイム通信ライブラリを提供しており、これはFluidの機能と一部重複していますが、FluidではSignalRは使用されていないとMicrosoftは述べています。React開発者は使い慣れているでしょう。そして、これがMicrosoftのOfficeチームが.NETよりもReact Nativeを好んでいる理由の一つかもしれません。特にMicrosoftはWindowsに加えてmacOS向けのReact Nativeも発表しています。
フレームワークは競合解決をどのように処理するのでしょうか？「開発者は多少の検討が必要です」とシモンズ氏は言います。「しかし、競合解決を容易に処理できるように設計に取り組んでいます。多くの分散データ構造には、共有文字列のように、ある程度の競合解決機能が組み込まれており、複数の操作が同時に実行されたときに合理的な出力が得られるように処理されます。」
データはどこに保存されるのでしょうか？「それは実装者次第です」とシモンズ氏は言いますが、Microsoftは当初、Fluidドキュメント用にSharePointを使用しています。データ保存には2つの異なる側面があります。1つはコンポーネントを定義するJavaScriptを含むクライアントファイル、もう1つは状態を変更する操作（ops）を追跡するサーバーです。この部分はSharePointによって行われるわけではありません。「サーバー上にDDSは保存されません」とシモンズ氏は言います。「サーバーはopsの管理とブロードキャストのみを担当します。クライアントは、それらの操作からデータ構造を構築する役割を担います。」
どの程度の拡張性があるのだろうか？「サーバーが行う作業量は非常に軽量です」とシモンズ氏は言う。「オペレーションを取り込み、スタンプを付け、ブロードキャストするだけです。サーバーに1秒間に数千件のリクエストを処理させても、全く問題はありません。最大の要因はネットワークだと考えています。」
つまり、Fluid FrameworkはOffice 365の新機能であると同時に、リアルタイムコラボレーションのためのJavaScriptライブラリであり、まもなくオープンソース化されるということです。Officeでどれほど役立つのでしょうか？ほとんどのユーザーは依然としてFluidが動作しないデスクトップアプリケーションで作業しており、魅力的なデモもいくつか見られましたが、ビジネス価値は不透明です。
しかし、同時共同編集に関しては、既存の SharePoint ベースの機能よりもはるかに優れていることは明らかであり、これは、Google の G Suite が共同作業に優れているという認識を変えるのに役立つ可能性があり、Microsoft が Windows ユーザーを置き去りにする Web ベースの機能を提供する意思があることを示す証拠でもあります。®
