AGAMES マイクラ徹底解説｜料金・始め方・MOD対応・トラブル対処まで網羅

2026年2月10日

「AGAMESでマイクラサーバーを立てたい」と思って調べ始めたものの、こんなモヤモヤはありませんか？

「結局、月いくらで遊べるの？追加料金が膨らまないか不安…」
「標準・MAX・プレミアムって何が違う？どれを選べば失敗しない？」
「申し込みから起動まで、初心者でも迷わずできる？どれくらいで遊べる？」
「MODやプラグインはどこまで対応？ Forge/Fabric/Paperって何が違うの？」
「入れない・落ちる・ラグい…ってなったとき、自力で直せる？サポートは頼れる？」
「運営元や規約、問い合わせ先は？安全に使えるサービスなのか確認したい」

マイクラのサーバー運用は、最初の選び方を間違えると「思ったより重い」「常時稼働できない」「設定が難しい」といったつまずきが起きがちです。
特にAGAMESは、プラン選び・構成（CPU/メモリ/容量）・サーバー種類（Vanilla/Paper/Forge/Fabric/Mohist）など“選択肢が多い”ぶん、はじめての人ほど迷いやすいのも事実です。

そこで本記事では、AGAMESの公式情報をベースに、

料金の考え方（見積もりの作り方、追加費用が出やすいポイント）
申し込み〜起動までの最短手順（接続情報の確認、Java/統合版チェックリスト）
MOD/プラグイン導入の失敗しない流れ（依存・競合・ログの見方）
ラグ/クラッシュ/参加できない等のトラブル対処
長期運用のコツ（バックアップ、権限管理、プラン変更・移行の出口設計）

を、初心者でも迷わないように整理しました。

「今日中に遊び始めたい人」も、「これから長期運用したい人」も、この記事を読み終えるころには、自分に合うプランと構成が判断でき、必要な手順が一通りわかる状態になるはずです。

最初に結論：あなたはどのプランが向いている？（3分診断）

まずは「何を優先するか」だけ決めれば、だいたい外しません。下の3つを順番にチェックしてください。

3つの質問に答えるだけ

Q1. サーバーを“ほぼ24時間”動かしたい？（深夜〜早朝も誰かが入る）

YES → MAX かプレミアムが本命（「標準」は運用上のクセが強い）
NO → 標準でもOK（短時間だけ遊ぶ・集まるときだけ起動する）

Q2. どの版で遊ぶ？

統合版（Bedrock）中心 → まずは軽めでOK（小規模なら低メモリから始めやすい）
Java版中心 → 低メモリだと足りないことが多い（特に人数・プラグインで増える）
Java⇄統合の“クロスプレイ”もしたい → Java側の構成が基準（導入物が増える）

Q3. 遊び方は軽い？重い？

バニラ（ほぼ素のマイクラ） → 低〜中スペックで十分なことが多い
プラグイン（Paper等） → 中スペック以上が安定
MOD（Forge/NeoForge等） → スペック増強前提（MAX/プレミアム推奨）

迷ったらこの“初手”が安全（目安）

スクロールできます

あなたの状況	初手のおすすめ	理由（ざっくり）
週末に友達と数時間だけ、軽く遊ぶ	標準（低メモリ〜）	費用を抑えやすい／始めやすい
平日も誰かが入る・放置装置を回す	MAX	常時運用しやすい前提
大人数・イベント運用・重めの構成	プレミアム	余裕を作ってトラブルを減らす
途中で重くなりそう／まず試したい	標準 or MAX → 必要に応じて増強	構成アップグレードが可能（差額は日割り）

💡 料金は「CPU/メモリ/ストレージ/オプション」の合算で決まります。見た目の“プラン名”より、実際に選ぶメモリ量が体感に直結します。
また、価格表と申込画面が違う場合は、申込画面（カート）の表示が優先です。

常時稼働が必要なら「標準」は要注意（強制停止/制限の把握）

「24時間サーバー」として運用したいなら、ここが最大の分かれ道です。

標準サーバーは“毎日止まる”前提で考える

標準サーバーには、毎朝の自動シャットダウンがあります。つまり、

深夜に誰かが入っていると 強制的に落ちる
友達が海外・夜型だと 遊ぶ時間帯と衝突しやすい
放置トラップや常時稼働の装置は 相性が悪い

という運用上のクセが出ます。

じゃあ常時稼働したい人はどうする？

現実的な選択肢は次のどれかです。

MAX / プレミアムにする
→ そもそも「落ちる前提」ではないので、運用がラク。
（どうしても標準を使うなら）止まる前提で“自動運用”を組む
例：
- 夜中に「あと5分で停止する」などの告知を自動送信
- 停止前にバックアップを取る
- 停止後に自動で起動する
  こういう「定時タスク」は、コントロールパネルのスケジュール機能で組めます。
  ※ただし、“毎日止まること自体”は回避できないので、完全な常時稼働にはなりません。

「バックアップがあるから安心」は半分だけ正しい

AGAMESにはコントロールパネル上でバックアップを作る機能がありますが、サービス側が勝手にバックアップしてくれるわけではありません。
大事なワールドほど、自分で定期的にバックアップを作る（＋PCにも退避）を基本にしてください。

Java版／統合版（Bedrock）／クロスプレイ：どれで遊ぶ？

結論から言うと、“誰が・何で入るか”が決まれば、必要スペックも決まります。

統合版（Bedrock）が向いている人

Switch / PS / スマホ / Windows など いろんな端末で入りたい
なるべく 導入をシンプルにしたい
小〜中人数で遊ぶことが多い

統合版は小規模なら軽めで回ることが多く、AGAMES側の案内でも1〜2GBが統合版に向く旨が示されています。

Java版が向いている人

PC中心で、遊び方をカスタムしたい
プラグインやMODを入れたい
サーバー文化（Paper/Forge等）に慣れている

Java版は構成次第で一気に重くなります。AGAMES側の案内でも、Javaは4〜8GB以上が推奨という目安が示されています。

クロスプレイ（Java⇄統合）をやりたい人へ

「全員が同じ版」よりも難易度が上がります。基本は Javaサーバー側に仕組みを入れて実現します。

公式FAQの案内例：Paperサーバー＋Geyserプラグインでクロスプレイが可能

クロスプレイは便利ですが、導入物が増える分だけ

設定ミスが起きやすい
バージョン差分の対応が必要になりやすい
ので、余裕を持ったスペック（少なくともJava基準）で考えるのが安全です。

バニラ・プラグイン・MOD：重さで必要スペックが変わる

同じ「Java版」でも、遊び方で必要スペックは別物になります。ポイントは メモリが足りない＝落ちる／カクつく に直結しやすいこと。

ざっくり負荷イメージ（軽い→重い）

バニラ：軽い（ただし人数が増えると急に重くなる）
プラグイン（Paper等）：中（便利機能の分だけ負荷増）
MOD（Forge/NeoForge等）：重い（前提として増強を見込む）

初心者が失敗しない“決め方”はこれ

「今」ではなく「1〜2か月後」を想像して決めるのがコツです。

今は2〜3人でも、あとで人が増えそう → 最初から少し余裕
MODを入れる可能性がある → 標準よりMAX以上を優先
“軽い構成”のつもりでも、建築が進むとワールドが重くなる → バックアップ＋監視を習慣化

スペック不足を早めに見抜くチェックリスト 🧩

コントロールパネルでは、CPU/メモリなどの使用状況を確認できます。次が増えてきたら増強のサインです。

TPSが落ちる／ブロック更新が遅れる
テレポートや移動でラグが出る
ログにエラーが増える
メモリ使用が常に高止まりする

✅ AGAMESでは途中でコア数・メモリ・ストレージ等のアップグレードが可能（差額は日割り）なので、
“最初は控えめ → 症状が出たら増やす”も現実的です。
※ダウングレードは返金がない点に注意。

「AGAMES マイクラ」で多い悩み（この記事で全部解決）

料金は本当に安い？追加費用はどこで増える？

結論、AGAMESの料金は「基本が安く見えやすい一方で、増えるポイントが明確」です。
だからこそ、どこで上がるかを知っておけば、想定外の出費はほぼ防げます。💰

追加費用が増えやすいポイント（ここだけ押さえる）

メモリ（RAM）：人数・プラグイン・MODで増えがち
CPUコア数：大人数や処理が重い構成で必要に
ストレージ：ワールド肥大化、バックアップ運用で増える
プロセッサー（MAX/プレミアムのCPU種別）：高性能CPUを選ぶと上乗せ
オプション：必要な人だけ追加（内容は公式の価格表で確認が安全）

料金の仕組みはシンプル（計算できる）

AGAMESのマイクラ料金は、基本的に次の足し算です。

月額 = プロセッサー代 + コア数代 + メモリ代 + ストレージ代 + オプション代

✅ 大事：価格表よりも「カート（申込画面）の表示が優先」です。
✅ もう1つ大事：価格は予告なく変わる場合があるので、最終確認は申込画面で。

無料枠がある（＝最初のハードルが低い）

プランによって「無料スタートできる部分」が違います。目安としてはこんな感じです。

スクロールできます

項目	標準	MAX	プレミアム
コア数の無料スタート	4コア	6コア	8コア
ストレージの無料スタート	20GB	50GB	100GB

※「無料枠を超えた分」だけが上乗せされるイメージです。

“安く見える”のに高くなる典型パターン

最初は低メモリで始める → 途中からMODやプラグインを追加 → RAM増強で月額UP
長期運用で建築が進む → ワールド肥大化 → バックアップも増えてストレージ増強
人数が増える → TPS低下 → CPUコア or RAM増強

契約期間の注意（見落としがち）

月間／半年一括／年一括があり、長期ほど割安
ただし、途中解約しても返金なし（前払い方式のため）

初心者でも迷わず立てられる？何分で遊べる？

結論、初心者でも進めやすいです。理由は、コントロールパネルが“マイクラ前提”で用意されているから。🧭

だいたいの所要時間（目安）

最短：10〜30分くらい
（決済が即反映 → コントロールパネルで起動 → アドレス共有までスムーズな場合）
遅くても：支払い後24時間以内
（サーバー詳細はメールで案内される仕様）

⏱️ 注文後、12時間以内に入金・支払いがないとキャンセルになる点も要チェックです。
「あとで払おう」が原因で、開始が翌日になることが多いです。

“迷子になりやすいポイント”だけ先回りして潰す

どの版で遊ぶか（Java / 統合版）を先に決める
バージョンを揃える（友達と同じ）
最初は盛りすぎない（MOD山盛りで始めると沼りやすい）

初心者にうれしい機能（覚えるのは名前だけでOK）

本文中で使う頻度が高いのはこのへんです。

バックアップ：ワンクリックで作成・復元
バージョン切替：主要ソフト＆バージョンに対応
サブドメイン提供：友達に共有しやすいアドレスを作れる
SFTP / ファイル編集：MODや設定ファイルの管理がしやすい

