Rust×ConoHa完全ガイド｜for GAMEとVPSの違いと選び方／初心者でも迷わない手順

2026年2月13日

Rustの身内サーバーを立てたい。だけど、いざ「ConoHaでRust」と調べると情報が散らばっていて、結局こんなところで止まりがちです。

「for GAMEとVPSって結局どっちが正解？何がどう違うの？」
「テンプレートで一瞬で立つって聞くけど、運用が難しくならない？」
「何人で遊ぶなら何GBが現実的？ラグらない？」
「サーバーを作ったのに、友達が入れない／サーバーが表示されないのはなぜ？」
「PvEにしたい、サーバー名を変えたい、ワイプをどう設計すればいい？」
「RCONって必要？荒らし対策や管理を外部からやりたいけど、危なくない？」
「週末だけ遊びたい。停止しておけば料金は止まる？ムダ課金したくない…」
「アップデート後に壊れたら詰みそう。バックアップや復元の最短手順が知りたい」

こうした悩みは、あなたが知識不足だからではありません。Rustサーバー運用は、ゲームの設定だけでなく、ネットワーク（ポート）／権限（RCON）／更新（アップデート）／データ（ワイプ・バックアップ）といった“運営の基礎”が絡みます。さらにConoHaは、for GAME（テンプレで速い）とVPS（自由度が高い）の2ルートがあるため、入口で迷いやすいのが自然です。

この記事では、公式情報を軸にしながら、初心者でも迷わないように「判断基準→最短セットアップ→つまずきやすいポイント→運用の型」という順番で整理します。読み終えるころには、次の状態を目指せます。

自分に合うのが for GAMEかVPSか 迷わず選べる
作成→接続→設定変更→運用 の流れを、手順として再現できる
「表示されない／入れない」などのトラブルを 診断フローで切り分けできる
アップデート・ワイプ・バックアップを、止めない運営の型として回せる
週末運用・長期運用それぞれで、料金で損しないルールが作れる

Rustは自由度が高いぶん、サーバーも“正しく作る”より“正しく回す”ことが大切です。最短で遊び始めたい人も、今後人数が増えて本格運用したい人も、ここで基礎を固めていきましょう。

ConoHa for GAME 公式サイト
ConoHa VPS 公式サイト

記事のゴールと想定読者

できるようになること（作成〜接続〜設定変更〜運用）

この記事（この後の本文全体）を読み終えると、初心者でも 「RustサーバーをConoHaで立てて、仲間と安定して遊ぶ」 ための一連の流れがわかります。

できるようになることは、主に次の4つです。

作成：ConoHaの管理画面から、Rust用テンプレート（またはVPS）でサーバーを用意する
接続：ゲーム内コンソールから IP:ポート で確実に接続する（検索で見つからない問題も回避しやすい）
設定変更：サーバー名、ルール、マップ関連（サイズ・シード等）など「遊び方」に直結する設定を触れるようになる
運用：アップデート・再起動・ワイプ（必要なら）など、止めずに回すための基本が身につく

💡ポイント：
「立て方だけ」ではなく、つまずきやすい所（表示されない／入れない／重い）を避ける考え方まで含めて理解するのがゴールです。

対応範囲と注意点（PC版／公式・コミュニティ・Mod運用の違い）

このテーマで迷いやすいのが「どのRustを、どの運用で遊ぶか」です。ここを最初に整理しておきます。

対応範囲（主に想定）
- ConoHa上にRustサーバーを用意して、友人や固定メンバーで遊ぶ（少人数〜中人数が中心）
- 設定変更・再起動・アップデートなど、最低限の管理を行う
注意点（重要）
- ConoHaのRustゲームテンプレートは PC版のみが前提です（コンソール版の話とは分かれます）
- Rustサーバーの運用は大きく分けて3系統あります
  - 公式サーバー（Official）：自分で立てるより「参加する」側になりがち
  - コミュニティ（Community）：自分で立てやすい。まずはここが現実的
  - Mod運用（Modded）：自由度が高い反面、更新や相性問題で運用難度が上がる
- 初心者はまず 「コミュニティ（バニラ寄り）」 で安定運用を優先し、慣れてからModを検討するのが安全です。

✅この記事では、基本は「初心者が詰まりやすい運用」を避けるために、
“まずは安定して遊べる構成” を軸に解説します。

検証環境の明示（プラン・リージョン・プレイ人数の目安）

ここでは「この記事が想定している前提」をはっきりさせます。
前提がズレると、同じ手順でも 重い／入れない／不安定 が起きやすいからです。

想定するサービス

ConoHaの Rustゲームテンプレート を中心に解説（最短で立ち上げられるため）

プランの前提（重要）

Rustテンプレートは メモリ4GB以上 が条件
体感を安定させるなら 8GB以上が推奨（“快適さ”を重視した目安）

リージョンの考え方

リージョンは「あなた（または遊ぶメンバー）に近い場所」を選ぶほど有利です。
近いほど、通信の遅延（ラグ）を抑えやすくなります。

プレイ人数の目安（ざっくり）
Rustは「人数」だけでなく、マップサイズ・建築量・戦闘頻度・プラグイン有無で負荷が変わります。
そのうえで、初心者が判断しやすいよう 最初の目安 を置きます。

スクロールできます

想定人数（目安）	まず試すライン	安定重視のライン	補足
2〜4人	4GB	8GB	マップが大きいと4GBは苦しくなりやすい
5〜10人	8GB	16GB	“重い”が出たら16GBが効きやすい
10人以上	16GB〜	32GB〜	ルールや運用設計も重要（ワイプ頻度等）

初回起動に関する注意

初回はマップ生成などで すぐに遊べない時間 が出ることがあります。
「接続できない＝失敗」と決めつけず、状況確認しながら待つ判断が必要です。

ConoHa for GAME 公式サイト
ConoHa VPS 公式サイト

まず押さえる：Rustマルチサーバーの仕組みと必要条件

「自分専用サーバー」が必要になるケース

Rustのマルチプレイは、ざっくり言うと 「みんなが同じ世界に入るための“常時稼働の部屋”」 が必要です。
公式サーバーに参加する方法もありますが、次のような目的があるなら 自分専用サーバー を用意する価値が高いです。

自分専用サーバーが向いている典型パターン

友だちだけで遊びたい（第三者に荒らされたくない／落ち着いて練習したい）
ルールを自分たちで決めたい（PvP弱め、建築中心、アイテム制限など）
ワイプ（リセット）のタイミングを管理したい（忙しい週は延長、区切りでリセット等）
サーバーの場所（リージョン）を選んでラグを減らしたい
運営者権限が欲しい（迷惑行為の対処、告知、イベント運営）
Modやプラグインで遊びを拡張したい（※初心者は後回し推奨）

💡覚え方：
「遊び方を“選ぶ側”になりたいなら、自分専用サーバー」 です。

サーバー種類の整理（コミュニティ／Modded 等）

Rustのサーバーは、大きく分けると次の3つに整理すると迷いにくいです。
（※名称はサーバーブラウザ上の分類や運用実態に近いイメージです）

1) 公式系（Official）

運営が用意した“既に人がいる世界”に参加するタイプ
メリット：手軽、情報が多い
デメリット：ルール変更や運営権限は基本なし、混雑・競争が強め

2) コミュニティ系（Community）

個人・グループが運営する“バニラ寄り”のサーバー
メリット：初心者が始めやすい、ルールを柔らかくできる、運営しやすい
デメリット：管理の手間（最低限）が発生

3) Modded（拡張運用）

Modやプラグインで、ゲーム体験を変えるサーバー
メリット：自由度が高い（QoL改善、PvE化、経済要素など）
デメリット：更新のたびに相性問題が出やすく、運用難度が上がる

✅初心者におすすめの順番
コミュニティ（バニラ寄り） → 慣れたらModded
最初からModdedにすると「動かない原因が多すぎる」状態になりがちです。

求められるリソースの目安（人数×メモリ・CPUの考え方）

Rustサーバーの重さは、人数だけで決まりません。
体感を左右する“主犯”はだいたいこの3つです。

マップサイズ（大きいほど重い）
エンティティ量（建築物・箱・罠などが増えるほど重い）
同時接続人数（戦闘や移動が増えるほどCPUが忙しい）

ここを踏まえたうえで、初心者向けに判断しやすく整理します。

メモリ（RAM）の考え方

まず前提として、ConoHaのRustテンプレートは メモリ4GB以上で利用可能、快適さ重視なら 8GB以上推奨 という立て付けです。
ただしRustは条件次第でメモリを大きく使います。特に 大きいマップ や 建築が育った終盤 は増えがちです。

“迷ったら”の目安（まず外しにくいライン）

少人数（2〜4人）：まずは 8GB を基準に考える
中人数（5〜10人）：最初から 16GB も視野（安定重視）
建築多め／マップ大きめ／長期運用：ワンランク上げるのが安全

CPUの考え方（Rustはここで詰まりやすい）

Rustサーバーは、ざっくり 「一部の処理が1コアに集中しやすい」 タイプです。
そのため、次が起きると“重い体感”が出やすくなります。

サーバーがカクつく（処理落ち感）
戦闘時や拠点周りで急に重い
プレイヤーが増えると急激に悪化

対策の基本はシンプルで、まずは “人数・マップ・建築”に対して余裕のあるプラン にすること。
小手先の設定より、余力（特にCPU/RAM） が効きます。

ストレージとネットワーク（最低限ここだけ）

ストレージは SSD/NVMeが有利（ワールド保存や読み込みの体感に影響）
ネットワークは、環境として 安定した回線 が前提
そして重要なのが「ポート（通信口）」
- Rustはゲーム接続やサーバー一覧表示、管理機能などで複数ポートを使います
- ConoHaテンプレートは基本設定が整っていますが、独自に変更する場合は“通信許可”が必要になります（ここは別パートで詳しく扱うと理解がラクです）

早見表：最初のプラン決めに使う（目安）

スクロールできます

遊び方のタイプ	人数の目安	マップ/建築	まず狙うライン（目安）
お試し・短期	2〜4人	小さめ／拠点小	8GB
友人グループ定番	5〜10人	普通／拠点育つ	16GB
長期・建築多め	5人〜	大きめ／建築多	16GB〜（余裕を持つ）

※これは「最初に迷わない」ための目安です。重さは マップサイズ と エンティティ量 で大きく振れます。

ConoHa for GAME 公式サイト
ConoHa VPS 公式サイト

ConoHaはどれを選ぶ？（for GAME と VPS の判断基準）

テンプレートで早く始めたい人：ConoHa for GAMEが向く理由

ConoHa for GAME は、ゲーム用に“始めやすさ”を最優先した選択肢です。Rustサーバー運用で初心者がつまずきやすい「初期構築」を短縮できます。

向いている人

まずは 最短でマルチ鯖を立てて遊びたい
Linuxの細かい設定より、ゲーム側の設定・運営に集中したい
「サーバーが表示されない」「接続できない」などの初期トラブルを減らしたい

なぜ早いのか（イメージ）

Rust用の“テンプレート”が用意されていて、サーバーの土台を作る工程が軽い
さらに、公式が「Rustテンプレの推奨メモリ」など目安を明示しているため、プラン選びで迷いにくい

初心者が失敗しにくい考え方

まずは コミュニティ（バニラ寄り）運用を想定して、安定性を優先する
迷ったら、公式が推奨するメモリラインに寄せる（快適さに直結しやすい）

ConoHa for GAME 公式サイト

自由にチューニングしたい人：VPS運用が向く理由

ConoHa VPS は、いわば “自由に組める素のサーバー” です。テンプレの手軽さより、運用の裁量を取りにいく選択になります。

向いている人

Rustだけでなく、周辺ツールや別サービスも入れて 拡張運用したい
Mod運用（uMod/Oxide等）を前提に、細部まで管理したい
自分のルールで、バックアップ・監視・自動化など 運用設計を作り込みたい

VPSが活きるポイント

OSやミドルウェア、監視、バックアップ、ファイアウォールなどを含めて
「自分の標準構成」を作れる（＝同じ型で増やしやすい）

ただし注意（初心者がハマりやすい）

自由度が高いぶん、最初は「やること」が増えます
例：セキュリティ設定、必要ポートの理解、更新手順の固定化、データ保護の仕組みづくり

