Univer - 表計算・文書・プレゼン編集を共通基盤で組み立てるOffice SDK

業務アプリに表計算や文書編集を入れると、画面だけでなく文書モデル、計算処理、プログラムから操作するAPIも必要になる。複数形式を扱う場合、用途ごとにこれらを組み合わせる方法では、機能の境界と操作方法を製品側が整理し続けなければならない。さらに画面で編集した文書をサーバー側の自動処理にも使うなら、二つの実行環境をどうつなぐかが課題になる。Univerが対象とするのは、この組み込みと連携の負担だ。

UniverのREADMEは、Sheets、Docs、Slidesが共通のプラグイン・コマンド基盤とFacade APIを使うと説明する。ここでいう共通性は、少なくとも利用者が機能を登録し、上位APIから操作する際の構成に表れている。一方、取得資料には各形式の内部モデルやコマンド処理を追った実装検証はない。三つの編集機能が同じ基盤に載るという説明を、あらゆる操作が同じ実装で動くという意味まで広げて読むべきではない。

選定時に記録されたGitHub Trendingの表示では、直近1日のスター増加は1,099件だった。これは関心の高まりを示す観測値であり、編集品質や性能の証拠ではない。取得された最新リリースは2026年9月24日公開のv1.0.2だが、リリースとスター増加の因果関係も資料からは分からない。技術的な評価には、READMEが示す構成、利用可能な機能の境界、導入先の要件を分けて確認する必要がある。

READMEのPlugin Mode例では、まずロケールを指定してUniverインスタンスを作り、描画エンジン、数式エンジン、文書形式やUIに関わるプラグインを登録する。その後、FUniver.newAPI(univer)でFacade APIを取得し、ワークブックを作成する。順序として重要なのは、アプリが必要な機能を構成してから、その構成に対する操作の入口を得る点だ。Facade APIはワークブック、ワークシート、範囲、文書、数式、コマンド、イベントを扱う。ただし、この例は仕組みを示す抜粋であり、必要なスタイルなどを含む完全な起動手順ではない。

機能を選ぶ単位がプラグインで、READMEは追加、交換、遅延読み込みに対応すると説明する。必要な描画、数式、文書、表計算、UIの機能を明示的に組み合わせるのがPlugin Modeだ。対してPreset Modeは、用途に合うプラグイン群にFacade APIの登録とスタイルをまとめる。前者は構成を細かく決めたい製品に向き、後者は定型的な構成をまとめて導入したい場合に分かりやすい。どちらを選んでも、利用する@univerjs/*パッケージは同じリリース系列・バージョンにそろえる必要がある。

READMEはCanvasベースの描画エンジンと独立した数式エンジンを挙げる。編集画面を持つ構成では、文書形式の機能に加えて描画やUIのプラグインを登録する。数式を扱う構成では数式エンジンも登録する。こうしてアプリが必要な機能を選び、Facade APIを通じてワークブックなどを操作するのが、公開資料から説明できる実行モデルだ。描画と計算の分離が特定の処理をどれだけ速くするか、あるいは各形式の内部でどの処理が共有されるかを示す測定やコード検証は、今回の資料にはない。

Univerはブラウザーの編集UIに加え、Node.jsでのヘッドレス処理を利用形態として挙げる。製品の画面で人が編集し、別の処理でUIなしにワークブックや文書を扱う構成を考えられる。拡張点としてREADMEはカスタムプラグイン、コマンド、サービス、UIコンポーネント、Facade APIを列挙する。ただし、ブラウザーとNode.jsの間で状態が自動的に同期されるという根拠はない。どのデータをいつ渡し、どの機能を双方に登録するかは、導入するアプリの設計事項として残る。

自社のSaaSや社内ツールに編集画面を埋め込み、必要な形式や機能を選びたい場合に適合しやすい。React、Vue、Web Componentsとの統合がREADMEに挙がり、推奨ビルドツールにはVite、esbuild、Webpack 5が含まれる。画面側とNode.jsの自動処理を同じSDK系列で検討できる点も、この用途に合う。形式ごとに編集UI、文書ロジック、操作APIを別々に組み合わせる方法と比べると、Univerは構成と操作の接点をSDK側に寄せる選択肢になる。ただし、製品固有のワークフローまでSDKが決めてくれるわけではない。

共同編集、編集履歴、ファイルの入出力、印刷、チャートなどは、READMEの機能表でUniver Pro側に分類されている。Officeファイルを取り込んで編集し、再び書き出すことや、複数人の同時編集を必須とする製品では、この境界が採用判断を左右する。公開パッケージだけで必要な機能を完結させたい場合には適合しにくい。READMEが紹介する製品群全体の範囲と、公開SDKで実際に利用できる範囲も同一とは限らないため、必要な機能ごとに提供パッケージとライセンスを確認する必要がある。

READMEは、エージェントが構造化APIで編集し、内容、スクリーンショット、レイアウト診断で確認し、隔離した下書きをレビューする用途を挙げる。これは保守者が示すワークフローであり、その運用上の成熟度を示す独立した検証結果ではない。ライブ編集、共有リビジョン、Worktreeワークフローには対応するWeb SDKと共同編集機能が必要で、機能ごとにパッケージとライセンスが異なる。エージェントに文書の変更を任せるなら、どの操作を許し、結果をどう確認するかも製品側の課題になる。取得資料だけでは具体的な権限モデルまで評価できない。

ヘッドレス処理の対応範囲はNode.js 18.17.0以上とされる。Intl.Segmenterがない環境ではポリフィルが必要で、exportsフィールドに対応しないビルドツールでは追加のパス設定が必要になる場合がある。複数パッケージのバージョン整合も継続的な管理事項だ。さらに0.25系から1.0系への更新にはAPI削除とパッケージ変更がある。小規模な組み込みでも、プラグイン構成や更新時の確認に時間を割けないなら負担は相対的に大きい。性能については比較条件付きの定量結果が取得資料になく、導入先の文書と操作で測る必要がある。