XServer VPS×マイクラ入門｜プラン選び・構築・運用・最適化まで

2026年2月11日

「友達とマイクラを遊ぶなら、サーバーを立てた方が快適そう。でも、VPSって難しそう……」
XServer VPSは、自分専用のマイクラサーバーを持てる選択肢として人気ですが、初めてだと“迷いどころ”が多いですよね。

たとえば、こんな声がよくあります。

「XServer VPSとXServer VPS for Game、結局どっちを選べばいいの？」
「プランが多すぎる……人数やMODでどれくらいのスペックが必要？」
「Java版と統合版って何が違うの？ Switch/PS/スマホの友達も入れる？」
「テンプレでサクッと立てたいけど、あとから拡張できる？逆にSSH構築は何が大変？」
「ポート開放って必要？セキュリティや荒らし対策は最低限どうすればいい？」
「立てた後が不安。バックアップ、アップデート、監視、ラグ対策って何からやるべき？」

この記事では、そうした疑問を“最短で解消”できるように、プラン選び → 構築（テンプレ／SSH）→ 必須設定 → プラグイン／MOD → 安定運用 → 最適化までを、初心者向けに一つの流れとして整理します。

料金やスペックは公式情報・最新情報を優先しつつ、実際の運用で差が出やすいポイント（バージョンの揃え方、バックアップ設計、ラグの原因切り分けなど）も丁寧に解説します。
「とにかく早く遊びたい人」も「後から本格運用したい人」も、この記事の手順通りに進めれば、迷いにくい構成です。

XServer VPS 公式サイト
XServer VPS for Game 公式サイト

この記事でわかること（対象読者とゴール）

このページは「XServer VPSでマイクラ（Minecraft）サーバーを立てたいけど、何から始めればいい？」という初心者向けに、迷いやすいポイントを先回りして解消しながら、最終的に「友達が入れるマルチサーバー」を作るところまでをゴールにした解説です。

最短で遊び始める手順（テンプレート／管理画面を使う方法）
つまずきやすい設定（Java版・統合版、バージョン、ポートなど）
目的別の選び方（少人数・大人数／バニラ・プラグイン・MOD）
安全に運用する最低限（バックアップ、権限、荒らし対策の考え方）

「専門用語が多くて不安…」という人でも大丈夫なように、“今のあなたが決めるべきこと”→“手順”→“トラブル対処”の順で整理していきます。

想定するプレイ：少人数／大人数、バニラ／プラグイン／MOD

まず最初に決めるのは、「どう遊びたいか」です。ここが曖昧だと、プラン選びや構築方法で迷いやすくなります。

1）人数（負荷の増え方）

👥 少人数（2〜5人程度）：バニラ中心なら軽め。まずは“無理しないプラン”で始めやすい
👥 中〜大人数（10人以上）：設定次第で一気に重くなりやすい。距離設定や最適化が重要

2）遊び方（サーバーの種類）

🧱 バニラ（素のマイクラ）
- 導入が簡単で、トラブルも比較的少なめ
- まずはここから始めると失敗しにくいです
🧩 プラグイン（Paper/Spigotなど）
- 保護・権限・便利機能などを追加できる（例：荒らし対策、ワープ等）
- ただし、プラグイン同士の相性や更新で不具合が出ることも
⚙️ MOD（Forge/Fabricなど）
- 遊びの幅が一気に広がる
- その代わり、参加者全員が同じMOD構成を揃える必要があり、クラッシュ対応も増えがち

このガイドの方針（初心者向けの最適ルート）

まずは バニラ（またはPaper）で安定稼働を目指す
慣れてから プラグイン／MODへ拡張する
いきなりMOD特盛りにすると、トラブル切り分けで詰まりやすいので注意です ✅

対応エディション：Java版・統合版のどちらを扱うか

ここは超重要です。Java版と統合版は別物で、基本的にそのままでは一緒に遊べません。

Java版（PC向け中心）
- プラグインやサーバー文化が成熟していて、自由度が高い
- ただし、設定項目が多く初心者は最初だけ迷いやすい
統合版（Switch/PS/スマホ/Windowsなど）
- 友達が家庭用ゲーム機やスマホ中心ならこちらが現実的
- ただし、Java版とは仕組みが違うため、サーバー側も統合版用で用意が必要

この記事での扱い

「XServer VPSでサーバーを立てる」観点で、Java版・統合版の両方を視野に入れて解説します。
ただし、途中で混乱しないように、本文中では
- “Java版ならここ”
- “統合版ならここ”
  のように分岐を明確にして説明します。

よくある勘違い（最初に回避）

「Switchの友達もいるけど、Java版サーバーで遊べる？」
→ 原則そのままでは難しいです。まずは“誰が何で遊ぶか”を揃えましょう。

検証環境・更新方針（バージョン差分が出るポイント）

マイクラはアップデートが頻繁で、記事が古いと手順どおりに進まないことがあります。そこで本記事は、次の方針で“情報のズレ”を最小化します。

1）バージョン差分が出やすいポイント

サーバー本体（Java/統合）のバージョン
テンプレート（イメージタイプ）の対応状況
プラグイン／MODの対応バージョン
接続トラブル（ポートや設定画面のUI変更など）

2）本記事の更新方針

料金・プラン・公式の提供機能は、公式ページの最新情報を優先して解説します。
画面名や機能名が変わる可能性があるため、本文では
- 「この名称が見当たらない場合は、同じ意味の項目を探す」
- 「公式マニュアルの該当ページで確認する」
  という“迷子にならない確認手順”もセットで案内します。

3）検証・前提の明記

記事内では、可能な範囲で
- どのタイプ（バニラ／Paper／Forge等）で説明しているか
- どこが環境依存か
  を明確にします。
なお、最重要なのは「サーバー側のバージョン」と「参加者側のバージョンを揃える」こと。ここさえ押さえると、初心者でも成功率が一気に上がります 👍

XServer VPS 公式サイト
XServer VPS for Game 公式サイト

最初に結論：XServer VPSでマイクラを動かす方法は2通り

XServer VPSでマイクラのマルチサーバーを動かす方法は、ざっくり 2つに分かれます。

方法A：テンプレ（アプリイメージ）で最短スタート
→ クリック中心でサーバーが立ち上がる。初心者の成功率が高い。
方法B：SSHで自分で構築（手動セットアップ）
→ 自由度は最大。ただし、Linux操作・切り分けの知識が必要。

まずは「今のあなたが欲しいのは、早さ？自由度？」を決めるだけで、迷いが激減します。

方法A：テンプレ（アプリイメージ）で“最短スタート”

テンプレ（アプリイメージ）とは、VPS作成時に「Minecraft（Java版／統合版）」「Paper」「Fabric」などを選ぶだけで、必要な環境を自動で用意してくれる仕組みです。
さらにゲーム向けの提供ページでは、マイクラ用のテンプレを選んで、管理パネル（マネージャー）から起動・設定できる形も用意されています。

何がラクになる？

初心者が詰まりやすいポイント（例：Java導入、起動設定、設定ファイル配置など）を スキップ できます。

🧩 インストール作業がほぼ不要（選択→作成で形になる）
🖥️ 管理画面で起動・停止・設定変更ができる（コマンド操作が少ない）
🔧 ゲーム設定（難易度・モード等）をGUIで触れる（慣れない編集が減る）

テンプレでやること（初心者向けの最短チェック）

細かい手順は後の章で解説するとして、ここでは流れだけ掴めばOKです。

プランを選ぶ（人数・遊び方で目安を決める）
イメージタイプでMinecraft系テンプレを選ぶ（Java／統合／Paper／Fabricなど）
管理用パスワード等を設定して作成
パケットフィルター（ポート許可）を確認
サーバーのIP（またはドメイン）を確認
管理画面でサーバー起動 → 参加者が接続

こんな人は方法Aが向いています

✅ 今日中にマルチを始めたい
✅ コマンド操作はできれば避けたい
✅ まずはバニラ or Paperあたりで安定稼働したい
✅ トラブル時に“手順どおり戻る”運用をしたい

注意点（テンプレでも避けられないこと）

テンプレは万能ではなく、最低限ここは押さえる必要があります。

Java版／統合版の取り違え（友達の端末に合わせる）
バージョン違い（参加者側とサーバー側を揃える）
バックアップ（ワールド消失を防ぐ保険）
公開範囲（ホワイトリスト等で荒らし対策）

「とりあえず立てた」だけで終わらず、“入れる状態を維持する運用”が大事です。

方法B：SSHで“自分で構築”して自由度を取る

こちらは、VPSに SSH接続して、OS上で必要なものを入れ、サーバーを自分で動かす方法です。
やることが多い分、テンプレにはない構成も組めます。

手動構築でできること（自由度が上がるポイント）

⚙️ サーバー構成を完全に自分仕様にできる
例：複数サーバー同居、特殊な起動方式、独自の監視や自動バックアップ
🧱 使いたいMOD／ローダー構成を細かく管理できる
例：テンプレにない組み合わせ、独自更新フロー
🧠 原因切り分けがやりやすい（仕組みが理解できるほど強い）

ざっくり流れ（初心者が“何をするか”だけ把握）

※ここでは“道筋”を示します。具体コマンドは別章で丁寧に扱うのが安全です。

OSを選んでVPSを作成
SSHでログインし、初期設定（更新・ユーザー管理・セキュリティ）
Java版ならJavaを導入（バージョン選定が重要）
サーバーファイルを配置して初回起動（EULA同意など）
常駐化（再起動で自動起動する仕組み）
必要ポートを許可（パケットフィルター／FW）
ログを見て安定化（重い・落ちるの原因を潰す）

こんな人は方法Bが向いています

✅ MODや構成を自由に組みたい（将来的に拡張したい）
✅ 複数サーバー／高度な運用（監視・自動化）もやりたい
✅ 多少のLinux操作に抵抗がない（または学ぶ前提がある）
✅ トラブル時にログを見て切り分けたい

注意点（初心者がハマりやすい）

そもそも 何が動いていないか分からない（FW？サーバー？Java？）となりやすい
Javaのバージョン違いやメモリ設定で落ちることがある
直すために ログ確認が必須になりがち

「自由度が高い＝自己責任の範囲が増える」と考えると判断しやすいです。

どちらを選ぶべきか（目的別：早さ／拡張性／運用のしやすさ）