MOD/プラグインはどこまで対応？

結論、AGAMESは「バニラ〜MOD/プラグインまで幅広く」に寄せた設計です。🧩
ただし、万能ではないので、“何ができるか”と“どこが重くなるか”を分けて考えると失敗しません。

対応範囲（公式が例として挙げているもの）

サーバーソフト例：Vanilla / Forge / Paper / Spigot / 統合版 / Magma / LiteLoader など
バージョン：1.7.10以降（提供状況に準ずる）

ここから先は「重さ」の話（重要）

MOD/プラグインは、対応していてもスペック不足だと厳しいです。

プラグイン（Paper系）
- 体感の安定性に効く
- ただし追加するほどメモリ使用量は増える
MOD（Forge系）
- 導入物が増えるほど一気に重くなる
- “推奨メモリ”より余裕を見た方が事故りにくい

✅ 目安として、Java版は「4〜8GB以上が推奨」という考え方が示されています。
（MOD盛りなら、さらに余裕が欲しくなるケースが多いです）

初心者におすすめの進め方（失敗しにくい順）

バニラで起動して参加できる状態を作る
次に 軽めの追加（プラグイン少数）
最後に MODや大型構成（この段階でRAM増強を検討）

安全性・運営元・問い合わせ先は？

結論、仕組みとしては「最低限以上は揃っている」タイプです。
ただし、オンラインサービスなので、“自衛できる部分”もセットでやるのが安心です。🔐

通信・攻撃対策（サービス側）

L3/L4のDDoS緩和が月額に含まれる
10Gbps回線が月額に含まれる

※「絶対に落ちない」を保証するものではありませんが、一般的な個人運用よりは前提が整っています。

アカウント保護（自分でやると強い）

二要素認証（Google Authenticator）を有効化
パスワードは
- 使い回さない
- 長め＆ランダム寄り
- 可能ならパスワード管理アプリを使う

運営元の確認ポイント

運営会社名、所在地、連絡先は特定商取引法に基づく表記で確認できます
利用ルールは利用規約で確認できます
「返金なし」「自動更新」などの条件は、申し込み前に必ず把握しておくのが安全です

困ったときの問い合わせ先（おすすめ順）

体感で早い順に書きます。📩

Discord（推奨）：早めの返信が期待できる案内
クライアントエリアのチケット：記録が残るのでトラブル整理に強い
メール：急ぎでなければOK

✅ 公式の案内でも、返信はベストエフォート（混雑状況で時間が変わる）とされています。
“急ぎ＝Discord、整理したい＝チケット”が基本戦略です。

AGAMESとは：マイクラ向けに何が便利なのか

AGAMESは、マイクラのマルチサーバー運用で面倒になりがちな

初期構築（バージョンやソフトの導入）
日々の運用（起動・停止・バックアップ・設定変更）
トラブル対応（ログ確認・負荷確認・設定の切り分け）

を、「ゲーム向けの管理パネル」中心にまとめて済ませやすいサービスです。
公式ページでも、サーバー構築の多くが自動化され、数分で立ち上げられる旨が案内されています。

自動構築＋管理パネルで「運用がラク」になる理由

初心者がつまずきやすいのは、実は「立て方」よりも “立てた後の管理” です。
AGAMESはそこを、パネルで次のように補ってくれます。

1つ目：最初の「環境づくり」を短縮できる

バージョンやソフト（例：Paper/Forge系）を、手作業よりラクに準備しやすい
うまくいかなかった時も、パネルで切り分けしやすい（ログ・設定画面が近い）

2つ目：運用に必要な操作が“画面内で完結”しやすい

たとえば、友達サーバーで頻出の操作はこれです。

サーバーの起動・停止・再起動
バックアップ作成・復元・ダウンロード
設定ファイルの編集（server.properties 等）
MOD/プラグインの追加・削除（ファイル管理 / SFTP）
ログ確認（エラーの原因探し）
負荷の確認（CPU/メモリ/容量がどれだけ使われているか）

「何か起きたら、とりあえずここを見る」が1か所に寄るので、初心者でも迷子になりにくいです。

3つ目：サーバーの“引き継ぎ”がラクになる

友達と共同運営するときに地味に助かるのが、次の仕組みです。

サブユーザー（権限付きアカウント）で共同管理しやすい
サブドメインを付けておくと、アドレス共有がわかりやすい
（さらに将来ノード変更などで接続先が変わっても、サブドメイン側は変えずに済むケースがある）

管理画面でできること（起動・設定・バックアップ・バージョン切替など）

ここでは「初心者がよく使う機能」だけに絞って、何ができるかを整理します。

コンソール：ログ確認とコマンド操作が中心

コンソールでは主に次ができます。

ログ表示：正常起動したか、どこでエラーが出たかを確認
コマンド送信：op や ホワイトリスト関連などを入力して設定できる
接続情報の確認：IPやPORTの確認（Java版はサブドメイン設定で見た目を簡略化できる）
負荷の見える化：CPU/メモリ/ストレージ使用量などの目安が表示される

👉 初心者は「参加できない」「落ちる」「重い」の3つのときに、まずコンソールを見るのが近道です。

ファイル：アップロード、編集、圧縮などの“基本作業”

ファイル画面では、MODや設定ファイルを扱う基本操作がまとまっています。

ファイル/フォルダ作成
アップロード（MODファイル等）
テキストファイル作成（json/txt など）
名前変更・移動・権限変更（chmod形式）
圧縮（tar.gz）・削除

「とりあえず置きたい」「軽い修正をしたい」ならファイル画面で十分なことも多いです。

SFTP：安定して大量に扱うならこちらが本命

ファイル画面は便利ですが、AGAMESの案内ではアップ/ダウンはSFTP推奨になっています。

安全かつ安定して転送しやすい
標準でSFTP機能が付いている（追加手続きなし）
接続情報はパネル内で確認でき、パスワードはパネルと同じ

✅ MODパックなどファイル量が多い運用は、最初からSFTP前提にするとラクです。

バックアップ：自動で守ってくれるわけではない（重要）

初心者が誤解しやすい点ですが、AGAMESの案内では

サービス側が自動でバックアップを取ってくれるわけではない
パネルのバックアップ機能や、SFTPで自分のPCへ退避を推奨

という前提になっています。

バックアップ画面でできること（要点）

作成（名前を付けて管理）
除外設定（不要データを除外して軽くする）
ダウンロード（PCに保存）
復元（上書き注意）
ロック（削除防止）

👉 “大事なワールドほど、PCにもコピー”が安全です。

スケジュール：定期タスクを自動化できる

スケジュール機能では、指定時刻にサーバーへ指示を送れます。

例）

事前に告知メッセージを流す（say）
定時バックアップ
定時再起動（運用が安定しやすい）

また「パワーコマンド（起動/再起動/停止など）」もありますが、案内上 標準マイクラサーバーではパワーコマンドが利用できない点に注意してください。
（できる範囲で、運用を組み立てるのがコツです）

サブドメイン：無料で配布、ドメインも複数から選べる

AGAMESは、マイクラサーバーに無償でサブドメイン提供があります。

アドレスが覚えやすくなる
Java版はポート番号を省略しやすく、共有が楽になる
将来の変更にも強い（アドレス告知の手間が減る）

注意点として、エディション変更（Java⇄統合）をする前にサブドメインを削除しておくなどの運用ルールが案内されています。

共同運営：サブユーザーで「権限付き共有」ができる

パネルのサブユーザー機能で、

共同管理者のメールアドレスを登録
付与したい権限を設定
招待してログインしてもらう

という流れで、アカウントを丸ごと渡さずに共同運営ができます。

サポート導線（Discord/チケット/メール）を先に知っておく

初心者ほど「何かあった時の連絡先」が先に分かっていると安心です。
AGAMESサポートの案内では、連絡手段と目安が次の順で示されています。

Discord：通常は数分〜数時間（推奨）
チケット（クライアントエリア）：通常は24時間以内
メール：通常は2日間以内
※いずれもベストエフォート（混雑等で変動）とされています。

早く解決するためのコツ（初心者向け）

問い合わせる前に、これだけ揃えると往復が減ります。

サーバーのエディション（Java/統合）
いまのバージョン
何をしたら問題が起きたか（直前の操作）
コンソールのエラー（スクショ or テキスト）
MOD/プラグインを入れているか（あるなら一覧）

料金の考え方：いくらで運用できる？（見積もりの作り方）

AGAMESのマイクラ料金は、ざっくり言うと 「必要なパーツ代を足し算する」 方式です。
なので見積もりは、次の順で作るとブレません。

サーバー種別（標準 / MAX / プレミアム）を決める
必要スペック（CPUコア・メモリ・ストレージ）を決める
オプションが要るか決める
「月間 / 半年 / 年間」どれで払うか決める
最後に カート（申込画面）で最終金額を確認する

契約形態（毎月/半年/年）の違いと注意点

まず、契約形態で「支払い方」と「リスク」が変わります。ここを押さえるだけで失敗が激減します。

月間契約（毎月更新）

毎月、自動更新
前払い方式
いつでも解約手続きはできますが、支払済み期間の返金は不可
「まず試す」ならこれが無難 ✅

半年間契約（6か月一括）

6か月分を 一括前払い（自動更新）
途中解約はできても 返金なし
月間より 1か月分お得という考え方（半年費用＝月間費用×5）

年間契約（1年一括）

1年分を 一括前払い（自動更新）
途中解約はできても 返金なし
月間より 3か月分お得という考え方（年間費用＝月間費用×9）

初心者におすすめの選び方

迷ったら：月間（様子見しやすい）
「半年は確実に遊ぶ」なら：半年
「1年運用する」前提で、途中で大きく変えないなら：年

💡ポイント：長期ほど割安ですが、途中でやめても返金されない前提で選ぶのが安全です。

プラン料金の“最低金額”と、構成変更で増える項目

AGAMESの料金は基本的にこの足し算です。

サーバー代 = プロセッサー代 + コア数代 + メモリ代 + ストレージ代 + オプション代

そして価格表では、「0円」＝その構成で申込可能＆無料提供、「-」＝その構成は提供なし、という扱いになっています。

“最低金額”が成立する仕組み（まず無料枠を使う）

プランによって、最初から無料で付いてくる要素があります。例として：

標準：CPU 4コアやストレージ20GBが 0円から始められる
MAX：CPU 6コアやストレージ50GBが 0円から始められる
プレミアム：CPU 8コアやストレージ100GBが 0円から始められる

つまり、最初の見積もりは 「0円の範囲で足りるか」→足りない分だけ足す が基本です。

構成変更で増えやすい項目（どこで上がる？）

初心者が「思ったより高くなった…」となりがちなのは、だいたいここです。

メモリ：人数増、描画負荷、プラグイン/ MOD追加で増えやすい
CPUコア：人数増や重い処理（大型建築、常時稼働の負荷）で必要に
ストレージ：ワールド肥大化、バックアップを残す運用で増えやすい
プロセッサー（MAX/プレミアム）：CPUの種類で加算が発生
オプション：必要な人だけ（内容と金額は申込画面で確認が確実）

