大規模データセット向けXLSB vs XLSX：開発者のパフォーマンスガイド

最終更新: 2026年9月30日

大規模データセット向けXLSB vs XLSX：開発者のパフォーマンスガイド

データパイプラインやバックエンドのレポートエンジン、Microsoft Excel と連携する分析ツールを構築している場合、“壁"にぶつかったことがあるでしょう。

ユーザーが45万行のワークブックをアップロードします。サーバーはワーカースレッドを起動し、メモリ使用量はギガバイト単位に急増し、ガベージコレクションがランタイムをフリーズさせ、実行がタイムアウトします。ペイロードを確認すると、標準的な .xlsx ファイルです。

これを解決するために、開発者はチャンク化やストリーミングパーサの実装、またはファイルをバックグラウンドワーカーにオフロードする作業に数日を費やすことがよくあります。しかし、最も効果的な最適化の一つは、アーキテクチャの再設計を一切必要とせず、ファイル拡張子を .xlsx から .xlsb に変更することです。

本ガイドでは、両フォーマットの内部構造を詳しく解析し、なぜ内部アーキテクチャが性能特性に大きな違いをもたらすのかを検証し、Python と .NET の具体的なベンチマークを比較し、プロダクションでバイナリワークブックを展開するタイミングに関する明確なルールを示します。

1. 内部構造：OpenXML vs. BIFF12

大規模データセットで性能が劇的に異なる理由を理解するためには、各フォーマットがディスク上にレコードをどのように保存しているかを確認する必要があります。

       ┌────────────────────────┐         ┌────────────────────────┐
       │     sample.xlsx        │         │      sample.xlsb       │
       │ (ZIP Archive Wrapper)  │         │ (ZIP Archive Wrapper)  │
       └───────────┬────────────┘         └───────────┬────────────┘
                   │                                  │
       ┌───────────▼────────────┐         ┌───────────▼────────────┐
       │   sheet1.xml (UTF-8)   │         │    sheet1.bin (BIFF12) │
       │  Verbose ASCII Tags    │         │ Structured Byte Stream │
       │  <c r="A1"><v>42</v>   │         │ [Opcode][Len][Payload] │
       └────────────────────────┘         └────────────────────────┘

Both .xlsx and .xlsb files are compressed ZIP containers conforming to the Open Packaging Conventions (OPC). If you rename either file to .zip and extract it, you will see a familiar directory layout: _rels, docProps, and xl/worksheets/.

xl/worksheets/ フォルダー内に重要な違いがあります：

• XLSX はシートをプレーンな XML テキスト（sheet1.xml）として保存します。
• XLSB はシートを独自のバイナリストリーム（sheet1.bin）として保存し、Microsoft の BIFF12（Binary Interchange File Format 12）でエンコードされます。

XLSX がデータをエンコードする方法 (XML DOM オーバーヘッド)

XLSX ワークシートでは、すべてのセルが明示的な XML タグで宣言されています：

<row r="1" spans="1:2">
    <c r="A1" t="s">
        <v>142</v>
    </c>
    <c r="B1">
        <v>98234.55</v>
    </c>
</row>

この行を読み取る際、実行時は次のことを行う必要があります：

1. 生の deflate ストリームをテキストに解凍する。
2. 文字列文字をトークン化し、XML DOM または SAX イベントストリームに解析する。
3. 開始タグと終了タグ（<c>、</c>、<v>、</v>）を検証します。
4. sharedStrings.xml テーブルから文字列参照を解決します。
5. ASCII テキスト \"98234.55\" を IEEE 754 64 ビット浮動小数点数に解析します。

各セルは文字列の解析、文字列の割り当て、字句解析のために CPU のオーバーヘッドが発生します。これを 500,000 行と 30 列（1500 万セル）に掛け合わせると、CPU はドメイン値の処理よりも構文解析にはるかに多くのサイクルを費やします。

XLSB がデータをエンコードする方法 (BIFF12 バイナリストリーム)

