【2026年1月最新】マインクラフトTPS最適化完全ガイド：重いサーバーを劇的に軽くする実践手順

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

2025年8月15日2026年1月5日

この記事は、マインクラフトサーバー運用で起きやすい「TPS低下（重い・カクつく）」を、設定・運用・診断の順で体系的に改善するための実践ガイドです。CSS・絵文字・ファビコンは使用しません。設定変更は必ずバックアップを取り、小さく変更→計測→必要なら戻すを繰り返してください。複数の施策を同時に入れると原因が追えなくなるため、1つずつ進めるのが安全です。

冒頭の直接回答

TPS最適化で最短で効きやすいのは、次の「優先順位」で進めることです。原因不明のまま設定を当てずっぽうで変えるより、計測で“犯人”を特定してピンポイントに潰す方が早く安定します。

計測して原因特定：まず「何がtick時間を使っているか」を確認する
距離設定を現実的にする：view-distance / simulation-distance を下げて土台の負荷を減らす
エンティティ過密を解消：村人・落下アイテム・動物・トロッコ等の増え過ぎを抑える
自動化・レッドストーンを整理：常時稼働装置を減らす（ホッパー・クロック回路）
プラグイン/ MODの負荷を削減：設定見直し・代替・機能整理
ワールド運用を改善：新規チャンク生成の抑制、保存・バックアップの最適化
ハード/ JVMを整える：CPU単体性能・SSD・メモリ割当の適正化

結論として、まずは距離設定と過密の解消だけでも、体感改善につながるケースが多いです。そこから計測で「最も時間を使っている処理」を特定し、対策を追加していくのが最短ルートです。

診断はこちら

マインクラフトのTPSとは何か：基礎知識と重要性

TPSの定義と標準値

TPS（Ticks Per Second）は、マインクラフトサーバーが1秒間に実行するゲームループの回数を示す指標です。マインクラフトは20TPSで動作するよう設計されており、1tick=50ミリ秒で動作します。この20TPSが維持されていれば、プレイヤーの動き、モブのAI、レッドストーン回路、農作物の成長など、すべてのゲーム内処理が正常に機能します。

TPSが20を下回ると、ゲーム内の時間進行が遅くなり、プレイヤーは様々な不具合を体験します。例えば、ブロックを破壊してもすぐに消えない、攻撃の反応が遅れる、モブの動きがカクカクする、などの現象が発生します。TPSが15以下になると明確なラグとして認識され、10以下では実質的にプレイが困難になります。

TPSとFPSの違い

FPSはプレイヤー側（クライアントPC/ゲーム機）の描画速度で、TPSはサーバー側の処理速度です。FPSが高くてもTPSが低ければ、ブロック破壊や当たり判定、モブの挙動、作物成長などサーバー処理に関わる部分が遅延します。逆にTPSが20でも、クライアントのFPSが低いと画面がカクつきます。

まず「ラグがサーバー由来かクライアント由来か」を切り分けることが大切です。サーバー由来なら、この記事の最適化で改善する余地が大きいです。

TPS低下がゲームプレイに与える影響

TPS低下は次のような症状で現れます。特に「常時処理が走る要素（エンティティ・装置）」が多いほど悪化しやすいです。

ブロック破壊・設置の反映が遅い（掘っても戻る、置いても消える等）

モブの移動・攻撃が不自然（止まる、瞬間移動、当たり判定の遅れ）

レッドストーンやホッパー搬送が遅い（装置効率が落ちる）

ワールドの読み込みが遅い（チャンク境界で止まる、遅延）

プレイヤーの同期ズレ（ゴムバンド、ワープ、ラバーバンド）

TPS低下の主な原因：ボトルネックの特定方法

TPS低下の原因は1つとは限りませんが、多くは「エンティティ」「チャンク」「装置」「プラグイン」「保存/ディスク」「GC/メモリ」のどれかが支配的です。まずは“どれが支配的か”を特定し、そのカテゴリに集中して対策するのが最短です。

エンティティ過多による負荷

エンティティ（モブ、落下アイテム、ボート、トロッコ、アーマースタンド、額縁など）は、tickごとにAI・物理・衝突判定・探索などが動きます。特に負荷が増えやすい代表例は次の通りです。

