【Factorio】惑星間物流とロケット輸送設計（Space Age）

Factorio 2.0とSpace Ageの惑星間ロケット輸送は、特別なイベント輸送として考えるより、地上物流の延長として組んだほうが一気に安定します。
ロケットサイロを供給、カーゴ降着パッドを受取と要求、宇宙プラットフォームハブを要求兼パッシブ供給として整理するのが、自分は一番詰まりにくかったです。

最初は、自分も修理パックを200個だけ送りたくてロケットを組んだのに、満載待ちで飛ばず、着いた先でもカーゴ降着パッドの1スタック受取で荷下ろしが詰まって悩みました。
そこで見えてきたのが、最小積載量、周辺レイアウト、惑星別要求のルールを先に決めるだけで、少量補給も緊急便も素直に自動化できるということです。

この記事は、Space Ageの宇宙物流を手動運用から卒業したい人向けに、大量定期便・少量補給便・緊急補修便をどう使い分けるかまで含めて、詰まらない設計ルールに落として解説します。

【Factorio】惑星間物流とロケット輸送の前提知識

対象バージョン・DLCの確認

この話の前提はFactorio 2.0 + Space Ageです。
Space Age は 2024年10月21日にリリースされた拡張で、ここからロケットの位置づけが変わります。
通り、宇宙到達と他惑星アクセスが進行の中心に入ってくるので、ロケットは「終盤のご褒美」ではなく「普段使いする物流設備」として見たほうが見通しが立ちます。

この前提を外すと、惑星内物流と惑星間物流を同じ設計軸で比べにくくなります。
自分は列車網を広げる感覚で最初は宇宙も見ていたんですが、Space Age ではそこで一段発想を切り替える必要がありました。
惑星内では、定常で大量に流すならベルト、長距離の大量輸送なら列車、短距離で配線の自由度が欲しいなら物流ロボット、という使い分けが基本です。
そこに対して惑星間だけはロケットが必須になります。
他惑星へ物資を渡す基幹手段がロケットだからです。

この整理を先に置いておくと、輸送方式の比較がすっきりします。
ベルトは連続供給が得意で、搬送ベルトの基本速度は 1.875 タイル/秒、高速はその2倍、超高速は3倍です。
一方で長距離になるほど配線が太りやすいのが利点です。
列車はその長距離区間をまとめて飲み込むのが得意で、大量輸送の主役になりやすいのが利点です。
物流ロボットは障害物を無視して柔軟に運べますが、ロボットステーションのエリアや充電がボトルネックになります。
宇宙にまたがる瞬間だけ、この三者の延長では届かず、ロケットへ役割が切り替わるわけです。

バニラの衛星打ち上げとの違い

バニラでのロケットは、相当長いあいだ「ゲームクリア演出に近い存在」でした。
衛星を載せて打ち上げる、という記憶で止まっている人は多いと思います。
自分もまさにそれで、衛星＝エンディングの発想が強く残っていました。
だから Space Age に入った直後は、ロケットを量産設備として扱う感覚に切り替わるまで少し時間がかかりました。

でも Space Age では、ここが別物です。
ロケットはたまに打つ特別イベントではなく、建材便、補修便、惑星専用資源便を回す日常物流の主役になります。
地上で言えば、ベルトや列車を置くのと同じくらい「どう回すか」を設計する対象です。
この変化を理解すると、惑星内の幹線設計と惑星間の補給設計が、頭の中で一本につながります。

衛星打ち上げの要素自体が消えたわけではありません。
カーゴ降着パッドは、衛星を搭載したロケットの打ち上げ時にスペースサイエンスパックを1000個受け取る仕様があります。
これは ただ、本記事の軸はそこではなく、貨物輸送としてロケットをどう扱うかです。
研究パック受け取りは仕様の一部として知っておけば十分で、設計の中心は「何を、どの惑星から、どんな便として流すか」に置くべきです。

カーゴ降着パッド - Factorio Wiki

wiki.factorio.com

レシピ・仕様の版差への注意

ロケットまわりは、旧情報と現行情報が混ざりやすいところです。
ここは地味に大事なんですよね。
特に検索で古い記事や古いレシピ画像を踏むと、今の設計と噛み合わなくなります。

まず押さえたいのは、ロケットはロケット部品100個で完成し、1個ごとに進捗1%という点です。
これは 打ち上げ1便をどう生産ラインに落とすか考えるときの土台になります。
ロケット1便を「1回の大イベント」ではなく、「100ステップの製造進捗を持つ物流便」と見ると、部品供給の詰まりも読みやすくなります。

一方で、昔のロケット情報に出てきたロケット制御装置（RCU）は、Space Age の系統ではもう使いません。
旧仕様を前提にすると「なぜ RCU のラインが必要ないのか」で混乱しがちですが、この差は版差として整理するのが正解です。
つまり、旧バニラ系のロケット素材構成と、2.0 + Space Age のロケット素材構成は同じものとして読まないほうがいい、ということです。

この版差は、単にレシピが違うだけではありません。
設計思想にも影響します。
旧感覚のままだと「ロケットは最終盤の超高級品」という認識が残りやすいのですが、Space Age では早めに物流手段として組み込む前提に変わっています。
だから惑星内の物流を作るときも、最終的にロケットサイロへどうつなぐかまで含めて考えると無駄が減ります。
たとえば、定常大量流の中間材はベルトでまとめ、鉱石や建材の長距離移動は列車で集約し、サイロ周辺の細かい補給だけロボットで受ける、という構成は相性がいいです。
その先で、惑星をまたぐ便はロケットに載せる。
この一本化ができると、地上と宇宙が別ゲームに見えなくなります。

ロケット部品 - Factorio Wiki

wiki.factorio.com

惑星間物流を構成する3施設の役割

ロケットサイロ

