7 Days to Die×ConoHa完全ガイド｜for GAMEとVPSの違い／作成→参加→安定運用までロードマップ

「7 Days to Dieをマルチで遊びたい。でも、サーバーって難しそう…」
そう感じて、ConoHaを調べ始めた人は多いはずです。

とはいえ、実際に調べるほど迷いが増えませんか？

「ConoHa for GAMEとConoHa VPS、結局どっちが正解なの？」
「最短で立てて、今日このあと友達と遊べる？」
「IPとかポートとか、友達に何を伝えればいい？」
「設定やMODってどこまでできる？ 途中からVPSに乗り換えても大丈夫？」
「アップデートのたびにバージョン不一致で入れなくなるって本当？」
「重い・落ちるって聞くけど、人数や設定の目安は？」
「停止と削除の違いが不安。課金で損したくない…」

このページでは、そんな悩みを「作成 → 参加 → 安定運用」まで一本道で解消します。
結論から言うと、ConoHaで7 Days to Dieサーバーを立てる方法は大きく分けて次の考え方です。

• for GAME：最短で遊ぶ（テンプレ中心。迷いにくい）
• VPS：自由度と運用力を取る（MOD・保守・更新のコントロールがしやすい）

記事の中では、どちらが優れているかではなく、あなたの遊び方（人数・MOD・更新頻度・作業量・コスト）に対して最適な選び方を整理します。さらに、

• 友達が迷わない「参加情報の渡し方」
• 落ちにくくする「基本設定の考え方」
• つまずきやすい「アップデート／バージョン不一致の対処」
• いざという時に戻せる「バックアップ運用テンプレ」

まで、初心者でも再現できる形でまとめました。

「とりあえず建てて終わり」ではなく、“遊び続けられる状態”まで持っていくためのロードマップとして使ってください。

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

この記事で解決できること（最短で遊ぶ／自由にカスタム／安定運用）

「7 Days to Die　ConoHa」で検索する人の多くは、次のどれか（または全部）で詰まっています。

• とにかく早くマルチサーバーを立てて、友達と遊びたい
• 設定（難易度・湧き・昼の長さなど）を自分好みに調整したい
• アプデや再起動、バックアップまで含めて安定して運用したい

この記事では、ConoHaで7 Days to Dieサーバーを扱ううえで必要な情報を「迷うポイント順」に整理し、1本で“開始〜運用”まで通せるようにまとめます。🎮✅

想定読者（初心者〜軽いLinux操作ができる人）

こんな人に向いています

• 友達数人〜中規模（少人数中心）で、専用マルチサーバーを持ちたい
• ConoHaのアカウント作成・支払い設定など、基本操作はできる
• PC操作で「コピー＆ペースト」「ファイル編集（メモ帳レベル）」ができる
• Linuxは未経験でもOK（ただし、SSHが触れるとできることが増える🧰）

先に知っておくと安心な前提

• ConoHaのテンプレート／イメージは便利ですが、ゲームはアップデート頻度が高いので、状況によっては更新作業が必要になります
• 7 Days to Dieのサーバー運用では、メモリがボトルネックになりがちです（公式ドキュメント上も最低メモリ要件の記載あり）
• “楽に始めたい”か“自由にいじりたい”かで、選ぶルートが変わります

この記事で扱うルート（ざっくり）🔎

目的	まずおすすめ	こんな人向き
最短で遊ぶ	ConoHa for GAME のテンプレ	とにかく早く合流したい
設定をいじる	アプリイメージ／VPS運用	設定編集・保守もやりたい
自由度MAX	Ubuntuで手動構築	MOD・更新・自動化まで作り込みたい

※「テンプレが使えないプランがある」「推奨メモリの目安がある」など、選ぶ前に押さえる注意点も本文で整理します。

このページの到達点（建てる→入る→安定して回す）

このページを読み終える頃には、次の状態を目指します。
（“今すぐ遊ぶ派”も“ちゃんと運用派”も、必要なところだけ拾える流れです）

到達点1：自分に合う建て方を選べる

• テンプレで最短にするか、VPSで自由度を取るか判断できる
• 人数・遊び方に合わせて、プラン選びの基準が分かる
  • 目安として、最低要件や利用制限（例：低メモリプラン不可）がある点も把握できる

到達点2：サーバーを作って、参加情報を迷わず渡せる

• 作成後に確認すべき情報（例：IP、参加パス、設定ファイルの場所）が分かる
• 友達に伝えるべき内容を、テンプレ文にしてそのまま送れる📩

到達点3：接続トラブルの“入口”を潰せる

• 「入れない／見つからない」で多い原因（ポート・セキュリティ設定）を先回りできる🛡️
• いざ詰まった時に、どこを見て切り分けるか分かる

到達点4：設定変更と運用の基本ができる

• サーバー設定（例：難易度、ゾンビ湧き、昼の長さ等）を安全に編集して反映できる🔧
• 再起動・バックアップ・アップデートを、事故らない順番で回せる
• MODを入れる場合も、導入前の注意（バックアップ、相性切り分け）が分かる

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

最初に結論：ConoHaでの建て方は「3ルート」から選ぶ

「7 Days to Die　ConoHa」で迷う原因は、ConoHaの中だけでも“建て方が3種類”あることです。
結論から言うと、あなたが欲しいのは次のどれかになります。

• 最短で遊びたい → ルートA（ConoHa for GAMEのゲームテンプレ）
• 簡単に始めつつ、あとから手を入れたい → ルートB（ConoHa VPSのアプリイメージ）
• 自由度MAXで作り込みたい → ルートC（ConoHa VPS Ubuntuで手動構築）

ここから、それぞれの特徴と「どれを選べばいいか」を初心者向けに噛み砕いて説明します。

ルートA：ConoHa for GAMEのゲームテンプレで“最短”スタート

向いている人

• まずは今日・今週末にでも、すぐ友達と遊びたい
• Linux操作は極力したくない（または必要最小限でOK）
• 「サーバーを立てる」より「ゲームを始める」を最優先したい

何がラクなの？（ポイント）

• テンプレを選んで作成するだけで、必要なソフトが入った状態で起動できる
• 作成後にサーバーへログインすると、参加に必要な情報（例：IP、パス等）が表示される設計になっていて、初心者が迷いにくい
• サーバー単位で通信を制御する仕組み（セキュリティグループ）が前提にあり、「開けるべきポート」だけ意識すれば運用しやすい

注意点（ここだけ先に知ると事故が減る）

• 初回はワールド生成などで、すぐ接続できないことがある（しばらく待つ前提）
• ゲームはアップデートが頻繁なので、状況によっては手動アップデートが必要になる
• こだわり設定やMOD運用は可能でも、作業は増えがち（「最短で遊ぶ」と相性がいい）

まずやること（最短チェック） ✅

• テンプレでサーバー作成
• 起動後、表示される参加情報（IP・パス等）を控える
• 参加できない場合は「ポート／セキュリティ設定」を優先的に確認（詳細は後続の記事パートで解説する想定）

ConoHa for GAME 公式サイト

ルートB：ConoHa VPSのアプリイメージで“簡単＋拡張”

向いている人

• なるべく簡単に始めたいが、あとから
  設定変更・バックアップ・自動再起動などもやっていきたい
• “VPSらしい運用”を少しずつ覚えてもいい
• 友達が増えたり、MODを入れたくなる可能性がある

ルートAとの違い（ざっくり）

• Aは「ゲーム用途に寄せた最短コース」
• Bは「VPSの土台の上に、7DTDが入ったイメージを載せる」イメージ

そのため、Bは次のメリットが出ます。

メリット

• OS側の運用（ログ確認、バックアップ設計、再起動自動化など）を取り入れやすい
• いざというときに、SSHで中を確認しやすい（原因切り分けが速い）
• “テンプレの枠”に縛られにくく、拡張しやすい

注意点

• 利用できるプランに条件がある（例：メモリ4GB以上が必要といった制約）
• セキュリティグループ（仮想ファイアウォール）の考え方を最低限理解する必要がある
• ゲーム更新の管理は、Aより「運用者の責任」が増える

まずやること（失敗しない順） 🧩

1. アプリイメージでサーバー作成（条件に合うプランを選ぶ）
2. 初回起動が落ち着くまで待つ
3. 参加情報を控える（IP・パス等）
4. 必要ポートの許可を確認する（ゲーム用＋管理用）

ConoHa VPS 公式サイト

ルートC：ConoHa VPS（Ubuntu）で“自由度MAX”の手動構築

向いている人

• MOD・設定・更新・自動化まで、自分の流儀で作り込みたい
• 多少の手間より、トラブル時に「中身が分かる」安心感が欲しい
• 将来的に、他サーバーへ移行する可能性も含めて設計したい

できること（強み）

• 起動方法を systemd 化して、落ちても自動復旧しやすくする
• バックアップを cron で定期化して、巻き戻し可能な運用を作る
• MODや設定の管理を「差分」で持ち、アップデート時の事故を減らす
• サーバー性能に合わせて調整し、ラグを抑える（メモリ・CPU・I/O）

ただし、初心者がつまずきやすい点

• SteamCMD や依存関係の準備、ポート開放など、作業工程が増える
• “動いたけど不安定”になりやすい（ログを見る習慣が必要）
• 最短で遊ぶ目的とは逆方向（最初は時間がかかる）

最低限の見取り図（何をするかだけ把握） 🧭

• Ubuntu用意 → ユーザー作成 → 必要パッケージ導入
• サーバーファイル取得（SteamCMD等）
• ポート・FW・セキュリティグループ調整
• 起動スクリプト作成 → 自動起動化 → ログ確認
• バックアップ設計 → アップデート運用の手順化

迷った時の判断軸（人数／MOD／更新頻度／作業量／コスト）

「結局どれ？」を最短で決めるために、5つの軸で整理します。
あなたの条件に近いところだけ見ればOKです。

1) 人数（負荷のかかり方）

• 友達数人で気軽に → A or B
• 人数が増える／ワールドが重い設定にしたい → B or C（調整・監視がしやすい）

※7DTDは運用上、メモリが効きやすいタイプです。まずは“条件を満たすプラン”を選ぶのが優先です。

2) MOD運用（導入・切り分けのしやすさ）

• MODなし／少なめ → Aでも十分
• MODを増やす予定がある → B（管理しやすい）
• 大型MODや検証を回したい → C（差分管理や自動化が強い）

3) 更新頻度（アプデ追従の手間）

• “たまに更新でもOK” → A
• 更新が来るたび確実に追従したい → B or C
• ベータや固定運用も考える → C

4) 作業量（どれだけ触りたいか）

• 管理は最小、ゲーム時間を増やしたい → A
• 運用も覚えたいが、難しすぎるのは嫌 → B
• 自動化・保守まで作り込みたい → C

5) コスト（支払いスタイル）

• 週末だけ遊ぶ／短期 → 時間課金が向くケース（サービス側の料金タイプで選択）
• 長期で遊ぶ → 長期割引が向くケース
• コスト最適化を突き詰める → B or C（運用自由度が高いほど調整余地が出る）

迷ったらこの早見表でOK

あなたの希望	まず選ぶなら
今日中に立てて遊びたい	ルートA
簡単に始めて、あとで設定や保守もやりたい	ルートB
MOD・更新・自動化まで、最初から全部自分で管理したい	ルートC

