Factorio MODの入れ方・更新・復元【Space Age対応】

Factorio 2.0とSpace Age環境でMODを触りたいなら、ゲーム内Mod Portalの手軽さと、modsフォルダへ置く手動管理の強さを分けて考えるのが安全です。
この記事は、初めてQoL系MODを入れる人から、qualityやElevated Railsを含む公式追加MODの運用まで崩さず進めたい人に向けて書いています。

軸になるのは、ユーザーデータの場所を把握してバックアップを取り、依存関係と起動ログを確認してから更新・無効化・復元するという流れです。
自分も最初は小さなQoL MODを1つだけ入れてログを見てから広げるやり方を徹底し、そのおかげでセーブ事故ゼロのまま大型MODへ移行できました。

FactorioのMOD導入前に知っておきたい前提

対象バージョンと本記事の前提

本記事が前提にしているのは、Factorio 2.0以後の環境です。
MODの導線としては、ゲーム内の「MOD」画面から入る Mod Portal と、ブラウザ版（factorio.com）の Mod Portal を中心に扱います。
コミュニティでは Mod Portal を用いる運用が一般的ですが、Steam Workshop の扱いに関しては一次情報で確認されることをお勧めします（公式の推奨導線は Mod Portal として説明されることが多い、という表現が安全です）。

ここを最初に切り分けておく理由は、FactorioのMOD運用が「ゲーム本体のインストール先」だけで完結しないからです。
セーブ、設定、MOD、script-output などはユーザーデータ側にまとまっており、つまり、同じPC上でも「どのフォルダを見ているか」がズレると、MODを入れたつもりでもゲーム側に出てこない、という初歩的だけれど厄介な食い違いが起きます。

2.0以後は、バニラとDLC、さらに追加MODの境界が以前より見えやすくなりました。
そのぶん、「公式の追加要素もMODとして管理される」という発想に慣れていないと、MOD一覧を開いた瞬間に少し戸惑います。
自分も Space Age 導入直後は、まずDLC由来の追加MODが有効化されているかをMOD画面で見直し、そのうえで quality だけを個別にON/OFFして挙動を掴みました。
この順番で触ると、コミュニティMODを入れる前に公式構成の見え方が理解できるので、混乱しにくくなります。

なお、MODの追加や削除はリプレイデータを壊します。
さらに新しいバージョンを入れる前には、セーブや設定を含むディレクトリのバックアップが推奨されています。
前のセクションで触れた「先に保全してから触る」という流れは、この2.0環境でもそのまま有効です。

Application directory/ja

wiki.factorio.com

公式の導入経路

FactorioでMODを入れるとき、いちばん自然なのはゲーム内Mod Portalから探して入れる流れです。
導入のしやすさ、依存関係の扱いやすさ、更新の追従まで含めると、初回の入口としてはここがもっとも安定しています。
コミュニティでも、ゲーム内ブラウザからのインストール時に必須依存が自動選択される運用は広く使われています。

ブラウザ側の factorio.com にある Mod Portal は、探し物や依存関係の確認に向いています。
とくに「このMODは何に依存しているのか」「どのバージョン系で更新されているのか」を落ち着いて見たいときは、ゲーム内より一覧性があります。
さらに技術寄りの話をすると、大量のMOD構成を扱う人や、サーバー運用、modpackの固定化を考える人にとっては、このAPIの存在を知っているだけでも見通しが変わります。

この方法の強みは、バージョン固定と検証がしやすいことです。
たとえば大型MODを旧版のまま維持したい、更新で構成が崩れるのを避けたい、再現用の環境を残したい、といった場面ではゲーム内導入より扱いやすいのが利点です。
その代わり、依存関係や競合は自分で管理する前提になります。
必要な前提MODが足りなければ普通に起動で止まりますし、DLC必須のものを混ぜればその場で弾かれます。
なお、UI のラベルや設定のデフォルト値はバージョンによって変わる可能性があるため、実際の表記や既定値はゲーム内の設定画面で確認してください。

構成を記録しておきたい場面では、script-output/mods.txt に有効な全MODとバージョンを書き出せるのも便利です。
あとで再現したいときに「何を入れていたか」を人力で思い出さなくて済むので、検証用の環境ではとても助かります。
FactorioのMOD管理は派手な専用ランチャーに頼るというより、公式のMod Portal、ユーザーデータの配置、ログ、出力ファイルを組み合わせて詰めていく設計だと捉えると見通しが立ちます。

Mod portal API

wiki.factorio.com

Space Ageとquality/Elevated Railsの整理

