Excelはなぜ5MBで壊れ始めるのか──AccessとCSVで乗り越える構造的限界

## ✅ 第1章：Excelはなぜ遅くなるのか？

Excelは非常に便利なツールだが、一定のデータ規模を超えると保存や入力に遅延が発生し、操作不能に近づいていく。

この遅延は仕様上の「セル数上限」などでは説明できず、実際には<b>ファイルサイズ（概ね5MB前後）</b>が一つの転換点となる。

これは公式では一切解説がないが、以下のような理由による：

- `.xlsx`ファイルはZIP圧縮されたXML構造で構成されており、読み書き時には逐次解凍・再圧縮が発生する。
- 各セルには値だけでなく、スタイル・数式・依存関係・変更履歴などの付加情報が格納されるため、行数や列数以上に「情報量」が肥大化する
- 自動再計算や描画最適化によってCPU負荷が集中し、操作応答が極端に低下する

このような負荷の蓄積は、使用者にとって「体感的なフリーズ」として現れ、特に5MBを超えたあたりから顕著になる。

### ✅ 参考事例：実際に10MBで破綻した報告

> 2022年、Spring Batch系プロジェクトでも10MB超のCSVをExcelで開いた際、内容が壊れた・開けなかった・暴走したといった現象が報告されている（GitHub Issue #97）。
> 
> 
> 実際のファイル構造やツール依存もあるが、**Excelが“構造のないCSV”を誤認識する臨界点は10MB前後**と見てよい。
> 
> 本記事で述べた「5MBで分割 or Accessへ移行」という実務方針は、このようなリスクを未然に防ぐ上で妥当かつ現実的である。
> 

---

## ✅ 第2章：CSVは構造を捨てたことで“自由”を得た

Excelのパフォーマンス問題に直面したとき、多くの現場で次に選択されるのが「CSV形式」である。

CSVはカンマ区切りのテキストファイルであり、構造情報・数式・書式・スタイルなどを一切持たない。

この構造を捨てたシンプルさが以下のような利点をもたらす：

- 読み込み・保存が高速
- ソフトウェア依存がない（あらゆる環境で開ける）
- ファイルサイズがそのまま内容量に比例するため、挙動が安定する

一方で、カンマやダブルクォート、改行を含むフィールドに対してはエスケープ処理が必要になるなど、可読性・編集性には限界がある。そのためタブ区切り（TSV）形式が実務上好まれる場面も多い。

また、Excelの自動補正（先頭ゼロの削除・日付の自動変換・指数表記化）を回避する目的で、`="20250515"` 形式や `"=2,450"` などのExcel専用フォーマットがCSVに混在することもある。これはBIツールや帳票エンジンからの出力に多く見られる。

---

## ✅ 第3章：Accessは“表計算”ではない

CSVを受け入れる受け皿として、Microsoft Accessは極めて適したツールである。

Accessは、見た目こそExcelに似た「テーブル形式」であるが、その実体はJet/ACEエンジンによるローカルDBMSである。

そのため以下のような特徴を持つ：

- 数十万件のデータをSQLで即時処理できる（Index付きなら検索は数ms）
- JOIN／GROUP BY／WHERE 条件などもGUIから組める
- 入力フォームやレポートも構築可能
- 表計算とは異なり、「描画負荷」がほぼゼロ
- ファイル単位で軽量かつ高速（MDB/ACCDB）

さらに、全列を `Text` や `Memo`（長文）型で持っていても**パフォーマンスへの悪影響が小さい**。

たとえばExcelでは扱いが難しい「不定長文字列」「複数行の長文データ」「改行や構造を含む文章」も、AccessではMemo型（現在ではLong Text型）を活用し、HTML形式で記述することで、改行や段落を保持したまま処理することができる。

Excelでは複数行セル（Alt+Enter）やリッチな注釈フィールドは構造として保持できないが、AccessのMemo型＋HTML記述であれば、1セル1文書のような表現すら可能となる。

Memo型はインデックスや完全一致検索には不向きだが、閲覧・保管・出力には非常に強く、テキストフィールドでは処理しきれない自由度の高いデータも吸収可能である。

## ✅ 第4章：Accessは“処理”をする、Excelは“描画”する

ExcelとAccessは見た目こそ似ているが、本質的には**まったく異なる処理系**で動いている。

| 比較項目 | Excel | Access |
| --- | --- | --- |
| 処理対象 | セル（=1単位がGUIオブジェクト） | 行・列（=データベースのレコード） |
| 保存形式 | `.xlsx`（ZIP圧縮XML構造） | `.mdb` / `.accdb`（バイナリDB） |
| 主目的 | 表計算とグラフ、表の整形 | データ操作、検索、リレーション |
| パフォーマンス | 描画とUI処理にコスト | 処理のみで完結（非描画） |

特に重要なのは、Excelでは**非表示のセル・列であっても描画処理対象に含まれる**ため、大量データを保持するだけでもパフォーマンスに影響が出る。一方、Accessは**描画を一切しない内部エンジン**で動いており、実行されるのはSQL処理だけである。

Accessにとって、テーブルとはただのストレージではない。**処理単位**であり、**検索対象**であり、**出力エンジンの土台**である。

---

## ✅ 第5章：Accessが他のOffice製品と異なる理由

Accessは「Officeの一部」と見なされがちだが、実際には**Windowsのシステム側により深く結びついている**。