個人的に“初心者にちょうどいい落としどころ”はルートBです。
理由は「最短感」と「後から困った時の逃げ道（SSH・ログ・バックアップ）」が両立しやすいからです。
ただし、“今すぐ遊ぶ”が最優先なら迷わずAでOKです。

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

失敗しないプラン選び（人数・ワールド規模・MODで見積もる）

プラン選びで一番大事なのは、「平均」ではなく「ピーク（重い瞬間）」で考えることです。
7 Days to Dieは、普段は軽くても、次のタイミングで一気に負荷が跳ねます。

• 新規ワールド生成・新エリア探索（チャンク生成）
• ブラッドムーンや大規模戦闘（AI・物理・同期が集中）
• 大拠点・トラップだらけ（処理＋データ量が増える）
• MOD追加後（メモリ・ロード・同期が増える）

さらに公式側の前提として、ConoHaの7 Days to Die（アプリイメージ）はメモリ4GB以上が必要、ConoHa for GAMEのテンプレでは推奨メモリ8GB以上の案内があります。
迷ったら、まずはこの「最低ライン」と「推奨ライン」を軸に考えるのが安全です。

人数が増えると効く要素（メモリ／CPU／ストレージI/O）

人数が増えるほど、単純に「人数分の処理」が積み上がります。体感が悪化しやすい順に見ると、だいたいこの並びです。

1）メモリ（最優先）
メモリ不足は、いきなり“カクつき”よりも、次の症状で出がちです。

• ログイン時や移動時に急に重くなる
• 時々フリーズっぽくなる／戻ってきたらワープしている
• サーバーが不安定（最悪、落ちる）

👉 対策の基本

• 人数が増えるほど、まずはメモリを厚めに
• 迷ったら「推奨」側（8GB以上）寄りでスタート

2）CPU（次に効く）
CPUが足りないと、戦闘や襲撃で分かりやすく出ます。

• ブラッドムーンで急にTPSが落ちる
• ゾンビの挙動が不自然、反応が遅い
• トラップ・タレット大量で一気に重い

👉 対策の基本

• 同時ログイン人数×戦闘量が多いなら、上位プラン（コア数増）を検討
• “普段は軽い”人ほど、ピーク（襲撃）で決めるのがコツ

3）ストレージI/O（意外と見落とし）
I/Oは「新しい場所へ行った瞬間」に効きます。

• 新天地に行くとカクッと止まる
• 探索が早い（乗り物／遠征）ほど気になる

👉 対策の基本

• ワールドサイズを欲張りすぎない
• 初回は“探索を一気に広げすぎない”運用にする（後述）

迷った人向け：ざっくり目安（経験則）
※最終的にはワールド規模・設定・MODで変わります。あくまで「外しにくい初手」です。

遊び方のイメージ	まずの目安
少人数で軽め（拠点も小さめ）	8GBあたりから
人数多め・拠点やトラップ盛りがち	12〜16GBを視野に
大規模拠点＋重めMODもやる	16GB以上で余裕を作る

ポイントは、「後で困るより、最初から少し余裕」です。
サーバー運用は、余裕があるほどトラブル対応が楽になります。

ワールド生成と負荷の関係（サイズ・探索範囲・拠点密度）

ワールド負荷は「作った瞬間」よりも、遊び方で育っていくタイプです。

1）初回ワールド生成は“待つ時間”がある
ConoHaの案内でも、VPSを初めて追加したタイミングでワールド生成が走り、接続可能になるまで数分かかるとされています。
初回につながらなくても焦らず、まずは時間を置くのが正解です。

2）ワールドサイズは“重さの上限”を決める
サイズが大きいほど、次が増えやすいです。

• 生成にかかる時間
• 保存データ量（ストレージ使用）
• 新エリア探索時のI/O負荷

👉 初心者向けの考え方

• 最初は中くらいで十分
• 「大きいほど良い」より、“快適に遊べる範囲”を優先

3）探索範囲が広いほど、重い瞬間が増える
探索のたびに新しいデータ処理が発生します。
特に、複数人が別方向に散ると、同時に負荷が積み上がります。

• 例：Aさんは北へ、Bさんは南へ → 同時に別チャンクが増える

👉 運用のコツ

• 初期は“探索の方向”を合わせる（負荷がまとまりやすい）
• 大遠征をする日は、サーバー再起動を事前に入れておくと安定しやすい

4）拠点密度（作り込み）も効く
トラップ・配線・タレット・大量収納…は、便利なほど処理が増えます。

• 拠点を盛るなら、メモリとCPUに余裕を持たせる
• “拠点の快適さ”は、サーバースペックで買う部分も大きいです

MOD運用で増える負荷（導入本数／追加アセット／同期頻度）

MODは「数」よりも、中身のタイプで負荷が変わります。初心者が事故りやすいポイントを先に押さえましょう。

負荷が増えやすいMODの傾向

• 追加アセットが多い（テクスチャ・音・大規模追加）→ メモリ／I/O
• AIや挙動を大きく変える → CPU
• プレイヤー間同期が増える要素（大量アイテム・イベント）→ CPU／通信

導入前にやるべき3点セット（ここ大事） 🧰

1. バックアップ（ワールド＋設定）を取る
2. MODは一気に入れない（1〜2本ずつ）
3. 不具合時は切り分け優先（最後に入れたものから戻す）

おすすめの現実的な運用

• 最初の数日はバニラ（MODなし）で安定運用を確立
• “快適に遊べる”ことを確認してから、MODを増やす
• 大型MODを入れるなら、最初から上位メモリを視野に

コスト最適化の考え方（長期割引 vs 時間課金／遊ぶ時間帯）

コストは「最安プラン」より、“無駄に課金しない運用”で差がつきます。
ConoHa VPSは料金タイプとして「まとめトク（長期契約割引）」と「時間課金」の2種類を用意しています。

1）まずは“サーバーを常時ONにするか”で決める

• 友達が好きな時間に入る／放置採取もしたい
  → 常時ONになりやすい＝長期割引（まとめトク）側が向きやすい
• 週末だけ／遊ぶ日だけ立てる
  → 時間課金がハマりやすい

2）ConoHa for GAMEは“月額と時間”が同時に見えるのが強い
ConoHa for GAMEの標準プランは、月額と時間単価が併記されています。
このときは、次の式で「どっちが得か」を機械的に判断できます。

• 月に使う時間（時間） × 時間単価（円）
  vs
  月額（円）

👉 たとえば「毎晩ちょっとだけ」でも、積み上げると意外と大きいので、
“週あたり何時間サーバーを動かすか”を先に決めるのがコツです。

3）コスト最適化は“遊び方”でやるのが一番効く
スペックを落とすより、次のほうが失敗しにくいです。

• 遊ばない日は停止（時間課金なら特に強い）
• 大遠征やブラッドムーン前に再起動（安定＝ムダ時間減）
• 重くなる設定（視界、湧き、トラップ盛り）をやりすぎない
  → 結果的に上位プランへ上げる必要が減る

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

事前準備チェック（建てる前にここだけ確認）

サーバー構築は、始めてから詰まるより「建てる前のチェック」で9割決まります。
ここでは初心者でも迷わないように、必要最低限＋つまずきやすい所だけを先に固めます。

必要なもの（Steam版／管理用PC／最低限の権限）

まずは「環境」と「権限」を揃えます。下のチェックが全部OKなら、準備は完了です。

必須（これがないと始まらない）

• PC版（Steam）の7 Days to Die（参加する全員分）
• ConoHaアカウント（契約・支払い設定が完了していること）
• 管理用PC（Windows/MacどちらでもOK）
  • ブラウザでConoHaのコントロールパネルにログインできる
  • 文字のコピー＆ペーストができる（参加情報を共有するため）

あると楽（作業が一気にスムーズ）

• パスワード管理ツール（長いパスを安全に管理できる）
• 共有用メモ（Notion/Googleメモ/メモ帳など）
• SSHクライアント（VPSで管理する場合：Tera Term / Windows Terminal / iTerm など）

ルート別に“必要レベル”が変わる

• ルートA（for GAMEテンプレ）
  → ほぼブラウザ操作で完結。サーバー側は「表示された情報を控える」だけで進めやすい
• ルートB（VPSアプリイメージ）
  → ブラウザ中心＋必要に応じてSSH（トラブル切り分けや更新で役に立つ）
• ルートC（Ubuntu手動構築）
  → SSH前提（導入・更新・自動化まで触る）

プラン条件の確認（建てる前に見落としがち）

• ConoHa VPSの7 Days to Dieアプリイメージは、メモリ4GB以上のプランが前提です。
• ConoHa for GAME側は、快適性の目安としてメモリ8GB以上が推奨として案内されています。
  「とりあえず最安で…」が通らないケースがあるので、先に条件だけ押さえておくのが安全です。

接続に必要な情報の控え方（IP・ポート・参加パス）

接続トラブルの多くは、情報の控え漏れ／伝え間違いです。
最初に、次の3点を“1セット”で控えましょう。

控えるべき3点セット

1. サーバーIPアドレス（友達が入力する宛先）
2. ポート番号（標準は26900周辺が多い。変更しているなら必ず控える）
3. 参加パス（JOIN Password）（友達が入室時に必要）

加えて、運用するならこの2つも控えると後々ラクです。

運用で効く追加メモ

• サーバー名（一覧で見分ける用）
• 管理者用の情報（adminパス／管理用ユーザーなど。※友達には配らない）

控え方のおすすめ（ミスが減る）

• “スクショだけ”は避ける（入力ミスが起きやすい）
  → テキストでコピペできる形で残すのが最強です。
• 共有メモに、下のテンプレで1回だけ整える（友達対応が楽になります）

友達に送る用テンプレ（そのままコピペOK）

• サーバーIP：xxx.xxx.xxx.xxx
• ポート：26900（変更していたらその値）
• 参加パス：********
• 参加方法：ゲーム内「ゲームに参加」→（必要なら）IP接続→パス入力

ConoHaで“どこに書いてあるか”

• テンプレ／アプリイメージの場合、ConoHa側の手順でサーバーにログインすると、必要情報が表示される形式になっています（IPとJOIN Passwordなど）。
• for GAMEやConoHaのドキュメントでは、7 Days to Dieで使うポートの例（TCP/UDP）も提示されています。
  ここを控えておくと、後で「開けるべきポートはどれ？」で迷いません。

セキュリティの最低ライン（公開範囲／管理パスの扱い）

ゲームサーバーは、動かした瞬間から“外部に開く可能性があるサービス”です。
ただし難しいことを全部やる必要はありません。初心者でもできる 最低ラインをまとめます。

最低ライン1：公開範囲を決める（誰に開くか）

• 友達だけで遊ぶなら、基本は「友達が入れる範囲」に絞る
• ConoHa VPSではセキュリティグループで通信（ポート）を制御できます
  • まずは「ゲームに必要なポートだけ許可」が基本
  • SSH（22番）などゲーム以外のポートは、必要になってから許可でもOK

最低ライン2：管理パスは“配らない・使い回さない”

• 参加パス（JOIN Password）と、管理者系のパスは分ける意識が大切です
• 管理者権限につながる情報は、次を徹底すると安全度が上がります
  • 長くする（12〜16文字以上）
  • 使い回さない
  • 共有は最小限（基本は運営者だけ）

最低ライン3：バックアップを“先に”決める（事故の保険）

• 初心者が一番困るのは「設定変更や更新で壊れて戻せない」ことです
• ConoHa公式でも、作業前にバックアップ（イメージ保存等）を推奨しています
  → MOD導入・アップデート・大きな設定変更の前だけでも、習慣にすると安心です