ロケットサイロは、この3施設の中ではいちばんわかりやすい供給側です。
役割で言い切るなら、地上で作った物資を宇宙へ送り出す発送口だと考えるのが整理しやすくなります。
自分はここを「宇宙向けの供給チェスト」と置き換えてから、サイロ周辺の設計が素直になりました。
何をどれだけ送りたいのかを地上側で集約し、サイロに流し込む。
やっていることは特別に見えても、頭の中の整理としては地上物流の延長です。

ロケットそのものは、つまりサイロは、単に貨物を積む場所ではなく、1便ごとの製造進捗を抱えた発送設備でもあります。
この性質があるので、サイロのボトルネックは「送りたい物が足りない」だけではありません。
ロケット部品の供給が切れる、積み込み対象が分散して集まらない、少量便なのに発射条件が重い、といった形でも止まります。

実際の運用では、サイロを工場の末端に置くより、列車や幹線ベルトでまとめた物を最後に集約する発送駅として扱ったほうが安定しやすい構成になります。
建材、補修材、弾薬、モジュール素材のように惑星間で融通したいものをサイロ前で一本化しておくと、「どの惑星へ何を送る設備なのか」が見えやすくなります。
逆にサイロへ直接いろいろなラインをねじ込むと、地上物流の詰まりがそのまま宇宙便の遅延になります。

この施設を供給側と割り切ると、設計判断も明快です。
サイロ自身に細かい判断を期待するより、地上で在庫を作って送り出す責任を持たせるほうがうまく回ります。
自分は最初、サイロを「宇宙物流の中心装置」だと思っていましたが、実際はそうではなくて、あくまで発送担当です。
中心になるのは要求の置き方で、発送側はその要求に応える構造にしたほうがトラブルを追いやすい形になります。

カーゴ降着パッド

カーゴ降着パッドは惑星側の受け取り兼要求ハブです。
宇宙プラットフォームから降りてくる物資の着地点であり、同時に「この惑星では何を欲しがっているか」を宇宙側へ示す窓口でもあります。
ここを地上の要求チェストに見立てると、惑星間物流の全体像が一気に見えやすくなります。
前述の通り、自分もこの対応関係でやっと腹落ちしました。

公式の一度に1スタックしか受け取れないことです。
これ、地味どころか本質的です。
大量便を想像して設計すると見落としやすいのですが、受け取り側は無限に飲み込めるわけではありません。
少量の高頻度補給では扱いやすい一方、降下物資が集中するとここが律速になりやすい設計です。

この制約のせいで、降着パッドの周辺は「届いた瞬間に素早くはける」構成が重要になります。
受け取った物をロボットへ任せるのか、ベルトで即座に仕分けるのか、列車駅前の一時集積所に送るのかで体感の詰まり方が大きく変わります。
自分の感覚では、降着パッドは倉庫そのものというより惑星側の玄関口です。
玄関で荷物が積み上がると次の便が詰まるので、到着後の搬出設計まで含めて一体で考えたほうが失敗しにくくなります。

衛星を搭載したロケット打ち上げ時に、カーゴ降着パッドがスペースサイエンスパック1000個を受け取る仕様もありますが、物流設計の観点では「惑星の受取窓口」という理解のほうを外すと設計が崩れます。
要求をここに置き、宇宙からの到着物をここで受け、地上物流へ流し直す。
この一連の流れが見えてくると、惑星ごとに何を自給し、何を輸入するかの線引きもしやすくなります。

宇宙プラットフォームハブ

宇宙プラットフォームハブは、宇宙側の運用拠点です。
公式ページで確認できる範囲でも、ハブにインベントリがあり、自動リクエスト機能を持ち、プラットフォームの中心として振る舞うことははっきりしています。
役割のイメージとしては、要求チェストでありながら、持っている物は供給側にも回るという理解がいちばん使い勝手が良いです。

この「要求チェスト兼パッシブ供給チェストっぽい」という整理は、細部まで公式が言い切っているというより、実運用でそう捉えると扱いやすい、という種類の知見です。
自分も最初はここがいちばん曖昧でした。
ハブをただの倉庫だと思うと、なぜ要求を出せるのか、なぜプラットフォーム上の物資の起点になるのかがつながりません。
逆に、欲しい物を集める場所であり、持っている物を軌道上の作業に回す場所だと考えると納得できます。

特にプラットフォーム運用では、地上のように好きなだけチェストを並べて整理する発想が通りにくいので、ハブの性格をどう理解するかが設計の軸になります。
建設用資材や補修物資を自動で欲しがる動きは要求チェスト的ですし、ハブ内にある在庫がプラットフォーム側の運用資源になる点は供給側の顔を持っています。
だからこの施設だけは、単純な「受け取り」でも「送り出し」でもなく、宇宙側の要求と保管を兼ねる中継核として見るのがしっくりきます。

この整理を入れると、3施設の関係はきれいに並びます。
地上で集めて宇宙へ送るのがロケットサイロ、惑星で受けて要求を持つのがカーゴ降着パッド、宇宙で要求しつつ保管と供給の中心になるのが宇宙プラットフォームハブ、という分担です。
自分はここを理解してから「宇宙物流は難しい仕組み」ではなく「物流チェストの役割分担が場所をまたいでいるだけ」と見えるようになりました。

Space platform hub - Factorio Wiki

wiki.factorio.com

施設役割の比較表

文章だけでも理解はできますが、実際に組むときは表で役割を切り分けたほうが迷いにくい傾向があります。
特に「どこが供給で、どこが要求で、どこが詰まるのか」を一枚で見られるようにしておくと、トラブルの切り分けが速くなります。

この表で見えてくるのは、3施設が似たような箱ではなく、発送・受領・宇宙側中継ではっきり分業していることです。
詰まったときも、「発送が悪いのか」「受け取りが詰まっているのか」「宇宙側の要求整理が甘いのか」で見るだけで、原因を追いやすくなります。
自分はこの切り分けができるようになってから、惑星ごとの専用便と緊急補修便を同じネットワーク上で共存させやすくなりました。

最初の自動輸送ラインを作る手順

研究: ロケットサイロと宇宙到達

