さくらのVPS×マイクラ入門｜プラン選びから公開・運用まで一気に解説

2026年2月11日

「友だちとマイクラを遊びたい。でも、ワールドは24時間いつでも入れる状態にしておきたい」
そんなときに候補に上がるのが VPS（仮想専用サーバー） です。中でも「さくらのVPS」は国内サービスとして知名度が高く、初めてでも挑戦しやすい一方で、いざ調べると不安や疑問が一気に出てきます。

たとえば、こんな声はありませんか？

「さくらのVPSって結局いくら？料金はどこを見れば最新なの？」
「何人まで快適に遊べる？探索多めだと重くなる？」
「Java版と統合版って何が違うの？ Switch/PS/スマホから参加できる？」
「スタートアップスクリプトって便利そうだけど、どこまで自動？自分で設定が必要？」
「ポート開放って何をすればいい？つながらないときはどこを疑う？」
「公開したら荒らされない？荒らし対策・乗っ取り対策は何からやるべき？」
「ワールドが壊れたら終わりそう… バックアップと復元はどう設計すれば安心？」
「アップデートで壊したくない。安全に最新化する手順が知りたい」

このページでは、初心者がつまずきやすいポイントを先回りしながら、プラン選び → 最短で立てる方法 → 安全設定 → バックアップ → 更新運用 → 重い/ラグい対策 → 公開時の注意までを、ひとつの流れとしてまとめます。

特に大事にするのは次の3つです。

失敗しない順番（“先にやるべきこと”を間違えない）
再現性（同じ手順で、誰でも迷いにくい）
安全性（荒らし・乗っ取り・データ消失を最小化）

「とりあえず動かす」だけで終わらせず、長く安心して遊べる運用まで一気に整えたい人は、このまま読み進めてください。

さくらのVPS 公式サイト

結論：さくらのVPSが向いている人／向かない人（他方式との住み分け）

さくらのVPSは、「自分でサーバーを持って運用する」タイプの選択肢です。
一方で、操作が簡単なぶん“管理の責任”も自分に来ます（アップデート、セキュリティ、バックアップなど）。

向いている人（おすすめ） ✅

月額を抑えつつ、マイクラのマルチ環境を作りたい
人数や負荷に合わせてスケールアップしていきたい
サーバーの設定（ポート開放・Linux操作など）を学びながら進めたい
Paper／Forgeなど、構成を自分好みに調整したい

向かない人（別方式がラク） ❌

とにかく1クリックで完成・運用は全部お任せがいい（→マイクラ専用のゲームサーバーやRealms系がラク）
休日だけ遊ぶなど、超短期で“使った分だけ払いたい”（→従量課金のクラウドや別方式が向きやすい）
統合版をスタートアップスクリプトで一発構築したい（※現在は公開が一時停止扱い）

💡コスト面の注意：月払いは「初回に2ヶ月分の請求」など、独特の請求サイクルがあります。さらに最低利用期間（3ヶ月）も案内されているので、短期利用前提なら先に把握しておくのが安全です。

「手軽に立てたい」人：スタートアップスクリプトが最短ルート

結論、Java版なら“最短で動く状態まで持っていく”のに強いです。
コントロールパネルでOSを選び、スタートアップスクリプトでMinecraft Server（Java版）を入れるだけで、初期構築の手間を大きく減らせます。

手軽ルートのメリット ✨

インストール作業をまとめて自動化でき、つまずきポイントが減る
まず動かしてから、人数に応じて上位プランへ拡張しやすい
クレカ払いなら2週間の無料お試しで動作確認もしやすい

ただし“何もしなくていい”わけではない ⚠️

バージョン更新で急に動かなくなる可能性はゼロではありません
運用（再起動、バックアップ、ログ確認、セキュリティ）は自分で行います
お試し期間中は転送量の制限などがあるため、体感の遅延が出ることがあります

迷ったらこの目安（Java版の人数イメージ）
（まずは“快適に遊べる最低ライン”としての目安。MOD多め・負荷高めなら上を選ぶのが安全です）

スクロールできます

目安人数	まずの推奨	こんな遊び方に
1〜4人	2G（仮想3Core/2GB）	バニラ中心・軽め
5〜9人	4G（仮想4Core/4GB）	探索多め・軽量プラグイン
10人以上	8G（仮想6Core/8GB）	大規模・余裕重視

「自由にいじりたい」人：手動構築（Paper／Forge／Bedrock）

「性能を出したい」「MOD構成を固めたい」「設定を完全に把握したい」なら、手動構築が最適です。
スタートアップスクリプトは“近道”ですが、手動にすると設計の自由度が上がります。

おすすめの分岐（ざっくり）

Paper系：軽量化・TPS重視で、マルチを安定させたい人向け
Forge/NeoForge系：MODをガッツリ入れたい人向け（※要求スペックが上がりやすい）
Bedrock（統合版）：統合版クライアントと遊びたい人向け
- ただし、さくらのVPSの統合版スタートアップスクリプトは公開一時停止扱いなので、現状は手動構築前提で考えるのが無難です

自由度の代わりに増える作業 🧰

Java（JDK）の管理、サーバー本体の取得、起動スクリプト、systemd登録
ポート設定（例：Javaは25565）やファイアウォール調整
自動アップデートの設計、バックアップ設計、障害時の切り戻し

こんな人ほど手動が向きます ✅

いずれプラグイン/ MODの相性を詰めたい
サーバー設定を理解して、トラブル耐性を上げたい
長期運用を前提に、保守しやすい構成にしたい

「常時稼働が不要」な人：必要なときだけ起動する選択肢

「毎日は遊ばない」「週末だけ」なら、“VPS＝常時稼働”にこだわる必要はありません。
ただし、VPSは止めても契約中は基本料金が発生するため、コスト最適化の考え方が重要です。

選び方のコツ 💡

まずは無料お試し（クレカ）で“自分の回線・端末・人数”で快適か確認
短期イベント運用なら、必要期間だけ契約して、終わったら解約（最低利用期間の条件は要確認）
「たまに重い」程度なら、スケールアップで上げる（IPを引き継げるため、案内や設定がラク）

“必要なときだけ起動”を現実的にする運用

遊ぶ前：サーバー起動 → 動作確認 → 参加者に案内
遊んだ後：停止（＋ワールドのバックアップ）
- ✅ セキュリティ面では、止めている間のリスクを下げやすい
- ⚠️ 料金が“停止＝ゼロ”になるわけではない点は注意

さくらのVPS 公式サイト

まず確認：Java版と統合版の違い（参加端末・クロスプレイ・必要ポート）

最初にここを間違えると、「友だちが入れない」「想定より重い」「やり直し」になりがちです。
結論はシンプルで、遊ぶ端末が“どっち向きか”で決まります。

PC中心・MODやプラグイン重視 → Java版
Switch/PS/スマホ/Windows版（統合版）中心 → 統合版（Bedrock）

Java版：PC中心／MOD・プラグインの自由度が高い

Java版が向いているケース

参加者が主に PC（Java Edition）
MOD を入れたい（Forge/NeoForge など）
プラグインで軽量化・管理をしたい（Paper/Spigot 系）
サーバー設定を細かく触って、安定運用を目指したい

特徴（初心者が押さえるポイント）

自由度が高い反面、構成次第で重くなる
- MODを増やすほど、必要メモリやCPUが上がりやすいです。
運用しやすい“定番”がある
- 例：バニラ → Paper系（軽量化）→ 必要ならプラグイン追加、の順が安全。

必要ポート（まずはここだけ覚える）

基本：25565 / TCP（デフォルト）
- 友だちに案内するときは「IPアドレス（＋必要ならポート）」の形になります。
- 例：xxx.xxx.xxx.xxx（※25565ならポート省略で通じやすい）

💡補足：25565は“よく使われる既定ポート”なので、公開運用だとスキャンされやすいことがあります。身内サーバーでも、ホワイトリストや権限管理は早めに入れておくと安心です。

統合版：Switch/PS/スマホ中心／UDPやフレンド周りの注意点

統合版が向いているケース

参加者が Switch / PlayStation / スマホ / タブレット / Windows版（統合版）
「同じ統合版同士」でクロスプレイしたい

特徴（初心者がつまずきやすい点）

通信が UDP 前提（Java版はTCPが基本）
- “ポートは開けたのに入れない”の原因が、TCP/UDPの取り違えであることが多いです。
コンソール勢は参加方法にクセがある
- Switch/PSは「フレンド参加」や「サーバー追加」が絡み、環境によって手間が増えます。
- まずは Windows/スマホから接続できるか で切り分けると楽です。

必要ポート（統合版の基本セット）

基本：19132 / UDP（IPv4）
可能なら：19133 / UDP（IPv6）
- IPv6を使わない運用なら必須ではありませんが、環境によって差が出るので“開けておく”判断もあります。

重要：統合版スタートアップスクリプトの提供状況と代替案

ここが「さくらのVPS × マイクラ」で一番大事な注意点です。

さくらのVPSのスタートアップスクリプトは、Java版は利用可能
統合版（Minecraft Server 統合版）のスタートアップスクリプトは、公開が一時停止中（2024年12月19日〜）

つまり、統合版をさくらのVPSでやるなら、基本的に以下のどちらかになります。

代替案1：統合版（Bedrock Dedicated Server）を手動構築する（王道）

「統合版で遊ぶ」目的がブレないなら、これが正攻法です。
手動構築のイメージは次の通り。

サーバーにBDSを導入（公式手順に沿う）
server.properties で設定
19132/19133（UDP） をファイアウォールで許可
起動・停止・自動起動（必要なら）を整える

メリット

統合版として“正しい形”で運用できる
スクリプト再開待ちに依存しない

デメリット

初心者は「Linux操作＋UDP開放」で詰まりやすい
- ただし、手順通りにやれば再現性は高いです。

代替案2：Java版サーバー＋（非公式の）クロスプレイ構成で“統合版勢も参加”させる

「サーバー運用はJava版が得意。でも統合版勢も混ぜたい」という発想です。
代表例として、Javaサーバー側に追加コンポーネント（例：Geyser系）を入れて、統合版クライアントを参加させます。

メリット

さくらのVPSの“Java版スタートアップスクリプト”を活かしやすい
Paper系で軽量化・管理がしやすい

デメリット（ここ大事）