最低ライン4：ルールを1行だけ決める（荒れ防止）
友達鯖でも、これを最初に書いておくとトラブルが減ります。

• 例：
  • パスは外部に共有しない
  • 大規模改築や大量トラップは事前相談
  • MOD追加は運営者がまとめてやる

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

ルートA：ConoHa for GAMEテンプレでサーバーを作る（最短手順）

「最短で建てて、友達が入れる状態まで持っていく」ことだけに集中した手順です。
やることは大きく ①作成 → ②初回生成を待つ → ③コンソールで参加情報を控える の3つです。

作成フロー（コントロールパネル→ゲーム選択→サーバー作成）

1. ConoHaのコントロールパネルにログイン
2. サービスで GAME を選ぶ
3. サーバー追加 を押す
4. イメージタイプで ゲーム を選び、ゲーム一覧から 7 Days to Die を選択
5. プラン（メモリ容量など）と料金タイプを選ぶ
6. rootパスワードを設定して作成

ここまでできれば、あとは「待つ」と「確認」だけです。

初期設定で迷うポイント（プラン／料金タイプ／rootパス）

プラン（メモリ）

• 7 Days to Dieテンプレは、利用できるプランに下限があります（小さすぎるプランは不可）。
• 迷ったら、まずは“条件を満たす範囲”で作って、重ければ後から上げる方が失敗しにくいです。
  • 7 Days to Dieは、人数増加・拠点作り込み・ブラッドムーンなどで急に重くなることがあります。

料金タイプ（長期割引パス／時間課金）
選び方はシンプルです。

• 1ヶ月以上ほぼ毎日動かす（友達が好きな時に入る）
  → 長期割引パスが向きやすい
• 数時間〜1週間程度だけ遊ぶ（週末だけ、短期イベントだけ）
  → 時間課金が相性◎

rootパスワード（超重要）
これは「サーバーに管理者としてログインするためのパスワード」です。参加パスとは別物なので、次を徹底すると安全です。

• 長め（12〜16文字以上）、推測されにくい文字列にする
• 参加パスと同じにしない
• メモ帳ではなく、できれば パスワード管理ツールに保管

初回起動で時間がかかる理由と待ち方（ワールド生成）

初回は、裏側で次の処理が走るため、すぐには入れないことがあります。

• 7 Days to Dieサーバーの初期準備
• ワールド生成（初めてサーバーを追加したタイミングで発生）

待ち方のコツは「余計な操作をしない」ことです。

• 作成直後に何度も再起動しない（逆に遅くなることがあります）
• まずは 5分程度は“待つ時間”として確保
• 焦ったら、次の章の手順で コンソールを開いて表示を確認するのが最短です

コンソールで“参加に必要な情報”を確認する

サーバーが立ったら、コントロールパネルから シリアルコンソールを開いて、rootでログインします。
ログインに成功すると、画面内に 参加に必要な情報が表示されます。

ざっくり流れはこうです。

1. コントロールパネルで対象サーバーを選ぶ
2. シリアルコンソールを開く
3. rootでログイン（作成時に設定したrootパスワードを入力）
4. 表示された情報を控える（コピペ推奨）

IP／参加パス／インストール場所／設定ファイルの所在

コンソールでまず控えるのはこの2つです（友達に渡す“参加情報セット”の核）。

• Server IP Address（サーバーのIP）
• Server JOIN Password（参加パス）

さらに、運用で触る可能性がある場所も「場所だけ」控えておくと後で迷いません。

• サーバーのインストール先（例）：/opt/7dtd/7dtd_server
• 設定ファイル（例）：/opt/7dtd/7dtd_server/serverconfig.xml

ゲーム側からの入り方（最短）
参加する側は、ゲーム内で「ゲームに参加」から検索画面へ進み、
IP接続の導線で「IP」と「ポート」を入力して接続します。

• IP：控えた Server IP Address
• ポート：26900（テンプレの案内で使われている値）
• 参加パス：控えた Server JOIN Password

友達に送る用テンプレ（コピペ）

• サーバーIP：xxx.xxx.xxx.xxx
• ポート：26900
• 参加パス：********
• 入り方：ゲーム内「ゲームに参加」→（必要なら）IP接続→上を入力

これで「建てる→入る」までが最短で完了します。
次のステップ（設定変更、再起動、バックアップ）に進む前に、まずは 全員が安定して入れることだけ確認しておくのがおすすめです。✅

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

ルートB：ConoHa VPSアプリイメージで建てる（手軽＋運用向き）

ルートBは「VPS上に、7 Days to Dieが入った状態で用意されるイメージ」を使う方法です。
テンプレ同様に始めやすい一方で、VPSなので 更新・バックアップ・自動起動など“運用”を組み込みやすいのが強みです。

サーバー作成時の選択ポイント（イメージ／リージョン／プラン）

イメージ（選ぶものはこれ）

• コントロールパネルでサーバー追加 → イメージの一覧から 「7 Days to Die」 を選びます
• 作成後、コンソールやSSHでログインすると、接続に必要な情報が表示される設計です（後述）

リージョン（迷ったら「遊ぶ人に近い場所」）

• 基本ルール：参加者の多い地域に近いリージョンを選ぶほど、遅延（ラグ）が減りやすい
• 友達が全員日本なら、まずは国内寄りにするのが無難です
• 途中でリージョン変更は簡単ではないので、最初にだけ意識しておくと後悔しにくいです

プラン（ここだけは“下限”を守る）

• ConoHaの7 Days to Dieアプリイメージは メモリ4GB以上が前提です（下限未満だと利用できません）
• 4GBは「動かすための最低ライン」と考え、次に当てはめて選ぶと失敗が減ります

遊び方の傾向	選び方の目安（考え方）
少人数・バニラ中心	まずは下限を満たす構成で開始し、重ければ増強
人数が増える／拠点盛りがち	最初から余裕を取り、ピーク時（襲撃・遠征）で崩れないように
MODを入れる予定がある	“動いたらOK”ではなく、更新や切り分け前提で余裕を確保

料金タイプ（VPS側の基本）

• ConoHa VPSは料金タイプとして 「まとめトク（長期割引）」と「時間課金」が用意されています
• ルートBは運用前提になりやすいので、常時ONが多いなら長期割引寄り、短期イベントなら時間課金寄りで考えるとシンプルです

ゲーム参加に必要な情報の確認（IP・ポート・参加パス）

ルートBは「作成 → ログイン → 参加情報を控える」で完了します。
最初に控えるべきは 3点セットです。

控える3点セット

• Server IP Address（グローバルIP）
• ポート：基本は 26900
• Server JOIN Password（参加パス）

さらに、運用を考えるなら「場所」も控えておくと後がラクです。

控えておくと便利な“場所”

• 7DtD Directory（インストール先ディレクトリ）
• 7DtD Server Config（設定ファイルの場所）

これらは、サーバーにログインした直後に表示される案内（motd）にまとまって出るので、初心者でも迷いにくいです。

参加手順（友達に伝える用）

1. ゲーム起動 → 「ゲームに参加」
2. 検索は触らず進む → 右下の IP接続へ
3. IPに Server IP Address、ポートに 26900 を入力
4. 求められたら Server JOIN Password を入力

詰まりやすいところ（先に潰す）

• 入れないときは、まず「入力ミス」より先に 公開設定（必要ポートの許可）を疑うのが近道です
• アプリイメージのドキュメントでは、ゲーム用ポートに加えて 8080/8082（TCP）も“利用ポート”として記載があります
  • 使わないなら公開しない（閉じる）ほうが安全です

更新の考え方（自動で追従しない場面の備え）

7 Days to Dieは更新が入ると、クライアントとサーバーのバージョン差で接続できなくなることがあります。
このときに慌てないために、ルートBでは「更新の基本方針」を先に決めておくのが重要です。

方針1：原則は“安定版”で運用する

• 友達鯖なら、まずは安定版（通常版）で十分です
• ベータ（experimental）に上げると、新要素は早い反面、トラブル対応の頻度が増えがちです

方針2：更新は“手順化”して事故を防ぐ
ConoHaドキュメントでも、バージョンアップ作業の前に バックアップ（イメージ保存など）を推奨しています。
初心者は、これを「必ずやるルール」にするだけで復旧難易度が激減します。

最低限の更新ルーチン（これだけ覚えればOK）

• 1. 事前に「○分止める」と告知
• 2. バックアップを取る
• 3. サーバーを停止（例：サービス停止）
• 4. アップデートを実行（ドキュメントの手順に沿う）
• 5. 設定を戻す（必要がある場合）→ 起動
• 6. 起動直後は反映に時間がかかることがあるので、ログイン確認まで待つ

ポイント：自動で追従しない場面に備える

• 「急に入れない」は、更新だけでなく 初回ワールド生成でも起きます（初回は約5分かかる場合あり）
• 更新後も、ダウンロードや差し替えが走るため 通常より起動が遅いことがあります
• だからこそ、更新は“焦って連打”せず「待つ→確認→切り分け」が正攻法です

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

ルートC：ConoHa VPS（Ubuntu）で手動構築する（上級寄り・自由度重視）

ルートCは「Ubuntuの素のVPS」に、SteamCMDで7 Days to Die Dedicated Serverを入れて運用する方法です。
最短ルートではない一方で、更新・MOD・自動起動・バックアップを自分のルールで組めるため、長期運用やトラブル対応が強くなります。

全体像：インストール→設定→起動→自動起動→保守

最初に、全体を“5ステップ”で頭に入れると迷いません。

1. OS準備：Ubuntuを最新化、運用ユーザー作成
2. 導入：SteamCMDを入れて、Dedicated Serverをダウンロード
3. 設定：serverconfig.xml を用意し、保存先やログの置き場を決める
4. 起動：手動起動で動作確認 → systemdでサービス化
5. 保守：更新手順（止める→バックアップ→更新→起動）をテンプレ化

初心者がつまずくのは、だいたい次の2点です。

• ポート（外部から入れない）
• サービス化（起動はできるけど運用が回らない）

この記事では、そこを最短で越える順番にします。

サーバー側の準備（ユーザー作成／依存関係／SteamCMD）

まず決める“ディレクトリ設計”

ConoHaの7 Days to Dieイメージ系ドキュメントでは、関連ファイルが /opt/7dtd/ 配下に置かれる例が多いです。
手動構築でも同じ流儀に寄せると、後で迷いにくくなります。

• 例（おすすめ）
  • インストール：/opt/7dtd/7dtd_server/
  • 設定：/opt/7dtd/7dtd_server/serverconfig.xml
  • バックアップ：/opt/7dtd/backup/

運用ユーザーを作る（root運用を避ける）

Dedicated Serverは長時間動くので、専用ユーザーで回すのが安全です。

• 例：steam ユーザーを作り、/opt/7dtd の所有者にする
• SSHは必要なら使う（ただし公開範囲は絞る）

SteamCMDを入れる（Ubuntuの定番手順）

SteamCMDは32bit関連の依存が絡むことがあり、ドキュメントでは i386アーキ追加や multiverse有効化が案内されています。

• 例（流れだけ把握すればOK）
  • i386を追加
  • リポジトリ更新
  • steamcmdをインストール

※コマンドは環境により差が出るため、公式の手順に合わせるのが安全です（出典は最後にまとめています）。

ゲームサーバー導入（Dedicated Serverの取得と配置）