Space Age は2024年10月21日にリリースされた有料拡張で、構成としては3つの追加MODから成っています。
Space Age - 日本語 と英語版の記述をあわせて見ると、内容は大きく、4つの新しい惑星、5種のサイエンスパック、22の建物、30の中間製品、5つの武器、2種類の敵、29の実績が追加されます。
バニラの延長として触り始めても、途中から別フェーズへ踏み込んだ感触になる規模で、このDLC、本当に“もう一本のFactorio”に近いです。

ここで大事なのは、Space Age の追加要素が「ゲーム本体に直接焼き付いた固定機能」ではなく、MOD画面で見える管理対象でもあることです。
だからこそ、導入後にMOD一覧を見たとき「どこまでが公式要素で、どこからがコミュニティMODなのか」が最初は分かりにくいのですが、仕組みとしては普通のMOD管理と同じ画面で把握できます。

その中でも quality 独立したMODとして有効化できますが、利用には Space Age の所有が必要です。
ここが実際きわめて重要で、Space Age を入れたからといって常に quality を含めて遊ぶ必要はありません。
自分は最初に quality だけ切って数時間触り、そのあと有効化して差分を見る形で進めました。
こうすると、レシピや装備感、量産ラインの意味づけがどこから変わるのかを体感でつかみやすいのが利点です。

Elevated Rails も、整理の仕方としては quality と近い感覚で見ておくと混乱しません。
公式要素としての Elevated rail は Space Age 側の機能ですが、Mod Portal にはそれに関連するコミュニティMODも複数あります。
つまり、MOD一覧に「Elevated Rails に関係する名前」が見えても、すべてが同じ意味ではありません。
公式DLCの構成要素としての追加MODなのか、その機能を拡張・前倒し・調整するコミュニティMODなのかを分けて読む必要があります。

この切り分けができるようになると、Space Age 環境でMODを増やすときの判断がずっと楽になります。
まずは公式の3追加MODと quality の関係を理解し、そのあとで QoL や大型MODを重ねる。
Factorio 2.0以後のMOD導入は、この順番で眺めるだけでも事故率が大きく下がります。

MODの入れ方は2通り：ゲーム内Mod Portalと手動導入

ゲーム内Mod Portalでの導入手順

いちばん迷いにくいのは、ゲーム内の「MOD」画面からそのまま Mod Portal を使う方法です。
Factorio ではこの導線が素直で、検索・導入・更新の流れがひとつの画面で完結しやすいのが強みです。
とくにQoL系を数本入れる段階なら、手動で依存関係を追うよりずっと楽です。

実際の流れはシンプルで、メインメニューから「MOD」を開き、インストール用のタブで入れたいMOD名を検索し、対象を選んで導入します。
コミュニティでも広く知られている通り、この方法だと必須依存が自動で選ばれやすいため、初心者ほど恩恵が大きいです。
たとえば単体では動かないライブラリ系MODを要求する場合でも、ゲーム内ブラウザ側で追従してくれることがあります。

導入後はMOD一覧に追加され、有効化された状態で見えることがあります。
ここで重要なのは、インストールできたかどうかだけでなく、起動時にエラーなくロードを通過したかまで見ることです。
依存関係の自動処理は実に便利ですが、互換性まで面倒を見てくれるわけではありません。
大型MODやDLC前提の構成では、導入自体はできてもロード段階で止まることがあります。

技術的には、api/mods/{name}/full では依存関係の配列も取得できます。
普段のプレイでAPIを直接触る必要はありませんが、ゲーム内ブラウザが依存を見ながら扱いやすくなっている背景を知っておくと、なぜこの方法が初心者向けなのかが腑に落ちます。

アカウント作成・Steam連携の注意点

ゲーム内Mod Portalを使うときに少し引っかかりやすいのが、ダウンロードに factorio.com のアカウントが必要になる場面があることです。
SteamでFactorioを遊んでいても、MODの取得経路はそのままSteamの機能に直結しているわけではなく、公式の Mod Portal 側の認証が関わります。

そのため、Steam版の購入者でも factorio.com アカウントを作り、Steamアカウントと連携しておくと整理しやすくなります。
ここを済ませておくと、ゲーム内からMODを探してそのまま入れる流れが安定します。
逆にこの紐付けが曖昧なままだと、「ゲーム本体は起動しているのにMODだけ取れない」という状態になりやすく、初回導入で戸惑う原因になります。

