マイクラMODサーバー入門|必要スペックから参加方法まで一気に分かる
マイクラのMODで遊びたいと思ったとき、意外と最初にぶつかるのが「サーバー、どうする問題」です。
「MODって入れればいいだけじゃないの? サーバー側も必要?」
「ForgeとFabricって何が違うの? 結局どれを選べばいい?」
「人数が増えたら重くなるって聞くけど、RAMは何GBいるの?」
「無料で試せるって本当? Aternosって制限が多いのかな…」
「自宅PCで立てたいけど、ポート開放とか危なくない?」
「友達が“入れない”って言い出したとき、何を見れば直せるの?」
「MODパックって便利そうだけど、配布や更新で壊れたりしない?」
こうした悩みは、初心者ほど当たり前に出てきます。
なぜならMODサーバーは、Minecraft本体/MODローダー/MODという“3点セット”を揃えたうえで、さらにサーバーの立て方(レンタル・無料・自宅・VPS)まで選ぶ必要があるからです。
この記事では、知識ゼロでも迷子にならないように、次の順番で「必要なことだけ」を整理しました。
- そもそもMODサーバーとは何か(バニラ・Realms・プラグインとの違い)
- 必要スペックの目安(人数・MOD量別の考え方)
- 4つの建て方(レンタル/Aternos/自宅PC/VPS)の選び方と手順
- 参加者が迷わない案内テンプレ(コピペで送れる)
- よくあるエラーの原因と直し方(入れない・落ちる・重い・外部から入れない)
- 長く安全に遊ぶための運用(バックアップ・更新・荒らし対策)
「まず成功する構成」から始めて、必要なら本格構成へステップアップできるようにまとめているので、これからMODマルチを始める人も、途中で詰まった人も、どちらにも役立つはずです。
この記事の対象と前提(最初に確認)
このページで扱うのは、「Java版で、MODを入れた状態で“マルチ(サーバー)”を遊ぶ方法」です。
いきなり手順に入る前に、まず前提をそろえるだけで失敗が激減します。
対象:Java版の「MOD入りマルチ」/統合版との違い
結論から言うと、検索キーワードの「マイクラ MOD サーバー」は多くの場合、Java版の“MOD(Forge/Fabricなど)”を入れたサーバーを指します。
- Java版(PC:Windows/macOS/Linux)
いわゆる「MOD文化」の中心。Forge / Fabric などの仕組みで改造の自由度が高い。 - 統合版(Bedrock:Switch/PS/Xbox/スマホ/Windows など)
仕組みが異なり、Java版のMODをそのまま入れて遊ぶ…という形にはなりません(代替としてアドオン等の文化があります)。
また、公式のサブスク型マルチとして Realms(Java向け)/Realms Plus(Bedrock向け) が分かれている点も混同ポイントです。
「友達がSwitchだから同じサーバーに入れるはず」と思っている場合、まず“Java版で遊ぶのか/Bedrockで遊ぶのか”を確定させましょう。
この記事が想定している人
- PC(Java版)で、友達と MOD入り の世界を遊びたい
- MODパック(例:工業・魔術など)をマルチで動かしたい
- レンタル/VPS/自宅PCなど、どの建て方でもOK(初心者向けに噛み砕いて解説)
この記事が想定していない(別物になりやすい)ケース
- 統合版のフレンドと、同じ“公式サーバー”で遊びたい
- Java版のMODではなく、プラグイン(Spigot/Paper系)中心で遊びたい
→ 目的は近いですが、導入方法や注意点が大きく変わります。
動作確認の考え方:ゲーム版本体・MODローダー・MODの3点セット
MODサーバーは「どれか1つでもズレると動かない」ことが多いです。
初心者が最短で安定させるコツは、3点セットを“同じ組み合わせ”で固定すること。
3点セット(ここが一致しているかが最重要)
- Minecraftのバージョン(例:1.xx.x)
- MODローダーの種類とバージョン(例:Forge / Fabric など)
- MOD(またはMODパック)の内容とバージョン(前提MOD含む)
まずはここだけチェック(これで8割防げます)
- ✅ サーバーと参加者が 同じMinecraftバージョン を使っている
- ✅ サーバーと参加者が 同じローダー(ForgeかFabricか等) を使っている
- ✅ MOD一覧が一致(入れている数・順番より“同じMOD/同じ版”が大事)
- ✅ 前提MOD(例:ライブラリ系)を入れ忘れていない
- ✅ 途中で誰かが勝手にMODを増やしていない(運用ルールも重要)
補足:MODには「クライアント側だけでOK」「サーバー側だけでOK」「両方必要」があります。
ただ、初心者のうちは判断に迷いやすいので、まずは “両方に同じMOD構成”で揃えるのが安全です(後で最適化できます)。
用語ミニ辞典:MOD/MODパック/プラグイン/前提MOD(ローダー)
はじめに単語のズレをなくしておくと、導入手順が一気に理解しやすくなります。
| 用語 | ざっくり意味 | 初心者が迷うポイント |
|---|---|---|
| MOD | ゲーム内容を拡張・改造する追加データ | Java版中心。MOD同士の相性や前提がある |
| MODパック | 複数MODを“セット”にした構成(配布用) | 便利だけど要求スペックが上がりやすい |
| プラグイン | サーバー機能を拡張する追加機能(主にSpigot/Paper系) | MODとは仕組みが別。混ぜたい場合は要注意 |
| MODローダー(前提) | MODを読み込むための土台(Forge/Fabric等) | ローダーが違うと同じMODでも動かない |
| 前提MOD(ライブラリ) | MODが動くために必要な追加部品(例:API系) | 入れ忘れると起動エラーが出やすい |
覚え方(超シンプル)
- MODは「追加コンテンツや機能そのもの」
- ローダーは「MODを動かす土台」
- 前提MODは「土台の上で必要になる部品」
- プラグインは「別系統の仕組み(サーバー拡張)」
ここまでが揃ったら、次は「どの建て方(レンタル/Aternos/自宅PC/VPS)が最適か」を選び、実際の手順に入っていく流れになります。
まず結論:あなたに合う「MODサーバーの作り方」早見表
「MOD入りマルチをしたい」と言っても、求める快適さとかけられる手間で最適解が変わります。
迷ったら、まずは下の早見表で“あなたのゴール”に一番近い方法を選ぶのが最短です。
3秒診断(これだけで方向性が決まる)
- 24時間いつでも入りたい? → YESなら「レンタル」か「VPS」
- 重いMODパック/人数多め? → YESなら「VPS/高性能プラン」
- まず無料で試したい? → YESなら「Aternos系(制限あり)」
早見表(結局どれがいい?を一発で)
| 作り方 | こんな人に最適 | 目安コスト | 難易度 | 24時間稼働 | 向き・不向き(要点) |
|---|---|---|---|---|---|
| レンタル(管理画面あり) | とにかく簡単に、早く遊びたい | 月額 数百〜数千円 | 低 | ✅(プラン次第) | ✅最短で始まる/⚠️自由度はVPSより低め |
| Aternos系(無料) | まず試したい・たまに遊ぶ | 無料 | 低〜中 | △(待ち・制限あり) | ✅費用ゼロ/⚠️混雑・性能・常時稼働に制限 |
| 自宅PC | コストを抑えつつ自由度も欲しい | 電気代・回線次第 | 中〜高 | ✅(PC常時ON) | ✅自由度高い/⚠️ポート開放・安定性・セキュリティが課題 |
| VPS | 24時間安定+自由度MAXで運用したい | 月額 千円台〜(スペック次第で上昇) | 中 | ✅ | ✅安定・拡張しやすい/⚠️初期設定はレンタルより手間 |
初心者の“失敗しにくい順”は、だいたい
レンタル → Aternos → VPS → 自宅PC(※目的によって逆転します)
料金・スペックの感覚(初心者向けの目安)
MODサーバーで効くのは主に メモリ(RAM) と CPU です。目安としては:
- 軽め(小規模・軽量MOD):RAM 2〜4GB から
- ふつう(MOD多め・5〜10人程度):RAM 8GB 前後
- 重め(MODパック・人数多め):RAM 16GB 以上推奨(状況により32GBも視野)
※MODの種類やワールドの重さで大きく変わるので、「足りなくなったら上げる」前提で選ぶのが安全です。
とにかく簡単:レンタル(テンプレ・管理画面あり)
「最短で遊べる」「専門知識が少なくて済む」ので、初心者に一番おすすめしやすいのがレンタル型です。
こういう人に向く
- ポート開放やLinux操作はやりたくない
- 友達とすぐ遊びたい(今日中に立てたい)
- 失敗してもサポートや管理画面がある方が安心
強み(レンタルがラクな理由)
- 管理画面でサーバー作成〜起動まで完結しやすい
- アップロードや設定が比較的わかりやすい(サービス側が“ゲーム向け”に最適化)
- プラン変更ができる場合、重くなったら上位へ移行しやすい
注意点(後で困りやすいところ)
- サービスによっては root権限(完全な自由操作)がない
→ 独自構成や特殊な運用をしたい人はVPS向き - 「どのMODでも万能」というわけではない
→ 対応ローダー(Forge/Fabric等)と導入方法(アップロード可否)は事前確認
初心者のプラン選び(まずは安全に)
- 迷ったら RAM 4GB〜8GB を起点にすると失敗しにくいです
(軽量なら4GB、MODパック寄りなら8GB〜)

無料で試したい:Aternos系(制限あり)
「まず体験したい」「週末だけ遊べればOK」なら無料サーバーは強い味方です。
ただし無料には、必ず“仕組み上の制限”があります。
こういう人に向く
- 完全無料で試したい
- 少人数で、短時間だけ遊べれば十分
- まずは“MODサーバーの雰囲気”を掴みたい
強み
- 費用ゼロで始められる
- 手順が簡単(ボタン操作中心のサービスが多い)
制限(ここを理解しておくとストレスが減る)
- 混雑時間帯に起動待ちが発生しやすい
- 常時稼働が前提になりにくい(止まりやすい・待ちが出る等)
- 重いMODパックや人数増加には不利になりやすい
Aternos系で失敗しないコツ
- 最初は MODを欲張らない(軽量・定番から)
- 遊ぶ時間を決めて、起動の待ちを見込む
- ワールドの肥大化を抑える(無駄に広範囲探索しない等)

自由度MAX:自宅PC or VPS(設定は多いが最強)
「自由にいじりたい」「運用も含めて本格的にやりたい」ならこの選択肢。
代わりに、設定・保守の責任は自分になります。
自宅PCとVPSの違い(ざっくり)
- 自宅PC:月額は抑えやすいが、回線・電気代・PC稼働・セキュリティが課題
- VPS:月額はかかるが、24時間安定しやすく、運用・拡張が楽
こういう人に向く
- MODパック運用、設定調整、バックアップなども含めて楽しめる
- 多少のトラブルはログを見て解決できる/覚える気がある
- 将来的に人数や規模が増える可能性がある
“最強”と言われる理由
- MOD構成・設定・自動化(バックアップ等)を自由に組める
- サーバー運用の柔軟性が高い(ディスクやメモリ、起動方法など)
初心者がつまずきやすいポイント(先に知っておく)
- 自宅PC:ポート開放、グローバルIP、ルーター設定
- VPS:Linux操作、セキュリティ(SSH等)、バックアップ設計
- 共通:バージョン不一致(Minecraft/ローダー/MOD)の管理