村人の大量取引所（職業判定・経路探索・衝突・補充処理）
落下アイテムの貯まり（アイテム化した瞬間から毎tick処理）
動物・モブの密飼い（当たり判定が増える）
トロッコ/ボートの大量使用（当たり判定・移動処理が重い）

対策の基本は「増えない仕組み」「溜めない仕組み」「動かさない仕組み」です。定期削除は最終手段で、まずは発生源（トラップ・密飼い・放置アイテム）から抑えます。

チャンクロードと描画範囲の問題

チャンクは読み込み/生成/保存が重く、距離設定（view-distance / simulation-distance）が大きいほど同時に処理するチャンク数が増えます。プレイヤーが増えるほど負荷は跳ね上がり、探索で新規チャンク生成が続くと一気にTPSが落ちることがあります。

運用で特に重要なのは「探索のルール作り」です。資源ワールドを分ける、ボーダーを設定する、プリジェネするなどで、新規生成の連続を抑えると安定しやすくなります。

レッドストーン回路と自動化装置

装置は「常時稼働」が最も危険です。クロック回路、常時作動ホッパー、無限に流れるアイテム、水流搬送の常時ループなどは、プレイヤーの有無に関係なくtickを消費し続けます。

対策は、装置を「必要な時だけ動く」設計へ変更することです。例えば、レバーや検知回路で稼働時間を限定する、一定量溜まったらまとめて搬送する、不要時はクロックを停止する、といった方法が有効です。

プラグイン・MODの競合と非効率

プラグインやMODは便利な反面、設定によっては常時監視・頻繁なDBアクセス・広範囲スキャンが発生し、TPS低下の原因になります。特に「地図系」「ログ/保護系」「ランキング/統計系」「スクリプト系」は負荷差が出やすいです。

大切なのは「何が重いか」を計測して、重い機能を絞ることです。プラグインを入れ替える前に、まず設定で軽くできないか確認します。

サーバーソフトウェアの選択：Paper/Purpur等への移行

サーバーソフトの選択はTPSに直結します。Vanillaで起きる負荷を“設定で軽減できる余地”が少ないため、プラグイン運用をするなら最初から最適化が進んだ系統を選ぶ方が安定しやすいです。

Vanilla/Bukkit/Spigot/Paperの違い

概要としては次の理解で十分です。

Vanilla：公式そのまま。軽量化の選択肢が少ない
Bukkit：プラグイン文化の基盤（歴史的要素が強い）
Spigot：Bukkit互換を保ちつつ改善した広く使われる系統
Paper：Spigot互換のまま、運用・最適化・診断を強化した定番

「プラグインを入れる」「人数が増える」「装置が増える」ほど、Paper系のメリットが出やすくなります。

Paperサーバーの導入とメリット

Paperへの移行は手順を守れば難しくありません。最も重要なのはワールドと設定の完全バックアップです。バックアップがあれば、問題が出ても戻せます。

サーバー停止
ワールドフォルダ・plugins・設定ファイル一式を別場所へ退避
Paperのjarに差し替え
起動して設定ファイル生成
設定を少しずつ最適化（変更→起動→テスト→計測）

メリットは「同じ人数でも落ちにくい」「設定で調整できる範囲が広い」「診断がしやすい」ことです。特に運用が長期化するほど差が出ます。

Purpur/Pufferfish等の代替選択肢

PurpurやPufferfishなどはPaper派生で、さらに細かい設定や追加最適化が入る場合があります。方針としては、まずPaperで安定運用し、必要が出た段階で検討すると失敗しにくいです。

派生系は“便利”が増える反面、挙動差が出る設定もあるため、装置・村人交易・戦闘など重要部分のテストをしてから本番適用してください。

server.properties設定の最適化

server.propertiesは「全体の負荷」に効きます。とくに距離設定は効果が大きいので、まずここから調整するのがおすすめです。

view-distanceの適切な設定値

view-distanceは、各プレイヤーの周囲で読み込むチャンクの距離です。数値が大きいほど同時ロードされるチャンクが増え、CPU・メモリ・ディスクI/Oが重くなります。

目安（サバイバル・一般的な運用）：

少人数（1〜5人）：8〜10
中規模（6〜20人）：6〜8
大規模（21人以上）：4〜6（視認距離と相談）

「見た目を保ちたい」場合は、次のsimulation-distanceを先に下げる方がトラブルが少ないことがあります。

