オンラインドキュメント SDK の選定：プライベート環境に組み込む編集機能

自社製品にドキュメント編集機能を必要とするチームは、通常、分岐点に直面します。編集 SDK を組み込むか、ドキュメントスイートを統合するか、エディタを自作するかです。どの選択肢も、長期的なコストの性質が異なります。

本記事では最初の選択肢、すなわちプライベート環境にデプロイする組み込み型のドキュメント編集 SDK に焦点を当て、実用的な選択と高コストな選択を分ける評価基準を説明します。

組み込むか、統合するか、自作するか

• SDK を組み込む。 編集画面と共同編集モデルを入手し、自社製品のナビゲーション、権限、ストレージに統合します。ドキュメントがより大きなワークフローの中の一機能である場合に最適です。
• ドキュメントスイートを統合する。 独自の UI とアカウントモデルを持つ、より広範な製品を採用します。標準的なオフィス作業には速い方法ですが、体験が自社製品に自然に溶け込む必要がある場合は適しません。
• エディタを自作する。 最大の制御と最大のコスト。編集の挙動が中核的な差別化要因であり、長いロードマップに投資できる場合にのみ合理的です。

この区別は商業的にも重要です。WPS のような製品群は完全なオフィススイートであり、組み込み型 SDK はコンポーネントです。両者は異なる問題を解くものであり、コンポーネントはスイートの代替ではありませんし、スイートは他社のワークフローに組み込むのに適したものでもありません。

組み込み型 SDK に求められるもの

1. 編集の忠実性

ユーザーは、すでに使っているツールを基準にエディタを評価します。次の点を確認します。

• リッチテキスト構造：見出し、リスト、表、画像、コメント、必要に応じて変更履歴。
• 契約書や印刷物を扱う場合は、ページ分割と印刷レイアウト。
• ブラウザやオフィスアプリケーションからの貼り付け挙動。
• 長いドキュメントでの性能。数百ページ、大きな表、多数の画像。

ベンダーが用意したサンプルファイルではなく、自社の実際のドキュメントでテストします。

2. 共同編集モデル

複数ユーザーによる編集には一貫性モデルが必要です。代表的な2つの方式があります。

• Operational Transformation（OT）：操作を並行する操作に対して変換します。構造化ドキュメントに強く、中央の権威が必要です。
• CRDT ベースの方式：収束するデータ構造を用います。オフラインやピア間のシナリオに強く、メモリとドキュメント表現に異なるトレードオフがあります。

どちらが適切かは、デプロイ形態とオフライン要件によります。競合がどのように解決されるか、ネットワーク分断時に何が起きるか、他のユーザーが編集中のときに単一ユーザーの undo がどう振る舞うかを確認します。

3. 形式の互換性

インポートとエクスポートは、プロジェクトが静かに失敗する箇所です。次の点を確認します。

• インポート、エクスポート、ラウンドトリップで対応する形式。
• ラウンドトリップでスタイル、コメント、変更履歴が保持されるか。
• 未対応の機能がどう扱われるか。黙って破棄されるのか、明示されるのか。
• 変換がクライアント側、サーバー側、その両方のどこで行われるか。

ユーザーが Microsoft Office や WPS のユーザーとファイルをやり取りする場合、ラウンドトリップの忠実性には専用のテストセットを用意する価値があります。

4. 権限と共有

ドキュメントは通常、ホスト製品から権限を継承します。SDK はドキュメント単位のロール、必要に応じて共有リンク、管理者による上書きを、認可ロジックを二重のシステムに複製することなくサポートする必要があります。

権限の判定がどこで強制されるか（クライアント、共同編集サービス、ストレージ層）を確認します。意味を持つのはサーバー側での強制です。

5. ストレージとデプロイ

プライベートデプロイでは、ドキュメントの内容とバージョン履歴は自社のオブジェクトストレージとデータベースに存在します。次の点を明確にします。

• ドキュメントの表現形式と、それがエクスポート可能か。
• バージョン履歴と保持の制御。
• バックアップとリストアの期待値。
• コンポーネント一覧、ポート、外部通信の要件。

6. オフラインと劣化したネットワーク

ユーザーが不安定なネットワークで編集する場合は、期待される挙動を定義します。ローカルへの下書き保存、再接続時の競合処理、共同編集サービスに到達できないときに何が見えるか。

7. 統合インターフェース

SDK はライフサイクルイベント、カスタムツールバーアクション、プラグインポイント、テーマ設定を公開すべきです。自社製品の UI のうち、設定で済む部分と作り直す必要がある部分がどれくらいか、アップグレードがカスタマイズを壊す可能性があるかを確認します。

評価計画

短いながら現実的な評価を行います。

1. 自社アプリケーションシェル内のテストページにエディタを組み込みます。
2. 代表的なドキュメントを10〜20件インポートし、元ファイルと描画を比較します。
3. 5〜10名で共同編集セッションを実施し、強制的な切断も含めます。
4. 改変したクライアントリクエストで権限のバイパスを試みます。
5. ドキュメントをエクスポートし、ラウンドトリップの忠実性を検証します。
6. コンポーネントとネットワークの要件をインフラチームと確認します。

すべての候補について同じ基準で結果を記録します。デモのスクリーンショットは証拠ではありません。

コストとロードマップのリスク

• ライセンスモデル。 シート単位、ドキュメント単位、デプロイ単位、プラットフォーム単位のライセンスは、利用の拡大に伴って経済性を大きく変えます。
• 形式のメンテナンス。 オフィス形式は進化します。互換性の更新がどのように提供されるかを確認します。
• ロードマップへの依存。 必要な機能が「計画中」である場合、契約上のチェックポイントまたは代替案を合意します。
• コミュニティと採用。 広く使われているオープンソースのエディタはロックインを減らします。プロプライエタリなものはより良いサポートを提供する場合があります。どちらも妥当ですが、含意するリスクは異なります。

Feiyan Docs の位置づけ

Feiyan Docs は当社のオンラインドキュメント編集 SDK であり、組み込みとプライベートデプロイを前提に設計されています。現在は Coming soon の段階です。利用可能な製品として提示しているわけではなく、引用できる顧客導入事例もありません。

このカテゴリを現在評価している場合は、上記の基準をどの候補にも適用してください。プレビューが利用可能になれば、当社製品も同様に評価いただけます。ロードマップではなく、動作するビルドで評価されることを望んでいます。