条件combinatorの使い方と最適化7パターン

条件combinatorは、Factorio の回路ネットワークで「入力が条件を満たしたときだけ指定の信号を出す」判定専用の装置であり、四則演算を担う算術combinatorと役割を分けて使います。
2.0のCombinators 2.0では、複数条件のAND/OR、複数出力、信号状態の可視化、説明文フィールドが入って、1.1時代の攻略情報とは前提から変わりました。
比較演算子は>, <, =, ≥, ≤, ≠の6種で、条件が偽なら出力0になるため、出力値が思った通りにならない場面も設定の理解で整理できます。
SRラッチ、記憶回路、タイマー、列車制御まで自力で組むには、1tick遅延を欠点ではなく動力として扱う発想が要ります。

条件combinatorとは何か：判定専用の『もし〜なら』装置

条件combinatorは、回路ネットワークの中で「計算」ではなく「判定」を担当する装置です。
入力された信号が比較演算子の条件を満たしたときだけ指定した信号を出力し、偽なら0、つまり何も出しません。
足し算や掛け算を任せる算術combinatorと役割が分かれているので、ここを混同しないだけで設計の迷いが減ります。

算術combinatorとの役割分担

初めて条件combinatorを置いたとき、見た目が算術combinatorと似ていて取り違え、足し算したいのに判定回路を延々いじって悩んだことがあります。
あの混乱の原因は単純で、算術が「計算」、条件が「真偽の判定」という別物だと頭に入っていなかったからです。
鉄板の在庫を足し合わせるなら算術combinator、在庫が閾値未満かを見るなら条件combinator、と役割で切り分けると回路の見通しが一気によくなります。

条件combinatorは、回路網の中で唯一といっていい「判断」を担う装置でもあります。
入力を条件と照らし合わせ、真なら次の装置に進ませ、偽ならそこで止める。
この if-then の動きがあるから、単なる配線が自動制御へ変わります。
鉄板が一定数たまったらインサータを止める、という enable 条件を組んだだけで工場の挙動が変わり、ここから回路の沼に入っていきました。

入力・条件・出力の3要素

基本は「入力信号・条件（比較演算子）・出力信号」の3要素だけです。
GUIでは左に比較する信号、中央に演算子としきい値、右に出力する信号と値を置く流れになっていて、まずこの配置を身体で覚えると応用が楽になります。
比較演算子は >, <, =, ≥, ≤, ≠ の6種で、真になったときだけ出力する、という骨格さえ押さえれば、あとは用途ごとに組み替えるだけです。

条件が偽のとき出力は0、つまり何も出さない挙動も、実は扱いやすさの核心です。
余計な信号が流れないので、インサータやランプの enable 条件へそのままつなげやすい。
入力が満たされた瞬間だけ仕事をさせる仕組みは、回路を難しく見せるどころか、むしろ配線レベルの自動化を始める入口になります。

赤線・緑線の入力選択と出力値の決め方

入力は赤線と緑線のどちらを読むか選べます。
両方をつなぐと値が合算されるため、別々の在庫を1つのcombinatorで集計したいのか、片方だけを見て独立に判定したいのかを先に決めるのがコツです。
ここを曖昧にすると、思っていたより早く条件が真になったり、逆にずっと偽のままだったりして、回路全体の意図が崩れます。

出力は、真のときに定数1を返すフラグ運用もできれば、入力カウントをそのまま通す設計にもできます。
前者は「条件を満たしたか」だけ知りたいときに向き、後者は「満たした量」を次の回路へ渡したいときに向きます。
赤線と緑線の選び方、そして出力を1にするか実数値にするかを分けて考えると、条件combinatorはただの判定器ではなく、細かな制御を組み立てる中核として扱えるようになるでしょう。

条件設定の基本：比較演算子と出力の3つの選び方

比較条件は、ただ数を比べるだけではなく、回路全体の分岐をどれだけ素直に書けるかを左右します。
6つの比較演算子を用途で切り分け、出力はフラグにするか値を通すかを先に決めておくと、後段の配線が読みやすくなります。
赤線と緑線を両方読む設定も、在庫集計では強力です。

