増え続けるPCゲームライブラリのSSD容量を大幅に節約するとするGame Compressor

Tom Hardwareは、容量を大量に消費するPCゲームライブラリが増える中、最大50％の削減をうたうWindowsユーティリティ「Game Compressor」に注目した。

このタイミングで、古くからあるWindows機能があらためて重要性を帯びている。プレイヤーは大容量インストール、限られた携帯型デバイスのストレージ、高止まりするSSD価格に直面している。Game Compressorは、ゲームをインストールしたまま物理ディスク使用量を削減するという新たな選択肢を提示する。

このユーティリティは新しい圧縮アルゴリズムを導入するものではない。Windows LZX圧縮に、ライブラリのスキャン、削減量の見積もり、タスクキュー、アップデート検出、元に戻せる解凍機能をまとめて1つのインターフェースにしている。

この違いが中心的な緊張関係を生む。Windowsにはすでに基盤となる機能が備わっており、無料の代替ツールでも類似した操作は可能だ。Game Compressorは、ゲーミングPCにもう1つアプリケーションを追加する価値が、その利便性と運用機能にあることを示さなければならない。

Tom Hardwareは、あるゲームが169 GBから91 GBへ縮小した例など、目を引く事例を報じた。ただし、こうした結果がすべてのライブラリに当てはまるわけではない。ファイル形式、既存の圧縮状況、アップデートの挙動、CPU性能、DirectStorage対応の有無はいずれも結果に影響する。

Tom Hardwareは大幅な削減を確認、ただし結果はゲームごとに異なる

重要なのは圧縮技術そのものの登場ではない。選択的なWindows圧縮を一般のプレイヤーにも理解しやすく、管理しやすいものにしようとする試みだ。

Game Compressorは、2月のEarly Access開始後、2026年7月10日に正式リリースを迎えた。Windows向けユーティリティの開発・販売はStone Pit Sonsが手がける。

リリースに先立ち、レポート精度、ライブラリ管理、圧縮速度に焦点を当てた複数のアップデートが実施された。ストレージユーティリティに大規模なインストールを処理させる前に、ユーザーには信頼できる測定値が必要となるため、これらの変更は重要だ。

Game Compressorのストアページによると、このアプリケーションはインストール済みゲームをスキャンし、見込まれる削減量を推定する。ユーザーはその後、予測される削減量が大きいインストールを優先できる。

この見積もりは最終結果を保証するものではない。開発元は、実際の削減量はゲームのバージョン、ファイル構造、ユーザーのシステム上に存在するファイルによって異なるとしている。

この注意書きは不可欠だ。音声、テクスチャ、データが比較的そのまま保存されたゲームには、かなりの冗長性が含まれている可能性がある。一方で、すでに効率的な圧縮を施したコンテナに大半のアセットを収めているゲームもある。

後者を圧縮しようとすると、ほとんど容量を取り戻せないまま時間とプロセッサー資源を消費しかねない。そのため、単純な「Compress」ボタンよりも、事前確認システムのほうが価値を持つ。

Tom Hardwareの記事では、ARK: Survival Evolvedが169 GBから91 GBへ縮小した例が挙げられた。これは78 GBの容量を回収したことになる。

同じ記事では、Crimson Desertが32 GB削減できたとされる。この規模の結果が1件でもあれば、別の大容量ゲームをインストールする余地を作れる。

好条件に当てはまるゲームが複数あるライブラリでは、合計で数百GB規模の削減につながる可能性がある。ただし、その結論は元の総容量だけでなく、ライブラリの構成に左右される。

古いゲームやパッケージ化が軽いゲームが中心のコレクションは、圧縮により適している。最適化済みアーカイブ、圧縮済みムービー、最新のストリーミング形式で満たされたコレクションでは、余地は小さい。

Game Compressorの正式版では、さらなる圧縮が効きにくい形式をスキップする高速圧縮設定が導入された。開発元によれば、メディアファイルは大規模ゲームの40〜70％を占める場合がある。

メディア中心のゲームでは、これらのファイルをスキップすることで、有効な削減量を損なわずに処理時間を短縮できるという。これは開発元の主張にとどまるが、その理屈は可逆圧縮の一般的な制約と一致する。