SteamCMDでDedicated Serverを取得する

SteamCMDでは、ゲームを App ID で指定してダウンロードします。
7 Days to Die Dedicated Serverは 294420 を使う案内が一般的です。

• ざっくりの流れ
  1. SteamCMD起動
  2. インストール先を指定（例：/opt/7dtd/7dtd_server）
  3. app_update 294420 で取得（安定版運用が無難）

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

• インストール先を固定する（後でサービス化がラク）
• 更新で壊れた時に戻せるよう、設定ファイルは別途バックアップする（後述）

serverconfig.xml を用意する

手動構築のメリットは「自分の運用前提で初期値を決められる」ことです。
初心者がまず固定すると良いのはこのへんです。

• サーバー名（一覧で見つけやすく）
• 参加パス（公開範囲が狭いほど強固に）
• 最大人数（最初は控えめ→安定後に増やす）
• セーブ関連の置き場（バックアップしやすい場所へ）

“最初から盛りすぎない”のが正解で、まずは 起動→参加→セーブできる を優先します。

通信の準備（必要ポート／FW／セキュリティグループ）

手動構築で一番多い失敗が「サーバーは動いてるのに外から入れない」です。
原因はだいたい セキュリティグループ（ConoHa側）かFW（OS側） のどちらかです。

必要ポートの考え方

ConoHaの7 Days to Die向けドキュメント／セキュリティグループ例では、次のポートが挙げられています。

• 26900（TCP）
• 26900–26903（UDP）
• 8080（TCP）
• 8082（TCP）

初心者向けの運用ルールはシンプルです。

• ゲーム参加に必要な範囲だけ開ける
• 使っていない管理系ポートは 開けない（必要になったら開ける）

“2段階で守る”と事故が減る

• ConoHa：セキュリティグループで「外からの入口」を絞る
• Ubuntu：ufw等でOS側でも絞る（できれば）

特にSSH（22）は、自分の接続元IPだけ許可にしておくと安心です。

起動・停止の設計（手動起動→サービス化→ログ確認）

まずは手動起動で動作確認

最初からサービス化すると、失敗時に原因が見えづらいです。
一度だけ手で起動し、次を確認します。

• 起動ログに致命的エラーがない
• 外部から接続できる（IP:26900 など）
• ワールドが生成され、セーブが作られる

systemdでサービス化（運用の要）

運用を楽にする“最短のゴール”はこれです。

• systemctl start 7dtd で起動
• systemctl stop 7dtd で停止
• systemctl status 7dtd で状態確認

ConoHaのアップデート手順でも、サービス名として 7dtd を停止して更新する例が示されています。
同じ名前で作っておくと、手順がそのまま流用できて迷いません。

ログ確認（困ったらここだけ見ればOK）

まず見る場所を固定すると、トラブルが怖くなくなります。

• systemdのログ：journalctl -u 7dtd
• ゲーム側ログ：Dedicated Serverが出力するログ（serverconfigや起動オプションで指定）

「入れない」「急に落ちる」は、原因が複数でもログにヒントが残ります。
“ログを見る習慣”が、ルートCの最大の強みです。

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

ゲーム側から参加する手順（友達に伝える情報もここで完結）

参加画面での流れ（検索→IP直打ち→参加パス入力）

ConoHaで立てた7 Days to Dieサーバーは、ゲーム内から 「IP直打ち」 で入るのがいちばん確実です。流れは次のとおり。

1. Steamで「7 Days to Die」を起動
2. タイトル画面で 「ゲームに参加」 を選ぶ
3. フィルター画面は基本そのまま、「検索開始」 をクリック
4. サーバーブラウザ画面右下の 「IPに接続」（表示例：「IPに接続しています…」）をクリック
5. 「IPに接続」画面で入力
   • IP：ConoHa側で控えた Server IP Address
   • ポート：通常 26900
6. 「接続」 をクリック
7. パスワード入力画面が出たら、Server JOIN Password を入力して 「送信」
   • 入力欄が 全部「X」表示でも仕様なのでOKです

友達に送る“接続テンプレ”（コピペ用）

• サーバーIP：xxx.xxx.xxx.xxx
• ポート：26900
• 参加パス：********
• 手順：ゲーム起動 → ゲームに参加 → 検索開始 → IPに接続 → 上を入力 → 送信

初心者がつまずきやすいポイントは「検索欄に何か入れてしまう」こと。まずは何も触らず 検索開始 → IPに接続 が最短です。

ポート番号の注意（初期値・変更時の伝え方）

ConoHaの案内では、接続時に入力するポートは 26900 が基本になっています（初期で入っている場合もあります）。ただし、次のケースでは“友達に伝えるポート”が変わります。

ポートが変わる代表例

• サーバー側で設定を編集して、ポート番号を変更した
• 同じVPSで複数サーバーを立てるなど、ポート競合回避のために変えた

伝え方のコツ（ミスを減らす）

• 口頭で「に・ろく・きゅう・ぜろ・ぜろ」は事故りやすいので、必ず テキストでコピペ できる形で渡す
• 友達には 「IP＋ポート＋参加パス」 をセットで送る（どれか欠けると入れません）

チェック用の簡易ルール

• 「ポートをいじってない」＝ 26900でOK
• 「設定変更したかも」＝ ConoHaのコンソール（またはSSH）で設定値を確認してから共有
  • ここを曖昧にすると、参加トラブルの原因が一気に増えます

参加できたか確認するチェック（Ping・一覧表示・入室ログ）

接続に成功したかどうかは、3段階で確認すると早いです。
（上から順に軽いチェック → 確定チェックになります）

1) Pingで“サーバーまで届いているか”をざっくり見る

Windowsなら、コマンドプロンプトで次を実行します。

• ping xxx.xxx.xxx.xxx

結果の見方

• 応答が返る：ネットワーク的に到達している可能性が高い
• 応答なし：到達していない か、サーバー側がPingを返さない設定の可能性もあります
  • Pingが通らない＝即ダメ確定ではない点だけ注意（ゲーム接続は別経路のため）

2) ゲーム画面で“正しい導線に乗れているか”を確認

次の画面遷移が出れば、かなり前進です。

• 「IPに接続…」→「接続」→ パスワード入力画面 が出る
  • ここまで来ない場合は、まず IP／ポート を疑うのが近道です

3) 入室ログで“確定”を取る（運営者側チェック）

運営者（サーバー管理者）は、ConoHaのコンソールやSSHでログを見て「入室した」確証を取れます。

確認の目安

• 接続直後に、ログにプレイヤー名や接続イベントが出る
• “入れない”ときは、同じタイミングでエラー理由が出ることが多い

よくある原因の切り分け（最短）

• パスワード画面すら出ない：IP/ポート/通信許可（セキュリティグループ）
• パスワードは出るが弾かれる：参加パスの不一致（コピペ推奨）
• たまに入れる／重い：サーバー負荷やワールド生成中の可能性（初回や更新直後は待ちが正解の場面あり）

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

運用で差がつく基本設定（“落ちない・荒れない・重くならない”）

7 Days to DieをConoHaで安定運用するコツは、ざっくり言うと次の3本柱です。

• 公開情報を整える（入る人が迷わない・荒れにくい）
• 負荷の山を削る（重い瞬間を軽くして落ちにくく）
• 権限とルールを先に決める（トラブルの芽を摘む）

ConoHaのテンプレ／アプリイメージ環境では、設定は主に serverconfig.xml（ゲーム設定）と、必要に応じて serveradmin.xml（管理・ホワイトリスト等）で行い、変更後は再起動で反映するのが基本です。
（ファイル場所や再起動方法は、最後の出典にまとめています）

サーバー名・説明・参加パス（公開用の整え方）

ここは「快適さ」より運営のしやすさに直結します。最初に整えておくと、友達が増えても混乱しません。

サーバー名（ServerName）の決め方

• 目的は「一覧で一発で見分ける」こと
• おすすめ構成：ゲーム名＋グループ名＋運用ルールの一言
  • 例：7DTD_〇〇鯖_夜20-24/基本まったり
• 避けたい：似た名前、記号だらけ、誰の鯖かわからない名称

説明（ServerDescription）に入れると親切な情報 📝

• 遊ぶ時間帯（例：平日21時〜）
• 参加条件（例：招待制／初見は一言）
• 軽いルール（例：拠点破壊NG、MOD追加は運営経由）
• 連絡先（Discordのチャンネル名など）

説明は“長文”にしなくてOK。短い箇条書き風が一番読まれます。

参加パス（ServerPassword / JOIN Password）の扱い 🔐

• 参加パスは「友達だけで遊ぶ」なら実質必須
• コツは “運営用のパス”と分けること
  • 参加パス：参加者に共有してOK
  • 管理パス（root/SSH/管理者）：絶対に共有しない
• パスの運用ルール例
  • 参加パスは定期的に変更（人が増えた／外部に漏れた疑いがある時）
  • 共有はテキストで（スクショだと打ち間違いが増えます）

日本語を使う場合の注意

• サーバー名・説明に日本語を入れるなら、編集時の文字コードで文字化けすることがあります。
  不安なら、いったんPCにダウンロードしてUTF-8で保存→アップロードの流れが安全です。

最大人数・視界・湧き設定（ラグ対策の定番）

「落ちない・重くならない」は、上位プランにする前に設定で改善できることが多いです。
ただし大事なのは、一気に変えないこと。変更は“1〜2項目ずつ”が事故りにくいです。

まず効きやすい3点セット（初心者向け）

• 最大人数（MaxPlayers）：今いる人数＋少しの余裕でOK
  • 大きくしすぎると、想定外に人が入ってピーク負荷が跳ねます
• 視界距離（View Distance系）：重いと感じたら最優先で見直し
  • 視界が広いほど、描画や同期・AI処理が増えがちです
• ゾンビ湧き（最大湧き数・同時出現数系）：ブラッドムーンが重いならここ
  • 「普段は平気、襲撃だけ重い」タイプの改善に効きます

“軽くなるけど体験が変わりやすい”項目（触る順番に注意）

• ブラッドムーン関連（頻度・数・範囲など）
• 探索／生成に関係する設定（ワールド規模や生成周りの要素）
• 難易度・経験値倍率（ゲーム性が変わりやすい）

おすすめの調整手順（型） ✅

1. いまの状態をメモ（最大人数・視界・湧き）
2. 視界 → 湧き → 最大人数の順で小さく調整
3. 再起動して反映
4. 10〜15分テスト（探索・戦闘・拠点周り）
5. まだ重いなら次の項目へ

どれを触ればいいか迷う人向け早見表

症状	まず触る候補	理由
新しい場所に行くとカクつく	視界距離	処理範囲が増えやすい
ブラッドムーンだけ激重	湧き（同時数）	AI処理が集中しやすい
人が増えたら不安定	最大人数	ピーク負荷の上限を決められる

管理者権限と運営ルール（admin／whitelist／BANの基本）

身内鯖でも、権限とルールは最初に軽く決めるのが一番ラクです。
「揉めた後に決める」より、圧倒的に平和に回ります。

admin（管理者）の考え方

• 管理者は最小人数に（1〜2人が基本）
• 管理者ができることは強力なので、次を徹底
  • 管理者の追加は運営者だけ
  • 管理者コマンドの利用は“復旧・対応時のみ”など方針を決める

whitelist（ホワイトリスト）を使うと“荒れにくさ”が上がる 🛡️

