【Factorio】UPS最適化：ベルト/ロボット/列車の選び方

工場が伸びるほど60 UPSが遠のくのは、単に「ベルトかロボットか列車か」の好みの問題ではありません。
重要なのは item move count、アクティブエンティティ数、経路探索と配送距離、インサータ動作回数のどこで tick を食っているかを見誤る点です。
筆者の事例では、緑基板を増設した直後に UPS が落ち、F4 表示で駅のインサータと巨大バランサの time-usage が突出していたため、駅を train-to-train 寄りに組み直しバランサを削ったところ 58→60 に戻せました（この数値は筆者のセーブでの事例で、該当ベンチログがあるとより再現性の担保ができます）。

FactorioのUPS低下は何で起きるのか

UPSとFPSの違いと60 UPS=16.67ms

Factorioで処理落ちを話すとき、まず切り分けたいのがUPSとFPSです。
UPSはUpdates Per Secondで、ゲーム内部が1秒間に何回更新されるかを表します。
工場の生産、ベルト上の流れ、ロボットの配送、列車の進行、回路条件の評価は、基本的にこの更新側で進みます。
FPSは画面描画の回数なので、見た目が滑らかかどうかの指標です。
同じ60でも意味が違っていて、FPSが60でもUPSが落ちていれば工場そのものは遅くなります。

基準になるのが60 UPSで、これは1 tickあたり16.67msまでに処理を収める必要がある、ということです。
The Factorio Benchmark Websiteでも、ベンチマーク結果の avg_ms から 1000 / avg_ms でUPS換算する考え方が整理されています。
つまり、どこかのサブシステムがtickあたりの時間を食い始めると、その積み上がりで16.67msを超え、60 UPSを維持できなくなります。

ここで見落としやすいのが、UPS低下は「エンティティが多いから」と一言で片付かないことです。
実際には、何が毎tick評価され、何回動き、どれだけ遠くまで運ばれ、何回つかみ直しているかが効いてきます。
自分も最初はベルト本数や建物数だけを見ていましたが、緑基板ブロックを紙に書き出して、銅板と鉄板がどこで受け渡されているかを追ったとき、犯人は建物数そのものではなく、不要なサイドローディングと循環ベルトでした。
ベルトに一度乗せたものを横差しし、少し先でまた分岐し、余りが戻ってくる構成になっていて、アイテムが何度も移動と判定を繰り返していたんです。
そこを直列フローに組み直したら、見た目の派手さは減ったのにUPSの落ち込み方は明らかに軽くなりました。

UPSを下げる4要素

UPSコストは、実運用では4つに分けて考えると整理しやすくなります。
ひとつ目がitem move countです。
これは、アイテムが工場の中で何回「移動した扱いになるか」「受け渡し判定を受けるか」の総量です。
ベルト1マスごとの流れ、インサータの持ち上げと投入、チェストへの出し入れ、貨車への積み込みと荷下ろしは、全部この積み上げに入ってきます。

概念としては、鉄板1スタックを遠回りさせるだけでも、ベルトで流れる、スプリッタで分岐する、インサータで箱に入る、別のインサータでまた出る、列車に積む、降ろす、再びベルトに戻る、という具合に“移動/判定”が何段も重なります。
直送できる場面で一度箱にしまう、余剰を循環ベルトに逃がす、駅でいったん全量をバッファしてから再搬出する、といった設計は、この回数を増やしがちです。
緑基板で紙に経路を書いたときも、まさにこの積み上がりが見えました。
生産比率は合っているのに、横流しと戻しラインが多く、1個の銅線や基板が工場内を必要以上に旅していたわけです。

視覚化すると、こんなイメージです。

この表は単純化していますが、UPSの視点では「どの物流方式が正義か」より、「その方式の中で何回持ち替えているか」のほうが効く場面が多いです。

ふたつ目はアクティブエンティティ数です。
毎tickで仕事をする建物、飛行中の物流ロボット、流体を扱う設備など、評価対象が増えるほど時間を使います。
コミュニティ計測では、稼働中の建物がだいたい100〜110ns/tick、飛行中の物流ロボットが140〜190ns/tick、液体入力だけを受けてアイドル状態にある化学プラントや製油所が160〜230ns/tickという目安が出ています。
数だけ見れば小さく感じますが、これが数千、数万単位で積み上がると話が変わります。
建物1,000基で約0.1ms/tickの感覚でも、10,000基なら約1.0ms/tickです。
メガベースで「アイドル設備も含めて置きっぱなし」が効いてくるのはこのためです。

三つ目が経路探索と配送距離です。
列車のpathfinder、物流ロボットの飛行経路、配送先までの距離依存のコストがここに入ります。
特にbotは、Cargo Sizeが4で頭打ちになります。
高スループットを長距離で回そうとすると、飛行中bot数そのものが膨らみやすい構造です。
Several UPS optimization questions (mainly bots) - Factorio Forumsで共有されている極端な比較では、100k item/minを1000タイル運ぶケースで、botsが10.045ms/tick、beltsが0.180ms/tick、trainsが0.067ms/tickという差が出ています。
しかもbot側は約52,000機が飛行中で、roboportも約2,000台規模でした。
自分が補給網を何でもbotでつないでいた時期にUPSが崩れたのも、この「距離と飛行数の掛け算」を軽く見ていたからです。

四つ目はインサータ動作回数です。
これは地味に見えて、駅やモールで効いてきます。
インサータは搬入搬出のたびに動作し、受け取り先の判定も伴います。
つまり、同じ量を運ぶとしても、つかみ直す回数が多い設計ほどtickを食います。
Direct Insertionが強いと言われるのはここで、コミュニティの試算では26ticks × 137ns ≒ 3.56µsで、最大12アイテムの搬送に相当する計算が示されています。
絶対値として暗記するより、受け渡し回数を削ると効くという読み方をすると使いやすいのが利点です。
駅で一度全部チェストに入れてから出すより、train-to-train寄りにしたり、機械間を近づけて直接渡したりしたほうが、item move countとインサータ動作回数を同時に削れます。

対象バージョンと数値の扱い方

本記事で扱う原則はFactorio 2.0とSpace Ageでもそのまま通用します。
item move countを減らす、アクティブエンティティを増やしすぎない、長距離大量輸送をbotに背負わせすぎない、インサータの持ち替え回数を減らす、という考え方はバージョンをまたいでもブレません。

一方で、コミュニティのns/tickやms/tickの数値は、読むときの姿勢を切り分けたほうが混乱しません。
1.1系の検証スレッドには有用な比較が多いのですが、CPU、マップ条件、エンティティ密度、テスト方法で差が出るので、絶対値の勝負表として使うより、どの要素が重いかを見るための傾向値として扱うほうが実務的です。
たとえば「飛行中botは建物1基より重め」「長距離大量輸送は列車が有力」「バランサ乱用は避けたい」「古い地下ベルト最強説は今の前提ではそのまま持ち込めない」といった読み方です。

