KAGOYA×マイクラ入門｜最適プランはどれ？人数別スペックと料金の目安

2026年2月11日

マイクラのマルチって、始めてみると楽しい反面──「どのスペックを選べば快適なの？」でつまずきがちです。
特にVPSは自由度が高いぶん、最初のプラン選びで迷いやすいですよね。

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

「KAGOYAでマイクラサーバーって本当に安定する？ラグらない？」
「人数が4人・8人・10人超だと、メモリは何GBが目安？」
「バニラなら軽い？ MODやプラグインを入れたら一気に重くなる？」
「料金は結局いくら？短期だと割高？長期だとお得？」
「Java版と統合版で、必要な準備や“つまずきポイント”が違うって本当？」
「テンプレートで始めるのと手動構築、どっちが安全で簡単？」

このページでは、そうした疑問をまとめて解消できるように、「人数 × 遊び方」から逆算して最適プランを決める考え方を、初心者向けに整理します。

まずは最小構成で失敗しない（＝ムダに高スペックを買わない）
重くなったら、原因を見て“必要な分だけ”強化する
料金は、KAGOYAの日額・月額上限の仕組みを踏まえて見積もる
さらに、テンプレートで最短起動する方法／運用の基本（バックアップ・権限・セキュリティ）まで押さえる

読み終える頃には、あなたの状況に合わせて
「最初はこのくらいでOK」「こうなったら増強」が判断できるはずです。
迷いを減らして、マイクラの時間を増やしましょう。

KAGOYA CLOUD VPS 公式サイト

この記事でわかること（最初に結論）

「KAGOYA　マイクラ」で検索する人が最初につまずきやすいのは、だいたいこの3点です。

そもそもKAGOYAでマイクラのマルチサーバーは作れるの？ → 作れます（テンプレートあり）
どの方法がラク？ → 最短で遊ぶならテンプレート／自由にいじるなら手動構築
Java版と統合版で何が違う？ → 用意するサーバーの種類・接続方法・調整ポイントが変わる

さらに、初心者が失敗しないための“超要点”だけ先に置いておきます👇

料金は「日額課金＋月額上限」なので、まず小さく始めて、重ければ増強がやりやすい
サーバー停止中も課金対象（“置きっぱなし”前提で考えるのが安全）
スペックは後から変更できる（ただしストレージを小さくする方向は不可）

参考として、公式の料金表（NVMeプラン）に載っている代表的なスペックは以下です。

スクロールできます

目安にしやすいプラン	CPU/メモリ	日額	月額上限
まず試す（かなり軽め）	1コア/1GB	20円	550円
迷ったらここ（少人数の起点にしやすい）	2コア/2GB	28円	770円
余裕を持たせたい	4コア/4GB	63円	1,760円
MOD等で重くなりやすい想定	6コア/8GB	122円	3,410円

※ここでは“選びやすい代表例”を抜粋しています。料金の仕組み（「日額×日数」と「月額上限」の安い方が月額になる等）も公式に明記されています。

KAGOYAでマイクラサーバーは建てられる？向いているケース

結論、KAGOYAのVPSでマイクラのマルチサーバーは運用できます。
しかも、Java版だけでなく統合版（Bedrock）にも対応したテンプレートが用意されているため、初心者でも着手しやすいのが強みです。

向いている人（✅が多いほど相性良い）

✅ 友だちと“いつでも入れる”ワールドを持ちたい（24時間稼働させたい）
✅ マップを長期で残したい／バックアップも自分で管理したい
✅ 設定をいじって遊び方を変えたい（難易度、ホワイトリスト、各種ルールなど）
✅ 人数や遊び方に合わせてスペックを上げ下げしたい（重くなったら強化したい）
✅ 「日額課金＋月額上限」で、まず試してから最適化したい

向いていない人（別手段がラク）

❌ 管理は一切したくない（アップデート・設定・バックアップ等も全部お任せがいい）
❌ 数回だけ遊べればOK（短期イベントのみ）
❌ 操作に慣れていない状態で、いきなり公開サーバー運用したい（荒らし対策が必須）

💡ポイント：VPSは「自由」と引き換えに、最低限の管理が必要です。
ただしKAGOYAはテンプレートがあるので、“いきなり全部を理解する必要はありません”。まず動かして、必要になった分だけ覚える進め方が現実的です。

最短で遊ぶなら「テンプレート」、自由度なら「手動構築」

ここが初心者にとって最大の分かれ道です。結論はシンプル👇

とにかく早く遊びたい → テンプレート
構成や改造まで含めて作り込みたい → 手動構築

テンプレート（最短ルート）でできること

メリット

🚀 “サーバーの土台”を自動で用意してくれるので、最初の手間が少ない
🧩 Java版／統合版それぞれのテンプレがあり、選び間違えにくい
🔧 後からスペック変更しやすく、重くなったら強化しやすい

注意点

「最小手順で起動」できる一方で、やり込み（特殊構成）をするなら、結局どこかで仕組み理解が必要

手動構築（自由度MAX）でできること

メリット

🛠️ サーバーソフトや設定を自分の方針で選べる（例：バージョン固定、細かいチューニング等）
📦 運用設計（バックアップ世代管理、監視、アクセス制限など）を自分好みにできる

注意点

初回はやることが増える（OS更新、必要ソフト導入、起動設定、通信設定…など）

初心者におすすめの“現実的な”選び方

迷ったら、これが失敗しにくいです。

テンプレートで始める（まず遊べる状態を作る）
重い・足りないが出てきたら
- スペック増強 or 設定の見直し
「もっと自由にやりたい」が明確になったら
- 手動構築へ移行（または別インスタンスで検証）

最初から完璧を狙うより、“動く→困る→改善する”の順が、結果的に最短です。

Java版／統合版（Bedrock）で手順が変わるポイント

同じ「マイクラ」でも、Java版と統合版（Bedrock）は“別物”に近い部分があります。
ここを取り違えると、「友だちが入れない」が起きがちなので、最初に整理しておきます。

1) 一緒に遊べる相手（端末）が変わる

Java版：主にPC（Java Edition）同士で遊ぶ前提
統合版（Bedrock）：Switch/スマホ/PS/Xbox/Windows版など、幅広い端末と遊びやすい

👉 友だちの環境がバラバラなら統合版寄り、
👉 PC中心で拡張して遊ぶならJava版寄り、が分かりやすいです。

2) “盛り上がる改造”の方向性が違う

Java版：MODやサーバー拡張（文化が大きい）
統合版：遊びやすさ重視。改造は方向性が違い、Javaほど同じノリで増やせないことも

「やりたい遊び」がどっちの世界観なのかで、選ぶ版が決まります。

3) 構築・接続の“つまずきポイント”が違う

初心者が詰まりやすい点は、ざっくり言うと👇

Java版で多い：バージョン違い／設定反映のための再起動／メモリ不足
統合版で多い：端末ごとの接続方法の違い／ネットワーク条件／参加手順の個別差

だからこそ、KAGOYAのように Java版・統合版それぞれのテンプレが用意されていると、最初の失敗が減ります。

KAGOYA CLOUD VPS 公式サイト

検索意図の整理：みんなが知りたいのはココ

「KAGOYA　マイクラ」で検索する人が本当に知りたいのは、だいたい次の3つに集約されます。
ここを先にクリアにすると、プラン選び→構築→運用まで迷いが減ります。

料金は結局いくら？（短期／長期）

KAGOYA（KAGOYA CLOUD VPS）は、ざっくり言うと 「日額課金」＋「月額上限」 の考え方です。
つまり、同じプランでも 短期利用と長期利用で“効いてくる数字”が変わります。

料金の超シンプルな考え方

1か月の請求は基本的に、次の“安い方”になります。

日額 × 課金対象日数
月額上限

なので、初心者はまずここだけ覚えればOKです👇

数日だけ試す → 日額が効く（安く済む）
1か月まるっと運用 → 月額上限で頭打ち（予算を読みやすい）

代表的な料金イメージ（NVMeプラン例）

迷いやすいので、マイクラ用途で“検討されがち”な帯だけまとめます。

スクロールできます

目安にしやすい帯	CPU/メモリ	日額	月額上限
お試し・超軽め	1コア/1GB	20円	550円
少人数の起点	2コア/2GB	28円	770円
中間（余裕が欲しい）	4コア/4GB	63円	1,760円
重めを見越す	6コア/8GB	122円	3,410円

例：2コア/2GBで週末（2日）だけ動かす
28円 × 2日 = 56円（上限770円より安いので、短期はこの感覚）

例：2コア/2GBを月まるごと運用
日額合計が上限を超える月は、770円で止まる（ざっくりこの理解でOK）

“料金の落とし穴”も先に回避

初心者が勘違いしやすい点だけ、短くまとめます。

停止していても課金対象（「止めたから無料」ではない前提で考える）
まず小さく始めて、重ければ上げるがやりやすい（上限があるので予算設計もしやすい）
「年額」などの選択肢もあるが、最初は 日額＋上限の運用感を掴んでからで十分

何人まで快適？ MODやプラグインは？

ここは正直、「人数」だけでは決まりません。
同じ5人でも、遊び方で負荷が全然違います。

建築メイン（移動少なめ・バニラ） → 軽い
探索多め（チャンク生成が多い） → 重い
自動化装置モリモリ（エンティティ増） → 重い
MOD大量・大型データパック → かなり重い

そこで本記事では、初心者が判断しやすいように 「人数×遊び方」 の目安で整理します。

目安（バニラ中心の現実ライン）

