POIからDsExcelへ：SpreadJS連携ガイド

1. はじめに：なぜ再び「エクセル（Excel）」なのか？

企業向けエンタープライズソリューションの開発において、最も一般的でありながら難易度の高い要件の一つが、間違いなく **「エクセル（Excel）処理」**です。実務の現場にいるユーザーは、Web画面で華やかなダッシュボードを見るだけでなく、複雑な多重ヘッダーグリッドデータを照会し、グループ別のツリー構造で書式設定されたテンプレートをダウンロードしてオフラインで作業した後、それを再びシステムへ一括アップロードすることを望んでいます。

長い間、Javaバックエンドのエコシステムにおけるエクセル処理の標準は、事実上Apache POIでした。オープンソースエコシステムにおける豊富なリファレンスと無料であることの圧倒的な利点により、ほとんどのプロジェクトはPOIから始まります。しかし、次のような複雑なビジネス要件が組み合わさると、開発チームは巨大な技術的障壁に直面することになります。

• **複雑な階層型多重ヘッダー（Multi-Header）**とツリー構造を持つグループ・フィールドテンプレートの生成

• Web UIで SpreadJSのような超高性能スプレッドシートコンポーネントを導入した際に発生する、バックエンド間の書式・データ同期のずれ

• 単純な値の入出力にとどまらない SUMPRODUCT、DSUMなどの高度な統計・数式計算エンジンのサーバーサイドでのリアルタイム評価

• 数万～数十万行のデータを処理する際に発生する JVM OutOfMemoryError(OOM)およびGCスパイク

本稿では、Apache POI環境で経験した実際の限界を確認し、**DsExcel（Document Solutions for Excel、旧GcExcel）**を導入してアーキテクチャを革新した経験を共有します。特にフロントエンドの SpreadJSとのネイティブJSON連携によるシナジー、そして過去にドメインモデリングおよびデータ設計の過程で徹底的に検討した ツリー構造テンプレートのインポート、多重ヘッダーグリッドのエクスポート、複雑な数式の処理戦略について、コードおよびアーキテクチャレベルで詳しく解説します。

2. バックエンドのエクセルエンジン徹底比較：Apache POI vs DsExcel

バックエンドでエクセルライブラリを選択する際に考慮すべき主な軸は、 メモリアーキテクチャ、数式計算エンジン、テンプレートの生産性、そしてライセンス費用です。

2.1 アーキテクチャおよびメモリ管理モデル

Apache POIの二面性（XSSFWorkbook vs SXSSFWorkbook）

• XSSFWorkbook（DOMモデル）： エクセルファイル（XLSX）のすべてのシート、行、セル、スタイルオブジェクトを、完全なオブジェクトグラフとしてJVMヒープメモリにロードします。データが数万件を超えると、1つのセルごとに多数のJava Wrapperオブジェクトが生成されるため、メモリ使用量が幾何級数的に増加し、すぐにOOMが発生します。

• SXSSFWorkbook（ストリーミングウィンドウモデル）： OOMを克服するため、メモリにはスライディングウィンドウ（例：直近100行）だけを保持し、残りはディスク上の一時ファイルへフラッシュする方式です。しかし、 重大な制約が伴います。

• 通過した行を修正したり、逆方向にアクセスしたりすることはできません。

• セル結合（Merged Region）や階層型ヘッダーを動的に再計算することは非常に困難です。

• シート間の相互参照数式の計算やピボットテーブルのサポートは、ほぼ不可能です。

• テンプレートベースのレポート生成では、既存テンプレートの書式を読み取りながらストリーミングで書き込む処理（Read-Write Template）を並行して行うことが困難です。

DsExcelの高性能エンジンアーキテクチャ

• DsExcelは、Microsoft Excelの計算エンジンと内部データ構造を完全に模倣しながら、Java/.NET環境向けに高度に最適化されたメモリマッピング構造を備えています。

• ポインターおよびプリミティブ配列ベースのメモリ軽量化： POIのようにセルごとに重量級のインスタンスを無制限に生成するのではなく、データとスタイルを内部インデックスベースでキャッシュすることで、ヒープ使用量をPOIと比較して1/5～1/10の水準に抑えます。

• 一時ディスクI/Oなしで、数十万行を超える大容量ワークブックも、純粋なインメモリ上で高速に生成・解析できます。