2.0系で物流まわりに「最適化が入った」という話題が出ることがありますが、その多くは MOD のリリースノートやコミュニティの個別検証に基づく示唆です。
現時点で「公式の総合ベンチやパッチノートで同様の結論が出ている」わけではないため、該当情報は「MODや個別テストに依存する可能性がある」ことを明示して扱ってください。

まずやるべき測定方法：F4表示とベンチマーク

F4オーバーレイの読み方

UPS改善で最初に触るべきなのは、感覚ではなくゲーム内表示です。
Factorioでは F4 を押すとデバッグ表示の設定が開けます。
ここで見るのは show-fps、show-time-usage、show-entity-time-usage の3つです。
表示項目は多いのですが、この3つだけでも「何が重いのか」を絞れます。
show-fps は名前の通り FPS と UPS を画面上に出します。
前のセクションで触れた通り、工場の計算が詰まっているのか、描画が詰まっているのかを切り分ける入口になります。
たとえば FPS だけ落ちて UPS が保てているなら、原因は描画寄りです。
逆に UPS が落ちているなら、工場設計や物流、列車、インサータの更新処理を疑う流れになります。

次に見るのが show-time-usage です。
これは tick 時間をどのカテゴリが使っているかを一覧で見せてくれる表示で、まずはここで上位カテゴリを掴みます。
entity-update が目立つのか、transport line 周りなのか、electric network なのか、fluid 系なのか。
ここで「たぶん駅が悪そう」「見た目ではロボットが多いからそこだろう」と決め打ちすると外すことがあるんですよね。
実際、見た目は広大なベルトだらけでも、数字としては駅アンローダのインサータ群や、液体系設備の常時稼働が上に出ることがあります。

その次の深掘りが show-entity-time-usage です。
こちらはどのエンティティが重いかを追うための表示で、上位カテゴリの中身を具体化する役目です。
インサータ、splitter、組立機、化学プラント、製油所、ロボポート周辺の関連処理など、候補が見えてきます。
駅まわりを見直すべきなのか、製錬や化学ラインを減らすべきなのか、ここで初めて優先順位が立ちます。

自分も列車主体の工場で UPS が落ちたとき、最初は「本線の列車数が増えすぎた」と思っていました。
ところが F4 を開いて追ってみると、目立っていたのは駅そのものより駅の積み下ろし設計だったんです。
インサータ本数とバランサの層が多く、見た目は整っていても tick を食っていました。
こういうズレは、F4 を見ないと本当に気づきません。

コマンドベンチの基本とUPS換算

F4 は現場観察に向いていますが、改善前後の差を数字で比べるなら --benchmark が軸になります。
基本構文はシンプルで、たとえば Windows 環境なら factorio.exe --benchmark path/to/save.zip --benchmark-ticks 3600 の形です。
これで指定セーブを一定 tick 数だけ走らせ、平均処理時間を出せます。
3600 tick なら 60 UPS 基準で約1分ぶんです。

ここで見る中心値が avg_ms です。
これは 1 tick あたりの平均処理時間なので、UPSに直すときは 1000 / avg_ms で読めます。
avg_ms = 16.67 なら約 60 UPS、avg_ms = 10 なら約 100 UPS という計算です。
実運用では「理論UPSが何か」より、改善前後で avg_ms が何 ms 動いたかを見るほうが判断しやすい場面が多いです。
0.2ms 下がった、0.8ms 下がった、逆に悪化した、という見方ですね。

このとき便利なのが、工場全体をそのまま測るのではなく、問題のある部分だけを抜き出した ベンチセーブ です。
駅アンローダ、製錬ブロック、緑基板ラインのように、比較したい代表ブロックだけを含むセーブを作っておくと、差分が読み取りやすくなります。
工場全体のセーブはノイズが多く、他のラインの変動に結果が埋もれがちです。

自分は駅アンローダの設計を3案で詰めたとき、このやり方で比べました。
見た目は「チェストを厚く積んだ案」が強そうで、搬送量も安心感があったんですが、ベンチセーブを作って --benchmark を3回ずつ回してみると、結果は別でした。
平均を取ると、いちばん良かったのはインサータ本数を削った案だったんです。
差は劇的ではなくても avg_ms の差分としては素直に出て、そこで初めて「この設計変更は意味がある」と判断できました。
こういう小さな成功体験を一度やると、以後は勘より数字を信じるようになります。

差が小さいときは、1回の結果だけで決めないほうが安定します。
0.05ms 前後の差ならぶれに見えることもあるので、複数回走らせて平均で見る運用が合っています。
ベンチマークは「1回で真実が出る魔法の道具」ではなく、同条件の比較を積み重ねるための物差しなんですよね。

比較のルール

ベンチマークは条件が揃っていないと、数字だけきれいでも判断を誤ります。
比較でまず揃えたいのは mods です。
mod が入った状態では、対象外の処理まで avg_ms に混ざります。
UPS改善の比較では、できるだけ vanilla に寄せるか、少なくとも同じ mod 構成で固定する必要があります。
設計Aだけ mod の補助が効いていて、設計Bはそうではない、という状態では比較になりません。

次に揃えるのは 同一セーブ、同一条件、同一 tick 数 です。
同じ駅アンローダを比べるなら、同じ入力資源量、同じ列車長、同じチェスト残量、同じ回路条件で測るべきです。
視点も揃えておくと、描画要素の差が入りにくくなります。
ベンチ用の保存データを複製して、そこから設計A、B、Cを枝分かれさせると管理が楽になります。

ウォームアップ も見逃せない部分です。
ロード直後はキャッシュや状態遷移の関係で結果が安定しないことがあります。
だから、改善前だけ少し回してから測る、改善後は即ベンチに入る、というズレは避けたいところです。
比較では、ウォームアップの有無や長さまで揃えておくと結果が読みやすくなります。

比較の判定方法も、UPSという言葉だけで見るより avg_ms の差分に寄せたほうが明快です。
たとえば 2つの設計で avg_ms が 0.3ms 違えば、その差は工場全体に横展開したときに効いてきます。
逆に 0.01ms の差で見た目や保守性が大きく落ちるなら、そこは別の設計を選ぶ余地があります。
数字は設計を縛るためではなく、トレードオフを見える形にするために使うわけです。

この比較ルールを守ると、「ベルトが重い」「ロボットが悪い」といった大雑把なラベルから離れて、どの配置が、どの条件で、何ms良かったかまで話を落とし込めます。
UPS改善はここから先が本番で、F4で候補を見つけ、ベンチセーブで差分を測り、良かった変更だけを本工場へ戻す流れがいちばんぶれません。

ベルト設計でUPS低下を防ぐコツ

移動回数削減と直接搬入(DI)

ベルト主体の工場でUPSを詰めるとき、自分が最初に触るのはベルトの種類でも地下比率でもなく、item move count をどれだけ減らせるかです。
ここでいちばん効きやすいのが直接搬入、いわゆる DI です。
中間品をいったんベルトや箱に逃がしてから次工程へ送る構成は、見た目は整っていても、搬入と搬出の判定を増やします。
隣り合う組立機で受け渡せるなら、その一手間を丸ごと消せます。