6つの比較演算子の使い分け

条件combinatorは、>, <, =, ≥, ≤, ≠ の6種を使い分けるだけで、かなり多くの判定を整理できます。
たとえば「閾値以上で発動」なら ≥、「ちょうどその値のとき」なら =、「その値以外」なら ≠ を選ぶだけで、あとから追加の判定器を挟まずに済みます。
比較式を欲張らないことが、回路を軽く見せる近道です。

2.0アップデートで複数条件のAND/ORも扱えるようになったとはいえ、まずは1条件をきれいに書けるかが出発点です。
条件が増えるほど、どこで真になったのかが見えにくくなります。
逆に演算子を正しく選んでおけば、判定そのものが説明文の役割を持つので、後から見ても意図が読み取りやすくなるでしょう。

定数出力（フラグ）と入力カウント出力の違い

出力の選び方は大きく2つあります。
ひとつは 信号I=1 のように定数1だけを出して、ON/OFFのフラグとして使う方法です。
列車制限やインサータ制御のスイッチに向いていて、判定が成立した事実だけを後段へ渡せます。

もうひとつは、入力カウントをそのまま通す方法です。
こちらは在庫値や個数を別回路へ橋渡ししたいときに向いています。
自分も最初は在庫の値をそのまま使いたいのに定数1で出してしまい、表示がずっと1のままで首をひねりました。
出力モードを入力カウントに変えた瞬間に解決して、2択の意味がやっと腹落ちしたのを覚えています。

判定対象の信号と出力フラグを同じにしないのも、地味ですが効きます。
鉄板を見ている回路でも、出力は無関係な I=1 にしておくと、後段が「何を条件に動くか」を読み取りやすくなるからです。
判定と出力を素直に分けたほうが、回路の役割分担がきれいに残ります。

赤線+緑線の合算を使った在庫集計

赤線と緑線の両方をチェックすると、その信号の値は合算されて出ます。
複数の倉庫を別々の線でつないでも、同じ信号なら合計在庫を1回で拾えるので、集計用のcombinatorを何個も並べる必要がありません。
複数チェストの合計を出すのに最初は何段も重ねていた配線が、これを知ってから1個で済むようになり、駅まわりが一気にすっきりしました。

この設定は、単に配線を減らすだけではありません。
集計の入口が1つにまとまると、あとで不足判定や輸送停止の条件を足すときも、どこを見ればいいかが明快になります。
変化させたいのは判定値か、通したい在庫値か。
その切り分けがはっきりしている回路ほど、説明なしでも動きが伝わる回路になるのです。

複数条件とAND/OR：2.0で激変した条件combinator

Combinators 2.0（FFF-384）で条件combinatorは、1条件しか扱えなかった頃の窮屈さから一気に解放されました。
2.0以前は「在庫が少なく、列車が在線中」といった複合判定でも、算術と条件を直列につないで回り道を作る必要があり、回路が長くなりやすかったのです。
複数条件をAND/ORでまとめられるようになったことで、書き方は短く、意図は明確になり、デバッグもしやすくなりました。

1.1までの『1条件の壁』と2.0での解放

2.0以前は、条件combinatorに入れられるのが実質1条件だけでした。
そのため、少し複雑な制御をしようとすると、算術回路で下ごしらえをしてから条件を通す、あるいは条件を複数個直列に並べる、といった組み方になりがちだったのです。
見た目も長くなりますし、どこで判定が落ちたのか追いにくい。
古い攻略記事に1条件前提の回路が多いのも、その制約を前提に工夫していたからでしょう。

2.0ではその壁が外れ、1個のcombinatorの中で複数条件を束ねられるようになりました。
実際、以前は3個ほど直列に並べていた回路が1個に収まったときは、かなり気持ちが良かったです。
古い自作回路を片っ端から整理したくなるのも自然で、発想自体を「1条件1combinator」に縛られない方向へ切り替えるのが、この更新の本質だと思っていいでしょう。

AND条件・OR条件のグループ化のやり方

