ラダー図の暗黙ルール｜二重コイル禁止・OUTとSETの混在など先輩が教えてくれない作法

ラダーは「動けばいい」では終わらない

ラダーの文法を覚えて、装置が思い通りに動くようになった——ここまでは、マニュアルとネットの情報だけでたどり着けます。問題はその先です。あなたが書いたラダーは、5年後・10年後に別の誰かが読みます。設備トラブルで夜中に呼び出された保全担当かもしれないし、改造工事を任された後任者かもしれない。そして高い確率で、その「別の誰か」には数年後の自分自身も含まれます。

ラダー図は動かすためのプログラムであると同時に、他人（未来の自分）に設備の動きを説明するドキュメントでもあります。ところが、メーカーのマニュアルに書いてあるのは命令の文法だけで、「読みやすいラダーの書き方」はどこにも書いてありません。現場の先輩から口伝えで教わるか、怒られながら覚えるのが実情です。

この記事では、多くの現場で共有されている「ラダーの暗黙ルール」を6つ整理します。二重コイルのようにPLCの動作仕様に根ざした禁止事項もあれば、規格でも仕様でもない純粋な設計作法もあります。どちらなのかを区別しながら読んでください。

ルール1：二重コイル禁止 — 後に書いた回路が勝つ

まずはPLCの動作仕様に直結する、最も重要なルールから。同じデバイスに対してOUT命令を2か所以上書いてはいけません。いわゆる「二重コイル」です。

なぜダメなのか。PLCのスキャンは上から下・左から右の順に演算されます。同じY10に対するOUTがプログラム中に2つあると、先に演算された結果は後の回路の演算結果で上書きされ、実際の出力にはスキャン順で後の回路の結果だけが反映されます（後勝ち）。文法エラーにはならず、PLCは平然と動き続けるのがタチの悪いところです。

二重コイルがあると、こんな不可解な症状が出ます。

モニタ上では前段のOUT条件が成立してコイルがONに見えるのに、実出力はOFFのまま（後段の条件が不成立で上書きされている）
片方の回路だけデバッグしていると正常に見えるが、もう片方の条件が変わった瞬間に挙動が変わる
改造で回路を追加したら、まったく触っていないはずの既存動作が壊れる

「原因不明の動作」を追いかけて数時間溶かした末に二重コイルを見つける、というのは若手の通過儀礼のような失敗です。デバイス使用一覧でコイル使用箇所を検索すれば一発で見つかるので、動作がおかしいときは真っ先に疑ってください。

では、離れた2つの条件で同じ出力を動かしたいときはどうするか。定石は2つです。

条件をORで束ねて、OUTは1か所にまとめる：出力条件が一望できるので、後から読む人にも優しい基本形
中継の内部リレー（M）で分ける：条件AでM100、条件BでM101をそれぞれONし、「M100 OR M101 → OUT Y10」と最後に1か所で束ねる。条件が複雑で1行に収まらないときに有効

どちらにしても「実出力へのOUTは1つのデバイスにつき1か所」という原則は崩しません。

ルール2：OUTとSET/RSTを同じデバイスで混在させない

二重コイルの親戚として、同じデバイスにOUTとSET/RSTを混ぜて使うのも避けたい書き方です。OUTは条件が成立している間だけONする命令、SET・RSTは一度ONしたら明示的にリセットするまで状態を保持する命令。つまり「条件追従型」と「状態保持型」という、思想の異なる2つの書き方です。

この2つを同じデバイスに混ぜると、そのデバイスがいまONなのは「どこかの条件が成立中だから」なのか「過去にSETされたまま」なのか、モニタを見ただけでは判別できなくなります。しかもOUTはスキャンごとに演算結果を書き込むため、SETで保持したはずの状態がOUT側の条件不成立で消される、といった追いにくい干渉も起こります。1つのデバイスは、OUTで動かすならOUTだけ、SET/RSTで動かすならSET/RSTだけ。どちらの流儀で管理されているかを統一するのが作法です。

そもそもOUTとSET/RSTをどう使い分けるべきかは、OUT・SET・RSTの使い分けで詳しく解説しています。「保持が必要ならSETか？それとも自己保持回路か？」という定番の悩みどころは、自己保持回路の基本形とあわせて読むと整理できます。

ルール3：回路は「工程順・機能ブロック順」に並べる

ここからは仕様ではなく設計作法の話です。ラダーの回路は、設備の工程順・機能のまとまり順に並べると圧倒的に読みやすくなります。「原点復帰」「起動条件」「工程1：供給」「工程2：加工」「異常検出」「出力まとめ」のように、章立てされた文書のような構成にするイメージです。

逆にやってはいけないのが、関連する回路を離れた場所にバラバラに書くこと。工程2の条件を作る回路がプログラムの先頭と末尾に分かれていたら、読む人はスクロールの往復を強いられます。追加改造のたびに「とりあえず末尾に足す」を繰り返したラダーが、まさにこの状態に育ちます。多くの現場で、改造時も「その機能が書かれているブロックの中に追記する」のがマナーとされているのはこのためです。

もうひとつ、スキャンが上から順に演算されることを意識すると、「条件を作る回路を上に、それを使う回路を下に」並べる自然な流れができます。演算順が絡む微妙な挙動（同一スキャン内で反映されるか、次スキャンになるか）を減らす意味でも、データの流れとスキャンの流れを揃えておくと事故が減ります。

ルール4：コメントを書く — M100に意味を与えるのはコメントだけ