1コア/1GB：ソロ検証・超少人数の“お試し”向け
- 「動くか確認」には便利。ただし余裕は少なめ
2コア/2GB：2〜4人のバニラ寄り（軽め設定なら安定しやすい）
- 迷ったらまずここから始めやすい帯
4コア/4GB：5〜10人のバニラ〜軽い拡張（設定次第で安定しやすい）
- 探索や装置が増えるならこの辺が安心
6コア/8GB：10人超や“重くなりやすい遊び方”を見越す帯
- チャンク生成・装置・データパックなどが増えるなら検討価値が高い

※あくまで目安です。重くなる要因が多い場合は、人数が少なくても上位帯が必要になります。

MODやプラグインの扱い（初心者が混乱しやすい点）

テンプレートは「すぐ遊べる標準環境」向き
MOD（例：Forge/Fabric）や、プラグイン前提の構成（例：Paper系）を本格的にやるなら、基本は 手動で環境を整える発想 が必要になりやすい

最初からMOD盛り盛りを狙うより、初心者はこうすると失敗しにくいです👇

まずバニラ（または軽い拡張）で運用に慣れる
重くなったら
- 設定を軽くする（視距離など）
- それでもダメなら スペックを上げる
それからMOD／プラグインに進む

「快適」の基準を“体感”から“指標”に変える

マイクラ鯖運用は、慣れると判断が速くなります。初心者でも見やすい指標はこれです。

急にカクつく／チャットが遅れる → CPU負荷・処理落ちの可能性
メモリ不足で落ちる／起動しない → メモリ不足の可能性
探索時だけ重い → チャンク生成負荷の可能性

「原因がどれか」を切り分けられるだけで、無駄な増強が減ります。

立て方・入り方・トラブル対処を一気に知りたい

初心者が求めているのは、だいたいこれです👇

どれを選べばいい？
どうやって立てる？
友だちはどうやって入る？
つながらない時どうする？

ここでは、細かいコマンドを詰め込まず、全体像が一気にわかる“一本道”でまとめます。

全体の流れ（最短で迷わない順番）

エディションを決める
- 友だちがPC（Java）中心 → Java版寄り
- Switch/スマホ等が混ざる → 統合版（Bedrock）寄り
方法を決める
- 早く遊ぶ → テンプレート
- こだわる → 手動構築
VPSを作成する（OS/テンプレ/スペックを選ぶ）
接続情報を確認する（IPアドレス等）
必要な通信を許可する（セキュリティ設定で詰まりやすいポイント）
サーバーへ参加する（クライアント側でサーバー追加／接続）
最低限の運用設定（ホワイトリスト・権限・バックアップ）

この順番で進めると、「作ったのに入れない」をかなり減らせます。

友だちに渡す情報（これだけでOK）

サーバーアドレス（IP）
（必要な場合）ポート番号
（身内運用なら）ホワイトリスト登録の方針（誰を入れるか）

※不用意に公開SNSに出さないなど、最低限の管理は重要です。

よくあるトラブルの“即チェック”リスト

接続できない時は、まずここから潰すと早いです。

サーバー側が起動しているか（落ちていないか）
アドレス（IP）を間違えていないか
版が合っているか（Java/統合版、バージョン差）
通信が許可されているか（セキュリティ設定・FW）
スペック不足の兆候がないか（起動直後に落ちる、処理落ちが酷い等）

「何から見ればいいか」が分かれば、初心者でも落ち着いて対処できます。

KAGOYA CLOUD VPS 公式サイト

KAGOYAでマイクラを動かす基礎知識

マルチの形は3つ：自宅PC／公式サービス／VPS（それぞれの違い）

マイクラのマルチは、大きく分けて 「どこでサーバーを動かすか」 で選択肢が変わります。
初心者が迷わないよう、違いを“使い心地”で整理します。

スクロールできます

方式	こんな人に向く	強み	注意点
自宅PC（自分のPCでホスト）	たまに遊ぶ／身内だけ／まず試したい	無料で始めやすい、準備が少ない	PCを落とすと終わる／回線・PC負荷／公開運用に不向き
公式サービス（Realms等）	とにかく簡単に遊びたい	手間が少ない、運用がラク	できることに制限が出やすい（自由度・拡張性）
VPS（KAGOYAなど）	24時間稼働／自由に設定／長期運用	自由度が高い、必要に応じて強化しやすい	最低限の管理が必要（設定・安全対策・バックアップ）

「KAGOYAが刺さる」典型パターンはこれです👇

🕒 いつでも入れるワールドにしたい（サーバー常時稼働）
🔧 遊び方に合わせて 設定をいじりたい（難易度、ホワイトリスト等）
📦 ワールドを長期で維持して バックアップも自分で握りたい
💰 いきなり大きく課金するより、小さく始めて必要なら強化したい

逆に、「一切管理したくない」なら公式サービス寄りの方がストレスが少ないです。

Java版と統合版の違い（参加端末・互換性・遊び方）

結論から言うと、ここを間違えると 「友だちが入れない」 が起きます。
まずは “誰と、どの端末で遊ぶか” を起点に決めるのが安全です。

Java版：MOD/プラグイン文化が強い

ざっくり特徴

主に PC（Java Edition）中心で遊ぶ前提
改造・拡張の自由度が高い（MODやサーバー側の拡張文化が強い）
「こだわった遊び方」「サーバーを育てる」方向と相性がいい

初心者がつまずきやすい点

バージョン違いで入れない（サーバー側とクライアント側）
拡張を入れるほど、必要スペックや相性問題が出やすい

こんな人におすすめ

PC勢メインで、将来的にMODや拡張もやってみたい人
バニラでもいいが、いずれ「もっと便利にしたい」が来そうな人

統合版：フレンド参加が楽だが前提が違う

ざっくり特徴

Switch / スマホ / PS / Xbox / Windows版など、幅広い端末で遊びやすい
友だちの環境がバラバラでも、同じ統合版ならまとまりやすい
“みんなで気軽に”の方向と相性がいい

初心者がつまずきやすい点

端末ごとに接続の導線が微妙に違う（入力項目や手順）
通信まわりの条件（ネットワーク設定）でハマることがある

こんな人におすすめ

Switch勢・スマホ勢が混ざるグループで遊びたい人
とにかく参加ハードルを下げたい人

KAGOYAの「アプリケーションテンプレート」でできること

KAGOYAの強みのひとつが、「簡単アプリケーションセットアップ（アプリケーションテンプレート）」です。
ざっくり言うと、マイクラサーバーの“土台づくり”を短縮できます。

テンプレートで主にラクになること

✅ インスタンス作成時に Minecraft用テンプレを選ぶだけで、初期構築の手間が減る
✅ Java版／統合版それぞれに合わせた サーバー環境を用意してくれる
✅ 「まず動かす」までの距離が短いので、初心者でも挫折しにくい

一方で、テンプレートでも “運用で必要なこと” は残ります。ここが大事です。

テンプレートでも自分でやるべきこと（最低限）

🔐 ログインの安全対策（強いパスワード、可能なら鍵運用）
🧱 公開範囲の管理（身内ならホワイトリスト、権限の最小化）
💾 バックアップ（ワールドを守る仕組み）
🔄 アップデート方針（急に上げない／検証して上げるなど）

「テンプレ＝全部お任せ」ではなく、“最初の坂をなだらかにする装置”と思うと失敗しません。

Java版テンプレの特徴

向いているゴール

PC中心のグループで、まずは“動くマルチ”を作りたい
将来的に拡張も視野に入れたい（ただし拡張は段階的に）

使いどころ（初心者のおすすめ運用）

まずはテンプレで バニラ運用 → 重くなったら
- 設定を見直す（視距離など）
- それでも厳しければ スペックを上げる
MOD/プラグインは、慣れてから 別環境で検証すると事故りにくいです

覚えておくと詰まりにくいポイント

「クライアント（遊ぶ側）とサーバー側のバージョン」を揃える意識が重要
人数が増えるよりも、探索（チャンク生成）や装置増加で重くなりがち

統合版テンプレの特徴

向いているゴール

Switchやスマホを含む混在メンバーで遊びたい
参加ハードルを下げて、ワールドを長期運用したい

使いどころ（初心者のおすすめ運用）

テンプレで起動 → まずは 身内限定で安定確認
慣れてきたら
- 参加メンバー管理（ホワイトリスト等）
- バックアップの自動化
- 必要ならスペック調整

覚えておくと詰まりにくいポイント

統合版は端末が多様なので、接続手順の案内を 短い手順メモにして共有すると親切です
「誰がどの端末か」でトラブルが分岐するので、最初に把握しておくと解決が速いです

KAGOYA CLOUD VPS 公式サイト

料金とスペックの決め方（失敗しない判断軸）

先に前提だけ1つ。KAGOYAのVPSは「小さく始めて、必要になったら上げる」運用と相性がいいです。
なので最初から“最大”を選ぶより、失敗しにくい判断軸（人数×遊び方）→目安→増強の順で決めるのが安全です。

まずは人数×遊び方で決める（バニラ／軽めMOD／重めMOD）

マイクラ鯖の負荷は、人数よりも 「遊び方（＝世界をどれだけ動かすか）」 の影響が大きいです。
初心者向けに、まずは遊び方を3段階に分けて考えると迷いません。

遊び方の3段階（自分がどれに近いか）