BIFF12 はテキストのシリアライズを完全に廃止します。文字列マークアップの代わりに、データは可変長バイナリレコードの連続シーケンスとして配置されます：

[Record Type: 2 bytes] [Record Length: 4 bytes] [Payload: N bytes]

BIFF12 の浮動小数点セルは \"98234.55\" のような文字列表現を使用しません。直接的に表現されます：

• レコード ID 用に 2 バイト（例: BrtCellRk または BrtCellReal）
• 列/行インデックス用に 4 バイト
• 生の IEEE 754 倍精度バイト構造を含む 8 バイト

パーサが XLSB ファイルを読み込むと、字句解析を完全にバイパスします。レコードヘッダーを読み取り、バッファから 8 バイトの生データを取得し、メモリに直接コピーしてポインタを進めます。検証すべきタグはなく、文字列から数値への型変換もなく、数値データに対する UTF-8 デコードのオーバーヘッドはゼロです。

2. 定量ベンチマーク: ディスク、メモリ、スループット

実際の影響を示すために、750,000 行と 25 列（タイムスタンプ、浮動小数点数、整数、カテゴリコードの混合）を含むシミュレートされたデータセットを考えてみましょう。

以下のテストは、同一の表形式データを XLSX と XLSB の両方で保存した場合の評価を行います。

テスト環境

• CPU: AMD Ryzen 9 5900X（12 コア、24 スレッド）
• RAM: 64 GB DDR4-3600
• Storage: PCIe 4.0 NVMe SSD
• Runtime: Python 3.11（openpyxl、pyxlsb、calamine）および .NET 8（ExcelDataReader、ClosedXML）

主要パフォーマンス指標

XLSB ファイルが小さい理由

両方の形式は標準のZIP圧縮を使用していますが、バイナリストリームは肥大化したXMLテキストよりもはるかに効率的に圧縮されます:

1. 冗長な構文が排除されます: XMLは各レコードに繰り返しのタグ（<c r=\"AA1\" s=\"1\">）が含まれています。ZIP圧縮は繰り返し文字列を軽減しますが、圧縮されていないデータストリームは膨大です。
2. 数値密度: XMLでは、数値 12345678.9012 は14バイトのASCIIテキストが必要です。BIFF12では、8バイトの倍精度浮動小数点として保存されます（または、特定の精度ルールに合致すれば4バイトの RK レコードにパックされます）。

3. メモリフットプリントとガベージコレクションの負荷

Webサービスやマイクロサービスで同時リクエストを処理する場合、CPU速度は戦いの半分に過ぎません；メモリフットプリント が実際にアプリケーションが失敗するポイントです。

XLSX Parsing Heap Profile:
[ String Buffer ] -> [ Tokenizer ] -> [ XML DOM Nodes ] -> [ Object Boxing ]
▲ Massive Gen 0/1 heap allocation -> Triggers aggressive Garbage Collection

XLSB Parsing Heap Profile:
[ Byte Buffer ] -> [ Fixed Struct Copy ] -> [ Destination Array ]
▲ Minimal allocations -> Low GC overhead

XMLパーサが100 MBのXLSXファイルを処理する際、数千の一時的な文字列トークン、文字列スライスバッファ、辞書ルックアップを作成しなければなりません。ガベージコレクション付き言語（Java、C#、Go、Node.js、Python）では、これによりヒープの断片化が極端になり、ランタイムが頻繁なガベージコレクション（GC）停止に追い込まれます。

XLSB のパースは固定幅バイトスライス上で直接動作するため、パーサはデータをスタック割り当ての構造体や再利用可能なバイトバッファに読み込むことができます。その結果、メモリフットプリントが劇的に削減され、ランタイムアロケータのスラッシングがゼロになります。

4. 開発者実装例

一般的な開発者ツールチェーンで XLSB を活用する方法を見てみましょう。

Python: OpenPyXL から Calamine / PyXLSB への移行

標準の pandas.read_excel('data.xlsx') はデフォルトで openpyxl を使用し、重いインメモリツリーを構築します。

