Satisfactory マルチ入門｜サーバー選び／初心者でも迷わない設定・運用・解決策

2026年2月14日

Satisfactoryを始めて、気づけば工場づくりに夢中。
「これ、友達と一緒にやったら絶対楽しいよね」と思った瞬間、次にぶつかるのが“マルチの壁”です。

「最短で合流したいけど、招待が出ない……どこから入るのが正解？」
「SteamとEpicって一緒に遊べるの？フレンド追加が必要？」
「ホスト式とDedicated Serverって何が違うの？ 24時間遊びたいならどれ？」
「レンタルサーバーって高い？必要スペックはどれくらい？」
「入れたけどラグがひどい。同期ズレで建物が戻ることもあるの？」
「アップデート後に急に入れなくなった。原因の切り分け方がわからない」
「セーブはどこにある？ Dedicatedに移行したら引き継げる？」

こうした悩みは、実は“やり方が難しい”というより、選び方と手順の順番がわかりにくいことが原因で起こりがちです。
特にSatisfactoryは、工場規模が大きくなるほど負荷やトラブルの出方が変わるため、「最初は快適だったのに、急に重くなった」というケースも珍しくありません。

この記事では、初心者でも迷わないように

マルチ方式はどれが正解か（ホスト式／Dedicated／レンタル）
最短で合流する手順（Steam/Epic混在も想定）
24時間運用の要点（Dedicatedの前提・セキュリティ・運用）
ラグ・同期ズレ・接続できない時のチェック順
セーブ移行・バックアップ・復元のコツ

を、順番どおりに整理して解説します。

公式情報を軸にしつつ、よくあるつまずきや実運用のポイントもまとめるので、
「今日すぐ遊ぶ」から「長期運用で安定させる」まで、この1記事で全体像がつかめます。

この記事で解決できること（最短合流／24時間稼働／人数・ラグ／接続トラブル）

まず結論：あなたに合う「マルチのやり方」はこれ

Satisfactoryのマルチは大きく 3パターン です。迷ったら、表の「向いている人」を見て選ぶのが最短です。

スクロールできます

やり方	こんな人に向く	いい点	注意点
ホスト式（誰かがゲーム内で部屋を立てる）	とりあえず今日すぐ遊びたい / 2〜4人くらい	準備が一番ラク ✅	ホストが落ちると止まる／ホストPCが重くなりやすい
自宅PCでDedicated Server（専用サーバー）	常時稼働したい / 設定を自分で管理したい	24時間運用しやすい 🔧	構築・更新・ポート設定が必要
レンタル（VPS等）でDedicated Server	24時間＋自宅PC負荷ゼロにしたい / 回線や電源が不安	安定・常時稼働しやすい 🌙	月額コストが発生／事業者選びが重要

最短合流：ホスト式で友達とすぐ遊ぶ手順

「今日集まって遊びたい」なら、まずはこれが最速です。

事前チェック（ここで9割つまずき防止）

全員のゲームが同じバージョン か確認（更新直後は特に）
可能なら 一度ゲームを再起動（認証やフレンド表示が安定しやすい）
ルーター・セキュリティソフトが厳しい環境だと、参加が不安定になることがあります（対処は後述）

ホスト側の流れ

通常どおりゲームを開始（新規でも既存セーブでもOK）
マルチ用に 参加を許可（フレンド限定／招待のみ／公開など）
必要なら パスワード を設定
- 公開する場合は、短すぎないパスワードが安心です

参加側の流れ

フレンド一覧や「参加」メニューから ホストのセッションに参加
表示されない場合は
- ホストが「招待のみ」になっていないか
- フレンド/プライバシー設定で見えなくなっていないか
  を先に確認

ホスト式の“あるある”

🧠 ホストPCの負荷が上がる：工場が大きいほど、ホストが重くなりやすい
⛔ ホストが抜けると止まる：作業を進めたいならDedicated Serverが向きます

24時間稼働：Dedicated Serverの基本（自宅 or レンタル）

Dedicated Serverは、ざっくり言うと 「みんながいつでも入れる常設ワールド」 です。

先に知っておくべきポイント

Dedicated Serverは“常時起動する別枠”：ホストがログインしていなくてもワールドが存在します
参加の自由度：友達が好きな時間に入って建築できるのが最大のメリット
注意（とても重要）：コンソールとPCは別エコシステムで、PCとコンソールのクロスプレイは不可。さらに、コンソールからDedicated Serverへ参加できない仕様です（＝Dedicated Serverは基本PC向けの運用と考えると安全）
※ただし、PC同士（Steam/Epic間）はクロスプレイ可能な案内があります

自宅PCでDedicated Serverを立てる（初心者向けの最短ルート）

ここでは「細かいコマンドの暗記」ではなく、迷わない流れに絞ります。

全体の流れ（これだけ覚えればOK）

Dedicated Serverをインストール（Steamツール／SteamCMDなど）
サーバーを起動（ログが出ていればまずOK）
ゲーム内の Server Manager でサーバーを登録（IP＋ポート）
初回接続者が サーバー名・管理者パス・（必要なら）参加パス を設定
ワールド作成 or セーブを読み込み して運用開始

最低限のセキュリティ

管理者パスワード は必須（荒らし対策）
公開するなら、参加パスも設定して 身内だけに限定 すると安全

ポート・通信（最短で理解）

ネットワークが原因の切断や参加失敗は、まずここを疑います。

公式の案内では、通信に使うポートとして TCP: 5222, 6666 / UDP: 5222, 6666, 7777-7827 が示されています
Dedicated Server側は、一般に ゲーム用ポート（例：7777） を使う前提の情報が多く、ルーターのポート開放やファイアウォール許可が必要になる場合があります

「何を開ければいいの？」で迷ったら、まずは 公式のポート一覧を優先 し、Dedicated Server用途で追加が必要な場合のみ（環境に応じて）調整するのが安全です。

レンタルでDedicated Serverを立てる（失敗しない選び方）

料金やスペックはサービスごとに頻繁に変わるので、数値の丸暗記より“選定基準”が大事です。

サービス選びチェックリスト

設置リージョン：日本から遊ぶなら、近い地域（遅延が少ない）を優先
CPUよりも“安定性”：同時接続・巨大工場で差が出やすい
メモリ：人数や工場規模で効く（余裕があるほど安定しやすい）
バックアップ：自動スナップショットがあると復旧が速い
再起動・自動起動：落ちた時に戻せる仕組みがあると安心

コストを揉めずに割るコツ

月額を人数で割るよりも、
- 「固定（基本料）＋利用が多い人が少し上乗せ」
  のほうが揉めにくいです 😊
「更新日・支払担当・停止条件」を最初に決めると、運用が長続きします

人数・ラグ：快適に遊ぶための考え方

「何人までいける？」は、実は 人数より工場規模 の影響が大きいことが多いです。

ラグの原因はだいたいこの4つ

ホスト（またはサーバー）のCPU負荷：巨大工場ほど増える
メモリ不足：長時間稼働や大規模セーブで影響
回線の上り（アップロード）：ホスト式だと特に重要
ネットワーク品質設定・同期：設定次第で体感が変わることも

すぐ効く軽量化の打ち手

一度に巨大改造をしない（分割して建てる）
物流を整理（ベルト・車両・ドローンなどは増えるほど負荷要因になりやすい）
不調時は、全員が一度抜けて サーバー再起動 →入り直し

接続トラブル：症状別チェックリスト（最短復帰）

「何が悪いか分からない」を、順番に潰せる形にしました。

1）セッションが見つからない／表示されない

ホスト側が 招待のみ になっていないか
フレンドの プライバシー設定 でブロックされていないか
両者とも一度 ゲーム再起動（意外と効きます）

2）タイムアウト・頻繁に切断される

公式案内の ポート（TCP/UDP） が塞がれていないか確認
- セキュリティソフトやWindows Defenderでゲーム/サーバーを許可
- ルーターのNATが厳しい場合は、設定見直しが必要になることがあります
公式でも、切断時の対策として ネットワーク品質設定 の見直しが案内されています
まずは全員同じ設定に寄せて試すと切り分けが楽です

3）Dedicated Serverに外から入れない

サーバーPCの ファイアウォール許可（まずここ）
ルーターの ポート開放（ポートフォワード） がサーバーPCに向いているか
まずLAN内（同一ネットワーク）から入れるか試す
- LAN内で入れる → 外部公開側（ルーター等）が原因
- LAN内でも無理 → サーバー起動やローカルFWが原因

4）セーブが消えた／別キャラになった／インベントリが空

公式案内では、オンライン状態によって 別のプレイヤーID扱い になり得る説明があります
対策としては
- いったんログイン状態を整えて再起動
- セーブのバックアップを定期的に取る
  が安定です

セーブのバックアップ（超重要）

公式が案内する保存場所を目安に、定期的に別フォルダへコピーしておくと安心です
（Dedicated Server運用なら、更新前のバックアップは必須レベルです）

Satisfactoryのマルチ基礎：まず知っておくべき仕組み

「セッション（ホスト式）」と「Dedicated Server（常時稼働）」の違い

初心者が最初に混乱しやすいのが、「ホスト式」と「専用サーバー（Dedicated Server）」の違いです。ポイントは “ワールドが誰に紐づいて動くか” です。

スクロールできます