最小構成で自動輸送ラインを作るなら、出発点はロケットサイロ研究です。
ここが終わっていないと、当然ですが地上から宇宙へ物を押し出す手段そのものがありません。
しかも今回やりたいのは「大量輸送」ではなく、ナウヴィスから宇宙プラットフォームや別惑星へ少量補給便を自動で回すことなので、まずは1便を安定して飛ばせる状態を作るのが先です。

ロケットの準備では、ロケット部品を積み上げて完成させていきます。
ここでありがちな失敗は、サイロ本体を置いた時点で「もう宇宙物流に入った気になる」ことです。
実際には、サイロに流し込む部品材料や、送りたい貨物の集約が別問題として残ります。
自分も最初、研究完了で一気に世界が開ける感覚になったんですが、正直なところ本番はその後でした。

この段階で意識しておくと楽なのは、最初の便は建設資材と最低限の補給品に絞ることです。
最初から品目を増やすと、どこで詰まっているのか見えにくくなります。
失敗ポイントは、研究直後に「あれもこれも送る」設定にして、サイロ側の供給不足と要求設定のミスが同時に起きることです。
最初は再現性を優先して、便の役割を目に見えて狭くしたほうが安定します。

惑星/プラットフォームへの進出

次は、物資の送り先を用意します。
送り先は大きく2通りで、宇宙プラットフォームに直接補給するか、別惑星の地表へ落とす前提で運用するかです。
最小構成として組みやすいのは、まず宇宙プラットフォームを作って、そこに補給を入れる形です。
宇宙プラットフォームは Space Age の中心機能で、停泊先の惑星軌道にいるときに地上との受け渡しを扱えます。

ここで必要なのは、「どこへ送るか」だけでなく「どこに止まっているときに受け渡すか」を意識することです。
プラットフォームが対象惑星の軌道にいなければ、地表とのやり取りは進みません。
つまり、物流の問題に見えて、実際には運行先の指定ミスで止まることがあるわけです。
これ、地味に大事なんですよね。
サイロ側ばかり見ていて、実はプラットフォームが別の場所にいて届かない、というのは起きできます。

別惑星へ直接進出する場合も考え方は同じで、受け取り先がすでに機能する状態かを先に確認しておく必要があります。
送り先の足場がまだないのに自動補給だけ先に組むと、到着後に搬出できず、次の便も詰まりやすくなります。

カーゴ降着パッドの設置

地表で受け取るなら、カーゴ降着パッドは最優先です。
ここがないと、惑星側の受け取り窓口が成立しません。
役割としては前のセクションで触れた通りですが、実際に手順へ落とすときは「置く」だけでなく、置いた直後に搬出経路までつなぐところまでを1セットで考えると失敗しにくい構成になります。

受け取りは一度に1スタック単位です。
だから、到着した物を素早く外へ逃がせないと、受け口が詰まって次の荷下ろしが鈍くなります。
最初は「少量便なんだから適当な箱でいいでしょ」と思いがちなんですが、実際は少量便ほどこの詰まりが目立ちます。
1スタックずつしか受けないので、建材・ベルト・ポールみたいな複数品目が混ざると、出し先が弱いだけで流れが止まりできます。

設置場所は、降着パッドのすぐ外にベルトか物流ロボットの受け先を置ける位置が扱いやすい構成です。
ロボットでさばくなら、ロボットステーションの物流エリアは50x50タイルなので、その範囲を意識して近くにまとめると整理しやすくなります。
失敗ポイントは、パッドだけ離れた場所に置いて、あとから長い搬出線を継ぎ足す形にすることです。
これをやると、到着確認と詰まり確認の両方が面倒になります。

宇宙プラットフォームハブの要求設定

送り先が宇宙プラットフォームなら、中心になるのは宇宙プラットフォームハブです。
ここで要求を出しておかないと、地上側は「何をどれだけ送ればいいのか」が定まりません。
ハブは単なる倉庫ではなく、補給の起点になる場所なので、最初の自動便では建設に必要な最低限の資材だけを要求するのがやりできます。

具体的には、最初の便で使い切る可能性が高い建材を少量ずつ要求に入れます。
ここで欲張って品目を増やすと、どの要求が満たされずに止まっているのかが見えなくなります。
しかも手動リクエストは配送元の惑星指定が絡むので、どこから届く前提なのかを自分で把握していないと混乱しやすく、序盤の安定感が増します。
自分はここで一度、ナウヴィスから送るつもりの資材が別の前提になっていて、サイロ側は動いているのに補給が揃わない状態を作りました。

初回は、「この便は建設開始用」と割り切るのが安定します。
プラットフォーム上でゴースト建設を進めたいなら、自動リクエストも相性がいいです。
逆に、どの惑星から送るかを細かく固定したい場面では、個別要求のほうが挙動を追いやすいため、実用性が高い構成です。
失敗ポイントは、要求量を大きくしすぎて、後述する最小積載量と噛み合わず、便がいつまでも出ないことです。

地上側供給の接続

要求を出しただけでは物は飛びません。
ナウヴィス側で、ロケットサイロに送る供給線をつなぎます。
最小構成なら、巨大な専用駅や列車網まではいりません。
まずはサイロに確実に集まる一本の供給線を作るだけで十分です。
ベルトでもロボットでも構いませんが、初回は流れが見える分、ベルトのほうがデバッグできます。

ここで大事なのは、ロケット部品の材料ラインと、貨物そのもののラインを頭の中で分けて考えることです。
サイロが動かないとき、原因は「送りたい物がない」のか「ロケットを完成させる側が遅い」のかで対処が変わります。
これを混同すると、補給品の不足を疑っていたら実はサイロ側の製造進捗が止まっていた、という遠回りになります。

最初の自動便では、地上モールの余剰をそのまま雑に突っ込むより、補給対象を限定した専用差し込みのほうが再現しやすく、結果として効率が上がります。
失敗ポイントは、地上物流のいろいろなラインを一気に接続して、サイロの中身が意図しない品目で埋まることです。
少量補給便なのに荷姿が毎回ぶれると、テスト結果も読みづらくなります。