バニラ（軽い）
建築中心、移動少なめ、装置少なめ、データパック最小
→ “安定”を作りやすい
軽めMOD／軽い拡張（中くらい）
少量のデータパック、軽量な拡張、探索多め、装置が増えてきた
→ メモリとCPUに余裕が欲しくなる
重めMOD／大規模拡張（重い）
MOD多数、重いデータパック、常時稼働の装置だらけ、同時接続も多め
→ まずメモリ、次にCPUがボトルネックになりやすい

ざっくりルール（覚えやすい版）

人数が増えるほど必要スペックは上がる
それ以上に、探索（新規チャンク生成）と装置（エンティティ増）で一気に重くなる
MODや大規模拡張は、同じ人数でも “1〜2段階上のプラン” を想定しておくと事故が減る

目安スペック早見（少人数→中人数→大人数）

「結局どれ？」となりやすいので、“最初の着地点”を早見表にしました。
（※あくまで目安。ワールドの状態・装置量・探索頻度で上下します）

スクロールできます

想定	人数の目安	遊び方	最初の目安（CPU/メモリ）	KAGOYA NVMeプラン例
まず動かす	1〜2人	バニラ寄り	1コア/1GB〜	1コア/1GB
身内で安定	2〜4人	バニラ中心	2コア/2GB〜	2コア/2GB
余裕を持つ	3〜6人	探索・装置が増える	3コア/3GB〜4コア/4GB	3コア/3GB / 4コア/4GB
ワイワイ運用	5〜10人	バニラ〜軽い拡張	4コア/4GB〜6コア/8GB	4コア/4GB / 6コア/8GB
しっかり大人数	11人以上	探索多め・装置多め	6コア/8GB以上	6コア/8GB〜
重め拡張前提	人数問わず	重めMOD／大規模拡張	8コア/16GB以上	8コア/16GB〜

ここから先は、人数帯ごとに「何を優先して安定させるか」を短く整理します。

少人数（例：～4人）で安定させる考え方

少人数で大事なのは、“最初から盛りすぎない”ことです。

まずは 2コア/2GB を起点にすると判断がラク
バニラ中心なら、設定を軽くするだけで体感がかなり変わることも多い
探索しながら新天地をどんどん広げるタイプなら、少人数でも負荷が跳ねる
- この場合は、3コア/3GB へ早めに上げる判断がしやすいです

目安の選び方（初心者向け）

「建築メイン」→ 2コア/2GBで様子見
「探索メイン」→ 3コア/3GBも候補
「軽い拡張を入れたい」→ 最初から3GB以上を検討

中人数（例：5～10人）でラグを避ける考え方

中人数帯は、ラグの原因が混ざりやすいので、メモリの余裕が効きます。

まずは 4コア/4GB を基準に考えると失敗しにくい
「探索が多い」「装置が増えやすい」なら 6コア/8GB まで見ておくと安心
人数が同じでも、次の行動で急に重くなりがちです
- 新規チャンク生成（遠出・ネザー移動）
- トラップや自動化装置の常時稼働
- モブやアイテムが溜まる拠点構造

目安の選び方（初心者向け）

「週末に集まる程度」→ 4コア/4GBでスタート
「ほぼ毎日誰かが入る」→ 6コア/8GBを視野に

大人数（例：11人以上）で先に見るべき項目

大人数になると、単純なスペックだけでなく “運用の型” が重要になります。
先に見るべきはこの3つです。

同時接続の最大値（常に11人なのか、ピークが11人なのか）
ワールドの伸び方（探索で広がるほど、保存・バックアップも重くなる）
運用ルール（装置・エンティティの制限、放置対策）

スペック面の目安

最低ラインとして 6コア/8GB以上 を起点に考える
重め拡張やピークが大きいなら 8コア/16GB以上 を検討

「後から増強できる」前提で、最初は小さく始める

初心者が一番やりがちなのは、最初から大きくして固定費を抱えることです。
KAGOYAはスペック変更ができる前提があるので、こう進めると合理的です。

おすすめの始め方（失敗しにくい順）

“自分の遊び方”の一段上を選ぶ（ギリギリを狙わない）
1〜2週間運用して、重いタイミングを観察
重い原因が「設定で軽くなる」のか「増強が必要」なのか切り分け
必要なら 1段階だけ上げる（上げすぎない）

補足：ストレージは「あとで増やす」方向なら考えやすい一方、小さく戻す方向はできない運用なので、バックアップ込みで少し余裕を見ておくと安心です。

スペック不足のサイン（TPS/メモリ不足/起動失敗）

「増強すべきか」を迷ったら、次の症状をチェックすると判断が速いです。

TPS系（処理落ちのサイン）

プレイヤーの動きがガクガクする／ブロック破壊の反映が遅れる
サーバーログに “Can’t keep up” 系の警告が出やすい
人が増えた瞬間、または探索時に急に重くなる

メモリ不足のサイン

しばらく遊ぶと突然落ちる（特に拡張が多いほど出やすい）
起動直後に停止・再起動を繰り返す
ログにメモリ不足を示すエラーが出ることがある

起動失敗のサイン（環境要因の可能性も）

バージョン違いで入れない（サーバー側とクライアント側）
Java版なのに統合版の接続を試している、など“版の取り違え”
設定変更後に再起動していない（反映されない）

判断のコツ

「探索時だけ重い」→ 設定見直し＋必要なら1段階増強
「常に重い」→ スペック増強の優先度が高い
「落ちる」→ まずメモリ不足を疑う（増強が効きやすい）

KAGOYA CLOUD VPS 公式サイト

始める前の準備チェックリスト

「KAGOYAでマイクラ鯖を立てる」と決めたら、先にここを固めておくと “作ったのに入れない／すぐ荒れる／後で詰む” を避けやすいです。
チェックリスト形式でまとめます。

必要なもの：アカウント／支払い／プレイ端末

KAGOYA側で用意するもの

KAGOYA CLOUD VPSのアカウント（登録自体は無料）
支払い手段
- クレジットカード（※デビッドカードは不可）
- 口座振替／自動払込（銀行・信用金庫・ゆうちょ等の口座引落）
管理用の端末（PC推奨）
- ブラウザでコントロールパネル操作
- SSHでサーバーへ接続（手動構築・調整するならほぼ必須）

💡小ネタ：VPSは“停止したら無料”ではありません。
「使わない期間の料金を完全に止めたい」なら 停止ではなく削除が必要になるので、消す前提の人はバックアップ方針も最初に決めておくと安心です。

マイクラ側で用意するもの

プレイヤー全員のマイクラ環境
- Java版で遊ぶなら：基本 PC（Java Edition）同士
- 統合版で遊ぶなら：Switch/スマホ/PS/Xbox/Windows版など（同じ“統合版”で揃える）
版の決定（超重要）
- 先に「Java版で立てるか」「統合版で立てるか」を確定
- ここが曖昧だと、後で“友だちが入れない問題”が起きがちです 😵‍💫

サーバー公開の方針（身内限定・一般公開）を先に決める

ここは技術より先に「方針」です。
身内限定と一般公開では、必要な対策と手間が別物になります。

身内限定：ラク。最初は基本これがおすすめ
一般公開：手間が増える。初心者は“公開専用の別環境”を作るくらいの覚悟が必要

身内限定なら：ホワイトリスト＋権限最小

身内サーバーは、次の3点で事故が激減します。

ホワイトリストを有効化（許可した人だけ入れる）
op（管理権限）を最小限にする
- opは便利ですが、付与範囲が広いほど「誤操作」も増えます
共有する情報を絞る
- 友だちに渡すのは、基本 サーバーアドレス（必要ならポート）だけ
- SNSなどに不用意に公開しない（身内でもこれ大事です）

✅身内限定の“ちょうどいい運用”

まずは ホワイトリスト＋必要最小のop
バックアップは「週1回」でもいいので ゼロにしない
慣れてから自動化（毎日バックアップなど）へ

公開するなら：追加の防御（後述）必須

一般公開にすると、想定外のアクセスが一気に増えます。
最低限、次の防御は“必須科目”だと思ってください。

通信の入口を絞る（ファイアウォール／セキュリティグループ）
- 開けるのは「Minecraft用のポート」と「管理用（SSH）」だけ
- さらに可能なら、SSHは 自分の固定IPだけ許可が安全
管理用ログインを強化
- SSH鍵の利用（パスワードのみ運用を避ける）
- 推測されにくい設定（例：rootログイン禁止等）
荒らし対策の運用ルール
- 参加ルール（チャット・荒らし対応）を明文化
- バックアップ頻度を上げる（復旧できることが生命線）

⚠️注意：KAGOYAのセキュリティグループは、適用すると「許可した通信以外は拒否」になります。
設定ミス＝自分も入れない、になりやすいので、公開運用は“戻せる手順メモ”もセットで用意しておくと安心です。

KAGOYA CLOUD VPS 公式サイト

最短ルート：テンプレートで“すぐ遊ぶ”手順

KAGOYA CLOUD VPS には、OS とアプリをまとめて用意できる「アプリケーションセットアップ（テンプレート）」があります。Minecraft も対象なので、“とにかく早くマルチを始めたい”なら、このルートがいちばん迷いません。

ステップ1：インスタンス作成（OS・テンプレ選択）

作成画面で迷いやすいのは「OS」「アプリ」「鍵」「セキュリティ」の4つです。まずは以下の流れで進めます。

コントロールパネル → KVM → インスタンス → 追加（作成）
OSテンプレートを選ぶ（Linux推奨）
アプリケーションセットアップで Minecraft を選ぶ
前章で決めた CPU/メモリに合わせてプランを選択
必要に応じて セキュリティグループ（ファイアウォール）を適用
コンソールログインパスワードとインスタンス名を設定して作成
作成直後に「停止」になっていたら起動（自動セットアップが走るので数分待つ）

