Satisfactory×ConoHa完全ガイド｜マルチ用の立て方・参加方法・運用まで

2026年2月14日

Satisfactoryのマルチは、友だちと遊び始めた瞬間は最高なのに、少し進むとこんな壁に当たりがちです。

「ホスト&プレイだと、ホストが落ちたら全員入れない…常設したい」
「専用サーバーって難しそう。結局どれを選べばいいの？」
「ConoHaで立てられるらしいけど、テンプレ？ VPS？違いがわからない」
「IPとポートって何？ Steam/Epicで参加方法は同じ？」
「つながらない／一覧に出ない／証明書が出て怖い…最短で直したい」
「工場が重くなるとラグる？メモリは何GBが安全ライン？」
「アップデートで入れなくなるのが不安。バックアップって何をどう取ればいい？」
「止めたら課金は止まる？ムダ課金せずに試す方法が知りたい」

このページは、そうした“最初の不安”から“常設運用のコツ”までを、1本でつなげるための完全ガイドです。
ConoHa（主にConoHa for GAMEのテンプレ運用）を軸に、必要ならVPSでの自前構築まで触れながら、初心者が詰まりやすいポイントを先回りして整理しました。

この記事を読み終えるころには、次の状態を目指せます。

最短ルートでマルチ用サーバーを立てて、Steam/Epicから参加できる
人数ではなく“工場の重さ”で考えて、後悔しにくいプランを選べる
オートセーブ／再起動／ネットワーク品質など、最低限の設定で快適化できる
更新・バックアップ・トラブル対応まで、慌てず自走できる

公式の一次情報（ConoHa公式ドキュメント・サポート、Satisfactory側のDedicated Server情報）をベースに、実運用でつまずきやすい「判断のしかた」もセットで解説していきます。

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

この記事のゴール（できるようになること）

最短でマルチ用サーバーを立ち上げて参加できる

ConoHa（とくに ConoHa for GAME の「Satisfactoryテンプレート」）を使うと、いわゆる“専用サーバー（Dedicated Server）”を ほぼ手順どおりに作るだけでマルチを始められます。ここでは「最短でつながる」流れだけに絞って整理します。

最短ルート（やることは4つ）✅

ConoHa for GAMEでサーバー作成
- コントロールパネルで「GAME」→「サーバー追加」
- イメージ（テンプレート）で Satisfactory を選ぶ
- 作成後、サーバー一覧から IPアドレス を控える
ゲーム側でサーバーを追加（Satisfactory）
- ゲームを起動 → サーバー管理 → サーバー追加
- アドレス：控えたIP
- ポート：7777（まずここを疑わない）
- 証明書のポップアップが出たら内容を確認して進む
初回設定（サーバー名・管理者パス）
- サーバー名を入力
- 管理者パスワードを設定（忘れないようにメモ）
ゲームを開始 → 合流
- 「ゲーム作成」でマップやセッション名を決めて開始
- 参加者には IP（＋必要なら参加用パス） を共有

つまずきやすいポイント（先回り）🧩

初回起動は待ち時間が出ることがあります（ワールド生成などで数分かかるケース）
「追加できたのに入れない」場合は、まず
- IPの入力ミス
- ポートが 7777 になっているか
- サーバーが“起動中”の状態か
  を確認すると、解決が早いです。

人数・工場規模に合わせて“後悔しないプラン”が選べる

Satisfactoryは、人数よりも 工場が育った後の負荷（オブジェクト量・セーブデータ・自動化の密度） で重くなりがちです。なのでプラン選びは、ざっくり言うと 「メモリ重視」 が安全です。

公式情報ベースの目安（結論）🎯

テンプレートは メモリ1GB以上で利用可能
ただし快適性の観点では、16GB以上が推奨されています
- 迷ったら 16GB を起点にすると失敗しにくいです

料金タイプは2系統（ここも大事）💡

時間課金：短期テストや週末だけ遊ぶ人向け（使った時間ぶん）
長期割引パス：1か月以上しっかり遊ぶ人向け（期間で割引が大きい）
- 途中解約できない・一括前払いなど条件があるので、申し込み画面の注意事項は必ず確認してください。

プラン比較（時間課金の表示例・公式ページ掲載の代表値）
※表示価格は改定やキャンペーンで変わることがあるため、最終確認は公式でお願いします。

スクロールできます

メモリ	月額（目安）	時間（目安）	こんな人に向く
8GB	8,083円/月	14.5円/時	小規模で様子見（ただし後半で重くなりやすい）
16GB	15,730円/月	26.6円/時	迷ったらここ：安定と快適性のバランス
32GB	31,460円/月	53.2円/時	大規模工場・長期運用・重さ対策を先取り

“後悔しない”ための選び方（超実用）🧠

短期（数日〜2週間）：時間課金で16GBを試す → 重さの傾向を見る
長期（1か月以上）：長期割引パス＋16GB以上を検討
「最近カクつく」「ロードが重い」が出てきたら、まず
- ネットワーク品質を上げすぎていないか
- オートセーブ間隔が短すぎないか
  を調整し、それでも辛ければ メモリ増量が効果的です。

アップデート/バックアップ/トラブル対応まで自走できる

ここは“運用の型”さえ作れば、初心者でも回せます。ポイントは ①バックアップ → ②更新 → ③再起動 の順番です。

1) バックアップ（最優先）🛡️

更新や設定変更の前に、イメージ保存（スナップショット等）を取る
最低限のルール
- 大型アップデート前：必ず取得
- 設定を触る前：必ず取得
- うまくいった状態を“復元ポイント”として残す

2) アップデート（テンプレには自動更新機能がある）🔧

ConoHaのSatisfactoryテンプレートには 自動バージョンアップ機能があります
ただし デフォルトでは動かない設定なので、使う場合は自分で有効化します

有効化の流れ（やっていることは「停止→設定変更→反映→起動」）

# サーバー停止
systemctl stop satisfactory-server.service

# 自動バージョンアップを有効化（サービス設定を書き換え）
sed "s/^# ExecStartPre/ExecStartPre/" -i /etc/systemd/system/satisfactory-server.service

# 設定反映
systemctl daemon-reload

# サーバー起動
systemctl start satisfactory-server.service

💡 注意：更新時はダウンロード/差し替えが走るため、いつもより起動が遅くなることがあります。焦って連打せず、状態確認→待機が安全です。

3) “最低限いじると効く”サーバー設定（快適性に直結）⚙️

参加用パスワード：未設定だと誰でも入れる可能性があるので、基本は設定推奨
オートセーブ間隔：短すぎると重く感じることがある（負荷と安全性のバランス）
サーバー再起動間隔：定期再起動で安定しやすい
ネットワーク品質：上げると良い面もあるが、サーバーFPSが下がる可能性がある（上げすぎ注意）

4) トラブル対応（まずこの順で切り分け）🧯

① IPが合っているか（コピペ推奨）
② ポートが7777か
③ 初回なら 数分待ったか（ワールド生成など）
④ 証明書ポップアップで止まっていないか
⑤ 追加したサーバーの状態が“起動中”か

5) セキュリティ（SSH/SFTPを使うなら設定が必要）🔐

ConoHa for GAMEは、セキュリティグループ（仮想ファイアウォール）で ゲームに必要なポート以外が制限されています。
設定ファイル調整やデータ操作で SSH/SFTP を使いたい場合は、SSH用の通信許可を追加してから行いましょう。
- 不要なら開けない＝安全、が基本です。

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

前提知識：Satisfactoryマルチの方式は3つ

方式A：ホスト&プレイ（手軽だが、ホスト依存）

いわゆる「いつものセーブデータで、ホストがオンラインセッションを立てて友達を招待する」方式です。
専用サーバーを用意しないので、初心者でも始めやすいのが最大の魅力です。

メリット

✅ 最速で始められる（サーバー契約や設定が不要）
✅ 追加コストが基本ゼロ
✅ ワールド管理がシンプル（ホストのセーブデータが基準）

デメリット

⚠️ ホストがいないと遊べない（ホストPCが停止＝ワールドも停止）
⚠️ 工場が大きくなるほど、ホスト側の負荷が増えやすい
⚠️ 回線・PC性能が弱いと、参加者側のラグや不安定さが目立つことがある

向いている人

まずは気軽にマルチを試したい
「週末に数時間だけ」など、稼働時間が短い
工場がまだ小規模（序盤〜中盤）

方式B：手元PCで24時間サーバー運用（自由だが難易度高め）

自宅PCや手元のマシンで Dedicated Server（専用サーバー）を自分で立てるやり方です。
「お金をかけずに24時間化」できる可能性はありますが、やることが増えます。

メリット

✅ 月額のサーバー料金を抑えられる（手元の機材で回せるなら）
✅ 設定や構成の自由度が高い（運用を自分好みにできる）
✅ うまく回せれば 24時間稼働 も可能

デメリット（初心者が詰まりやすい点）

⚠️ PCをつけっぱなし（電気代・騒音・熱・故障リスク）
⚠️ ネットワーク設定が必要（ルーター設定/ポート開放、セキュリティ対策など）
⚠️ アップデート・バックアップ・再起動管理が全部自分
⚠️ 回線の上り（アップロード）が弱いと、人数が増えるほど不利

向いている人

PC/ネットワークの設定に抵抗がない
サーバー運用を学びたい・試行錯誤が楽しい
すでに常時稼働できるマシンや環境がある

方式C：VPS/ゲームサーバー（安定・24時間向き）

外部のサーバー（VPSやゲーム向けサービス）を借りて Dedicated Serverを動かす方式です。
ホスト不在でもワールドが動くので、マルチが一気に快適になります。

メリット