Space Age 環境ではこの認識がとくに効きます。
公式追加要素もMOD一覧の文脈で見えるため、DLC由来の要素とコミュニティMODが同じ画面に並びます。
そこで認証まわりまで混線すると、導入の失敗なのか、所有権の問題なのか、依存エラーなのかが見えにくくなります。
自分は新しい環境を組むとき、先にゲーム内でログイン状態を確認してからMODを触るようにしています。
このひと手間だけで、原因の切り分けが段違いに速くなります。

手動導入（modsフォルダ配置）とzipの扱い

手動導入は、配布されたzipを mods フォルダへそのまま置くのが基本です。
ここで展開して中身のフォルダだけ入れる運用を想像しがちですが、通常はzipのまま配置する考え方で十分です。
Factorio のユーザーデータ側にある mods フォルダを使う点は前述の通りで、write-data を変えているなら、その設定先が実際の配置場所になります。

この方法の強みは、バージョン固定と検証がしやすいことです。
たとえば大型MODを旧版のまま維持したい、更新で構成が崩れるのを避けたい、再現用の環境を残したい、といった場面ではゲーム内導入より扱いやすい構成です。
その代わり、依存関係や競合は自分で管理する前提になります。
必要な前提MODが足りなければ普通に起動で止まりますし、DLC必須のものを混ぜればその場で弾かれます。

見落としやすいのが、同じMODの複数バージョンを同居させないことです。
コミュニティでも、同一MODの別バージョンを mods フォルダに並べたままにすると起動しないケースが知られています。
自分は大型MODを手動導入する前に、mods直下に同名のzipや同名フォルダが重複していないかを毎回見ています。
これだけで起動失敗が減りました。
実務では地味ですが、いちばん効く確認です。

もし手動で構成を詰めるなら、ロード順や停止箇所はログを見るとですし、有効な全MODとバージョンを script-output/mods.txt に書き出しておくと、あとで構成の比較もしやすくなります。
競合を切り分ける段階では、この一覧が想像以上に役立ちます。
互換性で詰まりやすい組み合わせについては、このあと触れる構成整理の考え方とあわせて見ると扱いやすい構成です。

導入方法の選び分け

導入方法は優劣というより、何をしたいかで使い分けるのが実際的です。
初めてのQoL導入や普段のプレイなら、ゲーム内Mod Portalのほうが明らかに楽です。
検索して入れて、依存もある程度拾ってくれるので、構成を広げる初速がとても軽いです。

一方で、旧版固定、検証用の再現、特定構成の保全を重視するなら、手動導入のほうが向いています。
zipを置いて管理する方法は地味ですが、更新に振り回されずに同じ状態を保ちやすいのが大きいです。
Krastorio 2 や Space Exploration のような大型構成を触っていると、この安定感の価値が見えてきます。

両者の違いを短く言うなら、ゲーム内Mod Portalは「導入のしやすさ」、手動導入は「構成の固定しやすさ」です。
ただし手動管理は、依存不足や競合を自分で拾う前提なので、慣れていない段階でいきなり大量導入すると詰まりやすい箇所になります。
そういう意味でも、まずゲーム内で小さく始めて、必要になったら手動へ寄せる流れが自然です。

詳しい見方は、互換性チェックの観点で「依存」「本体対応」「ロード順」を分けて見ると理解できます。

modsフォルダとユーザーデータディレクトリの場所

OS別のユーザーデータとmodsフォルダ

Factorio では、MOD・セーブ・設定ファイルは基本的にユーザーデータディレクトリ配下で管理されます。
手動導入で触る mods フォルダもここにあり、セーブデータや各種設定と同じ系統の保存場所だと理解しておくと迷いにくい設計です。
パスは OS ごとに異なり、正確な構成は

よく使う既定パスだけ先に押さえると、Windows では %APPDATA%\Factorio\mods、Linux では ~/.factorio/mods、macOS では ~/Library/Application Support/factorio/mods が基準です。
ここに saves や設定関連のファイルも並ぶので、MODだけ別物として考えるより、「Factorioのユーザーデータ一式」として見るほうが実務では迷いません。

自分は Windows と Linux のデュアル環境で遊ぶことがありますが、mods だけ個別に追うより、mods saves config をまとめて同じ親ディレクトリ単位で見たほうが圧倒的に楽でした。
バックアップや同期の単位が揃うので、「この環境ではセーブだけ新しい」「こっちは設定だけ古い」といった事故が減ります。
大型MOD構成を行き来すると、この差が効きます。

write-dataオプションが及ぼす影響

見落としやすいのが、実際の保存先は既定パスで固定ではないことです。
Factorio は config/config.ini の write-data 設定によって、ユーザーデータディレクトリの場所を変更できます。
ここを書き換えている場合、MODの保存先も mods フォルダの位置も、その新しい保存先に連動します。

