ConoHa VPS×マイクラ入門｜料金・必要スペック・立て方・参加方法まとめ

2026年2月10日

「友だちとマイクラを遊びたい。でも、ワールドをいつでも入れるマルチにしたい」
そんなときに候補に挙がるのが ConoHa VPS です。

ただ、いざ調べ始めると、こんな声が出てきませんか？

「結局、月いくらかかるの？できるだけ安く始めたい…」
「何GBのプランを選べばいい？人数が増えたらどうするの？」
「Java版と統合版って違うけど、自分たちはどっちでサーバーを立てるべき？」
「ポート開放とか難しそう。初心者でも本当に立てられる？」
「荒らしが怖い…。公開しない方法や安全な運用ってどうやるの？」
「MODやプラグインも入れたいけど、どこから手を付ければ事故らない？」
「つながらない・重い・落ちる…って聞く。トラブルの対処も知りたい」

この記事では、こうした疑問に答えるために、ConoHa VPSでマイクラを始める流れを “最短で動かす”→“安全に運用する”→“快適にする” の順にまとめました。

具体的には、

料金の考え方（時間課金・長期割引）と、ムダな出費を防ぐポイント
人数と遊び方から逆算する、必要スペックの目安
テンプレ（Minecraft manager）での最短構築と、手動構築の選び分け
IP:ポート／ドメインでの接続など、参加方法
ホワイトリスト・権限・バックアップを軸にした、安全・安定運用
よくあるトラブルを「症状→原因→対策」で潰す、復旧手順

まで、初心者でも迷わないように解説します。

「まずは今日中に遊べる状態にしたい」人も、「後からMODやプラグインで拡張したい」人も、この記事を読めば 自分に合う始め方が選べるはずです。

ConoHa VPS 公式サイト

最初に結論：ConoHa VPSは「こういう人」に刺さる

ConoHa VPSでマイクラをやる魅力はひとことで言うと、「サーバーを“自分の環境”として自由に育てられる」ことです。
テンプレート（Minecraft manager）を使えば初心者でも始めやすく、必要に応じて手動設定や構成変更にも広げられます。

一方で、VPSは「レンタルサーバー的に全部お任せ」ではないので、最低限の管理意識（更新・バックアップ・セキュリティ）は必要です。

向いているケース（常時稼働／自由度／コスパ重視）

次に当てはまるなら、ConoHa VPSはかなり相性が良いです。

24時間いつでも入れるマイクラ環境が欲しい
自宅PCをホストにしないので、電源や回線、スリープ問題から解放されます。
遊び方を“あとから”変える可能性が高い
例：最初はバニラ → 途中から軽量プラグイン → さらにMOD…のように、段階的に拡張したい人向き。
コストをコントロールしたい
ConoHa VPSは料金体系に「時間課金」と「長期割引（まとめトク）」があり、
「まず短期間で試す」→「良ければ長期で安くする」がやりやすいです。
※初期費用が無料なので、スタートの心理的ハードルも低めです。
“トラブルが起きた時に直せる”人（または学ぶ気がある人）
VPSは自由度が高い反面、何か起きた時に原因を切り分ける姿勢があると強いです。
とはいえ、テンプレ＋管理画面運用なら、最初は難しい操作をかなり減らせます。

💡初心者が失敗しにくい考え方
「まずは管理画面で完結する範囲で運用し、必要になったら手動へ」が安全です。

注意したいケース（管理負担／アップデート対応／セキュリティ）

逆に、次のタイプは「想像より手間が増える」可能性があります。

“完全放置で動いてほしい”（メンテも更新も一切やりたくない）
アップデートで不具合が出た時に、調べるのが苦手
サーバー公開のリスクが不安（荒らし、パスワード管理、ポート開放など）

特に大事なのがセキュリティです。
ConoHa VPSでマイクラを公開する＝インターネット上に入口を作ることなので、最低限これだけは守るのがおすすめです。

ホワイトリスト運用（参加者限定）にする
管理者権限（OP）をむやみに配らない
バックアップを“復元できる形”で用意する
ログ（記録）を見られる状態にしておく

✅結論：
「自由度」と引き換えに、最低限の“運用の責任”が発生する――ここに納得できるかが分かれ目になります。

迷いやすい比較：ConoHa for GAMEとConoHa VPSの違いを1分で整理

「ConoHaってVPSとfor GAME、どっちでマイクラやるのが正解？」はよく迷うポイントです。
結論としては、目的が違うので次のように選ぶと判断が速いです。

スクロールできます

比較ポイント	ConoHa VPS	ConoHa for GAME
ねらい	汎用VPS（自由度が高い）	ゲーム向けに最適化（始めやすさ重視）
管理のしやすさ	テンプレなら簡単／深掘りは自分で	ゲーム向け導線がわかりやすい
MOD/プラグイン	自分で入れる（方式選び含む）	ゲーム用テンプレが用意されやすい
料金の見え方	時間課金・まとめトクなど	月額・時間単位の表示が明確（プラン体系がゲーム寄り）
向いている人	「自由に育てたい」	「まずゲームを動かしたい」

ざっくりまとめると、

ConoHa VPS：サーバーを“自分の環境”として扱いたい（自由度優先）
ConoHa for GAME：テンプレ活用で“ゲーム運用を最短化”したい（手軽さ優先）

ConoHa for GAME 公式サイト

「Minecraft manager」でできること・できないこと

Minecraft managerは、ブラウザの管理画面からマイクラサーバーを操作できる仕組みです。
コマンド操作に不慣れでも、まずは“動く環境”を作りやすいのがメリット。

できること（まず押さえるべき基本機能）

サーバーの起動・停止（VPS内のminecraft-serverを操作）
バージョン変更
ゲームモードの切り替え
自動バックアップの設定

できないこと（＝ここから先は手動の領域になりやすい）

MOD/プラグイン方式そのものの導入（Forge/Spigot等を“管理画面だけで完結”は難しいケースが多い）
かなり細かい最適化・チューニング（起動オプションや高度な設定）
サーバーを別用途（他ゲーム、別アプリ）に転用するような“OSレベルの拡張”全般

ポイントは、Minecraft managerは「初心者がつまずきやすい最初の壁」を下げる道具だということ。
まずは管理画面で安全に回し、必要になったら少しずつ手動領域へ進むのが堅実です。

MOD/プラグイン前提なら、どちらが事故りにくい？

結論から言うと、「テンプレの用意があるか」「方式選びの迷いを減らせるか」で事故率が変わります。

事故が起きやすいパターン
- MOD/プラグインの方式（Forge/Fabric/Paper等）を決めないまま始める
- サーバーとクライアントのバージョン整合を取らずに更新する
- バックアップが“あるだけ”で、復元手順を試していない
事故を減らすコツ
- 最初に「何を入れたいか」を決める（MODか、プラグインか、バニラか）
- 更新前にバックアップ → 問題が出たら戻せる導線を作る
- 参加者全員のバージョン条件を固定する（途中でズレると詰みやすい）

そして選び方としては、

MOD/プラグインを“最初から”前提にするなら
迷いを減らせるテンプレが揃っている方（ConoHa for GAME側）を検討する価値が高いです。
※公式案内でも、ForgeやSpigotのテンプレはConoHa for GAMEで用意されている旨が示されています。
将来はMODも視野、でも最初はバニラでOKなら
ConoHa VPS＋Minecraft managerでまず安定運用 → 需要が固まったら拡張、が安全です。

🎯初心者向けの結論
「最初からMOD/プラグインで遊ぶ」なら、テンプレが用意される側を優先
「まずはマイクラを安定稼働させたい」なら、VPS＋Minecraft managerで十分戦える
──この分け方が失敗しにくいです。

ConoHa VPS 公式サイト

前提知識：ここを押さえると“詰まらない”

ConoHa VPSでマイクラを動かすのは、ざっくり言うと 「ネット上の自分専用PC（VPS）に、マイクラサーバーを置く」 ということです。
ここでつまずきやすいのが、版の違い／通信の仕組み／データの置き場所／用語。先に整理しておくと、後工程（立て方・設定・トラブル解決）が一気にラクになります。

Java版と統合版の違い（参加できる端末・互換性・必要ポート）

まず最重要：Java版と統合版（Bedrock版）は、そのままでは一緒に遊べません。
同じ「Minecraft」でも、参加できる端末・サーバー方式・通信が違います。