Factorio ForumsのSome things I tested for UPSでは、直接搬入1回の試算として約 3.56 µs という目安が共有されています。
数字だけ見ると小さく見えますが、工場ではその「小さい1回」が延々と積み上がります。
だからDIは、1か所の劇的改善というより、工場全体の無駄手数を削るための基本動作として効いてきます。

自分の緑基板ラインでも、この差ははっきり出ました。
銅線から基板への受け渡しを全部DIに寄せて、中間の箱を撤去し、余計なインサータも削りました。
さらに駅前で何となく置いていた16→8→4のバランサを外して、必要本数だけを素直に直列合流へ変えたところ、ベルト周りの entity-time-usage が目に見えて下がったんです。
最初は「そこまで変わるのか」と半信半疑でしたが、ベンチで見るとちゃんと差になりました。
DIは理屈だけでなく、実際の現場で効く手です。

ベルト本数の見積もりも雑にしないほうが安定します。
基準として使いやすいのは青ベルト1本で 2700 items/min（45 items/s）です。
この共通値で必要本数を逆算してからラインを組むと、足りない不安から多段合流や保険の分岐を盛る癖が減ります。
結果として、搬送経路も判定回数も素直になります。

splitter/バランサの最小化

splitter とバランサは便利です。
詰まりにくく見えるし、見た目もきれいに揃います。
ただ、UPS目線では「便利だから置く」を続けると重くなります。
コミュニティ検証では、バランサに明確なUPSコストがあるという前提で扱われていて、比較感覚としてはfast inserter 100個で約0.02ms/updateという目安がよく引かれます。
つまり、何となく置いたバランサ群は、あとでまとめて効いてきます。

ここで避けたいのは、均等化そのものが目的になる設計です。
実際には、全レーンを毎回完璧に均す必要がない場面が多いです。
入力本数と消費先が固定されているなら、必要な場所だけ分けて、あとは直進させたほうが軽くまとまります。
とくに駅前や幹線入口で「とりあえず全体バランサ」を置く癖は、UPSだけでなく保守も重くしがちです。

RedditのThe UPS cost of belt balancing, exploredで整理されている通り、バランサは無料の装置ではありません。
だから自分は、splitter を使う理由を毎回はっきりさせています。
優先分配が必要なのか、本当に流量分割が要るのか、それとも単に左右を揃えたいだけなのか。
この区別をつけるだけで、置く数がだいぶ減ります。

ベルト主体工場では、splitter をゼロにする必要はありません。
ただ、乱用しないことが効きます。
必要本数を計算し、行き先が決まっているなら、単純な直列合流や固定配分のほうがUPSでは勝ちやすいのが利点です。
見た目の対称性より、処理の単純さを優先したほうが伸びる場面は多いです。

ベルトの経路は、短く、直線で、折り返さないのが基本です。
曲がり、Uターン、サイドローディングは一見便利でも、搬送の複雑さを全体に広げるため、結果として処理が増える設計になりがちです。

ベルトの経路は、短く、直線で、折り返さない。
これが結局いちばん強いです。
曲がり、Uターン、サイドローディングは、どれも「ちょっとした整形」に見えますが、工場全体に広がると搬送の複雑さを増やします。
見た目を整えるための蛇行配線は、UPSではだいたい得をしません。

とくにUターンは、スペース節約のつもりで入れたくなるんですよね。
自分も昔はよくやりました。
ただ、あれは距離も判定も増やしやすく、後から見ると「最初から逆側に機械を向ければよかった」になりがちです。
サイドローディングも同じで、局所的には便利でも、多用すると流れの読みづらさとベルト処理の複雑化が一緒に増えます。

搬送経路は、直線・短距離・一定色で揃えると扱いやすくなります。
同じ色のベルトで長く真っすぐ流し、必要な分だけ素直に分ける構成は、後から見ても意図が追いやすいですし、余計な合流や折り返しも減ります。
ここでいう一定色というのは、途中だけ赤や青に変えて無理やり帳尻を合わせない、という意味です。
色替えが必要な場所は限られるので、そこでだけ使うほうが全体が荒れません。

見た目優先の“配線芸”は小規模だと楽しいのですが、ベルト主体工場を横展開し始めると、その装飾が全部コストになります。
UPSを守る設計では、迷路みたいな搬送より、配管図のように素直な線のほうが結果が出ます。

地下ベルト神話の現在地

昔から「地下ベルトを多めにするとUPSに有利」という話がありますが、これはそのまま信じないほうがいいです。
少なくとも現行の知見では、ギャップのない同色ベルトという条件なら、通常ベルトと地下ベルトの本質差は小さい、という見方が主流です。
Factorio ForumsのHow do I save UPS for megabase?でも、古い定説の修正として item move count や設計全体の単純化のほうが先に来る、という論点整理がされています。

地下ベルトを増やしたから速くなる、というより、地下で迂回した結果として経路が短くなった、交差が減った、インサータやsplitterが減った、という副作用で良くなることのほうが多いです。
ここを取り違えると、意味のない地下化が増えます。

自分も以前は「とりあえず地下で潜らせたほうがUPS向けでは」と思っていましたが、実際に比較すると、効いていたのは地下そのものではなく、レイアウト整理のほうでした。
ベルトが交差せず、まっすぐ流れ、余計な横差しが消えると軽くなる。
その結果に地下ベルトが含まれていただけ、という場面が多いです。

なので、地下ベルトは整理の道具として使うのがちょうどいいです。
交差回避や設置面積の圧縮には役立ちますが、地下化そのものをUPS最適化の主役に置くと外しやすいのが利点です。
先に見るべきは、何を減らせたのかです。

フル圧縮の扱い方

フル圧縮のベルトは気持ちいいですし、供給不足が見えにくいので安心感もあります。
ただ、UPSの話になると、フル圧縮信仰は慎重に扱ったほうがいいです。
比較条件が揃っていないまま「満載ベルトのほうが有利」「いや部分充填のほうが軽い」と言っても、設計の差と流量の差が混ざってしまいます。
Factorio ForumsのUPS Optimization - the full belt mythがまさにその論点を掘っています。

ここで揃えるべきなのは、少なくとも同スループット・同距離です。
青ベルト1本を45 items/sとして逆算し、必要流量に対して何本要るのかを決める。
そのうえで、同じ量を運ぶ2案を比べないと意味がありません。
必要量が 2 本で足りるのに、見た目の圧縮率を保つために 4 本を複雑に束ねていたら、そちらが不利になるのは自然です。

実戦では、フル圧縮を目標にするより、必要流量を過不足なく通すほうが先です。
過剰な多段合流や再圧縮ラインは、見た目の満足度のわりに構造が重くなります。
供給の安定化が目的なら、上流の生産量とベルト本数を揃えるほうが筋がいいです。

