【2025年7月最新】マイクラ TPS下がる原因徹底調査ガイド！Timings v2・Spark プロファイラ・エンティティ削減・タイルエンティティ対策まで完全解説

サーバーの紹介リンクにはアフィリエイト要素が含まれる場合がありますが、読者の皆様に有益な情報を提供することを最優先としています。最新情報は各公式サイトをご確認ください。

2025年7月9日

【2025年7月最新】マイクラ TPS下がる原因徹底調査ガイド！Timings v2・Spark プロファイラ・エンティティ削減・タイルエンティティ対策まで完全解説

この記事でわかること：

TPSが下がる根本的な原因とその特定方法
Timings v2を使った詳細な負荷解析手順
Sparkプロファイラーによる高度なパフォーマンス調査
エンティティとタイルエンティティの最適化テクニック
サーバー設定による根本的な改善方法

マイクラサーバーを運営していると、必ずと言っていいほど遭遇するのがTPS（Ticks Per Second）の低下問題です。TPSが下がると、プレイヤーの動きがカクカクになったり、ブロックの破壊が遅れたりと、ゲーム体験が大幅に悪化してしまいます。

本記事では、一流のマイクラサーバー管理者として長年の経験を積んだ筆者が、TPS低下の原因を徹底的に調査し、根本的な解決策を提示します。単なる対症療法ではなく、プロが実際に使用している高度な調査ツールと最適化手法を詳しく解説いたします。

TPSとは何か？なぜ重要なのか

TPSの基本概念

TPS（Ticks Per Second）とは、マイクラサーバーが1秒間に処理できるゲームティック数を表す指標です。理想的な状態では常に20TPSを維持する必要があります。1ティックは50ミリ秒に相当し、この間にサーバーはあらゆるゲーム内処理を完了させなければなりません。

出典: MCINFO – TPS確認画面の例

TPS値	サーバー状態	プレイヤーへの影響	対応の緊急度
18-20	良好	影響なし	問題なし
15-17	軽微な負荷	わずかな遅延	経過観察
10-14	中程度の負荷	明確な遅延	調査・対策必要
5-9	重度の負荷	著しい遅延	緊急対策必要
1-4	危険な状態	ほぼプレイ不可	即座に対応

⚠️ 警告： TPSが15を下回ったら即座に原因調査を開始してください。放置すると完全にサーバーが停止する可能性があります。

Timings v2による詳細負荷解析

Timings v2とは

Timings v2は、Spigot系サーバー（Paper、Spigot、Purpur等）に標準搭載されている高性能なパフォーマンス解析ツールです。サーバーの各種処理にかかる時間を詳細に記録し、ボトルネックとなっている箇所を特定できます。

基本的な使用手順

計測開始
/timings on
計測実行
最低3分間、問題が発生している状況でサーバーを稼働させます。高負荷時間帯での計測が効果的です。
計測停止とレポート生成
/timings paste

Timingsレポートの読み方

生成されたレポートでは、以下の項目を重点的にチェックします：

Overall（全体）：サーバー全体の処理時間分布
Entity Activation（エンティティ処理）：mob、アイテム等の処理負荷
Tile Entity Ticking（タイルエンティティ）：チェスト、ホッパー等の処理負荷
Lighting（照明計算）：光源処理の負荷
Plugin（プラグイン）：各プラグインの個別負荷

💡 プロのコツ： レポートで処理時間が1.00%を超える項目は要注意です。5.00%を超える項目は緊急に対処が必要です。

Sparkプロファイラーによる高度なパフォーマンス調査

Sparkプロファイラーの導入

Sparkは、Timingsよりもさらに詳細な解析が可能な高機能プロファイラーです。CPU使用率、メモリ使用量、個別MODの負荷まで詳細に調査できます。

インストール手順

Sparkプラグインをダウンロードしてpluginsフォルダに配置
サーバーを再起動
権限設定を確認（spark.profiler権限が必要）

基本的なプロファイリング手順

# 3分間のCPUプロファイリング
/spark profiler –timeout 180

# メモリ使用量の調査
/spark heapdump

# 特定スレッドの詳細調査
/spark profiler –thread “*” –timeout 300

Sparkレポートの重要指標

指標	正常範囲	注意値	危険値
CPU使用率	～70%	70-85%	85%～
メモリ使用率	～75%	75-90%	90%～
GC頻度	～5回/分	5-10回/分	10回/分～