• ホワイトリストは「許可した人だけ入れる」方式
• 使い方のイメージ
  • 友達のSteamID（または名前）を登録
  • 登録が1人でもあると、ホワイトリストが有効になる仕様の環境があります
• 招待制にしたいなら、参加パスよりさらに強い守りになります

BAN（追放・禁止）の基本

• 基本は“使わない”が理想。でも手順は知っておくと安心です
• ありがちなケース
  • 荒らし、チート疑い、ワールド破壊、無断でパスを外部共有
• 事前に「BAN基準」を1行で決めるだけで揉めにくい
  • 例：拠点破壊・チート・外部共有は即BAN（相談なし）

運営ルール（テンプレ） 📌
短くてOKです。おすすめはこの3行だけ。

• 参加情報の外部共有禁止（IP・参加パス）
• 大改築／大量トラップは事前相談（重くなる原因を共有）
• 設定変更やMOD追加は運営がまとめて実施（事故防止）

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

serverconfig.xmlの編集：場所／やり方／反映手順

設定ファイルの場所を特定する（テンプレ／VPSで違う）

ConoHaの「7 Days to Die」系（for GAMEテンプレ／VPSアプリイメージ）は、基本的にサーバーファイルが /opt/7dtd/7dtd_server/ 配下に置かれており、設定ファイルは次にあります。

• 基本の場所：/opt/7dtd/7dtd_server/serverconfig.xml

ただし、次のケースでは“場所が違う”ことがあります。

• ルートC（Ubuntu手動構築）で 自分でインストール先を変えた
• 以前の作業で 別の場所にコピーして編集していた（バックアップや退避など）

迷ったら、サーバー側で“今ある場所”を確定させるのが最短です。

場所を確定する確認コマンド（SSH/コンソールでOK）

ls -l /opt/7dtd/7dtd_server/serverconfig.xml

もし上が見つからないなら、検索して特定します（少し時間がかかる場合あり）。

sudo find /opt -name "serverconfig.xml" 2>/dev/null

安全に編集する流れ（ダウンロード→編集→アップロード）

コンソール上で vi を触るより、初心者が失敗しにくいのは 「ローカルで編集」です。
（ConoHaのコンソールはコピー＆ペーストができないことがあるので、ローカル編集のほうがラクになりがちです）

ここでは、事故が起きにくい“型”で進めます。ポイントは 「止める → バックアップ → 編集」の順番です。

1) 変更前にサーバーを止める（編集中の事故防止）

sudo systemctl stop 7dtd

止まったか確認：

systemctl status 7dtd

2) serverconfig.xmlをバックアップする（必須）

復元できる状態を作ってから編集します。

sudo cp -p /opt/7dtd/7dtd_server/serverconfig.xml /opt/7dtd/7dtd_server/serverconfig.xml.bk

可能なら日付付きもおすすめです（後で戻しやすい）：

sudo cp -p /opt/7dtd/7dtd_server/serverconfig.xml /opt/7dtd/7dtd_server/serverconfig.xml.bk_$(date +%Y%m%d)

3) ダウンロード（SFTPでローカルへ）

Windowsなら：WinSCP（SFTP）
Mac/Linuxなら：scp or sftp

例（Mac/Linuxのscp）：

scp root@<あなたのVPSのIP>:/opt/7dtd/7dtd_server/serverconfig.xml .

※ConoHa for GAMEでSSH/SFTPを使う場合は、セキュリティグループ側でSSH通信を許可する必要があります（許可したら、必要がなくなった時に閉じるのが安全です）。

4) 編集（ローカルのテキストエディタでOK）

おすすめは VS Code / Notepad++ など。編集時の注意はこれだけです。

• 触るのは value="..." の中身だけ
• name="..." は変えない（項目名なので壊れます）
• 日本語（サーバー名・説明）を入れるなら UTF-8で保存
• 余計な整形（自動整形・勝手な改行変換）をしない

よくあるミスは「タグを消す」「ダブルクォートを片方消す」「全角記号が混ざる」です。
不安なら、編集後に 差分（diff） を確認すると一気に安全になります。

5) アップロード（元の場所に戻す）

SFTPで、編集した serverconfig.xml を次に上書きします。

• /opt/7dtd/7dtd_server/serverconfig.xml

アップロード後に、サイズや更新日時が変わっているか確認：

ls -l /opt/7dtd/7dtd_server/serverconfig.xml

反映の手順（再起動・サービス再起動・反映確認）

反映は基本的に 再起動（サービス再起動）です。
止めていた場合は、起動するだけで反映されます。

再起動・起動コマンド

• いったん止めているなら（おすすめ）：

sudo systemctl start 7dtd

• “編集→すぐ反映”でやるなら：

sudo systemctl restart 7dtd

反映確認（初心者が見るべき3点）

1. サービスが起動しているか

systemctl status 7dtd

2. 直近ログにエラーが出ていないか

journalctl -u 7dtd -n 100 --no-pager

3. ゲーム側で変化が見えるか
   • サーバー名を変えた → 一覧やIP接続後に表示が変わる
   • 参加パスを変えた → 新しいパスで入れる（古いパスで入れない）
   • 最大人数など → 接続挙動が変わる

更新直後や初回生成後は、起動が完了して遊べるようになるまで時間がかかることがあります。焦って連打で再起動するより、ログと状態を確認するほうが早く解決します。

変更して良い項目／慎重に触る項目（事故りやすい設定）

「変えてOK」でも、初心者は “まず安全な範囲” から触るのが鉄則です。

比較的安全に変更しやすい（運用でよく触る）

• サーバー名／説明（一覧表示に関わるもの）
• 参加パス（公開範囲の制御）
• 最大人数（ピーク負荷の上限を作れる）
• 難易度・経験値倍率など（ゲーム性は変わるが、壊れにくい）
• 視界や湧き系（ラグ対策の定番。やりすぎると別ゲー感は出る）

慎重に触る（ミスると“入れない・ワールドが別物”になりやすい）

• ポート番号（変えたら、セキュリティグループ／FW／友達への案内も全部変わる）
• ワールド名・ワールド種別・シード（途中変更で別ワールド扱いになりやすい）
• セーブ関連（保存場所・ゲーム名など）（既存データと紐付かなくなる事故が起きがち）
• 管理系機能（Web管理・Telnet等）
  • 便利ですが、公開設定を誤るとリスクが上がります
  • 使うなら「強いパス」「公開範囲の限定」をセットで

もし壊した時の最短復旧
バックアップから戻して再起動です。

sudo systemctl stop 7dtd
sudo cp -p /opt/7dtd/7dtd_server/serverconfig.xml.bk /opt/7dtd/7dtd_server/serverconfig.xml
sudo systemctl start 7dtd

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

MOD導入：対応可否の判断から、入れ方・戻し方まで

まず確認：サーバーだけで完結するMOD／クライアント同梱が必要なMOD

MOD導入で最初にやるべきは「そのMODがどこまで影響するか」を仕分けすることです。
ここを間違えると、参加できない・クラッシュする・友達側だけおかしいが起きやすくなります。

判断の目安（ざっくり結論）

• ✅ サーバーだけで完結しやすい：主に“設定（XML）だけ”を差し替えるタイプ
  → サーバーに入れれば、参加者は追加作業なしで動くことが多い
• ⚠️ クライアント側にも必要になりやすい：新しいアセット（追加データ）やDLLを含むタイプ
  → 参加者全員が同じMODを入れる必要が出やすい（EACをOFFにする必要が出ることも）

MODページで見るべきチェック項目（これだけ見ればOK）

• 「Server-side only」「クライアント不要」などの記載があるか
• 「クライアントにも導入」「配布パックを入れてください」などが書かれていないか
• 「EACを無効化して起動」と書かれていないか（書かれていたら“クライアント側導入が必要”寄り）
• 配布物に 大きな容量のデータ（音声/画像/大量の追加物）が含まれていないか

仕分け早見表

タイプ	中身の雰囲気	サーバーだけでOKになりやすい？	友達へ追加で伝えること
軽量（XML中心）	Config中心、軽い	高い	ほぼ不要（入れたら参加できることが多い）
追加データ系	新武器・新素材・POI追加など	低め	同じMOD導入、場合によりEAC OFF
大型オーバーホール	一式変更（例：Darkness Falls系）	低い	導入手順を全員で統一（版本固定も検討）

迷ったら「参加者の手間が増える可能性がある前提」で進めると事故が減ります。身内鯖ほど“同梱が必要なMOD”の段取りが重要です。

導入フロー（バックアップ→配置→再起動→読み込み確認）

ConoHa環境（テンプレ／アプリイメージ）での導入は、基本的に サーバー本体フォルダ直下の Mods に置く形が一番わかりやすいです。
代表例：/opt/7dtd/7dtd_server/Mods

1) まずバックアップ（最短で戻せる形にする）

最低でも次の2つは確保しておくと安心です。

• 設定：serverconfig.xml
• セーブ（ワールド）：Saveフォルダ一式（場所は環境で異なるので後述）

さらに安全にしたいなら👇

• MOD一式：Mods フォルダごと退避（入れ替え事故の保険）

バックアップ例（概念だけ・パスは自分の環境に合わせてOK）

• serverconfig.xml をコピーして残す
• セーブフォルダを backup/ に固める（zip/tarなど）

2) サーバーを止める（導入中の破損を避ける）

ConoHaのテンプレ系は、サービス名が 7dtd のことが多いです。

sudo systemctl stop 7dtd

3) Modsフォルダを用意する（なければ作成）

sudo mkdir -p /opt/7dtd/7dtd_server/Mods

4) MODを配置する（“フォルダの深さ”が最重要）

ここが一番の落とし穴です。
正しい形は、Mods/Mod名/ModInfo.xml が見える状態。

✅ OK

• Mods/ExampleMod/ModInfo.xml
• Mods/ExampleMod/Config/...

❌ NG（よくある失敗：フォルダが1段深い）

• Mods/ExampleMod_v1.2/ExampleMod/ModInfo.xml

対策：アップロード後に、必ず ModInfo.xml が見える場所まで開いて確認してください。

5) 起動（再起動）して読み込み確認

sudo systemctl start 7dtd

確認ポイントは次の3つです。

• ✅ サーバーが起動し続けている（落ちていない）
• ✅ ログにMOD読み込みらしき行が出る（完全一致は不要。「MOD名」「読み込み」などが目安）
• ✅ ゲーム内の挙動が変わる（アイテム追加、設定反映など）

初回起動や更新直後は時間がかかることがあります。焦って何度も再起動すると、逆に切り分けが難しくなります。

セーブ（ワールド）場所の見つけ方（初心者向け）

環境で保存先が違うので、以下のどちらかで確定させると安全です。

• serverconfig.xml の SaveGameFolder / UserDataFolder を確認する
• 見つからなければ、Saves ディレクトリを検索して“今動いている保存先”を突き止める（例：find で探す）

相性問題の切り分け（MOD停止→1本ずつ戻す）

MODトラブルの基本は「原因を小さくする」ことです。
おすすめは、まず“MODなしで起動できる状態”を作るやり方。

切り分けの最短ルート（テンプレ）

1. サーバー停止
2. Mods をいったん無効化（フォルダ名を変えるのがラク）
   • 例：Mods → Mods.off
3. 起動して、バニラで正常か確認
4. 正常なら、MODが原因確定
5. MODを1本ずつ戻して、どれで壊れるか特定

速く特定したい人向け（時短のコツ）

