実測まとめ — 巨大ファイル対応ツール 概算性能比較（UwView Pro＝1.00）

2026.09.10

2026年7月から、巨大テキストファイルを扱えると謳うツールを実機で測り続けてきました。このページはその全記録を1枚にまとめた概算比較表です。

UwView Pro（閲覧）／UwView Pro＋Edit Upgrade（編集）を 1.00 とした倍率で並べています。数字が大きいほど遅く、1.00未満は UwView Pro より速いという意味です。

★ これは「一発で見渡すための概算表」です
計測時期・OS・ストレージが異なる数字を、同じ表に並べています（Windows 16GB機と Mac M4 32GB機、USB HDD 0.10GB/s と内蔵SSD 3.29GB/s など）。
厳密な比較ではありません。桁と傾向をつかむためのものとしてお使いください。
各セルの正確な条件は、下の関連記事に全部書いてあります。

★ 想定しているのは「手元のノートPCで巨大ファイルを開く」場面です
計測に使ったのは メモリ16GBの Windows ノートPC（ファイルは内蔵SSD）と、メモリ32GBの Mac（M4）（ファイルは外付けUSB SSD／HDD）です。ファイルのほうがメモリより何倍も大きい——この条件でどこまで実用になるかを見るための計測です。2台で保存先が違うので、OSをまたいだ秒数の比較はできません（倍率はもともと同じ機械の中だけで出しています）。
メモリを潤沢に積んだ専用機や、高速な内蔵ストレージだけで完結する環境では、結果は大きく変わります。ファイルがメモリに収まってしまえば、多くのツールは素直に速くなりますし、ここで「測定不可」になったものが普通に動く可能性も十分あります。
逆に言えば、この表が意味を持つのは、機械を買い替えずに何とかしたい場合です。そういう前提の数字としてお読みください。

  1. 一覧 — OS別・サイズ別の総合評価
    1. Windows
    2. macOS
    3. Web（ブラウザ）
    4. Linux
  2. 読み方 — 個別の表の約束ごと
  3. 結論 — サイズ別に、何を使えばいいか
  4. 1. Open — 索引完了（全域が使えるまで）
    1. 先頭が表示されるまで／末尾へ到達できるまで（参考）
  5. 2. 検索
    1. CLI 4種を日本データで測ったら、ほぼ横並びだった（2026年9月14日）
    2. ただし、この4〜9倍は「索引ができた後」の話です
    3. 250GB — 開けたGUIは4つ、編集まで届いたのは1つ（2026年9月14日 再計測）
    4. UltraEdit — 250GBは「設定を変えれば開ける」でした（2026年9月12日 訂正）
    5. 010 Editor / Log Viewer vs UwView Pro＋Edit — Mac 同時計測（2026年9月14日）
    6. 010 Editor を Windows でも測った — 同じツールを2つの機械で（2026年9月14日）
    7. klogg を Windows でも測った — 10GBで A（2026年9月14日）
    8. UltraEdit の Windows 計測について
    9. EmEditor vs UwView Pro＋Edit — Windows 同時計測（2026年9月14日）
    10. 「開く」だけ採用していない理由
  6. 3. 置換（エディタ系のみ）
  7. 4. 保存（エディタ系のみ・.uwvz 書き出し基準）
  8. 5. 全体作業の総計 — 「開いて、探して、直して、保存する」
  9. 6. まだ測っていない組み合わせ
  10. 7. 「測定不可」の中身
  11. 関連記事 — 各セルの正確な条件はこちらに
    1. 他ツールとの直接比較
    2. 早見表・実用ガイド
    3. 自社内の実測
  12. 試してみる — まずブラウザで
    1. 1. まず Wasm版（ブラウザ版）— インストール不要・無料
    2. 2. 無料版 UwView — 閲覧だけならこれで足ります
    3. 3. UwView Pro / ＋Edit Upgrade — 10GBを超えるなら

一覧 — OS別・サイズ別の総合評価

まずこの3枚だけ見てください。個別の数字は下に全部あります。

グレード 意味（UwView Pro＝1.00 との比）
S 0.5倍未満 — UwView Pro より2倍以上速い
A 0.5〜1.5倍 — ほぼ同等（UwView Pro は基準なので常に A）
B 1.5〜4倍
C 4〜15倍
D 15倍超
F 2つの工程のうち片方しか値が取れていない（閲覧なら Open と 検索、編集なら 置換 と 保存）。もう片方が未計測、または完走しなかったもの。総合の数字が出せないという意味で、速い・遅いの評価ではありません
可 動作は確認したが、そのサイズでの計測値なし（より大きいサイズで動いたことからの下方推定を含む）
× 測定不可（完走しなかった／条件を満たせなかった）。より小さいサイズで測定不可なら、それより大きいサイズも×とします
— 未計測

グレードの決め方（機械的に決めています。恣意的な加点はありません）

  • 閲覧グレード … Open と 検索 の倍率を掛けて平方根（相乗平均）。倍率は掛け算の世界なので、足し算の平均だと片方で勝っているツールが不当に沈みます。片方しか測れていない場合は F（比べられないため。遅いという意味ではありません）
  • CLI だけは別扱い … 「開く」が無いので、CLIの検索時間 ÷ UwView Pro の（開く＋検索）で1つのグレードにします。答えが出るまでの合計で揃えるためです
  • 編集グレード … 繰り返し作業で比べます。開く → （検索＋置換）を5回 → 保存。実際の編集は「開いて何度も直す」ので、1回だけの作業より実態に近いからです
  • 載せているのは、そのOSで実際に測ったツールだけです。他のOSで測った値を持ち込んで並べることはしていません
  • D・F・× は意味が違います。D は「測った結果、15倍より遅かった」。F は「片方の値が無くて総合が出せない」——もう片方は数字が出ているので、そこまでは使えるという意味でもあります。× は「そのサイズでは使えない」。F を見たら、そのツールが悪いのではなく判断材料が足りないと読んでください

Windows

Windows 機（メモリ16GBノートPC）で実測したのは、EmEditor・010 Editor・klogg・UwView 系の4つです。UltraEdit も測りましたが、設定を調整できていなかったため外しました。

ツール 3GB 10GB 50GB 250GB
UwView Pro（閲覧） A A A —
EmEditor A A C —
010 Editor B B B —
klogg（閲覧専用） B A B —

※ 250GBの列が「—」なのは、Windows 機に250GBのファイルを置けていないためです。基準になる UwView Pro 自体を Windows で測っていないので、他のツールも比べようがありません。250GBの数字はすべて Mac での計測です（下の macOS の表）。

※ 010 Editor の Windows 計測は2026年9月14日に追加しました。3サイズとも B で安定しています。10GBでは開くが0.73倍と UwView Pro より速い（21.5秒 対 29.3秒）一方、検索は4.78倍。Mac での傾向（開くは速い・検索で離れる）がそのまま出ています。

※ klogg の Windows 計測も2026年9月14日に追加しました。10GBが A です——開くが0.53倍（15.5秒 対 29.3秒）で UwView Pro の半分、検索も3.98倍に収まっています。ただしこの0.53倍は、UwView Pro の10GB開くを29.3秒として計算した値です。同じ日の別計測では 8.11秒が出ており、そちらを使うと1.91倍・グレードBになります。EmEditor 側の異常値と対で不採用にした回の値なので採用していませんが、この判断が klogg に有利に働いている可能性があります（詳しくは「1. Open」の注記）。

※ UltraEdit は Windows 表から外しました。大容量ファイル用の設定を調整しないまま測っていたためです。Mac 版の計測は有効です。

※ PilotEdit はこの表から外しました（2026年9月12日）。私の環境では、「すべて検索（Find All）」を実行するとアプリケーションが終了してしまい、検索の計測ができませんでした（通常の検索は動きます）。開発元に問い合わせたところ、「再現しない」との回答と検証動画をいただいています。そのためこちらの環境に固有の問題である可能性が高く、原因を特定中です。分かり次第、測り直して載せ直します。

試したファイル 検索語 私の環境での結果
約2KB の日本語テキスト 東京 検索できず（アプリ終了）
約4KB・ASCIIのみの英文（ライセンス文書） you 同上
同上 UwView 同上
3GB 東京 同上（2026年9月14日）

※ 開くことはできます——Open 単体では3.35倍・1.50倍・3.57倍で、決して遅くありません。設定や環境の問題である可能性があります。同じ環境で検索が使えている方がいれば、ぜひ教えてください。

編集（一連の作業）

ツール 3GB 10GB 50GB 250GB
UwView Pro＋Edit Upgrade A A A —
EmEditor S B C —
010 Editor B C F —

※ 250GBの列は閲覧表と同じ理由で「—」です。Windows 機に250GBのファイルを置けていません。

※ 010 Editor の50GBが F なのは、置換が完走しなかったためです（「東京」→「Tokyo」が20%のまま10分経過）。保存は589.1秒で通っています（11.81倍）。同じ50GBを Mac では12分45秒で置換できているので、メモリ16GBのノートPCでは 50GB の置換が重すぎる、という読み方になります。