迷ったら、基本は 方法A（テンプレ） が正解です。
理由はシンプルで、初心者のゴールはまず “友達が入れるマルチ環境を安定して動かすこと” だからです。

比較表（選ぶ基準が一発で分かる）

スクロールできます

観点	方法A：テンプレ	方法B：SSH手動
立ち上げ速度	速い（クリック中心）	遅め（準備が多い）
必要スキル	低〜中	中〜高（Linux/ログ）
自由度	中（用意された範囲）	高（何でも組める）
運用のしやすさ	GUI中心で楽	自動化できるが設計が必要
トラブル対応	手順に戻りやすい	切り分けできると強いが難しい

目的別のおすすめ

とにかく早く遊びたい → 方法A
バニラ／Paperで安定稼働が目的 → 方法A
MOD構成をガッツリ管理したい／高度な運用をしたい → 方法B
迷う → まず 方法Aで成功体験 → 必要になったらBへ

“迷わない決め方”テンプレ（そのまま使えます）

次の質問に答えるだけで結論が出ます。

Q1：今週中に遊びたい？ → はい＝A
Q2：参加者にSwitch/スマホがいる？ → いる＝統合版寄り（テンプレ推奨）
Q3：MODを大量に入れる予定？ → はい＝B（またはMOD向けテンプレ＋運用強化）
Q4：Linux操作に自信ある？ → ない＝A、ある＝Bも選択肢

XServer VPS 公式サイト
XServer VPS for Game 公式サイト

XServer VPSとXServer VPS for Gameの違いを整理（迷う人向け）

結論から言うと、マイクラだけ（ゲーム用途中心）なら「XServer VPS for Game」、マイクラ以外にも使う予定があるなら「XServer VPS」が選びやすいです。
ただし「できること／契約後の自由度」が完全に別物というより、“提供のしかた（テンプレや管理画面の方向性）”と“プラン構成”が違うイメージです。

スペック・料金は何が同じで、どこに差が出るか

同じところ（初心者がまず安心していい点）

どちらもVPSなので、マイクラ用のサーバーとして運用できます（Java版／統合版などのサーバーイメージも用意）。
マイクラ運用に必要な考え方（メモリ、vCPU、ストレージ、バックアップなど）は共通です。

違いが出るところ（ここが“迷いポイント”）

1）プランの刻み方が違う（＝選びやすさが違う）

XServer VPS：2GBの次が「6GB」「12GB」…のように、やや独特な構成（増設を含む形のプランがある）
XServer VPS for Game：2GB/4GB/8GB/16GB…のように、ゲーム用途で直感的な刻み。さらに大規模向けに128GBプランが追加されています。

2）“同じ月額帯でも中身（メモリ・ディスク容量）が違うことがある”

比較記事内の例（長期契約時の例）では、同じ月額帯でも
- XServer VPSの方がメモリとNVMe容量が厚め
- for Gameはゲーム向けにわかりやすいメモリ刻みだが、ディスク容量は一定寄り
  といった差が示されています。

3）料金は“キャンペーンと改定”で動く

たとえば2GBプランの料金改定（1ヶ月契約の月額が変更）など、時期によって前提が変わります。
一方で、ゲーム向けは割引キャンペーンが出て「月額◯◯円〜」の見え方になる時期もあります（契約期間の条件で最安が変わる点に注意）。

迷わないための超ざっくり早見

スクロールできます

迷いどころ	XServer VPS	XServer VPS for Game
マイクラ以外も動かしたい	◎（用途が広い）	△（ゲーム中心の設計）
初心者が“ゲームだけ”で迷いにくい	○	◎
プランの選びやすさ（ゲーム目線）	△（刻みが独特）	◎（2/4/8/16…）

ゲーム向け管理機能（マイクラ管理ツール／テンプレ／移行など）

マイクラ管理ツールはある？ → あります

マイクラ運用で助かるのが、ブラウザ操作中心で触れる「マインクラフトマネージャー」です。
主に次のような作業を、コマンドよりも軽い操作で進めやすくなります。

サーバーの起動／停止
ゲームモード・難易度などの基本設定
バージョンアップ
バックアップ（取得・管理）

（「クリック操作で設定・バックアップ・バージョン管理ができる」旨が案内されています）

テンプレ（アプリイメージ）は何が嬉しい？

初心者がつまずきがちな “入れるべきものの順番” をテンプレ側が肩代わりしてくれます。

Java版／統合版の土台
Forge / NeoForge / Fabric（MOD系）
Paper / Spigot（プラグイン系）

など、主要どころが「最初から選べる前提」で並ぶため、最短で“動く形”に持っていきやすいです。

移行（乗り換え・作り直し）の考え方

初心者が事故りやすいのは、サーバーを作り直した瞬間にワールドが消えるパターンです。
テンプレを変えたくなったら、まずはこの順番を守るのが安全です。

ワールドのバックアップを取る（最優先）
乗り換え先（新サーバー／新イメージ）を用意
バックアップから復元（またはワールドデータ移送）
参加者のバージョン・MOD構成を揃え直す

「移行したい＝構成変更したい」ことが多いので、バックアップを“作業前の儀式”にすると失敗が激減します。

「マイクラ以外にも使う」場合の落とし穴

ここが一番の分岐点です。for Gameは“ゲームに集中できる設計”の反面、マイクラ以外もやりたい人は引っかかりやすいです。

落とし穴1：申込時に選べるテンプレがゲーム中心

XServer VPSはゲーム以外（AIツール、ビジネス系、開発、サイト制作など）のイメージが広く、選択肢が豊富。
for Gameはゲーム系イメージに限定される、と整理されています。

「WordPressもついでに立てたい」
「Discordボットや監視ツールも同居させたい」
「開発環境としても使いたい」

このあたりの可能性があるなら、最初からXServer VPSの方が回り道が減ります。

落とし穴2：同居させると“マイクラが重くなる”

マイクラは、プレイヤー増・距離設定・MOD増で負荷が跳ねやすいです。
別用途を同居させるほど、CPU/メモリ/ディスクI/Oを取り合ってラグやTPS低下が出やすくなります。

まずはマイクラを安定稼働
余力が見えてから同居（もしくは別VPSに分ける）

この順番が安全です。

落とし穴3：セキュリティと公開範囲が雑になる

マイクラ用途でも、開けるポートは必要最小限が基本です。
「他用途も動かす」ほど開放ポートが増え、管理が雑になるとリスクも上がります。

参加者を絞るならホワイトリスト
管理画面・SSHは強いパスワード＋多要素を意識
バックアップは“定期”で自動化できると強い

XServer VPS 公式サイト
XServer VPS for Game 公式サイト

失敗しないプラン選び：必要スペックの考え方

マイクラ用VPSのプラン選びで迷ったら、まずは「何GBにすればいい？」より先に、どこがボトルネックになりやすいかを押さえると失敗しにくいです。

メモリ（最重要）：不足するとカクつき・落ちる・読み込みが遅い原因に直結
CPU（次に重要）：人数増・処理が重い仕組み（装置やMOB）が増えるほど効いてくる
ストレージ（NVMe/容量）：ワールドやバックアップが増えると容量が効く（速度はNVMeなら安心）

この3つを前提に、ここから「人数×遊び方」で目安を作ります。

人数で決める：負荷が増える理由と目安の立て方

人数が増えると負荷が上がるのは、単純に“処理すること”が増えるからです。

読み込むチャンク（地形）が増える
MOB・アイテム・村人・トロッコなどエンティティが増える
レッドストーンやホッパー、トラップが増える
参加者ごとの移動でワールド読み込みが同時多発しやすい

ここに「プラグイン」や「MOD」が乗ると、メモリとCPUの必要量が一段上がります。

バニラ（軽め）で遊ぶ場合

おすすめの考え方：まずは「少人数で安定」→重くなったら設定調整→それでも無理なら増強

2〜4人くらい：軽め設定なら 2GB〜4GB が出発点になりやすい
5〜10人くらい：安定重視なら 4GB〜8GB を検討（距離設定や装置量に左右されます）
10人以上：建築規模・活動範囲・装置量で差が出るので、最初から余裕を見ておくと安心

初心者がやりがちなNG

メモリを「全員分のPCスペック」みたいに考える
→ サーバーのメモリは“プレイヤー数”だけでなく、設定（距離）とワールド状況で増減します。

プラグイン入りで遊ぶ場合（Paper/Spigot想定）

おすすめの考え方：プラグインは便利だけど、追加するほど“常時動く処理”が増えます。
その分、バニラより 1段階上のメモリ を見ておくと失敗しにくいです。

少人数＋軽いプラグイン数個：4GB から考えると安心
中人数＋保護・経済・権限など複数入れる：8GB を視野に
大人数や複雑な機能を積む場合は、さらに余裕が必要

実務的なコツ

まずは Paper 系で始めて、プラグインは必要最小限から追加
“便利そうだから全部入れる”より、目的（保護・権限・ワープ等）ごとに厳選した方が安定します

MOD環境で遊ぶ場合（Forge/Fabric/NeoForge想定）

おすすめの考え方：MODは「導入した瞬間に重くなる」というより、
MODパックの規模・自動化・生成物・追加Mobなどで必要量が跳ねます。

軽量MOD＋少人数でも、8GBあたりから考えると安全寄り
中〜大型MODパックや、装置が増える遊び方なら 16GB以上も普通に射程
サーバー側だけでなく、参加者側も同じ構成を揃える必要があるので、運用の手間も増えます

公式情報の“目安”として使えるポイント

たとえば Mohist（MODとプラグインのハイブリッド）系では、利用条件や推奨メモリの案内が出ており、重め構成は8GB以上推奨といった扱いがあります。
→ MOD系の負荷感を掴む目安になります。

重くなりやすい要素（配布ワールド／描画距離／常時稼働／各種設定）

ここを押さえると、「プラン不足」なのか「設定の問題」なのかを切り分けやすくなります。

描画距離・演算距離（simulation/tick distance）
- 上げるほど、サーバー側のメモリ負担が増えます
- 快適さと負荷のトレードオフなので、最初は控えめが安全
配布ワールド・巨大建築・未探索エリアの高速移動
- 読み込みが増えて、カクつきやすい
- 対策として「事前生成（プリジェネ）」という考え方もあります
装置（ホッパー・レッドストーン・村人・トラップ）
- “人数が少なくても重い”原因の代表格
- ルール作り（過剰装置禁止）で劇的に安定することも
常時稼働（24時間）＋バックアップ頻度
- ワールドやバックアップが増えると容量を食う
- バックアップは大事ですが、頻度・保存世代を設計すると無駄が減ります