補足：停止中でも課金対象になるタイプのVPS運用なので、「試してやめる」ならインスタンス削除まで含めて判断すると安心です。

Java版テンプレを選ぶ手順

アプリケーションセットアップで Minecraft（Java版）（または類似の表記）を選択
参加する側（PC）は Minecraft: Java Edition のマルチプレイ画面から接続
サーバー側は最初から起動できる形で入りますが、MOD/プラグイン追加は“後から”が基本（最短ルートでは触らない）

統合版テンプレを選ぶ手順

アプリケーションセットアップで Minecraft（統合版/Bedrock）（または類似の表記）を選択
参加する側（Switch/PS/Xbox/スマホ/Windowsなど）は 統合版の「サーバー追加」から接続
統合版は通信方式が違うため、開けるポート（後述）でつまずきやすいです

ステップ2：ログイン情報・鍵・パスワードの扱い

テンプレートでも、VPSは「サーバー」なので、ログイン情報の管理が超重要です。

ログイン用認証キー（SSH鍵）
- 作成すると 秘密鍵ファイルをダウンロードします
- この秘密鍵は作成時のみダウンロード可能なので、紛失しない場所へ保管します
コンソールログインパスワード
- ブラウザ上のコンソールに入るためのパスワード（SSHとは別物）
- “緊急時の入り口”なので、推測されにくい文字列にします

推奨：SSH鍵を使う理由

パスワードより安全（秘密鍵を持つ端末しかログインできない）
KAGOYA では SSH 接続時の認証として公開鍵認証を前提にしており、運用上もスムーズです
万一、秘密鍵を失くすと復旧が面倒になりやすいので、
「バックアップ（安全な場所）」＋「外部に渡さない」を徹底します

ステップ3：サーバーアドレス確認→クライアントから参加

インスタンス詳細で グローバルIP（または割り当てアドレス）を確認し、クライアント側に入力します。

スクロールできます

版	クライアント側の操作	入力するもの	代表的なポート
Java版	マルチプレイ → サーバー追加	アドレス（IP/ドメイン）＋必要ならポート	25565（TCP）
統合版	サーバー → サーバー追加	アドレス＋ポート	19132（UDP）

※ セキュリティグループを適用している場合、許可したもの以外は遮断になります。Minecraft用のポートと、管理用の SSH（22）を忘れずに許可します。

友だちに共有する情報（共有していい範囲）

共有してOK ✅

サーバーアドレス（IP/ドメイン）
必要ならポート番号
Java/統合版どっちか
バージョン（合わないと入れません）
身内限定ならホワイトリスト運用のルール

共有NG ❌

コントロールパネルのID/パスワード
コンソールログインパスワード
SSHの秘密鍵ファイル（.key など）
サーバー内部の管理者権限情報

参加できない時にまず見る3点

版（Java/統合）とバージョンが一致しているか
- “Incompatible / Outdated” 系メッセージはまずここ
ポートが塞がっていないか（セキュリティグループ/OS側FW）
- セキュリティグループ適用中は「許可以外は全拒否」になりやすい
- Java：25565（TCP）／統合：19132（UDP）を意識
サーバーが起動・セットアップ完了しているか
- 作成直後はセットアップ中のことがあります
- インスタンスの状態やログ（分かる範囲）を確認して数分待つのも手

KAGOYA CLOUD VPS 公式サイト

自由度重視：手動で“自分好み”に建てる手順

ここは 「KAGOYAのテンプレートを使わず」、OSに自分でマイクラサーバーを入れて運用したい人向けです。
基本は Java版（Vanilla / Paper / Spigot 系） を想定します。※統合版（Bedrock）は使うサーバー本体が別なので、同じ流れでも “入れるもの” が変わります。

全体の流れ（更新→Java→本体→EULA→起動→通信設定）

ざっくりはこの順番にすると迷いにくいです。

OSを最新化（更新＋最低限の防御）
SSHの安全確認（鍵ログイン／root制限など）
Javaを用意（バージョン要件に合わせる）
サーバー本体（server.jar等）を配置
初回起動→EULA同意→再起動
server.properties等を調整
ポート開放（KAGOYA側＋OS側）
常駐化（systemd推奨）＋バックアップ方針

OS初期設定：更新と最低限のセキュリティ

1) まず更新（Ubuntu例）

SSHでログインしたら、最初に更新します。

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

2) 「作成した直後のroot運用」から早めに卒業する

KAGOYAは公開鍵認証（SSH鍵）前提で作ることが多いですが、運用はこの形が安全です。

普段用ユーザー（sudo権限あり）を作る
SSHは 鍵認証を基本（パスワードログインは極力使わない）
可能なら rootの直接ログインを禁止（少なくとも制限）

例（ユーザー作成）：

sudo adduser mcadmin
sudo usermod -aG sudo mcadmin

※KAGOYAは「秘密鍵が後から再ダウンロードできない」仕様があるので、鍵ファイルは必ず厳重に保管してください（紛失すると復旧が面倒になります）。

3) OS側ファイアウォール（UFW）を使う（任意だが推奨）

KAGOYA側（セキュリティグループ）と二重にしておくとミスに強いです。

sudo apt -y install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status

この時点では SSHだけ通す のがポイント。マイクラのポートは、サーバー起動後に開ければOKです。

更新で詰まりやすいポイント

再起動が必要なのに後回し
カーネル更新が入ったら、早めに再起動して状態を揃えます。
SSH切断→戻れない
ファイアウォールを触る前に、別タブでもう1本SSHを繋いでおくと安心です（保険）。
時刻ズレ
認証や証明書系で不具合の元。気になるなら timedatectl で確認。

Javaの準備：バージョン要件に注意

Minecraftのバージョンで「必要なJava」が変わります。
最近のJava版サーバー（例：1.21系）では Java 21 が最低要件 になりやすいので、まずはここを合わせるのが最重要です。

Ubuntu例（OpenJDK 21）：

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

java -version で 21以上 が出ればOK。

「Javaが古くて起動しない」系の典型パターン

エラー例の雰囲気：

Unsupported class file major version ...
起動直後に落ちる／jarを実行できない

対策：

Javaを上げる（またはサーバー側を下げる）
“昔の手順記事” をそのまま踏まず、公式のサーバーDLページに書かれた起動コマンド前提で合わせる

サーバー本体の配置と起動（バニラ/派生の考え方）

1) 専用フォルダを作る

sudo mkdir -p /opt/minecraft
sudo chown -R mcadmin:mcadmin /opt/minecraft
cd /opt/minecraft

2) サーバー本体を置く（公式配布の server.jar を基本に）

公式の「Server Download」ページから 対象バージョンの jar を入手
ファイル名はバージョン入り（例：minecraft_server.x.x.x.jar）

（例：wgetで落とす場合は、公式ページにある直リンクを使ってください。ここではURLは省略します）

wget -O server.jar "（公式ページのダウンロードURL）"

3) 初回起動（まずは落ちてもOK）

メモリは後で調整できますが、最初は控えめでも可。

cd /opt/minecraft
java -Xms2G -Xmx2G -jar server.jar nogui

バニラで始めるメリット

トラブル時に情報が多く、切り分けが簡単
プラグイン周りの相性問題が少ない
「まず動く」を最短で作れる

Paper/Spigot系に寄せる判断基準

次のどれかに当てはまるなら検討価値ありです。

人数が増えて TPSが落ちやすい
軽量化・最適化（ラグ対策）を強めたい
プラグインで遊びたい（権限管理、保護、経済など）

ただし、最初から欲張ると沼りやすいので、

最初：バニラ or Paper単体
次：必要なプラグインだけ追加

くらいが初心者には現実的です。

EULA同意と初回起動で生成されるファイルの見方

初回起動後、同じフォルダに eula.txt ができます。
これを 同意（true） にしないとサーバーは起動しません。

nano eula.txt

eula=false → eula=true に変更 → 保存

次に、再起動：

java -Xms2G -Xmx2G -jar server.jar nogui

あわせて把握しておくと便利なファイル：

server.properties：難易度、最大人数、ポート、ホワイトリスト等
logs/：困ったらまず見る
world/：ワールドデータ本体（バックアップ対象）

通信設定：ポート／FW／ルータの関係を整理

前提の整理（初心者が混乱しやすい所）：

KAGOYA（クラウド側）：セキュリティグループ等で “入口” を許可する
サーバーOS側：UFWなどで “OSの壁” を調整する
自宅ルータのポート開放：VPS運用なら基本不要（自宅PCで建てる時に必要になりがち）

Minecraft Java版のデフォルトは TCP 25565 です。
（ポートを変えるなら、参加側は IP:ポート の形で指定します）

FW（サーバー側）の開放

UFWを使っている場合（Java版 25565/TCP）：

sudo ufw allow 25565/tcp
sudo ufw status

自宅回線側でやること／やらないこと

やらないこと（VPS運用なら基本不要）

自宅ルータのポート開放
自宅側のグローバルIPを晒すような構成

やること

友だちに共有するのは サーバーのIP（またはドメイン）＋ポート（必要なら）
公開運用なら、最低でも
- ホワイトリスト運用
- 権限の最小化
- SSHを特定IPに絞る（可能なら）
  をセットで考える

（運用のコツ）“常駐化”は systemd が楽