公式の組み合わせではないため、アップデートで動かなくなる可能性がある
MODや一部挙動は相性が出る
Switch/PS側の参加手順は環境依存になりやすい

迷ったときの早見表（最初の判断だけはこれでOK）

スクロールできます

判断軸	Java版がおすすめ	統合版がおすすめ
参加端末	PC（Java Edition）中心	Switch/PS/スマホ/統合版Windows中心
カスタマイズ	MOD・プラグインを自由に使いたい	なるべく素直に統合版で遊びたい
運用難度	低〜中（スクリプト活用で下げやすい）	中〜高（現状は手動構築が基本）
通信の基本	25565/TCP	19132/19133/UDP

さくらのVPS 公式サイト

失敗しないプラン選び（人数×遊び方×重さで決める）

さくらのVPSはプランが明確なので、マイクラ用途なら 「同時接続人数」×「遊び方（負荷）」×「後から伸ばす前提」 で決めるのが最短です。

初心者向けに、まずはこの3ステップで考えると失敗しにくいです。

ステップ1：リージョン（石狩/東京/大阪）を決める
参加者の体感（遅延）は立地の影響が出ます。
日本の友だち中心なら、ざっくり 東日本寄り→東京／西日本寄り→大阪 が分かりやすいです。
ステップ2：最初は“余裕が少しある”メモリから始める
マイクラはアップデートで重くなりやすいので、最初からギリギリを狙わないのがコツです。
ステップ3：足りなくなったらスケールアップで上げる
「まず動かす → 実測 → 必要なら上げる」が一番コスパが安定します ✅

参考として、公式の基本スペックと月額（すべて税込）をまとめます。

スクロールできます

プラン	CPU	メモリ	SSD	月額（石狩）	月額（東京）	月額（大阪）
512MB	仮想1Core	512MB	25GB（50GBへ変更可）	643円	698円	671円
1G	仮想2Core	1GB	50GB（100GBへ変更可）	880円	990円	935円
2G	仮想3Core	2GB	100GB（200GBへ変更可）	1,738円	1,958円	1,848円
4G	仮想4Core	4GB	200GB（400GBへ変更可）	3,520円	3,960円	3,740円
8G	仮想6Core	8GB	400GB（800GBへ変更可）	7,040円	7,920円	7,480円
16G	仮想8Core	16GB	800GB（1600GBへ変更可）	13,200円	15,400円	14,300円
32G	仮想10Core	32GB	1600GB（3200GBへ変更可）	26,400円	30,800円	28,600円

💡年額（12ヶ月一括）にすると、“月額約1ヶ月分”お得になる設計です。長期運用なら最初から年額も検討価値ありです。

バニラ少人数／建築メイン／軽量設定の目安

結論から言うと、マイクラ目的なら まず2G以上 を起点にするのが安全です。
1Gでも動くケースはありますが、バージョンや設定次第でメモリが厳しくなりやすく、初心者ほど「落ちる/重い」になりがちです。

目安（Java版・バニラ中心）

1〜3人 / 建築メイン（軽量設定）：2G
4〜8人 / 探索もする（標準設定）：4G
9〜15人 / 拠点複数・自動化多め：8G
それ以上 / 安定最優先：16G〜

「軽量設定」で効きやすいのはこのあたりです（お金をかける前に試す価値あり）👇

描画距離・シミュレーション距離を下げる
常時稼働の装置（トラップ・自動化）を増やしすぎない
生成が重いときは、探索を控える or 先にワールドを作っておく

MOD多め／探索多め／プラグイン導入時の考え方

負荷が跳ね上がる代表が 「新規チャンク生成（探索）」 と 「MOD構成」 です。
ここに当てはまるほど、最初から一段上を選ぶのが結果的に安く済みます。

MOD・探索が重くなるパターン

みんなで遠くまで探索して、チャンク生成が頻発する
大規模な建築＋装置＋MOBが密集する
MODパック（要素が多い）を入れる
同時接続が増え、常に誰かが動き回っている

ざっくり指針（初心者向け）

軽めのプラグイン（Paper系）で快適化したい → 4Gからが安心
MOD少なめ（軽量） → 4G〜8Gを目安に“実測で判断”
MOD多め / 大型パック → 8G以上を前提に（安定優先なら16G）

✅ポイント：「プラグイン＝軽くなることが多い」「MOD＝重くなることが多い」
もちろん例外はありますが、初心者はこの前提で選ぶと事故が減ります。

ラグが出たら「増強」すべき指標（CPU・メモリ・ディスク・回線）

ラグの原因を雑に「スペック不足」と決めつけると、無駄に上位プランへ行きがちです。
まずは症状から当たりを付けると、最小コストで改善しやすいです。

CPUを疑うサイン

人が動くと急に重い（探索・戦闘・MOB密集で悪化）
TPSが落ちる、処理落ちっぽい
➡️ 対策：設定の軽量化 → サーバーソフト最適化 → それでもダメなら上位プラン

メモリを疑うサイン

しばらく遊ぶと急にカクつく／止まる（“固まる”感）
MOD追加後に不安定になる
➡️ 対策：MOD/設定の整理 → 余裕あるプランへ（2G→4G、4G→8G など）

ディスクを疑うサイン

セーブ時・ログイン時に引っかかる感じが強い
ワールドが大きく、バックアップや保存に時間がかかる
➡️ 対策：空き容量確保／バックアップ設計 → 必要ならストレージ増量（後述）

回線・ネットワークを疑うサイン

特定の人だけが入れない／時間帯で切れる
位置ズレ（ワープ）やタイムアウトが多い
➡️ 対策：ポート/ファイアウォール確認 → 参加者側回線も含めて切り分け

後から変更できる範囲・変更時の注意

さくらのVPSは「後で伸ばす」前提で選べるのが強みです。
ただし、変更にはルールがあるので、ここだけ押さえておくと安心です。

プラン変更（スケールアップ）でできること

上位プランへ変更できる（スペック不足に対応）
IPアドレスは引き継ぎなので、友だちへの案内やDNSが崩れにくい ✅
ストレージだけ増やす（プラン据え置き）選択もできる

スケールアップ時の注意点（初心者が詰まりやすい）

ディスク容量が少ないプランへの変更は不可（実質“戻す”のは難しい）
別リージョン（石狩↔東京↔大阪）への変更は不可
お試し期間中はスケールアップ不可
申込当日はスケールアップ不可
先のプランの在庫がないと、希望通りに上げられないことがある

ストレージを増やすだけの方法（容量不足が心配な人向け）

「容量は増やしたいけど月額は増やしたくない」場合、ストレージ変更オプションがあります。
月額はそのままで、一度だけ変更手数料が発生する方式です。

例：

2G：SSD 100GB → 200GB（手数料 2,200円）
4G：SSD 200GB → 400GB（手数料 4,400円）
8G：SSD 400GB → 800GB（手数料 8,800円）

🎯ワールドがどんどん大きくなる運用（長期マルチ）なら、最初から「容量も伸ばす前提」で考えると安心です。

バックアップ重視ならNFSという選択もある

VPSの外に追加ストレージを持つ方式で、バックアップ用途に向きます。
ただし、ストレージ変更オプションとは別料金です（容量とコストのバランスで選びます）。

さくらのVPS 公式サイト

事前準備チェックリスト（10分で確認）

ここを先に固めておくと、構築手順に入ってからの「詰まり」「やり直し」が激減します。
チェックは“完璧”でなくてOK。まずは 動かすための最低条件 を揃えましょう。

必要なもの：アカウント／VPS契約／OS／接続手段（SSH等）

1）まず決める（1分）

□ Java版 / 統合版（Bedrock）どっちで遊ぶか
- 参加端末がPC中心 → Java版
- Switch/PS/スマホ中心 → 統合版
□ ポートをメモ（あとで開放設定に使う）
- Java版：25565（TCP）
- 統合版：19132（UDP）（必要に応じて19133も）

※統合版は、さくらのVPSの「統合版スタートアップスクリプト」が公開一時停止中なので、基本は“手動構築”前提になります（Java版は利用可）。

2）アカウント＆契約（3分）

□ さくらインターネットの会員ID（ログインできる状態）
□ 支払い手段（クレカ等。申し込み時に詰まりがちなポイント）
□ リージョン（参加者の多い地域に寄せる：東京/大阪/石狩など）
□ プラン（この段階では“最小で動く”より“少し余裕”を優先）

3）OS選び（1分）

□ スタートアップスクリプトで作るなら、対応OSを選ぶ
- Ubuntu 24.04 / 22.04 が対象（Java版/統合版のスクリプトで共通）
□ 手動構築でも、初心者は Ubuntu LTS が無難（情報量が多く迷いにくい）

4）接続手段（SSH）（5分）

□ SSHでVPSへ接続できる（IPアドレス／ユーザー名／認証方法を確認）
□ 使う端末に合わせて“接続手段”を決める
- Windows：PowerShell/Windows Terminal、またはTera Term等
- Mac/Linux：ターミナル（標準でOK）
□ ファイル転送の手段（どれか1つでOK）
- SFTP（GUIならFileZilla等）
- コマンドなら scp（慣れてきたら便利）

推奨：秘密鍵ログイン・バックアップ方針・運用ルール（身内/公開）

セキュリティ（最初にやると後がラク）

□ 秘密鍵（公開鍵）ログインにする（パスワード認証より安全）
□ OS更新の方針を決める
- 「Minecraftを優先して安定運用」→ アプデのタイミングを管理する
- 「常に最新版寄り」→ 事前バックアップをルーチン化する
□ 公開運用の予定があるなら、最初からこれも意識
- ホワイトリスト
- OP権限の配布ルール
- ログの保管（荒らし対策・切り分けに効く）

バックアップ（“後悔しがち”なので先に決める）

□ バックアップ対象を決める（最低限でOK）
- ワールドデータ（最重要）
- 設定ファイル（server.properties等）
□ バックアップの頻度（例）
- 身内：週1＋大型作業前
- 公開：毎日＋更新前（できれば世代管理）
□ 保管先
- VPS内だけに置かない（できれば手元PC/別ストレージにも複製）

注意：さくらのVPSのJava版スタートアップスクリプトは、OS再起動で自動アップデートが走る設計です。
“更新前にバックアップ”を習慣にしておくと、事故が起きても復旧しやすいです。

運用ルール（身内と公開で分けて考える）