出典: Quicca Plus – サーバー最適化ガイド

エンティティ削減による根本的な改善

エンティティが与える負荷の実態

エンティティ（mob、ドロップアイテム、経験値オーブ等）は、サーバーリソースを大量に消費する主要因の一つです。特に大量のmobが同一チャンクに存在すると、AI処理により深刻な負荷が発生します。

効果的なエンティティ削減方法

1. server.propertiesによる基本設定

# 動物の自然スポーン数制限
spawn-animals=true
animals=10

# モンスターの自然スポーン数制限
spawn-monsters=true
monsters=50

# 水中mobの制限
water-animals=5

# NPCの制限
spawn-npcs=true
npcs=10

2. Paper設定による詳細制御

# paper.yml設定例
entities:
spawning:
monster-spawn-max-light-level: 0
despawn-ranges:
monster:
soft: 28
hard: 56
creature:
soft: 24
hard: 32
behavior:
mob-effects:
speed-multiplier: 0.5

3. プラグインによる自動制御

ClearLag：定期的なエンティティ削除
StackMob：同種mobのスタック化
MobLimiter：エリア別mob数制限

タイルエンティティ最適化の実践

高負荷なタイルエンティティの特定

タイルエンティティは、特別な処理を必要とするブロック（チェスト、ホッパー、看板等）です。これらが大量に存在すると、毎ティック膨大な処理が発生します。

タイルエンティティ	負荷レベル	主な処理内容	最適化方法
ホッパー	非常に高	アイテム移動・検索	代替手段の使用
チェスト	中	インベントリ管理	統合・削減
看板	低〜中	テキスト処理	設置数制限
レッドストーン系	高	信号計算	回路簡素化

ホッパー最適化の具体策

ホッパーの無効化
# spigot.yml設定
hopper-transfer: 8
hopper-check: 1
hopper-amount: 1
代替システムの構築
- 水流式アイテム運搬
- ドロッパー式搬送システム
- プレイヤー手動回収
集約による効率化

複数の小規模システムを大規模システムに統合し、総ホッパー数を削減

⚠️ 重要： ホッパーは1個でも常時動作するため、100個のホッパーは100倍の負荷となります。必要最小限の使用を心がけてください。

サーバー設定による根本的な最適化

JVMパラメータの最適化

適切なJava起動オプションは、サーバーパフォーマンスに劇的な改善をもたらします。

# 推奨JVMオプション（8GBメモリの場合）
java -Xms8G -Xmx8G -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions \
-XX:MaxGCPauseMillis=100 -XX:+DisableExplicitGC -XX:TargetSurvivorRatio=90 \
-XX:G1NewSizePercent=50 -XX:G1MaxNewSizePercent=80 -XX:G1MixedGCLiveThresholdPercent=50 \
-XX:+AlwaysPreTouch -jar server.jar nogui

重要な設定項目の解説

-Xms / -Xmx：初期・最大メモリ容量（同じ値に設定推奨）
UseG1GC：G1ガベージコレクタの使用
MaxGCPauseMillis：ガベージコレクションの目標停止時間
AlwaysPreTouch：メモリの事前確保

Paper.yml最適化設定

# paper.yml重要設定
settings:
save-player-data: 300
save-user-cache-on-stop-only: false

world-settings:
default:
# チャンク関連
max-auto-save-chunks-per-tick: 6
prevent-moving-into-unloaded-chunks: true

# エンティティ関連
per-player-mob-spawns: true
mob-spawner-tick-rate: 2

# Redstone最適化
redstone-implementation: FAST

監視と継続的改善

定期監視の重要性

サーバーパフォーマンスは時間と共に変化するため、継続的な監視が必要です。以下の項目を定期的にチェックしましょう。

TPS値の推移（最低でも週1回）
メモリ使用量の変化
プレイヤー数とパフォーマンスの相関
新規建築・装置による影響

出典: MCINFO – TabTPSプラグインによる監視

アラート設定の推奨

# 監視スクリプト例（Linux）
#!/bin/bash
TPS=$(rcon-cli tps | grep “TPS from last 1m” | awk ‘{print $4}’)
if (( $(echo “$TPS < 15.0” | bc -l) )); then echo “WARNING: TPS down to $TPS” | mail -s “Server Alert” admin@example.com fi