手動起動だとSSHを切った瞬間に止まりがちなので、最後に常駐化しておくと運用が一気に安定します。

screen/tmux：手軽だが事故りやすい
systemd：再起動後も自動で上がるので本命

（この記事の後半で「常駐化・バックアップ・アップデート手順」を別見出しでまとめると、読者満足が上がりやすいです）

KAGOYA CLOUD VPS 公式サイト

参加方法（入り方）を迷わせない章

「KAGOYAでサーバーを立てたのに、入れない…」の多くは、入力する情報の不足か、版・バージョン違いが原因です。
ここでは初心者が迷わないように、必要情報 → 入り方 → 入れない時の直し方の順でまとめます。

Java版：マルチサーバー追加の手順

まず、友だち（参加者）に伝えるのはこの3点だけでOKです。

サーバーアドレス（IPまたはドメイン）
ポート番号（通常は不要。変えている場合のみ）
サーバーのバージョン（例：1.xx.x）

手順（Minecraft: Java Edition）

マイクラを起動 → マルチプレイ
初回なら注意文が出るので内容を確認して進む
次のどちらかを選ぶ
- サーバーを追加（一覧に保存したい人向け）
- ダイレクト接続（1回だけ入れればいい人向け）
入力する
- サーバー名：好きな名前でOK
- サーバーアドレス：IP または ドメイン
  - ポート指定が必要なら IP:ポート の形（例：xxx.xxx.xxx.xxx:25565）
一覧からサーバーを選んで接続

つまずきやすいポイント（Java版あるある）

ローカルアドレスを入れてしまう
127.0.0.1 は「自分のPC」を指します。KAGOYAのVPSに入るなら、基本は VPSのグローバルIP（またはドメイン）です。
ホワイトリスト運用で弾かれる
身内限定サーバーだと、管理者があなたの Javaのユーザー名（ID）を登録しないと入れません。

統合版：接続の考え方と注意点

統合版（Bedrock）は、接続の考え方がJava版と少し違います。
最初に「どの端末で参加するか」で、選ぶ手順が変わります。

まず共有する情報（統合版）

サーバーアドレス（IPまたはドメイン）
ポート番号（統合版は入力する場面が多い）
参加者のゲーマータグ（ホワイトリスト運用なら登録用）

手順（基本の流れ）

マイクラ起動 → 遊ぶ
サーバー タブへ
サーバーを追加（Add Server）
入力する
- サーバー名：任意
- サーバーアドレス：IP/ドメイン
- ポート：指定された番号
保存 → 一覧から選んで参加

注意点（統合版で迷いやすいところ）

端末によって「外部サーバー追加」が同じではない
端末・環境によっては、画面の項目が違ったり、外部サーバー追加がやりにくいケースがあります。
その場合は、まず Windows/スマホ版から接続確認をして切り分けるのが早いです（サーバー側の問題か、端末側の制限かが分かります）。
通信（UDP）の前提がJavaと違う
「サーバーは動いているのに入れない」場合、セキュリティ設定で通すべき通信が違うことがあります。
まずは管理者に「統合版のポート設定を変えていないか」を確認するとスムーズです。

バージョン違いで入れない時の対処

表示が英語でも、意味はだいたい次の2択です。

Outdated client：参加者（あなた）のマイクラが古い
Outdated server：サーバーが古い（または固定バージョンで運用している）

対処の基本（迷ったらこれ）

管理者に確認：サーバーのバージョンは何か
自分側を合わせる：同じバージョンで起動して接続
それでもダメなら：
- MOD/プラグイン/ローダーの違い（Java）
- 端末側の制限（統合版）
  を疑って切り分け

「クライアント側を合わせる」具体例

例1：Java版（サーバーが 1.20.1、あなたが 1.21 だった場合）

Minecraft Launcher を開く
上部の Installations（起動構成）
New Installation を作成
Version（バージョン）で 1.20.1 を選ぶ
その構成で起動 → マルチで接続

💡Java版は「最新版で起動しているつもり」でも、サーバーが固定バージョン運用だと弾かれます。
“サーバーの数字に合わせる”が鉄則です。

例2：統合版（端末の更新が追いついていない場合）

ストア（Microsoft Store / App Store / Google Play / 各コンソールのストア）で更新
更新後に再起動して接続

💡統合版は「同じ統合版」でも、端末ごとに更新タイミングがズレることがあります。
まずは更新確認がいちばん早いです。

KAGOYA CLOUD VPS 公式サイト

運用の基本：毎日困るところだけ先に押さえる

マイクラサーバー運用で「毎日困る」のは、だいたい次の4つです。

設定を変えたい（難易度・ゲームモード・説明文など）
権限をどうするか（opの付与・やりすぎ防止）
バックアップ（取ってないと詰む）
アップデート（急に上げると壊れる）

ここでは、初心者が迷わない“実務”だけに絞って解説します。

設定ファイルの触り方（難易度・ゲームモード・説明文など）

設定を変える方法は2系統あります。

ファイル編集（server.properties など）：サーバーの根本設定を変える
コマンド（/difficulty など）：その場で変えられるものを素早く変える

まずは「どっちで触るべきか」の目安を置いておきます。

ファイルで触ることが多いもの（基本は server.properties）

サーバー説明文（MOTD）
難易度（difficulty）
デフォルトゲームモード（gamemode）
最大人数（max-players）
ホワイトリスト有効化（white-list）
オンライン認証（online-mode）※むやみに変更しない
ポート（server-port）※変えるなら参加者への周知が必須

コマンドで触ることが多いもの（即時反映・戻しやすい）

難易度変更：/difficulty peaceful|easy|normal|hard
ゲームモード変更：/gamemode survival|creative|adventure|spectator
ホワイトリスト操作：/whitelist on/off/add/remove/list
権限付与：/op /deop

コツ：初心者はまず コマンドで試して、納得したらファイルに反映 すると失敗しにくいです。

ファイル編集の安全な手順（テンプレでも手動でも共通）

編集前にバックアップを1つ取る（最低限）
サーバーを止める（または保存を固める）
server.properties を編集
サーバー再起動（反映確認）

サーバーは「変更したのに反映されない」が起きやすいので、基本は 再起動で反映が鉄則です。
（“reload” 系の操作は、初心者は避けた方が安全です）

op権限の付与と“やりすぎ防止”

opは便利ですが、事故の原因にもなります。
初心者サーバーの安定は 「opを増やさない」で決まると言っても大げさではありません。

まずおすすめの役割分担

管理者（op）：1〜2人に絞る
参加者：基本は一般権限（必要ならホワイトリストで管理）

“やりすぎ防止”の具体策

opは最小限
- 「みんなop」はトラブルの近道（誤コマンド・誤破壊・チート的運用が起きやすい）
身内でもホワイトリスト運用
- “身内だけ”のつもりでも、アドレスが漏れると一気に荒れます
ルールを短く固定
- 例：装置の上限、放置の可否、難易度変更は誰がやるか、など

補足：もっと細かい権限管理をしたい場合

Java版で Paper/Spigot 系を使うなら、権限管理プラグインで「必要なコマンドだけ許可」もできます。
ただし初心者は、最初から複雑化しない方が安定します。

バックアップ設計（手動／自動／世代管理）

バックアップは「いつかやる」だと、だいたい間に合いません。
初心者向けに、最小構成から段階的に作るのがおすすめです。

最小の正解（これだけはやる）

手動でいいので“週1回”は取る
さらに、次のタイミングでは必ず取る
- アップデート前
- 設定を大きく変える前
- プラグイン/MODを入れる前

手動バックアップ（例：zip/tarで固める）

基本は「ワールド＋主要設定」をひとまとめにして、日付で残す
例：backup_2026-02-11.tar.gz のように命名

自動バックアップ（cronで毎日1回など）

例：毎日深夜にバックアップ→7世代だけ残す
これで「うっかりゼロ」がなくなります

世代管理（ローテーション）の考え方

初心者はこの3段階が扱いやすいです。

直近7日分（毎日）
直近4週分（週1）
直近3か月分（月1）

「全部毎日で無限保存」は、ストレージを圧迫して逆に危険です。

ワールドだけ守ればいい？守るべきファイル一覧

結論：ワールドだけだと“復旧できないこと”が出ます。
最低でも、次はセットで守るのがおすすめです（Java版サーバーの典型例）。

必ず守る（最優先）

world/（メインワールド）
world_nether/（ネザー）
world_the_end/（エンド）

一緒に守ると復旧がラク

server.properties（各種設定）
whitelist.json（ホワイトリスト）
ops.json（op一覧）
banned-players.json / banned-ips.json（BAN運用している場合）
permissions や plugins/（Paper/Spigot 等で導入している場合）
config/（プラグインや追加要素の設定が入ることが多い）

ポイント：ワールドだけ戻しても、ホワイトリストや設定が戻っていないと「別サーバーみたい」になりがちです。

復元手順（戻し方）までセットで用意する

バックアップは「取った」だけだと半分です。
“戻せる”ことを1回だけでいいので確認しておくと、いざという時に詰まりません。

初心者向けの復元フローはこれでOKです。

サーバー停止
現在のフォルダを退避（念のため）
- 例：world を world_broken_日付 にリネーム
バックアップを展開して配置
起動
参加して確認（スポーン地点／チェスト／権限／MOTD など）
問題があれば、すぐ元に戻せるようにしておく（退避が効く）

さらに安全にしたい場合は、バックアップ取得時に以下を意識すると破損しにくいです。

サーバー停止して取る（いちばん安全）
停止できないなら、保存を固めてから取る（保存コマンド等）