スクロールできます

項目	Java版	統合版（Bedrock）
主な端末	PC（主にWindows/Mac/Linux）	Windows / iOS / Android / Switch / PS / Xbox など
互換性	統合版とは基本別物（そのまま相互参加不可）	Java版とは基本別物（そのまま相互参加不可）
代表的な拡張	MOD（Forge/Fabricなど）	アドオン中心（仕組みが別）
通信の目安	TCP（デフォルト 25565）	UDP（デフォルト 19132）

初心者向けの決め方（ここだけ覚える）

友だちが Switch/PS/Xbox/スマホ なら → 統合版サーバー
友だちが PC（Java）中心 なら → Java版サーバー

補足として、Javaサーバーに統合版プレイヤーを入れる「橋渡し」手段もあります（例：Geyser系）。
ただし難易度が上がり、ポートや追加設定も増えがちなので、最初は“どちらの版で遊ぶか”を固定するのが安全です。

サーバー公開の仕組み（グローバルIP／ポート／DNSの役割）

「VPSで立てたのに友だちが入れない」の大半は、ここ（通信の入口）で止まっています。
仕組みを図にするとこうです。

参加者のPC/スマホ
   ↓（ドメインを入力すると）
DNS：名前 → IPに変換
   ↓
グローバルIP:ポート（入口）
   ↓（VPS側で許可が必要）
セキュリティグループ/ファイアウォール
   ↓
マイクラサーバープログラム

ポイントを短くまとめます。

グローバルIP
インターネット上でVPSを特定する住所みたいなもの。
VPSは基本的にグローバルIPを持つので、家庭回線のような「ルーターのポート開放（ポート転送）」とは別の話になります。
ポート
同じ住所（IP）でも、用途ごとに入口が分かれているイメージです。
マイクラは通常、Java＝25565/TCP、統合版＝19132/UDP を使います。
DNS（ドメイン）
example.com のような“覚えやすい名前”を、IPに変換する仕組み。
参加者には IP直打ち でも案内できますが、運用が長いなら ドメインをIPに紐づけ（Aレコード） しておくとラクです。
（IPが変わる可能性や、共有のしやすさで差が出ます）
ConoHa VPSで特に大事な点
ConoHaはサーバー単位で通信を制御する仕組み（セキュリティグループ／接続許可ポート）を使います。
つまり、「サーバーを立てた」だけでは入口が閉じていることがあるので、必要なポートを許可する設計が重要です。

ワールド・設定ファイル・ログの「保存場所」概念

ここを理解すると、バックアップや移行、トラブル解決が一気に簡単になります。
結論：マイクラサーバーは“全部ファイル”です。

ワールド：地形・建築・プレイヤーデータ
設定：難易度、ホワイトリスト、各種ルール
ログ：何が起きたかの記録（エラー原因の手がかり）

そして、初心者が押さえるべき“考え方”は次の3つです。

1）保存場所は「VPS内のフォルダ」
VPSはクラウド上のPCなので、ワールドも設定もログも、すべて VPS内のディスク にあります。

2）サーバーの“本体”と“データ”は分けて考える

本体（サーバープログラム）を更新しても、データ（ワールド）を残せば続きができます
逆に、データ（ワールド）を消すと 元に戻りません（だからバックアップが重要）

3）困ったらまずログを見る
接続できない・起動しない・MODで落ちる、などの原因はログに出ることが多いです。
「何が悪いか分からない」を減らす最大の近道です。

目安として、Java版サーバーでは次がよく出てきます（名称だけ覚えればOK）。

server.properties（基本設定）
world フォルダ（ワールド）
logs フォルダ（ログ）

用語だけ先に：Vanilla／Forge／Fabric／Spigot／Paper

検索していると用語が多くて混乱しがちなので、初心者向けに「役割だけ」まとめます。

Vanilla（バニラ）
何も追加しない素のマイクラサーバー。まずはここからが安全。
Forge（フォージ）
Java版向けの代表的な MOD導入基盤（modding API/ローダー系）。
“MODサーバー”と言うとForge系を指すことが多いです。
Fabric（ファブリック）
こちらもJava版向けの MOD導入基盤。軽量志向のMODも多く、選択肢として人気。
Spigot（スポigot）
サーバー側に機能を追加する プラグイン を動かすための定番サーバーソフト（Bukkit系）。
参加者は基本的に 追加導入なし（普通のクライアント） で入れることが多いです。
Paper（ペーパー）
Spigotをベースに性能や機能を強化したサーバーソフト。
安定性・パフォーマンス重視なら候補に上がりやすいです。

「どれを選べばいい？」を最短で言うと、こうなります。

とりあえず安定稼働 → Vanilla（または後でPaper）
新アイテム・新要素など“MODで遊びたい” → Forge / Fabric
参加者に追加導入させず、サーバー側だけ便利にしたい → Spigot / Paper

MODサーバーとプラグインサーバーは“別物”

ここを混ぜると高確率で事故ります。違いはシンプルです。

MODサーバー（Forge/Fabric系）

追加要素（ブロック・アイテム・システム）を大きく変えられる
その代わり、参加者側にも 同じMOD構成 を求めることが多い
バージョン整合がシビアで、更新時に壊れやすい（バックアップ必須）

プラグインサーバー（Spigot/Paper系）

サーバー側だけで機能追加（権限、保護、便利機能など）がしやすい
参加者は通常クライアントで入れるケースが多い
比較的運用しやすいが、MODほど大改造はできない

初心者のおすすめは、まず 「参加者に追加導入が要るか？」で決めることです。

参加者に導入をお願いできる／MODが目的 → MODサーバー
できれば全員そのまま参加してほしい → プラグインサーバー（またはバニラ）

ConoHa VPS 公式サイト

料金とスペック：失敗しないプラン選定（人数×遊び方）

「ConoHa VPSでマイクラを動かしたい」場合、プラン選びで一番大事なのは“人数”よりも“同時接続×遊び方”です。
迷ったら、まずは 4GB を起点に考えると失敗しづらいです（軽量バニラ少人数なら2GBでもOK）。

料金タイプの考え方（時間課金／長期割引）

ConoHa VPSは大きく 2つの料金の考え方があります。マイクラ用途だと、ここを誤解すると「思ったより請求が…」が起きやすいです。

時間課金（1時間単位）

1時間ごとに料金が発生（使った分だけ）
ただし1か月使い続けても月額上限を超えない（上限＝月額料金）
重要：停止（シャットダウン）しても料金は変わりません
→ 料金を止めたいなら「停止」ではなく、基本的に削除（解約）が必要です

まとめトク（長期利用の割引枠）

期間分を一括前払い（月払いの分割は不可）
途中解約不可
更新しないと、期間満了でサーバーが削除される点に注意（うっかり更新忘れが事故りやすい）

料金を見るときの注意（地味に大事）

料金表示にはサービス維持調整費（10%）が含まれます
マイクラ運用では、必要に応じて 自動バックアップ や 追加SSD などのオプション費用も考慮します（最初は無しでOK）

人数目安の決め方（“同時接続”と“プレイ内容”で変わる）

「10人グループ」でも同時に入るのが3人なら、体感負荷は小さくなります。逆に、少人数でも次の条件が重なると一気に重くなります。

探索が多い（新規チャンク生成が頻繁）
交易所・大型トラップ・レッドストーン装置が多い
描画距離（サーバー側設定）が高い
MOD導入・高負荷プラグイン導入（Java版で顕著）

このあと紹介する目安は、「Java版で普通に遊ぶ」前提のざっくり基準です。統合版（Bedrock）は一般に軽めです。

少人数（〜4人）：軽量バニラ中心

おすすめの考え方

基本：2GB（まずここから）
探索多め／装置多め／Java版で重い：4GBへ

軽量で遊ぶコツ

描画距離を欲張らない（“快適さ”と“重さ”が直結しやすい）
大型トラップは段階的に（いきなり全部盛りにしない）

中規模（5〜10人）：軽量プラグイン・探索多め

おすすめの考え方

軽量寄りで調整できるなら：4GB
探索が多い／常時誰か入る／プラグイン多め：12GBを検討

ここで詰まりやすいポイント

“人数”というより、同時接続が5人を超える時間が長いと4GBが苦しくなりやすいです
新規チャンク生成が続くと、CPU/ディスク側の負荷も上がります（体感ラグとして出やすい）

