Логістика

【Factorio】Getting Started with City Block Expansion | Size and Signals

When your main bus grows so thick you can no longer see where to add new production, it's time to consider switching to city blocks in Factorio. This guide walks intermediate players through the concrete steps to transition to a 'manageable and easily expandable' factory in vanilla 2.0 and Space Age environments, with a focus on practical implementation rather than theoretical ideals.

Логістика

【Factorio】Getting Started with City Block Expansion | Size and Signals

When your main bus grows so thick you can no longer see where to add new production, it's time to consider switching to city blocks in Factorio. This guide walks intermediate players through the concrete steps to transition to a "manageable and easily expandable" factory in vanilla 2.0 and Space Age environments, with a focus on practical implementation rather than theoretical ideals.

The key point is not to build an enormous railway network all at once. Instead, lock in four core items first—block size, train length, traffic direction, and internal block logistics—then get one minimum viable block running cleanly before replicating it further. This approach proved far more resilient to breakdown than any shortcut I tried.

I spent three hours stuck debugging intersection lockups and insufficient stacker space when running over 100 stations. City blocks aren't a universal fix for UPS, but when you lock down the rules before building, expansion becomes remarkably stable and straightforward.

Scope and Version Context for This Article

This guide assumes Factorio vanilla v2.0 stable (2.0.73 equivalent) and Space Age DLC installed. The focus stays on vanilla city block design fundamentals, with Space Age-specific options and differences addressed separately. Splitting these cleanly prevents "DLC mechanics mixed with vanilla basics" confusion—a mistake I made myself when trying to absorb new features all at once.

By "city blocks" here, I mean the design pattern of placing production modules inside regular rail grids for incremental expansion. The focus is manageability and extensibility, not bleeding-edge UPS optimisation. Mega bases may use similar layouts, but UPS-first specialised design is a different beast entirely. Conflating the two leads to the "I expected it lighter but it's not" trap many fall into.

All dimensional discussion assumes map chunks are 32×32 tiles, as per . Aligning grid and block edges to multiples of 32 dramatically simplifies blueprint copy-paste and one-column extensions. The prevalence of 96×96 examples isn't accidental—that size naturally plays well with chunk boundaries.

Quick Terminology Primer

is a thick belt trunk for resource distribution. It's very strong from early to mid-game and remains a standard stepping stone before transitioning to train-centric city blocks at larger scales.

UPS (Updates Per Second) indicates how many game ticks fire per second. Factorio targets 60; when it drops, you feel it. When I mention UPS in this article, I'm discussing computational load, not vague "feels sluggish" impressions.

Chain signal (called in Japanese resources) is used at intersection entrances, allowing trains to enter only when the exit is clear. City blocks tend to spawn many intersections, so familiarity with chain signals pays off.

→ See also

explains chunk layout. covers DLC scope. This article pulls only necessary foundations from Space Age and preserves vanilla principles.

Map structure wiki.factorio.com

What Are City Blocks in Factorio?

Core Elements of City Blocks

A Factorio city block is a regular rail grid where each grid cell becomes an independent production zone. Instead of stretching one long trunk, you split the factory by function—smelting blocks, circuit blocks, science blocks—and duplicate cells as needed. I think of it less as the ultimate megabase blueprint and more as human-friendly expansion accounting. You can see exactly where to add what, making decisions much faster.

The foundation is rail, intersections, stations, signals, and blueprints built for replication. Because exists, once one block runs cleanly, you paste the same shape repeatedly. That's the magic moment—expansion stops being "rethink the whole layout" and becomes "add another identical unit." In main bus days, even adding a single new resource line sometimes ate half a day. With blocks, it's "need more copper? Add a copper block."

A common approach aligns block dimensions to chunks. Since shows the map divides into 32×32 tile chunks, 96×96 blocks (a 3×3 chunk area) are a textbook example. But there's no single answer. 64-tile blocks exist, as do 100×100 layouts. The best size depends on how many stations you want, how you move trains, and whether you use belts, bots, or mixed logistics inside.

Rail design quality—especially intersections—heavily influences overall stability. The pattern is textbook: place signals on the right side of travel direction, use chain signals at intersection entrances, normal signals at exits (exactly as describes). City blocks spawn intersections like rabbits, so sloppy signals break the entire web. I once crammed trains incorrectly through intersections for hours before realising signal placement alone was the culprit.