✅ 24時間稼働しやすい（ホストの都合に左右されない）
✅ 友達が好きな時間にログインできる
✅ 自宅回線やホストPCへの負荷を切り離せる
✅ 工場が大きくなっても「ホストのPCが限界」という問題が出にくい

デメリット

⚠️ 月額（または時間）コストが発生
⚠️ まったくのゼロ設定ではない（最低限の初期設定・運用は必要）
⚠️ どのサービスを選ぶかで、手間と自由度が変わる

ConoHaでの位置づけ（初心者が迷わない整理）

ConoHa for GAME（ゲームテンプレ）：最短で立てたい人向け（作成〜接続がわかりやすい）
ConoHa VPS：自由度優先（細かく作り込みたい人向け）

ConoHaを選ぶときの判断基準（何を優先するか）

「ConoHaが合うかどうか」は、結局 あなたの優先順位で決まります。
ここでは初心者でも判断できるように、基準をチェックリスト化します。

1）最優先が“手軽さ”なら

✅ ゲームテンプレで最短スタートしたい
✅ サーバー構築の手順をできるだけ省きたい
→ ConoHa for GAME（Satisfactoryテンプレ）が向きやすい

2）最優先が“コスト最適化”なら

✅ 数日〜1週間の短期：時間課金でムダを抑えたい
✅ 1か月以上の長期：長期割引パスで安くしたい
→ ConoHaは「遊び方に合わせて料金タイプを選べる」点が判断材料になります

3）最優先が“自由度（カスタマイズ）”なら

✅ サーバー設定を細かく触りたい
✅ ほかの用途にも使いたい（別ゲーム/検証など）
→ VPS系（root権限・SSHなど）を使えるかがポイント（ConoHa for GAMEはVPSタイプで自由度寄り）

4）最優先が“安定運用”なら

✅ ホストのPC性能や在席に依存したくない
✅ 友達がいつ入っても動いている状態にしたい
→ Dedicated Server（方式C）そのものが最適解になりやすく、ConoHaはその選択肢の一つ

5）最優先が“安全に運用できること”なら

✅ 不要な通信は閉じておきたい（ポート管理を意識したい）
✅ バックアップ（イメージ保存等）で戻せる状態を作りたい
→ 管理機能・セキュリティ機能・バックアップ手段が用意されているかを見ます

迷ったときの結論（初心者向けの選び方）

とりあえずマルチを体験したい → 方式A
24時間化したいが費用は抑えたい＆自信がある → 方式B
24時間化を現実的に、安定して回したい → 方式C（ConoHa含む）

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

ConoHaで建てるルートは2通り：どっちを選ぶ？

ルート1：ConoHa for GAME「Satisfactoryテンプレ」（初心者・最短向け）

ConoHa for GAMEのテンプレートは、サーバー追加と同時にSatisfactoryのマルチ用サーバー（Dedicated Server相当）まで“ほぼ出来上がる”のが強みです。
初心者がつまずきやすい「導入の分岐」と「初期設定の見落とし」を減らせます。

このルートがラクな理由（初心者目線）

✅ 最短で開始：テンプレ選択 → サーバー作成 → ゲーム側にIPとポートを入れる、が主線
✅ 運用の導線が用意されている：サーバー設定（パスワード、オートセーブ、再起動間隔など）を画面側で触れる
✅ “最低限の安全策”に気づきやすい：例）初期状態では参加パスワードが未設定なので、設定推奨…など

テンプレ利用時に知っておくべきポイント（短く要点だけ）

接続は基本「IPアドレス + ポート7777」が軸
初回起動時にサーバー側でワールド生成が走り、数分かかる場合があります
ゲーム用途以外のポート（例：SSHの22番）を使いたいなら、事前に通信許可（セキュリティグループ）が必要です

料金の考え方（初心者が迷いやすい所だけ）

ConoHa for GAMEは料金タイプが2つあります
- 長期割引パス：1か月以上の運用向き（期間が長いほど安くなる傾向）
- 時間課金：短期・週末利用向き（使った分だけ。月額上限がある）

「まず試す」なら、時間課金で2〜7日まわして感触を見る → 良ければ長期割引パス、が失敗しにくいです。

ルート2：ConoHa VPSでゼロから構築（自由度優先・上級者向け）

こちらは「ConoHa VPSを借りて、OS選定 → SteamCMD等でDedicated Server導入 → 常駐化 → 更新運用」までを自分で行うルートです。
テンプレの“手軽さ”を捨てる代わりに、自由度と拡張性を取りにいきます。

このルートで得られる自由度

✅ OSや構成を自分で決められる（他のサービス・監視・バックアップ設計なども組み込みやすい）
✅ 運用を自動化しやすい（更新、再起動、ログ管理、バックアップの世代管理など）
✅ “困ったときの調査”がしやすい（ログ、プロセス、ディスク、ネットワークを自分の流儀で追える）

その代わり増える作業（ここが上級者向け）

⚠️ Dedicated Server導入の手順とトラブルシュートが必要
⚠️ 常時稼働のための作法（systemd化、定期再起動、バックアップ運用）が必要
⚠️ セキュリティや通信周りを自分で設計する必要がある（開けるポートを最小化、管理経路の保護など）

初心者が選ぶと遠回りになりやすいケース

「とにかく今夜マルチしたい」
「Linuxやコマンドが不安」
「更新やバックアップの設計に自信がない」
→ この場合は、まずテンプレで“遊べる状態”を作ってからでも遅くありません。

結局おすすめはどっち？（目的別の結論）

迷ったら、次の結論でOKです。
“速さ”と“確実性”を取るか、“自由度”を取るかで決まります。

結論1：初心者の最適解はルート1（テンプレ）

✅ 初回の成功確率が高い
✅ 運用も「画面で触れる範囲」が広く、学びながら続けやすい
✅ 短期なら時間課金で試しやすい

結論2：次の条件に当てはまるならルート2（ゼロ構築）

✅ サーバー運用が趣味／学習目的で、試行錯誤が苦にならない
✅ ログ監視や自動バックアップなど、運用を自分で作り込みたい
✅ 将来、別ゲームや別用途にも転用したい

迷いを終わらせるための早見表（どっちが自分向きか）

スクロールできます

比較ポイント	ルート1：テンプレ	ルート2：ゼロ構築
始めるまでの速さ	速い（最短）	遅い（手順が多い）
必要スキル	低〜中	中〜高
失敗しにくさ	高い	低〜中（経験で改善）
運用の自由度	中（用意された範囲）	高い（設計し放題）
トラブル対応	画面＋最低限の知識でOK	ログ調査・切り分けが必要
おすすめ像	「すぐ遊びたい」「初サーバー」	「作り込みたい」「運用を楽しめる」

実用的な“折衷案”（独自のおすすめ）

いきなり完璧を狙うより、次の順番が現実的で失敗が少ないです。

テンプレ（ルート1）で最短起動して、友達と遊べる状態を作る
1〜2週間運用して、
- 重くなるタイミング
- 再起動やバックアップの頻度
- 更新で止まりやすい箇所
  を体験として掴む
「もっと自由に運用したい」と感じたら、ゼロ構築（ルート2）へ移行する

こうすると、“サーバーを立てたのに結局遊べない”を避けつつ、段階的にレベルアップできます。✨

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

プラン選びの最重要ポイント（ここで失敗しがち）

まず見るべきはメモリ（人数より“工場の重さ”が効く）

Satisfactoryの専用サーバーは、「何人で遊ぶか」よりも「工場がどれだけ巨大か」で重さが変わりやすいです。
序盤は軽いのに、中盤以降（ベルト・パイプ・発電・物流が増える頃）から急に重くなるのはこのためです。

メモリ不足が起きると…（よくある症状）

✅ セーブ/ロードが妙に長い
✅ 建築が増えたあたりからカクつきやすい（特に拠点周辺）
✅ 参加者がワープする・同期がズレる（ラバーバンド）
✅ サーバーが落ちる/再起動が必要になる頻度が増える

結論：迷ったら“16GB以上”が無難
ConoHaのSatisfactoryテンプレート自体は小容量でも動きますが、快適運用の目安として 16GB以上が推奨されています。

ざっくりの選び方（失敗しにくい目安）

まずは16GB：少人数〜中規模の工場で長く遊ぶ「標準解」
32GBへ拡張：人数が増える／工場が巨大化する／常時稼働で安定性重視
8GBは“短期検証向け”：序盤やテストには便利でも、進行で限界が来やすい（後から上げる前提ならアリ）

💡ポイント：同じ人数でも、ベルト・パイプ・車両・設備密度が高いほど“重いワールド”になりやすいです。
「4人だけど超巨大工場」みたいなケースは、人数の割にメモリが必要になります。

CPU・ストレージ・ネットワークはどこまで必要？

ここは「最低限押さえればOK」です。過剰に悩むより、メモリを優先した方が後悔しにくいです。

CPU（コア数よりも“処理の太さ”が効きやすい）

専用サーバーは一般に、コア数が増えるほど万能に軽くなるというより、処理が集中しやすい場面があります。
ConoHa for GAMEはプランごとにCPUコア数が決まっているので、まずは次の関係を把握しておけばOKです。

ストレージ（容量より“速度”）

Satisfactory専用サーバーは、ワールドの保存や読み込みがあるので、SSD（NVMe）のほうが体感が良くなりがちです。
ConoHa for GAMEはNVMe SSD（100GB）が付くため、容量面で困ることは多くありません。

ただし、次は増えがちです👇

セーブデータが増える（オートセーブ含む）
バックアップを残しすぎる
複数ワールド運用

👉 運用ルール例

オートセーブは「間隔を少し長め」＋「世代数を絞る」
大事な区切りだけ別途バックアップ（ダウンロード/イメージ保存など）

ネットワーク（“回線の安定”が超重要）

