【ラダー vs ST言語】まだ戦ってるの？「ラダーは時代遅れ」という極論への回答 & 賢い使い分け術

URLをコピーしました！

「なんで今どき、お絵描きみたいなラダー図でプログラム組まなきゃいけないんだ！ C言語なら3行で終わるのに！」「なんだこのST言語とかいう英語の羅列は！モニタしてもどこで電気が止まってるか一瞬で分からんやないか！」

FA業界の休憩所やSNSでは、今日も「ラダー（LD） vs ST言語」の終わらない宗教戦争が繰り広げられています。

一昔前まではラダー一択でしたが、IEC 61131-3（国際標準）の普及や、情報系出身のエンジニアが増えたことで、この対立は激化する一方です。

結論から言います。 「どっちか」を選ぼうとしている時点で、あなたの技術はそこで止まっています。

今回は、ハードウェアの「ねじ vs スプリング」に続くパラダイムシフト第2弾。ラダーとST、それぞれの致命的な弱点を暴露し、現場で最も賢い「ハイブリッド設計（インラインST & FB）」の極意を解説します。

なぜ「ラダー至上主義」は消えないのか？

若手エンジニアからすると「古い、ダサい、面倒くさい」と言われがちなラダー図。しかし、日本の製造現場においてラダーは依然として「最強の言語」です。

その理由はたった一つ。「保全性（トラブルシューティング）」において、ラダーの右に出るものは存在しないからです。

夜中の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をやるなら、変数の型（データタイプ）の意識が必須になります。 GX Works3なら、以下のようにリストから選ぶだけなので難しくありません。実数を扱うなら「単精度実数」、文字なら「文字列」を選びましょう。

現場で役立つ「自習セット」

「ラダーとSTのハイブリッド設計、面白そうだけど会社でいきなり試すのは怖い…」という方は、自宅でこっそりスキルアップしてしまうのが一番の近道です。

新しい設計（変数・構造化）を学ぶなら『実践 PLCプログラム設計』

この記事で紹介した「変数（ラベル）」や「FB（ファンクションブロック）」を使った設計手法が、体系的にまとまっています。 「Dレジスタの管理に疲れた……」という人が読むと、世界が変わる一冊です。

リンク

万が一のために自宅に置いておきたい実機
『三菱電機 FX5S シーケンサ』

リンク

⚠️ 注意：古い「FX3S」などはインラインSTに対応していません。

まとめ：二刀流こそが次世代の標準

「ラダーしか書けない」 ＝複雑な制御から逃げている、計算が苦手なエンジニア。
「STしか書けない」 ＝現場の泥臭いトラブル対応を知らない、独りよがりなエンジニア。

これからのFAエンジニアに必要なのは、「ラダーで骨格を組み、STで頭脳を作る」という二刀流のスキルです。

「どっちがいい？」と戦っている暇があったら、両方の武器を磨きましょう。ラダーの中に「インラインST」を一行書くだけで、あなたのプログラムは見違えるほどスッキリするはずです。

※本記事で使用している画面は、三菱電機株式会社「GX Works3」の操作画面です。
※GX Works3、MELSECは、三菱電機株式会社の登録商標です。
※本記事で紹介しているプログラムや回路図は、技術解説のためのサンプルです。実機での動作を保証するものではありません。
※実際に使用する際は、十分な検証を行った上で、安全に配慮して運用してください。