Blueprint wiki.factorio.com

City Blocks vs. Main Bus: Strengths and Trade-offs

The biggest difference is expansion philosophy. Main bus stretches a belt trunk and adds resource lanes sideways—very strong early and mid-game, visually transparent. Once factories balloon, belt count explodes and inserting new lines becomes clunky.

City blocks flip this: scale by blueprint duplication, not trunk extension. Short on copper? Add another copper block. Short on circuits? Replicate a circuit block. This makes expansion units crystal clear, perfect for shared factories. You see which zone does what; finding breakage is faster. Managerial overhead drops noticeably.

But main bus isn't "old" and city blocks "new." My sense is main bus for early/mid-game, city blocks when management burden peaks, then scale. Jump straight to massive rail grids and rail design itself becomes the bottleneck. Stick with main bus too long and the trunk chokes. Each stage suits different designs—pick what fits.

Hybrid operation is surprisingly strong, too. Keep main bus for mid-tier materials, switch only heavy or recurring resources to train blocks. No all-or-nothing rebuild required. Honestly, the largest factories I see aren't pure-anything. They fold wherever transition makes operational sense.

A quick comparison:

AspectMain BusCity BlocksHybridUPS-Focused
Primary UseEarly/mid-game standard expansionLarge-scale manageable expansionGradual transitionExtreme computation reduction
StrengthIntuitive, easy to startModular, straightforward replicationFlexible migrationProcessing efficiency
WeaknessBelt count balloonsRail design is hard; intersection thrashingRule drift under mixed logicVery high design difficulty
TransportMostly beltsTrains + block-internal logisticsBelts + trains bothDistance/computation minimisation
Beginner FitHighMediumMediumLow
UPS SuitabilityMediumMedium–LowMediumHigh potential

City blocks shine at modularity and extensibility, not raw speed. See for deeper framework comparison. City blocks are precisely the "manageable and expandable" end of the spectrum.

note.com

City Blocks and UPS: A Common Misconception

Here's a frequent pitfall: city blocks ≠ UPS-friendly by default. That needs sharp separation. City blocks are an operational pattern for expansion and management, not an optimisation doctrine. Larger rail networks mean more intersections, more pathfinding, more waiting. Sloppy design gets heavier, not lighter.

Dense grids with tiny intersections look orderly but often hurt UPS. Frequent rerouting and multi-intersection waiting queues thicken the computational load. Forums and Reddit consistently echo: "big city blocks are convenient, but not the lightest." My playthroughs back this—the moment station and intersection count rose, network stability got pricklier even though the layout looked cleaner.

💡 Tip

For UPS within city blocks, focus less on grid design itself and more on "don't over-intersect," "cut unnecessary long hauls," and "don't fragment one product across too many cells."

Real UPS-cutting design pulls in opposite directions: shrink travel distance, consolidate processes, slash intermediate transport, prune intersections. City blocks can do some of this, but grid regularity often forces slight detours just to keep the format clean. It's kinder to humans than to the processor.

So don't judge city blocks by UPS alone. Speed of expansion logic, maintainability, role separation, multi-player clarity—these add real value. I keep city blocks in big factories not because they're fastest, but because expansions don't fracture. The larger your factory, the more player cognitive relief matters. That's worth serious consideration.

Four Decisions Before You Build: Size, Train Length, Direction, Logistics

Choosing Block Size

Block size is hardest to change later. Intersections, stations, power, wiring, internal layout all cascade from it. Fuzzy sizing early means dimension drift with every expansion. The solution: use 32-tile chunk multiples as shown in . Multiples of 32 align with radar visibility, blueprint handling, and long-term readability. Future-you will thank present-you for the consistency.

96×96 tiles is genuinely practical. It's exactly 3×3 chunks, and demonstrate this size's workflow. I gravitate toward this range myself because it's neither too cramped nor oversized, making single-product iteration straightforward. Some designs appear 128×128 but use 96×96 effective space after deducting shared infrastructure.

100×100 is also very common—prioritising human intuition over chunk alignment. Conversely, 64-tile blocks suit small/experimental bases but quickly feel boxed in. Stations and logistics get tight, tempting awkward overflow. My experience: starting with 64 "feels compact" until you're scrambling for road space, then the block-replication elegance collapses.