項目	セッション（ホスト式）	Dedicated Server（常時稼働）
ワールドの存在	ホストの起動中だけ遊べる	サーバーが起動している限りいつでも入れる
運用の手軽さ	かなり簡単（ゲーム内で開始）	構築・更新・設定が必要
安定性	ホストPC負荷・回線品質に左右されやすい	環境次第で安定しやすい（特に常時運用）
こんな人向け	「今日すぐ遊びたい」	「24時間、みんなが好きな時に遊びたい」

迷ったら

まずはホスト式で遊ぶ（最速）
「ホストが不在でも進めたい」「人数が増えて重い」→ Dedicated Serverへ移行
…という順番が失敗しにくいです。

オンライン機能の前提：アカウント連携とクロスプレイの考え方

Satisfactoryの“クロスプレイ”は、1つの話に見えて 実は2種類あります。

PC内クロスプレイ（Steam版 ↔ Epic版）
コンソール内クロスプレイ（PlayStation ↔ Xbox）

そして重要なのが、PCとコンソールは別エコシステムとして扱われる点です。
つまり、コンソールとPCを混ぜて一緒に遊ぶ前提で考えるとつまずきます。

PCとコンソールは基本的に別世界（クロスプレイ不可の方針）
コンソールはDedicated Serverに参加できない方針
…という整理で覚えると、後から設定で迷いにくいです。

ホスト・参加に必要なオンライン設定（EOSなど）

オンライン周りは「何か難しい設定が必要そう…」と思われがちですが、初心者が押さえるべきは次の3点だけです。

1）オンラインサービスの“ログイン状態”が安定しているか
マルチでは、プレイヤーがオンラインIDに紐づいて扱われます。
そのため、ログインできていない（または途中で切れている）状態だと、

別キャラ扱いになる
インベントリが空に見える

といった現象が起こり得ます。こういう時は、まず再起動してログイン状態を整えるのが基本です。

2）「オンライン設定」メニューを一度確認する
特にクロスプレイが絡む場合は、ゲーム内のオンライン設定で

アカウント連携（必要な場合）
表示・プライバシー（相手からセッションが見えるか）
が原因になりやすいです。

3）通信品質の“土台”を揃える
マルチは回線・ルーター・セキュリティソフトの影響を受けます。
最初は難しいことをせず、まずは以下だけ意識すると切り分けが楽です。

全員、同じネットワーク品質設定で試す（高品質側に揃えると改善するケースあり）
セキュリティソフトでゲームをブロックしていないか確認
NATが厳しい家庭回線だと不安定になりやすい（この場合はDedicated Serverや回線見直しが効くことも）

Steam↔Epic／（該当する場合）コンソール間のクロスプレイ手順の要点

ここは「手順を丸暗記」より、成立条件を理解した方が早いです。

PC（Steam↔Epic）で一緒に遊ぶための要点

Steam版とEpic版でも一緒に遊べる（クロスプレイ可）
参加方法は大きく2つの考え方
- セッションIDで参加（相手のセッションを指定して合流するイメージ）
- Epic側の連携を使ってフレンド表示を通す（フレンドリストで見える状態にするイメージ）

※環境や設定によって「フレンドから見えない／招待できない」が起きるので、まずは

アカウント連携
プライバシー設定（相手からプロフィールが見えるか）
を確認するのが近道です。

コンソール（PlayStation↔Xbox）で一緒に遊ぶための要点

PlayStationとXbox間でのクロスプレイは可能
その際、相互にアカウント連携・フレンド関係が前提になりやすい
ただし PCとコンソール間のクロスプレイはしない方針で、コンソールはDedicated Serverにも参加できない整理です
（「PCのDedicated Serverにコンソールで入れる？」という発想が、初心者が一番ハマりやすいポイントです）

マルチで共有される要素・共有されない要素（進行／アンロック／権限）

マルチで揉めやすいのは「何が共有で、何が個人なの？」という部分です。結論から言うと、

ワールドの進行（工場・建設物・研究など）は基本“ワールド共有”
プレイヤーの持ち物・キャラは“個人（オンラインID）寄り”

という理解が安全です。

共有される（みんなに影響する）ものの代表例

工場・建物・配線・物流など、ワールドに置いたもの
ワールド全体の進行に関わる解放要素（例：研究・アンロック系）

ポイント：誰かが進めると、基本的にワールド側が前に進みます。
「ストーリーや解放を一緒に味わいたい」グループは、事前にルールを決めると安心です。

共有されにくい（個人に紐づきやすい）ものの代表例

プレイヤーキャラクター（オンラインIDに紐づく）
インベントリ（持ち物）

特に注意したいのが、ログイン状態が不安定なときに起きる “別キャラ化” です。
このとき「進行はそのままなのに持ち物だけない」ように見えることがあります。

初心者向けの予防策

マルチで遊ぶ時は、可能なら 常にオンライン状態で開始する
「別キャラになったかも？」と思ったら、まず 再起動してログイン状態を確認する
大事な資源は、個人インベントリに溜め込みすぎず 拠点のコンテナへ（事故が起きても戻しやすい）

結論：マルチのやり方は3つ。あなたの最適解はこれ

方式別の向き・不向き（手軽さ／自由度／24時間／コスト／安全性）

最短で決めるコツは、次の順で考えることです。

いつ遊ぶ？（今日だけ／毎日／24時間）
誰が負担できる？（ホスト役のPC負荷・回線・在席）
どこまで手間OK？（設定・更新・トラブル対応）
月額コストOK？（0円〜数千円）
安全性はどこまで必要？（公開範囲／パスワード／DDoS耐性）

それぞれの“向き・不向き”はこうです。

1）ホスト式（セッション）

向く：今日すぐ遊びたい／週末だけ／2〜4人中心
強み：準備が最少。追加費用ほぼ0円で始めやすい
弱み：ホストが落ちると止まる／ホストPC・回線に負荷が集中
安全性：フレンド限定・招待制にすれば十分安全（公開は注意）

2）自宅Dedicated Server（自分で専用サーバー運用）

向く：毎日遊ぶ／メンバーが好きな時間に入る／8人以上も視野
強み：ホスト不在でもOK。ワールドを常設できる
弱み：導入・更新・ネットワーク設定など運用の手間が増える
目安スペック感（初心者向け）：
- まずは メモリ12GB以上を基準に考える
- 大きなセーブや4人超なら 16GB以上を視野に入れると安心
安全性：管理者パス／参加パスでコントロールしやすい（ただし公開運用は設定が重要）

3）レンタルDedicated Server（VPS・ゲーム用テンプレ）

向く：24時間＋自宅PC負担ゼロにしたい／回線や電源が不安／安定重視
強み：落ちにくい環境を作りやすい。バックアップ等の機能が便利な場合も
弱み：月額コストが発生。契約・更新・解約の管理が必要
料金の考え方（迷わない基準）：
- 短期（数日〜）：日数課金や短期プランが得（週末イベント向き）
- 中〜長期（1か月〜）：VPS/ゲーム用テンプレの月額が分かりやすい
安全性：DDoS対策などが付くサービスもある（過信せず、パス設定は必須）

補足（大事）

コンソールはDedicated Serverに参加できない方針のため、コンソール中心のメンバー構成なら「ホスト式」が基本になります（PC版同士でDedicated運用する設計とは別物として考えるのが安全です）。

比較表：ホスト式 vs 自宅専用サーバー vs レンタルサーバー

スクロールできます

比較軸	ホスト式（セッション）	自宅Dedicated Server	レンタルDedicated Server
始めやすさ	最強（ゲーム内で即）	中（導入・設定が必要）	中（契約＋初期設定）
24時間稼働	✕（ホスト不在で止まる）	○（PCを起動し続ければ）	○（常設向き）
PC負荷	ホストに集中	サーバー用PCに集中	自宅PCはほぼ無関係
コスト	ほぼ0円	電気代＋機材（ある場合）	月額課金（数百円〜数千円帯が中心）
安定性	ホストの回線/PC次第	回線・設定次第	回線・設備が整い安定しやすい
手間	低	高（更新・監視・復旧）	中（更新は必要だが環境は整いがち）
安全性	招待制なら安心	設定次第（公開は要注意）	対策付きもあるがパス設定必須
こんな時に移行	人数増・重い・不在時も進めたい	もっと安定させたい／保守負担を減らしたい	自宅で回したくなった／コスト削減したい

最短で友達と遊ぶ：ホスト（Steam/Epic）でマルチを始める手順

事前準備：バージョン一致・フレンド追加・オンライン設定の確認

最短で合流するために、まずはここだけ押さえればOKです。
（逆に言うと、ここがズレていると“招待が出ない／見えない／入れない”が起きやすいです）

1）全員のバージョンを揃える（最重要）

全員が同じ更新状態になっているか確認
- 片方だけ更新中・更新待ちだと、参加時に弾かれやすいです
更新直後に不安定なら、いったん
- ゲーム終了 → ランチャー再起動 → 再起動
  を挟むと安定することがあります

2）フレンド関係を“使う方法”か“使わない方法”か決める

Satisfactoryのマルチは、合流の仕方が2ルートあります。

フレンド招待で入る（一番ラク）
セッションIDで入る（クロス環境や招待が出ない時に強い）

先に「どっちでやるか」を決めると、迷いません。

3）オンライン設定（EOS / Epicログイン）を確認する

マルチはEOSを使うため、ホスト・参加どちらもオンライン設定が前提になりやすいです。

