「ブラウザで巨大なログを開ける」——最近そう謳うツールをいくつか見かけます。私が開発している UwView にも、技術検証用に公開している Wasm（WebAssembly）版があるので、他人事ではありません。
実際に 47.73GB のファイルで試してみて分かったのは、「開ける」という一言に、まったく違う3つのことが混ざっているということでした。
「開ける」は3つに分けられる
| 段階 | 意味 |
|---|---|
| 1. 開ける | メモリが破裂せず、中身が表示される |
| 2. 端まで行ける | 最終行まで到達できる（＝総行数を知っている） |
| 3. 全体を検索できる | ファイル全域を対象に探せる |
1 だけを満たす作りでも、「ブラウザで◯◯GBを開ける」とは言えます。嘘ではありません。ただ、読む側が期待するのはたいてい 2 や 3 のほうです。
この違いは、設計思想の違いから来ます。
ブラウザで巨大ファイルの一部を”覗く”ことに特化した作りがあります。たとえば Log Voyager は、作者が Show HN で「ファイルを動画ストリームのように扱っており、総行数を読まずに従来型のスクロールバーを実装するのは難しい。スライダーはシークバーとして動作する」と説明しています（該当スレッド）。GitHub の README にも「タイムラインとエラーグループは、現在ロードされている 50KB のウィンドウについてのもの」とあります。
つまり、行で位置を指すビューアではなく、バイト位置で飛ぶ道具です。総行数を数えないぶん、開き始めが速い。そういう設計として、筋が通っています。目的が違うものを「どちらが上か」で並べても意味がありません。
47.73GB での実測（Wasm版 UwView）
- 対象: OpenStreetMap日本 XML — 47.73GB・892,239,125行（単一ファイル）
- 検索語:
東京 - 環境: MacBook Air（M4・メモリ32GB・macOS 26.3.1）・データは外付けUSB-SSD・Chrome
- 自社製品の計測です。作者が測っている数字として割り引いてお読みください
| 結果 | |
|---|---|
| Wasm版 UwView（Web・無料） | 「東京」94,979件を完走 |
| アプリ版 UwView Pro（参考） | 94,979件＋多段階絞り込み |
3の段階まで届いた、ということです。
追記（2026-09-23）— 秒数を測りました
公開時は「完走したかどうか」だけを見て、所要時間を測っていませんでした。
その後アプリ版が v1.6.6 になったので、同じファイル・同じ機械で3つ並べて測り直しました。
| 開くだけ | 開く→探す→画面に出るまで | 読み出し速度 | |
|---|---|---|---|
| Wasm版 UwView（ブラウザ） | 121.5秒 | 126.1秒 | 402 MB/s |
| klogg 24.11.0（ネイティブ） | 52.55秒 | 108.14秒 | 930 MB/s |
| アプリ版 UwView（無料・v1.6.6） | 50.44秒 | 53.7秒 | 969 MB/s |
読み取れることは2つです。
① ブラウザ版は、アプリ版のおよそ半分の速さです。 同じ機械・同じ SSD なのに、アプリ版が 969 MB/s 出すところを、ブラウザ版は 402 MB/s。頭打ちにしているのはディスクではなくブラウザです。「ブラウザには構造的な天井がある」と上で書いたことが、速度としても出ました。
② それでも、通しでは klogg と同じ土俵に立ちます。 126.1秒 対 108.14秒。klogg のほうが速いのは確かですが、ブラウザのタブの中で、ネイティブアプリと比べられる範囲に収まっています。
からくりは「開きながら探している」ことです。
| 秒 | |
|---|---|
| 開く（121.5）＋ 探す（86.8）を順にやる | 208.3 |
| 開きながら探す | 126.1 |
| 差 | −82.2秒（−39%） |
検索は 4.6秒ぶんしか増えていません（121.5 → 126.1）。読み込みの裏にほぼ隠れる、ということです。
klogg が通しで大きく伸びる（52.55 → 108.14）のは、索引ができるまで検索を始められないためで、ここが分かれ目になっています。
秒数には、私の操作時間が入っています。 ファイルを開くボタンを押し、検索窓に「東京」を打ち、
検索ボタンを押すまでの時間です。人間は 0% の瞬間には押せません。 今回は読み込み 10% の時点で押せたので、
手が速ければもう少し縮み、仮に 0% なら 115秒ほどになります。アプリ版の 53.7秒にも同じ条件が入っています。3GB のアプリ版に至っては、検索語を打ち終わる前に開き終わってしまい、そもそも測れませんでした。
待たされる側が、道具から人間に移りつつあります。ただしブラウザである以上、天井はあります——同じ Wasm版でも、250GBのファイルは読み込みが51%で止まりました。うちのブラウザ版も、上限の外では同じように止まります。
Wasm版が47GBまで届いた理由ははっきりしています。WebAssembly上で独自にヒープを管理し、チャンク読み込みでガベージコレクションを避けているためです。JavaScript のヒープを使う作りとは、天井の高さが変わります。
ブラウザ版は「参考」— その上に続く階段
種明かしをすると、今回勝った Wasm版は、うちでは「製品」ですらありません——技術検証用の参考版です。
- Wasm版 UwView（無料・ブラウザ）— 今回測ったもの。ブラウザの制約内で、性能はいちばん低い参考版
- アプリ版 UwView（無料）— OSネイティブのmmapが使え、ブラウザ版より速い。これも位置づけは参考製品
- UwView Pro — サイドカーキャッシュで2回目以降は0.02〜0.07秒で開き直し（実測・環境により変動）、多段階絞り込み検索。実務のための製品はここから
- UwView Pro＋Edit Upgrade — 加えて巨大ファイルの非破壊編集（10GB・21,994箇所を16.8秒で置換した実測）。開く・探す・編集して保存までを短時間で行う最上位構成
ブラウザには構造的な天井があり、それは Wasm版 UwView も同じです。巨大ファイルを本気で扱うなら、結局アプリ版に行き着く——自社製品も含めて、その序列が今回はっきりしました。
正直に書いておくこと
- 1ファイル・1環境（私のMac）での実測です。環境・ファイルにより結果は変わり得ます
- 他社ツールの内部実装は検証していません。設計についての記述は、作者自身の公開発言と README に基づいています
- Wasm版 UwView は技術検証用の公開物で、製品品質のサポート対象ではありません
- 秒数は 2026-09-23 に追記しました（公開当初は完走可否と件数のみ）。同一ファイル・同一機械で、
sudo purgeでキャッシュを破棄してから測っています。アプリ版は v1.6.6 - 「開く→探す→画面」には私の操作時間が含まれます（上記の注記）。機械だけの時間ではありません
- ファイルサイズの 47.73GB と 50GB は同じファイルです（1024 で割るか 1000 で割るかの違い）
使っている道具
UwView Pro は発売中です（Windows・macOS・Linux、1ライセンスで全OS。買い切り／月額。14日間の無料試用あり——編集機能も使えます）。一度きりの調査なら無料版 UwView でも十分です。
自分で試す（ブラウザで開くだけ）
- Wasm版 UwView: https://amru195704.github.io/UwView/
50GB級での追試結果は、コメントやXでお知らせください。本記事に反映します。
リンク
- AIに「50GBのログ調査」を聞いたら、うちの製品は出てこなかった（Zenn） — Log Voyagerの名前が出てきた経緯
- ripgrepは巨大単一ファイルでも最速なのか — 同じファイル系列でのCLI比較
- klogg との正直な機能比較【Ver1.1.1・完全版】
- 9万件のヒットを2回の絞り込みで54件に — 多段階検索