「まずは遊ぶ」を最短で達成したいなら for GAME、
「将来の運用を資産化したい」なら VPS が噛み合いやすい、という整理がしやすいです。

ConoHa VPS 公式サイト

課金方式の違い（スポット運用／長期運用での最適解）

ConoHa for GAME も ConoHa VPS も、使い方に合わせて料金タイプを選べるのが特徴です。
ここは“金額そのもの”より、課金の考え方を押さえると失敗しません。

1) スポット運用（週末だけ／短期イベント）

おすすめは 時間課金（使った時間分だけ）

✅「今週末だけ遊ぶ」「連休だけ建てる」などに強い
✅ 使わない時間を減らせば、コストを抑えやすい
⚠️ ただし、毎日立てっぱなしにするなら割高になりやすい

2) 長期運用（1か月以上、固定メンバーで継続）

おすすめは 長期割引系（for GAMEの長期割引パス／VPSのまとめトク等）

✅ 1か月以上の継続で割引が効きやすい
✅ 「毎晩ちょっとずつ」遊ぶスタイルと相性が良い
⚠️ プラン期間・キャンペーンで見え方が変わるので、申し込み画面の金額が最終判断

初心者向け：迷ったときの結論

“2週間以内”で終わる見込み → 時間課金でまず試す
“1か月以上”続けそう → 長期割引系を検討（最初からコスパが安定しやすい）

後から乗り換える場合の設計（設定・データの扱い）

「最初は for GAME で始めて、慣れたら VPS へ」みたいな移行は現実的です。
ただし、移行をラクにする鍵は “データを何として残すか”を先に決めることです。

まず押さえる：Rustサーバーの“引っ越し対象”

移行で扱うデータは、主に次の3層です。

ワールドデータ（マップの進行状況）
サーバー設定（サーバー名、各種パラメータ、起動オプション等）
拡張要素（Mod/プラグイン、権限、各種ツール設定）

このうち初心者が最初に決めやすいのは、次のどちらかです。

A：ワールドは捨てて、設定だけ持っていく（移行が軽い／やり直しが効く）
B：ワールドも含めて引っ越す（手間は増えるが“続き”で遊べる）

乗り換えを見据えた“最小ルール”（これだけで後がラク）

設定変更はメモして残す（変更日時・内容・目的を1行でOK）
ワイプ方針を決める（例：移行のタイミングでマップワイプ）
バックアップの癖をつける（“何か触る前に1回”が鉄板）

よくある失敗と回避策

失敗：移行直前に色々いじって、何が効いたか分からなくなる
→ 対策：「変更→動作確認→記録」の順番を固定する
失敗：Modを入れすぎて、移行先で動かない原因が増える
→ 対策：最初は バニラ寄りで安定させ、必要なものだけ追加する

まとめ：一発で決める早見表

スクロールできます

迷いどころ	for GAMEが合う	VPSが合う
最優先	早く遊びたい	自由に作り込みたい
運用難度	低め	中〜高（設計力が効く）
運用スタイル	少人数・定番運用	Mod/監視/自動化など拡張
料金の考え方	時間課金 or 長期割引パス	時間課金（上限あり）やまとめトク等

ConoHa for GAME 公式サイト
ConoHa VPS 公式サイト

失敗しないプラン選び（人数別の現実的な目安）

最低ラインと推奨ラインを分けて考える

Rustサーバーは「起動できる」と「快適に遊べる」が別物です。
まずは 最低ライン（動く） と 推奨ライン（ストレスが少ない） を分けて考えると、プラン選びで迷いにくくなります。

前提として押さえておきたいこと

ConoHaのRustテンプレートは メモリ4GB以上で利用可能、ただし 快適さ重視なら8GB以上推奨 という立て付けです。
そのうえで負荷は、人数だけでなく次で大きく変わります。
- マップが大きい
- 拠点・建築が増える
- 戦闘やイベントで同時に動く人数が多い
- Mod/プラグインを入れる

なので「人数別の目安」は、“あなたの遊び方”を一段階反映した数字にすると失敗しません。

少人数（2〜4人）想定

最低ライン（動く）

メモリ 4GB（ただし軽めの運用前提）

推奨ライン（安心して遊ぶ）

メモリ 8GB（まずはここが堅い）

こんな遊び方なら推奨ラインに寄せるべき

拠点づくりが好きで、箱・電気・トラップを作り込みたい
マップを大きめにしたい
“友だちが来た時だけ”ではなく、わりと頻繁に遊ぶ

判断のコツ

「4GBで動く」は“最低限”です。
少人数でも 遊び方が濃い（建築多め） と、体感の重さが出やすいので、最初から8GBにすると失敗が減ります。

中人数（5〜10人）想定

最低ライン（動く）

メモリ 8GB（マップ小さめ・建築控えめなら成立しやすい）

推奨ライン（快適さを確保）

メモリ 16GB（安定を優先するならここ）

この人数帯でよくある落とし穴

人数が増えるほど、拠点の総量も増えます。
結果として「序盤は軽かったのに、1〜2週間で急に重くなる」ことが起きがちです。

判断のコツ

“毎晩ちょっとずつ”遊ぶ運用なら、後半に重くなるのが普通なので、最初から16GBを視野に入れると安心です。

大人数（それ以上）想定

最低ライン（動く）

メモリ 16GB（ただし条件次第でギリギリ）

推奨ライン（トラブルを減らす）

メモリ 32GB以上（長期運用・建築多めなら特に）

この人数帯は「プラン」だけでなく「設計」も効く

マップサイズを欲張らない
ワイプ（リセット）方針を決める
定期再起動など運用ルールを作る
こういった“設計”をセットで考えるほど、必要スペックが現実的になります。

早見表（迷ったらこれ）

スクロールできます

想定人数	最低ライン（動く）	推奨ライン（快適寄り）	向いている運用イメージ
2〜4人	4GB	8GB	まず安定して遊ぶ／小〜中規模の拠点
5〜10人	8GB	16GB	友だちグループで継続／拠点が育つ前提
それ以上	16GB	32GB〜	長期運用・イベント多め／建築量が増えやすい

※「推奨」は“快適さ重視の現実ライン”として置いています。Mod運用や大マップは、さらに上を見た方が安全です。

ラグが出る典型パターン（CPU不足／メモリ不足／ディスク逼迫）

ラグの原因は1つとは限りませんが、初心者が切り分けしやすいように 症状 → 原因の当たり → 最初の一手 で整理します。

1) CPU不足っぽいとき

よくある症状
- 人が集まった瞬間にカクつく
- 戦闘・レイド・拠点周りで一気に重くなる
- “時間帯”で体感が変わる（ピーク時に悪化）
最初の一手
- 最大人数を抑える（まずは上限を下げる）
- マップを小さめにする
- 改善しなければ 上位プランを検討（CPU余力を増やす）

2) メモリ不足っぽいとき

よくある症状
- ワールド保存や再起動に時間がかかる
- だんだん重くなり、終盤ほどつらい
- 場合によってはサーバーが不安定になる
最初の一手
- メモリを増やす（8→16GB など）
- マップサイズを下げる、または ワイプで整理
- Modを使っているなら “まず外して”原因を減らす

3) ディスク逼迫（容量・I/O）っぽいとき

よくある症状
- 定期的に小さなフリーズが入る（保存タイミングで顕著）
- 起動・更新・再起動が遅い
- ログが増え続けて、気づいたら容量が厳しい
最初の一手
- 空き容量を確保（不要ログ・バックアップの整理）
- バックアップの世代数を決める（溜めすぎない）
- それでも厳しければ 容量に余裕のある構成へ

失敗を減らす“実務的な結論”

「とりあえず最小で」より、“推奨寄りでスタート”した方が、結果的に安く済むことが多いです。
（途中で重くなって移行・作り直しが発生すると、時間コストが大きいので…）
迷ったら、まずは 8GB（少人数）／16GB（中人数） を基準に、
マップ・建築・Modの有無で上げ下げするのが現実的です。✅

ConoHa for GAME 公式サイト
ConoHa VPS 公式サイト

最短セットアップ：テンプレートからRustサーバーを作成する

作成前チェック（サーバー名方針／公開・非公開／運用ルール）

作成ボタンを押す前に、ここだけ決めておくと「作ったのにやり直し」が激減します。

1) サーバー名の方針（後から効いてくる）

短く・判別しやすく（例：teamname-rust のように用途がわかる）
個人情報を入れない（配信・スクショで露出する可能性があります）
友だちが探すなら、メンバーに共有しやすい表記にする
（日本語名にするより、英数字中心のほうが共有時にミスが減りやすいです）

※ConoHaのRustテンプレートでは、あとで接続に使う 「Rust Server name」 として表示されます（控える対象になります）。

2) 公開・非公開の決め方（初心者向けの現実解）
「非公開＝完全に隠す」と考えると難しくなりがちです。まずは次のどれを目指すか決めるのがラクです。

スクロールできます

目的	まず選びやすい形	メモ
身内だけで遊ぶ	IP共有＋パスワード	設定が軽く、事故が少ない
検索でも入れるようにしたい	公開（一覧に出す）	サーバー名が被ると探しにくい
絶対に第三者を入れたくない	アクセス制限	後で“仕組み”を整える必要あり

最初は 「IPで接続＋必要ならパスワード」 が、簡単でトラブルが少ないです。

3) 最低限の運用ルール（決めないと揉めやすい）

管理者（1人でOK）：再起動・設定変更をする人
共有情報：IP／接続方法／パスワード（使うなら）
遊ぶ期間：短期（週末）か、長期（1か月以上）か
リセット方針：まずは「必要になったら考える」でOK（決めすぎない）

サーバー追加の手順（テンプレート選択〜作成完了まで）

ここでは ConoHa for GAME のゲームテンプレート（Rust） で、最短で作る流れをまとめます。
画面の細かな文言は更新されることがありますが、操作の“骨格”は同じです。

手順（ざっくり3分）

ConoHaのコントロールパネルにログインし、メニューから 「GAME」 を選ぶ
「サーバー追加」 を押す
イメージタイプで 「ゲーム」 を選び、一覧から 「Rust」 を選択
リージョン（場所）を選ぶ
- メンバーが日本中心なら、近いリージョンを選ぶほどラグが出にくいです
プラン（スペック）を選ぶ
- 最低条件：メモリ4GB以上
- 快適さ重視：8GB以上が推奨
サーバー名を入力し、台数は通常 1台でOK
作成を確定（申し込み／作成完了まで待つ）

作成直後に“必ず控えるもの”

IPアドレス：ConoHaの「サーバー」一覧で確認してメモ
Rust Server name：あとでコンソール画面（サーバーへログイン後の表示）で確認してメモ

この2つを控えておくと、接続で迷子になりません。✅

初回起動で時間がかかる理由と待つべきサイン

「接続できない＝失敗」ではないことが、Rustではよくあります。初回は特に。

時間がかかる主な理由（初回あるある）

マップ生成が走る
初回起動時はワールド（島）を作る処理があるため、プランによっては 30分程度 かかることがあります。
起動時に最新バージョンの確認・インストールが入る
サーバー起動タイミングで更新があると、その分だけ起動が遅くなります。

待つべきサイン（初心者でも見分けやすい）

ConoHa側でサーバーが「稼働中」になっている（OSとして起動している）
Rust側でまだ準備中の間は、
IPで接続しても入れない
サーバー一覧にも出てこない
という状態になりえます（焦らなくてOK）

やってはいけない行動（時間を余計に溶かします）

何度も連続で再起動する
→ 生成や更新が“最初から”になり、結果的に遅くなることがあります。

おすすめの動き方（最短で前に進む）

まずは作成後に IPを控える
その後、時間を置いてから接続を試す（ダメならさらに待つ）
「待っても無理そう」になって初めて、ログイン情報の確認や再起動に進む
（最初から深追いすると迷いやすいです）

ConoHa for GAME 公式サイト
ConoHa VPS 公式サイト

最初に必ず控える情報（接続・管理の生命線）

サーバー基本情報（グローバルIP／サーバー名）

Rustサーバー運用で「迷子」になる原因の多くは、参照すべき情報を控えていないことです。まずは接続に直結する2点を、作成直後にメモしておきましょう。

控えるべき2つ（最優先）