少量補給のテスト配送とログ確認

配線と要求がそろったら、いきなり本運用にせず、まずは少量補給のテスト配送を回します。
ここで確認したいのは、物が届くかどうかだけではありません。
満載待ちで止まらないか、そして到着後にカーゴ降着パッドが1スタック受取の制約で詰まらないかの2点です。

特に見ておきたいのが最小積載量です。
実運用ではここを低めにしないと、自動打ち上げが満載待ちになって少量便が動かないことがあります。
自分の初回もまさにそれで、建設資材が届く前にずっと待機していました。
設定を下げたら、一気に便が回り始めたんですよね。
少量補給便を作るなら、この挙動確認はきわめて効きます。

ログや状態表示では、少なくとも次の流れがつながっているかを見ます。
サイロで貨物が集まる、ロケットが出る、プラットフォームまたは地表側で受け取る、降着パッドから外へ搬出される。
このどこかで止まっていたら、その場所がボトルネックです。
到着はしているのに次便が鈍いなら、降着パッド周辺の搬出不足を疑うと早いです。

このテスト段階では、成功条件を「大量に届くこと」ではなく、少量でも止まらず1サイクル回ることに置くのがコツです。
ここが通ると、その後は要求品目や便数を増やしても崩れにくくなります。
逆に、初回サイクルが曖昧なまま拡張すると、どこで詰まったのか本当に見えなくなります。

設計のポイント：満載待ち・1スタック制限・惑星別要求

少量補給で一番ハマりやすいのが、「要求数を入れたのにすぐ飛ばない」という挙動です。
ここで注意したいのは、この「満載待ち」的な振る舞いについて、公式ドキュメントで既定値が逐語的に明示されているわけではない点です。
コミュニティの実プレイ観察では「打ち上げ可能なだけ積もうとする」動作が報告されているため、実運用ではその知見を前提に最小積載量を下げる等の対策を取ると安定しやすい、という扱いに留めてください。
必要なら factorio のフォーラムやコミュニティスレッド（例: r/factorio、factorio@jp など）の該当議論を参照することを推奨します。
反対に、鉱石系の中間材や建材のような大量便では、最小積載量をあまり下げすぎると便数だけ増えて運用が散らかります。
少量補給便と大量定期便は、同じロケット輸送でも別物として切り分けたほうが安定します。
設計イメージとしては次の2パターンに分けると整理できます。

少量補給便は「とにかく早く届く」を優先し、大量定期便は「一便ごとの密度」と「受け側のさばき能力」を優先する、という分担です。
この切り分けをしないと、少量品は遅れ、大量品は受け側で詰まるという最悪の両負けになりがちです。

カーゴ降着パッドの1スタック受取が生むボトルネック

受け側で見落としやすいのが、これがあるので、便がちゃんと到着していても、降着パッドの外へ荷物を出し切れず、次の受け取りが鈍ることがあります。

少量補給便ではこの制限はそれほど表に出ません。
問題になるのは、大量便を1基のパッドに集中させたときです。
自分も建材をまとめて落としたとき、サイロ側の生産も打ち上げも回っているのに、現地の補給速度だけ妙に遅いことがありました。
原因を追うと、律速はロケットでもプラットフォームでもなく、降着パッド1基の受け取りと、その周辺の搬出でした。
パッドを増やしたら一気に流れが変わったので、この部分は想像以上に効きます。

パッド本体だけ増やして満足しないことです。
受け取り能力を底上げするには、パッドの並列化と周辺搬送の強化をセットで考える必要があります。
惑星内の大量搬送なら列車が本命ですし、近距離なら高速搬送ベルトや超高速搬送ベルト、仕分けが多いならロボ網が扱いやすい構成です。
ロボットで受ける場合は、ロボットステーション - 50x50タイルの物流エリアに収める配置だと、受け口の見通しが良くなります。

設計イメージを簡単に言うと、少量補給便は「1基のパッドからすぐ隣へ逃がす」、大量定期便は「複数パッドから複数系統へ分散する」です。
特に大量便では、パッド前に仕分けバッファを少し置くだけでは足りず、その先の列車駅や幹線ベルトまで含めて太くしておかないと、結局パッド前が詰まります。

惑星別要求と配送元指定のルール

要求設定でもうひとつ詰まりやすいのが、配送元惑星を省略できない点です。
宇宙プラットフォームの手動リクエストは、プレイヤーが指定した一つの惑星から満たされる前提です。
なので、同じ品目を複数惑星のどこからでも補充できるつもりで1本の要求を書いていると、思ったように回りません。

このあたりは、コミュニティで整理されている「宇宙ネットワークの詳細」の知見が実務的です。
本文で断定しすぎない形で言うと、配送元指定を空欄のまま自由化する運用はできず、複数惑星から同じ品目が欲しいなら、要求を惑星ごとに分ける扱いで考えておくのが安全です。
たとえばナウヴィス産の建材と、別惑星で量産している同名品を両方候補にしたいなら、「同じアイテムを1件」ではなく「惑星A分の要求」「惑星B分の要求」と分けておく、という考え方です。

ここを曖昧にすると、物流の見た目は整っているのに補給が欠けます。
特に複数惑星を巡回するプラットフォームでは、「どこから届く想定なのか」が設定に埋もれできます。
自分はこの手のミスを避けるため、少量補給便では品目数を減らすだけでなく、配送元の責任分界も減らすようにしています。
ナウヴィスから送る便なのか、現地惑星で補う便なのかを最初から分けておくと、詰まったときに追いできます。

自動リクエストは別の考え方で、任意の惑星から受け取れる運用ができます。
ただ、どの惑星を優先したいかまで細かく握りたい場面では、手動要求のほうが設計意図を保ちやすい点が強みです。
補給が遅いときに「要求量の不足」なのか「配送元指定のズレ」なのかを見分けやすいのも手動側の利点です。