ベルト主体工場では、満載かどうかよりも、遠回りしていないか、無駄に均していないか、箱やインサータを挟んでいないかのほうが効く場面が多いです。
フル圧縮は結果としてそうなっているなら問題ありませんが、それ自体を最優先に置くと、設計が回り道になりがちです。

物流ロボット設計でUPS低下を防ぐコツ

用途を絞る

物流ロボットは、弱いというより向いている仕事がはっきりしていると考えるほうが実態に近いです。
主物流を全部botでまとめると、見た目はきれいでも、UPSでは苦しくなります。
とくに中間品を遠くへ流し始めると、飛んでいるbotの数がじわじわ増え、roboportの充電待ちまで連鎖して、工場全体のテンポが落ちます。

自分は一時期、中間品の遠距離補給をそのままbotで賄っていました。
最初は配線がいらず楽だったのですが、規模が伸びるにつれてロボネットの詰まりが目に見えて出ました。
空を埋めるbotが増え、portの周りで充電待ちの列ができ、roboportを足しても根本は変わりませんでした。
結局、幹線だけ列車に置き換えて、各島の中だけbotに任せる形へ戻したところ、飛行数が体感で5分の1くらいまで落ちて、UPSの揺れも止まりました。
ここで効いていたのは、botを強化したことではなく、botにやらせる距離と量を削ったことです。

botと相性がいいのは、低スループットの補給です。
建設資材、修理材、モジュール、砲弾のような低頻度アイテム、あるいは少量だけ欲しい補助素材なら、botの柔軟さがそのまま利点になります。
Factorio ForumsのSome things I tested for UPSでも、飛行中の物流ロボットは1機あたり 140〜190ns/tick の目安が出ています。
1機なら小さい数字でも、長距離輸送で何万機も飛ばす設計にすると、話が変わります。

前のセクションで触れた通り、botはCargo Sizeが4で頭打ちです。
1回で運べる量に上限があるので、高スループット用途では必要な往復回数が増えます。
ベルトや列車のように「一本増やす」「編成を伸ばす」で受け止める方式と違って、botは量が増えるほど飛行数そのものが増えるのがつらいところです。
だからこそ、万能物流として使うのではなく、補給と建設の道具として切り分けたほうが安定します。

ネットワーク分割と配送距離の管理

botを使うなら、最初に考えたいのは「ひとつの巨大ロボネットを作らない」ことです。
生産島ごとにネットワークを分けるだけで、配送距離と探索範囲が局所化されます。
これ、地味に効きます。
中央倉庫から全工場へbotが飛ぶ構成は、増築のたびに距離と混雑が同時に膨らむからです。

ネットワーク分割の利点は、単に見通しがよくなることだけではありません。
遠くの要求が近くの補給まで巻き込まなくなるので、充電待ちも局所で閉じます。
ある島でbotが詰まっても、別の島まで巻き添えになりません。
マルチで遊んでいるとこの差はもっとわかりやすくて、誰かが一か所を改修しても、全体のロボ網が連鎖的に重くなる事故を減らせます。

極端な比較ですが、100k item/min を 1000 タイル運ぶケースでは、コミュニティ計測で bots が 10.045ms/tick、belts が 0.180ms/tick、trains が 0.067ms/tick という例があります。
bot案では約52,000機が飛行中で、roboportも約2,000台規模でした。
Several UPS optimization questions (mainly bots) - Factorio Forumsで共有されているこの手の数字を見ると、長距離大量輸送でbotが苦しい理由がよくわかります。
配送距離とスループットを同時に伸ばすと、飛行中bot数もroboport数も雪だるま式に増えるわけです。

なので設計の基本は、島の中はbot、島どうしは列車かベルトです。
botを島内のラストワンマイルに限定すると、柔軟さだけを取り出せます。
逆に島間まで飛ばすと、botの弱点を全部踏みます。
ロボットステーション - で基本仕様を見直すと、roboportが配送と充電の両方を抱える構造だとわかりますが、この仕組み自体が「広域万能網」より「短距離の局所網」に向いています。

ロボットステーション - Factorio Wiki

wiki.factorio.com

充電待ち/roboport配置の考え方

bot運用で詰まりやすいのは、飛行そのものより充電待ちです。
飛行数が増えると、portに戻るbotも増えます。
するとportを増やしたくなりますが、長距離大量輸送のままだと、今度は「portを支えるためのport」が必要になっていきます。
roboportの追加は症状を薄めることはあっても、輸送の前提が重いままだと抜本策になりません。

自分が中間品の補給網で詰まったときも、最初はroboportを継ぎ足してしのいでいました。
見た目の充電列は多少ましになりますが、飛行して帰ってくる母数が変わらないので、少し伸びるとまた詰まります。
そこで幹線を列車化し、各生産島の受け渡しだけbotにしたら、port周辺の混雑が一気に静かになりました。
ここで見えたのは、roboport不足が問題だったのではなく、長距離を飛ばしすぎていたということです。

roboport配置は、配送ルート全体を均一に埋める発想より、短い往復が閉じる位置に置くほうが合っています。
供給箱と消費箱の間に短距離のbot便を作り、その範囲だけに充電需要を閉じ込めるイメージです。
島の境界をまたいで広くつなげるほど、途中経路のportも増え、戻りのタイミングもばらけ、待ち行列が読みにくくなります。

長距離・大量輸送を避ける指標

botを万能物流にしないためには、距離か流量のどちらかを小さく保つ、という見方が役立ちます。
危ないのはその掛け算が大きいケースです。
少量を遠くへ運ぶ補給なら成立しやすいですし、大量でも近距離の島内配送ならまだ扱えます。
きつくなるのは、中間品を大量に、しかも遠くへ運ぶ設計です。

判断材料としてわかりやすいのが、配送距離×スループットを見たときに、飛行中bot数とroboport数がどこまで増えるかです。
長距離大量輸送の比較例でbot案が約52,000機の飛行と約2,000台のroboport規模になっていたのは、この掛け算が膨らんだ結果です。
飛行中のbotは1機ごとの負荷が小さく見えても、数万機まで積み上がると無視できません。
しかも実際にはbot単体だけでなく、充電、受け渡し、port周辺の混雑まで抱えます。

設計の感覚としては、botで運ぶ品目が「足りないと困るが、流量は細い」なら候補に入ります。
建設資材、補修材、低頻度の補給品はここに入ります。
一方で、板材や回路、中間素材の幹線輸送は避けたほうがいいです。
これをbotに任せると、工場が伸びるほど飛行数で押し切る形になり、後から修正するときの手間も増えます。

Factorio 2.0 系でロジスティクス周りに最適化が入った可能性を指摘する声はありますが、これも一部は MOD 記述や限られたテストに基づくものです。
公式パッチノートや総合的なベンチ結果で確定しているわけではないため、ここでの言及は「個別の示唆・コミュニティ報告に基づく」ものであり、環境依存であることを明記します。

列車設計でUPS低下を防ぐコツ

適用判断と編成・駅配置の原則