2.0の肝は、複数条件をAND/ORで組み合わせられる点にあります。
AND条件は全項目が真のときだけ真、OR条件は1つでも真なら真です。
つまり、「在庫が少なく、かつ列車がいるとき」のような複合判定を、ひとつの条件塊としてそのまま表現できるわけです。
制御の意図と回路の形が一致するので、読み返したときの理解速度がまるで違います。

さらに、GUI上で信号の状態が可視化されるようになったのも大きい変化です。
動かない回路を開いて、この条件だけ赤い、つまり成立していない、とすぐ分かるだけで、切り分けの手数が減ります。
自分はこの表示が入ってから、デバッグ時間が体感で半分以下になりました。
なぜ出力が出ないのかをその場で見抜けるのは、複雑な制御ほど効いてきます。

複数出力と説明文フィールドの活用

2.0では複数出力にも対応し、1つのcombinatorから複数の信号を同時に出せるようになりました。
これまでは、似た判定を何度も分けて書いていた場面を、ひとつの回路にまとめやすくなっています。
加えて、全combinatorに説明文、つまりカスタム説明フィールドが追加されたことで、何のための回路かをその場でメモできるのも便利です。
あとから見返したとき、用途が読めるだけで保守性がまったく違います。

こうした仕様変更のおかげで、2.0以降は複合条件を積極的にまとめるほどcombinator数を減らしやすくなりました。
古い回路をそのまま持ち込むより、条件の粒度を見直して再構成したほうが、配線は短くなり、回路図も読みやすくなります。
複数出力と説明文フィールドを合わせて使えば、単なる自動化装置ではなく、意図まで残る設計になるのです。
おすすめです。

ワイルドカードを使いこなす：each / everything / anything

each：信号ごとの個別フィルタ

ワイルドカードは、どの信号をまとめて扱うかを一括で指定する仕組みです。
each・everything・anythingの3種を使い分けると、個々の信号名を書かずに複数信号をまとめて処理でき、汎用回路の組み立てが一気に楽になります。
まずは「全部に同じ条件をかける」のか「信号ごとに別々に見る」のかを分けて考えると、迷いにくいです。

each を入力に使うと、信号ごとに個別判定して、条件を通った信号だけを出力します。
たとえば各鉱石が一定数未満なら、その鉱石だけ補充信号を出す回路が作れます。
普通の条件では全信号がまとめて通って困ったのですが、each条件に切り替えた途端に信号別フィルタとして働き、normalモードとeachモードの違いを体で理解できました。
1信号ずつ扱いたい場面では、この切り替えを意識するだけで事故が減ります。

everything と anything の違い

everything は全入力信号が条件を満たすと真になり、入力が1つも無くても真です。
anything は1つでも条件を満たせば真で、満たす信号が無ければ偽になります。
ここは「全部そろったか」を見るのが everything、「どれか来たか」を見るのが anything と覚えるのがいちばん早いでしょう。

自分も everything と anything を取り違えて、全資源がそろってから動かしたい回路が、どれか1つ入った時点で動いてしまい、駅が暴発したことがあります。
あの手の事故は、条件の意味をうろ覚えにしたまま組むと起きやすい。
結局、「全部=everything、どれか=anything」と紙に書いて貼ってから、ようやく間違えなくなりました。
単語の違いに見えて、実際には回路の発火条件そのものを決める差だと考えると覚えやすいです。

normalモードとeachモードの切り替わり

入力側に each 条件が無いと、回路は normalモードで動きます。
このときは、1つでも条件が真になると全入力信号をそのままパススルーします。
逆に each 条件があると eachモードに切り替わり、各信号を個別に通す挙動になるため、同じワイルドカードでも出力の見え方がまるで変わります。

この2モードの違いを知らないと、「1信号だけ通したいのに全部出てきた」という事故が起きます。
自分も鉱石ごとに個別補充したくて普通に条件を書いたら、全信号が一緒に流れてきて困惑しました。
each条件を入れた瞬間に狙いどおりの信号だけが抜けるようになって、ようやく設計意図と挙動が一致した感覚がありました。
意図に応じて each を入れるか入れないかをはっきり決めることが、ワイルドカード活用の肝です。