アップデート方針（自動更新しない/検証して上げる）

初心者サーバーで一番多い事故は、「勢いで最新版にして壊れる」です。
おすすめはこの方針です。

基本方針：自動で上げない

サーバー本体（jar等）は 自分のタイミングで更新
先に「何を優先するか」を決める
- 安定最優先：しばらく固定（ワールド継続が楽）
- 新要素最優先：更新頻度が上がる（検証が必要）

安全なアップデート手順（最短で事故らない）

バックアップを取る（必須）
サーバー停止
サーバー本体を更新（Vanilla / Paper など）
Java要件を確認（必要ならJavaも更新）
起動してログ確認
身内で短時間テスト（入れるか／重くないか／設定が維持されているか）
問題があれば 即ロールバック（バックアップ復元）

“検証して上げる”の現実的なやり方

可能なら、同じ設定でもう1台（小さいプラン）を作って 検証用にする
- KAGOYAの課金体系は“小さく短時間”の検証と相性が良いので、運用として合理的です

KAGOYA CLOUD VPS 公式サイト

重い・ラグい時の改善（原因を切り分ける）

ラグ対策は「闇雲に設定を下げる」より、原因を3系統（メモリ／CPU／ディスク）に切り分けてから手を打つほうが、少ない変更で改善しやすいです。
ここでは、初心者でも迷わない順番でまとめます。

まず見る指標：メモリ不足／CPU飽和／ディスクI/O

最初の3分は、これだけ見れば十分です。

サーバーログに “Can’t keep up” が出ているか
メモリが足りているか（空き・スワップ・OOM）
CPUが張り付いていないか（load・1コア飽和）
ディスク待ちが長くないか（iowait）

目安が分かる“症状→原因”早見

スクロールできます

症状	ありがちな原因	まず確認	まずやる対処
人が増えると急にカクつく	CPU飽和 / エンティティ過多	`top`、ログ	視距離/シミュ距離を下げる、装置・湧き対策
探索（新天地）で一気に重い	チャンク生成が重い（CPU+I/O）	ログ、iowait	生成負荷を減らす、事前生成を検討
時々落ちる・再起動する	メモリ不足（OOM）	`dmesg`、`free -h`	メモリ増強 or 拡張整理
常にモッサリ・保存が遅い	ディスクI/O詰まり	`iostat`、iowait	ワールド肥大の見直し、バックアップ方式整理

具体的な確認コマンド（Ubuntu例）

メモリ：

  free -h

available が少ない／swap を常用 → メモリ不足の疑い
CPU：

  uptime
  top

load average が「CPUコア数」より常に高い → CPU飽和の疑い
ディスクI/O（入っていなければ導入）：

  sudo apt -y install sysstat
  iostat -xm 1 5

%util が高止まり、await が大きい、%iowait が目立つ → I/O詰まりの疑い
OOM（メモリ不足で落ちた痕跡）：

  dmesg -T | grep -i oom

💡Paper系を使っているなら、プロファイラ（例：spark）で「どの処理が重いか」を可視化できるので、犯人探しが速くなります。

設定で効く：視距離・シミュレーション距離・生成負荷

“体感ラグ”に効きやすいのは、まず 距離系 と 生成系 です。
初心者はここだけ触れば、過剰チューニングになりにくいです。

距離系（まずここを下げる）

view-distance（視距離）
プレイヤーに送るチャンク量が減り、CPU/通信が軽くなります。
simulation-distance（シミュレーション距離）
レッドストーンやモブ等の“動作範囲”が減り、CPUが軽くなります。

おすすめの下げ方（失敗しにくい）

いきなり極端に下げず、2ずつ下げて体感確認
例：10→8→6、シミュ距離は 8→6→4

※値は server.properties で調整することが多いです（Paperでも基本の考え方は同じ）。

生成負荷（探索が重い人向け）

探索で重いなら、原因はだいたい「新規チャンク生成」です。
対策は2つの方向があります。

運用で抑える
- “探索デー”を決める（みんなが一斉に遠出しない）
- ワールドをむやみに広げない（拠点を分散させすぎない）
技術で抑える（余裕があれば）
- 事前にチャンクを生成しておく（ワールド外周を先に作る）
  → 探索時のガクッとした負荷を減らせる

MOD/プラグインの整理（犯人探しの手順）

拡張が多いほど、ラグの原因は“複合”になりがちです。
なので、1つずつ外して当てるより、段階的に切り分けるほうが速いです。

初心者向けの切り分け手順（遠回りに見えて最短）

いまの構成を一覧化（MOD/プラグイン名＋バージョン）
再現条件を固定（何人・どこで・何をすると重いか）
まずは 重い時間帯にプロファイルを取る（可能なら）
次に “半分外す”（二分探索）
- 重さが消える → 外した側に犯人がいる
- 変わらない → 残した側に犯人がいる
当たりが付いたら、最後は 1つずつで確定

※いきなり全部消すと「別物」になって比較できないので、二分探索が安定します。

追加→検証→記録のテンプレ

「何をしたら良くなったか」を残すと、次から爆速になります。
メモはこれで十分です（コピペして使えます）。

変更日時：
変更内容：
- 追加/削除：
- バージョン：
検証条件：
- 同時接続：◯人
- 場所：拠点/ネザー/遠征
- 行動：装置稼働/探索/戦闘
結果：
- 体感：改善/悪化/変化なし
- ログ：Can’t keep up の回数（概数でOK）
- 指標：CPU(load)、メモリ(available)、iowait（ざっくり）
次の手：戻す/続行/別案

最終手段：スペック増強（停止時間を最小にする段取り）

設定・整理で限界なら、最後は素直に増強が効きます。
KAGOYAはコントロールパネルでスペック変更ができますが、停止してから変更が基本です（その分、段取りで止め時間を短くできます）。

止め時間を短くする“現実的な手順”

事前告知（身内でも大事）
- 「何時〜何時は入れない」「終わったら連絡する」
バックアップを先に取る（必須）
サーバーを“きれいに止める”
- 可能なら、ワールド保存してから停止（急停止より安全）
KAGOYA側でインスタンスを停止 → スペック変更
起動 → 動作確認（ログ・接続・ワールド整合）
問題があれば即ロールバック（バックアップ復元）

増強の優先順位（迷ったらこの順）

落ちる／OOMが出る → まずメモリ増強（効果が出やすい）
常にTPSが低い／loadが高い → CPU（コア数）増強
探索・保存で詰まる／iowaitが目立つ → ディスクI/Oの見直し（ワールド肥大・バックアップ方式・不要データ整理）

⚠️注意（KAGOYA運用の落とし穴）

ストレージ容量が小さくなる方向の変更はできないため、上げる時は“戻せない”前提で判断すると安全です。
セキュリティグループを適用している場合、許可していない通信は通らないので、起動後に「入れない」ときは設定も合わせて見直します。

KAGOYA CLOUD VPS 公式サイト

セキュリティとマナー（身内でも必須）

「身内だけだから大丈夫」と思っていると、アドレス流出・権限事故・バックアップ無しのどれかでだいたい痛い目を見ます。
ここは“面倒でも最初に固定”して、以後は楽に運用できる形を作りましょう。

IP/アドレスの扱い：不用意に拡散しない

サーバーに参加するためのアドレス（IP/ドメイン）は、いわば「玄関の場所」です。拡散すると、次が起きやすくなります。

不正アクセスの試行（ログイン総当たり、ポートスキャン）
荒らしや迷惑行為（特に公開運用）
「誰が漏らしたか」問題で身内がギスる

身内サーバーでおすすめの共有ルールはこれだけです。

共有は 参加メンバーだけ（SNS・オープンなチャットに貼らない）
共有内容は 接続情報だけ
- OK：アドレス、（必要なら）ポート、Java/統合、バージョン、参加ルール
- NG：管理画面ログイン情報、SSH鍵、サーバー内の管理者情報
可能なら、アドレスを貼る場所は「参加者だけ見える場所」に固定（招待制のチャットなど）

ホワイトリスト・BAN・権限の基本

身内でも、ホワイトリスト運用がいちばん効きます。理由はシンプルで「漏れても入れない」状態を作れるからです。

最小構成（まずはこれで十分）

ホワイトリスト：ON
op：1〜2人に絞る
参加者：基本は一般権限

ホワイトリストとBANの役割分担

ホワイトリスト：入場許可の名簿（身内向けの第一選択）
BAN（プレイヤー/IP）：問題が起きた後の遮断（トラブル対応用）

“やりすぎ防止”の考え方（権限事故を減らす）

opを配る前に、次を決めておくと揉めません
- 「設定変更は誰がやるか」
- 「クリエ・権限コマンドは使うか」
- 「ワールド破壊の復旧方法（バックアップ）」
もっと細かい権限分けをしたくなったら、Java版（Paper/Spigot）で権限管理の仕組みを導入する段階に進むのが安全です
（最初から複雑化すると、原因切り分けが難しくなります）

SSHと管理画面：強いパスワード／鍵／二段階の考え方

VPSのセキュリティは「ゲーム内」より先に、管理入口（管理画面とSSH）を固めるのが最重要です。

管理画面（コントロールパネル）側

強いパスワード（使い回し禁止・長め・推測困難）
二段階認証を有効化（可能なら必須レベル）
管理画面を突破されると、インスタンス停止や設定変更までされ得ます。

SSH（サーバーへログインする入口）側