身内サーバー（おすすめ）
- □ IPは参加者にだけ共有
- □ 参加者の“最低限のマナー”だけ決める（破壊・持ち逃げ・荒らし対応）
公開サーバー（難易度UP）
- □ 利用規約（荒らし/チート/暴言/課金要素の扱い）
- □ 通報・BAN対応の基準
- □ 連絡窓口（Discord等）とログ運用

規約・EULAの確認ポイント（トラブル回避）

「知らなかった」で揉めやすいのがここです。難しく感じても、確認ポイントだけ押さえるのがコツ。

Minecraft側（最低限ここを見る）

□ Minecraft EULA（エンドユーザーライセンス）
- Java版サーバーは初回起動時に eula.txt が作られ、同意が必要になります（同意しないと起動できません）
□ Usage Guidelines / Commercial Usage（商用利用）系のルール
- 公開サーバーで寄付や特典を扱うなら、“許される範囲”を必ず確認
- 迷う場合は「課金要素なし」で運用開始が安全

さくらのVPS側（サービス停止リスクを避ける）

□ さくらのVPSの約款（禁止事項・責任範囲の確認）
- 不正行為を目的とした利用や迷惑行為に該当すると判断されると、制限が入る可能性があります
□ サーバー公開時は、特に次の運用を徹底
- 管理者権限（root/op）の取り扱い
- 脆弱性対策（OS更新・不要サービス停止）
- 公開ポートの最小化（必要なものだけ開ける）

さくらのVPS 公式サイト

最短：スタートアップスクリプトでJava版サーバーを作る手順

サーバー作成：OS選択→スクリプト選択→バージョン指定のコツ

さくらのVPSには、Minecraft（Java版）用のスタートアップスクリプトが用意されています。Ubuntuを選んでスクリプトを指定するだけで、サーバー一式（server.jar／設定ファイル／自動起動設定など）が作られる想定です。

手順は大きく5ステップです。

サーバー新規追加（またはOS再インストール）を開く
OSはUbuntu（24.04 / 22.04）を選ぶ
スタートアップスクリプトを選択 →「Minecraft Server（Java版）」を選ぶ
Minecraftのバージョンを選ぶ（後述の「固定／更新方針」を先に決めると迷いません）
注意書きに同意（規約・バージョン選択の注意にチェック）→ 申込確定 → 起動

インストールが始まったら、コントロールパネルのネットワーク欄で 「ネットワーク情報-IPv4」 を控えておきます（このIPをクライアント側で使います）。

「バージョン固定／更新方針」を最初に決める

バージョン選びは「みんなが遊ぶクライアント」と「更新のしやすさ」で決めるのがコツです。特にJava版は、サーバーとクライアントのバージョン差で入れないことがよくあります。

おすすめの決め方（迷ったらこれ）

スクロールできます

決めたいこと	まずの方針
みんなが同じ版で遊べる？	参加者のMinecraft（Java）のバージョンを先に揃える
新要素を早く使いたい？	最新寄り（ただし不具合・互換性の変化も受ける）
安定優先？	大きく動かさない（更新はまとめて、事前バックアップ必須）

重要な落とし穴（運用方針に直結）

さくらのVPSのこの構成は、OS起動時にゲームサーバーを自動更新する仕組みが案内されています。
→ 「完全に固定したい」場合は、再起動のタイミング＝更新のタイミングになり得るため、運用を工夫する必要があります（例：大きな更新前はバックアップ→再起動、検証用サーバーで先に試す、など）。
さらに、1.20.5以降へ自動更新される際、Javaが21未満だと起動しない注意点があります。
→ 更新が絡むタイミングでは、Javaのバージョンもセットで確認する癖をつけると安全です。

初回セットアップ完了の確認（どこを見れば安心か）

「起動したけど本当にできてる？」を短時間で判断するなら、次の3点を見るのが確実です。

A. ファイルが生成されているか（最低ライン）

SSHで接続できたら、Minecraftの配置先として案内されているディレクトリに
- server.jar
- server.properties
- logs/
- eula.txt
  などがあるかを確認します。

B. サービスが動いているか（実運用ライン）

systemdでMinecraftサーバーがデーモン起動する構成になっている想定なので、サービス状態を確認します。
- 「動作中」になっていれば、だいたい“参加テストへ進んでOK”です。

C. ログにエラーが出ていないか（トラブル先回り）

logs/ 配下やサービスログを見て、致命的エラー（起動失敗、Java不足、EULA未同意など）が出ていないかを確認します。

ポイント：初回はワールド生成でCPU/ディスクに負荷がかかり、すぐに軽快にならないことがあります。まずは「サービス稼働」「ログ正常」「参加できる」の順で確認すると迷いません。

参加方法：IPアドレス確認→クライアントから追加→接続テスト

参加手順はシンプルですが、詰まりやすいポイントがいくつかあります。

Minecraft（Java版）を起動
マルチプレイ → サーバーを追加
サーバーアドレスに、控えた IPv4 を入力
- 通常は IPアドレス（必要なら IPアドレス:25565 まで指定）
サーバーを選択 → 接続

接続テストで引っかかる典型例

バージョン不一致：サーバー側に合わせてクライアントを切り替える
通信が通らない：
- コントロールパネルのパケットフィルターを使っている場合、25565/TCPを許可しているか
- OS側のファイアウォール（ufw/iptables等）で塞がっていないか
名前解決ではなくIP直打ち：まずはDNSを使わずIPでOK（切り分けが速い）

初期設定：管理者権限・難易度・ワールド設定・ログの見方

最初に触る設定は、ほぼ /opt/minecraft/server.properties にまとまります（編集後は再起動で反映される運用が前提になりやすいです）。

よく使う設定（まずここだけでOK）

難易度：difficulty=peaceful|easy|normal|hard
ゲームモード：gamemode=survival|creative|adventure|spectator
最大人数：max-players=10 など
視界距離：view-distance（重いと感じたら下げると効きやすい）
PVP：pvp=true|false
ワールド名：level-name=world（ワールド差し替え時に使う）

管理者（OP）周りの考え方

OPは ops.json に保存されます。
ただし、JSON編集はミスると読み込みエラーになり得るので、初心者はまずは
- 身内だけで非公開運用
- ホワイトリストを後から段階的に強化
  が安全です。

ログの見方（困ったらここ）

実行ログ：/opt/minecraft/logs/
クラッシュ情報：crash-reports/
見るべき観点はこの3つだけでOKです👇
- 起動直後に “Done” 相当の起動完了ログが出ているか
- バージョン更新直後に Java不足のエラーが出ていないか
- プレイヤー接続時に 認証・通信エラーが出ていないか

最低限の安全対策：ホワイトリスト・権限設計・公開しない設定

「最低限」だけでもやると、荒らし・事故・トラブルをかなり減らせます。

1) 公開しない（検索されない状態を維持）

サーバーIPを不特定多数に出さない
Discord等でも招待制にする
SNSにIP直書きしない（これが一番危険）

2) ホワイトリスト運用を基本にする

whitelist.json を使い、参加者を限定
server.properties 側もホワイトリスト前提に寄せる（設定項目は環境により異なるため、変更後は必ず接続テスト）

3) 権限は「最小限」を徹底

OP付与は必要な人だけ
コマンドブロックなど強い機能は、必要になるまで無効のまま

4) パケットフィルターを使うなら「必要ポートだけ」

さくらのVPSのパケットフィルター機能を使う場合は
- SSH（22）
- Minecraft（通常 25565/TCP）
  のように、必要なものだけ許可が基本です。
送信元IPを絞れるなら、自宅の固定IPなどに限定するとさらに強固になります。

さくらのVPS 公式サイト

手動構築（自由度重視）：Ubuntuに自分で入れる方法

スタートアップスクリプトに頼らず、バージョン固定・Paper化・MOD化・Bedrock化などを「自分の方針」で管理したい人向けです。
その分、アップデート／バックアップ／セキュリティも自分で面倒を見る必要があります。

Java版（バニラ／Paper系）を手動で構築する

事前に決めること（迷子防止）

サーバーの種類：バニラ or Paper
対応バージョン：クライアントと合わせる（例：1.20.6で遊ぶならサーバーも同じ系統）
更新方針：「固定」（安定）or 「追従」（最新）
公開範囲：身内のみ（推奨）or 公開（対策必須）

Java導入とバージョンの選び方

Minecraft側の要件が変わるので、まずここが最重要です。

スクロールできます

遊ぶMinecraftの目安	サーバーで必要になりやすいJava
1.20.4以前が中心	Java 17系が基本
1.20.5以降が中心	Java 21系が基本

Ubuntuでの例（Java 21を入れる）：

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

Java 17にしたい場合：

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

✅ ポイント

迷ったら「遊びたいマイクラのバージョンに合わせる」が正解です。
Javaを入れ替えるときは、起動スクリプトやsystemdが参照する java がどれかも確認します（which java）。

サーバーファイル配置→初回起動→EULA同意→再起動

1) 専用ユーザーと設置場所を作る（推奨）

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

2) サーバー本体（server.jar）を置く

公式の「Minecraft Server Download」ページから server.jar を取得し、/opt/minecraft/server に配置します。
（ブラウザでダウンロード → SFTP/WinSCP などでアップロードでもOK）

例（作業ディレクトリへ移動）：

sudo -u minecraft bash -lc 'cd /opt/minecraft/server && ls -la'

3) 初回起動（ワールド生成）

メモリはVPSのRAMに合わせて調整（目安：RAMの6〜7割を上限に）。

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

すると eula.txt が生成されます。

4) EULAに同意して再起動

sudo -u minecraft bash -lc "sed -i 's/eula=false/eula=true/' /opt/minecraft/server/eula.txt"
sudo -u minecraft bash -lc 'cd /opt/minecraft/server && java -Xms1G -Xmx2G -jar server.jar nogui'

⚠️ 公開するなら最低限ここもチェック

server.properties の online-mode=true（なりすまし対策の基本）
ファイアウォール：Java版の既定ポートは 25565/tcp（必要なら変更）

常駐化（systemd／screen等）と自動起動

systemd（おすすめ：再起動やクラッシュ復帰に強い）

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

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

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

[Install]
WantedBy=multi-user.target

有効化・起動：

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

ログ確認：

sudo journalctl -u minecraft -f

screen/tmux（手軽だけど自動復帰は弱め）

「落ちたら手動で上げ直す」運用ならアリ、くらいの位置づけです。

✅ ついでにやると楽になる運用

