Factorio 列車デバッグ｜LTN配車の診断手順

マルチの列車網を広げていたとき、自分も「鉱石駅は満杯なのに製錬所へ列車が来ない」でしばらく止まりました。
原因は新設した駅の『LTN』Network IDが未設定の0だっただけで、設定を1つ入れたら即復旧です。
こういう詰まり方、見た目だけでは信号なのか回路なのか配車なのか判断しづらいんですよね。

この記事は Factorio 2.0 / Space Age 環境で列車網を運用している中級者を主な対象としています。
LTN を併用する場合は、導入する LTN 本体や補助 MOD（例: LTN Manager、LTN Combinator Modernized 等）が Factorio 2.0 に対応しているか、mods.factorio.com の各 MOD ページで「対応バージョン」「最終更新日」を必ず確認してください。
MOD のポーティング状況は差があり、動作保証を断定できないため、個別確認を促します。

この記事の対象と想定読者

この記事が前提にしているのは、『Factorio 2.0』系と『Space Age』環境で列車網を組んでいて、そこへ『LTN』2.0系の考え方も持ち込みたい人です。
バニラ列車の固定スケジュールは触れるけれど、複線化したあたりから「動かない理由の切り分け」に時間を取られ始めた中級者を主な対象にしています。
信号の置き忘れなのか、駅設定なのか、回路なのか、配車なのか。
この境目が曖昧になった瞬間に手が止まるので、最初に前提を揃えておく必要があります。

LTN - Logistic Train Networkは、列車をデポで待機させて、供給と要求に応じて仕事を割り当てる方式のMODです。
固定ルートを走らせるバニラ列車とは頭の使いどころが違います。
LTN Manualでもこの考え方が運用の中心として整理されていて、Provider、Requester、Depotの3役が基本になります。
汎用列車を共用できるので、大規模運用では必要車両数を3割以下まで圧縮できるケースがある一方、トラブル時は「線路」だけ見ても答えに届かない場面が増えます。

このセクションでは、記事全体の方針も先に宣言しておきます。
順番は症状→確認→修正で固定です。
いきなり配線を組み替えたり、信号を置き直したりすると、別の原因を上書きして泥沼になります。
自分もこれで何度も遠回りしました。
症状を見て、原因候補を絞り、その候補に対応した確認をしてから直す。
この順番で進めると、100駅を超えるネットワークでも崩れません。

なお、『LTN』2.2.0以降はDefault Network IDが0です。
ここは見落としやすいのですが、明示的なNetwork ID信号を入れていない駅は、実質的にネットワークへ参加していない扱いになります。
見た目は駅として完成していても、仕事は発生しません。
前の導入部でも触れた通り、この一点だけで「駅はあるのに配車されない」が成立します。

Upcoming features

wiki.factorio.com

バニラ vs LTN — デバッグ観点の違い

バニラ列車のデバッグは、まず物理的にそこへ行けるかどうかから始まります。
線路がつながっているか、駅の向きが合っているか、信号の向きが逆ではないか、ブロックが壊れていないか。
コミュニティでは駅や線路をホバーして接続矢印を追う方法がよく紹介されており、到達不能の原因は絞れます。

一方で『LTN』は、線路が正しくても仕事が発生しないことがあります。
デポがない、駅がRequesterになっていない、Provide ThresholdやRequest Thresholdを超えていない、Network IDが一致していない、回路条件を使っているのにsend to trainが入っていない。
つまり、列車が走れないのか、そもそも走る仕事が作られていないのかを最初に分けないと、確認箇所がずれます。
ここを混同すると、信号を直しても未配車は直らず、逆に回路をいじっても到達不能は直りません。

この違いは、Factorio 2.0のInterruptsでバニラ運用を高度化している場合にも効いてきます。
見た目はLTN風でも、実体が固定スケジュール＋割り込みなら、根本のデバッグ軸はバニラ寄りです。
供給駅の有効化やstation limit制御で列車をさばく設計はできますが、供給駅数より待機車両数が多いと、理屈の上では余った列車が供給側に滞留します。
自分の感覚でも、ここは「LTNを入れるか」「バニラ回路で自作するか」のコスト差がはっきり出るところで、どちらの仕組みで動いているのかを曖昧にしたまま追うと、診断がブレます。

交差点まわりも同じです。
自分は一度、手動運転だと通れるのに自動運転だけ失敗する交差点に当たりました。
最初は信号間隔を疑っていたのですが、実際の原因は駅停止矢印の向きと、交差点入口でのブロック定義の見落としでした。
手動では抜けられるので線路断線ではない、でも自動では経路として認識されない。
この手の症状は、バニラなら経路認識、LTNならその前段の配車成立と切り分けて追うと早く当たります。

LTN Combinator Modernizedを使っている場合も、定数回路を直接読む感覚とは少し違います。
設定値はGUIで触れていても、中身はNetwork IDや閾値、役割信号の組み合わせです。
見た目が親切になっても、確認する論点までは自動で減りません。
UIが整っているほど「設定したつもり」で止まりやすいので、どの役割の駅で、どの信号が入り、何が不足すると未配車になるのかを先に整理しておくと迷いません。

LTN Manager

A GUI for managing your Logistic Train Network.

mods.factorio.com

症状4分類と対応チェック項目

切り分けの起点は、列車がどう壊れて見えるかです。
この記事では「到達不能」「渋滞」「LTN未配車」「混載」の4つに分けます。
最初から細かいケース分けを増やすより、この4分類で入口を固定したほうが、確認範囲を一気に絞れます。

表の見方も一つに固定します。
到達不能は線路、渋滞は信号と待機容量、LTN未配車は役割と回路、混載は積み降ろし条件です。
特にLTN未配車は、見た目が静かなぶん厄介です。
駅に資材がある、要求側も空いている、線路もつながっている。
それでも列車が出ないなら、配車条件が1つ欠けています。
ここでNetwork IDとデポを同時に見ないと、延々と別の場所を触ることになります。