設定UIのチェックリスト

設定画面では、数値そのものよりどの種類の詰まりを防ぐ設定なのかで見ると見通しが立ちます。
自分は次の4点を見て、少量便なのに満載待ち、大量便なのに受け側飽和、という典型的な事故を減らしています。

• 要求が少量補給便なのか大量定期便なのか

便の役割が曖昧だと、最小積載量もパッド数も決まりません。
弾薬や修理パックは少量補給便、建材や中間材は大量定期便として分けて考えると設定がぶれにくい構成になります。

• 最小積載量が便の役割に合っているか

少量品は低めにして頻度重視、大量品は高めにして密度重視です。少量便でここが高いままだと満載待ちに入りやすく、欠品が長引きます。

• 配送元惑星が明示されているか

手動要求は配送元を前提に動くので、「どこから来る便なのか」が曖昧だと切り分け不能になります。同品目を複数惑星から欲しいときは、要求を分けたほうが追いできます。

• 降着パッドの数と周辺搬送が釣り合っているか

大量便を受けるのにパッド1基だけ、あるいはパッドを増やしても搬出が細いままだと、到着後に詰まります。
列車、ベルト、ロボ網のどれで外へ逃がすかまで含めて一体で見ます。

UI上の正式ラベルは公式文書で網羅確認できない部分がありますが、設計の見方としてはこの4点で十分回せます。
実際、宇宙物流のトラブルは「送れない」より送れるのに届かない、届くのに回らないのほうが多いです。
なので設定画面では、数量の大小よりも、満載待ち・配送元・受け取り口の3つが噛み合っているかを見るほうが、運用の安定に直結します。

輸送方式の比較：ベルト・列車・物流ロボット・ロケット

惑星内の定常流

惑星内物流をひとつの設計体系として見ると、流量が一定で、ずっと止めたくない物はベルトが基準になります。
板材や中間材のように「採掘地から精錬」「精錬から一次加工」「加工から組立」と流れが読みやすい品目は、ベルトでつないだほうが挙動が素直です。
『搬送ベルトの物理学』 で示されている基本ベルトの速度は 1.875タイル/秒、高速ベルトはその2倍、超高速ベルトは3倍です。
つまり、同じ経路でも色を上げるだけで流量の天井を段階的に押し上げやすいわけです。

ベルトの強みは、単に安いとか早いというより、連続供給をそのまま見える化できることです。
詰まりも欠品も帯の見た目に出るので、原因を追いやすいんですよね。
自分は宇宙便の受け取り先でも、降着パッドから最初の整列まではベルトにすることが多いです。
ロボだけで受けると一見きれいですが、どこで飽和しているのかが見えにくく、後から調整するときに地味に手間が増えます。

逆に、ベルトは長く引き回すほど設計の重さが増します。
惑星内で何百タイルもまたぐ幹線を全部ベルトで通すと、増設や分岐のたびに配線が肥大化しやすい構成になります。
なのでベルトは「定常で大量に流す区間」に集中投入し、遠距離は別方式に切り替えるのが収まりのいい形です。

Transport belts/Physics/ja

wiki.factorio.com

基幹長距離

長距離地上輸送は列車優位です。
これは実際に大規模化するとはっきり出ます。
鉱床と本拠地が離れた瞬間、ベルトは引けなくはないけれど、修正コストと横展開のしにくさが一気に重くなります。
列車なら駅を介して複数資源をまとめて扱えますし、需要が増えたら編成や本数で伸ばしやすい形になります。
鉄道 の仕組み上、駅設計と信号が必要になるぶん最初の敷居はありますが、幹線としてはやはり強いです。

特に鉱石、板材、建材のようなまとまった量を遠くから継続して運ぶ場面では、列車が主役になります。
宇宙物流と地上物流をつなぐときも考え方は同じで、降着パッドの近くに駅前バッファを作り、そこから各工場へ再分配する形にすると運用が静かになります。
受け取り側の瞬間的な凹凸を駅前で吸収できるからです。

このあたり、自分は降着パッドの周辺だけロボ網にして、着地した物資をいったん駅前バッファへ集める構成をよく使います。
そうするとパッドの1回ごとの受け取りの揺れを近距離ロボがならしてくれて、その先は列車で太く安定して流せます。
現場がばたつかず、どこが詰まっているかも見やすいので、マルチでも手に馴染みます。

短距離・柔軟

短距離で柔軟性を最優先するなら物流ロボットです。
ロボポートの物流エリアは 50x50タイル なので、この範囲に受け口と供給先を収めると使い勝手が一気に良くなります。
ロボットステーション の仕様どおり、ロボは障害物を無視して飛べるため、細かな仕分け、モール周り、補給所、駅前の取り回しでは実に便利です。

ただし、ロボは万能ではありません。
律速になるのはだいたい充電です。
需要が跳ねたとき、ロボの機数そのものより先にロボポートの充電待ちが詰まりやすいんですよね。
見た目では飛んでいるのに、実際には往復の回転率が落ちていて、補給遅延だけがじわじわ出ます。
なのでロボは「複雑だけど近い」「品目は多いが量は局所的」という場所に置くのが合っています。

ベルトと列車に対するロボの立ち位置を一言で言うなら、量ではなく自由度を買う輸送手段です。
駅の荷下ろし直後、降着パッド周辺、建設資材の補給ライン、少量多品目の仕分けではロボが本当に楽です。
一方で、惑星全土の主幹線をロボに任せると、充電設備まで含めて支えるコストが大きくなります。

惑星間

惑星をまたいだ時点で、ロケット輸送が必須です。
ここが地上物流との決定的な境目です。
ベルトも列車も物流ロボットも、強いのはあくまで惑星内までで、他惑星へ物を送る基幹手段にはなりません。
地上側でどれだけ洗練された網を作っても、惑星間の境界だけはロケットを通る必要があります。