The real question: how many stations fit inside, and can you close the transformation loop? Multi-input recipes consume station space and internal routing fast. Underestimate this and you're redesigning mid-block repeatedly.

Train length deserves its own weight here. Use one length everywhere. Whether 1-2 or 1-4, mix consistency more than elegance. Every deviation breaks station dimensions, stacker sizing, and branch logic. A single misaligned composition kills the regularity on which city blocks rely.

Note: For exact tile lengths and platform dimensions, verify via official reference data. The examples here (1-4 with 96×96) stem from personal experience; apply these concepts to your confirmed measurements.

Traffic Direction: Left-Side or Right-Side?

Settle on left or right traffic before spawning blocks. Either works, but mixing them mid-project means flipped intersections and stations everywhere—costly retrofit.

I favour left-side traffic for a practical reason: Factorio presumes signals and stations on the right of travel direction. Left-side running lets me cram them inward, keeping the outer boundary intact. Stations cluster neatly inside the loop. It's workable rather than elegant, but that works-first mentality fits the game better. 96×96 examples favour left-side too; my own layouts stabilised visibly after switching.

Neither is dogma. Right-side works if you're comfortable with it. The critical thing is unified consistency: intersections, stations, and main lines all follow the same rule and replicate seamlessly. Confused about the choice? Build one intersection with a T-branch and station entrance, then step back. The comfortable side becomes clear.

Internal Block Logistics: Belt / Robot / Sub-Bus

Decide how goods move inside blocks before you begin building. Changing this per block ruins the whole format. Three main options: belt, logistics robot, sub-bus.

Belts are most transparent. gives solid data: yellow = 15 items/sec, red = 30, blue = 45. If one blue line suffices or two are needed, you can back-calculate station count and unload lanes. Steady high-volume items (plates, circuits) thread onto belts cleanly with visible bottleneck detection.

Logistics robots simplify wiring dramatically and suit odd-shaped recipes or many small items. However, my experience: robots are convenient until you deploy them everywhere, then power and density management gets invisible. Within a closed block they're manageable; spread freely and you lose sight of where it's choking.

A sub-bus inside the block—short internal main bus—sits between belt and bot in both effort and visibility. Multiple items flow short distances; not as sight-transparent as belts, not as black-box as robots. I find this works beautifully for 2–4 intermediate materials. In fact, when I was struggling with everything-direct-to-assembly setups, switching to internal sub-buses untangled things instantly, multiple times.

The mental model is straightforward: high-throughput short-distance = belt; low-volume many-types = robot; bundled mid-distance = sub-bus. City block usability hinges on block internals matching the external template. Replicating a block whose innards shift every time kills the whole advantage.

Belt transport system wiki.factorio.com

Expanding with City Blocks: Workflow

Lay Grid Structure Before Production

Staged migration beats full overhaul. Keep the old factory humming while building new zones. If you rebuild everything at once, you run dry during construction and the old facility grinds to a halt—I learned this the hard way, slowing research and ammunition refill mid-build.

Start with empty block templates, not production lines. Place blank zones, intersections, and standard stations. No contents needed yet. Pre-structuring lets you decide a block's purpose later without struggling with placement. Maps divide into chunks, so gridding early keeps expansion sightlines clear.

I keep these shells—intersection, empty block, standard station—as one replicable blueprint. Locking down station orientation and input/output position matters. Blocks are meaningless if you paste one successfully but fight station alignment every time. Once I standardised the "empty + intersection + station" template, deployment speed jumped dramatically.

and the construction guide system let you carry empty, standard-station, and completed-inside variants as a suite. Pull the right version per expansion phase; confusion drops.

Migrate High-Demand Goods First

When blocks are ready, move things that bloat main bus and hit everywhere else. Classic candidates: smelted plates, circuits. These touch nearly everything, so leaving them on main bus forces endless trunk tweaks.

A sane sequence: stand up one new block (smelting or green circuits), confirm stable output, then gradually redirect consumers. Don't nuke the old factory first—layer in new supply, then switch feeds. If migration falters, old lines still feed the chain.

Circuits especially ripple everywhere (red, blue, intermediate assemblies). Carving them out clears main bus fast. Smelting similarly unclogs the spine. Once these are block-sourced, the "why is the trunk getting wider" problem evaporates.

Complete One Block → Replicate → Scale Out