メニューの Online Settings でログイン状態を確認
Epicアカウントがない場合は、ゲーム内から作成できる場合があります
Steam版でも、マルチのためにEpicへのログインが求められることがあります

✅ チェックの目安

Online Settingsで「ログイン済み」になっている
フレンド一覧が表示される（またはセッションIDが表示できる）

4）回線の“最低ライン”だけ整える（体感が変わる）

できれば ホストは有線LAN（Wi-Fiでも可能ですが安定性が落ちやすい）
同時に動画視聴・大容量DLをしている人がいると切れやすいので、開始前だけ控える
セキュリティソフトが厳しい人は、ゲームをブロックしていないか確認

ホスト側：セッション作成と公開範囲の設定（招待のみ／フレンド／公開）

ここは「難しい設定」ではなく、“誰が入れる部屋にするか”を決めるだけです。

1）セッションを開始する（新規でも既存セーブでもOK）

新規：みんなで最初から進めたい時
既存：ホストのワールドを見せたい／続きから遊びたい時

※初回は、チュートリアルやオンボーディングを終えるまで一部メニューが出そろわない場合があります。
「セッション管理が見当たらない」時は、いったんゲーム進行を少し進めてください。

2）公開範囲（プライバシー）を選ぶ

公開範囲の違いは、ざっくりこのイメージです。

スクロールできます

公開範囲	使いどころ	メリット	注意点
招待のみ（Private）	身内だけで確実に遊ぶ	もっとも安全	セッションIDで入れない設定になりやすい
フレンド（Friends Only）	いつものメンバーで気軽に	招待・合流が楽	フレンドが見えないと詰まる
公開（Public）	募集して遊ぶ	人が集まりやすい	荒らし対策が必須（パス・権限）

初心者のおすすめは 「フレンド」か「招待のみ」 です。
公開は、慣れてからで十分です。

3）招待がうまくいかない時の“逃げ道”を用意する

招待が出ない／押せない環境は普通にあります。
その時のために、ホストは セッションIDを出せる状態にしておくと強いです。

ESCメニューから Manage Session（セッション管理）
Session Settings で Session ID を表示・コピー
それを参加者に共有（チャット等）

セッション名・パスワードの決め方（公開時の注意）

公開する可能性があるなら、ここは手を抜かない方が安心です。

セッション名のコツ

個人情報（本名・学校名・住所に近いワード）は避ける
例：
- 「Factory_Weekend_02」
- 「Satis_4p_Progress」

パスワードのコツ

短すぎない（6文字以上を目安）
推測されにくい（誕生日・1234は避ける）
例：
- ランダム英数字＋記号の一部
- “単語2つ＋数字”のような覚えやすい形でもOK

運用ルールも一言決めると揉めにくい

「勝手にTier解放を進めていい？」
「大改造は相談してからにする？」
この2つだけでも、マルチの満足度が上がります。

参加側：招待から参加／Joinメニューから参加

参加側は「招待で入る」→ダメなら「セッションIDで入る」の順が最短です。

1）招待から参加（基本ルート）

ゲーム内の招待通知、またはフレンド一覧から参加
うまくいかない時は、いったん
- ゲーム再起動
- Online Settingsのログイン状態確認
  を挟むのが近道です

2）Joinメニューから参加（セッションIDルート）

招待が不安定な時でも入りやすい方法です。

メインメニューの Join Game（参加）へ
Session ID を入力（コピペ推奨）
参加できない時は、ホスト側の公開範囲が
- 「招待のみ」になっていないか
  を確認してもらうと解決することが多いです

✅ セッションIDが見当たらない／出ない場合

ホストがマルチセッションとして開始できていない
進行が必要で管理メニューが出ていない
などが原因になりやすいです。

ホスト式で起きやすい落とし穴（ホスト退出・負荷・同期ズレ）

ホスト式は最速ですが、ハマりどころも決まっています。
事前に知っておけば、ほぼ回避できます。

1）ホストが落ちる／抜けると、基本的に遊べなくなる

ホスト式は ホストPCがサーバー役です
つまり
- ホストがメニューに戻る
- ホストが終了する
  だけで、参加者は続行できません

対策

長時間やるなら、ホストは「抜ける前に必ず一言」
「みんなが好きな時間に進めたい」ならDedicated Serverへ移行が快適

2）ホストの負荷が高いと、全員が重く感じる

よくある症状：

参加者がワープする／カクつく
建築の反映が遅い
戦闘や移動がガタつく

対策（効きやすい順）

ホストは 有線LANにする
いったん 工場から離れた場所に集合してから作業する（負荷が下がりやすい）
大改造は分割して実施（“一気に壊す・一気に建てる”は負荷が跳ねます）
どうしても厳しいなら、ホストをPC性能・回線が強い人に交代する

3）同期ズレ（見えている状態が人によって違う）

ホスト式では、まれに

「片方には繋がって見えるのに、もう片方では違う」
「解体したはずが戻って見える」
のような体験が出ることがあります。

対策

一度全員がロビーに戻る／入り直す（再同期の効果が出やすい）
作業を分担しすぎない（同じ建物周辺を複数人が同時に触るとズレやすい）
大事な節目（Tier解放など）の前後で、手動セーブや小休止を入れる

24時間遊びたい：Dedicated Server（専用サーバー）を選ぶ前に知ること

Dedicated Serverのメリット・デメリット（常時稼働／設定自由度／運用の手間）

Dedicated Server（専用サーバー）は、あなた（ホスト）がゲームを起動していなくてもワールドが動き続けるマルチ方式です。
「みんなの合流タイミングがバラバラ」「進行を止めたくない」なら、最も相性がいい選択肢になります。

メリット（うれしい点）✅

24時間稼働：ホスト不在でも遊べる（社会人グループに強い）
ホストのPC負荷が軽い：工場が巨大化するほど差が出やすい
運用の自由度が高い：バックアップ、再起動、更新などを自分の方針で管理できる
参加者側が安定しやすい：ホスト落ち＝全員強制終了、が起きにくい

デメリット（先に覚悟する点）⚠️

初期設定が必要：ポート開放、Firewall例外、管理者認証など
運用の手間が増える：アップデート追随、ログ確認、トラブル対応
コストが発生しやすい：自宅PC常時稼働の電気代／VPSやレンタルの月額など
セキュリティ意識が必須：公開IPを扱う以上、パスワード・公開範囲はちゃんと決める

迷ったら、この判断が早いです

週末だけ＆必ず同時に集まる → セッション（ホスト式）でも十分
だれかが平日も触る／自分がいない時間も進めたい → Dedicated Serverが向く
「ポート開放が不安」→ まずはレンタルか、VPN系で“外部公開しない運用”を検討（後述のセキュリティ参照）

人数と負荷：公式の目安と現実的な上限の考え方

Dedicated Serverは「人数が増えればOK」ではなく、工場の規模（オブジェクト数）×移動体（車両・列車）×同時操作で負荷が跳ねます。
先に“現実的な上限”の考え方を持っておくと、後で揉めにくいです。

公式目安の読み方（ざっくり）

メモリは最低ラインが示されていても、実運用では余裕があるほど安定します
“4人を超える” or “セーブが重い”に入ったら、一段上の余裕が効きます

現実的な上限の考え方（おすすめの目安）

2〜4人：デフォルトの設計思想に近く、安定しやすい
5〜8人：可能だが、工場が大きいほどCPU/メモリ不足→ラグが出やすい
9人以上：理論上は増やせても、運用面（同期ズレ・処理落ち・トラブル対応）で現実的ではないことが多い

人数より“重さ”を決める要素

コンベア・パイプ・分岐の総量（増えるほど処理が増えやすい）
列車・車両・ドローンの稼働数（移動・衝突・経路で負荷が出やすい）
ブループリント大量設置（短時間で一気に負荷が跳ねやすい）
同時に別拠点で大工事（同時操作が増えると同期負荷が出やすい）

MaxPlayersは設定で変えられるが…

Dedicated Serverはプレイヤー上限を設定で変更できます（例：設定ファイルで指定）
ただし、上限を上げるほど“安定運用の難易度”が上がるので、まずは「4人想定で快適」を基準に考えるのが無難です。🙂

ネットワーク要件の基本（固定IP／NAT／ポート開放／証明書警告）

Dedicated Serverでつまずきやすいのは、ゲームの操作よりネットワーク側です。
ここだけ先に押さえると、接続トラブルが激減します。

1) 固定IP（または固定化）を用意する

自宅運用なら、サーバーPCのIPはDHCP予約で“変わらない状態”にするのが安全です
外部（インターネット越し）から繋ぐなら、回線のグローバルIPが変わる場合もあるので、必要ならDDNSも検討します

2) NATの状態を意識する

NATが厳しい環境だと、マルチ全般で問題が出やすいです
公式サポートでも「必要ポートが通っているか」を案内しています（ホスト式・Dedicatedどちらでも役立つ考え方です）

3) ポート開放（ポート転送）とFirewall例外

Dedicated Serverでは、バージョンによって「必要ポートの考え方」が変化しました。
いまの基本として覚えるなら、まずはこの2点が核です。

ゲーム用の標準ポート（デフォルト：7777）
Reliable Messaging / 管理系API側のポート（デフォルト：8888）
→ バージョン1.1系以降で重要になりやすいポイントです