しかも惑星間物流は、地上輸送の延長でありつつ、ボトルネックの出方が大きく違います。
地上なら「線路が細い」「ベルトが遅い」「ロボが遠い」が中心ですが、ロケットでは満載待ち、積載設計、降着パッドの受取能力が支配的です。
すでに見てきたように、着地側は一度に1スタックずつ受けるので、送り側で便を作れていても、受け口が細いと簡単に詰まります。

ここで重要なのは、ロケットを「超長距離版の列車」とは見ないことです。
列車は同じ惑星の中で編成を回し続ける思想ですが、ロケットは便ごとの積み方と到着側の処理能力まで含めて設計しないと機能しません。
建材便、補修便、惑星専用資源便のように役割を分け、地上側では降着パッドから先をベルト・列車・ロボのどれで受けるかを先に決めておくと、宇宙物流が急に扱いやすくなります。

比較を一枚にまとめると、使い分けはこう整理できます。

選び分けフローチャート

実運用では、4方式を競合させるというより、どの区間にどれを置くかで決めるのがです。判断順はシンプルで大丈夫です。

1. 目的地が別惑星か

• はい → ロケット
• いいえ → 次へ進む

1. 流したい物が、同じ経路を継続して大量に通るか

• はい → 次へ進む
• いいえ → 物流ロボット

1. 輸送距離が長く、拠点間を結ぶ幹線になるか

• はい → 列車
• いいえ → ベルト

1. 短距離でも品目数が多く、分岐や回り込みが多いか

• はい → 物流ロボット
• いいえ → ベルト

このフローで見ると、役割分担は明快です。
定常大量流はベルト、長距離大量は列車、短距離高柔軟性は物流ロボット、惑星間はロケットという4本柱になります。
実際の設計では、これを単独で使うより、「ロケットで惑星へ到着 → ロボで受け口を整える → 列車で幹線輸送 → ベルトで各工程へ定常供給」という接続にすると、地上物流と宇宙物流が同じ思想でつながります。

よくある失敗と対策

過剰在庫とロケット打ち上げ頻発

初心者で相当多いのが、要求数と便の積み方を同じ発想で決めてしまうことです。
たとえば受け側では少しずつ欲しいのに、送り側で最小積載量を高めにしていると、ロケットはなかなか飛びません。
ところが、いったん条件を満たして飛ぶと今度はまとまった量が一気に到着して、受け側の保管や搬出が飽和します。
結果として「普段は足りないのに、来るときは来すぎる」という、いちばん扱いにくい状態になります。

この症状が厄介なのは、見た目では一応動いていることです。
欠品していた物が急に山ほど届くので、最初は改善したように見えます。
でも実際には、到着波形が荒すぎて下流工程が安定しません。
特に建材や補修資材のような、消費にムラがある品目で起こりできます。

対策はシンプルで、要求数と最小積載量を分離して設計することです。
受け側では「常時これだけ持ちたい在庫量」を決め、送り側では「どれくらい溜まったら飛ばすか」を別に調整します。
さらに、着地側にワンテンポ受け止めるバッファを置いておくと、便の波を吸収しやすくなります。
自分はこの分離を意識するようになってから、ロケット便が“イベント輸送”ではなく、ちゃんとした定期物流として回るようになりました。

惑星指定漏れで届かない

これ、地味に見えて本当に時間を溶かします。
要求自体は入っているのに届かないとき、確率で配送元の惑星指定がずれています。
宇宙プラットフォームまわりの要求は、手動設定だと指定した一惑星からしか満たされないので、品目だけ合っていても配送元が違えば沈黙します。

自分はこの“惑星指定漏れ”で3時間くらい普通に迷いました。
供給ラインもロケット部品も揃っているのに、なぜか便が出ない。
原因を追っていったら、欲しい物はナウヴィス側にあるのに、要求が別惑星を向いていた、というオチです。
率直に言って最初は全然わからなかったです。

防ぎ方は、要求設定をテンプレ化することに尽きます。
毎回ゼロから作ると、惑星だけ抜ける事故が起こりやすい設計です。
ブループリントや自分用テンプレにして、名前や見出しに惑星名を入れておくと一気に減ります。
たとえば「ナウヴィス建材便」「グレバ補修便」のように、用途だけでなく出発元が見た目で判別できる形にしておくと、後から触る自分も他の人も迷いません。

少量要求なのに満載待ちで欠品

少量の補給が欲しいのに、いつまで経っても飛ばない。
これは少量要求と大量便を同じプロファイルで扱っているときの典型的な詰まりです。
前の設計段階で触れた話ですが、運用に入るとこのミスがいちばん表面化できます。

弾薬、修理パック、建設資材の補充みたいに「今すぐ少し欲しい」品目は、満載待ちとの相性が悪いです。
ロケット側が十分集まるまで待つ設計だと、欠品時間だけが伸びます。
物量そのものは大したことがないのに、発車条件のせいで停止している状態です。
ロケット輸送の弱さというより、便の性格分けがされていないのが原因です。

ここでは、少量便プロファイルと大量便プロファイルを分けるのが定石です。
少量便は最小積載量を低めにして便数を増やし、補修・保全・建設再開に必要な物を途切れさせない。
大量便は逆に最小積載量を高めにして便数を抑え、建材や中間材をまとめて流す。
自分はこの2系統を分けてから、欠品の原因調査がずっと楽になりました。
少量物資が切れているなら少量便だけ見ればよく、大量便の都合に引きずられません。

降着パッド飽和と着陸渋滞

着地側で詰まるときは、だいたいカーゴ降着パッドの周辺設計が細いです。
カーゴ降着パッドは一度に1スタック単位で受けるので、到着そのものよりも、その後の搬出が追いつかないと荷下ろしが連鎖的に遅れます。
ロケットは飛んでいるのに、着地後に流れないせいで全体が止まるパターンです。

このときありがちなのが、パッドを1基だけ置いて満足してしまうことです。
少量便なら成立しても、建材や多品目補給が重なると、受け口がすぐ飽和します。
しかも周囲にベルトやロボの待避余地がないと、着陸エリア自体が詰まりやすくなります。
見た目はコンパクトで綺麗でも、実運用では渋滞の原因になりがちです。