すでに圧縮されたデータには、別のアルゴリズムで取り除ける冗長性が少ない。したがって、すべてのバイトにLZXを適用しても、物理ディスク使用量を大きく変えずに時間を浪費する場合がある。

このユーティリティは、処理前後のファイルも測定する。以前のアップデートでは、表示される削減量とWindows側の値に不一致があるとユーザーが指摘したことを受け、レポートをファイルシステムの測定値へ切り替えた。

この経緯は、見出しにある数値を理解するうえで有益な背景となる。圧縮率は、アプリケーションが論理的なファイルサイズとディスク上で実際に占有する物理容量を区別できて初めて意味を持つ。

Game Compressorは現在、圧縮後のサイズをファイルシステムから直接読み取るとしている。また、コミュニティの結果は、まったく同じゲームのデータが存在する場合にのみ使用するという。

関連する報告がない場合、インターフェースは根拠のない見積もりを生成するのではなく、その不在を表示するべきだ。この仕組みにより機能の誠実さは高まるが、コミュニティデータは異なるパッチやインストール状況を反映している可能性がある。

Tom Hardwareの例は、普遍的な結果ではなく、達成し得る上限を示している。実用上の問題は、個人のライブラリ内に圧縮の効果が見込めるゲームが十分にあるかどうかだ。

Windows LZXはCPU処理をストレージ容量へ変換する

Game Compressorは、ゲームをアーカイブとして再パッケージ化するのではなく、Windowsに組み込まれた透過圧縮を用いて、一部のプロセッサー処理と引き換えにディスクトラフィックを減らす。

LZXは、WindowsのCompactコマンドで利用できる実行可能圧縮オプションのうち、最も容量効率が高いものだ。互換性のあるファイルを圧縮形式で保存し、アプリケーションが読み取る際に内容を解凍する。

Microsoftは、Compactコマンドのドキュメントで、LZXをXPRESS4K、XPRESS8K、XPRESS16Kと並べて掲載している。XPRESS4Kは速度を優先し、LZXは最小サイズを優先する。

この処理はファイルシステムレベルで透過的に行われる。ゲームは、まず別のアーカイブを展開するようユーザーに求めることなく、通常のWindows操作を通じて想定どおりのファイルを開き続ける。

この挙動はLZXをZIPやRARの保存形式と区別する。アーカイブ化されたゲームでは通常、ファイルを正常に使用する前に展開が必要となる。透過圧縮では代わりに、読み取り経路に解凍処理が組み込まれる。

MicrosoftはWindowsのファイル圧縮を可逆圧縮と説明しており、解凍時には情報を失うことなく元のデータを再構築できる。ディスク上に残るバイト数が少なくても、アプリケーションは通常、非圧縮のデータを参照する。

Game Compressorは、この確立されたWindowsの基盤を利用する。経験豊富なユーザーであればすでにコマンドラインツールで実行できる操作に、視覚的なワークフローを加えている。

ストレージの利点には計算コストが伴う。ゲームがデータを読み込むたびにWindowsが解凍しなければならず、CPUに追加の負荷がかかる。

Tom Hardwareは、多くのシステムにはこのオーバーヘッドを吸収できる未使用のプロセッサー性能があると論じている。記事では、物理ディスクからの読み取り量が減ることで、低速なストレージではロードが改善する場合もあると指摘した。

その結果はあり得るが、保証されるものではない。バランスは、プロセッサー、ストレージデバイス、ゲームエンジン、ファイル配置、アクセスパターンに依存する。

HDDや低速なストレージデバイスでは、読み取る物理バイト数を減らすことで入出力のボトルネックが解消され、恩恵を受ける可能性がある。高速なNVMe SSDでは、ストレージがすでに高速にデータを供給するため、計算が変わる。

この場合、CPUが解凍する時間は短くなり、解凍そのものがロード経路の一部になり得る。コア数が少ないシステム、古いプロセッサー、スレッド負荷の高いゲームでは、より慎重な検証が必要だ。

フレームレートも不完全な指標である。平均fpsが安定していても、アセットストリーミングによって断続的なレイテンシーや目に見えるカクつきが生じることがある。

そのためプレイヤーは、ロード時間、移動中のカクつき、フレームタイムの安定性、CPU使用率を確認すべきだ。単一のベンチマーク数値では、圧縮による副作用をすべて捉えられない。