実用パターン①：SRラッチと記憶回路で状態を保持する

SRラッチは、setイベントで信号を出し始め、resetイベントが来るまでその状態を保つ回路です。
瞬間的に成立した条件を「記憶」に変えられるので、自動制御ではかなり出番が多い部品になります。
蓄電池の充電量に合わせて予備設備を動かすような場面では、ただの閾値判定よりも、状態を保持できる仕組みが効いてきます。

SRラッチの仕組み

蓄電池の充電が1%以下でバックアップ発電をONし、20%まで回復したらOFFにする二閾値制御は、SRラッチの典型例です。
1%と20%を分ける意味は、境界付近で条件が揺れたときに毎tickのON/OFFを防ぐためにあります。
自分も最初は充電量だけで蒸気発電のインサータを直接切り替えてしまい、閾値ちょうどでチャタリングが起きて燃料を無駄にしました。
set 1%、reset 20%に変えた途端、嘘のように安定します。

出力を入力に戻すフィードバック記憶回路

記憶回路の核は、出力を入力へフィードバック配線することです。
『入力>0なら同じ値を出力』するデサイダーの出力をそのまま入力に戻すと、値が自己保持され続けます。
ここで1tick遅延が入るからこそ、ループが暴走せず、1tickごとに状態を更新できるわけです。
自分は出力を戻しただけで値が増え続けて止まらず、リセットを知らないまま3時間溶かしました。
負パルスで打ち消す方法を覚えてから、ようやく記憶回路を実用的に扱えるようになったのです。

リセットのやり方は2通りあります。
セット条件を偽にして自己保持を切る方法と、保持中の値と同じ大きさの負パルスを入れて打ち消す方法です。
後者は、外部から任意のタイミングでクリアしたいときに向いています。
セットは正の値で立て、リセットは同量の負値で倒す、と決めておくと、複数の記憶回路を並べても破綻しにくく、後から調整もしやすくなります。

バックアップ発電・予備設備の自動制御

バックアップ発電は、この仕組みの使いどころが最もわかりやすい例でしょう。
蓄電池が1%以下になったら予備の蒸気発電を起動し、20%まで戻ったら止めるだけで、境界の揺れに引きずられない安定運用になります。
予備設備は「必要な瞬間に立ち上がり、不要になったら静かに退く」ことが求められるので、SRラッチのような状態保持が相性抜群です。
セットとリセットの正負まで含めて設計しておくと、電力網だけでなく、物流や防衛の待機制御にもそのまま応用できます。

実用パターン②：タイマー・カウンタ・パルス生成

時間制御を組むなら、まず押さえたいのがクロック、カウンタ、パルス生成の3つです。
いずれも条件combinatorと記憶の組み合わせで作れて、定期通知や周期動作の土台になります。
仕組みは単純でも、リセットの置き方とパルス幅を外すとすぐ破綻するので、最初に回路の役割を分けて考えるのが近道です。

自己リセットクロックの作り方

自己リセットクロックは、1個のデサイダーで組めます。
非ゼロ条件のあいだ値を毎tick加算し続け、目標値に届いたら条件を偽にして止めるだけです。
60tickで1秒なので、60カウントに合わせれば1秒周期のクロックになり、在庫通知や炉の巡回確認のような「一定間隔で見たい情報」を安定して拾えるようになります。

この手の回路でつまずきやすいのは、増え続ける値をどこで止めるかを先に決めていないことです。
1分ごとに在庫を知らせたくて組んだ回路でも、リセット条件を入れ忘れると値が際限なく増え続け、周期になりませんでした。
60の倍数で=パルスを出す形に直してからは、ようやく安定した通知になり、クロックは「増やす回路」ではなく「止め方まで含めて設計する回路」だと実感しました。

カウンタとリセット

カウンタは、入力をそのまま出力に戻す構成で作ります。
デサイダーを入力→出力に設定し、その出力を入力へフィードバックすると、パルスが来るたびに値が加算されます。
ロケット打ち上げ回数や搬入回数のように、イベントの総数を数える用途に向いていて、時間ではなく回数を追いたい場面で役立ちます。

