結論：「IEC 61131-3準拠」は互換を保証しない
①ST言語の基本構文（IF/CASE/FOR、:=代入、T#500msのような時間リテラル）は5社でほぼ共通。ここだけ見ると「どこでも同じ」に見えます。
②差が出るのは構文の外側。変数とデバイスの流儀、タイマ・カウンタの使い方、メーカー独自の命令・ファンクション、開発ツールの作法——方言の正体はこの4レイヤです。
③生成AIの事故は「方言の混入」で起きる。コンパイルが通らないコードより、通ってしまうが微妙に意図と違うコードが危険です。対策は機種・ツール・流儀・禁止事項の4点指定。
この構図は、人間のエンジニアが他社機種へ移るときのつまずきと同じです。違いは、人間は「怪しい」と手が止まるのに対し、生成AIは確信を持って混ぜてくること。だから「どこに差が出るか」の地図を先に持っておく必要があります。
方言が生まれる4つのレイヤ
ST方言の差は、次の4レイヤに分解すると見通しが良くなります。上に行くほど共通で、下に行くほどメーカー色が濃くなります。
- レイヤ1: 言語コア（ほぼ共通）。IF〜END_IF、CASE、FOR〜END_FOR、代入の「:=」、コメントの「(* *)」など。IEC 61131-3の中核部分で、ここは5社で大きくは変わりません。
- レイヤ2: データ型と標準ファンクション（概ね共通・細部に差）。BOOL/INT/DINT/REALなどの基本型は共通ですが、文字列型の扱い、型変換ファンクションの名称・挙動、演算の暗黙型変換の許容度に差が出ます。
- レイヤ3: 変数とデバイスの流儀（大きく異なる）。「シンボリック変数だけで書く」文化（オムロン・ベッコフ）と、「Dレジスタ・DMなどデバイスを直接書ける」文化（三菱・キーエンス）、「データブロックとアドレスで管理する」文化（シーメンス）に分かれます。移植性を最も左右するレイヤです。
- レイヤ4: 独自命令と開発ツールの作法（完全に別物）。メーカー独自の便利命令・FB、タイマの宣言方法、ライブラリの持ち方、ツール上での書式チェック。ここはマニュアルの世界で、AIの知識も最も不正確になりやすい領域です。
【チートシート】主要5社のST開発環境比較
5社の「どこが違うか」を1枚に集約します。◎○△はIEC標準スタイルへの近さの目安です。構文の正確な仕様は必ず使用バージョンの公式マニュアルで確認してください（本表は差分が出る場所の地図です）。
| 項目 | 三菱電機 | キーエンス | シーメンス | オムロン | ベッコフ |
|---|---|---|---|---|---|
| 代表機種 | MELSEC iQ-R / iQ-F | KV-X（KV-8000後継世代） | SIMATIC S7-1500 / 1200 | NX / NJシリーズ | 産業用PC＋TwinCAT 3 |
| 開発ツール | GX Works3 | KV STUDIO（Ver.12〜） | TIA Portal | Sysmac Studio | TwinCAT 3（Visual Studio統合） |
| ST系言語の呼称 | ST（構造化テキスト） | ST（KV-X世代で新実装。旧KVスクリプトは廃止） | SCL | ST | ST（CODESYS系） |
| 変数の流儀 | ラベル（変数）とデバイス直接記述（D/M/X/Y等）の併用文化 | デバイス（DM/R等）文化が強い。KV-X世代でIEC準拠の変数・PLCopen FBに対応 | ローカル変数は#付き、グローバルはDB（データブロック）経由。%I/%Q/%M等のアドレス表記 | シンボリック変数のみで記述。実I/Oへの割付はAT指定で行う変数中心設計 | シンボリック変数中心。ポインタ・参照など高級言語的な拡張も持つ |
| IEC標準スタイルへの近さ（目安） | △〜○（デバイス併記と独自命令が濃い） | △〜○（IEC対応は新しく、デバイス文化が残る） | ○（独自作法は多いが体系的） | ◎（変数ベースで最もIEC的） | ◎（CODESYS系で最も汎用PL的） |
| 生成AIとの相性の現状 | 学習データ多め。ただしラダー文化の流儀（デバイス・タイマ）を混ぜやすい | 公開情報が比較的少なく、AIの知識が最も不正確になりやすい。方言テンプレート必須 | 学習データ最多クラス。純正AI（Engineering Copilot等）も商用提供 | 変数ベースなのでAI出力の移植は素直。独自FB名の創作に注意 | 汎用プログラミングに近く生成精度が出やすい。TwinCAT Chatも提供 |
ベンダー各社の生成AI製品の状況は「ラダー図は生成AIで書けるのか【2026年版】」で、キーエンスKV-XのST移行の背景は「キーエンスKV-Xと生成AI」で詳しく解説しています。
AIが最も間違えるポイント——タイマと変数の流儀
実務でAI生成コードをレビューしてきた経験則として、方言事故が集中するのは次の3か所です。
- タイマ・カウンタの流儀。IECスタイルでは「TON（オンディレイタイマ）のインスタンスを変数として宣言し、IN/PTを渡して呼び出す」のが基本形ですが、三菱・キーエンスのラダー文化圏にはタイマデバイス（T）を命令で使う流儀が根強く残っています。AIはこの2つの流儀を混ぜたコード（宣言していないタイマインスタンスの使用、デバイスとFBの混在）を出しがちです。時間の指定も、TIME型リテラル（T#500ms）と「タイマ設定値の数値指定（機種・タイマ種別で単位が変わる）」が混在すると単位事故になります。
- デバイスの直接記述。三菱のD100とキーエンスのDM100は別物ですし、オムロンNX/NJのSTにDレジスタを書いても通りません。AIに「三菱で」と言ったのに%MW（シーメンス流）が混ざる、といった横流れも頻発します。シンボリック変数だけで書かせて、実デバイスへの割付はツール側で行うのが最も事故が少ない構成です。
- 存在しない独自命令の創作。AIは「それらしい名前のファンクション」を作り出すことがあります。特にキーエンスのように公開コード資産が少ない環境では、実在しない命令・FB名の混入率が上がります。「不確かな命令は使わず、コメントで代替案を書け」という指示が効きます。
生成AIへの機種指定プロンプト（コピペ用）
生成AIにSTコードを書かせるときは、依頼文の先頭に次の指定ブロックを付けます。【】を自分の環境に置き換えてください。
共通テンプレート:
「対象PLCは【メーカー・機種（例: 三菱電機 MELSEC iQ-R）】、開発環境は【ツール名とバージョン（例: GX Works3）】。言語は【ST/SCL】。変数は【シンボリック変数のみ使用（デバイス直接記述の禁止）／デバイス併用可】。他社の命令・関数・アドレス表記を混ぜないこと。この環境に存在するか不確かな命令は使わず、コメントで『要確認』と代替案を書くこと。タイマは【TON等のFBを宣言して使う／タイマデバイスを使う】流儀に統一すること。」
機種別の要点は次のとおりです。
- 三菱電機: 「GX Works3のST。ラベルベースで記述し、デバイス直接記述は【可／不可】を明示。MELSEC独自命令を使う場合は名称の根拠をコメントに書くこと」
- キーエンス: 「KV STUDIO Ver.12以降・KV-XのST。旧KVスクリプトの構文を混ぜないこと。使用できる命令が不確かな場合は必ず『要マニュアル確認』とコメントすること」（AIの知識が最も薄い環境のため、この一文が保険になります）
- シーメンス: 「TIA PortalのSCL。ローカル変数は#、グローバルはDB経由。IECタイマはインスタンスを宣言して使用」
- オムロン: 「Sysmac StudioのST。シンボリック変数のみ。実I/O割付はAT指定で行う前提とし、コード内にアドレスを書かないこと」
- ベッコフ: 「TwinCAT 3のST。標準ライブラリ（Tc2_Standard等）のFBを使用し、使用ライブラリ名を冒頭コメントに列挙すること」
この指定を毎回貼るのが面倒になったら、変換・レビュー用のプロンプトを整備してチームで共有する段階です。実務用のひな形は「ST方言変換プロンプト」「KVスクリプト→ST移行プロンプト」「AI生成STレビュープロンプト」として配布しています。
生成・変換コードのレビューチェックリスト
AIが出したST/SCLコードは、コンパイル前に次の7点を機械的に確認します。
- 機種宣言との一致: コード中のデバイス表記・命令が、指定した機種のものだけで構成されているか
- タイマの宣言: 使用しているタイマ・カウンタFBのインスタンスがすべて宣言されているか。設定値の単位（TIME型か数値か）が統一されているか
- 未宣言変数・型の不一致: 暗黙の型変換に頼っている箇所がないか（機種によって許容度が違うため）
- 実在しない命令: 見慣れないファンクション名はマニュアルまたはツールの命令一覧で実在確認（AIの創作が混ざる前提で）
- 初回スキャン・電源断復帰: 初期化処理とラッチ（停電保持）の扱いが機種の仕様に合っているか
- スキャンタイムへの影響: FORループの回数上限・多重ループなど、1スキャンで回り切らない構造がないか
- 安全関連部の混入: 非常停止・安全入力に関わるロジックが含まれていないか（含まれていたらAI生成部分から除外し人間が設計）
このチェックリストの運用を含めた「AIが書いてよい範囲の線引き」はピラーガイドの実務導入5ステップで、エンジニア個人のキャリア戦略はエンジニアの生存戦略ガイドで扱っています。ST言語×生成AIを武器にする具体的な学び方は、三菱電機のラダー生成AI記事の3プロトコルも参照してください。
よくある質問（FAQ）
Q. 三菱のSTコードは、キーエンスのKV STUDIOに貼り付ければそのまま動きますか？
A. 動かない前提で扱ってください。同じIEC 61131-3系のST言語でも、デバイスの表記（DレジスタとDMなど）、メーカー独自の命令・ファンクション、タイマの使い方、変数宣言の作法が異なります。移行する場合は「①変数・デバイス対応表を作る→②独自命令を洗い出す→③生成AIに変換の下書きをさせる→④移行先ツールでコンパイル→⑤シミュレータで動作確認」の手順を踏みます。変換の下書き自体は生成AIの得意領域です。
Q. 生成AIにSTコードを書かせるとき、最初に何を指定すべきですか？
A. 最低限4つあります。①メーカーと機種（例: 三菱電機 iQ-Rシリーズ）、②開発ツールとバージョン（例: GX Works3）、③変数の流儀（ラベル/シンボリック変数を使うか、デバイス直接記述を許すか）、④禁止事項（他社の命令・関数を混ぜない。不確かな命令は使わずコメントで代替案を示す）。この4点を省くと、AIは学習データ中で最も多い書き方——多くの場合CODESYS系やシーメンス系の作法——に寄せたコードを平然と出してきます。
Q. シーメンスのSCLとST言語は別物ですか？
A. SCL（Structured Control Language）はシーメンスにおけるST相当言語の呼称で、考え方はIEC 61131-3の構造化テキストと同じ系統です。ただしローカル変数の「#」プレフィックス、データブロック（DB）へのアクセス記法、%I/%Qといったアドレス表記など、シーメンス固有の作法があります。「SCLで」と指定して生成させたコードを他社のSTにそのまま持ち込むことはできません。
Q. ラダーとST、生成AIに書かせるならどちらですか？
A. STです。大規模言語モデルの本領はテキスト生成であり、テキスト言語のSTは学習データも多く精度が出ます。グラフィカル言語のラダーはツール内部の保存形式もベンダー独自で、AI生成は一部の純正ツール（シーメンスなど）に限られます。ただし安全関連部（非常停止・ライトカーテン等）は言語を問わずAI生成コードの無検証投入は論外で、人間の設計・承認が前提です。詳しくは常設ガイド「ラダー図は生成AIで書けるのか」を参照してください。
Q. 各社の方言の正確な仕様はどこで確認できますか？
A. 一次情報は各社の公式マニュアルです。三菱電機はGX Works3のプログラミングマニュアル（構造化テキスト編）、キーエンスはKV STUDIOのユーザーズマニュアル・スクリプト/STリファレンス、シーメンスはTIA Portalのヘルプ（SCLプログラミング）、オムロンはSysmac Studioのリファレンスマニュアル、ベッコフはInformation System（オンラインヘルプ）が該当します。本ページの表はあくまで「どこに差が出やすいか」の地図であり、最終確認は必ず使用バージョンのマニュアルで行ってください。