ラダーのデバイスは「M100」「D200」のような無機質な番号です。C言語なら変数名で意図を伝えられますが、ラダーでM100に「工程1完了」という意味を与える手段はデバイスコメントしかありません。コメントのないラダーは、変数名が全部「a1, a2, a3…」のプログラムを読まされるのと同じです。

書くべきコメントは2種類あります。

デバイスコメント：デバイス1点ごとの意味。「M100：工程1完了」「X5：供給部在荷センサ」のように、現物や状態と対応づける。入出力は電気図面の信号名と一致させておくと、盤前でのデバッグが格段に速くなります
回路コメント（行間ステートメント）：回路ブロックの見出し。「▼工程2：ワーク位置決め」のように章タイトルとして入れる。ルール3のブロック分けとセットで効きます

粒度の目安としては、「なぜこの条件が入っているのか」が番号の羅列から読み取れない箇所に一言添える、くらいで十分です。全行にコメントを書く必要はありませんが、内部リレーとタイマ・カウンタには原則すべてデバイスコメントを付ける、というのが多くの現場の相場感です。

ルール5：入力を一度内部リレーに受けるかは「現場標準」に従う

正直に書くと、この話題には流派があります。外部入力（X）をそのまま条件接点として使う流派と、プログラム先頭で一度内部リレー（M）に受け直してから使う流派です。どちらが正しいと決まっているものではなく、その現場・その会社の標準に従うのが正解です。

参考までに、内部リレーに受ける派の主な言い分はこうです。

a接/b接の反転を1か所に整理できる：b接点センサの論理反転を受け口で済ませれば、以降のプログラムは全部正論理で書ける
センサ変更に強い：入替えで接点の極性が変わっても、受け口の1回路だけ直せばよい
チャタリング対策やフィルタ処理を挟む場所ができる：受け口にタイマを入れて信号を安定させる、といった加工がしやすい

一方で「回路が1段増えて追いかける手間が増える」「Xを直接見た方がモニタが素直」という反対意見にも一理あります。大事なのは、自分の好みを持ち込む前に既存プログラムの流儀を確認すること。既設ラダーの改造で自分だけ違う書き方をすると、それ自体が読みにくさの原因になります。

ルール6：「動作の入口と出口」をセットで考える

回路を書くとき、起動条件だけ考えて満足していないでしょうか。読みやすく、かつ事故の少ないラダーを書く人は、「どうやって動き出すか」「どうやって止まるか」「異常のとき何が起きるか」を必ずセットで設計しています。

自己保持を1つ組むにしても、「保持を切る条件はどこか」「異常発生時にこの保持は残すべきか、即座に落とすべきか」「電源再投入後はどの状態から始まるか」まで考えて初めて回路として完成です。入口だけ書いて出口を後回しにしたラダーは、「異常後にリセットしても中途半端に動き出す」「止めたはずの工程が復電で勝手に再開する」といった形で必ず牙をむきます。

そしてこの延長線上にあるのが、「そもそもPLCに任せてはいけない停止がある」という話です。非常停止は、プログラムの出来とは無関係に、ハードワイヤで確実に動力を切る構成にします。理由は非常停止はなぜPLCを通してはいけないのかで掘り下げているので、ラダーの作法とあわせて押さえておいてください。

先輩に赤を入れられるラダー実例集

最後に、多くの現場でレビュー時に指摘されがちな「怒られるラダー」を短く並べます。心当たりがないかチェックしてみてください。

巨大な1行回路：接点を横に十数個も連ねた回路。どの条件で切れたのか、モニタしても一目で分かりません。意味のまとまりごとに中継Mで区切ると読めるようになります
マジックナンバー：比較命令やタイマ設定値に「K350」のような生の数値が説明なしに埋まっている状態。なぜ350なのかは書いた本人しか知らず、その本人も半年で忘れます。コメントで根拠を残すか、設定値をDレジスタに持たせて一覧管理するのが定石です
使い捨てデバイスの散乱：M999、M1000、M1001…と空いている番号を場当たり的に使い、どこにも用途の記録がない状態。デバイスの番号帯を機能ごとに割り当てておくと防げます。デバイスの種類ごとの性質と割り当ての考え方は三菱PLCのデバイスの使い分けで整理しています
コメントゼロ：論外に見えて、実は現場で最もよく遭遇するパターンです。「動いているから触るな」という負の遺産は、こうして生まれます

まとめ

ラダーの暗黙ルールを6つ整理しました。PLCの仕様に根ざした禁止事項と、読みやすさのための作法を区別して押さえてください。

ルール1（仕様）：二重コイル禁止。同一デバイスへのOUTはスキャン順で後の回路が勝つ（後勝ち上書き）。条件はORで束ねるか中継Mで分けて、OUTは1か所に
ルール2（作法）：同じデバイスにOUTとSET/RSTを混在させない。条件追従型と状態保持型の思想を混ぜない
ルール3（作法）：回路は工程順・機能ブロック順に。スキャンは上から下なので、条件を作る回路を上に
ルール4（作法）：デバイスコメントと回路コメントを書く。M100に意味を与えるのはコメントだけ
ルール5（流派）：入力を内部リレーに受けるかどうかは現場標準に従う。自分の好みより既存の流儀
ルール6（設計思想）：起動・停止・異常時の挙動をセットで考える。非常停止はPLCに任せない

どれも「ラダーは未来の誰かが読むドキュメントである」という一点から導かれる作法です。命令の文法そのものを整理したいときはGX Works3 命令語早見表も手元に置いてみてください。