大人数（11人〜）：最適化前提・増強タイミング

おすすめの考え方

最低ライン：12GB
常時稼働＋探索＋装置多め：24GBが視野

増強の目安（感覚）

「夜になると急に重い」「探索が始まるとガクつく」「落ちる・再起動が必要になる」が出たら
→ まず設定見直し → それでも厳しければプランアップ

ラグの主因はどれ？CPU／メモリ／ディスク／回線を切り分ける

「重い＝メモリ不足」と決めつけると遠回りになります。症状で切り分けすると改善が早いです。

CPUが原因っぽい
- 人が増える／装置が動くタイミングでTPSが落ちる
- 探索で新規チャンク生成が続くと重い
メモリが原因っぽい
- 定期的にカクつく（GCっぽい挙動）
- 最悪、プロセスが落ちる／強制終了
ディスクが原因っぽい
- 新規ワールド生成・探索で急に重い
- セーブ時に引っかかる感じが出る
回線が原因っぽい
- 特定の人だけ重い（ping差）
- 全員が重いならサーバー側（CPU/メモリ/ディスク）の可能性が高め

費用を最適化する運用（必要な時間だけ増強／遊ばない日は止める）

必要な時間だけ増強（おすすめ）

ConoHa VPSはプラン変更ができます。
重い日だけ上げて、落ち着いたら戻す、が現実的です（作業時は一度停止が必要）。

メリット：IPや環境を維持したまま強化しやすい
注意：CPU/メモリを“個別に”増やすのではなく、プラン単位で変更になります

遊ばない日は止める（ここは誤解注意）

ConoHa VPSは 停止（シャットダウン）しても課金は変わりません。
「週末だけ遊ぶ」なら、コスト最適化としては次のどちらかが現実的です。

時間課金で：使わない期間は“削除”して料金を止める
- ワールドデータはローカルに退避（バックアップ必須）
- 再作成するとIPが変わる前提で、必要ならDNS運用で吸収
まとめトクで：常時稼働前提で割引を取りに行く
- ただし一括前払い＆途中解約不可なので、利用頻度が低いと割高になりやすい

主要プランの目安（マイクラ用途でよく使う帯）

（数字が多いので、まずは2GB / 4GB / 12GB / 24GBだけ見ればOKです）

スクロールできます

メモリ	CPU	SSD	時間課金（円/時）	時間課金（月額）	まとめトク（月あたり換算）	更新時（月あたり換算）
2GB	3コア	100GB	3.7	2,033	657	903
4GB	4コア	100GB	7.3	3,969	1,184	1,860
12GB	6コア	100GB	14.6	8,083	2,234	3,511
24GB	8コア	100GB	26.7	15,730	5,034	7,910

ConoHa VPS 公式サイト

構築ルート選び：最短テンプレ vs 手動構築（あなたはどっち？）

ConoHa VPSでマイクラを始めるとき、最初に決めるべきは「立て方」ではなく、“どこまで自分で管理するか”です。
同じConoHaでも、選ぶルートで「手間」「自由度」「事故りにくさ」が大きく変わります。

まずは、ざっくり早見表でイメージを掴んでください。

スクロールできます

ルート	こんな人向き	難易度	事故りにくさ	自由度
ルートA（テンプレ＋Minecraft manager）	とにかく早く始めたい／まず安定稼働したい	低	高	中
ルートB（OSから手動）	仕組みから理解したい／細かく最適化したい	中〜高	中	高
ルートC（MOD/プラグイン前提で逆算）	最初から拡張前提／目的が明確	中	中〜高	中〜高

迷ったら、基本は ルートAで開始→必要になったらB/Cへ が失敗しづらいです。
（最初からBにすると、学びは深い一方で「まだ遊べない期間」が伸びがちです）

ルートA：テンプレ＋Minecraft managerで“まず動かす”

結論：初心者の最適解になりやすいルートです。
ConoHa VPSには「Minecraft Java」「Minecraft 統合版（Bedrock）」のアプリケーションイメージが用意されており、サーバー作成時に選ぶだけで土台が整います。さらに、Minecraft manager（管理画面）で基本操作ができます。

ルートAが向いている人

まずはマルチを早く開始したい
コマンド操作に慣れていない（または最小限にしたい）
バニラ中心、または軽い調整で運用したい
運用を「管理画面ベース」で回したい

できること（初心者が困るところを先回り）

サーバーの起動・停止、状態確認
バージョン確認・変更（運用ルールを決めるのが重要）
基本設定（難易度など）
バックアップ運用（自動化の設計がしやすい）

苦手なこと（ここから先はB/C領域）

MOD/プラグインを“自由自在に”入れて運用する（方式選びが必要）
OSレベルのチューニングや高度な監視
こだわった構成（複数サーバー連携、プロキシなど）

つまずかないためのチェックポイント

512MBプランではMinecraftアプリイメージを選べない（最初の落とし穴になりがち）
Minecraft managerのログインは、基本的にroot＋作成時に設定したrootパスワードが基準
「Java版/統合版」を先に固定（後から混ぜようとすると難易度が上がる）

初心者向けのおすすめ進め方

アプリケーションイメージでサーバー作成（Java or 統合版を選ぶ）
Minecraft managerにログインして起動確認
ホワイトリスト運用を先にON（公開事故の予防）
バックアップを設定してから、友だちを招待

この順番にすると、後から何かあっても「戻せる」状態が作れて安心です。

ルートB：OSから手動で“自由度MAX”構築

結論：一番自由だけど、初心者が最初に選ぶと遠回りになりやすいルートです。
OSにSSHで入り、Java導入・サーバーファイル配置・起動設定・セキュリティ設定までを自分で組み立てます。

ルートBが向いている人

仕組みを理解しながら運用したい（学びを優先）
こだわりたい目的がある（高度な最適化、監視、複数ワールド運用など）
MOD/プラグイン運用を“自分の流儀”で作りたい

ルートBのメリット

構成の自由度が最大（起動オプション、監視、ログ設計、アクセス制限など）
トラブル時に「なぜ起きたか」を追いやすい（ログや設定が把握できる）
将来的にマイクラ以外にも転用しやすい（VPSの本領）

ルートBのデメリット（初心者が挫折しやすい点）

最初のセットアップ項目が多い
例：ユーザー管理、SSH設定、ファイアウォール、Java、サービス自動起動、バックアップ…
「接続できない」「起動しない」を自力で切り分ける必要がある
更新時に事故が起きたとき、復旧まで自分で対応する必要がある

初心者がBを選ぶなら“この形”が安全

最初から完璧を目指さず、次の順で段階化します。
ステップ1：バニラで起動（まず遊べる状態を作る）
ステップ2：バックアップ・ログ・自動起動を整備
ステップ3：最適化（必要ならPaperなど）
ステップ4：MOD/プラグイン（目的が固まってから）

いきなりMODを入れて動かないが最も多い事故なので、「まず動く→安全に戻せる→拡張」の順が鉄板です。

ルートC：MOD/プラグイン前提で“方式から逆算”

結論：目的が明確なら、最短で満足度が高いルートです。
「何を入れたいか」が最初から決まっているなら、立て方を逆算した方が失敗しません。

まず決めるべきことは3つだけ

参加者に追加導入を求めるか？
- 追加導入ありでもOK → MOD（Forgeなど）に向く
- できれば追加導入なし → プラグイン（Paper/Spigotなど）に向く
遊び方の重さ（探索多め／装置多め／同時接続多め）
更新方針（頻繁に更新するか／固定するか）

代表パターンとおすすめルート

バニラで快適に、荒らし対策や便利機能を足したい
→ Paper/Spigot系（プラグイン運用）
→ ルートAで開始し、必要になったらC（プラグイン導入）へ
MODで別ゲー級に遊びたい（工業・魔術・大型MODパックなど）
→ Forge系
→ ConoHaにはForge導入済みのゲームテンプレートが用意されているため、テンプレ活用はかなり相性が良い
→ ルートC（テンプレ活用 or 手動）で設計してから始めるのが安全
最初は軽く、あとでMOD/プラグインを考えたい
→ ルートAで安定稼働を作る（バックアップ込み）
→ 需要が固まったらCへ移行（方式選定）

ルートCで事故を減らす運用ルール

バックアップは「ある」だけでなく、復元手順も決める（これが最重要）
バージョンは簡単に上げない（上げるなら“全員同時”＋事前バックアップ）
MOD/プラグインは一気に増やさず、1つずつ導入して動作確認する