混載は、見た目の派手さのわりに根が地味です。
積み込み完了条件が甘くて残り1スタックを抱えたまま次の仕事へ出る、貨車が最後の1スタックを下ろし切る前に次の配車が入る、インサータが止まらず積載量が揺れ続けて列車が発車条件を満たさない。
自分の運用でも、混載の大半は「列車が悪い」のではなく「駅の停止条件が雑だった」に着地しました。
ここも症状から入って、対象を駅ロジックに絞ると追いやすくなります。

この先の各セクションでは、4分類ごとに確認箇所を掘り下げていきます。
バニラ列車と『LTN』を同じ棚に入れず、どの層で壊れているかを見分けることが、最短で直すための前提になります。

バニラ列車の不具合を切り分ける基本手順

駅・線路接続の即席チェック

Can’t reach destinationが出たときは、まず駅そのものが線路にどうつながっているかを見ます。
ここで最初に効くのが、駅にカーソルを合わせたときのホバー表示です。
停止位置の矢印が進行方向と噛み合っているか、駅が置かれているレールの向きと接続先が連続しているかを見るだけで、配線ミスの多くはこの段階で落とせます。
新しく引いた側線に駅を足した直後は、見た目ではつながっていても、停止位置の向きが逆で自動列車だけ入れないことがあるんですよね。

線路側は、Ctrl を押しながらレールをなぞって経路を追うと早いです。
コミュニティでもよく使われている方法で、想定しているルートがどこまで連続しているか、途中で赤い閉塞や切れた接続がないかを目で追えます。
How to debug a trainsystem?で語られている基本の考え方もここに近くて、列車が通るはずの道を人間の目で一本の線として確認するわけです。
交差点をまたぐ長い路線でも、地図をぐるぐる回すより、目的地まで一本ずつなぞったほうが早く詰まり場所が見つかります。

この確認で一緒に見ておきたいのが、駅の有効化状態とスケジュール条件です。
経路が通っていても、駅が無効化されていれば目的地候補に入りませんし、発車条件が変で列車が前駅から出られないケースもあります。
見た目は「到達不能」っぽいのに、実際は一時停止点や発車条件の設定違いだった、というのは中盤以降だとわりと起きます。
優先順位としては、線路接続、その次に駅の向き、その次にスケジュール条件を見ると迷いません。

信号の向きとブロック長を最短で見抜く

手動走行で通れたのに自動運転では止まるときは、だいたい信号まわりです。
ここで意識したいのは、手動はプレイヤーが無理に進められても、自動列車は信号とブロック規則に従って「予約できる進路」しか選ばない、という違いです。
つまり、手で通せた事実は経路成立の証明にはなりません。
片方向信号が逆を向いている、交差点の手前だけ信号がなくてブロックが大きすぎる、逆に短く切りすぎて列車が交差点の中にはみ出す、といった問題は自動運転でだけ表面化します。

信号の向きは、まず片側だけに置いた通常信号が進行方向に対して正しい面を向いているかを見ます。
複線のつもりで組んだのに、片方だけ逆向き信号が混じっていて、その区間だけ一方通行扱いになっていることがあるわけです。
特に駅の出入り口や仮設の迂回線は、敷き直しの途中で向きが混ざりやすいのが利点です。
Ctrl で経路をなぞったときに、ある位置から先へ進路が伸びないなら、その直前の信号面を見ると原因が出ることが多いです。

ブロック長も見逃せません。
列車長より短いブロックが交差点や合流の直前直後にあると、先頭車両は入れても後ろが本線や分岐を塞ぎます。
すると後続列車が予約できず、見た目は「全員止まっているのに壊れている場所がわからない」状態になります。
列車1本が収まる長さに少し余裕を足した区間を1ブロックとして考えると、原因の切り分けが一気に進みます。
短いブロックを増やせば流れるわけではなく、出口が空く前に次の列車を押し込む形になると、むしろ詰まりの種になります。

合流・交差点・スタッカーの要所

合流部と交差点は、線路がつながっていても止まりやすい場所です。
見る順番としては、進入にチェーン信号、退出に通常信号が置かれているか、その間のブロックに列車1本が収まるか、出口先が詰まっていないかを追うと整理できます。
チェーン信号は「抜け切れるなら入れ」、通常信号は「このブロックが空いたら進め」という役割なので、交差点の中に通常信号を乱立させるより、入口と出口の責任分界をはっきりさせたほうが挙動が読みやすくなります。

合流部では、合流後すぐ先に十分な空きブロックがあるかも見ます。
ここが短いと、1本が本線に頭だけ出して停止し、もう片方の支線もまとめて止めます。
複線本線へ資源列車を流し込むときに起きがちで、線路自体は正しいのに容量の置き方が悪くて渋滞します。
待避線やスタッカーがない駅前でも同じで、本線上で順番待ちを始める構造だと、駅の問題が本線全体へ波及します。

スタッカーは入口より出口のほうが事故ポイントになりやすいのが利点です。
自分も一度、スタッカー出口に通常信号を置き忘れて、入口側を全部チェーン信号で固めたまま動かしていたことがありました。
見た目は整っているのに、どの列車も「先が予約できない」と判断して凍りついたんです。
あのときは交差点を疑って遠回りしましたが、原因は出口の1本でした。
チェーン信号だけでは列車を解放できないので、待機列の出口には通常信号でブロックの終端を作る必要があります。

交差点やスタッカーで詰まりが出たときは、単に信号の数を増やすより、「どの列車がどこまでを1回で予約すべきか」を基準に見ると整います。
合流前後、交差点内部、スタッカー出口の3か所を先に押さえると、初歩的な経路不良と信号不良は短時間でだいぶ除外できます。

LTNの仕組みをデバッグ視点で理解する

Provider/Requester/Depotの役割整理

LTNをデバッグするとき、最初に頭の中で分けたいのはProviderRequesterDepotの3役です。
ここが混ざると、在庫はあるのに列車が来ない、列車はいるのに仕事を取らない、という状態を見ても原因の場所を外します。
LTN - Logistic Train Networkの思想そのものが、供給駅と需要駅を汎用列車でつなぎ、その列車を平常時はデポに置いておく形なので、まず役割を固定して見ると切り分けが一気に進みます。