Windows の要点 — 3GBは EmEditor の独壇場です。編集が S（0.39倍）。検索0.45倍・置換0.14倍と、どちらも UwView Pro＋Edit より2倍以上速く、繰り返すほど差が開きます。逆転は10GBからで、保存が18.36倍に膨らんで編集が B、50GBで C。閲覧は3GB・10GBとも A（10GBは開くが0.48倍と EmEditor が速い）。PilotEdit は開発元へ問い合わせ中のため、今回は表から外しています。010 Editor は Windows でも3サイズとも閲覧 Bで、10GBでは開くが0.73倍と UwView Pro より速い。ただし50GBの置換が20%で止まり、編集は F です。klogg は10GBで A——開くが0.53倍と UwView Pro の半分で、検索も3.98倍。閲覧に限れば、Windows でも十分な選択肢です（ただし分母の取り方で B になります。上の注記）。UltraEdit は Windows 表から外しました（設定を調整しないまま測っていたため）。250GBは、Windows 機にファイルを置けていないため1件も測っていません。

3GBの内訳

工程 EmEditor UwView Pro＋Edit 倍率
開く 5.0秒 4.6秒 1.09
検索（2語） 1.06秒 2.35秒 0.45
置換（2回） 0.9秒 6.3秒 0.14
保存して閉じる 5.1秒 3.2秒 1.59
開く＋（検索＋置換）×5＋保存 19.90秒 51.05秒 0.39

置換の7倍差が効きます。3回繰り返した時点で総時間が2倍以上ひらきます。3GB前後のファイルを Windows で日常的に編集するなら、EmEditor が最良の選択です。そこは正直に書いておきます。

ripgrep・amber も Windows で動きますが、計測は macOS で行ったため、この表には載せていません（下の macOS の表にあります）。Windows での実測値をお持ちの方は、ぜひ教えてください。010 Editor と klogg は両方で測ったので、Windows・macOS の両方の表に出てきます（値は別々です）。UltraEdit も両方で測りましたが、Windows 側は外しました。

macOS

ツール 3GB 10GB 50GB 250GB
UwView Pro（閲覧） A A A A
klogg（閲覧専用） B B B B
010 Editor B B B B
UltraEdit B C B C※設
Log Viewer 1.3.0（閲覧専用） B B D ×
UwView（無料版・閲覧専用） A C B C
Wasm版 UwView（Web・閲覧専用） C C C ×
ripgrep（CLI）※ A B A B
GNU grep（CLI）※ A B A B
amber（CLI）※ A A B B
BSD grep（CLI）※ B B B B

※ 250GB は klogg・010 Editor・UltraEdit・UwView（無料版）・UwView Pro・CLI が計測できた組み合わせです。

※ UltraEdit の250GBは、既定の設定では開けません。「一時ファイルを使わない」モードに変え、一時ファイルの置き場所を外付けへ移して、はじめて開きました（2026年9月12日）。既定のまま開こうとすると、約1分で何のメッセージも出さずに終わります。詳細は「7.「測定不可」の中身」の下の項を見てください。
Log Viewer は Mac 本体が再起動する現象が起きたため「×」としています（詳細は「7.「測定不可」の中身」）。Log Viewer の件は開発者へ報告済みで、修正版が提出予定です（2026年9月11日）。

※ CLI には「開く」がありません。そこで CLI だけは、CLIの検索時間 ÷ UwView Pro の（開く＋検索）で1つのグレードにしています。GUI 側は索引を作ってから答えるので、「答えが出るまでの合計」で揃えたほうが公平だからです。

※ CLI は A〜B に並びます。「2. 検索」の表では 4〜9倍に見えますが、あれは索引ができた後の検索だけを比べた値です。索引を作る時間まで含めると差は 1.28〜3.73倍に縮みます。質問が1〜2回で済むなら CLI で十分、というのが正直なところです。

※ lnav はこの表から外しました（2026年9月12日）。作者が巨大ファイル対応を謳っておらず、1ファイルあたり134,217,728行という上限が設計として明示されているためです。巨大ファイル対応を掲げるツールと同じ表に並べたのは、こちらの誤りでした。10GB・1億行までは問題なく動きます（追加調査記事）。

※ macOS 表の3GB列のうち、010 Editor と Log Viewer は上限値です。3GB検索が1秒未満で測れなかったため、1秒として積んでいます。実際のグレードはこれより良くなる可能性があります。

※ 無料版の UwView も同じ表に入れました。250GBまで開いて検索できます（2026年9月11日 実測）。索引と圧縮キャッシュは Pro の機能なので、無料版は検索のたびにファイルを読みます。

サイズ 開く 検索（2語計） 相乗平均 グレード
3GB 6.18秒（1.82） 0.485秒（0.31） 0.75 A
10GB 21.7秒（1.85） 35.57秒（14.40） 5.16 C
50GB 1分46.8秒（1.82） 2分56.4秒（7.84） 3.77 B
250GB 8分52.6秒（1.68） 7分29.9秒（13.89） 4.83 C

※ 3GBだけ A なのは、無料版の検索が Pro より速かったからです（0.485秒 対 1.555秒＝0.31倍）。毎秒12.5GBという値なので、ディスクではなくOSのページキャッシュから読んでいます。3GBは32GBのメモリに収まるので、開いた直後はファイル全体がキャッシュに載る。そこを素のバイト走査（SIMD）でなぞるほうが、圧縮キャッシュを読んで展開するより速い、ということです。自社の有料版が無料版に負けている数字ですが、そのまま載せます。

※ ただしこの A は、同じ回で測った値ではありません。Pro 側の 0.926秒／0.629秒 は別日の計測で、キャッシュの状態が同じだった保証がありません。同じ回で測り直したい1件です（「6. まだ測っていない組み合わせ」）。

※ 無料版の速度は、サイズによらずほぼ一定でした。開くは473〜491MB/s、検索は575〜581MB/s（3GBのキャッシュ効きを除く）。索引を持たないので、ただ読むだけだからです。倍率が3GB→10GB→50GB→250GBで 0.31 → 14.40 → 7.84 → 13.89 と動くのは、無料版が変わったからではなく、Pro 側が変わったからです。

※ Wasm版 UwView はブラウザで動くものですが、Mac から同じファイルを開いて比べたので同じ表に並べました。閲覧だけなら、Wasm版は 010 Editor・UltraEdit と同じ土俵にいます（3GB・10GB・50GB とも C）。

※ Log Voyager はこの表から外しました（2026年9月12日）。行で位置を指すビューアではなく、バイトオフセットで飛ぶ「シークバー」として作られているためです（作者が Show HN でそう説明しています）。行番号を前提にした指標で測っても、優劣の比較になりません。ブラウザで巨大ファイルの一部を”覗く”ことに特化した設計で、目的が違います。

編集（一連の作業）

ツール 3GB 10GB 50GB 250GB
UwView Pro＋Edit Upgrade A A A A
010 Editor B C F ×
UltraEdit C C C ×
CLI（ripgrep＋sed） C C B C
CLI（BSD grep＋sed） C C B C

※ UltraEdit の250GBの編集が「×」なのは、一時ファイルが現実的でないからです。UltraEdit の編集は一時ファイル方式で、258GBのファイルには258GB級の一時領域が要ります。この環境では用意できませんでした。閲覧は「一時ファイルを使わない」モードで測れています（上の閲覧表・C）が、そのモードは編集が即座に元ファイルへ反映されるため、置換の計測には使えません。アプリの欠陥ではなく、方式と環境の噛み合わせの問題です。

※ 繰り返し作業で比べると、他社は総じて1段下がります。置換や保存を5回払うためです。UltraEdit 3GB が B→C、CLI が B→C。1回だけの作業なら、UltraEdit 3GB は3.64倍、CLI（ripgrep＋sed）は 3GB 2.32倍・10GB 1.55倍・50GB 1.68倍でした（下の「5. 全体作業の総計」）。

※ UltraEdit は2026年9月14日に10GB・50GBの置換・保存まで測り、どちらも C になりました（10GB：置換12.53倍・保存1.91倍・繰り返し9.00倍／50GB：置換4.30倍・保存1.08倍・繰り返し4.29倍）。50GBのほうが倍率は小さい——UwView Pro 側も50GBでは相応に時間がかかるためです。250GBの × は開けなかったためです。

※ （この表は Mac での計測です。010 Editor の Windows 版の結果は上の Windows の表にあります。）010 Editor は10GBまでは編集できます。3GB は2026年9月14日に置換・保存まで測り、B になりました（置換2.55倍・保存は理論下限1.00倍）。50GBが F なのは、置換（16.28倍）は測れたが保存が完走しなかったためで、遅いという意味ではありません——最後まで通せていないので、総計が出せないのです。250GBの × は、全置換が1時間47分・99%で応答が返らなくなったもの。閲覧のほうは250GBまで到達します（上の表）。

※ CLI の全体作業は、検索と「置換して保存」の合計です。CLI では置換と保存が同じ1工程（sed の出力）になります。3GB 22.68秒／10GB 46.79秒／50GB 298.70秒（ripgrep 系）。