重いMODパック・人数多め:VPS/高性能プランが安定
「重いMODパック」「同時接続が増える」「24時間いつでも」…
この条件が揃うほど、VPS(または高性能レンタル)が安定します。
なぜVPS/高性能が必要になりやすい?
- MODパックは 要求メモリが跳ね上がることが多い
- 人数が増えるほど、エンティティ処理・読み込みが増えて CPUも効く
- ラグの原因が「PCの性能不足」ではなく「サーバーの余裕不足」になりやすい
失敗しない選び方(ポイントだけ)
- RAMは余裕を持つ:迷ったらワンランク上
- NVMeなど高速ストレージ:ワールドの読み書きが体感に直結
- “後から増強できる”サービスだと安心(遊びながら最適化できる)
お金をムダにしないコツ
- 最初から最大スペックにしない
→ まず「快適に動く最低ライン」を作り、必要に応じて上げる - ラグ対策は“スペックだけ”ではない
→ view-distance などの設定や、MOD構成の見直しで改善するケースも多い
そもそもMODサーバーとは?(検索意図の基礎)
「MODサーバー」とは、Minecraft(Java版)のマルチサーバーに“MOD環境(ローダー+MOD)”を入れて動かす仕組みのことです。
バニラ(素のマイクラ)ではできない、新しいブロック・機械・魔法・新要素・UI拡張などを、複数人で同じワールドで遊べるのが魅力です。
ただし、その代わりに “参加者側も同じMOD環境が必要” になりやすく、ここを理解していないと「入れない」「落ちる」が起きます。
バニラ/Realms/プラグインサーバーとの違い
混同が多いので、まずは「何ができるのか」を整理します。
ポイントは “改造の方式が違う” ことです。
| 種類 | できること(ざっくり) | 参加者の準備 | 向いている人 |
|---|---|---|---|
| バニラ(素のサーバー) | 公式そのまま。データパック等で軽い拡張は可 | 基本不要(通常の起動でOK) | とにかく簡単にマルチしたい |
| Realms(公式ホスティング) | 招待で手軽・常時オンライン。運用はラク | 基本不要(通常の起動でOK) | “管理が面倒”を避けたい |
| プラグインサーバー(Spigot/Paper系) | サーバー機能拡張(経済・ミニゲーム等) | 基本不要(通常の起動でOK) | “運営・管理系”の機能を足したい |
| MODサーバー(Forge/Fabric等) | 新ブロック・新要素など大改造が可能 | 同じローダー+同じMODが必要になりやすい | MODで遊びたい(工業・魔術・冒険など) |
ここが重要(初心者がハマりやすい点)
- プラグインは「サーバー側の追加機能」が中心で、参加者はだいたいバニラのまま入れます。
- MODサーバーは「ゲームそのものを拡張」するため、参加者側も同じMOD環境が必要になるケースが多いです。
- Realmsは“公式で手軽”ですが、一般的な意味での Forge/Fabric系のサーバーMODを自由に入れて運用するタイプとは別物として捉えるのが安全です(代替としてデータパック等の範囲で遊ぶイメージ)。
MODローダーの役割:Forge・Fabric・NeoForge・Quiltの立ち位置
MODは単体では動きません。MODを読み込んで動かす「土台」が MODローダーです。
つまり、MODサーバー作りはまず ローダー選び=土台選びから始まります。
それぞれの立ち位置を、初心者向けに超ざっくり言うとこうです。
- Forge
歴史が長く、対応MODが多い時期が長かった“大定番”枠。大型MOD・大型MODパックで採用されることが多い流れがありました。 - NeoForge
Forgeから派生した流れのローダー。新しめの環境で採用されることがあります。※Forgeと常に互換というわけではないため、MODが「Forge向け」か「NeoForge向け」かの確認が大事です。 - Fabric
“軽量・更新が速い”と言われやすい系統。最適化系MODや軽快な構成で採用されがちです(もちろん大型もあります)。 - Quilt
Fabricの技術を土台にしたコミュニティ主導の系統。Fabric互換を意識した設計で、Fabric向けMODが動く場合もあります(ただし万能ではないので、対応表記の確認が安全)。
✅ 重要:ローダーが違うと、同じMODでも動きません。
「Forgeで入れるつもりだったMODがFabric用だった」だけで詰みます。
運用目線のコツ
- 友達と遊ぶなら、まず “全員が同じローダーで起動できる” 状態を作るのが先です。
- ローダーやMODの更新は魅力的ですが、マルチは更新がトラブル源になりがちなので、初心者のうちは バージョン固定が安定します。
選び方はシンプル:「入れたいMODが対応しているローダー」を優先
最短で成功する選び方は、実はこれだけです。
- 遊びたいMOD(またはMODパック)を先に決める
- その配布ページで 対応ローダー(Forge/Fabric/NeoForge/Quilt) と 対応Minecraftバージョン を確認
- サーバー側も参加者側も、その組み合わせに揃える
迷いやすいパターンとしては、次があります。
- 「Forgeだと思い込んでいたが、実はFabric用MODだった」
- 「同じMOD名でも、Minecraftの対応バージョンが違っていた」
- 「前提MOD(API/ライブラリ)を入れ忘れて起動しない」
なので、初心者ほど “入れたいMOD(パック)→対応ローダー” の順番が確実です。
MODパック運用と“個別MOD寄せ集め”の違い
MODの導入には大きく2種類あります。
どちらが正解というより、目的で向き不向きがはっきりします。
MODパック運用(セットで導入)
メリット
- ✅ 最初から“動く前提”で組まれていることが多く、導入がラク
- ✅ 設定(config)も含めて最適化されている場合がある
- ✅ 友達に配るときも「このパック入れてね」で済みやすい
デメリット
- ⚠️ 重くなりやすい(RAMやCPU要求が上がる)
- ⚠️ 更新が大変(作者側の更新待ち/互換崩れが起きることも)
- ⚠️ 途中でMODを足すと、途端に不安定になるケースがある
向いている人
- “工業・魔術など、これをやりたい”が明確
- みんなで同じ体験をしたい(環境を統一したい)
個別MODの寄せ集め(必要なものだけ導入)
メリット
- ✅ 軽量にしやすい(必要な機能だけ追加)
- ✅ 自分好みに調整できる(不要な要素を入れない)
- ✅ 途中で入れ替えもしやすい(設計次第)
デメリット
- ⚠️ 相性問題が出やすい(競合・前提漏れ・バージョン不一致)
- ⚠️ 友達に配るのが大変(MOD一覧とバージョン管理が必要)
- ⚠️ 不具合が出たとき原因切り分けが難しい
向いている人
- まずは軽く便利MODから始めたい
- “この要素だけ欲しい”がハッキリしている
- 多少の調整や検証も楽しめる
初心者のおすすめは、
「最初はMODパック or 少数MODで成功体験 → 慣れたら寄せ集めで最適化」
という順番です。いきなり盛り盛りにすると、トラブル時に詰まりやすいです😅
準備チェックリスト(ここで失敗が減る)
MODサーバーは「建て方」より先に、準備の段階で勝負がほぼ決まります。
ここを押さえると、ありがちな「入れない」「起動しない」「重すぎる」を一気に減らせます。
必要スペックの目安(人数・MOD量・ワールド規模)
まず前提として、MODサーバーの必要スペックは公式が一律に示しているものではありません。
なのでここでは、初心者が失敗しにくいように「安全寄りの目安」を示します(あとから調整できる設計にするのがコツです)。
スペックに効く要素(ざっくり)
- 同時接続人数(増えるほどCPU/RAMが必要)
- MODの種類と数(最適化系は軽くなることも/工業・大型要素は重くなりがち)
- ワールド規模(探索範囲が広い、常時読み込みが多いほど重い)
- 設定(view-distance、simulation-distanceなど)
- 装置やMOBの密度(工業MODの自動化・トラップは負荷要因)
迷ったら、最初は「少なめ構成+余裕あるRAM」で成功体験を作るのが最短です。
最低限そろえるべき“ハードの方向性”
- CPU:コア数よりも “1コアあたりの強さ(高クロック)”が効きやすい
- ストレージ:可能なら SSD(できればNVMe)
- 回線:上りが弱いと人数増で体感が悪化しやすい(自宅PC運用で特に)
メモリ(RAM)目安:軽量/中量/重量MODパック別
「MODサーバー=RAMが正義」になりやすいです。目安は下記。
| 構成の目安 | 例 | 少人数(〜4人) | 中人数(5〜10人) | 多人数(10人以上) |
|---|---|---|---|---|
| 軽量 | 便利MOD中心・少数MOD | 4GB から | 6〜8GB | 8GB〜 |
| 中量 | 工業/魔術を少し・MOD多め | 6〜8GB | 8〜12GB | 12〜16GB |
| 重量 | MODパック・大型要素が多い | 8〜12GB | 12〜16GB | 16GB〜(状況で上振れ) |
見落としやすい注意点
- サーバー用RAMは「空きメモリ全部」ではありません。OSや管理ツール分を残します。
- “重い”の原因がRAMではなく、CPU不足・設定(描画距離)・装置密度の場合もあります。
- 最初から最大にしなくてもOK。上げやすい建て方(レンタル上位/VPS増強)を選ぶと失敗しにくいです。✅
Javaのバージョン確認(サーバー側で重要)
MODサーバーで地味に多いのが「Javaのバージョン違い」です。
ポイントは、Minecraftのバージョンによって必要なJavaが変わること。
最低限これだけ覚えればOK
- Minecraft 1.20.5以降:Java 21が必須(さらに 64-bit OSが必須)
- それ以前(例:1.18系〜1.20.4系):少なくとも Java 17以上 を用意すると安全
MODパックやローダーが「1.20.1」など特定バージョンに固定されていることも多いので、まず“遊ぶマイクラの版本体”を確定 → Javaを合わせる、の順番が鉄板です。
いま使っているJavaを確認する方法(最短)
サーバーを起動する端末で、次を実行して確認します。
java -version
- 表示が 21未満で、かつサーバーが 1.20.5以降なら → Java 21へ更新が必要
- 複数のJavaが入っている場合、起動時に別のJavaが使われることがあるので注意(パス設定など)
初心者がつまずきやすいポイント
- クライアント(普段遊ぶ側)はランチャーがJavaを同梱していても、サーバー(server.jar)は別でJavaが必要なケースがある
- レンタル/VPSでも、環境によっては「使えるJavaが固定」なことがある
→ その場合は、管理画面や案内で“対応Java”を確認して合わせるのが安全です
参加者に先に共有するもの(必須)
MODサーバーは「サーバーを立てる」より、参加者の環境を揃えるほうが重要です。
ここを先に決めて共有しておくと、当日のグダグダが激減します。
共有すべき必須セット(これだけは先に送る)
- Minecraftのバージョン(例:1.xx.x)
- MODローダーの種類とバージョン(Forge / Fabric / NeoForge / Quilt)
- MOD一覧(MOD名+バージョン)
- 配布方法(どこで何を配るか)
- サーバー接続情報(IP/ドメイン、ポート、ホワイトリストの有無)
「MOD一覧」は、できればテキストで管理すると強いです。
例:Discordの固定メッセージ/Googleドキュメント/README など(更新履歴も書ける)
ズレを防ぐ“配布方法”の決め方
初心者向けにおすすめ順で書くと、だいたいこの3つです。
- MODパックとして配る(いちばん事故が少ない)
- 参加者は同じパックを入れるだけになりやすい
- 更新も「パック更新」で統一しやすい
- modsフォルダをzipで配る(手軽だけど運用ルール必須)
- ✅すぐ始められる
- ⚠️誰かが勝手に足すと崩壊しやすいので、追加・更新は管理者だけなどルール化推奨
- 各自でMODを入れてもらう(初心者には非推奨)
- ほぼ確実に「入れ忘れ」「違う版」が出ます
- やるなら、チェックリストとスクショ例まで用意すると親切
ゲーム版・ローダー版・MOD一覧(配布方法まで決める)
最後に、友達へ送る“コピペ用テンプレ”を置いておきます。これがあると超ラクです。
共有テンプレ(コピペ用)
- Minecraft版本体:
- ローダー:(種類 / バージョン)
- MOD構成:
- 配布URL(MODパック or zip置き場):
- 追加・更新ルール:例)更新は管理者がまとめてやります
- サーバー接続:
- アドレス:
- ポート:
- 初回の注意:例)ホワイトリスト申請が必要
- トラブル時:
- “入れない/落ちる”場合はクラッシュログ or 最新ログを貼ってください(場所は後で案内)
建て方A:レンタルで作る(最短ルート)
レンタル型(ゲーム向けサーバー/マイクラ向けテンプレ付き)は、初心者がいちばん失敗しにくい方法です。
管理画面で設定できる部分が多く、サーバー知識が少なくても「遊べる状態」まで到達しやすいのが強みです。