Providerは「何をどれだけ出せるか」をLTNへ知らせる駅です。
鉱石の積み込み駅、板材の出荷駅、流体タンクの払い出し駅がここに入ります。
Requesterは逆に「何がどれだけ欲しいか」を出す駅で、製錬所の鉱石受け入れ、工場ラインの中間材受け入れなどが該当します。
Depotは荷役をしない待機場所で、自動列車をここに並べ、仕事が発生したらここから配車されます。
つまりデポは「余った列車の置き場」ではなく、LTNの出発点です。
デポがないと、汎用列車をどこから呼ぶのかが曖昧になって、未配車の原因を追う以前に構成が崩れます。

LTN駅の構成も、駅名看板ひとつで完結しているわけではありません。
役割があるのは大きく3つで、列車が停車する駅本体（Stop）、LTNへ条件を渡す入力、状態やエラーを受け取る出力です。
入力はLTN Combinatorや対応するコンビネータ側で行い、出力はランプや回路側で受けます。
ここで詰まりやすいのが、配線を駅本体に直接つないで「設定したはずなのに反映されない」と悩むパターンです。
LTNは指定のI/Oを見ているので、駅の近くに置いてある対象へ正しくつながっていないと、見た目だけ駅がある状態になります。

自分も最初、この構造をふわっと理解したまま鉱石駅を増やしていました。
鉱石Providerを量産したのにNo station supplying...が消えず、在庫は山ほどあるのにどこも候補にならなかったんです。
あれこれしきい値や貨車設定を疑って遠回りしましたが、実際には駅ごとの信号がばらばらで、ネットワーク所属がそろっていませんでした。
ID信号をまとめて引き回したら、その場で配車が通り始めて、「LTNは駅単体を見るより、駅がどのネットワークに属しているかを先に見るべきだ」と腹落ちしました。

LTN - Logistic Train Network

Adds logistic-train-stops acting as anchor points for building a fully automated, train logistic network.

mods.factorio.com

Network ID・Threshold・Send to trainの必須理解

LTNの未配車でいちばん見落としやすいのがNetwork IDです。
これは「どの駅同士を同じ物流ネットワークとして扱うか」を決める信号で、同じIDを持つ駅同士だけが配車対象になります。
鉱石Providerがどれだけ在庫を抱えていても、Requester側とIDが違えば存在しないのと同じです。
LTN Manualでもこの前提が明示されていて、2.2.0以降の既定値は 0 です。
昔の情報だと既定が別値の説明を見かけますが、今は「何も設定していない駅は0」という理解で揃えたほうが事故が減ります。

この0が曲者で、未設定のまま量産すると「全部同じ0だからつながるはず」と思い込みやすい一方、拠点ごとにIDを分ける設計へ途中から移ったとき、古い駅と新しい駅が混ざって原因不明の未配車を起こします。
自分がNo station supplying...で詰まったときもまさにこれで、鉱石のProvider群だけ未設定0のまま増設し、Requester側だけ別IDへ切り分けていました。
見た目は全部LTN駅なのに、一方は所属あり、もう一方は未所属扱いのままです。
ID信号を共通線で一括投入したら一発で解消したので、駅単位の在庫より先に「その駅はどのネットワークにいるか」を見る癖がつきました。

しきい値も同じくらい引っかかります。
Provide ThresholdとRequest Thresholdの既定値は、マニュアル準拠でどちらも 1000 です。
Provider側は、供給可能量がこの値未満だと候補に上がりません。
Requester側も、欲しい量がこの値未満だと依頼を出しません。
つまり、鉱石が800だけ余っているProviderや、弾薬を600だけ欲しいRequesterは、設定を変えていない限り静かなままです。
駅が壊れているのではなく、「まだ発注ラインに達していない」だけ、というわけです。

この挙動は、1-1編成や小口配送を作ったときに特に混乱します。
列車容量よりしきい値のほうが大きいと、在庫や要求が積み込み単位に届いていても案件化しません。
逆に、しきい値を下げすぎると細かい配車が増えて、デポから列車が頻繁に出入りします。
LTNは汎用列車の共用が得意で、条件がハマると列車数を3割以下に抑えられるケースもありますが、その前提には「案件として切る最小単位」が運用に合っていることが含まれます。

Send to trainも未配車デバッグで外せません。
これはLTN駅の信号を列車へ送る設定で、特にスケジュール側で circuit conditions を使う構成では前提になります。
ただし、この機能は一部の駅だけ有効にしても意味が薄く、全LTN駅で有効にして、なおかつ回路接続も成立していることが条件です。
片方だけON、もう片方は未接続のままだと、列車側が受け取るべき情報が欠けて、見た目は駅設定が正しくても列車が意図通り動きません。
ここは「RequesterだけONにした」「Depotは関係ないと思って切った」で沼に入る場所です。

更新間隔・メッセージフィルタ等の運用設定

LTNは配車ロジックだけでなく、運用設定もデバッグ結果に直結します。
典型例がメッセージ表示です。
エラーが出たはずなのに見失う、同じ警告が出なくなって直ったと勘違いする、というのは珍しくありません。
マニュアル上のMessage filter timeout既定値は 18000 ticks で、同種メッセージの再表示を抑える仕組みがあります。
デバッグ中は、実際には同じ失敗を繰り返しているのに、通知だけ静かになることがあるわけです。
自分も一度、Provider不足が直ったと思って配線を戻したら、単に再表示抑制で黙っていただけ、ということがありました。

この仕様を知っていると、メッセージが出ないことを「正常」の証拠にしなくなります。
ランプ出力や駅の信号値、配車ログの変化と合わせて見る発想に切り替わるので、通知欄だけを追って空振りする時間が減ります。
LTNは回路で静かに失敗する場面があるので、エラー文がない＝設定OK、とは読まないほうが実態に合います。