2.2 数式評価エンジン（Formula Calculation Engine）の違い

実務で頻繁に要求されるSUMPRODUCT、DSUM、INDEX/MATCH、XLOOKUP、そして動的配列（Spill）数式の処理は、エンジンの完成度を左右する決定的な指標です。

• Apache POI： FormulaEvaluatorが組み込まれていますが、サポートされている関数の一覧は限られています。特に複数条件の配列演算を行うSUMPRODUCTや、データベース関数系（DSUM、DCOUNT）を評価する際、実装が欠落していたり、複雑な括弧のネスト解析でNotImplementedExceptionをスローしたりするケースが頻繁にあります。

• DsExcel： Microsoft Excel仕様に100%互換する独自の高性能数式演算エンジンを内蔵しており、450以上のエクセル標準関数をオフライン（サーバーサイド）で完全に計算します。Excel DesktopやOffice Interop（Interop）のインストールなしでも、完全な数式の整合性を保証します。

2.3 テンプレートバインディングの生産性

• POI方式： デザイン済みのエクセル書式を読み込んだ後、開発者が行・列のインデックスを一つずつカウント（rowNum++、cellNum++）し、スタイル、フォント、罫線、背景色をJavaコードで注入する必要があります。企画担当者やデザイナーが書式を1行変更しただけでも、バックエンドのインデックス計算ロジック全体が壊れてしまいます。

• DsExcel方式： 強力な 宣言型テンプレートエンジンを標準で提供します。Excelファイル自体に{{ds.fieldName}}、{{ds.group(R=T)}}のような構文を記述しておけば、バックエンドでは単純にJava POJOやJSONデータセットを渡すだけで、繰り返し行の拡張、小計／合計の挿入、動的なセル結合が自動的に完了します。

2.4 総合比較マトリックス

3. Front-End（SpreadJS）とのシナジー：完全なフルスタックExcelパイプライン

フロントエンドのグリッドコンポーネントとしてMESCIUSの SpreadJSを採用しているシステムであれば、バックエンドエンジンとしてDsExcelを選択することは、単なる代替案ではなく必須の設計です。

3.1 無損失のネイティブJSON交換（Zero-Fidelity Loss）

一般的に、Web画面（グリッド）の内容をサーバー側のExcelにエクスポートまたはインポートするには、次のような複雑なボトルネックの工程を経る必要があります。

• 従来方式（SpreadJS + Apache POI）：

a. クライアント（SpreadJS）でXLSXバイナリblobを生成

b. ネットワーク経由で数MBのバイナリを転送

c. バックエンドでPOIがZIPを解凍し、数千個のXMLファイルを解析

d. 変更後、再びZIPに圧縮してクライアントに返却

-問題点： CPU過負荷、転送帯域幅の浪費、さらにPOIが解釈できない高度なCSS／テーマ／条件付き書式の消失が発生します。

• モダンアーキテクチャ（SpreadJS + DsExcel）：

-SpreadJSとDsExcelは、**同一のデータスキーマとJSON仕様（SpreadJS JSON Format）を共有します。**

-クライアントはグリッドのシリアライズ済みJSON文字列（spread.toJSON()）だけを送信します。

-バックエンド（DsExcel）は、わずか1行でこれを読み込みます。

Workbook workbook = new Workbook();
workbook.fromJson(spreadJsonString);

-サーバー上でビジネスロジックの演算、大量データのマージ、マスキング処理を実行した後、再びworkbook.toJson()で返却するか、最終配布用の.xlsxまたは.pdfファイルとして即座にレンダリングします。

3.2 スタイル、多重結合、条件付き書式の無損失保持

SpreadJSでユーザーが設定した多段ヘッダースパン（Span）、フォント階層、データバー（Data Bar）、カラースケール、ドロップダウンの入力規則が、バックエンドのDsExcelに100%同一の状態で反映されます。POIを使用する場合に、CellStyleを一つずつマッピングし、インデックスのオーバーフローを心配しなければならなかった構造上の問題は完全に解消されます。

4. 実践事例研究：複雑なエンタープライズドメインの課題解決

4.1 ケース1：多段ヘッダー（Multi-Header）階層型Webグリッドの無損失Excel入出力