simulation-distanceの調整

simulation-distanceは、モブAI・レッドストーン・成長など“実際の処理”が動く距離です。view-distanceよりもTPS改善に効くケースがあり、見た目（視認距離）を大きく変えずに負荷を落とせるのが利点です。

まずは「6→4」を試し、装置やスポーンに影響が出ない範囲で「4→3」と段階的に調整します。大規模トラップや自動化が多いサーバーは影響確認を必ず行ってください。

entity-broadcast-range-percentageの設定

entity-broadcast-range-percentageは、エンティティ情報をプレイヤーに送る範囲の割合です。人数が増えるほど通信と処理が増えるため、大規模サーバーでは下げると安定することがあります。

ただし下げすぎると「遠くのモブが急に現れる/消える」体感が出る場合があります。100→75→50のように段階的に試し、プレイヤーの不満が出ない範囲で落とし所を探します。

bukkit.yml/spigot.yml/paper.ymlの詳細設定

ここは「細かい最適化」で効いてきます。ただし強めにいじると挙動が変わる場合があるため、変更は小さく、必ずテストしてから本番へ反映してください。

チャンク関連の設定最適化

チャンク負荷の本質は「新規生成」と「保存」です。探索が活発な時期は新規生成が支配的になりやすく、長期運用では保存とワールド肥大化が効いてきます。

探索が活発：資源ワールド分離、ボーダー設定、プリジェネを検討
保存が重い：保存タイミングの平準化、ログ量削減、バックアップの時間帯調整
肥大化が問題：不要領域整理、定期メンテで整理

紙一重の調整よりも「生成を抑える運用」を作る方が安定に直結します。特に人数が多いサーバーほど効果があります。

エンティティ処理の最適化設定

Spigot系では、エンティティの“処理する範囲”と“頻度”を抑える設定があります。これにより、プレイヤーから遠い場所のモブ処理を軽くしてTPSを安定させやすくなります。

例として、考え方は次の通りです。

プレイヤーから遠い動物・モブは処理頻度を落とす
重要な要素（村人など）は下げすぎず、様子を見ながら調整
影響が出たらすぐ戻せるように、変更前の値を控える

ここはサーバー方針（バニラ寄り/快適寄り）で最適値が変わるため、“万能の数値”はありません。計測で重いと分かった時に、段階的に調整するのが安全です。

ホッパーとレッドストーンの制御

ホッパーとレッドストーンは、TPS低下の代表格です。ホッパーは近くにプレイヤーがいると常に動くことが多く、装置が増えるほど負荷が積み上がります。レッドストーンは常時クロックが最も危険です。

対策の基本は「ホッパーを減らす」「常時稼働を止める」です。具体例：

仕分け機のホッパー列を短くする（必要最小限に）
水流搬送＋最後だけホッパーにする
クロック回路をレバーや検知で必要時のみ稼働にする
一定量溜まってからまとめて搬送する（常時搬送を避ける）

さらに設定での最適化も可能ですが、挙動差やプラグイン互換の影響が出ることがあります。まずは設計で減らす方が安全です。

エンティティ管理とクリーンアップ

エンティティ対策は、TPS改善の中でも効果が出やすい分野です。「数を減らす」「溜めない」「密集させない」を守るだけで体感が変わることが多いです。

エンティティ数の監視方法

まずは「何が増えているか」を把握します。プレイヤー体感では原因が分からないため、コマンドや診断ツールで“種類別の量”を確認するのが重要です。

村人が増えすぎていないか（交易所・繁殖施設）
落下アイテムが溜まっていないか（トラップの床・回収漏れ）
動物の密飼いがないか（牧場・自動繁殖）
トロッコやボートが溜まっていないか（搬送装置・水路）

「特定の拠点に近づくと急に重くなる」場合は、その拠点のエンティティ過密や装置が原因であることが多いです。まずその地点で計測し、原因を絞り込みます。

ClearLaggプラグインの効果的な使用

ClearLagg系の自動削除は、緊急時の改善や運用補助として有効です。ただし“根本原因”を直さないと再発します。まずは「放置アイテム」など限定的な対象から始め、削除頻度や除外条件を慎重に調整してください。

運用のポイント：