マルチは回線の揺れがあると体感が悪化します。
またConoHaのドキュメントでも、ネットワーク品質を上げるとロードや通信が改善する一方、サーバー負荷でフレームレートが落ちる可能性が示されています。

👉 おすすめ運用

まずはデフォルトで開始
「ロードが遅い/同期が悪い」時だけネットワーク品質を上げて検証
上げた途端にカクつくなら、無理に上げず戻す（サーバー側が先に限界）

目安の考え方：少人数スタート→増えたらスケールの手順

「最初から高額プランで固定」より、16GBで始めて必要になったら上げるのが現実的です。

スケール判断のチェック（上げ時）

次が複数当てはまったら、32GBを検討すると失敗しにくいです。

✅ 拠点周辺で常に重い（人が集まると特に悪化）
✅ セーブ/ロードが長い、または失敗することがある
✅ プレイヤー増加（参加頻度が高い）＋工場も拡大中
✅ 長時間稼働で「安定性」を最優先したい

スケールの基本手順（安全第一）

バックアップを取る（事故対策）
サーバーを止める（データ破損防止）
プラン変更（上位へ）
起動して動作確認（参加・セーブ・ロード・ラグ感）

💡“何かする前にバックアップ”が一番コスパ良いです。
自動アップデートを有効化する場合も、事前バックアップが推奨されています。

短期テスト運用と長期運用で“コスパ”が変わる理由

ConoHa for GAMEは料金タイプが大きく2つあります。
遊ぶ期間で選ぶと失敗しません。

時間課金：数日〜2週間くらいの短期向き（使った分だけ）
長期割引パス：1ヶ月以上の長期向き（長いほど割引率が上がる）

さらに時間課金は、月額上限が設定されているため、つけっぱなしの事故にも一定の安心があります。

時間課金（通常料金）の目安（抜粋）
※「どのプランを選ぶか」の判断材料として代表的なところだけ載せます。

スクロールできます

メモリ	CPU	ストレージ	時間課金の目安
8GB	6コア	NVMe SSD 100GB	14.5円/時（上限：8,083円/月）
16GB	8コア	NVMe SSD 100GB	26.6円/時（上限：15,730円/月）
32GB	12コア	NVMe SSD 100GB	53.2円/時（上限：31,460円/月）

結論（コスパ判断）

週末だけ・イベントだけ → 時間課金
しばらく継続（1ヶ月以上） → 長期割引パス（キャンペーン込みで差が出やすい）

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

最短ルート：ConoHa for GAMEテンプレでサーバーを用意する

準備チェック（必要なもの・決めておくこと）

最短で成功させるコツは、「作る前に決めること」を先に固めることです。
ここが曖昧だと、立てたあとに「誰が管理者？」「パスどれ？」「セーブどうする？」で混乱しがちです。

サーバー名の方針／管理用パス／参加用パス

まず、名前とパスワードは“用途が違う”ので分けて考えると事故りません。

サーバー名（表示名）
- 例：Atsushi_Factory_01 / Satis_友達用_常設
- ✅ おすすめ：目的＋識別子（「誰の」「何用」かが一瞬で分かる）
管理用パス（管理者パス）
- サーバー設定を触れる“管理者用”
- ✅ おすすめ：他と使い回さない／長めにする
- 🔒 共有は最小限（基本は運営者だけ）
参加用パス（プレイヤー用パス）
- 参加者が入るための“入室パス”
- ✅ おすすめ：必ず設定（デフォルトで未設定の場合があるため）
- 👥 共有はDMなどで（公開チャットに貼らない）

💡混同ポイント：
「サーバー名」と「セッション名（ワールド側の名前）」は別物です。
サーバー＝入る先／セッション＝中で遊ぶワールド、というイメージでOKです。

プレイ予定人数／稼働時間／セーブ方針

ここは“途中で変わってもいい”ですが、初回だけでも方針があると運用がラクになります。

プレイ予定人数
- 最初は「普段集まる最大人数」でOK
- 例：2〜3人中心／週末は最大6人…など
稼働時間（どれくらい常設する？）
- 例：毎日24時間／夜だけ／週末だけ
- 💰 料金タイプ選び（時間課金 or 長期割引）の判断材料になります
セーブ方針（事故対策）
- ✅ 最低限おすすめ：
  - オートセーブ間隔を設定
  - 大きな作業前はバックアップ（イメージ保存等）を取る
- 🧠 ルール例：
  - 「大型改装前」「アップデート前」は必ずバックアップ

サーバー作成（コントロールパネル操作）

ここは公式の手順どおりに進めればOKです。ポイントは テンプレ選択 → 作成 → IP控える の3点。

「GAME」からサーバー追加 → テンプレでSatisfactoryを選ぶ

ConoHaのコントロールパネルで 「GAME」 を選択
「サーバー追加」 をクリック
イメージタイプ（ゲーム）から Satisfactory を選んで作成

迷いやすいのはここ👇

「VPS」ではなく、まず 「GAME」側から入る（テンプレ運用の最短ルート）

サーバーが立ち上がったらIPアドレスを控える

作成後、サーバーの接続に必要な情報は IPアドレス です。

「GAME」→ 左メニュー「サーバー」→ 対象サーバーのIP を控える
参加者に渡すのも基本はこの IP（＋必要なら参加用パス）

初回起動で時間がかかるケースと見分け方

初回はサーバー側でワールド生成が走るため、約5分ほど時間がかかる場合があります。

「失敗」と勘違いしやすい状態

サーバーが“稼働中”なのに、ゲーム側で見つからない／参加できない
追加はできたが、入ろうとすると不安定

見分けのコツ（初心者向け）

作成直後はまず 5分待つ（焦って設定をいじらない）
その後、ゲーム側のサーバー管理で 再読み込み／再試行
それでもダメなら「通信設定（次項）」をチェック

通信設定（つながらない原因の大半はここ）

マルチの“つながらない”は、体感として 設定ミスより通信許可（ポート）が原因になりやすいです。
ConoHa for GAMEはサーバーごとに セキュリティグループ（仮想ファイアウォール）で通信を制御します。

必要ポートの整理（ゲーム用／管理用）

初心者は、まず「ゲームが使うポート」と「管理に使うポート」を分けて覚えると混乱しません。

スクロールできます

用途	ポート	プロトコル	いつ必要？
ゲーム接続の中心	7777	TCP/UDP	ほぼ必須（まずここ）
Web/管理系（テンプレ側の機能で使われることがある）	8888	TCP	既定のセキュリティグループに含まれる
Beacon/補助	15000	UDP	環境によって使われる（既定に含まれる）
Query（クライアントUIで参照される既定ポートが別にある）	15777	UDP	環境によって使われる（既定に含まれる）
SSH（サーバーにログインして作業）	22	TCP	必要な人だけ（使わないなら閉じてOK）

✅ 結論：テンプレで普通に遊ぶだけなら、まずは
Satisfactory用の既定セキュリティグループが正しく付いているか を確認するのが最短です。
逆に、SSHやSFTPで触りたい場合は 22番の許可が別途必要になります。

ConoHa側のセキュリティ設定で許可すべき通信

セキュリティグループは「どのポートを開けるか」「どのIPから許可するか」を設定できます。

初心者向けの安全運用（おすすめ）

🎮 ゲーム用：Satisfactory用セキュリティグループ（既定）を利用
🔧 SSHを使う場合だけ：
- 22番を開ける
- 可能なら 自分の固定IPだけ許可（IP/CIDRで絞る）
❌ 不要なポートは増やさない（開けるほど攻撃面が増える）

「つながらない」時の最短チェック順

サーバーの IPアドレス を控え間違えていないか（コピペ推奨）
ゲーム側の接続ポートが 7777 になっているか
対象サーバーに Satisfactory用セキュリティグループが付いているか
初回起動直後なら 5分待ったか（ワールド生成の待ち）

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

参加手順：ゲーム側からサーバーを登録して入る（Steam/Epic）

サーバー追加に必要な情報（IP・ポート・確認ポイント）

まず、ゲーム側で「サーバー追加」に必要なのは たった2つです。

IPアドレス：ConoHaで作成したサーバーのグローバルIP
ポート：7777

加えて、失敗しやすいので「事前チェック」も最初に押さえておくと迷いません。

入力情報（これだけ覚えればOK）

スクロールできます

項目	何を入れる？	ありがちなミス
アドレス	ConoHaのサーバーIP	半角/全角、コピペ漏れ、古いIP
ポート	7777	15777などを入れてしまう、空欄のまま

追加前の確認ポイント（詰まりやすい順）

✅ ConoHa側のサーバーが「稼働中」になっている
✅ 作成直後なら 5分ほど待った（初回はワールド生成で時間がかかることがあります）
✅ ConoHa側でサーバーに Satisfactory用のセキュリティグループが付いている
✅ 友達が入れないときは、まず IPのコピペと ポート7777を再確認（ここが最多）

Steam/Epicの違いは？

起動元がSteamでもEpicでも、操作は基本的に ゲーム内の「サーバー管理」から同じ流れで進みます。

初回だけ必要なセットアップ（名前・管理者パスなど）

サーバーを追加すると、初回だけ「そのサーバーの持ち主（管理者）」としての設定が求められます。
ここを雑に決めると、あとで「管理できない」「誰が管理者？」になりがちなので、短くても丁寧に決めましょう。

初回セットアップの流れ（ゲーム内で完結）

ゲームを起動 → サーバー管理 を開く
画面下の サーバー追加
アドレス（IP） と ポート（7777） を入力 → 確認
サーバー証明書の確認が出たら内容を読んで進める
サーバー名を入力（一覧で見分けやすい名前がおすすめ）
管理者パスワードを設定（＝管理権限の鍵）
追加が完了したら、ゲーム作成でマップ・セッション名を決めて開始
必要に応じて サーバー設定で各種調整（後述の参加用パスもここ）