この方法が向く人/向かない人
向く人
- できるだけ早く、迷わずMODマルチを始めたい
- ポート開放・自宅回線・セキュリティ設定を避けたい
- 不具合時に「管理画面のログ」や「サポート」を頼れると安心
向かない人(別の選択肢がラクなことも)
- Linuxでの細かい運用や自動化まで、自由に作り込みたい → VPSが向きやすい
- 完全無料で試したい → Aternos系(制限あり)が向く
- “超重量級MODパック+大人数”を想定している → 高性能プラン or VPSを優先したほうが安定しやすい
全体の流れ:ローダー選択 → サーバー起動 → MOD配置 → 再起動 → 接続
レンタルでの基本フローは、ほぼどのサービスでも同じです。
- ローダー(Forge/Fabric等)を選ぶ
- サーバーを起動(初回は環境生成で時間がかかることあり)
- MODをアップロード(modsフォルダへ)
- 再起動して反映
- 参加者の起動構成を揃えて接続
ポイントは、「変更(MOD追加・設定変更)はサーバー停止中にやる」こと。
動いている状態で触ると、反映漏れや破損リスクが上がります。
手順1:サーバータイプをForge/Fabric等に切り替える
レンタルの管理画面で、だいたい次のどちらかが用意されています。
- テンプレ(Forge/Fabricなど)を選んで新規作成
- 既存サーバーを 再構築(Reinstall) して、ローダーを切り替える
初心者は、可能なら 「テンプレで新規」 がラクです。
既存ワールドがある場合は再構築で消えることもあるので、必ずバックアップを取ってからにしましょう。
注意:MODが対応するゲームバージョンと揃える
ここで詰まる人が多いので、最短チェックだけ置きます。
- ✅ Minecraftのバージョン(例:1.xx.x)
- ✅ ローダーの種類とバージョン(Forge / Fabric…)
- ✅ MODの対応バージョン(前提MOD含む)
よくある失敗例
- 「MODが1.20.1対応なのに、サーバーを1.20.4で立てた」
- 「Forge用MODを、Fabricサーバーに入れた」
この段階でズレると、次のステップが全部ムダになりがちです。
最初は“欲しいMOD(またはMODパック)に合わせて、サーバー側を決める”のが安全です。
手順2:サーバーへMODを入れる(ファイル転送・管理画面)
レンタルは主に2パターンです。
- 管理画面のファイルマネージャーでアップロード
- SFTP/FTPでアップロード(PCの転送ソフト使用)
どちらでもOKですが、MODが多い場合は SFTPのほうが安定しやすいです。
アップロード前の安全ルール(初心者はこれだけ守る)
- サーバーを 停止してから作業する
- 追加は 一気に大量に入れず、最初は少数で起動確認
- MODは基本 .jarのまま(zipを解凍しないタイプが多い)
- “前提MOD”があるMODは、必ずセットで入れる
フォルダ構造の見方:mods / config / world
レンタルのディレクトリはサービスにより見え方が違いますが、考え方は共通です。
- mods:MOD本体(.jar)を入れる場所
→ ここに置いたものが読み込まれます - config:MODの設定ファイルが生成・保存される場所
→ サーバー起動後に増えることが多いです - world:ワールドデータ(地形・建築・プレイヤーデータなど)
→ ここを消すと基本的にワールドは戻りません
初心者向けのコツ
- まずは modsフォルダだけ触る
- configは、起動後に自動生成されるのを確認してから調整する
- worldは「バックアップを取ってから」以外、触らない
手順3:サーバー再起動と反映確認(ログで確認)
MODを入れたら、次は 再起動 → ログ確認 で“成功”を確定させます。
ここを飛ばすと、参加者が入れない原因が分からなくなります。
確認ポイント(最低限)
- 管理画面のコンソールログで、エラーが連発していないか
- 起動完了まで到達しているか(例:起動完了を示すメッセージが出る)
- MOD読み込み行が出ているか(MOD数が多いほど表示も増えます)
よくあるエラーの原因(頻出)
- MODのバージョンが合っていない(Minecraft/ローダー/MOD)
- 前提MODが足りない
- メモリ不足(起動途中で落ちる、極端に重い)
- 同じ機能のMODが競合(特に最適化系・描画系を盛りすぎた時)
トラブル時の切り分け手順(最短)
- 直近で入れたMODを一旦外す(最後に追加したものから)
- 起動できるところまで戻す
- MODを“少数ずつ”戻して、原因を特定する
この手順にしておくと、沼にハマりにくいです。
手順4:参加者側の準備(起動構成を揃える)
サーバーが起動できたら、次は参加者を“確実に入れる”段階です。
初心者のつまずきは、ほぼ 参加者側の環境ズレで起きます。
参加者に共有する必須セット
- Minecraftのバージョン
- ローダーの種類とバージョン
- MOD一覧(できればMOD名+バージョン)
- MODの配布方法(どこから入手するか)
いちばん事故が少ない運用
- MODパックがあるなら MODパックで統一
- 個別MODなら「modsフォルダ一式をzipで配布」して同一化
(※勝手に追加・更新しないルールもセットで)
チェックのしかた(初心者向け)
- 参加者が起動した“起動構成”で、modsフォルダに同じMODが入っているか
- ローダーがForgeなのにFabricで起動していないか(逆も同様)
- 入れない人が出たら、まずは「MOD一覧の差分」を確認する
最後に、サーバーアドレス(IP/ドメイン)を渡して接続テストをします。
最初の接続は、管理者が1人だけ入って動作確認 → 次に参加者を増やす流れが安定です 😊
建て方B:無料Aternosで作る(お試し向け)
Aternosは、無料でマイクラサーバーを作って遊べるサービスです。
「まずMODサーバーがどんな感じか試したい」「週末だけ友達と遊べればOK」という人に向きます。
一方で、無料ゆえに 待ち時間(キュー) や 24時間稼働できない などの制限もあるので、先に特徴を押さえておくと失敗しません。