鍵認証を基本にする
パスワードより安全で、運用も安定します。
鍵の扱いルールを決める
- 秘密鍵は「参加者」に渡さない
- 保管場所を固定（紛失すると復旧が面倒）
- 端末を替えるなら鍵の移行手順もメモしておく
可能なら、アクセス元を絞る
- KAGOYAのセキュリティグループで「SSHは自分のIPだけ許可」にすると強い
- ただし設定ミスで自分も入れなくなるので、変更手順は慎重に

セキュリティグループ運用の注意

適用すると「許可以外は拒否」になります
つまり、MinecraftポートやSSHを許可し忘れると、普通に詰みます。
さらに、Pingも拒否されるため、監視系の挙動が変わることがあります（機能の制約が出る場合あり）。

問い合わせ先の切り分け（どこまでがサーバー側の話か）

トラブル時に「どこへ聞けば早いか」を決めておくと、復旧が速くなります。切り分けは次の通りです。

KAGOYA（VPS事業者）に寄る領域

コントロールパネルにログインできない
インスタンスが起動/停止できない、ネットワーク設定・セキュリティグループの挙動
料金・課金・契約に関すること
スナップショット、管理機能の仕様

自分（サーバー運用）で対応する領域

マイクラが起動しない、ログにエラーが出る
バージョン違いで入れない
ラグい・重い（設定、MOD/プラグイン、スペックの問題）
ホワイトリスト・op・BANなどの運用設計

参加者（クライアント側）で対応する領域

端末側のアップデート不足
入力間違い（アドレス・ポート）
統合版の端末特有の制限や設定

迷ったときの最短ルール：

「管理画面・VPSの機能」＝KAGOYA寄り
「Minecraftのログ・設定」＝自分の領域
「端末アプリの状態」＝参加者の領域

この切り分けを記事内で明示しておくと、初心者読者が詰まりにくくなります。

KAGOYA CLOUD VPS 公式サイト

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

「KAGOYAでマイクラ鯖を立てたのに、うまくいかない…」は珍しくありません。
ここでは 症状→原因→対処 の順で、初心者でも迷いにくい“確認の順番”に整理します。

接続できない（アドレス/ポート/FW/サーバー停止）

症状

サーバー一覧で「接続できません」「タイムアウト」になる
友だちは入れないのに、自分は入れる（またはその逆）
統合版だけ入れない／Java版だけ入れない

よくある原因

アドレス（IP/ドメイン）やポートの入力ミス
Java版と統合版の取り違え
サーバーが止まっている（落ちている／起動していない）
KAGOYA側のセキュリティ設定（セキュリティグループ等）で遮断
OS側FW（UFW等）で遮断
ポート番号がデフォルトと違う（server.propertiesで変更した等）

まずやるチェック（上から順に）

版の確認（超重要）
- Java版：通常 TCP 25565
- 統合版：通常 UDP 19132
  ※「Javaサーバーに統合版で入る」「統合版にJavaで入る」は必ず失敗します。
共有情報が揃っているか
- 伝えるべきはこれだけでOK
  - サーバーアドレス（IP/ドメイン）
  - ポート（変更している場合）
  - Java/統合
  - バージョン（Javaは特に重要）
サーバーが起動しているか
- KAGOYA管理画面でインスタンスが「起動中」か確認
- 手動構築なら、SSHでプロセスやログを確認
KAGOYA側（入口）が開いているか
- セキュリティグループを使っている場合、Minecraft用ポートが許可されているか
  - Java：25565/TCP
  - 統合：19132/UDP
- 管理用のSSH（22/TCP）も許可し忘れに注意（自分が入れなくなります）
OS側FWが塞いでいないか（UFW例）

sudo ufw status

Javaなら：

sudo ufw allow 25565/tcp

統合なら：

sudo ufw allow 19132/udp

対処のコツ（最短で解決する順番）

まず「版」→ 次に「サーバー起動」→ 最後に「FW」
ここを逆にすると沼りやすいです。
「身内限定」でホワイトリスト運用なら、ホワイトリスト未登録でも弾かれます（入れない理由が“遮断”とは限らない）。

起動直後に落ちる（Java/EULA/メモリ）

症状

起動コマンドを打つとすぐ終了する
再起動を繰り返す
ログにエラーが出てワールドが生成されない

よくある原因

EULA未同意（eula.txt が false のまま）
Javaのバージョンが足りない／古い（特に新しめのマイクラ）
メモリ不足（割当が小さすぎる／実メモリが足りない）
jarが違う（別用途のファイル／壊れたDL）
フォルダ権限が不足（配置場所とユーザーの不一致）

まずやるチェック（上から順に）

ログの最後の20行だけ見る（最短で原因が出ます）

tail -n 20 logs/latest.log

EULA
- eula.txt を開いて eula=true になっているか
Javaの確認

java -version

サーバー側の要求より古いと、起動しません。

メモリの確認

free -h

available が少ない／swap常用だと、起動後に落ちやすいです。

代表的な対処

EULA：eula=true にして再起動
Java：必要なバージョンのOpenJDKへ更新（例：21系など）
メモリ：まずは割当を控えめに増やす（例：-Xmxを1段階上げる）
- それでも落ちるなら、VPSのメモリ増強も検討
権限：サーバーフォルダの所有者・権限を見直す（運用ユーザーで読み書きできる状態に）

MOD入りでクラッシュ（依存関係/バージョン不一致）

症状

MODを入れた瞬間、起動しない
起動はするが、入った瞬間に落ちる
特定の行動（アイテムを開く等）でクラッシュする

よくある原因

ローダーの取り違え（Forge/Fabric/NeoForge など）
MOD同士の依存関係不足（必要MODが足りない）
MODの対応バージョン不一致（マイクラ本体／ローダー／MOD）
クライアントとサーバーのMOD構成がズレている
メモリ不足（MODは想像以上にメモリを食います）

犯人探しの最短手順（初心者向け）

MODを全部入れたまま悩まない（ここが一番時間が溶けます）
まず “最小構成” に戻して、起動できる状態を作る
- ローダー＋必須MODだけ
そこから 追加→起動→確認 を繰り返す
落ちたら、直前に追加したMOD周り（依存・バージョン）を疑う

※MODは「同時に10個入れる」のが最悪ムーブです。1つずつ増やす方が最短です。

設定変更が反映されない（編集場所/再起動/権限）

症状

server.properties を変えたのに反映されない
MOTD（説明文）が変わらない
最大人数や難易度が戻る／変わらない

よくある原因

編集したファイルが違う場所（別フォルダの同名ファイルを触っている）
サーバー起動中に編集して、上書き・競合している
再起動が必要な項目なのに、再起動していない
権限不足で保存できていない（編集はできたように見えて実は保存失敗）
Paper/Spigot系で、別の設定ファイル（paper-global.yml等）を触るべき項目を探している

まずやるチェック（迷わない順）

“いま動いているサーバーのフォルダ”を確定する
- 起動コマンドを打ったディレクトリが基準です
- 分からなくなったら、サービス化（systemd）している場合はUnit設定を確認
編集→保存→再起動の3点セットにする
- 多くの項目は再起動が必要です
編集内容が本当に保存されているか

grep -E "motd|difficulty|gamemode|max-players|server-port|white-list" server.properties

権限の確認

ls -l server.properties

所有者が運用ユーザーになっているか、書き込みできるか確認

対処の定番

変更したら、いったん 停止→起動（反映の確認が最も確実）
Paper系で「反映しない」が続くなら、どの設定がどのファイル管轄かを切り分ける（server.propertiesなのか、Paper側設定なのか）

KAGOYA CLOUD VPS 公式サイト

他の選択肢との比較で迷いを終わらせる

「KAGOYAで建てるべき？」の判断は、結局 “何を優先するか” で決まります。
ここでは、代表的な選択肢（公式サービス／無料サーバー／VPS）を、初心者が迷いにくい観点で整理します。

「公式サービス」が向く人／向かない人

ここで言う「公式サービス」は、代表例として Minecraft Realms（Realms Plus 含む） をイメージしてください。

向く人

とにかく 最短で身内マルチを始めたい
サーバー運用（Linux、ポート、バックアップなど）に時間を使いたくない
招待制で安全に遊びたい（公開運用しない）
サーバーは “基本機能で十分”（高度な最適化や拡張を求めない）

向かない人

同時接続が10人を超える可能性がある
Paper/Spigot などの サーバーソフトを選びたい、高度に最適化したい
“サーバー側を自由にいじる”タイプの拡張（運用・構成の自由度）を求める
料金を 月額サブスクではなく、必要な分だけに寄せたい

公式サービスを選ぶときの見落としポイント

公式はラクですが、そのぶん 自由度は小さめです。
「設定や構成をいじって伸ばす」より「手間を減らして遊ぶ」方向の設計だと思うと失敗しません。

無料サーバーが向く人／向かない人

「無料サーバー」は、Aternos などの 無料ホスティングを想定します（サービスにより仕様は異なります）。

向く人

まずは0円で試したい（長期運用が前提ではない）
時間帯によって待ってもOK（常に遊べなくても良い）
“週末だけ遊ぶ”など、稼働率が低い遊び方
学習目的で「まず触ってみる」

向かない人

24/7で常時稼働していてほしい（空いたら止まると困る）
「今日は絶対遊びたい」など、待ち時間があると厳しい
ラグや制限が少ない環境を求める（負荷が上がる遊び方をしたい）
安定したバックアップ・復元を前提にした運用をしたい

無料サーバーの“現実的な注意点”

