【マイクラ】TPS/MSPT徹底解説!サーバーが重い・ラグい原因の直し方

⚠ 本記事は2026年6月時点の情報を元に編集部が独自に構成した解説です。MOD名・コマンド・JVM引数などの仕様には未確認要素を含みますので、最終的にはMojang公式や各MOD/ツールの公式をご確認ください。

サーバーが重い・カクつく・ラグい原因の9割は「TPS(サーバー処理の速さ)」の低下です。まずTPSとMSPTを計測して、ラグの主犯(エンティティ・チャンク・hopper・レッドストーン)を特定するのが最短ルート。マインクラフト(以下マイクラ)のマルチ/自宅サーバー運営者向けに、直し方を順番に整理します。

まず結論:重い時にやる順番

効果が大きくて手軽なものから試すのが鉄則です。原因を特定せずにMODを盛ったりメモリを増やしても、たいてい直りません。

迷ったらこの順番でやってみましょう。

1. 計測する(spark or /tick queryでTPS/MSPTを見る)
2. simulation distance(シミュレーション距離)を下げる(一番効くことが多い)
3. spark profilerでラグの主犯を特定する
4. 主犯を減らす(mob間引き・hopper最適化・重い装置の見直し)
5. それでもダメならサーバーソフトの見直し(Java版ならPaper系)

「これだけ覚えとけばOK」なくらい、上から順にやれば大半は改善します。

そもそもTPSとMSPTって何?fpsとは別物

TPS=サーバー側の処理速度、fps=自分の画面の滑らかさ。この2つは完全に別物で、混同すると原因を見誤ります。

まず用語をかみ砕いておきます。

• ティック:マイクラの世界が1回更新される単位。mobの移動・レッドストーン・作物の成長などが1ティックごとに計算される。
• TPS(Ticks Per Second):1秒あたりのティック数。正常は20TPS。これが下がると世界全体がスローになる。
• MSPT(Milliseconds Per Tick):1ティックの処理にかかった時間(ミリ秒)。50ms以内が目安。
• fps(Frames Per Second):自分のPCが1秒に何枚画面を描くか。クライアント(自分側)の滑らかさの指標。
• エンティティ:mob・アイテム・矢・トロッコなど「動くもの」全般。TPSを食う主犯。
• VRAM:グラボの専用メモリ。fps側(描画)に関わる。

なぜ「20TPS」と「50ms」がセットなのか

1秒÷20ティック=50ms。だから1ティックを50ms以内で終わらせられれば、キッチリ20TPSを維持できます。

MSPTが50msを超えると、次のティックが前のティックの終わりを待つことになり、TPSが20を割り込むという仕組み。ここが最重要ポイントです。

指標	正常値	意味	下がると起きること
TPS	20	サーバー処理速度	世界がスロー化、コマンド遅延、mob停止
MSPT	50ms以下	1ティックの処理時間	50ms超でTPS低下が始まる
fps	30〜60以上	画面の描画枚数	自分の画面だけカクつく(サーバーは無関係)

症状で切り分ける

自分だけカクカクで、他の人は普通に動いてる → fps(クライアント)の問題。全員そろってスローになる・mobがワープする → TPS(サーバー)の問題です。

症状	主な原因	どっちの問題
自分の画面だけカクつく	描画設定・グラボ・VRAM不足	fps(自分側)
全員でmobがカクつく・ワープ	TPS低下	サーバー
コマンドや扉の反応が遅い	TPS低下	サーバー
「Can’t keep up!」がログに出る	MSPT超過でティック遅延	サーバー
特定エリアに入ると重くなる	チャンク内のエンティティ/装置	サーバー

fps側(描画)の軽量化は別記事のテーマなので、この記事はサーバー側(TPS/MSPT)にしぼって進めます。

ラグを計測する:sparkと/tickの使い方

原因特定なしに対策するのは時間のムダ。まずは数字を見ましょう。計測ツールはJava版と統合版で事情が違います。

Java版:sparkが定番

sparkは、サーバーがCPU時間を何に使っているかを細かく分解してくれるプロファイラ(計測ツール)。ラグの主犯特定にはこれが一番強いです。

主なコマンドはこんな感じ(※コマンド仕様は2026年時点、要確認)。

コマンド	何ができるか
/spark tps	現在のTPS/MSPTをサッと確認
/spark health	メモリやGC(※後述)を含む健康診断
/spark profiler	30〜60秒記録して重い処理を分解表示

/spark profilerはラグが起きている最中に30〜60秒回すのがコツ。終わるとWeb上のレポートリンクが出て、どのmobやどの装置が重いか一目でわかります。

sparkはFabric/Paper/Purpurなどに導入できるMOD/プラグイン。バニラサーバーには基本入りません。

Java版バニラ:/tickコマンドで簡易チェック

MODなしでも、/tick queryで今のTPSとティック時間を確認できます。/tickはJava版限定で、スナップショット23w43a(1.20.3開発中)で追加された機能です。

サブコマンド	用途
/tick query	現在のTPS・ティック性能を表示
/tick rate <値>	目標TPSを変更(デフォルト20.0)
/tick sprint <ティック数>	全力で回して処理能力を計測
/tick freeze / unfreeze	ワールドの時間を止める/再開

計測目的なら/tick sprintが便利。**サーバーの素の処理力(伸びしろ)**が見えます。

統合版:専用の計測ツールは弱め(※要確認)

統合版はsparkのような公式プロファイラがなく、細かい原因特定がしづらいのが正直なところ。デバッグ画面や運用ツールで大まかなラグは見えますが、Java版ほどの分解はできません。