ConoHa VPS 公式サイト

ルートA｜テンプレで最短：ConoHa VPSでマイクラを立ち上げる手順

「とにかく早く遊べる状態にしたい」「でも失敗してワールドを壊したくない」人向けに、ConoHaのアプリケーションイメージ（Minecraft）＋Minecraft managerを前提に、最短ルートを整理します。

事前チェックリスト（アカウント／支払い／参加者の版）

まずここだけ揃えると、途中で詰まりにくいです。✅

参加者がJava版か統合版か（混在しないのが基本）
プレイ人数と遊び方
- バニラ中心か、重めの建築・探索が多いか
- MOD/プラグイン予定があるか（あるなら後述の注意）
連絡手段
- アップデートや再起動の告知先（Discord等）
最低限のセキュリティ方針
- 「基本は非公開」＝ホワイトリストONで運用する
- 管理者（OP）を付ける人を最小化する

⚠️ 注意
Minecraftアプリケーションイメージは、軽いプラン（例：メモリ512MB）だとインストール不可のケースがあります。最初から“最低ライン以上”を選ぶのが安全です。

VPS作成：リージョン・プラン・テンプレ選択の判断基準

ConoHaの管理画面で「サーバー追加」→「VPS」を選び、次を決めていきます。

1) リージョン（場所）

基本は参加者に近い地域を選ぶほどラグが減りやすいです。
迷ったら「参加者が一番多い地域」を優先。

2) プラン（スペック）

まずは「遊べる」ことが最重要なので、無理に最小プランを狙わないのがコツ。
人数が少なくても、探索が多い／描画距離が長い／常時稼働などで負荷は上がります。

3) テンプレ（イメージ）

イメージタイプは 「アプリケーション」 を選び、
- Java版なら「Minecraft Java」
- 統合版なら「Minecraft 統合版」
併せて、ネームタグ（後で見分けやすい名前）と rootパスワードを設定します。

4) IPアドレスを控える
作成後、サーバー詳細の「ネットワーク情報」にある IPアドレスは、この後の接続設定で使うのでメモしておきます。📝

Minecraft manager：最初にやるべき初期設定

Minecraft manager は、ConoHaの管理画面から 「管理画面」を開いてログインします。
ログインは ユーザー名：root／パスワード：サーバー作成時のrootパスワード が基本です。

ここから先は、「まず安全に」「次に快適に」の順で設定すると事故が減ります。

サーバーの起動・停止と現在状態の見方

最初にやることはシンプルです。

Minecraftサーバー：起動（初回はワールド生成で少し待つことあり）
状態確認
- 起動中か停止中か
- 接続があるか（機能が対応している場合）

💡運用の基本

設定を変えたら、反映に再起動が必要な項目が多いです。
「変更 → 再起動 → 接続テスト」をワンセットにすると混乱しません。

バージョン変更の安全な手順（事故らない更新）

バージョン更新で壊れやすいのは、だいたいこの3つです。
①ワールドの互換性 ②MOD/プラグイン ③参加者のクライアント版本。

事故を避ける手順はこれです。✅

バックアップを取る（必須）
- 自動バックアップがあっても、更新前は手動バックアップを1つ取るのが安全。
参加者のクライアント版を揃える
- サーバーだけ上げても、参加者が古い版だと入れません。
更新は“1回で大きく飛ばさない”（不安なら段階的に）
- 問題が出たらすぐ戻せるよう、直前バックアップを残します。
更新後に必ず確認
- ログにエラーがないか
- 実際に自分が接続して、スポーン・チェスト・権限まわりを軽くチェック

⚠️補足
ConoHaには古いテンプレ向けのアップデートスクリプト案内もありますが、Minecraft managerが入っているテンプレでは想定通り動かない注意があるため、基本は Minecraft manager側の操作を優先したほうが安全です。

ゲーム設定（難易度・ゲームモードなど）の調整

Minecraft manager から代表的なゲーム設定を触れます（例：PvP、ゲームモード、難易度、ワールド関連など）。

おすすめの決め方は次の通りです。

初心者が多い：難易度は「ノーマル」か「イージー」から
建築メイン：PvPはOFFにしてトラブルを防ぐ
探索が激しい：無理に設定を重くしない（重い設定はラグの原因）

⚠️重要
設定によっては 再起動が必要です。
また、統合版（Bedrock）は項目によって ワールド再生成が必要になることがあるため、変更前にバックアップ推奨です。

ホワイトリスト運用（公開しない基本設計）

最初からホワイトリストをONにすると、荒らし・侵入リスクが激減します。🔒

手順（ざっくり）

「ホワイトリスト」→「ユーザ追加」→ 参加者名を登録
その後、ホワイトリストをON
反映に再起動が必要な場合あり

運用のコツ

参加者のID（Java）やゲーマータグ（統合版）を正確にもらう
新規参加者追加のたびに、管理者が手順を固定化（誰がいつ追加するか）

管理権限（OP）を安全に付与する

OP（オペレーター権限）は便利ですが、付けすぎると事故の原因になります。⚠️

おすすめルール

OPは最小人数（できれば1〜2人）
必要な作業が終わったら、OPを外す運用も検討
管理用のIDを分けられるなら分ける（普段用と管理用）

※機能として、Minecraft managerのOP設定は Java版（＋一部方式）向けで、統合版では利用できないケースがあります。

バックアップ：自動／手動／復元までをセットで理解

バックアップは「取る」だけだと半分で、復元（リストア）できて初めて安心です。

自動バックアップ

ダッシュボードの「自動バックアップ」でスケジュールを設定
保存数（世代）も調整できるので、運用に合わせる

手動バックアップ（重要）

更新前、設定変更前、イベント前など「節目」に取る
名前を付けておくと、戻すとき迷いません（例：before_update_1.XX）

復元（リストア）

「バックアップ一覧」から対象を選んでリストア
リストアは基本的に現在のワールドが置き換わるので、タイミングは慎重に

ログ：確認・ダウンロード・原因切り分けに使う

トラブル時の最短ルートは「勘」ではなくログです。🧩

Minecraft manager から

Minecraft managerのログ
Minecraftサーバーのログ
をダウンロードできます。

よくある切り分け例

入れない：版本不一致／ポート閉じ／ホワイトリスト未登録
落ちる：メモリ不足／設定の反映ミス／更新直後の互換トラブル
重い：探索・描画負荷／人数増加／設定が重い

参加方法：クライアントから接続（IP:ポート／ドメイン）

接続に必要なのは基本これだけです。

サーバーIPアドレス（ConoHaの管理画面で確認したもの）
ポート
- Java版の定番：25565（通常は省略できることが多い）
- 統合版の定番：19132（入力が必要なことが多い）

まずはIP直打ちで接続（最短）

Java版：マルチプレイ → サーバー追加 → アドレスにIP（必要なら:25565）
統合版：サーバー追加 → サーバーIPにIP → 保存 → 接続

ドメインで入りやすくする（慣れてきたら）

「数字のIPが覚えづらい」なら、DNSで

Aレコード：play.example.com → サーバーIP
のように設定すると便利です。

ConoHa VPS 公式サイト

ルートB｜手動構築：OSからMinecraftサーバーを入れる（中上級者向け）

このルートは、「自分で運用の土台を固めたい」人向けです。テンプレより手間は増えますが、そのぶん、

余計な公開リスクを減らせる
トラブル時に原因を追いやすい
MOD/プラグインや最適化に広げやすい

という強みがあります。

以降は、初心者でも迷いにくいように “ロックアウトしない順番” と “最小の安全設計” を軸に説明します。

最初のセキュリティ設計（root依存をやめる）

最初に覚えるべき考え方はこれです。

rootは「初期設定のための鍵」
普段の運用は「一般ユーザー＋sudo」
サーバー実行は「専用ユーザー（minecraft等）」

この3段構えにすると、万が一パスワード漏洩や鍵流出が起きても被害を抑えやすくなります。

一般ユーザー作成とsudo設計

（例：Ubuntu/Debian系の流れ。OSが違っても考え方は同じです）

まず更新

sudo apt update && sudo apt -y upgrade

管理用ユーザーを作る（例：adminuser）

sudo adduser adminuser
sudo usermod -aG sudo adminuser

sudoが効くか確認

su - adminuser
sudo -v