運用面では、問題が起きたときだけ設定を触るのではなく、駅数が増えてきた段階で「どのくらいの更新粒度で回すか」「通知をどこまで信用するか」を揃えておくと、後からデバッグするときの手がかりがそろいます。
参考までにユーザー報告のベンチマークではProject Cybersynが特定条件下でわずかに軽かったという報告（平均差約0.01ms）がありますが、これはマップ構成・駅数・MODバージョンなど条件依存が大きいため参考値として扱い、自分の環境での検証を必ず行ってください。

LTNでよくあるエラー別の確認手順

No station supplying found

LTNで一番見かけるエラー文のひとつがこれです。
意味はそのままで、要求に合う供給駅が見つかっていません。
厄介なのは、供給駅に在庫が山ほどあるように見えても、LTN側の条件では「供給可能」と判定されていないことがある点です。
自分も最初は「鉱石が入っているのに、なぜ供給なし扱いなのか」で止まりました。
実際は在庫そのものではなく、どの信号がどこへ届いているかの問題でした。

まず見るべき場所を、症状から逆算すると次の表になります。

LTNでは、駅にある箱の中身と、LTNが認識している供給量が一致しないことがあります。
典型例は、Providerの在庫を読み出す配線がtrain stop本体に刺さっていて、LTNが読むべき入力へ届いていないケースです。
ここ、地味に罠です。
駅を選択すると存在感があるので本体に線をつなぎたくなるのですが、LTNの設定や在庫信号は、構成によってはstation本体ではなくlamp/input側へ配線しないと正しく流れません。
見た目ではつながっていても、LTNにとっては無信号のままです。

短く切り分けるなら、手順はこの順番が速いです。

• Requester側とProvider側のNetwork IDを見る
• Providerが出している在庫信号の品目名を見る
• その在庫量がProvide Thresholdを超えているか見る
• Requester側とProvider側のNetwork IDを見る。
• Providerが出している在庫信号の品目名を見る。
• その在庫量がProvide Thresholdを超えているかを確認する。
• Input配線が駅本体ではなく、LTNが読むランプや input 側に入っているか確認する。
• 赤線と緑線を混在させていないかを確認する。

修正例としては、Provider駅のUIでProvide Thresholdを見直し、同じ画面でNetwork IDが期待どおりに入力されているかを確認します。
スクリーンショットを撮るなら、駅GUIのLTN設定欄でNetwork IDとProvide Thresholdが同時に見える状態、かつ配線先が train stop 本体ではなくランプや input 側に刺さっていることが確認できる画角を1枚ずつ押さえておくと、後で見返したときに原因特定が速くなります。

要求があるのに配車されない

こちらはエラー文が出ないのに止まることが多く、体感ではいちばん時間を溶かします。
Requesterが要求信号を出していて、Providerにも在庫があり、なのに列車が出ない。
こういうときは供給条件よりも、列車側とデポ側が案件を受け取れる状態かを先に疑ったほうが当たりが多いです。

自分が実際に引っかかったのは、デポ未認識のまま拠点を拡張したケースでした。
見た目では待機駅が並んでいるのに、LTNからはデポ扱いされず、空いた車両が通常駅へ退避してネットワーク全体が詰まりました。
マップ上では各所に列車が散って、交差点まで渋滞し始めたので線路設計の問題に見えたのですが、原因はデポフラグの抜けとNetwork ID不一致でした。
そこを立て直してIDをそろえたら、待機車両が元の流れに戻って即座に復帰しました。
LTNは駅設定ひとつで列車全体の居場所が変わるので、この手の詰まり方をします。

症状と確認点を整理するとこうなります。

ここで見落としやすいのが、列車編成の不一致です。
たとえば1-2編成前提の駅に1-4編成の汎用列車を混ぜると、ネットワーク上は空き列車が存在していても、案件に使えない扱いになります。
貨車フィルタを使っている構成なら、空車でも適格列車として拾われないことがあります。
要求があるのに無反応なら、在庫より先に「その列車はその仕事を受けられるか」を見たほうが早いです。

Send to train絡みもここで効きます。
駅側のSchedule circuit conditionsを使っているのに、信号送信が片側だけ無効だと、列車が受け取るべき指示が欠けます。
駅UIでは設定済みに見えるのに、列車は案件を成立させられない、という止まり方になります。
LTN Manualで説明されているこの周辺の条件は、見た目より連動が強いです。
UI確認のスクリーンショットを残すなら、各駅のLTN設定欄でSend to trainのチェック位置、列車スケジュール側の回路条件欄、デポ駅の役割設定が同時に追える並びが役に立ちます。

チェックリストとしては、次の順番だと空振りが減ります。

• デポ駅が本当にデポ扱いになっているかを確認する。
• デポと対象駅のNetwork IDがそろっているかを確認する。
• 空き列車の編成が案件条件に合うかを確認する。
• 貨車フィルタや長さ制限で弾かれていないかを確認する。
• デポ駅が本当にデポ扱いになっているかを確認する。
• デポと対象駅のNetwork IDがそろっているかを確認する。
• 空き列車の編成が案件条件（長さ・フィルタ等）に合っているかを確認する。
• Schedule circuit conditionsとSend to trainが噛み合っているか、通知欄が静かでも表示抑止で見逃していないかを確認する。

列車が動かない・デポから出ない

こちらは「LTNが壊れた」というより、配車成立前のどこかで列車が待機し続けている状態です。
デポに並んだまま出ない、あるいは案件が出ても1本も反応しないなら、まずデポ駅自体が有効か、空き列車が存在するかを切り分けます。

表にすると、確認の筋道はこうなります。

ここで厄介なのは、LTNの問題とバニラ列車の経路問題が重なって見えることです。
案件自体は成立しているのに、予約済みの駅や出口ブロック詰まりでデポから出られない場合、表面上は「未配車」に見えます。
自分はこういうとき、LTN設定画面だけ見続けて遠回りしました。
実際には列車が目的地を持っていて、ただ線路側で進めないだけでした。
前述のバニラ切り分けに戻って、予約状態と交差点の詰まりを並べて見ると、LTN側の犯人探しを続けずに済みます。

