「生成AIで作ったPLCプログラムは、そのままラインで動くのか」——本記事はこの問いに、5タスクの検証結果とPLCメーカーごとの文法差分、そして生産技術OSという業務基盤の中での位置づけを含めて答えるガイドです。ST言語はIEC 61131-3で標準化されていますが、自己保持・FOR文・構造体まわりは実機種で書き換えが必要で、ロジックそのものよりも「業務として誰がどう検収するか」が実用度を決めます。

PLCプログラム生成AIは、四則演算・条件分岐・入出力代入レベルでは2024年時点でほぼ実用域に到達しました。一方、自己保持回路・FOR文・構造体宣言は機種依存が残るため、「コード生成」ではなく「生産技術業務の一部」として扱う設計が必要です。下記の比較表とFAQで、評価軸を整理します。

PLCプログラム生成AIの実用度——5タスク別の到達点（2026年版）

結論を先に提示します。ST（Structured Text）言語をChatGPTやClaudeなどの汎用大規模言語モデルで生成した場合、タスク種別ごとに「そのまま使える」「部分修正」「機種別書き換え必須」の3段階に分かれます。下図は、現場で頻出する5タスクを実用度で並べたマップです。

マップから読み取れるのは、「生成AIの実用度はコード難易度ではなく、ST言語の方言ばらつきに支配される」という構造です。四則演算や代入文はIEC 61131-3の中核仕様に近いため機種を超えて使えますが、自己保持回路・FOR文・構造体まわりはメーカー独自記法に依存します。

ST言語と生成AIの相性——なぜテキスト系言語が選ばれるのか

PLCプログラムは下記の5種類の言語が国際規格IEC 61131-3で定められています。

• IL（インストラクション・リスト）
• LD（ラダー・ダイアグラム）
• FBD（ファンクション・ブロック・ダイアグラム）
• ST（ストラクチャード・テキスト）
• SFC（シーケンシャル・ファンクション・チャート）

5種類のうち、現場で利用率が高いのはLD（ラダー）ですが、生成AIと相性が良いのはST言語です。STはPASCALベースの高級言語で、テキストのみで記述可能なため大規模言語モデルが扱いやすい構造を持ちます。一方、ラダーは記号と接点で表現されるグラフィカル言語のため、現状の大規模言語モデルでは「ラダー風テキスト表現」までしか出力できません。

ラダー側のAI生成事情と、PLC主要3メーカー（三菱・オムロン・キーエンス）の文法差については、姉妹記事で詳しく整理しています。

ラダー図は記号と接点で表現されるグラフィカル言語のため、生成AIによる「コードそのものの自動生成」は2026年時点でまだ限定的です。一方、自然言語からのラダー設計支援は実用域に入りつつあります。

【2026年最新】PLCラダー図とは｜基本5記号・主要3メーカー比較とAI自動生成の到達点（roboin-fa.com）

ST言語のメリット・デメリット

ST言語のメリットは「テキストのみで記述可能」「複雑な計算が容易」「繰り返し処理・条件分岐の記述が容易」の3点で、生成AIの出力と直結します。一方、デメリットは「文法理解が必須」「機種別の方言差がある」「グラフィカルでないため現場のラダー文化と乖離する」の3点です。

つまり生成AIは「ST言語を書けない人がいきなり実用コードを得る」用途より、「ST言語の文法を理解した技術者が、雛形生成の時短に使う」用途で実用性が高い、というのが正確な結論になります。

5タスクの検証結果——ChatGPT-4で何ができて、何ができないか

以下、ChatGPT-4で実際に検証した5タスクを順に見ていきます。コード片はそのまま掲載しますが、各セクション末尾に「機種依存度」と「現場での扱い方」を加筆しました。

1. 四則演算

「D0とD2とD4の和をD6倍し、5で割った値をD20に代入する」という指示に対して、ChatGPT-4は以下を返しました。

// D0とD2とD4の和をD6倍し、5で割った値をD20に代入する
D20 := (D0 + D2 + D4) * D6 / 5;

機種依存度：低。アドレス命名（D0／D6など）だけ自社環境に置換すればそのまま動作します。三角関数や平方根も同様にIEC 61131-3標準関数で動くため、生成AIの出力をほぼ無修正で利用できます。

2. 入出力代入と自己保持回路

単純な入出力代入は問題ありません。ところが「X010でONし、X011で解除する自己保持」を指示すると、ChatGPT-4はIF-ELSIF構文で返してきました。

IF X010 THEN
    Y000 := 1;
ELSIF X011 THEN
    Y000 := 0;
END_IF;

動作はしますが、PLCの現場で慣用される自己保持の書き方は Y000 := X010 OR Y000; という1行です。実機種を想定すると、三菱製では後者が標準。AI生成出力を受け取った技術者は、現場慣用記法に書き直す工程が必須になります。