ワールドフォルダ（world/）を定期バックアップ（圧縮＋世代管理）
バージョンアップ前は必ずバックアップ→テスト起動の順

MODサーバー（Forge/NeoForge）で遊ぶ

MODサーバーは「Minecraft本体バージョン」「ローダー（Forge/NeoForge）」「MODの組み合わせ」の整合がすべてです。

導入の流れ（ざっくり）

遊ぶマイクラのバージョンを固定
Forge/NeoForgeのインストーラを入手
サーバー側をセットアップ
MODと設定ファイルを配置
クライアント側も同じMOD構成に合わせる

起動は、生成される run.sh / start.sh を使う形式が多いです。

MOD配布の考え方（クライアントとの整合・事故防止）

✅ 事故が起きにくい運用ルール

MODパックとして配る（同じzip/同じバージョンを全員が使う）
「サーバー専用MOD」と「クライアント必須MOD」を分けて説明する
更新は一気に上げない（1つずつ／原因切り分け可能に）
設定ファイル（config/）も含めて配布・同期する

⚠️ よくあるトラブル

MODの依存関係不足（前提MODが入ってない）
同じMODでも版が違う（Minecraft側の版違いも含む）
サーバーは起動するのに、参加者が弾かれる（クライアント側不一致）

更新で詰まるポイント（依存関係・ワールド破損対策）

✅ 詰まりにくい手順テンプレ

worldバックアップ
サーバー側でMODを更新（最小単位）
起動してログ確認（logs/latest.log / crash-reports/）
問題なければ参加者へ配布 → 全員で同期
大型更新は「別ディレクトリに新環境」→移行が安全

⚠️ MOD更新で怖いのは「ワールド破損」よりも

生成物やID変更による不整合
前提ライブラリ更新の連鎖
が原因で、起動しない・クラッシュし続けるケースです。
なので、世代バックアップ＋小分け更新が最強です。

統合版（Bedrock）を手動で構築する

BedrockはJavaとは別物です（server.jarではありません）。
公式のBedrock Dedicated Server（BDS）を使います。

ざっくり手順（Ubuntu）

公式配布のzipをダウンロードして展開
初回起動（必要なフォルダが作られる）
server.properties を調整
ポート開放（UDP）
allowlist等を設定して身内運用

必要ポート（UDP）と疎通確認

Bedrockの既定ポートは 19132（IPv4）／19133（IPv6） です。
UFW例（UDPを明示してミス防止）：

sudo ufw allow 19132/udp
sudo ufw allow 19133/udp
sudo ufw reload
sudo ufw status

✅ 疎通確認のコツ

参加端末から「サーバー追加」で IPアドレス＋ポートを指定
“Outdated Client/Server” が出たら サーバーとクライアントの版ズレが原因のことが多いです

権限・許可リスト（allowlist等）の基本

allowlist（身内運用の基本）

server.properties の allow-list=true で、許可した人だけ入れる運用にできます
追加は /allowlist add <GamerTag> が簡単
ファイル編集で変えた場合は /allowlist reload を使います

管理者権限（オペレーター）

コンソールから op <playername> で権限付与、deop <playername> で剥奪できます

さくらのVPS 公式サイト

ネットワーク設定：つながらない原因の9割はここ

VPSは（自宅回線と違って）基本的にグローバルIPが最初から付いているので、やることはシンプルです。

① サーバープロセスが待ち受けている（起動している）
② 通すべきポートが開いている（さくら側 or OS側）
③ クライアントが正しいIP/ポート/バージョンで接続している

この3点を順番に潰せば、ほとんど解決します。

開けるべきポート（Java／統合版）と最小ルール

まずは「最小構成」を押さえましょう。開けすぎるとリスクが増え、閉じすぎると繋がりません。

最小構成（身内サーバー想定）

SSH（管理用）：22/TCP
- できれば 自分の接続元IPだけ許可（全開放は避ける）
Minecraft
- Java版：25565/TCP（標準）
- 統合版（Bedrock）：19132（IPv4）／19133（IPv6）
  - server.properties の server-port / server-portv6 に依存（変更しているなら、その値）

追加で開ける可能性があるもの（必要なときだけ）

RCON：リモート管理を使う場合（Java版で有効化したときのみ）
Dynmap等のWeb表示：プラグインのWebポート（導入した場合のみ）
複数サーバー：同一VPSで複数立てるなら、サーバーごとに別ポートが必要

ありがちなミス

Java版なのに UDPだけ開けている（→ Javaは基本TCP）
Bedrockの server-port を変えたのに 開けるポートを変えていない
ポートを変えたのに、クライアント側で「IP:ポート」を指定していない
server.properties の server-ip を変に埋めて、特定のIPにしかbindできていない（基本は空欄推奨）

パケットフィルタとOS側FW（ufw等）の役割分担

「さくらのパケットフィルター」と「Ubuntu側のファイアウォール（ufwなど）」は、どちらも入口を絞る仕組みです。
ただし、二重に設定すると“開けたつもりなのに閉じてる”が起きやすいので、考え方を整理しておきます。

まず知っておくべき仕様（さくら側）

さくらのパケットフィルターは IPv4にのみ適用
→ IPv6通信は“全て許可”扱いになる点が重要です
NIC1にのみ適用、かつステートレス動作（戻り通信は別枠で許可される仕様）
OS側FWと動作が重複する可能性があるため、マニュアル上も注意が書かれています

役割分担のおすすめ（初心者向け）

「どちらか片方を主に使う」ほうが事故りにくいです。

パターンA：さくら側（パケットフィルター）を主に使う
- メリット：コントロールパネルで完結、設定が簡単
- 注意：IPv6は守れない（＝OS側でIPv6制御したいなら不向き）
- 向いている：身内運用／IPv4前提／とにかく早く繋げたい
パターンB：OS側FW（ufw）を主に使う
- メリット：IPv4/IPv6や細かい条件をまとめて制御しやすい
- 注意：設定ミスるとSSHまで閉じて詰むので、変更前に22/TCP許可を確認
- 向いている：公開運用／IPv6も含めて管理したい／後々拡張する予定

迷ったときの結論

“まず動かす”なら：パケットフィルターで必要ポートだけ許可 → 動作確認
“公開や長期運用”なら：OS側FWに寄せる（IPv6も含めて整理できる）

外部からの疎通チェック手順（切り分けテンプレ）

「繋がらない」を最短で切り分けるテンプレです。上から順にやるのがコツです。

0）前提情報をメモ（ブレ防止）

サーバーの グローバルIPv4
接続したい種類：Java / Bedrock
ポート：Java=25565、Bedrock=19132/19133（変更していればその値）
パケットフィルター：有効？無効？
ufw：有効？無効？

1）サーバーが“待ち受け”できているか（サーバー内で確認）

Java版（TCP）例

sudo ss -lntp | grep 25565

Bedrock（ポート確認の基本は ss とログ）

sudo ss -lnup | grep 19132

ここで何も出ない場合は、ネットワーク以前に サーバー起動・設定・クラッシュが原因です。
まずサービス状態やログ（journalctl、logs/latest.log、crash-reports）を見に行きます。

2）同一サーバー内でのローカル確認（“起動はしてる？”の裏取り）

Java版ならTCPの疎通が簡単です。

nc -vz 127.0.0.1 25565

OKなら「プロセスは生きていて待ち受けもしている」可能性が高い
NGなら「起動失敗」「別ポートで起動」「bind先が違う」などを疑います

3）フィルター系（ここが“9割”）

次の2つのどちらで止めているかを確認します。

A. さくら側（パケットフィルター）

25565（カスタム）を許可しているか
Bedrockなら 19132/19133（カスタム）を許可しているか
そもそも「パケットフィルターを利用しない」になっていないか／逆に有効のままになっていないか

B. OS側（ufw）

状態確認：

sudo ufw status verbose

許可（例）：

# Java
sudo ufw allow 25565/tcp

# Bedrock（迷ったらUDP指定で）
sudo ufw allow 19132/udp
sudo ufw allow 19133/udp

sudo ufw reload

※ ufwの設定を触る前に、念のためSSHも確認しておくと安全です。

sudo ufw allow 22/tcp

4）外部回線からの接続テスト（“本当に外から入れる？”）

VPSは自宅ルーターの「ポート開放」概念が基本不要ですが、外部からの到達性を確認するには外部回線で試すのが早いです。

おすすめの方法：

スマホのテザリングに切り替えて接続（同一LANの影響を排除）
友人に「IP（必要ならIP:ポート）で追加」してもらって接続テスト

結果で分岐：

外部から入れる → クライアント側（バージョン不一致等）を疑う
外部から入れない → フィルター設定（さくら側/OS側）か、サーバーが待ち受けていない

5）それでもダメなときの“最後の当たり”

別ポートで起動していないか（server.properties を再確認）
server-ip を指定していないか（空欄が基本）
Bedrockで enable-lan-visibility の挙動や、複数サーバー運用によるポート競合
パケットフィルター＋ufwの 二重設定で食い違っている（どちらか片方に寄せて再テスト）

さくらのVPS 公式サイト

セキュリティ：荒らし対策・乗っ取り対策を“先に”やる

VPSのIPは、公開した瞬間から自動スキャン（総当たりログイン等）の対象になりがちです。
「サーバーが完成してから対策」ではなく、最初の30分で“入口”を固めるのが一番ラクで安全です。

SSH防御：鍵ログイン／root制限／不要ポート遮断

1) まず“管理できる一般ユーザー”を確保する（最重要）

いきなりrootを閉じると、自分が入れなくなる事故が起きます。最初にこれを確認します。

一般ユーザーでSSHログインできる
sudo で管理コマンドが実行できる（権限昇格できる）

この2つができたら、次へ進みます。

2) 鍵ログインに寄せて、パスワードを閉じる

最も効果が大きいのがここです。

公開鍵認証（鍵ログイン）を使う
パスワード認証を無効化する（総当たりをほぼ無力化）
可能なら秘密鍵はパスフレーズ付きで保管

設定例（方針だけ覚えればOK）

PasswordAuthentication no
PubkeyAuthentication yes

3) rootログインを禁止する

rootは狙われやすく、突破されると即アウトです。

PermitRootLogin no

※「rootが必要な作業」は、普段は一般ユーザー → sudo で行う形にしておくと安全です。

4) 入口（ポート）を最小化する

「開けるのは必要なものだけ」が基本です。