まず疑う順番（初心者向けの鉄板）

距離設定（描画/演算）を見直す
装置・エンティティ量を見直す
それでもダメなら、メモリ割り当てやプラン増強を検討

あとから上げられる前提で“最初の最適解”を決める

初心者がいきなり大きいプランにするより、「増強できる」ことを前提に、最初は堅実なラインから始めるのが失敗しにくいです。

1）まずは“出発点”を決める（目安）

下の表は、あくまで最初の見立て用です（設定や遊び方で上下します）。

スクロールできます

遊び方	2〜4人	5〜10人	10人以上
バニラ中心	2〜4GB	4〜8GB	8GB〜
プラグインあり	4GB〜	8GB〜	8〜16GB〜
MODあり	8GB〜	16GB〜	16GB〜（構成次第で上も）

2）プラン増強の現実的な判断基準

次の状態が続くなら、設定調整だけでは限界のことが多いです。

人が増えると急にラグい（夜のピークが特に重い）
落ちる／再起動が増えた
ワールド読み込みが明らかに遅い状態が続く

この場合は、上位プランへの変更を検討します（XServer側にもプラン変更の案内があります）。

3）増強より先にやると“得”なこと

増強は確実に効きますが、先にこれをやるとコスパが上がります。

距離設定を適正化する
Paper系に寄せて軽量化する（可能な範囲で）
ルールを決める（過剰装置・放置トラップの抑制）
バックアップの世代管理（無限に増やさない）

XServer VPS 公式サイト
XServer VPS for Game 公式サイト

構築前のチェックリスト（ここで詰まるのを防ぐ）

ここを飛ばして作業を始めると、あとで「なんで入れないの？」が起きやすいです。
先に “参加できる状態”に必要な条件を揃えてから、構築に入るのが最短ルートです。

エディション一致：Java版と統合版は互換ではない

最初に確認するのはこれです。Java版と統合版は別物なので、原則そのままでは一緒に遊べません。

チェック項目（まずここだけ）

参加者は Java版（PC）？それとも 統合版（Switch/PS/スマホ/Win版など）？
“全員同じエディション”で揃えられる？

初心者が混乱しやすいポイント

「Windowsのマイクラ」は Java版と統合版の両方があり得ます（購入形態や起動する版で変わる）
サーバーを立てた後に「実は友達がSwitchだった…」となると、作り直しになりやすい

迷ったときの決め方

参加者に Switch/PS/スマホがいる → まずは 統合版サーバーを前提に考える
プラグイン文化・自由度重視、参加者がPC中心 → Java版サーバーが扱いやすい

バージョン一致：サーバーと参加者側を揃える

次に多い詰まりポイントがバージョン違いです。サーバー側と参加者側でズレていると、接続できない原因になります。

チェック項目（作業前にメモしておく）

サーバーは どのバージョンで立てる？（例：最新で遊ぶ／特定バージョン固定）
参加者のクライアントは 同じバージョンに合わせられる？

運用がラクになる方針（初心者向け）

“基本は最新に合わせる”（みんなでアップデートする日を決める）
MOD/プラグインを入れる場合は “固定バージョン運用”に寄せる
- 理由：アップデート直後は互換が追いつかず、動かなくなることがあるため

更新するときの鉄板ルール（事故防止）

アップデート前に 必ずバックアップ（ワールドだけでもOK）
「本体→プラグイン／MOD」の順に更新し、ログイン確認してから公開

共有情報の整理：IP／ドメイン／ポート／参加ルール

ここが整理できていないと、参加者側が迷子になります。
サーバー公開前に、コピペで渡せる“案内文”を作っておくのが最強です。

1）接続先情報（参加者へ渡す）

最低限はこれだけです。

サーバーアドレス：VPSのグローバルIP もしくはドメイン
ポート番号：エディションで変わる（後述）
サーバー名（任意）：参加者側の一覧で見分けやすい名前

初心者向けメモ

自宅PCで立てる場合と違い、VPSは基本的に “外から届くIP”が最初から用意されています
ただし、VPS側で 必要ポートを許可していないと繋がりません（XServerのパケットフィルター等）

2）ポートとプロトコルの超基本（ここだけ覚える）

Java版：通常は 25565（TCP）
統合版：通常は 19132（UDP）

※「普段はポート入力しなくても繋がる／繋がらない」が起きるのは、クライアント側の仕様差や入力画面の作りによるものです。迷ったら、IP（またはドメイン）＋ポートをセットで案内すると安全です。

3）参加ルール（最低限でOK）

サーバーは、作った瞬間から“運用”が始まります。最初に決めておくと揉めにくいです。

参加できる人：招待制（推奨）／公開
NG行為：窃盗・荒らし・チート等の扱い
装置ルール：ホッパー大量・放置トラップなど（重くなる原因の代表）
管理者への連絡手段：Discordなど

4）参加者へ渡すテンプレ（コピペ用）

必要ならそのまま使ってください。

サーバー名：〇〇
アドレス：xxx.xxx.xxx.xxx（または example.com）
ポート：（Java版なら 25565 / 統合版なら 19132）
バージョン：1.xx.x（全員ここに合わせてね）
ルール：招待制／初回は管理者がログイン確認してから案内

運用ルールの最低限：ホワイトリスト・権限・バックアップ

「入れた！でも翌日荒らされた／ワールドが消えた」を防ぐための、最低限セットです。
難しいことは不要で、“守り”だけは最初に固めるのがおすすめです。

1）ホワイトリスト（招待制の要）

基本はON推奨（知っている人だけ入れる状態にする）
参加者が増えても、許可制なら荒らしリスクが激減します

※管理画面が用意されている場合は、GUIで設定できることもあります。コマンドが必要な場合もありますが、最初は「招待制で運用する」だけでも効果が大きいです。

2）権限（OP/管理者）を最小限に

管理者権限（OP）は 必要最小限の人数に絞る
“全員OP”は事故の元（間違ってワールド設定を変えるなど）

おすすめ運用

OPは1〜2人まで
建築保護や権限管理を強化したいなら、Java版はプラグインで整理しやすい

3）バックアップ（これだけは妥協しない）

バックアップは「いつかやろう」では遅いです。初心者ほど、先に仕組み化がおすすめ。

最低限のルール（簡単で強い）

毎日1回（またはプレイ後）バックアップ
アップデート前は必ずバックアップ
世代管理：直近 7回分くらい残す（無限に増やさない）

初心者が守るべき考え方

バックアップは“保険”ではなく、運用の一部
何かあった時に「戻せる」だけで、トラブルのストレスが激減します

XServer VPS 公式サイト
XServer VPS for Game 公式サイト

方法A：テンプレで最短構築（初心者向け手順）

テンプレ（イメージタイプ）を使う方法は、「申し込みと同時にサーバーの土台が自動で用意される」のが最大のメリットです。
ここでは、初心者が迷いにくい順に「作成 → 初期設定 → 接続テスト」までをまとめます。

申し込み〜サーバー作成の流れ

全体像はこの3ステップです。

プランと契約期間を決める
イメージタイプ（テンプレ）を選ぶ
rootパスワード等を設定してサーバー作成

プラン・契約期間の決め方（後悔しない選び方）

契約で後悔しやすいのは「最初から長期にして、遊ばなくなった」「逆に短期で割高になった」です。迷ったら、次の考え方が安全です。

まず試したい（初めて・週末だけ）
→ 短めの契約期間でスタートし、手応えを見て延長・増強
しばらく継続するのが確定（固定メンバーで長期）
→ 長めの契約期間を検討（トータル費用が安くなることが多い）
MOD・大人数が確定している
→ 最初から“余裕寄り”のプランで、ラグのストレスを減らす

ポイント：VPSは「あとからプランを上げる」運用が現実的です。
最初のプランは“完璧”よりも、「まず安定して動く」ラインを狙うと失敗しにくいです。

イメージタイプ選択（Java／統合／Paper／Forgeなど）

テンプレで最重要なのがここです。
「どんな遊び方をしたいか」から逆算して、イメージタイプを選びます。

XServerのゲーム向けテンプレでは、Minecraft系のイメージタイプが複数用意されています（例：Java/統合、プラグイン、MODなど）。選べる種類の例は次のとおりです。

統合版（Bedrock）：統合版サーバーの土台
Java版（バニラ）：Java版サーバーの土台
Forge / NeoForge / Fabric：MOD向け
Spigot / Paper / Purpur / SpongeVanilla：プラグイン向け
Mohist：MODとプラグイン両方（難易度高め）

初心者のおすすめは、まずこのどれかです。

Java版でバニラ中心：Minecraft（Java版）
Java版で軽快に＋プラグイン予定：Minecraft（Paper）
統合版で遊びたい：Minecraft（統合版）
MOD確定：Minecraft（Forge / NeoForge / Fabric）のいずれか（配布元が指定するローダーに合わせる）

よくあるミス

“プラグインを入れたいのにバニラ”を選ぶ
“MODパックがNeoForge指定なのにForge”を選ぶ
→ 後からやり直しになりやすいので、配布元の指示がある場合は必ず合わせるのが鉄則です。

rootパスワード・SSHキーの扱い（安全に管理する）

テンプレ方式でも、サーバー管理の入口として rootパスワード（またはSSHキー）が必要になります。ここは「後で何とかしよう」が通りにくいので、最初にきっちり管理します。

rootパスワードの基本

推測されにくい文字列にする（英字＋数字＋記号を混ぜる）
必ず控える（あとで必要になる場面がある）
共有しない（Discord等に貼らない／スクショで残さない）

SSHキーの基本（使うなら推奨）

鍵認証は安全性が高い反面、秘密鍵を失うとログインできなくなるリスクがあります
秘密鍵は「PC内の安全な場所＋バックアップ」で保管（パスフレーズ設定も検討）

初心者の現実的な結論

まずはテンプレで立ち上げて遊ぶだけなら、SSH操作をしないケースも多いです
ただし、後々カスタム運用（ログ確認・手動導入）をするなら、鍵認証の導入を視野に入れると安心です