更新間隔も地味に効きます。
駅数が増えたネットワークでは、状態更新が粗いと「動かない」のではなく「まだ評価されていない」時間が伸びます。
配車遅延と配車失敗を混同すると、正しい設定まで崩しがちです。
とくに変更直後は、設定ミスより先に更新待ちを疑ったほうが流れを読み違えません。

短手順で見るなら次です。

• デポ駅が有効で、LTN入力が生きているか確認する。
• デポ所属の空き列車が存在するか確認する。
• デポのNetwork IDがRequester/Provider側と一致しているか確認する。
• デポ駅が有効で、LTN入力が生きているか確認する。
• デポ所属の空き列車が存在するか確認する。
• デポのNetwork IDがRequester/Provider側と一致しているか確認する。
• 列車がすでに別駅を予約して詰まっていないか確認する。
• 変更直後なら更新待ちの時間を挟んで、状態が変わるかを確認する。

デポ未認識・wrong wireの典型

LTNのトラブルは、結局ここに戻ってくることが多いです。
デポがデポとして認識されない、信号が届かない、値は出ているのに相手が読んでいない、という類の失敗が中心になります。

まず典型例を表にまとめます。

デポ未認識では、Depot flagが入っていないだけでなく、駅本体に配線して終わったつもりになっているケースが本当に多いです。
LTN系の構成では、station本体ではなく、設定信号を受けるlamp/input側へつなぐ前提になっているものがあります。
ここを外すと、デポ信号もNetwork IDもLTNから見えません。
駅はある、列車も止まっている、でもLTNからは普通の停車駅か、ただの無関係な駅に見えます。

wrong wireも同じで、赤線で流したつもりが途中だけ緑線になって別ネットワークへ分離している、ランプの入出力を逆に見ている、定数コンビネータで品目信号ではなく仮想信号を送っている、といったミスが重なります。
こういうときは複雑な回路式を追うより、1マスずつ線をたどったほうが早いです。
How do I troubleshoot LTN?のようなコミュニティ事例でも、最終的に配線先の勘違いへ戻る例が多いのは納得できます。

チェックリストにすると次の形です。

• デポ信号が入っているか確認する。
• デポ駅のNetwork IDが合っているか確認する。
• 配線先がstation本体ではなく、LTNが読むランプやinputか確認する。
• 赤線と緑線が途中で分離していないか確認する。
• ランプ、コンビネータの向きが合っているか確認する。
• item信号と仮想信号を取り違えていないか

修正例としてスクリーンショットを撮るなら、デポ駅のLTN設定欄でNetwork IDが見える画面、しきい値が見えるProvider側UI、そして各駅のSend to train位置が見えるUIを押さえておくと、再発時に比較しやすくなります。
配線画面は、train stop本体に刺さっていないことと、ランプまたはinputに刺さっていることが一目で分かる角度だと、wrong wireの洗い直しが一気に進みます。

荷物残留・混載・過積載を防ぐ駅設計

Providerの積み込み制御テンプレ

混載や過積載を止める設計は、結局のところ「発車前に帳尻を合わせる」のではなく、積み込み中に余計な1スタックも入れないところまで駅側で締める、という話です。
LTNの案件生成を直しても、Provider駅が無制限に積み込む構成だと、1本の列車の中で事故が増えます。
自分はここを甘く見ていて、最初のうちは「配車が正しければ荷物も正しく乗るはず」と考えていました。
でも実運用では、インサータが止まる条件を入れていない駅ほど、残荷と混載の発生源になりました。

設計原則は単純で、積み込みが完了してから発車させることです。
Factorioの列車は、貨車の積載量が変化している間は発車しない前提で組めるので、この挙動を利用して「必要量に達したらインサータを止める」回路にすると、積み込み完了と発車条件が自然につながります。
列車を無理に待たせるのではなく、貨車の積載量を変化させない状態を作って発車させるわけです。

Provider駅で見る信号は、貨車内の量だけだと足りません。
実際にはL（貨車内）+ B（積み込みバッファ）で上限を見ます。
バッファチェストにまだアイテムが残っているのに「貨車内だけ見て到達済み」と判定すると、次のインサータ動作で積み過ぎます。
たとえば要求量に対して、貨車に入った量と、すでに手前のチェストへ運ばれている量の合計が上限に達したら、積み込み用インサータを止める形です。
これでインサータの慣性分まで吸収できます。

混載防止では、フィルタインサータで品目固定を入れておくと事故率が一気に下がります。
『LTN』側で正しい案件が出ていても、駅のベルトやバッファに異物が1種類でも混ざると、無条件インサータはそのまま拾います。
そこでProviderテンプレートは、対象品目ごとにホワイトリスト化しておくのが安定です。
LTN Combinator Modernizedのような補助系を使う構成でも、現場の積み込み口が自由入力だと事故は止まりません。
駅テンプレート側で「この口は鉄鉱石だけ」「この口は銅板だけ」と固定しておくほうが、あとで人が増えたマルチ環境でも崩れません。

自分が今よく使う考え方は次の3点です。

• 供給品目は駅単位で固定し、積み込みインサータにも同じ品目フィルタを入れる
• 停止条件は貨車内だけでなく、バッファを含めた合計で判定する
• 上限到達後はインサータを止め、貨車の積載量変化を止めてから発車に入る

この形にしてから、Provider駅での「少しだけ多い」が消えました。
少しの超過でも、Requester側で受入上限にぶつかると残荷になります。
残荷はその列車だけの問題で終わらず、次の案件で別品目を取りに行った瞬間に混載へ変わるので、Providerで余計に積まない設計が最初の防波堤になります。
LTN Manualでもしきい値や回路条件の前提が運用の肝になっていますが、現場の感覚としては、案件生成より駅の積み込み停止条件のほうが先に壊れます。

