「ファイルが大きすぎて開けません」— 巨大ファイルに沈む4つの定番ツールと、その先

「このログ、中身を確認しておいて」と渡されたファイルが 8GB あった。あるいは、エクスポートしたCSVが 3,000万行あった。

このとき人がまず試すのは、だいたい決まっています。メモ帳で開く。Excelに読ませる。VS Codeにドラッグする。それでもダメなら分割する。そして、そのどれもが違う理由で行き止まりになります。

この記事では、その4つの定番手段がなぜ・どこで沈むのかを順に見ていきます。「使えないツール」の話ではありません。それぞれに向いている仕事があり、ただ巨大ファイルの調査がその仕事ではない、というだけの話です。

1. メモ帳 — 「ファイルが大きすぎます」で終わる

状況

とりあえずダブルクリックする。しばらく砂時計が回り、「ファイルが大きすぎます」と出るか、無反応のまま応答なしになる。タスクマネージャを見ると、メモリがじりじり食われている。

なぜ起きるか

メモ帳は編集のためのツールです。編集を成立させるには、テキスト全体をメモリ上に載せ、任意の位置への挿入・削除ができる状態にしておく必要があります。つまり、開くという操作が「全部読む」とほぼ同義になっている。

Windows 11 のメモ帳は大きめのファイルの扱いが以前より改善されましたが、この設計上の前提そのものは変わっていません。8GBのログを開こうとすれば、8GB分のメモリ（実際には内部表現のぶんそれ以上）を要求します。32GB積んだマシンでも、50GBのファイルは物理的に載りません。

汎用ツールでの対処と限界

「先頭だけ見たい」なら PowerShell の Get-Content -TotalCount 100 で頭を切り出せます。末尾なら -Tail。実際、これで用が足りる場面はあります。

限界は、見たい場所が真ん中にあるときです。障害調査で欲しいのは「先頭100行」ではなく「エラーが出た瞬間の前後」で、それがファイルのどこにあるかは事前に分かりません。頭と尻尾だけ覗ける道具では、そこに到達できない。

2. Excel — 104万行の壁は、壁の手前がもっと厄介

状況

CSVをExcelで開いたら「このデータセットは大きすぎます」と言われた。あるいは何も言われずに読み込みが終わり、なんとなく安心して集計してしまった。

なぜ起きるか

Excelの1シートは 1,048,576行 × 16,384列 が上限です。これは2007年以降ずっと変わっていない仕様上の天井で、設定で広げることはできません。3,000万行のログを読ませれば、当然入りきらない。

厄介なのは、入りきらなかったことに気づきにくいケースがあることです。読み込みが途中で止まっても、シートには104万行分のデータが並んでいます。見た目は正常です。そのまま「エラーは3件でした」と報告してしまうと、残り2,900万行にあった件数が丸ごと抜け落ちる。行数の壁より、この静かな切り捨てのほうが実務では怖い。

さらに手前にも罠があります。00123 のような伝票番号が数値と判定されて 123 になる。2026-08-26 に見える文字列が日付シリアル値に変換される。ログのIDやタイムスタンプがそのまま原本と一致しなくなります。

汎用ツールでの対処と限界

Power Query（データの取得と変換）を使えば、104万行を超えるデータもデータモデルに読み込めます。集計だけならこれが正解です。型の自動変換も、取り込み時に「テキスト」を明示すれば止められます。

限界は、Power Queryが集計の道具であって、閲覧の道具ではないことです。「3,000万行目あたりの、この時刻の前後10行を目で見たい」——この一番よくある要求に、集計エンジンは答えません。そもそも巨大ログをExcelに持っていこうとしている時点で、多くの場合は集計ではなく確認がしたいはずです。

3. VS Code — 開けたのに、機能が消えていく

状況

エディタにドラッグしたら「ファイルが大きすぎるため表示できません」。設定を調べて上限を上げたら今度は開けたが、シンタックスハイライトが効かない。検索を叩くとウィンドウが固まる。

なぜ起きるか

VS Codeには段階的な安全装置が入っています。既定では数十MBを超えたあたりで Large File Optimizations が働き、シンタックスハイライト・折り畳み・一部の言語機能が自動的に無効化されます。さらに大きくなると、表示そのものを拒否します。境界値はバージョンと設定（editor.largeFileOptimizations、files.maxMemoryForLargeFilesMB など）で動くので、正確な数字は環境ごとに確認が必要です。

なぜ機能を落とすかというと、エディタが提供している価値のほとんど——構文解析、折り畳み、シンボル一覧、差分表示——がファイル全体を構造として理解していることの上に立っているからです。理解には全体の走査が要る。走査が終わらないファイルでは、機能を切るしかない。

つまり、上限設定を上げてGB級のファイルをVS Codeで開けたとしても、そこにあるのは「機能を全部切ったエディタ」です。エディタの強みを捨てた状態で使っている。

汎用ツールでの対処と限界