つまり、「Windows だから %APPDATA%\Factorio\mods にあるはず」と思って探しても、write-data を使っている環境では空振りします。
mods だけでなく、saves、設定、script-output までまとめて移るので、手動導入・バックアップ・復元のどれでもこの設定が前提になります。
前のセクションで触れた zip 配置の作業も、実際にはこの write-data が向いているディレクトリに対して行う形です。

この仕様を理解しておくと、複数環境の管理がきれいになります。
自分はデュアル環境で write-data を明示して、ユーザーデータの置き場を意図的に揃える運用にしてから、バックアップと同期が一気に扱いやすくなりました。
mods だけを追うのではなく、保存先の親ディレクトリごと固定する発想にすると、構成の再現性が高まります。

セーブ・設定・player-data.jsonの関係

ユーザーデータディレクトリ配下には、MODやセーブだけでなく、設定とアカウント関連の情報も入っています。
その中で把握しておきたいのが player-data.json です。
これは単なる見た目設定の保管場所ではなく、Mod Portal 用のトークンを含むファイルとして扱われます。
ゲーム内の MOD 取得や API 利用まわりを整理するとき、このファイルの役割を知っていると状況を読み違えにくい点が特徴です。

整理すると、mods は導入したMOD本体、saves はプレイ中の工場データ、各種設定ファイルは操作や表示の環境、player-data.json はプレイヤー情報や Mod Portal 認証の補助情報、という住み分けです。
どれも同じユーザーデータディレクトリにあるので、バックアップや移行では一部だけを見るより、関連ごとまとめて捉えるほうが筋が通ります。

この構造を知っていると、環境移行や復元のときに「MODは戻ったのにログイン状態だけ違う」「セーブはあるのに設定が元に戻らない」といったズレの理由が見えやすくなります。
Factorio のファイル操作は少し無骨ですが、セーブ・設定・認証情報が同じ土台の上にあると理解すると、どこを触れば何が変わるかがはっきりします。

更新・無効化・バックアップの安全な運用手順

更新前チェックリストとバックアップ

本体更新や新しい MOD の導入は、入れる瞬間より入れる前の退避で事故率が大きく変わります。
Factorio は MOD・セーブ・設定が同じユーザーデータディレクトリに集まっているので、更新前は個別ファイルを拾うより、その親ディレクトリを丸ごとバックアップする運用がいちばん崩れにくい設計です。
この保存場所を基準に整理できます。

実務では、更新前に mods と saves だけを別々に退避するより、ユーザーデータディレクトリごと ZIP 化しておくほうが復元が速いです。
自分も大型アップデートの直前はこの単位で固めていますが、不整合が出ても差し戻しが短時間で済みます。
特に Space Age のように公式側の追加要素が大きい更新では、構成の変化が一気に入るので、このひと手間の価値が相応に高いです。

更新前チェックとしては、項目を増やしすぎるより次の3点に絞ると回できます。

1. 現在のユーザーデータディレクトリを丸ごと退避する
2. プレイ継続中のセーブを別名で複製する
3. いま有効な MOD 構成を崩す更新なのかを意識してから適用する

ここで特に重要なのがセーブの複製です。
MOD の追加や削除は、単にロード可否の問題だけでなくリプレイ互換性にも直結します。
MOD 構成が変わるとリプレイデータは壊れます。
普段遊ぶぶんでは見落としがちですが、あとから再現や検証をしたくなったときに効いてくるので、更新前のセーブ複製は保険というより通常運用に近いです。

無効化・復元（ロールバック）の基本

更新後に不具合が出たときは、原因を一気に探しにいくより、直前の安定状態へ戻せるかを先に見たほうが早いです。
Factorio の MOD トラブルは、壊れた 1 つのファイルというより「本体・MOD・セーブの組み合わせ」で起きることが多いので、ロールバックもその組み合わせ単位で考えるのが基本になります。

無効化の第一歩は、追加した MOD や更新した MOD を切り分けることです。
ただし、単にチェックを外せば元通りになるとは限りません。
セーブは読み込めても内容が変質したり、逆にセーブ側がその MOD を前提に保存されていたりします。
とくに生産チェーンやエンティティを増やす系の MOD は影響範囲が広く、外した瞬間に工場が別物になります。

そのため、復元の優先順位は「問題のある MOD を消す」よりも、更新前に複製しておいたセーブと、更新前の mods 状態をセットで戻すほうが安定します。
これなら「セーブだけ古い」「MOD だけ新しい」という半端な状態を避けやすい形になります。
前のセクションで触れた通り、ユーザーデータを親ディレクトリ単位で扱う発想がここでも効きます。