削除対象はまず「落下アイテム」「矢」「経験値オーブ」などから
削除間隔を短くし過ぎない（プレイヤー体験を損なう）
削除の告知は必要最小限（チャットが荒れる原因になりやすい）
例外（ネームタグ付き、額縁、重要展示物など）の扱いを確認

削除に頼り切るよりも、回収漏れを減らす（ホッパー回収を確実にする、溢れない設計にする）方が安定します。

モブキャップとスポーン制限

スポーン上限やスポーン範囲を調整すると、過剰スポーンを抑えてTPSを安定させやすくなります。ここは「難易度」「トラップ運用」「プレイヤーの好み」で適正値が変わります。

考え方は次の通りです。

敵モブの上限を少し下げると負荷が減りやすい
動物の上限を下げると密飼い問題が起きにくい
トラップで稼ぎたいサーバーは下げすぎない（方針を先に決める）

いきなり大きく下げると体感が変わり過ぎることがあるため、段階的に調整し、プレイヤーにも周知するとトラブルが減ります。

プラグインとMODの最適化

プラグイン/ MOD最適化のコツは「削除」ではなく「負荷の高い機能を絞る」ことです。便利な機能は残しつつ、重い処理だけを抑えれば、体験を落とさずに改善できます。

パフォーマンスプロファイリングの実施

最適化は計測がすべてです。負荷が出ているタイミング（人数が多い、イベント中、拠点で装置が動いている等）でプロファイルを取り、どの処理が時間を消費しているか確認します。

プロファイル時の注意：

「重い状況」を再現してから計測する（軽い時に取っても意味が薄い）
2〜5分程度の短い計測でも十分なことが多い
計測結果は保存して、変更前後で比較する

重いプラグインが原因なら、まず設定で軽量化できないかを確認し、それでも難しければ代替を検討します。

重いプラグインの特定と代替案

よく負荷が出やすいカテゴリと、見直しポイントは次の通りです。

地図系：描画範囲、更新頻度、解像度、レンダリングスレッドを見直す
保護/ログ：記録対象、保持期間、DB書き込み頻度を見直す
統計/ランキング：集計頻度、同期処理、外部送信頻度を見直す
スクリプト系：イベント取り過ぎ（常時監視）を削る

「昔から入れている」プラグインほど、設定が初期のまま重くなっていることがあります。まず設定を見直し、それでも重い場合に代替を検討すると安全です。

プラグイン設定の見直しポイント

設定見直しで効きやすいポイントをチェックリストにします。

全チャンク/全プレイヤーを短周期でスキャンしていないか
ログやDB書き込みが頻繁すぎないか（特に同期書き込み）
外部API連携（Discord等）の送信頻度が高すぎないか
不要な機能が有効になっていないか（使っていないなら切る）
大量の権限チェックやイベントフックが常時走っていないか

「全部を最高設定」にすると必ず重くなります。サーバーの方針に合わせて、必要な機能だけを有効化するのが最適化の基本です。

ワールド最適化とチャンク管理

長期運用ではワールドの肥大化と新規生成がTPS低下の原因になります。とくに探索が多いサーバーは、ワールド運用を整えるだけで安定度が上がります。

未使用チャンクの削除（プリジェネレーション後）

探索が落ち着いてからは、範囲を固定して運用するのが安定します。たとえばプリジェネ（事前生成）で必要範囲だけ生成し、それ以外の探索を抑えると、新規生成による急な負荷が出にくくなります。

不要領域の削除は慎重に行ってください。必ずバックアップを取り、テスト環境で手順を確認してから実施します。削除を行う場合、プレイヤーに「探索可能範囲」を周知してトラブルを防ぎます。

Trimコマンドによるワールド縮小

バージョンや運用方法によって、ワールドデータの整理（使用されない領域の整理・縮小）が検討できる場合があります。実施前にバックアップを取り、実行後はワールドが正しく読み込めるか、スポーン地点・主要拠点・ネザー移動などを一通り確認します。

縮小は便利な一方で、やり方を誤ると破損リスクがあります。まずは「探索ルール」「資源ワールド分離」「プリジェネ」など、壊さない運用での改善を優先するのが安全です。

定期的なワールドセーブ最適化

保存のタイミングで一瞬TPSが落ちる場合、保存頻度・バックアップ方式・ログ量が影響していることがあります。対策の考え方は次の通りです。