3. 条件分岐（IF文）

IF X000 = 1 THEN
    Y000 := 1;
ELSE
    Y000 := 0;
END_IF;

IF D0 * D1 <= 200 THEN
    D2 := 0;
ELSE
    D2 := 1;
END_IF;

機種依存度：低。IF文はIEC 61131-3標準のため、機種を問わずそのまま使えます。入出力アドレス命名のみ確認すれば実装可能です。

4. 繰り返し処理（FOR文）

「D100を0で初期化し、D100が30まで、D100を1ずつ増加させながらD200にD100+1を代入する」という指示に対し、ChatGPT-4は以下を返しました。

D100 := 0;
FOR D100 TO 30 DO
    D200 := D100 + 1;
    D100 := D100 + 1;  // 通常、FORループ中で変更は推奨されません
END_FOR;

三菱製のPLCに合わせると、本来は以下のような記法になります。

FOR D100 := 0 TO 30 BY 1 D
    D200 := D100 + 1;
END_FOR;

キーエンスのPLCでは「BY 1 D」が不要、オムロン製ではループ変数の宣言方法が異なる、というようにFOR文はST言語の中で最も機種差分が大きい構文です。生成AIをそのまま転載すると動かない確率が高いため、対象機種のリファレンスマニュアルを並走で参照する運用が必要です。

5. 構造体の定義と配列の計算

名前・身長・体重を100人分の構造体配列として定義し、平均値を計算するプログラムをChatGPT-4に依頼すると、TYPE定義からFOR文の集計、平均算出までを一括出力できました。ただし、構造体定義に対応していないPLC機種（特に小型ラインPLC）では、そもそも構造体宣言自体が文法エラーになります。

TYPE
    Person: STRUCT
        Name: STRING[20];
        Height: REAL;  // 単位: cm
        Weight: REAL;  // 単位: kg
    END_STRUCT;
END_TYPE

機種依存度：高。中型〜大型機種では概ね動作しますが、小型機種・古い機種では非対応です。生成AIから受け取ったコードを「機種仕様書と突合して使えるかを判定する」工程が必要になります。

主要PLCメーカー別 ST言語の方言差分（2026年版）

生成AIをPLC現場で使う場合、ST言語の方言差を事前に押さえておくことが実用化の鍵になります。下表は主要3メーカー（三菱・オムロン・キーエンス）と汎用CODESYS環境のST方言を比較したものです。

項目	三菱電機（GX Works3）	オムロン（Sysmac Studio）	キーエンス（KV STUDIO）	CODESYS
自己保持の慣用記法	Y000 := X010 OR Y000;	SET/RST命令併用	Y000 := X010 OR Y000;	標準IF-ELSIF
FOR文（カウンタ書式）	FOR i:=0 TO 30 BY 1 D …	FOR i:=0 TO 30 DO …	FOR i:=0 TO 30 DO …	FOR i:=0 TO 30 BY 1 DO …
構造体宣言	○（中型機以上）	○	△（機種限定）	○
配列インデックス	1始まり推奨	0始まり可	機種により異なる	0始まり標準
標準関数（三角・平方根）	○	○	○	○
生成AI出力との親和性	中（書き換え多）	高	中（書き換え多）	非常に高

表が示すのは、生成AI×PLCの実用度は「言語の問題」ではなく「対象機種の方言」の問題であるという事実です。同じST言語でも、三菱とキーエンスではFOR文の書式が異なります。生成AI活用を組織で展開する際は、「自社が使う機種のST方言テンプレート」を整備しておくことが投資対効果を左右します。

【2026年最新】生成AI×PLCは「コード生成」ではなく「生産技術OS」の一部

ここまで読むと、生成AIが「ST言語の文法を知っている技術者の時短ツール」だと分かります。しかし、生産技術部門が直面する本質的な課題は、コードを書く速さではありません。

装置立ち上げ時のPLCプログラムは、要求仕様→ロジック設計→コーディング→デバッグ→検収→ライン投入→改造履歴の蓄積、という一連の業務フローの中で生成・修正・運用されます。生成AIで「コーディング」だけが3倍速になっても、要求仕様の読み解きや、改造履歴の引き継ぎが従来のExcel管理のままでは、現場の業務時間は思ったほど短縮されません。

ERPは「お金とモノの記録台帳」、PLMは「図面とBOMの保管庫」であり、いずれも「業務そのもの」を実行する仕組みではない。

業務OSとは何か——製造業ERPでもPLMでもない、第3の業務基盤の正体（roboin-fa.com）

