冒頭の直接回答
MinecraftサーバーのTPS（Ticks Per Second）低下は、「①原因を計測して特定 → ②設定で負荷を減らす → ③エンティティ/チャンク/回路/プラグインを整理 → ④スペックと運用を見直す」の順で最短で改善できます。
要点
- まずは /tps と /mspt（Paper/Spigot系）または /spark tps で現状を確認
- 次に view-distance / simulation-distance を適正化（最も効果が出やすい）
- エンティティ（Mob/アイテム/ホッパーなど）とチャンク読み込み（移動・探索）の負荷を抑える
- レッドストーン・自動化装置の常時稼働を減らす（ホッパー/コンパレータが特に重い）
- プラグイン・MODの整理（相性/更新/代替）とプロファイル（spark）でボトルネックを潰す
- 最後にCPU（シングル性能）・メモリ・NVMeなどサーバースペックを適正化
本記事は2025年12月時点のPaper/Spigot系（Java版）を中心に、設定例と手順を「コピペ→確認→微調整」で進められる形でまとめています。
MinecraftサーバーのTPSとは
TPSはサーバーが1秒間に処理できるゲーム内更新（tick）の回数です。理想は20.0 TPSで、これを下回ると「Mobの動きがカクつく」「ブロック破壊が遅れる」「ヒット判定が遅れる」など、いわゆるサーバーラグが発生します。
TPSとFPSの違い
TPSはサーバー側の処理速度、FPS（Frames Per Second）はクライアント側の描画速度です。FPSが高くてもTPSが低いとマルチでは重く感じます。逆にTPSが20でもFPSが低い場合はPC/設定/シェーダーなどクライアント側が原因です。
TPS値の確認方法
まずは「TPS」と「MSPT」をセットで見ます。TPSが20でもMSPTが高い（50msに張り付く）場合、瞬間的なカクつきが出ることがあります。
- /tps：直近1分/5分/15分のTPS平均を表示（Paper/Spigot）
- /mspt：tick処理時間（平均・最小・最大）を表示（Paper）
- /spark tps：TPS/MSPTに加えCPU使用率などを表示（spark）
- ログ/監視：長時間の傾向はGrafana等の監視やホスティングのメトリクスが便利
/tps
/mspt
/spark tpsTPS低下の主な原因
TPS低下の原因は大きく「エンティティ」「チャンク」「回路」「プラグイン/MOD」「スペック」の5つに集約できます。症状が似ていても対処が違うので、まずはどれが支配的かを切り分けます。
1. エンティティ過多
Mob・アイテム・ボート・トロッコ・額縁・防具立てなどが多いと、毎tickのAI/衝突/判定が増えます。特に「アイテムが大量に散らばる」「村人が多い」「統合トラップが常時稼働」は要注意です。
2. チャンク読み込みの負荷
探索や高速移動、ネザー高速道路、エリトラ飛行などで新規チャンク生成/読み込みが集中するとCPUとストレージI/Oが跳ねます。初期ワールド生成（pre-generate）未実施のサーバーで顕著です。
3. レッドストーン回路の複雑化
ホッパー・コンパレータ・クロック回路・常時稼働の仕分け機・巨大な自動化装置はTPSに直撃します。『使ってないのに重い』は大抵これです。
4. プラグイン・MODの競合や非効率なコード
更新が止まったプラグイン、互換性の薄いMOD、設定の重い保護/経済/ログ系、タスクを毎tick回す系が原因になります。sparkでメソッド単位の負荷を確認すると最短です。
5. サーバースペック不足
Minecraftのメイン処理は基本的に単一スレッド依存なので、コア数よりCPUのシングル性能が重要です。さらにNVMeのI/Oと十分なメモリ（GCの安定）が効いてきます。
server.propertiesによる基本最適化
まず効くのは距離系です。view-distance（描画/送信範囲）とsimulation-distance（エンティティ等をtickする範囲）は、設定を少し下げるだけで負荷が大きく下がります。
推奨設定項目
以下は「一般的に効果が出やすく、体感の悪化が少ない」順に並べた基本セットです。プレイヤー人数やワールド設計で最適値は変わるため、まずは下限寄りからスタートして必要に応じて上げてください。
| 項目 | 推奨値の目安 | 効果/注意点 |
|---|---|---|
| view-distance | 6〜8（初期10から下げる） | 送信チャンク数が減り、CPU/帯域が大幅に軽くなる。低すぎると遠景が見えない。 |
| simulation-distance | 3〜6 | Mob/レッドストーン等のtick範囲が減る。トラップ/装置の挙動距離に影響。 |
| sync-chunk-writes | true（Linux） | チャンク書き込みの最適化。Linux環境での性能改善が期待できる。 |
| network-compression-threshold | 256〜512 | 帯域とCPUのバランス調整。回線が太いなら高め、CPUが弱いなら上げすぎ注意。 |
| max-tick-time | -1（監視前提） | フリーズ時の強制停止を回避。暴走対策は別途監視/再起動設計が必要。 |
実際のserver.propertiesは環境差が大きいので、まずは距離系だけ反映して効果を見るのが安全です。
# 例：小〜中規模サーバーの出発点
view-distance=7
simulation-distance=4
sync-chunk-writes=true
# 圧縮はお好み（回線/CPU次第）
network-compression-threshold=256view-distanceの最適化効果
view-distanceは『半径Rチャンク』の範囲を送信するため、送信量はざっくり(2R+1)^2に比例します。例えば10→7に下げるだけで、R=10なら(21^2)=441、R=7なら(15^2)=225なので、送信対象が約49%まで減ります（体感しやすい改善）。
| 設定値 | 処理チャンク数 | 推奨環境 |
|---|---|---|
| 10 | 441チャンク | 高スペックサーバー、少人数 |
| 8 | 289チャンク | 標準的な環境 |
| 6 | 169チャンク | 低スペック、大人数サーバー |
設定後は必ずサーバーを再起動してください。
spigot.yml/paper.ymlによる高度な設定
server.propertiesで基礎を固めたら、次はSpigot/Paper側のYAML設定で『無駄なtick』を減らします。2025年のPaperでは設定ファイルが分割されていることが多く、まずは該当キーがどのファイルにあるか確認してから調整してください。
spigot.ymlの推奨設定
spigot.ymlは主に「エンティティの活性化範囲」「マージ（統合）」「ホッパーなどのtick頻度」など、TPSに直結する項目が多いです。以下は代表的な調整例です（数値は出発点）。
# spigot.yml（例）
world-settings:
default:
# Mobのスポーン処理範囲を縮める（探索型サーバーでは4が無難）
mob-spawn-range: 4
# エンティティの活性化範囲（近くにいないものは低頻度で更新）
entity-activation-range:
animals: 24
monsters: 24
raiders: 32
misc: 12
water: 12
# アイテム/経験値の統合（落ちている物が多い環境で効く）
merge-radius:
item: 3.5
exp: 4.0
# ホッパー処理頻度（後述）
ticks-per:
hopper-transfer: 16
hopper-check: 16paper.ymlのさらなる最適化
Paperはバージョンによりpaper-global.yml / paper-world-defaults.yml / worldごとのpaper-world.ymlに設定が分かれます。まずは『デフォルト→必要なキーだけ上書き』が鉄則です。
- グローバル設定：config/paper-global.yml（全ワールド共通）
- ワールド既定：config/paper-world-defaults.yml（全ワールドのデフォルト）
- ワールド個別：<world>/paper-world.yml（そのワールドだけ上書き）
以下は多くの環境で効果が出やすい項目の例です。キー名や階層はバージョンで変わるため、実ファイル内で検索して該当箇所を調整してください。
# paper-world-defaults.yml（例：一部）
# 例）負荷の大きい要素の最適化
# optimize-explosions: true
# per-player-mob-spawns: true
# max-auto-save-chunks-per-tick: 6
# delay-chunk-unloads-by: 10s
# 例）レッドストーン最適化（互換性に注意）
# use-faster-eigencraft-redstone: trueホッパー最適化の影響
ホッパーは『常時アイテムを探して吸い込む/押し出す』ため、数が増えるほどTPSを削ります。spigot.ymlのhopper-transfer / hopper-checkを増やす（頻度を下げる）と大幅に軽くなりますが、搬送速度が遅くなります。仕分け機の詰まりが出ないか必ずテストしてください。
エンティティとチャンク管理の最適化
設定で基礎を固めたら、運用面の最適化で『いつでも重い』状態を解消します。特に「アイテム散乱」「放置トラップ」「探索で新規チャンクを量産」があるサーバーは効果が大きいです。
推奨プラグイン: ClearLag
ClearLag系のプラグインは、落ちているアイテムやMobを定期的に整理して瞬間的な負荷を下げます。ただし自動化装置や農場の挙動を壊すことがあるため、導入するなら『警告→猶予→対象を限定』の運用がおすすめです。
- まずは設定でアイテム散乱が起きにくいようにする（merge-radius / despawn時間の見直し）
- 次にClearLag等で『地面のアイテムのみ』『一定数以上のみ』など限定して整理
- 村人・名札付きMob・ボート等の重要エンティティは除外する
チャンク事前生成の実施
新規チャンク生成は非常に重いので、サーバー公開前や大型イベント前にチャンクを事前生成（pre-generate）しておくと安定します。一般的にはChunkyなどのプラグイン/ツールが使われます。
# 例：Chunky（プラグイン）を使う場合の流れ
# 1) ワールド選択
/chunky world world
# 2) 中心と半径を指定（例：半径5000ブロック）
/chunky radius 5000
# 3) 生成開始
/chunky start
# 4) 進捗確認
/chunky progressワールドボーダーの設定
探索で無限に遠くへ行ける状態だと、新規チャンク生成が続いて負荷が上がり続けます。運用が落ち着くまではワールドボーダーで範囲を区切ると効果的です。
/worldborder set 10000
/worldborder warning distance 64
/worldborder warning time 10上の例はワールド中心から半径5000ブロック（直径10000）の範囲です。プレイヤー数と遊び方に合わせて調整してください。
Timingsレポートによる診断方法
原因の特定にはプロファイリングが必須です。なお、Paper 1.21以降はsparkが主流で、Timingsは無効化（no-op）になっているバージョンがあります。まずはsparkで診断するのがおすすめです。
Timingsレポートの取得手順
旧来のTimingsを使う場合（対応している環境のみ）は、以下の流れで取得します。Paper 1.21以降では動かないことがあるため、動作しなければ次の「spark手順」を使ってください。
# Timings（動作する環境のみ）
/timings on
# 数分プレイして負荷が再現するのを待つ
/timings pastesparkはPaper/Spigot/Forge/Fabric等で利用でき、レポートが読みやすいのが強みです。
# spark（推奨）
/spark tps
# プロファイル開始（数分）
/spark profiler start
# 再現中に確認
/spark profiler open
# 終了して共有URLを取得
/spark profiler stopレポートの読み方
レポートは大きく『メインスレッドのtick時間』『どの処理（プラグイン/エンティティ/チャンク）が時間を使っているか』を見ます。優先順位は以下です。
- MSPTが50msを超えている時間帯があるか（超えるとTPSが20を維持できない）
- メインスレッドで時間を食うトップ項目（プラグイン名、entityTick、chunkLoadなど）
- entityTickが高い場合：村人/トラップ/放置エリアを疑う
- chunkLoadやgenerationが高い場合：探索・高速移動・事前生成不足を疑う
- 特定プラグインが突出：更新・設定・代替の検討（重い機能を無効化）
サーバースペックの選び方
同じ設定でも、CPUやストレージが弱いとTPSは安定しません。特にJava版のサーバーはCPUのシングル性能が最重要で、次にNVMe（I/O）とメモリ（GC安定）が効きます。
Minecraftサーバーに求められるスペック
- CPU：高クロック/高IPC（1コア性能重視）＋余裕のあるコア数（裏タスク/プラグイン用）
- メモリ：少人数なら4〜8GB、プラグイン多め/長時間稼働は8〜16GBが安心
- ストレージ：SSDよりNVMe推奨（チャンクI/O・ログ・バックアップで効く）
- 回線：同時接続が増えるほど上り帯域とレイテンシが重要
プレイヤー数別推奨スペック
| 想定 | Vanilla/軽量 | プラグイン多め（Paper） | MOD多め（Forge/Fabric） |
|---|---|---|---|
| 〜5人 | 4GB / 2〜4vCPU / NVMe | 6〜8GB / 4vCPU / NVMe | 8GB+ / 4vCPU / NVMe |
| 6〜15人 | 6〜8GB / 4vCPU / NVMe | 8〜16GB / 4〜8vCPU / NVMe | 16GB+ / 6〜8vCPU / NVMe |
| 16〜30人 | 8〜16GB / 6〜8vCPU / NVMe | 16GB+ / 8vCPU+ / NVMe | 32GB+ / 8vCPU+ / NVMe |
上はあくまで目安です。『探索が多い』『村人が多い』『常時稼働の自動化が多い』ほど、同人数でも上の段階が必要になります。
MinecraftサーバーTPS最適化の参考動画（日本語）
文章だけだと設定ファイルの場所や手順がイメージしにくい部分もあるので、日本語で分かりやすく解説している動画を3本紹介します。まずは全体像を掴んでから、本記事の手順（距離設定→エンティティ/チャンク対策→sparkで原因特定）に沿って進めると改善が早いです。
① Paper導入と軽量化の考え方を一気に把握したい人向け
Paperを使う理由、軽量化設定で「どこを触ると効くのか」の方向性がまとまっています。最初の一本として、全体の地図を作るのに向きます。
② サーバー方式の選び方（Paper/プラグイン/MODなど）を整理したい人向け
Java版のサーバー構築を複数パターンで比較しながら解説しています。最適化の前提となる「自分の運用に合う方式」を決めるのに役立ち、動画内に軽量化サーバーの建て方パートもあります。
③ 「サーバーが重い」ときの見直しポイントを運用目線で掴みたい人向け
設定をいじる前に、エンティティ（Mob/アイテム/村人）や装置の常時稼働、プレイスタイル由来の負荷をどう疑うかが分かりやすい内容です。原因の当たりをつけてから設定調整に入ると迷いにくくなります。
動画で手順のイメージが掴めたら、本記事の「距離設定（view/simulation）」「エンティティ・チャンク対策」「sparkプロファイル」の順に実施し、改善前後で /mspt と /spark tps を比較すると効果が判断しやすいです。
サーバー選びの比較診断ツール
ここでは、あなたの用途から『どのタイプのサーバーが合うか』を短時間で判断できるチェックリストを用意しました。Minecraftサーバーに最適なホスティングサービスを選ぶ際、複数のサービスを比較検討することが重要です。サーバー比較診断サイト「comparison.quicca-plus.com」では、主要なVPSプロバイダーやゲーム特化型サーバーの料金プラン、スペック、特徴を一覧で比較でき、自分のプレイ人数や予算に合わせた最適なサービスを効率的に見つけることができます。
診断1：遊び方（最重要）
- Java版（Paper/Spigotでプラグインを使いたい） → VPS/レンタルVPSが自由度高め
- MODパック（Forge/Fabric）で重い → メモリ多め（16GB以上）＋NVMe推奨
- 短期（週末だけ） → 時間課金やオンデマンドが便利
- 長期（常時公開） → 月額固定＋バックアップ/監視/自動再起動が重要
診断2：人数とワールド規模
- 〜10人で探索多め：まずは8GB前後（CPU4コア以上）から
- 〜20人以上：16GB以上＋CPU余裕、ワールド事前生成とボーダーで安定化
- 建築・自動化が多い：人数より『装置数』が支配的。ホッパー/村人で一気に重くなる
診断3：管理の手間
- コマンドやLinux操作に慣れている → VPS（自由度/コスパ）
- できるだけ簡単に始めたい → ゲーム特化VPS（テンプレ/管理画面）
- 企業/コミュニティで運用 → SLA/サポート/バックアップの充実度を重視
おすすめMinecraft対応サーバーサービス
Minecraftサーバーを運用する際、適切なホスティングサービスの選択は快適なプレイ環境を実現する上で極めて重要です。ここでは、2025年11月現在の最新情報に基づき、Minecraft運用に適した主要なサーバーサービスを詳しく比較します。
ConoHa for GAME
ConoHa for GAMEは、GMOインターネットグループが提供するゲーム特化型VPSサービスです。Minecraftサーバーのテンプレートが豊富に用意され、初心者でも簡単にサーバーを立ち上げられます。
主な特徴
- Minecraft（Java版/統合版）の自動インストール機能
- Paper、Spigot、Forge、Fabric対応テンプレート
- 管理画面から簡単にバージョン変更やMOD管理が可能
- 東京・大阪のデータセンターで低遅延
- 時間単位の課金制で柔軟な運用が可能
料金プラン（2025年11月時点）
- 2GBプラン: 1,065円/月
- 4GBプラン: 2,033円/月
- 8GBプラン: 4,081円/月
推奨利用シーン: 初めてMinecraftサーバーを立てる初心者、友達数人で遊ぶ小規模サーバー
Xserver VPS for Game
Xserver VPS for Gameは、エックスサーバー株式会社が提供するゲーム専用VPSサービスです。高性能なCPUと高速SSDにより、安定したパフォーマンスを実現します。
主な特徴
- AMD EPYC（第3世代）採用で高クロック周波数
- NVMe SSD標準搭載で高速なI/O性能
- Minecraft統合管理ツール「Minecraft manager」搭載
- 自動バックアップ機能（14日間）
- 複数バージョンの同時運用が可能
料金プラン（2025年11月時点）
- 2GBプラン: 1,150円/月
- 4GBプラン: 2,200円/月
- 8GBプラン: 4,400円/月
推奨利用シーン: 中規模サーバー（10〜20人）、長期運用を前提としたコミュニティサーバー
さくらのVPS
さくらのVPSは、さくらインターネット株式会社が提供する老舗VPSサービスです。カスタマイズ性が高く、上級者向けの柔軟な設定が可能です。
主な特徴
- root権限でのフル管理が可能
- OS選択の自由度が高い
- ストレージの追加が柔軟
- 24時間365日のサポート体制
料金プラン（2025年11月時点）
- 2GBプラン: 1,738円/月
- 4GBプラン: 3,520円/月
- 8GBプラン: 7,040円/月
推奨利用シーン: サーバー管理の経験がある上級者、カスタム設定を多用する場合
KAGOYA CLOUD VPS
KAGOYA CLOUD VPSは、カゴヤ・ジャパン株式会社が提供する高品質なVPSサービスです。24年以上の運用実績を持つ老舗プロバイダーで、安定性に定評があります。
主な特徴
- 専用ネットワーク接続で安定した通信品質
- 10Gbps共有回線で高速通信
- 柔軟なスペック変更が可能
- 法人利用にも対応した高セキュリティ
料金プラン（2025年11月時点）
- 2コア/2GBプラン: 979円/月
- 3コア/4GBプラン: 1,540円/月
- 4コア/8GBプラン: 3,960円/月
推奨利用シーン: 安定性を最優先する中規模サーバー、法人やコミュニティでの長期運用
シンVPS
シンVPSは、エックスサーバー株式会社が提供する新しいVPSサービスです。最新技術を採用し、高速性に特化しています。
主な特徴
- 最新のAMD EPYC（第4世代）プロセッサー搭載
- オールNVMe環境で超高速I/O
- シンプルな料金体系
- モダンな管理画面
料金プラン（2025年11月時点）
- 2GBプラン: 900円/月
- 4GBプラン: 1,800円/月
- 8GBプラン: 3,600円/月
推奨利用シーン: コストパフォーマンスを重視、小〜中規模の高速サーバー
ConoHa VPS
ConoHa VPSは、ConoHa for GAMEのベースとなる汎用VPSサービスです。ゲーム特化機能は少ないものの、柔軟なカスタマイズが可能です。
主な特徴
- 豊富なOSテンプレート
- APIによる自動化対応
- 追加ディスクやIPアドレスの柔軟な追加
- スナップショット機能
料金プラン（2025年11月時点）
- 2GBプラン: 1,065円/月
- 4GBプラン: 2,408円/月
- 8GBプラン: 4,818円/月
推奨利用シーン: 上級者向けの柔軟な環境構築、複数のサービスを1台で運用
その他の選択肢
ロリポップ！for Gamersは、GMOペパボ株式会社が提供するゲーム特化レンタルサーバーです。低価格で始められる点が魅力です。
カラフルボックスは、高速LiteSpeedサーバーを採用した共有レンタルサーバーで、小規模なMinecraftサーバーにも対応しています。
主要サーバーサービス比較表
| サービス | 目安プラン（10人前後） | 料金目安（2025年12月） | 特徴 |
|---|---|---|---|
| ConoHa for GAME | 8GB / 6コア / NVMe 100GB | 8GB 8,083円/月（時間課金の月額上限の例） | 短期〜長期、テンプレ/管理画面で導入が楽 |
| Xserver VPS for Game | 8GB | 8GB 4,400円/月（1ヶ月の例） | 国内大手、プランが分かりやすい |
| さくらのVPS | 8GB / 仮想6Core / SSD 400GB | 月7,040〜7,920円（リージョンで変動） | 老舗、安定運用志向 |
| KAGOYA CLOUD VPS | 8GB / 仮想6Core / NVMe 800GB | 月額上限 3,410円（NVMeプラン） | 従量制＋上限、コスパ寄り |
| シンVPS | 8GB | 8GB 1,900円/月〜（表示例） | メモリコスパ訴求（最新条件は要確認） |
| ConoHa VPS | 12GB（8GB相当が増量された表示例） | 更新時 8,083円/月（時間課金上限の例） | 汎用VPS、自由度高い |
比較表は『入口の目安』です。実際はCPU世代・共有/専有・ストレージI/O、そしてサポート/バックアップの有無で体感が変わります。
よくある質問（FAQ）
Q1. TPSが15以下に低下した場合、どこから手をつけるべきですか？
まずは/msptと/spark tpsでMSPTが50msを超えているか確認し、次にview-distance/simulation-distanceを下げて即効性を出します。その上でspark profilerを回し、entityTick（エンティティ）なのかchunkLoad/generation（チャンク）なのか、あるいは特定プラグインなのかを特定して対処します。
Q2. BukkitとSpigotとPaperの違いは何ですか？
Bukkitは歴史的なAPI/系統の呼び名、SpigotはBukkit互換で高速化・管理機能を追加したサーバー実装、PaperはSpigot互換を維持しつつさらに最適化や機能拡張を進めた実装です。TPS改善目的ならまずPaperが定番です。
Q3. プレイヤーが10人の場合、最低限必要なメモリは何GBですか？
軽量なVanilla寄りなら6〜8GBが現実的な下限です。プラグインが増える、探索が多い、村人や自動化が多い場合は8〜16GBを推奨します。MOD環境はさらに上振れしやすいです。
Q4. レッドストーン回路がTPSに与える影響を軽減する方法はありますか？
ホッパー数を減らす（必要最小限＋水流/ドロッパー活用）、常時クロックを避ける（必要時のみON）、回路の稼働エリアを分散し、simulation-distance外で止まる設計にするのが効果的です。
Q5. MODサーバーでもSpigot/Paperのような最適化は可能ですか？
MOD環境（Forge/Fabric）はPaper系の設定最適化とは別系統ですが、距離設定、チャンク事前生成、エンティティ整理、sparkでのプロファイル、そしてサーバー/クライアントのMOD見直しは共通で効きます。MOD固有の最適化MOD（例：AI抑制、チャンクI/O最適化）も検討対象です。
まとめ
- TPS改善は計測→距離設定→エンティティ/チャンク/回路整理→プラグイン最適化→スペックの順が最短
- まずは view-distance / simulation-distance を下げて効果を見る
- Paper 1.21以降はsparkで原因特定（Timingsが無効化される場合あり）
- 探索が多いサーバーはチャンク事前生成とワールドボーダーで安定する
ここまでの手順を順番に行えば、多くのケースでTPSは改善します。もし改善しない場合は、sparkレポート（URL）とサーバー構成（人数、プラグイン一覧、距離設定、CPU/メモリ）を整理すると原因に一直線で辿り着けます。