バックアップはオフピーク（深夜など）に実行する
同時に重い処理（地図レンダリング等）を走らせない
不要なログを減らし、ディスクI/Oを抑える
ストレージが弱い場合はSSD/NVMeを優先する

「保存が原因かどうか」は計測で判断するのが確実です。保存が支配的なら、ディスクと保存運用の改善が近道です。

ハードウェアとサーバー環境の最適化

設定を詰めても限界がある場合、最終的にはハードウェアが支配的になります。ただし“先に設定と運用で改善できる余地”が大きいため、まずはソフト面を整えてからハードを検討すると無駄が減ります。

CPU性能とシングルスレッド性能の重要性

マインクラフトはメイン処理が単一スレッドに依存する場面が多く、コア数よりも単体性能（世代・クロック・IPC）がTPSに効きやすい傾向があります。大人数や装置の多いサーバーほど差が出ます。

VPS/専用サーバーを選ぶ際は「CPUの新しさ」「高クロック」「安定した性能（共有過多でない）」を重視すると失敗しにくいです。

メモリ割り当ての最適化

メモリは多いほど良いとは限りません。過剰に割り当てるとGC（ガベージコレクション）が重くなったり、OSがメモリ不足になったりします。まずは現実的な容量（例：4〜8GB）で安定させ、必要に応じて増やします。

基本方針：

OSに余裕を残す（VPS総メモリの全割当は避ける）
XmsとXmxは同じ値にすると安定しやすい場合が多い
GC調整（フラグ）は、まず無理に入れず、計測で必要性が出たら検討する

# 例：まずはこれで安定させる（値は環境に合わせて調整）
java -Xms6G -Xmx6G -jar paper.jar nogui

Javaの要件はマイクラ本体のバージョンで変わることがあるため、サーバーを更新する際は公式の案内を確認してください。

ストレージの選択（SSD必須）

ストレージはチャンクの読み書きに直結します。HDDはランダムアクセスが遅く、保存やチャンク読み込みでTPSが落ちやすくなります。サーバー用途ではSSD（できればNVMe）が強く推奨されます。

推奨：NVMe SSD
最低ライン：SATA SSD
非推奨：HDD

バックアップは別ストレージや別サーバーへ退避し、稼働中のディスクI/O競合を避けると安定します。大規模サーバーほど効果があります。

TPS監視とトラブルシューティング

最適化は一度で終わりません。人数や装置が増えると再び重くなるため、監視とトラブル対応の手順を持っておくと長期運用が安定します。

リアルタイムTPS監視ツールの導入

最低限やりたいのは「TPSとMSPTの確認」「重いタイミングの記録」です。TPSだけでなく、1tickに何ミリ秒かかっているか（MSPT）を見ると原因の追跡がしやすくなります。

監視の運用例：

重くなった時の時刻と状況（人数、場所、稼働装置）を記録する
重い拠点があるなら、そこに近づいた時に計測して比較する
イベント前後で計測し、悪化傾向を早めに掴む

Timingsレポートの読み方

環境によってはTimingsが参考になる場合がありますが、サーバーソフトやバージョンにより扱いが変わることがあります。Timingsを使う場合は「どの項目が最も時間を使っているか」を見て、カテゴリ（エンティティ、タイルエンティティ、プラグイン、保存など）を切り分けるのが基本です。

読み方の要点：

Full Tickが高い：全体が重い。まず距離設定と過密を疑う
Entityが高い：村人・モブ・落下アイテム・移動体を疑う
Tile Entityが高い：ホッパー・かまど・装置を疑う
Pluginsが高い：設定見直しや代替検討

ただし、最終的には「実際に何が重いか」を示せる計測手段を優先してください。手段は環境により変わるため、公式ドキュメントの案内に従うのが安全です。

ボトルネック特定から対策までの手順

TPS低下が起きた時は、次の順に進めると迷いにくいです。

現状確認：TPS/MSPTを確認し、いつ・どこで重いか記録
再現：重い状況（拠点、トラップ、人数増）を再現
計測：プロファイルやログで時間を食う処理を確認
分類：エンティティ/装置/プラグイン/保存/GCのどれが支配的か判断
対策：支配的な要素だけを優先して改善（1つずつ）
再計測：改善したかを同条件で比較

この流れを守るだけで、無駄な設定変更を大幅に減らせます。