加えて、マルチ全般の通信として公式が挙げているポートも「塞がれていないか」を確認すると切り分けが速くなります。

ポートのイメージ（整理表）

スクロールできます

目的	代表例	よく見る設定の方向性
Dedicated Serverのゲーム通信	7777	ルーター転送＋Firewall許可（TCP/UDPの扱いは環境と版で差が出るため、指示に沿って設定）
Reliable Messaging / 管理系	8888	ルーター転送＋Firewall許可（特にTCP）
オンラインサービス関連（一般）	5222 / 6666 / 7777-7827	公式が案内するポートが通るか確認（塞がれているとNAT問題が出やすい）

4) 証明書警告（Server Certificate Warning）は“仕様”

Dedicated Serverは、管理・接続の仕組み上、自己署名証明書（self-signed）が絡むケースがあります。
その結果、クライアント側で 「Server Certificate Warning」 が出ることがありますが、これは「異常＝即危険」ではなく、自己署名を使っているために出る想定の警告として扱われます。

まずは慌てず、表示内容を確認して承認
もし「TLS交渉失敗／証明書がまだ有効でない」系が出る場合は、サーバーPCの時刻ズレなども疑うと切り分けが早いです

最低限のセキュリティ（管理者パス／ゲストパス／公開範囲）

Dedicated Serverは“外部公開”になり得るので、ここだけは最低限やっておくのがおすすめです。🔒

1) 管理者パス（Admin Password）は最重要

サーバーの初期セットアップ（Claim）時に設定することが多く、
サーバー設定や管理操作の鍵になります
紛失すると復旧が面倒になりがちなので、パスワード管理アプリ等に保存が安心です

2) ゲスト側（参加者）に「クライアントパス（Client/Player Password）」を設定

公開IPを知っている人が入れてしまう事故を防ぎます
コツはこれだけ：
- 管理者パスと別物にする
- 12文字以上＋英数記号でランダム寄せ
- 定期的に変更（トラブル時は即変更）

3) 公開範囲を絞る（“誰にIPを渡すか”）

SNS等にIPを載せない（事故の元）
参加メンバーが固定なら、共有先を限定してOK
さらに安全寄りにするなら、外部公開せずVPN（身内ネットワーク）で参加する運用も現実的です（ポート開放が苦手な人にも向きます）

4) “守りの運用”もセットで

OS・サーバーを定期更新（更新遅れは事故の温床）
Firewallは「必要なポートだけ許可」
セーブのバックアップは最低でも週1、理想は更新前に必ず1回（事故った時に助かります）

レンタルサーバーで立てる（VPS・ゲーム用テンプレ）：初心者でも迷わない手順

レンタルが向く人（回線・電気代・常時起動・セキュリティが不安な人）

レンタル（VPSやゲーム用テンプレ）は、次のどれかに当てはまる人に特に向きます。

みんなのログイン時間がバラバラで、ホスト不在でも進めたい
自宅PCを24時間つけっぱなしにしたくない（電気代・騒音・寿命が気になる）
ホスト役のPCが重い／回線が不安で、ラグを減らしたい
ルーター設定（ポート開放・NAT）が苦手で、自宅公開が怖い
荒らし対策など、最低限のセキュリティをちゃんとやりたい

逆に、週末だけ／毎回同じメンバーが同時に集まる／2〜3人で短時間なら、ホスト式でも十分なことが多いです。

サービス選びチェックリスト（テンプレ／バックアップ／更新／サポート）

初心者が失敗しやすいのは「安いから」で決めて、あとから運用で詰まるパターンです。以下をチェックすると外しにくいです。

A. テンプレの有無（最重要）

✅ Satisfactory用テンプレがある
→ あるだけで、インストールや設定の手間が激減します
✅ 管理画面で サーバー再起動／設定変更／バックアップ ができる

B. バックアップと復元のしやすさ

✅ 自動バックアップ（スナップショット等）がある
✅ 「どのタイミングでバックアップされるか」が明確
✅ 復元方法がわかりやすい（ワンクリック復元が理想）

C. アップデートの方針

✅ 自動更新か、手動更新か（または選べるか）
✅ 更新後に不具合が出たとき、巻き戻し（復元）ができる

D. サポート・情報の見つけやすさ

✅ 公式ヘルプ／手順記事がある
✅ 問い合わせ手段（フォーム、チャット、コミュニティ等）が用意されている
✅ 障害情報・メンテ情報が確認できる

E. “後から困る”ポイント

✅ プラン変更（スケールアップ）が簡単
✅ 契約期間や解約ルールが明確（途中解約可否、前払いなど）

料金体系の違い（時間課金／月額／長期割）

料金は「何日使うか」で最適解が変わります。考え方だけ押さえると迷いません。

1）時間課金（時給制）

使った時間だけ支払うタイプ
✅ 短期検証・イベントに向く
⚠️ つけっぱなしにすると月額より割高になりやすい

2）月額（1か月単位）

✅ 毎日遊ぶ／常時稼働に向く
価格が読みやすく、メンバーで割り勘しやすい

3）長期割（3・6・12・24・36か月など）

✅ 長期で遊ぶならかなり得
⚠️ 一括前払い／途中解約できない等の条件があることが多いので、先に確認

初心者向けの選び方（失敗しない）

まずは 1か月で試す
「続く」と確信してから長期割へ
価格はキャンペーンや更新条件で変わるので、申込画面の表示を最優先で確認

必要スペックの目安（少人数～大規模工場）

Dedicated Serverは、人数だけでなく 工場の規模（オブジェクト数）で重くなります。
まずは「最低ライン」と「安全ライン」を分けて考えると失敗しにくいです。

公式目安の押さえどころ

Dedicated Serverは、12GB以上が最低ラインとして案内されており、
大きなセーブや4人超なら16GBが推奨という整理が基本です。
ストレージは「フルゲームを入れなくてもよい」一方、サーバーファイルに一定量が必要になります。

初心者向けの“実用目安”（迷ったらここ）

2〜4人／まだ工場が小さめ：まずは 16GBを基準に考える（余裕が出やすい）
4人超／工場が育つ前提：最初から 32GBも検討（後で引っ越ししなくて済む）
大規模工場・常に誰かが建築：32GB以上で様子見 → 足りなければ上げる

※サービスによってはSatisfactory用に「16GB以上のみ」など、ゲーム別に推奨プランを分けている場合があります。ゲーム別ページの案内に従うのが最短です。

構築の流れ（作成→起動→初期設定）

ここは「テンプレ型」を前提に、初心者が迷わない一本道にまとめます。

サービスに登録 → 管理画面へログイン
対応ゲームから Satisfactory を選ぶ
プラン（メモリ）と契約期間を選ぶ
サーバー名を設定（自分たちが識別しやすい名前）
作成（デプロイ）→ 起動
管理画面で IPアドレスを確認
ゲーム内で サーバーを追加 → 接続
初回接続時に 管理者／参加者パスワード を設定して運用開始

ここで時間を溶かしやすいポイント（先に回避）

作成直後は裏で準備中のことがあるので、管理画面で「起動中／稼働中」になるまで待つ
更新直後はクライアントとサーバーのバージョン差で入れないことがある（運用パート参照）

初回セットアップ：管理者／ゲストパスワード・サーバー名

Dedicated Server運用で最低限やるべき“安全設定セット”です。

1）サーバー名

個人情報を入れない（本名・学校名・住所連想ワードは避ける）
例：Satis_Weekend_01、Factory_JP_4p

2）管理者パスワード（Admin）

最重要：設定変更や管理操作の鍵
推奨：12文字以上、英数＋記号、使い回しなし
紛失すると面倒なので、パス管理アプリ等で保管

3）参加者パスワード（Client / Player）

公開IPが漏れても入れないようにする保険
管理者パスとは必ず別にする
メンバーが固定なら、定期的に変更するとより安全

4）公開範囲（共有の仕方）

IPはSNSなどに載せず、参加メンバーだけに共有
外部募集するなら、パス＋運用ルール（荒らし対応）を決めてから

参加方法：ゲーム内「サーバー管理」から追加して入る

基本は「Server Manager（サーバー管理）」に IPとポートを登録して入ります。
（招待が不安定な環境でも、この方法だと合流が安定しやすいです）

参加の流れ

ゲームを起動
メニューから サーバー管理（Server Manager） を開く
サーバー追加を選び、IP/ポートを入力
保存して接続
初回は 参加者パスワードを求められることがあります

IPアドレスの確認と入力

管理画面に表示されている IPアドレス（例：xxx.xxx.xxx.xxx） をコピー
共有する場合は、誤入力防止のため コピペ推奨
グループ運用なら、次も一緒に共有しておくとトラブルが減ります
- サーバー名
- 参加パスワード
- ポート（変更している場合のみ）

ポート設定の考え方（デフォルト／変更時の注意）

初心者が混乱しやすいので、考え方をシンプルにします。

基本方針

まずは デフォルトのまま使う（テンプレ型はこれが最短）
接続できないときだけ、サービス側の案内に従って確認する

よくある入力パターン

IPだけで通る（サービス側で必要ポートが管理されている）
IP:7777 のように ポート付きが必要な場合がある
- どちらが正しいかはサービスの手順に従うのが確実です

ポートを変更する場合の注意

参加者全員に「新しいポート」を共有する必要があります
変更すると、接続トラブル時の切り分けが難しくなるので、理由がない限りはおすすめしません

