これまで EmEditor・klogg・UltraEdit・010 Editor・Log Voyager と、「巨大ファイルを扱える」とされるツールを実データで比較してきました。ひとまず一巡した後、複数のAI（Grok・Gemini・ChatGPT）に「他に比較すべきツールは？」と尋ねたところ、共通して名前が挙がったのが PilotEdit（Windows）と lnav（Mac/Linux・無償OSS）でした。
今回はこの2本の追試結果です。先に結論を書くと、PilotEdit は48GBを開けました。置換は私の環境では完了しませんでしたが、開発元は再現できないと回答しており（動画で確認）、こちらの環境に固有の問題である可能性が高いことが後で分かりました（後述）。lnav は10GB・1億行まで問題なく完走しています（48GB以上は後述の理由で対象外としました）。
テスト条件
これまでの比較と同じ実データを使います。
- ファイル: OpenStreetMap 日本の XML（約48GB・892,239,125行＝8.9億行）※過去記事の「50GB」「51GB」と同一ファイルです（表記揺れのため48GBに統一）
- PilotEdit: Windows ノートPC（メモリ16GB）——EmEditor比較と同じ環境
- lnav 0.14.1: Mac（M4・メモリ32GB）——klogg比較と同じ環境
- 3GB（1億行）・10GB（1億行）の同系データも使用
PilotEdit — 開くのは速い。置換は私の環境では完了せず
PilotEdit は「大容量ファイル対応」を掲げる Windows エディタです。巨大ファイル用の Quick Mode を明示的に指定してテストしました。
まず、オープンは健闘します。
| サイズ | オープン（Quick Mode） | 参考: EmEditor |
|---|---|---|
| 3GB | 15.4秒 | 約5.0秒 |
| 10GB | 44秒 | 14.0秒 |
| 48GB | 4分32秒 | 4分06秒（103〜301秒＋全域移動） |
48GBを4分32秒で開くのは、EmEditor とほぼ互角です。サイズにきれいに比例しており、インデックス作成の仕組み自体は機能しています。
ところが、置換（Tokyo → 東京）を実行すると一変します。
| サイズ | 全置換の結果 |
|---|---|
| 3GB | 2分10秒の時点でアプリケーションが終了し、完了を確認できず |
| 10GB | 5分以上応答なし・完了せず |
| 48GB | 5分以上応答なし・完了せず |
3GB・1億行は、メモリ16GBに完全に収まる「安全圏」のサイズです。同じ条件・同じ置換で EmEditor は0.9秒（2回）、UwView Pro＋Edit Upgrade は6.3秒（2回・単発なら1.31秒）で完了しています。Tokyo（5バイト）→東京（6バイト）は、行長が変わるごく標準的な日本語置換です。
もうひとつ気になったのが、開いている間の挙動です。PilotEdit は読み込みが終わるまでUIが完全にブロックされ、画面が暗転します。48GBなら4分半、先頭の1行すら見えません。
追記 — 開発元に問い合わせました（2026年9月12日）
開発元は「再現しない」と回答しています。検証動画を2本送っていただき、こちらでも確認しました。
経過はこうです。まず「検索（Ctrl+F）でアプリケーションが終了する」と報告しました。開発元からは再現しない旨の返信と、指定ビルドの案内。入れ直したところ、通常の検索は動きました。そこで、こちらの計測は「すべて検索（Find All）」「すべて置換」で行っており、終了するのは Find All のほうだと報告し直しました。4KBのテキストファイルという、誰でもすぐ試せる条件も添えています。
それでも開発元では再現しません。Find All の動画も送っていただきました。つまり、この現象はこちらの環境に固有である可能性が高いということです。現在、終了時のログから原因のモジュールを特定しているところです。分かり次第この節を書き直します。
上の置換の数値は、その前提で読んでください。開発元の環境では別の結果になる可能性が十分にあります。
lnav — 10GB・1億行まで問題なく完走
lnav は CLI 文化圏で定評のあるログ調査用 TUI ツールです（無償・オープンソース）。前回書いたとおり、50GB超の主戦場で実際に競合するのはアプリよりも CLI ツール群なので、その「対話的調査」の代表として測りました。
| サイズ | オープン（全行読み切り） | 検索 |
|---|---|---|
| 3GB・1億行 | 35.5秒 | 東京 2.74秒／大阪 2.3秒 |
| 10GB・約1億行 | 1分38.8秒 | Osaka 9.95秒／Tokyo 10.1秒 |
3GBと10GBは完走します。lnav はこの XML を logfmt 形式のログとして解釈し、時刻順の乱れ（Out-Of-Time-Order）を警告しながらも、10GBでは末尾の99,999,998行目・100%まできちんと表示できました。
初期表示は1.4秒でした。先頭が見えるまでの速さは、今回測った中でも最速級です。検索は3GBで2〜3秒弱、10GBで約10秒。同じ10GBの実測は klogg が約2〜3秒、UwView Pro 系が1〜2秒台なので速くはありませんが、1億行の実データを対話的に探せる状態にはなっています。
48GB以上は、この比較の対象外としました
lnav は本来ログファイル向けのツールで、作者も巨大ファイル対応を謳っていません。実際、1ファイルあたりの行数に上限（134,217,728行）が意図的に設けられています——メモリ使用量とのバランスを取るための設計上の判断で、ソースにも明記されています。ログファイルは、その行数に達する前にローテーションされるのが普通だからです。
48GBの OSM XML は8.9億行あり、この上限を6.6倍超えます。つまり設計上の想定外であって、性能の優劣として比べる対象ではありません。当初この記事では48GBの結果も載せていましたが、比較として不適切だったので取り下げました（2026年9月12日）。
10GB・1億行までなら、lnav は問題なく動きます。ログ調査という本来の用途では定評のあるツールです。
「開いた直後」の3つの世代
今回の追試で、巨大ファイルを開いた瞬間の挙動に明確な段階があることが見えてきました。
- 完全ブロック型（PilotEdit）: 読み込みが終わるまで画面が暗転し、何もできない。48GBなら約4分半
- 先頭のみ表示型（klogg・EmEditor）: 開いた瞬間に先頭は見えるが、全域の読み込みが終わるまで末尾や中間へジャンプできない。48GBなら約2〜9分
- 全域即時型（UwView 系・Wasm版を除く）: インデックスをバックグラウンドで作りながら、開いた瞬間から末尾でも50%位置でも即座にジャンプできる（索引完了は54〜140秒）
そして lnav は「1.4秒で見え始める」という意味では3に近い体験です（10GB・1億行まで完走）。
「巨大ファイル対応」というレビューの読み方
ネット上には「このツールは巨大ファイルも快適」と書かれた比較記事が数多くあります。追試した立場から言えるのは、前提が違うことが多いということです。そこでの「巨大ファイル」は数十MB〜1GB程度であることが多く、判定基準も「開いて先頭が表示され、英単語が検索できたか」まで。また「何百GBを開けた」系の報告には、1行が数バイトしかない改行主体の人工データが使われている例もあります。タグと日本語がびっしり詰まった実データで、行長の変わる置換までかけるという今回の条件は、それらとはまったく別の負荷です。これは特定の製品の話ではなく、測り方の話です。
恒例のまとめ表（48GB・実データ）
| ツール | オープン | 検索 | 置換 |
|---|---|---|---|
| UwView Pro＋Edit Upgrade | 即閲覧可（索引54〜140秒） | 初回12.5〜23.9秒 | 置換2回47.0秒 |
| EmEditor | 103〜301秒（全域移動約4分） | 144〜245秒 | 11分超・保存毎回31分（16GB環境） |
| klogg（Mac・閲覧専用） | 先頭のみ110〜545秒 | 120〜585秒 | — |
| grep / ripgrep（CLI） | — | 64.64秒 / 71.49秒 | —（sed等は別途） |
| PilotEdit | 4分32秒（画面暗転） | — | 私の環境では完了せず（開発元では再現せず） |
| 010 Editor（Mac） | 56.7秒 | — | 1回12分45.3秒・保存は15分を超えても完了せず |
※ lnav は上表に入れていません。1ファイルあたり134,217,728行という設計上の上限があり、48GB（8.9億行）は想定外のためです。10GB・1億行までは完走します（本文の表参照）。
正直な注記
- どちらも私の環境での実測です。使い方や設定の問題かもしれません——ご存じの方がいれば、ぜひ教えてください。訂正します
- PilotEdit については開発元に問い合わせ、「再現しない」との回答と検証動画をいただいています（2026年9月12日）。こちらの環境に固有の問題である可能性が高いと考えています
- PilotEdit は巨大ファイル用の Quick Mode を指定してのテストです。ASCII同士の置換であれば違う結果になる可能性はあります（未検証）
- lnav の48GBの結果は取り下げました（2026年9月12日）。作者は巨大ファイル対応を謳っておらず、1ファイルあたりの行数上限も設計として明示されています。巨大ファイル対応を謳うツールと同じ表に並べたのは、こちらの誤りでした。10GBまでの結果は、そのまま有効です
- 私は比較対象の一方（UwView Pro）の開発者なので、その分は割り引いてお読みください
結論 — 50GB級で「使える」道具は本当に少ない
「開ける」ことと「使える」ことの間には、高い壁があります。48GB実データでの実測を積み重ねてきた結果、検索・置換・保存まで完走できたのは、UwView Pro＋Edit Upgrade と、（潤沢なRAMがあれば）EmEditor、そして検索だけなら grep/ripgrep という、ごく限られた顔ぶれでした。
今回の追試で、GUI型のアプリには比較対象がほぼ見当たらないことも確認できました。今後は grep・ripgrep・lnav といった CLI系ツールとの機能比較を主にしていきます。UwView Pro の多段階検索には、grep の -v（含まない）・-w（単語一致）に相当するチェックに続き、uniq -c に相当する頻度集計までの追加ができています（いずれも v1.5.0 でリリース済みです）。次に取り込む機能は選定中です。
UwView Pro は販売中です（Windows・macOS・Linux対応、1ライセンスで3OS。14日間の無料試用あり——編集機能も使えます）。
関連記事
開発者より: 私のアプリ・Kindle本・OSSの一覧は GitHub: amru195704 にあります。
ご注意
本記事の情報は参考情報として提供するものであり、正確性・完全性を保証するものではありません。すべての計測値は記載の特定環境におけるものであり、他のハードウェアでは異なる場合があります。誤りにお気づきの場合はコメントでお知らせください。確認のうえ訂正いたします。