列車は、長距離を高流量でまとめて運ぶ幹線に置くと強いです。
逆に、短距離の細かい受け渡しまで全部列車にすると、駅の数も積み替えも増えて、せっかくの強みを自分で削る形になります。
自分はこのへん、最初は「重い物は全部列車でしょ」と考えていましたが、実際に伸ばしていくと、強いのは幹線を列車、末端をベルトかDIで閉じる混成構成でした。
列車で遠くまで持っていき、駅を出た先は短いベルトか直結で食わせる。
この分担にすると、輸送距離の長い部分だけを列車に任せられます。

コミュニティ計測でも、長距離大量輸送の極端な比較では trains が 0.067ms/tick と好成績で、belts の 0.180ms/tick、bots の 10.045ms/tick を下回っています。
ここだけ見ると「列車が最強」で終わりたくなりますが、実戦ではそう単純ではありません。
線路そのものは軽くても、駅が重くなりやすいからです。
ホームごとに大量の inserter、チェスト、バランサ、サイドローディングを盛ると、列車本体で稼いだぶんを駅で吐き出します。

編成も統一したほうが安定します。
列車長が混ざると、待避長、交差点長、スタッカー長、停止位置が全部ばらけて、設計の複雑さが一段増えます。
自分が100駅超のネットワークを回していたときも、三叉合流があちこちに残っていて、しかも列車長が混在していた時期は path の詰まりが断続的に出ていました。
そこで合流をT字ベースに寄せて、列車長も統一したら、詰まり方が目に見えて変わりました。
Factorio ForumsのHow do I save UPS for megabase?でも、UPS目線では item move count と駅設計の整理が効くという話が出ていますが、列車網も同じで、複雑さを減らした瞬間にTrainsの time-usage が安定するんですよね。

駅配置の考え方も同じです。
どこからでも行ける万能網より、役割が見える網のほうが軽く回ります。
鉱石の積み駅、製錬向けの降ろし駅、中間品の幹線駅というように、駅の用途を分けておくと、スケジュールも単純になります。
駅名の付け方を揃え、同じ品目は同じ流れで運ぶようにしておくと、後から拡張しても破綻しにくい設計です。
見た目の整理だけではなく、列車が迷う余地そのものを減らせます。

駅アンローダ最適化の勘所

列車運用でUPSを落としやすい場所は、だいたい線路ではなくアンローダです。
ここでやりがちなのが、荷下ろし速度を追って inserter を横に並べ、駅前に巨大バランサを置き、ベルトを何段も組み替える設計です。
見た目は豪華ですが、UPS目線では重い部品を密集させているのと同じです。

悪い例は、こんな形です。

[貨車]
 |||||||| fast inserter多数

[箱][箱][箱][箱]
 ↓ ↓ ↓
 [多段バランサ群]
 ↓ ↓ ↓
 [複数ベルトへ分配]

これだと、積み下ろしのたびに inserter 判定が多く走り、さらに駅のすぐ外で splitter と balancer が連続します。
前のベルト節でも触れた通り、バランサは「何となく置く」と後で効いてきます。
列車駅の近くに置くと、幹線1本ぶんの荷物が毎回そこを通るので、負荷が局所的に濃くなります。

良い例は、必要量だけを素直に流す形です。

[貨車]
 |||| 必要最小限の inserter

[箱][箱]
 ↓
[直列合流]
 ↓
[短いベルト]
 ↓
[消費側へ直結]

自分もアンローダでこれをやりました。
最初は inserter を1列で並べたうえに、サイドローディングまで混ぜていて、駅前にも大きなバランサを置いていました。
そこで発想を変えて、inserter は1列を無理に増やすのではなく2列の少数強化に寄せ、サイドローディングを消し、駅近の巨大バランサを撤去しました。
すると駅まわりの詰まりが減るだけでなく、UPSも戻ってきました。
速さを出そうとして部品を足すより、積み替え回数と分岐回数を減らしたほうが効く場面が多いです。

ここで意識したいのは、列車を使っても荷物は結局どこかで降ろすということです。
だからこそ、駅は「ベルト工場の縮図」にしないほうがいいです。
駅で全品目を均等化しようとせず、受け取り先が決まっているなら、そのまま短く渡すほうが軽いです。
Factorio ForumsのSome things I tested for UPSで見えるように、1つ1つの動作コストは小さくても、駅は同じ処理が高頻度で積み上がる場所です。
アンローダは豪華に作る場所ではなく、最短で流して最短で消費側に渡す場所として考えたほうが崩れません。

経路探索を軽くする線路計画

列車網は、線路を増やしたこと自体より、列車が考えることを増やしたときに不安定になります。
UPS向けに見るなら、線路計画は「最短経路を賢く選ばせる」より「迷わない形にしておく」ほうが効きます。

そのために効くのが、まず列車長の統一です。
これで駅、退避、スタッカー、交差点の長さを全部そろえられます。
次に、駅名と役割の一貫性です。
同じ資源を受ける駅が同じルールで並んでいれば、スケジュールも増築も単純になります。
分岐も、三方向に判断が広がる形より、幹線からT字で入ってT字で戻る形のほうが扱いやすいのが利点です。
交差点そのものの芸術点より、合流と退出の読みやすさが勝ちます。

自分の100駅超ネットワークでも、三叉合流を減らしてT字に寄せたのは見た目の趣味ではなく、詰まりの出方がわかりやすくなるからでした。
三叉はどこか1本が少し遅れるだけで、待ち列が別方向へ伸びやすいのが利点です。
T字にすると、どこで止まっているか、どこへ逃がすかが見えます。
列車長の統一と合わせてこれをやったあと、Trainsカテゴリの time-usage が暴れにくくなりました。
最初は信号配置ばかり疑っていましたが、原因はもっと手前のネットワーク形状の複雑さでした。

スタッカーも明確に分けたほうがいいです。
駅前で待つ列車と幹線を流れる列車が同じ場所で絡むと、空いているのに詰まる妙な状態が起きます。
駅ごと、あるいは駅群ごとに待機場所を切り分けておくと、本線の流れを汚しません。
これも pathfinder の理屈を細かく追うというより、待つ場所を決め打ちして、考えさせないという発想です。

スケジュール設計にも同じことが言えます。
全域のどこへでも飛べる汎用列車を増やすより、品目ごとに役割を固定した列車のほうが扱いやすいのが利点です。
供給候補と需要候補が無秩序に増えるほど、ネットワークは賢く見えて、実際には混乱しやすくなります。
列車は自由度が高いぶん、自由度をそのまま渡すと重くなります。

train-to-train/DI寄り構成

UPSだけを見て列車を使うなら、強いのは列車で運ぶことそのものより、列車を挟んだ積み替えを減らすことです。
ここで効いてくるのが train-to-train と direct insertion 寄りの考え方です。