グローバルIP（Server IP Address）
友だちに共有する「住所」です。IP接続を使う場合、これがないと始まりません。
サーバー名（Rust Server name）
Rust内のサーバー検索（Community）で見つけるための名前です。
※名前は重複しうるので、初心者は IP指定の接続を主軸にすると迷いにくいです。

どこで確認する？（迷わない導線）

IP：ConoHaのコントロールパネル（GAME → サーバー一覧）で確認して控える
Rust Server name：コンソールでログイン後の表示で確認して控える（表示される値をそのまま使う）

メモのコツ（後で助かる）

友だちに共有するのは、基本 IP:ゲームポート の形式（例：xxx.xxx.xxx.xxx:28015）
サーバー名検索で入る運用を想定するなら、検索用の表記ゆれを避ける
- 例：全角/半角、日本語/英数字、スペース有無など

コピペ用：控えるメモテンプレ

【接続用】
Server IP Address（グローバルIP）：
ゲームポート（例：28015）：
接続コマンド（例）：client.connect <IP>:<PORT>

【検索用】
Rust Server name：
（Community検索で使う）

管理用情報（root／RCONパスワード等）

次は「運営者しか触らない情報」です。ここが漏れると、最悪サーバーを乗っ取られます。
“控える”だけでなく“守る”のがセットです。

root（サーバー管理者）情報

rootで必要になる場面

設定変更（マップサイズ・seed・PvE切替など）
アップデート確認、再起動、ログ確認
ファイルのバックアップ／移行

控えるべき内容

rootパスワード（作成時に設定したもの）
ログイン手段（SSHで入るのか／コンソールで入るのか）

重要な注意（セキュリティ）

ConoHa for GAMEは初期状態で、ゲームに不要な通信が制限されています。
SSHで作業する場合は、SSH用のセキュリティグループ（22番ポート相当）を一時的に許可し、作業が終わったら解除するのが安全です。
rootパスワードは、共有しない・使い回さない・長くランダムにする（これだけで事故が激減します）

RCON（遠隔管理）情報

RCONは、ゲーム外からサーバーを操作するための仕組みです。
「管理画面っぽく運営したい」「荒らし対応を素早くしたい」なら、早めに押さえる価値があります。

RCONで控えるべき3点

RCONポート
RCONパスワード
接続先IP（＝Server IP Address）

初心者向けの運用方針（ラクで安全）

最初は「使う予定ができてから」でもOK
（ただし、使うと決めたら 必ず強いパスワードに）
RCONパスワードは、短い／辞書語／使い回しを避ける
例：16文字以上、英大小＋数字＋記号を混ぜる

どこで確認・変更する？（迷わない考え方）

Rustサーバーは起動オプション（起動設定）に、RCONの設定値を持つのが一般的です。
ConoHaのRustテンプレートでも、設定変更で起動設定ファイルを開く運用が前提になっています。
そのため、RCONも同じ場所（起動設定）で「現在値の確認」「必要なら変更」という流れで整理すると理解が早いです。

ゲーム接続に必要なポートの全体像

「接続できない」「一覧に出ない」は、ポート（通信口）が絡むと一気に沼ります。
ここでは、Rust運用で出てくるポートを 役割ベースで把握できるように整理します。

まず結論：最初に効くのはこの2つ

ゲーム接続（プレイヤーが入る）：28015/UDP が中心
サーバー検出（一覧・照会）：27015（Query系）が関わる

役割別ポート早見表（ConoHaのRustテンプレート前提）

スクロールできます

役割	代表的な用途	プロトコル	ポート例
プレイヤー接続	友だちがサーバーに入る	UDP	28015
サーバー照会（Query）	サーバー一覧表示・検出の補助	TCP/UDP	27015
RCON	遠隔管理ツールで操作	TCP	28016
追加の通信枠	構成により使われる補助ポート	UDP/TCP	28017 / 28023 など
Rust+	公式コンパニオン連携	TCP	28082–28083

ここが超重要（ConoHa特有のハマりどころ）

ConoHa for GAMEは、セキュリティグループで “ゲームに必要なポート以外” が基本ブロックされます。
なので、SSH（22番相当）や独自ツール用ポートを使うなら、許可設定が別途必要です。
Rust+を使う場合は、テンプレート提供時期やセキュリティグループの状態で、ポートが開いているか確認が必要になることがあります。

チェックの順番（トラブル時の最短ルート）

友だちが入れない → まず IP:28015 が正しいか確認
サーバー一覧に出ない → サーバー起動完了待ち＋Query系の状況を疑う
管理ツールがつながらない → RCONポートとパスワード、許可ルールを確認
SSHできない → SSH用セキュリティグループを追加したか確認（作業後は解除）

ConoHa for GAME 公式サイト
ConoHa VPS 公式サイト

セキュリティと通信設定（詰まりやすいポイントを先回り）

セキュリティグループ（仮想ファイアウォール）の考え方

ConoHaの「セキュリティグループ」は、サーバーの外側（入口）で通信を制御する仕組みです。イメージとしては、建物に入る前の受付ゲートみたいなもの。

ここを理解すると、初心者がハマりがちな

「サーバーが表示されない」
「友だちが入れない」
「SSHがつながらない」

が、かなり整理しやすくなります。

基本ルール（これだけ覚える）

セキュリティグループは原則、許可した通信だけ通す（ホワイトリスト方式）
ルールは主に次の項目で決まる
- 通信方向：IN（外→サーバー）／OUT（サーバー→外）
- プロトコル：TCP or UDP
- ポート番号：28015など
- IP/CIDR：許可する接続元（例：自宅IPだけ）

初心者向けの設計方針（失敗しない型）

ゲームに必要なものは開ける（後述）
それ以外は「使う時だけ」「使う人だけ」開ける
→ これが一番安全で、トラブルも減ります

もう1つ大事：OS側のファイアウォール
ConoHa側のセキュリティグループとは別に、サーバー内部（OS）にもファイアウォール設定がある場合があります。
「セキュリティグループで開けたのに、まだつながらない」時は OS側も疑う、というのが最短ルートです。

開けるべきポート／開けない方がいいポート

ここは「何をしたいか」で最小セットが変わります。
最初は “遊ぶのに必要な最小限”＋“管理に必要な分だけ” の考え方が安全です。

ゲーム用ポート

結論：テンプレートの標準セキュリティグループを使うなら、基本は追加で開けなくてOK なケースが多いです。
Rust用として、必要ポートがまとまったセキュリティグループが用意されています。

ただし「自分でセキュリティグループを作って付け替えた」場合は、最低限これらを意識します。

開ける対象（代表例）

プレイヤーが入るための通信（ゲーム本体）
サーバー照会（一覧表示・検索に関わる通信）
RCON（使うなら）
Rust+（使うなら）

初心者向け：目的別“最小セット”

スクロールできます

やりたいこと	開ける考え方（IN）	補足
友だちと普通に遊ぶ	Rust標準のゲーム用ポート	まずここだけでOK
サーバー検索に出やすくしたい	Query系も含めて必要ポート	「表示されない」対策の要点
RCONで管理したい	RCON用ポートを追加（使う時だけ）	可能なら接続元IPを絞る
Rust+を使いたい	Rust+用ポートを許可	テンプレート世代で条件が変わる場合あり

開けない方がいい（やりがちNG）

プロトコルを「全て」にして、ポートも広く開ける
→ 設定はラクでも、外部から見た“穴”が増えます
使わない機能のポートまで開ける
→ 「何のために開けたか分からない」状態が事故の元です

SSHなど管理用ポート

管理用は開け方が一番重要です。理由はシンプルで、狙われやすいから。

基本方針

SSHは“必要な時だけ”開ける
開けるなら 接続元IPを自分の回線に限定する（IP/CIDRで絞る）

おすすめ運用（初心者でも安全に回せる）

普段：SSHは閉じておく
作業するときだけ：SSHを開ける（できれば自宅IP限定）
作業が終わったら：SSHを閉じる ✅

どうしても外出先からSSHしたい場合

まずは ConoHaのコンソール（ブラウザからログイン）で作業できないか検討
外からSSHするなら、最低でも
- 強いパスワード（または鍵認証）
- 接続元IPの制限
  のどちらか（できれば両方）を徹底します

最低限やるべき防御（パスワード管理／不要アクセス遮断）

ここは「高度なこと」より、事故を起こしやすい所だけ先に塞ぐのがポイントです。

1) パスワード管理（これだけで被害が激減）

root / RCON は別パスワード（使い回ししない）
長さは 16文字以上 を目安に、英大小・数字・記号を混ぜる
共有は最小限（管理者だけ）
- 共有が必要なら、期限を決めて後で変えるのが安全です

2) 不要アクセス遮断（“開けっぱなし”をやめる）

SSHは 使う時だけ開ける（終わったら閉じる）
RCONも 使う時だけ、可能なら 接続元IPを絞る
「何のためのルールか分からない」ものは削除する
→ ルールが増えるほど、トラブル時の原因切り分けが難しくなります

3) つまずきやすいチェックポイント（現場のあるある）

セキュリティグループを付け替えたら、Rust用の必要ポートが抜けていた
→ 「入れない」「一覧に出ない」の典型原因
セキュリティグループはOKでも、OS側ファイアウォールで止まっていた
→ “外側OK・内側NG”のパターン
Rust+だけ動かない（テンプレート世代／自前ルールでポートが足りない）
→ Rust+用ポートが許可されているか確認

初心者向け：安全設計の合言葉

ゲーム用は必要最小限で公開
管理用は“自分だけ”に限定
使わない穴は作らない 👍

ConoHa for GAME 公式サイト
ConoHa VPS 公式サイト

ゲームから接続する（IP指定／サーバー検索）

IP:ポートで直接つなぐ手順

サーバーに確実に入るなら、まずは IP指定接続 がいちばん安定です。
「サーバー一覧に出ない」「検索で見つからない」といった初期のつまずきを避けやすい方法でもあります。

事前に用意するもの

グローバルIP（ConoHaの管理画面で確認）
ゲーム用ポート（ConoHaのRustテンプレートは通常 28015/UDP が中心。変更していなければ 28015 を使うことが多いです）

手順（Rustゲーム内）

Rustを起動し、メニュー画面のまま F1キー を押してコンソールを開く
下の形式でコマンドを入力して実行する

client.connect <IPアドレス>:<ポート>

例

client.connect 203.0.113.10:28015

サーバー側でパスワード設定がある場合は、接続時に入力を求められます
接続できたら成功です（以降は「履歴」から入りやすくなります）

初心者が間違えやすいポイント

IP の打ち間違い（特に数字の並び）
:（コロン）を抜かす
ポートを 28015 以外に変えているのに、昔の番号で接続している
初回起動直後で、マップ生成・更新が終わっていない（しばらく待つ必要がある）

サーバー名で検索して入る手順

「毎回IPを打つのは面倒」という場合は、サーバー検索（Community）でも入れます。
ただし検索は、反映が遅れたり、同名が混ざったり しやすいので、最初は IP接続と併用するのがおすすめです。

手順（Rustゲーム内）

Rustを起動 → Play Game（サーバー一覧） を開く
タブを Community に切り替える
検索欄に サーバー名（Rust Server name） を入力する
表示されたサーバーを選んで接続する

検索で見つけやすくするコツ（運営側の工夫）

サーバー名は 英数字中心＋短め にする（表記ゆれを減らす）
記号や絵文字、全角スペースを多用しない（検索ミスが増えやすい）
似た名前が多い場合は、固有の接頭辞をつける
例：ABC- や teamname- など

それでも見つからないときの考え方

まず IP:ポートで入れるか を試す（入れるならサーバー自体は動いている可能性が高い）
検索はタイムラグがあることがあるため、作成直後は焦らず少し待つ

お気に入り登録・再接続を楽にするコツ

毎回の接続作業を減らすと、運用がかなりラクになります。ここは小技の差が大きいです。

1) まずは「履歴（History）」を育てる

一度でも接続できれば、サーバー一覧の History（履歴） に出てくることが多いです
最初だけIP接続 → 次から履歴、の流れが最短です

2) Favorites（お気に入り）に入れる

サーバー一覧で対象サーバーを見つけたら、お気に入り（Favorites） に追加
次回から Favoritesタブ だけ見ればよくなります
※UIは更新されることがありますが、基本は「お気に入り登録→Favoritesから再接続」の発想でOKです