運用：停止・再起動・アップデート・自動更新の扱い

Dedicated Serverは「立てて終わり」ではなく、更新とバックアップが生命線です。
とはいえ、やることはパターン化できます。

日常運用（ラクに続けるコツ）

重くなったら 再起動（体感が改善することがある）
大改造の前後は バックアップ（事故っても戻せる）
「誰かが作業中のまま放置」を避ける（不具合切り分けが難しくなる）

更新前にやること（バックアップ／告知／検証）

更新は失敗すると「入れない」「セーブ戻せない」に直結します。更新前はこれだけ。

バックアップを取る（スナップショット or セーブ退避）
メンバーに 停止時間を告知（例：20分だけ止める）
更新方式を確認
- 自動更新：更新完了まで待つ
- 手動更新：手順に沿って実施
可能なら、更新後に 一度ホスト（管理者）が接続テストしてから周知

更新後に入れない時の切り分け手順

慌てず、上から順に見ると復帰が早いです。

1）サーバー側

管理画面で 稼働中になっているか
再起動して改善するか（更新直後はまず試す価値あり）
サービス側の障害・メンテ情報が出ていないか

2）バージョン差の可能性

クライアント側が未更新／サーバー側が未更新
→ 両方が同じ更新状態になるまで待つ or 更新する

3）接続情報のミス

IPの打ち間違い（コピペで再登録）
ポート指定が必要なタイプなのに、省略している（または逆）

4）パスワード・権限

参加パスを変えたのに共有していない
管理者パスと参加パスを混同している

5）最後の手段

直前のバックアップへ復元して原因を切り分け
（“更新そのものが原因”か、“セーブが壊れた”かが見えます）

自宅PCでDedicated Serverを立てる（Windows／Linux）

準備：常時起動・ストレージ・回線・ルーター設定

Dedicated Serverは「ゲームを起動しているPC＝サーバー」になるので、最初の準備で安定度がほぼ決まります。まずはチェックリストで穴を潰しましょう。

スクロールできます

項目	目安	つまずきポイント
常時起動	24時間稼働するならスリープ無効	スリープ/休止で“落ちた扱い”になりやすい
ストレージ	サーバー本体＋更新分の余裕	容量不足で更新失敗→起動不可になりがち
回線	ホストはできれば有線LAN	Wi-Fiだとラグ・切断が増えやすい
ルーター	LAN内IP固定＋ポート転送	LAN内IPが変わると転送先がズレる
OS更新	自動更新のタイミング管理	再起動でサーバーが止まる

最低限やること（ここだけは必須）

サーバーPCのLAN内IPを固定（DHCP予約がおすすめ）
Windowsならスリープ/休止をOFF
ルーター側のポートフォワードを“固定IPのPC”へ向ける
サーバー運用するなら、バックアップ方針を先に決める（更新前に必ず1回など）

インストール方法の選択（Steamツール／SteamCMD／配布元の違い）

結論から言うと、初心者はこの選び方がいちばんラクです。

WindowsでGUI運用したい → Steamの「ツール」から Dedicated Server を入れる（手軽）
Windows/Linuxで“サーバー専用”にしたい → SteamCMD（定番・自動化しやすい）
Dockerやサーバー管理パネルで運用したい → 慣れてから（変数が増える）

配布元の違いをざっくり整理

Dedicated Server自体は、Steam（ツール）やSteamCMDから入手するのが一般的
クライアント（遊ぶ側）はSteam/EpicどちらでもDedicated Serverに接続できます
ただし、アップデート直後はストア間で配信タイミングがズレて“バージョン不一致”になることがあるので、そのときは「時間を置く」が最短解になりがちです

SteamCMDで導入する場合の全体像

SteamCMDは「Steamのコマンド版」で、Dedicated Serverの導入・更新をコマンドでできます。
やることは (1) インストール先指定 → (2) 匿名ログイン → (3) AppIDで導入 の3つだけです。

前提：Satisfactory Dedicated ServerのAppID

1690800（Steamのツール扱い）

Windows例（最短）

:: 例：C:\Servers\Satisfactory に入れる
steamcmd.exe +force_install_dir "C:\Servers\Satisfactory" ^
  +login anonymous ^
  +app_update 1690800 validate ^
  +quit

Linux例（最短）

# 例：/opt/satisfactory に入れる
./steamcmd.sh \
  +force_install_dir /opt/satisfactory \
  +login anonymous \
  +app_update 1690800 validate \
  +quit

ポイント

validate はファイル検証もするので、トラブル時に強い（時間は少し増えます）
“更新のたびに同じコマンドを回す”だけでメンテできます（運用が楽）

起動と初期設定（新規ワールド／既存ワールド／ログの確認）

Dedicated Serverは「起動したら勝手にワールドが始まる」タイプではなく、クライアント側から初回セットアップ（Claim）してゲームを作る流れが基本です。

1）サーバーを起動する

Windows：FactoryServer.exe を起動（ショートカットやbatでOK）
Linux：FactoryServer.sh を起動（screen/tmuxやsystemd運用が定番）

初回はまず「起動して落ちない」ことを確認します。

2）ゲーム内からサーバーを登録して接続する

ゲーム内の サーバー管理（Server Manager） でサーバーを追加
LAN内ならサーバーPCのLAN内IPでOK
外部からならグローバルIP（またはDDNS）を使う

3）初回セットアップ（Claim）

初回接続した人（管理者）が、画面に従って設定します。

サーバー名
管理者パスワード（Admin）
必要なら 参加者パスワード（Client/Player）
新規ワールド作成 or 既存セーブ選択

既存ワールドで遊びたいときのコツ

いきなり本番セーブを入れず、まずは小さなセーブで“起動→読み込み→セーブ”が通るか確認すると安全です

起動オプション・ログで見るべきポイント

トラブルの8割はログで切り分けできます。初心者はまずこれだけ覚えれば十分です。

よく使う起動オプション（安全側）

-log：ログ表示（Windowsならウィンドウに出す）
-unattended：確認ダイアログ等で止まらないようにする
-multihome=<IP>：特定のIPにバインド（複数NICやVPN併用時に有効）
-Port=<数値>：ゲーム用ポート変更（複数サーバー運用時など）
（バージョンによって）追加のAPI/信頼通信ポートが必要になることがあります

ログでまず見るポイント

起動直後にエラーで落ちていないか（クラッシュ/例外）
“Listening on …” のような待受（ポート）情報が出ているか
接続時に「APIに繋がらない」系が出るなら、8888/TCP周りや証明書/時刻ズレを疑う

ポート開放・ファイアウォール設定

Dedicated Serverで詰まりやすいのはここです。
ただし、やることは「ルーター転送」と「OS許可」の2つに分けると簡単です。

基本の考え方（重要）

ルーター（NAT）：外から来た通信を、サーバーPCへ転送する
OS（Firewall）：サーバーPCが受け取っていい通信を許可する

さらに、Dedicated Serverは近年の更新で ゲーム用ポートに加えて、API用ポート（例：8888/TCP）が重要になっています。
「ゲームは起動しているのに入れない」「無限ロード」系は、ここが原因になりやすいです。

ルーター：ポートフォワード設定の考え方

まずは“外部公開するかどうか”で分岐します。

外部公開する（インターネットから参加）

サーバーPCのLAN内IPを固定
ルーターで以下をサーバーPCへ転送（目安）
- 7777（ゲーム用）：UDPに加えてTCPも必要になるケースあり
- 8888（API用）：主にTCP（v1.1以降の“Server API”系で重要）
うまくいかないときの鉄板チェック
- 転送先IPが合っているか（固定できているか）
- 同じポートを別機器で使っていないか
- 二重ルーター（“ルーターの下にルーター”）になっていないか

よくある落とし穴

NATループバック（ヘアピンNAT）非対応のルーターだと、LAN内から“グローバルIP”で接続できないことがあります
→ LAN内テストはLAN内IP、外部テストはスマホ回線など“本当に外部”で試すのが確実です

OS側：ファイアウォール許可の考え方

OS側は「許可する対象」を2パターンで考えると迷いません。

A. 実行ファイルで許可（初心者向け）

FactoryServer.exe（Windows）やサーバープロセス（Linux）を許可
ポート変更しても追従しやすい

B. ポート番号で許可（運用向け）

7777/8888など必要ポートを明示して許可
余計な通信を入れにくい（セキュリティ寄り）

証明書警告やTLSエラーが出るとき

サーバー側の時刻がズレていると、TLS交渉で失敗するケースがあります
→ まずはOSの日時を自動同期にするのが近道です

外部公開しない選択肢（LAN内／VPN）

「ポート開放が怖い」「身内だけで遊べればいい」なら、外部公開しない運用も十分アリです。

LAN内だけで遊ぶ（家の中・同一ネットワーク）

ルーターのポート開放は不要
サーバーPCのLAN内IPで接続するだけ
注意：友達が家の外にいるならLANでは届きません

VPNで身内ネットワークを作る（外部公開せず“内輪LAN化”）

参加者のPC同士をVPNで同一ネットワーク扱いにする方法
ルーターのポート開放を避けられることが多い
ただしVPN側の導入・権限管理（誰を入れるか）は必要

外部公開しない運用が向く人

とにかく安全に身内だけで遊びたい
ルーター設定が苦手で沼りたくない
一時的なイベントでサッと立てたい