このユーティリティは元に戻せる設計であるため、利用のハードルを下げている。削減量が小さい場合や性能に変化が見られた場合、ユーザーはインストールを解凍できる。

ただし、元に戻すには空き容量が必要だ。圧縮ファイルを元のディスク占有量まで復元する際、ドライブの空きが不足していれば失敗する可能性がある。

Game Compressorは、解凍前に利用可能な容量を確認するとしている。この保護機能は、特に回収した空き容量を追加のゲームで埋めた後に起こり得る問題に対応するものだ。

この仕組みは、削減量が大きく異なる理由も説明する。可逆圧縮は繰り返しパターンを除去するが、ほとんど冗長性がない場所に冗長性を生み出すことはできない。

大きな未加工アセットや軽度にしか処理されていないアセットは、大幅に縮小することがある。動画、音声、画像、暗号化されたアーカイブは、追加の圧縮に耐性を示す場合が多い。

ゲームエンジンによってもパッケージング戦略は異なる。そのため、表示上のサイズが近い2つのインストールでも、LZXによる結果は大きく異なり得る。

このばらつきにより、見積もりレイヤーが製品の中心的な要素となる。このアプリケーションの真の貢献はLZXそのものではなく、LZXを適用する価値がありそうなケースを特定することにある。

利便性は無料のWindows圧縮機能と競合する

主な競争は、有料の利便性と無料のネイティブ機能の間にあるのであって、Game Compressorと新しいストレージ技術の間にあるわけではない。

Windowsユーザーは、Game Compressorをインストールせずともcompact.exeを通じてLZXを実行できる。アルゴリズムの提供とファイルシステム処理は、オペレーティングシステムが担う。

この事実は、ユーティリティが差別化できる範囲を限定する。Stone Pit Sonsは、無料のWindows機能を中心に、検出、予測、キュー管理、監視、復旧をパッケージ化している。

この違いは、多くのシステムユーティリティに似ている。中核となる操作はすでに存在していても、ネイティブのインターフェースが特定の利用者層や反復的なワークフローに対応しているとは限らない。

コマンドラインを使うプレイヤーは、正しいフォルダを特定し、アルゴリズムを選択し、実行を監視し、結果を確認し、何を圧縮したかを記録しなければならない。ゲームのパッチは、さらなるメンテナンス作業をもたらす。

Game Compressorはライブラリをスキャンし、候補となるインストールを1つの画面にまとめる。現在のサイズ、予想削減量、圧縮状態、ドライブ使用量、操作履歴を表示する。

ユーザーは複数のゲームをキューに入れ、作業を一時停止し、タスクをキャンセルし、選択したインストールを復元できる。こうした操作により、大規模ライブラリの処理は手動コマンドの集まりより扱いやすくなる。

アップデート監視機能は、あまり目立たない問題に対応する。ランチャーはパッチ適用中に圧縮済みファイルを置き換えることがあり、インストールの物理ディスク使用量が再び増える可能性がある。

Game Compressorは変更されたゲームを確認し、圧縮を再適用できるようにする。この工程がなければ、パブリッシャーが新コンテンツを配信したり大容量パッケージを置き換えたりするにつれ、当初の削減効果は薄れていく可能性がある。

ストア説明によれば、アプリケーションを常時開いたままにする必要はない。ユーザーはアップデート後に再スキャンし、再処理が必要なゲームに集中できる。

この運用モデルこそ、無料ツールという議論に対する最も強い答えとなる。価値は1回の圧縮作業を完了することではなく、変化するライブラリ全体で結果を維持することから生まれる。

ただし、Game CompressorはWindows圧縮機能の唯一のインターフェースではない。オープンソースのCompactGUIプロジェクトも、ネイティブWindows APIをラップし、ゲーム、プログラム、その他のフォルダに対応している。

CompactGUIはXPRESSおよびLZXモード、圧縮分析、Explorer統合、変更されたフォルダを監視するウォッチャーを提供する。同プロジェクトのドキュメントも、DirectStorageゲームを圧縮しないよう警告している。

この比較は、Game Compressorの独自インターフェースにプレッシャーをかける。同製品は、信頼できる推定、ライブラリ検出、アップデート処理、使いやすさ、サポートによって差別化しなければならない。

