ARTICLES

ReoGrid V5 リリース — 完全仮想化を設計の一行目に。100万行が「普通のデータ」になる

reogridspreadsheet.netperformancerelease
2026年8月25日·UNVELL Inc.
ReoGrid V5 リリース — 完全仮想化を設計の一行目に。100万行が「普通のデータ」になる

UNVELL株式会社は、.NET向けスプレッドシートコンポーネント ReoGrid の新世代バージョン V5 を2026年8月25日にリリースしました。

V5 は、既存 V4 の延長・改良版ではなく、コアから再設計された次世代版です。「完全仮想化」を後付けの最適化ではなく、設計の一行目に置き、データ構造からレンダラまでを作り直しました。

結果として、100万行を抱えたシートでも、最初の1画面が立ち上がるまでは1ミリ秒に満たない時間で済みます。理由はひとつで、処理量を決めるのがデータ量ではなく、いま見えている範囲だけだからです。

スクロールも同じ理屈で動きます。画面1枚ぶんのセルを読み出すのにかかるのは数十マイクロ秒、そのとき新たに確保するメモリは0バイト。60fps を保つための1フレーム16.7ミリ秒のうち、読み取りが使うのは 0.1% 未満です。残りはすべて描画とアプリケーション側の処理に回せます。

10行のシートも、100万行のシートも、手元の体感は同じ。これが V5 の出発点であり、到達点です。


「速くした」のではなく、「速い形で作り直した」

性能を上げる道は2つあります。ボトルネックを見つけて潰していく道と、そもそもボトルネックが生まれない構造に作り替える道です。

ReoGrid はこれまで前者を積み重ねてきました。直近の V4.4 では、条件付き書式を伴う大量データ投入を約11,700倍、ソートを約10倍まで高速化しています。その過程ではっきりしたのは、最後に残った天井は実装ではなく、設計そのものにあるということでした。

従来の設計では、値の入ったセル1つにつき1つの CLR オブジェクトが確保されます。実測で1セルあたり約300バイト。 100万行×50列を素直に持てば、それだけでギガバイト級です。この土台の上で「100万行を普通に扱う」ところまで行くには、土台を入れ替える必要がありました。

そこで V5 では、天井そのものを作り直すという判断をしました。


設計の一行目に置いたもの — 完全仮想化

仮想化を「あとから足す最適化」として扱うと、どこかに必ず取りこぼしが残ります。描画は仮想化されているのに、条件付き書式の評価はシート全体を舐めている。スクロールは軽いのに、列全体に色を付けた瞬間に固まる。一箇所でも全件走査が残っていれば、そこが新しい天井になります。

V5 は、この一点を設計の前提として全体に貫きました。

作業量は、シートの大きさではなく、いま見えている窓の大きさに比例する。

この原則を、描画だけでなく、入力・評価・書式・検索・I/O のすべてに適用しています。以下は、その内訳です。


なぜ速いのか ① — 省メモリ設計で、メモリ管理のコストを極限まで下げた

速さの土台は、そもそも運ぶ荷物を軽くすることにあります。データが小さければ、CPU のキャッシュに乗り、ガベージコレクタが面倒を見る対象も減ります。

V5 のコアストレージは「行チャンク × 列指向 + 適応型ブロック」構造です。セルの値は16バイトの値型として密に並び、スタイルと文字列はインターン(共有)されます。値の入っているセルの分だけを持つので、宣言だけが大きいシートは軽いままです。

計測環境: .NET 10 / ServerGC / 64-bit(2026-06-19 実測・2026-08-25 再検証)

シナリオ占有セル数ヒープ1セルあたり
密 200,000行 × 50列(数値)10,000,000155 MB16.3 B
密 200,000行 × 50列(テキスト200種)10,000,000155 MB16.3 B
密 200,000行 × 50列 + 5スタイル10,000,000194 MB20.4 B
一様に散在する疎データ(最悪ケース)23.4 B

1,000万セルを積んで約155MB。 ノートPCのメモリに余裕をもって収まります。

従来設計と、同じマシンで並べて測りました

以前この記事では従来比を「約9.8倍」と推計値で示していました。その後、同一マシン・同一ランタイムで V4 を実際に動かして計測したところ、実測値は推計を上回りました。以下はすべて実測です。

V4 は「1セル=1 CLR オブジェクト」という、スプレッドシート部品としてごく一般的な作りです。つまりこの比較は、事実上標準的な設計との比較にあたります。

計測環境: AMD Ryzen 9 9900X / Windows 11 / .NET 10.0.10 / Workstation GC / 3回計測の中央値(2026-08-25 実測)

