それなりゲーミングPCでMinecraftが重い理由

現行のAAAタイトルを高設定で走らせるPCが、2011年のブロックゲームで20FPSに沈む。「もっといいGPUを買え」という定番の助言は、完全に的外れだ。Minecraft Java EditionはCPUとメモリが律速するJavaプログラムであり、仕事の大半を単一のメインスレッドが処理する。だからこのゲームのラグは、手持ちの他のどのゲームとも違う場所に住んでいる。

Minecraftが罰するのはGPUではなくCPU

Java Editionは単一のメインスレッドで描画し、チャンクの読み込み、チャンクメッシュの構築、エンティティのロジックがその同じスレッドに積み上がる。現代のGPUはほとんど暇をしているのに、CPUの1コアだけが汗をかいている。ミドルクラスより上のGPUを買っても、得られるものはほぼない。フレームレートの天井を決めるのはシングルコア性能と、ゲームがどれだけ速くGPUにチャンクを供給できるかだ。

メモリがもう半分を占める。ランチャーはデフォルトで小さめのヒープでゲームを起動し、バニラの世界もModパックもその上限に向かって喜んで育っていく。ヒープが一杯になると、ガベージコレクタがメモリを回収するためにゲーム全体を停止させる。その停止こそ、あなたが見ているカクつきの正体だ。描画距離は両方の問題を一度に増幅する。チャンクの環が1つ増えるごとに、メッシュもメモリもスレッドの仕事も増える。

実際に数値を動かす対策

効果の大きい順の概算で、Mod入り世界で費やした私たちの時間から。ハードウェアに1円払う前にまずこれらを。たいていの機種では、これが「プレイ不能」と「滑らか」の境界線になる。

描画距離 — 最大のレバー。32ではなく8〜12チャンクにするだけでフレームタイムが一変する
RAMの割り当て — ランチャーのインストール → その他のオプションで、-XmxをデフォルトからModパックなら4〜6 GBへ引き上げる
パフォーマンス系Mod — Fabric上のSodium（古い環境ではOptiFine）はJava Editionのフレームレートを定番のように倍増させる
シミュレーション距離 — 1.18以降は描画距離と同じかそれ以下に保つ。大半のプレイには5〜6チャンクで十分
Javaランタイム — ランチャー同梱の新しいJavaを使わせること。古いシステムのJavaはそれ単体でカクつきを生む
バックグラウンド負荷 — タブを20枚開いたブラウザは、ヒープが伸びたがっているのと同じRAMを横取りする

Bedrockは別エンジン — そして別の問題

Microsoft Store版はJavaではなくネイティブコードで、控えめなハードウェアでも劇的に良く動く。この点は本当だ。ただしBedrockの「重い」という不満は、たいてい別の生き物である。大規模な公開サーバーでのサーバー側の遅延や、生のフレームレートではなくネットワークとコントローラーのジッタだ。主にスマホやコンシューマ機の友達と遊ぶなら、Bedrockが筋の通った選択になる。ModのためにJava版で遊ぶなら、ハードウェアのせいにする前に上の設定を直すこと。