スクリーンショットを入れるなら、Provider最小構成として、貨車読み取り、バッファ読み取り、インサータ停止条件の3点が同時に見える図があると伝わりやすいのが利点です。

Requesterの受入制御テンプレ

Requester駅も考え方は同じで、必要量を受け取ったらそれ以上は降ろさないが基本です。
ここを「列車が持ってきた分は全部下ろす」にすると、供給側で少し多かった荷物がそのまま流れ込み、駅在庫が膨らむだけでなく、降ろしきれなかった端数が列車に残ります。
つまり過積載の発生源はProviderだけではなく、受入側の無制限アンロードにもあります。

Requesterでは、受入在庫が目標量に達した時点でアンロード用インサータを止めます。
監視対象は、駅の受入チェストやその直後のバッファです。
列車から降ろした瞬間にベルトへ流す構成でも、駅が「いま何個まで受け取る案件なのか」を回路で見て、到達後は積み下ろしを止めるほうが後腐れがありません。
列車の中に荷物が残るのは一見まずそうに見えますが、必要量に達したのにさらに降ろして在庫をあふれさせるより、駅テンプレートとしては筋が通っています。
残荷はこの後のデポで隔離します。

ここでもフィルタの標準化が効きます。
Requester駅のアンロード口を品目固定にしておけば、万一残荷列車が紛れ込んでも、別品目を降ろして受入ラインを汚す事故を抑えられます。
理想は残荷列車をRequesterへ入れないことですが、現場では一度の設定漏れで事故が起きます。
そのとき、駅側まで無制限だと被害が広がります。
受入テンプレートにホワイトリストを入れておくと、事故の範囲がその駅の入口で止まります。

自分は昔、残荷を抱えた列車がそのまま次の駅へ回り、そこで別品目のインサータが動いて、列車全体が混載で崩壊したことがあります。
1本のミスが次の駅、その次の駅へと伝染して、ネットワーク全体の荷物が濁るんですよね。
見た目は1駅の事故でも、実際には列車を共用している時点で全体障害です。
そこからはRequester側でも「目標量到達でアンロード停止」を徹底するようになって、少なくとも受入超過から始まる事故は止まりました。

スクリーンショット候補としては、Requester最小構成図に、在庫目標と現在量の比較、アンロード用インサータの停止条件、品目フィルタの3点が入っていると、再発防止の意図が伝わります。

デポの残荷隔離・自動クリア動線

ProviderとRequesterで締めても、運用のどこかで残荷列車は出ます。
だからこそデポ設計では、残荷を抱えた列車を運用に戻さないことが絶対条件です。
ここを素通しにすると、空車前提で配車されるLTNの共用列車が、次の駅を汚染します。
自分は一度これで列車網を丸ごと壊しました。
残荷を積んだ列車が次の案件先で別品目を触り、さらにその列車がまた別駅を汚して、気付いた頃には複数路線で混載が連鎖していました。
デポ分岐に残荷クリア線を増設してからは、この手の再発は止まっています。

テンプレートとしては、デポ入口で列車内アイテムを読み、車内アイテム > 0 なら隔離線へ分岐、0なら通常デポへ入れる形がわかりやすいのが利点です。
ロジック自体は簡易で十分で、貨車読み取りの合計が0かどうかだけでも機能します。
要は「空車デポ」と「残荷処理デポ」を物理的に分けることです。
空車だけが待機列車として再投入される構造にすると、RequesterやProviderのテンプレートで取りこぼした事故がそこで止まります。

残荷クリア線の中では、品目ごとのフィルタインサータでアンロードし、異物が一般在庫へ混ざらないようにします。
複数品目を扱う可能性があるなら、ホワイトリスト化した仕分け口へ流すか、専用の廃棄・返送ラインへ抜く形が安定です。
重要なのは、デポの本線上で中途半端に降ろさないことです。
待機列車の並びに残荷処理を混ぜると、詰まりと誤進入が増えます。
隔離線で停止、クリア、空車確認、通常デポへ復帰という一方向の動線にしておくと、トラブル時でも追跡が簡単です。

この手の分岐は、駅テンプレートとして全品目共通にしておくと運用が軽くなります。
LTN - Logistic Train Networkの考え方自体は汎用列車を共用して本数を抑えるところに強みがあり、条件がはまれば列車数を30%以下に抑えられる場合もあります。
その代わり、1本の列車が複数案件を渡り歩くから、残荷対策を入れない設計だけは相性が悪いです。
共用の恩恵を受けるなら、デポで空車保証を作る必要があります。

スクリーンショットは、通常デポ線と残荷クリア線の分岐、車内アイテム有無の判定信号、クリア後に通常デポへ戻る最小構成が見えると十分です。
ここまで標準化しておくと、混載は「起きたら直す事故」ではなく、「起きても広がらない故障」に変わります。

便利ツールと補助MOD

LTN Combinator Modernizedの利点

『LTN』を触り始めた直後に一番つまずきやすいのは、設定の意味そのものより、定数回路と配線先の取り回しだと思います。
Provider、Requester、Depotで入れる信号が少しずつ違ううえに、刺す先を1本間違えるだけで駅が無言になります。
そこで効くのがLTN Combinator Modernizedです。
LTN Combinator Modernizedの配布ページにある通り、これは『LTN』用の信号をGUIからまとめて設定する補助MODで、定数回路を何個も並べて手入力する作業を減らせます。

未導入のときは、Network ID、しきい値、役割フラグを回路ごとに置いて、配線色まで意識して組む必要があります。
導入後は、駅テンプレートにコンビネータを置いてGUIで値を入れる流れになるので、「信号の意味は合っているのに配線先だけ違う」という初歩ミスが減ります。
自分の感覚だと、これを入れてから駅テンプレ作成は体感で半分くらいの手間になりました。
特に最初の学習段階で、設定意図と実際の配線がズレて混乱する場面が減ったので、「LTNそのものが難しい」のか「回路の置き方で事故っている」のかを切り分けやすくなった実感があります。