マイクラ用の専用ユーザー（例：minecraft）を作る

ポイント：このユーザーにはsudoを付けない（権限を分離）

sudo adduser --system --home /opt/minecraft --group minecraft

SSHは鍵認証＋ポート・許可元の見直し

ここで一番怖いのは 「設定を変えて自分が入れなくなる」ことです。
安全な順番で進めると事故が激減します。

ロックアウトを防ぐ手順（超重要）

ConoHa側（セキュリティグループ）で、SSHの入口を先に用意する
鍵ログインで入れることを確認する
その後に、パスワードログインやrootログインを閉じる

やること（おすすめセット）

SSH鍵認証にする（パスワード認証はOFFへ）
rootでのSSHログインを禁止
SSHポートを変更（22のままでも可だが、攻撃が増えがち）
接続元IPを絞る（可能なら“自宅IPのみ”など）

最低限の設定例（sshd_configのイメージ）

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
Port 2222（例）
AllowUsers adminuser

⚠️注意
SSHポート変更は ConoHa側（セキュリティグループ）とOS側（UFWなど）両方 を先に通してから切り替えます。片方だけだと詰みます。

ファイアウォール：必要ポートだけ通す

ここも大事な考え方があります。

通信の壁は2枚ある

① ConoHaのセキュリティグループ（クラウド側の入口）
② VPS内のソフトウェアFW（OS側の入口）

「片方だけ開けた」状態が、初心者の“入れない”原因になりやすいです。

Java版の基本（25565/TCP）

Java版サーバーの基本は 25565/TCP を許可します。
例：UFWを使うなら

sudo ufw default deny incoming
sudo ufw default allow outgoing

# SSH（例：2222）を“自分のIPだけ”許可
sudo ufw allow from <あなたのIP>/32 to any port 2222 proto tcp

# Minecraft Java
sudo ufw allow 25565/tcp

sudo ufw enable
sudo ufw status verbose

ConoHa側（セキュリティグループ）でも 25565/TCP をIN許可してください。

統合版の基本（19132/UDP）

統合版（Bedrock）の基本は 19132/UDP です。
UFW例：

sudo ufw allow 19132/udp

ConoHa側も 19132/UDP をIN許可します。

“開けたのに入れない”時の典型チェック

「開放したのに接続できない」ときは、順番に潰すと早いです。

チェック1：そもそもサーバーが起動している？

systemctl status（後述の自動起動化をしている場合）
まだなら ps aux | grep java などで確認

チェック2：待ち受け（LISTEN）してる？

Java：ss -lntp | grep 25565
統合：ss -lnup | grep 19132

チェック3：プロトコルを間違えてない？

Javaは基本TCP、統合は基本UDP
「25565をUDPで開けた」などが意外と多いです

チェック4：ConoHa側とOS側、両方開けた？

ConoHaセキュリティグループ：IN許可があるか
OSファイアウォール：UFWやfirewalldで許可があるか

チェック5：接続情報が正しい？

IP/ドメイン
ポート番号
版（Java/統合）が一致しているか

Java導入→サーバー本体配置→初回起動（EULA含む）

1) Javaを入れる（バージョンの考え方）

ここは「最新なら最新でOK」ではなく、Minecraftの世代に合うJavaが必要です。

最近のPaper/新しめのMinecraftでは Java 21 が必要になることがあります
古いバージョン（例：1.18～1.20前半など）は Java 17 で動くことが多い

迷ったときの判断はシンプルで、起動時エラーに従うのが確実です。
（例：UnsupportedClassVersionError が出たらJavaが古い）

Ubuntu/Debian系の一例：

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

2) サーバー置き場を作る（専用ユーザーで運用）

sudo mkdir -p /opt/minecraft/server
sudo chown -R minecraft:minecraft /opt/minecraft

3) サーバー本体（jar）を配置

公式のサーバー配布元から server.jar を取得し、/opt/minecraft/server/ に置きます
可能ならハッシュ（checksum）で検証すると安心です

4) 初回起動 → EULA同意

初回起動で eula.txt や server.properties が生成されます。

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

その後、eula.txt を開いて eula=true に変更し、再起動します。
EULAに同意しないとサーバーは起動できません。

常時運用：自動起動・停止・再起動の仕組み化

「手動起動のまま」は、落ちたときに気づけず、再起動忘れも起きやすいです。
VPS運用では systemd化 が定番で、安定します。

systemdサービス例（イメージ）

/etc/systemd/system/minecraft.service（例）：

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

[Service]
User=minecraft
WorkingDirectory=/opt/minecraft/server

# メモリはプランに合わせて調整
ExecStart=/usr/bin/java -Xms2G -Xmx2G -jar server.jar nogui

Restart=on-failure
RestartSec=10
Nice=5

[Install]
WantedBy=multi-user.target

有効化・起動：

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

ログ確認（困ったらここ）：

journalctl -u minecraft -e

アップデート手順とロールバックの逃げ道

アップデートで一番大事なのは、「戻れる状態を作ってから上げる」ことです。
おすすめの安全手順はこれです。

1) 事前告知（参加者に周知）

更新日時、再起動予定、バージョン固定の有無

2) 停止 → バックアップ（“復元できる形”で）

サービス停止：sudo systemctl stop minecraft
world/、server.properties、whitelist.json、ops.json（あれば）を固めて退避

3) server.jarを差し替え

旧jarは残す（例：server.jar.bak）

4) 起動 → 動作確認

起動ログにエラーがないか
自分が接続して、ワールド/権限/スポーンを軽く確認

5) 問題があればロールバック

jarを元に戻す
ワールドも必要に応じてバックアップから復元

⚠️注意
バージョンによっては 「一度ワールドを上げると戻せない」 ことがあります。
アップデート前バックアップは“必須”として運用してください。

ConoHa VPS 公式サイト

MOD・プラグイン：導入前に決めるべきこと（事故防止パート）

ConoHa VPSでマイクラを運用していて、一番トラブルが増えやすいのが 「拡張（MOD/プラグイン）を入れ始めた瞬間」です。
理由はシンプルで、拡張は「便利」と引き換えに 互換性・更新・負荷 の3点が一気に難しくなるから。

この章では、導入前に決めるべきこと→安全に入れる手順→重くなった時の対処までを、最短で整理します。

方式選び：Forge／Fabric／Paper(Spigot系)の選び方

まず、MODとプラグインは別物です。

MOD（Forge/Fabric）
- サーバー側だけでなく、参加者側にも導入が必要なものが多い
- バージョン整合がシビア（Minecraft本体／ローダー／MOD同士）
プラグイン（Paper/Spigot系）
- 基本的に参加者は バニラ（素のクライアント）で参加できる
- 便利機能や負荷軽減がしやすい（反面、できることの種類がMODと違う）

選び方は、次の質問に答えるだけでほぼ決まります。

質問1：参加者に「追加導入」をお願いできる？

できる → MOD方式（Forge/Fabric）が候補
難しい／嫌がられそう → Paper（プラグイン）が第一候補

質問2：やりたいことは「別ゲーム級の追加要素」？「快適化や便利化」？

工業・魔術・大型要素・MODパック → Forge寄り
軽量な追加要素、最適化、QoL中心 → Fabric寄り
荒らし対策、権限管理、快適化、サーバー機能追加 → Paper寄り

ざっくり結論（迷った人向け）

快適に遊びたい・参加が簡単な方がいい → Paper
軽めの改造で安定させたい → Fabric
大型MODで遊ぶのが目的 → Forge

※補足：Javaサーバーに統合版（Switch/PS/Xbox/スマホ）から入れたい場合は、Paper側で「変換系プラグイン（例：Geyser系）」を使う選択肢があります。ただし構成が一段難しくなるので、最初は“Javaのみ”で安定させてからの導入が安全です。

導入前の必須作業（バックアップ／バージョン整合／検証環境）

導入前に、最低限これだけやると事故率が激減します。

1) バックアップは「取得」ではなく「復元まで」確認

ワールド（world系フォルダ）
サーバー設定（server.properties など）
権限/許可系（whitelist/ops/permissions系）
プラグインやMODの設定（plugins/ mods/ config/）

おすすめ運用

導入前バックアップを「導入名付き」で残す（例：before_add_spark）
1回だけでも「別フォルダに戻して起動できる」ことを試す
→ これができると、心理的に運用が楽になります

2) バージョン整合を「3点セット」で固定する