ただし、数える対象が1tick以上立ちっぱなしになると、1回の入力が複数回として扱われます。
搬入回数を数えるカウンタでこれをやらかし、パルスが1回のはずなのに多重カウントされたことがありました。
そこに1tickへ絞る処理を挟んでからは正確に数えられるようになり、パルス幅そのものがカウンタの精度を左右すると身にしみました。
リセット機構は、目標値に達したらリセット信号を出し、定数combinatorの値で0へ戻す形が基本です。
クロックもカウンタも、最初にリセット設計を決めておくと後から回路を増やしても崩れにくくなります。

パルス生成と一定間隔の点滅・通知

パルス生成は、クロックの出力に「=」条件のデサイダーを足して作ります。
周期のうち指定した1点だけ信号を通すので、出力は単発パルスになります。
点滅ランプの制御、一定間隔の通知、定期的なバッチ起動まで使い道は広く、連続信号をそのまま使うよりも扱いやすいです。

ここで効いてくるのが、クロックとパルスを分けて考える発想です。
クロックは周期そのものを作り、パルスはその中の1回だけを切り出します。
周期通知を安定させたいなら、まずクロックでリズムを作り、そのあとで=条件を重ねて1tickの信号に整えると、後段の回路が暴れません。
点滅や定期通知が安定するだけでなく、複数の回路へ同じタイミングを配れるようになるので、時間制御の基礎として使いやすい構成です。

実用パターン③：列車・インサータ制御と回路の最適化

列車駅の制御は、条件combinatorの使いどころの中でも特に実感しやすい分野です。
駅に L 信号を入れて列車制限を動的に変えると、在庫が無い積込駅や満杯の荷下ろし駅を自動で止められます。
駅そのものを有効・無効で切り替えるより、向かっている列車の行き場を失わせにくいのが扱いやすい理由です。

在庫連動の列車制限

在庫が閾値未満のときに L=1 を出して駅を開き、足りたら L=0 に戻して列車を呼ばない。
この形が定番です。
倉庫群をcombinatorにつないで必要量を見れば、積込側は「材料があるときだけ列車を受け入れる」、荷下ろし側は「置き場が空いているときだけ受け入れる」という動きにできます。
駅を丸ごと消す運用だと、発車済みの列車や接近中の列車が詰まりやすいですが、train limit 0/1 の切り替えなら待機先を残したまま制御できるので事故が減ります。

インサータの enable/disable 条件設定

インサータも同じ発想で、enable/disable 条件に条件combinatorの出力を直結します。
たとえば出力チェストの在庫が一定以下のときだけ動かせば、必要な分だけ流し込み、過剰生産を抑えられます。
ライン全体を止めるのではなく、末端の搬送だけ絞るので、上流の生産を保ちながら下流の滞留を防げるのが利点です。
現場感としても、チェストが埋まるたびに設備全体を止めるより、インサータ単位で細かく制御したほうが調整しやすいでしょう。

1tick遅延の累積とcombinator数を抑えた最適化

最適化でまず意識したいのが1tick遅延です。
combinatorは前tickの入力で計算し、出力は次tickに反映されるため、直列に何個もつなぐと遅延が積み上がります。
多段判定で「1tick足りずに誤動作」するのはここが原因で、駅の開閉やインサータ制御では特に目立ちます。
Factorio 2.0 の複数条件を使って段数を減らせば、判定の安定性が上がります。

UPSの面でも、Factorioは60tick/秒で動き、変化した回路網だけ再計算されます。
だからこそ、毎tick変動するクロック回路を増やしすぎると負荷が跳ね上がるのです。
メガベース手前で回路を増やしすぎてUPSが落ち始め、原因を追うとクロック回路が大量に置かれていたことがありました。
必要数まで減らし、複数条件で段数を圧縮したら、UPSが目に見えて戻りました。
回路は増やすほど賢くなるわけではなく、必要な場所だけ動かす設計こそが長期運用ではおすすめです。