Tom Hardwareは、キュー、プレビュー、ログ、再圧縮機能を有意義な利便性として提示している。これらの機能により、多数のゲームでLZXを安全に使うために必要な知識を減らせる。

正式版では、縮小しにくいファイルの処理高速化も追加された。カスタム実行ファイルの選択、Explorer統合、リネーム操作、より広範なライブラリ管理も導入している。

これらの追加機能は、圧縮率を変えるのではなく、圧縮にまつわる摩擦を対象としている。Game CompressorとCompactGUIはいずれも、最終的にはWindowsのアルゴリズムに依存する。

だからこそ、信頼性は特に重要になる。ステータス表示が停止したり、推定値がずれたり、圧縮済みファイルを追跡できなくなったりするなら、グラフィカルなインターフェースの価値は下がる。

開発者は、バージョン1.0以前にこうした問題が複数あったことを認めている。アップデートでは、プロセスが残り続ける、進捗が停止したように見える、節約容量がWindowsの表示と一致しないといった事象がユーザーから報告されたとしている。

その後の修正では、バイト単位で重み付けした進捗表示、ファイルシステムの直接測定、中断された操作からの復旧、キャッシュ済みライブラリ記録の保持が追加された。

これらの変更は、迅速な保守対応を示している。同時に、ユーザーがストレージ管理ツールを一度きりの計算機ではなく、運用ソフトウェアとして扱うべき理由も示している。

Steamのレビュー要約は、7月26日時点で初期導入のシグナルを示した。ストアには購入者レビューが182件表示され、そのうち82％が好評に分類されていた。

直近のレビューはやや弱く、購入者レビュー79件のうち78％が好評に分類されていた。これらの数値は急速に変わり得るものであり、独立した性能テストの代わりにはならない。

コミュニティの議論には大幅な容量削減の報告がある一方、停止したキューや競技系ゲームに関する疑問も含まれる。この組み合わせは、多様なライブラリを扱う新しいシステムユーティリティでは典型的だ。

開発者によれば、Game Compressorは実行中のゲームコードを変更しない。ゲームプロセスへのインジェクションではなく、Windowsのファイル圧縮を通じて動作する。

このアーキテクチャは、特定の互換性上の懸念を軽減するはずだ。それでも、アンチチートを多用するゲームでは、対象タイトル、ランチャー、現行パッチそのものに関する証拠が必要になる。

したがって、このユーティリティの競争力は信頼にかかっている。容量削減を正確に予測し、処理を完了させ、パッチ後も機能し、ユーザーが混乱なく変更を元に戻せる必要がある。

DirectStorageという例外は見出し以上に重要だ

特に慎重になるべき最も強い理由はDirectStorageにある。追加のCPU解凍レイヤーが、アセット処理をGPU側へ移すために設計されたパイプラインと競合する可能性があるためだ。

DirectStorageは、高スループットでゲームアセットを読み込むためのMicrosoftのストレージAPIである。最近のバージョンではGPU解凍をサポートし、CPUを介したアセット処理への依存を減らしている。

MicrosoftはDirectStorage 1.1でGPU解凍を利用可能にした。同社のドキュメントでは、解凍作業をGPUへ移すことで読み込み経路を改善できると説明している。

同社は2026年3月、この方向性をさらに拡大した。DirectStorage 1.4 previewでは、ZstandardサポートとオープンなGPU解凍ベースラインが追加された。

このアーキテクチャは、インストール済みファイルに透過的なLZX圧縮を追加する方法とは異なる。DirectStorage対応アセットは、ゲーム開発者とランタイムが選択したパイプラインに従う。

CompactGUIは、DirectStorageを使用するゲームを圧縮しないよう明示的に勧めている。Tom HardwareもGame Compressorについて同じ懸念を繰り返している。

リスクは、LZXが必ずしもこれらのゲームを破損させることではない。問題は、DirectStorageが本来の経路を続ける前に、WindowsがCPUで解凍する必要が生じる可能性にある。

この追加ステップにより、ストレージからGPUへ直接データを移す利点が損なわれる可能性がある。また、時間に敏感なアセット配信が解凍によって遅延すれば、スタッターを引き起こすこともある。

DirectStorageの採用状況にはばらつきがあるため、この警告によってGame Compressorの有用性がなくなるわけではない。ただし、ライブラリ全体の自動化ではなく、タイトルごとの判断が必要になる。