Perfecting one block beats sketching ten. Once one runs stable (stations, internals, power, signals all solid), then you clone. Bugs stay local: intersection thrashing? Station hogging? Thin belt? Single-block isolation makes diagnosis instant. Spawn multiple half-finished blocks and you can't tell where rot began. I once pasted a broken station design across six blocks—soul-crushing untangling.

The finished block becomes your blueprint. Paste it using the pre-built empty+intersection+station skeleton to keep framework rules unbroken. Swap interiors; the skeleton holds. This is the moment when "designing from scratch" becomes "copy-paste," and factory expansion lightens dramatically.

💡 Tip

Block one prioritises correct station placement, input/output positions, and unbroken internal flow over raw production volume. Frame it right, and copying becomes smooth.

Keep the Old Factory as a Buffer

Don't demolish the old main bus immediately. This is crucial. It acts as a supply shock absorber. New blocks often look good until real demand hits, then hidden shortfalls emerge. If the old factory is gone, construction stutters while you fix it.

Running both in parallel is the safety net. One dips; the other covers. Especially for building materials, ammo, defences, research—anything where shortage cascades. I've rushed retirement of old lines and watched new networks reveal their brittleness mid-patch.

Keep the old factory until new blocks hit steady supply. Retire lanes gradually by role, not wholesale. It's more like building a replacement factory beside the old one than moving houses. That mindset makes migration far more resilient.

Rail, Stations, and Signals Fundamentals

Signals and Blocks: The Basics

Signal placement breaks before tracks do in city blocks. Sloppy signalling across many intersections looks fine until trains start hanging everywhere. The breakthrough for me was: **decide where to stop before laying track.** That locked in signal discipline.

Core rule: place signals on the right side of travel direction. One-way segments presume this. Breaking it means "doesn't go where expected." Block layouts standardise direction anyway, so signals can sit mechanically correct.

The next big idea is fine-grained block separation. Split between intersections into bite-sized sections so follow-up trains advance after small progress. Don't chunk the whole span as one block; the lead train goes far before the follower moves at all, wasting space. Tighter sections let the queue compress.

Never stop trains inside intersections. If one halts mid-crossing, crossflow locks, exits jam, entire directions freeze. I botched this once, mixing in normal signals at the wrong spot. The fix—flipping entry to chain signal—instantly smoothed flow. This one principle is deceptively important.

実際の配置イメージとしては、分岐や合流で線路が競合し始める直前に連動式を置き、競合区間を抜けた直後に通常信号を置きます。
交差点の中そのものに通常信号を置いて細かくブロック化したくなる場面もありますが、そこは我慢したほうが詰まりにくいです。
交差点内に閉塞を増やすと、一見すると複数列車が入りやすそうに見えて、実際には「途中で止まれる場所」が増えるだけになりがちです。

Tutorial: Train signals wiki.factorio.com

Intersection Pattern: Chain Entry / Normal Exit

The canonical intersection is chain signal at entry, normal signal at exit. Why? Entry checks if the entire path through clears before entering. Exit signals only once that far side block opens, so trains advance smoothly.

Visually: branch/merge points warrant a chain before lines tangle; clear the junction, place a normal to unblock the onramp. Temptation hits to scatter normal signals throughout an intersection for granularity, but resist—you're just creating internal stopping zones. Intersections are meant to be passed, not parked in. I learned this by trial and spectacular error.

This design pairs with one more: main routes should prefer straight-through, with branches curving away. Don't grid-intersect at uniform density. Thicken main flow, thin branch networks. When every axis intersects equally, every train stops constantly. Bias toward throughput on primary arteries; let lesser flows detour. Counterintuitively, fewer crossings beat more routing choice. The network feels lighter when things flow, not when they could take many paths.

💡 Tip

Lost on intersection trouble? Default to chain/normal, skip internal complexity, and unify. If still congested, ask: "Do this many trains need this intersection?" Often the design sends too much through one choke. Rerouting beats redesign.

www.jias.jp

Stations and Stackers: Don't Block the Main Line

Even perfect signals jam if stations clog the trunk. City blocks often back up at platform entries—waiting trains creep into the grid. Multiple trains targeting one dock overflow past the intersection.

Stackers—waiting areas—prevent this. They're simple: let trains queue off the main line until the dock frees. Several trains can queue; the trunk stays open. I underestimated stackers for ages, but "where to park waiting trains" matters more than intersection elegance. The moment I started sizing stackers with the same discipline as stations, gridlock dropped sharply.