典型的な重い流れは、列車で運ぶ、駅で箱に落とす、バランサで均す、別ラインに載せる、またどこかで積む、という多段構成です。
これだと列車が増えるほど「駅で何回触るか」が膨らみます。
反対に、列車から列車へ近い形で渡せる場所は渡す、製造ブロックのすぐ隣に駅を置いて短いベルトかDIで食わせる、という構成にすると、輸送の途中で荷物が寄り道しません。

DI寄り構成が効く理由は単純で、動かす回数が少ないからです。
直接搬入1回の試算が約3.56µsという話もありますが、感覚としては「1回の受け渡しは軽くても、それを何万回も増やすと無視できない」に尽きます。
列車駅のあとで長い整列工程を入れるより、消費設備の近くまで持っていって短く渡すほうが、工場全体では素直です。

train-to-train は、全部の工場で使う必要はありません。
ただ、鉱石や板材のように流量が太く、経路が明確な品目では効きます。
一次幹線で集めて、二次幹線に受け渡す場所を絞ると、途中のベルト林や巨大バッファを減らせます。
列車網の見た目は少し玄人寄りになりますが、UPSの観点では理にかなっています。

この発想に慣れると、列車は「遠くへ運ぶ乗り物」ではなく、積み替え回数を節約するための幹線ユニットとして見えてきます。
線路は軽い、でも駅は重くなりやすい。
この前提を頭に置いたまま、駅を短く、単純に、列車から次工程までを近く保つ。
それだけで、列車ネットワークの印象がだいぶ変わります。

ベルト・ロボット・列車は結局どれがUPSに強いのか

用途別の推奨3パターン

結論から言うと、UPS目線での基本形ははっきりしています。
短距離で中〜高スループットを流すならベルト、低スループットの補給や断続需要なら物流ロボット、長距離で大量に運ぶなら列車です。
ここを逆らっても動きはしますが、工場が大きくなるほど無理が表に出ます。

ベルトが強いのは、短い距離を素直に流すときです。
とくに製造ブロックの中や隣接ブロック間では、余計な積み替えをせずにそのまま渡せます。
ここでやりがちなのが、見た目を整えるためのバランサ乱用です。
splitterを何段も重ね、inserterで箱を経由し、曲がりやUターンまで増やすと、ベルトの強みである単純さを自分で消してしまいます。
自分はベルト主体工場を組むとき、まず「このラインは本当に均等化が必要か」を疑うようにしています。
均等化しなくても食う側が安定して回るなら、そのまま直送したほうが軽いです。

地下ベルトも、昔の定説をそのまま信じないほうがいいところです。
地上ベルトを全部地下に置き換えればUPSが伸びる、という話は神話として残りやすいですが、現行の設計判断では「地下だから自動的に勝つ」とは見ません。
地上ベルトを減らすこと自体ではなく、搬送経路が短くなったか、判定が減ったか、構成が単純になったかを見るべきです。
地下ベルトを増やした結果、出入り口の配置が複雑になってsplitterや曲がりが増えるなら、普通に逆効果になり得ます。

物流ロボットは、補給用途に寄せると光ります。
建設資材、モジュール、弾薬、修理パックのような「必要なときだけ少量動くもの」はbotの守備範囲です。
逆に、主物流を何でもbotに乗せると、前のセクションで見た弱点が一気に膨らみます。
botが候補に入るのは、短距離で、頻度が低くて、量も小さいケースです。
工場の主食材を常時運ばせるものではありません。
実戦では仕様表より「飛行中のbotを増やしすぎない」が先に効いてきます。

列車は、長距離大量輸送の幹線として使うと一番筋がいいです。
ただし「列車が強い」ではなく、「長距離大量を列車に押し込むと、他方式の無理が減る」と捉えたほうが設計を外しません。
駅で豪華なバランサと箱群を組み始めると、せっかく幹線で節約したぶんを積み下ろしで吐き出します。
列車は万能物流ではなく、遠距離の太い流れをまとめる役です。

ここでもうひとつ触れておきたいのが、フル圧縮ベルト信仰です。
ベルトは常に完全圧縮されているほどUPSにいい、という話も単純化しすぎです。
Factorio ForumsのUPS Optベルトの充填率だけを絶対視しても設計全体の良し悪しは決まりません。
無理に圧縮を維持するために再循環、過剰な優先分岐、横差しの連打を入れるくらいなら、少し余白があっても素直なレイアウトのほうが結果は良いことが多いです。
自分も最初は「隙間のあるベルトは悪」と思っていましたが、工場全体で見ると、重いのは隙間より寄り道でした。

混成設計（幹線/支線/端末）の型

UPSを意識した工場でいちばん効く型は、幹線を列車、支線をベルト、端末を直接搬入に寄せる構成です。
言い換えると、列車で大きく運び、ベルトで短く配り、最後はDIで受け渡す、という三段です。
ここで本質になるのは、方式の優劣そのものより積み替え回数を最小化することです。

よくある重い構成は、列車で運んで、駅で箱に落として、バランサで均して、ベルト幹線に戻して、また分岐して、最後にinserterで設備へ入れる流れです。
これだと品目が増えるたびにsplitter、inserter、曲がり、箱の数が増えていきます。
見た目は立派でも、荷物が何度も触られます。
逆に、列車駅を消費ブロックの近くに置き、そこから短いベルトで引き、入れられる場所は直接搬入で受けるようにすると、触る回数そのものが減ります。

自分が科学1000超の構成を触っていたときも、途中から幹線列車と端末DIに寄せたら、F4のentity-time-usageでInsertersとTransport linesの割合が目に見えて下がりました。
体感だけでなく表示でも落ち着いたので、「遠くは列車、近くは短いベルト、終点は直接」の型はやはり効くと実感しました。
列車を増やしたから軽くなったのではなく、駅の先に長い整列工程を置かなくなったことが効いていました。
これ、地味に見えて差が出るところです。

DIの価値は、単発の数値より「搬送の枝を切れる」点にあります。
直接搬入1回の試算は約3.56µsですが、実戦で効くのはその1回の軽さだけではありません。
ベルト1本、箱1個、inserter1本を置かずに済む場面が積み上がることです。
たとえば板材から中間素材を作る列では、隣接配置で受け渡せるなら、端末ベルトを伸ばさないほうが全体は素直になります。

この型で注意したいのは、支線ベルトまで幹線化しないことです。
駅から出たあとに何画面分も巨大なベルトバスを引くと、列車で距離を詰めた意味が薄れます。
幹線は列車、支線は短いベルト、その先は DI という役割分担を崩さないほうが安定します。

判断フローチャート

方式選びに迷ったら、距離・スループット・更新頻度の順で判定すると手早く決まります。
短距離ならベルト、長距離かつ大量なら列車、断続需要で小量なら bot が候補、という具合です。

1. まず距離を見る。長距離なら列車を先に候補に置きます。短距離ならベルトから考えます。

1. 次に流量を見る。中〜高スループットを常時流すならベルト、長距離かつ大量なら列車です。低スループットならbotが候補に入ります。

1. 更新頻度を見る。断続需要で小量ならbot、常時消費ならベルトか列車に寄せます。

