冒頭の直接回答
マインクラフトのTPS（Ticks Per Second）最適化は、サーバーの処理負荷を軽減してゲームを快適にする技術です。TPSは本来20が標準値で、これを下回るとラグやブロック破壊遅延が発生します。最適化には「不要なチャンクのアンロード」「エンティティの削減」「プラグイン・MODの見直し」「サーバー設定の調整」が必要で、適切な対策により重いサーバーでも快適なプレイ環境を実現できます。
要点
- TPSは1秒間に実行されるゲーム内処理のサイクル数で、20TPS（50ms/tick）が標準値
- TPS低下の主な原因はエンティティ過多・チャンクロード過多・レッドストーン回路・プラグイン競合
- Paper/Purpur等の最適化サーバーソフトウェアへの切り替えで大幅な改善が可能
- server.propertiesとbukkit.ymlの設定調整で負荷を30〜50%削減できる
- 定期的なTPS監視とボトルネック特定が継続的なパフォーマンス維持の鍵
マインクラフトのTPSとは何か：基礎知識と重要性
TPSの定義と標準値
TPS（Ticks Per Second）は、マインクラフトサーバーが1秒間に実行するゲームループの回数を示す指標です。マインクラフトは20TPSで動作するよう設計されており、1tick=50ミリ秒で動作します。この20TPSが維持されていれば、プレイヤーの動き、モブのAI、レッドストーン回路、農作物の成長など、すべてのゲーム内処理が正常に機能します。
TPSが20を下回ると、ゲーム内の時間進行が遅くなり、プレイヤーは様々な不具合を体験します。例えば、ブロックを破壊してもすぐに消えない、攻撃の反応が遅れる、モブの動きがカクカクする、などの現象が発生します。TPSが15以下になると明確なラグとして認識され、10以下では実質的にプレイが困難になります。
TPSとFPSの違い
多くのプレイヤーがTPSとFPS（Frames Per Second）を混同しますが、これらは全く異なる指標です。FPSはクライアント側（各プレイヤーのPC）での画面描画速度を示し、グラフィックカードやCPUの性能に依存します。一方、TPSはサーバー側のゲームロジック処理速度を示し、サーバーのCPU性能とプログラムの効率性に依存します。
FPSが低くてもTPSが20であればゲームロジックは正常に動作しており、グラフィック設定を下げるなどクライアント側の対策で改善できます。しかし、TPSが低い場合はサーバー全体の問題であり、接続しているすべてのプレイヤーに影響します。そのため、マルチプレイサーバーの運営ではTPS維持が最優先課題となります。
TPS低下がゲームプレイに与える影響
TPSが低下すると、ゲーム体験全体が損なわれます。具体的な影響として、ブロック破壊の遅延（破壊したブロックが復活する現象）、モブのワープ現象（位置情報の更新遅延）、レッドストーン回路の誤動作、アイテムのドロップ遅延、チャット送信の遅延などが発生します。
特に大規模な建築プロジェクトや自動化システムを構築しているサーバーでは、TPS低下は致命的です。例えば、農場の自動収穫システムが正常に動作しなくなったり、トラップタワーの効率が大幅に低下したりします。また、PvP（対人戦）環境では、TPS低下により公平な戦闘が不可能になり、サーバーの評判を大きく損ねる原因となります。
TPS低下の主な原因：ボトルネックの特定方法
エンティティ過多による負荷
マインクラフトにおけるエンティティとは、モブ（動物や敵対Mob）、ドロップアイテム、乗り物、経験値オーブ、矢などの発射物など、動的に存在するすべてのオブジェクトを指します。これらのエンティティは毎tick処理が必要で、数が増えるほどサーバー負荷が増大します。
特に問題となるのは、プレイヤーが放置したドロップアイテム、過剰に繁殖した動物、トラップタワーで溜まったモブなどです。1つのチャンクに100体以上のエンティティが存在すると、そのチャンクの処理だけで数ミリ秒を消費し、TPS低下の直接原因となります。エンティティ数は/forge entity listコマンド（Forge環境）や各種プラグインで確認できます。
チャンクロードと描画範囲の問題
マインクラフトの世界はチャンク（16×16×高さのブロック群）単位で管理されています。プレイヤーの周囲の一定範囲のチャンクは常時読み込まれ（ロードされ）、処理が実行されます。server.propertiesのview-distance設定が大きいほど、多くのチャンクが同時にロードされ、サーバー負荷が増大します。
デフォルトの描画距離10チャンク（直径約320ブロック）は中規模サーバーでは過大で、プレイヤー数が増えると急速にTPS低下を引き起こします。また、複数のプレイヤーが離れた場所にいる場合、それぞれの周囲のチャンクがロードされるため、負荷は人数に比例して増加します。/forge tpsや/timingsコマンドでチャンク処理のボトルネックを特定できます。
レッドストーン回路と自動化装置
レッドストーン回路は非常に便利ですが、複雑な回路や大規模な自動化装置はサーバーに大きな負荷をかけます。特にクロック回路（常時信号を送り続ける回路）は毎tick処理が必要で、1つのクロック回路が1tick処理に0.5〜1ミリ秒を消費することもあります。
ホッパー、ドロッパー、ディスペンサーなどのアイテム輸送システムも負荷源です。ホッパーは毎tick周囲のアイテムをチェックし、大量に配置されたホッパーチェーンはTPS低下の主要因となります。特に問題なのは、プレイヤーが不在でも常時動作する自動化システムで、これらは24時間サーバーリソースを消費し続けます。
プラグイン・MODの競合と非効率
プラグインやMODは機能を拡張する便利なツールですが、不適切な実装や競合により深刻なパフォーマンス問題を引き起こします。特に古いバージョンのプラグイン、更新が止まっているプラグイン、複数のプラグインが同じ機能を重複して処理している場合に問題が発生します。
/timingsコマンド（Paperサーバー）やSparkプラグインを使用すると、各プラグインのCPU使用率を詳細に分析できます。1つのプラグインが全体の処理時間の20%以上を占めている場合、そのプラグインが最適化されていないか、設定が不適切である可能性が高いです。また、ワールドエディット系プラグインで大規模な編集を実行すると、一時的にTPSが急降下します。
サーバーソフトウェアの選択：Paper/Purpur等への移行
Vanilla/Bukkit/Spigot/Paperの違い
マインクラフトサーバーには複数のソフトウェア選択肢があり、それぞれパフォーマンス特性が異なります。Vanilla（公式サーバー）は最も安定していますが、最適化機能が限定的でプラグインも使用できません。Bukkitは歴史的なプラグインプラットフォームですが、現在はほとんど使用されていません。
Spigotはバニラサーバーに最適化とプラグイン機能を追加したもので、長年の標準として使用されてきました。しかし、2025年現在ではPaperがSpigotをベースにさらに大幅な最適化を施したものとして主流となっています。Paperは非同期チャンクロード、エンティティアクティベーション範囲の調整、ライト計算の最適化など、多数の改善が組み込まれています。
Paperサーバーの導入とメリット
Paperサーバーは、Spigotの完全互換性を保ちながら、パフォーマンスを30〜50%向上させる最適化が施されています。導入は非常に簡単で、公式サイト（https://papermc.io/）から対応するマインクラフトバージョンのjarファイルをダウンロードし、既存のserver.jarと置き換えるだけです。既存のワールドデータやプラグインはそのまま使用できます。
Paperの主なメリットは、チャンクの非同期読み込みによるロード時間の短縮、エンティティのティック処理最適化、ホッパーの処理効率化、ライト計算の改善などです。また、paper.ymlという独自の設定ファイルにより、細かいパフォーマンス調整が可能です。特にmax-auto-save-chunks-per-tickやoptimize-explosionsなどの設定は、大幅なTPS改善をもたらします。
Purpur/Pufferfish等の代替選択肢
Paperをさらに発展させたサーバーソフトウェアも存在します。Purpurは、Paperにゲームプレイ調整機能とさらなる最適化を加えたもので、村人のAI処理最適化、モブスポーン制御の細かい設定、ゲームメカニクスの調整機能などを提供します。
Pufferfishは、Paperにデータ構造の最適化を加えた高パフォーマンス版で、特にエンティティ処理とチャンク処理に優れています。2025年現在、大規模サーバー（同時接続100人以上）では、Pufferfish→Purpur→Paperの順で検討することが推奨されます。ただし、これらは実験的な最適化を含むため、小規模サーバーではPaperが最も安定した選択肢です。
server.properties設定の最適化
view-distanceの適切な設定値
view-distanceは、各プレイヤーの周囲で読み込まれるチャンクの半径を設定します。デフォルト値は10ですが、これは多くのサーバーにとって過大です。適切な値はサーバースペックとプレイヤー数によって異なりますが、一般的には以下の目安が有効です。
- 1〜5人：view-distance=8
- 6〜15人：view-distance=6
- 16〜30人：view-distance=5
- 31人以上：view-distance=4
この設定を6に下げるだけで、ロードされるチャンク数は約44%減少し、サーバー負荷が大幅に軽減されます。ただし、プレイヤーの視認距離も短くなるため、バランスが重要です。多くのサーバーでは、6が最適なバランスポイントとされています。
simulation-distanceの調整
simulation-distanceは、マインクラフト1.18以降で追加された設定で、実際にゲームロジック（モブのAI、作物の成長、レッドストーン回路など）が実行されるチャンクの範囲を制御します。これはview-distanceと独立して設定でき、view-distanceより小さい値に設定することで、見えるが処理されないチャンクを作ることができます。
推奨設定はsimulation-distance=4です。これにより、プレイヤーの視界は維持しつつ、遠方のチャンクでの不要な処理を削減できます。特にモブファームや自動化装置が多いサーバーでは、この設定が30%以上のTPS改善をもたらすことがあります。
entity-broadcast-range-percentageの設定
entity-broadcast-range-percentageは、エンティティ情報がクライアントに送信される範囲を調整します。デフォルトは100%ですが、70〜80%に下げることで、ネットワーク帯域とサーバー負荷を削減できます。この設定を下げても、プレイヤーの実際のゲームプレイにはほとんど影響しません。
特に大規模なモブファームやエンティティが多い環境では、この設定が効果的です。ただし、PvPサーバーでは敵の視認距離に影響するため、50%以下には下げないことが推奨されます。サバイバルサーバーであれば、70%が最適なバランスです。
bukkit.yml/spigot.yml/paper.ymlの詳細設定
チャンク関連の設定最適化
bukkit.ymlでは、chunk-gc.period-in-ticks（チャンクのガベージコレクション周期）を調整できます。デフォルトは600tick（30秒）ですが、400に短縮することで、不要なチャンクをより頻繁にアンロードし、メモリとTPS負荷を削減できます。
spigot.ymlでは、merge-radius設定が重要です。item: 4.0とexp: 6.0に設定すると、近接したドロップアイテムと経験値オーブが自動的に統合され、エンティティ数が削減されます。これだけでTPS改善の実感が得られることが多いです。
paper.ymlのmax-auto-save-chunks-per-tickは、自動セーブ時に1tickあたり何チャンクを保存するかを制御します。デフォルトの24から8に下げることで、セーブ時のTPS低下を防げます。ただし、セーブ完了までの時間は長くなります。
エンティティ処理の最適化設定
spigot.ymlのentity-activation-rangeは、プレイヤーから一定距離以上離れたエンティティの処理頻度を下げる設定です。以下の設定が推奨されます。
entity-activation-range:
animals: 16
monsters: 24
raiders: 48
misc: 8
water: 8
villagers: 16
flying-monsters: 48
これにより、遠方のモブは処理頻度が下がり（例えば毎tickではなく4tickに1回処理）、TPSへの負荷が大幅に削減されます。プレイヤーが近づけば通常通り処理されるため、ゲームプレイへの影響は最小限です。
paper.ymlのdespawn-rangesも重要で、モブが自動的に消える距離を設定します。soft: 28、hard: 96に設定すると、プレイヤーから28ブロック以上離れたモブは徐々に消え始め、96ブロック以上では即座に消えます。これによりモブの過剰蓄積を防げます。
ホッパーとレッドストーンの制御
paper.ymlのhopper.disable-move-eventをtrueに設定すると、ホッパーがアイテムを移動する際のイベント呼び出しを無効化し、処理速度が向上します。ただし、ホッパーの動作を監視するプラグインが正常に機能しなくなる可能性があります。
redstone-implementation設定では、レッドストーン処理のアルゴリズムを選択できます。ALTERNATE_CURRENTに設定すると、レッドストーン処理が大幅に最適化されます。2025年現在、この設定はPaper 1.19以降で標準となっており、複雑なレッドストーン回路でも安定した動作が期待できます。
optimize-explosionsをtrueにすると、TNTや爆発物の処理が最適化され、大規模な爆発でもTPS低下が軽減されます。TNTキャノンやTNTトラップを使用するサーバーでは必須の設定です。
エンティティ管理とクリーンアップ
エンティティ数の監視方法
エンティティ数の定期的な監視は、TPS維持の基本です。/forge entity list（Forge）、/paper entity list（Paper）、または/lagg check（ClearLaggプラグイン）コマンドで、現在読み込まれているエンティティ数とその種類を確認できます。健全なサーバーでは、プレイヤー1人あたり50〜100エンティティ以下を目安にします。
Sparkプラグイン（https://spark.lucko.me/）を導入すると、Web UIでエンティティ分布をヒートマップで視覚化でき、問題のあるチャンクを簡単に特定できます。特定のチャンクに500以上のエンティティが集中している場合、そのエリアが主要なボトルネックとなっている可能性が高いです。
ClearLaggプラグインの効果的な使用
ClearLaggは、定期的にドロップアイテムやモブを削除してサーバー負荷を軽減するプラグインです。設定ファイル（config.yml）で、削除間隔（推奨：5〜10分）、削除前の警告時間（推奨：60秒前、30秒前、10秒前）、除外アイテム（プレイヤーが持っているアイテム、名前が付いたアイテムなど）を指定できます。
効果的な設定例として、remove.entitiesセクションで以下を有効化します。
- DROPPED_ITEM
- ARROW
- EXPERIENCE_ORB
- PRIMED_TNT (inactive)
これにより、ドロップアイテム、矢、経験値オーブが定期削除され、TNTは削除されません（建築用に使用されることがあるため）。item-age-limitを300秒（5分）に設定すると、5分以上地面に放置されたアイテムのみが削除対象となります。
モブキャップとスポーン制限
spigot.ymlのmob-spawn-rangeを調整することで、モブがスポーンする範囲を制限できます。デフォルトの8チャンク（128ブロック）から6チャンク（96ブロック）に下げると、同時にスポーン処理が必要なエリアが減少し、TPS負荷が軽減されます。
bukkit.ymlのspawn-limitsでは、各種モブの同時スポーン上限を設定できます。デフォルト値は比較的高く設定されているため、以下の値に下げることを推奨します。
spawn-limits:
monsters: 50 (デフォルト70)
animals: 8 (デフォルト10)
water-animals: 3 (デフォルト5)
water-ambient: 15 (デフォルト20)
ambient: 10 (デフォルト15)
これにより、過剰なモブスポーンを防ぎつつ、ゲームプレイに必要なモブは維持されます。
プラグインとMODの最適化
パフォーマンスプロファイリングの実施
Sparkプラグイン（https://spark.lucko.me/）は、サーバーパフォーマンスの詳細なプロファイリングを提供する必須ツールです。`/spark profiler startコマンドで計測を開始し、5〜10分後に/spark profiler stop`で終了すると、Web上で詳細な分析レポートが生成されます。
このレポートでは、各プラグインやゲーム内処理がCPU時間の何%を使用しているかが視覚化されます。1つのプラグインが10%以上を占めている場合、そのプラグインの設定見直しや代替プラグインへの切り替えを検討すべきです。特に注意すべきは、常時動作するプラグイン（権限管理、チャット管理、保護系プラグインなど）です。
重いプラグインの特定と代替案
よくある重いプラグインとその代替案を以下に示します。
- WorldEdit/WorldGuard: 大規模編集時にTPS低下を招きます。
//limitコマンドで1回の編集ブロック数を制限（推奨：50000以下）するか、FastAsyncWorldEdit（FAWE）への移行を検討してください。FAWEは非同期処理により、編集中のTPS低下を大幅に軽減します。 - Essentials: 多機能ですが重い部分もあります。使用しない機能はconfig.ymlで無効化してください。特に
auto-afk、repair、eco（経済機能）などは負荷が高いため、不要なら無効化します。 - Dynmap: リアルタイムマップ生成は非常に重いです。
renderintervalを60秒以上に設定し、fullrenderintervalを使用してフルレンダーを深夜のみに制限してください。あるいは、Pl3xMapやBluemapなどの軽量な代替プラグインへの移行を検討してください。
プラグイン設定の見直しポイント
すべてのプラグインの設定ファイルを確認し、以下の項目をチェックしてください。
- 更新間隔（update-interval）: 高頻度の更新は負荷が高いため、可能な限り長い間隔に設定します（例：1tick → 20tick）。
- データベース保存頻度（save-interval）: 過度に頻繁な保存はディスクI/Oを圧迫します。5分以上の間隔を推奨します。
- 範囲計算（range-calculation）: 保護範囲や影響範囲の計算が頻繁に行われていないか確認します。キャッシュ機能がある場合は有効化してください。
- デバッグモード（debug）: 本番環境ではすべてのプラグインのデバッグモードを無効化してください。デバッグログの出力は予想以上に負荷が高いです。
ワールド最適化とチャンク管理
未使用チャンクの削除（プリジェネレーション後）
長期間運営されたサーバーでは、プレイヤーが一度訪れただけで使用されていないチャンクが大量に存在します。これらのチャンクはワールドファイルサイズを肥大化させ、バックアップやロード時間に影響します。
プリジェネレーションは、プレイヤーが新しい地域を探索する際のチャンク生成ラグを防ぐ効果もあります。推奨される境界サイズは、スポーン地点から半径5,000〜10,000ブロック（312〜625チャンク）です。Chunkyでのプリジェネレーション実行例：
/chunky world world
/chunky radius 5000
/chunky start
Trimコマンドによるワールド縮小
Paper/Spigotサーバーでは、/minecraft:worldborderコマンドと組み合わせてワールドトリムを実行できます。まず、WorldBorderプラグインで境界を設定し、その後サーバーを停止して、マップ編集ツールでトリム処理を実行します。
より簡単な方法として、Chunkyプラグインの/chunky trimコマンドを使用できます。これは、指定した範囲外のチャンクを自動的に削除します。大規模なワールドでは、この処理により数GB〜数十GBのディスク容量を節約でき、バックアップ時間も大幅に短縮されます。
定期的なワールドセーブ最適化
server.propertiesのsave-allコマンドは、すべてのチャンクを強制的にディスクに書き込みますが、これは一時的にTPSを低下させます。自動セーブの頻度を調整することで、TPS低下を軽減できます。
bukkit.ymlのticks-per.autosaveをデフォルトの6000（5分）から12000（10分）に延長すると、セーブによるTPS低下の頻度が半減します。ただし、クラッシュ時のデータロスリスクは若干増加するため、定期的な完全バックアップ（1日1回以上）との併用が必須です。
ハードウェアとサーバー環境の最適化
CPU性能とシングルスレッド性能の重要性
マインクラフトサーバーは、主にシングルスレッド処理に依存しています。多くの処理（特にメインゲームループ）は単一のCPUコアで実行されるため、コア数よりもシングルスレッド性能（クロック周波数とIPC）が重要です。
2025年現在、マインクラフトサーバーに推奨されるCPUスペックは以下の通りです。
- 小規模サーバー（1〜10人）: 3.5GHz以上のシングルコア性能、2コア以上
- 中規模サーバー（11〜30人）: 4.0GHz以上のシングルコア性能、4コア以上
- 大規模サーバー（31人以上）: 4.5GHz以上のシングルコア性能、8コア以上
Intel Core i7/i9シリーズ、AMD Ryzen 7/9シリーズが適しています。特にゲーミング向けの高クロックモデル（例：Intel i9-13900K、AMD Ryzen 9 7950X3D）は、マインクラフトサーバーに最適です。
メモリ割り当ての最適化
Java仮想マシン（JVM）のメモリ割り当ては、サーバーパフォーマンスに直接影響します。適切なメモリ量は、プレイヤー数とプラグイン数によって異なります。
- バニラ、1〜5人: 2〜3GB
- 軽量プラグイン、6〜15人: 4〜6GB
- 中規模プラグイン、16〜30人: 8〜12GB
- 大規模、31人以上: 16GB以上
起動スクリプトでの推奨設定例（8GB割り当て）：
java -Xms8G -Xmx8G -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions -XX:+DisableExplicitGC -XX:+AlwaysPreTouch -XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=40 -XX:G1HeapRegionSize=8M -XX:G1ReservePercent=20 -XX:G1HeapWastePercent=5 -XX:G1MixedGCCountTarget=4 -XX:InitiatingHeapOccupancyPercent=15 -XX:G1MixedGCLiveThresholdPercent=90 -XX:G1RSetUpdatingPauseTimePercent=5 -XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1 -Dusing.aikars.flags=https://mcflags.emc.gs -Daikars.new.flags=true -jar paper.jar --nogui
これらのフラグ（Aikar’s Flags）は、ガベージコレクション（GC）を最適化し、GC実行時のTPS低下を最小限に抑えます。
ストレージの選択（SSD必須）
マインクラフトサーバーでは、チャンクの読み書きが頻繁に発生するため、ストレージ速度が重要です。HDD（ハードディスクドライブ）ではランダムアクセス速度が遅く、チャンクロード時のTPS低下が発生します。
必須要件：NVMe SSD または SATA SSD
- NVMe SSD: 読み込み3000MB/s以上、推奨（特に大規模サーバー）
- SATA SSD: 読み込み500MB/s以上、最低ライン
- HDD: 非推奨（小規模バニラサーバーでもラグの原因となる）
また、定期的なバックアップは別ドライブに保存し、サーバー稼働中のディスクI/O競合を避けてください。理想的には、ワールドデータ用SSDとバックアップ用HDDの2ドライブ構成が推奨されます。
TPS監視とトラブルシューティング
リアルタイムTPS監視ツールの導入
TPS監視は、問題の早期発見に不可欠です。以下のツールが推奨されます。
- Spark:
/spark tpsコマンドでリアルタイムTPS表示、/spark profilerで詳細プロファイリング - Timings: Paper標準の
/timingsコマンドで各処理の時間分析 - LagMonitor: 専用プラグインで、TPS低下時に自動アラートとログ記録
これらのツールをDiscord Webhookと連携させると、TPS低下時に管理者へ自動通知できます。例えば、LagMonitorプラグインでは、TPSが15以下に低下した場合に自動でプロファイリングを開始し、結果をDiscordに送信する設定が可能です。
Timingsレポートの読み方
Paperサーバーの/timings reportコマンドを実行すると、詳細な性能分析レポートがWebブラウザで表示されます。重要な確認ポイントは以下の通りです。
- Full Tick: 1tickの総処理時間。50ms（理想値）を超えているとTPS低下が発生しています
- Entity Tick: エンティティ処理時間。20%以上を占める場合、エンティティ数削減が必要
- Tile Entity: ホッパー、かまど、チェストなどのブロックエンティティ処理。10%以上なら最適化対象
- Plugin Timings: 各プラグインの処理時間。上位3つで全体の30%以上を占める場合、プラグイン最適化が必要
特に「Entity Tick > minecraft:villager」が上位にある場合、村人の過剰繁殖や取引所の負荷が問題です。村人数を制限するか、村人最適化プラグイン（VillagerOptimiserなど）の導入を検討してください。
ボトルネック特定から対策までの手順
TPS低下が発生した場合の体系的なトラブルシューティング手順：
- 現状確認:
/spark tpsでTPS値確認、/forge entity listでエンティティ数確認 - プロファイリング開始:
/spark profiler start→ 5分待機 →/spark profiler stop - レポート分析: 生成されたWeb UIでCPU使用率上位の処理を特定
- 対策実施:
- エンティティが原因 → ClearLaggで削除、スポーン制限強化
- プラグインが原因 → 設定見直し、代替プラグイン検討
- チャンクが原因 → view-distance削減、未使用チャンク削除
- レッドストーンが原因 → 問題の回路特定、最適化または撤去
- 効果測定: 対策後、再度プロファイリングして改善を確認
この手順を定期的（週1回程度）に実施することで、TPS低下を予防的に防げます。