Univer は、表計算・文書・スライド・データベース・ボードを1つのランタイムに載せるOffice SDKだ。READMEの一行目は “The Office Harness for AI Agents”——AIエージェントのためのOfficeハーネス、と名乗っている。star 21k、fork 1.8k、Apache-2.0、TypeScriptのpnpmモノレポ。「エージェントに表計算を触らせたい」という需要にまっすぐ応える位置づけだが、この種のプロジェクトはOSSと商用の線引きが曖昧になりがちだ。そこで2026-09-28時点の v1.0.2 を実際に入れ、規模・重さ・公式AIスキル・そしてApache-2.0でどこまで作れるかを測った。結論を先に言うと、境界はREADMEに驚くほど明確に書かれていた。

Univerのエージェント向けワークフロー。構造化APIでエージェントがセルや文書を読み書きし、描画スクショとレイアウト診断で出力を検証し、Worktreeで隔離した変更を人がレビューして採否を決める
出典: v1.0.2 README の Office Workflows for AI Agents 節を実測して作図（2026-09-28）。②③はWeb SDKと協調編集機能が前提
30秒でわかるUniver（2026-09-28時点）
  • ・表計算・文書・スライド・Bases・Boards を1ランタイムで扱うTypeScript製Office SDK。PDFは coming soon
  • ・packages/ 直下は60パッケージ、presets/ は2つ。既定ブランチは dev で、最新タグは v1.0.2
  • ・npm install @univerjs/presets で node_modules 109MB。数式エンジン44MBと描画エンジン29MBで3分の2
  • ・Apache-2.0。ただし協調編集・入出力・印刷・グラフ・ピボットは Univer Pro（商用）側
  • ・エージェント向けの公式スキルは別リポジトリに4本。合計で約10,073トークン（heuristic近似）
  • ・OSSの telemetry パッケージはインターフェースのみで、送信先URLはソースに存在しない

エージェント基盤そのものの比較はAIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証にまとめてある。本記事はエージェントに持たせる「作業場」の側の話だ。

Univerとは：Officeの部品を全部プラグインにしたSDK

Univer はアプリではなくSDKだ。自分のWebアプリに表計算や文書エディタを埋め込むための部品群で、しかもその部品が徹底的に分割されている。packages/ 直下を数えると60パッケージあり、命名を見るだけで粒度が分かる。

層 パッケージ例
基盤 core・design・engine-formula（数式）・engine-render（描画）・ui・themes・network・rpc
表計算 sheets・sheets-formula・sheets-filter・sheets-sort・sheets-numfmt・sheets-data-validation・sheets-conditional-formatting・sheets-table・sheets-note など
文書 docs・docs-ui・docs-toc・docs-hyper-link・docs-thread-comment・docs-drawing など
スライド slides・slides-ui
横断 find-replace・thread-comment・drawing・watermark・action-recorder・telemetry
アダプタ ui-adapter-vue3・ui-adapter-web-component

機能ごとにロジック（sheets-filter）とUI（sheets-filter-ui）が別パッケージになっているのが特徴で、UIを自前で作りたい場合にロジックだけ取れる。逆に言えば、素直に全部入りを使いたいなら presets/ の Preset Mode を選ぶ設計になっている。READMEも「完全な製品カバレッジと精密な構成が要るなら Plugin Mode、短い手順で始めるなら Preset Mode」と書き分けている。

実際に Preset Mode で入れて重さを測った。

mkdir uv-npm && cd uv-npm && npm init -y
npm install @univerjs/presets
du -sm node_modules            # 109
ls node_modules/@univerjs | wc -l   # 10
node_modulesの内訳。@univerjs/engine-formulaが44MB、@univerjs/engine-renderが29MB、@univerjs/coreが6MB、その他7パッケージが30MB
出典: 空のnpmプロジェクトに npm install @univerjs/presets した直後の du -sm（合計109MB・@univerjs 配下10パッケージ・2026-09-28）

109MBのうち、数式エンジンが44MB、描画エンジンが29MB。この2つで3分の2を占める。ブラウザに配るバンドルはツリーシェイクとコード分割を経るので109MBがそのまま転送量になるわけではないが、Univerの重心が「表計算の計算と描画」にあることは数字からはっきり読める。単なるUIコンポーネント集ではない。

Univerの実測データ。GitHub star 21k（fork 1.8k）、packages/直下60パッケージ、presetsを入れたnode_modulesが109MB、公式AIスキルは別リポジトリに4本
star/fork はリポジトリページ、他は dev ブランチ a77bd5d（v1.0.2）と npm の実測値（2026-09-28）