• MODが10本以上なら、1本ずつより「半分ずつ戻す（2分探索）」が速いです
  例：10本 → 5本戻す → OK/NG → 次の5本…のように絞る

よくある“相性の正体”

• 同じ項目（同じXML）を別MODが上書きしている
• 前提MOD（依存関係）が抜けている
• MODのフォルダ階層が間違っていて、そもそも読み込まれていない
• クライアント同梱が必要なのに、サーバーだけ入れている（参加者側で不整合）

アップデート時の注意（ゲーム更新とMOD更新の順序）

MOD運用でいちばん壊れやすいのが、ゲーム本体の更新タイミングです。
結論としては、次のどちらかの方針に寄せると安定します。

方針A：バニラ優先（更新を先に当てる）

• まずゲーム本体を更新
• その後、MODを対応版に更新（対応していないMODは一時停止）

手順テンプレ

1. バックアップ
2. サーバー停止
3. ゲーム本体を更新
4. いったん MODなしで起動して正常確認
5. MODを更新・再配置
6. 起動して確認

✅ メリット：最新に追従しやすい
⚠️ デメリット：MOD側が追いついていないと遊べない期間が出る

方針B：MOD優先（版本固定で安定運用）

• 大型オーバーホールや重要MODがある場合、ゲーム更新を待つ
• MOD作者の「対応済み」アナウンス後に更新する

✅ メリット：長期運用が安定
⚠️ デメリット：最新要素は遅れる

追加で覚えておくと強いこと（EAC）

• MODによっては、EAC（Easy Anti-Cheat）を無効にしないと動かないことがあります
• その場合、サーバー側だけでなく 参加者側もEACをOFFにして起動する必要が出やすいです
  （＝「クライアント同梱が必要」寄りだと判断しやすい）

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

アップデート／バージョン不一致の対処（ここが一番つまずく）

よくある症状（参加できない／互換性エラー／読み込み停止）

バージョン不一致まわりのトラブルは、見え方がいくつかあります。まずは“症状→最初にやること”を短く整理します。

症状	ありがちな原因	最初にやること（最短）
サーバーを選ぶと「互換性がない」「Version mismatch」系で入れない	サーバーとクライアントのバージョン差（安定版/実験版、パッチ差）	サーバー側のバージョンと、参加者のSteamの分岐設定を揃える
参加できるが、途中で読み込みが止まる／落ちる	MOD不整合、更新直後の初回処理、ワールド/セーブの不整合	いったんMODなしで起動できるか確認→原因を切り分け
サーバーが一覧に出ない／IP直打ちでも繋がらない	ポート・FW・セキュリティグループ、もしくはサーバーが起動していない	systemctl status 7dtd と、ポート許可（26900周辺）を確認
ConoHaのテンプレを使っていて、突然入れなくなった	本体側の更新に対してテンプレ反映が遅れている／手動更新が必要	待つか、手動アップデートのどちらで行くか判断

ポイントは、「入れない＝即サーバーが壊れた」ではないこと。
だいたいは「どこかの“更新”が先に進んだだけ」です。

原因の整理（クライアント差・サーバー差・ベータ設定差）

バージョン不一致は、原因を3つに分けると混乱しません。

1) クライアント差（参加者のSteam側がズレている）

• 誰か1人だけ入れない → その人の ゲームの分岐（ベータ）設定がズレている可能性が高い
• 例：実験版（Experimental）に入っている／逆に安定版に戻っていない

運営者が友達に確認してもらうこと

• Steamで7 Days to Dieを右クリック → プロパティ → ベータ（または分岐）
• 「なし（NONE）」なのか、「latest_experimental」などの実験ブランチなのか

2) サーバー差（ConoHa側のサーバーがズレている）

• サーバーが古い：クライアントだけ更新されて入れない
• サーバーが先に実験版へ：安定版クライアントが入れない

特にConoHa for GAMEテンプレは、本体の最新が出てからテンプレ反映まで時間がかかる場合がある、と案内されています。
「急に入れなくなった」直後は、まずここを疑うのが近道です。

3) ベータ設定差（“安定版”と“実験版”が混在している）

これは一番多いパターンです。

• サーバー：安定版
• 参加者：実験版（または逆）

解決策は2択だけ

• みんなをサーバーに合わせる（安定版で運用するなら最優先）
• サーバーをみんなに合わせる（実験版を試すなら検証用で）

安全な更新手順（停止→バックアップ→更新→起動→確認）

更新は「やり方」より「順番」が重要です。ConoHa環境なら、次の型に固定すると事故が激減します。

0) 事前に決めること（迷いの芽を先に摘む）

• 今日の更新は 安定版を維持する？ それとも 実験版へ上げる？
• MOD入りなら、更新日は MOD停止で起動確認してから戻す（この順番が安全）

1) 停止（サーバーを“ちゃんと止める”）

ConoHaの案内でも、シャットダウンボタンではなく、サービス停止で止める流れが示されています。

• VPS/テンプレ共通の代表例：
  • systemctl stop 7dtd

2) バックアップ（最低2点だけでOK）

最低ラインはこれです。

• 設定：serverconfig.xml
• ワールド/セーブ（戻せる保険）

「最短で復旧できる」ことが、運営上の最大の安心材料になります。

3) 更新（サーバー側を揃える）

• ConoHaの案内手順に沿って、SteamCMD等で更新する
• 実験版を入れたい場合は、サーバー更新コマンドに ベータ指定が必要になります（例：-beta latest_experimental など）

4) 起動（サービス開始）

• systemctl start 7dtd（または restart）

5) 確認（ここで“ズレ”を潰す）

チェックは3つだけで十分です。

• systemctl status 7dtd で稼働している
• ログで致命的エラーが出ていない（起動直後は少し待つ）
• 参加者が入れる（まず運営者が入室テスト → OKなら共有）

更新時のコツ

• 連打で再起動しない（原因の切り分けが難しくなる）
• “入れない”が出たら、まず サーバーを最新にしたかと、参加者のベータ設定の2点を揃える

検証用に“更新を遅らせる/固定する”考え方

身内サーバー運用で一番ラクなのは、実は「更新しない」ではなく “更新の当て方をコントロールする”ことです。

パターンA：安定運用（メイン鯖は安定版固定）

• 原則は安定版（NONE）
• 本体更新が来たら、いきなり当てずに
  1. まず告知
  2. バックアップ
  3. 更新
  4. 30分だけテスト
     で事故を減らします

パターンB：検証鯖を1台作る（おすすめ）

ConoHaはサーバーを複数持てるので、次の形にすると強いです。

• メイン鯖：友達が遊ぶ本番（安定版・MODもここ）
• 検証鯖：更新・実験版・MOD更新の確認用（人が少ない時間にだけ触る）

✅ メリット

• 本番を止めずに検証できる
• 「この更新は危ない」が先に分かる

パターンC：ConoHaテンプレの“反映待ち”を選ぶ

ConoHa for GAMEテンプレは、最新リリース後に反映まで時間がかかる場合がある、と明記されています。
この方針を取るなら、次のルールにすると混乱が減ります。

• “入れない日”が出たら、まずは 待つ（反映待ち）
• 急ぎなら、ConoHaの手順で 手動アップデート
• どちらにするかは、遊ぶ予定（今日遊ぶ？週末？）で決める

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

トラブルシューティング早見表（接続できない・重い・落ちる）

困ったときは「原因を当てにいく」より、順番に潰すほうが早いです。まずはこの流れだけ覚えておくと、ほとんど解決できます。

まず見る順番	何を確認する	目安
1	サーバーは起動している？（落ちてない？）	systemctl status 7dtd
2	IP・ポート・参加パスは合ってる？（コピペできてる？）	友達へテンプレ共有
3	“一覧に出ない”のか、“IP直打ちでも入れない”のか	症状で分岐
4	重い／落ちるなら「ピーク負荷」と「ログ」を見る	視界・湧き・MOD・メモリ

入れない：IP/ポート/パスの見落としチェック

「入れない」は、だいたい 入力ミスか バージョン差か サーバー停止です。まずここから。

1) 友達に渡す3点セットを“コピペで”再共有

口頭は事故りやすいので、必ずテキストで渡します。

• サーバーIP：xxx.xxx.xxx.xxx
• ポート：26900
• 参加パス：********

ありがちな見落とし

• IPの桁ミス（. が抜ける、全角になる）
• ポート未入力（空欄）／ポート変更済みなのに26900のまま
• 参加パスの前後に空白が入る（コピー時に起きがち）

2) まず「サーバーが動いてるか」を運営側で確認

運営者はサーバー側で確認が最短です。

systemctl status 7dtd

• active（running）なら次へ
• 落ちている／起動失敗なら「落ちる」の章へ

3) “初回生成・更新直後”なら待つのが正解なことがある

初回のワールド生成や、更新後の差し替え直後は、起動しても遊べるまで時間がかかる場合があります。
このとき、焦って再起動連打すると逆に長引きやすいです。

• まず数分待つ
• 次にログ（journalctl）で進行しているか確認

4) それでもダメなら「バージョン差」を疑う

症状が 互換性エラー／Version mismatch 系なら、ほぼこれです。

• サーバー側：安定版なのか、実験版（ベータ）なのか
• 参加者側：Steamの「ベータ（分岐）」設定が揃っているか

ポイント：1人だけ入れないなら、その人の分岐設定ズレが濃厚です。

見つからない：ポート・FW・セキュリティ設定の確認

「一覧に出ない」は珍しくありません。結論、一覧検索よりIP直打ちが確実です。
それでも見つからない（＝IP直打ちでも繋がらない）なら、通信側を疑います。

1) “一覧に出ないだけ”かを切り分ける

• 一覧に出ない → まず IPに接続で試す
• IP直打ちでも繋がらない → 次へ（通信の問題の可能性大）

2) セキュリティグループ（ConoHa側）の確認

ConoHa側で、必要ポートが許可されていないと絶対に入れません。

最低限、次が開いているか確認します。

• 26900（TCP）
• 26900–26903（UDP）

さらに、管理画面・管理機能を使う場合に限り、次が必要になることがあります。

• 8080（TCP）
• 8082（TCP）

初心者は「ゲーム参加に必須の範囲だけ開ける」が安全です。使っていない管理系ポートは閉じてOKです。

3) OSファイアウォール（Ubuntu側：ufw等）の確認

OS側で塞いでいる場合もあります。ufw を使っているなら状態を見ます。

sudo ufw status

• activeで、必要ポートがdenyになっていないか確認
• 使っていないなら、無理に触らない（運用方針を決めてから）

4) “ポートを変えた覚えがある”なら、伝達ミスが最頻出

ポート変更は、次の4点がセットです。

• serverconfig.xml のポート設定
• ConoHaのセキュリティグループ
• OS側FW
• 友達への案内（テンプレ）

どれか1つでも古いと、繋がりません。

重い：負荷が高い設定の見直し（人数／視界／湧き／MOD）

「重い」は“常時重い”より、重い瞬間（ピーク）で起きます。
まずはピークを作る要因を減らすと、体感が一気に改善します。

1) まず切り分け：いつ重い？

• 探索で新しい地域に入った瞬間だけ重い
  → 生成・I/O負荷寄り（視界、探索の広がりが影響）
• ブラッドムーンだけ重い
  → 湧き・AI処理寄り
• 人数が増えたら重い
  → 最大人数・メモリ寄り
• MOD入れてから重い
  → MOD起因の可能性（導入本数・タイプ）