大きな XLSB ファイルを最大速度で処理するには、Rust 製の calamine エンジンを使用します（python-calamine 経由で利用可能で、最新の Pandas に統合されています）：

import pandas as pd
import time

filename_xlsx = "large_dataset.xlsx"
filename_xlsb = "large_dataset.xlsb"

# Reading standard XLSX (uses openpyxl by default)
t0 = time.perf_counter()
df_xlsx = pd.read_excel(filename_xlsx, engine="openpyxl")
print(f"XLSX loaded in {time.perf_counter() - t0:.2f}s")

# Reading XLSB with Calamine (Rust engine)
t0 = time.perf_counter()
df_xlsb = pd.read_excel(filename_xlsb, engine="calamine")
print(f"XLSB loaded in {time.perf_counter() - t0:.2f}s")

データ全体を DataFrame にロードせずに、巨大なデータセットを行単位で反復処理する場合、pyxlsb は軽量なストリーミングイテレータを提供します：

from pyxlsb import open_workbook

total_sum = 0.0

with open_workbook("massive_export.xlsb") as wb:
    with wb.get_sheet(1) as sheet:
        for row in sheet:
            # Cell 0 contains an RK integer or Double float
            val = row[0].v
            if val is not None:
                total_sum += val

print(f"Aggregated Total: {total_sum}")

C# / .NET: 高性能ストリーム取り込み

.NET では、ClosedXML や EPPlus といったライブラリは標準的な生成に適していますが、メモリ枯渇せずに大容量ファイルを取り込む場合、XLSB 対応の ExcelDataReader は非常に高速です：

using System;
using System.IO;
using ExcelDataReader;

public class XlsbProcessor
{
    public static void ProcessBinarySheet(string filePath)
    {
        // ExcelDataReader automatically identifies BIFF12 from file headers
        using var stream = File.Open(filePath, FileMode.Open, FileAccess.Read, FileShare.Read);
        using var reader = ExcelReaderFactory.CreateReader(stream);

        long rowCount = 0;
        double aggregateValue = 0;

        while (reader.Read())
        {
            rowCount++;
            
            // Read column directly without boxing overhead where possible
            if (!reader.IsDBNull(0))
            {
                aggregateValue += reader.GetDouble(0);
            }
        }

        Console.WriteLine($"Processed {rowCount:N0} rows. Sum: {aggregateValue:F2}");
    }
}

5. アーキテクチャ上のトレードオフ: XLSB を使用すべきでない時

圧倒的なパフォーマンス上の利点があるものの、XLSB は万能ではありません。スタック全体で導入する前に、いくつかの運用上のトレードオフを検討すべきです：

                      DECISION MATRIX
                      
               Is file size > 50MB OR 
               rows > 100,000?
                    │
         ┌──────────┴──────────┐
        YES                    NO
         │                     │
   Do third-party        Use standard XLSX
   tools strictly        (Maximum compatibility)
   require OpenXML?
         │
    ┌────┴────┐
   YES        NO
    │         │
Use XLSX   Use XLSB
(Stream)   (Max speed & efficiency)

1. エコシステムとライブラリのサポート

• XLSX: ユニバーサルです。実質的にすべての言語、ライブラリ、SaaSツール（Google Sheets、Airtable、Tableau）およびウェブパーサーがOpenXMLをネイティブにサポートしています。
• XLSB: あまり普及していません。Excel、LibreOffice、そして成熟した開発者向けライブラリ（ExcelDataReader、pyxlsb、calamine、Aspose）はサポートしていますが、多くの軽量パッケージや純粋なウェブベースのJavaScriptパーサー（例えば古いバージョンの SheetJS）は限定的または読み取り専用のサポートしかありません。

2. Git とバージョン管理の差分比較

• XLSX: ZIP コンテナ内にテキスト XML が含まれているため、コマンドラインユーティリティや Git フックで ZIP を解凍し XML を整形して、コミット間の可読性のある構造的差分を生成できます。
• XLSB: 純粋なバイナリデータです。バージョン管理システムはこれを不透明なバイナリブロブとして厳密に扱うため、細かな差分表示や行レベルのマージの可能性がなくなります。