そのぶん統合版は「設定で予防する」のが基本方針になります(後述)。

ラグの主犯を減らす:エンティティ・チャンク・hopper・レッドストーン

サーバーラグの犯人はだいたい決まっています。エンティティ・読み込みチャンク・hopper・レッドストーンの4つ。ここを減らせばMSPTは大きく下がります。

主犯別・対策一覧

ラグの主犯	よくある原因	対策
エンティティ過多	mob増殖・アイテム散乱・大量繁殖	動物の頭数制限、アイテム自動処理、湧き潰し
チャンク読み込みすぎ	描画/シミュレーション距離が高い	simulation distanceを下げる(最優先)
hopper大量設置	選別機・仕分け倉庫が常時アイテムチェック	個数を減らす、空hopperを止める工夫
レッドストーン常時稼働	クロック回路が回りっぱなし	使う時だけ動くよう改修、間欠化

一番効く:シミュレーション距離を下げる

simulation distance(シミュレーション距離)=プレイヤーからどこまでの範囲を実際に動かすか。ここを下げると、ティックするチャンク数が一気に減ってCPU負荷がガクッと下がります。

• Java版:server.propertiesのsimulation-distanceを下げる(例:10→6)。view-distance(描画距離)も別途下げられる。
• 統合版:simulation-distanceを4〜6あたり、view-distanceを6前後が目安。統合版はシミュレーション距離が最大12チャンクまで(※要確認)。

体感への影響は小さいのに負荷は大きく減るので、重い時はまずここを下げときましょう。

エンティティを間引く

動物を数百匹まとめて飼うと確実に重くなります。繁殖しすぎた牛や、経験値トラップにたまったmobは大きな負荷源。

• 動物は必要な頭数だけに絞る
• ドロップアイテムはhopperやゴミ箱で早めに処理(アイテムも1個ずつエンティティ扱い)
• 使っていない大型トラップは止める or 撤去

hopperは「数」が正義の敵

hopperは1個1個が毎ティック中身をチェックしているので、仕分け倉庫でずらっと並べると地味に効きます。数を減らす・アイテムが流れない時は動かさない設計にするのが有効です。

やりがちだけど効果が薄い/逆効果なこと

「メモリを増やせば軽くなる」は半分ウソです。TPSラグの多くは処理内容の問題で、メモリを盛っても直りません。ここを勘違いすると沼ります。

やりがちな対策	実際の効果	補足
メモリ(RAM)を大量割り当て	△ 効果薄い〜逆効果	Java版のみ。盛りすぎるとGCが重くなることも
軽量化MODを大量導入	△ サーバーラグには効きにくい	軽量化MODの多くはfps(描画)向け。Java専用
描画距離だけ上げ下げ	△ TPSには効きにくい	描画はfps側。TPSはsimulation distance
高性能グラボに買い替え	✕ TPSには無関係	グラボはfps側。TPSはCPU/シングルスレッド性能
サーバー再起動でごまかす	△ 一時しのぎ	原因が残ってるとすぐ再発

メモリとGCの話(Java版)

GC(ガベージコレクション)=使い終わったメモリの掃除。この掃除中に一瞬処理が止まり、ラグの原因になります。

メモリを盛りすぎると1回の掃除が重くなることがあり、「増やせば増やすほど良い」ではないのがポイント。適量に抑えて、JVM引数(起動オプション)を最適化する方が効くケースが多いです(※JVM引数の具体値は環境依存、公式や配布元を要確認)。

軽量化MODはサーバーラグに効きにくい

軽量化MOD(Sodium系など)はfps=描画を軽くするもので、TPS(サーバー処理)にはほぼ効きません。しかもJava版専用。統合版には導入できないので注意しましょう。

サーバーTPSを本気で改善したいJava版なら、サーバーソフト自体を**Paper系(Paper/Purpur等)**に替えて最適化オプションを使う方が効果的です(※導入は自己責任・公式手順を確認)。

エディション別まとめ:Java版と統合版で何が違う

対策の道具立てがまるっと違います。ここを取り違えると「MODが入らない」「コマンドが無い」で詰まります。

項目	Java版	統合版
計測ツール	spark(高機能)・/tick	専用プロファイラは弱め(※要確認)
/tickコマンド	あり(1.20.3〜)	なし
メモリ割り当て/JVM引数	調整できる	基本いじれない
軽量化MOD	使える(fps向け)	使えない
サーバー最適化	Paper系で強力に	設定ファイル中心
主な負荷対策	sim距離+主犯特定+ソフト最適化	sim距離+view距離の設定

ざっくり言うと、**Java版は「計測して主犯を叩く」、統合版は「設定で予防する」**が基本戦略です。

合わせて読みたい

• サーバーに必要なメモリ・CPUの目安
• レッドストーン装置の軽量化・作り方
• おすすめMOD・軽量化MODまとめ
• マルチプレイ・サーバー運営の基礎
• 快適プレイのための設定・環境

次にやること

1. /spark tps(または/tick query)で今のTPS/MSPTを確認する
2. simulation distanceを1〜2下げて再計測、変化を見る
3. ラグ中に/spark profilerを30〜60秒回して主犯を特定する
4. 特定した主犯(mob・hopper・装置)を減らす/止める
5. Java版でまだ重いならPaper系サーバー+JVM引数を検討する(※公式手順を確認)

まずは計測から。数字を見ずに対策するのが一番遠回りなので、/spark tpsか/tick queryを打つところから始めましょう。