• 問題の定義：画面のWebグリッドには、3段階以上のグループ化されたヘッダー構造があります。これをPOIで処理するには、CellRangeAddressを使用して横方向・縦方向の結合座標を再帰的に計算する必要があり、列が動的に変更されると座標がずれてしまいました。

• DsExcel + SpreadJSによる解決策：SpreadJSのColumn Header構造をそのままfromJsonでDsExcelに渡すことで、内部の結合座標を完全に維持できます。サーバーとフロントエンド間のヘッダースキーマの不一致が解消されました。

4.2 ケース2：ツリー構造（Tree-structure）のグループ・フィールドデータインポートテンプレート

• 問題の定義：大分類の下に中分類があり、その下に動的な属性フィールドがツリー構造でまとめられたエンティティモデルでした。

• DsExcelテンプレートエンジンの適用：テンプレートXLSXに{{ds.groupName(M=T)}}のような宣言型マーカーを設定し、データセットを渡すだけで、動的な行の拡張とセル結合を自動化しました。手動でのポインター計算ロジックが不要になり、保守性が最大限に向上しました。

4.3 ケース3：高度な数式（SUMPRODUCT、DSUM）の処理およびサーバーサイド演算

• 問題の定義：アップロードされたファイルの複雑な条件付き加重計算の結果を、サーバー上ですぐに検証する必要がありました。

• 解決策：DsExcelのworkbook.calculate()を呼び出し、組み込みのExcel互換エンジンにすべての依存セルを特定させて正確な結果を導出することで、数学的ロジックをJavaコードで再実装する二重作業を回避しました。

4.4 ケース4：添付ファイルおよびデータ管理ドメインモデルのアーキテクチャ

• アーキテクチャ設計：大容量処理時のHTTPスレッド枯渇を防ぐため、非同期キューパイプライン（Spring Task / RabbitMQ）を導入し、try-with-resourcesによってDsExcelのワークブックリソースを直ちに解放することで、JVMメモリを安定して管理しました。

5. 実践コードウォークスルー：POIとDsExcel

5.1 Apache POIの実装例（手動による座標マッピング）

Workbook poiWorkbook = new XSSFWorkbook();
Sheet sheet = poiWorkbook.createSheet("계층형데이터");
Row headerRow1 = sheet.createRow(0);
headerRow1.createCell(0).setCellValue("조직 인프라 정보");
sheet.addMergedRegion(new CellRangeAddress(0, 0, 0, 1));
int rowIndex = 2;
for (DepartmentDto dto : dataList) {
    Row row = sheet.createRow(rowIndex++);
    row.createCell(0).setCellValue(dto.getDivision());
    // ... 인덱스 수동 관리 및 스타일 설정 생략
}

5.2 DsExcel + SpreadJSパイプラインの実装例

public byte[] generateExcelWithDsExcel(String spreadJsJson, List<DepartmentDto> dataList) {
    try (Workbook workbook = new Workbook()) {
        workbook.fromJson(spreadJsJson); // 프론트 디자인 로드
        IWorksheet sheet = workbook.getActiveSheet();
        sheet.addDataSource("dept", dataList); // 데이터 바인딩
        workbook.calculate(); // 수식 재계산

        ByteArrayOutputStream out = new ByteArrayOutputStream();
        workbook.save(out, SaveFileFormat.Xlsx);
        return out.toByteArray();
    }
}

6. 結論および導入意思決定ガイド

6.1 POIを継続して使用してもよいケース

• 単純な1次元テーブル形式の生データエクスポート

• 固定フォーマットの小規模なExcelファイルの生成（数千件以下）

• 追加のライセンス費用を投資できないオープンソースプロジェクト

6.2 DsExcelへの移行を強く推奨するケース

• SpreadJSを導入して完全なWYSIWYG環境が必要なプロジェクト

• 複雑な複数ヘッダー、ツリー型データ、結合セルを多数含むテンプレートの管理

• SUMPRODUCT、XLOOKUPなどの高度な数式について、サーバーサイドでの信頼性評価が必要な場合

• POIのOOM障害により、大容量処理時のシステム安定性が脅かされている場合

おわりに

現代のエンタープライズアーキテクチャにおいて、Excelは単なるファイルではなく、主要なビジネスルールの集合体です。DsExcelとSpreadJSの組み合わせは、開発者に座標計算の手作業から解放され、ビジネスロジックに集中できる自由をもたらすでしょう。

BigJumbo