ここは役割分担で考えるのが素直です。編集する対象（設定ファイル、ソースコード、抽出後の数千行）はエディタで。読むだけの対象（生ログ、ダンプ、エクスポート）は別の道具で。

限界は、その「別の道具」を持っていないと、結局エディタに無理をさせ続けることになる点です。役割分担は、分担先があって初めて成立します。

4. 分割する — 定番の回避策が、調査では逆に効く

状況

split -l 1000000 huge.log part_ で100個のファイルに切った。あるいはGUIの分割ツールでバラした。これで開けるようになった、と思った。

（この「分割せずに開く」という話は Windowsで「ファイルが大きすぎて開けない」— 10GB・50GBのログを分割せずに調査する方法 でも扱いましたが、ここではもう一段踏み込んで、分割した後の運用がどう崩れるかを見ます。）

なぜ起きるか

分割は、開けない原因（ファイルが大きい）を確かに取り除きます。しかし同時に、調査に必要な前提をいくつか壊します。

行番号が原本と一致しなくなる。 part_ab の 3,412行目は、原本では 1,003,412行目です。報告書に「3,412行目でエラー」と書けば、受け取った側は原本のその位置を見て首をかしげます。オフセットを毎回足す運用は、分割数が増えるほど確実に事故ります。

境界がレコードを断ち切る。 スタックトレースは複数行で1つの意味を持ちます。JSONログでも、整形されて出力されていれば1レコードが複数行です。分割点がその途中に落ちると、Caused by: の連鎖が2ファイルに分かれ、片方だけ見た人は原因を取り違える。

検索が手作業に戻る。 grep ERROR part_* で横断はできます。しかし前後の文脈を見ようとした瞬間、どのファイルの何行目かを確認して、そのファイルを開き直す作業が挟まります。50個のファイルを行き来しているうちに、「さっき見たあの行はどれだったか」が分からなくなる。

ディスクを二重に食う。 8GBのログを分割すれば、合計8GBのコピーができます。元を消せば原本がなくなり、消さなければ16GB。調査中にディスクが埋まるのは、避けたい種類の事故です。

汎用ツールでの対処と限界

行番号のズレは、awk 'FNR==1{offset+=prev} ...' のような細工である程度は補正できます。境界問題は、csplit でレコード区切りのパターンを指定すれば緩和できます。

限界は、こうした細工が調査のたびに書き捨てになることです。ログの形式が変われば書き直し。急いでいる障害対応の最中に、調査ではなく調査の準備を書いている。分割は「開けない」を解いた代わりに、「原本のまま扱える」という前提を手放しています。その前提こそが、調査で効いていたものでした。

4つに共通していたもの

並べてみると、沈み方は違っても理由は1つに収束します。

いずれも「全体を扱えるようになってから、使えるようにする」という設計です。この前提は、ファイルがメモリに収まる限りは正しく、収まらなくなった瞬間に破綻します。

裏を返せば、巨大ファイルの調査に必要なのは、全体を扱い終える前から見られること——先頭も末尾も真ん中も、開いた直後からスクロールでき、検索でき、原本を1本のまま保てること。ここまでの4つは、どれもその設計になっていませんでした。それは欠陥ではなく、別の目的のために選ばれた設計です。だから、目的が違うときは道具を変えるのが早い。

使っている道具

私が開発している UwView（無料）は、まさにこの前提を外したビューアです。巨大なテキストでも開いた瞬間から全体を表示・スクロール・検索でき、索引はバックグラウンドで作られて、完成すると行番号が付きます（他のビューアの多くは索引が終わるまで先頭しか見えません）。分割せず、原本を1本のまま扱えます。実測の一例として、47.73GB・約8億9,200万行のテキスト（USB外付けSSD・メモリ32GBのマシン）で、開いた直後から末尾への移動と検索ができることを確認しています（環境により異なります）。そして、ストレージを専有している巨大ログを圧縮して保管し、さらに高速に検索したいなら UwView Pro をどうぞ。永続索引・圧縮キャッシュ検索・約1/9保管で、開き直しも検索も一段速くなります（2回目以降は行番号付きで瞬時に開けます。全OS対応・買い切り／月額プランあり）。

リンク

• 分割せずに巨大ログを調査する手順: https://uvp.y42u.net/blog/uwview-huge-log-cannot-open/
• 48GBファイルでの実測比較（RAM 16GBのノートPC）: https://uvp.y42u.net/blog/uwview-emeditor-48gb-comparison/
• ソースコード（GitHub）: https://github.com/amru195704/UwView

開発者より: アプリ・Kindle本・オープンソースの一覧は GitHub: amru195704 にまとめています。

お願い
本記事の情報は参考目的で掲載しており、正確性・完全性を保証するものではありません。数値は特定環境での実測であり、環境により異なります。ツールの仕様・上限値はバージョンや設定により変わります。誤記・不正確な情報がございましたら、コメント欄よりご指摘いただければ、確認のうえ修正いたします。