見積もりテンプレ（コピペして使える）

「自分の構成」をこの形に当てはめると、見積もりが一瞬で作れます。

サーバー種別：標準 / MAX / プレミアム
プロセッサー：＿＿円（該当する場合のみ）
CPUコア：＿＿円
メモリ：＿＿円
ストレージ：＿＿円
オプション：＿＿円
= 月間費用：＿＿円
→ 半年なら 月間×5 ／年なら 月間×9

例：標準で「まず動かす」最低ラインの考え方

CPU：無料枠（例：4コア 0円）
ストレージ：無料枠（例：20GB 0円）
メモリ：遊び方次第で有料（例：4GBなど）

ここで大事なのは、CPUやストレージが無料でも、メモリが有料になりやすい点です。
なので初心者は、まず 「メモリから逆算」すると見積もりが外れにくいです。

価格が変動しうる前提：公式の価格表を最終確認する

料金でトラブルが出やすいのは「見た情報が古かった」「途中で条件が変わった」パターンです。ここを先に知っておけば回避できます。

1) 価格表の金額は“告知なく変更”されうる

価格表自体が更新されることがあります。
なので最終的には、申込画面（カート）に表示された価格を正として確認するのが確実です。

2) “価格改定”には2種類ある（ここが重要）

AGAMES側の説明では、価格改定は大きく2つに分かれます。

既存価格の改定：すでに契約中の人にも影響しうる（ただし値上げは頻繁ではない）
今後の価格の改定：新規申込や、構成変更・プラン変更のときに新価格が適用されるタイプ（こちらは比較的起こりやすい）

つまり、同じ構成のまま使い続けるなら影響が少ないこともありますが、
アップグレードする瞬間に“最新価格”へ切り替わることがある、という見方が安全です。

3) 初心者がやるべき“最終チェック”3つ ✅

申込前に、最低この3つだけ確認すればOKです。

価格表の更新日（古くないか）
カート表示の最終金額（ここが最優先）
途中解約＝返金なしを理解しているか（長期契約ほど重要）

プラン比較：標準・MAX・プレミアムの違いを「運用目線」で整理

AGAMESの3プランは、単に“速さ”だけでなく、運用の自由度（＝毎日止まるか／自動化できるか）が大きく違います。
初心者が迷いやすいポイントは「値段」よりも、実は “止まる前提かどうか” です。

まずは、最重要ポイントだけを表で整理します。

スクロールできます

観点	標準	MAX	プレミアム
向いている人	低コストで短時間運用したい	少人数〜中規模の本命	大人数・重い構成・長期運用
CPUの方向性	一般的な高クロック（Xeon系）	ゲーム向けRyzen 9	最上位クラスRyzen 9（X3D系）
常時稼働	毎朝自動停止あり	なし	なし
標準コア数の目安	4コア〜	6コア〜	8コア〜
標準ストレージの目安	20GB〜	50GB〜	100GB〜
自動化（スケジュール）	できることに制限あり	自動化しやすい	自動化しやすい
最低構成の月額目安	低い	中	高（ただし性能も最大）

※実際の月額は「メモリ・コア・容量・オプション」の選び方で変わります（最終金額は申込画面が基準）。

標準サーバー：とにかく安いが、制限を理解して選ぶ

標準は“お試し〜身内サーバー”として使いやすい反面、運用上のクセがあります。
ここを知らずに選ぶと「思ってたのと違う」が起きやすいです。

おすすめの使い方
- 週末に集まって数時間遊ぶ
- 少人数でバニラ中心
- 「安く始めて、必要になったら上位へ」を想定している
避けた方がいい使い方
- 夜間も誰かが入る
- 放置装置・常時稼働前提
- “いつでも入れるワールド”として運用したい

常時稼働の扱い（毎日停止など）

標準は、毎朝4時に自動シャットダウンがあります。
つまり「ほぼ24時間の常設サーバー」にしたい人ほど不向きです。

とはいえ、工夫でダメージは減らせます。

3:55に 「あと5分で止まる」告知を流す
3:58に ワールド保存（save-all）
3:59に バックアップ作成

このように「止まる前に整える」運用を組むと、事故は減ります。
ただし、次の点は割り切りが必要です。

止まった後の“自動起動”は、標準ではやりにくい（後述の制限による）
「深夜に誰かが遊べる」状態を常に維持するのは難しい

スケジュール系の制限（できる/できない）

AGAMESのスケジュール機能は便利ですが、標準のマイクラ（標準サーバー）では “電源操作（起動/停止/再起動）”に制限があります。

標準でやりやすいこと（例）

コマンド送信（例：sayで告知、save-allで保存）
バックアップ作成（定期バックアップの自動化）

標準でやりにくいこと（要点）

パワーコマンド（起動/再起動/停止/強制終了）をスケジュールから使う
→ 「止まったら自動で起動」みたいな運用は組みにくいです。

初心者向けの結論としては、標準は
“止まる前に備える”自動化は得意／“止まった後に立て直す”自動化は苦手
と覚えると判断がラクです。

MAXサーバー：少人数〜中規模の“本命”になりやすい理由

MAXは「値段と快適さのバランス」で選ばれやすい層です。
標準より運用が素直で、“普通にマルチをやりたい人”の満足度が上がりやすいのがポイント。

こんな人に合う
- 平日も誰かが入る（常設に近い）
- Java版で遊びたい
- プラグイン（Paper系）を入れて便利にしたい
- 参加人数が増減するけど、安定性は欲しい
MAXが“本命”になりやすい理由
- 自動停止がないため、運用のストレスが減る
- ゲーム向けCPUの系統で、体感が安定しやすい
- スケジュールで「再起動」「バックアップ」など、運用の型を作りやすい

特に初心者は、標準で「毎日止まる問題」に悩むより、
MAXで「普通に運用する」方が結果的にラクになりがちです。

プレミアム：大人数・重いMOD・長期運用向けの考え方

プレミアムは「とにかく余裕を作って事故を減らす」方向の選択です。
初心者でも、次の条件に当てはまるなら検討価値が出ます。

プレミアムが向く典型パターン
- 大人数（イベント・公開・コミュニティ運用）
- MODパックなど重い構成
- 長期運用で、ワールド肥大化が確実
- “落ちないこと”の優先度が高い
初心者がプレミアムで得しやすいポイント
- 初期から余裕があると、トラブルの原因が減り、
  「原因切り分け」に時間を取られにくい
- 運用が長期化しても、後から増強の回数が少なくなりやすい

もちろん「最初からプレミアム」はやりすぎになることもあるので、
迷ったら MAX →（必要なら）プレミアムの順で上げるのも堅実です。

プロキシー（BungeeCord/Velocity）を使うべきケース

プロキシーは一言でいうと、「入口（ロビー）を作って、複数サーバーをつなぐ中継役」です。
必須ではありませんが、運用の目的がはっきりしていると強力です。

使うべきケース

1) サーバーを“分けて”運用したい

ロビー（Hub）
生活（サバイバル）
ミニゲーム
建築ワールド
のように、役割別に分けたいとき。

2) 接続の入口を一本化したい

参加者には「このアドレスだけ教える」
裏側のサーバーを増減しても、入口は変えない
という運用がしやすくなります。

3) 公開・大人数で“入口の負荷”をさばきたい

ピーク時の接続処理を、プロキシー側で受け止めて
ゲーム本体側の負荷を抑える設計を取りやすいです。

4) セキュリティや運用を強化したい

入口で弾く／制限する
サーバー間の移動を管理する
など、公開運用で欲しくなる機能を載せやすいです。

注意点（初心者が見落としがち）

プロキシーは“別サーバー”として用意するのが基本です。
つまり、プロキシー＋ゲームサーバーで 契約が2つになるイメージ。
最初から入れると構成が複雑になりがちなので、初心者は
「まずは1台で安定運用 → 伸びたらプロキシー」が失敗しにくいです。

人数・遊び方別：おすすめ構成の目安（失敗しないスペック設計）

スペック設計で一番ラクなのは、「メモリ→CPU→ストレージ」の順に決めることです。
マイクラは“とりあえずメモリ”になりがちですが、実際は CPUが原因のラグも多いので、最後に「症状別の増やし方」まで押さえると失敗しません。

まず公式の目安として、AGAMESは次の方向性を示しています。

統合版（Bedrock）は1〜2GBが最適
Java版は4〜8GB以上が推奨
（ただし、プラグイン・MOD・ワールド内容・設定で必要スペックは変わります）

以降はこの公式目安を“土台”にして、初心者が選びやすいように具体化します。

バニラ（軽め）で遊ぶ：必要メモリの考え方

バニラは「軽い」寄りですが、人数・建築量・自動化で重くなります。
目安は次のイメージでOKです（迷ったら「少し上」を選ぶのが安全）。

まずはメモリを決める（目安）

統合版：1〜2GB（小規模なら十分になりやすい）
Java版：4GB〜が出発点、安定を取りたいなら6〜8GBが安心

人数別の“ざっくり設計”例（バニラ）

スクロールできます

版 / 人数感	まずのメモリ目安	こうなったら増強の合図
統合版（少人数）	1〜2GB	読み込みが遅い・カクつく
Java版（1〜3人）	4GB	メモリ不足エラー、頻繁に落ちる
Java版（4〜10人）	6〜8GB	移動時ラグ、TPS低下が増える
Java版（10人以上）	8GB〜	常に重い、再起動しても改善しない

※「視界距離（view-distance）」を高くすると一気に重くなるので、最初は欲張らないのがコツです。

CPUとストレージはどう考える？

CPU：人数が増えるほど、同時に処理する量が増える
→ バニラでも「10人前後」からCPU（コア/性能）の重要度が上がります。
ストレージ：最初は無料枠でも足りがち
→ ただし長期運用＋バックアップを残すほど、後から増えます。

プラグイン運用（Paper/Spigot）：TPSを落とさない設計

プラグイン運用は、バニラより便利になる反面、「入れすぎ」と「設定ミス」で重くなるのが典型です。
ここでは、初心者が“最短で安定”させる設計ルールだけまとめます。

まず押さえる：TPSとは？

TPSは、超ざっくり言うと 「マイクラ世界の処理が追いついているか」の目安です。
TPSが落ちると、体感ではこうなります。

扉が開くのが遅い
ブロック破壊や成長が遅れる
モブやプレイヤーがワープする感じが出る

Paper/Spigotで失敗しない構成のコツ

最初はPaper推奨（安定運用の情報が多く、調整もしやすい）
プラグインは 「目的が同じものを重複させない」
例：権限系、ワープ系、保護系を複数入れると競合しやすい
導入は 1つずつ（問題が出たら原因を特定しやすい）

“重くしない設定”の考え方（初心者向け）

