「ラダーは古いと言われるが、STは現場で嫌われる…」「どちらで書くべきか、社内でも意見が割れている…」
そんな「ラダー vs ST言語」の不毛な論争は、今日で終わりにしましょう。
実務9年の現場エンジニアである私が断言します。現代のFA制御において、どちらか一方の言語に固執するのは非現実的です。
本記事では、ラダーの「保全性」とSTの「開発効率」をいいとこ取りする「ハイブリッド設計」3つの極意を解説します。 この記事を読めば、トラブル復旧が早く、かつ美しいプログラムを組める次世代の二刀流エンジニアになれます。
ただし、2つの言語を無秩序に混ぜるのは絶対にNGです。
一歩間違えれば、休日も深夜もあなたに電話が鳴り続ける「永久指名」の地獄に陥ります。設計者が絶対に守るべき「境界線」とは何か？ 続きをご覧ください。
なぜ「ラダー至上主義」は消えないのか？
若手エンジニアからすると「古い、ダサい、面倒くさい」と言われがちなラダー図。しかし、日本の製造現場においてラダーは依然として「最強の言語」として君臨しています。
その理由は、言語としての純粋なスペックの優劣ではありません。
国内主流のPLC環境において圧倒的な「保全性（視認性）」を発揮すること、そして何より、それを支える日本のFA業界の「文化（長年の教育や既存の回路図資産）」が深く根付いているからです。
夜中の3時に叩き起こされても読めるか？
想像してください。 深夜3時、ラインが停止して呼び出されました。眠い目をこすりながら盤を開け、PCを繋ぐ。 その時、モニタ画面に映るのが「英語のテキストコード（ST）」だったらどう思いますか？
- 現状（国内主流ソフト）のST画面： 変数の値をウォッチウィンドウで確認し、IF文の分岐を頭の中で追う必要があるケースが多い。
- ラダーの場合： 「切れている箇所（OFF）」が一目でわかる。
「ここが繋がっていない＝このリミットスイッチが入っていない」 この直感的な視認性こそが、ラダーが現場の共通言語であり続ける理由です。設備を「即座に復旧させる」という日本のFA現場の至上命題において、この視認性と圧倒的な浸透率（文化）を持つラダー図は、現在もなお最も合理的な選択肢なのです。
なぜ「ST言語」が必要なのか？
結論、複雑な計算と文字列処理をラダーで書くのは非効率だからです。
ラダーは保全性に優れる反面、データ処理には致命的に不向きです。
例えば、トレーサビリティ用に「ロット番号（文字）と重量（数値）を結合して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言語は強力で便利ですが、国内の主流PLC環境と保全文化を前提とするならば、インターロックや自動順序などの「条件制御（ON/OFF）」をSTで書くことはやめてください。
❌ なぜ「条件」をSTで書いてはいけないのか？
// 現場で嫌われるSTの例
IF (SensorA = TRUE) AND (SensorB = TRUE) AND (DoorClose = TRUE) THEN
MotorStart := TRUE;
END_IF;プログラムとしては正しく動きます。しかし、トラブルが起きてモーターが動かない時、「どのセンサが邪魔しているのか」が一目で分かりません。
モダンな統合開発環境（CODESYS等）であればSTでもインラインで状態確認が容易ですが、国内で圧倒的シェアを持つ主流PLCの環境下においては、その機能が十分に提供されていないことが多く、変数をウォッチウィンドウに入れて一つずつ確認する作業が発生しがちです。
現場の「共通言語」はラダーである
設備のトラブル対応をするのは、あなただけではありません。深夜に叩き起こされる「保全担当者」の多くは、ラダー図なら読めても、ST言語（テキストコード）には慣れていない人が大半です。
「保全担当者」がラダーを読めるのは、言語としての絶対的な優位性というよりも、日本のFA業界における長年の教育や、既存資産・回路図との親和性という強力な「文化」が根付いているためです。
この「現場の共通言語としての普及率」を無視し、保全担当者が慣れていないST言語で条件制御を組むということは、「何かあったら全部俺を呼べ」と言っているのと同じです。これが「永久指名（休日呼び出し）」の正体です。
✅ 正解：制御はラダー、演算はST
- ON/OFFが見たい場所（インターロック、工程歩進） → ラダー回路
- 計算結果だけ欲しい場所（数値計算、データ処理） → ST言語
この「制御（ビット）はラダー、演算（ワード）はST」という境界線を守るだけで、現場の保全性を維持したまま、プログラム工数を劇的に減らすことができます。
【補足】変数の型について
STをやるなら、変数の型（データタイプ）の意識が必須になります。 GX Works3なら、以下のようにリストから選ぶだけなので難しくありません。実数を扱うなら「単精度実数」、文字なら「文字列」を選びましょう。
客観的データが明かす真実：世界はST、日本はラダー
ここまで「ハイブリッド設計」の重要性を説いてきましたが、これは私の個人的な経験則だけではありません。先日、PLCopenなどがまとめた業界動向のセミナー資料（JEMAの最新調査等を含む）に目を通す機会があったのですが、そこでも非常に興味深いデータが示されていました。
世界標準はすでに「ST言語」が主流
北米や欧州を中心とした海外の調査データを見ると、主に使用する言語として「ST言語（38%）」が「ラダー図（34%）」を上回りトップになっていました。海外のモダンな開発環境では、ST言語の活用がすでに標準化されているのです。
日本の現場を支配する「9割のラダー文化」
一方で、日本国内の動向に目を向けると、依然として全体の約9割が「ラダー図言語」を使用しているという現実がありました。
世界がST言語へ移行しているにもかかわらず、なぜ日本だけがここまでラダーに偏っているのでしょうか？
その答えは、言語としての純粋なスペックの優劣ではありません。この「9割」という特異な数字の裏には、日本の保全現場における長年の教育や、既存の回路図資産との親和性といった、日本独自の強力な「現場文化」が深く根付いているからです。
業界団体が推奨する「最適解」もハイブリッド設計
さらにセミナーのまとめでは、今後の制御アプリケーションの大型化や複雑なデータ処理への対応として、「適材適所で言語を使い分ける（複雑処理はST、工程はSFC、回路的ロジックはLD）」ことが明確に推奨されていました。
「ラダーか、STか」という二元論で争っている場合ではありません。日本の現場文化（ラダー）に寄り添いながら、複雑化する制御（ST）を適材適所で組み込む「ハイブリッド設計」こそが、これからのFAエンジニアが目指すべき洗練された設計手法なのです。
まとめ：二刀流こそが次世代の標準
「ラダーのみの設計」は、複雑な演算においてプログラムの肥大化と工数増大を招きます。 一方で、「STのみの設計」は、現場からの視認性を奪い、トラブル復旧の遅延に直結します。
これからのFAエンジニアに求められるのは、「どちらが優れているか」という不毛な二元論からの脱却です。
「ラダーで骨格を組み、STで頭脳を作る」
この二刀流のスキルこそが、保守性と開発効率を両立させる次世代のスタンダードです。まずは、普段のラダー回路の中に「インラインST」を一行書き込んでみてください。あなたのプログラムと設計思想が、見違えるほどクリアになるはずです。
※本記事で使用している画面は、三菱電機株式会社「GX Works3」の操作画面です。
※GX Works3、MELSECは、三菱電機株式会社の登録商標です。
※本記事で紹介しているプログラムや回路図は、技術解説のためのサンプルです。実機での動作を保証するものではありません。
※実際に使用する際は、十分な検証を行った上で、安全に配慮して運用してください。