Accessの内部では、以下のような**ネイティブコンポーネント**が稼働している：

- `msjet40.dll`（Jetエンジン）あるいは `ACE.dll`
- DAO（Data Access Object）
- ADO（ActiveX Data Objects）
- ODBC/OLEDBドライバ（標準搭載）

Accessの `.mdb` ファイル形式は、古くから Windows の一部機能（レジストリログ・ADツール・一部管理ツールの履歴）で使われていた。

つまり、Accessは単なるOffice製品ではなく、**Windows標準の軽量ローカルDBMS**として設計されていた歴史を持っている。

これは、ExcelのようにVBAと描画を重ねて構築された「ユーザー向けUI製品」とは全く違う存在であることを示している。

---

## ✅ 第6章：Memo型と型の壁──それでもAccessの方が扱える

Accessでインポートする際、CSVの項目が長すぎる場合や、先頭が数字だったり文字列だったりする場合、型判定によって勝手に `Memo` 型（現在では `Long Text` 型）にされることがある。

Memo型は以下の制限を持つ：

- インデックスが張れない
- `WHERE memoField = '...'` は動作しない
- クエリ上で LIKE 検索が一部非対応になる（Accessバージョン依存）

しかしそれでも、Excelよりは遥かに**柔軟で壊れにくい**。

なぜなら、Accessは以下のことが可能だからである：

- データ長の自動調整
- 部分一致（`Like "*xxx*"`）での抽出（条件による）
- 入力制限付きフォーム連携
- メモ型 → テキスト型への変換（`Left([memo],255)`）

Excelでこれをやろうとすれば、すぐに列崩れ・誤変換・保存エラーに至る。

つまり、**型が不安定なCSVでも、Accessは“吸収”して処理できる**のだ。

## ✅ 第7章：Excelが壊れる前に「5MBで分割」または「Accessへ移行」

実務でCSVやExcelファイルを扱う際、データの蓄積により処理が遅延・破損する事態を避けるためには、**明確な閾値と移行基準を設ける**必要がある。

### 📌 推奨基準：

- **ファイルサイズが5MBを超える前に分割**
    
    → Excelはこの辺りから保存・開封・スクロールが著しく遅くなる
    
- **5MBに近づいたらAccessにインポートして処理**
    
    → CSVをそのままAccessで取り込むことで、型整合・結合・フィルタが高速に行える
    
- **日付型・数値型の崩れがある場合は、後からAccessで型補正する設計に切り替える**

---

## ✅ 第8章：CSVは“構造を捨てた”データである

CSVは、**何の形式情報も持たない“素データの集合”**である。

これは表形式として扱いやすい反面、次のような性質を持つ：

| 項目 | CSVでの課題 | 対応策 |
| --- | --- | --- |
| 日付 | `20250101` → 固定長文字列のためテキスト認識 | AccessでMid/DateSerialに変換 |
| 数値 | `00123` → 先頭ゼロが失われる | 文字列として明示、AccessでText型 |
| 複数列 | 255列超でExcelが壊れる | Accessで分割＋JOIN処理に切り替え |

🔍 **実務上の注意：CSVの文字コードと区切り形式について**

- テキストの文字コードは基本的に **UTF-8** を使用（AccessではBOMなしが安全）
- コンマ区切りではなく **タブ区切り** にすることで、**数値や日付の分裂を防止**
- `.csv` 拡張子のままでも、**中身をタブ区切りにする（TSV相当）**ことで、ExcelとAccessの両方で安全に扱える

---

## ✅ 第9章：256列の壁はAccessでJOINして越える

Excelは最大16,384列まで対応しているが、実際には256列（旧仕様）を超えると**UI処理・入力・数式が著しく困難になる**。

Accessでも1テーブルに保持できるフィールド数には制限（255列程度）があるが、以下の方法で回避可能：

### 💡 実践方法：

1. 元CSVを **128列 × Nファイルに分割**
2. それぞれ `tbl_part1`, `tbl_part2`, `tbl_part3` としてインポート
3. 主キー（ID列）を共通にして **INNER JOIN または LEFT JOIN** で再統合ビューを作成
4. 必要に応じて `Make-Table Query` で統合テーブルを生成

➡ これにより、**実質的に512列・1024列以上の構造でも処理が可能**

---

## ✅ 第10章：Accessには2GB制限がある——だから「リンク型」で分離せよ

Accessの `.mdb` / `.accdb` 形式には、以下の上限が存在する：

- 最大ファイルサイズ：2GB（*.accdb）
- テーブル数：制限なし（理論上）
- フィールド数：最大255列／テーブル
- 添付ファイルのサイズ：厳しく制限（推奨されない）

### 🎯 解決策：

- **画像やPDF、重い添付ファイルは“リンクパスで管理”する**
- 本体テーブルに「ファイル名」「ファイルパス」「最終更新日」だけを持たせる
- アプリ側・フォーム側で `ShellExecute` やハイパーリンクとして外部呼出し

こうすることで：

- Accessのパフォーマンスと2GB制限を維持したまま
- 巨大な非構造データ（画像・文書・PDF）と連携可能になる

本記事は、現場のファイル運用・構造処理において「Excel・CSV・Access」をどのように使い分けるかを整理したものです。形式が壊れる前に判断できる知識を、再利用できるように書きました。参考になれば幸いです。