ST言語(構造化テキスト)でラダーを卒業する方法ー IF文やFORループで書くPLCプログラミング

なぜ今ST言語なのか
ST言語の基本構文
1. IF文（条件分岐）
2. FORループ（反復処理）
ラダーからSTへの移行手順
書き換えサンプル集
1. サンプル1：複数センサの異常判定
2. サンプル2：配列を使った多重設定値管理
ラダーからSTへの変換ポイント一覧
ST言語のデバッグ方法
失敗パターン3選
OpenCodeでST言語をAI生成する
まとめ
出典・参考情報

なぜ今ST言語なのか

日本のPLCプログラミングは長らくラダー言語が主流だった。しかしスマートファクトリー化が進む中で、プログラムの複雑化・大規模化に対応するため、IEC 61131-3で標準化されたST言語（構造化テキスト）の採用が世界的に加速している。ST言語はPascalライクな高水準言語で、IF文やFORループ、CASE文を使った構造化プログラミングが可能だ。本記事では、ラダーからの移行手順と具体的な書き換えサンプルを紹介する。

ラダーがプログラマーに読まれない理由

ラダー言語は「回路図をそのままプログラムにした」言語であり、電気回路の知識がある現場技術者には直感的だ。しかしC言語やJava、Pythonなどで長年コードを書いてきたプログラマー出身のエンジニアにとっては、接点とコイルの組み合わせで論理を表現するラダーは極めて読みにくい。「なぜこれがプログラミング言語なのか」と感じるレベルである。

一方ST言語は、IF文・FORループ・CASE文・WHILE文といった汎用プログラミング言語と同じ制御構造を持ち、変数宣言もVAR〜END_VARで明示的に行う。プログラマーからPLCエンジニアに転身した人にとって、ST言語は自然に書ける「待っていた言語」なのである。

キーエンスのスクリプト言語——VB経験者には低い導入障壁

キーエンスのPLC（KVシリーズ）が提供するスクリプト言語は、Visual Basicに近いシンタックスを持つ。変数の宣言方法、代入演算子、関数の呼び出し方がVBユーザーにとって馴染み深い。VBで業務アプリケーションを開発していたエンジニアや、VBAでExcelマクロを組んでいた現場担当者にとっては「ほぼ同じ感覚」で扱える。

KV STUDIOのスクリプトエディタでは、演算処理・文字列操作・ファイル出力などをコードベースで記述できる。これをラダーで書こうとするとF命令や拡張命令を駆使した難解な回路になるが、スクリプトなら数行で済む。VBやVBAの経験者がPLCプログラミングに参入する際、キーエンスのスクリプトは理想的な入り口となる。

WEBエンジニアがPLCプログラミングに参入する時代

さらに注目すべきは、WEBエンジニアでさえPLCプログラミングを行える環境が整いつつあることだ。ファナックが推進するROS 2対応やPython標準搭載、そしてフィジカルAIの流れがその立役者である。

ファナックの産業用ロボットはPythonを標準搭載し、ROS 2ドライバもオープンソース公開された。つまりPythonが書けるエンジニアならPLCやロボットの制御に自然にアクセスできる。Node-REDのようなノーコード／ローコードツールを使えば、REST API経由でPLCのデータを取得しダッシュボードを構築することも珍しくない。

ST言語の知識は、こうした流れの中で「PLCの世界とITの世界をつなぐ共通言語」としての役割を果たし始めている。ラダーしか知らなければPLCの世界に閉じていたものが、ST言語を理解することでPythonやJavaScript、SQLとの連携が見えてくる。ST言語は単なるラダーの代替ではなく、OT（運用技術）とITの架け橋なのである。

ST言語の基本構文

ST言語の基本構文をラダーと比較しながら解説する。

IF文（条件分岐）

ラダーでは条件分岐は複数の接点とコイルで表現するが、STでは1行で書ける。

ST: IF Sensor1 AND NOT Sensor2 THEN Output1 := TRUE; ELSE Output1 := FALSE; END_IF;
ラダー: Sensor1のa接点とSensor2のb接点を直列接続し、Output1のコイルを配置

FORループ（反復処理）

ラダーでは反復処理の実現が難しいが、STなら簡単である。

FOR i:=1 TO 10 DO
  DataArray[i] := DataArray[i] * 2;
END_FOR;

配列の全要素を2倍にするこの処理をラダーで書こうとすると、カウンタ・比較命令・演算命令を組み合わせた10行以上のプログラムになる。

ラダーからSTへの移行手順

移行は段階的に行うことを推奨する。一気に全プログラムを書き換えるのはリスクが高い。

ステップ1：開発環境を整える

三菱GX Works3、キーエンスKV STUDIO、オムロンSysmac StudioはいずれもST言語に対応している。まずは開発環境でST言語のPOUを作成し、コンパイルが通ることを確認する。

ステップ2：簡単な処理からST化する

最初に移行するのは、ラダーで無理に書いている複雑な演算処理が適している。複数のアナログ入力値の平均を計算する処理やBCD変換などが好例だ。ラダーで10行の演算ブロックが、STなら3行で書けることが多い。

ステップ3：制御ロジックをST化する

演算処理に慣れたら、シーケンス制御の一部をST化する。単純なON/OFF制御はラダーのままでも問題ない。ST化の優先順位は「複雑な条件分岐＞配列処理＞数値演算＞単純なシーケンス」とする。