ロールバック時に見落としやすいのが、自動で新しい MOD を有効化する設定です。
mods フォルダへ zip を置いた構成では、次回起動時にその MOD が有効化済みで並ぶことがあります。
復元したつもりでも、余計な zip が残っているだけで再発しやすいので、戻すときは「どのファイルが置かれているか」と「どの MOD が有効になっているか」を同時に揃えるのが筋です。

複数バージョン混在リスクの回避策

旧版を残したくなる場面はあります。
検証用の構成、進行中セーブの延命、特定 MOD の互換待ちなど理由はさまざまですが、ここで起きやすいのが複数バージョンの混在です。
同じ mods フォルダに新旧の zip を積み、さらに本体側も更新していくと、どの組み合わせで動いているのか分かりにくくなります。
トラブル時に切り分けが難しくなるのは、この状態がいちばん典型です。

旧版を残す必要があるなら、運用はできるだけ手動で 1 つに絞るのが安全です。
普段遊ぶ構成と検証構成を同じ場所で共存させるより、「今このセーブで使う MOD 群だけを置く」ほうが、読み込み時の解釈違いや更新取りこぼしを減らせます。
特に手動導入はバージョン固定に強い反面、残骸も残りやすいので、整理しないまま積み上げると事故の温床になります。

Space Age 周辺は公式追加要素と通常 MOD が近い場所で見えるぶん、構成の境界が曖昧になりやすいのも厄介です。
DLC 側の要素を前提にした MOD と、そうでない MOD が同居していると、見た目では似た名前でも意味が違うことがあります。
自分はこの手の混在を避けるため、検証するときほど mods フォルダを細く保ちます。
大量に入れて便利さを取るより、工場をひとつのレシピに絞る感覚で、環境も最小構成にしたほうが結果的に速いです。

複数バージョンをどうしても並行維持するなら、本体・セーブ・MOD 一式を同じ単位で分ける発想が欠かせません。
どれか 1 つだけを残す運用では整合が崩れやすく、あとで見返したときにも再現性が落ちます。
Factorio の MOD 管理は導入時より維持時の差が大きいので、混在を避けて「いま使う構成を明確に 1 つ選ぶ」こと自体が、際立って強い安全策になります。

依存関係・互換性・競合の見分け方

依存関係の読み方

起動しない MOD の多くは、まず依存関係の解釈ミスから崩れます。
Factorio では Mod Portal の各ページに依存関係が載っていることが多く、配布ファイル側でも info.json に依存情報が入っています。
ゲーム内 Mod Portal から入れたときは必須依存が自動で拾われる場面もありますが、手動導入や旧版維持ではこの情報を自分で読む場面がすぐ来ます。

見方としては、「この MOD 単体で動くのか」ではなく、何を前提にしている MOD なのかを見るのがコツです。
たとえばライブラリ系、翻訳補助系、特定のオーバーホール前提の拡張系は、名前だけ見ても依存の重さが分かりにくい構造になっています。
Mod Portal 上の説明文より、依存欄のほうが実際の起動可否に直結することは珍しくありません。

機械的に確認したいなら、『Mod portal API』 で api/mods/{name}/full の情報を見る方法があります。
この full エンドポイントでは dependencies 配列を取得できるので、ゲーム内表示だけでは追いにくいときに実に便利です。
複数人で同じ modset を再現するときや、どの MOD が何を要求しているか整理したいときは、表示より API のほうが内部情報に近く、切り分けが速くなります。

自分は大型 MOD を足すとき、説明文を読む前に依存欄を見ます。
ここを先に押さえると、「便利系を1個追加しただけ」のつもりが、実際には別の基盤 MOD や DLC 前提だった、という事故を避けできます。

Factorio本体バージョン対応の確認

依存関係が揃っていても、本体バージョンが合っていなければ読み込みは止まります。
Factorio の MOD では、その MOD がどの本体バージョン向けに作られているかを外すと設計が崩れます。
とくにメジャー更新直後は、人気 MOD でも追従前のものが残りやすく、導入手順そのものよりここで詰まるケースのほうが目立ちます。

Space Age のリリース日は2024年10月21日で、このタイミング以降は 2.0 系への移行と DLC 対応が一気に進みました。
こういう大きな節目では、昨日まで安定していた構成でも、更新後に一気に非対応が表面化します。
しかも Space Age は追加 MOD という見え方をしつつ、実際には公式拡張の構成要素が絡むので、通常 MOD と同じ感覚で「名前が見えているから使える」と判断するとズレやすい設計です。