セーブデータとワールド管理：移行・バックアップ・復元

セーブの保存場所（ホスト式／Dedicated Server）

まず大前提として、Satisfactoryのワールドは .sav（セーブファイル） で管理されます。
ホスト式とDedicated Serverでは「置き場所」と「触り方」が少し違います。

ホスト式（セッション）で遊んでいるワールド

Windowsの保存場所（Steam/Epic共通）

%LOCALAPPDATA%\FactoryGame\Saved\SaveGames

開き方（初心者向け）

Win + R → 上のパスを貼り付け → Enter

フォルダの中身の見方

その中に IDっぽい名前のフォルダ があり、そこに .sav が並びます
基本は 更新日時が新しいものが最新（迷ったら更新日時で並び替え）

補足（知っておくと安全）

クラウド同期を使っている場合でも、ローカルのセーブを定期的に別場所へコピーするのが安心です（同期ミスや上書き事故の予防）

Dedicated Serverで動いているワールド

Dedicated Serverのセーブは、環境によって 2パターン で見つかることが多いです。

パターンA：サーバーのデータフォルダ配下
- …/FactoryGame/Saved/SaveGames/server/
パターンB：Linuxなどでユーザー領域に保存される
- ~/.config/Epic/FactoryGame/Saved/SaveGames/server

さらに便利なのが、ゲーム内の Server Manager → Manage Saves（セーブ管理） です。

アップロード／ダウンロード ができるため、ファイル操作が苦手でも移行しやすいのが強みです

既存ワールドをDedicated Serverへ移す手順

ここでは「ホスト式のワールドを、Dedicatedへ引っ越す」最短ルートをまとめます。
（レンタルでも自宅サーバーでも考え方は同じです）

手順（失敗しにくい順番）

ホスト式ワールドで手動セーブを1回作る
- 名前に日時を入れると後で助かります
- 例：MainFactory_2026-02-14.sav
ホスト側PCで .sav を取り出す
- %LOCALAPPDATA%\FactoryGame\Saved\SaveGames から、目的の .sav を探す
Dedicated Serverへセーブを入れる（2択）
- A：Server Managerでアップロード（初心者におすすめ）
  - Esc → Server Manager → Manage Saves → Upload
- B：サーバーの保存フォルダへアップロード
  - …/FactoryGame/Saved/SaveGames/server/ などに .sav を置く
Dedicated側でLoad（読み込み）する
- Server Managerの Save/Load から対象セーブを選んでロード
初回の確認（ここまでやれば安心）
- スポーンできるか
- HUBや工場が正しく残っているか
- セーブできるか（セーブ→再ログインで確認）

移行後に起きがちな“別キャラ化”への対処（短く）

Dedicatedへ移した直後、参加者が「別キャラ」「インベントリ空」に見えることがあります。
多くは オンラインIDが正しく認識されていないことが原因なので、

まず ゲーム再起動してログイン状態を整える
それでもダメなら、ワールド内に残っている“以前の自分”から インベントリを回収する（状況により対処）

…という順で対応すると戻しやすいです。

バックアップ戦略（自動／手動／世代管理）

バックアップは「たくさん取る」より、“戻せる形で残す”のが大事です。
初心者向けに、実用的な3段構えをおすすめします。

レイヤー	目的	何を残す	頻度の目安
自動（Autosave）	うっかり事故の保険	直近の自動セーブ	いつでも
手動（節目セーブ）	大改造の巻き戻し	“節目”の手動セーブ	重要作業の前後
世代管理（外部保管）	破損・同期事故に備える	セーブフォルダ丸ごと or 主要sav	週1＋更新前

実務で強い運用ルール（これだけでOK）

更新前（ゲーム更新／サーバー更新）に必ず1回バックアップ
大工事の前に 「Before_核燃料」「Before_鉄道」 のような節目名を付けて保存
世代管理は“欲張らない”
- 例：直近3つの節目 + 日次7日 + 週次4週
  くらいが、探しやすくて復元もしやすいです

Dedicated Serverでのコツ

レンタル：管理画面の スナップショット／バックアップ機能があるなら最優先で活用
自宅：セーブフォルダを 定期的にZIP化して別ドライブへ（外付けやNASがあると強い）

破損・巻き戻し時の復旧フロー

「急に入れない」「ロードで落ちる」「なんか変」になったら、慌てずこの順で切り分けると復旧が早いです。

復旧フロー（最短で戻す）

いったん“現状のセーブ一式”を退避
- まずコピーして保険を作る（ここが一番大事）
1つ前のオートセーブ／手動セーブをロード
- DedicatedならServer ManagerのSave/Loadで試す
- ローカルならロード画面で1つ前を選ぶ
ダメなら“問題のセーブだけ”を隔離して起動
- セーブフォルダから怪しい .sav を別場所へ移動
- 起動して一覧が正常化するか確認
バックアップ（世代）から復元
- 週次／更新前バックアップから戻す
- レンタルならスナップショット復元が速いことが多い
更新直後の不具合なら“バージョン差”も疑う
- クライアントとサーバーで更新タイミングがズレると入れないことがあります
- 少し待つ／更新を揃える、で解決するケースも多いです

事故を増やさないための注意点

本番ワールドで実験しない（実験用セーブを分ける）
主要な切り替え（安定版↔実験版など）をする前は、必ずバックアップを取る

快適化：ラグ・同期ズレ・クラッシュを減らす

原因の切り分け（PC性能／回線／工場規模／設定）

マルチが重いときは「全部が悪い」ように見えますが、実際は 原因の当たりどころを見つけると一気に楽になります。
まずは下の順番で切り分けてください（最短で当たりを付ける流れです）。

まず確認したい“症状→原因”の目安

スクロールできます

よくある症状	原因になりやすいもの	最初にやること
ホスト式で全員が重い	ホストPC負荷／ホスト回線	ホストを有線に、負荷の高い拠点から離れて再確認
Dedicatedだけ重い	サーバー負荷／サーバー回線	サーバー再起動→ログ確認→メモリ不足の兆候を見る
特定の人だけワープする	その人の回線・Wi-Fi	有線化／同時DL停止／VPNやセキュリティソフト確認
建築の反映が遅い・戻る	同期遅延／同時編集	同じ場所の同時作業を避ける→入り直し
ロードで落ちる・頻繁にクラッシュ	バージョン差／セーブ負荷／ドライバ	バージョン統一→設定軽量化→バックアップから検証

切り分けの超シンプル手順（3分でできる）

“場所”を変える
いちばん負荷が高い大工場から、全員が少し離れた場所へ移動。
→ 体感が変われば、原因は 工場規模（オブジェクト量）寄り です。
“方式”で見分ける（ホスト式 vs Dedicated）
- ホスト式でだけ重い → ホストPC／ホスト回線
- Dedicatedでだけ重い → サーバー側負荷／設定／ポート周り
“誰が”を特定する
1人だけ重いなら、その人の回線・PCが原因の可能性が高いです。
逆に全員同じタイミングで重いなら、サーバーか工場が原因になりやすいです。

クライアント側で効く改善（描画・設定・安定化）

クライアント側は「FPSの安定」と「通信の安定」を分けて考えると改善しやすいです。

描画の軽量化（FPSが落ちる・カクつくとき）

まずは“体感に効きやすい順”で調整します。

FPS上限を設定（例：60/90など）
ぶん回し状態を避けると、熱・クロック変動が落ち着きクラッシュ耐性も上がりやすいです。
影／描画距離／エフェクトを下げる
工場が大きいほど効きます（視界に入るオブジェクトが増えるため）。
フルスクリーン最適化（Windows）やオーバーレイを見直す
Discord/Steam/録画系のオーバーレイが相性悪いケースがあります。
バックグラウンド負荷を止める
配信・録画・ブラウザ大量タブ・別ゲームDLなどを一旦止めるだけで改善することがあります。

通信の安定化（ワープ・反映遅れ・切断が多いとき）

有線LANを優先（特にホスト役・不調な人）
Wi-Fiは「速度」より「揺れ（遅延のブレ）」が問題になりがちです。
同時に大容量通信をしない
家族の動画視聴、クラウド同期、OS更新などが重なると不安定になりやすいです。
ゲーム内のネットワーク品質設定を見直す
マルチには通信品質の設定項目があり、状況によって改善します。
迷ったら、全員が同じ設定に揃えて試すと切り分けが簡単です。
セキュリティソフト／VPNを疑う
“特定の人だけ”発生する切断は、ここが原因のことがあります。
まずは一時的にオーバーガード（厳格モード）を緩める、VPNを切るなどで検証すると早いです。

安定化の基本（クラッシュが多いとき）

ゲームとサーバーのバージョンを揃える（更新直後は特に）
ドライバ更新（GPU・チップセット）
MODを入れているなら全員の整合性（Dedicatedでは相性も出やすい）
セーブを分ける
“実験用（テスト）セーブ”を作って、重い改造はテスト側で試すと事故が減ります。

サーバー側で効く改善（負荷対策・運用ルール）

Dedicatedでもホスト式でも、サーバー側の負荷は結局「工場の情報量」と「同時操作」で決まります。
対策は、技術よりも“運用の設計”が効きやすいです。

すぐ効くサーバー運用（まずやる3つ）