The method: size stackers and platforms to the train length; everything—approach, dock, exit—fits one composition. If the platform takes a 1-4 but the stacker is tiny, overspill vehicles block merges or the trunk. Everything must nest cleanly, or the refuge becomes a leak.

Next, separate arrival and departure flows from the main line. Don't let entry-approach slowdowns ripple through active traffic. Ideally: main line → branch to stacker → queue at dock → exit ramp → rejoin. Two different lanes: "main" stays flowing; "station" handles waiting and manoeuvring. When shared cargo needs to go somewhere, multiple people can tinker with stations without collapsing the trunk. Templating stations with built-in stacker geometry pays dividends.

From what I've seen, congestion blamed on intersections was really station-queue overflow. Trains don't park in intersections; they park waiting to dock. Solve stacker sizing, and trunk flow improves noticeably.

Layout Design Inside Blocks

One Product Per Block

Simplest: one block, one output product. Assembly-line blocks for green circuits, smelting blocks for plates, etc. Clear role, simple replication, easy diagnosis.

Strength: cargo routes are unmixed. Input docks feed stock; output docks ship finished goods. You see at a glance what flows where. Multiplayer clarity pays. Whoever adds stations knows the block's purpose; rules don't erode.

Downside: easily spirals into many blocks. Fragmenting intermediate materials multiplies trains and station sprawl. I started aggressive single-product splitting and ended up shuffling more cargo than assembling. Balance clarity against transport overhead. Separate high-demand items; bundle lower-volume ones upstream.

Multiple Inputs, Single Output

A close variant: many component feeders converge into one finished product. Assemble complexity benefits from this; plug inputs at the perimeter, assembly loops centrally, product pours out. Then swap internals while keeping input/output stable.

This works well for high-complexity items. Many materials → one craft chain → clean exit. Rethink the recipe? Tinker internally without touching the external skeleton.

The catch: inputs × consumption rate ≠ dock count is obvious. Calculate consumption as belt-line equivalents. A heavy-demand material running on blue belt likely needs a dedicated dock; light items can share. Size docks to belt throughput, not item count. reference data (15/30/45 items per second) lets you back-solve dock count.

This pattern pairs well with robots—mixed inputs, ropey internals—but beware scaling. Robots are convenient for prototyping; volume production leans belt-stable. My practice: bot it fast in R&D, belt it when scaling. Salvages time and headache.

Sub-Bus Internal Design

Want flexibility? Stash a tiny main-bus inside. Feeds from the perimeter, stages materials on internal belts, branches to assembly as needed. It sounds meta—city blocks with inner buses—but operationally it's robust.

Gains: easy recipe tweaks and mid-life upgrades. Pure 1-product blocks are sharp until you need a second production line or want to add a new craft. Internal sub-buses let you splice new feed lanes or assembly without demolishing walls. A green-circuit block I was scaling? Added copper-wire production in-place via spare sub-bus lanes and sidestep full redesign.

It eats more internal space but buys flexibility. Blocks you might upgrade later or experiments that may expand suit this. Once you've locked down a block's final form, compress it if you want; while growing, sub-bus cushion is worth the footprint.

💡 Tip

Unsure on internals? Perimeter = docks and trunk line; centre = crafting; middle = sub-bus glue. Clean separation: docks stay put, guts swap as needed.

Station Count and Train Length Alignment

How many docks? Depends on input types, throughput, and train length. Don't guess.

Process: compute consumption in belt equivalents. "This needs yellow belts worth" or "blue-belt scale." Gauge if one dock buffers it or many are required. Then scale docks to your fixed train length and platform footprint.

Train length locks dimensions everywhere. Longer trains need bigger stackers, longer platforms, deeper branch approach. Shorter trains fit tighter but multiply frequency. Reconcile dock count with total block footprint before building, or stations won't nestle and you rebuild wholesale.

Front-load this math. Blocking out dock and stacker space before interior design prevents disasters. I've designed perfect production insides, then discovered no room for the required stations. Wholesale reconstruction sucks.

Common Pitfalls and Fixes

Beginners hit the same walls. City blocks look tidy, so early they seem golden. Hit real load, and station, stacker, merge, and train-length consistency crumble. Designs fracture fast.