Mod Portal の個別ページには対応本体バージョンの情報が出ますし、配布データのメタ情報でも追えます。
見るべきポイントは単純で、自分の Factorio 本体の世代と、MOD 側の対応世代が一致しているかです。
旧版で遊んでいるセーブを延命したいなら、むしろ新しい MOD を追うより、当時の本体と当時の MOD の組み合わせを固定したほうが安定します。
前のセクションで触れた「構成を丸ごと扱う」考え方がここでも効きます。

競合時のエラーメッセージとログの読み方

競合が起きたときは、感覚で犯人探しをするよりエラーメッセージとログの順番を追うほうが早いです。
Factorio は起動時に素直に情報を出してくれるので、落ちた事実そのものより、どの読み込み段階で止まったかを見るのが重要になります。

エラー画面でまず拾いたいのは、失敗した MOD の内部名です。
表示名は親切でも、エラーでは内部名で出ることが多く、ここを取り違えると Mod Portal 上で別物を探し始めてしまいます。
さらに詳しく見るなら、『ログファイル』 にあるロード順や失敗箇所を追います。
ログには「どこまで正常に読めていたか」が残るので、A が壊したように見えて実際には B が足りない、というズレを拾いできます。

ログ読みで見たいのは、派手な英語のエラー全文よりも、その少し手前です。
依存不足、バージョン不一致、他 MOD との定義衝突は、決定打の一行より前に文脈が出ています。
大量 MOD 環境ほど、エラー本文だけ読むよりロードの流れを追ったほうが実態に近づきます。
競合チェックを体系立てて進めるなら、mod-compatibility-check の観点で「依存」「本体対応」「ロード順」を分けて見ると混線しにくい構成になります。

Log file/ja

wiki.factorio.com

内部名（name）と表示名（title）の違い

Factorio の MOD 管理で地味に効いてくるのが、内部名（name）と表示名（title）は別物だという点です。
表示名は Mod Portal やゲーム内で人間向けに見える名前で、内部名は info.json に入っている識別子です。
ログ、依存関係、API、保存データまわりでは内部名が基準になることが多く、トラブル時はこちらを読めないと話がつながりません。

たとえば表示名に装飾語が入っていたり、似たタイトルの派生 MOD が並んでいたりすると、見た目では同系統に見えても内部名はまったく別です。
逆に、タイトルが更新されて分かりやすくなっていても、内部名は古いまま残っていることがあります。
こういう差があるので、エラー文の名前を Mod Portal の見た目だけで探すと、目的の MOD にたどり着けないことがあります。

API を使うときも api/mods/{name}/full の {name} に入るのは基本的に内部名側です。
つまり、依存解決・ログ解析・API 参照は内部名、一覧で探すときは表示名と頭の中で分けておくと混乱しません。
自分も最初のころは title だけ見て追っていたのですが、起動失敗時にログの文字列と Mod Portal 上の表記が噛み合わず、そこで内部名を見る癖がつきました。
MOD が増えるほど、この区別は効きます。

よくあるエラーと対処法

ログイン・アカウント関連のつまずき

ゲーム内 Mod Portal で意外と多いのが、Steam アカウントと factorio.com アカウントを同じものだと思って詰まるケースです。
Steam で Factorio を所持していても、MOD のダウンロード導線では factorio.com 側の認証が絡みます。
ここが分かれているので、Steam には入れているのにゲーム内ではログインできない、という状態が起きます。

とくにありがちなのは、Steam のメールアドレスと factorio.com のユーザー名・パスワードを頭の中で混ぜてしまうことです。
ゲーム内のログイン欄で求められているのがどちらの認証なのかを取り違えると、資格情報そのものは正しいのに通らない、というやや嫌な詰まり方になります。
自分も導入初期はここを雑に覚えていて、Steam 版を持っているのだからそのまま通るだろうと考えて空振りしました。

整理の仕方は単純で、Steam は購入・起動の基盤、factorio.com は MOD 配布側の認証と切り分けると混線しにくい点が特徴です。
ゲーム内でログイン状態を見直すときも、「今入力しているのは factorio.com の情報か」を基準にすると判断が速くなります。
ログインできないときにパスワードだけを何度も試すより、どのアカウントの情報を使っているかを先に揃えたほうが復旧は早いです。

複数バージョン同居/依存不足エラー