管理ツールで初期設定

テンプレで立ち上げた後は、管理ツール（例：マインクラフトマネージャー等）を使って「動作確認 → 最低限の運用設定」を整えます。

起動／停止／再起動の基本

まず確認するのは、サーバーが“稼働中”になっているかです。

ステータスが「停止中」なら起動
挙動がおかしい・設定反映後なら 再起動
しばらく遊ばないなら停止（コストではなく“管理上の整理”として有効）

さらに、重くなりやすいサーバーでは 定期再起動が効くことがあります。
指定時刻に自動で再起動できる機能が案内されているため、夜間などに組むと運用がラクになります。

ゲームモード・難易度・各種設定の変更

初心者が先に触ると効果が大きい設定は、次の3つです。

ゲームモード（サバイバル／クリエ）
難易度（ピースフル〜ハード）
距離系の設定（描画・演算に関係する項目）
- 上げすぎると一気に重くなりやすい
- 迷ったら“控えめ”で開始し、物足りなければ少しずつ上げる

運用上のコツ

設定を変えたら「一度再起動 → 接続テスト」までをセットにする
誰が設定を変えたか分からなくならないよう、管理者（OP）は最小限に

ワールドのバックアップ／復元／移行

テンプレ運用でも、バックアップは必須です。特に次のタイミングは“事故が起きやすい”ので、儀式化がおすすめです。

アップデート前
MOD／プラグイン追加・削除の前
設定を大きく変える前（距離・生成系など）

バックアップの考え方はシンプルです。

取得頻度：毎日1回 or プレイ後
世代：直近7回くらい残す（無限に増やさない）
復元：戻す必要が出たら「復元 → 起動 → 接続確認」の順で確実に

また、テンプレを変える／サーバーを作り直す可能性がある人は、“移行できる形（ワールドデータを戻せる状態）”を意識すると安心です。

接続テスト（参加者が入れる状態にする）

接続テストは、必ず 管理者が先に1回やってから参加者に案内します。
この順番にすると、参加者側の混乱がほぼ消えます。

サーバーのIP（またはドメイン）を確認
必要ならポートも確認（Java/統合で違うことがある）
パケットフィルター（通信許可）が適切か確認
自分が接続できるかテスト
OKなら参加者へテンプレ文で案内

Java版：サーバー追加〜接続確認

Java版は基本的にこの流れです。

マイクラ起動 → マルチプレイ
サーバーを追加
サーバーアドレスに IP（またはドメイン）を入力
- ポート指定が必要な場合は アドレス:ポート の形式
接続 → ログインできればOK

入れないときの最短チェック

サーバーが稼働中か
アドレスの打ち間違いがないか（コピペ推奨）
通信許可（パケットフィルター）が必要ポートを許可しているか

統合版：サーバー追加〜接続確認

統合版は端末によって表示が少し違いますが、基本は次の流れです。

マイクラ起動 → プレイ
サーバータブ → サーバー追加
アドレスとポートを入力して保存 → 接続

注意点（初心者が詰まりやすい）

PC/スマホは比較的スムーズに追加できる一方で、家庭用ゲーム機（Switch/PS等）は“外部サーバー追加”が簡単でない場合があります
→ 参加者に家庭用機がいるなら、事前に「その端末で参加できる導線」も確認しておくと安全です。

バージョンが合わない時の対処

バージョン不一致の対処は、焦らず“情報を揃える”だけで解決することが多いです。

まず確認すること（順番が大事）

サーバー側のバージョン（管理ツールや案内表示）
参加者側のバージョン（起動中のマイクラ）
MOD／プラグイン環境なら「構成が一致しているか」

対処パターン

サーバーが新しすぎる：参加者をアップデート
参加者が新しすぎる：サーバー側を更新（可能なら）
MOD環境：MODローダー（Forge/NeoForge/Fabric）とMOD一式を同一にする
- 1つでも違うと入れない／落ちる原因になります

接続エラーで迷ったら

「アドレス・ポート・稼働状態」→「バージョン」→「構成（MOD/プラグイン）」の順に潰すと、最短で原因に当たりやすいです。

XServer VPS 公式サイト
XServer VPS for Game 公式サイト

方法B：SSHで一から構築（自由度重視の手順）

テンプレを使わず、SSHでOSから整えてMinecraftサーバーを立てる方法です。
メリットは 自由度と拡張性、デメリットは 初期設定と保守の手間。ただ、手順を固定すれば初心者でも十分運用できます。

OS選定と初期セットアップ

まずは「安定して長く使えるOS」を選び、最低限の“土台”を作ります。

初心者に無難：Ubuntu LTS / Debian
慣れている人向け：Rocky Linux / AlmaLinux など

アップデート／ユーザー作成／時刻設定

以下はUbuntu/Debianの例です（コピペOK）。

まずログインして更新

sudo apt update
sudo apt -y upgrade
sudo apt -y autoremove

管理用ユーザーを作る（普段はrootを使わない）

sudo adduser admin
sudo usermod -aG sudo admin

時刻を日本に合わせ、NTPを有効化

sudo timedatectl set-timezone Asia/Tokyo
sudo timedatectl set-ntp true
timedatectl

ここが大事

ログの時刻がズレると、トラブル時の原因追跡が一気に難しくなります。
まずは「更新できる」「sudoできる」「時刻が正しい」までを“成功条件”にしましょう。

SSHの基本強化（鍵ログイン・不要な入口を閉じる）

次に、SSHを固めます。ここを雑にすると、後々の不安が増えます。

1) 鍵ログインを用意する（推奨）

手元PCで鍵を作っていない場合（WindowsならPowerShellでもOK）：

ssh-keygen -t ed25519

公開鍵をサーバーへ（例）：

ssh-copy-id admin@＜サーバーIP＞

2) SSH設定を強化する（最小限の安全策）

/etc/ssh/sshd_config を編集し、目安として以下を設定します。

rootでのSSHログインを禁止
パスワード認証を無効（鍵のみ）

sudo nano /etc/ssh/sshd_config

例（存在する行を探して変更）：

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

反映：

sudo systemctl restart ssh

3) “入口を閉じる”は2段階で考える

XServer側（パケットフィルター）：VPSに届く通信を制限
OS側（ファイアウォール）：OSが受け取る通信を制限

この二重化が、初心者でも事故を減らせます。

Minecraftサーバー導入（Java版の例）

ここでは Java版（Vanilla/Paper/Forge等の土台）を、手動で入れる流れを例示します。
MODやプラグインは、まず「素のサーバーが動く」まで進めてから足すのが最短です。

Javaの導入とバージョン選定

Javaは Minecraftのバージョンで必要条件が変わります。目安としては次の理解でOKです。

1.20.5以降：Java 21 が必要
1.18〜1.20.4：Java 17 が必要（それより古いと条件が異なる）

迷ったら「立てたいMinecraftのバージョン → 必要なJava」を先に確定してください。

Ubuntu/DebianでJava 21を入れる例：

sudo apt update
sudo apt -y install openjdk-21-jre-headless
java -version

Java 17を使いたい場合：

sudo apt -y install openjdk-17-jre-headless
java -version

※複数Javaを切り替える運用はできますが、初心者は “1サーバー=1Java”の方が事故が少ないです。

サーバーファイル配置とEULA同意

Minecraft用のユーザーと作業場所を作ります（例：/opt/minecraft）。

sudo adduser --system --home /opt/minecraft --group minecraft
sudo mkdir -p /opt/minecraft/server
sudo chown -R minecraft:minecraft /opt/minecraft

公式のサーバーjar（server.jar）を用意します。
最も安全なのは、Minecraft公式の「Java Edition Server」配布ページから取得する方法です（リンクのコピー→wget等）。

配置後、初回起動してファイルを生成：

sudo -u minecraft bash -lc 'cd /opt/minecraft/server && java -Xms1G -Xmx1G -jar server.jar nogui'

EULAに同意（eula.txt の false を true に）：

sudo -u minecraft nano /opt/minecraft/server/eula.txt

もう一度起動して、正常に立ち上がるか確認します。

メモリの考え方（最初は控えめ→後で調整）

例：2GBプランなら -Xmx を1G〜1.5G程度から様子見
OSや他プロセスにもメモリが要るため、“全部割り当て”は危険です

常駐起動（systemd / screen / tmux など）

初心者におすすめは systemd です（再起動後も自動起動しやすい）。

/etc/systemd/system/minecraft.service を作成：

sudo nano /etc/systemd/system/minecraft.service

中身（例）：

[Unit]
Description=Minecraft Server
After=network.target

[Service]
User=minecraft
WorkingDirectory=/opt/minecraft/server
Restart=on-failure
RestartSec=10
ExecStart=/usr/bin/java -Xms1G -Xmx1G -jar server.jar nogui

[Install]
WantedBy=multi-user.target

有効化して起動：

sudo systemctl daemon-reload
sudo systemctl enable --now minecraft
sudo systemctl status minecraft --no-pager

ログ確認：

journalctl -u minecraft -n 50 --no-pager

screen/tmuxは「一時的に動かす」「作業中の確認」に便利ですが、運用の安定性はsystemdが上です。

ネットワーク設定（必須）

「サーバーは動いてるのに、外から入れない」の9割はここです。
XServer側 + OS側の両方でポートを通します。

VPS側のフィルタ／FW設定でポートを許可する

XServerには パケットフィルターがあり、ここで必要ポートを許可します。
ゲーム用パネルでも通常のVPSでも同様に“フィルタで許可する”流れになります。

最低限（例）：

SSH：22/TCP（自分の管理用）
Java版：25565/TCP（マイクラ接続）
（統合版を立てるなら）19132/UDP

※構成次第で追加（例：RCON、Dynmap等）がありますが、初心者はまず“必要最小限”でOKです。

Java版・統合版のポート整理（参加者向けに説明できる形に）

参加者へ渡す情報は、これだけに絞ると迷子が減ります。

Java版
- アドレス：IP or ドメイン
- ポート：通常 25565（省略されることも多い）
統合版
- アドレス：IP or ドメイン
- ポート：通常 19132

コピペ用テンプレ（配布）

Java版：example.com（必要なら example.com:25565）
統合版：example.com / ポート 19132

ドメイン利用（DNS／必要ならSRVの考え方）