細かい数字より、方針だけ覚えるとラクです。

視界距離・シミュレーション距離は 上げすぎない
住民（村人）・ホッパー・トロッコは 増えるほど重い
大規模トラップは 作った瞬間から負荷が跳ね上がりやすい

プラグイン運用のメモリ目安（バニラより少し上）

Java版バニラで4GB相当なら、プラグイン運用は 6GB〜を検討
人数が増える／保護・経済・地図系など“重め機能”を入れるなら 8GB〜が安心

安定運用の「型」（これだけで事故が減る）

定期バックアップ（最低でも毎日1回）
定期再起動（軽いラグが蓄積しにくい）
ログ確認（エラーが増えたら早めに対処）

MOD運用（Forge/Fabric等）：メモリ・ストレージの増やし方

MODは「対応しているか」より、“継続して快適に動かせるか”が勝負です。
とくにワールド生成系・大型MOD・MODパックは、必要量が一段上がります。

まず結論：MODは“余裕が正義”

初心者が陥りやすいのは「ギリギリ動いた＝成功」になることです。
MODは後から追加・更新が起きやすいので、最初から余裕を持つほどラクです。

メモリの目安（MOD）

軽めのMOD少数：8GB前後が出発点になりやすい
MODパック級：12〜16GBを視野
大型MOD・人数多め：16GB以上が現実的

※「入れるMODの数」だけでなく、ワールド生成・機械・魔法・大量アイテム系は重くなりやすいです。

ストレージの考え方（MODは増えやすい）

MOD運用は、バニラよりも次の理由で容量が増えます。

MOD本体・設定・追加ファイルが増える
ワールド生成が重く、データが太りやすい
バックアップの世代が増える

安全策としては、ざっくり次の発想でOKです。

ワールド容量の2〜3倍の空きを残す
バックアップは「残す数」を決める（無限に残すと必ず圧迫）

失敗しにくい導入手順（MOD）

まずサーバーだけ起動（MODなしで土台確認）
MODを少数入れて起動（動作確認）
追加するたびにログ確認
重くなったら「最近入れたMOD」から切り分け

ワールドが重い時の典型原因（エンティティ/チャンク/自動化）

「重い」と言っても原因はだいたい4パターンです。
ここを押さえておくと、増強すべきか／設定で直るかの判断が速くなります。

1) エンティティが多い（最頻出）

エンティティ＝動くもの・落ちるもの、のイメージです。

落ちているアイテム
大量の動物・モブ
村人（増殖・取引所）
ホッパー、トロッコ、ボート、額縁・防具立てなど

対策（初心者でも効く順）

まずは 散らかったアイテムを減らす
村人・ホッパー・トロッコの数を見直す
トラップは稼働時間を決める（常時稼働しない）

2) チャンクが広く読み込まれている

チャンクが増えると、読み込み・保存・生物処理が増えます。

視界距離が高すぎる
複数人がバラバラの場所で活動している
ワールド生成（未探索）が多い

対策

視界距離・シミュレーション距離を上げすぎない
探索イベントは時間を区切る（生成が落ち着くと軽くなる）

3) 自動化・レッドストーンが重い

常時動く回路
大規模農場（収穫・仕分け・搬送）
大量のチェスト仕分け

対策

常時動作を減らす（スイッチ式にする）
搬送・仕分けの規模を調整する

4) スペック不足の“症状”を見分ける

増強判断は、次の見方が分かりやすいです。

落ちる／メモリ不足エラー → メモリ不足の可能性が高い
TPSが低い・処理落ちが常時 → CPU（性能/コア）や設定の可能性
バックアップ失敗・容量不足 → ストレージ不足の可能性

申し込み〜起動まで：最短で遊び始める手順

全体の流れ：注文→アカウント→サーバー起動→参加

最短で迷わないために、まずは全体像を1枚にまとめます。

1）公式ページから「マイクラ」プランを選ぶ
2）エディション（Java / 統合版）と構成（CPU・メモリ・容量）を選ぶ
3）アカウント作成（メール・パスワードなど）
4）支払いを完了する
5）メールで「サーバー詳細」が届く（支払い後24時間以内が目安）
6）コントロールパネルにログイン → サーバーを起動
7）接続情報（アドレス・ポート・バージョン）を確認 → 参加

つまずき防止の超重要ポイント

注文から12時間以内に支払いがないと、注文がキャンセル扱いになります。
「あとで払う」をやると、結局スタートが遅れがちです。
サーバー詳細は、公式案内では支払い後24時間以内にメールで連絡となっています。
まずはメール（迷惑メール含む）を確認し、次にクライアントエリアも見に行くと早いです。

構成選択：エディション/CPU/メモリ/容量の選び方

ここは「最初に決める4つ」だけ押さえればOKです。

1）エディションを決める（最優先）

Java版：PC中心。MOD・プラグインの選択肢が多い
統合版（Bedrock）：Switch/スマホ/Windowsなど。軽めで動きやすい

迷ったら：参加メンバーの端末に合わせる（混在なら後述のクロスプレイを検討）

2）CPUは“人数と重さ”で考える

少人数・バニラ中心：大きく悩まなくてOK（メモリ優先で決めやすい）
人数が多い／自動化が多い／プラグイン多め：CPUの重要度が上がる
→ 「重いワールド」「TPS低下」が出るなら、CPU（上位プラン含む）検討の価値あり

3）メモリは“最初から少し余裕”が安全

公式ページの目安が分かりやすいです。

統合版：1〜2GBが適性
Java版：4〜8GB以上が推奨

初心者の「失敗しない考え方」はこれです。

バニラで少人数：まず 4GB（Java）/ 1GB（統合） から
プラグインや軽MODを入れたい：まず 6〜8GB（Java）
MODパック級：最初から 12GB以上も視野（あとから増やすより事故が少ない）

4）容量（ストレージ）は“バックアップ込み”で決める

最初は無料枠から始めやすい一方、運用すると増えるのが容量です。

増えやすい理由

ワールドの肥大化（探索・建築が増えるほど）
バックアップを残すほど増える
MOD運用だと追加ファイルが多い

初心者向けの決め方

まずは「無料枠〜最小」で開始
バックアップを残す運用にするなら、早めに増量を検討
“ワールドが大事”なら、容量より先に「バックアップ設計」を決める（世代数を決める）

初回起動後に確認する3点（アドレス・ポート・バージョン）

サーバーを起動したら、最初にここだけ確認すれば参加で詰まりにくいです。

サーバーアドレス（接続先）
ポート番号（接続口）
バージョン（プレイヤー側と一致しているか）

コントロールパネルのコンソール画面に「参加に必要な情報」が表示されます。
特に重要なのは、IPだけでは入れず、基本は IP:PORT が必要という点です。

Java版：参加までのチェックリスト

[ ] サーバーが「起動中」になっている
[ ] アドレスを確認（基本は IP:PORT）
[ ] Java側のマイクラ起動 → 「マルチプレイ」→「サーバー追加」
[ ] サーバーアドレス欄に IP:PORT を入力して参加
[ ] 入れないときは、まず バージョン一致を確認
[ ] 共有するならサブドメイン設定も検討
Java版はサブドメインを使うと ポート番号を書かずに入れる形にできて、共有がラクになります。

統合版（Bedrock）：参加までのチェックリスト

[ ] サーバーが「統合版」になっている（エディション確認）
[ ] アドレスとポートを確認（統合版は入力欄が分かれていることが多い）
[ ] 「サーバー」→「サーバー追加」などから接続情報を入力
[ ] 入れないときは、まず アドレス/ポートの入力ミスを疑う
[ ] 参加後に管理したい場合は、権限付与（OP等）は手順がJavaと違う点に注意

クロスプレイ：前提条件とつまずきポイント

「Java版のサーバーに、統合版（Bedrock）の人も入れたい」なら、基本は Geyser（プラグイン） を使います。

前提条件（ここがスタートライン）

ベースは Javaサーバー
サーバーソフトは Paper 推奨（Geyser導入手順もPaper前提で説明されています）
Geyserを導入・設定して、Bedrockから接続できるようにする

つまずきポイント（初心者がハマりやすい順）

ポートの考え方
- 設定次第で「JavaとBedrockを同じポートで受ける」ことも、「別ポートに分ける」こともできます。
追加ポートが必要になるケース
- 別ポート運用にする場合、追加で割り当てたポートを設定に書く必要があります。
端末側の壁
- 統合版でも、機種によっては「外部サーバー追加」が手間なことがあります（特に家庭用機）。
  まずは参加メンバーの端末で“外部サーバーへ接続できるか”を早めに確認しておくと安全です。

管理パネル入門：運用がラクになる“重要タブ”だけ先に押さえる

最初に、管理パネル（コントロールパネル）でよく触る場所を整理しておきます。
初心者が迷うのは「設定項目が多い」からなので、まずはこの順で覚えるのがラクです。

スクロールできます

目的	主に使うタブ	まずやること
エラー確認・コマンド	コンソール	ログを見る／`say`で告知する
MOD/プラグイン導入・設定変更	ファイル	該当フォルダにアップ→設定ファイル編集
自動化（再起動・告知・バックアップ）	スケジュール	“毎日◯時”の定期処理を作る
データ保護	バックアップ	取得→PCへダウンロード→世代管理
複数人で運営	サブユーザー	権限を分けて招待する
参加しやすいアドレス	サブドメイン	先に注意点を確認してから作る
追加ポートが必要	ネットワーク	ポート追加→必要なら設定へ反映
MOD種別や起動方式	バージョン／起動パラメータ	変更時は必ずバックアップ前提で

コンソール：ログ確認・コマンド実行の基本

コンソールは「サーバーの状態を読む場所」です。困ったらまずここを見ます。

ログ（動作履歴）を見る
- 起動に成功しているか
- エラーが出ていないか（赤っぽい行、例外、プラグインの読み込み失敗など）
コマンドを送る
- 例：全員に告知 👉 say ○○します
- 例：権限付与（Java版）👉 op プレイヤー名
- 例：ホワイトリスト系の設定（運用方針に合わせて）
接続情報を確認する
- 原則は IP:PORT で参加（サブドメイン設定で入力が楽になる場合あり）
負荷の目安をつかむ
- CPU / メモリ / ストレージ使用量が高い状態が続くなら、設定見直しやスペック増強を検討 👍

💡迷ったときのコツ
「何をした直後に壊れたか」を思い出して、その前後のログを読むと原因が見つかりやすいです。

ファイル：アップ/ダウンロード、設定ファイル編集の要点

ファイルタブは「サーバーの中身を直接触る場所」です。MOD/プラグイン運用では必須になります。

よく使う操作（最低限これだけ）

