✅ 第1章：Excelはなぜ遅くなるのか？
Excelは非常に便利なツールだが、一定のデータ規模を超えると保存や入力に遅延が発生し、操作不能に近づいていく。
この遅延は仕様上の「セル数上限」などでは説明できず、実際にはファイルサイズ（概ね5MB前後）が一つの転換点となる。
これは公式では一切解説がないが、以下のような理由による：
-
.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列程度）があるが、以下の方法で回避可能：
💡 実践方法：
- 元CSVを 128列 × Nファイルに分割
- それぞれ
tbl_part1,tbl_part2,tbl_part3としてインポート - 主キー（ID列）を共通にして INNER JOIN または LEFT JOIN で再統合ビューを作成
- 必要に応じて
Make-Table Queryで統合テーブルを生成
➡ これにより、実質的に512列・1024列以上の構造でも処理が可能
✅ 第10章：Accessには2GB制限がある——だから「リンク型」で分離せよ
Accessの .mdb / .accdb 形式には、以下の上限が存在する：
- 最大ファイルサイズ：2GB（*.accdb）
- テーブル数：制限なし（理論上）
- フィールド数：最大255列／テーブル
- 添付ファイルのサイズ：厳しく制限（推奨されない）
🎯 解決策：
- 画像やPDF、重い添付ファイルは“リンクパスで管理”する
- 本体テーブルに「ファイル名」「ファイルパス」「最終更新日」だけを持たせる
- アプリ側・フォーム側で
ShellExecuteやハイパーリンクとして外部呼出し
こうすることで：
- Accessのパフォーマンスと2GB制限を維持したまま
- 巨大な非構造データ（画像・文書・PDF）と連携可能になる
本記事は、現場のファイル運用・構造処理において「Excel・CSV・Access」をどのように使い分けるかを整理したものです。形式が壊れる前に判断できる知識を、再利用できるように書きました。参考になれば幸いです。