ここだけ注意（初心者がつまずく要点）

管理者パスワードは「友達が入るためのパス」と別物です
- 管理者パス：設定変更・運用のため（共有は最小限）
- 参加用パス：身内だけが入るため（必要なら全員に共有）

フレンドに渡す情報（漏らすと危険な情報／渡してOKな情報）

友達に渡すのは「入るために必要な最小限」に絞るのが安全です。
逆に、管理者情報まで配ると “誰でも設定を変えられる状態” になって事故が起きます。

渡してOKな情報（これだけで参加できます）

✅ サーバーIP（アドレス）
✅ ポート（7777）
✅ 参加用パスワード（設定した場合のみ）
✅（任意）サーバー名（一覧で迷わないため）

渡すと危険な情報（共有しない）

❌ 管理者パスワード
❌ ConoHaのログイン情報（アカウント/支払い情報）
❌ SSHの秘密鍵やrootパスワード（SSHを使う場合）
❌ バックアップファイル一式（不用意に配ると改変・流出リスク）

共有のしかた（事故防止のコツ）

IPやパスは、可能なら DM や 限定チャンネルで共有
参加用パスは「流出したかも」と思ったら 即変更（後述の設定からすぐ可能）

参加用パスワードを有効にして“身内サーバー”にする

身内サーバー運用なら、ここは ほぼ必須です。
初期状態で「参加用パスワードが未設定」のことがあるため、最初に入れておくと安心できます。

設定場所（ゲーム内）

サーバー管理 → 対象サーバー → サーバー設定
- プレイヤーのパスワード保護（参加用パスの設定）

おすすめの運用ルール（軽く守るだけで安全度が上がる）

🔐 参加用パスは「短すぎ・単純すぎ」を避ける（例：1234は避ける）
🔁 メンバーが増えた／一時的に公開した → その後変更
🧑‍🔧 管理者パスは運営者だけが保持（必要なら共同管理者だけに限定）

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

サーバー設定で快適化（最低限ここだけ触ればOK）

ConoHa for GAMEのSatisfactoryテンプレには、ゲーム内の「サーバー設定」画面から触れる“運用項目”が用意されています。ここでは初心者でも迷いにくいように、「まず触るべき順」で整理します。

管理者パスと参加用パスの役割分担

最初に混乱しがちなのが「パスワードが2種類ある」点です。役割を分けるだけで、事故（荒らし・勝手な設定変更）をほぼ防げます。

管理者パス（管理用パスワード）

サーバー設定を変更するための“管理者キー”
基本は 運営者だけが保管（共同管理者がいるなら最小人数）
例：
- オートセーブ間隔を変える
- ネットワーク品質を調整する
- 再起動間隔を設定する

参加用パス（プレイヤーのパスワード保護）

参加者が接続するための“入室キー”
重要ポイント：初期状態で未設定のことがあるので、身内運用なら設定推奨
参加者全員に共有してOK（ただし公開チャンネルには貼らない）

安全な運用ルール（これだけで十分）

管理者パス：共有しない／長め／使い回さない
参加用パス：身内で共有／漏れたら即変更
共有方法：できればDM、少なくとも限定チャンネル

オートセーブ・オートポーズ・再起動間隔の最適化

この3つは、「データ保全」「不在時の挙動」「長時間運用の安定」に直結します。最初は完璧を狙わず、“無難な初期値”から始めるのがおすすめです。

オートセーブ（オートセーブ間隔／プレイヤー切断時のオートセーブ）

オートセーブは 1分単位で間隔を設定できます
さらに「プレイヤー切断時に自動セーブ」をON/OFFできます

考え方

短すぎる：安心だが、セーブ頻度が高くなり負荷が出やすい
長すぎる：軽いが、事故時の巻き戻りが大きい

オートポーズ（プレイヤーがいない時にゲーム内時間を止める）

ON：誰もいない間は“ゲーム内時間が進まない”
OFF：誰もいなくても“進む”方向（運用方針に合うかが重要）

どっちが正解？

身内で「みんな揃って進めたい」→ ONが扱いやすい
誰かが不在でも「工場を回し続けたい」→ OFFを検討

サーバー再起動間隔（時間）

自動再起動の間隔を 1時間単位で設定できます
長時間稼働では、定期再起動が安定につながることがあります

項目	まずの目安	こういう意図
オートセーブ間隔	10〜15分	巻き戻りを抑えつつ、負荷も過剰にしない
プレイヤー切断時のオートセーブ	ON	「落ちた/抜けた」で区切りセーブが残る
オートポーズ	ON（身内向け）	不在時に時間が進まず、勝手に状況が変わりにくい
サーバー再起動間隔	24時間	“毎日一回整える”運用が分かりやすい

オートロード（どのセーブを自動で開くか）

「オートロードセッション名」は、サーバー起動時に“どのセッション（ワールド）を自動で読み込むか”を決める設定です。これを合わせておくと、再起動後に毎回迷いません。

何が便利？

サーバー再起動・更新後でも、いつものワールドが自動で立ち上がる
「起動したのにワールドが空っぽ」みたいな混乱を減らせる

初心者がミスしやすいポイント

テスト用セッションを作ったまま、そちらを選んでしまう
セッション名が似ていて、選び間違える

ミスを防ぐ命名のコツ

メイン：MAIN_みんなの工場
テスト：TEST_実験用
旧：OLD_バックアップ確認用

“MAINだけをオートロード”にしておくと、運用が安定します。

ネットワーク品質：上げるべき/下げるべき判断

ネットワーク品質は、上げると クライアントのロード時間やネットワーク性能の改善が期待できます。一方で、上げすぎると サーバーのフレームレートが低下する可能性があります。ここが一番の落とし穴です。

上げるべきサイン

参加者が入るのに時間がかかる（ロードが長い）
同期ズレ（ワープ/ラバーバンド）が目立つ
回線は安定しているのに、体感だけが不安定

上げない（戻す）べきサイン

変更後にサーバーがカクつく／操作が重い
人数が増えるほどサーバー側が苦しそう
そもそもメモリ不足っぽい症状（セーブが遅い、落ちる等）が強い
→ その場合、ネットワーク品質より メモリ・セーブ設定の見直しが先です

失敗しない調整手順（1回で決めない）

いったん現状の体感をメモ（参加に何分か、同期ズレの頻度など）
ネットワーク品質を 1段階だけ変更
参加者がいる時間帯に15〜30分テスト
良くなったら維持、悪化したら元に戻す

コツ：ネットワーク品質は“万能ツマミ”ではありません。
「セーブ設定」「定期再起動」「メモリの余白」とセットで効かせると、結果が出やすいです。

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

アップデート運用：更新で止まらないための流れ

基本方針：アップデート前にバックアップを取る

アップデート運用で一番大事なのは、技術よりも段取りです。
Satisfactoryはクライアント（Steam/Epic）が先に更新されやすく、サーバー側が追従できないと「入れない」「バージョン不一致」になりがち。そこで、更新前に“戻れる状態”を作ってから進めます。

最低限のバックアップ方針（初心者向け）

✅ アップデート前：必ずバックアップ
✅ 大改装（工場の大工事）前：バックアップ
✅ 安定して動いている状態を「復元ポイント」として残す

バックアップの手段（ConoHaで現実的な順）

イメージ保存（スナップショット相当）：失敗時にまるごと戻しやすい
自動バックアップ：定期的に保険をかけられる（ただし復元単位・保持期間などは仕様確認が必要）
可能なら＋αで
- 重要なタイミングのセーブデータを別途退避（「最悪でもワールドだけ守る」）

“アップデートの事故”で起きがちなこと

更新途中に再起動してしまい、起動が不安定になる
バージョン不一致で誰も入れず、焦って設定を触って悪化する
復元手段がなく、結局ワールドを作り直す

👉 だからこそ、先にバックアップを取るのが最短です。

自動更新を使う場合の注意点（デフォルト挙動と切り替え）

ConoHa for GAME の Satisfactoryテンプレートには、サーバー側の自動バージョンアップ機能があります。
ただし、データ保全の観点から初期状態では動かない（OFF）になっているのが重要ポイントです。

自動更新の“動き方”

有効化すると、サーバー起動の直前に更新処理が走るタイプ
つまり、アップデートが来たら「サーバー再起動」で更新が動くイメージです

注意点（ここで止まりやすい）

⏳ 更新があると、起動時に
ダウンロード／差し替えが発生して、普段より時間がかかります
→ 「落ちた？」と思って連打しないのがコツ
🛡️ 有効化の作業前に、公式でもイメージ保存などのバックアップ推奨
🔐 SSHやコンソールでコマンドを打つ必要があるため、操作ミスが不安なら
“メンテ時間を決めて、落ち着いてやる”のが安全

有効化の手順（やることは4行）

サーバーにログイン（コンソール or SSH）
次を順番に実行します

systemctl stop satisfactory-server.service
sed "s/^# ExecStartPre/ExecStartPre/" -i /etc/systemd/system/satisfactory-server.service
systemctl daemon-reload
systemctl start satisfactory-server.service

運用のおすすめ（迷わないための型）

平日夜など人がいる時間に更新を当てない
事前に「◯時〜◯時は更新」と共有しておく
更新後は、まず運営者がログインして
- セーブが正常にできるか
- 拠点周辺で異常がないか
  を短時間チェックしてから、参加者に解放するとトラブルが減ります。

手動更新で詰まらないチェックリスト

ここでいう「手動更新」は、ざっくり2パターンあります。
あなたがどちらの運用かで、チェック項目が変わります。

A：ConoHa for GAMEテンプレ運用（最短ルート）
B：ConoHa VPSでDedicated Serverを自前構築（自由度ルート）