3) 共有用の“接続セット”を作っておく（友だち用）
DiscordやLINEに、これを固定しておくと質問が激減します。

接続コマンド
- client.connect IP:PORT
サーバー名（検索用）
パスワード（ある場合のみ）
補足
- 「検索に出ないときはIPで入ってね」など一言

テンプレ（コピペ用）

【接続】client.connect 203.0.113.10:28015
【サーバー名】teamname-rust
【パスワード】（必要ならここ）
【補足】検索に出ないときはIP接続でお願いします

4) 「再接続しやすい運用」を最初から決める

ポートやサーバー名をコロコロ変えない（共有情報が陳腐化しやすい）
変更したら、共有テンプレも同時に更新する（“情報のズレ”が一番の敵です）

ConoHa for GAME 公式サイト
ConoHa VPS 公式サイト

つながらない・サーバーが表示されないときの診断フロー

まず確認する3点（起動状態／初回生成中／ポート許可）

トラブル時は、いきなり細かい設定に入るより、「今どこで止まっているか」を3点で切り分けると最短です。

診断の順番（この通りにやると迷いにくい）

起動状態：ConoHa側でサーバーは稼働中か
初回生成中：初回のマップ生成・初期化が終わっているか
ポート許可：必要ポートがセキュリティグループで許可されているか

1) 起動状態：サーバーは動いているか

まずはConoHaの管理画面で、対象サーバーが 稼働中 になっているか確認します。

稼働中 → 次へ
停止中／エラー → 起動（再起動）し、状態が安定してから次へ

ここでのポイント

“ゲームに入れない”のはRust側の問題に見えますが、実際は サーバーが起動していないだけのケースが珍しくありません。

2) 初回生成中：初回は待ちが発生しやすい

Rustは初回アクセス時に マップ作成処理 が走り、プランやタイミングによって 30分前後 かかることがあります。
この間は、次のようになりがちです。

サーバー検索に出ない
IP指定しても入れない／接続が続かない

待つべきサイン

ConoHa側は稼働中だが、Rust側はまだ安定していない（作成直後）
何度試しても「Connecting」から進まない

やりがちなNG

連続で再起動をかける（生成や更新が巻き戻ることがあり、逆に遅くなる）

3) ポート許可：セキュリティグループを疑うべき場面

ConoHa for GAMEはセキュリティグループ（仮想ファイアウォール）で通信を制御します。
Rustテンプレートの標準セキュリティグループを使っていれば基本は整っていますが、次の場合は要注意です。

セキュリティグループを 自分で作って付け替えた
管理目的で SSH（22番） などを使おうとしている
RCON や Rust+ を使いたい

まず押さえる最小の全体像（代表例）

ゲーム接続：28015/UDP
照会（検索・一覧系）：27015/TCP・UDP
RCON：28016/TCP
Rust+：28082–28083/TCP

「入れない」「一覧に出ない」は、まず 28015/UDP と 27015 の許可を疑うのが近道です。
「SSHできない」は、そもそも 22番ポートが許可されていないことが多いです（ゲーム用以外は別途許可が必要）。

症状別チェックリスト

検索に出ない

検索（Community）に出ない場合、原因はだいたい次のどれかです。上から順に潰します。

A. そもそも初回生成中

作成直後（特に最初の30分前後）は“出ない”ことがある
✅対応：いったん待つ（連続再起動はしない）

B. 検索の仕様（反映遅れ・同名問題）

サーバー名は重複しうるため、検索で迷子になりやすい
✅対応：検索は補助と割り切り、まずはIP指定で接続できるか確認する

C. セキュリティグループ／ポートが不足

28015/UDP（接続）や 27015（照会）が抜けていると、一覧・検索に影響が出やすい
✅対応：Rust用セキュリティグループ（標準）を使う／自作ルールなら該当ポートを追加

D. “検索に出ないけどIPで入れる”場合

この状態は「サーバーは動いている」可能性が高いです
✅対応：運用ルールとして IP接続を正 にして、サーバー名検索はサブにするのが安定します

最短の確認方法（おすすめ）

Rustのコンソール（F1）で次を実行し、入れるかだけ見ます
- client.connect <IP>:28015
  入れたら「検索の問題」、入れないなら「起動／ポート／生成中」の問題に戻れます。

接続途中で落ちる

「Connectingの後に戻される」「ロード途中で落ちる」は、原因の当たりが付きやすい症状です。

A. 初回生成・更新が終わっていない

✅対応：時間を置いて再試行（特に作成直後）

B. IPやポートの入力ミス

✅対応：次をチェック
- 数字はすべて半角
- .（ピリオド）と :（コロン）を落としていない
- ポートは変更していない限り、まず 28015 を試す

C. ポート許可が足りない／自作セキュリティグループの抜け

✅対応：Rust用ポート（特に 28015/UDP）を再確認
- 「自作SGに替えたあとから入れない」は、この原因が最多です

D. サーバー側の負荷が高い（特にピーク時）

✅対応（軽い順）
- いったん最大人数を下げる
- しばらく待って再接続（ピークを避ける）
- 改善しなければプラン見直し（CPU/RAMに余裕を）

E. Rust+関連でエラーが出る

Rust+を使うなら、Rust+用ポート（28082–28083/TCP）が必要になります
✅対応：標準セキュリティグループなら自動で開くケースがありますが、古い環境や自作ルールでは開放が必要になることがあります

Pingが高い／カクつく

Pingやカクつきは「回線の問題」と思われがちですが、実際は 距離（リージョン） と サーバー負荷 が大半です。

A. リージョン（物理的な距離）が遠い

症状：常にPingが高い（時間帯に関係なく高い）
✅対応：メンバーの居住地に近いリージョンへ（近いほど有利）

B. サーバー負荷（CPU不足）が原因

症状：戦闘時・拠点周り・人数が増えた瞬間にカクつく
✅対応（効きやすい順）
- 最大人数を抑える
- マップサイズを小さくする
- 建築密度が増えすぎたらワイプを検討
- それでもダメなら上位プラン（CPU/RAM余裕）

C. メモリ不足が原因

症状：序盤は快適→日数が経つほど重い／再起動や保存が重い
✅対応：プランのメモリを上げる、マップを小さくする、Modを減らす（入れている場合）

D. ディスク逼迫／ログ肥大

症状：定期的に小さくフリーズする、起動や更新が遅い
✅対応：空き容量確保、不要ログ整理、バックアップ世代数を決める

最後に：初心者が最短で抜ける“鉄板ルート”

まず IP:28015 で入れるか を試す
- 入れる → 検索・表示の問題（運用はIP接続中心に）
- 入れない → 起動状態 → 初回生成 → ポート許可の順で戻って潰す

この流れを覚えるだけで、「とりあえず全部いじって余計に悪化」を避けられます。

ConoHa for GAME 公式サイト
ConoHa VPS 公式サイト

アップデート運用（止めないための基本）

アップデートの仕組み（自動更新のタイミング理解）

ConoHaのRustテンプレートは、Rustサーバーが起動するタイミングで更新の有無をチェックし、必要なら更新を実行する仕組みです。
つまり実務的には「再起動＝アップデートを取りに行く動作」になります。

初心者が押さえるべきポイントは次の3つです。

アップデートは“再起動時”に走る（起動中に勝手に差し替わる、というより「起動前後の処理」と考える）
更新がある／ないに関わらず、起動完了まで時間がかかることがある
目安として30分程度かかる場合がある、と公式が案内しています。
初回起動はマップ生成もあるため、起動完了まで接続できないことがあります（慌てて再起動連打しないのがコツです）。

運用のコツ（止めないための型）✅

アップデート日（※Rustは更新頻度が高い）に備えて、「再起動する時間」を先に決める
プレイヤーがいる場合は、再起動前に「何分くらい落ちるか」を共有しておく（体感トラブルが激減します）

手動で更新する手順（必要なケースだけ）

結論から言うと、ConoHaのRustテンプレートは 通常は“手動でSteamCMDを叩く”必要はありません。
まずは「再起動で自動更新」が基本です。

それでも“手動対応”が必要になるのは、主に次のケースです。

サーバー設定をいじった結果、自動更新の処理が無効化されてしまった
（VPS側で）systemdの設定を変更し、起動前処理（自動更新）が動かなくなった
何らかの事情で「自動更新を元に戻したい」

ここでは、公式が案内している「自動更新を復旧させる」手順を、初心者向けに噛み砕いて書きます（VPS向けの案内ですが、同様の構成で使われることがあります）。

自動更新の復旧（例：ExecStartPre がコメントアウトされている場合）

Rustサーバーを停止

systemctl stop rust-server.service

設定ファイル内で、コメントアウトされている ExecStartPre を戻す
（公式例では sed で一括修正します）

sed "s/^# ExecStartPre/ExecStartPre/" -i /etc/systemd/system/rust-server.service

systemdに変更を再読み込みさせる

systemctl daemon-reload

Rustサーバーを起動（起動時に更新チェックが走る想定）

systemctl start rust-server.service

この復旧後は、今後はVPSの再起動でアップデートが実施されると案内されています。
また、アップデートの有無にかかわらず起動に時間がかかる場合がある点も同様です。

※上記のようなOS操作に不安がある場合は、「ConoHaの標準テンプレート設定に戻す」「余計な変更を入れない」ほうが、長期的にトラブルが減ります。

更新後に確認すべきこと（接続・設定・Mod）

アップデート後は「起動したっぽい」で終わらせず、3分で終わる確認を入れると事故が減ります。
チェックは 接続 → 設定 → 拡張（Mod/Rust+） の順が最短です。

1) 接続（まずは生存確認）

IP指定で接続できるか（F1 → client.connect IP:PORT）
サーバー名検索で出るか（Community検索）
※検索は反映が遅れることがあるので、最初はIP接続の成否を優先
起動直後は「まだ準備中」で入れないことがある
→ 公式も起動に時間がかかる旨を明記しています

2) 設定（意図した値が残っているか）

更新で設定が勝手に消えるケースは多くありませんが、運用では“変更履歴のズレ”が起きがちです。

サーバー名／説明（想定どおりか）
マップ関連（worldsize、seed、マップタイプ）を変更しているなら再確認
※ConoHaの案内では systemd のサービス設定を編集して値を入れる形が示されています
PvE設定など、起動オプションを足している場合は再確認

3) Mod・Rust+（ここが“更新後に壊れやすい”）

Mod（uMod/Oxide 等）を使っている場合
- ゲーム本体アップデート → Modが追従していないことがある
- 症状：接続できるのに挙動がおかしい／エラーが増える／プラグインが動かない
- 対策：まずは「Modを一時的に外して素の状態で起動」→原因切り分け
Rust+（公式コンパニオン）を使っている場合
- ConoHaは 2024/4/25以降、Rust+で使う 28082・28083(TCP) を解放したテンプレート提供を開始し、標準セキュリティグループ利用者は自動で該当ポートが開く、と案内しています
それ以前に作成した環境などでは、ufw で許可設定の確認・追加が必要になる場合があります

ConoHa for GAME 公式サイト
ConoHa VPS 公式サイト

ゲーム設定を変更する（まず触る項目から順に）

ゲームルール系（PvP/PvE、最大人数、説明文など）

ConoHaのRustテンプレートでは、サーバー起動コマンド（systemdのサービス設定）に「起動オプション」を足し引きして挙動を変えるのが基本です。
ポイントはシンプルで、「編集 → 保存 → 再起動（または起動）」で反映します。

変更作業の“安全な型”（迷わない手順）

サーバーを停止

systemctl stop rust-server.service

サービス設定を開く（編集）

systemctl edit --full rust-server.service

ExecStart=... の行末に、目的のオプションを追加（または削除）
保存して閉じる（エディタ操作：Ctrl+O → Enter → Ctrl+X）
起動

systemctl start rust-server.service

※「起動したらすぐ入れる」とは限らず、更新や初期化で時間がかかることがあります。

PvP → PvE（プレイヤー同士の戦闘を無効化）

PvEにしたい場合は、ExecStart=... の末尾にこれを追加します。

追加するもの：+server.pve true

注意（初心者がつまずきやすい点）