SSH：22/TCP（管理用）
Minecraft：Java 25565/TCP、統合版 19132/19133（UDP）など必要分だけ

公開運用なら、SSHはさらに絞ると強いです👇

自宅の固定IPがある → 接続元IPを限定
ない → せめて鍵認証＋root禁止＋パスワード禁止は必須

5) さくら側とOS側の二重管理に注意

さくらの「パケットフィルター」は便利ですが、注意点があります。

IPv4のみ対象で、IPv6は“全許可”扱いになりやすい
OS側のFW（ufw等）と設定が重複して、開けたつもりで閉じている事故が起きやすい

運用の考え方（初心者向け）

まず動かす：パケットフィルター中心でもOK
公開・長期運用：OS側FW（ufw）中心に寄せると整理しやすい

6) 追加で効く“守り”（余裕があれば）

fail2ban 等でSSHの不正アクセスを自動ブロック
セキュリティアップデートの適用方針を決める（自動 or 定期メンテ日）
使わないサービスは止める（“動いているもの”が攻撃面になる）

マイクラ側防御：ホワイトリスト／権限最小化／管理コマンド運用

Minecraftは「ゲームだから安全」ではなく、公開すると荒らしの入口になります。
やることはシンプルで、“入れる人を限定”＋“権限を絞る”です。

1) まずホワイトリスト（許可制）を前提にする

身内サーバーなら、これだけで荒らし被害の多くを防げます。

Java版：whitelist を有効化（white-list=true など）
統合版：allow-list を有効化（allow-list=true）

運用のコツ

追加・削除は コマンドで管理（ファイル直編集はミスしやすい）
「招待された人だけが入れる」状態を基本にする

2) OP（管理者権限）は“必要最小限”にする

OPは強力です。増やすほど事故も増えます。

OPは管理者1〜2人に限定
“便利だから”で全員に付けない
新規参加者のデフォルト権限は低め（統合版なら default-player-permission-level で設計可能）

3) 危険な機能は、必要になるまでオフ

「便利＝危険」になりやすい機能は、最初は閉じておくのが安全です。

RCON（遠隔管理）：使わないなら無効
- 使うなら 強固なパスワード＋外部公開しない設計
コマンドブロック：公開や半公開なら慎重に
ルール違反対策：キック/バンの運用基準を決めておく

4) “なりすまし”を避ける基本

Java版で外部公開するなら、オンライン認証（online-mode）を有効にするのが基本
（※オフライン運用は事情がない限り避けたほうが安全）

5) ログを“見れる状態”にしておく

トラブルの8割はログで切り分けできます。

サーバーログ（接続・エラー・荒らしの痕跡）
OSログ（SSHの不正試行など）

「誰が・いつ・何をしたか」を追えるだけで、対応が一気に楽になります。

公開サーバーにする場合の追加対策（ログ・通報・ルール整備）

公開は難易度が一段上がります。技術だけでなく運用設計が必要です。

1) ルールと対応フローを先に作る

最低限、これだけ決めると揉めにくいです。

禁止行為（荒らし、チート、暴言、グリーフ等）
処分（警告→一時BAN→永久BAN など）
証拠（ログ・スクショ・動画）の扱い
通報窓口（Discord等）と返信方針

2) 記録の取り方（“あとで困らない”）

ログの保存期間（例：7日/30日）
バックアップの世代管理（例：日次＋週次＋更新前）
重大トラブル時の復旧手順（戻す順番、告知テンプレ）

3) 入口を強める（公開前提の現実策）

参加導線を「いきなり誰でも入れる」形にしない
例：申請制、招待制、Discord認証など
BOT的な接続が増えたら、接続制限や対策プラグイン等を検討（Paper系など）

4) “安全に公開するなら”おすすめの考え方

最初は 小さく公開（テスト公開→段階的に拡大）
管理者が対応できる規模を超えない
ルール違反は“例外なく淡々と”処理（治安が安定しやすい）

さくらのVPS 公式サイト

バックアップと復元（最重要）：ワールドを守る運用設計

「さくらのVPS」は標準・オプションで“自動スナップショット”のようなバックアップ機能が用意されていない前提で、運用設計を組むのが安全です。
だからこそ、最初に「何を・どこへ・どれくらい残すか」を決めておくと、事故っても落ち着いて戻せます。

バックアップの種類：手動／自動（世代管理）／退避先の考え方

バックアップで“守る対象”を決める（迷ったらこれだけ）

最低限、次の3点が守れれば復旧が速いです。

ワールド本体（地形・建築・チェストなど）
サーバー設定（server.properties、権限、ホワイトリスト等）
追加要素（プラグイン／MOD／データパック／リソース周り）

「ワールドだけ戻したのに入れない・壊れる」原因の多くは、バージョン差・MOD差・設定差です。
なので、バックアップ単位は次のどちらかがおすすめです。

A案：サーバー一式を丸ごと（初心者向け・ミスが減る）
B案：ワールド＋設定＋追加要素をセットで（容量を抑えたい人向け）

手動バックアップ（確実・更新前に必須）

手動バックアップは「大きい変更の前」にやるのが鉄板です。

マイクラ本体の大型アップデート前
Paper/Forge/NeoForge 等の切り替え前
MOD・プラグインの追加/更新前
ワールド生成系（地形拡張など）を入れる前

やり方はシンプルで、サーバー停止 → 圧縮 → 別場所へコピーが一番安全です。
（稼働中バックアップは“慣れてから”でOK）

停止してバックアップする例（Java/Bedrock共通の考え方）

# 例：サービス停止（環境により名称は異なります）
sudo systemctl stop minecraft

# バックアップ作成（日時付きでzip/tar）
cd /path/to/minecraft
sudo tar -czf /path/to/backup/mc_$(date +%F_%H%M).tar.gz .

# 再開
sudo systemctl start minecraft

自動バックアップ（世代管理が本体）

自動化で大事なのは「毎日取ること」より世代管理（どれだけ残すか）です。おすすめはこれ。

日次：7世代（直近1週間）
週次：4世代（直近1か月）
月次：3〜6世代（直近3〜6か月）

容量に不安があるなら、週次・月次だけでも効果が出ます。

cronで回す最小構成の考え方

1日1回：バックアップ作成
8日より古い日次を削除
週次・月次は別フォルダに退避（または命名で管理）

※「運用ルール」を先に決めておくと、バックアップが“貯まり続ける地獄”を避けられます。

退避先の考え方（同じVPS内だけに置かない）

バックアップが同じVPS内だけだと、VPS障害・操作ミスで一緒に消えることがあります。
基本は「3-2-1」発想が安全です。

3つコピー（原本＋バックアップ2つ）
2種類の場所（VPS内／外部など）
1つはオフサイト（自宅PC・別サービス・別拠点など）

退避先の選択肢（現実的な順）

別の保存先（自宅PC / NAS / 外部ストレージ）に定期ダウンロード
別サーバーへrsync（別VPSや別リージョン）
さくらのVPSの追加ストレージ（NFS）を“退避先の1つ”として使う
※ただし、これ単体で「オフサイト」にはなりにくいので、できればもう1段外へ
仕組みごと任せたいなら、バックアップ製品（例：Acronis系）を検討

復元手順：ロールバックで戻す流れ（事故対応）

復元は焦ると二次被害が出ます。手順を固定すると安定します。

1) まず現状を“退避”してから戻す

いきなり上書きせず、現状を別名に避難させます。

サーバー停止
現在のワールド（または一式）を world_broken_日時 のようにリネーム
バックアップから戻す

2) 戻す対象を“セット”で戻す

ワールドだけ戻すと、環境差で不具合が出やすいです。基本はセット復元。

ワールド
server.properties（特に level-name / difficulty / whitelist）
プラグイン・MOD・データパック
権限・ホワイトリスト（ops.json / whitelist.json 等）

3) 起動後はこの順で確認する（最短チェック）

サーバーログにエラーが出ていないか
自分が入れるか（権限・ワールド読み込み）
主要拠点のチャンクが壊れていないか
MOD/プラグイン環境なら、依存関係エラーがないか

事故対応の判断基準（迷ったら）

参加できない／クラッシュする：環境差（バージョン・MOD）を疑う
建築が巻き戻っている：選んだ世代が古い可能性
一部だけ消える：稼働中バックアップの整合性不足の可能性（停止バックアップ推奨）

ワールド移行：PC→VPS／VPS→PC（SFTP等で迷わない）

結論：ワールドフォルダを丸ごと圧縮して運ぶのが一番ミスりません。
（細かいファイル選別は慣れてからでOK）

手順テンプレ（PC→VPS）

PC側でワールドフォルダをzip/tarで圧縮
SFTPでVPSへアップロード（WinSCP等が楽）
VPS側で解凍して所定の場所へ配置
level-name（ワールド名）や起動設定を合わせる
起動して動作確認

手順テンプレ（VPS→PC）

VPS側でワールド（または一式）を圧縮
SFTPでPCへダウンロード
PC側の所定フォルダへ配置
シングル/ローカルで開けるか確認

Java版の移行で注意するフォルダ構造

Javaは「level.dat があるフォルダ = ワールド」が基本です。
移行時は、次を丸ごと運ぶのが安全です。

ワールドフォルダ（例：world/）
- level.dat（ワールドの核）
- region/（地形チャンク）
- playerdata/（プレイヤーデータ）
- data/ advancements/ stats/ など

加えて、環境によって次が別フォルダになることがあります（ここが落とし穴）。

ネザーやエンドが world_nether/ world_the_end/ のように別ディレクトリ
もしくはワールド内に DIM-1 DIM1 のように入っている

どちらの構造か分からないときは、ワールド関連っぽいフォルダをまとめて一式バックアップが確実です。

統合版の移行で注意するフォルダ構造

統合版（Bedrock）は、PC側のワールドが「分かりにくいフォルダ名」になりがちです。
見分けるポイントは levelname.txt です。

PC（非サーバー）のワールド：minecraftWorlds 配下にフォルダで保存
- フォルダ名が暗号っぽくても、levelname.txt に“表示名”が入っている
Bedrock Dedicated Server（BDS）：初回起動後に必要フォルダが作られるので、一度起動してから移行するのが安全

稼働中にバックアップ整合性を取りたい場合は、BDSの save 系コマンド（hold/query/resume）を使う設計もあります。
ただし初心者のうちは、まず 停止バックアップ→移行 の順が失敗しにくいです。