macOS の要点 — EmEditor が存在しないので、3GBでも横並びになる相手がいません。UltraEdit は50GBまで開けます（2026年9月14日 再計測）。250GBには klogg と 010 Editor が到達しました。UltraEdit は既定の設定では開けず、一時ファイルの設定を変えて10分10秒で開きました（閲覧 C）。Log Viewer は Mac 本体が再起動する現象が起きたため打ち切りました。 到達した2つは、開くのはどちらも UwView Pro より速い（0.81倍・0.90倍）一方、検索は8.15倍・8.82倍。開けるかどうかではなく、開いたあと何回聞くかで決まります。010 Editor は250GBの全置換だけが完走しませんでした（閲覧は250GBまで到達します）。
3GBではどれを使っても困りません（2026年9月14日 同時計測）。開くのが2倍前後、検索は3ツールとも1秒前後。10GBで検索だけが離れます——開くは 010 Editor 1.05倍・Log Viewer 1.32倍とほぼ横並びなのに、検索は9.29倍・6.64倍です。50GBで他社の最上位は 010 Editor（開く0.82倍・検索5.02倍で B）。
CLI は全サイズで A〜Bです。索引を作る時間まで含めると、UwView Pro との差は1.28〜3.73倍しかありません。質問が1〜2回で済むなら CLI で十分です。
ブラウザ版（Wasm版 UwView）も、閲覧だけなら 010 Editor・UltraEdit と同等です。インストール不要で3GB〜50GBを開いて検索できます。

Web（ブラウザ）

上の macOS の表に並べてあります（Mac から同じファイルを開いて測ったため）。

Web の要点 — ブラウザで完結する選択肢は実質1つです。Wasm版 UwView は3GB・10GB・50GB のどれも C で安定していて、閲覧だけなら 010 Editor・UltraEdit と同じ土俵にいます（3GBで索引10.4秒・「東京」5.8秒）。インストールも登録も要りません。3GB・1億行なら実用範囲です。ただし250GBは読み込みが51%で止まりました——ブラウザで動く以上の制約があり、そこはネイティブ版の領域です。Web版に編集機能はありません。

Linux

1件も計測していません。対応しているのは UwView 系・klogg・010 Editor・UltraEdit・ripgrep・amber・GNU grep / sed です（EmEditor は Windows 専用のため対象外）。Linux 環境での実測をお持ちの方は、ぜひ教えてください。

読み方 — 個別の表の約束ごと

ここから下が、上のグレードの元になった個別の数字です。

  • Open は索引完了（ファイル全域が使えるまで）。先頭が表示されるまでの時間は別項にしています
  • 保存の基準は .uwvz 書き出し。プレーンテキスト書き出しは別途記載します
  • 置換・保存はエディタ系のみ。閲覧専用ツールには該当欄がありません
  • 表の記号
  • 数字 … 倍率（UwView Pro＝1.00）
  • 可 … そのサイズでの実測はしていないが、より大きいサイズで動作を確認しているため、使えると判断したもの（下方推定）
  • 測定不可 … 完走しなかった、または条件を満たせず値が取れなかったもの。環境や設定の問題である可能性もあります。より小さいサイズで測定不可だったものは、それより大きいサイズも測定不可としています（上方推定）。開けなかったものは、検索・置換・保存も測定不可です（そこへ到達できないため）
  • — … 該当なし、または判断材料が無いもの
  • アプリ名の横の記号は対応OSです（そのツール自体が動く環境。今回どのOSで測ったかは下の表を見てください）
  • W … Windows ／ M … macOS ／ L … Linux ／ Web … ブラウザ（インストール不要）
  • 例）EmEditor (W) は Windows 専用、UwView Pro (W/M/L) は3OS対応、Wasm版 UwView (Web) はブラウザで動作
  • すべて私の環境での実測です。設定の問題かもしれません——ご存じの方は教えてください。確認のうえ訂正します
  • 私は比較対象の一方（UwView 系）の開発者です。その分は割り引いてお読みください

計測したOS（ツールによって動作環境が異なります）

Windows で計測 Mac で計測 両方で計測
EmEditor Log Viewer / grep / ripgrep / sed / amber UwView 系 / 010 Editor / UltraEdit / klogg

EmEditor は Windows 専用です。Mac 環境では選択肢に入りません。逆に Log Viewer は Mac で測っています。

ripgrep・amber は Windows でも動きますが、計測したのは Mac だけです。この表より下の倍率は、その前提でお読みください。

010 Editor と klogg は Windows と Mac の両方で測りました（2026年9月14日）。下の表では 〈Mac〉 と 〈Win〉 に分けています。UltraEdit は〈Mac〉だけです。比較相手の UwView Pro も、それぞれ同じ機械で測った値です。〈Mac〉と〈Win〉の倍率を直接比べないでください——分母が違います。

サイズ表記は概数です。「50GB」は 51,254,526,392 バイト・892,239,125行（記事により48GB／51.25GBとも表記。÷1024³か÷1000³かの違いで同一ファイル）、「250GB」は 258,679,440,228 バイト・4,509,830,821行です。

結論 — サイズ別に、何を使えばいいか

表を全部見なくても、結論はこれだけです。

サイズ 現実的な選択肢
〜3GB Windows なら EmEditor が最強。置換は UwView Pro＋Edit の 7倍速い（0.14倍）、検索も 2倍以上速い（0.45倍）。開くはほぼ互角（1.09倍）。繰り返し編集すると0.39倍まで開きます（編集グレード S）。この領域でわざわざ乗り換える理由はありません。ただし EmEditor は Windows 専用で、Mac には存在しません（Mac の3GBなら UltraEdit が近い位置ですが、置換は10.76倍）。Windows の UltraEdit は表から外しました（設定を調整しないまま測っていたため）
10GB ここで逆転が始まります。EmEditor は開くが0.48倍と速く検索も1.92倍で健闘しますが、保存が18.36倍。繰り返し編集で3.07倍になります。010 Editor も保存が27.84倍（Mac）。ただし 010 Editor は10GBを開くのが速い——Mac で1.05倍、Windows では0.73倍と UwView Pro を上回ります
50GB 閲覧なら他社GUIもまだ戦えます。開くのはほぼ横並びで（010 Editor 0.82倍・UltraEdit 1.21倍・klogg 1.59倍）、検索で差がつきます（010 Editor 5.02倍・UltraEdit 7.33倍・klogg 8.95倍・Log Viewer 39.64倍）。閲覧に限れば 010 Editor が他社で最上位（B）。差が決定的になるのは編集して保存するところです——EmEditor は全体作業47分13秒、UltraEdit は11分33秒（2分53秒の3.08倍。繰り返すと4.29倍）、010 Editor は保存が完了せず（Mac）、Windows では置換が20%で止まりました
250GB 開いて検索できたGUIは klogg・010 Editor・UltraEdit※設・UwView 系の4つ。（UltraEdit は一時ファイルの設定変更が必要で、開くのに10分10秒かかります。）設定変更なしで開ける3つは4〜5分でほぼ横並び（klogg 0.81倍・010 Editor 0.90倍と、むしろ UwView Pro より速い）。ただし1問検索した時点でもう逆転します（klogg 8.15倍・010 Editor 8.82倍。どちらも検索のたびに258GBを読み直すため）。編集して保存まで到達できたGUIは UwView Pro＋Edit だけでした——010 Editor は全置換が1時間47分・99%で応答なしとなり、完了を確認できていません

つまり、サイズが上がるにつれて選択肢が減っていくという話です。3GBでは全員が戦えて、50GBで大半が脱落し、250GBまで来ると閲覧できるのが klogg・010 Editor・UltraEdit（要設定変更）・UwView 系の4つになります。UwView Pro を作ったのは、この最後の2列のためです。

ただし「開ける」と「使える」は別でした。250GBを開く時間は3ツールとも4〜5分でほぼ同じです。差が出るのは2回目以降の検索と、編集して保存するところです。詳しくは下の「250GB — 開けたGUIは4つ、編集まで届いたのは1つ」節に書きました。

Windows で3GB前後のファイルを扱うなら、EmEditor のほうが良い選択です。そこは正直に書いておきます。

1. Open — 索引完了（全域が使えるまで）

ツール 3GB 10GB 50GB 250GB
UwView Pro (W/M/L) 1.00 1.00 1.00 1.00
UwView（無料版） (W/M/L) 1.82 1.85 1.82 1.68
EmEditor (W) 1.09 0.48 3.96 —
klogg〈Mac〉(W/M/L) 1.93 1.73 1.59 0.81
klogg〈Win〉(W/M/L) 1.56 0.53※ 1.25 —
010 Editor〈Mac〉(W/M/L) 2.00 1.05 0.82 0.90
010 Editor〈Win〉(W/M/L) 1.85 0.73 1.75 —
UltraEdit〈Mac〉(W/M/L) 1.24 1.12 1.21 1.92※設
Log Viewer 1.3.0 (M) 1.92 1.32 5.95 測定不可
Wasm版 UwView (Web) 3.07 4.88 5.22 測定不可

初回のOpenは、UwView Pro が負ける場面があります。250GBの klogg は0.81倍、50GBの 010 Editor は0.82倍。索引を作るぶん、最初の1回で不利です。

※ klogg〈Win〉の10GB（0.53倍）について — 分母の UwView Pro を 29.3秒（以前の計測）としています。2026年9月14日には 8.11秒という値も出ていて、そちらを使うと 1.91倍になります。この回は EmEditor の開くが説明のつかない遅さ（14.0秒 → 31.1秒）だったため、対で不採用にしたものです。結果として、klogg に有利な側の数字を使っていることになります。Windows 機の UwView Pro を測り直したら、この行は更新します。