対策は3つあります。
まずパッドを増設して受け口を分散すること。
次に、パッド直後の搬出を強くすることです。
ベルトで受けるなら赤や青の幹線に早めに乗せる、ロボで受けるならロボ網をパッド密着で組んで、その先に十分な搬出先を用意する。
このあたりは 『カーゴ降着パッド』 の性質を踏まえると整理がつきます。
さらに、着陸エリアに少し広めの待避スペースを持たせると、荷下ろし直後の滞留で詰まりにくくなります。
パッド周辺は“見た目の省スペース”より“詰まらない余白”のほうが価値があります。

地上側の積み込み資源枯渇

受け側ばかり見ていると見落としやすいのが、送り側サイロに物が集まっていないケースです。
ロケットが発射されないとき、設定ミスだけでなく、そもそも積み込み資源が細くてサイロ前で止まっていることがあります。
特に複数品目を同時に送り始めると、どこか1種類だけ細って便全体が止まる、という形で出やすい特徴があります。

ロケット1便は、貨物だけでなくロケット部品の供給も必要です。
『ロケット部品』 の基準を見ても、サイロ側の供給が細いと便の安定性に直結します。
宇宙物流のトラブルに見えて、実際は地上工場の生産不足や列車供給不足だった、というのはよくあります。
自分の感覚でも、惑星間物流の停止原因は宇宙ではなく地上にあることが多いです。

この対策では、供給ラインを見える化するのが効きます。
回路やランプで「サイロ前の在庫下限」を可視化しておくと、どの品目が先に枯れたかが一目でわかります。
さらに、ロケット用の積み込みに専用列車駅とスタッカーを持たせると、通常工場との取り合いが減って安定します。
サイロは重要度の高い消費先なので、余り物を拾う設計より、最初から優先供給される幹線に置いたほうがトラブルが少ないです。

監視とアラート設定のコツ

宇宙物流は、壊れてから配線を追うと時間がかかります。
なので実運用では、止まる前に気づける信号を作るのを怠ると後で詰まります。
特に見る価値が高いのは、「要求があるのに届いていない」「サイロ前在庫が下限を割っている」「降着パッド周辺で搬出が詰まっている」の3種類です。

ここで有効なのは、完璧な中央監視を目指すことではなく、詰まり方ごとにランプを置くことです。
惑星指定漏れなら要求ブロック単位、積み込み枯渇ならサイロ前、降着パッド飽和なら着陸エリア出口に置く。
異常の発生場所とランプの場所を近づけると、見つけた瞬間に原因へ触れます。
物流ネットワークを使っているなら、ロボ網内の在庫下限も監視対象にしやすい点で優れています。
し、『物流ネットワーク』 の範囲を意識してパッド周辺だけを独立気味に見ると、局所詰まりを切り分けやすくなります。

実際に回していて感じるのは、宇宙物流で怖いのは大事故より無言の停止です。
ロケットが飛ばない、届かない、着いても出ていかない。
この3つは見た目が似ているので、監視がないと毎回ゼロから調査する羽目になります。
便名、惑星名、在庫下限、搬出可否。
この4点が見えるだけで、初心者がハマりやすい設計ミスは潰せます。

Logistic network/ja

wiki.factorio.com

発展編：補給便・建材便・惑星専用便の設計

汎用補給便

中盤以降に安定感を出すなら、まず作っておきたいのが汎用補給便です。
役割ははっきりしていて、弾薬、修理パック、建設ロボのような“常備品”を、各惑星や前線拠点で在庫下限を割ったら薄く補充することです。
一度にたくさん送ることではなく、切らさないことです。

この便は、前のセクションで触れた少量便プロファイルと相性がいいです。
最小積載量は低めにして、満載待ちで止まるより小口で高頻度に飛ぶほうが安定します。
特に修理パックや壁、弾薬みたいな防衛の生命線は、倉庫をパンパンにするより「減ったらすぐ戻る」設計のほうが事故を起こしにくい構成になります。
自分はここをケチって、補給をまとめ便に寄せていた時期がありましたが、前線の欠品が出た瞬間に一気に崩れました。
逆に、緊急補修便として壁・タレット・弾薬・修理パックを少量高頻度で回すようにしてからは、壊滅しかけたラインがそのまま持ち直す場面が何度もありました。
これ、地味に大事なんですよね。

運用のコツは、品目を増やしすぎないことです。
汎用補給便は便利ですが、あれもこれも載せ始めると建材便と役割が混ざって挙動が鈍くなります。
常備品だけに絞ると、欠品時の原因も追いやすいと感じる場面が多くあります。
弾薬が来ないのか、修理パックだけ止まっているのか、建設ロボの補充が遅いのかが見えやすくなります。

惑星側の受け取りも、ロボ網前提だと組みやすく、序盤の安定感が増します。
ロボポートの物流エリアは50x50タイルなので、降着パッド周辺をひとつの小さな補給所としてまとめ、そこから壁沿いの補修拠点や駅前倉庫へ配る形にすると扱いやすくなります。
少量多品目をベルトで全部さばこうとすると配線がうるさくなりがちなので、このタイプはロボット向きです。

建材便

建材便は汎用補給便と分けたほうがうまくいきます。
対象は組立機、インサータ、電柱、ベルト、地下ベルト、分配器のような、工事を始めると急にまとまった数が必要になる品目です。
これを常備品と同じノリで送ると、便の性格が噛み合いません。
建設開始の瞬間は大量に欲しいのに、その後は薄い維持で十分、という波が大きいからです。