手動導入で起きやすいのが、同じ MOD の複数バージョンを mods フォルダに残したままにするパターンです。
更新前の zip を消し忘れて、新旧が同居した状態で起動すると、見た目では最新版を入れたつもりでもロードで止まります。
古い検証用ファイルやバックアップをそのまま置いていると起きやすく、初心者ほど「保存しておけば安心」がそのまま競合の原因になりがちです。

この手のエラーは、mods フォルダ内を見て同じ名前の MOD を 1 つに揃えるだけで解決することが少なくありません。
旧版を残したいなら別フォルダに退避して、ゲームが読む場所には現在使うものだけを置く、という切り分けが効きます。
前のセクションで触れた本体バージョン対応も絡むので、旧セーブ用の構成と現行プレイ用の構成を同じ場所に積み上げるほど、どこかで噛み合わなくなります。

もうひとつ典型なのが依存 MOD の不足です。
ゲーム内ブラウザでは必須依存がある程度拾われますが、手動導入ではそこを自分で埋める必要があります。
エラー文に出ている内部名を手掛かりに Mod Portal の依存欄を見ると、「本体は合っているのに必要な土台 MOD が足りない」だけだった、ということはよくあります。
Space Age 関連や公式追加要素に触れる MOD では、通常の QoL MOD より依存の読み違いが起きやすい印象です。

自分の感覚では、大型 MOD や周辺拡張を触り始めたあたりから、単体で動かすより構成で動かす意識がになります。
1 個ずつ入れているつもりでも、実際には依存先や前提 MOD まで含めて 1 セットなので、足りないのは導入した MOD 本体ではなく、その周囲にあることが多いです。

ロード順・起動失敗時のチェックリスト

起動失敗時は、闇雲に全部切るより直前に何を入れたかと、ログで最後に読まれていた MOD は何かを結びつけると原因に近づきやすく、序盤の安定感が増します。
『ログファイル』 には読み込みの流れが残るので、エラー文の一行だけを見るより、少し前から追ったほうが実態が見えます。
A の行で止まっていても、実際には B の不足や順序の問題で A が巻き込まれている、という並びは珍しくありません。

切り分けでは、いったん怪しい MOD を OFF にして起動し、そこから順に戻すやり方が素直です。
大量導入環境だと面倒に見えますが、最初から全部を疑うより、直近の追加分とログ上の終端を重ねて絞るほうが結果的に速いです。
ロード順が絡むケースでは、単独では起動するのに、組み合わせると失敗する MOD が見えてきます。

実際に見たい項目を絞るなら、次の順番が手に馴染みます。

1. エラー画面に出た内部名を拾う
2. ログでその直前に読まれていた MOD を見る
3. 直近で追加・更新した MOD を一度 OFF にする
4. 起動したら 1 つずつ戻して再現位置を確かめる
5. 依存不足か、重複か、組み合わせ起因かを分ける

mods.txtの記録と復元に使うコマンド

復旧で地味に効くのが、その時点で有効な MOD 構成をテキストで残しておくことです。
Factorio では 『コンソール（mods.txt出力）』 の仕組みを使って script-output/mods.txt に有効な MOD とバージョンを書き出せます。
手動管理でもゲーム内導入でも、この一覧があるだけで「何を入れていたか思い出せない」という事故を減らせます。

とくに更新や大型入れ替えの前後では、zip ファイルを見ても本当に有効だった構成と一致しないことがあります。
mods フォルダに置いてあるもの全部が有効とは限らないからです。
その点、mods.txt は実際に有効だった組み合わせを残せるのが強みです。
自分も起動不能になったとき、script-output/mods.txt を保存しておいたおかげで、あとから同じ構成を手動で並べ直して復旧できたことがあります。
こういう記録は、バックアップとは別の意味で効きます。

コマンド自体は難しくなく、重要なのは「壊れる前の正常構成」と「壊れた直後の構成」を見比べられる形で残せることです。
依存 MOD を入れ忘れたのか、更新で版がズレたのか、あるいは単に有効化状態が変わっただけなのかが、一覧にすると見えやすくなります。
トラブル時の作業を感覚頼りにしないための記録として、mods.txt は十分実用的です。

Console/ja

wiki.factorio.com

発展編：Mod Portal APIやプロファイル的運用の考え方

APIの基本

普段のプレイであれば、ゲーム内の MOD ブラウザ（Mod Portal） から入れる方法がいちばん自然です。
Steam 版の利用者でもゲーム内ブラウザ経由が一般的に使われる導線ではありますが、Steam Workshop の扱いについてはコミュニティ運用に差があるため、公式の情報や自分の環境での挙動を確認したうえで運用方針を決めるのが安全です。