EmEditor の 3GB / 10GB について — 2026年9月14日に測り直したところ EmEditor 9.7秒／31.1秒 対 UwView Pro 3.71秒／8.11秒 となり、EmEditor だけが2倍遅く出ました。同じ条件で片方だけ遅くなるのは説明がつかないため、この回の「開く」は採用していません。表の 1.09倍・0.48倍 は EmEditor 5.0秒／14.0秒 対 UwView Pro 4.6秒／29.3秒 の実測です。

250GBでも同じことが起きます。klogg は258GBを4分18秒（258.3秒）、010 Editor は4分44.9秒（284.9秒）で開き、UwView Pro の317.8秒よりどちらも速い（0.81倍・0.90倍）。索引を作るぶん、最初の1回は UwView Pro が不利です。

差が出るのは2回目以降です。UwView Pro は50GBで0.02〜0.07秒（圧縮キャッシュから復元）、klogg は毎回110秒（再索引）、EmEditor は再オープンに約4分かかります。250GBでも klogg は開き直すたびに258.3秒を払い直します。

先頭が表示されるまで／末尾へ到達できるまで（参考）

ツール 先頭表示（10GB / 50GB） 末尾へ到達
UwView 系（ネイティブ） (W/M/L) 1秒未満 / 1秒未満 開いた瞬間
Wasm版 UwView (Web) 1秒未満 / 1秒未満 索引完了後
Log Viewer 1.3.0 (M) 10秒 / 50秒 索引完了後
EmEditor (W) 先頭のみ表示 4分06秒（50GB）

障害調査で最初にやるのは「最新のログを見る」＝末尾を見ることです。ネイティブ版 UwView は開いた瞬間に末尾へ行けますが、Log Viewer と Wasm版 UwView は索引完了を待つ必要があります（50GBで350秒／307秒）。

2. 検索

ツール 3GB 10GB 50GB 250GB
UwView Pro (W/M/L) 1.00 1.00 1.00 1.00
UwView（無料版） (W/M/L) 0.31 14.40 7.84 13.89
klogg〈Mac〉(W/M/L) 4.65 2.63 8.95 8.15
klogg〈Win〉(W/M/L) 3.81 3.98 3.14 —
EmEditor (W) 0.45 1.92 8.15 —
010 Editor〈Mac〉(W/M/L) 1.29※ 9.29 5.02 8.82
010 Editor〈Win〉(W/M/L) 2.00 4.78 3.45 —
UltraEdit〈Mac〉(W/M/L) 5.64 15.38 7.33 15.36※設
Log Viewer 1.3.0 (M) 1.29※ 6.64 39.64 測定不可
Wasm版 UwView (Web) 7.14 9.65 13.51 測定不可
BSD grep (M) 5.94 8.98 5.84 11.05
GNU grep（ggrep） (M/L) 4.07 8.79 5.30 8.45
ripgrep 15.2.0 (W/M/L) 4.10 8.80 5.36 8.58
amber 0.6.1 (W/M/L) 4.09 8.52 6.28 11.05

検索語は日本語ファイルが「東京」「大阪」、250GBが「New York」ほかです。倍率はサイズが上がるほど開きます。Log Viewer は10GBで6.64倍、50GBで39.64倍でした。

CLI 4種（GNU grep / ripgrep / amber / BSD grep）の 3GB・10GB・50GB は 2026年9月14日の実測です。詳細は次の節に書きました。250GB だけは5問ワークロードでの比較で、GNU grep と amber は1問の実測を5倍した値です。

EmEditor の 3GB / 10GB は 2026年9月14日に測り直しました（詳細は下の節）。3GBの検索は EmEditor が2倍以上速い（0.45倍）。10GBでも1.92倍と、まだ EmEditor 寄りです。

※ 010 Editor と Log Viewer の 3GB は上限値です。両ツールとも1秒未満でストップウォッチでは測れず、1秒として積んだ値なので、実際はこれより小さくなります。

CLI は質問1回あたりの値です。質問が1つだけなら ripgrep のほうが速く（索引を作る意味がない）、2問目から逆転します。250GBでの分岐点は1.29問目でした。

CLI 4種を日本データで測ったら、ほぼ横並びだった（2026年9月14日）

/benchmarks/ の CLI 行で「可」のままだった 3GB / 10GB を実測しました。検索語は GUI 側と同じ「東京」「大阪」で、東京＋大阪の合計です。5ツールでヒット数が完全に一致しています（3GB 11,274／5,560、10GB 11,393／6,268、50GB 94,979／53,210）。

ツール 3GB 10GB 50GB
GNU grep（ggrep） 6.33秒 21.72秒 119.38秒
ripgrep 6.39秒 21.75秒 120.70秒
amber（ambs） 6.37秒 21.06秒 141.50秒
BSD grep（LC_ALL=C） 9.25秒 22.20秒 131.48秒
BSD grep（UTF-8） 8.48秒 22.14秒 126.68秒
UwView Pro＋Edit 1.555秒 2.47秒 22.5秒

10GB以上では、どのCLIを使ってもほぼ同じでした。最速と最遅の差が10GBで1.05倍、50GBで1.19倍しかありません。1パスあたりの実効速度を出すと理由が見えます。

ツール 3GB 10GB 50GB
GNU grep 958 MB/s 944 MB/s 859 MB/s
ripgrep 949 MB/s 943 MB/s 849 MB/s
amber 952 MB/s 974 MB/s 724 MB/s
BSD grep（LC_ALL=C） 656 MB/s 924 MB/s 780 MB/s

950MB/s 付近に頭打ちになっています。ストレージを読み切る速度が上限で、そこに達したツールはそれ以上速くなれません。ツールの選択が効くのは、この上限に届かないツールだけです。

例外が2つあります。3GBの BSD grep は656MB/sで、上限の3分の2しか出ていません。GNU grep より1.46倍遅い。macOS の標準 grep を使っていて遅いと感じるなら、brew install grep で入る ggrep に替える価値があります。もうひとつは50GBの amber で724MB/s、GNU grep の1.19倍遅い。258GBでも同じ傾向でした（詳細）。

UwView Pro＋Edit との差は、10GBで最大になります。

サイズ ripgrep 差が開く／縮む理由
3GB 4.10倍 UwView Pro 側が1.555秒。ここまで小さいと索引の効きも小さい
10GB 8.80倍 UwView Pro 側が2.47秒のまま。ここが一番開く
50GB 5.36倍 UwView Pro 側が22.5秒に伸びる。差が縮む
250GB 8.58倍 5問での比較。質問を重ねるほど開く

50GBで倍率が下がるのは、CLI が速くなったからではありません。UwView Pro 側が 2.47秒 → 22.5秒 と伸びたためです。CLI は21.75秒 → 120.70秒 と素直にサイズなりに伸びています。

ただし、この4〜9倍は「索引ができた後」の話です

上の倍率は検索だけを比べたものです。GUI 側は、その前に索引を作っています。CLI にはその工程がありません。答えが出るまでの合計で揃えると、こうなります。

サイズ UwView Pro（開く＋検索） ripgrep GNU grep amber BSD grep
3GB 4.945秒 1.29倍 1.28倍 1.29倍 1.87倍
10GB 14.22秒 1.53倍 1.53倍 1.48倍 1.56倍
50GB 81.3秒 1.48倍 1.47倍 1.74倍 1.62倍
250GB※ 479.7秒 2.90倍 2.85倍 3.73倍 3.73倍

※ 250GB だけは5問での比較です（他は東京・大阪の2語）。

4〜9倍が、1.28〜3.73倍まで縮みます。索引を作る時間を無視していたぶんが、そのまま差になっていたわけです。

そしてこの表がいちばん正直なところだと思っています。質問が1〜2回で済むなら、CLI で十分です。3GBなら ripgrep 6.39秒に対して UwView Pro は4.945秒——1.29倍しか変わりません。索引が元を取るのは、同じファイルに何度も質問するときです。250GBの5問で2.90倍、20問なら5.76倍まで開きます（逆転点の計算）。

上の総合評価表で CLI が A〜B に並んでいるのは、この合計で比べているからです。

250GB — 開けたGUIは4つ、編集まで届いたのは1つ（2026年9月14日 再計測）

klogg・010 Editor・UwView Pro の3つが258GBを開いて検索できます。UltraEdit も、一時ファイルの設定を変えれば開けました（10分10秒。詳細は下の節）。ただし編集して保存するところまで届いたのは UwView Pro＋Edit だけでした。

開く（索引完了まで）

ツール 実測 UwView Pro比 物理下限比
klogg（閲覧専用） 4分18.3秒（258.3秒） 0.81 0.96
010 Editor 4分44.9秒（284.9秒） 0.90 1.06
UwView Pro 5分17.8秒（317.8秒） 1.00 1.18
UltraEdit※設 10分10秒（610秒） 1.92 2.27