Aternosの特徴(できること/できないこと)
初心者が押さえるべきポイントを「できる/できない」でまとめます。
| ざっくり | 内容 |
|---|---|
| できること | 無料でサーバー作成、Java版/Bedrock版の選択、対応MODの追加(数クリック)、対応MODパックの導入、サーバー起動→アドレスで参加 |
| できないこと(代表例) | 24/7常時稼働(最後の1人が落ちると停止)、混雑時は起動待ち(キュー)、好きなMODや自作MODパックを自由にアップロード(基本はAternosが用意する一覧から) |
もう少し具体的に言うと、AternosのMOD周りは次のイメージです。
- MOD(単体)運用:Aternosの「Mods」一覧(主にCurseForge/Modrinth由来)から入れる
→ “一覧にあるMOD”は入れやすい反面、一覧にないMODは基本的に追加できません。 - MODパック運用:Aternosの「Modpacks」から選んで導入する
→ ただし原則として、1つのMODパックをそのまま使う方式になりやすく、途中で自由に改造する用途には不向きです。
「完全に自由な構成でやりたい」「配布されていないMODも入れたい」なら、レンタル高性能プランやVPSなどが向きます(Aternosは“お試し向け”と割り切るのがコツです)。
手順1:サーバー作成 → Java版を選ぶ
Aternosでのサーバー作成は、基本的に画面の案内通りで進められます。
やること(最短手順)
- Aternosにログイン(アカウント作成)
- 「Create a server」を選択
- Java Edition を選ぶ(※この記事はJava版のMODサーバー想定)
- サーバー名やMOTD(説明文)を設定して作成
- 「Start」で起動 → EULAに同意して開始
ここでの注意点
- 初回起動は、内部準備で少し時間がかかることがあります。
- サーバーのアドレス(例:◯◯.aternos.me 形式など)は、作成後の画面で確認できます。
→ あとで参加者に共有するので、コピーできる場所を把握しておくとスムーズです。
手順2:ソフトウェアをForge/Fabric/Modpacksに設定
Aternosでは、サーバーの“土台”を Software(ソフトウェア) で選びます。
ここを間違えると、MODが表示されなかったり、起動できなかったりします。
まず選び方(迷わない基準)
- 入れたいMODが決まっている → そのMODが対応する Forge / Fabric / NeoForge / Quilt を選ぶ
- 入れたいMODパックが決まっている → Modpacks を選ぶ
MOD運用(単体MODを入れる)場合
- Softwareで Forge/Fabric/NeoForge/Quilt のいずれかを選択
- Minecraftのバージョンと、ローダーのバージョンを揃える
(例:MODが1.20.1+Forge対応なら、サーバーもその組み合わせにする)
MODパック運用の場合
- Softwareで Modpacks を選択して、入れたいパックを指定
- 初心者向けの重要ポイントとして、MODパックは「完成品」です。
途中でMODを足したり設定をいじって“自分好みに改造”したいなら、最初から MOD運用(単体MOD) で組むほうが安全です。
※設定を変えたら、基本的に 再起動(Restart)で反映されるタイプの項目が多いので、変更後は再起動をセットで覚えておくと迷いません。
手順3:MOD(またはMODパック)を選び、起動する
ここからは「MOD運用」か「MODパック運用」かで手順が分かれます。
あなたの方針に合わせて、該当ルートだけ読めばOKです。
MOD運用(単体MODを入れる)ルート
- サーバーのSoftwareが Forge/Fabric/NeoForge/Quilt になっていることを確認
- 「Mods」画面でMOD名を検索して追加
- 依存MOD(前提MOD) が必要なら一緒に入れる
- サーバーを起動(または再起動)して、コンソールログでエラーがないか確認
- 参加者側も同じローダー&同じMOD構成で起動して接続
初心者向けのコツ
- 最初はMODを欲張らず、少数で起動確認 → 少しずつ追加が安全です。
- 「サーバーは起動するのに入れない」場合、原因はだいたい
参加者側のMOD不足/バージョン違い です(サーバーよりクライアント側がズレがち)。
MODパック運用ルート
- Softwareを Modpacks にして、使いたいパックを選ぶ
→ 選んだ時点で、サーバー側は自動で必要要素が入るイメージです - サーバーを起動(MODサーバーより起動が長くなりやすいです)
- 参加者側は、パックに対応した方法で導入
- CurseForge系パック:CurseForge App で同じパックを入れる
- Modrinth系パック:Modrinth App で同じパックを入れる
- パックのバージョンが一致していることを確認して接続
初心者向けのコツ
- 参加者に配る説明はシンプルに
「このパック名」「このバージョン」 の2点を固定して共有すると事故が減ります。
つまずき:起動待ち・同時稼働・制限事項への対処
Aternosで初心者が詰まりやすいポイントと、現実的な対処をまとめます。
1) 起動待ち(キュー)で進まない
- 混雑時は起動ボタンを押すと 順番待ち(Queue) に入ります。
- 途中で離脱すると 順番がリセットされます。
- 先頭付近で 確認ボタンを押さないと順番から外れる仕組みもあります。
✅ 対処のコツ
- 遊び始める時間より少し早めに起動操作をする
- 混む時間帯を避ける(平日昼など、可能なら)
- うまく起動できたら、最初は軽い構成で安定運用して“落ちにくい状態”を作る
2) 24時間稼働できない/勝手に止まる
- Aternosは 24/7常時稼働を提供していません。
基本は「最後のプレイヤーが退出したらサーバー停止」です。 - ただし、遊んでいる間に“時間制限で強制終了”される仕組みではない、という考え方です(誰かがオンラインでアクティブなら稼働)。
✅ 対処のコツ
- 「遊ぶときに起動する」運用に割り切る
- 24時間常駐が必要なら、レンタル高性能プランやVPSへ切り替える(用途で使い分け)
※“常時稼働っぽくするための不正な方法(ボット等)”は規約上NGになりやすいので、やらないのが安全です。
3) 入れたいMODが検索に出ない
- Aternosは幅広いMODを扱いますが、すべてのMODが必ずあるわけではありません。
- とくに「作者側の配布設定」「対応ローダー違い」「対応バージョン違い」で見つからないことがあります。
✅ 対処のコツ
- ローダー(Forge/Fabric等)が合っているか再確認
- 近い機能の代替MODを探す
- どうしても必要なら、自由にアップロードできる環境(VPS等)へ
4) 接続できない/アドレスを入れても入れない
- まず サーバーがOnlineになっているかを確認
- それでもダメなら、Aternos側の案内にある DynIP を使うと解決することがあります(起動ごとに変わる“直接接続用”)
✅ 対処のコツ
- 1回目で失敗しても、もう一度接続で通るケースがある
- DNSのキャッシュが原因の場合は、DynIPが早い
建て方C:自宅PC(Windows)で立てる(自由度重視)
自宅PCでのMODサーバーは、自由度が高い反面、ネットワーク設定や安定運用の責任も自分にあります。
「まずは動かしてみたい」初心者でも進められるように、つまずきやすい点を先回りして解説します。
この方法のメリット/デメリット(回線・安定性・リスク)
メリット
- MODや設定を好きなだけ自由にいじれる(ファイル操作が制限されない)
- 月額料金が不要(電気代・回線はかかる)
- 学べる:後でVPSへ移行する際も知識がそのまま活きる
デメリット
- PCを起動しっぱなしにする必要がある(落ちるとサーバーも落ちる)
- 回線品質に左右される(上り速度・Wi-Fiの不安定さなど)
- ポート開放/ファイアウォールが必要で、ここが最大の壁
- 公開するとセキュリティ面の注意が増える(不特定多数にIPを出さない、ホワイトリスト運用など)
初心者向けの現実的な割り切り
- まずは「身内だけ」「短時間」「バックアップ取りながら」でOK
- 24時間稼働・安定を求め始めたら、レンタル高性能やVPSに移すのがスムーズです
手順1:サーバーフォルダを作成し、ローダーのサーバーを用意
ここは「環境を1つのフォルダにまとめる」が鉄則です。散らかるとトラブル時に戻せません。
0. 事前に決める(最重要)
- Minecraftバージョン(例:1.20.1 など)
- ローダー(Forge / Fabric など)
- MOD構成(MODパックなのか、個別MODなのか)
※Minecraft 1.20.5以降を使うなら、サーバー側もJava 21が前提になるので、古いJavaのままだと起動しません。
1. サーバーフォルダを作る
例:C:\MinecraftServers\MyModServer\
中身は最初こういう状態でOKです。
- まだ何も入っていない空フォルダ
2. Javaを確認する(地味だけど超重要)
Windowsの「ターミナル(PowerShell)」で確認します。
java -version
- 1.20.5以降を使うなら、表示が「21」系になっていることが目安
- 64-bit OSが必要になるバージョン帯もあるので、古いPCだとここで詰まります
3. 公式サーバー(server.jar)を用意する
- 公式の「Minecraft Server Download」から、選んだバージョンのサーバーをダウンロードしてフォルダへ置きます
- 最初はバニラでも一度起動して、基本ファイル(
eula.txtやserver.properties)を生成できると安心です
Forge系:サーバー側の生成ファイルと初回起動
ForgeでMODサーバーを作る方法は、初心者には次の2択が分かりやすいです。
A. MODパックの“Server Pack”がある場合(いちばん簡単)
- 配布元がサーバー用一式(start.bat等)を用意していることがあります
- それをフォルダに展開して、指示通りに起動するだけ
- クライアントとズレにくいので初心者向け
B. Forge Installerで“Install server”する(王道)
- Forgeのダウンロードページから、目的バージョンのInstallerを取得
- 実行して「Install server」を選び、作ったサーバーフォルダを指定
- 必要ファイルが生成されたら、起動用のbat(または付属の起動スクリプト)で起動します
初回起動で起きがちなこと
- 最初の起動でフォルダが増えます(例:
libraries、logs、mods、configなど) - その後に
eula.txtが生成され、同意しないと止まります(次の手順へ)
手順2:EULA同意と起動スクリプト(メモリ割り当て含む)
1. EULAに同意する
初回起動後にできる eula.txt をメモ帳で開き、
eula=false→eula=true
に変更して保存します。これで次回起動が進みます。
2. 起動スクリプト(start.bat)を作る
サーバーフォルダに start.bat を作り、例としてこんな形にします(jar名は手元の環境に合わせてください)。
@echo off
cd /d "%~dp0"
java -Xms4G -Xmx6G -jar server.jar nogui
pause
cd /d "%~dp0":batをどこから実行しても、必ずこのフォルダで動くようにする保険nogui:余計な画面を出さず軽くする(好みで外してもOK)
Forgeの場合は、起動対象のjarが server.jar ではないことがあります。
InstallerやMODパックが用意しているbatがあるなら、まずそれを優先するのが安全です。
OOM対策:-Xmx/-Xmsの考え方
OOM(Out Of Memory)は「メモリ不足で落ちる」典型例です。
設定は難しそうに見えて、初心者はこのルールだけ守れば十分です。
基本ルール
-Xmx:サーバーに使わせる最大メモリ-Xms:起動直後に確保するメモリ
初心者向けのおすすめ
- まずは
-Xmsは控えめ、-Xmxを適切に
例:PCが16GBなら、サーバーに 6〜10GB 程度から(他アプリも動かすなら少なめ) -XmxをPCのメモリギリギリまで上げない
→ Windows側が苦しくなって、逆に重くなることがあります
目安(超ざっくり)
- 軽め:
-Xmx4G - ふつう:
-Xmx6G〜8G - 重めMODパック:
-Xmx10G〜16G(PCが相応に強い前提)
起動はできるのにプレイ中に落ちるなら、まず -Xmx を少し上げるのが手っ取り早いです。
それでもダメなら、MODの相性・前提MOD不足・設定(距離系)も疑いましょう。
手順3:ポート開放・ファイアウォール(外部から入れる設定)
「家の外から友達が入る」ためには、だいたい次が必要です。
- ルーターでポート開放(ポート転送)
- Windowsでファイアウォール許可
- 接続先(グローバルIPやDDNS)を共有
1. ルーターのポート開放(ポート転送)
Minecraftのデフォルトは 25565 です。ルーターの設定画面で、
- 外部ポート:25565
- 内部ポート:25565
- 転送先:サーバーPCのローカルIP(例:192.168.1.10)
- プロトコル:TCP(迷うならTCP。ルーターによりTCP/UDP両方指定する場合も)
という形で転送を作ります。
※サーバーPCのローカルIPが変わると転送先がズレるので、可能なら「固定(DHCP予約)」にしておくと安定します。
2. Windows Defender Firewall の許可
次のどちらかで通ることが多いです。
- java.exe / javaw.exe を許可する(プログラム許可)
- ポート25565を受信許可する(受信規則でポート開放)
「許可したのにダメ」なときは、既存ルールが邪魔していることもあるので、
- いったん既存の25565ルールを整理して作り直す
- “プライベート”ネットワーク側で許可されているか確認する
を試すと改善することがあります。
チェック:同一LANで入れる?→ 次に外部から入れる?
初心者は、次の順に確認すると原因の切り分けが速いです。
ステップ1:同一LAN(家の中)で接続できるか
- サーバーPC自身:
localhostで入れるか - 同じWi-Fiの別PC:
192.168.x.x:25565(サーバーPCのローカルIP)で入れるか
ここで入れないなら、ポート開放以前に
- サーバーが起動してない
- そもそもMOD構成が合ってない
- Windowsファイアウォールがブロック
の可能性が高いです。
ステップ2:外部(家の外)から接続できるか
- 友達には「あなたのグローバルIP(またはDDNS)」を伝える
- 注意:同じ家の中から“グローバルIP”で入ろうとして失敗することがあります(ルーター側の仕様で起きる)
→ 外部チェックは、実際に外から(スマホ回線など)試すのが確実です
外部だけ入れない場合の典型原因
- ルーターのポート転送先IPが違う(PCのIPが変わった等)
- Windowsファイアウォールの受信許可が不足
- 回線側の都合で外部から到達できない環境(設定しても開かないケースがある)
建て方D:VPS(Linux)で立てる(24時間・重いMOD向け)
VPSは、24時間稼働や重いMODパックに強い「本命」構成です。
その代わり、最初のセットアップ(SSH・FW・起動管理・バックアップ)を丁寧にやるほど、後がラクになります。