積極的な圧縮を選ぶ前に、ユーザーはDirectStorageの対応状況を確認すべきだ。保守的なワークフローでは、古いゲーム、あまり遊ばないタイトル、またはコミュニティで良好な結果が知られているタイトルから始める。

テストはゲームの大きなアップデートのたびに行う必要がある。パブリッシャーは、インストール名を変えずにパッケージング、ストリーミング挙動、アセット構成を変更できる。

性能テストにも再現可能な場面が必要だ。圧縮前後で、ロード時間、フレームタイム、移動時の挙動、シェーダー関連の停止、CPU使用率を比較する。

負荷の低いエリアで数分試しただけでは、互換性を確認できない。ゲームプレイ中にアセットを要求するため、ストリーミング負荷の高い場面の方が適切なストレステストになる。

開発者が掲げる最大50％の削減という主張にも、同様の慎重さが必要だ。「最大」は好条件で得られた結果を示すものであり、対応するすべてのゲームで期待できる削減率を意味しない。

Tom HardwareのARKの例は、この違いを示している。圧縮後のインストールは元のサイズの約54％になったが、その結果だけでは、すでに高密度にパックされたタイトルについてはほとんど分からない。

ユーザーは処理時間も考慮しなければならない。LZXはコンパクトな出力を優先するため、非常に大きなインストール全体に適用すると長時間の作業になり得る。

Game Compressorはキューに入れた作業を一時停止またはキャンセルできるため、不便さを軽減できる。それでも、中断されたストレージ操作には注意が必要であり、とりわけシステムのシャットダウンやドライブの切断時には重要だ。

正式版には、中断されたタスク向けの復旧ロジックが含まれている。報道によれば、このソフトウェアは次回起動時に実際のディスク状態を確認し、記録を修復する。

これは安心材料だが、価値のあるファイルについては通常どおりバックアップの習慣を維持すべきだ。ゲームは通常再ダウンロードできる一方、セーブデータは別の場所に保存されていたり、クラウド同期に依存していたりする可能性がある。

ドライブ形式も別の境界となる。このユーティリティには、LZXをサポートするNTFS形式のドライブと、64ビット版Windowsのインストールが必要だ。

この要件により、幅広いデバイスとの互換性のためにフォーマットされた多くの外付けドライブは対象外となる。また、プラットフォームをまたぐ単一の圧縮戦略ではなく、アプリケーションをWindowsに限定することにもなる。

アップデート時と復元時の両方で、利用可能な空き容量が重要になる。圧縮後の最終的な占有容量にかかわらず、ランチャーは大きなファイルのパッチ適用中に一時領域を必要とすることがある。

そのため、Game Compressorが大幅な容量削減を報告していても、ほぼ満杯のドライブでは運用上の問題が生じ得る。回収した容量を自動的にすべて割り当て可能な容量と見なすべきではない。

ユーザーは、パッチ、シェーダーキャッシュ、一時ファイル、解凍のために適切な余裕を残すべきだ。このアプリケーションが管理するのはゲームファイルであり、ストレージ増加のあらゆる要因ではない。

より広い測定上の問題もある。コミュニティの推定値は報告された圧縮前後のサイズを集計するが、インストール内容は言語パック、ダウンロードコンテンツ、オプションのテクスチャによって異なり得る。

Game Compressorは、中央値とより厳格な検証を用いるとしている。このアプローチは外れ値の影響を抑えられるが、すべてのローカルインストールを同一にはできない。

最適な解釈は確率的なものだ。推定値は候補の優先順位付けに役立つ一方、圧縮を有効のままにする価値があるかは、ローカルで測定した結果によって決まる。

このユーティリティが定着するかは次の展開が決める

Game Compressorの将来は、推定の正確さ、タイトル別の性能証拠、そしてパッチ後の信頼できる再圧縮という3つのシグナルにかかっている。

最初のシグナルは、予測された容量削減と測定された削減の差だ。正式版は、価値の低い処理を避けるため、コミュニティデータに依存している。

データセットが拡大すれば、人気ゲーム全体のカバー範囲は改善するはずだ。ただし、開発者がパッケージを置き換えたり大きなアセットを追加したりすれば、アップデートによって古い報告は陳腐化する可能性がある。

