
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,000 | 155 MB | 16.3 B |
| 密 200,000行 × 50列(テキスト200種) | 10,000,000 | 155 MB | 16.3 B |
| 密 200,000行 × 50列 + 5スタイル | 10,000,000 | 194 MB | 20.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 ms | 8.9 秒 | 12.2× |
| 1,000万セル(テキスト200種)の保持 | 16.4 B/セル | 234.2 B/セル | 14.3× |
| 2,000万セル(100万行×20列)の保持 | 312 MB | 5.54 GB | 18.2× |
| 1,048,576行のシートで列全体に書式適用 | 0.89 ms | 10 ms | 11.1× |
| 1,000万セルへの書式適用(ピークメモリ) | 235 MB | 4.25 GB | 18.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 µs | 95.4 µs | 3.1× |
| 確保メモリ | 1.2 B | 90.8 B | 78.8× |
※ V5 の 1.2 B は計測ハーネスがプロセス全体で観測した値です。読み取り経路自体の確保は 0 バイトで、スレッド単位の計測(ストア単体ベンチ、ServerGC・16.9 µs/read)で確認しています。
シートが1,048,576行と宣言されていても、読み取りのコストは窓の大きさだけで決まります。スクロール中に出るゴミは0バイトなので、GC は静かなまま。スクロールバーを端まで放り投げるように動かしても、指の動きにそのまま追従します。
そして、行数を10行から100万行に増やしても、1フレームあたりの仕事量は同じです。データが増えたぶんだけ重くなる、という関係そのものを V5 は断ち切りました。
ここが V5 で最も手をかけた部分です。「レンダラが仮想化されている」製品はよくあります。実際の業務アプリで詰まるのは、たいていその周辺です。V5 では、シート全体を走査しうる処理を一つずつ設計し直しました。
一つ一つは地味な実装です。けれど全部が揃って初めて「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 はどちらも取ります。
なお、商用のグリッド製品との比較は掲載しません。各社の利用許諾にはベンチマーク結果の公表を禁じる条項があるのが通例のためです。ここに挙げたライブラリはいずれもオープンソースで、結果の公表に制限がありません。
大規模データ対応と機能の充実は、しばしばトレードオフになります。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件の自動テストが常時グリーンの状態で付随しています。
Avalonia を参照します)。| パッケージ | 用途 |
|---|---|
unvell.ReoGrid.One | WinForms |
unvell.ReoGrid.One.Wpf | WPF |
unvell.ReoGrid.One.Avalonia | Avalonia(Windows / macOS / Linux) |
unvell.ReoGrid.One.Core | ヘッドレス(UI なし) |
V5 は製品 ReoGrid® One として提供します。ライセンス体系はシンプルです。
長期運用が前提の基幹システムに組み込んでいただく以上、「支払いを止めたら出荷済みの製品が止まる」設計を避け、手元のバイナリが永久に動く形を選びました。この方針はこれからも守ります。
なお、ライセンス未適用の状態でも、表示・スクロール・印刷・エクスポートはすべて動作します(描画に透かしが入り、編集が無効になります)。そのまま評価いただける形にしていますので、まずはお試しください。
ReoGrid は2014年の登場以来、日本・アメリカ・ドイツを含む12カ国以上のプロジェクトで採用され、NuGet 経由の累計ダウンロードは 180,000件を超えました。金融システムのように信頼性が重視される領域での導入実績もあります。
V5 の設計判断の多くは、机上の理想ではなく、この10年間に現場からいただいたご指摘の蓄積から生まれています。「数十万行を読み込むと固まる」「条件付き書式を設定した帳票にデータを流し込むと待たされる」「Excel で作ったファイルを開くと書式が落ちる」— こうした声の一つ一つが、V5 のどの構造をどう作るかを決めました。
完全仮想化を設計の一行目に置いたのも、流行の技術だからではなく、お客様が実際に困っていた場所が、すべて同じ根に繋がっていたからです。
ReoGrid は日本国において登録商標です(登録第7052809号)。
V5 は API 互換性を持たない全面書き直しです。そのため、V4 の販売と保守はこれまでどおり継続します。 移行の時期は、お客様のご都合で決めていただけます。
性能は、カタログの数字ではなく、実際のデータで確かめていただくのが確実です。評価版はそのまま起動して動作しますので、いま一番重いワークブックを読み込んで、スクロールしてみてください。指に返ってくる感触が、この記事のどの数字よりも雄弁です。
導入のご検討にあたり、性能検証用のサンプルデータでの評価や、既存 V4 プロジェクトからの移行に関するご相談も承っております。お気軽にお問い合わせください。