この仕組みの面白いところは、単に「自動で落とす」だけでなく、構成そのものを記録できる点です。
どの MOD を、どの版で、どの依存込みで使うかをテキストやスクリプト側に寄せると、手で覚えていた modset が少しずつ“再現可能な構成”に変わっていきます。
大型 MOD を何本か触る段階になると、この差が効きます。
自分も検証環境を何度も組み直すうちに、GUI だけで管理するより、構成を残せるほうがずっと戻しやすいと感じました。

関連 MOD を探す視点としては、Space Age に対応しているかどうかでまとまりを作るとです（例: Space Age 前提の拡張群、QoL系、翻訳系）。
こうした分類を意識すると、対応可否の判断や検証の優先順位が付けやすくなります。

tokenとplayer-data.jsonの関係

API や認証付きダウンロードで要になるのが player-data.json の token です。
Factorio ではこの token を使って API 認証ができ、username と token を組み合わせると認証付きのダウンロードにも使えます。
ゲーム内ブラウザで普通に使っているぶんには裏側を意識しなくても済みますが、外部ツールや自作スクリプトで Mod Portal から取得する場合は、この組み合わせが実務上の入口になります。

ここで前提になるのが、factorio.com アカウントです。
Steam で Factorio を遊んでいても、MOD のダウンロード導線は factorio.com 側とつながっています。
Steam 版ユーザーがゲーム内ブラウザでログインまわりにつまずくときは、factorio.com アカウントと Steam の連携が整理されていないケースが出やすい特徴があります。
体感としては「Steam で持っているからそのまま全部通る」と思っていると、ここで一度引っかかります。

token は便利ですが、扱いは慎重に見るべき情報です。
設定ファイルを丸ごと共有したり、スクリーンショットに映したまま公開したりすると、ただの導入メモのつもりが認証情報の露出になります。
API を触るのが楽しくなってくると、ついスクリプト内に直接書きたくなりますが、少なくとも公開リポジトリや共有ファイルにそのまま置く運用は避けたいところです。
一般用途では「自分の環境だけで使う認証情報」と割り切るのが実際的です。

プロファイル的運用（環境分離）のヒント

手動導入の強みは、mods フォルダへ zip を置くだけで構成を明示的に持てることです。
Windows なら %APPDATA%\Factorio\mods、Linux なら ~/.factorio/mods、macOS なら ~/Library/Application Support/factorio/mods が基本の置き場です。
ゲーム内ブラウザほど手軽ではない代わりに、「何を置いたか」がそのまま見えるので、旧版維持や検証環境の切り替えではこちらが強くなります。

このとき重要なのは、zip を展開しないでそのまま置く運用を基準にすることです。
Factorio は zip のまま読む前提で扱えるので、手で中身をばらしてしまうより、配布された zip をそのまま管理したほうが混乱しにくい傾向があります。
さらに気をつけたいのが、同じ MOD の複数バージョンを同じ mods フォルダに混在させないことです。
バックアップ感覚で旧版 zip を残しておくと、復元用のつもりだったファイルが起動トラブルの火種になることがあります。
前のセクションで触れた重複問題とも直結する部分です。

ここで効いてくるのが、いわゆるプロファイル的運用です。
Factorio 自体に専用のプロファイル UI があるわけではありませんが、mods フォルダの中身を用途ごとに分けたり、write-data や --mod-directory を使って読み先を切り替えたりすると、実質的に「テスト用」「本番用」「旧セーブ用」のような環境分離ができます。
自分は大型 MOD の検証でこれを使うようになってから、やり直しがずっと楽になりました。
新しい構成を試して壊しても、本番側の安定セットに触れずに済むからです。

ゲーム内ブラウザ中心の運用と、手動配置や API を使った半自動運用は、対立というより役割分担で考えると収まりがいいです。
普段使いはブラウザ、版固定や再現性は手動管理、さらに構成をコードとして持ちたくなったら API、という順で深くしていくと無理がありません。

最初にやることはシンプルで、いきなり盛らずに、小さく試して戻せる状態を作ることです。
自分はこの「小さく試す→記録→拡張」の流れにしてから、MOD運用のトラブルがほぼ消えました。
まず現在のセーブとユーザーデータディレクトリを退避し、ゲーム内の MOD ブラウザで QoL 系を1つだけ入れて起動ログを確認してください。
そこで問題が出なければ、mods.txt やログの見方を手元の習慣にしてから大型 MOD へ進むのが、いちばん安定します。
Space Age 導入済みなら、quality を単体で有効化したときの挙動も先に見ておくと、その後の構成判断がずっと楽になります。

関連記事（候補）