Minecraft本体のバージョン
ローダー（Forge/Fabric）やPaperのバージョン
MOD/プラグインのバージョン

よくある事故

サーバーだけ更新して、参加者が入れない
MODだけ更新して、ワールドが壊れる／起動しない
プラグインが未対応でエラー連発

対策は簡単で、「更新は月1回」など頻度を決めて、普段は固定が強いです。

3) 検証環境（テスト用）を用意する

本番サーバーでいきなり試さないのが最重要です。

同じ構成の“テスト用ディレクトリ”を作る
例：/opt/minecraft/server_test/
もしくはConoHa VPSを複製できるなら、短時間だけ検証用を立てる

テストで見るポイント

起動するか（ログに赤字がないか）
ワールドに入れるか
10分放置しても落ちないか
TPSが極端に落ちていないか

ファイル操作：SFTPでアップロード・編集する基本

MOD/プラグイン運用は、結局「ファイル操作」が中心になります。
初心者が詰まりやすいのは、操作自体ではなく “安全な手順”を知らないことです。

まずは安全な型を覚える

サーバー停止（導入・設定変更の前は止めるのが基本）
ローカルに控えを取る（今の状態を保存）
ファイルをアップロード／編集
権限・改行コード・文字化けがないか確認
起動してログ確認
接続テスト

SFTPでよく使うツール

Windows：WinSCP / FileZilla
macOS：Cyberduck など

接続で必要な情報

ホスト：VPSのIP（またはドメイン）
ユーザー：作成した一般ユーザー（推奨）
認証：鍵認証（推奨）
ポート：SSHポート（変更している場合はその番号）

“編集ミス”を減らすコツ

設定ファイルは直接編集せず、ダウンロード→編集→アップロードが安全
編集前に .bak を残す（例：server.properties.bak）
日本語を含むパス・空白があると、特定のツールやスクリプトで詰まることがある
→ ディレクトリ名は英数字が無難

導入フロー（代表例）

ここからは「やることが見える」ように、代表的な流れを短くまとめます。

Forge：MODサーバーを運用する最短手順

Minecraftのバージョンを決める（MODパック基準で決めるのが楽）
対応するForge Installerを入手
サーバー用ディレクトリを作る（例：/opt/minecraft/forge_1xx/）
Installerをサーバーとして展開（ヘッドレスなら --installServer を使う）
初回起動 → eula=true → 再起動
mods/ にMODを入れる（サーバー用／クライアント用の区別に注意）
参加者には「同じMinecraft本体＋同じForge＋同じMOD」を配布
テスト参加 → ログ確認 → 本番へ

（例コマンドのイメージ）

java -jar forge-xxxx-installer.jar --installServer

ポイント

MODは「一気に20個」より「1個ずつ」入れて動作確認が最強
まずは軽い構成で起動に成功してから増やす

Fabric：軽量MODで安定させる手順

Fabric Installerで「Server」を選んでセットアップ
初回起動 → EULA同意 → 再起動
mods/ にFabric用MODを入れる（Fabric APIが必要なMODが多い）
参加者にも同じMODを導入してもらう
軽量化MOD中心なら、まず“安定稼働”を作ってから追加

ポイント

Fabricは軽量路線と相性がよく、構成がシンプルになりやすい
Minecraftの世代によって推奨Javaが変わるので、指示に従って揃える

Paper/Spigot：プラグインで快適化する手順

Paperのjarを用意して、サーバーディレクトリに置く
初回起動 → eula=true → 再起動
plugins/ フォルダにプラグインを入れる
起動後、各プラグインの設定ファイルを調整
負荷を見ながら、必要なものだけ残す（入れすぎは逆効果）

ポイント

1.21以降のPaperは、プロファイラ（spark）が同梱されていて原因調査がしやすい
「便利だから」と入れ過ぎると、逆にTPSが落ちることがある

重くなった時の処方箋（メモリ割当／view-distance／最適化設定）

「重い」には種類があるので、闇雲にプラン変更する前に、効く順番で手を打つのがコスパ良いです。

まず効く3点セット

メモリ割当を適正化
- VPSメモリを全部Javaに渡さない（OSが息できなくなる）
- 例：4GBなら、Javaに2.5〜3GB程度から試す…など、“余白”を残す
view-distanceを下げる
- 遠くまで見せるほど重くなる（探索や拠点が増えるほど効く）
simulation-distanceを下げる
- エンティティ（動物・村人など）の更新範囲を減らす
- 体感を損ねにくい割に、CPU負荷が落ちやすい

※値の最適解はサーバーごとに違うので、まずは「少し下げて様子見」を繰り返すのが安全です。

Paper運用で効きやすい追加ポイント

エンティティ過多（村人・動物・トロッコ・アイテム）を疑う
自動化装置が多い拠点は、負荷が集中しやすい
プラグインが定期処理で重くなっている場合がある

“TPSが落ちる”原因の見つけ方

TPS低下は、原因を当てに行くより「測って潰す」方が早いです。

おすすめの切り分け順

いつ落ちる？（夜だけ／探索時だけ／拠点に集まると落ちる）
CPUが張り付いている？（top/htopで確認）
メモリが足りない？（スワップが発生していないか）
ディスクI/Oが詰まっていない？（ワールド保存やログ肥大化）
MOD/プラグインが重い？（プロファイラで特定）

Paperなら、sparkでプロファイルを取って「重い処理の犯人」を特定しやすいです。
犯人が分かれば、対処はだいたい次のどれかに落ちます。

設定で負荷を下げる（距離・エンティティ・周期）
問題のプラグインを更新／代替する
入れたプラグイン（MOD）を減らす
どうしても必要ならプラン増強

ConoHa VPS 公式サイト

安全・安定運用

荒らし対策の基本3点（公開しない／権限最小／ログ確認）

マイクラ鯖のトラブルは、だいたいこの3つで防げます。

公開しない：参加者を「許可制」にする（＝誰でも入れる状態にしない）
権限最小：OP（管理権限）を配りすぎない／一時的に付与する
ログ確認：不正の兆候を「早めに気づける」運用にする

加えて、VPS側でも最低限やっておくと安心です。

開けるポートを必要最小限にする（ゲーム用＋管理用だけ）
管理用（SSH）は接続元IPを絞る（できれば固定IPやVPN経由）

ホワイトリスト運用を標準にする

「ホワイトリスト＝招待制」を標準にすると、荒らし対策が一気に楽になります。

参加者は ホワイトリストに登録した人だけ 入れる
公開IPが知られても、基本的に突破されにくい
何かあっても「ホワイトリスト整理」で即座に収束できる

運用のコツはこの2つだけです。

新規参加は必ず追加→確認→入室の順（いきなり入らせない）
ホワイトリストON/OFFの切り替えや反映条件（再起動など）を把握しておく

もし「身内だけ」のつもりなら、最初からホワイトリスト前提で設計するのが最短です。

権限（OP）を配りすぎないルール

OPは便利ですが、配りすぎると事故が起きます（コマンド誤爆、設定変更、権限の連鎖など）。

おすすめルール（そのまま採用OK）：

OPは 原則1〜2人（共同管理でも最大3人まで）
OP付与は 「作業するときだけ」（終わったら外す）
重要作業（バージョン更新／MOD追加／復元）は OPが2人いる場で実施（保険）

プラグイン運用（Paper/Spigot系）の場合は、さらに安全にできます。

OPを増やすより、権限プラグインで“できること”を小分けにする
（例：テレポだけ許可、キックだけ許可、など）

BAN・追放・復旧の手順を決めておく

荒らし対応は「その場のノリ」でやると長引きます。先に型を決めておくと、数分で収束します。

おすすめの対応フロー（テンプレ）

状況確認：誰が・いつ・何をしたか（ログ／目撃／スクショ）
いったん隔離：追放（kick）で即退場
再侵入を止める：BAN（必要ならIP BANも）
被害を止める：ホワイトリストON＋怪しいユーザー削除
復旧：バックアップから戻す（戻す範囲を決めて実行）

最低限のコマンド例（Java版の専用鯖想定）：

/kick <player> <理由>
/ban <player> <理由>
/ban-ip <IP または player> <理由>
/banlist
/pardon <player>
/pardon-ip <IP>

復旧判断の基準も決めておくと迷いません。

破壊が軽い → 手作業修復
破壊が広い／ログ追跡が面倒 → バックアップ復元が早い

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