計測ReoGrid V5従来設計(ReoGrid V4)
1,000万セル(20万行×50列・数値)の保持16.4 B/セル(156 MB)298.2 B/セル(2.78 GB)18.2×
同・書き込みにかかる時間727 ms8.9 秒12.2×
1,000万セル(テキスト200種)の保持16.4 B/セル234.2 B/セル14.3×
2,000万セル(100万行×20列)の保持312 MB5.54 GB18.2×
1,048,576行のシートで列全体に書式適用0.89 ms10 ms11.1×
1,000万セルへの書式適用(ピークメモリ)235 MB4.25 GB18.5×

同じデータを、18分の1のメモリで持てます。 100万行×20列のシートは従来設計では5.5GBを要し、事実上サーバー級のメモリが必要でした。V5 では312MBです。

※ 計測は従来設計にとって最良の条件で行っています(一括投入時は、V4 自身が案内しているイベント抑止・数式再計算オフの経路を使用)。ここに出ている差は実装の粗さではなく、設計世代の違いです。V4 は現役の製品として販売と保守を継続します。

文字列はインターンによって数値と同じコストに落ち着きます。スタイルも同様で、200万セルに同じ書式を当てても、保持されるスタイルインスタンスは1個です。

最悪ケースである「シート全域に一様にセルが散らばる」パターンでも23.4バイトに収まっている点が重要です。単純なブロック構造ではこのパターンで146バイトまで膨らむ(=従来と同水準に戻る)ことが検証段階で判明したため、疎な領域は疎なまま持ち、密になった時点で昇格する適応型ブロックを採用しました。どんなデータの並び方でも、同じ速さが出ます。


なぜ速いのか ② — シートのサイズではなく、可視領域だけが処理対象

軽い荷物を、必要な分だけ運ぶ。これが2つ目の柱です。

スプレッドシートの体感を決めるのは、メモリの総量よりも毎フレーム何をしているかです。スクロール中にわずかでもメモリを確保すれば、それはやがてガベージコレクションになり、フレーム落ちとして指に返ってきます。

V5 は、可視領域(ビューポート)を読み取る経路を完全にゼロアロケーションで通しました。

20万行 × 50列のシートで、60行 × 40列の窓を1,000回読み取った実測値です(2026-08-25 / Workstation GC)。

1回の読み取りあたりReoGrid V5従来設計(ReoGrid V4)
時間30.4 µs95.4 µs3.1×
確保メモリ1.2 B90.8 B78.8×

※ V5 の 1.2 B は計測ハーネスがプロセス全体で観測した値です。読み取り経路自体の確保は 0 バイトで、スレッド単位の計測(ストア単体ベンチ、ServerGC・16.9 µs/read)で確認しています。

シートが1,048,576行と宣言されていても、読み取りのコストは窓の大きさだけで決まります。スクロール中に出るゴミは0バイトなので、GC は静かなまま。スクロールバーを端まで放り投げるように動かしても、指の動きにそのまま追従します。

そして、行数を10行から100万行に増やしても、1フレームあたりの仕事量は同じです。データが増えたぶんだけ重くなる、という関係そのものを V5 は断ち切りました。


なぜ速いのか ③ — 細部まで、同じ原則で貫いた

ここが V5 で最も手をかけた部分です。「レンダラが仮想化されている」製品はよくあります。実際の業務アプリで詰まるのは、たいていその周辺です。V5 では、シート全体を走査しうる処理を一つずつ設計し直しました。

  • 条件付き書式 — ルールの評価は可視セルだけに対して行います。範囲の統計値(最小・最大・平均・順位)はフレーム単位でキャッシュするため、100万行にカラースケールを設定したまま、軽くスクロールできます
  • セル型(チェックボックス・ドロップダウン等) — セルごとにインスタンスを持つ設計から、範囲スコープのフライウェイトへ。100万行のチェックボックス列が、エントリ1件と共有ディスクリプタ1個で表現されます。描画とクリック判定も可視範囲だけです。
  • 交互行スタイル(しま模様) — シートが縞の定義を1つ持ち、描画のたびに解決します。100万行を縞にしてもオブジェクトは1個。ソート・フィルタ・行挿入を通しても、縞はそのまま保たれます。
  • 行・列全体への書式変更 — 行/列の既定スタイルに振り分けるため、コストはセル数ではなく行数・列数に比例します。1,048,576行のシートで列全体に色を付けても、実測0.89ミリ秒です。
  • 検索・置換 — ストアの256行チャンク単位で、値の入っているセルだけを歩きます。100万行と宣言されたシートでも、かかるのは中身の分だけです。
  • XLSX 読み込み — ストリーミング読み込みにより、消費メモリはシートの宣言サイズではなく実在セル数に比例します。
  • 列幅の自動調整(AutoFit) — 測定対象は使用範囲だけ。空の100万行は最初から視界の外です。