さくらのVPS 公式サイト

アップデート運用：安全に“最新化”するための手順書

アップデートで一番怖いのは「更新そのもの」より、更新後にプラグインやMODが噛み合わず落ちる／ワールドが壊れる／参加者が入れないことです。
ここでは、初心者でも事故りにくい“型”として手順化します。

更新前にやること（互換性チェック／バックアップ／検証）

1) まず「更新の単位」を切り分ける

更新は混ぜるほど事故ります。以下を別々に考えます。

Minecraft本体（サーバー）
Java（実行環境）
サーバー種類（バニラ／Paper／Forge／NeoForge）
プラグイン／MOD
ワールド（データ）

2) 互換性チェックの最短チェックリスト

更新前に、これだけ確認すると「詰まりどころ」を潰せます。

サーバー側の目標バージョン（例：1.xx.x）を決めたか
参加者全員のクライアントが、そのバージョンに上げられるか
Java版なら 必要なJavaバージョンを満たすか（特に1.20.5以降）
Paper/プラグインなら「対応バージョン（対応Minecraft版）」が揃うか
MODなら「Minecraft版・ローダー版・MOD版」が一致するか

3) バックアップは「更新直前」に1つ増やす

すでに日次バックアップがあっても、更新前は別枠で取るのが鉄板です。

ワールド
設定類（server.properties、権限、ホワイトリスト等）
プラグイン／MOD（本体jar・config含む）

※停止バックアップが一番安全。更新で取り返しがつかないケースの多くは、ここをサボったときに起きます。

4) 検証（できる範囲でOK）を挟むと成功率が跳ねる

理想は「検証用コピー」で先に起動してみることです。

VPS内に server_test/ を作って、バックアップを展開
ポートだけ変更して、身内1人で接続テスト
問題がなければ本番に適用

「検証なんて無理…」なら、最低限これだけでもOKです。

更新後の最初の起動は必ずログを見る
参加者を呼ぶ前に、自分だけでワールドに入って主要拠点を確認

5) さくらのVPS（スタートアップスクリプト利用時）の注意

Java版のスタートアップスクリプトは、OS再起動時に自動更新が走るタイプです。
つまり「再起動＝更新」になりやすいので、次を運用ルールにすると事故が減ります。

再起動は“メンテ時間だけ”にする（普段はむやみにrebootしない）
再起動前に Javaのバージョン確認をする
再起動前にバックアップを取る（更新トリガーになるため）

Paper・プラグイン・MODの更新方針（地雷回避）

Paperの更新方針（安全な順）

Paperは更新自体は簡単ですが、事故要因はだいたい「プラグイン側」です。

おすすめの順番：

バックアップ
プラグイン更新（必要なら）
Paper更新
起動ログ確認 → 接続確認

Paper更新のコツ

サーバー稼働中にjarを差し替えない（停止して差し替えが安全）
更新後の初回起動は、プラグイン読み込みエラーが出やすいのでログを見る

プラグイン更新での“地雷”はこれ

一番多いのが 同じプラグインが2つ入る事故です（旧版と新版が共存）。
回避策として、Paperには「updateフォルダ」を使う方法があります。

plugins/update/ を作る
新しいjarは update に入れる
再起動でまとめて差し替える（既存jarは触らない）

これだと「途中で差し替えて中途半端になる」事故が減ります。

プラグイン更新の判断基準（迷ったら）

重大バージョンアップ（例：1.20→1.21）時は、プラグインも合わせて更新前提
小さいパッチアップデートなら、まずPaperだけ更新して様子見でも可（ただしログは確認）

MOD（Forge/NeoForge系）の更新は“順番”が命

MOD環境は「全部同時に上げる」と壊れやすいので、順番を固定します。

基本の順番：

バックアップ
Minecraft本体（サーバー側の目標版）を固定
ローダー（Forge/NeoForge）を更新
MODは“少しずつ”更新（依存関係込みで揃える）
起動 → ログ確認 → ワールド確認 → 参加者へ展開

安全運用のコツ

参加者には「配布物（MOD一式）」を毎回セットで渡す（版ズレ防止）
ひとつ更新するたびに起動確認（原因の切り分けが速い）
大型アップデートは検証環境で先に起動（本番直当てを避ける）

ロールバックを簡単にする小ワザ

更新前の mods/ を丸ごと mods_prev/ に退避しておく
だめなら元に戻して再起動、で戻せる

統合版の更新で詰まりやすい点

統合版は、つまずきがだいたい「バージョン不一致」です。さらに厄介なのは、パッチ違いでも不一致が起きることがある点です。

1) よくある症状と原因

“Outdated Client”／“Outdated Server” が出る
→ クライアントとサーバーのプロトコル（対応版）が一致していない

2) 事故らない更新ルール（身内運用）

参加メンバーの中で「一番先に上がった端末」に合わせる
（スマホが先に更新されて、Switchが遅れる…などが起きやすい）
逆に、全員が更新できるまではサーバーを上げない、も選択肢
（“今日は入れない人が出る”のを許容するかどうかの問題）

3) サーバー更新時のポイント

サーバー更新前にバックアップ（ワールド＋設定＋allowlist）
更新後はまず管理者だけで接続確認
問題が出たら、焦って連続更新せず「ログと版」を落ち着いて確認

4) さくらのVPSで統合版を扱う場合の注意

スタートアップスクリプトや導入方式によって、更新のトリガー（再起動／再インストール／手動入れ替え）が変わります。
どの方式でも共通して重要なのはこれです。

更新前にバックアップ
更新後に最初の接続テスト（管理者のみ）
“入れない人”が出たら、まずバージョン不一致を疑う

さくらのVPS 公式サイト

重い・ラグいを解決：原因特定→改善の順番

「体感ラグ」の原因は、だいたい次のどれかです。

サーバー処理が重い（TPSが落ちる／カクつく）
回線・経路が不安定（ワープする／チャット遅延）
クライアント側が重い（自分だけカクカク）

闇雲に設定をいじるより、“測る→当たりを付ける→効く順に改善”が最短です。

まず測る：CPU／メモリ／TPS目安／ディスクI/O

1) まず「TPS / MSPT」を見る（これが基準値）

目標：TPS 20（常に20が理想）
目安：MSPT 50ms以下（1tick=50msを超えるとTPSが落ち始める）

Paperなら（1.21以降）sparkが同梱されているので、原因特定が一気に楽です。

例：/spark profiler start --timeout 600
→ 10分計測してレポートURLが出る（重い処理が“どれか”が見える）

ここで分かること（初心者向け）

「サーバースレッド」が重い → エンティティ・チャンク生成・プラグインが疑わしい
「GC（ガベージコレクション）」が頻発 → メモリ不足 or メモリ設定不適切が疑わしい

2) CPU：高いのは「総量」より「1コア張り付き」

マイクラは（特にJava版）メインスレッドが1コアに寄りがちです。

目安
- プレイヤーが少ないのにCPUが常に高い → プラグイン/MOD/設定が原因のことが多い
- 探索・新天地で急に重い → チャンク生成が原因のことが多い

3) メモリ：足りないと“重い”より先に“ガクガク”

メモリ不足や設定ミスは、体感が「ラグ」というより定期的な固まりで出やすいです。

目安の見方
- 空きがほぼない／スワップを多用 → メモリが足りない可能性
- メモリ割り当てが大きすぎる → GCが重くなることもある（増やせば良いとは限らない）

※特にMOD環境はメモリ要求が跳ね上がります。

4) ディスクI/O：意外と見落とす“詰まりポイント”

次のタイミングで重くなるなら、I/Oを疑います。

新規チャンク生成（探索）
自動セーブ
大量のMob／村人／チェスト周り
バックアップや圧縮を稼働中に走らせた

症状の例

CPUはそこまで高くないのにTPSが落ちる
セーブの瞬間だけガクッと止まる
→ こういうときはディスクI/Oが犯人になりやすいです。

設定で効く：描画距離・シミュレーション距離・entity抑制

「設定で効くもの」は、まず“副作用が少ない順”に触るのが安全です。

1) まずは距離系（効果大・調整しやすい）

view-distance：送る地形の範囲（見える距離）
simulation-distance：動作する範囲（Mob・レッドストーン・成長など）

目安（身内サーバーの初期値として無難）

view-distance：6〜10（まず8あたり）
simulation-distance：4〜6（まず5あたり）

ポイント：

simulation-distanceを下げると軽くなりやすい一方、農場や装置の動作範囲に影響します。
→ “軽さ優先か、装置優先か”を先に決めると迷いません。

2) 次に「エンティティ（Mob/アイテム）」を抑える

ラグの主犯になりやすいのはエンティティです。まず“事故が少ない”順に。

落ちているアイテムが増えすぎない運用
- 連続稼働のトラップ・自動回収がない → アイテムが残り続ける
村人・動物の増やしすぎを避ける
- 村人は特に重くなりやすい（AI・職業・取引）

サーバー設定側の調整（やるなら慎重に）

Mobのスポーン上限（多すぎると重い）
追跡範囲・アクティブ範囲（遠くのMobを動かしすぎない）

※ここはやりすぎると“バニラ感”が変わるので、まずは距離設定→運用改善→最後に細かい抑制、の順が安全です。

3) 「探索が重い」ならチャンク生成対策が効く

探索時だけ重いなら、原因はほぼチャンク生成です。

できる対策
- 探索範囲を事前に決める（無限に広げない）
- 余裕のある時間に“先に生成”しておく（後述のPaper移行やツール活用でやりやすい）

サーバー実装で効く：Paper系の導入判断

「設定を詰めても限界がある」ときに効くのが、サーバー実装の見直しです。

1) 結論：迷ったらPaperは“性能・運用のバランスが良い”

バニラ（公式）：挙動が素直。ただし負荷に弱い
Paper：パフォーマンス改善・設定項目が豊富、運用もしやすい

特に「身内で快適に遊びたい」「プラグインを入れたい」なら、Paperは相性が良いです。

2) Paperに向くケース

TPSが落ちやすい（プレイヤーが増えると顕著）
探索や拠点でラグが出る
プラグインで“遊びやすさ”を上げたい（権限・保護・バックアップ補助など）
原因調査をしたい（sparkで“何が重いか”見える）

3) Paperに向かない（慎重に）ケース