ドメインを使うと、IP変更時や共有がラクです。

DNSで Aレコードを作る
- mc.example.com → ＜VPSのIP＞
ポートを変えたい場合（Java版）
Java版は SRVレコードで「ポートを隠す」運用ができます（対応クライアントで有効）。
- 例：_minecraft._tcp.mc.example.com を SRV で設定し、内部的に 25565 へ誘導

ただし、SRVはDNS側の設定ミスが起きやすいので、初心者はまず 標準ポート25565のままが安全です。

XServer VPS 公式サイト
XServer VPS for Game 公式サイト

サーバー設定で体験が変わる：最低限とおすすめ

マイクラサーバーは「立てた瞬間が完成」ではなく、設定しだいで快適さ・安全性・ラグの出やすさが大きく変わります。
ここでは初心者でも扱いやすいように、まずは “最低限だけで事故を防ぐ” → “重くなったら効く設定から触る” の順で整理します。

server.propertiesの要点（安全・快適の両立）

server.propertiesは、マイクラサーバーの基本設定をまとめたファイルです。
ただし、闇雲に触ると「入れなくなった」「遊び方が変わった」などが起きるので、初心者は目的別に必要な項目だけを押さえるのがコツです。

whitelist／権限（OP）／オンライン認証周り

まず守りの設定です。ここを固めるだけで、荒らし・事故・余計なトラブルがかなり減ります。

おすすめの結論

友達と遊ぶなら、基本は 招待制（ホワイトリスト） が安全 ✅
OP（管理者権限）は 必要最小限（1〜2人） に絞る ✅
オンライン認証（online-mode）は、事情がない限り オンのまま が無難 ✅

最低限セット（何をどうするか）

スクロールできます

目的	見る項目の例	おすすめの考え方
招待制にしたい	whitelist / enforce-whitelist	whitelistを有効にし、許可した人だけ入れる
管理者を絞りたい	ops.json（OP一覧）	OPは最小限。配布ワールド編集などは管理者だけ
“正規ログイン”を前提にする	online-mode	原則オン。変更はリスクと影響を理解してから

運用のコツ（初心者でも混乱しない）

設定を変えたら、必ず 再起動 → 自分でログイン確認 → 参加者に案内 の順にする
参加者の追加・削除は「誰が」「いつ」やったかをメモ（Discordの固定メッセージでもOK）

ありがちな落とし穴

OPを増やしすぎて、誰かが誤操作（ゲームモード変更、ワールド破壊など）
whitelistを使っているのに、案内が雑で「入れない！」が多発
→ 参加者への案内は アドレス・ポート・バージョン・参加名をテンプレ化すると解決しやすいです。

難易度・ゲームモード・スポーン周り

次は“遊び心地”を決める設定です。ここは正解が1つではないので、初心者は最初のおすすめ値から始めるのがラクです。

最初のおすすめ（迷ったらこれ）

難易度：Normal（易しすぎず、アイテムも揃いやすい）
ゲームモード：Survival（一般的な遊び）
PvP：仲間同士なら OFF でもOK（事故死が減る）
スポーン保護：拠点荒らしを避けたいなら ON（ただし拠点作りの自由度とトレードオフ）

目的別の選び方

「拠点を荒らされたくない」
→ スポーン周りの保護（スポーン保護範囲など）を活用
「最初からクリエで建築したい」
→ gamemodeをクリエ寄りに。ただし混在するなら権限設計が必要
「難易度で揉める」
→ 固定にするより、「変更ルール（多数決・イベント時だけ等）」を先に決める方が揉めにくいです。

ラグ対策の基本（設定由来の負荷を減らす）

ラグの原因は色々ありますが、初心者が最短で効かせられるのは「設定で減らせる負荷」です。
ここを先に触ると、スペック増強よりもコスパ良く改善することがよくあります。

描画距離・シミュレーション距離

この2つは「重いときに最初に見る場所」として鉄板です。

描画距離（view-distance）
- プレイヤーに送る地形（チャンク）の範囲
- 上げるほど見通しは良いが、サーバー負荷が増える
シミュレーション距離（simulation-distance）
- 作物成長、MOB挙動、レッドストーンなど“動く処理”の範囲
- 下げると負荷は下がるが、遠くの装置や畑が動きにくくなる

初心者向けの調整手順（迷わない順番）

まずは simulation-distanceを少し下げる（体験を壊しにくく、効きやすい）
まだ重いなら view-distanceを下げる
それでもダメなら、後述の“仕組み由来の負荷”を疑う（ホッパー等）

目安の考え方（数値を丸暗記しない）

人数が少ないうちは、距離を少し高めでも耐えることがあります
人数が増えるほど、同時に処理する範囲が増えるので、距離設定の影響が大きくなります
“まず低めで始めて、物足りなければ上げる”が、失敗しにくい運用です 👍

エンティティ／ホッパー／レッドストーンの負荷

「距離を下げても重い」なら、次はこの3つが原因であることが多いです。

1）エンティティ（MOB・アイテム・村人など）

代表例：村人施設の作りすぎ、MOBトラップ常時稼働、アイテム散乱
対策：放置トラップの稼働ルール、アイテムが散らない工夫（回収・整理）

2）ホッパー

代表例：大量ホッパーが常に探索している（チェスト倉庫の作りが重い）
対策：必要な場所に絞る／“常時動く形”を減らす／大型倉庫は設計を工夫

3）レッドストーン

代表例：クロック回路が常に回っている、巨大装置を常時稼働
対策：スイッチで止める、必要なときだけ動かす、装置の稼働ルールを決める

初心者でもできる“効くルール”例

放置トラップは同時稼働1つまで（人数が多いほど効く）
大型倉庫のホッパーは必要最小限
常時稼働クロックは禁止（重い原因になりやすい）

設定をいじるより先に、こうした運用ルールで解決するケースも多いです。

Paper系の最適化（プラグイン環境の定番チューニング）

Paperは「Spigot系の高性能サーバー」として定番で、同じハードでも軽くなりやすいのが強みです。
ただし、最適化は“やりすぎると挙動が変わる”こともあるので、初心者は段階的に進めるのが安全です。

Paper/Spigot設定の見直しポイント

初心者が触って効果が出やすいのは、次の考え方です。

1）「ワールドごとの設定」がある前提で見る

Paper/Spigotは、設定が複数ファイルに分かれたり、ワールドごとに上書きできたりします
まずは「全体設定」と「特定ワールド設定」が混ざっていないかを意識すると迷子になりにくいです

2）重いときの“定番”に絞って見る

例として、Spigot設定には 視界距離・エンティティ挙動距離など、ラグと関係が深い項目があります
いきなり大量に変えず、1つ変えたら再起動→体感確認の手順で進めるのがコツです

おすすめの進め方（失敗しない）

まずは server.properties の距離設定を整える
次に、Spigot/Paper側で “挙動範囲”や“処理頻度”の見直しを検討
「軽くなったけど挙動が変で不満」が出たら、変更を戻せるように 設定ファイルのバックアップを先に取る

計測の考え方（上級者っぽくしない版）

“なんとなく重い”のまま設定を弄ると迷走しがちです
Paper系では、負荷の見える化（Timings/Sparkなどの考え方）がよく使われます
→ 初心者はまず「何が重いかを特定する道具がある」くらい覚えておけばOKです。

管理・保護系プラグインの選定基準

プラグインは便利ですが、入れ方を間違えると重くなる・不具合が出る原因にもなります。
初心者ほど、選定基準を固定して“地雷”を避けるのが安全です。

最低限の選定基準（これだけ守れば失敗しにくい）

対応バージョンが明記されている（自分のサーバー版に対応）
更新が継続されている（長期間更新が止まっていない）
導入目的が明確（“何でも入り”系より、役割がはっきりしたもの）
権限（Permissions）設計ができる（誰でも強い機能を触れない）

初心者向けの“優先順位”

権限管理（誰が何をできるかを整理）
保護・復旧（荒らしや誤操作から戻せる仕組み）
便利機能（ワープ、ホーム、経済など）は、必要になってから追加

導入の安全手順（事故を減らす）

追加前に バックアップ
まずは 1つだけ導入して動作確認
問題がないことを確認してから次へ（まとめて入れない）

この流れにするだけで、トラブル対応が一気にラクになります。

XServer VPS 公式サイト
XServer VPS for Game 公式サイト

プラグイン／MODを安全に導入・更新する

プラグインやMODは、入れるだけで便利になる一方で、「入れ方・更新の順番・戻し方」を決めていないとトラブルが増えます。
ここでは、初心者でも事故りにくい“型”を、Paper（プラグイン）／Forge・Fabric・NeoForge（MOD）に分けてまとめます。

プラグインサーバー（Paper）

互換性・更新頻度・信頼性で選ぶ

プラグイン選びで失敗しないコツは、「機能」より先に “相性と継続性” を見ることです。

チェック項目（優先度順）

対応バージョンが明記されている
- 自分のMinecraftバージョン／Paperバージョンに合うか
更新が継続されている
- 最近の更新が止まっていないか（放置プラグインは不具合が増えがち）
配布元が信頼できる
- 公式配布ページ・公式リポジトリ・実績ある配布サイトを優先
依存関係がはっきりしている
- 「このプラグインには前提プラグインが必要」などが明確か
設定が分かりやすい
- ドキュメントやサンプル設定があり、運用の想像がつくか

初心者が避けたい地雷パターン

“とりあえず便利そう”で大量導入 → どれが原因か分からなくなる
同じ機能のプラグインを複数入れて競合（例：権限系・保護系・ワープ系）

おすすめの考え方

まずは 「権限」「保護」「バックアップ」 の3ジャンルだけで十分
便利機能（ワープ・経済・ミニゲーム等）は、必要になってから追加が安全です

導入／更新／削除の手順（事故を防ぐ）

プラグイン周りは、次の“型”を守るだけでトラブルが激減します。

0）共通：作業前の3点セット

バックアップ（ワールド＋plugins＋設定ファイル）
変更メモ（何を入れた／何を更新した）
戻し方の準備（旧jarを退避しておく）

1）導入手順（新規追加）

サーバーを停止（または少なくとも安全に再起動できる状態に）
プラグインjarを plugins/ に配置
起動 → コンソール（ログ）で読み込み成功を確認
生成された設定ファイルを調整
再起動 → 動作確認（コマンド、権限、競合）