klogg・010 Editor・UwView Pro の3つは4〜5分で、ほぼ横並びです（UltraEdit だけ10分10秒で、しかも設定変更が要ります）。しかも速いほうから klogg・010 Editor で、UwView Pro が一番遅い。索引と圧縮キャッシュを作っているぶん、最初の1回は不利になります。「物理下限比」は wc -l で258GBを1回読み切る時間（268.49秒）との比で、3つとも1回読み切る時間に張り付いています。

検索

ツール New York Statue of Liberty 2問平均 UwView Pro比
klogg 4分18.9秒（258.9秒） 4分28.9秒（268.9秒） 263.9秒 8.15
010 Editor 4分47.8秒（287.8秒） 4分43.1秒（283.1秒） 285.5秒 8.82
UltraEdit※設 8分10.5秒（490.5秒） 8分25.2秒（505.2秒） 497.8秒 15.36
UwView Pro — — 32.38秒 1.00

※ UltraEdit の250GBの検索は、ヒット数が正常であることを確認しています（数値そのものは記録していません）。他ツールで行っている「ヒット数の厳密な一致」の照合まではできていないので、時間は実測、同じ仕事をしたことの裏取りは目視レベル、という位置づけです。

klogg と 010 Editor の検索時間は、開く時間とほぼ同じです。どちらも物理下限に張り付いています（0.98倍・1.06倍）。つまり検索のたびに、258GB全体をもう一度読んでいる。UwView Pro が32.38秒で返せるのは、索引を引いているからです。

開いて N 問聞くまでの合計

ツール 開くだけ 1問 5問
UwView Pro 5分18秒 5分50秒 8分00秒
klogg 4分18秒 8分42秒 26分18秒（3.29倍）
010 Editor 4分45秒 9分30秒 28分32秒（3.57倍）
ripgrep（CLI・参考） — 4分38秒 23分10秒

速いのは「開くまで」だけでした。1問目の検索を終えた時点でもう逆転しています（UwView Pro 5分50秒 対 klogg 8分42秒・010 Editor 9分30秒）。索引の317.8秒は、質問1回で元が取れる計算です。

そして5問では、2つとも ripgrep より遅くなります——GUIなのに、CLIより時間がかかる。1問だけで済むなら ripgrep（4分38秒）が最速なのは変わりません。

置換 — 010 Editor は完走しませんでした

010 Editor で「New York」→「NYC」の全置換を実行しました。19分00秒で約1/3、そこから進み続けて 1時間47分で99% まで到達しましたが、そこで応答が返らなくなり、完了を確認できませんでした。

99%まで行って終われない、というのがこの計測でいちばん重い結果だと思います。1時間47分待った末に成果物が得られていません。

手段 同じ置換にかかった時間
UwView Pro＋Edit Upgrade 62.0秒
sed（変換のみ） 741.48秒（12分21秒）
sed（実ファイル出力込み） 999.38秒（16分39秒）
010 Editor 1時間47分で99%・完了せず

この結果を受けて、010 Editor は総合評価では「閲覧枠」に置いています。250GBを開いて検索するところまでは実用的でしたが、編集して保存するところまでは到達できませんでした。設定や環境の問題である可能性もあります。

届かなかったもの

ツール 観測したこと
UltraEdit ~~既定の設定では開けません~~ → 設定を変えたら10分10秒で開けました（2026年9月12日）。一時ファイルの置き場所が起動ディスクだったため、258GB分の領域を確保できず、約1分で何も表示せずに諦めていたのが原因です。詳細は上の「UltraEdit — 250GBは『設定を変えれば開ける』でした」
Log Viewer 1.3.0 開こうとすると Mac 本体が再起動する現象が繰り返し起きました。危険なため打ち切っています
Wasm版 UwView（自社） 読み込みが51%で止まり、先へ進みませんでした。50GBまでは動作します

自社の Wasm版 も届いていません。ブラウザで動く以上の制約があり、250GBはネイティブ版の領域です。

Log Viewer の250GBは、他と性質の違う「測定不可」です。遅いとか完走しないという話ではなく、OSごと落ちます。250GBのファイルで試すことはお勧めしません。メモリの使われ方に何かありそうですが、原因までは分かりません。この件は開発元へ直接報告し、同日中に「原因を2つ特定して修正した」との回答をいただいています（2026年9月11日。詳細は「7.『測定不可』の中身」の Log Viewer の項）。修正版は App Store へ提出予定とのことなので、この「×」は 1.3.0 に対するものです。50GBまでは（検索は39.64倍かかるものの）動作しています。

klogg は閲覧専用なので、置換・保存の欄はありません。

UltraEdit — 250GBは「設定を変えれば開ける」でした（2026年9月12日 訂正）

この項目は、まるごと書き直しです。以前は「10分経っても開かず中止」、次に「約1分で黙って終わる」と書いていました。どちらも、原因を突き止めずに現象だけ書いていたものです。

原因は一時ファイルでした。

UltraEdit は大容量ファイルを一時ファイル方式で開きます。ところが一時ファイルの置き場所が既定のままだと、macOS では ~/.idm/（起動ディスク）に作られます。ファイル本体を外付けSSDに置いていても関係ありません。258GBのファイルには258GB級の一時領域が要るので、起動ディスクでは足りず、確保できずに諦めていた——それが「1分で黙って終わる」の正体でした。

そして、失敗した回の一時ファイルが残っていました。~/.idm/ に210GB。

フォルダ 中身
EF673EFD-… 110.6GB（53.6 / 52.0 / 3.8 / 1.2 GB の4分割）
32CB244A-… 99.4GB
他2つ 0バイト（作って失敗した跡）

自分の残骸で自分の首を絞めていた形です。ユーザーは ~/.idm を見に行かないので、気づかないうちに起動ディスクが210GB減ります。

ただし、これは「片付けない」という意味ではありませんでした。後日、一時ファイル フォルダを空きの十分な外付けに設定した状態で試したところ、強制終了したにもかかわらず一時ファイルは削除され、空のフォルダだけが残りました（2026年9月12日）。残骸が積み上がるのは、空き容量が足りずに失敗した回のようです。当初この記事では「片付けていない」と書きましたが、言いすぎでした。訂正します。

効いたのは1つだけでした。

3つ試して、開けたのは「一時ファイルを使わない」に変えたときだけです。

試したこと 一時ファイルの置き場所 結果
既定のまま 起動ディスク（~/.idm/） 約1分で黙って終了
一時ファイル フォルダを外付けへ 外付けSSD・374GB空き 約6分で黙って終了
「一時ファイルを使わない」モード （使わない） 10分10秒で成功

置き場所を変えても駄目でした。空きが374GBあっても——258GBの一時ファイルには十分な余裕です——諦めるまでの時間が1分から6分に延びただけで、結末は同じ。つまり容量の問題ではなく、一時ファイル方式そのものが258GBに届いていません。

そして3回とも、何のメッセージも出ません。エラーも警告もなく、アプリは以後も普通に使えます。ユーザーからは、まだ読み込み中なのか、もう諦めたのかが区別できません。

開ける方法はあるのに、アプリはそれを教えてくれない——ここがいちばん惜しいところです。設定を1つ変えれば10分10秒で開くのに、既定のままでは「何も起きない」としか見えません。

実際に開いた設定: ファイル取り扱い → Large Files → 「Open file without temp file but NO prompt」

操作 実測 UwView Pro 比
開く 10分10秒（610秒） 1.92
「New York」 8分10.5秒（490.5秒） —
「Statue of Liberty」 8分25.2秒（505.2秒） —
検索2問平均 497.8秒 15.36

閲覧グレードは C（相乗平均 √(1.92 × 15.36) ＝ 5.43）。250GBに到達した4つ目のGUIになりました。

注意点が3つあります。

  1. これは既定の設定での値ではありません。上の3手順を踏んだ状態の値です。表では ※設 を付けています。同じ表の10GB・50GBは既定の設定での計測なので、厳密には条件が揃っていません。
  2. 「一時ファイルを使わない」モードは、編集が即座に元ファイルへ反映されます。閲覧の計測には使えますが、置換のテストには使えません。250GBの編集系が空欄なのはこのためです。
  3. 検索が物理下限の1.8倍かかっています。klogg（258.9秒）と 010 Editor（287.8秒）は「258GBを1回読む時間（268.49秒）」に張り付いていますが、UltraEdit は490秒。読むだけでは説明が付かない時間を使っています。なお10GBの検索倍率15.38倍と、250GBの15.36倍がほぼ一致しており、サイズが25倍になっても倍率は変わりませんでした。

この件は開発元へ問い合わせます（2026年9月12日時点で下書き）。聞くのは2つです。

  1. 失敗したときに何も表示しない件。「このファイルは大きすぎます」と1行出るだけで、ユーザーは判断できます。しかも、この場合は開ける設定が実在するので、それを案内できれば理想です
  2. ~~失敗した一時ファイルを片付けない件。~~ → 取り下げました。一時フォルダを適切に設定すれば削除されます（上記）。残骸が積み上がるのは、空き容量が足りずに失敗した場合に限られるようです

「258GBの一時ファイルに対応しろ」とは言いません。それは無理な注文かもしれません。言えないのは、無理だと言わないことのほうです。

010 Editor / Log Viewer vs UwView Pro＋Edit — Mac 同時計測（2026年9月14日）

Mac・外付けUSB SSD・同じファイルで、3ツールを同じ日に測りました。