超バニラ挙動に強いこだわりがある
レッドストーン装置などで「挙動が変わるのは困る」
→ この場合は、まずバニラで距離・運用改善、次に最小限の最適化、という順がおすすめです。

スケールアップ判断：プラン変更のタイミング

最後の手段は「強いマシンにする」です。
ただし、スケールアップはお金が増えるので、“改善で伸びしろが残っているか”を見てからが合理的です。

1) 先にスケールアップすべきサイン

設定を軽くしても TPS/MSPTが安定しない
spark等で見て メインスレッドが常に重い（プレイヤー少数でも）
MOD環境でメモリ不足が明確（スワップ多用・GC頻発）
探索が多く、チャンク生成が頻繁でCPUが張り付く
ディスクI/Oが詰まり、セーブ時にガクガクする（容量も逼迫）

2) 何を増やすべきか（症状→対策の対応表）

スクロールできます

症状	まずやる改善	それでもダメなら
プレイヤー増でTPS低下	view/simulation距離を下げる、エンティティ抑制	CPU（vCPU強化）
定期的に固まる（停止）	メモリ割当見直し、不要常駐を減らす	メモリ増強
探索時だけ重い	生成範囲の運用・事前生成	CPU強化＋余裕ある構成
セーブ時にガクッと止まる	バックアップの時間帯調整、I/O負荷軽減	ストレージ/プラン見直し

3) さくらのVPSでのスケールアップ注意点（運用で詰まらないために）

さくらのVPSはコントロールパネルからスケールアップできますが、制限条件があります。

下位プランへは変更不可（上位のみ）
申込当日はスケールアップ不可
お試し期間中・未納状態は不可
在庫がないと不可
リージョン/ゾーン変更は不可
IPアドレスは引き継ぎ（＝参加方法を変えずに済むことが多い）

スケールアップ前にやること（最低限）

バックアップ（ワールド＋設定＋追加要素）
メンテ時間を決める（再起動が絡む可能性があるため）
スケールアップ後に 最初は管理者だけで接続確認

さくらのVPS 公式サイト

よくあるトラブル集（症状→原因→対処で探せる）

ここは「最短で直す」ために、よくあるパターンを 症状→原因→対処 でまとめます。
困ったらまず、サーバー側ログ（起動ログ／接続ログ）を開きながら進めると解決が速いです。

接続できない（アドレス／ポート／FW／バージョン違い）

まず最初に確認する3点（ここで8割解決）

IPアドレスは合っているか（さくらのVPSのIPv4を見直す）
ポートは合っているか
- Java版：基本 25565/TCP
- 統合版：基本 19132/UDP（IPv6なら19133も）
サーバーは起動して待ち受けているか（起動していないと絶対つながりません）

症状別：原因と対処の早見表

スクロールできます

症状	よくある原因	まずやる対処
「タイムアウト」「サーバーに接続できません」	ポート未開放（パケットフィルタ/ufw）、サーバー停止、IPミス	①待ち受け確認→②FW確認→③外部から再テスト
「接続拒否（Connection refused）」	サーバーがそのポートで待ち受けていない／別ポートで起動	サーバー側で待ち受けポートを確認（ss）
「不明なホスト（Unknown host）」	IPではなくドメインで入れていてDNS未設定	まずIP直打ちで試す
「バージョンが違います」	サーバーとクライアントのMinecraft版が不一致	両者を同じ版へ（特にJava）
統合版でサーバーが出ない／入れない	UDP未許可、ポートが違う、allowlist	UDP許可・server-port確認・allowlist確認

切り分けテンプレ（この順で潰す）

1）サーバーが待ち受けているか（VPS内）

# Java版（TCP）
sudo ss -lntp | grep 25565

# 統合版（UDP）
sudo ss -lnup | grep 19132

出ない → ネットワーク以前に「サーバーが起動していない／別ポート」なので、起動ログへ。

2）ファイアウォール（どこで止めてるか）

さくら側：パケットフィルタで 必要ポートを許可しているか
OS側：ufw等で許可しているか（UDP/TCPの向きも注意）

3）外部回線から試す（最強の確認）

自宅Wi-Fiではなく、スマホテザリング等で接続（経路を変える）
友人にも試してもらう（自分の回線問題を切り分け）

“やりがち”注意点

JavaなのにUDPを開けている（逆も同様）
server.properties の server-ip を埋めてしまい、意図せずbind先を縛っている
→ 基本は空欄でOK
ポートを変えたのに、クライアント側で IP:ポート を指定していない

起動しない（EULA／Java／権限／メモリ不足）

まず見る場所（ここだけで当たりが付く）

systemd運用：

  sudo systemctl status minecraft
  sudo journalctl -u minecraft -n 200 --no-pager

手動起動：コンソールに出たエラー文（最重要）
追加で：logs/latest.log、crash-reports/（あれば）

原因トップ4と対処

1）EULA未同意（初回あるある）

症状：EULAに同意していない旨が出て終了
対処：eula.txt の eula=true を設定して再起動

2）Javaのバージョン違い

症状：起動直後にJava要件エラー、あるいは謎の例外で落ちる
対処：遊ぶMinecraft版に合うJavaを入れる → java -version で確認
- 例：1.20.5以降はJava 21が必要になりやすい（ここを外すと起動しません）

3）メモリ不足／メモリ指定ミス

症状：起動途中で落ちる、OutOfMemory、サーバーが固まる
対処：
- -Xmx をVPSメモリの 6〜7割程度に（他プロセス分を残す）
- MOD環境なら、まず“MODを減らす”のも即効性があります

4）権限（ファイル所有者）問題

症状：ファイルを読めない／書けない、ログやワールドが作れない
対処：実行ユーザーがディレクトリに書き込めるか確認

  ls -la /opt/minecraft
  sudo chown -R minecraft:minecraft /opt/minecraft

「暗号化中」で止まる／ログイン直後に落ちる

この系統は「ネットワーク」より、サーバー側処理／互換性／権限が原因のことが多いです。

よくある原因と、最短の当て方

1）サーバーが重くて参加処理に耐えていない

典型：参加者が入る瞬間だけ固まる／TPSが落ちる
対処（効く順）
- ① サーバー再起動（まず状態を整える）
- ② view-distance / simulation-distanceを下げる
- ③ 同時接続が多いならプラン見直し（CPU/メモリ）
- ④ Paper導入や、負荷原因（エンティティ・プラグイン）を減らす

2）MOD/プラグイン不一致（特にMODは多い）

典型：ログイン直後に落ちる、特定の人だけ落ちる
対処
- ① サーバーとクライアントのMinecraft版を一致
- ② MODパックを“同じzip”で配布（1つでもズレると落ちやすい）
- ③ 直前に入れたMOD/プラグインを一旦外して検証

3）認証・アカウント周り（Java）

典型：ログに認証失敗、クライアントは「暗号化中」から進まない
対処
- ① サーバー設定（online-mode）を確認（公開なら基本ON）
- ② 一時的な認証側トラブルの可能性もあるので、時間を置いて再試行
- ③ “非公式ランチャー混在”など運用ルールも見直す

4）ワールド/プレイヤーデータ破損（特定の人だけ落ちる）

典型：Aさんだけ入れない、他は普通に入れる
対処
- ① その人のプレイヤーデータ（Javaならplayerdata）を退避して再試行
- ② 退避前に必ずバックアップ（元に戻せるように）

ここまでで直らないときの“観察ポイント”

“誰が入ると落ちるか”（特定の人＝プレイヤーデータ／権限／クライアント差）
“どの地点で落ちるか”（暗号化中、ワールド読込、スポーン直後…）
サーバーログに同時刻のエラーが出ているか（最重要）

ワールドが壊れた／巻き戻したい（復元手順）

最優先：上書きせず「現状を退避」してから戻す

サーバー停止
現状ワールド（またはサーバー一式）を別名へ退避
バックアップから復元
起動して確認（管理者だけでOK）
問題なければ公開

具体的な“ロールバック手順”（基本形）

1）停止

  sudo systemctl stop minecraft

2）現状退避（例：worldを退避）

  cd /opt/minecraft/server
  mv world world_broken_$(date +%F_%H%M)

3）バックアップ展開（例）

  tar -xzf /path/to/backup/mc_backup.tar.gz -C /opt/minecraft/server

4）起動

  sudo systemctl start minecraft

バックアップが無い場合（できるだけ安全に）

バックアップ無しで“直す”のは成功率が下がるので、まず 現状を丸ごとコピーして保険を作ってください。

まずやる：ワールドの複製（退避）
次の選択肢（軽い順）
- ① 直前の変更を戻す（MOD/プラグイン更新、設定変更など）
- ② 破損のヒントをログで探す（どのファイルで落ちているか）
- ③ 最終手段：破損している領域データ（region等）の切り分け
  ※この手順は“消える可能性”があるので、必ず退避コピーを取ってから

さくらのVPS 公式サイト

運用をラクにする小ワザ（慣れてきたら）

サーバーが安定して動き始めたら、次は「管理者が疲れない仕組み」に寄せるのがコツです。
ここでは、やり過ぎない範囲で“効く”小ワザをまとめます。

定時再起動・ログ整理・自動通知（Discord等）

定時再起動は「やるなら安全手順を固定」

再起動は万能薬ではありませんが、プラグインやMODの相性・メモリ断片化などで長時間稼働が不安定になりやすい環境では効くことがあります。

おすすめの考え方👇

「毎日」より「週1〜2回」くらいから開始
再起動前後に バックアップ or 少なくともセーブ
参加者がいる時間帯は避ける（深夜〜早朝など）

安全な再起動テンプレ（これだけ覚えればOK）

事前告知（5分前 / 1分前）
サーバー内で保存（save-all）
停止 → 起動（systemdなら stop/start）
起動ログ確認 → 管理者が1回接続してOKなら解放

ここをルール化すると、事故対応が“作業”になります（精神が削れにくい）。

定時再起動の実装（例：cronで毎日4:00）

※サービス名や実行方法は環境によって異なるので、あなたの構成に合わせてください。

sudo crontab -e

0 4 * * * /bin/systemctl restart minecraft

さらに丁寧にするなら「再起動前にメッセージ送る」「セーブしてから落とす」などをスクリプト化します（後述）。

ログ整理は「増え続けるものだけ回収」

ログは“残す価値”がありますが、無限に増えるのが問題です。

整理の方針（ラクな順）