一つ一つは地味な実装です。けれど全部が揃って初めて「100万行を普通に扱える」という体験になります。V5 が最も時間をかけたのは、この一貫性の部分です。


他のライブラリと並べる — 同じファイルを、同じマシンで

数値は、比較対象があってはじめて意味を持ちます。.NET の主要なオープンソース スプレッドシートライブラリと、同一マシン・同一ランタイム・同一の入力ファイルで並べて計測しました。

入力の xlsx は、比較対象のどれにも依存しない中立な生成器で作っています。いずれかのライブラリで生成すると、そのライブラリの読み込み経路に最も都合の良い形になってしまうためです。読み込んだ値は複数箇所で期待値と突き合わせているので、「速いが中身が空」という結果が上位に来ることはありません。

計測環境: AMD Ryzen 9 9900X / Windows 11 / .NET 10.0.10 / Workstation GC / 3回計測の中央値(2026-08-25 実測) 対象ファイル: 20万行 × 10列(200万セル)の xlsx

ライブラリ保持方式読み込み時間保持メモリ
ReoGrid V5セルモデル1.9 秒129 MB
ReoGrid V4セルモデル2.7 秒521 MB
NPOI 2.7.4(XSSF)セルモデル4.3 秒631 MB
ClosedXML 0.105セルモデル3.6 秒165 MB
EPPlus 4.5.3.3セルモデル1.8 秒168 MB
NanoXLSX 2.5セルモデル11.8 秒281 MB
MiniExcel 1.41ストリーミング2.0 秒89 MB

セルモデルを保持するライブラリの中で、V5 は読み込み時間・保持メモリともに最小です。

正確を期すために2点を補足します。EPPlus 4.5 は読み込み時間ではほぼ同等(1.8秒)ですが、保持メモリは V5 の約1.3倍です。MiniExcel は保持メモリが89MBと最小ですが、これは行を流して捨てるストリーミング読み取りで、読み込んだ後にセル単位でアクセスできる状態にはなりません。用途が異なるため、同じ土俵の比較ではありません。

読み込んだ「あと」の使い勝手も測りました。ランダムなセルへのアクセスを1万回行うと、V5 が 0.3 µs/回で最も高速です(V4 0.5、ClosedXML 0.6、NanoXLSX 0.9、NPOI 1.1、EPPlus 1.5 µs)。ファイルを開く速さと、開いたあとの速さは別の話です。V5 はどちらも取ります。

なお、商用のグリッド製品との比較は掲載しません。各社の利用許諾にはベンチマーク結果の公表を禁じる条項があるのが通例のためです。ここに挙げたライブラリはいずれもオープンソースで、結果の公表に制限がありません。


完成度 — Excel と同じ土俵で

大規模データ対応と機能の充実は、しばしばトレードオフになります。V5 は両方を同時に実現しました。以下はすべて、上記の仮想化と両立しています。

数式エンジン 約85関数、Kahn 法による依存関係の再計算、行・列の挿入削除に追従する参照シフト。=Sheet2!A1 のようなクロスシート参照、'My Sheet'!A1:B2 形式、ブック/シートスコープの定義名(名前付き範囲)に対応します。

書式 Excel の書式コードをそのまま解釈する数値書式エンジン(セクション・条件・色)。条件付き書式は OOXML 準拠のフルセット — セル値・数式・文字列一致・カラースケール(2色/3色)・データバー・上位下位・平均比較・重複/一意、そしてアイコンセット(矢印・旗・信号・評価・星など標準セット全種)まで実装し、XLSX と往復します。

業務で必要になるもの Undo / Redo、複数キーソート、オートフィルタ(条件フィルタ含む)、データの入力規則、シート保護とセル単位のロック、セルのメモ、オートフィル、テキスト回転・インデント・縦書き、フリーズ枠、アウトライン、ズーム(10〜400%)。

印刷とエクスポート A5〜A3・B5・B4・Letter・Legal・Tabloid・Executive の用紙、余白、拡大縮小、ページに合わせる(fit-to-page)、印刷タイトルの繰り返し、Excel の &P &D 形式に対応したヘッダー/フッター。画面・プリンタ・PDF が同一のページ分割エンジンを共有するため、プレビューと印刷結果と PDF は常に一致します。

入出力 XLSX(依存ライブラリゼロ・ストリーミング読み込み)、PDF(依存ライブラリゼロ・日本語フォント埋め込み済みで出力後も検索とコピーが可能)、reogrid-json(ReoGrid Web とバイト互換)、CSV。