A：テンプレ運用のチェックリスト（“更新＝再起動”が基本）

✅ まずバックアップ（イメージ保存など）
✅ 自動更新を使うなら、上の手順で有効化済みか確認
✅ 更新が来たら、サーバー再起動（更新処理→起動）
✅ 起動に時間がかかっても、まずは落ち着いて待つ（更新が走っている可能性）

B：VPS自前構築のチェックリスト（SteamCMD等で更新）

✅ バックアップ（セーブデータ／設定ファイル／必要なら全体イメージ）
✅ サーバー停止（更新中に動かさない）
✅ SteamCMDで更新（例：app_update 1690800 validate など）
✅ 起動→参加テスト→問題なければ開放

共通で効く“詰まり防止”のコツ

「クライアントが更新された直後」は混雑しやすい
→ 少し時間を置く or メンテ時間を決めて実施
更新後すぐは、一度運営者だけでログインして安全確認
設定をいじるのは最後
→ まずは「更新が完了しているか」「起動しているか」を確認する方が早いです

更新後に入れないときの“切り分け順”

「入れない」原因は、だいたいこの順で潰すと最短です。

サーバーが起動中か
- ConoHa側で状態が稼働になっているか
- 起動直後なら、更新で時間がかかっていないか
更新処理が終わっていない（まだ入れない時間帯）
- 自動更新を有効にしている場合、起動前に差し替えが走ります
  → “しばらく待つ”が正解のことがあります
バージョン不一致（クライアント＞サーバー）
- クライアントが先に更新され、サーバーが古いままだと発生
- 対応：
  - テンプレ運用：サーバー再起動（更新が走る前提）
  - 自前構築：SteamCMDで更新→再起動
接続情報の基本ミス（IP/ポート）
- IPをコピペし直す
- ポートは基本 7777（まずここを疑う）
通信許可（セキュリティグループ）
- Satisfactory用ルールが付いているか
- 追加で開けたポートが原因で変に塞がっていないか
最終手段：バックアップから復元
- 更新で壊れた／どうにも直らない場合は、ここで時間を溶かさない
- 復元→再度アップデートの手順を丁寧に、が結果的に早いです

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

バックアップとデータ保全（復旧できる人が一番強い）

セーブデータを守る設計（頻度・世代管理・保管先）

Satisfactoryのマルチは、工場が大きくなるほど「壊れたときの損失」も大きくなります。
なので、バックアップは“やるかどうか”ではなく、“どう設計するか”がポイントです。✅

まず押さえる：守るべきデータは2種類

ワールド（工場）セーブ：.sav（進行状況の本体）
サーバー環境：OS設定・起動設定・自動更新設定・セキュリティ設定など
→ ここまで含めるなら「サーバー丸ごとバックアップ」が強い

世代管理の考え方（「上書き事故」に強くする）

バックアップは1個だけだと危険です。
おすすめは次のような「世代」運用です。

短期（直近）：直近3〜10個（壊れた直前に戻す用）
中期（週単位）：週1で数世代（気づくのが遅れた時用）
長期（節目）：大型目標達成ごとに1個（記念＋保険）

保管先の基本（サーバー内だけに置かない）

サーバー内バックアップだけだと、サーバー障害で一緒に失うリスクがあります。
可能なら “外部にも1つ”（PC / クラウドストレージ等）📦

方式比較（迷ったらこれで選ぶ）

スクロールできます

方式	守れる範囲	強み	弱み	向く人
セーブ(.sav)を外部にコピー	ワールドのみ	軽い・移行しやすい	環境は復元できない	最低限でOKな人
自動バックアップ	サーバー全体（復元点）	放置で取れる	世代数・頻度に限界	取り忘れが怖い人
イメージ保存（サーバー丸ごと）	サーバー全体	事故対応が最強	停止が必要になりやすい	アプデ/改修が多い人

ConoHaのバックアップ機能を使う場合の考え方

ConoHaで現実的に使うバックアップは、主に次の2本立てです。

イメージ保存（手動の“丸ごとスナップショット”）
自動バックアップ（有料の“定期バックアップ”）

結論：おすすめの組み合わせ

普段：自動バックアップ（取り忘れ防止）
大きな変更前（アップデート・設定変更・MOD導入・工場が重くなった等）：イメージ保存（保険の確実性）

自動バックアップの注意点（過信しない）

便利ですが、一般に「頻度」「世代数」「任意タイミングで取れない」などの制約があります。
→ “更新前に自分で取る”を併用すると事故がほぼ防げます。

イメージ保存の注意点（運用ルールを決める）

イメージ保存は強い反面、雑に増やすと管理不能になります。

おすすめルール例：

付ける名前を統一：before_update_yyyy-mm-dd / before_planup_yyyy-mm-dd など
「残す基準」を決める：直近3つ＋節目の1つ、など
使わない保存イメージは整理（増やしすぎない）

重要：バックアップは“停止手順”とセットで覚える

バックアップ時にサーバー停止が必要になることがあるため、次の順で癖づけると安全です。

参加者に「停止する」連絡
サーバー停止（ゲームサーバーも含めて）
バックアップ取得
起動 → 接続確認
問題なければ通常運用へ

サーバー移行（プラン変更・別サーバーへ乗り換え）

「工場が重くなってきた」「人数が増えた」「別リージョンに移したい」など、移行はいつか必ず発生します。
ConoHaでの移行は、実務的にこの2パターンです。

パターン1：プラン変更（スケールアップ）

目的：メモリ不足・CPU不足の解消（＝カクつき/ロールバック/不安定化の予防）

おすすめ手順（安全運転）：

① 事前にイメージ保存（戻れる状態を作る）✅
② 可能ならサーバー停止（プレイ中にやらない）
③ コントロールパネルからプラン変更
④ 起動 → 参加できるか確認
⑤ しばらく様子見（オートセーブ・再起動間隔も調整）

ポイント：

体感が悪い原因は「人数」より“工場の重さ（メモリと処理負荷）”で来ることが多いです。
迷ったら、まずはメモリ増量を優先する判断が堅いです。

パターン2：別サーバーへ乗り換え（移設）

目的：環境を丸ごと移す／新規サーバーに切り替える／バックアップから復旧する

移行方式は2つあります。

A. サーバー丸ごと移す（おすすめ）

イメージ保存 → そのイメージから「新サーバー作成」または「再構築」
メリット：設定も含めて一式が戻る（復旧が速い）
注意：切り替え時はIPが変わることがあるため、参加者への共有情報更新が必要

B. ワールド（.sav）だけ移す（軽いが手間は増える）

サーバーのセーブフォルダから .sav を取り出して、新サーバー側へ配置
メリット：データが小さく、柔軟に移行できる
注意：保存場所・権限・サービスの停止/起動など、手順ミスが起きやすい

乗り換え時の「事故防止チェックリスト」

バックアップを2種類用意（丸ごと＋.sav の外部コピー）🧯
切り替えの前に「復元できるか」最小テスト
参加者に共有する情報を整理（IP/ポート/参加用パス）
セキュリティ設定（必要ポート）を新サーバーでも忘れずに

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

上級編：ConoHa VPSでゼロからDedicated Serverを構築する

構築の全体像（OS準備→サーバー導入→常駐化→更新）

ConoHa VPSで「自作Dedicated Server」をやるときは、ざっくりこの流れにすると迷いにくいです。

1. VPSを用意（Ubuntu推奨。最初はスケール前提でOK）
2. 初期セキュリティ（SSH鍵・アップデート・不要ポートを閉じる）
3. 通信を通す（ConoHa側の仮想FW + サーバー内FWの二重で整える）
4. Dedicated Serverを導入（SteamCMDで配布ツールを取得）
5. 起動スクリプトを作る（ポート・IPバインドなどを固定）
6. systemdで常駐化（自動起動・再起動・ログ管理）
7. 更新ルールを決める（停止→バックアップ→更新→起動の型を作る）

「テンプレより手間が増える代わりに、自由度（運用設計・サーバー合体・周辺ツール）が手に入る」のがVPS自作ルートです。

Linuxでの構築ステップ（SteamCMD／起動スクリプト／サービス化）

ここでは Ubuntu 22.04系を想定します（ConoHaのSatisfactoryテンプレもUbuntu 22.04なので相性がよいです）。

1) OS初期設定（最低限）

まずは更新（セキュリティと安定性のため）
SSHは「鍵認証」前提に寄せる（可能ならパスワードログイン無効化）

例（ログイン直後）：

sudo apt update && sudo apt -y upgrade

2) ConoHa側の通信設定（最重要）

VPSは「サーバー内のFWだけ開けても、外側（ConoHa側）で閉じていると届かない」ことが多いです。

ConoHa側（仮想ファイアウォール）
- セキュリティグループ（または接続許可ポート）で 必要ポートのみ許可
サーバー内（UFW/iptables）
- 同じく 必要ポートのみ許可

Dedicated Serverでまず通す候補（基本形）：

ゲーム用：7777（TCP/UDP）
補助ポート：8888（TCP）（最近のSatisfactory専用サーバー運用でよくセットで扱われます）
SSH：22（TCP）（可能なら接続元IPを絞る）

3) サーバー内FW（UFWの例）

sudo apt -y install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing

# SSH（できれば自分のIPだけに制限）
sudo ufw allow 22/tcp

# Satisfactory
sudo ufw allow 7777/tcp
sudo ufw allow 7777/udp
sudo ufw allow 8888/tcp

sudo ufw enable
sudo ufw status

4) SteamCMDの導入（Dedicated Serverを落とす道具）

SteamCMDは32bit依存が絡むことがあるので、先にi386を有効化します。

sudo dpkg --add-architecture i386
sudo apt update
sudo apt -y install steamcmd lib32gcc-s1