同じことが、PLCプログラム生成AIにも当てはまります。生成AIは「コードを書く」業務を高速化しますが、その前後にある「装置仕様の要求整理」「機種別方言テンプレートの管理」「検収・改造履歴の継承」という生産技術業務を統合的に扱う仕組みが必要です。これが生産技術OSの考え方になります。

生成AIを単体で導入しても、道具層が高速化するだけです。装置仕様の整理、機種別ST方言テンプレートの管理、改造履歴の引き継ぎ——これらの業務層を整える生産技術OSと組み合わせて、はじめて「コーディング以外の業務時間」が短縮できます。

ハードウェアとしてのロボットが用意できても、「どの工程に・どのSKUで・どの順番で投入するか」を決める業務側の意思決定が遅いと現場は動かない。

業務OSとは何か——製造業ERPでもPLMでもない、第3の業務基盤の正体（roboin-fa.com）

PLCプログラム生成AIに置き換えれば、「ST言語のコード自動生成が用意できても、機種別方言・改造履歴・検収フローを決める業務側が整っていないと現場の工数は減らない」となります。装置メーカー・設備保全部門が生成AIを評価する際は、コード生成精度だけでなく、業務OSへの組み込み可能性まで含めて検討してください。

FAQ：生成AI×PLCプログラムの実務疑問

Q1. 生成AIで作ったPLCプログラムは、そのまま装置に転載できますか？

タスクによります。四則演算・IF文・単純な代入文はそのまま動作する確率が高く、対象機種のアドレス命名規則だけ確認すれば実装可能です。一方、自己保持回路・FOR文・構造体宣言は機種別方言の影響を受けるため、PLCメーカーのリファレンスマニュアルに沿って書き換えが必要です。「コード生成精度が95%でも、現場に展開するには検収者が必須」と理解してください。

Q2. ChatGPTとClaude、PLC向けのST言語生成はどちらが優れていますか？

2026年5月時点で、IEC 61131-3標準準拠の出力品質は両モデルとも高く、四則演算・条件分岐レベルでは大きな差はありません。違いが出るのは「機種固有方言の知識量」と「指示の追従性」です。三菱電機のGX Works3固有のFOR記法など、特定メーカーの慣用記法を踏まえた出力を求める場合は、システムプロンプトで「対象機種：三菱電機GX Works3」と明示するなど、機種情報を入力する工夫で出力品質が上がります。

Q3. ラダー図は生成AIで作れますか？

2026年時点で、グラフィカルなラダー図そのものを生成AIで自動生成する仕組みは限定的です。ただし「自然言語からのラダー設計支援」（自然言語→ST言語→ラダー変換、または接点・コイル構成案の提案）は、専用ツールや社内ワークフローで実現可能です。詳細はPLCラダー図ガイドで整理しています。

Q4. 生成AIをPLCコーディングに使うとき、最大のリスクは何ですか？

「動くが慣用記法と異なるコードがライン投入される」リスクが最大です。動作はするが、後続の保全担当者が読み解けない、改造履歴を追えない、というケースが発生します。生成AIの出力をそのまま使うのではなく、自社の機種別ST方言テンプレートで再整形してから登録する運用が不可欠です。生産技術OSの一部としてテンプレート管理を組み込むのが現実的な解決策になります。

Q5. ST言語の知識ゼロでも生成AIでPLCを書けますか？

難しいです。AI出力の妥当性検証にはST文法の理解が必要で、特に自己保持・FOR文・構造体の機種依存判定はST言語経験者でないと判断できません。ただし「ST文法を知っている技術者の作業時短ツール」としては高い実用価値があります。装置メーカーの設計部門でAI活用を企画する場合は、まず1〜2名がST言語スキルを保有した上で、その人たちの時短ツールとして導入するのが現実的です。

関連記事：業務OSの最前線

• 【2026年最新】PLCラダー図とは｜基本5記号・主要3メーカー比較とAI自動生成の到達点——ラダー図の基本記号と主要3メーカー比較。本記事のST言語編と対をなす技術解説
• 業務OSとは何か——製造業ERPでもPLMでもない、第3の業務基盤の正体——生成AI・PLCツールを業務OSの中に位置づける考え方
• 設計OSとは——図面・部品表・設計変更を一気通貫させる業務エージェント基盤——装置仕様の上流である設計工程のOS化アプローチ

次のアクション

生成AIによるPLCプログラム生成は、ST言語の文法理解者にとって2026年時点で実用域に到達しています。しかし、コーディング以外の生産技術業務（仕様整理・方言テンプレ管理・検収・改造履歴継承）が従来の属人運用のままなら、現場の業務時間は思ったほど減りません。

生産技術OSとして、生成AIを業務フローに組み込む構成検討にご関心があれば、業務診断（30分・無料）または生産技術OSページからご相談ください。