品質の裏付けとして、コアには 940件の自動テストが常時グリーンの状態で付随しています。


導入しやすさも、設計項目です

  • 1パッケージ = 1 DLL、NuGet 依存ゼロ。 コア・入出力・UI をすべて含んだ自己完結アセンブリを、参照1つ追加するだけで導入できます(Avalonia 版のみ、利用側と同じ Avalonia にバインドするため Avalonia を参照します)。
  • WinForms / WPF / Avalonia の3プラットフォーム。 Avalonia 対応により、Windows / macOS / Linux で同じコードが動きます。
  • UI 非依存のヘッドレス版 も提供します。XLSX を読み込んで PDF を生成する処理は、サーバー上だけで完結します。
  • 対応ランタイムは .NET 10 以降
パッケージ用途
unvell.ReoGrid.OneWinForms
unvell.ReoGrid.One.WpfWPF
unvell.ReoGrid.One.AvaloniaAvalonia(Windows / macOS / Linux)
unvell.ReoGrid.One.Coreヘッドレス(UI なし)

ライセンス — 1本で、全バージョン・全プラットフォーム

V5 は製品 ReoGrid® One として提供します。ライセンス体系はシンプルです。

  • 買い切りの永続ライセンス + 任意の年間更新。 サブスクリプションではなく、一度のご購入で永続的にご利用いただけます。
  • バージョン非依存・プラットフォーム非依存。 V4 用に発行済みのキーが、そのまま V5 で通ります。1本のライセンスで WinForms / WPF / Avalonia / ヘッドレスすべてをカバーします。
  • 年間更新の状態にかかわらず、お手元のバイナリは永久に動作します。 出荷済みアプリケーションの配布もそのまま継続できます。年間更新が及ぶ範囲は、新しいビルドの入手権と公式サポートの2つです。
  • ランタイムはロイヤリティフリー。 ライセンスが必要なのは開発者様のみで、エンドユーザー様はそのままご利用いただけます。

長期運用が前提の基幹システムに組み込んでいただく以上、「支払いを止めたら出荷済みの製品が止まる」設計を避け、手元のバイナリが永久に動く形を選びました。この方針はこれからも守ります。

なお、ライセンス未適用の状態でも、表示・スクロール・印刷・エクスポートはすべて動作します(描画に透かしが入り、編集が無効になります)。そのまま評価いただける形にしていますので、まずはお試しください。


10年以上の実績の、延長線上にあります

ReoGrid は2014年の登場以来、日本・アメリカ・ドイツを含む12カ国以上のプロジェクトで採用され、NuGet 経由の累計ダウンロードは 180,000件を超えました。金融システムのように信頼性が重視される領域での導入実績もあります。

V5 の設計判断の多くは、机上の理想ではなく、この10年間に現場からいただいたご指摘の蓄積から生まれています。「数十万行を読み込むと固まる」「条件付き書式を設定した帳票にデータを流し込むと待たされる」「Excel で作ったファイルを開くと書式が落ちる」— こうした声の一つ一つが、V5 のどの構造をどう作るかを決めました。

完全仮想化を設計の一行目に置いたのも、流行の技術だからではなく、お客様が実際に困っていた場所が、すべて同じ根に繋がっていたからです。

ReoGrid は日本国において登録商標です(登録第7052809号)。


V4 をご利用中のお客様へ

V5 は API 互換性を持たない全面書き直しです。そのため、V4 の販売と保守はこれまでどおり継続します。 移行の時期は、お客様のご都合で決めていただけます。

  • V4 と V5 は別の NuGet パッケージ ID で配信します。バージョンを上げても、既存プロジェクトのビルドはそのまま通ります。
  • 契約は1本のままです。 ReoGrid One のライセンスをお持ちであれば、同じライセンスで V4 も V5 もご利用いただけます。
  • チャート、図形オブジェクト、多段(複数行)列ヘッダーは V5 の初回リリース対象外です。これらをお使いの場合は、引き続き V4 をご利用ください。V5 への実装はご要望を伺いながら進めます。

まずは、お手元のデータで試してください

性能は、カタログの数字ではなく、実際のデータで確かめていただくのが確実です。評価版はそのまま起動して動作しますので、いま一番重いワークブックを読み込んで、スクロールしてみてください。指に返ってくる感触が、この記事のどの数字よりも雄弁です。

導入のご検討にあたり、性能検証用のサンプルデータでの評価や、既存 V4 プロジェクトからの移行に関するご相談も承っております。お気軽にお問い合わせください。