もしログに「SDLが無い」系が出る場合は追加で入れると改善しやすいです。

sudo apt -y install libsdl2-2.0-0:i386

5) 専用サーバー本体をダウンロード（AppIDで取得）

運用用ユーザーを分けると管理が楽です。

sudo adduser --disabled-password --gecos "" steam
sudo -iu steam
mkdir -p ~/satisfactory
steamcmd +login anonymous +force_install_dir /home/steam/satisfactory +app_update 1690800 validate +quit

ポイント：

1690800 が「Satisfactory Dedicated Server」の配布ツールIDです
以後、更新も基本はこの app_update を使います（停止中に実行）

6) 起動スクリプトを作る（ポート固定・IPv4指定もここ）

まずはシンプルに「起動できる」状態を作ります。

cat > /home/steam/start-satisfactory.sh << 'EOF'
#!/usr/bin/env bash
set -euo pipefail

cd /home/steam/satisfactory

# 迷ったら最初はこれだけでOK（必要なら後で調整）
# -Port は外から入力する「接続ポート」の核
# -multihome はIPv4固定にしたいときに有効（環境によっては接続性が上がる）
./FactoryServer.sh -Port=7777 -multihome=0.0.0.0 -unattended -log
EOF

chmod +x /home/steam/start-satisfactory.sh

※起動オプションは「後ろに付けたら無視される」タイプの注意があるので、基本は スクリプト側で固定しておくのが安全です。

7) systemdで常駐化（自動起動・落ちたら復帰）

sudo tee /etc/systemd/system/satisfactory.service > /dev/null << 'EOF'
[Unit]
Description=Satisfactory Dedicated Server
After=network-online.target
Wants=network-online.target

[Service]
User=steam
WorkingDirectory=/home/steam
ExecStart=/home/steam/start-satisfactory.sh
Restart=on-failure
RestartSec=10
LimitNOFILE=1048576

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now satisfactory
sudo systemctl status satisfactory --no-pager

ログ確認：

journalctl -u satisfactory -e --no-pager

8) 初回セットアップ（ゲーム側でやること）

Dedicated Serverは「起動しただけではワールドが始まりません」。

クライアント側の「サーバー管理」→「サーバー追加」
IP（VPSのグローバルIP）とポート（例：7777）を入力
初回接続時に
- 管理者パスワード
- サーバー名
- セッション作成
  などを決めて進めます

9) 更新手順（事故りにくい型）

更新は “毎回同じ手順” に寄せるほど強いです。

1. サーバー停止
2. セーブ・設定をバックアップ
3. SteamCMDで更新
4. 起動して動作確認

sudo systemctl stop satisfactory

# 例：セーブの場所（Linux）
# ~/.config/Epic/FactoryGame/Saved/SaveGames
# 必要ならzip化して退避

sudo -iu steam
steamcmd +login anonymous +force_install_dir /home/steam/satisfactory +app_update 1690800 validate +quit

exit
sudo systemctl start satisfactory

Windowsでの構築ステップ（RDP運用の注意点含む）

Windowsは「触りやすい」反面、RDPの公開＝セキュリティリスクが増えるので、次を徹底したいです。

RDP（3389）は 接続元IP制限（自宅/スマホ回線など）
パスワードは強力に（可能なら多要素・ロックアウト）
Windows Updateの再起動タイミングに注意（プレイ中に落ちる原因）

構築手順の考え方（最小）：

1. RDPで入れる状態を作る（ConoHa側の許可 + Windows Firewall）
2. Steam（GUI）または SteamCMDで Dedicated Server を入れる
3. バッチファイルで起動オプションを固定
4. 常駐方法を選ぶ（タスクスケジューラ / NSSM 等）
5. セーブ場所（サービス実行アカウント）を把握してバックアップ設計

Windowsで「サービス化」すると、セーブの保存先がユーザー配下ではなくなることがあるため、

どのアカウントで動かしているか
セーブがどこに出ているか
を最初に確認しておくのがコツです。

テンプレ運用に戻す/テンプレへ移す判断基準

VPS自作が向くのは、こういう人です。

サーバーを「ゲーム運用」だけでなく、周辺込みで作りたい
（監視、外部バックアップ、複数ゲーム同居、細かいOS設定など）
トラブル時にログを追って切り分けできる（または学ぶ前提がある）
更新・停止・バックアップの運用を自分で回せる

逆に、次に当てはまるなら ConoHa for GAMEのテンプレへ寄せたほうが満足度が高いです。

とにかく最短で遊びたい（構築に時間を溶かしたくない）
OSやFW、サービス常駐の管理を増やしたくない
“ゲームの管理” に集中したい（インフラの保守は最低限にしたい）

「自作がしんどい＝失敗」ではなく、目的に対して最小コストのルートを選べているのが正解です。

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

安定運用のコツ（ラグ・落ちる・重いを減らす）

“重くなる原因”はCPUよりメモリ/セーブ周りが多い

SatisfactoryのDedicated Serverは、体感として「CPUが弱いから重い」よりも、メモリ不足やセーブ/ロード周りがボトルネックになりやすいです。
特に、工場が育ってくると「人数は少ないのに重い」が普通に起きます。

重くなりやすい典型パターン（あるある）

ベルト・パイプ・設備が増えて、拠点の“密度”が上がる
セーブデータが肥大化し、オートセーブ時に引っかかる
参加者が一箇所に集まって、同期対象が一気に増える
長時間稼働でキャッシュが溜まり、徐々に不安定になる

まず効く対策（初心者でもやりやすい順）✅

メモリに余白を作る
- 迷ったら 16GB以上（大規模化するなら32GBも視野）
オートセーブを“短すぎ”にしない
- セーブ頻度が高いほど、引っかかりが体感に出やすいです
参加者が集まる時間帯だけでも運用を整える
- 例：ピーク前に再起動、セーブ直後の建築ラッシュを避ける

症状別の“原因あたり”の付け方（切り分けが早くなります）

スクロールできます

症状	まず疑う順	取りうる対策
建築/移動が常に重い	メモリ不足 → 工場密度	メモリ増量、拠点の密度を分散、再起動
オートセーブでカクつく	セーブ頻度/世代数	オートセーブ間隔を延ばす、世代を絞る
同期ズレ（ワープ）	ネットワーク品質/回線/負荷	ネットワーク品質を1段階だけ調整、再起動
落ちる・停止する	メモリ枯渇/ディスク不足/更新	メモリ増量、空き容量確保、更新前バックアップ

独自の小ワザ（“体感”が良くなりやすい）💡

重い拠点に全員集合しない（集合場所を“軽い場所”にする）
→ 同期対象が減り、ラグが軽く感じることがあります
大工事の前に一度再起動
→ “最初から重い状態”を避けやすいです
ネットワーク品質は万能ではない
→ 上げれば良い、ではなく「ロード改善 ↔ サーバー負荷増」のトレードです（後述）

再起動のタイミング設計（プレイ時間を邪魔しない）

再起動は“落ちた後にやるもの”ではなく、落とさないための習慣にすると運用が一気にラクになります。
コツは「みんなが遊ぶ前に、静かに整える」ことです。

おすすめの再起動設計（わかりやすい型）

毎日1回（24時間）：まずはこれが無難
- 例：平日は深夜、週末は朝など「人が少ない時間」に固定
大工事前：物流や発電の大改修をする前に一度
更新後：アップデートを当てた後の初回起動は“検証タイム”を作る

再起動の“事故”を防ぐ手順（これだけ守る）

参加者に一言（「○時に再起動します」）
直前にセーブが走る状態を作る（オートセーブ直後が理想）
サーバー停止 → 再起動
運営者が先に入って 5分だけ確認（入れる/セーブできる/極端なラグがない）
OKなら開放

テンプレ運用（ConoHa for GAME）での考え方

「再起動＝整備」になりやすいので、定期再起動を前提にすると安定しやすいです
自動更新を有効にしている場合、再起動時に更新が走ることがあるため、
“再起動＝メンテ”として時間を確保しておくとトラブルが減ります

VPS自作運用での考え方

systemdで常駐化しているなら、
- Restart=on-failure（落ちたら復帰）
- 定期再起動（手動でもOK）
  をセットにすると事故率が下がります

ログ・状態確認の最低限（異常の早期発見）

初心者が“沼る”のは、異常が起きたときに「何が起きているか分からない」状態です。
逆に言うと、見る場所を3つに絞るだけで復旧が速くなります。

最低限チェックする3点セット

サーバーの稼働状態（起動しているか / 落ちていないか）
リソース状況（メモリが枯れていないか / ディスクが埋まっていないか）
直前のログ（更新・クラッシュ・再起動の痕跡がないか）

ConoHa for GAME（テンプレ）での“最低限の見方”

まずは管理画面で
- サーバーが稼働中か
- 直前に再起動や更新をしていないか
  を確認
「入れない」場合、最初に疑うのは
- IP/ポート
- 起動直後（更新・初回生成）で待ち時間が必要
  です

VPS（Linux）なら、これだけ覚えると強い（コピペでOK）

稼働状態

sudo systemctl status satisfactory --no-pager

直近ログ（原因の手がかり）

journalctl -u satisfactory -e --no-pager

メモリ枯渇・ディスク不足の確認

free -h
df -h

“危険信号”の例

free -h で空きがほぼ無い（Swapに強く逃げている）
df -h でディスク使用率が高すぎる（セーブ・バックアップで埋まりがち）
ログにクラッシュ/再起動の繰り返しがある

異常の早期発見の運用ルール（簡単版）🔍

週1でいいので、
- ディスク使用率
- バックアップ世代数
  を見直して「増えすぎ」を防ぐ
更新前後は、運営者が ログを1回だけ見ておく
→ “原因不明”になりにくいです

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