検証環境：Linux 6.18.44／Node 22.22.2／npm 10.9.7／2026-09-28。リポジトリは既定ブランチ dev の a77bd5d（2026-09-28・最新タグ v1.0.2）を git clone --depth 1。npm からは空プロジェクトへ @univerjs/presets を導入して du -sm で計測。公式スキルは dream-num/univer-sdk-skills を同日クローンし SKILL.md を計測。パッケージ数は packages/ と presets/ のディレクトリを数えた。未検証：ブラウザで一度も起動していない。表計算の編集、Facade API からのセル操作、エージェント連携、Worktree ワークフロー、描画性能、日本語入力とIMEの挙動はいずれも未実行。Univer Pro は入手していないため、Pro 側の機能は README の記載のみを根拠にしている。star 21k・fork 1.8k はリポジトリページの表示値。

エージェント向けという位置づけの実体

READMEには 🤖 Office Workflows for AI Agents という独立した節がある。書かれているのは3つだ。

・プログラマティックな編集：エージェントが構造化APIを通じてOfficeコンテンツを検査・変更する
・出力の検証：コンテンツの検査、レンダリング済みスクリーンショット、レイアウト診断で結果を確かめる
・Worktree協調：エージェントは隔離されたドラフトで作業し、人がその変更をレビューして何をマージするか決める

「LLMを組み込みました」ではなく、エージェントが壊しても人が戻せる導線を設計として書いているのが面白い。とくに Worktree という言い方は、コードのブランチ運用の比喩をそのままOffice文書に持ち込んでいる。ログや変更を正本として扱う設計思想という点ではApache Maka（Incubating）とは｜ログを権威にするローカルファーストAIエージェント基盤と発想が近い。

ただし同じ節の末尾に、見落としてはいけない一文がある。「ライブ編集、共有リビジョン、Worktreeワークフローには対応する Web SDK と協調機能が必要で、パッケージの提供状況とライセンスは機能ごとに異なる」。つまりこの3つのうち後半2つは、OSSリポジトリだけでは完結しない。ここが次の節につながる。

エージェント側に渡す知識も公式に用意されている。別リポジトリ dream-num/univer-sdk-skills をクローンすると、Agent Skills が4本入っていた。

git clone --depth 1 https://github.com/dream-num/univer-sdk-skills
find univer-sdk-skills -name 'SKILL.md'
# univer-sdk-skills/skills/univer-integrate/SKILL.md
# univer-sdk-skills/skills/univer-plugin-dev/SKILL.md
# univer-sdk-skills/skills/univer-node-backend/SKILL.md
# univer-sdk-skills/skills/univer-pro-integrate/SKILL.md
公式スキル4本の常駐コスト。univer-integrateが3761トークン、univer-pro-integrateが2791トークン、univer-node-backendが2088トークン、univer-plugin-devが1433トークン
dream-num/univer-sdk-skills をクローンして SKILL.md を計測。tokenizer は tools/token_audit.py の heuristic 近似（2026-09-28）

4本の合計は約10,073トークン（tools/token_audit.py の heuristic 近似、CJK 1字=1・ASCII 4字=1）。全部入れるとエージェントの文脈に1万トークン乗る計算なので、必要なものだけ選ぶのが現実的だ。4本のうち1本は univer-pro-integrate、つまり商用Pro層の組み込み用である点も、この製品の構造をよく表している。スキルを複数ツールへ配る運用そのものの注意点はCanvasMind徹底解説：AIワークフローをノードで組む低コードIDEと単体書き出しで扱った低コード側の話とも通じる。

Preset Mode と Plugin Mode：どちらで始めるか

導入の入口は2つある。READMEは「完全な製品カバレッジと精密な構成が要るなら Plugin Mode、対応する Sheets・Docs・Node プロファイルなら Preset Mode のほうが手順が短い」と書き分けている。実際の差は、書き下すパッケージの数に出る。

Plugin Mode の例としてREADMEが挙げているのは、表計算を最小構成で動かすための13パッケージだ。

pnpm add の引数に並ぶのは core・design・docs・docs-ui・engine-formula・engine-render・sheets・sheets-formula・sheets-formula-ui・sheets-numfmt・sheets-numfmt-ui・sheets-ui・ui の13個（本記事の環境では Plugin Mode は未実行のため、READMEの記載として扱う）。

表計算を出すだけで docs と docs-ui が要るのは、セル内のテキスト編集が文書エンジンを使っているからだ。Plugin Mode では、この一覧に加えてスタイルのインポート、ロケールのマージ、Facade API の登録、プラグインの設定を自分で書く。細かく制御できる代わりに、初期設定の記述量は増える。