定期再起動
長時間稼働で重くなったとき、再起動で体感が戻ることがあります。
例：毎日深夜、または週2回など、遊ばない時間に固定。
更新前バックアップを習慣化
更新で不具合が出た時に戻せるかどうかで、復旧時間が変わります。
ログの場所だけ把握
「入れない」「クラッシュした」時に、ログがあると原因が見えます。
まずは“エラーが出た時刻”だけでもメモしておくと切り分けが早いです。

工場側の負荷を下げる考え方（“数を減らす”が効く）

サーバー負荷は「派手な建物」より、動いている要素の総数に引っ張られます。

同じ生産量なら、機械台数を減らす発想
例：設計を見直して“増設の連鎖”を止める／上位レシピや効率設計を使う
（結果としてオブジェクト総数が減り、同期も軽くなりやすい）
移動体（車両・列車・ドローン）は“増やしすぎない”
便利ですが、増えるほど同期と処理が増えがちです。
巨大スパゲッティを避ける
配線・ベルト・分岐が密集した場所は、視界に入るだけで重くなりやすいです。
“モジュール化して分散配置”が効きます。

大規模工場での“マルチ運用ルール”（分業・建設ルール・テスト環境）

ここが一番のオリジナルポイントです。
技術的な最適化より、チームのルールを作るほうがラグと同期ズレを減らせます。

1）分業ルール：担当を「場所」で切る

おすすめは“役割”ではなく“エリア”で切る方法です。

例：北＝発電、東＝精錬、西＝組立、中央＝物流ハブ
同じ場所を複数人が同時に触ると、
反映遅れ・巻き戻り・同期ズレが出やすくなります。

2）建設ルール：大改造は「時間」と「単位」を決める

大解体・大移設はイベント化（30分だけ全員集合など）
→ 同時編集が増える作業ほど、まとまってやるほうが事故が減ります。
“一気に壊す”より“単位で置き換える”
例：1ラインずつ新旧並走→切り替え→旧撤去
→ 止まる時間も短く、同期トラブルが起きにくいです。

3）テスト環境：本番を触る前に“検証用セーブ”を作る

新しいレイアウト、巨大ブループリント、輸送網の刷新は、まずテストで試す
うまくいったら本番へ移植
失敗しても本番が壊れないので、精神的にも安定します 😄

4）共有の運用ノート（短くていい）

チャット固定メッセージでも十分です。

今日の変更点（何をどこで触ったか）
次に触る予定（衝突回避）
サーバー再起動予定時刻
最新バックアップの日時

これだけで「誰が何をしたかわからない」事故が激減します。

接続できない・参加できない：症状別チェックリスト

最初に確認：オンライン認証／バージョン／フレンド状態

接続トラブルの多くは、いきなりポートやルーターを疑うより先に、ここで止まっています。まずは次の順で“土台”を揃えましょう。

1）オンライン認証（EOS）

メニューの Online Settings で、ログイン状態を確認
「別キャラ扱い」「インベントリが空」になったときは、オフライン扱いになっている可能性が高いです
→ ゲーム再起動でログイン状態が戻ることがあります ✅
うまく認証できない／アカウントが不整合っぽい
→ Options > Online > Reset Account Linking を試す（再連携の再登録）

2）バージョン（枝の違いも含む）

全員が同じ枝か確認
- 例：安定版（Main）とExperimentalが混ざるとズレやすい
更新直後は、Steam/Epic間で配信タイミングがズレることがあるので、全員が同じ更新状態になるまで待つのが最短な場合もあります

3）フレンド状態・表示設定

Steam/Epicの“フレンド”は揃っているか
「Join Gameに友達のセッションが出ない」場合は、プライバシー設定で“他人がプロフィールを閲覧できる状態か”も確認（見えない原因になることがあります）

症状別の対処

サーバー一覧に出ない／検索できない

まず結論：一覧に出るかどうかは環境依存なので、初心者は「一覧を信用しすぎない」のがコツです。
確実性を上げる順に試してください。

A：Dedicated Serverなら“直指定”に寄せる（おすすめ）

ゲーム内 Server Manager から IPで追加して接続
LAN内テストは「LAN内IP」、外部参加は「グローバルIP（またはDDNS）」で試す
※ルーターによっては“LAN内からグローバルIPで入れない”ことがあります（故障ではなく仕様のことが多いです）

B：ホスト式なら「公開範囲」と「招待経路」を再確認

ホスト側がセッション公開範囲を「招待のみ／フレンド／公開」で想定どおりに設定しているか
参加側は「Join Game」だけでなく、可能なら
- 招待から参加（Steam/Epicの招待）
- セッションIDで参加（クロスストア時に特に有効）
  も試すと見つかることがあります

C：NATがStrict/TBDなら“表示されない・入りにくい”が起きやすい

NATがStrict/TBDのときは、まずFirewall/ウイルス対策ソフトでSatisfactoryを許可
それでもダメなら、必要ポートが塞がれていないか確認（ポートは後述）

D：Dedicatedで「LANはOK、外からはNG」

ほぼ ポート転送（ルーター）かFirewall（OS） が原因です
→ 7777系だけでなく、1.1以降はAPI側（8888）が絡むケースがあります

「接続が失われました」系（NAT／ポート／セッション設定）

この系統は“原因が広い”ので、公式が案内している順番で潰すのが最短です。

1）“誰がホストか”を変える

ホスト式なら、ホスト役のPC/回線がボトルネックのことが多いです
→ 別の人がホストして改善するか試す（切り分けが速い）

2）Network Qualityを全員そろえて上げて試す

設定でNetwork Qualityを変更できるので、全員が同じ設定に揃え、まずは高め（例：Ultra）で再起動して試す ✅
※「一部だけ設定が違う」状態は切り分けを難しくします

3）セーブ依存かどうかを判定

“そのセーブだけ”で落ちるなら、セーブ側（規模・破損・MOD残り）の可能性
“新規セーブでも落ちる”なら、回線・NAT・Firewall寄り

4）Firewall・ウイルス対策でブロックされていないか

まずはSatisfactoryの実行ファイルを許可対象に入れる
VPNや厳格な通信監視ソフトがある人は、一時的にOFFで比較（特定の人だけ落ちるときに効きます）

5）ポート（ホスト式・Dedicated共通）

公式の案内に沿って、必要ポートが塞がれていないか確認
Dedicated Serverを外部公開する場合は、ルーターのポート転送＋OSのFirewall許可が両方必要

証明書の警告が出る／参加で止まる

Dedicated Serverで出やすい症状です。慌てず、まずは“安全に確認できる範囲”から。

よくあるパターン

サーバー追加時に Server Certificate Warning が出る
「承認したのに進まない」「無限ロードっぽい」

チェックポイント（上から順に）

そのサーバー、本当に自分（または信頼できる友人）のものか
知らないIPなら承認しないのが安全です 🔒
サーバーの時刻ズレ
TLS系のエラーで「まだ有効でない」などが出る場合、サーバーOSの時刻がズレていることがあります
→ OSの自動時刻同期をONにして再起動
API側（8888）が通っているか（1.1以降で重要）
参加で止まるタイプは、ゲーム用ポートだけでなくサーバーAPI側が原因のことがあります
→ ルーター転送・Firewall許可を見直す
ネットワーク設定の特殊指定を外して比較
複数NIC/VPN環境で -multihome 等を指定している場合、いったん外して挙動が変わるか確認（比較が目的）

入れたが極端に重い（ラグ・同期・負荷）

「入れた＝通信OK」なので、ここからは 負荷（PC・回線・工場規模） の勝負です。
短時間で原因を当てるなら、次の手順が効きます。

1）場所テスト（いちばん速い）

全員で巨大工場から少し離れる
→ 体感が軽くなるなら、原因は 工場規模（オブジェクト量） 寄り

2）誰だけ重い？全員重い？

特定の人だけワープ／遅い
→ その人のWi-Fi、同時DL、VPN、回線混雑の可能性が高い
全員同時に重い
→ サーバー性能・サーバー回線・工場規模の可能性が高い

3）即効の改善メニュー

ホスト式：ホストを有線＋負荷の低い場所へ移動、必要ならホスト交代
Dedicated：サーバー再起動、同時建築を減らす、移動体（列車・車両・ドローン）を増やしすぎない
クライアント：描画設定を軽くし、FPS上限設定で安定化（クラッシュ耐性も上がりやすい）

アップデート後に起動しない／入れない

更新直後は「設定の問題」より「更新の揃い」が原因のことが多いです。

1）まず“揃える”

クライアントとサーバーのバージョンを揃える
DedicatedはSteamCMD/ツール側の更新が漏れやすいので、更新コマンド（または管理画面の更新）を再実行して再起動

2）公式の基本手順（クラッシュ・変な挙動のとき）

Steam/Epicの 整合性チェック（Verify） を試す
画面が出る前に落ちるなら、ドライバ更新や描画API切り替え（DX11/DX12/Vulkan）も候補

3）MODを入れている場合

まずMODを無効化して比較（Dedicatedは相性が出やすい）
MODを消してもセーブに影響が残る場合があるので、“新規セーブで入れるか”も合わせて確認すると切り分けが早いです

4）Dedicatedだけ「更新後から無限ロード」

1.1以降、サーバーに組み込みAPI（デフォルト8888/TCP）があり、ここが通らないと詰まるケースがあります
→ 7777系だけでなく、8888もルーター転送・Firewall許可を確認