よくあるトラブル集（最短で直すための分岐）

サーバーが一覧に出ない／追加できない

まず「どこで見えないのか」を切り分けると、解決が早いです。

A. ゲーム内の“公開サーバー一覧”に出ない

これは珍しくありません。身内サーバーや設定次第で、一覧に出ない・出にくいことがあります。
✅ 対処：サーバー管理 → サーバー追加（IP直指定）で入るのが最短です（一覧は当てにしない）。

B. サーバー管理で“追加”自体ができない（確認で弾かれる）
次の順で潰してください。

ConoHa側でサーバーが稼働中か
- GAMEのサーバー一覧で「稼働」になっているか確認
IPが合っているか（コピペし直す）
- ありがち：古いIPを渡された／メモが違う／桁の欠け
ポートが 7777 になっているか
- 入力欄が空欄だったり、別ポートを入れていると詰まります
セキュリティグループが“サティス用”になっているか
- ざっくり言うと「Satisfactory_Server（7777等）が開いている状態」になっているか
OS側ファイアウォールが閉じていないか
- ConoHa側で開いていても、サーバー内（UFW等）で閉じていると届きません
- テンプレ運用なら基本は少ないですが、VPS自作や追加設定をした場合は要確認

参加できない（IP/ポート/許可設定/証明書周り）

「追加はできたのに参加できない」場合は、原因がだいたい4系統に分かれます。

1) IP/ポートが間違っている

✅ 最短チェック
- IP：ConoHaのサーバー詳細に表示されるものをそのままコピペ
- ポート：まず 7777 で固定して試す

2) “許可設定（ポート開放）”が足りない

Satisfactory用の基本ポート（目安）
- 7777（TCP/UDP）
- 8888（TCP）
- 15000（UDP）
- 15777（UDP）
✅ 最短チェック：ConoHa側のセキュリティグループで、上記が許可されているか確認
- 特に「7777だけ開けたつもり」で詰まるケースがあります

3) 証明書ポップアップを通していない（または不安で止めた）

サーバー追加時に「サーバー証明書」の確認ポップアップが出ます
✅ 最短対処：内容を確認して「確認」を押す
⚠️ 注意（安全側の判断）
- 以前は出なかったのに急に出た／証明書が変わった場合は、サーバーが再構築された可能性があります
- 不安なら、サーバー管理者に「再構築や移行をした？」を確認してから進めると安全です

4) パスワード（参加用/管理者）が噛み合っていない

参加用パスがONなら、当然ここで弾かれます
✅ 対処：参加用パスを共有し直す／漏れが疑われるなら変更する

初回だけ異様に時間がかかる

初回は「失敗」ではなく、サーバー側でワールド生成が走って時間がかかるパターンが多いです。

よくある見え方

ConoHa側は稼働中
でもゲーム側では「オフラインっぽい」「参加できない」「反応が遅い」

最短でやること

✅ 作成直後はまず 約5分待つ
✅ 待ったあとに
- サーバー管理で再試行（再読み込み）
- それでもダメなら「ポート許可」を再チェック

やらない方がいいこと

焦って再構築・プラン変更・設定いじりを連打
→ かえって原因が増えます

パスワードを忘れた／権限が取れない

まず「どのパスワードを忘れたか」で分岐します。

A. 参加用パス（入室パス）を忘れた

✅ サーバー管理者がサーバー設定で変更 → 共有し直し
漏れが疑われるなら、変更してしまうのが早いです

B. 管理者パス（Admin）を忘れたが、まだ管理画面に入れる

✅ サーバー設定から「管理用パスワード」を変更できます
“忘れたけどログイン状態が残ってる”なら、このルートが最速です

C. 管理者パスを忘れて、もう管理権限を取れない（詰み状態）
初心者の最短ルートは「復元 or 再構築で取り直し」です。

✅ 最短の現実解（おすすめ順）
1. バックアップから復元（イメージ保存 / 自動バックアップがあれば最速）
2. バックアップが無いなら
  - セーブデータだけ退避（できる範囲で）
  - サーバー再構築して、最初からセットアップし直す
🔧 上級者向けの回復策（VPS自作など）
- サーバー停止 → セーブをバックアップ → “設定ファイルを削除して再クレーム”の手順で再設定する方法があります
ただし場所やファイル名が環境で変わるため、手順を見ながら慎重に（いきなり消さず、必ずバックアップ）

アップデート後に入れない／クラッシュする

「アップデート直後」は原因が固まりやすいので、順番どおりに切り分けるのが最短です。

1) まず“バージョン不一致”を疑う

クライアント（Steam/Epic）が先に更新 → サーバーが追従してない
これが王道パターンです。

✅ 対処（テンプレ運用）

ConoHaのテンプレは自動更新がデフォルトで動かない前提なので、
- 自動更新を有効化しているか
- していないなら、更新手順に沿ってアップデートするか
  を確認します
更新後は一度再起動して、運営者が先に接続確認

2) 更新後に“参加できない”だけなら、証明書・ポート・パスを再確認

証明書ポップアップ（再構築や入れ替えで出ることがあります）
ポート許可（セキュリティグループ）
参加用パスの変更有無

3) クラッシュする／落ち続ける（再起動ループ）

✅ 最短の守り
- いったん止める
- バックアップから復元（戻せる状態に戻す）
✅ 次の一手
- “直近のセーブ”が壊れている場合があるので、一つ前の世代で起動を試す
- それでもダメなら、更新手順・ポート・ディスク空き（バックアップで埋まりがち）を確認

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

料金・契約・解約（ムダ課金を防ぐ）

短期テスト：最小コストで試す手順

短期で試すなら、基本は 「時間課金」スタートが安全です。
ただし重要な注意点が1つあります。

サーバーを停止（シャットダウン）しても料金は止まりません
→ 料金を止めるには、原則 VPSそのものを削除します。

短期テストのおすすめ手順（ムダ課金防止の型）

時間課金でサーバー作成（まずはテスト用）
身内だけで接続テスト（IP/ポート/参加用パスなど）
セーブデータを必ず退避（ローカル保存 or どこかに保管）📦
続けないなら VPS削除（これで課金ストップ）✅

時間課金の「目安」（公式の表示例）

スクロールできます

メモリ	時間課金（1時間）	月額（上限の目安）
8GB	14.5円/時	8,083円/月
16GB	26.6円/時	15,730円/月
32GB	53.2円/時	31,460円/月

💡ポイント

短期で“試すだけ”なら、削除前提で運用するのが最安ルートになりやすいです。
データ転送量そのものに 追加課金がない仕様なので、通信量を過度に心配しなくてOKです。

長期運用：割引/固定費を最適化する考え方

長期で遊ぶ（= だいたい毎週/毎日）なら、候補はこの2つです。

A. 時間課金のまま運用

メリット：契約の縛りがなく、いつでもやめやすい
デメリット：遊ばない月でも VPSが存在する限り料金が発生（停止しても変わらない）

B. 長期割引パスで固定費化（おすすめになりやすい）

メリット：長く使うほど割引が効き、月額を読みやすい
デメリット：途中解約できない／一括前払い／更新時は申込時の価格が適用されない場合がある など注意点あり⚠️

さらに実務的に助かるのがこれ👇

時間課金で稼働中のサーバーにも、後から長期割引パスを適用できる
→ 「最初は時間課金で試す → いけそうならパスに切り替え」が、失敗しにくい王道です。

長期運用でムダ課金を避けるコツ

“遊ぶ頻度”ではなく“サーバーを残す期間”で考える（残している限り課金対象）
コミュニティで24時間稼働させるなら、最初から固定費化した方が精神的にもラク
料金はキャンペーン等で変動しうるので、申込前に公式の最新表を必ず再確認🧾

解約前に必ずやること（データ退避チェック）

解約（課金停止）でやることは、契約タイプで分岐します。

時間課金の場合

✅ VPSを削除（削除した時点までが課金対象）
🧾 利用分の請求は、タイミングによって 翌月月初に発生するケースがあります

長期割引パスの場合

✅ VPS削除だけでは不十分になり得ます
✅ 長期割引パスの自動更新をOFFにする（満了後に解約扱い）
⚠️ 自動更新がONだと、満了日の7日前から更新期間に入るため、余裕を持ってOFFにしておくのが安全

解約前チェックリスト（最低限これだけ）

✅ セーブデータ退避（ローカル/保管先にコピー）
✅ VPS削除の前に「復旧できない」ことを再確認
✅ 長期割引パス利用中なら 自動更新OFF
✅ 解約後、翌月の請求/利用明細を確認

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

他サービスとも比較したい人へ（ConoHaが合わないケース）

比較軸：テンプレ有無／料金体系／拡張性／サポート

「SatisfactoryをConoHaで立てるべきか？」は、“今の遊び方”と“今後どう育てたいか”で答えが変わります。
迷ったら、次の4軸で“合う/合わない”を機械的に判定すると失敗しにくいです。

比較の早見表（ざっくり方向性）

スクロールできます

比較軸	ConoHa for GAME	国内ゲームテンプレ系（例：XServer GAMEs など）	海外ゲームホスト（例：G-Portal / Bisect など）	汎用VPS（自前構築）
テンプレの手軽さ	強い（最短）	強い（最短〜短手順）	強い（即時）	弱い（学習コスト）
料金の柔軟さ	時間課金＋上限／長期割引など	短期プランが強い場合あり	プリペイド・契約縛りなし等が多い	月額中心（使わなくても固定費）
拡張性（自由度）	中（テンプレ範囲が中心）	中（サービス仕様次第）	中（パネル機能は豊富だが制限あり）	最強（root権限・監視・自動化）
サポート/言語	日本語・国内向け	日本語・国内向け	英語中心が多い	ほぼ自己責任（サポートはVPS次第）