Game Compressorは、有用性を保つために、結果を十分なバージョン情報と関連付ける必要がある。予測がローカルの結果から繰り返し乖離するなら、その最も明確な利点は弱まる。

コミュニティの報告が、より新しいリリースやダウンロードコンテンツの構成をカバーしているか注視すべきだ。一貫した推定は、管理された圧縮レイヤーの価値を強めるだろう。

2つ目のシグナルは、独立した性能テストだ。ストレージ削減だけでは、LZXがすべてのゲームとシステムにとって無害だとは証明できない。

有用なテストには、ロード時間、フレームタイム測定、移動時の挙動、CPU使用率を含めるべきだ。複数のプロセッサとストレージデバイスを比較する必要もある。

DirectStorageタイトルは、独自のカテゴリとして扱う価値がある。スタッターやロード時間の増加に関する証拠があれば、それらのインストールを非圧縮のままにする判断を支持することになる。

古いゲームやDirectStorage非対応ゲームで安定した結果が得られれば、選択的な戦略が裏付けられる。重要なのは「選択的」という言葉であり、1つの設定ですべてのライブラリに対応することはできない。

3つ目のシグナルは、パッチ後の挙動だ。Steamなどのランチャーは日常的にファイルを変更または置き換えるため、以前に測定した削減量が低下する場合がある。

Game Compressorのアップデート検出と再圧縮ワークフローは、このサイクルに直接対応している。その長期的な有用性は、誤ったステータス情報を出さずに変更されたゲームを特定できるかにかかっている。

将来のリリースでランチャー対応範囲が改善されるか、中断された処理から問題なく復旧できるかをユーザーは見守るべきだ。停止したキューや不正確なディスク容量表示の報告は、信頼を弱める。

競争も期待値を形作る。CompactGUIはすでに、複数のアルゴリズム選択を含む、Windowsネイティブ圧縮へのオープンソースの道を提供している。

Windows自体も基準となる競合だ。compact.exeは、ユーザーの時間と知識以外の費用を必要としない。Game CompressorはLZXへの独占的なアクセスを主張できない。

同製品が守れる価値はオーケストレーションにある。候補を特定し、結果を推定し、作業を管理し、結果を測定し、変更を検出し、1つのインターフェースを通じて圧縮を元に戻す。

この提案は、Windowsハンドヘルドの所有者や複数のドライブを管理するプレイヤーに最も訴求するはずだ。こうしたユーザーは頻繁にストレージ制限を感じる一方、コマンドラインによる管理は避けがちだ。

多くのゲームをインストールしているアーカイブ志向のユーザーも、このモデルに合う。圧縮を1回適用した効果が長く続く、あまり変更されないタイトルを優先できる。

高度に最適化されたリリースを数本だけインストールするプレイヤーにとって、得られるものは少ない。同じことは、十分なストレージを持つユーザーやDirectStorage中心のライブラリを持つユーザーにも当てはまる。

より広い教訓は、1つのアプリケーションを超えるものだ。Windowsには有用なストレージ制御機能が長年搭載されてきたが、ネイティブで利用できることが実用的な採用を保証するわけではない。

専門的なインターフェースは、分かりにくいシステム機能を利用しやすくできる。同時に、本来であれば技術的なユーザーが手作業で調べる制限事項を説明する責任も引き継ぐ。

Tom Hardwareは、最も説得力のある結果に注目を集めた。1つのインストールから数十GBを回収し、ライブラリ全体では数百GBに達する可能性があるというものだ。

より持続的な論点は管理にある。圧縮は、ゲームアップデート後も測定可能で、元に戻せ、互換性を維持し、保守できなければならない。

ライブラリ全体を処理する前に、推定削減量を確認し、十分にサポートされている候補を1つ選ぶ。その物理ディスク使用量を記録し、圧縮後に代表的なゲームプレイをテストする。

次の大きなパッチ後にも、この確認を繰り返す。ロードやフレームタイムの低下なく削減量が維持されるなら、似たタイトルへ段階的に広げていく。

推定が大きく外れる、DirectStorageの挙動が変わる、またはキューの信頼性が低下する場合は、処理を元に戻し、より良い証拠を待つべきだ。あなた自身のライブラリでは、どのような結果が出るだろうか？