PvEでも NPCや動物との戦闘は発生します（“完全平和”ではありません）。
PvPに戻すときは、追加した +server.pve true を削除して再起動します。

最大人数（maxplayers）

最大人数は、混雑を防ぐだけでなくサーバー負荷と直結します。まずは控えめに設定して、運用しながら上げるのが安全です。

追加するもの（例）：+server.maxplayers 10

運用のコツ

「最大人数＝いつもその人数が入る」ではないので、最初は実参加人数 + 少しくらいが安定しやすいです。
人数を欲張るほど、CPU/RAM不足によるカクつきが起きやすくなります。

サーバー名・説明文（検索・参加のしやすさに直結）

サーバー一覧で見える情報は、“入ってもらえるかどうか”を左右します。
最低限、サーバー名（hostname）と説明文（description）は整えておくのがおすすめです。

サーバー名：+server.hostname "〇〇サーバー"
説明文：+server.description "〇〇（ルール/方針/連絡先など）"

説明文に入れると親切な項目（テンプレ）

スクロールできます

入れる内容	目的	例
ルール（PvP/PvE）	ミスマッチ防止	PvE / PvP（週末のみPvP）など
参加対象	荒れ防止	身内・初心者歓迎・社会人向け
ボイス/連絡先	迷子防止	Discord招待（URLはserver.urlでも可）
ワイプ方針	トラブル予防	月例ワイプに合わせる／不定期など
時間帯	参加の目安	平日夜／土日中心など

ちょっとした注意

文章は長すぎると読まれません。まずは2〜3行で要点がベストです。
文字化けや表示崩れが起きたら、記号や改行を減らして短文に寄せると安定しやすいです。

マップ系（サイズ／シード／タイプ）

マップ系の変更は、ゲーム体験が大きく変わる一方で、「変更＝マップ再生成」が必要になりやすいです。
そのため基本は、次の考え方で整理すると失敗しにくいです。

seed（シード）：島の“形”を変える（同じサイズでも地形が変わる）
worldsize（サイズ）：島の“広さ”を変える（負荷・移動時間に直結）
level（タイプ）：マップの“種類”を変える（特殊マップ等）

変更前に知っておきたいこと（重要）

マップを変えると、既存の拠点や地形は基本的にリセットされます（実質ワイプ）。
マップ再生成で、プラン次第ではプレイ可能まで時間がかかることがあります。
→ 事前に「次回ログインは◯分後」と共有しておくと揉めにくいです。

変更の実務フロー（ConoHa流）

大枠はこうです。

サーバー停止
マップデータ削除（ワイプ）
rust-server.service の ExecStart=... で値を変更
起動 → マップ生成を待つ

worldsize（サイズ）の決め方：初心者向けの現実解

“広いほど楽しい”とは限りません。広いほど、

探索や移動が長くなる
メモリ・ディスク負荷が増える
人が少ないとスカスカに感じる

迷ったらこの目安

少人数（身内中心）：3000〜4000
人数が多め／探索重視：4000〜5000
かなり大人数：5000〜6000（負荷が跳ねやすいので余裕あるプラン前提）

seed（シード）の決め方：考えすぎなくてOK

seedは整数です。イベント用に「同じ島を再現したい」などがなければ、

適当な数字でOK（覚えやすい数字でも良い）
気に入らなければ、次回ワイプで変える

で十分です。

map type（タイプ）：ConoHaで案内される例

ConoHaの手順では、ExecStart=... の末尾に +server.level "タイプ名" を付けて変更します。
例：+server.level "Procedural Map"

この「タイプ名」は表記ゆれがあると起動しない原因になるので、入力は慎重に（コピペ推奨）です。

Rust＋（公式コンパニオン）連携のセットアップ

Rust+は、スマホアプリ（公式コンパニオン）から拠点のアラームや状態確認などができる機能です。
ただし、サーバー側でRust+用の通信（TCPポート）が通る必要があります。

まず確認：ポートが開いているか

Rust+は「TCPの専用ポート」に外部から到達できないと動きません。ConoHaのRustテンプレートでは、条件により対応が分かれます。

新しめのテンプレート + 標準のRust用セキュリティグループ
→ 追加設定なしでRust+用ポートが開いているケースがあります
古い時期に作成したテンプレート または 独自セキュリティグループ運用
→ ポート開放が必要になることがあります

ConoHaの案内では、ufw（OS側ファイアウォール）で状態を確認し、必要なら許可します。

確認：

ufw status verbose

許可（未設定なら）：

ufw allow 28082:28083/tcp

“実際に使っているRust+ポート”を確認する（ここが最重要）

Rust+のポートは、環境や設定で変わることがあります。
まずはサーバー側で app.info を実行し、現在のポートを見てください。

うまくいかないときほど、推測より app.infoの実測が強いです

もしポートを変える必要がある場合は、app.port を指定して再起動で反映します。
（Rust+は 10000以上のポートでないと到達できない条件があるので、変更するならそこも守ります。）

ペアリング時の注意（壊しやすいところ）

Rust+はサーバー側に companion.id という識別ファイルができ、これがRust+上での“サーバーの身分証”になります。

むやみに削除しない
他サーバーのものを流用しない
バックアップ/移行でも同一サーバーとして扱うなら丁寧に扱う

ここを雑に触ると、プレイヤー側が再ペアリング地獄になりがちです。

よくある失敗パターン（チェックだけ覚える）

✅ ポートは開けたのにRust+が「無効」扱い
→ app.info で「どのポートを使っているか」と「公開IPが正しいか」を確認
✅ 再起動を短時間に何度も繰り返して登録に失敗する
→ Rust+には短時間の試行回数に制限があるため、設定変更後は落ち着いて確認する

ConoHa for GAME 公式サイト
ConoHa VPS 公式サイト

ワイプ運用を設計する（マップ／ブループリント）

ワイプの種類と影響範囲

ワイプは「どこまで“最初から”に戻すか」を決める作業です。まずは用語を整理すると、迷いが激減します。

マップワイプ（Map Wipe）
新しいマップに切り替わり、拠点や設置物など“ワールド上の進行”がリセットされます。
ただし、ブループリント（BP）は残す運用も一般的です。
ブループリントワイプ（BP Wipe）
学習済みBP（研究・テックツリー進行を含む扱い）をリセットします。
“装備格差をゼロに寄せたい”ときに効きますが、反発も出やすいので頻度は慎重に。
フルワイプ（Full Wipe）
マップワイプ＋BPワイプをまとめて実施するイメージです。
初心者サーバーや身内サーバーでは、区切りを明確にできるメリットがあります。

運用設計の現実解（迷ったときの型）

まずは 「マップだけ定期」＋「BPは低頻度」 が揉めにくいです。
PC版Rustは、月例アップデートが一定の周期で行われるため、“月のどこかでマップ更新が必要になる”前提で計画すると破綻しにくいです。

実施前の準備（告知テンプレ／バックアップ方針）

ワイプ当日に慌てる原因は、だいたい「告知不足」と「戻せない削除」です。ここだけ先回りしておくと安定します。

1) 決めることチェックリスト

何ワイプ？（マップ／BP／フル）
実施日時（目安の停止時間も含める）
参加者への連絡手段（Discord固定メッセージなど）
ワイプ後の方針（PvE/PvP、最大人数、マップサイズ・シードを変えるか）

2) 告知テンプレ（コピペ用）

（見出しではないので絵文字OKです）

📅 実施日：YYYY/MM/DD（曜日） HH:MM〜
🧹 種類：マップワイプ（BPは保持）／BPワイプ／フルワイプ
⏱ 目安停止：〜XX分（※初回生成や更新で延びる可能性あり）
🗺 変更点：マップサイズXXXX、seed=XXXX、ルール（PvEなど）
🔗 再接続：client.connect IP:PORT（必要なら併記）
🆘 連絡先：Discord #support など

3) バックアップ方針（最低限）

⚠️ ワイプは“削除作業”なので、最小でも ワイプ直前に1世代残すのがおすすめです。

サーバー停止 → 対象フォルダを固めて退避（例：zip/tarで固める）
退避先は 同じフォルダ配下に置かない（削除に巻き込まれやすい）

マップワイプの実行手順

ConoHaのRustテンプレート（for GAME / VPS）での手順は、基本的にこの流れです。
※以下の <SERVERNAME> は、ConoHaの画面で確認できる「Rust Server name」に置き換えます。

Rustサーバーを停止

systemctl stop rust-server.service

（推奨）バックアップを作成
例：フォルダを固めて退避（コマンドは環境に合わせて）

# 例：バックアップ用ディレクトリに退避するイメージ
mkdir -p /opt/backup
tar -czf /opt/backup/rust_$(date +%Y%m%d_%H%M).tar.gz /opt/rust_server/server/<SERVERNAME>/

マップデータを削除（＝マップワイプ）

rm -f /opt/rust_server/server/<SERVERNAME>/{*.map,*.sav,*.sav.*}

この削除で「新しいマップ生成」が走ります。

Rustサーバーを起動

systemctl start rust-server.service

起動待ち（重要）
プランやタイミングによっては、プレイ可能になるまで時間がかかることがあります。
✅ やることは「待つ」＋「後述の復旧チェック」だけでOKです（再起動連打は逆効果になりがち）。

ブループリントワイプの実行手順

ConoHa公式の案内では、BPワイプは DBファイル（*.db）を削除する手順になっています。
初心者はまずこの公式手順をそのまま踏むのが安全です（迷って別ファイルを消すのが一番危険）。

Rustサーバーを停止

systemctl stop rust-server.service

（強く推奨）バックアップを作成
※BPワイプは影響が大きいので、必ず退避してから。
BPデータを削除（ConoHa手順）