ここでは二段構えが際立って強いです。
ひとつは、工事前にまとめて叩き込む大量初回便。
もうひとつは、建設途中の食い潰しや追加工事に備える補充便です。
最初の便で「駅前モジュール1式」「精錬ブロック1基分」「防衛線延伸用1セット」みたいに塊で送り、その後は不足分だけを薄く戻すイメージです。
正直なところ最初は全然わからず、建材も全部下限補充で回していました。
でもそれだと、工事開始時の立ち上がりが遅いんです。
ロボが幽霊を置いているのに肝心の組立機とインサータが届かず、現地で待ちぼうけになります。
定数維持の考え方も相性がいいです。
現地の建材倉庫に「組立機はこのくらい」「インサータはこのくらい」といった基準在庫を持たせることで、増設や修復時に都度大規模な初回便を組まずに済みます。
大量初回便で倉庫を満たし、その後は補充便で水位を保つ運用にすると安定度が増します。

惑星専用便

惑星専用便は、汎用補給便や建材便よりさらに役割を絞った便です。
特定の惑星でしか作りにくい物、あるいはその惑星で受け取る意味が大きい物を、専用レーンとして回します。
燃料、鉱石、中間素材、特産品のリレーはこの分類に入れると整理できます。

この便が必要になる理由は単純で、物流の優先順位を濁らせないためです。
たとえば補給品と特産資源を同じ要求に混ぜると、どちらの遅延なのか見えにくくなります。
専用便にしておけば、「この惑星向け燃料ラインが細い」「この鉱石リレーだけ止まっている」と切り分けできます。
特に惑星ごとの供給元を意識して組む段階では、汎用便に寄せるより専用化したほうがデバッグできます。

受け取り側では、降着パッドの並列化が重要になります。
専用品は1品目あたりの流量が上がりやすいので、パッド1基に全部まとめると周辺搬出が先に限界に来ます。
パッドを並べて受け口を分散し、その外側に列車駅やベルト幹線を置いて吸い出す形が安定です。
惑星内で大量に動かすなら列車、パッド直後の整列ならベルト、近距離の多品目整理ならロボ、という役割分担がはっきりします。

ここで意識したいのが、宇宙側で全部を持ち運ぶより、現地で回せる加工は現地で回すことです。
宇宙プラットフォームは保管も投下も制約があるので、何でも惑星間で往復させるより、専用便は「その惑星に届ける価値が高い物」に絞ったほうが詰まりません。
自分の体感でも、惑星間で細かい中間材まで全部動かす設計は、あとで管理コストが重くなります。
専用便は便利ですが、便利だからこそ対象を絞るのがコツです。

鮮度感のある消耗品や、少量高頻度で欲しい品も、実は惑星専用便に向きます。
たとえば前線惑星向けの弾薬強化版や、現地では作らない補修用資材などです。
汎用補給便に入れてもいいのですが、特定惑星だけ消費が激しいなら専用便に分離したほうが在庫の読みが合います。
前線惑星だけ便の性格が違う、というのはよくあるので、ここを無理に共通化しないほうが運用は楽です。

ブループリント化する単位と共有のコツ

便の設計が固まってきたら、どこをブループリント化するかで運用負荷が大きく変わります。
自分が特におすすめしたいのは、アイテム一覧そのものより、物流の受け口ユニットを先に固定することです。
毎回ゼロから降着パッド周辺を組むと、搬出不足やロボ網不足を何度も再発します。

定番にしやすいのは、「降着パッド周辺駅前ロボ網モジュール」です。
カーゴ降着パッド、パッド直後の搬出、ロボポート、補給用チェスト群、必要なら最寄りの列車駅までをひとつの塊にします。
これを先に共通化しておくと、汎用補給便でも建材便でも惑星専用便でも、受け側の品質が揃います。
マルチで特に効くのはここで、誰が置いても同じように流れる設計にしておくと、他の人が増設しても事故りにくくなります。

宇宙側では、「宇宙プラットフォーム要求テンプレ」も有効です。
常備品の自動要求、建設に使う基本資材、専用便で受ける代表品目をテンプレ化しておくと、新しいプラットフォームや新規惑星ルートの立ち上げが速いです。
宇宙プラットフォームハブには自動リクエストがあり、建設に必要なアイテムを自動で求める運用もできるので、テンプレ側では「何を常備するか」「どこからは手動で切り分けるか」を整理しておくと使いやすくなります。

コミュニティの運用例でも、宇宙プラットフォームの立ち上げをテンプレ化して事故を減らす考え方は強くて、Steam Community の「宇宙プラットフォームのジャンプスタート」を見ても、初動の要求整理と受け口整備を先に固める発想がよくわかります。
実際、この手のテンプレは細かな最適化より効きます。
自分も列車網で同じことをやってきましたが、上手い設計は“1回すごく考える”より“誰が置いても同じ挙動になる”ほうが強いです。

共有のコツとしては、ブループリント名に便の用途を入れると管理しやすく、結果として効率が上がります。
たとえば「補給便受取」「建材便受取」「専用資源便受取」のように分けておくと、惑星側での置き間違いが減ります。
さらに一段進めるなら、壁・タレット・弾薬・修理パック用の緊急補修便モジュールを独立させるのもおすすめです。
前線で必要なのは豪華な拠点ではなく、すぐ立ち上がる補給所なので、この単位で切っておくと復旧が本当に速いです。

まとめと次のアクション

3施設は別物に見えて、発想としては供給側・要求側・中継保管の物流チェストです。
ここを起点に、満載待ち・1スタック受取・惑星別要求を前提にすると、便は少量・大量・緊急で分けたほうが素直に回ります。
自分も最初は全部まとめて詰まらせましたが、便の性格を分けるだけで初回の惑星間補給は安定しました。
まずはナウヴィスでサイロと降着パッドを最小接続し、宇宙プラットフォームで少量要求を作って満載待ちを確認し、最小積載量を触って便を分離し、降着パッド周辺を列車かロボで整理してみてください。
この4手順だけで、「止まる輸送」から「回り続ける補給」に感触が変わります。

この先の発展や惑星ごとの詳しい手引きは、当サイトで順次公開していく予定です。
この記事は単独で完結するように設計してあるため、まずは本稿の手順に従って環境を作ってください。