Block Too Small → Main Line Blockage

Oversized ambition, undersized blocks. Stations and stackers don't fit; trains queue onto the grid. One ore dock feeds a plant that gulps faster than wagons unload; trunk gets strangled. Design looks compact; operation strangles.

Fix: size for the waiting queue, not just the dock. Add the train length, add approach distance, add slack. Everything must nest. Front-load buffer space. I watched my "efficient" 64-tile blocks become hamstrung gridlock until I added stacker reach. Rebuilding wasn't fun.

Train Length Drifts Mid-Project

Started with 1-2 composition? Later switched to 1-4 because throughput? Now stackers, platforms, merge distances all mismatch. Trains don't fit where they used to; intersections feel broken.

Prevention: commit to one length from day one. Write it down. Templated stations, stackers, and grid spacing all lock to that number. Multiplayer? Announce it openly. One person sneaking in a 2-4 when the rest run 1-2 breaks the whole spine.

Over-Blocifying Everything

The urge: make every item a block. Gorgeous grid, right? Reality: low-demand goods don't justify a station each. You end up with tons of docks and thin traffic. Transport overhead balloons past assembly overhead.

Sensible: migrate high-demand early; leave low-demand on main bus or old sub-bus longer. Hybrid operation isn't failure; it's realism. Cull what matters; leave light stuff. Mixed designs actually run smoother at scale. I tried "all blocks" once. Felt pretty, operated bloated.

Intersections Multiplied Without Restraint

Dense grids seem stronger. Every axis crossed, theoretically more routing. In practice: trains stop constantly. Paths tangle. Instruction thrashing worsens not better.

Approach: straight-through > many choices. Main lanes should feel direct. Branches shunt aside. Fewer intersections, better flow. Design for throughput, not connectivity.

💡 Tip

Diagnosing gridlock? Before tweaking intersections, ask: "Is too much traffic forced through one crossing?" Re-route demand, not redesign the intersection.

Misunderstanding City Blocks = UPS-Strong

A pervasive myth. City blocks are operationally tidy, not computationally light. Rail networks grow heavy with intersections and path searches. Sloppy block designs are heavier, not lighter.

Real UPS work: cut intersections, shrink distances, drop intermediate steps, and choke pathfinding. City blocks can contribute but aren't automatic. Some designs benefit from pure belt efficiency or hybrid shortcuts that city blocks can't express.

Judge city blocks on manageability, not speed. Operational clarity, expansion confidence, multi-player coherence—these are the real wins. UPS? Bonus if you're disciplined; not guaranteed.

City Blocks in Space Age and v2.0 Context

Space Age and 2.0 didn't invalidate city block fundamentals. Train signal rules, composition consistency, and replicability still matter hugely. Chain entry, normal exit, unified length—these still sing.

That said, 2.0 opened options that make "city blocks = only way" less universally true. Maps with favourable terrain may not need grids. Small factories thrive with fatter buses. Multiplayer scales it: many hands? Grids prevent chaos. Few hands? Looser patterns work.

Don't overfit grids everywhere. Ask: Do I need regularity here? High-demand megafactory? Absolutely grid it. Modular base for a friend group? Grid it. Small-ish solo self-sufficiency? Maybe belt-focus instead.

New mechanics (high-quality production, new recipes) alter layout pressure. Hard to claim today's optimal patterns when the meta is still settling. Stick to 1.1 fundamentals, test new additions incrementally. Real-world observation beats theory.

Takeaway and Actionable Next Steps

City blocks aren't a total rebuild—they're an expansion-management discipline. Lock in train length, block size, traffic direction, and internal logistics up front. Build one solid block, replicate it. That replicability, kept sacred, is the whole point.

My top-level workflow:

  • Fix train length; template empty block, intersections, and standard dock as one blueprint suite
  • Migrate one supply line (smelting, circuits, plastic) to blocks; leave old sources alive as buffer
  • Verify signals against ; if intersections jam, isolate the signal mistake

Don't try to change everything at once. Pick one rule, execute one block, grow it. That pace is stable. I've seen full rewrites collapse and incremental builds thrive. Same designer, different discipline.


article.share

R

RinSeo

Factorio 2,000時間超。100駅以上の列車ネットワーク運用実績と Death World マラソンクリアの経験から、物流・防衛の実践ノウハウをお届けします。