サイズ 操作 010 Editor Log Viewer 1.3.0 UwView Pro＋Edit
3GB・1億行 開く 6.78秒 6.5秒 3.39秒
「東京」 1秒未満 1秒未満 0.926秒
「大阪」 1秒未満 1秒未満 0.629秒
「東京」→「Tokyo」置換 3.34秒 ―（閲覧専用） 1.31秒
「大阪」→「Osaka」置換 2.03秒 ―（閲覧専用） 1.31秒※
保存 3.5秒※理 ―（閲覧専用） 3.5秒
10GB・1億行 開く 12.3秒 15.5秒 11.75秒
「東京」 11.46秒 9.5秒 1.24秒
「大阪」 11.48秒 6.9秒 1.23秒

倍率にするとこうなります。

サイズ 項目 010 Editor Log Viewer
3GB 開く 2.00 1.92
検索（2語計） 1.29※ 1.29※
閲覧グレード B（相乗平均1.61※） B（相乗平均1.57※）
置換（1語） 2.55 ―（閲覧専用）
保存 1.00※理 ―（閲覧専用）
編集グレード B（繰り返し1.70） ―（閲覧専用）
10GB 開く 1.05 1.32
検索（2語計） 9.29 6.64
閲覧グレード B（相乗平均3.12） B（相乗平均2.96）
50GB 開く 0.82 5.95
検索（2語計） 5.02 39.64
閲覧グレード B（相乗平均2.03） D（相乗平均15.36）

※ 3GBの検索は3ツールとも1秒前後で、他社2つはストップウォッチで測れませんでした。1秒として積んだ上限値なので、実際の倍率はこれより小さくなります。

※ UwView Pro＋Edit の3GB置換 1.31秒は以前の計測値（1語あたり）で、2語ぶんは 2.62秒として計算しています。

※理 — 010 Editor の保存は理論値です。ストップウォッチでは1.0秒でしたが、3.03GB を1秒で書くと毎秒3GBになり、このディスクでは出ません（＝計測できていない）。同じ機械・同じディスクで観測した最速の書き出し 877MB/s で 3,032,812,644 byte を書く時間 3.5秒 を、理論下限として置いています。これ以上速くは書けないので、010 Editor に最も有利な値です。

3GBでは差がほとんどありません。開くのが2倍、検索は測れないほど速い。この領域はどれを使っても困りません。編集まで含めても、繰り返し作業で1.70倍（開く → 検索＋置換 ×5 → 保存で 47.13秒 対 27.77秒）。010 Editor は3GBなら編集もまだ実用範囲です。10GB・50GB で離れていきます。

10GBで検索だけが離れます。開くのは 010 Editor 1.05倍・Log Viewer 1.32倍とほぼ横並びなのに、検索は9.29倍・6.64倍。索引を持っているかどうかが、ここで初めて効いてきます。

50GBで2つの差が開きます。010 Editor は開くが0.82倍（UwView Pro より速い）・検索5.02倍で B、Log Viewer は開く5.95倍・検索39.64倍で D です。閲覧に限れば、50GBで他社の最上位は 010 Editor（東京56秒・大阪57秒）。

以前の数字との違い — 010 Editor の10GB検索は、以前は5.23倍と書いていました。010 Editor 側は 11.5秒 → 11.46秒 とほとんど変わっていません。変わったのは UwView Pro＋Edit のほうで、2.2秒 → 1.24秒に短縮しています。Log Viewer も同じで、5.00倍 → 6.64倍の変化は主に UwView Pro＋Edit 側の高速化によるものです。新しいほうは同じ日に同じ機械で全部を測った値なので、そちらを採用しています。

010 Editor を Windows でも測った — 同じツールを2つの機械で（2026年9月14日）

010 Editor は、このページで唯一 Windows と Mac の両方で測ったツールです。同じアプリが機械によってどう変わるかが見えます。

Windows（メモリ16GBノートPC）での実測

サイズ 操作 010 Editor UwView Pro＋Edit 倍率
3GB 開く 8.5秒 4.6秒 1.85
「東京」 2.5秒 1.49秒 —
「大阪」 2.2秒 0.86秒 —
検索（2語計） 4.7秒 2.35秒 2.00
置換（2回） 28.5秒 6.3秒 4.52
保存 4.9秒 3.2秒 1.53
10GB 開く 21.5秒 29.3秒 0.73
検索（2語計） 27.05秒 5.66秒 4.78
置換（2回） 67.6秒 12.41秒 5.45
保存 76.8秒 10.2秒 7.53
50GB 開く 2分13秒（133.2秒） 76.1秒 1.75
検索（2語計） 2分45秒（165.1秒） 47.8秒 3.45
置換 20%のまま10分経過・中止 47.0秒 測定不可
保存 9分49秒（589.1秒） 49.9秒 11.81

閲覧は3サイズとも B です（相乗平均 1.92・1.87・2.46）。10GBで開くが0.73倍——UwView Pro が索引を作っている29.3秒に対し、010 Editor は21.5秒で開きます。Mac でも同じ傾向（10GB 1.05倍・50GB 0.82倍）で、開くのが速いのは機械を変えても変わりません。

差がつくのは、やはり検索の2回目以降です。010 Editor は検索のたびにファイルを読み直すので、質問の数だけ時間が積み上がります。

編集は 3GB B・10GB C・50GB F。50GBの置換は「東京」→「Tokyo」が20%のまま10分経っても進まず、中止しました。保存自体は589.1秒で通っているので、詰まったのは置換です。

Windows と Mac で、同じ 010 Editor がどう違うか

サイズ 操作 Windows（16GB） Mac（M4・32GB）
3GB 開く 8.5秒 6.78秒
10GB 開く 21.5秒 12.3秒
10GB 検索（2語計） 27.05秒 22.94秒
50GB 開く 133.2秒 56.7秒
50GB 検索（2語計） 165.1秒 113秒
48〜50GB 置換（1回） 20%で中止 12分45秒（765.3秒）

サイズが上がるほど、機械の差が開きます。3GBでは1.25倍の違いですが、50GBの開くは2.35倍。そして50GBの置換は、Mac では12分45秒で完走し、Windows では20%で止まりました。

これは 010 Editor の問題というより、メモリ16GBで50GBを書き換えることの問題だと考えています。冒頭に書いたとおり、このページの数字は「非力なノートPCで巨大ファイルを扱う」前提です。潤沢なメモリを積んだ機械なら、Windows でも50GBの置換は通る可能性があります。

※ Windows 側の UwView Pro＋Edit は、3GB・10GB・50GB とも以前の計測値です（開く 4.6／29.3／76.1秒）。010 Editor と同じ日に測り直したのは EmEditor の検索だけで、そちらは次の節にあります。

klogg を Windows でも測った — 10GBで A（2026年9月14日）

klogg は閲覧専用なので、開くと検索だけです。

サイズ 操作 klogg〈Win〉 UwView Pro〈Win〉 倍率
3GB 開く 7.18秒 4.6秒 1.56
「東京」 4.58秒 1.49秒 —
「大阪」 4.38秒 0.86秒 —
検索（2語計） 8.96秒 2.35秒 3.81
閲覧グレード B（相乗平均2.44）
10GB 開く 15.5秒 29.3秒 0.53※
検索（2語計） 22.5秒 5.66秒 3.98
閲覧グレード A（相乗平均1.45）
50GB 開く 1分35秒（95.2秒） 76.1秒 1.25
検索（2語計） 2分30秒（150.1秒） 47.8秒 3.14
閲覧グレード B（相乗平均1.98）

klogg は Windows でも安定しています。検索は3サイズとも 3.1〜4.0倍 に収まり、サイズを上げても倍率がほとんど増えません。Mac では50GBで8.95倍・250GBで8.15倍まで開いたことを思うと、この Windows 機では klogg のほうが相対的に健闘していることになります。UwView Pro 側が Windows 機では遅い、というのが実体です。

10GBの A は、このページで他社ツールが取った最上位です。開くが0.53倍——klogg は索引を作らないので、そのぶん最初が速い。

※ ただし、この0.53倍は分母の取り方に依存します。UwView Pro の10GB開くを 29.3秒（以前の計測）としていますが、2026年9月14日には 8.11秒も出ています。そちらなら 1.91倍・グレードB。この回は EmEditor の開くが説明のつかない遅さだったため対で不採用にしたもので、結果的に klogg に有利な数字を使っています。Windows 機の UwView Pro を測り直したら更新します。

Mac の値との比較は控えます。Mac 側の klogg は「2回合計」で測った参考値で、Windows 側は1回の実測です。基準が違うので、並べると誤解を招きます。

UltraEdit の Windows 計測について

外しました。大容量ファイル用の設定（Large Files と一時ファイルの扱い）を調整しないまま測っていたためです。Mac 版の計測は有効です。

EmEditor vs UwView Pro＋Edit — Windows 同時計測（2026年9月14日）

同じ日・同じ機械・同じファイルで、両方を測りました。環境差の入らない、いちばん素直な比較です。