相談用テンプレ：環境情報・ログ・再現手順

困ったときは、これを埋めて貼るだけで“回答が返ってくる確率”が上がります。コピペして使ってください。

【環境】

参加側：Windows / Linux、Steam / Epic、安定版 or Experimental、ゲーム内の表示バージョン：
ホスト方式：ホスト式 / Dedicated（自宅PC）/ Dedicated（レンタル）：
サーバーOS：Windows / Linux（ディストリ名）：
接続形態：LAN内 / インターネット / VPN：
回線：有線 / Wi-Fi、上り下り速度（だいたいでOK）：
NAT表示（わかれば）：Open/Moderate/Strict/TBD：

【症状】（当てはまるものにチェック）

[ ] サーバー一覧に出ない　[ ] 追加しても接続できない
[ ] 接続が失われました　[ ] 無限ロード
[ ] 証明書警告が出る　[ ] 入れるが激重
[ ] 更新後からだけ発生

【再現手順】

（例）Server ManagerにIPを追加 → Confirm → ここで止まる
（例）Join Gameでホストが見えない／クリックで落ちる
発生頻度：毎回／たまに（割合）

【すでに試したこと】

例：ゲーム再起動、ホスト交代、Network Qualityを揃えた、Verifyした、MOD無効化、サーバー再起動、ポート確認…など

【ログ】（貼れる範囲でOK）

クライアントログ：%LOCALAPPDATA%\FactoryGame\Saved\Logs の末尾20〜50行
Dedicatedログ：FactoryGame/Saved/Logs の末尾20〜50行
エラーが出た時刻（だいたいでOK）：

FAQ：よくある質問

最大何人まで遊べる？（設定変更の考え方と注意点）

まず押さえておきたいのは、公式に安定動作として想定されているのは4人という点です（それ以上も動かせますが、快適さは保証されません）。

人数を増やす前に考えるべきこと

人数が増えるほど重くなるのは「チャット」ではなく、同期（建設・物流・移動体）です
ボトルネックは「CPU」「回線」「工場の密度（オブジェクト量）」の合算になりがち
4人→6人で一気にキツくなる…というより、“工場が大きい状態で人数を増やす”のが最も危険です

ホスト式（セッション）で人数上限を増やす考え方

設定ファイル（Game.ini）で MaxPlayers を増やす方法が知られています
ただし、ホストPCの負荷が急増しやすいので、まずは「一度少人数の新規セーブ」で挙動を確認してから本番セーブに入るのが安全です

Dedicated Serverで人数上限を増やす考え方

多くの環境で Game.ini 側の MaxPlayers を編集して上限を調整します
上限を上げると、次が一気にシビアになります
- サーバーのメモリ不足（クラッシュ・落ちやすさ）
- 同時建築による同期遅延（反映が遅い／巻き戻る）
- 大規模拠点でのラグ（全員が同時に重い）

初心者向けの結論（失敗しない進め方）

いきなり上限だけ上げず、“運用ルール（同時作業を減らす）”を先に作る
それでも足りないなら、Dedicatedに寄せる（常時稼働＋負荷分散）
最後に MaxPlayers を上げる（上げたら、必ずテストセーブで検証）

ホストが落ちたらどうなる？工場は止まる？

ホスト式（セッション）の場合

ホストが落ちる／ゲームを終了する → その瞬間にセッション終了し、参加者は切断されます
工場のシミュレーションも止まるので、生産・発電・輸送も止まります
再開はホストが同じセーブで再ホストすればOK
※直前の操作が反映されていない場合は、オートセーブの時点まで巻き戻っていることがあります

Dedicated Serverの場合

参加者が落ちてもサーバーが稼働していれば、工場は回り続けます（常時稼働の強み）
逆にサーバー自体が落ちたら、当然そこで止まります
→ 復旧は「サーバー再起動 → 最後のセーブから復帰」が基本です

トラブルを減らすコツ

ホスト式：ホストはできれば有線＋バックグラウンド負荷を止める
Dedicated：更新前バックアップ＋定期再起動を運用に組み込む

SteamとEpicで一緒に遊べる？

できます。やり方は大きく2つです。

方法1：セッションIDで合流（手早い）

ホストがセッション設定画面で セッションIDをコピーして共有
参加側はそのIDを使って参加
「フレンド登録が面倒」「一回だけ遊ぶ」ならこれがラクです

方法2：Epic連携＋フレンド経由（安定運用向け）

ゲーム内の Online Settings でアカウント連携を済ませる
Epic上でフレンドになっておくと、Joinメニューで見つけやすくなります

※補足：最近のサポート情報では、PC（Steam/Epic）間のクロスプレイは可能ですが、PCとコンソールのクロスプレイは別扱いになっています（環境が混ざる場合は要注意）。

マルチでパスワードをかける／公開範囲を絞る方法

「知らない人に入られたくない」なら、まず公開範囲を絞るのが最優先です。

ホスト式（セッション）の考え方

公開範囲は実質的に次の2択が中心です
- 招待制：招待された人だけ参加
- フレンド中心：フレンド経由で参加しやすい（セッションIDが使える設定もここに寄ることが多い）
“完全公開で誰でも参加”の運用は、荒らし対策の面でおすすめしません
→ どうしても外部募集するなら、Discord等で本人確認・ルール・キック基準を決めてから

Dedicated Serverの考え方（最も安全にしやすい）

管理者パスワード（Admin）：設定変更の鍵（サーバー設定や権限操作に必要）
参加者パスワード（Client/Player）：参加そのものを制限する鍵
ルール（これだけ守れば事故が減ります）
- 管理者パスと参加パスは必ず別
- 参加パスは「メンバー固定なら定期変更」
- IPやパスはSNSに貼らず、信頼できる連絡手段で共有

MODはマルチで使える？（導入前の注意点）

使える場合はありますが、初心者ほど「最初は入れない」ほうが安定します。理由はシンプルで、同期ズレ／セーブ破損／更新事故が起きたときの切り分けが一気に難しくなるからです。

マルチでMODを入れるときの大原則

サーバーと全員のクライアントで、MODの種類とバージョンを一致させる
→ 1人でもズレると接続できない／挙動が変になる原因になります
Dedicated Serverでは、MODごとにサーバー対応・非対応があります
→ Satisfactory Mod Manager（SMM）の“サーバー互換”フィルタ等で絞るのが安全

失敗しない導入手順（おすすめ）

本番セーブを触る前に、必ずバックアップ
テスト用セーブでMOD導入 → 接続・建設・ロード/セーブを確認
問題がないのを確認してから本番へ
ゲーム更新が来たら、MOD側の対応状況が揃うまで焦って更新しない（ここで壊れがち）

覚えておくべき注意

公式サポート側でも「MODが原因の不具合はサポート外になりやすい」「MODを外してもセーブに影響が残る場合がある」旨が案内されています
→ 困ったら、まずMODを疑うのが鉄則です

レンタル費用はどう割る？（トラブルにならない決め方）

レンタルは便利ですが、揉める原因はだいたい「お金」と「責任範囲」です。先に“型”を作っておくと平和です。

割り勘のおすすめモデル（揉めにくい順）

A：月額を人数で等分（いちばん簡単）

例：月3,000円／6人 → 1人500円
追加ルール（これが重要）
- 途中参加は「次回更新月から」
- 途中退出は「更新月の区切りで清算」

B：ホスト負担を少し軽くする（現実的）

サーバー管理・告知・バックアップなど、運用負担が出るなら
→ 管理者（払う人）を100〜300円安くするなど、最初に決めておくと後から揉めにくいです

C：デポジット方式（出入りが多いグループ向け）

先に1か月分を預かっておき、退出時に清算
「払わない人が出た」を防ぎやすい

合意しておくと強いチェック項目

支払いタイミング（毎月○日まで）
サーバー停止の判断（誰がいつ止めるか）
大型アップデート時のルール（更新前バックアップ、更新時間の告知）
“荒らし対応”の権限（キック・パス変更の判断）

参考情報

公式情報（オンライン要件／クロスプレイ）

公式情報は、次の順で見ると迷いません。

オンラインの前提条件（EOSログイン、必要アカウント、NAT、必要ポート、Timed out対処）
→ まずここを“正解”にしてから、個別トラブルを切り分けるのが最短です。
大型アップデートで変わった点（オンライン統合／クロスプレイ挙動の変更など）
→ 直近の仕様変更は、パッチノート由来の情報がいちばん確実です。
クロスプレイの仕組み（EOSの役割）
→ Steam/Epic混在の理解が進むと、「なぜセッションが見えないのか」を説明できるようになります。

コミュニティ情報（人数設定・運用のヒント）

コミュニティ情報は“手順が具体的”な反面、環境差で当てはまらないこともあります。おすすめの使い方はこの2つです。

公式Wiki（wiki.gg）で「設定ファイル／起動引数／MaxPlayers」などの全体像をつかむ
→ Dedicated運用の基本と、変更点（INI指定・起動パラメータ）がまとまっています。
ホスティング事業者の手順（Nodecraft等）で「実際の操作手順」を確認する
→ GUIパネル前提で、初心者が迷いにくい説明が多いです。
Q&A／Steamコミュニティ／Redditで“詰まりポイント（設定が消える／5人目が入れない等）”の実例を拾う
→ 「同じ現象の人がいるか」を探す用途に向きます（最終判断は公式寄りに）。