2) “効きやすい順”に、1〜2項目ずつ調整する

おすすめの順番はこれです（変化が出やすい順）。

1. 視界距離（View Distance系）：探索や拠点周りの負荷に効きやすい
2. 湧き（同時出現数・襲撃関連）：ブラッドムーンのカクつき対策の定番
3. 最大人数（MaxPlayers）：ピークの上限を作れる
4. MOD：重いMODを疑うなら、まずは一時停止して比較

コツ：一気に変えると、改善した要因が分からなくなります。必ず小さく変えてテストします。

3) MODが原因っぽいときの最短チェック

• いったんMODなしで起動して、重さが改善するか確認
• 改善するなら、MODを「半分ずつ」戻して原因を絞る（時短）

落ちる：ログの見方と再発防止（再起動設計・バックアップ）

「落ちる」は原因が広いので、ログで当てるのが最短です。
ただし初心者は、まず“よくある原因”から潰すと早いです。

1) まず見るべきログ（運営側）

systemdで動かしているなら、まずこれだけでOKです。

journalctl -u 7dtd -n 200 --no-pager

ログでよく出るヒント例（考え方）

• メモリ不足っぽい → OOM系の記録、突然のプロセス終了
• 更新直後 → 起動はしているが処理が長い／エラーで停止
• MOD起因 → MOD読み込みや初期化付近でエラー

2) “再起動で直る”でも、再発するなら設計を変える

再起動で一時的に直る場合、ピーク負荷が原因になっていることが多いです。

• ブラッドムーン前に再起動（ピーク前に状態を整える）
• 人数が増える時間帯の前に再起動
• 長時間連続稼働で不安定なら、定期再起動を検討

3) 予防策の最小セット（これだけやると強い）

バックアップ方針と復元手順を“先に決める”だけで、運用難易度が激減します。

• 更新・MOD導入の前：必ずバックアップ
• 最低限守る対象
  • serverconfig.xml（設定）
  • セーブ（ワールド）

「壊れても戻せる」が、初心者運用の最重要スキルです。

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

保守のテンプレ（バックアップ・再起動・ログ管理を習慣化）

バックアップ方針（いつ／どこを／どれだけ残す）

保守で一番大事なのは、何かあったときに「戻せる」ことです。
迷ったら、次の“最小セット”だけ守れば、初心者でも運用が安定します。

バックアップ対象（最小セット）

• 設定：serverconfig.xml（サーバー名、参加パス、最大人数などが入る）
• ワールド／セーブ：Saves（ワールドそのもの。ここが消えると復旧が重い）
• （MOD運用なら）Modsフォルダ：Mods/（相性問題の切り分けにも役立つ）

いつ取る？（タイミングの型）

• ✅ 必須：更新前／MOD追加前／大きな設定変更前（ここで取らないと事故が痛い）
• ✅ 推奨：大型建築やイベントの前後（ブラッドムーン調整、拠点引っ越し等）
• ✅ ルーチン：週1回（最低）、可能なら毎日1回

どこに置く？（初心者が迷わない置き場）

• まずはサーバー内に退避：/opt/7dtd/backup/ など“固定の置き場”を作る
• さらに安心するなら、ConoHaのイメージ保存（スナップショット的なバックアップ）も併用
  • “サーバー丸ごと戻す”ができるので、更新事故に強いです

どれだけ残す？（おすすめ保持ルール）

• 毎日：直近7回
• 週次：直近4回
• 月次：直近3回（余裕があれば）

バックアップの作業テンプレ（短く）

1. 告知（プレイ中なら）
2. サービス停止

   sudo systemctl stop 7dtd

3. 設定・セーブ・Modsをバックアップへコピー（または圧縮）
4. 起動

   sudo systemctl start 7dtd

コツ：バックアップは「毎回完璧」を目指さず、“更新前だけは絶対に取る”を徹底するのが最強です。

定期再起動の考え方（時間帯・頻度・告知）

「たまに重い」「長時間で不安定」を減らすなら、定期再起動がかなり効きます。
ただし、やりすぎると不便なので“ちょうどいい頻度”を決めましょう。

おすすめ頻度（目安）

• まずは 週1回（これだけでも体感が変わることが多い）
• 症状があるなら 2〜3日に1回
• 大人数・MOD多めなら 毎日（深夜）も検討

おすすめ時間帯

• 参加者が少ない時間（例：平日深夜〜早朝）
• “これから集まる”の直前（例：金曜の20時前に一回再起動）

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

• 「本日 22:50 にサーバー再起動します（目安 3分）。22:48以降は大事な作業を控えてください🙏」
• 「再起動後、入れない人がいたら Steam再起動→再接続 を先に試してください」

再起動の手順（最小）

sudo systemctl restart 7dtd
systemctl status 7dtd

“再起動連打”を避けるルール

• 更新直後・初回生成直後は、起動完了まで時間がかかることがあります
  → 連打より、status とログ確認のほうが早く原因に届きます

異常検知の最低ライン（ログ・ディスク逼迫・メモリ）

監視を本格導入しなくても、初心者ならこの3点を“点検メニュー”にするだけで十分です。
週1回（＋不調時）にチェックするだけでも、事故が減ります。

1) ログ（落ちる／入れないの原因が残る）

• まずこれだけ見ればOK：

  journalctl -u 7dtd -n 200 --no-pager

• 見る観点
  • 起動できているか（start後に落ちていないか）
  • エラーが特定のタイミングで繰り返していないか（MOD・更新・ピーク負荷）

2) ディスク逼迫（“突然落ちる”の伏線になりやすい）

• 空き容量チェック：

  df -h

• 危険ラインの目安：空き10〜15%未満になったら対処を検討
• 増えやすいもの：ログ、バックアップ、セーブの世代増加
  • 対策はシンプルに「バックアップの保持数を減らす」からでOK

3) メモリ（人数・湧き・MODで急に足りなくなる）

• ざっくり確認：

  free -h

• 目安
  • プレイ人数が増えた日だけ不調 → メモリ余裕がない可能性
  • ブラッドムーンで落ちる → 湧き設定＋メモリの両面で疑う

“異常時の最短フロー”（覚えるのはこれだけ）

1. systemctl status 7dtd で生死確認
2. 落ちていたら journalctl -u 7dtd で直近ログ確認
3. 更新・MOD・設定変更をしたなら、まずは 戻す（バックアップ復元）
4. それでも再発するなら、負荷要因（人数／視界／湧き／MOD）を段階的に下げる

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

ConoHaで運用する際の注意（停止・解約・課金で損しない）

まず結論だけまとめると、「停止＝休憩」ではなく「停止＝課金は続く」のが落とし穴になりやすいです。
課金を止めたいときは、基本的に 削除／自動更新OFF までセットで考えます。

停止と削除の違い（データが残る／消える）

ConoHaでは、ざっくり言うと次の整理が安全です。

操作	状態	料金	データ	使いどころ
停止（シャットダウン）	サーバーを止める	変わらない（発生し続ける）	基本そのまま	一時休止・メンテ・夜だけ止めたい
削除	サーバー自体を消す	削除時点までで止まる（時間課金の区切りになる）	消える（復旧不可）	もう使わない・課金を止めたい

ここが重要ポイント

• ⚠️ 停止しても料金が下がったり止まったりはしません。「使ってないのに請求が来た」原因の多くがこれです。
• ⚠️ 削除は取り消しできない前提で、必ずバックアップ（最低でもワールド/セーブと設定）を取ってから実行します。

おすすめの“安全な手順”

1. バックアップ（ワールド/セーブ・設定・MOD）
2. 停止（必要なら告知してから）
3. もう使わないなら削除（＝課金停止へ）
4. 長期割引系を使っているなら自動更新を必ずOFF（次項）

料金タイプ別の注意点（想定外請求を防ぐ）

ConoHaの課金は、どの料金タイプで契約しているかで“止め方”が変わります。
ここを押さえるだけで、損や事故が激減します。

時間課金（通常料金）の注意

• 停止では止まらないので、課金を止めるなら 削除が必要です。
• ただし短期利用なら便利で、月額を超えて請求されないよう自動計算される仕組みです（“上限”のイメージ）。
• 「解約したのに請求が来た」系は、削除した時点までの利用分が後から請求されるパターンが多いです。慌てず、確定まで待てばOKです。

長期割引パス（ConoHa for GAME）の注意

• 長期割引パスは前払いの性質が強いので、基本的に「買った期間」は使い切る前提が安全です。
• 自動更新がONのままだと、期限の前に自動決済されます。
  → 解約したい場合は、更新日までに自動更新をOFFにします。
• さらに安全策として、自動更新をOFFにするときに「設定先サーバー削除予約」を有効化できる場合があります。
  これを使うと、期限満了後にパスとサーバーが自動で削除されるので、「OFFにしたつもりだった」「削除し忘れてた」を防ぎやすいです。

まとめトク（ConoHa VPS）の注意

• まとめトクは長期契約の割引枠なので、即時削除できないケースがあります。
  → 先に 自動更新をOFFにして、契約の考え方に沿って終了させるのが基本線です。
• 「削除＝即解約」と思い込むとズレやすいので、“自動更新OFFが必要か”を必ず確認するのが事故防止になります。

“損しないためのチェック表”（3分で確認）

• □ いま契約しているのは 時間課金／長期割引パス／まとめトク のどれ？
• □ 停止だけになっていない？（＝料金は続く）
• □ 長期系は 自動更新がOFFになっている？
• □ 削除前に バックアップを取った？（復旧不可対策）
• □ 最終請求が来る可能性があるので、支払い設定はしばらく維持する？

友達に渡す情報の扱い（管理情報は渡さない）

マルチ運用でよくある事故は、「便利だから」と管理情報まで共有してしまうことです。
友達に渡す情報は、原則この範囲に絞ると安全です。

共有してOK（参加に必要な情報）

• サーバーの IPアドレス（またはホスト）
• ポート番号（変更している場合）
• 参加パス（Join Password）
• サーバー名（検索で見つける運用なら）

共有しない（運営・課金・乗っ取りにつながる情報）

• ConoHaの ログイン情報（アカウントID、パスワード、2段階認証系）
• 支払い情報（クレカ、チャージ等）
• サーバーの rootパスワード／SSH鍵
• 管理者パス（Admin系）や、管理コマンドを使える権限

運用のコツ（トラブル予防）

• 「参加パス」と「管理系のパス（運営用）」は必ず分ける
  → 参加者が増えても、運営の安全性が落ちにくいです。
• 管理権限を渡す必要があるなら、できるだけ限定的に
  → 例えば「再起動はできるが設定は触れない」など、“役割”で分ける発想が安全です。
• ⚠️ スクショ共有にも注意
  → 管理画面のスクショにIP以外の情報（ネームタグ、鍵、パス）が写り込むのがあるあるです。

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

他社との比較・乗り換え判断（迷った時の結論）

“テンプレで十分”な人／“自由度が必要”な人

迷ったら、まずは 「あなたが欲しいのは“最短で遊べること”か、“自由にいじれること”か」 で分けるのが一番早いです。
7 Days to Dieは運用が長くなるほど、バックアップや更新、MOD相性など“運営タスク”が増えやすいので、ここを先に決めるのが正解です。

テンプレで十分な人（＝運営を簡単にしたい） ✅
次のうち2つ以上当てはまれば、ConoHaのテンプレ系（または同系統のゲーム特化サービス）でOKです。