アップロード
- MODファイル・プラグイン・既存データを入れるときに使用
- ドラッグ＆ドロップ対応のケースもあり、まずは小さめのファイルで試すと安心
新規作成
- txt / json などのテキストファイルを作って設定を書く場面で使います
名前変更／移動／削除
- 事故りやすいので、削除前にバックアップ推奨（特に world フォルダ）
権限（chmod）
- 一部ツールで必要になることがあります。分からない場合はむやみに変更しないのが安全
圧縮（tar.gz）
- まとめて保管・移動したいときに便利（Windowsなら解凍ツールで扱えます）

アップロードでつまずくポイント

MODパックは容量が大きいことが多い
管理パネル経由のアップロードには上限がある場合があり、大きいものはSFTPのほうが安定します。
バージョン不一致は失敗の典型
- サーバー側のMinecraftバージョン
- MOD/プラグイン側の対応バージョン
  ここがズレると起動しない・反映されない原因になります。

✅おすすめ運用
「大物はSFTP、小物はファイルタブ」にすると、作業が速くて失敗しにくいです。

バージョン：サーバー種類の切替（Vanilla/Paper/Mohist等）

ここは「遊び方を変えるスイッチ」です。たとえば：

バニラ（素のMinecraft）
Paper/Spigot系（軽量化・プラグイン運用向き）
Forge/Fabric系（MOD運用向き）
Mohist系（MOD＋プラグイン混在を狙う選択肢）

切り替え前に知っておくべき注意

ワールドは“下げる”と壊れやすい
- 新しいバージョンで作ったワールドを古いバージョンで開くとエラーになりやすいです。
環境を変えると挙動も変わる
- 同じ設定でも、サーバー種類が変わると負荷・互換性・プラグイン動作が変化します。

安全に進める基本手順はこれです👇

バックアップ取得（できればPCへも保存）
変更（サーバー種類／バージョン）
起動→ログ確認→問題があれば戻す（復元）

再インストール時の分岐（データ保持/初期化）

「環境がぐちゃぐちゃになった」「特定バージョンへ入れ替えたい」ときに、再インストール（再セットアップ）を使うことがあります。

データ保持で進めたいケース
- ワールドや設定を残したまま、軽微な調整で済む見込みがある
- ただし、互換性問題が残る可能性もあるのでログ確認は必須
初期化（クリーン）したほうが早いケース
- MOD構成を大幅に変えた
- 起動しない原因が特定できず、混在状態をリセットしたい
- Forgeなどで指定バージョンに入れ替えるためにファイルを整理→再インストールする手順が必要になる場合がある

⚠️超重要
再インストールや大きな切替をする前に、バックアップを取ってPCにも保存しておくと、最悪でも戻れます。

スケジュール：自動バックアップ・自動再起動の組み方

スケジュールは「放置で回る仕組み」を作る場所です。初心者でも効果が大きいので、早めに触るのがおすすめ。

まず作るべき“鉄板3点セット”

毎日：メッセージ告知（例：5分前）
毎日：停止 or 再起動（サーバー運用の方針に合わせる）
毎日：バックアップ作成

例（イメージ）🧩

2:55　say 5分後に再起動します
3:00　停止（または再起動）
3:02　バックアップ作成
3:15　起動（必要な場合）

知っておきたい制限

マイクラの標準サーバーではパワーコマンドが使えない場合があります。
その場合、スケジュールでできる範囲が変わるので、先に仕様を確認して「できる運用」に寄せましょう。

バックアップ：取得→復元→世代管理のルール

バックアップは「事故の保険」です。特にMODや設定変更をする人ほど必須。

重要ポイント（ここだけ覚えてOK）

自動でバックアップされる前提にしない
サービス側がサーバー全体のバックアップを取らない旨が明記されている場合があります。
→ 自分で定期的に取る運用にしておくのが安全です。
バックアップ作成時は、必要に応じて除外（ワイルドカードや否定記号）が使えることがあります
- 例：重いログを除外、ワールドだけ残す…など
PCへダウンロードして二重化する
- サーバー側に残すだけだと、故障・解約・操作ミスのリスクが残ります

世代管理のおすすめ

基本は 1日1回 を目安
“数分おき”で取りすぎると、上限に達して古い世代が消え、いざという時に戻れない…が起きがちです

サブユーザー：複数人運営の権限設計

複数人で管理するなら、ログイン共有は避けてサブユーザーが安全です。

招待の流れ（ざっくり）
- 管理パネルでサブユーザーを登録
- メールアドレスを入力
- 必要な権限だけ付与して招待
- 招待メール側でパスワード設定→ログイン

✅権限設計の例

「建築班」：ファイル編集なし／コンソールも基本触らない
「運用担当」：バックアップ・スケジュール・ログ確認はOK
「管理者」：すべてOK（最小人数にする）

サブドメイン：ポート番号なしで参加しやすくする

サブドメインは、参加案内がラクになります。

覚えやすいアドレスになる（例：xxx.minecraft.green など）
Java版ではポート番号を書かなくても良いケースがあり、案内がさらに簡単になります
ノード変更などでIPが変わっても、サブドメインが変わらないメリットがあります

⚠️注意点（先に知っておくと事故らない）
サブドメインを登録したあとにJava版⇄統合版へ切り替えると、削除ができなくなる旨の注意が案内されていることがあります。
エディションを変える可能性があるなら、切替前にサブドメインを削除しておくのが安全です。

ネットワーク：追加ポートが必要になる代表例（Dynmap等）

「MODや外部ツールが“別ポート”を使う」タイプは、ネットワーク（ポート追加）が必要になります。

代表例

Dynmap（Webで地図を見る系）
→ 追加ポートを割り当てて、Dynmap設定に書く流れになりやすいです
Java/Bedrockのポートを分けたい運用（設定次第）
一部の管理ツールや外部連携

だいたいの流れはこの形👇

ネットワークタブでポート追加（アロケーション登録）
割り当てられたポートをメモ
プラグインや設定ファイルに反映
再起動して動作確認

起動パラメータ：Javaバージョン/起動JARの注意点

起動パラメータは「起動の根っこ」を触る場所なので、初心者は“必要なときだけ”でOKです。

よくある用途（Minecraft系）

Forgeの特定バージョン指定（Forge version などの入力欄）
追加ポート（必要なポートを使えるようにする欄がある場合）
（環境によって）Javaバージョンや起動JARの指定

失敗しないための鉄則

要件を先に確認する
- MODパック配布元が推奨するMinecraft/Forge/Fabric/Javaの条件
変更前にバックアップ
- 起動しなくなったときに戻せる
変更後は必ずログを見る
- どこで止まったかが分かるので復旧が早い

MOD・プラグイン導入：失敗しない“最短ルート”

MODやプラグイン導入で失敗しやすいのは、作業そのものよりも

前提（バージョン整合）を確認せずに入れる
一気に入れすぎて原因が追えなくなる
落ちた時にログを見ずに勘で直そうとする

この3つです。

ここでは、初心者でも「短時間で安定」させやすい順番で解説します。

導入前に確認すべきこと（依存関係/バージョン整合/競合）

最初に、導入前チェックを“3分”で終わらせましょう。
ここを飛ばすと、後で30分〜数時間溶けます。💦

1）Minecraftの版とバージョンを固定する

Java版なのか / 統合版なのか
Minecraftのバージョンはいくつか（例：1.xx.x）
参加メンバーのクライアント側も 同じバージョンに揃える

✅コツ
「とりあえず最新にする」より、MOD/プラグインが安定している定番バージョンに揃える方が成功率は上がります。

2）入れるものの“種類”を切り分ける（混ぜると事故る）

プラグイン：Paper/Spigot系で動く（例：Geyser、Dynmapなど）
MOD：Forge / NeoForge / Fabric などで動く
データパック：バニラ寄り、比較的安全だが相性はある

ここが混ざると、よくある事故が起きます。

Forgeサーバーにプラグインを入れて「動かない」
PaperサーバーにMODを入れて「起動しない」

※例外として、後述のMohist系は「混在」を狙えますが、初心者は最初から狙わない方が安全です。

3）依存関係を確認する（入れ忘れが最頻出）

MODやプラグインには「前提ライブラリ」があることがあります。

例：このMODは「○○API」が必要
例：このプラグインは「Paper推奨」「Javaの特定バージョン必須」

チェック方法（初心者向け）

配布元ページの「Requirements」「Dependencies」欄だけ見る
必須（Required）と任意（Optional）を分けてメモする

4）競合を避ける（同じ役割を重ねない）

競合は「入れても起動するけど、おかしい」タイプが多いです。

保護系（土地保護）を複数
ワープ系を複数
経済・ショップ系を複数
チャット・表示系を複数

✅ルール
“同じ役割は1つに絞る”が鉄則です。

Forge/Fabric/（必要に応じて）Mohist：選び方の基準

「どれを選べばいい？」は迷いやすいので、初心者が判断しやすい基準で整理します。

Forge（またはNeoForge）が向く人

MODの情報が多い構成を使いたい
大型MOD・定番MODが多い環境を作りたい
MODパックを動かしたい

特徴（覚えるのは1つだけ）

MODの選択肢が広い反面、更新や相性がシビアになりやすい

Fabricが向く人

軽量・最適化系MODを中心にしたい
できるだけ軽く運用したい
“必要最低限だけMOD”の方針でいきたい

特徴

軽量・高速寄りの構成にしやすい
ただしForge専用MODは使えないので、欲しいMODがFabric対応か要確認

Mohist（必要に応じて）の位置づけ

Mohist系は「MOD（Forge系）＋プラグイン（Spigot系）を混在させたい」ときの選択肢です。

ただし初心者が最初から選ぶと、つまずきポイントが増えます。

互換性が絡む（“動くはず”が動かないが起きやすい）
トラブル時の情報が少なめになりがち
導入・更新・切り分けが難しくなる

✅おすすめの順番
1）まずは Paper（プラグイン） か Forge/Fabric（MOD） のどちらかに寄せる
2）どうしても混在が必要になったら Mohist を検討

MOD追加の手順（アップロード場所・再起動・動作確認）

ここからは「実際の手順」です。最短で成功させるコツは 1個ずつです。

手順0：必ずバックアップ（最速の保険）

管理パネルのバックアップ機能で 今の状態を保存
可能ならPCにもダウンロード
「戻れる状態」を作るだけで、作業の精神的負担が激減します。

手順1：サーバーを止める

MOD/プラグインは、基本的に 停止した状態で入れるのが安全です。
（稼働中に入れると、ファイル破損や読み込みミスの原因になります）

手順2：正しいフォルダに入れる

「入れたのに反映されない」は、フォルダ違いが多いです。

プラグイン：plugins/ フォルダ
MOD：mods/ フォルダ
設定：config/ フォルダ（MODによって自動生成されることも多い）

アップロード方法は2通りです。

ファイルタブでアップロード（小さめ向け）
SFTPで転送（大きめ・大量向け）
→ MODパックや多数ファイルならSFTPが安定です

手順3：起動してログを見る（ここが一番大事）

起動したら、まずコンソールで次を確認します。

MOD/プラグインが読み込まれたか（“Loaded”系の表示）
エラーが出ていないか（赤文字、例外、依存不足）