1) テンプレ有無（＝立ち上げの速さと“詰まりやすさ”）

テンプレあり：クリック中心で立つ。初心者でも“初日から遊べる”確率が高い
テンプレなし（自前）：SteamCMD・サービス化・FWなどが必要。自由だが詰まりやすい

👉 「工場づくりに時間を使いたい」ならテンプレ優先が基本です。

2) 料金体系（＝短期向きか、長期向きか）

ここは“遊ぶ頻度”より、サーバーを残す期間で考えるのがコツです。

短期イベント（週末だけ、数日だけ）
- 3日単位などの短期プランがあるサービスが刺さりやすい（ムダ課金が出にくい）
長期運用（常設、数か月〜）
- 長期割引／月額換算が安定する仕組みがあるとラク
注意（どのVPSにもありがち）
- “停止しただけ”では請求が止まらないタイプが多い
  → ムダ課金を防ぐには、削除/更新停止の手順まで含めて運用設計します

3) 拡張性（＝どこまで運用を“自動化/高度化”したいか）

ConoHaやゲームテンプレ系が得意
- サーバー追加・基本設定・アップデート導線が整っている
自前VPSが得意
- 定期ジョブ、監視、ログ収集、外部バックアップ、複数ゲーム同居などを“好きなだけ”できる

👉 反対に言うと、高度なことをしないなら自前VPSは過剰になりやすいです。

4) サポート（＝トラブル時の復旧速度）

国内サービス：日本語UI・日本語ドキュメントが揃い、初心者の復旧が速い
海外ホスト：パネルが強い一方、サポート言語や時差が壁になることがある

小さな見落としポイント

友達が海外在住なら、サーバーの設置地域（リージョン）が重要
→ 国内固定だとピン（遅延）が不利になるケースがあります
→ 逆に国内在住中心なら、国内サービスで十分なことが多いです

「乗り換えるべきサイン」と「ConoHaに残るべきサイン」

ここからは“判断を一発で決める”ためのチェックリストです。
当てはまる項目が多い方が、あなたの正解に近いです。

乗り換えるべきサイン（ConoHaが合わない可能性が高い）

週末だけ/短期イベント中心で、とにかく最小コストに寄せたい
- → “数日単位”の短期プランがあるサービスが相性良いことがあります
海外在住の参加者が多い、または「海外リージョンに置きたい」
- → 多拠点（ロケーション選択が豊富）な海外ホストが有利なことがあります
1つの契約で Satisfactory以外のゲームにも頻繁に切り替えたい
- → “ゲーム切替”が前提のホスト（Gamecloud系）だと運用が軽い場合があります
バックアップや復元をパネルで完結させたい（外部退避の手間を減らしたい）
- → バックアップ機能が手厚いホストの方が楽なケースがあります
工場規模が大きくなり、監視・自動再起動・ログ収集など“運用の自動化”をしたい
- → ここまで来ると、自前VPSの自由度が効いてきます

乗り換え時に損しないコツ（最小限）

先に“移行先”で起動テスト → 最後に切り替える（いきなり解約しない）
セーブデータは必ず外部退避（最悪でもワールドだけ守る）
共有情報（IP/ポート/参加用パス）を更新する導線を作る（混乱防止）

ConoHaに残るべきサイン（ConoHaが“ちょうどいい”可能性が高い）

テンプレで最短起動が最優先（インフラに時間を溶かしたくない）
日本語UI・日本語ドキュメントで、初心者でも迷いにくい環境が良い
期間が読めないので、時間課金＋上限や長期割引など“運用の逃げ道”が欲しい
参加者が主に日本国内で、リージョン問題が起きにくい
まずは安定稼働が目的で、拡張や自動化は“必要になったら考える”方針

結論の決め方（おすすめ）

迷ったらまずConoHa（テンプレ）で始めて、
“短期しか使わない”or“運用を高度化したい”が確定した時点で乗り換え
→ これが最も後悔が少ないパターンです。

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

参考情報（公式・一次情報への導線）

ConoHa公式ドキュメント／サポートの参照先

ConoHa側は「どこを見れば何が分かるか」を押さえると、迷子になりません。目的別に“見る場所”をまとめます。

テンプレの仕様・必要ポート・設置情報を確認したい

「Satisfactory（ゲームテンプレート）」の仕様ページ
- OS / インストール先の目安 / 既定の利用ポート / 自動更新の扱いなど

テンプレの“更新（自動バージョンアップ）”手順を確認したい

「Satisfactoryゲームテンプレートを使う（サポート）」
- 自動更新は“標準で無効”になっている前提で、有効化の手順や注意点がまとまっています
- 作業前バックアップ推奨など、事故を避ける導線もここ

つながらない原因の9割＝ポート/許可設定を確認したい

「セキュリティグループ（ドキュメント）」
- Satisfactory用のセキュリティグループ名と、開放ポートの一覧
「セキュリティグループ機能を使う（サポート）」
- セキュリティグループの作り方／ルール追加／サーバーへの適用方法
- OS内ファイアウォール（UFW等）が別で動く場合がある注意もここ

バックアップ・復元・移行（再構築）を確認したい

「イメージ保存機能」
- “丸ごとスナップショット”の考え方（バックアップの基本に最適）
「自動バックアップ」
- 取得頻度・世代管理・リストア（復元）手順の確認に便利

テンプレ自体の更新履歴（最近何が変わった？）を追いたい

「ConoHaのリリースノート」
- テンプレ更新（OS内FW設定の更新など）が告知されることがあります

料金の最新表（時間課金／長期割引パス）を確認したい

「ConoHa for GAME 料金」
「長期割引パス」
- 価格は変動しうるので、申し込み前にここで再チェックが安全です

Satisfactory側のDedicated Server関連の確認先

Satisfactory側は、“サーバー運用の正解がまとまっている場所”を知っておくのが一番効きます。

まず最初に見る：Dedicated Serverの基礎（公式Wiki）

「Dedicated servers（公式Wiki）」
- 導入全体像（Windows/Linux）
- 接続の考え方（クライアントとの関係）
- よく参照する項目への導線がまとまっています

設定ファイル／運用の自動化まで踏み込みたい（公式Wiki）

「Configuration files」：どこに何が保存され、何をどう変えるか
「Running as a Service」：落ちたら自動復帰・起動時自動スタート（常設運用向け）
「HTTPS API」：状態取得・管理操作（高度な運用をしたい人向け）
「Dedicated servers/History」：サーバー周りの変更点の履歴

セーブの場所・バックアップの基本を確認したい（一次情報）

「Satisfactory公式サイトのSupport」
- セーブデータの場所（Windows）と、バックアップ推奨の案内
「Save files（公式Wiki）」
- OS別のセーブ場所や、バックアップ時に迷いやすい点の補助

アップデート情報（安定版/Experimental）を追いたい

「Satisfactory Q&AのPatch notes」
- 公式のパッチノートがまとまっており、Experimentalの更新も追いやすいです
- “Dedicated Server”に言及がある回は、ここを起点に確認すると復旧が早いです

自前構築（VPSでゼロから）でSteamCMD更新をする人向け

Valve公式Wiki「SteamCMD」
- 基本コマンド（app_update など）
Dedicated ServerのAppID確認（目安）
- SteamDBに「Satisfactory Dedicated Server（App 1690800）」情報があります（※一次情報ではないので、最終判断は公式情報と合わせて）

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

まとめ

Satisfactory×ConoHaのマルチ運用は、結局のところ「手順」よりも “運用の型”を持てるかどうかで成功率が変わります。
ここまでの内容を、実際に迷わない形にまとめると次の通りです。

1) 迷ったらテンプレ運用で最短スタート

まずは ConoHa for GAME のテンプレを使い、
「作成 → IP控える → ゲーム側でサーバー追加（IP/ポート） → 初回セットアップ」の流れで、最短でマルチを成立させるのが王道です。
公開一覧に出ないこともあるので、IP直指定で入る前提にしておくと詰まりにくくなります。

2) プランは“人数”より“工場の重さ”で決める

快適さはCPUよりも、メモリ・セーブ周りの影響が出やすいのがSatisfactory専用サーバーの特徴です。
少人数でも工場が肥大化すると重くなるので、最初から完璧を狙うより、

小さく始める（短期テスト）
重くなったらスケール（メモリ増強・運用見直し）

という順番が、コスパも失敗も最小になります。

3) 安定運用は「再起動」「セーブ」「バックアップ」の3点セット

ラグ・落ちる・更新で止まる──を減らすには、次を“習慣”にするのが近道です。

オートセーブを短すぎにしない（体感とのバランス）
定期再起動を設計する（遊ぶ前に整える）
アップデート前は必ずバックアップ（戻れる人が一番強い）

これだけで、トラブルの多くは「未然に回避」か「最短復旧」できます。

4) ムダ課金を防ぐには“停止”ではなく“削除/更新停止”まで理解する

短期で試したい場合は、時間課金で始めて、続けないなら削除までやって課金を止める。
長期運用なら、割引や固定費化を検討しつつ、解約前には必ずデータ退避を済ませる。
このルールさえ守れば、料金面の失敗はかなり減ります。

最後に。
このガイドは「最短で立てる」だけでなく、「更新やバックアップまで含めて止まらない」ことをゴールにしています。
まずはテンプレで立ち上げ、遊びながら運用の型（セーブ・再起動・バックアップ）を作り、必要になったタイミングでVPS自前構築や他社比較へ進む──この順番が、いちばん後悔しにくい進め方です。

もしあなたが次にやることを1つに絞るなら、
「短期テストでサーバー作成 → IP直指定で参加 → 参加用パス設定 → バックアップの1回目を取る」。
ここまでできれば、Satisfactoryマルチの“常設運用”はもう現実的な選択肢になります。

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