① Minecraftのログ：世代を決めて古いものを削除
② systemd/journal：上限サイズや保持期間を設定
③ crash-reports：必要な期間だけ残す（原因究明できたら削除）

Minecraftログをlogrotateで回す例
/etc/logrotate.d/minecraft を作成：

/opt/minecraft/server/logs/*.log {
  weekly
  rotate 8
  compress
  missingok
  notifempty
  copytruncate
}

rotate 8 → 8世代残す（週次なら約2か月分）
copytruncate → プロセスを止めずに切り替え（※環境によっては停止して回すほうが安全）

journalの肥大化対策（例）

sudo journalctl --vacuum-size=500M
# もしくは
sudo journalctl --vacuum-time=14d

Discord通知（Webhook）で“管理者の確認コスト”を下げる

一番ラクなのは DiscordのWebhook を使って「再起動・障害・バックアップ」を通知する方法です。

Webhookの基本

Discordでチャンネル → Webhookを作成 → URLを取得
VPS側で curl で投げるだけ

例（再起動開始／完了メッセージ）：

WEBHOOK_URL="https://discord.com/api/webhooks/xxx/yyy"

curl -H "Content-Type: application/json" \
  -d '{"content":"🛠️ サーバー再起動を開始します（約1〜2分）"}' \
  "$WEBHOOK_URL"

sudo systemctl restart minecraft

curl -H "Content-Type: application/json" \
  -d '{"content":"✅ サーバー再起動が完了しました。接続テストOKです。"}' \
  "$WEBHOOK_URL"

運用が一気にラクになる通知アイデア

🕒 定時再起動：開始／完了
💾 バックアップ：成功／失敗
🚨 異常検知：起動失敗、プロセス停止、ディスク逼迫（残容量◯%）など

「Discordで一目で状況がわかる」だけで、管理のストレスがかなり減ります。

身内運用の“決めごと”テンプレ（管理者が疲れない）

身内サーバーで荒れやすいのは、技術よりも「期待値のズレ」です。
最初に“軽いルール”を置くと、管理者の負担が激減します。

1枚で済むテンプレ（コピペ用）

サーバーの目的：例）「建築メイン」「のんびりサバイバル」「MOD検証」など
参加条件：招待制（紹介制）／ホワイトリスト必須
連絡手段：Discord（#連絡 / #不具合 / #要望）
ログイン時間：自由（ただし深夜の重い作業は控える等）

ルールは“揉めやすいところだけ”に絞る

おすすめはこの5つだけです。

ワールド共有物の扱い
- 他人の建築・チェストは勝手に触らない（必要なら一言）
資源採取のマナー
- 共同拠点付近での採掘ルール（景観・落とし穴など）
重くなる行為の制限
- 放置トラップは「事前申請」
- 村人増殖・大型装置は「上限」または「場所指定」
更新方針
- 「大きな更新は週末にまとめて」など、いつ上げるかを決める
- MOD/プラグイン環境なら「配布物はこの1つ（ZIP/リスト）だけを使う」
トラブル時の対応
- 落ちたら：#不具合に「何をしてたか」「エラー文」を貼る
- 荒らし・事故：まず管理者に連絡 → ロールバック判断（勝手に直さない）

管理者が疲れない“役割分担”の型

管理者（1人）：最終判断、バックアップ、アップデート
副管理者（1〜2人）：再起動、簡単なサポート、連絡係
参加者：要望はテンプレに沿って投稿（情報が揃うほど解決が速い）

おすすめ運用：要望テンプレを固定する（これだけで神）

Discordの #要望に貼るテンプレ例：

やりたいこと：
いつ：
影響（重くなる？破壊あり？）：
必要MOD/プラグイン：
失敗したときの戻し方（分かる範囲で）：

これで「結局どうしたいの？」の往復が減り、管理がラクになります。

さくらのVPS 公式サイト

FAQ（「さくらのVPS マイクラ」で聞かれがちな疑問）

結局いくらかかる？どこを見れば最新料金？

結論、費用は 「プラン料金」＋（必要なら）「ストレージ増量」＋（必要なら）「バックアップ置き場」 で決まります。
マイクラ用途なら、まずは Linuxの通常VPS を前提に考えると分かりやすいです。

料金の“最新”を確認する場所

さくらのVPS公式の 料金・仕様一覧ページ
公式の 料金・仕様PDF（プラン表）

この2つを見れば、キャンペーンやリージョン差を含めた最新の価格に追従できます。

目安（まず迷うのはここ）

マイクラは遊び方で差がありますが、入門としては以下が現実的です。

スクロールできます

まずの目安	どういう人向け	料金感のイメージ
2G〜4G	少人数・身内・軽め	まず始める価格帯
8G	人数増・探索多め・プラグイン/軽いMOD	余裕を持たせたい
16G以上	MODパック級・公開寄り・重め運用	かなり安定重視

見落としがちな追加費用

ストレージ増量：ワールドが育つ／バックアップを多めに残すなら検討
バックアップ置き場（例：NFS）：VPSとは別場所に退避したいなら有効
Windows系：基本マイクラはLinuxでOK（Windowsは費用が跳ねやすい）

ポイント：迷ったら「まず4Gで開始 → 重ければ8Gへ」の流れが一番失敗しにくいです。

何人まで遊べる？ MODありだとどう変わる？

「何人まで」は、実際には 人数より“負荷の種類” で決まります。
同じ5人でも、建築中心と探索中心では重さが全く違います。

人数の目安の考え方

人数見積もりは、次の3点で大きく上下します。

ワールド生成（未探索地の移動）：一番重くなりやすい
距離設定（描画距離・シミュレーション距離）：体感に直結
常時稼働系（村人・トラップ・装置）：積み上げで重くなる

バニラ（Paperなど軽量化含む）だと

少人数（2〜6人程度）は、設定を整えれば動かしやすい
探索が多い場合は、同人数でも体感が落ちやすいので余裕を見ます

MODあり（Forge/NeoForge）だと

MODは基本的に メモリを強く要求 します。特に「MODパック」系は別物です。

軽めのMOD少数：まだ調整で吸収しやすい
MODパック／大型追加：最初から上位プラン前提 になりやすい
クライアントとサーバーのバージョン・構成一致が必須（ズレると沼）

ざっくり判断ルール（迷ったらこれ）

身内で軽め：4Gから
探索多め／プラグイン導入：8G寄り
MODパック級：最初から大きめ（「後から増強」前提でOK）

“何人まで”を断言するより、最初は TPSやメモリ使用量を見て増強判断 するほうが安全です。

Switch/PS/スマホから参加できる？（統合版の前提）

結論、統合版（Bedrock）サーバー を立てれば、スマホやPC（統合版）からは参加しやすいです。
ただし ゲーム機（Switch/PS）だけは注意点 が増えます。

まず前提として押さえること

Switch/PS/スマホは基本 統合版（Bedrock）
Java版サーバーに統合版で入るには、別途ブリッジ構成が必要（初心者向けではない）

スマホ・PC（統合版）から参加する流れ

サーバーの IPアドレス と ポート（通常UDP） を確認
クライアント側でサーバーを追加して接続

Switch/PSは「そのまま追加できない」ケースがある

機種・環境によっては、メニューに カスタムサーバー追加が出ない など制約があります。
その場合、DNS変更や中継アプリ（いわゆるBedrockConnect系）など 非公式の迂回手段 が語られますが、これは環境依存・不安定要素もあるため、

安全第一なら：スマホ/PC（統合版）中心で運用する
ゲーム機も必須なら：Realms等の選択肢も含めて検討する

という整理が失敗しにくいです。

既存ワールドを移したい／バックアップだけ取りたい

結論、ワールド移行もバックアップも 「止めて、固めて、転送して、戻す」 が基本です。
動かしたままコピーすると、破損や巻き戻りの原因になります。

既存ワールドをVPSへ移す（Java版）

サーバー停止（または最低でも保存してから停止）
ワールド一式を圧縮（例：zip / tar.gz）
SFTPでVPSへ転送
サーバーのワールド配置場所に展開
起動してログ確認（読み込み成功を確認）

移行でつまずきやすいポイント

フォルダ名（level-name）が一致していない
ネザー／ジ・エンド等の関連フォルダが欠けている
バージョン差が大きい（先にバックアップ必須）

既存ワールドをVPSへ移す（統合版）

基本の流れは同じですが、統合版はファイル構造や扱いが異なるため

統合版用のワールドフォルダ を丸ごと扱う
ポートがUDP中心 なのでネットワーク設定も合わせて確認
が重要です。

バックアップだけ取りたい（最短）

サーバー停止（または保存→短時間停止）
ワールドを圧縮して退避
退避先は「VPS外」を推奨（障害時に同時に消えるのを防ぐ）

退避先の候補

NFS等の別ストレージ
クラウドストレージ
手元PCへの定期ダウンロード

バックアップは「世代管理（例：7世代）」までやると、本当に事故に強くなります。

さくらのVPS 公式サイト

まとめ

さくらのVPSでマイクラを運用するコツは、最初に“正しい型”を作ってしまうことです。この記事で押さえたポイントを、最後に短く整理します。

まずは方式を決める
- 早く始めたいなら：スタートアップスクリプトなど“最短ルート”
- 自由度を取りたいなら：Ubuntuに手動構築（Paper／Forge／Bedrock など）
プランは「人数」より「遊び方」で決める
探索や装置、MODの有無で負荷は大きく変わります。迷ったら小さく始めて、ラグの指標（CPU/メモリ/TPS）を見て増強が安全です。
つながらない原因の9割はネットワーク設定
IP・ポート・フィルター（パケットフィルター/OS側FW）・バージョン違いを、決まった順番で切り分けると迷いません。
セキュリティは“先に”やるほどラク
SSHは鍵ログイン・root制限・不要ポート遮断。マイクラ側はホワイトリストと権限最小化。公開するならログとルールもセットで。
バックアップは最重要の運用設計
ワールドは“資産”です。手動＋自動（世代管理）で守り、復元手順（ロールバック）まで決めておけば事故が起きても立て直せます。
アップデートは「互換性チェック→バックアップ→検証」の順
本体・Paper・プラグイン・MODを混ぜて更新しないこと。統合版はバージョン不一致で詰まりやすいので、更新方針を先に決めましょう。
重い・ラグいは「測ってから」改善
距離設定やエンティティ抑制、Paper導入、最後にスケールアップ。闇雲にいじらないのが最短です。