バックアップは「取る」より “戻せる” が重要です。設計はこの3点で決まります。

頻度（どれくらい失ってOK？）：RPO（許容できる巻き戻り時間）
復旧時間（どれくらいで直したい？）：RTO（復旧にかけられる時間）
保存先（同じ場所に置かない）：VPS内だけだと事故に弱い

目的	手段	頻度の目安	保管の考え方	ポイント
日常の事故対策	ゲームデータの自動バックアップ	毎日〜数日に1回	直近14世代など	まずはこれが最重要
更新・導入前の保険	手動バックアップ	更新の直前	1〜3世代でもOK	“作業前に必ず取る”
VPS障害・全損対策	VPSの自動バックアップ（オプション等）	週1など	世代数に注意	鯖ごと戻せるのが強い
乗っ取り・操作ミス対策	オフサイト退避（ダウンロード）	月1〜大更新前	手元 or クラウド	「別の場所」に置く

復元テストをサボらないコツ

月1回だけ「復元できるか」を確認する
（本番に当てない：別環境、または別ワールド名でチェック）
できれば “復元手順を手順書化”して、誰でも戻せる状態にする

監視の目安（CPU/メモリ/ディスク/ネットワーク）

監視は「ずっと見張る」より、異常に気づく仕組みが大事です。

まず見るべき指標（迷ったらこれだけ）

CPU：高止まりが続く（探索が多い／MODが重い／TPS低下）
メモリ：空きが少ない状態が続く（GC頻発→カクつき）
ディスク：残量不足／I/Oが張り付く（ログ肥大・バックアップ増加）
ネットワーク：急な増加（不正アクセスの兆候になることも）

目安のしきい値（通知設定の叩き台）

スクロールできます

指標	通知の目安（例）	補足
CPU	90%超が5分継続	瞬間スパイクは無視してOK
メモリ	85〜90%超が10分継続	常時ギリギリは危険信号
ディスク	使用率80%超で注意、90%で緊急	ログ・バックアップで急増しがち
ディスクI/O	張り付きが続く	探索多め＋低速ストレージで起きやすい
ネットワーク	普段と違う増え方	DDoS等は別対策も検討

ついでにやると効く“ログ肥大”対策

バックアップを 溜めっぱなしにしない（古い世代は削除）
ログを見て「何が起きたか」を説明できるようにする
（参加／権限変更／BAN／エラーのタイミング）

運用ルール（管理者交代／パスワード／更新手順の文書化）

ここを固めると、トラブル時の復旧が早くなり、「責任ある運用」として説得力が出ます。

管理者交代（引き継ぎテンプレ）

管理者一覧（連絡先／担当範囲）
OP付与の基準（誰に・いつ・何のために）
VPSログイン方法（誰の鍵／どのユーザー）
バックアップ場所（どこに・何世代・復元手順）
緊急時の判断（復元する基準／停止する基準）

パスワード・鍵の基本ルール

root直運用を避け、一般ユーザー＋sudoを基本にする
SSHは 鍵認証を前提にする（可能ならrootログイン禁止）
管理用ポート（SSH）は 接続元IPを絞る（できる範囲でOK）
共有しない：パスワードは口頭・チャットでばらまかない（管理ツールに集約）

更新手順（事故らない型）

更新で事故るパターンはだいたい「バックアップ不足」「互換性未確認」「戻し方が決まってない」です。型はこれでOKです。

事前バックアップ（手動で1つ取る）
メンテ告知（身内でも一言あると揉めない）
更新は1つずつ（Minecraft本体→プラグイン→設定）
動作確認（ログ／接続／TPS）
問題があればロールバック（戻す対象と手順を決めておく）

ConoHa VPS 公式サイト

よくあるトラブル集：症状→原因→対策の順で解決する

この章は「まず直す」ための実戦パートです。
症状 → ありがちな原因 → 最短チェック → 対策の順で並べています。

接続できない（タイムアウト／拒否）

接続トラブルは、だいたい次の4系統に分かれます。

入力ミス（IP/ポート/版）
サーバー側が動いていない
ポートが通っていない（ConoHa側＋OS側）
クライアント側でブロック（セキュリティソフト等）

IP・ポート入力ミス（ありがちな見落とし）

よくある原因

Java版なのに統合版の接続先を見ている（逆も同様）
ポート番号を付け忘れ、または違う番号を入れている
全角記号（：）や余計な空白が混ざっている
ドメイン運用で、DNSがまだ反映されていない

最短チェック

Java版：アドレスが IP か IP:25565 になっているか
統合版：サーバーIPとポート（通常19132）を分けて入力しているか
そもそも「参加者が同じ版」か（Java/統合の混同が最多）

対策

いったん IP直打ちで接続を成功させる（DNSは後回し）
ポートは次を基準に再確認
- Java版：25565（TCP）
- 統合版：19132（UDP）

サーバーが起動していない／落ちている

よくある原因

まだ起動していない（初回は生成で時間がかかる）
更新直後に落ちた（EULA未同意／互換性エラー／メモリ不足）
MOD/プラグイン追加後に起動しなくなった

最短チェック

管理画面で「稼働中」になっているか
Minecraft manager（使っている場合）で状態が「起動」になっているか
ログに 赤字（エラー）が出ていないか

対策

まず 再起動（軽い詰まりならこれで直ることがある）
起動しない場合は、直前にやった作業を1つ戻す
- 追加したMOD/プラグインを外す
- 更新したjarを元に戻す
それでもダメなら、バックアップから復旧（最後の安全弁）

ファイアウォール・ポート未開放

ここは初心者が一番つまずくポイントです。理由はこれ。

通信の壁が2枚ある

ConoHa側（セキュリティグループ）
VPS内（OS側ファイアウォール：UFW/firewalld等）

よくある原因

ConoHa側だけ開けた（OS側が閉じてる）
OS側だけ開けた（ConoHa側が閉じてる）
TCP/UDPを取り違えた

最短チェック（順番が大事）

ConoHaのセキュリティグループで、該当ポートが IN方向で許可されているか
VPS内ファイアウォールで、該当ポートが許可されているか
プロトコルが合っているか（Java＝TCP、統合＝UDP）

対策

Java版：25565/TCP を許可
統合版：19132/UDP を許可
SSHは、できれば 接続元IPを絞って開ける（安全性が上がります）

セキュリティソフトがブロック

よくある原因

参加者のPCのファイアウォールが、Minecraft/Javaの通信を遮断
学校・職場・公共Wi-Fiなどで、ゲーム系ポートが制限されている
VPNの影響で接続が不安定

最短チェック

同じ接続先に「別の回線（スマホテザリング等）」から入れるか
同じ人だけ入れないか（＝クライアント側原因の可能性が高い）

対策

Windowsなら、ファイアウォールでMinecraft/Javaを「許可」する
可能なら、制限の少ない回線で試す（特に公共Wi-Fi）
それでもダメなら、サーバー側の問題ではなく クライアント側の制限を疑う

ホワイトリストに入れない／BANされている

ここは「設定の思い込み」で起きやすいです。

よくある原因

ホワイトリストに追加したのに、ホワイトリスト自体がOFFのまま
反映に再起動が必要なのに、再起動していない
Java版のIDと、統合版のゲーマータグを混同している
以前BANしたまま解除していない

最短チェック

ホワイトリストがONか
追加した名前が正しいか（大文字小文字・スペース含む）
反映のために再起動が必要な方式か
BANリストに残っていないか

対策（運用ルールにすると強い）

追加手順を固定：追加 → ON確認 → 再起動 → 接続確認
管理者は最小人数（OPを増やす前に、役割分担を決める）
BAN/解除の担当者・手順を決めておく（揉めない）

バージョンが合わない（クライアントとサーバーの不一致）

よくある原因

サーバーだけ更新した／参加者だけ更新した
MOD/ローダー（Forge/Fabric）のバージョンが一致していない
Paper/プラグインの対応が追いついていない

最短チェック

エラー文言の確認
- “Outdated client / Outdated server” 系 → Minecraft本体が不一致
- “Incompatible FML modded server” 系 → Forge/Fabric/Mod構成が不一致
サーバー側と参加者側の「3点セット」が揃っているか
- Minecraft本体
- ローダー（Forge/Fabric）またはPaper
- MOD/プラグインのバージョン

対策