ポイント

いきなり複数入れない（1個ずつ入れて確認）
依存プラグインがある場合は、先に依存側を入れる

2）更新手順（安全な更新の基本）

Paperは、更新時に専用フォルダを使って更新する手順が定番です（上書き事故・二重導入を避けやすい）。

plugins/update/ フォルダを作る
新しいプラグインjarを plugins/update/ に入れる
再起動（サーバー稼働中にjarを入れ替えない）
起動後、プラグインのバージョンが更新されたか確認

よくある失敗

同じプラグインのjarが2つ残っている（旧版と新版が同居）
→ 「二重導入」は不具合の原因になりやすいので、必ず整理します。

3）削除手順（消す前に“何が残るか”を理解）

サーバー停止
plugins/ から対象jarを退避（いきなり削除しない）
起動して問題がないか確認
問題なければ、設定フォルダやデータファイル（例：plugins/PluginName/）を整理
- 迷うなら、設定・データは残す（復帰がラク）

困ったときの切り分け（最短で原因に近づく）

「何かおかしい」→ プラグインが原因かどうかを先に判定
- plugins フォルダ名を一時的に変えて（例：plugins-disabled）起動し、症状が消えるか確認
ログに特定プラグイン名が出る → そのプラグインを最優先で疑う
直前に更新したプラグインがある → まずロールバック（旧jarに戻す）

MODサーバー（Forge/Fabric/NeoForge）

MODと本体バージョンの整合を取る

MOD環境は「構成が1ミリでもズレると入れない」のが基本です。
整合で見るのはこの3点セット。

Minecraft本体バージョン（例：1.20.1 / 1.21.x など）
ローダー（Forge / Fabric / NeoForge）
MODの対応バージョン（上の2つに一致しているか）

初心者向けの鉄則

“最新版に上げたい”より先に、遊びたいMODが動く版を固定する
途中で上げるなら、本体→ローダー→MODの順に検証しながら進める

更新前に確認すること

MOD配布元の「対応バージョン」「既知の不具合」「前提MOD（依存）」
更新でワールド互換が壊れないか（大型MODや生成系は要注意）

参加者側に必要な準備（同じMOD構成を揃える）

マルチで一番多い詰まりは「参加者のMODが揃っていない」です。
案内は“文章”より、配布物（同じセット）で揃えるのが確実です。

参加者に渡すべきもの（基本）

modsフォルダ一式（同じファイル、同じバージョン）
configフォルダ（必要なら）
- MODによっては、設定が揃っていないと挙動が変わります
起動に必要なローダー情報
- Forge/Fabric/NeoForgeのどれか、ローダーのバージョン

ズレを防ぐ運用テク

「サーバーMOD一覧」を固定（メモでもOK）し、更新履歴も残す
参加者には「このzipを入れるだけ」にして、手作業を減らす
“サーバー専用MOD”と“クライアント必須MOD”を分けて把握する
- サーバーにしか要らないMODもありますが、初心者はまず「全員同じmods」で始めると事故が少ないです

クラッシュログの最低限の読み方

MOD環境でトラブったら、感覚で直すよりログから当てにいく方が早いです。
初心者は、全部読もうとせず「見る場所」を固定するとラクになります。

1）まず探すファイル

logs/latest.log（ほぼ必ず役に立つ）
crash-reports/ 内のクラッシュレポート（出るときは出る）

2）最初に見るポイント（ここだけで8割）

“Caused by（原因）” に近い行
Mod名（modid） や jar名 が出ている箇所
Missing / required（不足・依存不足）
- 例：前提MODが入っていない、バージョンが合わない
Mixin / class not found
- ほぼ「対応バージョン違い」か「MOD同士の衝突」が原因になりがち

3）症状別の当たりの付け方

起動直後に落ちる
→ ローダー／前提MOD不足／バージョン不一致の可能性大
ワールド読み込みで落ちる
→ 生成系・追加ブロック系・ワールド互換の問題が多い
特定操作で落ちる（アイテムを開く等）
→ その機能に関わるMODの衝突・設定不整合が多い

4）最短の直し方（初心者向け）

直前に入れた／更新したMODを 1つ戻す（または外す）
それで直るなら、そのMODの「対応バージョン」「依存」「既知不具合」を確認
直らないなら、半分ずつ外して原因を絞る（“二分探索”）

XServer VPS 公式サイト
XServer VPS for Game 公式サイト

安定運用のベストプラクティス

「一度立てたら終わり」ではなく、落ちない・壊れない・戻せる状態にしておくと、マイクラサーバー運用は一気にラクになります。ここでは初心者でもそのまま採用しやすい“型”に絞ってまとめます。

バックアップ設計：頻度・保存先・復元テスト

バックアップは「作る」より “戻せるか”が本番です。おすすめは次の3点セットです。

頻度の決め方（迷ったらこのルール）

毎日1回（自動 or 手動）：最低ライン
プレイ時間が長い日：終了後に追加で1回
アップデート／プラグイン／MOD追加前：必ず1回（作業前の儀式）

「頻度を上げる」より、まず 世代（何個残すか）を決めると事故に強いです。

世代管理のおすすめ（シンプルで強い）

日次：直近 7個
週次：直近 4個
月次：直近 3〜6個

これなら「昨日から壊れていた」みたいなケースでも戻しやすいです。

保存先は“二重化”が安心

バックアップがサーバー内だけだと、ディスク破損や誤操作時に同時に失うことがあります。

① サーバー内（管理ツールのバックアップ）：復元が速い
② 手元PC or 別ストレージにダウンロード：最悪時の保険

可能なら「3-2-1（3つ持つ／2種類の媒体／1つは別場所）」の考え方で、最低でも“2か所”に置くのが安全です。

復元テスト（ここが差を作る）

バックアップは「取れているように見える」だけでは不十分です。おすすめはこの頻度。

月1回：テスト用の環境（別VPSや別ディレクトリ）に復元して起動できるか確認
大きな更新（メジャーアップデート）前：必ず1回

チェックするのは難しくありません。

サーバーが起動する
自分がログインできる
重要施設（拠点・ネザーゲートなど）が破綻していない

アップデート運用：本体／プラグイン／MOD

更新作業は、「順番」「確認ポイント」「戻し方」の3点で事故がほぼ決まります。

共通の型（本体でもプラグインでもMODでも）

メンテ時間を決めて告知（今から更新するをやめる）
バックアップ
更新は1段ずつ（まとめて上げない）
起動 → ログ確認 → ログイン確認
問題があれば 即ロールバック（元に戻す）

本体（Minecraftサーバー）の更新

バージョン差分の影響が大きい（特にメジャー更新）
ワールド生成や仕様変更が絡むため、更新前に
- 参加者のバージョンを揃えられるか
- プラグイン／MODが追随しているか
  を確認してから進めるのが安全です。

プラグイン（Paper）の更新

更新で多い事故は「二重導入」「互換性の崩れ」「依存関係の抜け」です。
おすすめは Paperの“updateフォルダ方式”（更新手順を固定できて事故が減る）

運用の目安：

重要プラグイン（権限・保護・経済など）は 慎重に（更新間隔は長めでもOK）
小規模サーバーは「必要に迫られたら更新」でも十分回ります

MOD（Forge / Fabric / NeoForge）の更新

MOD環境は「揃えるもの」が多いので、更新の基本はこれです。

本体 → ローダー → MODの順で整合を見る
参加者側にも 同じ構成を配布（mods/config/ローダー版）

更新で困りやすいのは「依存MODの追加」や「対応版ズレ」なので、更新のたびに

追加したMOD
更新したMOD
外したMOD
をメモしておくと復旧が速いです。

監視と通知：落ちた時に気づける仕組み

監視は“本格的な監視ツール”より、まず 気づける最小構成を作るのが効果的です。

最低限：落ちたら自動で起き上がる

systemdのRestart設定（プロセスが落ちたら再起動）
定期再起動（必要なら、深夜などに固定）

「落ちた瞬間の手動対応」を減らすだけでも運用がかなり安定します。

次に効く：外から死活を見て通知する

サーバー内で監視しても、サーバー自体が死んだら通知が飛びません。
そこでおすすめなのが 外部の死活監視です。

TCPポート監視：25565（Java）/19132（統合）が開いているか
HTTP監視：Dynmap等を公開しているならURL監視でもOK
通知先：メール／Discord／LINE（Webhook連携）

“落ちたのに誰も気づかない”を防げれば十分価値があります。

バックアップ監視（見落としがち）

実は多いのが バックアップが止まっていた問題です。
対策はシンプルで、バックアップ処理が走ったら外部に“生存信号”を送る方式が便利です。

cronが動いたら外部サービスにPing
Pingが来なければ通知（＝バックアップ失敗に気づける）

本格派：監視ツールを入れる（必要な人だけ）

やることが増えてきたら、監視ツール（Nagios等）を入れて

CPU/メモリ
ディスク残量（バックアップで埋まりがち）
プロセス稼働
をまとめて見るのも手です。

ワールド移行：別環境・他社からの引っ越し

移行は「ファイルを置けば終わり」ではなく、止める→固める→持ち出す→入れる→確認の順が重要です。

移行前チェック（最短で失敗を避ける）

エディション一致（Java/統合）
バージョン一致（移行先で起動できる版か）
MOD/プラグイン環境の一致（導入しているならセットで移行）
ネザー／エンドも含めて移すか（ワールドが複数フォルダの場合がある）

基本手順（どの環境でも通用）

サーバー停止（ワールド書き込みを止める）
ワールドをZIP化（必要なフォルダをまとめる）
移行先へアップロード
所定の場所に配置して起動
ログイン確認 → 重要地点確認

XServer側の移行機能を使える場合

XServerのゲーム用環境には、移行を簡単にする仕組み（簡単移行・ファイルマネージャ等）が用意されています。
該当する環境なら、手動SFTPよりも 公式手順に寄せた方がミスが減りやすいです。

移行後の確認（ここまでやって完成）

スポーン地点が正常
ネザーゲート接続が破綻していない
主要施設（村人施設・トラップ等）が動く
重さが急に増えていない（距離設定やエンティティ量を再確認）

XServer VPS 公式サイト
XServer VPS for Game 公式サイト

