「なんで今どき、お絵描きみたいなラダー図でプログラム組まなきゃいけないんだ！」 「なんだこのST言語とかいう英語の羅列は！ どこで電気が止まってるか分からん！」
FA業界の休憩所やSNSでは、今日も「ラダー（LD） vs ST言語」の終わらない宗教戦争が繰り広げられています。 結論から言います。「どっちか」を選ぼうとしている時点で、あなたの技術はそこで止まっています。
今回は、実務9年の現場エンジニアの視点から、ラダーとSTそれぞれの致命的な弱点を暴露し、現場で最も賢い「ハイブリッド設計（インラインST & FB）」の極意を解説します。
これを読めば、不毛な論争から抜け出し、「保全性」と「開発効率」を両立できる一流の設計者になれます。
ただし、単に混ぜればいいわけではありません。 ラダーとSTには、絶対に踏み越えてはいけない「明確な境界線」が存在します。このルールを無視してSTを使うと、休日も深夜もトラブル対応の電話が鳴り止まない「永久指名」の地獄を見ることになります。
なぜ「ラダー至上主義」は消えないのか？
若手エンジニアからすると「古い、ダサい、面倒くさい」と言われがちなラダー図。 しかし、日本の製造現場においてラダーは依然として「最強の言語」です。
その理由はたった一つ。「保全性（トラブルシューティング）」において、ラダーの右に出るものは存在しないからです。
夜中の3時に叩き起こされても読めるか？
想像してください。 深夜3時、ラインが停止して呼び出されました。眠い目をこすりながら盤を開け、PCを繋ぐ。 その時、モニタ画面に映るのが「英語のテキストコード（ST）」だったらどう思いますか？
- STの場合： 変数の値をウォッチウィンドウで確認し、IF文の分岐を頭の中で追う必要がある。
- ラダーの場合： 「切れている箇所（OFF）」が一目でわかる。
「ここが繋がっていない＝このリミットスイッチが入っていない」 この直感的な視認性こそが、ラダーが現場の共通言語であり続ける理由です。設備を「止まらせない」ことに関しては、ラダーはC言語やPythonよりも圧倒的に優秀なのです。
それでも「ST言語」が必要な理由
では、なぜ最近になってST言語（Structured Text）がもてはやされているのでしょうか？ それは、ラダーには「致命的に苦手なこと」があるからです。
それは、「複雑な計算」と「文字列処理」です。
【比較】CSVログデータの作成
例えば、トレーサビリティのために「ロット番号(文字列)と重量(数値)を繋げてCSV形式にする」という処理を考えてみましょう。 やりたいこと："LOT-001, 12.5" という文字列を作りたい。
▼ ラダーで書いた場合： 文字列転送、数値→文字列変換、文字結合……これらをパズルのように組み合わせる必要があります。 「一時メモリ（バッファ）」を大量に消費し、どのレジスタに何が入っているか管理するだけで一苦労です。途中で1箇所間違えても気づきにくい。「スパゲッティコード」の完成です。
▼ STで書いた場合：
// ロットNo, カンマ, 重量を結合
LogString := CONCAT(LotNo, ', ', REAL_TO_STRING(Weight));たった1行です。 「文字列操作」「複雑な数式」「IF文による条件分岐」。これらをラダーで書くのは、スプーンで穴を掘るようなものです。ショベルカー（ST）を使ったほうが圧倒的に早いのです。
解決策：【ハイブリッド設計】のススメ
「保全のラダー」か、「効率のST」か。 答えは「混ぜる」です。 現代のPLC（三菱電機 GX Works3やキーエンス KV STUDIO、オムロンSysmacStudioなど）には、この2つを共存させる機能が備わっています。
百聞は一見にしかず。まずは「ハイブリッド設計」の形をご覧ください。
▲ 上段： ラダーの中に埋め込まれた「インラインST」 ▲ 下段： STで書かれた中身を持つ「FB（ファンクションブロック）」
この2つの使い方を解説します。
① その場の計算なら「インラインST」
「わざわざ部品を作るほどでもないけど、この計算だけはラダーで書きたくない…」 そんな時は、ラダー回路の中に直接STを書ける「インラインST」機能を使います。
- イメージ： ラダー回路の途中に「STの小窓」を作る。
- 使い方： ラダーの接点条件（X0）の先に、ボックスを置いて処理を書く。
画像の通り、面倒な CONCAT（文字結合）や REAL_TO_STRING（数値変換）も、ラダー上の小窓の中でサクッと記述できます。変数定義の手間もなく、ここだけSTの恩恵を受けられる便利な機能です。
② 使い回すなら「ST記述のFB（ファンクションブロック）」
同じ計算や制御を何度も使うなら、「中身をSTで書いたFB」を作ります。
- 外側（メインルーチン）：ラダーで書く
- 画像の下段を見てください。保全マンが見るのはこのシンプルな「箱」だけです。全体の流れが一目でわかります。
- 中身（ブラックボックス）：STで書く
- 箱の中を開けると、以下のようになっています。
複雑な計算ロジックは、このようにFBの中に隠蔽します。 ラダーで見ても意味不明な計算式は、隠してしまった方が逆に見やすいからです。
【警告】「永久指名」を避けるための絶対境界線
最後に、リード文でお伝えした「地獄を見ないための境界線」を明確にします。 ST言語は便利ですが、インターロックや自動順序などの「条件制御（ON/OFF）」をSTで書くことはやめてください。
❌ なぜ「条件」をSTで書いてはいけないのか？
// 現場で嫌われるSTの例
IF (SensorA = TRUE) AND (SensorB = TRUE) AND (DoorClose = TRUE) THEN
MotorStart := TRUE;
END_IF;プログラムとしては正しく動きます。しかし、トラブルが起きてモーターが動かない時、「どのセンサが邪魔しているのか」が一目で分かりません。 ラダーなら「切れている接点」が青くならずに見えるので一瞬で分かりますが、STでは変数をウォッチウィンドウに入れて一つずつ確認する作業が必要です。
現場の「共通言語」はラダーである
設備のトラブル対応をするのは、あなただけではありません。深夜に叩き起こされる「保全担当者」の多くは、ラダー図なら読めても、ST言語（テキストコード）には慣れていない人が大半です。 彼らが読めないコードを書くということは、「何かあったら全部俺を呼べ」と言っているのと同じです。これが「永久指名（休日呼び出し）」の正体です。
✅ 正解：制御はラダー、演算はST
- ON/OFFが見たい場所（インターロック、工程歩進） → ラダー回路
- 計算結果だけ欲しい場所（数値計算、データ処理） → ST言語
この「制御（ビット）はラダー、演算（ワード）はST」という境界線を守るだけで、現場の保全性を維持したまま、プログラム工数を劇的に減らすことができます。
【補足】変数の型について
STをやるなら、変数の型（データタイプ）の意識が必須になります。 GX Works3なら、以下のようにリストから選ぶだけなので難しくありません。実数を扱うなら「単精度実数」、文字なら「文字列」を選びましょう。
「ラダーとSTのハイブリッド設計、面白そうだけど会社でいきなり試すのは怖い…」という方は、自宅でこっそりスキルアップしてしまうのが一番の近道です。
新しい設計（変数・構造化）を学ぶなら『実践 PLCプログラム設計』
この記事で紹介した「変数（ラベル）」や「FB（ファンクションブロック）」を使った設計手法が、体系的にまとまっています。 「Dレジスタの管理に疲れた……」という人が読むと、世界が変わる一冊です。
万が一のために自宅に置いておきたい実機
『三菱電機 FX5S シーケンサ』
⚠️ 注意：古い「FX3S」などはインラインSTに対応していません。
まとめ：二刀流こそが次世代の標準
- 「ラダーしか書けない」 ＝ 複雑な制御から逃げている、計算が苦手なエンジニア。
- 「STしか書けない」 ＝ 現場の泥臭いトラブル対応を知らない、独りよがりなエンジニア。
これからのFAエンジニアに必要なのは、「ラダーで骨格を組み、STで頭脳を作る」という二刀流のスキルです。
「どっちがいい？」と戦っている暇があったら、両方の武器を磨きましょう。 ラダーの中に「インラインST」を一行書くだけで、あなたのプログラムは見違えるほどスッキリするはずです。
※本記事で使用している画面は、三菱電機株式会社「GX Works3」の操作画面です。
※GX Works3、MELSECは、三菱電機株式会社の登録商標です。
※本記事で紹介しているプログラムや回路図は、技術解説のためのサンプルです。実機での動作を保証するものではありません。
※実際に使用する際は、十分な検証を行った上で、安全に配慮して運用してください。＼ 現場で役立つ！あわせて読みたい ／
端子台の選定も重要ですが、「そこに繋ぐ電線の太さとブレーカー容量」は合っていますか？ 「5.5sqに30Aブレーカー」など、現場でやりがちな危険な組み合わせを一目でチェックできる早見表を作りました。ぜひ画像を保存して、現場で活用してください！👇