まずは 全員が同じMinecraft本体バージョンに揃える
MODサーバーなら、配布するべきものを固定する
- 参加者へ「同じローダー＋同じMOD一式」を渡す
更新頻度を下げるのが最大の安定化策
- 「月1回まとめて更新」など、運用ルール化すると事故が激減します

ラグい・落ちる（メモリ不足／CPU高負荷／設定過多）

まず結論：ラグの原因は「メモリ不足」だけではありません。
症状で切り分けすると、無駄な増強を避けられます。

症状 → 疑う順

探索でカクつく → CPU/ディスク（新規チャンク生成）
拠点で急に重い → エンティティ過多／装置／プラグイン処理
定期的にカクつく → メモリ（GC）／負荷の波
人が増えると落ちる → メモリ不足 or CPU不足

最短チェック

CPU使用率が張り付いていないか
メモリが常にギリギリで、スワップが発生していないか
ディスク空き容量が不足していないか（ログ・バックアップで増えがち）
view-distance / simulation-distance を上げすぎていないか

対策（効く順に）

設定を軽くする
- view-distance を下げる
- simulation-distance を下げる
重い原因を減らす
- 村人・動物・アイテムの増えすぎを整理
- 常時稼働の装置を見直す
- プラグイン/MODを一度に増やさず、1個ずつ導入して検証
メモリ割当を適正化（手動構築の場合）
- VPSメモリを全部Javaに渡さない（OSの余白が必要）
それでも無理なら プラン増強（最後にやるとコスパが良い）

ワールド破損・巻き戻し（バックアップから復元）

よくある原因

更新後に互換性問題が起きた（戻せないケースもある）
MOD/プラグイン導入でデータ破損
強制終了・ディスク逼迫でセーブに失敗

最短チェック

直前に「更新」「MOD追加」「設定変更」をしていないか
ログにワールド読み込みエラーが出ていないか
ディスク容量が枯渇していないか

対策（復元の基本手順）

サーバー停止（まず被害拡大を止める）
直前バックアップを選ぶ
- 迷ったら「破損が起きる前」の日時へ
復元（リストア）実行
起動して確認（ログ／接続／ワールドの整合）
もし再発するなら、原因（更新・MOD等）をいったん取り除く

運用のコツ

バックアップは「ある」だけでなく、復元テストを月1回でもやる
→ 本当に戻せると、トラブル対応が早くなります

ConoHa VPS 公式サイト

FAQ：検索されやすい疑問を先回り

月いくらから始められる？最小構成の考え方

結論、「とにかく最安」よりも“マイクラがちゃんと動く最小ライン”で考えるのが失敗しにくいです。

ConoHa VPS（テンプレ運用）での実質的な最小ライン
- Minecraft（Java）アプリケーションイメージは、512MBプランではインストールできません。
- そのため、テンプレ＋Minecraft managerで始めるなら1GB以上が現実的な起点です。
料金の見方（ここで混乱しがち）
- 時間課金（スポット）：使った分だけ（ただし月額を超えない仕組み）。
- まとめトク等（前払い）：契約期間分を一括前払い。途中解約ができない等の制約あり。
超ざっくりの目安（「まず動かす」前提）
- まずは 1GB〜2GB のどちらかでスタート
- 「人数が増えそう」「探索・自動化が多い」「MOD/プラグインを入れたい」なら、最初から余裕を持たせる（あとで増強も可能）

参考：公式が提示している料金例（2026年2月10日時点の表示）
※キャンペーン・契約期間で変動するので、表示価格は必ず公式で再確認してください。

人数が増えたら何を変える？（プラン・設定・方式）

増員時は「いきなり上位プラン」より、ボトルネックを潰す順番が大事です。

1) まず“増強”より先にやること（体感が変わりやすい）

✅ 同時接続のピーク（何人が同時に入るか）を把握
✅ サーバー設定の見直し
- 例：view-distance / simulation-distance を控えめにする
- エンティティ（動物・村人・装置）を増やしすぎない運用ルールにする
✅ ワールドを重くする要素を整理
- 大規模TT・常時稼働装置・無限増殖系・常時稼働トラップなど

2) 次に“プラン変更”を検討する（増員に強いのはどこ？）

ラグが悪化 → まずはメモリ不足を疑う（GCが頻発しやすい）
TPSが落ちる／処理落ち → CPU負荷が主因のことも多い
- 人数が増えたタイミングで顕在化しやすいです

※ConoHa VPSのプラン変更は、基本的に停止状態で行う流れです。

3) 方式そのものを変える（増員・快適化の切り札）

バニラで限界を感じたら
- ✅ 軽量化寄り（例：Paper系）へ移行して最適化
MODを増やしたいなら
- ✅ Forge / Fabric 前提で「増員＝増強」が必要になりがち（プラン設計を早めに）

途中でプラン変更・停止した場合の料金は？

ここは誤解が多いので、要点だけ整理します。

停止（シャットダウン）＝課金停止ではない

ConoHa VPS（等）は、停止しても料金は変わらない（稼働・停止に関わらず契約数で発生）という案内です。

「課金を止める」選択肢はどれ？

時間課金（スポット）
- 使った分だけ課金（ただし月額上限あり）。
- 完全に止めたいなら、最終的にはサーバー削除が必要です。
まとめトク等（前払い）
- 原則、契約期間分を前払いで、途中解約不可の注意書きがあります。

プラン変更の注意

変更時は停止が必要、などの条件があります。
また、512MBプランと1GB以上の相互変更ができない制約があります。

ConoHa for GAMEへ移行したい／戻したい時の考え方

「どっちが上？」ではなく、運用スタイルで決めるのが正解です。

ConoHa for GAMEへ“寄せる”と楽になること

✅ ゲーム用途に寄った管理（迷いやすい初期設定や運用がラクになりやすい）
✅ Minecraft向けの料金表示・プラン選びが直感的（※価格はキャンペーン等で変動）

ConoHa VPSへ“戻す/残す”と強いこと

✅ OSから自由に組める（複数サーバー、細かなセキュリティ設計、周辺ツール連携など）
✅ MOD/プラグイン含めて「全部自分で管理したい」人に向く

データ移行の考え方（失敗しないコツ）

最優先：ワールドのバックアップを取ってから動く（復元できる状態にして着手）
ConoHa for GAMEには「Minecraft専用かんたんデータ移行」の案内がありますが、100%の動作保証ではない旨が明記されています。
また、対応条件（対象テンプレ、PC版のみ等）があるので、移行前に要件チェックが必須です。

ConoHa VPS 公式サイト

まとめ：失敗しない3原則（プラン／セキュリティ／バックアップ）

最後に、ConoHa VPSでマイクラを“長く快適に”運用するための結論を、3原則に絞って整理します。
この3つを押さえるだけで、初心者がつまずきやすい事故（重い・入れない・壊れた）をかなり減らせます。

原則1：プランは「人数」ではなく「同時接続×遊び方」で決める

失敗パターンは、最安プランで始めて、途中から常に不安定になることです。
おすすめは “まず安定稼働できる最低ライン”から始め、必要に応じて増強する考え方です。

✅ 基準は「同時接続」と「負荷のかかる遊び方」
- 探索多め（新規チャンク生成が増える）
- 村人・動物・装置が多い
- 描画距離・simulation-distanceが高い
- MOD/プラグインを入れる
✅ 迷ったら「余白」を取る
- VPSはOSも動くので、メモリをギリギリにしない方が安定します
✅ 重くなったら“増強の前に”設定を見直す
- view-distance / simulation-distance
- エンティティ過多（村人・装置）
- プラグイン/MODの入れすぎ

「最初は軽く」ではなく、「最初から止まらない」を優先すると、結果的にコスパが良いです。

原則2：セキュリティは「公開しない」「権限最小」「入口最小」

サーバー運用で一番ラクなのは、荒らしに対応することではなく 荒らしが起きない設計にすることです。

✅ 公開しない：ホワイトリスト運用を標準にする
- “誰でも入れる状態”を作らない
✅ 権限最小：OPは最小人数、必要な時だけ付与
- 共同管理でも、役割を決めて権限を分ける
✅ 入口最小：開けるポートは必要分だけ
- ゲーム用ポート（Java＝25565/TCP、統合＝19132/UDP）
- 管理用（SSHなど）は接続元IPを絞るとさらに安全

セキュリティは難しい設定を増やすより、「不要な入口を作らない」が最強です。