この流れに沿うと、botが本命になる場面は限定されます。
短距離で、低頻度で、小量。
この三つが揃ったときだけです。
補給箱の補充や建設資材の配達はそこに入りますが、板材や回路を主物流で運ぶ役ではありません。

ベルトを選ぶ場面では、「まっすぐ短く流せるか」を合わせて見ます。
そこで大量のsplitterやinserterが必要なら、ベルト向きの案件を自分でベルト不向きに変えている可能性があります。
曲がりやUターンが何度も入る設計、箱を挟む設計、均等化のためのバランサだらけの設計は、ベルトの利点を削ります。
ベルトは単純であるほど強い、という前提を崩さないほうが安定します。

列車を選ぶ場面では、「駅で何回触るか」を見ます。
遠くへ運ぶこと自体は得意でも、降ろしたあとに複雑な整列工程を組むなら、その駅は重くなります。
train-to-trainに寄せる、消費ブロックのそばで降ろす、ベルト支線を短くする、DIで終点を閉じる。
このどれかが入ると、列車案の強みが生きます。

コミュニティのベンチマークは、この判断の背中を押す材料として使うと役立ちます。
たとえば長距離大量輸送では列車が先頭に立ち、botは苦しくなりやすい、という傾向は共有しやすいのが利点です。
ただ、自分が設計を詰めるときは、数字をそのまま信仰しません。
ハードも地形も工場の組み方も違うので、同じ原則でも順位がひっくり返る場面はあります。
だからベンチは方向を決める地図、自分のセーブでのF4計測は答え合わせ、くらいの距離感がちょうどいいです。
自分も理屈ではベルト優位と思っていた区間が、実際には端末DIへ寄せた列車案のほうが素直に下がったことがありました。
数字を見ると、思い込みが一回外れます。

よくある誤解と古い情報の見分け方

地下ベルト神話のアップデート

UPSの話で長く残っている定番のひとつが、「地下ベルトを多く使うほど軽い」という説です。
これは昔の知見として語られることが多いのですが、今の議論では、ギャップのない同色ベルトを同条件で並べた場合、通常ベルトと地下ベルトの差を一般論として大きく見るのは難しい、という整理が主流です。
Factorio ForumsのHow do I save UPS for megabase?でも、古い定説をそのまま持ち込むより、item move countや駅・搬送設計全体を見るほうが筋がいい、という方向で話が進んでいます。

自分もこれで一度思い込みを外されました。
昔は地下ベルトを詰め込んだ設計ほどUPS向けだと信じていて、古い青写真をその前提で組んでいました。
ところが、その旧設計を通常ベルト主体に差し替えてベンチを取り直したとき、結果はほぼ動かなかったんです。
そこで効いたのは地下化そのものではなく、途中に入れていたバランサを減らしたことでした。
見た目は派手に変わっても、tick時間に出た差は「ベルトの種類」より「余計な分配処理」のほうが大きかったわけです。

ここで気をつけたいのは、「地下ベルトは無意味」という話ではないことです。
交差回避、取り回し、設計密度の確保には今でも強いです。
ただ、地下であること自体をUPS改善の本丸に置くと、重い箇所を見誤りがちになるということです。
直線区間の通常ベルトを地下に置き換えるより、splitterだらけの整列工程や、箱を挟む回り道を削るほうが筋のいい改善につながることが多いです。

核発電は常に悪？への留保

もうひとつ、古い言い回しで見かけるのが「核発電はUPS的に常に悪い」という断定です。
これも言い過ぎです。
発電方式には差がありますが、実戦では発電所そのものの差より、そこに燃料や資材をどう運び、どこで積み替え、駅をどう組んでいるかのほうが支配的になることが多いです。

たとえば、発電を軽くしたつもりでも、燃料搬入のために駅にinserterとチェストを並べ、さらにバランサで均していたら、発電設備で節約したぶんを物流側で使ってしまいます。
前述の通り、UPSは方式名だけで決まるのではなく、触る回数の総量で見たほうが外しません。
核だけを悪者にすると、この視点が抜けます。

なので、核発電は「絶対に避ける対象」ではなく、設置数に応じて最適化対象として扱うくらいの距離感がちょうどいいです。
発電設備が巨大になってきたら見直す価値はありますが、工場全体を見たときに先に効くのが列車駅の複雑さや主物流の遠回りである場面は珍しくありません。
発電方式の議論だけを切り出して白黒をつけると、工場全体の重心を外します。

MOD入りベンチの読み方

ベンチマーク結果を見るときに地味に危ないのが、MOD入りの数字をそのまま一般化することです。
ここは本当に引っかかりやすいところで、MODは新しい建物や物流手段を足すだけではなく、スクリプト処理や描画まわりの差も持ち込みます。
すると、見えている差が設計の優劣なのか、MOD由来の負荷なのかを分けにくくなります。

そのため、設計比較の読み方としては、まずvanilla寄りの条件で見て、青写真の差だけを追う形が安定します。
The Factorio Benchmark Websiteの考え方でも、比較は同じ条件で揃えることが前提ですし、Factorio ForumsのUPS-optimized green circuits benchmarkingでも、青写真比較は条件統一が前提で進んでいます。
MODを入れた結果を読むなら、「そのMOD環境ではそうだった」と一段階限定して受け取るほうがぶれません。

数字の扱い方も同じで、コミュニティ実測のns/tickやms/tickは便利ですが、記事や会話では断定の材料というより傾向の地図として読むのが安全です。
複数ソースで似た向きの話が出ているか、比較条件が揃っているか、vanillaかどうか。
この3点を見るだけでも、古い情報やノイズの混入をだいぶ避けられます。

部分充填vs満載ベルトの注意

「部分充填ベルトのほうが軽いのか、満載ベルトのほうが軽いのか」という議論も、単独で切り出すと誤解が増えやすいテーマです。
Factorio ForumsのUPS Optimization - the full belt mythで扱われている通り、ここは条件を揃えない比較がそのまま広まりやすい分野です。

問題は、比較の前提がずれやすいことです。
同じスループットなのか、同じ距離なのか、splitterやinserterの数も同じなのか。
ここが一致していないまま「満載が強い」「部分のほうが軽い」と言っても、設計全体では別の要因を見ている可能性があります。
たとえば、満載ベルト案が有利に見えても、実際にはベルト本数を減らしたことでinserterや分岐も減っていただけ、ということがあります。
逆に部分充填案がよく見えても、単にレイアウトが短かっただけ、ということもあります。

この手の議論は、同スループット・同距離・同構成で並べないと一般化できません。
自分の感覚でも、ベルト充填率そのものより、そこに至るまでの分配工程や終端処理のほうが結果を左右する場面が多いです。
なので、満載か部分かだけを設計原則にすると、実際にはバランサ過多や無駄な合流を温存してしまいます。
見るべきなのはベルトの見た目の密度ではなく、そのラインに到達するまでに何回触っているかです。