書き換えサンプル集

サンプル1：複数センサの異常判定

ラダー: 5つのセンサの状態をそれぞれ判定し、3つ以上がONなら異常フラグを立てる。自己保持回路とカウンタを組み合わせた複雑な回路になる。

ST: IF (Sensor1 + Sensor2 + Sensor3 + Sensor4 + Sensor5) >= 3 THEN ErrorFlag := TRUE; END_IF; これだけで完了する。

サンプル2：配列を使った多重設定値管理

ラダー: 10品種の設定値をDレジスタに個別保存し、品種選択スイッチで切り替える。品種番号ごとにMOV命令を並べる必要がある。

ST: RecipeValue[ProductNo] := SetValue; 配列を使えばたった1行である。

ラダーからSTへの変換ポイント一覧

ラダー	ST言語
a接点（ノーマルオープン）	`IF 条件 THEN` の条件部
b接点（ノーマルクローズ）	`NOT 条件`
コイル（出力）	`変数 := TRUE; または変数 := 式;`
自己保持回路（セット/リセット）	`IF セット条件 THEN 変数 := TRUE; ELSIF リセット条件 THEN 変数 := FALSE; END_IF;`
タイマ	`TON_INST(IN:=条件, PT:=設定時間);`
カウンタ	`CTU_INST(CU:=カウント条件, R:=リセット条件, PV:=設定値);`

ST言語のデバッグ方法

ST言語のデバッグはラダーより難しいと言われるが、各社のモニタ機能で十分対応できる。三菱GX Works3では各変数の現在値を表示可能。キーエンスKV STUDIOでもSTエディタで変数の値をリアルタイム監視できる。シミュレーションモードを使えば実機なしでの動作確認も可能だ。複雑な計算式は中間変数で分解して確認するのがコツである。

失敗パターン3選

1. ラダーと同じ発想でSTを書く
STの特徴である構造化を活かさず、単にラダーを1行ずつSTに書き写すだけでは効果が半減する。

2. 全プログラムを一度にST化する
デバッグが収集つかなくなる。段階的な移行が鉄則である。

3. 「ラダーの方が理解されやすい」と諦める
若手エンジニアの多くはST言語に抵抗がなく、むしろラダーより理解しやすいと感じる。現場の思い込みで移行機会を逃さないこと。

OpenCodeでST言語をAI生成する

ここまでの流れで、ST言語がコードを書くスタイルのエンジニアに親和性が高く、ラダーより効率的であることは伝わったと思う。しかしさらに一歩進んで、AIを活用してST言語そのものを自動生成する選択肢が現実のものとなっている。OpenCode（OpenAI Codex CLIベースのコーディングエージェント）を使えば、自然言語で指示するだけでAIがSTコードを生成・実行・デバッグしてくれる。

実装の高速化

「温度センサの値が一定以上なら警報を出力するSTプログラムを書いて」と指示するだけで、以下のコードが瞬時に生成される。

IF AI_Temperature > 80.0 THEN
    AlarmOutput := TRUE;
    AlarmCode := 100;
ELSE
    AlarmOutput := FALSE;
    AlarmCode := 0;
END_IF;

ラダーなら比較命令・出力コイル・自己保持回路を1つずつ配置するところが、ST＋AI生成なら数十秒で完了する。タイマやカウンタを使った複雑なシーケンスも日本語の指示で生成できる。

デバッグの効率化

AIに「このSTプログラムのバグ原因を分析して」と依頼すれば構文エラーや論理ミスを指摘し、「修正案を提示して」と続ければ修正コードを生成する。PLCシミュレータでステップ実行しながら時間をかけて探していたバグが、AIとの対話だけで解決できる。

コード品質の標準化

チームのコーディング規約をAIにプロンプトとして与えておけば、誰が生成しても一定品質のSTコードが出力される。「変数名はハンガリアン記法」「コメントは日本語で処理の意図を書く」といったルールを含めるだけで、統一感のある保守しやすいコードベースを維持できる。

AI活用の注意点

ただし、AIが生成したコードを無条件に実機で動かすのは危険である。必ずシミュレータで検証し、安全回路とは別系統で動作確認する必要がある。AIはあくまで「生産性を高める道具」であり、最終的な責任は人間にある。

まとめ

ST言語は複雑な演算・配列処理・大規模制御においてラダーより圧倒的に効率的であり、プログラマー出身のエンジニアにとっては自然な選択肢である。さらにOpenCodeのようなAI生成ツールを組み合わせれば、作成・デバッグの障壁はさらに下がり、制御システムの品質向上が期待できる。

移行は段階的に行い、まずは簡単な演算処理から始めることを推奨する。ラダーとSTのハイブリッド運用も十分実用的であり、無理に統一する必要はない。筆者の経験では、ST化したプログラムの保守性はラダーの3倍以上向上した。「ラダーしか知らない」状態から一歩踏み出せば、新たな世界が広がっている。

出典・参考情報

IEC 61131-3 規格解説（Hitopedia）
三菱電機 GX Works3 ST言語マニュアル
キーエンス KV STUDIO スクリプト機能マニュアル
PLCプログラミング入門（techcraft）
FANUC「ロボット新技術：オープンプラットフォームとフィジカルAI」（2025年12月）
Node-RED公式サイト
OpenCode（OpenAI Codex CLI）