混雑時は 起動まで待つ（キュー）ことがある
空になったサーバーは 自動停止する設計のものがある
無料である代わりに、広告や制限がある（サービス運営上の都合）

「無料＝ダメ」ではなく、“お試し用途に強い”のが無料サーバーです。
逆に、身内でも運用が長くなるほど、待ち時間や停止仕様がストレスになります。

VPSを選ぶなら比較する項目（料金・自由度・安定性・日本語情報量）

VPS（KAGOYAを含む）を選ぶなら、比較の軸はこの4本に絞ると迷いが減ります。

1) 料金の考え方

月額固定か、従量（時間・日額など）もあるか
長期運用で総額がどうなるか（半年・1年でざっくり見積もる）
“隠れコスト”
- 運用の手間（設定・監視・アップデート・復旧）
- バックアップ保存先（容量が増えると意外に効く）

2) 自由度（できること）

サーバーソフトを選べるか（バニラ／Paper系など）
MOD・プラグイン・データパックの運用がやりやすいか
サーバー設定や最適化（視距離、チューニング）をどこまで詰められるか
テンプレート（簡単セットアップ）があるか
- “すぐ遊ぶ”と“作り込む”の両方を取りたい人は重要

3) 安定性（遊びやすさ）

国内リージョン（日本）など、回線的に安定しやすい条件があるか
ディスクが速いか（体感差が出やすい）
仕様として 24/7運用が前提か（無料系と違う）
サポートや障害情報の出し方（復旧の安心感）

4) 日本語情報量（初心者が詰まらないか）

公式マニュアルが分かりやすいか
日本語の解説記事・コミュニティが多いか
“同じ環境の人”が多いか（検索で解決しやすい）

迷った人向け：選び方の結論だけ

最短で身内マルチを回したい → 公式サービス
0円で試して納得してから決めたい → 無料サーバー
自由度・安定・拡張（MOD/プラグイン）を重視したい → VPS（KAGOYA含む）

3択を一発で整理する早見表

スクロールできます

比較軸	公式サービス	無料サーバー	VPS（KAGOYA含む）
始めやすさ	とても簡単	簡単	テンプレありなら簡単／手動は中〜上級
24/7稼働	基本○	サービス次第（停止ありのことも）	○
自由度	小さめ	中（制限あり）	大（構成・最適化まで触れる）
安定性	高め	混雑・制限の影響を受けやすい	選び方次第で高めにできる
同時接続の伸びしろ	上限が明確	制限されやすい	伸ばしやすい（増強・最適化）
日本語で解決しやすい	高め	ばらつき	公式マニュアル＋国内事例があると強い

KAGOYA CLOUD VPS 公式サイト

注意事項・利用上の前提（トラブル回避のために）

商標・利用許諾・アップデートによる影響

まず大前提として、この記事はKAGOYAやMinecraft公式の発表ではなく、一般的な運用ノウハウとしての解説です。運用・公開・課金をする場合は、必ず公式の規約・ガイドラインも確認してください。

商標・ロゴの扱い
- 「Minecraft」は商標・ブランド資産に関わるため、ブログやサーバー告知での見せ方は慎重に。
- ありがちなNG例は「公式っぽく見せてしまう」「ロゴを勝手に多用する」「提携・公認と誤認させる」などです。
サーバー運営＝“商用扱い”になりやすい
- 収益化の意図がなくても、サーバーやコミュニティを公開・運営する行為が“商用利用に該当する”扱いになるケースがあります。
- 寄付・広告・課金（VIP等）を検討しているなら、特にサーバー運営に関するガイドラインは先に目を通してください。
配布・改変まわりの注意（MOD/プラグイン/配布物）
- MOD・プラグイン・配布ワールド等は、それぞれ作者のライセンス条件があります。
- 「入れるのは簡単」でも、再配布の可否や同梱していい範囲で事故が起きがちです（公開前に一度整理すると安全です）。
アップデートの影響は“避けられない前提”で設計する
- Minecraft本体の更新で、以下が連鎖的に崩れます：
  - サーバー本体（Jar） ↔ Java要件 ↔ MOD/プラグイン ↔ 設定ファイル ↔ クライアント版
- 対策はシンプルで、「バックアップ → 検証 → 本番反映」の順を固定すること。
- テンプレート利用でも「テンプレ側の対応版が更新されるまで待つ」という判断が必要になることがあります。

サポート範囲（どこから先は自己管理か）

KAGOYAのVPSは基本的に“自分が管理者”として扱うのが安全です。
つまり、困ったときに「どこまでがKAGOYA側の責任で、どこからが自分の作業か」を最初に線引きしておくのが、最短のトラブル回避になります。

スクロールできます

領域	ざっくり言うと	あなたが主にやること
基盤（ホスト・仮想基盤・ネットワーク）	事業者側が保守する範囲	障害情報の確認、発生時刻や状況を添えて問い合わせ
OS（Linux/Windows）	“使うのはあなた”の領域になりやすい	更新、ユーザー管理、SSH、FW、ログ確認
アプリ（Minecraft/Java/MOD等）	ほぼ自己管理	導入・更新・設定・トラブル解析（ログ）
セキュリティ運用	共同責任になりやすい	最小権限、公開範囲、バックアップ、鍵管理

「サポート対象外」になりやすい代表例
- Linuxのコマンド操作そのもの（コマンドの意味や個別のチューニング相談）
- インスタンス内でのOSアップグレード（例：OSを上書き更新して壊れた、など）
- MOD/プラグイン由来のクラッシュ、設定ミス、依存関係の不整合
問い合わせ前に準備すると早い情報（メモしておく）
- いつから発生したか（日時）
- 影響範囲（自分だけ／全員接続不可／特定ワールドだけ）
- 直前にやった変更（更新・設定変更・MOD追加など）
- ログの要点（全部貼るより「エラー行＋前後数行」）
“自己管理が不安”なら、方針を変えるのも正解
- 「学びながら育てたい」ならVPSは強い一方、
  「なるべく触らずに遊びたい」なら運用負荷が低い選択肢のほうが満足しやすいです。
- ここを誤ると、料金よりも時間コストで損しがちです。

KAGOYA CLOUD VPS 公式サイト

まとめ｜“最短で始めて、必要になったら強くする”が正解

KAGOYAでのマイクラ運用は、最初から完璧を目指すよりも、小さく始めて、困ったポイントだけ強化するほうが失敗しにくいです。
特に初心者は「テンプレで開始 → 最低限の運用 → 必要に応じて最適化」の順で進めると、時間もコストもムダが減ります。

初心者のおすすめ手順（テンプレ→運用→最適化）

「まず遊ぶ」を最優先にするルートです。テンプレートでサーバーの土台を作り、運用で詰まりやすい所だけ先に固めます。

テンプレートで起動（まず動く状態を作る）
- Java版／統合版（Bedrock）どちらで遊ぶかを決める
- テンプレートでインスタンス作成 → サーバーアドレスを確認 → 接続テスト
“身内でも必須”の最低限を固定
- 共有するのは「アドレス・ポート（必要なら）・版・バージョン」だけ
- ホワイトリスト運用（身内限定なら特に効く）
- opは1〜2人に絞る（事故防止）
バックアップだけは先に仕組み化
- まずは「更新前」「設定変更前」「MOD/プラグイン追加前」に手動でOK
- 慣れたら自動化（毎日＋世代管理）へ
重いと感じたら“設定で先に軽くする”
- まずは視距離・シミュレーション距離など、影響が大きい所から調整
- いきなり全部いじらず「変更→確認」を小さく回す
それでも厳しい時だけ増強（最終手段）
- “落ちる/再起動する”ならメモリ
- “常にTPSが低い/負荷が高い”ならCPU
- 変更前後でバックアップ＋短時間テストをセットにする

💡ポイント：KAGOYAはテンプレで始められるので、初心者は「手動構築の沼」を後回しにしてOKです。まず遊べる状態を作るほうが続きます。

中級者の伸ばし方（手動構築→自動化→監視）

「自由度・再現性・安全性」を伸ばしたい人向けです。運用を“属人化”させず、壊れにくい形にしていきます。

手動構築で“自分の標準構成”を作る
- 専用ユーザーで運用（root直運用を避ける）
- systemdで常駐化（SSHを閉じても落ちない）
- セキュリティグループ＋OS側FWで入口を最小化（SSHは可能なら特定IPのみ）
自動化で「毎回の作業」を消す
- バックアップ：cron＋圧縮＋世代管理（7日/4週/3か月など）
- 更新：本番は“検証してから上げる”に固定（自動更新しない）
- 変更履歴：追加したMOD/プラグインや設定変更をメモで残す（原因切り分けが速くなる）
監視で“壊れる前”に気づく
- 最低限：CPU負荷、空きメモリ、ディスク空き容量、iowait
- ラグ調査：プロファイラ等で「重い処理」を特定（犯人探しの時間を短縮）
- アラートは最初は不要でも、週1で数値を見るだけで事故が減ります

💡ポイント：中級者は「テンプレから卒業」ではなく、テンプレで早く始めた上で、必要になった領域だけ手動化・自動化していくのが現実的です。

最後にひとつだけ注意点。KAGOYAはプラン変更の柔軟性が高い一方で、課金の仕組み（停止中の扱い等）も含めて理解しておくと、想定外の出費やトラブルを避けやすくなります。
だからこそ、この記事の方針どおり 「小さく始める → まず運用を固める → 必要な分だけ強化」が、最適解になりやすいです。

KAGOYA CLOUD VPS 公式サイト