マインクラフトサーバーホスティングの選び方

ホスティング選びは「料金」だけでなく、TPS安定に直結するポイントを押さえることが重要です。特にCPU単体性能とストレージ（SSD/NVMe）の差が、体感に出やすいです。

CPU：単体性能が高いほど有利（共有過多の環境は不利）
メモリ：人数・プラグイン量に合わせて適正に
ストレージ：SSD必須、可能ならNVMe
回線：人数が増えるほど重要
バックアップ：自動バックアップの有無と復旧手順

ConoHa for GAME

ConoHa for GAMEは、マインクラフトに特化したゲーミングVPSサービスです。最大の特徴は、マインクラフト統合版とJava版の両方に対応した専用管理パネルで、サーバー構築が数クリックで完了します。

主な特徴

テンプレートイメージ: Vanilla、Paper、Spigot、Forgeなど主要サーバーソフトウェアがプリインストール
自動バックアップ: 毎日自動バックアップで、ワールドデータの消失リスクを最小化
高性能CPU: Intel Xeon（3.3GHz以上）搭載で、シングルスレッド性能が高い
NVMe SSD: 全プランでNVMe SSD標準搭載、チャンクロードが高速
料金: 2GBプラン1,065円/月〜、4GBプラン2,408円/月〜（2025年11月時点）

推奨プラン：4GBプラン（10〜20人規模のサーバーに最適）。MODサーバーの場合は8GBプラン以上を推奨します。初期費用無料で、時間課金（最低1時間〜）にも対応しているため、テストや短期イベントにも向いています。

Xserver VPS for Game

Xserver VPS for Gameは、エックスサーバーが提供するゲーム特化型VPSサービスです。高速CPUと大容量SSDを標準装備し、大規模サーバーの運営にも対応できます。

主な特徴

マインクラフトマネージャー: Web UIからサーバー起動・停止、設定変更、プラグイン管理が可能
高速CPU: 第3世代AMD EPYC（3.0GHz以上）搭載、マルチコア性能も優秀
大容量SSD: 4GBプランで100GB、8GBプランで200GBのNVMe SSD
安定性: エックスサーバーの高品質インフラ、稼働率99.99%保証
料金: 4GBプラン2,200円/月〜、8GBプラン4,400円/月〜（12ヶ月契約時、2025年11月時点）

推奨プラン：8GBプラン（20〜40人規模、MODサーバーに最適）。長期契約割引が大きく、12ヶ月契約で月額料金が約30%安くなります。SSH接続も可能で、上級者の細かいカスタマイズにも対応できます。

さくらのVPS

さくらのVPSは、老舗のVPSサービスで、柔軟なカスタマイズ性と安定性が特徴です。マインクラフト専用機能は少ないですが、Linux経験者には最適な選択肢です。

主な特徴

完全root権限: OSから自由にカスタマイズ可能、Paper/Purpurなど最新ソフトウェアを自由に導入可能
豊富なプラン: 512MBから32GBまで、幅広いメモリプラン
NVMe SSDオプション: 標準はSSDですが、NVMe SSDへのアップグレードも可能
コストパフォーマンス: 4GBプラン2,200円/月〜と、性能対コストが優秀
料金: 4GBプラン2,200円/月〜、8GBプラン4,400円/月〜（2025年11月時点）

推奨プラン：4GBプラン（中規模サーバー、カスタマイズ重視の運営者向け）。OSはUbuntu 22.04 LTSまたはRocky Linux 9が推奨されます。マインクラフトサーバーの構築には、SSH接続とLinuxコマンドの基礎知識が必要です。

ConoHa VPS

ConoHa VPSは、汎用VPSサービスですが、マインクラフトテンプレートも用意されており、ゲーム用途にも対応できます。ConoHa for GAMEよりも安価で、小規模サーバーに適しています。

主な特徴

簡単セットアップ: マインクラフトテンプレートで初期構築が簡単
低価格: 2GBプラン968円/月〜と、業界最安値クラス
高速SSD: 全プランでSSD標準搭載、ストレージ速度は十分
スケーラビリティ: プラン変更が簡単で、サーバー規模の拡大に柔軟対応
料金: 2GBプラン968円/月〜、4GBプラン1,848円/月〜（2025年11月時点）