手順4：動作確認は“最低限”でOK

長時間遊ぶ前に、まずは短く確認します。

ワールドに入れるか
追加要素が表示されるか（MODアイテム・コマンド等）
重大なラグが出ないか

✅コツ
動作確認が済んだら、次の導入に進む。
「1つ追加→起動→ログ確認」を繰り返すのが最短です。

落ちたときの切り分け（ログ→最近入れたMOD→依存）

「起動しない」「起動してもすぐ落ちる」時は、手順を固定すると早いです。

1）まずログの最後を見る（原因は末尾に出やすい）

コンソールの最後の方に、だいたい原因があります。

Missing / Required / Dependency
→ 依存関係の不足
Unsupported / Wrong version
→ バージョン不一致
Duplicate / Conflict
→ 競合（同じ役割の重複など）
OutOfMemory
→ メモリ不足（RAM増強や構成見直し）

2）直前に入れたものを外す（最短の切り分け）

原因が分からなければ、まずこれです。

直前に入れたMOD/プラグインを一旦外す
起動してみる
起動したら「それが原因」か「それが引き金」だった可能性が高い

✅コツ
フォルダから削除が怖ければ、いったん別フォルダに退避してから起動すると安全です。

3）依存を足す／対応版に揃える

原因が「依存不足」「版ズレ」なら、やることは単純です。

必須ライブラリを追加する
Minecraft / サーバーソフト / MODのバージョンを揃える
（クライアント側も同じ版に合わせる）

4）それでも無理なら“構成を軽くする”

大きく詰まったときは、次が効きます。

MOD数を減らして最小構成で起動
その上で1つずつ戻す
RAMを増やす（MODパックは特に効く）

安定運用のコツ：ラグ/クラッシュ/重さを減らす

「軽い時は快適なのに、建築が進むと急に重い…」はマイクラあるあるです。
AGAMESで安定させるコツは、“重くなる原因を先に潰す” → “日次の型を作る” → “標準プランの制約を前提にする”の順で整えることです。

重くなる原因TOP：視界距離・チャンク・エンティティ・自動化

体感の“重さ”は、だいたい次の4つが原因です。
上から順に効きやすいので、まずはここから触るのが最短ルートです。

1) 視界距離とシミュレーション距離が高すぎる

視界距離（view-distance）やシミュレーション距離が高いほど、サーバーが処理する範囲が増えます。

まずやること
- 視界距離・シミュレーション距離を欲張らない設定にする
効果が出やすい場面
- 人数が増えた／探索が増えた／移動が多い

2) チャンクが“広く・同時に”読み込まれている

複数人が別方向へ探索すると、未生成チャンクの生成が同時多発して負荷が跳ね上がります。

まずやること
- 探索は「時間を決める」「同時に散らばりすぎない」
- 大規模探索の前にバックアップを取る（生成で不具合が起きた時に戻れる）
ワンポイント
- “未探索を掘るほど重い”のは正常なので、探索の仕方で負荷を抑えるのが近道です。

3) エンティティ（動くもの・溜まるもの）が多すぎる

エンティティ過多は、体感のラグ原因として最頻出です。

重くしやすい代表例

落ちているアイテム（回収されないドロップ）
村人（大量の取引所・繁殖）
牧場（動物の増やしすぎ）
ホッパー、トロッコ、ボート、額縁、防具立てなど

すぐ効く対策（簡単な順）

まずは散らかったアイテムを減らす
村人や動物は“上限”を決めて運用する
仕分け装置・搬送系は「常時稼働」から「必要時稼働」へ

4) 自動化（レッドストーン・装置）が“常時動いている”

自動化そのものが悪いわけではなく、常に動き続ける仕組みが負荷を作ります。

まずやること
- 常時稼働をやめて、スイッチ式・タイマー式にする
- トラップは「稼働時間を決める」（人がいる時だけ回す）

症状から逆引き：何を直すべき？

「何が原因か分からない」人向けに、よくある症状を整理します。

スクロールできます

症状	ありがちな原因	まずやる対策	次にやる対策
ブロック破壊や扉が遅い／ワープする	TPS低下（CPU負荷）	視界距離↓、装置の常時稼働↓	上位プラン/コア増強を検討
移動でカクつく／探索で急に重い	チャンク生成	探索の同時分散を減らす	生成が落ち着くまで運用調整
落ちる／エラーで起動しない	メモリ不足・MOD競合	最近入れたMODを外す	メモリ増強、構成見直し
バックアップ失敗／容量警告	ストレージ不足	世代数を減らす	ストレージ増量＋PC保管

日次運用テンプレ：再起動・バックアップ・更新の順番

安定運用は“その場の対処”より、ルーチン化が効きます。
以下は、初心者でも事故が減りやすい「型」です（コピペして自分の時間に置き換えてOK）。

毎日の型（最小セット）

告知（例：5分前に say）
ワールド保存（save-all）
バックアップ作成（パネルのバックアップ機能）
再起動（できるプランの場合）
ログ確認（エラーが増えていないか）

ポイント

バックアップは“作るだけ”で終わらせない
週1回でもいいので、重要な世代はPCにもダウンロードして二重化すると安心です。
再起動は万能ではないですが、軽いラグの蓄積には効果が出やすいです。

更新の型（MOD/プラグイン更新で事故らない順）

更新は毎日やる必要はありません。やるときだけ、この順番にすると失敗しにくいです。

バックアップ（必須）
更新対象を1つだけ更新（まとめて更新しない）
起動 → コンソールログ確認
短時間の動作確認（入れるか、主要機能が動くか）
問題なければ次を更新

コツ

「更新前に戻れる状態」を作るだけで、トラブル対応が一気に楽になります。

標準プランの制約前提で運用を組む（停止対策の考え方）

標準プランはコスパが魅力ですが、“止まる前提”で設計しないとストレスが出やすいです。
ここでは、標準プランに合わせた現実的な運用の組み方をまとめます。

標準は「毎朝4時に停止」＋「自動起動できない」前提で考える

標準サーバーは毎朝4時にシャットダウンされ、さらにAPIやcron等で自動起動させることはできない旨が案内されています。
つまり、常時稼働のサーバー運用には不向きです。

現実的な対策は3つ

対策A：停止前に“守る”運用にする（標準で一番おすすめ）
- 3:55 告知（say）
- 3:58 保存（save-all）
- 3:59 バックアップ作成
- 4:00 自動停止（仕様）
- 翌日：遊ぶ前に手動で起動
対策B：夜間常駐を諦めて、遊ぶ時間を決める
- 「今日は21〜24時」など、稼働時間を決めるだけでも安定します
対策C：常時稼働が必要ならMAX/プレミアムへ寄せる
- “いつでも入れるワールド”が目的なら、最初から上位プランの方が結果的に楽です

スケジュールの使い方も「できること」に寄せる

スケジュール機能は便利ですが、標準マイクラではパワーコマンド（起動/再起動/停止/強制終了）が使えない旨が案内されています。
そのため標準では、スケジュールをこう使うのが現実的です。

できることに寄せる（例）
- 告知（say）
- 保存（save-all）
- バックアップ作成（“止まる前の保険”として活用）

安心して使うための確認ポイント

「安く始められる」ことと同じくらい大事なのが、安心して長く運用できる状態を最初に作ることです。
ここでは、AGAMESでマイクラサーバーを運用するうえで、初心者が最低限チェックしておくと失敗しにくいポイントをまとめます。

運営情報の確認：特商法表記・規約・プライバシー

最初にやるべきは「万一のときに困らない状態」を作ることです。具体的には、次の3ページは一度目を通しておくと安心です。

特商法表記で見ておくと良い項目

運営主体（会社名）と問い合わせ先
提供時期（支払い後にいつ届くのか）
サポート対応時間
支払い・更新の考え方（更新日、支払い期限、途中解約の扱い）
キャンセル・返金の扱い

💡ポイント
「料金が安いか」だけでなく、更新や解約のルール、サポート時間を把握しておくと後悔が減ります。

利用規約で押さえるべき観点

禁止行為（迷惑行為、過負荷、規約違反コンテンツ等の扱い）
免責・補償の範囲（障害時にどこまで保証されるか）
価格改定・規約変更の扱い（通知方法や適用タイミング）

プライバシーポリシーで押さえるべき観点

収集する情報の種類（アカウント情報など）
利用目的（何のために使うのか）
第三者提供・委託の有無
開示・訂正・削除などの手続き

✅結論としては、ここを確認しておくと
「想定外の課金」「解約の行き違い」「問い合わせ先が分からない」をかなり防げます。

サポートの使い分け：Discord/チケット/メール

困ったときに早く解決するコツは、状況に合った窓口を選ぶことです。AGAMES側は連絡手段ごとの目安も案内しています。

スクロールできます

連絡手段	向いている内容	使い方のコツ
Discord	すぐに止めたい／急ぎの相談／軽い質問	まずは要点だけ短く、必要ならログや画像を追加
チケット	記録を残したい／やり取りが長くなりそう／不具合報告	時系列で整理して書く（いつ・何をした・どうなった）
メール	アカウント・請求などの事務連絡／Discordが使えない	返信まで余裕を見て、証跡（請求番号など）を添える

返信を早める「問い合わせテンプレ」

最短で解決したいなら、最初の1通にこれを入れるのが効果的です。

何のサーバーか（Minecraft／Javaか統合版か）
いまの構成（バニラ / Paper / Forge など、分かる範囲で）
いつから起きたか（日時）
何をした直後か（MOD追加、設定変更、バージョン切替など）
症状（起動しない／入れない／重い／クラッシュなど）
コンソールのエラー（最後の数十行だけでOK）
可能ならスクショ1枚

👍この形にしておくと、追加質問の往復が減って結果的に早いです。

権限管理：OP・ホワイトリスト・共同管理の基本

サーバー運用で事故が多いのは、実はラグより権限まわりです。
「荒らし」だけでなく、身内でも操作ミスは起きるので、最初にルールを決めておくのがおすすめです。

OP（管理権限）は最小人数にする

OPは強力で、ワールド破壊や設定変更も可能です
OPは“必要な人だけ”に絞るのが基本
運用担当を複数にするなら、役割分担して「触っていい範囲」を決める

ホワイトリストは「身内サーバー」なら基本ONが安心

知り合いだけで遊ぶなら、ホワイトリストONが安全です
参加者を追加する運用にしておくと、招待管理が楽になります

共同管理は「パスワード共有」より「権限分離」

共同運営での事故を減らす定番はこれです。

管理パネルのログイン情報を共有しない
サブユーザー機能があるなら活用して、権限を分ける
強いパスワード、使い回しを避ける（基本だけど効きます）

💡初心者向けの運用例

「主管理者」：全権限（1人だけ）
「運用担当」：再起動・バックアップ・ログ確認まで
「一般」：ゲーム内権限のみ（OPなし）