セキュリティ・荒らし対策（最低限はやる）

ここは「やり込み」ではなく、最低限の防波堤を作るパートです。
ポイントは次の3つだけ。

入口を減らす（開けるポート・権限・管理者を最小限に）
乗っ取りにくくする（2段階認証／SSH鍵／root禁止）
荒らされても戻せる（参加制限＋ログ＋バックアップ）

OS更新・ミドルウェア更新を習慣化

VPSは放置すると、既知の脆弱性を突かれて終わるのが現実です。
「毎回こまめに」より、回せる運用ルールにしておくと続きます。

更新の優先順位（迷ったらこの順番）

OSの更新（最優先）
SSHやFWなど“外に開く系”の更新
Java・Minecraft本体・管理ツール周り
プラグイン／MOD（互換性を確認しつつ）

更新頻度の目安（初心者でも続く設定）

週1回：OS更新（15分で終わるルーティン）
月1回：再起動を伴う更新（カーネル更新など）
何か入れる前：必ず更新（新規構築時の事故を減らす）

まずは“自動更新”を検討する

Linuxは自動更新の仕組みがあります。
常時稼働のマイクラでは「勝手に再起動」すると困るので、運用は次のどちらかに寄せると安全です。

自動ダウンロード＋手動適用（おすすめ）：メンテ時間にまとめて反映
セキュリティ更新のみ自動適用：再起動タイミングは自分で握る

Minecraft側の更新は「互換性」を最優先

OSと違い、Minecraft本体／Paper／Forge系は更新で動かなくなることがあります。

本体を上げる前に プラグイン／MODが対応しているか確認
大型アップデートは “すぐ追わない”のも立派な安全策
可能なら、更新前に テスト用の別環境で起動確認（ワールドのコピーでOK）

管理画面・SSH・OP権限の守り方

マイクラ運用は入口が複数あります。それぞれ役割が違うので、混ぜないことが最大の対策です。

スクロールできます

守る場所	できること	最低限の守り
事業者のアカウント（契約・サーバー全体）	契約管理・サーバー操作・各種設定	2段階認証／強いPW／共有しない
SSH（サーバーOS）	ファイル操作・設定変更・全部できる	鍵ログイン／root禁止／IP制限
ゲーム内権限（OP）	コマンド・BAN・ルール変更	OPは最少人数／普段は外す

管理画面（アカウント）でやるべきこと

2段階認証を有効化（最優先）
パスワードは使い回さず、長め（12〜16文字以上）
友達と遊ぶだけなら、管理画面のID/パスワードは共有しない
→ 共有するのは 接続先（IP/ドメイン）とルールだけで十分です

SSHでやるべきこと（できれば全部）

SSHは狙われやすいので、ここを固めると一気に楽になります。

公開鍵認証（鍵ログイン）にする
rootで直接ログインしない（一般ユーザー＋sudoに寄せる）
パスワードログインを許可するなら
- 接続元IPを限定（自宅や自分の回線だけ）
- それが無理なら fail2ban等で総当たり対策

「SSHを使わない運用」なら、そもそもSSHを閉じるのが最強です。
ただしファイル転送（SFTP）や手動復旧をする可能性があるなら、“必要な時だけ開ける”運用が現実的です。

OP権限でよくある事故と対策

OPを配りっぱなし → いたずら・誤操作が起きる
- 対策：OPは最少人数／普段は外す／必要時だけ付与
コマンドでワールド破壊（/fill /kill など）
- 対策：操作担当を絞る、ログが残る仕組みを入れる（後述）

ホワイトリスト／参加制限／BAN運用

“荒らし対策”は難しいことをするより、まず 入れない が最強です。

ホワイトリストは基本「ON」

公開サーバーにしないなら、ホワイトリストONが最も費用対効果が高いです
参加メンバーは「招待制」にして、追加・削除のルールを決めます

おすすめの運用ルール（そのまま使えます）

参加希望は ゲーム内ID（またはゲーマータグ）で申請
追加は管理者1名が担当（勝手に増やさない）
参加者が抜けたら 即削除
トラブル時は 一旦ホワイトリストを締めてから整理（被害拡大を止める）

BANは「短期→長期」の段階制が扱いやすい

まずは 警告＋一時BAN（例：24時間）
改善がなければ 長期BAN
露骨な荒らしは 即BAN

友人間サーバーでも、方針があるだけで揉めにくくなります。

“証拠が残る”仕組みを作る

荒らし対策は感情戦になりがちなので、ログと復旧手段があると強いです。

いつ誰が入ったか（ログインログ）
何が壊れたか（ブロック変更ログが残る仕組み）
バックアップから戻せるか（復元手順の固定）

プラグイン環境（Paper）なら、ロールバック系・保護系を優先すると、復旧が圧倒的に速くなります。

不正アクセス・DDoSに備える現実的な対策

結論から言うと、個人VPSでできるのは 「攻撃されにくくする」「被害を小さくする」 までです。
大規模DDoSを個人で完全に防ぐのは難しいので、守る場所を分けて重ねるのが現実的です。

1) まずは“開けるポート”を最小限にする

公開するポートは、基本これだけに寄せます。

Java版：25565/TCP（※変更している場合はそのポート）
統合版：19132/UDP（※変更している場合はそのポート）
SSH：使うなら 必要な時だけ（可能なら接続元IPを限定）

「よく分からないポートが開いている」状態をなくすだけで、事故が激減します。

2) 事業者側のフィルター機能（パケットフィルター）を使う

OS側のFW（ufw/iptables）だけで頑張るより、先に入口を落とすほうが簡単で堅いです。

ゲームに必要なポートだけ許可
SSHは「自分のIPだけ許可」or「使う時だけ許可」
それ以外は閉じる

3) OS側でも“最後の砦”を作る

事業者側で落としても、OS側で保険をかけると運用が安定します。

OSファイアウォールで 許可ポートを固定
SSHは 試行回数制限（fail2ban等）
ログを見て、怪しいIPが続くなら遮断

※注意：fail2banは“ログイン試行”には強いですが、回線を埋めるタイプのDDoSには効きません。目的を分けて考えるのがコツです。

4) 公開しないのが最強（できる人向け）

もし参加者が身内だけで、設定も許容できるなら

VPN（メッシュVPN）で閉域化して
ゲームポート自体を インターネットに公開しない

という形にすると、荒らしやスキャン系のリスクを根こそぎ減らせます。
「とにかく安全に身内で遊びたい」なら検討価値があります。

5) それでも攻撃されたら（被害を小さくする動き）

まず ホワイトリストON／一時停止で状況固定
事業者側の機能（DDoS対策・フィルター）を確認して適用
ログとバックアップで復旧
公開サーバー運用なら、DDoS対策された中継（プロキシ）や専用サービスも検討

XServer VPS 公式サイト
XServer VPS for Game 公式サイト

よくあるトラブルと切り分け手順

トラブル対応で一番大事なのは、“当てずっぽうで弄らない”ことです。
最短で直すコツは、まず次の4つをメモしてから切り分けること。

参加者の エディション（Java/統合）
参加者の バージョン
接続先 アドレス（IP/ドメイン） と ポート
サーバー側の 稼働状況（起動してる？落ちてる？）

この4点が揃うと、原因の8割はすぐ絞れます。

接続できない：確認の順番（最短で直す）

おすすめの確認順はこれです（上から潰すほど早い）

エディション／バージョン
アドレス・ポート・ファイアウォール
サーバー稼働状況・IP変更・ホワイトリスト

エディション／バージョン

ここがズレていると、ネットワーク設定が完璧でも入れません。

チェックポイント

参加者は Java版？ 統合版？（混在だと原則そのままでは不可）
サーバーのバージョンと、参加者のバージョンが一致しているか

よくあるパターン

✅ Java版サーバーを立てたのに、参加者にSwitch/スマホ（統合版）がいる
✅ 参加者だけ先に最新版へ更新 → サーバーが古い版のまま
✅ MOD環境で、参加者のMOD構成が1つでも違う（=別物）

最短の対処

揃えるのは「サーバー側に合わせる」が基本
（参加者が多いほど、サーバー側を軸にした方が事故が減ります）

アドレス・ポート・ファイアウォール

次に多いのがここ。
“1文字の入力ミス”と“ポートが閉じている”が大半です。

1) アドレス確認（まずコピペ）

IP/ドメインは 必ずコピペ（手入力はミスの元）
ドメイン運用なら、DNS反映直後は時間差が出ることがあります

2) ポート確認（迷ったらここだけ）

Java版：通常 25565 / TCP
統合版：通常 19132 / UDP

参加者への案内は、できればこの形に固定すると迷子が激減します。

Java版：example.com（必要なら example.com:25565）
統合版：アドレス example.com、ポート 19132

3) XServer側のフィルター（最優先で確認）

XServerでは、VPS側に パケットフィルターがあり、ここで詰まりがちです。

確認すること

パケットフィルターがONなら、必要な通信が許可されているか
「XServer VPS for Game」系なら、ゲーム推奨のルールが入っているか（FAQで案内されている確認ポイントです）

切り分けのコツ

いったん「接続できるか」だけを確認したいなら
→ 必要ポート（25565/19132）だけ許可して試す
（許可範囲を広げすぎないのが安全です）

4) OS側のFW（SSH構築の場合は要チェック）

SSHで一から構築（方法B）をしている場合、OS側で閉じていることがあります。

Ubuntu系なら例として：

ufw status で有効か確認
必要なら 25565/tcp を許可

（ここは環境ごとに設定が違うので、“OS側も壁がある”ことだけ覚えておけばOKです）

5) 参加者側の環境（意外と盲点）

会社/学校Wi-Fiなど、ゲーム通信が制限されている回線
セキュリティソフトが通信をブロックしている（クライアント側）

この場合、参加者だけ別回線（スマホテザリング等）で試すと一発で判別できます。

サーバー稼働状況・IP変更・ホワイトリスト

1) サーバーが本当に動いているか

管理パネルで「稼働中」か確認
直前に再起動・更新をしたなら、起動完了まで少し待つこともあります

2) IPが変わっていないか

以下の操作をした後は、IPが変わる可能性があります（環境・操作内容による）。

サーバー再作成（OS再インストール／作り直し）
何らかの移行・切替

対策

「前のIPを共有したまま」になっていないか確認
ドメイン運用なら、DNSのAレコードが新IPを向いているか確認