rm -f /opt/rust_server/server/<SERVERNAME>/*.db

Rustサーバーを起動

systemctl start rust-server.service

注意点（ここだけは知っておいてください）

*.db は“BP関連だけ”に限らず、プレイヤー関連の状態を広めに消す可能性があります。
→ 「BPだけを厳密に消したい」などの高度な運用は、慣れてから“対象DBを絞る方式”に移行するのがおすすめです（最初は事故りやすい）。

ワイプ後にやる復旧チェック

ワイプ後は「起動したっぽい」で終わらせず、5分で終わる確認を入れるとトラブルが激減します。

1) 接続の生存確認

IP指定で入れるか（まずこれを優先）
サーバー検索に出るか（遅れることがあるので、補助扱い）

2) ワイプ内容が反映されたか

マップワイプ：拠点や地形が新しくなっている
BPワイプ：BP（研究・進行）がリセットされている

3) 設定が想定どおりか

サーバー名／説明文
PvE/PvP、最大人数
マップサイズ・seedを変えたなら、その値になっている

4) 追加要素（入れている人だけ）

Mod導入サーバー：プラグインが動いているか（更新直後は不整合が出やすい）
Rust+：連携が生きているか（ポートや識別ファイルまわり）

5) 失敗したときの戻し方（最低限）

停止 → バックアップを元の場所に戻す → 起動
（このためのバックアップです。焦って再インストールに走らないのがコツ）

ConoHa for GAME 公式サイト
ConoHa VPS 公式サイト

管理者権限とRCON（運営を“ゲーム内”から外へ出す）

管理者権限でできること／できないこと

Rustの運営は大きく分けて 「権限（誰が何できるか）」 と 「操作手段（ゲーム内／外部ツール）」 の2層です。
まずは権限の整理からいきます。

権限の種類（ざっくり）

Owner（管理者 / AuthLevel 2）：サーバーの全操作ができる
Moderator（モデレーター / AuthLevel 1）：荒らし対応など“運営補助”ができる
一般プレイヤー：通常プレイのみ

できること（代表例）

プレイヤー管理：キック／BAN／ミュート、BAN解除、プレイヤー一覧確認
運営通知：全体アナウンス（サーバーメッセージ）
運用操作：再起動（RCONからコマンド実行で）、ワイプ準備（バックアップ・設定変更）
調査：ログ確認、管理コマンドでの状況把握（人数、座標、状態など）
（Ownerのみ）強めの操作：テレポート、スポーン、時間・天候調整など

できないこと（誤解が多いポイント）

チートを“ゼロ”にする（アンチチートは別領域。運営は「検知→対処」が中心）
ラグを権限で解決する（根本はCPU/RAM/回線/設定）
消えたデータを魔法のように復元する（バックアップがなければ難しい）
Facepunch公式サーバーのような自動運用を“権限だけで”実現する（監視・自動化は別途設計が必要）

初心者向けの安全な運用ルール

自分：Owner（AuthLevel 2）
友だちに任せるなら：まず Moderator（AuthLevel 1） から
Ownerを複数人に配るのは、慣れてから（事故率が一気に上がります）

RCON接続に必要な情報と取得場所

RCONは「サーバーの遠隔コンソール」です。ゲーム内でF1を開く代わりに、外部から管理コマンドを叩けるようになります。

RCON接続に必要な3点（これだけ）

Server IP Address（グローバルIP）
RCON Port（通常 28016/TCP）
RCON Password（RCONパスワード）

ConoHaでの取得場所（迷わない導線）

ConoHaのRustテンプレートは、サーバーにログインすると「必要情報が表示される（motd）」形式になっています。
ここに Server IP Address / Rust Server name / Rcon Password がまとまって出るので、必ず控えます。

通信面の注意（詰まりポイント）

RCONは TCP です（ゲーム接続のUDPと別物）。
セキュリティグループを自分で作り替えている場合、RCONポートが閉じていて接続できないことがあります。

おすすめの守り方（最低限）

RCONパスワードは強く（16文字以上＋英大小＋数字＋記号）
RCONポートは「全世界に開ける」より、可能なら 接続元IPを自分の回線に限定
（ConoHaのセキュリティグループで“許可元IP”を絞れるなら、これが一番効きます）

RCON.IOでの基本操作（キック／BAN／アナウンス）

RCON.IOはブラウザで使えるRCONクライアントです。考え方はシンプルで、接続→プレイヤー管理→通知の順に覚えると迷いません。

1) 接続（初回だけやること）

RCON.IOを開く
新規接続（Add/Connect のような項目）を選ぶ
次を入力して接続
- Server IP Address
- RCON Port（例：28016）
- RCON Password

接続できない場合は、まずここを確認します。

ポートがTCPで開いているか
パスワードのコピペミス（末尾の空白が混ざるのがあるある）
サーバーが起動中か（停止中は当然つながりません）

2) キック（Kick）
目的：一時的に退出させる（警告→クールダウンに便利）

UIにKickボタンがある場合：プレイヤーを選択 → Kick → 理由
コマンドで行う場合（例）：

kick "プレイヤー名" "理由"

3) BAN（Ban）
目的：継続的に入れないようにする（荒らし対策の本命）

UIにBanボタンがある場合：プレイヤーを選択 → Ban → 理由
コマンドで行う場合（例）：

banid 7656119xxxxxxxxxx "理由"

※初心者は「名前」より SteamID（Steam64ID）でBAN のほうが安全です（改名されてもブレにくい）。

4) アナウンス（全体メッセージ）
目的：再起動予告、ルール告知、ワイプ案内など

UIにSay/Announceがある場合：テキスト入力 → 送信
コマンドで行う場合（例）：

say "5分後に再起動します。安全な場所に移動してください。"

運営で効く“定番アナウンス”テンプレ

再起動：10分前 / 5分前 / 1分前 の3回
ワイプ：日時・種類（マップ/BP）・再接続方法（IP:PORT）

Rust Manager等の管理ツールでできること

「RCONは分かった。でも毎回ブラウザで打つのは面倒」になったら、専用ツールが効きます。
Rust Managerや類似ツールは、RCON情報を登録して “運営の定型作業をボタン化” するイメージです。

Rust Manager系でよくできること

サーバーを複数登録して切り替え（身内鯖＋検証鯖など）
プレイヤー一覧・チャット監視
Kick/Ban/Mute、BANリスト管理
よく使うコマンドのショートカット化（定型アナウンス等）
ログの閲覧（ツールによって範囲は差あり）

接続に必要なもの（RCONと同じ）

IPアドレス
RCONポート
RCONパスワード

初心者が“管理ツール導入で失敗しない”コツ

まずはRCON.IOなどで「RCON接続そのもの」が成功するか確認
→ 成功したら、管理ツールに移す（原因切り分けがラク）
いきなり多機能に頼らない
→ 最初の目的は「Kick/Ban/アナウンスの高速化」で十分です
ツールにRCONパスワードを保存するなら、PC側のセキュリティも意識
（共有PCでは使わない、ログイン保護、バックアップの扱いなど）

ConoHa for GAME 公式サイト
ConoHa VPS 公式サイト

MOD・プラグイン運用（導入より“維持”が重要）

前提：Modded運用のリスクと注意点

RustのMod（uMod/Oxide系）運用は、便利になる反面「壊れる前提」で設計しないと、ある日いきなり詰みます。初心者ほど “導入”より“維持” を先に考えるのが安全です。

よくあるリスク（最初に知っておくと損しない）

アップデート後にプラグインが動かなくなる（ゲーム本体＞Mod＞プラグインの順で追従が必要）
原因切り分けが難しくなる（“接続できない”がMod原因かサーバー原因か混ざる）
サーバー負荷が増える（プラグイン数・処理内容次第でCPU/RAMに効く）
セキュリティ面の穴が増える（不明な配布元のプラグイン、過剰権限など）

初心者向けの現実的な運用ルール（おすすめ）

まずは バニラ設定で目的を達成できないか を確認（PvE化・最大人数・説明文など）
入れるプラグインは 目的が明確なものだけ（“便利そう”で増やすと壊れやすい）
変更前に必ず バックアップを1世代（ワイプより頻繁に役立つ）
“本番”とは別に、可能なら テスト用サーバー（または短時間の検証枠）を用意

Oxide/uMod系の導入方針（入れるべき場合だけ）

まず判断：Modを入れるべきケース

uMod（旧称Oxide系）を検討してよいのは、例えば次のようなときです。

身内鯖で パスワード制・ホワイトリスト などを強化したい
管理を楽にしたい（自動告知、便利コマンド、権限管理の拡張）
PvE専用の体験に寄せたい（バニラの範囲だけだと物足りない）
イベント運営（テレポートや運営補助機能が必要）

逆に、次の目的なら Modなし のほうが安定しやすいです。

ただ友だちと遊ぶ／小規模運用
“止めたくない”を最優先したい
初めてのサーバー運用で、まず成功体験を積みたい

導入ポリシー（ConoHa運用で失敗しない考え方）

ConoHaのテンプレートは「起動時に更新が走る」など、最初から運用の型が用意されています。
Mod導入でこの型を崩すと、更新や復旧が面倒になりがちです。

おすすめ方針

できるだけ 公式に近い手順（= uModの標準構成） で入れる
“便利な一括スクリプト”は、仕組みが見えにくいので初心者は慎重に
（使うなら、何を変更するスクリプトなのかを把握してから）

導入前にやること（最低限）

サーバー停止
現状のディレクトリを丸ごとバックアップ（戻せる状態を作る）
変更点をメモ（「いつ／何を／なぜ」）

プラグイン追加・更新・削除の手順

uMod運用が始まったら、作業はほぼ “ファイル管理＋再読み込み” です。
覚える場所は3つだけでOKです。

oxide/plugins/：プラグイン本体（多くは .cs）
oxide/config/：設定ファイル
oxide/data/：データ保存（BAN補助・実績・経済などプラグイン次第）

追加（新しいプラグインを入れる）

サーバーを停止（安全第一。慣れるまでは停止推奨）
プラグイン（.cs）を oxide/plugins/ にアップロード
サーバーを起動
プラグインが動作しているか確認（ログ、ゲーム内挙動）

コツ

いきなり複数入れない（1つずつ入れて確認）
プラグイン説明に「依存プラグイン」がある場合は先に入れる

更新（プラグインを新バージョンにする）

旧ファイルをバックアップ（念のため別名で退避）
新しい .cs で上書き
再起動、またはRCONで再読み込み（可能な場合）

“更新後に壊れた”の保険

上書き前の退避があると、元に戻すのが一瞬です

削除（不要になったプラグインを外す）

まずは 無効化（いきなり削除しない）
- .cs を別フォルダに移動（例：oxide/disabled_plugins/ を作って退避）
起動して問題がないか確認
問題なければ、最終的に削除（必要なら config/ や data/ も整理）

注意

プラグインによっては、データや設定が残っていると再導入時に影響することがあります
→ 迷ったら “config/dataは残す” でOK（復旧優先）

相性問題の切り分け（更新後に壊れた時の戻し方）

「アップデート後に急におかしい」は、Mod運用では定番です。
焦って全部いじるより、切り分けの型 を持っていると最短で復旧できます。

まずやる3ステップ（最短ルート）

バニラで起動できるか（プラグイン全停止の状態を作る）
uMod自体が最新か（Rust更新直後はuMod側の追従待ちが起きる）
プラグインを1つずつ戻す（犯人探し）

“プラグイン全停止”の現実的なやり方

oxide/plugins/ の中身を一時退避（フォルダごと別名にするのが早い）
起動して、接続・基本動作が安定するか確認
- 安定する → プラグインの問題が濃厚
- 安定しない → サーバー設定／ポート／更新処理など別要因を疑う

犯人探しの手順（迷わない）

1個ずつ戻す（確実だが時間がかかる）
ある程度数が多いなら「半分ずつ戻す（二分探索）」
→ “壊れる側のグループ”を絞り込んでいく

直し方の優先順位（戻すのが早い順）

プラグインを最新版にする
それでもダメなら、一つ前の版に戻す（退避しておいた旧ファイルが役立つ）
uModの再導入・更新（Rust更新後にuMod側が追従していない／壊れている場合）
最終手段：バックアップから復元（時間を溶かさないための保険）

“壊れにくい運用”に寄せるコツ

重要プラグインは「更新タイミング」を固定（Rust大型更新直後は様子を見る）
プラグイン一覧をスプレッドシート等で管理
- 名前／目的／導入日／最終更新日／配布元／依存関係
“無くても遊べる”構成を目指す（運営が楽になります）🙂

ConoHa for GAME 公式サイト
ConoHa VPS 公式サイト

バックアップ／復元／移行（事故っても詰まない）

守る対象の整理（設定／マップ／プレイヤーデータ）

Rustサーバーの“守るべきもの”は、ざっくり3カテゴリです。まずここを分けると、バックアップ設計が一気にラクになります。

1) 設定（運用の土台）

サーバー起動オプション（PvE、最大人数、hostname、description、マップ設定など）
セキュリティグループ設定（ゲーム用ポート、RCON、Rust+、SSH）
秘密情報：RCONパスワード、サーバーパスワード、管理者の権限設定

2) マップ（ワールドの状態）

拠点・建築・配置物
地形（seed / worldsize / map type に紐づく）
マップ・セーブ系ファイル（例：.map / .sav）

3) プレイヤーデータ（“戻すと揉める”領域）

BP（研究進行）
所持品・ステータス
BANリスト・権限（運営系）

ここで大事なのは、「どれを戻したいか」で最適なバックアップが変わることです。

バックアップ方式は2段構えが安心

スクロールできます

方式	何を守れる？	強み	弱み
サーバー丸ごと（自動バックアップ／イメージ保存）	OS・設定・Rustデータ全部	事故復旧が速い／取りこぼしが少ない	有料オプションや容量制限が絡むことがある
Rustデータだけ（ファイル退避）	マップ・プレイヤー・プラグイン設定等	軽い／移行しやすい	取り忘れると詰む（チェックリスト必須）

初心者のおすすめ

まずは 丸ごとバックアップを“保険”として有効化
その上で、重要なタイミングだけ Rustデータをファイルで退避
この2段構えだと、どの事故にも強いです ✅

まず確認：Rustのデータ場所は「motd」を基準にする

ConoHaのRustイメージは、ログイン時に表示される motd に
Rust Server Directory（インストール／データの基点） が出ます。

このディレクトリを起点にバックアップ対象を決める
パスを決め打ちしない（テンプレート差分でズレる事故を避ける）

バックアップ頻度の決め方

バックアップは“毎日やれば安心”ではなく、何が起きたら困るかで頻度を決めるのが合理的です。

まずは「どの事故が怖いか」で決める

設定ミス（PvE化、ポート、RCONなど）が怖い
→ 設定変更の前後でバックアップ
荒らし／BAN事故／権限事故が怖い
→ 週1〜隔週＋大きい変更前後
ワイプ前提で遊んでる（失ってもOK）
→ 最低限（ワイプ前だけ）でも回る

現実的なおすすめ頻度（初心者向け）

A. ConoHaの自動バックアップ（丸ごと）

週1取得・最大3世代のように「最低限の保険」として有効化しておく
（“自分で何もしなくても戻せる”のが強い）

B. ファイルバックアップ（Rustデータだけ）

設定変更の前（PvE/PvP、マップ変更、Rust+設定、RCON設定）
ワイプの前
大きいアップデートの前後（Modded運用なら特に）
平常運転なら週1（身内鯖ならこれで十分なことが多い）

バックアップの“取り方”のコツ（壊れにくい）

可能なら サーバー停止してから 取る
（動作中に取ると、セーブ途中の不整合が混ざりやすい）
退避先は 同じフォルダ配下に置かない
（ワイプや整理で巻き込みやすい）
ファイル名に 日時を入れる
例：rust_backup_20260213_2350.tar.gz

復元手順（最短で復旧するチェックリスト）

復元は「最短で復旧 → 原因調査は後」が基本です。焦っていじるほど長引きます。

0) まずは状況分類（1分）

サーバー自体が壊れた／ログインできない／設定がぐちゃぐちゃ
→ 「丸ごと復元」が最短（自動バックアップ or 保存イメージ）
Rustのワールドだけ戻したい（設定は無事）
→ 「ファイル復元」が速い
別サーバーへ移行したい（プラン変更・乗り換え）
→ 「ファイル移行」または「保存イメージで再構築」

1) 丸ごと復元（いちばん詰みにくい）

A. 自動バックアップからの復元

コントロールパネルで対象サーバー → 自動バックアップ → 復元（リストア）
世代を選べる場合は「事故直前」より少し前を選ぶのが安全なことがあります

B. 保存イメージ（スナップショット）から再構築

事前にイメージ保存していれば、停止状態で「保存イメージから再構築」が可能
大きい事故ほど、この方法が最短で戻ります

復元後にまず見るもの ✅

motdの Server IP Address / Rust Server Directory / Rust Server name / Rcon Password
セキュリティグループ（ポートが戻っているか）
Rustの接続（IP:PORTで入れるか）

2) ファイル復元（Rustデータだけ戻す）

最短手順（チェックリスト）

サーバー停止
いまのデータを退避（念のため）
バックアップを元の場所へ戻す
起動
接続テスト（IP指定） → 設定確認 → 追加要素確認（Mod/Rust+）

作業イメージ（例：tarで戻す）

systemctl stop rust-server.service

# いまの状態を退避（念のため）
mv <Rustデータのフォルダ> <Rustデータのフォルダ>_broken_$(date +%Y%m%d_%H%M)

# バックアップを展開して戻す（例）
mkdir -p <Rustデータのフォルダ>
tar -xzf /path/to/rust_backup_YYYYMMDD_HHMM.tar.gz -C /

systemctl start rust-server.service

復元後の“つまずきポイント”

IPが変わった（再作成・移行時）
→ 友だちに共有している client.connect を更新
Rust+が効かない
→ Rust+用ポート（TCP 28082–28083）と設定の再確認
Moddedが壊れる
→ まずプラグインを全部止めてバニラで起動できるか確認（原因切り分け）

3) 移行（別サーバーへ引っ越し）を失敗しないコツ

移行は「復元＋差分対応」です。初心者はこの順でやると事故りにくいです。

同じテンプレート構成の新サーバーを用意
新サーバーのmotdで Rust Server Directory を確認
旧サーバーのRustデータをバックアップ → 新サーバーへ転送 → 展開
仕上げに、セキュリティグループ・Rust+・RCONだけ再確認

移行でよくある落とし穴

プラン変更で性能が下がる（CPU/RAM不足でカクつく）
ポート設定が移行先で開いていない（RCONやRust+が死ぬ）
“バックアップしたつもり”で重要フォルダを入れ忘れる（plugins/config/dataなど）

ConoHa for GAME 公式サイト
ConoHa VPS 公式サイト

パフォーマンス最適化（ラグ対策の実践）

監視すべき指標（CPU・メモリ・ディスク・ネットワーク）

ラグ対策は、体感だけで当てに行くと遠回りになりがちです。まずは「どこが詰まっているか」を数字で掴むのが最短です。

Rust側（ゲーム内／RCONで確認できる“体感に直結”指標）

サーバーFPS（Server FPS）
低下すると、入力遅延やカクつきとして出やすいです。
- 画面表示：perf 1〜6（数字を上げるほど情報が増えます）
Ping（遅延）
サーバー処理が重いのか、通信が不安定なのかの切り分けに使います。
- 画面表示：perf 4 以上でPingまで表示されます（構成による）

コツ：「サーバーFPSが落ちている」＝サーバー内の処理が詰まり気味、
「Pingが高い」＝回線や経路の要素も疑う、という感じで見ます。

OS側（ConoHa上のLinuxで確認する“原因の特定”指標）

以下は “見る順番” も含めた定番セットです。

CPU
- 見るもの：CPU使用率、Load Average、iowait（I/O待ち）
- 目安：常時高止まり＋Server FPS低下なら、CPUがボトルネックの可能性が濃厚
- 例コマンド：top / htop / uptime
メモリ
- 見るもの：空きメモリ、キャッシュ、swap（スワップ）使用量
- 重要：swapが動き始めると“周期的なカクつき”が出やすいです
- 例コマンド：free -h / vmstat 1
ディスク
- 見るもの：空き容量、書き込み頻度、I/O待ち（iowait）
- 重要：空きが少ないと、保存やログ出力が詰まって体感悪化につながります
- 例コマンド：df -h / du -sh <Rustディレクトリ> / iostat -x 1
ネットワーク
- 見るもの：Ping、パケットロス、帯域の詰まり
- 例コマンド：ping / mtr（入っていれば）/ ss -tulpn

まずはこの“観測テンプレ”だけでOK（初心者向け）

ラグを感じたら
1. perf 4（サーバーFPS＋Ping）
2. top（CPU）
3. free -h（メモリ／swap）
4. df -h（ディスク空き）
  これで 「サーバーが重いのか／OSが苦しいのか／回線っぽいのか」 がだいぶ絞れます。

よく効く改善策（人数制限／設定調整／プラン変更）

ここは“効きが強い順”に並べます。1つずつ試して、観測（上の指標）で差分を見るのが失敗しにくいです。

人数制限（いちばん確実で副作用が少ない）

最大人数（maxplayers）を現実に合わせる
- 例：身内で5人なのに20人上限にしている、などは無駄が出やすいです
もし「人数は増やしたい」なら
- 次の“設定調整”や“プラン変更”とセットで考えるのが安全です

設定調整（効くが、やりすぎ注意）

1) マップの重さを下げる（効果：大／副作用：中）

ワールドサイズを大きくしすぎない
- マップが大きいほど、生成・保存・AI・建築物などが重くなりがちです
カスタムマップは、導入すると負荷が増えるケースもあるので慎重に

2) サーバーFPS上限を不必要に上げない（効果：中／副作用：小）

サーバーFPSの上限を高くしすぎると、CPUを余計に使って逆に不安定になりやすいです
変更するなら「少しずつ」「必ず戻せる状態で」がおすすめ
- 例：sv fps.limit <値>（管理者権限で実行）

3) 再起動の“運用”で安定させる（効果：中／副作用：小）

長時間稼働で徐々に重くなるタイプの不調には、定期再起動が効くことがあります
ただし「再起動＝万能」ではないので、まずは原因の方向性（CPU/メモリ/ディスク）を見てから

プラン変更（根本解決になりやすい）

ConoHaのRustテンプレートは、最低動作ラインよりも “余裕を持ったメモリ” が体感に直結しやすいです。

症状 → プラン変更が刺さりやすいパターン
- swapが使われている（free -h でSwap増）→ メモリ増強が最優先
- CPU常時高止まり＋Server FPS低下 → 上位プラン（CPU性能が上がる帯）検討
- 保存タイミングでガクッと止まる → ディスクI/O（iowait） と合わせてプラン見直し

判断のコツ：
“設定をいじって改善しない” ときは、だいたい リソース不足（CPU/RAM/ディスク） が本丸です。

重くなる原因の典型（Mod過多／ログ肥大／保存頻度）

「よくある地雷」を先に知っておくと、最初から“重くしない設計”にできます。

Mod過多（いちばん起きやすい）

プラグインが多いほど、CPU・メモリ・保存（ディスク）に負担
“便利系”でも、内部で定期処理が走るものは積み上がって効いてきます

軽く保つコツ

プラグインは 目的ごとに最小限
導入・更新は 1つずつ（不調時の犯人捜しが爆速になります）
「保存時に重い」なら、プラグインのdata/config肥大も疑う

ログ肥大（気づいたら詰むタイプ）

ログが増えると、ディスク圧迫だけでなく、ログ書き込み自体がボトルネックになることがあります。

まず確認
- df -h（空き容量）
- du -sh <ログっぽい場所>（どこが太っているか）
- journalctl --disk-usage（systemdログが膨れていないか）

対策の考え方

“消す”より先に 退避・ローテーション（安全第一）
Rust本体ログ／プラグインログ／OSログを分けて考える

保存頻度（短すぎるとカクつきの原因に）

保存は安心材料ですが、頻繁すぎると 書き込みが増えて引っかかりが出やすくなります
ただし、間隔を空けすぎると クラッシュ時の巻き戻りが増えるのでトレードオフです

運用でのおすすめ

体感で「保存っぽいタイミングで止まる」なら
- ディスク（iowait）と空き容量を確認
- そのうえで、保存間隔や周辺設定を“少しだけ”見直す
変更前には、必ずバックアップ（復元できる状態が最強）✅

ConoHa for GAME 公式サイト
ConoHa VPS 公式サイト

コスト最適化（料金で損しない運用）

短期・週末だけ運用する場合の考え方

週末だけ・イベントだけのRust運用は、「時間課金で作って、終わったら“停止”ではなく“削除”」 がコツです。
（ConoHaは“シャットダウンしても料金が変わらない”前提のため、止めるだけでは節約になりにくいです）

まず押さえる：料金はこの3点で決まる

プラン（メモリ/CPU）
料金タイプ（時間課金 or 長期割引パス）
有料オプション（自動バックアップ/追加ストレージ/イメージ保存など）

週末運用のおすすめ手順（最小コスト設計）

時間課金でサーバー作成（遊ぶ直前〜前日に用意）
友だちに共有する情報を固定化
- サーバー名（検索用）
- IP:PORT（直指定用）
- パスワード（必要なら）
遊び終わったら サーバーを削除（ここが重要）🧹
- 「停止（シャットダウン）」では、料金が止まらない設計なので要注意

“消すのが不安”な人向け：消す前の保険の作り方

軽い運用（身内でワイプ前提）なら、割り切って削除が一番安いです
“状態を残したい”なら次のどちらか
- イメージ保存：任意のタイミングで保存して、後から同じ状態に近い復旧を狙う
- 自動バックアップ：週1回の自動取得（最大3世代）で「事故復旧」寄りに強い

迷ったら：
週末だけ＝削除前提（最安）
長く遊ぶ＝長期割引パス（単価を下げる）
“戻せないのが怖い”＝バックアップ系オプション（保険料として払う）

長期運用での最適化（停止・再開・更新のルール化）

長期は「安くする」より “ムダを出さない” が効きます。ポイントは 更新・見直しのタイミングを決めて機械的に回すこと です。

1) 料金タイプの選び方（結論）

2週間以内が目安：時間課金
2週間以上が目安：長期割引パス（まとめ買いで割引、前払い）

さらに、時間課金で運用開始していても、途中から 長期割引パスを適用できます。
「この先も遊びそう」と分かった時点で切り替えるのが損しにくいです。

2) “停止・再開”をルール化する（節約の肝）

ConoHaは 停止（シャットダウン）しても料金は変わらない ので、長期運用で「しばらく遊ばない」が発生するなら、運用ルールはこうなります。

短い休止（数日〜）：そのまま維持（データ優先）
休止が長い（数週間〜）：
- A案：削除して課金を止める（最安）
- B案：イメージ保存だけ残して削除（“再開の手間”と“保険料”のバランス）

3) “更新”を事故らないための運用テンプレ

長期割引パスは、放置が一番怖いです（自動更新が絡むため）。

月1回（おすすめ：月初）に見るもの
- 長期割引パスの残日数
- 自動更新がON/OFFどっちか
- 有料オプションが増えていないか
もし「この期間で終わり」にしたいなら
- 契約満了日の7日前までに自動更新をOFF
- 必要なら「サーバー削除予約」も使う（満了後に消して課金を止める）

見落としがちな課金ポイントと対策

「サーバー代だけ見てたら、オプションと更新で想定より上がった」が典型です。ここだけ押さえると損が減ります。

よくある“課金の落とし穴”チェックリスト ✅

停止しても安くならない
- 対策：遊ばないなら削除（課金を止める行動は“削除”）
長期割引パスの自動更新がデフォルトON
- 対策：終わりが見えたら早めに OFF（満了7日前ルール）
バックアップ系オプションが“保険料”として乗る
- 自動バックアップは月額/時間単位料金がある
- イメージ保存は「50GBまで無料」でも、増えると追加容量が課金対象
- 対策：
  - 週末運用なら「そもそも付けない」
  - 長期運用なら「どれを守りたいか」を決めて最小構成にする
ストレージ追加は強力だけど高め
- 対策：ログ肥大や不要データを先に整理して、追加は最後の手段に
支払い方法の手数料
- 一部の支払い方法は手数料がかかる
- 対策：メイン決済を固定し、余計な手数料が出ない形に寄せる
通信量課金は基本なし（ただし運用ミスは別）
- 対策：課金よりも「ポート開放ミスで攻撃を受ける」ほうが事故りやすいので、セキュリティ側を優先

すぐ使える“コスト点検”ミニ表

スクロールできます

点検タイミング	見る項目	目的
作成直後	料金タイプ・プラン	目的に対して過剰に払ってないか
週末運用の終了時	削除できているか	「消し忘れ」をゼロにする
月初	自動更新ON/OFF・オプション	固定費の増殖を止める
アップデート/ワイプ前	バックアップ要否	“保険料”を必要な時だけ払う

ConoHa for GAME 公式サイト
ConoHa VPS 公式サイト

よくある質問（検索されがちな悩みを先に潰す）

友達が入れない／見つけられない

まずは「見つからない」と「入れない」を分けると、解決が早いです。

A. サーバー自体が一覧に出ない（見つからない）とき

PC版（Steam）か確認
ConoHaのRustテンプレートは基本的にPC版向けです。友達がConsole Editionだと合流できません。
サーバーが起動し切っているか
初回はマップ生成・更新で時間がかかり、一覧に出るまで待ちが発生します。
ConoHa側で「起動中」でも、Rust側が準備中のことがあります。
セキュリティグループがRust用になっているか
ConoHa for GAMEなら、標準のRust用セキュリティグループが付いているか確認。
自前のルールにしている場合は、Rustが使うポートが塞がれていると一覧に出ません（次の「入れない」側のポートも参照）。
反映待ちを挟む
サーバー名変更直後・再起動直後は、サーバー一覧の反映にタイムラグが出ることがあります。
この場合は「直指定接続」を先に試すのが確実です。

B. 一覧には出る／見つかるが、接続できない（入れない）とき

直指定接続で確認（最優先） ✅
RustのF1コンソールで、次の形式で接続します。
- client.connect <グローバルIP>:<ポート>
- 例：client.connect 203.0.113.10:28015
  ※ポートを変更していないなら、まずは 28015 から試すのが無難です。
ConoHaのRust用ポートが許可されているか
ConoHa for GAMEのRustでは、Rust用の複数ポートが利用されます。
標準セキュリティグループなら基本は揃っていますが、独自ルールの場合は不足しがちです。
「友達だけ入れない」なら回線側も疑う
同じIP:PORTで、あなたは入れるのに友達が入れない場合：
- 友達が別回線（テザリング等）で試す
- VPNのON/OFFを変えてみる
- 企業・学校回線だとUDPが厳しいことがあります

迷ったら：「直指定で入れるか」→「ポート」→「回線」の順に潰すと最短です。

サーバー名を変えたい

Rustの“サーバー名”は、主に server.hostname を変更します。ConoHaのテンプレート運用なら、初心者は「systemdの起動オプションを編集」が分かりやすいです。

手順の全体像（テンプレ運用の定番）

サーバーへrootでログイン
設定ファイルを開く
- systemctl edit --full rust-server.service
ExecStart=... の行にある以下を探して変更
- +server.hostname "..."（サーバー名）
- 必要なら +server.description "..."（説明文）
保存 → 再起動

反映されないときのコツ

サーバー一覧への反映は遅れることがあります。
先に 直指定接続（client.connect） で入れるか確認すると、切り分けが速いです。
文字化けが怖い場合は、まず 英数字中心でテストしてから日本語を試すと安全です。

PvE専用にしたい／ルールを固定したい

PvE化の基本は、起動オプションで server.pve を有効にすることです。ConoHaのRustテンプレートでも、PvE手順が案内されています。

PvEにしたときの注意点（初心者が誤解しやすい）

PvEでも NPC・動物との戦闘は発生します（完全な平和世界ではありません）。
PvEは「プレイヤー間の戦闘を避けたい」には有効ですが、
「荒らしをゼロにしたい」「細かい禁止行為をシステムで縛りたい」までやるなら、Mod/プラグイン（Modded運用）の検討が必要です。

“ルール固定”で最初に触る順番（失敗しにくい）

人数：server.maxplayers（身内の実人数に合わせる）
PvE：server.pve
説明文：server.description（ルール概要・Discord等の連絡先）
パスワード：身内限定なら設定（公開不要ならこれが一番効きます）

ルールを増やすほど運用負荷が上がります。最初は 「PvE＋人数＋パスワード＋説明文」 くらいがちょうどいいです。

ワイプのおすすめ頻度は？

ワイプは「正解の頻度」より、何を楽しみたいかで決めるのが失敗しません。

まず押さえる前提

Rustには、月次アップデートに合わせた“第1木曜”を基準にした運用が広く知られています（コミュニティサーバーもここに合わせることが多いです）。

初心者（身内サーバー）におすすめの目安

マップワイプ：月1（まずはこれ）
飽きにくく、運用も簡単。月次アップデートのタイミングにも合わせやすいです。
BPワイプ：2〜3ヶ月に1回、または「マンネリを感じたら」
BPまで毎回消すと、社会人勢・ライト勢はしんどくなりやすいです。

頻度を上げたほうがいいサイン

拠点だらけで探索が面白くない
新規参加者が追いつけず定着しない
データ肥大や不調が増え、運用的にも一度リセットしたい

管理者コマンドが効かない

「コマンドが効かない」は、ほとんどが 権限不足か 実行場所の間違いです。

まず確認する3点

自分が管理者登録されているか（owner/moderator）
RCONの接続情報が正しいか（IP・RCONポート・パスワード）
ポートが塞がっていないか（特にRCONはTCP）

最短の直し方（権限を付ける）

RCON（例：RCON.IOやFacepunchのWebRCON等）でサーバーに接続
次を実行（Steam64IDが必要）
- ownerid <Steam64ID> "<name>"
- server.writecfg（設定を書き出して保持）

※一時的に試すだけなら moderatorid でもOKですが、運営するなら owner が分かりやすいです。

“効いてるはずなのに反応がない”ときの典型

RustのF1コンソールで、クライアント向けコマンドを叩いている（＝サーバーに届いていない）
そもそも接続している先が違う（別サーバー・別ポート）
サーバー再起動で権限が保存されていない（server.writecfg をしていない）

コツ：最初は RCONから操作すると、成功/失敗が分かりやすく、運営が安定します。

ConoHa for GAME 公式サイト
ConoHa VPS 公式サイト

公式情報・参考（信頼性の担保）

ConoHa公式サポート（作成／接続／更新／設定／ワイプ）

ConoHa運用で迷ったら、まずは「公式サポート（手順書）」を基準にすると事故が減ります。特にRustは、テンプレートの仕様（起動・更新・表示される情報）が前提になるため、個人ブログより先に公式を確認するのが安全です。

作成：テンプレート（Rust）からの作成手順、注意事項（利用できるプラン条件など）
接続：サーバーIPの確認、ログイン時に表示される情報（motd）の読み方
更新：再起動時の自動更新、アップデート前にやるべきこと（バックアップなど）
設定：サービス設定の編集（VPS運用時のsystemd編集など）、最低限の運用手順
ワイプ：マップ／BPの削除でワイプする手順（テンプレのファイル配置前提で案内される）

「ConoHa for GAME」と「ConoHa VPS」では案内ページが別なので、あなたの契約側のサポートをブックマークしておくと迷子になりません。

ConoHa公式ドキュメント（ポート／セキュリティグループ等）

次に見るべきなのが「公式ドキュメント（仕様・要件）」です。特に、接続不良やRust+、RCONの詰まりは ポート・プロトコル・セキュリティグループ に集約されがちです。

Rustが使うポート一覧（TCP/UDPの区別）
「ゲームに入れる／入れない」「RCONだけつながらない」などの切り分けに必須です。
セキュリティグループの既定ルール（Rust向け）
自分でルールを作り替えた場合、必要ポートが欠けていると症状が出ます。
Minimum RAM、更新方法（再起動で最新化など）
“動く最低ライン”と“快適ライン”の判断材料になります。

ポイントは、個別記事の「たぶんこのポート」ではなく、ドキュメントにある 公式の利用ポート を基準に設計することです。

Rust公式・Wiki（仕様変更の追跡）

Rustはアップデート頻度が高く、運用の正解が変わります。運営側としては、次を押さえるだけでも「突然うまくいかなくなる」確率が下がります。

公式ニュース（Facepunch）
アップデートの方針（いつ更新されるか、ワイプの扱いなど）を把握するのに向きます。
公式Wiki（Facepunch Rust Wiki）
サーバー設定の基本、ワイプスケジュール設定、Rust+（コンパニオン）連携など、運用で参照頻度が高い情報がまとまっています。

特に「ワイプ周期」と「Rust+連携」は、周辺仕様が動くことがあるので、困ったときほど公式Wikiの該当ページを先に確認するのが近道です。

ConoHa for GAME 公式サイト
ConoHa VPS 公式サイト

まとめ

Rust×ConoHaでサーバー運営を成功させるコツは、テクニックよりも「最初の設計」と「運用の型」です。ポイントを最後に整理します。

まず、迷いやすい for GAME と VPS の選び方はシンプルです。
「最短で立てて、余計な作業を増やしたくない」なら ConoHa for GAME。
「細かくチューニングしたい／管理や拡張を自分の裁量で作り込みたい」なら VPS運用が向きます。最初から完璧に選ぶ必要はなく、運用しながら「必要になったら移行できる」設計にしておくと、長期的に無駄が減ります。

次に、初心者が一番つまずく 接続トラブル（表示されない／入れない）は、
「起動状態 → 初回生成中 → ポート許可」の順で切り分ければ、ほとんど解消できます。特に、サーバー検索に出ないときほど、まずは IP:ポートの直指定で“サーバーが生きているか”を確認するのが最短ルートです。

運営面では、設定変更（PvE・人数・マップ）は“触るほど難しくなる”部分でもあります。だからこそ、最初は「目的がはっきりしている項目から順に」変更し、毎回 変更→再起動→接続確認のワンセットを徹底すると事故が減ります。管理を外に出すなら、RCONを使い、権限を配りすぎないことが安定運用の近道です。

そして、止めない運用の要は アップデートとワイプ、バックアップです。
アップデート後は「接続・設定・（導入している場合は）Mod/Rust+」のチェックをセットにして、ワイプ前は必ず“戻せるバックアップ”を作る。これだけで「詰んだ」状態の多くは回避できます。

最後に、コスト最適化は「安いプランを選ぶ」より、課金が止まる行動を理解することが重要です。週末だけ遊ぶなら“停止”ではなく“削除”が基本。長期なら、更新ルールやオプション（バックアップ等）を棚卸しして“固定費の増殖”を防ぐのが効きます。

もしこの先、あなたがやるべきことを最短で並べるなら次の順番です。