3. Web クライアントのレンダリング

もしアーキテクチャが WebAssembly やクライアントサイド JavaScript を通じてブラウザ内でスプレッドシートを直接レンダリングすることに依存している場合、XLSX パーサーはクライアントサイドのバイナリパーサーに比べてはるかに成熟しており、エッジケースのレンダリングバグが少ないです。

4. サードパーティの取り込みパイプライン

外部の企業クライアント向けにファイルをエクスポートする場合、多くの厳格な企業セキュリティポリシーが .xlsb ファイルをフラグします。BIFF12 ファイルは .xlsm ファイルと同様に VBA マクロを同一に保存でき（別の拡張子は不要）、一部のメールフィルタやファイアウォールスキャナは .xlsb のアップロードをマクロを含む潜在的な脅威として隔離します。

6. 要約比較: どのフォーマットが優位か

7. 開発者の結論

次の場合は XLSX を使用します:

• ファイルはサイズが小〜中程度（< 50,000 行）です。
• ファイルはサードパーティの SaaS プラットフォームや消費者向けアプリ（例：Google Sheets）で取り込まれる必要があります。
• ファイルを読むエンドクライアントの環境を制御できません。

次の場合は XLSB に切り替えます:

• 内部パイプライン、バッチジョブ、ETL システム、または大量のデータ抽出（> 100,000 行）を処理するワーカータスクを構築している場合です。
• サーバーがスプレッドシートのシリアライズまたはデシリアライズ中にメモリ不足（OOM）エラーに直面しています。
• 大規模な定期的な財務モデルやデータエクスポートに対して、S3/Blob ストレージの使用量とネットワーク転送時間を最小化する必要があります。

XLSB への切り替えは、エクスポートサービスの設定文字列を変更するだけで済むことが多いですが、通常は数週間のコード最適化が必要な 3 倍から 5 倍のスループット向上を実現します。

よくある質問 (FAQ)

**Q1: XLSB ファイルは、XLSX ファイルと同じ行と列の上限をサポートしていますか？ はい。XLSB と XLSX はどちらも、ワークシートあたり 1,048,576 行 × 16,384 列という同一のグリッド上限を共有しています。

**Q2: XLSB ファイルは、拡張子を変更せずに VBA マクロを安全に保存できますか？ はい。XLSX がコードを実行するには XLSM として保存する必要があるのとは異なり、XLSB は同じ .xlsb ファイル形式内でバイナリ VBA マクロの保存をネイティブにサポートしています。

**Q3: 両方の形式がすでに ZIP 圧縮されているのに、XLSB として保存するとサイズが小さくなるのはなぜですか？ XLSB は冗長なテキストマークアップタグを排除し、セル位置、レコード、そして生の数値データを、プレーンな XML 文字列よりはるかに高密度に圧縮できるタイトなバイナリバイトストリームにエンコードします。

**Q4: Google Sheets は XLSB ファイルを直接インポートして編集できますか？ いいえ。Google Sheets は .xlsb ファイルを直接開いたり変換したりできないため、インポートする前に .xlsx または CSV に変換する必要があります。

**Q5: XLSB ファイルは XLSX ファイルよりもデータ破損しやすいですか？ XML ファイルは部分的に破損した場合、テキストエディタで手動で検査・修復できることがありますが、バイナリ BIFF12 ストリームは厳密なバイトオフセットが必要で、構造セクタが損傷すると手動での復旧が困難です。

関連項目

• 2026 年の CSV vs XLSX vs ODS：開発者に最適なスプレッドシート形式
• XLS vs XLSX vs XLSM vs XLSB - 正しいスプレッドシート形式の選び方
• Excel とは何か？知っておくべき重要情報
• Excel ファイル形式：XLSX、XLSM、XLS、XLTX、XLTM
• XLS と XLSX の違い