数値を持ち出すときも、参考値はあくまで参考値として置くのが筋です。
ひとつのベンチ結果だけで原則化せず、複数の比較を見て、「この条件ではこういう傾向だった」と読むほうが、誤った最適化に引っ張られません。
ここを押さえておくと、古い神話に振り回されず、工場全体のどこを削るべきかが見えやすくなります。

UPS改善の実践チェックリスト

手を付ける順番さえ間違えなければ、UPS改善は「大工事」になりません。
筆者は主要駅の一つで inserter を 48 本から 32 本に減らし、バランサを外して受け側を DI 寄せにしただけで avg_ms が 0.12 下がった事例を持っています（この値は該当セーブでの計測結果に基づく事例です）。
こうした個別改善は、まず代表ブロックでベンチを取り、結果を数値で確認してから本工場へ横展開するのが安全です。

改善対象を見つけるときは、方式名ではなく「どれを何個、どれくらい動かしているか」を数字で見ます。
物差しは item move count、アクティブ数、距離、inserter回数の4つです。
不要な迂回や循環でアイテムを何度も動かしていないか、飛行中botや稼働建物が膨らんでいないか、botに長距離を飛ばしていないか、駅で積み下ろしのためにinserterを盛りすぎていないか。
この4点で見ると、減らすべきものがはっきりします。

減らすべき対象は明快です。
不要なアイテム移動、バランサと splitter の乱用、長距離bot、そして駅アンローダの過剰な inserter です。
逆に採用候補として当たりを引きやすいのは、直接搬入、幹線を列車で運んで端末だけをベルトやDIでつなぐ形、botネットワークの分割、直線で短距離の単純フローです。
複雑な見た目を整えるより、1回でも触る回数を減らすほうが、UPSでは素直に効きます。

今日からできる4ステップ

着手順は、重いところを見つけてから、いちばん高いコストの物流を1件置き換え、駅を棚卸しし、ベンチで確認する流れが鉄板です。
順番を崩すと、手応えの薄い改善に時間を吸われます。

1. F4 を有効化して、重いカテゴリとエンティティを特定します。show-fps、show-time-usage、show-entity-time-usage を見て、まず bot なのか、inserter なのか、輸送ラインなのかを切り分けます。
2. 長距離bot輸送の代替を1件だけ入れます。1000タイル級の長距離大量輸送では、Factorio Forumsで共有されている比較でも bots 10.045ms/tick、belts 0.180ms/tick、trains 0.067ms/tick という差が出ています。主物流をbotで抱えているなら、まず1本を列車かベルトに置き換えるだけで傾向が見えます。
3. 主要駅のバランサと splitter を棚卸しします。均等化のために積んだ部品が、本当に必要な箇所だけ残っているかを確認して、駅アンローダの inserter 本数も見直します。過剰な荷下ろしは、列車の強みを駅で削ります。
4. 代表ブロックをベンチセーブ化して、--benchmark で前後比較します。改善は1変更ごとに測るのが基本です。avg_ms の差分が 0.05ms 以上なら当たりと見てよく、0.02ms 前後なら誤差も混ざるので複数回回して判断します。

減らす/採用するの判断基準

何を減らすかは、見た目の複雑さではなく、4つの指標に落として決めるとぶれません。
item move count が多いものは、まず疑う価値があります。
ベルトから箱、箱から列車、列車から箱、箱からベルトのように保管を何度も挟む構成は、そのぶん触る回数が増えます。
直接搬入に寄せられる場所は、そこから削るのが筋です。
直接搬入1回の試算は約3.56µsなので、こうした小さな節約もまとまると効いてきます。

アクティブ数は、飛んでいるbotと動いている設備をまとめて見る感覚が欠かせません。
飛行中の物流ロボットは1機あたり 140〜190ns/tick の目安があり、数が膨らむと一気に重くなります。
補給や建設のような短距離・断続用途はbotに向いていますが、長距離の主物流まで抱え込ませると、飛行数と距離が一緒に増えて厳しくなります。
botを採用するなら、ネットワーク分割で飛行距離を短く保つ形が安定します。

距離は、同じスループットでも方式の向き不向きを分けます。
短距離ならベルトやDIが素直で、長距離の高流量は列車幹線に寄せたほうが崩れません。
自分は「長く運ぶものは列車、着いた先の数十タイルをベルトかDIで閉じる」という形をよく使います。
これだと幹線は単純で、端末も station-heavy になりにくい設計です。

inserter回数は、駅改善の判断にそのまま使えます。
アンローダで belt balancer を通す前提になっていると、inserter 本数も周辺設備も増えます。
受け側ラインにそのまま流せるなら、均等化より直結を優先したほうが軽くまとまります。
見直すべき駅アンローダは、全ホームで同じ構成を機械的に並べている場所です。
混雑対策のつもりで足した部品が、常時コストに変わっていることが多いです。

採用する設計の基準もシンプルです。
直接搬入、幹線列車＋端末ベルト/DI、分割したbotネットワーク、直線で短い単純フロー。
この4つは、どれも「アイテムを遠回りさせない」「同じ役割の部品を増やしすぎない」という共通点があります。
逆に、減らすべき対象は、不要な迂回と循環、バランサ・splitterの乱用、長距離bot、駅の過剰inserterです。
見た目の整い方より、1アイテムがゴールまで何回触られるかで選ぶと外しません。

ベンチセーブの作り方と運用

改善の効き方を確実に見るなら、代表ブロックをベンチセーブにして比べるのがいちばん早いです。
対象は、主力の製造ブロック、長距離輸送の起点と終点、主要駅のいずれかに絞ります。
ポイントは「重い場所をそのまま切り出す」ことです。
軽い場所で試しても差が埋もれます。

作るときは、改善前の状態を保存し、そのコピーで1変更だけ加えます。
たとえば、長距離botを列車1本に置き換える、駅アンローダの inserter を減らす、バランサを撤去してDIへ寄せる、といった単位です。
変更を2つ3つまとめると、何が効いたのか分からなくなります。
最初は自分もまとめて直してしまって、良くなった理由が追えずにやり直しました。

運用では --benchmark を使って前後比較し、見るのは avg_ms の差分に絞ります。
The Factorio Benchmark Websiteの考え方どおり、比較で見るべきなのは換算後の見栄えより、前後で何ms動いたかです。
0.05ms以上の改善なら、その変更は横展開する価値があります。
0.02ms前後なら誤差の可能性が残るので、複数回まわして平均を見てから判断します。
この「1変更→測定」の短いサイクルを守ると、思い込みで工場を壊さずに済みます。

自分のおすすめは、ベンチセーブに名前で意図を残すことです。
駅なら「ore_unload_before」「ore_unload_DI_after」のように、何を変えたかが一目で分かる形にしておくと、後から見返しても迷いません。
改善の蓄積は、結局この比較ログが資産になります。
UPS改善はセンス勝負というより、重い1点を見つけて、減らすべきものを削り、採用する設計を数字で選ぶ作業です。
ここが回り始めると、工場全体の手直しも怖くなくなります。