ワールド保全：バックアップ＋ローカル保管のすすめ

一番後悔しやすいのが「ワールドが消えた／戻せない」です。
マイクラは資産（建築・思い出）が大きいので、バックアップだけは最初に仕組み化しましょう。

まず押さえる前提

サービス側が自動でバックアップを取ってくれるとは限りません
→ 自分でバックアップを取る運用が安全です

初心者でも失敗しにくいバックアップ設計

おすすめは「サーバー内 + 手元」二段構えです。

サーバー内：管理パネルのバックアップ機能で定期取得
手元（PC）：SFTPなどで定期的にダウンロードして保管

世代管理のルール（増やしすぎない）

バックアップは「多ければ安心」になりがちですが、保存枠や容量を圧迫します。

例：日次は7世代、週次は4世代、月次は3世代…のように上限を決める
大きい更新（MOD追加・バージョン切替）の前後だけは“手動で1本”取る

事故を防ぐワンポイント

重要作業の前にバックアップ（必須）
取っただけで満足せず、たまに復元手順を確認しておく（いざというとき焦らない）
PC保管は、できれば別ドライブやクラウドにも置くとさらに安心（やりすぎない範囲で）

よくあるトラブル：症状→原因→解決策

トラブル対応は、「事実確認 → 切り分け → 最小変更で復旧」の順がいちばん早いです。
まずは下の表で当たりを付けて、各項目の手順に沿って潰していきましょう。

スクロールできます

症状	よくある原因	まずやること（最短）
参加できない	アドレス/ポート違い、サーバー停止中、バージョン不一致、ホワイトリスト	接続先を再確認 → サーバー稼働確認 → ルール系（ホワイトリスト）確認
起動しない・落ちる	メモリ不足、MOD/プラグイン競合、設定ファイル破損、バージョン不整合	ログ確認 → 最近の変更を戻す → 最小構成で起動
ラグい	視界距離・チャンク、エンティティ増、メモリ不足、自動化装置	使用率（CPU/メモリ）を見る → 設定で軽量化 → 規模に合わせて見直し
データが消えた気がする	表示上の勘違い、ワールド指定ミス、復元上書き、再インストール	バックアップ有無確認 → 復元手順確認 → “上書き”に注意
支払いが反映されない	反映待ち、請求状態確認不足、決済手段の違い	請求書ステータス確認 → 指定時間待つ → まだなら問い合わせ

参加できない（アドレス/ポート/バージョン違い）

よくある原因

アドレスの入力ミス（コピペ時の空白・全角混入も多い）
ポート番号の付け忘れ（Javaは「IP:PORT」が基本）
サーバーが停止中（停止中だと当然入れません）
クライアントとサーバーのバージョン不一致
ホワイトリストが有効で、参加者が追加されていない

解決手順（チェックリスト）

接続先を“正しい形式”で入れ直す
- Java版は基本的に IP:PORT が必要です。
- サブドメインを設定している場合、Java版は ポートなしで入れることがあります（※エディション変更前に削除など注意点あり）。
サーバーが稼働しているか確認
- 管理パネルのコンソール/ステータスで「起動中」になっているか見ます。
- 停止中なら起動してから再接続。
ホワイトリストを疑う（とくに身内サーバー）
- サーバー側でホワイトリストが有効なら、追加した人しか入れません。
- 参加させたい人を whitelist add ユーザー名 で追加し、必要なら再起動。
バージョンを合わせる
- サーバー側のバージョン（例：1.20.1）と、参加する側のバージョンを一致させます。
- MODサーバーは、MOD側もバージョン整合が必要です。

✅ ここまでで多くの「入れない」は解決します。まだダメなら、次はコンソールログに出ているエラー文を手がかりにします。

起動しない・落ちる（メモリ不足/MOD競合/設定ミス）

よくある原因TOP3

メモリ不足：起動直後に落ちる／一定時間で落ちる
MOD/プラグイン競合：追加した直後から落ちる
バージョン不整合：サーバー本体・MOD・プラグインの組み合わせが噛み合っていない

解決手順（最短ルート）

ログを見て“最後のエラー行”を拾う 🔍
- コンソールのログに、クラッシュ理由がほぼ出ます。
- 「直前に何を変えたか」をセットで考えると早いです（例：MOD追加、設定編集、バージョン変更）。
最近入れたものをいったん戻す（最小構成で起動）
- MODを入れた直後なら、まずは そのMODだけ外す → 起動確認。
- プラグインも同様に、追加順に戻すと当たりが付けやすいです。
MOD導入の基本を再チェック
- サーバーのMinecraftバージョンと、MODの対応バージョンが一致しているか
- 依存MODが足りない／競合していないか
- Forge/Mohistなど、入れ方が前提と合っているか
“再インストール”は最後の手段にする ⚠️
- 再インストールやファイル削除が絡む操作は、状況によって「全部消えた」に見えがちです。
- 実行前に必ず バックアップのダウンロードを挟みましょう。

ラグい（負荷の見える化→設定→スペック見直し）

ラグ対策は、体感でいじるより 数字で判断すると失敗しません。

まず見る場所（負荷の見える化）

コンソール画面で CPU使用量 / メモリ使用量 / ストレージを確認
“重い瞬間”に張り付く（CPUが常時高い？メモリが限界？）

よくある原因と対策

視界距離・シミュレーション距離が高すぎる
→ 少し下げるだけで効果が大きいです。
エンティティ増（動物・村人・アイテム散乱）
→ 置きすぎ/湧きすぎを制限、回収導線を作る。
自動化装置・大量ホッパー
→ まとめる、常時稼働を減らす、必要な時だけ動かす。
プラグイン運用なのに最適化されていない
→ Paper系の最適化設定を見直す（闇雲に弄らず、段階的に）。

“運用”で効く対策（初心者でもやりやすい）

✅ 定期再起動（毎日/数日に1回でも差が出る）
✅ 定期バックアップ
✅ 更新（MOD/プラグイン）前にバックアップ → 更新 → 動作確認

データが消えた気がする（復元/再インストール注意）

まず落ち着いて確認すること

ワールドが“消えた”のではなく、別ワールドを見ている（ワールド名やディレクトリ違い）
サーバー種類/バージョン変更で、読み込みに失敗している
そもそもバックアップが存在するか（世代数の上限で古いものが消えていないか）

バックアップ復元での注意点（超重要）

復元は基本的に 現在のファイルに上書きされます。
→ 「戻すつもりが、上書きで状況を悪化」しやすいので、復元前に現状を別で退避できると安全です。
バックアップは ローカルへ定期ダウンロードが安心です 🧰
バックアップは取りすぎても不利なケースがあります（古い世代が消えやすくなるため）。

“再インストールで消えた”パターン

特定の作業手順で、全ファイル削除 → 再インストールの流れが出てくることがあります。
→ その前にバックアップを取っていないと、復旧が難しくなります。

支払いが反映されない（決済手段別の確認先）

まずは「どの支払い方法か」で、待つべき時間が変わります。

1) 請求書ステータスを確認する

まずは管理画面で、請求書が 支払い待ちのままになっていないかチェックします。

2) 支払い方法別の“目安”

クレジットカード / 銀行振込 / コンビニ / Amazon Pay
→ 手続き後、基本はすぐ反映する想定。5分経っても変わらないなら問い合わせの対象になりやすいです。
コンビニ決済
→ 支払い後に自動反映。1時間経っても反映しないなら連絡。
STORES経由のクレジット購入
→ 連携の都合で 即時ではないことがあります。目安は数時間〜最大3日。

3) 最後はサポートへ（最短で解決する出し方）

問い合わせるなら、次をセットで送ると一往復減ります ✅

注文ID / 請求書番号
支払い方法（カード/コンビニ/STORESなど）
支払い時刻（だいたいでOK）
反映されない画面の状況（ステータス名）

解約・プラン変更・移行（長期運用の出口設計）

長く遊ぶほど、サーバー運用は「始め方」よりも終わらせ方（出口）が大事になります。
AGAMESはプランや構成を柔軟に変えられる一方で、解約のタイミング次第ではデータが短時間で削除されるため、先に“持ち出し手順”を固めておくと安心です。

解約前チェック：ワールド/設定/プラグインの持ち出し

解約時に慌てないために、まずは「残すべきもの」を分解して考えます。

持ち出すべきもの一覧（最低限）

ワールドデータ（最重要）
サーバー設定（例：server.properties、各種設定ファイル）
権限・参加者設定（OP、ホワイトリスト）
プラグイン/ MOD一式（jar本体・設定・依存）
運用メモ（バージョン、導入物一覧、起動条件）

解約前のおすすめ手順（安全優先）

結論：先にバックアップ→ローカル保管→解約の順が鉄則です。
（解約と同時にバックアップも削除される可能性があるため）

サーバー停止（またはプレイヤー退出を促す）
バックアップ作成（管理パネルのバックアップ機能）
バックアップをPCへダウンロード（SFTP等でもOK）
必要ファイルの“追加持ち出し”
- MOD/プラグイン構成なら、mods/ plugins/ config/ 等も退避
解約申請（クライアントエリアから）
解約タイミングは基本 「契約期間終了時」 を選ぶ
- 「即時」は数分で削除され、取り消しできない前提で考える

“契約期間終了時”を選ぶべき理由

すぐ消えないので、ダウンロード漏れがあっても立て直しやすい
更新請求が出ていても、解約の予約自体はできる（結果的に更新を避けやすい）

解約でやりがちな失敗 3つ（先に回避）

失敗1：バックアップが“サーバー内にしかない”
→ 解約・削除と一緒に消える前提で、必ずPCにも保管する
失敗2：即時解約を選んでしまう
→ “消えるのが早い”プランほど事故が増えます。迷ったら契約期間終了時。
失敗3：MOD/プラグインの設定を持ち出していない
→ jarだけ持っていっても同じ挙動になりません。config/ や各設定もセットで。

人数が増えたらどこから上位プランを検討する？

プランアップの判断は「人数◯人になったら」よりも、運用上の“困りごと”が出たらが正解です。
次のどれかに当てはまったら、上位プラン（または構成増強）を検討する合図です。

1) “常時稼働したい”が目的になった

夜中や早朝も自由に入りたい
学校/仕事終わりに毎回起動するのが面倒
参加者が増えて「誰かが起動係」だと回らない

👉 このタイプは、標準の制約（停止・自動起動の不可など）がネックになりやすいので、早めの見直しが効きます。

2) ラグが“運用で吸収できない”レベルになった

次がセットで起きるなら、スペックかプランの限界が近いサインです。

視界距離を下げてもまだ重い
エンティティ・装置を整理してもTPSが戻らない
ログ上のエラーやタイムアウトが増える
再起動で一時的に良くなっても、すぐ悪化する

👉 対応の順番はおすすめとして
設定見直し → メモリ/コア増強 → 上位プラン（必要なら）
が失敗しにくいです。

3) MOD・大規模建築・自動化が“当たり前”になった