• とにかく 最短で建てて、すぐ友達と遊びたい
• SSHやLinuxの細かい作業は できれば避けたい
• 設定は“最低限”触れれば十分（サーバー名、パス、難易度など）
• まずは お試し で短期間だけ使う可能性がある
• 「困ったときは手順がまとまっている方が安心」

このタイプは、候補としては主に以下の“方向性”になります。

• ConoHa for GAME（7DTDテンプレ）：テンプレがあり、手順も揃っているので入り口が軽い
• ロリポップ！for Gamers（7DTD）：ブラウザ中心で設定を触れるタイプ（運営のハードルが低い）
• XServer GAMEs（7DTD）：ゲーム用に“すぐ建つ”系のサービス

「サーバー運営に慣れてない」「週末だけ遊べればOK」なら、まずこの路線が失敗しにくいです。✨

ロリポップ! for Gamers 公式サイト
XServer GAMEs 公式サイト

---

自由度が必要な人（＝自分で整備してでも快適にしたい） ✅
次のうち2つ以上当てはまれば、VPS寄り（＝rootやOS側を触れる運用）をおすすめします。

• MODを本格運用したい（大型オーバーホール／相性切り分けを自分でやりたい）
• ログや再起動、バックアップを 自分のルール で作りたい
• 7DTD以外のゲームも同じサーバーで回したい（用途拡張したい）
• パフォーマンス（ピーク負荷）を詰めたい（視界・湧き・同接の最適化）
• 「テンプレの更新待ち」がストレスになりそう

このタイプの候補は主に以下です。

• ConoHa VPS（Ubuntu手動）：自由度MAX（あなたの作りたい運用を作れる）
• XServer VPS for Game（7DTDイメージ）：導入は短く、運用はVPS寄り（“簡単＋自由”の中間）
• KAGOYA CLOUD VPS（7DTD向け）：日額課金の柔軟さが魅力（遊ぶ頻度が変動する人に刺さる）

XServer VPS for Game 公式サイト
KAGOYA CLOUD VPS 公式サイト

---

迷った時の“結論テンプレ”（判断を強制的に早くする）

• 「今週末に絶対遊びたい」→ テンプレ系（立ち上げ成功率が高い）
• 「長期運用して、運営も上手くなりたい」→ VPS寄り（後から効いてくる）
• 「月によって遊ぶ量がブレる」→ 日額課金がある系 を検討
• 「海外勢と遊ぶ／海外ロケーションが重要」→ 海外ゲームホスト（ただし日本からの距離＝遅延は要確認）

移行の考え方（ワールド・設定・MODの持ち運び）

乗り換えは、やること自体はシンプルです。
ただし“雑にやると壊れる”ので、順番だけ守るのがコツです。

持ち運ぶものは基本3点セット（これで“同じサーバー”を再現できます）

• ワールド／セーブ（Saves）：進行状況そのもの
• 設定（serverconfig.xml）：サーバー名、パス、最大人数など
• MOD（Mods）：導入している場合のみ

移行で一番やらかしやすいポイント ⚠️

• サーバーとクライアントのバージョンが揃っていない
• MODの有無が揃っていない（“サーバーだけMOD”なのか“全員導入が必要”なのか混ざる）
• 旧サーバーを止めずにコピーして セーブが壊れる／巻き戻る

---

移行の安全手順（テンプレ）（停止→退避→新環境へ→起動確認）

1. 移行日を決めて告知（プレイ中の書き込みが止まるタイミングを作る）
2. 旧サーバーを停止
   • 例：systemctl stop 7dtd（systemd運用の場合）
3. バックアップ（3点セットを固める）
   • serverconfig.xml
   • Saves一式
   • Mods一式（使っているなら）
4. 新サーバー側に7DTDを用意（ここが重要）
   • 旧サーバーと同じバージョン に揃える（まずここ）
5. 新環境へファイルを配置
   • Savesを所定の保存場所へ
   • serverconfig.xml を差し替え
   • Modsを正しい階層で配置（Mods/Mod名/ModInfo.xml が見える形）
6. ポート開放（ConoHaのセキュリティグループ／OSのFW）
7. 起動→ログ確認→運営者が入室テスト→OKなら友達へ共有

---

保存場所が分からないときの“確実な探し方”（初心者向け）

• serverconfig.xml に 保存先のヒント（UserDataFolder / SaveGameFolder 等）があることが多いです
• 分からなければ「Saves」をサーバー内検索して、“更新日時が新しい方”を採用すると事故が減ります

---

MOD移行の注意（同じ環境を再現したい人向け）

• まず新環境で MODなし起動→正常 を確認してからMODを戻す
• 大型MODは、サーバーだけで完結しないことがあります
  • その場合は「参加者側の導入」や「EACの扱い」まで含めて手順を揃えます
• 乗り換え先が“ゲームホスティング（管理画面中心）”の場合、ファイル配置の自由度がVPSより低いことがあります
  • MOD可否、アップロード方法（FTP等）、反映手順を先に確認すると手戻りが減ります

---

最後に：乗り換え判断の“損しない”コツ 💡

• いきなり本番移行せず、検証用に1回だけ新サーバーで起動してみる（同じワールドが動くか）
• “合わなければ戻す”前提で、旧サーバーは 数日だけ残す（時間課金なら特に保険になる）
• 「快適さ」を決めるのはスペックだけでなく、運営のラクさ（更新・バックアップ・復元）です

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

参考情報・公式（最新仕様の確認先）

ConoHa公式サポート／ドキュメント

「情報が古くて詰まる」を避けるには、ConoHa公式の“手順ページ”と“仕様ページ”をブックマークしておくのがいちばん確実です。特に7 Days to Dieは更新頻度が高く、クライアントとサーバーのバージョン差で参加できなくなることがあるので、確認先を固定しておくと強いです。

1) 作り方・入り方（まずここ）

• ゲームテンプレの利用手順：管理画面での作成〜参加方法（IP／ポート／JOINパスの確認）までがまとまっています
• VPSアプリイメージの利用手順：初回起動で時間がかかる理由（ワールド生成）や、ログイン後に表示される motd（接続情報・設置場所） の見方が載っています

2) “いまの仕様”を確認（OS／7DTDバージョン／最低要件）

• VPSアプリイメージのページには、インストールOS や 主要ソフトウェア（7DTDのバージョン） が明記されることがあります
• ゲーム用イメージのドキュメントには、利用ポート や Minimum RAM がまとまっていることがあります
• 「自分の環境が“テンプレ”なのか“VPSイメージ”なのか」で、載っているページが変わるので注意

3) ポート・セキュリティ（接続できない原因の大半）

• 7DTD向けに用意された セキュリティグループ（開放ポートの一覧） を必ず確認
• 追加でSSH等を使う場合は、ゲーム用ポート以外も必要になるので、開けるポートを増やす前提でドキュメントを見る

4) 料金とコスト最適化（“損しない”確認先）

• ConoHa for GAMEの料金ページ：時間課金・長期割引パスの扱いが公式説明で確認できます
• ConoHa VPSの料金・スペックページ：VPS運用（ルートB/C寄り）の場合、プラン差・上限・割引（まとめトク等）をここで把握できます
• 料金はキャンペーン等で変動しやすいので、スクショ保存より“ページを都度見る”のが安全です

5) 障害・メンテ（“今日遊べる？”の確認先）

• ConoHaはコントロールパネル内の 「お知らせ」 に、メンテ／障害などが掲載される案内があります
• 「急に入れない」「再起動が頻発」などは、まずここを見て“自分だけの問題か”を切り分けると早いです

6) アップデートの遅れ・手動更新（公式の注意書きがある）

• テンプレ更新は検証を挟むため、ゲーム側の最新リリースから 反映まで時間差が出ることがあります
• その場合、手動アップデートの公式手順が用意されていることがあるので、更新が必要なときはそこを参照
• 実行前にバックアップ推奨、などの“事故りやすい注意”も書かれているので、自己流で走るより安全です

コミュニティWiki・アップデート情報の追い方

ConoHa側の仕様（テンプレの7DTDバージョン等）と、ゲーム本体の更新（クライアント／Dedicated Server）を別物として追うのがコツです。
「公式→（必要なら）コミュニティ」の順で追うと、情報の精度が上がります。

1) 公式で追う（最優先）

• Steamニュースハブ：開発元の更新告知・パッチノートがまとまる（まずここ）
• 公式サイトのNews／Release Notes：大型アップデートの内容や要点を把握しやすい

2) Dedicated Serverの更新を追う（“バージョン不一致”の早期発見に効く）

• SteamDBのDedicated Server（App）のパッチノートを見ると、サーバー側の更新タイミングを追いやすいです
  • 「クライアントは更新されたのに、サーバーが追いついてない？」みたいな状況の判断材料になります

3) 設定・運営の辞書（serverconfig.xml等）

• Official Wiki（wiki.gg） は、serverconfig.xmlの項目を引く“辞書”として便利です
  • 値の意味を調べるときは、検索より「公式Wikiで該当項目を探す」方がブレが少ないです
• SteamCMDなど“建て方の一般論”は、Valve Developer Community のDedicated Serverページが基礎資料として役立ちます（ConoHa以外でも通用）

4) 実務的な“追い方テンプレ”（迷ったらこれ）

• ステップA：Steamニュース（公式）で 最新の公開状況 を確認
• ステップB：ConoHaのドキュメントで 自分のテンプレ/イメージの7DTDバージョン を確認
• ステップC：差があるなら「待つ／手動更新する／一時固定する」を判断
  • 友達と遊ぶ予定があるなら、“同じ版で揃える”を最優先（先に更新した人が入れなくなるのが典型パターンです）

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

まとめ

ConoHaで7 Days to Dieを運用するうえで大事なのは、スペックや手順の暗記ではなく、迷いどころを先に潰して“事故らない型”で回すことです。

今回のポイントを要点だけ振り返ります。

• for GAMEは「最短で遊ぶ」向き
  • テンプレで迷いが少なく、サーバー初心者でもスタートしやすい
• VPSは「自由度と運用力」重視向き
  • MOD・更新・自動起動・ログ確認・バックアップなどを自分のルールで固めやすい
• 迷ったら、まずは 「人数／MODの有無／更新への強さ／作業量／コスト」 で判断する
• 参加で詰まる原因はだいたい3つ
  • IP・ポート・参加パスの伝え間違い
  • ポート開放やFWの設定漏れ
  • バージョン不一致（安定版／実験版の混在）
• 安定運用のコツは「保守の習慣化」
  • 更新前にバックアップ
  • 定期再起動の時間帯を決める
  • ログ／ディスク／メモリの最低限チェック
• 課金で損しないために、停止と削除（解約）の違いは最初に把握しておく

もしあなたが「今夜すぐ友達と遊びたい」なら、まずは for GAMEで最短スタートが堅実です。
一方で「MODや長期運用を見据えて、運営も含めて快適にしたい」なら、VPS運用（またはVPS寄りルート）に寄せると後悔が少なくなります。

最後にひとつだけ。料金やプラン、テンプレの仕様、必要ポート、アップデート手順は変わることがあります。記事の手順を進めるときは、必ず公式の最新情報も確認しながら進めてください。
その上で、このロードマップ通りに「建てる→入る→安定して回す」までを一度経験すれば、次からは驚くほどスムーズに運営できるようになります。

あなたの7 Days to Dieマルチが、“毎回つまずく”から“気持ちよく遊び続けられる”に変わるきっかけになれば嬉しいです。

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