Preset Mode はこれを2パッケージに畳む。

pnpm add @univerjs/presets @univerjs/preset-sheets-core の2つだけで済む。

プリセットは「必要な Facade API 登録とスタイルを含む、厳選されたプラグインの集合」と説明されている。冒頭で測った109MBはこの Preset Mode の数字で、@univerjs 配下に10パッケージが展開された。まず動かして評価したい段階では Preset、UIを差し替えて製品に組み込む段階で Plugin という移行を想定した設計に見える。

flowchart TD A["自分のWebアプリ"] --> B{"導入モード"} B -- "Preset Mode" --> C["@univerjs/presets
+ preset-sheets-core"] B -- "Plugin Mode" --> D["13パッケージを個別に指定
スタイル・ロケール・Facade登録も自前"] C --> E["Univer ランタイム"] D --> E E --> F["engine-formula
数式の計算・44MB"] E --> G["engine-render
キャンバス描画・29MB"] E --> H["Facade API
エージェントはここを叩く"] H --> I["OSS で可能
編集・数式・書式・データ検証"] H --> J["Univer Pro が必要
協調編集・入出力・グラフ"]

動作要件もREADMEに明記されている。ブラウザは Chrome 88 をターゲットにコンパイルされ、Edge・Chrome は88以上、Firefox 90以上、Safari 14.1以上、Electron 12以上を狙う。Intl.Segmenter に依存しているので、対応しない環境では @formatjs/intl-segmenter などのポリフィルが要る——日本語や中国語のように単語境界が自明でない言語を扱ううえで、ここは避けて通れない実装だろう。ビルドツールは Vite・esbuild・Webpack 5 が推奨で、package.json の exports を解釈できない Webpack 4 ではパスマッピングの追加が要る。ビュー層は React 18 ベース、React 19 にも対応し、16.9以上と17には最小限の互換だけ提供する。ヘッドレスの Node.js は 18.17.0 以上、このモノレポ自体の開発には Node.js 22.18 以上が要る。

この要件一覧は、採用判断のときにそのままチェックリストになる。社内の管理端末が古いブラウザに固定されている、ビルドが Webpack 4 のまま止まっている、React 17 から上げられない——こうした事情があるプロジェクトでは、Univer を入れる前にそちらの解消が先になる。逆に Vite と React 18 以降で組んでいる新しいフロントエンドなら、引っかかる箇所はほとんど無いはずだ。Intl.Segmenter の依存だけは日本語を扱う以上ほぼ確実に通る道なので、ターゲットブラウザの対応表を先に確認しておきたい。

エージェントに触らせる観点でもう一点挙げておくと、Univer の操作面は Facade API に集約されている。プラグインを個別に呼ぶのではなく、ワークブック・ワークシート・レンジといった概念に沿った窓口が用意されていて、公式スキルの univer-integrate もこのAPIの使い方を中心に書かれている。エージェントに与えるインターフェースとして、パッケージ60個の内部構造を見せずに済む形になっているのは素直に良い設計だと思う。

OSSとProの境界：Apache-2.0でどこまで作れるか

ここが本記事でいちばん伝えたい部分だ。READMEには 🔓 Open Source and Pro という節があり、カテゴリ別の表で線が引かれている。原文を整理するとこうなる。

OSSとProの比較。OSSはコアSDK・プラグイン機構・描画/数式エンジン、表計算の編集・数式・書式・フィルタ/並べ替え、データ検証・条件付き書式・表・コメント、Node.jsヘッドレス実行・RPC/Web Worker。Proは協調編集・編集履歴、インポート/エクスポート・印刷、グラフ・ピボットテーブル・スパークライン、協調サーバー・SSR・サーバー側計算
出典: README の Open Source and Pro 節の表を原文から整理（2026-09-28）
カテゴリ OSS（このリポジトリ） Univer Pro（商用）
基盤 コアSDK・プラグイン機構・描画エンジン・数式エンジン・Facade API・テーマ・i18n・フレームワークアダプタ Proプリセット、エンタープライズ配備パッケージ
表計算 編集・数式・数値書式・フィルタ/並べ替え・データ検証・条件付き書式・ノート・テーブル・ハイパーリンク・コメント・作図・検索置換 協調編集、編集履歴、インポート/エクスポート、印刷、グラフ、ピボットテーブル、スパークライン、アウトライン、図形、セル内グラフィック、データコネクタ、拡張数式エンジン
文書 ドキュメントモデルとエディタUI、リスト、ハイパーリンク、コメント、クイック挿入、作図連携 協調編集、インポート/エクスポート、印刷、拡張テーブル/リスト、段組み、コールアウト、コードブロック、引用、図形
スライド OSSのプレゼンモデルとUI Proのモデル/UI、スライドの入出力、グラフ、テーブル、図形エディタUI
サーバー/実行環境 Node.jsヘッドレスランタイム、RPC/Web Workerパターン、サーバー向け自動化の基礎 協調サーバー、Node協調クライアント、SSR、計算委譲、サーバー側計算、変更セット再生

Excelファイルの読み書き（インポート/エクスポート）はPro側、グラフとピボットテーブルもPro側、協調編集もPro側。ここを知らずに「OSSの表計算SDK」として採用すると、要件の後半で詰まる可能性が高い。

一方で評価したいのは、この線引きがREADMEに明記されていることだ。同じ節には「境界の原則」まで書かれている——OSSパッケージは単体で有用であることを意図している、OSSのバグはPro機能が絡んでもOSSリポジトリで直す、OSSのドキュメントはPro限定機能が公開パッケージで使えるかのように書かない、OSS機能にPro強化版がある場合もOSS側の挙動を独立して文書化する。商用レイヤーを持つOSSの書き方としては、かなり誠実な部類だと思う。

OSSと商用の導線という点では、同日に測ったmem0とは｜AIエージェントの記憶OSSを217MBで実測、公開ベンチ値が指すのはOSS版ではないも同じ構造を持っていた。あちらはベンチマークの数字がマネージド版のものだと注記され、こちらは機能表で線を引く。形は違うが、OSSを入口にした商用製品を評価するときは、まず境界の記述を探すのが近道だという点は共通している。

測って分かったこと、測れなかったこと

実測で確認できた細かい点を並べる。

・既定ブランチは dev：main ではない。クローンしたときに手元に来るのは開発ブランチなので、安定版が要るなら v1.0.2 などのタグを指定する。タグは149本
・ライセンス実体は Apache-2.0：LICENSE ファイルの先頭も Apache License Version 2.0、package.json の license も Apache-2.0 で一致していた
・テレメトリは仕組みだけ：packages/telemetry/src には ITelemetryService インターフェースとDI識別子の定義しかない。URLを grep して出てくるのは各ファイル冒頭のApacheライセンス表記2件だけで、送信先は存在しない。実装は利用者が用意する設計で、既定で外に送るタイプではない
・モノレポの運用はpnpm + turbo：pnpm-workspace.yaml と turbo.json があり、vitest.workspace.ts でテストも束ねている。コントリビュートする側の入口は整っている
・最終コミットは当日：クローン時点の dev 先頭は 2026-09-28 のコミットだった。開発は活発

grep -rnoE 'https?://[a-zA-Z0-9./-]+' packages/telemetry/src/
# packages/telemetry/src/index.ts:8:http://www.apache.org/licenses/LICENSE-2.0
# packages/telemetry/src/services/telemetry.service.ts:8:http://www.apache.org/licenses/LICENSE-2.0
# → 出てくるのは各ファイル冒頭のApacheライセンス表記だけで、送信先は存在しない

未検証として残した範囲も明確にしておく。ブラウザで実際に表計算を起動して操作する、エージェントからFacade APIを叩いてセルを書き換える、Worktreeワークフローを回す——これらはいずれも動かしていない。ヘッドレス環境でパッケージを入れ、ソースとREADMEを読み、サイズを測ったところまでが本記事の範囲だ。したがって編集の使い心地、描画性能、日本語入力やIMEまわりの挙動、大きなシートでの計算速度については何も言えない。日本語ロケールの有無すら確認していない。

総括。 Univer は「エージェントに渡せるOffice」を本気で作りにいっているSDKで、60パッケージという分割と、数式・描画の2エンジンに寄った重心がそれを裏づけている。エージェント向けの公式スキルまで別リポジトリで用意しているのは、この規模のプロジェクトでは珍しい。判断が要るのは機能の位置だ。Excelの入出力・グラフ・協調編集が要件に入るなら、それはOSSではなくProの領域であり、そこを最初に確かめてから採否を決めるのが正しい順序だと思う。逆に「自前UIで表計算のロジックだけ使いたい」「Nodeでヘッドレスに計算させたい」なら、Apache-2.0の範囲で十分に成立する。

参照ソース

・dream-num/univer（公式リポジトリ） — README・packages/・LICENSE・packages/telemetry/src を 2026-09-28 に確認（dev の a77bd5d）
・dream-num/univer-sdk-skills（公式AIスキル） — 同日クローンしてSKILL.md 4本を計測
・Univer 公式ドキュメント — READMEから案内されている公式ドキュメント
・@univerjs/presets（npm） — 実際に導入した配布物