プラン選び:CPU/RAM/SSD/帯域の見方
VPS選びは「安い順」ではなく、“ボトルネックになりやすい順”で見ると失敗が減ります。
優先順位の目安(初心者向け)
- RAM(メモリ):MOD・人数が増えるほど効く
- CPU(vCPU):ラグやTPS低下に直結しやすい
- SSD(できればNVMe):ワールド読み書き・再起動時間に効く
- 帯域・転送量:人数が増えるほど回線品質が体感に影響
ここだけ見ればOK(チェックポイント)
- RAMは後から増やせるか(スケールアップ可能だと安心)
- SSDがNVMeか(体感差が出やすい)
- ロケーションが近いか(日本の友達中心なら国内/近隣リージョンが有利)
- バックアップ/スナップショット機能があるか(復旧が速い)
“重いMOD向け”で特に大事な考え方
- まずは余裕のあるRAMを確保し、次にCPUを上げる
- ラグが出たら「スペックを上げる」だけでなく、描画距離(view-distance等)や装置密度も同時に見直す
- 料金は変わりやすいので、最終的には各社の公式プラン表(RAM/CPU/SSD/転送量)で確定させるのが安全です
手順1:Java導入・ユーザー作成・セキュリティ基礎
ここでは「Ubuntu系」を例に、最低限の安全策+運用しやすい形を作ります。
(他ディストリでも考え方は同じです)
最初にやること(全体像)
- ✅ 一般ユーザーを作って、普段はrootで作業しない
- ✅ SSH鍵ログインを基本にする
- ✅ ファイアウォールで“必要な穴だけ”開ける
- ✅ 自動更新は「便利」だが、再起動が絡むので方針を決める
SSH鍵/ファイアウォール(UFW等)/自動更新の扱い
1) ユーザー作成(例:mc)
# 初回ログインがrootの場合
adduser mc
usermod -aG sudo mc
作業用ディレクトリも先に作っておくと迷いません。
mkdir -p /srv/minecraft
chown -R mc:mc /srv/minecraft
2) SSH鍵ログインを用意する(推奨)
手元PCから鍵で入れるようにします(例の流れ)。
- 手元PCで鍵作成(未作成なら)
ssh-copy-idなどでVPSへ公開鍵を登録
※このあたりは環境差が出やすいので、VPS会社の案内に沿ってOKです。
3) ファイアウォール(UFW例)
先にSSHを許可してから有効化します(ここを間違えると入れなくなります⚠️)
sudo apt update
sudo apt install -y ufw
sudo ufw allow OpenSSH
sudo ufw allow 25565/tcp # Minecraftの標準ポート(変更するならそれに合わせる)
sudo ufw enable
sudo ufw status
4) 自動更新(unattended-upgrades)の考え方
- セキュリティ更新を自動で入れるのは基本的に良い判断です
- ただし、カーネル更新などで再起動が必要になると、サーバーが落ちる可能性があります
初心者におすすめの方針はどちらかです。
- 方針A(安全寄り):自動更新はON、再起動は手動(夜間にメンテ日を作る)
- 方針B(省手間寄り):自動更新ON+再起動も自動(落ちてもOKな用途向け)
手順2:サーバー配置と起動(screen/tmux/systemd)
VPS運用のキモは、「起動を自動化して、落ちても戻る」状態を作ることです。
最初は手動で起動確認 → 問題なければsystemdで常駐、が最短です。
1) サーバー本体を配置する
/srv/minecraft にまとめる例です。
sudo -iu mc
cd /srv/minecraft
- 公式ページからMinecraftサーバー(server.jar等)を取得して、ここに置きます
- Forge/Fabric/Modパックは、配布物に含まれる手順(server packやinstaller)を優先してください
→ jar名や起動コマンドが変わることが多いです
2) 初回起動(手動でテスト)
まずは手動で起動して、ファイル生成・エラー有無を確認します。
cd /srv/minecraft
java -Xms2G -Xmx6G -jar server.jar nogui
初回は eula.txt が作られ、同意しないと止まります。
同意する場合は以下のようにします。
printf "eula=true\n" > eula.txt
3) tmux(またはscreen)で“落ちない作業環境”を作る
作業中にSSHが切れてもサーバーが落ちないようにします。
sudo apt install -y tmux
tmux new -s mc
# ここで起動コマンドを実行
# Ctrl + b → d でデタッチ
tmux attach -t mc
4) systemdで常駐(おすすめ)
/etc/systemd/system/minecraft.service を作ります(例)。
[Unit]
Description=Minecraft Server
After=network.target
[Service]
User=mc
WorkingDirectory=/srv/minecraft
ExecStart=/usr/bin/java -Xms2G -Xmx6G -jar /srv/minecraft/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
ログ確認(つまずき解消に必須):
sudo journalctl -u minecraft -f
初心者がハマる点(先回り)
ExecStartは相対パスより フルパスが安全- jar名が違う(Forge/Modパックでよく起きる)
- メモリ割り当てが過大でOSが不安定になる(まずは控えめ→必要に応じて増やす)
手順3:バックアップ設計(自動・世代管理)
24時間運用の“安心”は、スペックよりバックアップが作ります。
初心者はまず「確実に復元できる」仕組みを1本作るのが最優先です。
何をバックアップするか(最低限)
world/(最重要)mods/(MOD構成)config/(設定)server.properties/whitelist.json/ops.jsonなど運用ファイル
方式は2段階で考えるとラク
- 簡単(おすすめ):毎日1回、短時間だけ止めてバックアップ(確実)
- 上級:稼働したままバックアップ(RCON等が必要になりがち)
初心者はまず「簡単で確実」からでOKです。✅
例:停止→圧縮→世代削除(14日残す)
- スクリプト作成(例:
/usr/local/bin/mc-backup.sh)
sudo tee /usr/local/bin/mc-backup.sh > /dev/null <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
BASE="/srv/minecraft"
DST="/srv/mc_backups"
TS="$(date +"%Y%m%d-%H%M")"
mkdir -p "$DST"
# 停止してからバックアップ(確実)
systemctl stop minecraft
tar --ignore-failed-read -C "$BASE" -czf "$DST/mc-$TS.tgz" \
world mods config server.properties whitelist.json ops.json banned-players.json banned-ips.json || true
systemctl start minecraft
# 14日より古いバックアップを削除
find "$DST" -type f -name "mc-*.tgz" -mtime +14 -delete
EOF
sudo chmod +x /usr/local/bin/mc-backup.sh
- cronで毎日実行(例:毎朝5:00)
sudo crontab -e
以下を追加:
0 5 * * * /usr/local/bin/mc-backup.sh
もう一歩安心にする(おすすめ)
- バックアップ保存先は、できれば VPS内だけでなく別場所にも(別サーバー / オブジェクトストレージ等)
- 定期的に 復元テスト(別ディレクトリに展開して起動できるか確認)
MOD導入のルール(ここが一番トラブルになる)
MODサーバーのトラブル原因は、だいたい次の3つに集約されます。
- バージョン違い(Minecraft/ローダー/MOD)
- 入っているMODの差(誰かだけ不足・余計・別バージョン)
- 設定(config)の差(同じMODでも設定がズレて入れない)
ここを「ルール化」しておけば、初心者でも安定運用できます。
MODは3種類:サーバー専用/クライアント専用/両方必須
MODは“どこで動く前提か”が違います。これを理解すると「入れない」が激減します。
| 種類 | ざっくり | 例(イメージ) | 典型トラブル |
|---|---|---|---|
| サーバー専用 | サーバーの処理・管理・最適化向け | 最適化、権限、管理系など | クライアントに入れなくてもOKなことが多い |
| クライアント専用 | 画面表示や操作補助向け | UI改善、マップ、見た目補助など | サーバーに入れても意味がない/逆に不具合の原因になることも |
| 両方必須 | 追加要素(ブロック・アイテム等)を共有する | 新要素、ゲームルール拡張など | 片方だけだと接続拒否・クラッシュが起きやすい |
初心者が迷う場合は、まずは安全策として
「両方必須っぽいMODは、サーバーと参加者に同じものを入れる」
これを徹底すると失敗しにくいです。✅
見分け方:配布ページの“Server/Client”表記・依存関係
見分けは「勘」ではなく、次の順で確認すると堅いです。
- 対応ローダー(Forge / Fabric / NeoForge / Quilt)
- 対応Minecraftバージョン
- 動作環境(Client / Server / Both)表記
- 依存関係(Dependencies)
- 必須(Required)
- 推奨(Optional)
- 前提ライブラリ(API系)
初心者がハマりやすいポイント
- “同じMOD名”でも、Minecraftの対応版が違うことがある
- 前提MODを入れ忘れると、起動ログに「◯◯が必要」と出て止まる
- ローダー違いはほぼ確実に失敗(Forge用をFabricに入れる等)
迷ったときの安全な判断
- 配布ページで「Server/Client」の記載が曖昧なら、いったん 両方に入れる前提で揃える
- サーバー起動が通って、参加者も入れる状態を作ってから、不要なものを整理する
サーバーと参加者の環境を一致させる手順
ここは“作業手順”というより、“運用の型”です。
一度型を作れば、MODを増やしても崩れません。
手順(おすすめの順番)
- 基準を固定する
- Minecraftのバージョン
- ローダーの種類とバージョン
ここがブレると全部やり直しになりがちです。
- MOD構成を「確定」する
- MOD名
- バージョン
- 前提MOD
“だいたい同じ”ではなく、完全一致が前提です。
- 配布方法を決める(ここが超重要)
初心者におすすめなのは次の順です。- MODパックとして配布(最も事故が少ない)
- 次点:modsフォルダ一式をzip配布(ルール必須)
- 非推奨:各自が個別に入れる(ズレやすい)
- 接続テストの順番を固定する
- 管理者が単独で入る → 1人招待 → 問題なければ人数を増やす
いきなり全員だと、原因切り分けが難しくなります。
- 管理者が単独で入る → 1人招待 → 問題なければ人数を増やす
- “勝手に更新しない”運用ルールを作る
- 更新は管理者だけ
- 更新日は週1など固定
- 変更点(追加/削除/更新)をメモする
おすすめ運用:MOD一覧の固定(バージョン含む)→一括配布
「MOD一覧の固定」は、“ミスの再発防止”のためにやります。
特に人数が増えるほど、効果が大きいです。
最低限、これだけは固定すると強い
- Minecraftバージョン
- ローダー(種類+バージョン)
- MOD一覧(ファイル名+バージョン)
MOD一覧テンプレ(例)
配布用のテキストに、こういう形で残すと後で助かります。
| 種別 | MOD名 | バージョン | 前提MOD | 備考 |
|---|---|---|---|---|
| Both | 例:追加要素系 | x.y.z | 例:API系 | 参加者も必須 |
| Server | 例:最適化系 | x.y.z | なし | サーバーのみ |
| Client | 例:UI補助系 | x.y.z | なし | 参加者のみ |
一括配布の現実的なやり方
- MODパック運用:
- “パック名”と“パックのバージョン”を固定して共有
- zip配布運用:
modsフォルダを丸ごとzip- 同梱で
modlist.txt(一覧)を入れる - 「勝手に追加しない」を明文化
※MODの配布・再配布は、作者の利用規約やライセンスが関係します。
不安な場合は「MODパック機能(正規配布前提)」や「各自インストールの案内」を使うと安心です。
configの共有と注意点(設定差で入れない問題)
同じMODでも、config(設定ファイル)が違うと接続できないことがあります。
ただし、全部のconfigを共有すればいいわけではなく、ここも整理が必要です。
まず押さえるべき“configの種類”
- サーバー側の設定:サーバーの挙動を決める(参加者に影響)
- クライアント側の設定:表示や操作感など(個人差があってもOKなことが多い)
- ワールドごとの設定:ワールドに紐づく(環境を再現しやすい)
「入れない」につながりやすいパターン
- サーバーと参加者で、同じMODの重要設定がズレている
- “設定同期”を前提にしているMODで、参加者側のconfigが古い/壊れている
- MODパックの作者が想定するconfigから外れている
安全に運用するコツ
- 原則:サーバー側を“正”にする
サーバーで動作確認できた状態を基準にします。 - 参加者が入れないときは、まず「MOD一覧」→次に「config」を疑う
- config共有が必要な場合は、共有範囲を絞る
- 何でも全部配るより、必要なファイルだけが安全です
初心者向けの“直し方”(参加者が入れない場合)
- 参加者側で、該当MODの設定ファイルを一度退避(または削除)
- もう一度起動して再生成させる
- それでもダメなら、管理者が「正しいconfig」を配布して統一する
この手順だと、原因が「設定差」かどうかの切り分けが速いです。
アップデート手順(安全な順番)
MOD環境はアップデートで壊れやすいので、“安全手順”を固定しましょう。
手順を守るだけで、最悪の事故(ワールド破損・長期停止)をかなり防げます。
安全な順番(おすすめ)
- 更新内容を決める(1回で全部変えない)
例:今日はMODだけ更新、ローダーは触らない…のように“軸を分ける” - サーバー停止 → バックアップ
- 検証環境で起動(同じ構成をコピーしてテスト)
- ログ確認&参加者1人で接続テスト
- 本番反映 → 再起動 → 監視
- 問題が出たら 即ロールバック(元に戻す)
必須:更新前バックアップ → 検証起動 → 本番反映
初心者が最低限やるべき“3点セット”です。
1) 更新前バックアップ(必須)
バックアップ対象の目安:
world(最重要)modsconfig- 運用ファイル(ホワイトリスト等)
2) 検証起動(必須)
本番フォルダを直接いじるのではなく、コピーで試します。
- 起動できるか
- ログに致命的エラーがないか
- 参加者が入れるか(最低1人でテスト)
3) 本番反映(必須)
検証OKになってから本番に適用。
- 参加者向けに「更新したもの(MOD一覧とバージョン)」を共有
- 必要なら配布物(パック/zip)を差し替え
- 起動後しばらくは、ログとTPS(体感)を観察
ロールバック(戻し方)も先に決めておく
- うまくいかなければ、バックアップを戻して“元の環境で遊べる状態”に即復帰
- 原因調査は復帰後に落ち着いてやる
この流れだと、遊ぶ時間が無駄になりにくいです。✅
参加方法(友達が迷わないテンプレ)
友達が迷うポイントはほぼ固定で、「どの起動構成で起動するか」と「サーバーアドレスの入れ方」です。
ここでは、相手が初心者でも詰まらないように、必要情報と案内テンプレをセットでまとめます。
接続に必要な情報:IP/ドメイン・ポート・バージョン一式
友達に渡す情報は、最小でもこの4点です(これが欠けると高確率で入れません)。
- サーバーアドレス:IPまたはドメイン
- ポート番号:基本は 25565(変更していなければ省略可)
- Minecraftのバージョン(例:1.20.1 など)
- ローダー+MOD構成(Forge/Fabric/NeoForge/Quilt、MOD一覧とバージョン)
アドレスの書き方(コピペ用)
- ポートがデフォルト(25565)のまま →
example.com(ポート省略でOK) - ポートを変えている →
example.com:25566のように コロン+ポートを付ける
(IPでも同じ:123.45.67.89:25566)
ホワイトリスト/OP権限/ゲームルールの初期設定
身内サーバーでも、最初に“守り”を作ると後の事故が減ります。
特に自宅PC/VPSはIPが露出しやすいので、基本はホワイトリスト運用がおすすめです。
ホワイトリスト(推奨:身内サーバーは基本ON)
- 有効化:
/whitelist on - 追加:
/whitelist add プレイヤー名 - 削除:
/whitelist remove プレイヤー名 - 一覧:
/whitelist list
コツ
- まず管理者(あなた)を追加 → 次に友達を追加、の順で。
- 招待していない人が入れないので、公開事故に強くなります。
OP権限(最小限に)
OPは便利ですが、できることが強すぎるので付与は慎重に。
- 付与:
/op プレイヤー名 - 解除:
/deop プレイヤー名
おすすめ運用
- OPは基本「管理者1人」
- 友達に必要なときは、その作業が終わったら解除(事故防止)
ゲームルール(最初に決めると揉めない)
サーバー方針がぶれやすい項目だけ、最初に決めて共有すると平和です。
- 難易度(Peaceful/Easy/Normal/Hard)
- ルール系:KeepInventory、MobGriefing、PvP など
- 夜スキップ、死亡時の扱い(墓MODがあるならそのルール)
- 荒らし対策:チェスト保護系MODがあるなら使い方も共有
配布用テンプレ(コピペで送れる案内)
そのままDiscord/LINEに貼って使える形です。
角カッコの部分だけ埋めて送ればOK。
【マイクラMODサーバー参加案内】
■ 0) 先に確認(超重要)
- Java版です(統合版は入れません)
- Minecraftバージョン:[例:1.20.1]
- ローダー:[Forge / Fabric / NeoForge / Quilt](バージョン:[ ])
- MOD構成:[MODパック名 or MOD一覧](バージョン固定)
■ 1) 接続に必要な情報
- サーバーアドレス:[example.com]
- ポート:[25565](※25565なら省略OK / 変更してたら「:ポート」を付けてね)
- 参加条件:ホワイトリスト制(事前にID教えてください)
■ 2) 参加までの流れ
① 起動構成の作り方
- [ローダー名]を入れて、Minecraft[バージョン]で起動できる状態にする
- 起動構成(プロファイル)は「[名前:例 MODサーバー用]」を作って、それで起動してね
② mods投入
- 送った[MODパック / modsフォルダzip]を入れる
- MODパック:[CurseForge/Modrinth等]で「[パック名](ver[ ])」を入れて起動
- zip配布:起動構成のmodsフォルダに、同じ中身になるように入れる
- 追加・更新は禁止(更新は管理者がまとめてやります)
③ 接続
- Minecraft起動 → マルチプレイ → サーバー追加
- サーバーアドレス欄にこれを貼る:[example.com]
(ポート変更してる場合:[example.com:25566])
- 入れない時は「エラー文」と「modsフォルダのスクショ」を送ってください
■ 3) あなたのID(ホワイトリスト用)
- Minecraftのプレイヤー名:[ここに返信してね]
①起動構成の作り方 → ②mods投入 → ③接続(つまずきゼロの補足)
- ①でローダーとMinecraftバージョンが揃っていないと、②③を頑張っても入れません
- ②は「同じMODが同じ版で入っている」が正義(“だいたい同じ”はNG)
- ③で入れない場合、原因の多くは
MOD不足 / MODの版違い / ローダー違い / config差 のどれかです(焦らず差分チェックで解決できます)
よくあるエラー別:原因と直し方
MODサーバーの不具合は、突き詰めると多くが「環境のズレ」「設定のズレ」「リソース不足」「回線の壁」のどれかです。
ここでは、初心者でも迷わないように 症状 → 原因 → 最短の直し方 の順でまとめます。
「MODが足りない/違う」系(Mismatch・Missing)
よくある症状
- 接続時に「Missing」「Mismatch」「mismatched mod channel list」などが出て入れない
- サーバーには入れる人と入れない人がいる
- 入れた直後に弾かれる(Disconnect)
主な原因
- modsフォルダの中身が一致していない(1個でもズレるとアウト)
- 同じMODでもバージョン違い(ファイル名が似てても中身が違う)
- ローダーの種類・バージョンが違う(ForgeとFabricなど)
- 依存MOD(前提MOD)不足(API系・ライブラリ系)
- configが噛み合っていない(後述)
最短で直す手順(おすすめ)
- まず3点固定を確認
- Minecraftバージョン
- ローダー(種類+バージョン)
- MOD一覧(MOD名+バージョン)
- “差分探し”をやめて、正しいセットに置き換える
- いちばん確実なのは、管理者が「正のmodsフォルダ」を用意して
参加者は 自分のmodsを一旦空にしてから その中身に置き換える方法です。
- いちばん確実なのは、管理者が「正のmodsフォルダ」を用意して
- 依存MODを確認
- 配布ページのDependencies(必須)を見て不足を補います。
- クライアント専用MODの混入を疑う
- 「便利系・UI系・見た目系」を入れた人だけ弾かれることがあります。
まずはそのMODを外して接続テスト。
- 「便利系・UI系・見た目系」を入れた人だけ弾かれることがあります。
一撃でズレを防ぐ運用
- MOD一覧(バージョン込み)を固定 → 一括配布が最強です。
MODパック運用か、modsフォルダzip配布に寄せると事故が減ります。
起動で落ちる(クラッシュログの最短チェックポイント)
まず確認する場所(最低限)
logs/latest.log(直近の起動ログ)crash-reports/(クラッシュレポートが出る場合)- Forge系は状況により
logs/debug.logが出ることもあります
最短チェックのコツ(読む順番)
クラッシュログは全部読む必要はありません。ここだけ見ればOKです。
- 最初の致命行(ERROR / FATAL)
- “Caused by:” の行(本当の原因がここに出やすい)
- Missing / Requires / depends on(依存不足の合図)
- Mixin / ClassNotFound / NoSuchMethod(互換性崩れの合図)
- Javaバージョン(要求より古いと起動しないことがある)
直し方の王道(安全な戻し方)
- 直前に追加・更新したMODを外す(1個ずつ戻す)
- 依存MODを追加する
- Minecraft・ローダー・MODの対応バージョンを揃え直す
- それでもダメなら、次の順で切り分け
- MOD無しでサーバー起動できるか
- MODを少数だけ入れて起動できるか
- 問題のMODを特定
よくある落とし穴
- “最新版”を入れれば良いとは限りません。
MODパックや環境が特定バージョン固定のことが多いので、更新は慎重に。
重い・ラグい(view-distance、メモリ、MOD構成の見直し)
まず最初に見るべき3点
- 描画距離(view-distance)
- 処理距離(simulation-distance)
- メモリ割り当て(-Xmx)と実メモリ余裕
この3つで体感がガラッと変わることが多いです。
すぐ効く軽量化(設定編)
server.propertiesの調整候補view-distanceを下げる(見える距離を短くする)simulation-distanceを下げる(作物成長やAIなど“処理”を短くする)
- いきなり極端に下げず、1〜2ずつ調整して体感を確認するのが安全です。
メモリ(RAM)の考え方
- メモリ不足は落ちやすさ・カクつきにつながりますが、
メモリを盛れば必ず快適になるわけではありません(CPUや設定が原因のことも多い)。 - Windows自宅PCなら、OSが苦しくならない範囲で
-Xmxを設定します。
VPSなら、OS分の余裕も残します。
MOD構成の見直し(効きやすい順)
- まず 重いMODパック/大型要素を疑う
- 次に 自動化装置・MOB密度(工業・トラップ・大量搬送など)
- 最後に 最適化系MODの組み合わせ(相性で逆に重くなることがある)
体感が悪いときの“順番”テンプレ
view-distance/simulation-distanceを少し下げる- 同時接続人数を減らして変化を見る
- 重い装置・拠点周りを整理(MOB・搬送・常時稼働装置)
- それでもダメならプラン増強(RAM/CPU)を検討
外部から入れない(ポート開放/CGNAT/ルーター設定)
切り分けの鉄則(この順で確認)
- 同一LAN(家の中)で入れるか
- まずローカルIP(例:192.168.x.x)で接続テスト
- ここで無理なら、ポート開放以前の問題(サーバー未起動・FWブロック等)
- 外部(家の外)から入れるか
- 友達にグローバルIP(またはDDNS)で試してもらう
- 家の中からグローバルIPで入れないのは、ルーター仕様で起きることがあります(外部テストが確実)
ポート開放の超基本
- Java版のデフォルト待受は 25565 が一般的です(変更しているならそれに合わせる)
- ルーターで 外部→内部(サーバーPCのローカルIP) に転送を作る
- Windowsならファイアウォールで java.exeの許可または 25565/TCP受信許可
CGNATが原因のパターン(やりがち)
設定が全部正しそうなのに、外部から絶対に入れないときは CGNAT を疑います。
疑い方(目安)
- ルーターのWAN側IPが
100.64.x.xや10.x.x.xなど“プライベートっぽい” - 「自分のグローバルIP確認サイト」で出るIPと、ルーターのWAN IPが一致しない
現実的な解決策
- 回線事業者に グローバルIP(またはポート開放可能な契約)を相談する
- VPSやレンタルに移す(最も確実)
- どうしても自宅でやるなら、CGNAT回避手段(トンネル等)を検討
※手段は多いですが、安定性・規約・セキュリティの観点で慎重に
ワールド破損・巻き戻し(バックアップ復旧)
よくある症状
- 起動はするがワールドに入ると落ちる
- 一部のチャンクだけ真っ白・消失
- MODを抜いたらワールドが壊れたように見える
基本方針(初心者はこれでOK)
- まず復旧=バックアップから戻す
- 原因究明は復旧して遊べる状態に戻してから
復旧の手順(安全)
- サーバーを停止
- 現在のワールドを退避(保険)
- バックアップの
world/を戻す - MOD構成(mods)と設定(config)が、バックアップ当時と一致しているか確認
- 起動 → 管理者だけでログイン確認 → 問題なければ全員招待
“巻き戻し”を防ぐ運用(重要)
- 自動バックアップ+世代管理(例:14日分残す)
- 更新前は必ず手動バックアップ(更新事故の保険)
- MODの追加・削除は「小さく」「検証してから本番」
(特にワールド生成系・地形追加系は影響が大きいです)
安全に長く遊ぶ:運用ベストプラクティス
MODサーバーは「立てて終わり」ではなく、運用ルールを最初に決めた人が勝ちです。
ここでは、初心者でもそのまま真似できる“事故らない型”をまとめます。✅
バックアップ:頻度・保存先・復元テスト
まず決める:何をバックアップする?
最低限これだけはセットで取ります(ワールドだけだと復旧できないことがあります)。
- world(最重要)
- mods(構成そのもの)
- config(設定差で入れない問題の元)
server.properties/whitelist.json/ops.jsonなど運用ファイル- (VPS/自宅PCなら)起動スクリプトやsystemd設定もメモしておくと復旧が速い
おすすめ頻度(迷ったらこれ)
「いつ取るか」を固定すると、巻き戻し事故が激減します。
| タイミング | 推奨 | 理由 |
|---|---|---|
| 毎日(定期) | 1回 | “気づかない破損”に強い |
| MOD追加/削除/更新の前 | 必ず | 更新事故の保険 |
| config変更の前 | 必ず | 入れない問題の保険 |
| 大型アップデート前(MC/ローダー更新) | 必ず+世代多め | 破壊力が大きい |
保存先の鉄板:3-2-1の考え方
失敗しないための合言葉です。
- 3つ持つ(例:本番+バックアップ+予備)
- 2種類に分ける(例:同じVPS内+別ストレージ)
- 1つは別場所へ(例:クラウド/別サーバー/外付け)
例(初心者向けの現実解)
- 自宅PC:PC内 + 外付けHDD/SSD + クラウド
- VPS:サーバー内 + スナップショット + オブジェクトストレージ(または別VPS)
復元テスト(ここまでやると本物)
バックアップは「取った」だけだと不安です。月1でもいいので、短くテストします。
- 別フォルダ(または別サーバー)にバックアップを展開
- 同じmods/configで起動できるか確認
- 管理者だけログインして、ワールドが正常か確認
- OKなら本番は触らない(テスト環境を消す/保管)
💡コツ:復元テストをすると「何が必要ファイルか」が体で分かり、次回から復旧が爆速になります。
荒らし対策:ホワイトリスト、権限、ログ監視
最低限の守り(身内でも推奨)
- ホワイトリストをON(招待制にする)
- OPは最小人数(基本は管理者だけ)
- 外部公開するなら、アドレスの拡散を避ける(SNSに貼らない)
認証まわりの注意(自宅PC/VPSで特に重要)
- サーバーの認証(アカウント確認)が無効だと、なりすましなどのリスクが増えます。
事情がない限り、認証が効く設定で運用するのが安全です。
ログ監視(“何が起きたか”を残す)
トラブルは「証拠」があると一瞬で解決します。
- サーバーログを残す(
logs/ systemdならjournalctl) - 荒らしが疑われたら、まずログで
- 参加・退出のタイミング
- エラーや権限実行
- 破壊が起きた時間帯
を確認する
💡運用のコツ:
「荒らし対策=BAN」より、ホワイトリスト+権限最小+バックアップが一番ラクで強いです。
更新管理:誰がいつ更新する?“勝手にMOD追加”を防ぐ
ルールは3行でOK(これで9割防げる)
- 更新は管理者だけが行う
- 更新日は決める(例:週末の昼)
- 更新前にバックアップ → 検証 → 本番の順番を守る
“勝手にMOD追加”を防ぐ仕組み
おすすめは「口約束」ではなく、配布の仕組みで封じることです。
- MODパック運用に寄せる(パックのバージョン固定)
- もしくは modsフォルダ一括配布(zip)にして
- 参加者は「入れ替えるだけ」
- 追加は禁止
にする
変更履歴(チーム運用の強い味方)
小さくてもいいので、更新のたびにこれだけ残します。
- 変更日
- 追加したMOD / 削除したMOD / 更新したMOD(バージョン込み)
- config変更の有無
- 問題が出たときの戻し先(バックアップ名)
💡これがあると「昨日まで動いてたのに」が即解決します。
配布・ライセンス配慮:MOD配布ルールの確認ポイント
MODは作者が作った作品なので、配布や同梱にルール(ライセンス)があることが普通です。
初心者が安全にやるなら、次の順で確認すると事故りません。
確認ポイント(最短チェック)
- 配布ページに 再配布OK/NG の記載があるか
- ライセンス表記(例:All Rights Reserved / MIT / LGPLなど)
- MODパックに同梱して公開する場合、同梱許可や条件があるか
- 「MOD本体(jar)を別場所に再アップロードしていいか」は特に要注意
安全な配布のやり方(初心者向け)
- リンク共有(公式ページへのリンクを送る)
- Modpack機能で共有(プラットフォームのルールに沿って配布)
- 身内でzip配布する場合も、できれば
- 公式配布先へのリンク
- MOD一覧(作者名・配布元)
を添えると、後から困りにくいです
NGになりやすい例(避けると安心)
- MOD作者が再配布を禁止しているのに、jarをまとめて再配布
- 許可が必要な形で、公開配布(不特定多数へ配る)
- 配布元が違うファイルを混ぜる/勝手に改変して配る
💡迷ったら:
「公式配布先へのリンク共有」か「Modpackとして正規手順で共有」が最も安全です。
ケース別おすすめ構成(迷う人向け)
「どの建て方が正解?」は、やりたいMODの重さと人数と運用の手間で決まります。
ここでは、初心者が迷いがちな3ケースを「まず成功しやすい形」に寄せて設計例を出します。
軽量MOD+少人数(まず成功しやすい形)
「便利系を少し入れて、2〜4人で遊ぶ」なら、まずは軽さと安定を最優先にすると成功しやすいです。
ねらい
- まず“普通に遊べる”状態を作る(ここが最重要)
- 追加するMODは少数からスタートし、後で増やす
推奨構成(例)
- 建て方:レンタル(テンプレ/管理画面あり) または Aternos(お試し)
- ローダー:軽量寄りのローダー(対応MOD次第)
- RAM目安:4〜6GB(少人数&軽量ならここから)
- ストレージ:SSD(レンタルなら基本OK)
- 参加者への配布:modsフォルダ一括配布 か 小規模MODパック運用
サーバー設定のおすすめ方針(軽量優先)
- view-distance / simulation-distance は“高すぎない”値で開始
(最初は欲張らず、重ければ少し下げて調整) - 参加者が増えたら、まず設定調整 → それでも厳しければRAM増強
失敗しない運用ルール(軽量ケース向け)
- MODは最初5〜10個程度までに抑えて起動確認
- “便利そうだから”で一気に増やさない(原因特定が地獄になります)
- 更新は「週末にまとめて」「管理者だけ」がラクです
工業・魔術など中〜重量MOD(安定優先の構成)
工業・魔術・冒険大型など、要素追加が多いMODは、メモリとCPUの余裕が体感に直結します。
「遊べるけど重い」を避けるには、最初から“安定寄り”で組むのがコスパ良いです。
ねらい
- サーバーの余裕を先に確保して、ラグや落ちを減らす
- “装置が増えるほど重くなる”前提で設計する
推奨構成(例)
- 建て方:VPS(24時間) か 高性能レンタル
- ローダー:入れたいMODが多い系統のローダー(対応MOD最優先)
- RAM目安:8〜12GB(5〜10人ならここから、重めなら上振れ)
- CPU:コア数よりも“1コアの強さ”が効きやすい(体感ラグ対策)
- 参加者への配布:MOD一覧固定(バージョン込み)→一括配布
安定させるための設計ポイント
- ワールド開始直後から“超巨大拠点”を作らない
→ 装置密集・MOB密度・搬送系がラグ源になりやすいです - 「重い要素」をチーム内で共有しておく
- 常時稼働装置
- 大量MOB・トラップ
- 広範囲探索(チャンク生成)
- パフォーマンスが落ちたら、まずは
距離設定の調整 → 装置/MOBの整理 → スペック増強
の順が安全です
運用ルール(中〜重量向け)
- MOD追加は小刻みに(1回で2〜3個までが目安)
- 更新前は必ずバックアップ
- 問題が出たら“戻せる”ように、バックアップを世代管理する
大型MODパック(導入・更新・配布の設計例)
大型MODパックは、導入がラクな反面、更新で壊れやすく、配布が雑だと必ず崩れます。
成功のコツは「パックを1つの製品として扱う」ことです。
ねらい
- サーバーと参加者の環境を“完全一致”で固定する
- 更新手順を決めて、事故ったら即ロールバックできるようにする
推奨構成(例)
- 建て方:VPS(または高性能レンタル)推奨
※無料枠は起動待ちや性能面でつらくなりがち - ローダー:パックが採用しているものに従う(ここは逆らわない)
- RAM目安:12〜16GB以上(パックと人数で上振れしやすい)
- 配布方法:パック名+パックバージョン固定で統一
- 参加者は同じアプリ/ランチャーで同じパックを入れる
- 「modsフォルダを各自でいじらない」ルールにする
導入設計のテンプレ(最短で安定する流れ)
- サーバー側:パックのServer Packがあるならそれを優先
- 参加者側:同じパックを同じバージョンで導入
- まず管理者だけ接続 → 次に1人 → 最後に全員
- 問題がなければ、初回バックアップを取って“基準状態”を保存
更新設計のテンプレ(壊さない手順)
- 更新は「サーバーだけ先に更新」ではなく、全員同じタイミングで統一が基本です
安全な順番
- 更新前バックアップ(world / mods / config をセット)
- 検証用フォルダ(または別サーバー)で起動テスト
- 管理者+1人で接続テスト
- 本番反映 → 全員に“更新案内テンプレ”を送る
- もしダメなら即ロールバック(バックアップから戻す)
配布のコツ(トラブルを減らす)
- 参加案内は「パック名」「パックバージョン」「起動手順」だけに絞る
- 追加MODや設定変更をやる場合は、変更点を必ずメモ(後で助かります)
- 不特定多数に配布するなら、MODの配布ルール(ライセンス)も確認する
よくある質問(FAQ)
統合版でも「MODサーバー」みたいなことはできる?
結論から言うと、Java版の“MOD(Forge/Fabric等)”と同じものは統合版では動きません。
ただし、統合版にも「似たこと」を実現する手段はあります。
統合版でできる“近いこと”
- アドオン(Add-ons)
アイテム・MOB・挙動などを追加/変更できる仕組みです。
Java版MODほど自由度が高いとは限りませんが、用途次第では十分楽しめます。 - マーケットプレイスのコンテンツ
導入が簡単で、参加者も迷いにくいのがメリットです(反面、自由度や選択肢はJavaほどではないことも)。 - 統合版(Bedrock)サーバーでの配布・導入
運用方法は環境によって違うため、「同じワールド・同じアドオンで揃える」設計が重要です。
逆に、Java版MODサーバーが向くケース
- 工業・魔術・大型要素など、Java版MOD文化の強みを楽しみたい
- MODパックで“別ゲーム級”の体験をしたい
- 参加者全員がJava版を使える
👉 迷ったら:
「遊びたいコンテンツがJava MODなのか、統合版アドオンなのか」で先に決めるのが最短です。
プラグインとMODを同時に入れたい(代替案の考え方)
まず前提として、一般的な意味での「プラグイン(Bukkit/Paper系)」と「MOD(Forge/Fabric系)」は、土台が違うため“そのまま両立”は難しいです。
そこで考え方は、次の3ルートに分かれます。
ルートA:MOD優先(MODサーバーで、必要機能はMODで代替)
- 例:保護・権限・管理・ミニマップ等も、MOD側で似た機能を探す
- メリット:MODの互換性が保ちやすい/MODパック運用に強い
- デメリット:プラグイン資産(Paper用の便利機能)が使えない
ルートB:プラグイン優先(Paper系で、MODっぽさは別手段で)
- 例:データパック+プラグインで遊びを拡張する
- メリット:運営・管理・保護・権限・ログ監視がやりやすい
- デメリット:Java版MODほどの大改造は難しいことが多い
ルートC:ハイブリッド(MOD+プラグインの“両対応”をうたう土台)
- コミュニティ製の“混在サーバー”が存在します(例:ハイブリッド系サーバーソフト)。
- メリット:目的がハマれば便利
- デメリット(重要):
- MOD/プラグインの相性問題が増えやすい
- サポートや情報が分散し、トラブル時の切り分けが難しい
- MODパックの前提環境とズレると破綻しやすい
👉 初心者におすすめの結論:
「MODを主役にしたいならルートA」、「運営機能が主役ならルートB」が失敗しにくいです。
混在は“最後の手段”として考えると安全です。
無料で24時間稼働できる?
現実的には、“完全無料で24時間安定稼働”はかなり難しいです。理由は単純で、常時稼働にはサーバー側のコスト(CPU/RAM/電気/回線/保守)が発生するからです。
ただし「無料っぽく見える形」はあります。
よくある無料枠の実態
- 無料ホスティング:
- 起動待ち(キュー)
- “誰もいないと停止”
- MOD/ファイルの自由度に制限
などがセットになりやすいです。
- 自宅PCで運用:
サービス料金はかかりませんが、電気代・回線・PC負荷・セキュリティは自己責任です。 - クラウドの無料枠:
一時的に無料でも、仕様変更や制限があり得ます。
また、常時稼働やゲーム用途が規約・性能・安定性の面で厳しいこともあります。
👉 結論としては、次のどちらかに寄せると失敗しません。
- 「お試し=無料(制限込み)」
- 「本格=有料(安定を買う)」
参加者が増えたら何から強化すべき?
やみくもにスペックを上げるより、“どこが詰まっているか”で優先順位が変わります。
初心者向けに、判断しやすい順でまとめます。
まず最優先:設定と運用(お金をかけずに効く)
view-distance/simulation-distanceを欲張らない- 常時稼働の装置(工業・トラップ)やMOB密度を整理
- チャンク生成(探索)が重いなら、探索を分散・控えめにする
- MODを増やしすぎない(追加は小刻みに)
次に強化:RAM(メモリ)
次の症状が多いなら、まずRAMが効きやすいです。
- 接続人数が増えるほど不安定
- 起動はするがプレイ中に落ちる
- Out Of Memory系が疑われる
目安としては、軽量少人数なら4〜6GBからでも始められますが、人数・MODが増えるほど上振れします。
次に強化:CPU
次の症状が多いならCPUがボトルネックの可能性が高いです。
- TPSが落ちて体感ラグ(カクつき・反応遅れ)が出る
- 装置やMOBが増えると急に重くなる
- メモリを増やしても改善が弱い
(マイクラは“コア数”よりも1コアの強さが効く場面が多いです。)
状況次第で強化:SSD/NVMe と回線
- ワールド読み込みが遅い/再起動が長い → SSD(できればNVMe)
- ゴムバンド現象(位置が戻る)や夜だけ不安定 → 回線(上り・品質)
迷わない結論(優先順位テンプレ)
- 距離設定と運用の見直し
- RAM増強
- CPU強化
- SSD/NVMeと回線の見直し
まとめ(今日から迷わず始めるために)
マイクラMODサーバーは難しく見えますが、押さえるべきポイントは意外とシンプルです。
一番大事なのは、最初に“揃えるもの”と“運用ルール”を固定することでした。
この記事の要点
- MODマルチは、まず Minecraft本体/MODローダー/MOD の3点セットを揃える
- 建て方は目的で選ぶ
- とにかく簡単:レンタル(管理画面あり)
- 無料で試す:Aternos(制限あり)
- 自由度重視:自宅PC(設定は多い)
- 24時間・重いMOD向け:VPS(安定運用)
- トラブルの多くは「環境のズレ」
- バージョン違い/前提MOD不足/config差が原因になりやすい
- MOD一覧(バージョン込み)を固定して一括配布すると“入れない”が激減する
- 長く遊ぶなら「運用」が勝ち
- 更新前バックアップ → 検証起動 → 本番反映
- ホワイトリストと最小権限で荒らし対策
- バックアップは保存先と復元テストまでセットで考える
次にやること(最短チェック)
- 遊びたいMOD(またはMODパック)の 対応Minecraft版とローダー を確認
- 人数とMOD量から、必要な建て方(レンタル/Aternos/自宅/VPS)を選ぶ
- MOD一覧(バージョン込み)を固定し、参加者に同じ構成を配布する
- まずは管理者→1人→全員の順で接続テストし、問題がなければバックアップを取る
ここまでできれば、MODサーバーは「たまに詰まる難しい遊び」ではなく、みんなで長く楽しめる遊び場になります。
あとは、軽量構成で成功体験を作ってから、工業・魔術・大型MODパックへ広げていきましょう。