3) ホワイトリストで弾かれていないか

招待制（ホワイトリスト）にしている場合、IDの表記揺れが原因のことが多いです。

大文字小文字の違い
記号やスペースの入れ間違い
統合版のゲーマータグの入力ミス

最短の対処

管理ツールで該当IDを一度削除 → もう一度追加 → 再起動（必要なら）
まず管理者が入れるか確認してから、参加者を案内

起動しない／落ちる：原因トップ3と対処

結論として、初心者がハマりやすい原因はこの3つです。

メモリ不足
Javaの不一致
MOD/プラグインの不整合

メモリ不足・Java不一致・MOD/プラグイン不整合

1) メモリ不足（特にMOD）

症状

起動途中で落ちる
プレイ開始直後に落ちる
ログに “OutOfMemory” っぽい文言が出る

対処

まず 割り当てメモリ（-Xmx）を適正化
“全部割り当て”はNG（OS側が枯れて逆に落ちやすい）
MOD環境なら、MODを減らして起動確認（原因切り分け）

2) Java不一致（バージョン要件）

症状

jarを実行してもすぐ終了
“Unsupported class version” 系のエラーが出る

対処

サーバー本体のバージョン要件に合うJavaを入れる
すでに複数Javaが入っている場合は、実行に使っているJavaがどれか確認

3) MOD/プラグイン不整合（更新後に多い）

症状

更新した直後から起動しない
特定のプラグイン名/Mod名がログに出る

対処（最短）

“直前に触ったもの”を 戻す（ロールバック）
- プラグイン：旧jarに戻す
- MOD：直前に入れた/更新したMODを外す
それで起動するなら、互換性（対応バージョン・依存関係）を再確認

ログで見るべき箇所（初心者向け）

ログは全部読もうとすると疲れます。見る場所を固定すると楽になります。

まず見るファイル

（多くの環境で）latest.log
MOD環境なら crash-reports/ のレポート

見る順番（ここだけ）

一番下の数十行（落ちた直後の情報がある）
Caused by 付近（原因の手掛かり）
プラグイン名 / Mod名 / jar名が出ている行
“Missing/required” “not found” “version” などの語がある行

迷ったときの強い手

直前に入れたものを外す（1つずつ）
それでもダメなら、半分ずつ外して原因を絞る（いわゆる二分探索）

このやり方は、初心者でも再現性が高いです。

重い／TPS低下：設定・ワールド・プランのどこが原因？

体感の「重い」は原因が3系統に分かれます。

設定由来（距離・エンティティ制御など）
ワールド由来（装置・村人・MOB・アイテム散乱など）
プラン（CPU/メモリ/ディスク性能）の限界

まずは、上から順に“タダで効く対策”を当てにいくのがコスパ最強です。

設定由来（距離・エンティティ等）の改善

最初に触るべき2つ

シミュレーション距離（動く範囲）
描画距離（送る範囲）

改善の順番（おすすめ）

まず シミュレーション距離を下げる（体験を壊しにくい）
次に 描画距離を下げる
まだ重いなら「仕組み由来」を疑う

仕組み由来の“重い三兄弟”

大量エンティティ（村人・MOB・落下アイテム）
大量ホッパー（常時探索）
常時稼働レッドストーン（クロック回路）

✅ ここは設定よりも、運用ルール（同時稼働制限・装置の停止スイッチ）で劇的に改善することが多いです。

増強判断の目安（上げる前にやること）

プランを上げる前に、まずこれだけやると“無駄な増強”を避けられます。

増強前チェックリスト

距離設定を見直したか
放置トラップ・村人施設・ホッパー倉庫の規模を見直したか
不要なプラグイン/MODを整理したか
ディスク残量が逼迫していないか（バックアップで埋まりがち）
再起動で改善するタイプの劣化ではないか（長期連続稼働）

増強を考えるべきサイン（分かりやすいもの）

人数が増えるほど露骨に重くなる（ピーク時だけ耐えない）
最低限の最適化をしても、常にTPS低下が出る
MODの追加でメモリが明確に足りなくなった

この状態なら、メモリ増強 or CPU余裕のあるプランへ移行する価値があります。

XServer VPS 公式サイト
XServer VPS for Game 公式サイト

料金の見方とコスト最適化

VPSの料金は「月額」だけ見て決めると、あとで「思ったより高い／損した」となりがちです。
初心者が迷わないために、見る順番と最適化の考え方を“型”としてまとめます。💰

料金チェックのポイント（プラン／契約期間／キャンペーン）

1) まず「月額〜」の“〜”に注目する

XServer系は、同じプランでも 契約期間（例：1ヶ月／12ヶ月／36ヶ月）で月あたりが変わることがあります。
つまり、比較するときは必ず「自分が選ぶ契約期間の月額」で揃えましょう。

月額（表示）＝ プラン × 契約期間の割引が入った“最安値表示”の可能性あり
初回は「契約期間分の前払い」になることが多い
→ 月額が安く見えても、初回支払いが大きくなる点に注意

2) “初回だけ安い”特典と“ずっと安い”特典を分ける

キャンペーンにはタイプがあります。

初回利用料金の割引：初回は安いが、更新時に戻ることがある
長期契約割引：契約期間中ずっと効く（ただし縛りが長い）
クーポン／キャッシュバック：条件（新規・期間・最低契約月数など）を満たす必要がある

チェックはこの順がおすすめです。

自分が選ぶ「プラン」と「契約期間」の通常料金
同じ条件で使えるキャンペーン
追加で使えるクーポン／限定割
初回支払い総額（いつ、いくら払うか）

3) 「XServer VPS」と「XServer VPS for Game」は“料金＋手間”で判断

ゲーム用（for Game）は、管理機能やテンプレが前提なので、

月額は少し高くても、設定ミス・運用コストを減らせる
逆に、SSHで自力構築できるなら、通常VPSのほうが自由度とコスパが出る

…という違いが出ます。
「自分の時給」をざっくりでも入れて考えると、総コストの納得感が上がります。

4) 目安の料金感（比較用の“ざっくり表”）

※下は「何を見比べるべきか」を掴むための例です（表示は“月額〜”“実質月額〜”の形式になりやすい点に注意）。

スクロールできます

方式	料金の考え方	向いている人
XServer VPS（通常VPS）	プラン×契約期間×キャンペーンで最安が変動	自由度重視／SSHで構築できる
XServer VPS for Game	管理機能込みで“運用の手間”が減る	初心者／最短で安定運用したい
Realms（公式）	月額固定（プラットフォームで差が出る場合あり）	とにかく簡単／少人数で常時開けたい

“必要になったら上げる”運用で無駄を減らす

コスト最適化の基本は、最初から最大にしないことです。
ただし闇雲に安くすると、ラグで結局ムダになります。そこでおすすめは「段階運用」です。

ステップ1：最小構成で“基準”を作る

まずは 少人数・軽め（バニラ or 軽いプラグイン）で快適に動くラインを作る
目標は「誰も文句が出ない最低ライン」

ステップ2：増強前に“タダで効く改善”をやる

プランを上げる前に、先にこれをやるだけで“上げなくて良い”ケースが多いです。

描画距離／シミュレーション距離を下げる
エンティティ（村人・MOB・落下アイテム）を整理
ホッパー・レッドストーンの常時稼働を抑える
不要なプラグイン／MODを減らす
バックアップでディスクを圧迫していないか確認

ステップ3：上げるなら「1段だけ」上げる（戻りやすい）

いきなり倍にせず、1段上を試す
“上げた結果、何が改善したか”をメモする
→ 次回の判断が速くなります

ありがちなムダを防ぐコツ

「最初から36ヶ月」ではなく、まず短期で運用を固めてから長期にする
長期割引が強い時だけ、確信があるなら長期を選ぶ
友達が飽きる可能性があるなら、縛りは短めが安全

他の選択肢（Realms等）と総コストで比較する

VPSとRealmsは「料金」だけでなく、できること／上限／運用の手間が違います。
同じ“月額”でも、満足度が変わるポイントを整理します。

Realmsのコスト感（少人数なら強い）

公式サービスで設定がラク（サーバー知識がほぼ不要）
ただし、同時プレイ人数や自由度に上限がある
料金はプラットフォームで差が出る場合があり、購入画面での確認が確実

ざっくりの目安としては、

小人数向けプラン（自分＋2人程度）
大人数向けプラン（自分＋10人程度）

が用意されているイメージです。

VPSのコスト感（人数・拡張で逆転しやすい）

VPSは「同時人数が増えるほど」や「MOD/プラグインで重くなるほど」Realmsより有利になりやすいです。

人数上限が実質“スペック依存”になる（=伸ばせる）
プラグイン／MODや細かい設定ができる
ただし 運用の手間（更新・セキュリティ・バックアップ）は発生する

総コストで比べる“判断の早見”

迷ったら、この基準が分かりやすいです。

少人数・すぐ遊びたい・設定したくない → Realmsが有力
5〜10人以上になりそう／MOD・プラグインをやりたい／設定を詰めたい → VPSが有力
“VPSは不安”だけどRealms以上に自由度が欲しい → VPS for Game（管理機能込み）が有力

「割り勘」で見える世界

友達と遊ぶ場合は、月額を人数で割ると納得しやすいです。

月額1,000円でも、5人なら1人あたり200円
月額2,000円でも、10人なら1人あたり200円

「何人で、どれくらいの期間遊ぶか」を先に決めると、最適解がすぐ出ます。

XServer VPS 公式サイト
XServer VPS for Game 公式サイト

FAQ（よくある質問）

Switch/PS/スマホの友達も参加できる？

結論から言うと、「サーバーが統合版（Bedrock）かどうか」で決まります。

統合版（Bedrock）サーバーを立てた場合
- スマホ／タブレット／Windows（統合版）は参加しやすいです。
- Switch／PSなど家庭用ゲーム機も統合版なので“理屈上は同じ系統”ですが、機種や環境によっては「外部サーバーを追加」が素直にできないことがあります。
Java版サーバーを立てた場合
- そのままだとJava版（PC）しか参加できません。
- ただし、サーバー側に Geyser（＋必要に応じてFloodgate）を入れると、統合版クライアント（スマホや一部の家庭用ゲーム機など）を参加させる構成も作れます。