PaperMC 1.21.10 対応の最新最適化手法を網羅
Paperはバニラ/Spigotに対し、チャンク・エンティティ・I/O等の処理を広範に最適化します。ただし適切な設定・計測・継続改善が伴って初めて最大効果を発揮します。本ガイドは最新の構成ファイル構造（paper-global.yml / paper-world-defaults.yml / paper-world.yml）を前提に、TimingsとSparkを併用した「見える化 → 改善」手順を紹介します。
PaperMCとは？なぜ最適化が必要か
PaperはSpigot系の高性能フォークで、より厳密なスケジューリングとチューニング可能な設定群を備えます。ただし「入れただけ」では環境差（地形/装置/プレイヤー数/プラグイン）によるボトルネックが残るため、設定の見直しと計測が不可欠です。高負荷時の回復力が必要なら、Folia（リージョン化スケジューラ）も選択肢ですが、ほとんどのBukkit系プラグインと互換ではない点に注意してください。
Paperの利点（抜粋）
| 領域 | 要点 | 効果の方向性 |
|---|---|---|
| チャンク処理 | 読み込み/アンロード/保存のキュー最適化 | スパイク低減・I/O削減 |
| エンティティ | 追跡・AI・衝突の閾値/範囲の調整 | CPU負荷軽減 |
| 設定群 | per-world デフォルト/上書きで緻密に制御 | 用途別の最適解を適用 |
| 可視化 | Timings/Spark で原因を数値化 | 再現性のある改善 |
最適化の基本設定（1.21.10の構成に準拠）
server.properties（基本）
まずは影響度の高い描画/計算距離を妥当化します。値はサーバー性能と人数・装置密度に応じて調整してください。
推奨の出発点
- view-distance: 8–10（探索主体なら10、装置主体なら8）
- simulation-distance: 6–8（装置負荷が高い場合6から）
- max-players: マシン/回線に合わせて上限を現実的に
- sync-chunk-writes: false（I/Oスパイクを抑制）
Paper設定（paper-global.yml / paper-world-defaults.yml）
Paper 1.20+ では従来の paper.yml が再編されています。全体設定（global）とワールド既定（world-defaults）、個別ワールドのpaper-world.ymlで段階的に管理します。以下は代表的な観点と例です（キーは版差があるため該当ファイル内のコメントとドキュメントを必ず確認）。
チャンク/保存の例（world-defaults 側）
chunks:
delay-chunk-unloads-by: 10s # 直後の再訪を想定してアンロード猶予
max-auto-save-chunks-per-tick: 6 # 1tickの保存件数上限（I/O平準化）game-mechanics:
treasure-maps:
enabled: false # 生成コスト重めの宝の地図を無効化（探索サーバーでは要検討）
エンティティ/AIの例（world-defaults 側）
AI・追跡・スポーン等は体感への影響が大きいため、下げ過ぎ注意。まずは可視化で原因を確認してから段階調整します。
entities:
activation-range:
animals: 24
monsters: 32
raiders: 32
misc: 16
track-range:
animals: 48
monsters: 48
misc: 32
# 追跡/AI関連の個別フラグはドキュメントに従う（過度な無効化はゲーム性を損なう）
注：ここに記すキーは代表例です。実際のキー名・階層はバージョンにより変わり得ます。
設定適用の指針
- 一度に多項目を変えない（1変更→計測のループ）
- プレイヤー体験とトレードオフ（敵の追跡/アイテム挙動など）を把握
- ワールドごとに負荷特性が違う（装置ワールド/建築ワールド等）
Spark・Timings解析によるボトルネック特定
Paper内蔵のTimingsは全体の傾向把握に、Sparkはプロファイラ/ヒープ分析に適します。両者を使い分けると原因特定が速くなります。
Timings の使い方
基本フロー
/timings onで計測開始- 10–30分、通常運用（ピーク帯が理想）
/timings pasteでURL取得→分析
見るべき指標
- TPS（20.0付近）/ 平均tick時間（≦50ms）
- プラグイン別負荷（ハンドラ/イベント）
- エンティティ/チャンクの処理時間比率
Spark（プラグイン）で深掘り
代表コマンド
/spark profiler –timeout 60
# 停止してレポート生成（URL）
/spark profiler stop
# CPUサンプラの短時間実行
/spark tickmonitor
# ヒープ/オブジェクト
/spark heap
Sparkは詳細だが読み解きに慣れが必要。Timingsで当たりを付け、Sparkで深掘りする使い分けが効率的です。
プラグイン最適化とおすすめ構成
「入れれば速くなる」類のプラグインは存在しません。可視化・事前生成・自動調整など、目的を明確にした導入が原則です。過剰な掃除系は副作用が出やすいため要注意です。
| プラグイン | 目的 | 効果の方向性 | 備考 |
|---|---|---|---|
| Spark | CPU/メモリ/ヒープの可視化 | 原因特定速度の向上 | 運用の必需品 |
| Chunky | ワールドの事前生成 | 探索時のラグ削減 | 低負荷時間帯に実行 |
| ViewDistanceTweaks | VD/SDの自動調整 | ピーク帯のTPS維持 | 過度な上下動は抑制設定を |
| FarmControl / MobFarmManager | 過密な農場の制御 | エンティティ負荷削減 | 仕様と副作用を理解して導入 |
注意（掃除系プラグイン）
不必要なアイテム/エンティティの一括削除を乱用すると、ゲーム体験の毀損や想定外の消失が発生しがちです。Paperの設定・スポーン制御・事前生成で根本対策し、掃除系は最小限/限定用途に留めてください。
tick・AI・スポーンの調整（spigot.yml / Paper）
以下は方向性の指針です。値は環境依存のため、段階的に適用しTimings/Sparkで検証します。
アクティベーション/トラッキング
- activation-range（Paper）：animals 24 / monsters 32 / misc 16 付近から
- tracking-range（Paper）：animals/monsters 48 / misc 32 を基準に微調整
- tick-inactive-villagers を無効化しない（挙動が破綻しやすい）
成長/スポーン（spigot.yml）
| 設定 | 基準 | 方向性 | 注記 |
|---|---|---|---|
| growth.*-modifier | 100 | 150–300 | 成長速度を落とし負荷緩和（必要に応じて） |
| entity-activation-range | バニラより狭く | CPU負荷↓ | 見え方に影響、プレイ感と折衝 |
| spawn-limits | デフォルト | 装置密集なら微減 | 過剰な削減は生態系に影響 |
適用ステップ
- 現在値を必ず控える（復帰用）
- 1項目だけ変更 → ピーク帯でTimings/Spark
- 体感（戦闘/探索/農業）への影響をヒアリング
メモリ最適化と起動引数（Java 21 推奨）
Java 21 の既定（G1GC）は十分優秀です。起動フラグは最小限が原則。過剰フラグは逆効果になり得ます。
推奨のシンプル起動
オプション（要検証）
-XX:+UseZGC：ヒープ8GB以上で遅延を抑えたい場合に試験的に。小規模では恩恵が小さいことも。- OS/FS のチューニング（I/Oスケジューラや巨大ページ等）は安定性と引き換えになりがち。まずは既定を尊重。
メモリ配分の目安
| 総RAM | 割り当て例（Xmx） | 同時接続の目安 | 備考 |
|---|---|---|---|
| 4GB | 2–3GB | ～15 | 装置控えめ |
| 8GB | 4–6GB | ～40 | 一般的なSMP |
| 16GB | 8–12GB | 40+ | 装置多め・Mod少 |
監視とメンテナンス
定期監視
TPS
常時 19.5–20.0 を目標
ヒープ使用率
80%超が続くなら Xmx/GC 再検討
CPU
平均負荷の平準化を重視
ディスク/バックアップ
空き20%+／自動バックアップ検証
週次メンテ項目
- Timings/Sparkで重い時間帯の傾向確認
- 不要ログ/古いバックアップの整理
- プラグイン更新（互換を確認のうえ）
- ワールドの事前生成の継続（Chunky スケジューリング）
トラブルシューティング
よくある事象と解決
| 症状 | 原因候補 | 対処 |
|---|---|---|
| TPSが落ちる | 装置/プラグイン/探索スパイク | Timingsで該当tickを特定→該当領域の設定/装置修正 |
| GC停止が長い | ヒープ飽和/断片化 | Xmx見直し/プラグインのオブジェクト保持調査（Spark heap） |
| チャンク破損疑い | I/O中断/障害 | バックアップ復元、事前生成の再実行、I/O環境の見直し |
| 接続不安定 | ネットワーク/OS設定 | 帯域・遅延測定、OSの同時接続制限を確認、ホスティングの変更も検討 |
おすすめサーバーホスティング比較（目安）
価格・仕様は変動します。最新は公式を参照してください。
高性能VPSサーバー
ゲーミング特化
サーバー選定のポイント
- CPU：高いシングルスレッド性能を優先（装置/AI負荷に強い）
- RAM：プレイヤー数・装置密度に応じて余裕を持たせる
- ストレージ：NVMe SSD（I/Oスパイク対策に有効）
- 回線/サポート：国内DC・24/7サポート・自動バックアップ
まとめ
最適化は「よく効く万能設定」を探す作業ではありません。可視化→仮説→段階適用→再計測のループで、あなたのワールドに最適な着地点を探ることが肝要です。Paper 1.21.10 と Timings/Spark を武器に、安定20TPSの快適環境を構築しましょう。
設定は最小から大きく
バックアップは必ず
免責事項
※本記事は2025年10月時点の情報に基づいています。Paperの設定キーやデフォルト値はリリースごとに調整されます。実際のファイル内コメント/公式ドキュメントを参照し、適用は自己責任で。適用前に必ずバックアップを取得してください。