この差は、駅を1つ作るときより、同じテンプレートを横展開するときに効きます。
100駅規模まで伸ばすと、毎回同じ定数回路を並べる作業そのものがノイズになります。
GUIで設定が見える形になっているだけで、後から他の人が触るマルチ環境でも読み解きやすくなります。
スクリーンショットを入れるなら、ここはLTN Combinator Modernizedの設定UIで、ProviderとRequesterの主要項目が一画面で見えている構図が向いています。

『LTN Manager』で全体把握 1駅ずつ配線を追っても原因が見えないとき、視点をネットワーク全体へ上げてくれるのが『LTN Manager』です。
『LTN Manager』は駅一覧、稼働中の輸送ジョブ、列車の状態、エラーの概況をGUIで見せてくれるので、「この駅が壊れている」のか「そもそも案件が成立していない」のかを俯瞰で見られます。
導入前には mods.factorio.com の該当ページ（例: Factorio バージョンと最終更新日を確認してください。
Factorio 2.0 周辺では互換性の確認が特に欠かせません。

自分は「未配車の原因が見えない」「同じ警告の再発タイミングを追いたい」というときにだけdebug message levelを上げます。
常時細かく出すと、読む側の負担のほうが先に限界に来ます。
ログは多ければ正義ではなく、仮説に合わせて出力量を変える道具として扱ったほうが生きます。
スクリーンショットを入れるなら、ここはログ設定パネルでdebug message levelとMessage filter timeoutが見える状態が相性良いです。

デバッグ観点では、LTN - Logistic Train Networkの概要ページよりも、LTN Manualの説明のほうが実際の調整に直結します。
とくにメッセージの粒度と更新の考え方は、数字の意味を知っているだけで無駄な追跡が減ります。

回路配置補助MODの位置づけ

『Picker Dollies』のような配置補助MODは、物流制御そのものを賢くするわけではありませんが、回路の事故を物理配置の段階で減らす役目があります。
設置済みのコンビネータを少しずらしたい、向きを直したい、配線を保ったまま整理したい、という場面はLTN駅テンプレートで頻繁に出ます。
『Picker Dollies』系はそうした微調整を設定やワイヤを保持したまま行えるので、「直したつもりで配線を組み直し、別のミスを増やす」流れを避けやすくなります。

LTN駅は、積み込み制御、駅設定、ランプ、インサータ停止条件が近い範囲に固まりがちです。
その密集地帯を手で壊して置き直すと、赤線と緑線の刺さり先が1本だけ入れ替わる事故が起きます。
見た目は些細でも、動作は別物になります。
こういう場面で位置調整だけを安全に済ませられる補助MODは、デバッグ工数を減らす道具として効きます。
特にテンプレートを後から整形する人ほど恩恵が大きいです。

『Factorio 2.0』系では『Picker Dollies』の派生版として2.0対応の書き換え版も出ているので、配置補助は「古い便利MOD」ではなく現役の補助枠として見ておく価値があります。
役割としてはLTN Combinator Modernizedや『LTN Manager』より一段手前で、配車ロジックを助けるのではなく、回路レイアウトの崩れを防いで結果的に誤接続を減らすものです。
地味ですが、列車ネットワークのトラブルはこういう地味な層で発生率が変わります。

Picker Dollies

Move most placed entities quickly and easily.

mods.factorio.com

大規模ネットワークでの運用最適化

更新間隔とUPSの最適点を探る

駅数が増えて詰まりや未配車が出始めると、つい配線ミスやしきい値設定を疑いたくなります。
ですが、500駅規模を超えたあたりからは、設計そのものより規模に対して更新頻度が攻めすぎというケースが出てきます。
ここは「壊れている」のではなく、「細かく見すぎて処理が揺れている」状態です。

LTN Manualでも、update interval 5、500超の駅で更新時間が約0.05msという作者コメントの目安が示されています。
これを見てもわかる通り、更新間隔はゼロコストではありません。
短くすると配車の反応は鋭くなりますが、そのぶんUPS側には確実に負担が乗ります。
逆に長くするとUPSは落ち着く一方で、要求が立ってから列車が動くまでのテンポは少し鈍ります。
ここは反応性とUPSの交換だと割り切って触るほうが、調整の迷いが減ります。

自分も500駅規模まで膨らんだセーブで、更新間隔を短くしすぎてUPSがじわじわ揺れたことがあります。
未配車そのものは減ったように見えても、全体の刻みが不安定になるせいで、マルチだと触っていて落ち着かないんですよね。
そこでintervalを5まで戻したら安定しました。
配車反応はわずかに鈍った感触がありましたが、列車網全体の揺れが収まった恩恵のほうが大きく、自分はこの設定のほうが運用しやすいと感じました。

ここでハマりやすいのは、反応が遅い＝更新間隔をさらに詰める、という一直線の調整です。
実際には、更新間隔を詰める前に、あとで触れるNetwork ID分割やデポ分散で案件の衝突を減らしたほうが効く場面が多いです。
スケールしたネットワークでは、まず更新間隔を見直して土台の揺れを止める。
そのうえで構造側に手を入れる順番のほうが、トラブルの切り分けが進みます。

Network IDで機能別に分割

大規模化で起きる問題の中には、単一ネットワークへ全部を流し込んだ結果、案件同士が無駄に競合しているものがあります。
こういうときは、『LTN』のNetwork IDで機能別に分割すると一気に整理できます。
LTN - Logistic Train NetworkでもNetwork IDは中核機能として扱われていて、既定のdefault network IDは2.2.0で-1から0に変わっています。
古い感覚のまま組み足していると、ここで認識がズレることがあります。

分け方は、原料網、中間材網、最終製品網のように物流の層で切るのが実運用では扱いやすいのが利点です。
たとえば鉱石や原油を動かす列車と、基板やモジュールを動かす列車を同じNetwork IDに置くと、デポも案件探索もひとまとめになります。
その状態で駅数だけ増えると、「間違ってはいないが重い」「配車されるが遠回りが増える」という、地味に厄介な症状が出ます。