サイズ 操作 EmEditor UwView Pro＋Edit 倍率
3GB・1億行 開く ※不採用 9.7秒 3.71秒 （2.61）
「東京」 0.51秒 1.49秒 0.34
「大阪」 0.55秒 0.86秒 0.64
検索2語 計 1.06秒 2.35秒 0.45
10GB・1億行 開く ※不採用 31.1秒 8.11秒 （3.83）
「東京」 7.03秒 2.87秒 2.45
「大阪」 3.82秒 2.79秒 1.37
検索2語 計 10.85秒 5.66秒 1.92

3GBでは EmEditor の検索が2倍以上速い（0.45倍）。10GBになると1.92倍まで縮まります。サイズが上がるほど索引が効いてくる、という構図がこの2段でそのまま出ています。

「開く」だけは採用していません（次項）。表に載せている開くの倍率は 1.09倍・0.48倍で、以前の計測によるものです。

「開く」だけ採用していない理由

この日の計測で、EmEditor の開くが 5.0秒 → 9.7秒（3GB）／14.0秒 → 31.1秒（10GB）と2倍以上遅くなりました。同じ日の UwView Pro は逆に 29.3秒 → 8.11秒（10GB）と速くなっています。ストレージの状態が原因なら両方が同じ方向に動くはずで、片方だけ遅くなる説明がつきません。原因を特定できていないため、「開く」は以前の計測値を使っています。検索は両方が同じ傾向で出ているので採用しました。

3. 置換（エディタ系のみ）

ツール 3GB 10GB 50GB 250GB
UwView Pro＋Edit Upgrade (W/M/L) 1.00 1.00 1.00 1.00
EmEditor (W) 0.14 2.30 14.30 —
010 Editor〈Mac〉(W/M/L) 2.55 5.14 16.28 測定不可
010 Editor〈Win〉(W/M/L) 4.52 5.45 測定不可 —
UltraEdit〈Mac〉(W/M/L) 10.76 12.53 4.30 測定不可
BSD sed (M) 可 可 可 11.96

3GBの置換では EmEditor に完敗しています（0.14倍＝7倍速い）。ここは隠しません。小さいファイルなら、素直にメモリへ載せて書き換えるほうが速い。差分方式が効いてくるのは10GBからです。

※ 010 Editor〈Mac〉の3GB（2.55倍）は2026年9月14日の実測です。「東京→Tokyo」3.34秒・「大阪→Osaka」2.03秒。10GBの5.14倍と比べると、サイズが上がるほど差が開くのが見て取れます。

※ 010 Editor〈Win〉は2回ぶんの合計で比べています（3GB 28.5秒 対 6.3秒／10GB 67.6秒 対 12.41秒）。Windows 側は UwView Pro も2回ぶんの実測しか無いためです。50GBは「東京」→「Tokyo」が20%のまま10分経過し、中止しました。

※ UltraEdit〈Mac〉の10GB（12.53倍）・50GB（4.30倍）も2026年9月14日の実測です。10GB：「東京→Tokyo」45.1秒・「大阪→Osaka」43.5秒／50GB：3分22秒（202秒）・3分21秒（201秒）。この表のなかで、サイズを上げると倍率が下がる唯一の相手です。UltraEdit が速くなったのではなく、UwView Pro 側も50GBでは47秒かかるためです。

4. 保存（エディタ系のみ・.uwvz 書き出し基準）

ツール 3GB 10GB 50GB 250GB
UwView Pro＋Edit Upgrade (W/M/L) 1.00 1.00 1.00 1.00
EmEditor (W) 1.59 18.36 37.27 —
010 Editor〈Mac〉(W/M/L) 1.00※理 27.84 測定不可 —
010 Editor〈Win〉(W/M/L) 1.53 7.53 11.81 —
UltraEdit〈Mac〉(W/M/L) 1.14 1.91 1.08 測定不可
sed（実ファイル出力） (M) 可 可 可 7.24

最も差の大きい項目です。UwView Pro＋Edit Upgrade は原本を書き換えず変更を差分として積むので、作業途中の保存は0秒（差分が既にある）。EmEditor は50GBで毎回31分かかります。

※理 — 010 Editor の3GB保存は理論値です。ストップウォッチでは1.0秒でしたが、3.03GB を1.0秒で書くと毎秒3GBになり、このディスクでは出ない値です（＝計測できていない）。そこで、同じ Mac・同じ外付けUSB SSD で観測した最速の書き出し（877MB/s）を使い、3,032,812,644 byte ÷ 877MB/s ＝ 3.5秒 を理論下限として置きました。どのツールでもこれより速くは書けないので、010 Editor に最も有利な値です。実測ではありません。

※ UltraEdit〈Mac〉の10GB（1.91倍）・50GB（1.08倍）は2026年9月14日の実測です。11.1秒・54.1秒。比較相手は UwView Pro＋Edit の .uwvz 書き出し（5.8秒・49.9秒）。10GB をプレーンテキストで書き出す12.3秒と比べるなら0.90倍で、ほぼ互角になります。差がつくのは、作業途中で何度も保存するときです。

※ UltraEdit〈Mac〉の50GB保存 54.1秒は、ディスクの書き込み上限に張り付いた値です。51,254,526,392 byte を54.1秒で書くと毎秒947MBになり、この外付けUSB SSD の実効（約0.9GB/s）をわずかに上回ります。ストップウォッチの誤差の範囲と見て採用していますが、書き出しの完了前に操作が返っている可能性は残ります。

プレーンテキストで書き出す場合は250GBで323.9秒でした。その出力は sed の出力と1バイトも違いません（258,678,935,268 byte で完全一致）。

5. 全体作業の総計 — 「開いて、探して、直して、保存する」

個々の操作ではなく、一連の仕事を丸ごと測った値です。

この表は「1回だけの作業」です。上の総合評価の編集グレードは5回繰り返した場合なので、数字が違います。1回だけなら CLI が有利（3GB 2.32倍）、繰り返すと不利（同 5.35倍）になります。繰り返すたびに全部を読み書きし直すか、差分だけ持つかの違いです。

ツール 3GB 10GB 50GB 250GB
UwView Pro＋Edit Upgrade (W/M/L) 1.00 1.00 1.00 1.00
EmEditor (W) 0.78 4.43 16.38 —
010 Editor〈Mac〉(W/M/L) 1.60 7.98 測定不可 測定不可
010 Editor〈Win〉(W/M/L) 2.83 3.35 測定不可 —
UltraEdit〈Mac〉(W/M/L) 3.64 4.44 3.08 測定不可
CLI（ripgrep＋sed） (M/L) 2.32 1.55 1.68 4.11
CLI（BSD grep＋sed） (M) 2.62 1.57 1.74 4.64

3GBでは EmEditor に負けています（0.78倍）。そして50GBで16.38倍まで開きます。同じ相手・同じ操作で、サイズを変えるだけでこれだけ動きます。

※ EmEditor と UwView Pro＋Edit の Windows の値は、一連の作業を通しで測った実測です。010 Editor と UltraEdit は、工程ごとの実測を足した値（開く＋検索2語＋置換2語＋保存）で、通しでは測っていません。010 Editor〈Mac〉3GB は17.65秒 対 11.07秒、010 Editor〈Win〉は 3GB 46.6秒 対 16.45秒・10GB 192.95秒 対 57.57秒、UltraEdit〈Mac〉は 10GB 149.75秒 対 33.72秒・50GB 11分33秒（693.1秒）対 3分45秒（225.2秒）。

実測の中身です。

3GB 10GB 50GB
EmEditor (W) 11.0秒 229.9秒 47分13秒
UwView Pro＋Edit (W/M/L) 14.1秒 51.91秒 2分53秒

CLI 側の内訳（Mac・2026年9月14日）

3GB 10GB 50GB
検索2語（ripgrep） 6.39秒 21.75秒 120.70秒
検索2語（BSD grep） 9.25秒 22.20秒 131.48秒
置換して保存（sed） 16.29秒 25.04秒 178.00秒
合計（ripgrep＋sed） 22.68秒 46.79秒 298.70秒
合計（BSD grep＋sed） 25.54秒 47.24秒 309.48秒
UwView Pro＋Edit（開く＋検索＋置換＋保存） 9.76秒 30.12秒 2分58秒

CLI では置換と保存が同じ1工程です（sed 's/東京/Tokyo/g' file > out）。読みながら書き換えて、そのまま書き出します。倍率は 1.55〜2.62倍で、250GBの4.11倍と比べるとかなり小さい。50GB以下なら、CLI で回すのは十分に現実的です。

※ 比較相手の UwView Pro＋Edit は、開く＋検索＋置換＋保存を足した概算です。3GB＝3.39＋1.555＋1.31＋3.5＝9.76秒、10GB＝11.75＋2.47＋3.6＋12.3＝30.12秒、50GB＝58.8＋22.5＋47.0＋49.9＝178.2秒。開くと検索は2026年9月14日の実測、置換と保存は別日の計測を足しています。

注意 — この表の Windows の値は以前の計測です。2026年9月14日の同時計測では UwView Pro＋Edit の「開く」が 3.71秒／8.11秒（この表の 4.6秒／29.3秒 から短縮）でした。置換と保存をまだ測り直していないため、総計は更新していません。測り直したら差し替えます。

250GBは、5問の検索・絞り込み4段・集計・全置換・保存を通した値です。CLI 51分17秒 対 12分29秒（.uwvz で締めた場合）。プレーンテキストで書き出す場合は15分35秒で3.29倍でした。