MODの追加が増えて、必要メモリが右肩上がり
ワールド容量が増え、バックアップが重くなる
参加者が拠点を分散し、チャンク負荷が増える

👉 このケースは、メモリ増強＋ストレージ増量が効きやすい一方、
根本的に「余力が足りない」なら上位プランが早いです。

4) 具体的な“相談基準”（迷った時の目安）

CPU/メモリ使用率が高止まりしている（ピークではなく“常時”）
クラッシュやフリーズが増えた
バックアップや更新作業が怖くなってきた（復旧に自信がない）

このあたりが出たら、チケットやDiscordで「現状（人数・構成・症状）」を添えて相談すると早いです。
AGAMESは、コア数・メモリ・ストレージの変更ができる範囲と、スタッフ対応が必要な範囲が分かれているため、最短ルートの案内をもらいやすいです。

他環境へ移すときの基本（同じ版/同じMOD/同じ設定）

移行は“ワールドを移すだけ”では再現できないことが多いです。
基本は 「同じ版・同じ導入物・同じ設定」 を揃えること。これで9割の事故が減ります。

移行の全体像（最短で成功する流れ）

移行先を決める（AGAMES内の別プラン / VPS / 他社等）
現サーバーの情報をメモ
- エディション（Java/統合版）
- サーバー種別（Vanilla/Paper/Forge/Fabric/Mohist 等）
- マイクラのバージョン
- MOD/プラグイン一覧（依存含む）
サーバー停止 → バックアップ作成 → PCへダウンロード
移行先で 同じ条件でサーバーを用意
ワールド・設定・導入物をアップロード
起動→ログ確認→短時間テスト（参加できるか/主要要素が動くか）

“バージョン違い”が一番危険（とくにダウングレード）

移行先でマイクラのバージョンを下げると、ワールドが読めずエラーになることがあります。
基本方針はこう考えると安全です。

同じバージョンが最優先
変えるなら 上げる方向が原則（ただしMODは対応確認が必要）
下げるのは基本NG（別ワールド生成が必要になるケースがある）

移行時に忘れがちな“再現セット”

ワールドだけ移して「何か違う」を防ぐために、これもセットで移します。

server.properties（難易度、スポーン、PVPなど）
whitelist.json / ops.json（権限・参加制御）
plugins/（プラグイン本体＋各プラグインの設定）
mods/ と config/（MOD本体＋設定＋依存）
起動条件（Javaバージョン、起動パラメータ等）

移行前の“最小確認”チェック（これだけはやる）

✅ バックアップが PCに保存されている
✅ 移行先で 同じ版・同じ導入物を揃えた
✅ 初回起動は、いきなり本番参加させず テストログインする
✅ エラーが出たら、まずは ログ末尾と「直前に入れた物」を疑う

FAQ：「AGAME マイクラ」で検索されがちな質問まとめ

何人まで遊べる？目安は？

結論、「上限◯人」と決まっているというより、遊び方（バニラ/プラグイン/MOD）と割り当てるリソース次第です。まずは公式の“人数目安”をベースに考えるのが安全です。

スクロールできます

ざっくりの目安	想定	最初に見るべきポイント
統合版：少人数	軽め・カジュアル	1〜2GBでも始めやすい（ただし重くなれば増強）
Java版：1〜5人	バニラ〜軽めプラグイン	4GBあたりからが現実的
Java版：5〜20人	生活鯖＋プラグイン運用	8GB以上が目安
Java版：20人以上	参加者が増える/負荷が高い	16GB以上＋設定最適化が効く
50人〜/100人規模	大規模運用	サーバー分割やプロキシ、設計・運用が重要

ただし、同じ人数でも体感が変わります。特に効くのはこの4つです。

視界距離/シミュレーション距離（上げすぎると急に重くなる）
エンティティ量（村人・動物・トロッコ・ホッパーの増えすぎ）
自動化装置の密度（常時稼働の装置が多いほど負荷が積み上がる）
導入MOD/プラグインの質と相性（同系統の機能が重複すると不安定に）

✅ 迷ったら：最初は「少し余裕あるメモリ」→重ければ増強、が失敗しにくいです。

常時稼働にしたい場合はどうする？

標準プランは“常時稼働前提”で選ぶとハマりやすいです。理由はシンプルで、

毎朝4時に自動シャットダウンされる
APIやcron等で自動起動できない（＝放置で24時間稼働にしづらい）
という制約があるからです。

常時稼働したいなら、基本は次のどちらかです。

MAX/プレミアムで運用する
- 長期運用・いつでも入れる状態にしたい人向け
標準は“遊ぶ時間が決まっている人”向けに割り切る
- 「夜だけ起動して遊ぶ」「週末だけ使う」など
- 4時前に手動で切り上げる運用に寄せるとストレスが減ります

💡「標準で毎日停止する前提」の場合は、バックアップだけは習慣化がおすすめです（万一に備えてローカル保管も）。

Javaと統合版、どっちもいける？

考え方はこうです。

Java版：MOD/プラグインの自由度が高い（サーバー文化の主流）
統合版（Bedrock）：Switch/PS/Xbox/スマホ等で参加しやすい（軽めに遊びやすい）

そしてAGAMESは、主要なサーバーソフト（Paper/Forge/Fabric/Velocity等）に幅広く対応していて、用途に合わせて選びやすいのが特徴です。

さらに、「Javaと統合版を同じワールドで遊びたい」なら、Geyserのような仕組みでクロスプレイ構成にする手もあります。

Javaサーバー側にプラグインを入れて、統合版の参加を可能にするイメージ
設定次第で「Javaと統合版が同じポートで参加できる」形も作れます

✅ 迷ったら：

PC中心・自由度重視 → Java
Switch/スマホ混在・気軽さ重視 → 統合版
混在メンバーで一緒に遊びたい → クロスプレイ構成を検討

プロキシーはどんな時に必要？

プロキシ（BungeeCord/Velocityなど）は、ひとことで言うと 「入口（ロビー）と複数サーバーをつなぐ中継役」です。必要になるのは主に次のケース。

サーバーを分割したい
- 例：ロビー／生活ワールド／ミニゲームを行き来させたい
人が増えてきて、1台に全部載せるのがきつい
- サーバーを複数台に分けて負荷を分散しやすい
公開サーバー運用を見据えて、構成を整えたい
- 運用・拡張の自由度が上がることが多い

逆に、友だち数人で1ワールドなら、いきなりプロキシは不要なことが多いです。
✅ 目安：「参加者が増える」「用途が増える」「公開する」が見えたら検討、でOKです。

公式の問い合わせ先はどこ？

困ったら、まずは公式のマニュアル（AGAMESサポート）を確認 → 解決しなければ問い合わせ、が最短です。

問い合わせの基本動線はこの3つです。

Discord（早めの返信が期待しやすい）
クライアントエリアのチケット（内容を整理して伝えやすい）
メール（急ぎでない/記録を残したいとき）

📌 伝えるときは、これをセットにすると往復が減ります。

契約プラン（標準/MAX/プレミアム等）
エディション（Java/統合版/クロスプレイ構成）
サーバーソフト（Paper/Forge/Fabric 等）
発生時刻、症状、ログの該当部分（可能な範囲で）

一次情報（執筆の根拠を明示）

この記事は、AGAMESの公式ページ／公式ドキュメント／公式の規約類を軸に内容を整理しています。
「料金や仕様は変わることがある」ため、最終確認は以下の一次情報で行うのが安心です。

公式：マイクラ向け案内ページ

AGAMESのマイクラサーバーの全体像（できること・特徴・よくある質問）を確認するためのページです。

サービスの特徴（自動構築、サポート、DDoS緩和など）
基本的な考え方（1契約=1サーバー等）
途中アップグレードやクロスプレイの可否など、判断材料になりやすいFAQ

公式：プラン比較

「標準／MAX／プレミアム」や「プロキシ」の違いを把握するためのページです。
初心者が迷うポイント（常時稼働向きか、何が制限されるか等）を整理する際に参照します。

各プランの位置づけ
最低金額の目安や選択項目（CPU・メモリ・容量など）
プロキシ（BungeeCord/Velocity）系の扱い

公式：価格表（ドキュメント）

料金を“数字で確認”するための一次情報です。
価格表の更新日や、価格表示の優先ルール（カート表示が優先など）もここで確認できます。

契約形態（毎月／半年一括／年一括）
標準／MAX／プレミアム別の料金体系（CPU/メモリ/ストレージ等）
価格が変動しうる前提と、最終確認の考え方

公式：特商法表記・利用規約・プライバシーポリシー

「安心して使えるか」を判断する一次情報です。
とくに、自動更新／支払い期限／解約の扱い／サポート時間／個人情報の取り扱いは、ここで必ず確認します。

事業者情報・連絡先
提供時期、支払い条件、返品/返金の扱い
解約・更新ルール（自動更新など）
個人情報の取得・利用目的・管理

公式：サポートマニュアル（問い合わせ方法）

困ったときに「どこへ」「どうやって」連絡すべきかを確認する一次情報です。
問い合わせ手段の使い分け（Discord／チケット／メール）や返信目安もまとまっています。

まず読むべきマニュアルの入口
連絡手段ごとのおすすめ用途と目安時間
解決までの導線（手順や設定例へのリンク）

まとめ

AGAMESでマイクラサーバーを快適に運用するコツは、難しいテクニックよりも “最初の設計” と “日々の型” にあります。

料金は“最低金額”だけで決めない
CPU・メモリ・容量、そして運用（バックアップや更新）まで含めて見積もると失敗しにくいです。
プランは目的で選ぶ
「とにかく安く短時間で遊びたい」のか、「常時稼働や長期運用をしたい」のかで最適解は変わります。
MOD/プラグインは“整合性”が9割
バージョン・依存関係・競合を確認し、導入は1つずつ。落ちたらログ→最近入れたもの→依存の順で切り分ければ復旧が早いです。
安定運用は“見える化→設定→運用→必要なら増強”
体感でいじるより、CPU/メモリ/ログを確認して原因を絞る方が確実です。
データ保全は最優先
バックアップは取得するだけでなく、重要な世代をローカルにも保管しておくと安心です。
困ったら公式マニュアルとサポートを使い分ける
Discord/チケット/メールを用途で使い分けると、解決までの時間が短くなります。

もし今あなたが「どのプランにすべきか迷っている」なら、まずはこの記事内の3分診断と、人数・遊び方別のおすすめ構成から確認してください。
そして、起動できたら次は バックアップと再起動の型 を作るだけで、運用の不安が一気に減ります。

AGAMESは、公式ドキュメントが整っており、サーバー種類や構成も選べるため、初心者でも“正しい手順”を踏めば十分に快適なマルチ環境が作れます。
この記事を手元に置きつつ、まずはあなたの目的に合った構成で一度立ち上げてみてください。最初の一歩さえ越えれば、あとは「少しずつ育てる」感覚で運用できます。