機能別に分離すると、まず案件探索の範囲が狭まります。
次に、列車編成やしきい値の考え方を網ごとに変えられます。
鉱石網は大量・低頻度、中間材網は中量・高頻度、最終製品網は細かい品目を刻む、といった差を吸収しやすくなります。
単一巨大ネットワークで全部を均すより、現場の調整量が減ります。

ここで一緒に見たいのがデポの配置です。
Network IDだけ分けてデポだけ中央集約のままだと、案件は分離できても出発点がひとつに集中します。
結果として、ボトルネック駅ではなくボトルネックデポが生まれます。
大規模運用では、Network IDの分割とデポ分散はセットで考えたほうが崩れません。

デポ分散と高優先度供給駅

デポを分散する狙いは、単に待機場所を増やすことではありません。
案件が出たとき、同じ方面へ向かう列車が一か所から雪崩れる状態を避けるためです。
中央デポ一極だと、出庫レーン、合流、幹線入口のどこかが詰まり、駅側ではなくデポ側の交通で遅れます。
原料網は採掘地帯寄り、中間材網は加工拠点寄りというように置くだけでも、列車の初動距離が短くなり、幹線の混み方が変わります。

供給駅側の優先制御も、規模由来の詰まりを抑えるのに効きます。
特に鉄板、銅板、石炭、燃料のような止まると広範囲へ波及する資源は、どの供給駅から先に出すかを意識したほうが安定します。
『LTN』ではProvider側の在庫がProvide Thresholdを超えていることが前提で、既定値は1000です。
この値を重要資源だけ運用量に合わせて調整すると、「十分ある駅から先に出す」流れを作れます。
供給を急がせたい駅では、LTNの優先度信号を使って配車順を前に寄せる考え方も有効です。
高優先度供給駅を決めておくと、同じ品目を複数駅が出せるときに、主力拠点から先に列車が抜けます。

この手の調整は、しきい値を低くすれば解決するという話ではありません。
Provide Thresholdを下げすぎると、在庫が薄い駅まで供給役に引っ張り出され、積み込み待ちが増えます。
逆に高すぎると、在庫はあるのに案件に乗れない駅が出ます。
だからこそ、重要資源だけ先に優先度としきい値を触る順番が効きます。
全部を一度に均すより、止まったときの被害が大きい品目から制御するほうが結果が読みやすいのが利点です。

自分は大規模網で列車が足りないと感じたとき、実際には台数不足よりデポ偏在のほうが原因だった場面を何度も見ました。
供給駅の在庫も要求駅の信号も正しいのに、同じデポから遠距離案件へばかり出ていくと、近場の小口案件がずっと後回しになります。
デポを散らして高優先度供給駅を立てるだけで、この「理屈上は回るのに現場で鈍い」感じが消えることがあります。

Cybersyn補足: 立ち位置と使い分け

Project Cybersynは、LTN系の自動配車を導入しやすい方向へ寄せた選択肢としてよく比べられます。
公開されているベンチマークの一部では特定条件下で Cybersyn の方がわずかに更新が速かったという報告がありますが、これらは条件依存です。
マップ構成や駅数、MOD のバージョンで結果が大きく変わるため、「どちらが常に速いか」を断定せず、自環境での挙動と運用コストで選ぶことをおすすめします。
この比較で見落としたくないのは、UPSと操作性が同じ軸ではないことです。
平均更新時間がわずかに軽くても、既存ネットワークの思想と噛み合わなければ調整工数が増えます。
逆に、多少手に馴染んだ仕組みのほうが、問題発生時の復旧は速いです。
自分の感覚では、すでに『LTN』で大規模網を組んでいて、Network ID分割や優先度制御まで運用に乗っているなら、その知識の蓄積は強い武器になります。
新規に始めるならProject Cybersynのほうが入り口は低めです。

規模由来の不調へ手を入れる順番も、この視点で考えるとぶれません。
まず更新間隔を見直してUPSの土台を整え、次にNetwork IDで網を分け、続いてデポを分散し、その後に高優先度供給駅やProvide Thresholdで流れを整える。
この順番なら、「設定が悪い」のか「規模に対して単一網が重い」のかを切り分けながら進められます。
『LTN』でもProject Cybersynでも、スケールした瞬間に効いてくるのはこの運用面の整理です。

まとめ

最初の優先順位

詰まったときは、症状ごとに最初の3点だけ見ます。
到達不能なら線路のつながり、信号の向き、駅の向きです。
渋滞なら交差点の信号配置、出口側ブロック、スタッカーです。
未配車なら『LTN』のNetwork ID、しきい値、デポとsend to trainです。
混載なら貨車フィルタ、積み降ろし条件、残荷物です。
自分はここを紙1枚の順番に固定してから、調査が横道にそれなくなりました。

見る順番も固定すると再現性が出ます。
まずはバニラ側の問題、つまり線路、信号、駅を確認します。
そこが崩れていると『LTN』の設定をいくら触っても直りません。
その次に『LTN』の基本であるNetwork ID、Threshold、Depot、 send to trainを見ます。
そこまで合っていて初めて、更新間隔やログのような運用設定に進む流れです。
自分も最初は逆順で触って時間を溶かしました。

再発防止

再発を減らすなら、ProviderRequesterDepotを駅テンプレ化して、配線とフィルタを固定するのが一番効きます。
新設駅ではNetwork ID確認を設置手順に入れておくと、「駅を置いたのに仕事しない」が一気に減ります。
実際、自分の環境ではテンプレ化してからこの手の事故が激減し、チェックリスト運用を合わせるとデバッグ時間は体感で半分以下になりました。

補足すると、初心者は無理に『LTN』へ急がなくて大丈夫です。
先にバニラで信号、交差点、スタッカーを安定させたほうが、問題の切り分けが身につきます。
必要になってから『LTN』を入れても遅くありません。
バニラ側でもできることは増えています。
まず土台を固め、その上に自動配車を載せるのが結局いちばん速いです。