6. まだ測っていない組み合わせ

空欄のうち、測れるのに測っていないものを明示しておきます。順次埋めます。

ツール 未測定 備考
UwView Pro＋Edit (W/M/L) Mac での 3GB / 10GB / 50GB の置換・保存 CLI 側は2026年9月14日に測りました。GUI 側の置換・保存だけ別日の値を流用しているので、同じ日に測り直すと総計が確定します
UwView Pro＋Edit (W/M/L) Windows 機での 3GB / 10GB の置換・保存 開くと検索は測り直し済み
~~UwView（無料版） (W/M/L)~~ ~~全サイズの開く・検索の実測~~ 2026年9月11日に埋まりました（閲覧 A／C／B／C）。残るのは3GBの同時計測——無料版0.485秒 対 Pro 1.555秒 は別日の値で、キャッシュ状態が揃っていません
GNU grep（ggrep） (M/L) 250GB の5問ワークロード 表の8.45倍は、1問の実測（273.66秒）を5倍した推定値です
EmEditor / 010 Editor〈Win〉/ klogg〈Win〉 (W) 250GB Windows 機に250GBのファイルを置けていません。置ければ Windows 側の上限が分かります
UwView Pro＋Edit (W/M/L) Windows 機の「開く」の測り直し 3GB 4.6秒／10GB 29.3秒／50GB 76.1秒 は以前の計測です。2026年9月14日には 3.71秒／8.11秒 も出ており、どちらを分母にするかで klogg〈Win〉10GB が A にも B にもなります
~~UltraEdit (W/M/L)~~ ~~10GB / 50GB の置換・保存~~ 2026年9月14日に埋まりました（10GB 編集 C／50GB 編集 C）。250GB は開けないため対象外

klogg と 010 Editor は258GBに到達します（2026年9月14日 再計測。上記「2. 検索」参照）。

Wasm版 UwView の3GB は2026年9月14日に測りました（索引10.4秒／東京5.8秒／大阪5.3秒）。これで表から「可」のセルがほぼ無くなりました。

010 Editor の3GB置換・保存も2026年9月14日に測りました（「東京」→「Tokyo」3.34秒／「大阪」→「Osaka」2.03秒）。保存だけは理論値です——ストップウォッチでは1.0秒でしたが、3.03GB を1秒で書くと毎秒3GBになり、このディスクでは出ません。計測できていないので、同じディスクで観測した最速の書き出し（877MB/s）から求めた 3.5秒 を理論下限として置いています。実測したければ、書き出し後のファイルサイズと更新時刻を確認する形で測り直す必要があります。

7. 「測定不可」の中身

値が取れなかった組み合わせです。環境や設定の問題である可能性もあるため、ツールの欠陥とは書きません。観測した事実だけを記します。

ツール サイズ 観測したこと
010 Editor〈Mac〉(W/M/L) 50GB テキスト保存が15分を超えても完了せず、最終ファイルを得られなかった
010 Editor〈Win〉 (W/M/L) 50GB 「東京」→「Tokyo」の全置換が20%のまま10分経過し、中止した（2026年9月14日）。保存自体は589.1秒で通っている。同じ50GBを Mac では12分45秒で置換できている
010 Editor〈Mac〉(W/M/L) 250GB 全置換が 1時間47分で99% に達したところで応答が返らなくなり、完了を確認できなかった
Log Viewer 1.3.0 (M) 250GB 開こうとすると Mac 本体が再起動する現象が繰り返し発生した。危険なため計測を打ち切った。→ 開発者へ報告し、同日中に「原因を2つ特定して修正した」と回答を得た（2026年9月11日。①ファイル全体をメモリに読み込む経路が残っていた→以後はメモリマップのみ ②行索引の構築でメモリを圧迫する更新が大量に積まれていた→共有と上限を追加）。修正版は App Store へ提出予定。この「×」は 1.3.0 のものです
Wasm版 UwView (Web) 250GB 読み込みが 51% で止まり、先へ進まなかった（2026年9月14日）。ブラウザ側の制約と思われる
~~UltraEdit〈Mac〉(W/M/L)~~ ~~250GB・開く~~ 解消しました（2026年9月12日）。一時ファイルの置き場所を外付けへ移し、「一時ファイルを使わない」モードで10分10秒、一時ファイルを使う設定でも17分10.1秒で開けます。既定のままだと約1分で何も表示せずに終わります
UltraEdit〈Mac〉 (W/M/L) 250GB・置換 一時ファイル方式に258GB級の一時領域が必要で、この環境では用意できませんでした。参考までに、一時ファイルを使う設定で「New York」→「NYC」を実行したところ、19分後に「該当なし」と表示され、その後応答が返らなくなりました（設定の問題である可能性があります）。閲覧を測った「一時ファイルを使わない」モードは、編集が即座に元ファイルへ反映されるため、置換の計測には使えません
amber（ambr） 250GB インプレース置換のため原本＋一時ファイルで516GBが必要。空き401GBでは実行できなかった

これらは私の環境での結果です。設定や条件次第で違う結果になるかもしれません。ご存じの方は教えてください。確認のうえ訂正します。

上の表にない「×」は、上方推定によるものです。

サイズによらず、最後までスクロールできず、ファイル全体を検索できないため、全サイズが「×」です。100MB弱でも同じでした。

250GBまで開けたGUIは、klogg・010 Editor・UwView のネイティブ版、そして設定を変えた UltraEdit の4つでした。自社の Wasm版 UwView は51%で止まっています。

Log Viewer の250GBだけは、性質の違う「測定不可」です。開こうとすると Mac 本体が再起動する現象が繰り返し起きました。時間がかかるとか完走しないという話ではないので、1.3.0 で250GBのファイルを試すことはお勧めしません。

この件は開発者へ直接報告しました（2026年9月11日）。同日中に返信があり、原因を2つ特定して修正したとの回答でした——①ファイル全体をメモリに読み込む経路が残っていた（以後はメモリマップのみを使い、できない場合は安全に失敗する）、②行索引の構築で、メモリを圧迫する更新が大量に積まれていた（データを共有し、積む量に上限を設けた）。45億行という行数自体は問題ではないことも確認済みとのことです。修正版は App Store へ提出予定。

ただし、開発者の環境には258GBのファイルを作る空き容量がなく、実ファイルでの確認はできていません。同じサイズのスパースファイルでは正常に開くところまで確認されています。実ファイルでの再確認は、こちらで引き受けます。修正版が公開されたら測り直して、この欄を更新します。

関連記事 — 各セルの正確な条件はこちらに

他ツールとの直接比較

早見表・実用ガイド

自社内の実測

試してみる — まずブラウザで

上の表を見て「自分のファイルではどうか」と思われたら、確かめる順番はこうです。

1. まず Wasm版（ブラウザ版）— インストール不要・無料

3GB・1億行程度までなら、Web版で十分使えます。

3.03GB・1億行での実測は、索引完了まで10.4秒／「東京」の全文検索が5.8秒・「大阪」が5.3秒（2026年9月14日）。文脈表示やジャンプは即時です。ブラウザで開くだけなので、インストールも登録も要りません。

→ WASMデモを開く

正直に書いておくと、Wasm版は初期コストが高い作りです。同じ3GBを、デスクトップ版（UwView Pro＋Edit）は3.39秒で開き、検索も1秒前後で返します。3倍から7倍の差があります。一方でスケールは素直で、10GB・50GB でも同じ C のまま。50GBでは索引307秒と、Log Viewer（350秒）を上回りました。それでも、大きいファイルを日常的に扱うならネイティブ版のほうが快適です。250GBは読み込みが51%で止まりました。

2. 無料版 UwView — 閲覧だけならこれで足ります

デスクトップアプリの無料版です。Tail（追記の追尾）は無料版の機能で、Pro にはありません。

250GBまで開いて検索できます（2026年9月11日 実測。8分52.6秒で開き、検索は1語あたり約7分30秒）。3GBなら閲覧グレードは A で、検索は Pro より速い（0.485秒 対 1.555秒）——この大きさならファイルがメモリに載るので、索引を引くより素で読んだほうが速いためです。索引と圧縮キャッシュは Pro の機能なので、10GBを超えると差が開きます（10GB C・50GB B・250GB C）。3GB前後で、何度も検索しないなら、無料版で足ります。

→ ダウンロード

3. UwView Pro / ＋Edit Upgrade — 10GBを超えるなら

Windows・macOS・Linux に対応し、1ライセンスで3OS使えます。買い切りまたは月額で、14日間の無料試用あり——編集機能も使えます。

→ UwView Pro

Windows で3GB前後なら、EmEditor のほうが速い場面があります。差が開くのは10GBを超えてからです。まずは無料のWasm版で、自分のファイルが何秒で開くかを見てから決めてください。

ご注意
本ページの情報は参考情報として提供するものであり、正確性・完全性を保証するものではありません。掲載の倍率は、計測時期・OS・ストレージの異なる測定値を同一表に並べた概算値です。各ツールのバージョンは計測当時のものです。誤りにお気づきの場合はお知らせください。確認のうえ訂正いたします。

ホーム
タイトルとURLをコピーしました