推奨プラン：2GBプラン（5人以下の小規模サーバー、友人内サーバー向け）。初めてのマインクラフトサーバー運営で、コストを抑えたい場合に最適です。

シンVPS

シンVPSは、エックスサーバーの新ブランドで、最新のハードウェアを採用した高性能VPSです。マインクラフトサーバーに必要な高速CPU性能を備えています。

主な特徴

最新CPU: 第4世代AMD EPYC（3.5GHz以上）搭載、2025年現在最速クラス
NVMe SSD: 全プランで高速NVMe SSD標準搭載
マインクラフトテンプレート: Paperサーバーのテンプレート提供
コストパフォーマンス: 高性能ながら、4GBプラン2,200円/月〜と手頃
料金: 4GBプラン2,200円/月〜、8GBプラン4,400円/月〜（2025年11月時点）

推奨プラン：4GBプラン（10〜20人規模、最新ハードウェア重視の運営者向け）。特にCPU性能を重視する場合、シンVPSは2025年現在の最適解の一つです。

KAGOYA CLOUD VPS

KAGOYA CLOUD VPSは、企業向けVPSサービスですが、マインクラフトサーバーにも対応できる高い安定性を持っています。

主な特徴

高稼働率: データセンター品質で、稼働率99.95%以上
日額課金: 日額20円〜で利用可能、短期テストに最適
スケール変更: リソース変更が柔軟、サーバー規模の拡大に対応
料金: 2GBプラン979円/月〜、4GBプラン2,200円/月〜（2025年11月時点）

推奨プラン：4GBプラン（安定性重視、長期運営向け）。特に大規模コミュニティや公開サーバーなど、ダウンタイムが許されない環境に適しています。

よくある質問（FAQ）

Q1. TPSが15前後で停滞していますが、最優先で対策すべきことは何ですか？

最優先は「計測して原因を特定」することです。次に効きやすいのは距離設定（view-distance / simulation-distance）と、エンティティ過密（村人・落下アイテム・密飼い）の解消です。闇雲にプラグインを入れ替えるより、まず“犯人カテゴリ”を確定させる方が早いです。

Q2. view-distanceを下げるとプレイヤーから不満が出ませんか？

不満が出る場合はあります。その場合は、先にsimulation-distanceを下げる、資源ワールドを分ける、ボーダーを設けて探索負荷を抑えるなどで「見た目を保ちつつTPSを守る」運用が可能です。サーバー方針を決め、どこまで快適性を優先するかを事前に共有しておくと納得されやすいです。

Q3. マインクラフトサーバーに最適なJavaバージョンは何ですか？

Java要件はマイクラ本体・サーバーソフトのバージョンで変わることがあります。最適解は「現在のサーバーバージョンが要求するJava」を使うことです。サーバー更新時は、公式のリリースノートや導入ガイドで必要なJavaを確認し、実行されているJavaが意図通りか（java -version）も合わせて確認してください。

Q4. PaperサーバーとVanillaサーバーでゲームプレイに違いはありますか？

基本的な体験は近いですが、最適化や運用上の理由で挙動差が出る設定もあります。できるだけVanillaに近づけたい場合は、バニラ寄りの設定方針で調整し、重要要素（交易・レッドストーン・トラップ・戦闘）をテストした上で本番反映してください。

Q5. ホッパーを多用する自動化装置がありますが、負荷を減らす方法はありますか？

最も安全で効果が高いのは「設計でホッパー数を減らす」ことです。水流搬送＋最後だけホッパー、稼働時間を限定する、一定量溜めてからまとめて搬送するなどで、常時稼働を減らせます。設定で抑える方法もありますが、互換や挙動差が出ることがあるため、まずは設計改善を優先すると安定します。

まとめ

TPS最適化は「設定集を全部入れる」ことではなく、計測→原因特定→ピンポイント対策→再計測の反復が最短です。まずは距離設定（view/simulation）とエンティティ過密の解消で土台を整え、その後に装置・プラグイン・ワールド運用・ハードへと段階的に広げていくと、無駄なく安定した改善ができます。

「どこから手を付けるべきか迷う」場合は、最初に距離設定を現実的にし、次に村人・落下アイテム・ホッパーの過密を疑ってください。この2つだけでも改善することが多く、改善しない場合は計測で“真の原因”が見えます。