導入：PLCプログラムに生成AIを使う前に決める3つのこと
PLCプログラムに生成AIを使えないか、という相談が増えています。前任者が残したラダーが読めない。コメントが日本語のままで、タイ人の保全担当者が読めない。小さな改造でも外注SIerの見積もりと日程を待つ必要がある。こうした悩みに対して、2024年から2026年にかけて、主要なPLCやFAのベンダーが生成AIの機能を相次いで発表しています。発売済みのものもあれば、開発中のものもあります。
本記事では、導入で先に決めるのはツールの名前ではなく、次の3つだと考えます。
- ①AIに任せる作業の範囲（新規作成、改造、既存コードの解読とコメント付け、レビュー、テスト作成、ドキュメント作成のどれから始めるか）
- ②生成物の検証手順（コンパイル、静的チェック、シミュレーションや仮想立上げ、実機でのFATとSAT、人のレビューと承認）
- ③ソースと設備情報の送り先（クラウドかローカルか、学習に使われるか、顧客との秘密保持契約に触れないか）
人の関与に触れている主要ベンダーは、いずれも人が確認してから使う前提で機能を説明しています。研究でも、検証ツールを組み込まないと有効なプログラムが出にくいという報告があります。確認した規格の公式要旨や条文には、AIで書いたコードの可否を定めた記述は見当たりません。一方で、書き手が人でもAIでも、制御ロジックの誤りが危険を生まないことと、改造の検証と版管理は求められます。だからこそ、任せる範囲と検証と送り先を社内ルールとRFPに書き、FATとSATで確かめる、というのが本記事の編集見解です。
この記事は特定製品の推奨やランキングではありません。製品の機能は各社の説明として紹介します。後半の費用試算は、この記事のための仮の数字です。PLCやラダーの基本は「PLCとは？基本の仕組みと選び方」で解説しているので、本記事では生成AIを使う場面に絞ります。
なぜ今、PLCプログラムに生成AIが話題になるのか
話題になっている理由は、主要ベンダーの製品がこの1〜2年で相次いで表に出てきたことです。2026年10月15日時点で確認できた範囲で、主な動きを整理します。
Siemens は、2026年4月20日のハノーバーメッセで「Eigen Engineering Agent」を発表し、同日から販売を始めたと説明しています。同社によると、100社を超える企業と19か国でのパイロットを経ての発売です。名称は「Industrial Copilot」から「Engineering Copilot TIA」（Preview とベータ）を経て、現在の製品名は Eigen Engineering Agent になっています。同社はパイロット結果に基づく数値として、エンジニアリング効率が最大50%向上したと説明しています。これは同社の自己申告で、条件の異なる他社の数値と比べられるものではありません。
Rockwell Automation は、2024年11月19日に Microsoft との協業拡大を発表し、その中で設計ソフト FactoryTalk Design Studio に生成AIの Copilot を加えたと説明しました。現在の製品ページでは、AI Plan & Build Agents やクラウドでのエミュレーションも紹介されています。
CODESYS Group は、AIシステムから開発環境を操作できる「CODESYS Development System MCP Server」を単体製品として提供していると説明しています。Beckhoff は、2023年の TwinCAT Chat を2025年4月に TwinCAT CoAgent へ発展させたと発表しました。ただし製品ページ TE1700 のステータスは「product announcement」で、一般販売を示す記載は確認できませんでした。
日本のメーカーでは、三菱電機がラダー生成AIを、オムロンが「OMRON Automation Teams（仮称）」を、それぞれ展示会（IIFES 2025）とインタビューで紹介しています。どちらも展示会とインタビューで説明された開発中の内容で、2026年10月15日時点で発売の発表は確認できませんでした。キーエンスの生成AI機能については、公式の発表を確認できませんでした。
タイ側の背景も簡単に触れておきます。タイ投資委員会（BOI）によると、2025年の投資奨励の申請額は1兆8,766億バーツ（3,370件）で、前年比67%増でした。これは申請ベースの数字で、承認額や実投資額ではありません。日本からのFDI申請は1,191億バーツ、311件でした。また、BOI告示4/2569（2026年3月31日官報掲載）は、法律事務所の解説によると、自動車製造（区分3.6と3.8）を対象に自動化とロボットへの投資を奨励するものです。自動車部品、電子部品、食品の工場がそのまま対象になるかは、この資料では確認できません。人材面では、カシコンリサーチが2025〜2029年にタイで約110万人の高度技能人材が必要と推計しています。一方で、STEM系の卒業者の比率は2020年の23.2%から2025年は22.3%に下がりました。制御の分かる人材が限られる中で、既存プログラムの理解や改造を少しでも速くしたい、という需要が背景にあると本記事では考えます。
PLCプログラムの生成AIでできること：作業の6類型
各社の説明をもとに、PLCプログラムで生成AIが関わる作業を6つに分けます。どの作業から始めるかが、後で述べるルール①の出発点です。
1つ目は新規作成です。Siemens は Eigen Engineering Agent の製品ページで、SCL と LAD の生成を挙げています。CODESYS は MCP Server 経由で POU や PLC コードを生成できると説明しています。
2つ目は改造です。Siemens は既存コードの改修を、三菱電機は既存ラダーとコメント、改造指示を与えると改造後のラダーと説明文、フローチャートを出すデモを紹介しています（開発中の内容です）。
3つ目は既存コードの解読とコメント付けです。Rockwell は、他人が書いたコードについて、ラング、ルーチン、プログラム、プロジェクト全体を選んで Copilot に内容を分解し説明させられると説明しています。Siemens もレガシーロジックの解説とコメント付けを機能に挙げています。CODESYS も既存コードの解説を挙げています。
4つ目はレビューとエラー修正です。Siemens はコンパイルや文法エラーの修正とスタイルガイドのチェックを、CODESYS はコーディングエラーの検出と修正を挙げています。Copia Automation は、Copia AI の製品ページで品質改善の提案を挙げています。
5つ目はテスト作成です。Siemens はテストロジックの生成を挙げています。Schneider Electric は、公式ブログで Copilot が同社の検証済みライブラリと多層のガードレールを使って、PLCコードを生成し、説明し、テストすると書いています。
6つ目はドキュメント作成と翻訳です。Copia Automation は、ルーチンやコメント、概要といったPLCコードのドキュメントの自動生成を挙げています。Siemens はプロジェクトの自動ドキュメント化と、PLCやHMIのテキストの翻訳を挙げています。タイ人の保全担当者向けにコメントを訳したい工場にとっては、関心の高い用途でしょう。
なお、Schneider Electric は公式ブログで、開発時間を最大30〜50%短縮できると説明しています。これも同社の説明で、条件の異なる他社の数値とは比べられません。
ラダー（LD）と構造化テキスト（ST）で難しさが違う
PLCの言語によって、生成AIの扱いやすさが違うと報告されています。まず言語の定義を確認します。2025年5月22日に発行された IEC 61131-3 の第4版について、IEC の公式要旨は、テキスト言語の ST と、グラフィカル言語の LD と FBD からなる言語群の構文と意味を規定すると説明しています。SFC は、プログラムやファンクションブロックの内部を組み立てる要素として定義されています。第4版の主な変更として、UTF-8 文字列の追加が挙げられています。
研究では、テキスト言語の ST について、生成の成果を報告する論文が複数あります。2023年の論文（ABB の研究者による探索的研究）は、10カテゴリ100のプロンプトを GPT-4 で試し、多くの場合に文法的に正しい ST が生成されたと報告しています。2024年の別の論文は、公開されている学習データに ST が少ないことと構文の複雑さを課題に挙げ、コンパイラのフィードバックを使った学習でコンパイル成功率が上がったと報告しています。
一方、ラダーは難しいとされています。2024年の論文の条件では、例を複数与えると単純な要件の SFC は正しく生成できたものの、LD の自動生成は非常に単純なケースでも課題が残ると報告されています。三菱電機の開発者もインタビューで、プロンプトの工夫や GX Works3 内部のロジックを使わないと、今のLLMではほとんどラダープログラムを生成できない、という趣旨を述べています。同社が2026年3月のインタビューで説明した開発中の構成では、ラダーには GPT、ST には Claude のモデルを使っているとのことでした。ただし、これは開発中の構成で、サービスの形によって変わりうると本人も述べています。製品の仕様ではありません。
ここで紹介した論文は2023〜2025年のもので、使われたモデルは現在の最新モデルではありません。それでも、ラダー中心の工場では「生成」より「解読」のほうが入りやすい、という考え方の材料にはなると本記事では考えます。
研究が示す限界と、検証を組み込む考え方
研究で繰り返し示されているのは、LLMを単体で使うのではなく、検証の仕組みと組み合わせると結果が良くなる、という点です。
LLM4PLC（2024年の論文）は、当時の GPT-4 などのLLMは、産業制御システム向けの有効なプログラムを生成できなかったと書いています。そこで、文法チェッカー、コンパイラ、SMV 検証器という外部の検証ツールと、ユーザーのフィードバックを使う反復の仕組みを提案しました。2024年の論文の条件では（FischerTechnik の製造テストベッドで、GPT-3.5、GPT-4、Code Llama などを使用）、生成成功率は47%から72%に、専門家によるコード品質評価は10点満点で2.25から7.75に上がったと報告しています。72%は検証ツールとフィードバックを組み込んだ場合の数字で、単体のLLMの性能ではありません。残りの約3割は失敗しています。
Agents4PLC（2024年の論文）は、生成、コンパイル、形式検証、デバッグを複数のLLMエージェントに分担させ、閉ループを作る仕組みです。形式検証には nuXmv や PLCverif を使っています。論文自身が、LLMで生成したコードには大きな不確実性があり、コンパイルに失敗したり要件を満たさなかったりすることがあると書いています。形式仕様を定義すること自体がユーザーにとって難しい点も課題として挙げています。
Spec2Control（2025年の論文、ABB の研究者）は、プロセス制御システム（DCS）のグラフィカルな制御ロジックを自然言語の要求から生成するもので、2025年の論文の条件では、制御戦略の接続の98.6%を正しく生成したと報告しています。これは DCS についての結果で、工場のディスクリートなPLCのラダーにそのまま当てはまる数字ではありません。
ドイツの Fraunhofer IKS は、2025年1月に始まった3年計画の研究プロジェクトで、AIが生成する制御コードの信頼性を測るベンチマークを作っていると説明しています。生成した ST コードを、静的解析、仕様からAIが作るユニットテスト、ソフトPLCと機械のデジタルツインでのシミュレーション、の3段階で評価する流れです。同研究所は、産業コードの多くが企業の知的財産であるため、ST 向けのベンチマークが不足しているとも指摘しています。
これらを工場の実務に置き換えると、生成物は「コンパイルが通るか」「決めた規則に沿っているか」「テストで意図どおり動くか」「シミュレーションで設備と合わせて動くか」「人が読んで説明できるか」を順に確かめ、最後に実機のFATとSATに進む、という流れになります。本記事ではこの流れを検証パイプラインと呼びます。
主要ベンダーの提供状況と、同社が説明している機能
主要ベンダーの状況を表にまとめます。ベンダーはアルファベット順で、優劣や推奨を示すものではありません。提供状況は2026年10月15日時点で確認できた範囲です。確認できなかった欄は「公式資料で確認できず」としています。
| ベンダー | 製品、機能名 | 提供状況 | 同社が説明する主な機能 | データの扱いの記載 |
|---|---|---|---|---|
| Beckhoff | TwinCAT 3 CoAgent for Engineering（TE1700）。前身は TwinCAT Chat | 製品ページの表記は「product announcement」。一般販売を示す記載は確認できず | 自然言語とプロジェクトの文脈に基づくPLCコードの提案、I/O設定の提案、Beckhoff Information System への直接アクセス | 2023年の TwinCAT Chat は各LLMのホストクラウドに接続する方式と説明。TE1700 は公式資料で確認できず |
| CODESYS | CODESYS Development System MCP Server | 単体製品として提供中（CODESYS V3.5 SP22 以上、Professional Developer Edition のバンドル） | AIシステムからの遠隔操作による POU とPLCコードの生成、コーディングエラーの検出と修正、既存コードの解説 | クラウドAIとローカルLLMの両方とやり取りできると説明。OpenVINO によるローカルLLMは研究段階 |
| Copia Automation | Copia AI | 公式資料で確認できず | ドキュメントの自動生成、コードブロックの要約、品質改善の提案、定型タスクのコード生成。マルチベンダー対応と説明 | 公式資料で確認できず |
| Mitsubishi Electric | ラダー生成AI（名称未定） | 開発中。展示会とインタビューで説明された段階 | 仕様書からのラダー、フローチャート、説明文の出力。既存ラダーの改造案の出力（いずれもデモ） | 公式資料で確認できず |
| OMRON | OMRON Automation Teams（仮称） | 開発中。2026年度中の投入予定とインタビューで説明。正式リリースは確認できず | 過去のラダー資産の検索と解説、STプログラムの自動生成、エンジニアリング支援 | インタビューで、LLMに学習させず、クラウドサーバに情報を残さない設計と説明（計画中のサービス） |
| Rockwell Automation | FactoryTalk Design Studio の Copilot、AI Plan & Build Agents | 提供中（Copilot は2024年11月発表）。無料トライアル90日 | コード生成、コードの説明、トラブルシューティング、デバイス設定、要件からの実装計画づくり | ISO 27001 と SOC 2 の認証、GDPR 準拠を説明。学習利用の有無と処理地域は公式資料で確認できず |
| Schneider Electric | PLC Code Generation Copilot（EcoStruxure Automation Expert Platform） | 2025年5月の発表で同プラットフォーム内での提供とされる。一般提供の範囲（地域、版）は確認できず | 検証済みライブラリとガードレールを使ったPLCコードの生成、説明、テスト | 公式資料で確認できず |
| Siemens | Eigen Engineering Agent（旧 Engineering Copilot TIA） | 2026年4月20日発売。TIA Portal V19、V20、V21 の有効なライセンスが必要 | SCL と LAD の生成と改修、テストロジック生成、エラー修正、スタイルガイドチェック、ドキュメント化、レガシーロジックの解説、テキストの翻訳 | 入出力プロンプトはローカルにだけ保存し、PLCコードやプロジェクトファイルを学習に使わないと説明。EU顧客のデータはEU域内で処理。タイの顧客の処理地域は公式資料で確認できず |
表を読むときの注意が3つあります。
1つ目は、提供状況が大きく違うことです。発売済み、発表のみ、開発中が混在しています。開発中の機能を前提に計画を立てると、時期がずれる可能性があります。
2つ目は、データの扱いを他社に当てはめないことです。「学習に使わない」「ローカルに保存する」は Siemens Eigen の公式ドキュメントの記載です。また「クラウドに保存しない」は「クラウドで処理しない」と同じ意味ではありません。Siemens の前身の Preview 版は、クラウド上のマイクロサービスとLLMを使う構成だったと同社は説明しています。
3つ目は、人の関与に触れている各社の説明が、いずれも人の確認を前提にしていることです。Schneider Electric は公式ブログで「自律的なAIコーディングではなく、人の管理を残すAI支援ワークフロー」と書いています。Rockwell は、エンジニアが適用前に推奨内容をレビューし修正すると説明しています。Siemens の Preview 版の利用規約は、生成コンテンツを本番利用に使うことを意図しないと明記していました。製品版 Eigen についても、同社はレビュー可能な状態になるまで自己検証を繰り返すと説明しており、出力は人のレビューに回る前提です。三菱電機の開発者は、生成AIの回答を確認せずに装置へ書き込む使い方は想定していないという趣旨を述べています。オムロンはインタビューで「AIはハルシネーションを起こすため、100％正確なものは技術的に出力できない」と述べています。
ルール①：AIに任せる作業の範囲を決める
最初のルールは、どの作業をAIに任せるかです。6類型ごとに、始めやすさと検証の重さを整理すると次のようになります。これは各社の説明と研究をもとにした本記事の考え方で、数値の評価ではありません。
| 作業の類型 | 始めやすさ | 主なリスク | 検証の重さ |
|---|---|---|---|
| 解読とコメント付け | 始めやすい | 説明の誤りで、保全担当者が誤解する | 軽い（人が原本と照らして読む） |
| ドキュメント作成と翻訳 | 始めやすい | 専門用語や信号名の誤訳 | 軽い〜中程度 |
| レビューとエラー修正 | 中程度 | 指摘の見落とし、修正案の副作用 | 中程度 |
| テスト作成 | 中程度 | テスト自体が仕様を取り違える | 中程度 |
| 改造 | 慎重に | 既存の動作を意図せず変える | 重い（差分確認、シミュレーション、実機確認） |
| 新規作成 | 慎重に | 仕様の誤解、異常系の抜け | 重い |
本記事では、最初の一歩として「既存プログラムの解読とコメント付け」から始めるのが入りやすいと考えます。理由は3つあります。
まず、生成物が装置の動作を変えないことです。解説やコメントが間違っていても、プログラムの動作には影響しません。人が原本と照らして確認できます。
次に、需要が大きいことです。三菱電機は、IIFES 2025 の後にラダーと ST の「解説生成」機能の開発にも着手したと説明しています。信頼性を担保しにくい生成より受け入れられやすいため、という理由です。オムロンはインタビューで、過去資産の流用は同社の調べで8割以上のケースだと述べ、過去のラダー資産を検索してAIが解説する機能を紹介しています（いずれも同社の調査と説明で、業界統計ではありません）。Rockwell と Siemens も、発売済みの製品で既存コードの説明や解説の機能を挙げています。
最後に、効果を測りやすいことです。1本のプログラムを読み解くのにかかった時間は、導入前と導入後で比べられます。
安全関連の回路は、当面はAIに任せる範囲の対象外にしておく、という選択肢もあります。安全関連の扱いは後の章で詳しく述べます。
前任者のプログラムを引き継ぐ場面での確認手順は「三菱PLCプログラムの引継ぎ」で整理しています。生成AIで解読を速めても、バックアップの確保や、実機とソースの一致の確認といった引継ぎの基本は変わりません。
ルール②：生成物の検証手順を決める
2つ目のルールは、生成物をどう確かめるかです。研究とベンダーの説明から、次の6段階を社内の手順として書き出すことを勧めます。
第1段階はコンパイルです。開発環境で文法エラーがなく通るかを確かめます。Siemens や CODESYS は、コンパイルエラーやコーディングエラーの修正を機能として挙げています。
第2段階は静的チェックです。命名規則、コメントの書き方、使ってよい命令やデバイスの範囲など、自社のスタイルに沿っているかを確かめます。Siemens はスタイルガイドのチェックを機能として挙げています。自社の規則が文書になっていなければ、まずそれを作ることが先になります。
第3段階はテストです。仕様からテストケースを作り、意図どおりの入出力になるかを確かめます。テストをAIに作らせる場合は、そのテスト自体を人が確認します。
第4段階はシミュレーションと仮想立上げです。ソフトPLCや設備のモデルと組み合わせて動かし、タイミングやインターロックを確かめます。Rockwell は、FactoryTalk Design Studio の v2.06 で「FactoryTalk Logix Echo as a Service」によるクラウドエミュレーションを統合し、ハードウェアを待たずに制御ロジックを作成、検証できると説明しています。オムロンは、インタビューでフェーズ1としてPLCを仮想化してAI生成物を検証する構想を述べています（開発中の内容です）。仮想立上げの進め方は「ロボットシミュレーションと仮想立上げ」を参考にしてください。
第5段階は人のレビューと承認です。誰がレビューし、誰が承認するかを名前で決めます。レビューでは「このロジックを自分の言葉で説明できるか」を確かめます。説明できない箇所は、動いたとしても採用しない、という基準が分かりやすいでしょう。
第6段階は版管理です。どの版をいつ、誰が、どの理由で変えたかを残します。AIが生成した箇所に印を付けておくと、後で問題が出たときに追いやすくなります。
この6段階のあとに、実機でのFATとSATに進みます。作業の類型によって、どの段階まで必要かは変わります。解読とコメント付けなら第5段階の人の確認が中心で、改造や新規作成なら全段階が必要になる、という考え方です。
ルール③：ソースと設備情報の送り先を決める
3つ目のルールは、PLCのソースや設備の情報をどこへ送るかです。ここはツールごとに設計が違うので、一般論で判断できません。
公的機関の考え方として、米国の CISA など9機関が2025年12月3日に出した共同指針「Principles for the Secure Integration of Artificial Intelligence in Operational Technology」があります。この指針は重要インフラの事業者向けで、主な対象は運用中のAIです。PLCのコーディング支援を規制する文書ではありません。ただし、OTデータの扱いの考え方として参考になります。指針は、外部の管理下でホストされるAIモデルに機密データを共有しないこと、AIベンダーがOTデータにどうアクセスし、どう使うかを把握することを求めています。優先して守るデータとして「エンジニアリング構成データ」を挙げ、その例にネットワーク図、資産台帳、運転シーケンスの文書、安全関連情報、ロジック図、回路図を含めています。さらにベンダーに対して、学習利用を含むデータ利用方針、オンプレミスや常時接続なしで動かせるか、AI機能を無効化できる条件などを確かめるよう勧めています。
ベンダーの説明はさまざまです。Siemens は Eigen について、入出力プロンプトをローカルにだけ保存し、PLCコードやプロジェクトファイルを学習に使わないと説明しています。ただし、EU顧客のデータをEU域内で処理するという記載はあっても、タイの顧客の処理地域は確認できませんでした。CODESYS は MCP Server がクラウドAIとローカルLLMの両方とやり取りできると説明しています。オムロンは計画中のサービスについて、LLMに学習させずクラウドサーバに情報を残さない設計だと述べています。Rockwell、Schneider Electric、三菱電機、Copia Automation については、学習利用の有無を明記した公式記載を確認できませんでした。
タイの個人情報保護法（PDPA）との関係も整理しておきます。PDPA は、生存する個人を識別できる情報を保護する法律です。PLCのソースコードや設備の情報は、通常は個人データに当たらないと考えられます。クラウドのAIに送るかどうかは、主に営業秘密、顧客との秘密保持契約、知的財産の問題になると本記事では考えます。ただし、コメントに作業者名が入っている場合や、作業者IDを扱うロジックやログを送る場合は、PDPA の対象になりうる点に注意が必要です。
実務では、送る前に次の点を確かめます。顧客から預かった図面や仕様が含まれていないか。秘密保持契約で第三者への開示が制限されていないか。作業者名などの個人情報がコメントに入っていないか。社内の情報分類で、どのランクの情報まで外部のAIに送ってよいか。生成AIへの情報の出し方の全体像は「生成AIの情報漏洩対策」で解説しています。社外に出したくない場合の選択肢として、社内でモデルを動かす方法は「ローカルLLMの導入」を参考にしてください。
安全関連のプログラムと規格の関係
安全規格とAIで書いたコードの関係は、誤解されやすい点です。確認した規格の公式要旨や条文には、生成AIで書いたコードの可否を定めた記述は見当たりませんでした。言えるのは、書き手が人でもAIでも、ソフトの検証、ツールを選んだ根拠、制御ロジックの誤りへの対策が求められる、というところまでです。
IEC 61508-3（ソフトウェア要求）の公式要旨によると、この規格は安全関連システムを開発するために使うソフトウェアと、開発や設計のツール、言語変換器、試験ツールなどのサポートツールへの要求を含みます。IEC 61508 では、オフラインのサポートツールを T1〜T3 に分類します。T3 は、実行コードに直接または間接に寄与する出力を生成するツールで、仕様に適合している証拠が求められます。生成AIをこのどれに当てはめるかを示した規格や公的機関、認証機関の資料は確認できませんでした。そのうえで本記事の推論として、AIの出力がそのまま実行コードになるなら、コンパイラと同じ考え方で、ツールの選定根拠と検証を求められる可能性がある、と考えます。これは推論であり、規格の要求として断定するものではありません。
ISO/IEC TR 5469:2024 は、安全関連機能の設計や開発にAIシステムを使う場合も扱う技術報告書です。適合を求める要求規格ではありません。ISO 13849-1:2023 と IEC 62061:2021 は、機械の安全関連制御システムの設計の要求を定めていますが、公式要旨に生成AIの記載はありません。
欧州向けの機械を作る場合は、EU機械規則（EU）2023/1230 も関係します。欧州委員会は、この規則を2027年1月20日から義務的に適用すると明記しています。附属書III 1.2.1(c) は、制御システムのロジックの誤りが危険な状況を生まないことを求めています。第三者による適合性評価が必須となる区分に挙げられているのは、機械学習による自己進化的な挙動を持つ安全部品やシステムです。前文(55)は、学習や進化ができず、特定の自動機能を実行するようにプログラムされただけのソフトウェアには、この第三者評価の規定を適用しないとしています。生成AIで書いたあとに固定されたPLCプログラムは、それ自体が学習も進化もしないので、この文言では自己進化型に当たらないと読めます。ただしこれは本記事の解釈で、当局の見解ではありません。また、ロジックの誤りを防ぐ要求は、AIで書いたかどうかに関係なくかかります。
TÜV などの認証機関が、安全関連ソフトへのAI生成コードの使用について出した公式見解は、今回は確認できませんでした。安全PLCの妥当性確認の進め方は「安全PLCの妥当性確認」で解説しています。本記事の考え方としては、安全関連の回路は当面AIに任せる範囲の対象外とし、扱う場合も通常の安全関連ソフトと同じ検証と承認の手順を通す、という線引きが分かりやすいと考えます。
OTセキュリティと版管理
生成AIを使うと、ソースの変更が速く、多くなります。そのぶん、変更の記録と保護が大事になります。
EU機械規則の附属書III 1.1.9 は、適合に重要なソフトとデータを特定し、不正や偶発的な改変から守ること、ソフトの改変の証跡を集めることを求めています。1.2.1(f) は、上市後にアップロードした安全ソフトの版と介入のデータを追跡するログを5年間有効にすることを求めています。欧州向けの設備でなくても、改造の版と理由を残すという考え方は、AIを使う工場の版管理の目安になります。
IEC 62443-4-1 は、産業用の制御システム向け製品を安全に開発するプロセスの要求を定めた規格です。ただし、適用されるのは製品の開発者と保守者で、インテグレータやユーザーには適用されないと公式要旨に書かれています。工場やSIerに直接かかる規格ではなく、AI機能を持つツールを出すベンダーに何を求めるかを考える材料として使うのが適切だと本記事では考えます。
実務で決めておきたいのは次の点です。ソースのバックアップを、改造の前と後に残すこと。実機のプログラムとサーバのソースが一致しているかを定期的に確かめること。AIツールが開発環境やPLCにどの権限でつながるかを把握すること。MCP のように外部のAIから開発環境を操作できる仕組みを使う場合は、操作できる範囲を絞ることです。工場でAIエージェントを使うときのセキュリティは「工場AIエージェントのセキュリティ」で整理しています。
PLC更新・リプレースでの移行に使うときの注意
PLCの更新やメーカー変更の際に、古いプログラムを新しい環境へ移す作業にも生成AIが使われ始めています。
CODESYS は、外部ソリューションとして KS Solutions AG の SyntaxShift を紹介しています。Siemens の IL や SCL と CODESYS の ST の間をAIで変換するもので、同社のページでは「CODESYS Store に近日登場」と説明されています。Siemens は Eigen の機能として、レガシーロジックの解説とコメント付けや、WinCC Unified での VBScript から JavaScript への移行を挙げています。
移行に使う場合は、変換結果を新しく書いたプログラムと同じように扱うことが大切です。変換前と変換後で、入出力の割り付け、タイマーやカウンタの設定、異常時の動作が一致しているかを差分で確かめます。そのうえで、ルール②の検証手順を通し、実機での確認に進みます。古いプログラムを先にAIで解読してコメントを付け、仕様を文書にしてから移行する、という順番も考えられます。
更新するかどうか、いつ更新するかの判断は「PLC更新とリプレースの判断」で解説しています。
外注先・SIerに生成AIを使わせる場合の取り決め
自社で生成AIを使わなくても、外注先のSIerが使う場合があります。発注者として、次の点を取り決めておくことを勧めます。
1つ目は、使うツールと送り先の開示です。どのツールを使い、ソースや仕様をどこへ送るか、学習に使われる設定かどうかを事前に知らせてもらいます。顧客の図面などを預けている場合は、秘密保持契約との関係も確かめます。
2つ目は、生成箇所の記録です。AIが生成または改造した箇所を、コメントや変更記録で分かるようにしてもらいます。
3つ目は、レビュー責任の所在です。AIを使ったかどうかに関係なく、納品するプログラムの内容に責任を持つのは受注者である、と契約に書いておくと誤解が減ります。
4つ目は、ソースの納品です。実機に書き込んだ版と同じソースを、コメント付きで納品してもらいます。
5つ目は、コメントの言語です。タイ人の保全担当者が読めるよう、タイ語や英語のコメントを求めることもできます。生成AIの翻訳機能を使う場合でも、信号名や専門用語の訳は人が確かめます。
外注先の選び方や発注の一般的な進め方は「PLCプログラム開発の外注」で解説しています。
RFPに書く要件とFAT・SATの受入基準
ツールを導入する場合も、外注先に生成AIの利用を認める場合も、要件をRFPに書いておくと比較と受入が楽になります。社内の利用ルールの作り方は「生成AIの社内利用ルール」も参考にしてください。
| 項目 | RFPに書く内容 | 確認の方法 |
|---|---|---|
| 対象作業の範囲 | 6類型のうちどれに使うか。安全関連の回路を対象にするか | 提案書の記載 |
| 対象PLCとソフトのバージョン | メーカー、機種、開発ソフトのバージョン | 動作環境の資料 |
| データの送り先と学習利用 | 処理する地域、クラウドかローカルか、学習に使うか | 公式文書と契約条項 |
| ログの保存 | プロンプトと出力の保存場所と期間 | 設定画面と文書 |
| 生成箇所の識別 | AIが生成した箇所をどう記録するか | サンプル納品物 |
| 検証手順 | コンパイル、静的チェック、テスト、シミュレーションのどこまで行うか | 手順書と記録 |
| レビューと承認者 | 誰がレビューし、誰が承認するか | 体制表 |
| 安全関連の扱い | 対象外にするか、扱う場合の追加手順 | 提案書と手順書 |
| 版管理 | 版の付け方、バックアップ、実機との一致確認 | 運用手順 |
| 教育 | 利用者への教育の内容と回数 | 教育計画 |
FAT（工場での受入試験）では、代表的な改造指示をいくつか用意し、次の点を確かめます。コンパイルが通るか。用意したテストが通るか。シミュレーションで意図どおり動くか。担当者がそのロジックを読んで説明できるか。
SAT（現地での受入試験）では、実機での動作確認、異常系の確認、問題が出たときに元の版に戻す手順の確認を行います。
合格の基準となる数値（たとえば検証を通る割合や、人の手直しにかかる時間）は、自社で合意した値を書きます。本記事では具体的な値を推奨しません。試行（PoC）をいつ終えて本導入に進むかの決め方は「AI PoCの終了基準」で解説しています。
費用と効果のモデル試算（仮の数字）
ここからは、この記事のための仮の数字で試算します。実際の工場の数字ではありません。
想定するのは、タイの日系自動車部品工場です。生産技術の制御担当が3人いて、PLCは複数メーカーが混在しています。小さな改造は外注SIerに出しています。
前提となる年間の費用は2つです。AとBは別の作業として数えており、同じ費用を2回数えているわけではありません。
- A 既存プログラムの解読とドキュメント作成にかかる社内の時間は、年600時間で、1時間500 THBとすると300,000 THB/年です。
- B 小さな改造の外注費は、年20件で1件40,000 THBとすると800,000 THB/年です。
- 合計は1,100,000 THB/年です。
対策は、生成AIツールの導入、検証環境、社内ルールと教育、ソースの整理と版管理です。
- 初期費用は520,000 THBです。内訳は、検証環境（ソフトPLCやシミュレーションとテスト手順）220,000 THB、社内ルール作りと教育150,000 THB、ソースの整理と版管理150,000 THBです。
- 年間の運用費は90,000 THB/年です。内訳は、ツール利用料（仮）60,000 THBと、生成物の追加レビューの工数30,000 THBです。
| 項目 | 基準ケース | 感度（効果が小さい場合） |
|---|---|---|
| A の削減率 | 40% | 20% |
| A の効果 | 300,000 × 40% = 120,000 THB | 300,000 × 20% = 60,000 THB |
| B を社内で行う件数 | 年5件 | 年2件 |
| 減る外注費 | 5 × 40,000 = 200,000 THB | 2 × 40,000 = 80,000 THB |
| 増える社内工数 | 5 × 40時間 × 500 = 100,000 THB | 2 × 40時間 × 500 = 40,000 THB |
| B の効果（差し引き） | 100,000 THB | 40,000 THB |
| 効果の合計 | 220,000 THB/年 | 100,000 THB/年 |
| 年間の運用費 | 90,000 THB/年 | 90,000 THB/年 |
| 年間の純効果 | 130,000 THB/年 | 10,000 THB/年 |
| 初期費用 | 520,000 THB | 520,000 THB |
| 回収年数 | 520,000 ÷ 130,000 = 4.0年 | 520,000 ÷ 10,000 = 52.0年 |
基準ケースでは、A の時間を40%減らせると120,000 THB/年の効果になります。B のうち年5件を社内で行えると、外注費200,000 THBが減る一方で、社内工数として5件 × 40時間 × 500 THB = 100,000 THBがかかるので、差し引き100,000 THB/年です。効果の合計は220,000 THB/年で、運用費90,000 THB/年を引いた純効果は130,000 THB/年、初期費用520,000 THBの回収は4.0年です。
効果が小さい場合（A は20%、B は年2件）は、A が60,000 THB、B が80,000 THBの外注費減から社内工数40,000 THBを引いて40,000 THBで、効果の合計は100,000 THB/年です。純効果は10,000 THB/年にとどまり、回収は52.0年と、実質的に回収できません。
この試算の読み方を補足します。効果の割合と件数は仮定です。検証とレビューの費用は使う量に関係なくかかるので、効果が小さいと回収できません。だから最初は対象作業を絞り、解読とコメント付けのように検証が軽く、量の多い作業から効果を測るのが現実的だと本記事では考えます。安全関連の改造や、取り違えたときの損失（設備停止や品質事故）は、この試算に入れていません。導入の前に、過去12か月の改造件数、外注費、既存プログラムの解読にかかった時間を数えておくことを勧めます。PoCで代表的な改造指示を試し、検証を通った割合と人の手直しの時間を測るまでは、効果に数えないほうが安全です。
費用の公開情報についても触れておきます。Siemens の Eigen Engineering Agent は、Siemens Digital Exchange（S-DEX）の販売ページで、年間サブスクリプションが USD 2,100（1か月の無料トライアル後）と表示されていました。これは米国の課金地域で表示された価格（2026年10月15日時点、税別の場合あり）で、タイでの価格や販売条件は確認していません。同ページでは、1シートに最大3ユーザーを割り当てられ、同時に使えるのは1人と説明されています。Rockwell の FactoryTalk Design Studio には90日の無料トライアルがありますが、公開価格は確認できませんでした。CODESYS の MCP Server は Professional Developer Edition のバンドルで提供されると説明されていますが、公開価格は確認できませんでした。Beckhoff、Copia Automation、Schneider Electric、三菱電機、オムロンについても、公開価格は確認できませんでした。
よくある質問
生成AIでPLCプログラムは作れる？
作れる場面はありますが、人の確認を前提にした下書きや改造案として使うものだと考えてください。人の関与に触れている各社は、いずれも人がレビューしてから使う前提で機能を説明しています。研究でも、検証ツールを組み込んだ仕組みで成功率が上がったと報告されていますが、2024年の論文の条件でも約3割は失敗していました。
ラダーとSTではどちらが生成しやすい？
研究では、ST については生成の成果を報告する論文が複数あります。一方で、2024年の論文の条件では、ラダー（LD）の自動生成は非常に単純な例でも課題が残るとされました。三菱電機も、工夫なしの汎用LLMではラダーをほとんど生成できないという趣旨を述べています。ただし論文は2023〜2025年のもので、モデルは最新ではありません。
生成したプログラムをそのまま使ってよい？
勧めません。コンパイル、静的チェック、テスト、シミュレーション、人のレビューと承認を通し、実機のFATとSATで確かめてから使うことを本記事では勧めます。Siemens の Preview 版の利用規約は、生成コンテンツを本番利用に使うことを意図しないと明記していました。
安全規格はAI生成コードを禁止している？
確認した安全規格の公式要旨や条文には、生成AIで書いたコードを禁止または許可する記述は見当たりませんでした。ただし、書き手が人でもAIでも、ソフトの検証、ツールの選定根拠、制御ロジックの誤りへの対策は求められます。本記事では、安全関連の回路は当面AIに任せる範囲の対象外にする選択肢を示しています。
PLCのソースをクラウドAIに送っても大丈夫？
ツールごとにデータの扱いが違うので、一般論では判断できません。処理する地域、学習に使うか、ログの保存場所を公式文書と契約で確かめてください。PLCのソースは通常は個人データに当たりませんが、顧客との秘密保持契約や営業秘密の問題になりえます。コメントに作業者名がある場合は、タイのPDPAの対象になりうる点にも注意が必要です。
既存のラダーの解読にも使える？
使えます。本記事では、最初の一歩として解読とコメント付けから始めるのが入りやすいと考えます。生成物が装置の動作を変えず、人が原本と照らして確かめられるからです。Rockwell と Siemens は発売済みの製品で既存コードの説明機能を挙げており、三菱電機とオムロンも開発中の内容として解説の機能を紹介しています。
PLCプログラムの生成AIツールの費用は？
確認できた公開価格は Siemens Eigen Engineering Agent だけでした。米国の課金地域で表示された価格（2026年10月15日時点、税別の場合あり）は年 USD 2,100 で、タイでの価格は確認していません。他社の公開価格は確認できませんでした。ツール代のほかに、検証環境、教育、ソースの整理、追加レビューの工数もかかります。
まとめ
- PLCプログラムへの生成AIの導入で先に決めるのは、ツールの名前ではなく、①任せる作業の範囲、②生成物の検証手順、③ソースと設備情報の送り先の3つです。
- 主要ベンダーの提供状況は、発売済み、発表のみ、開発中が混在しています。人の関与に触れている各社は、いずれも人の確認を前提に機能を説明しています。
- 研究では、検証ツールを組み込むと結果が良くなると報告されています。ラダーは ST より生成が難しいとされています。
- 最初の一歩は、既存プログラムの解読とコメント付けが入りやすいと本記事では考えます。
- 検証は、コンパイル、静的チェック、テスト、シミュレーション、人のレビューと承認、版管理の6段階を手順に書き、実機のFATとSATで確かめます。
- データの扱いは各社で違います。処理地域、学習利用、ログの保存を公式文書と契約で確かめます。
- 確認した安全規格の公式要旨や条文には、AI生成コードの可否を定めた記述は見当たりません。ロジックの誤りへの対策と改造の検証は、書き手に関係なく求められます。
- 仮の試算では、効果が小さいと回収できません。導入前に改造件数や解読時間を数え、PoCで測ってから効果に数えます。
TOMAS TECH では、どの作業から生成AIを試すかの検討、検証手順やソースの送り先の整理、外注先との取り決めづくりといった段階からでもご相談をお受けしています。タイの工場で複数メーカーのPLCが混在している場合も、現状の整理から一緒に進められます。お気軽にお問い合わせください。
参考情報
- Siemens bringt „Eigen Engineering Agent” auf den Markt（2026-04-20）/ Siemens AG
- Eigen Engineering Agent（製品ページ）/ Siemens
- Data security, Eigen Engineering Agent（Doc v1.5.1）/ Siemens
- Eigen Engineering Agent（S-DEX 販売ページ）/ Siemens
- Engineering Copilot TIA Standard（Preview）/ Siemens
- Rockwell Automation and Microsoft Deliver on a Shared Vision（2024-11-19）/ Rockwell Automation
- FactoryTalk Design Studio（製品ページ）/ Rockwell Automation
- TwinCAT Chat: Using innovative chatbot technology in TwinCAT engineering / Beckhoff
- TE1700 TwinCAT 3 CoAgent for Engineering / Beckhoff
- Engineering at scale: How AI is transforming PLC coding（2025-11-14）/ Schneider Electric Blog
- CODESYS AI-supported Engineering / CODESYS Group
- なぜ三菱電機がラダー生成AIに挑んだのか（1/2）/ MONOist
- なぜ三菱電機がラダー生成AIに挑んだのか（2/2）/ MONOist
- 「そのラダープログラム10年後も読めますか」オムロンが描くAI活用（1/2）/ MONOist
- 「そのラダープログラム10年後も読めますか」オムロンが描くAI活用（2/2）/ MONOist
- オムロンは“チーム生成AI”で効率化 ラダーのプログラム資産検索も / MONOist
- Copia AI / Copia Automation
- LLM4PLC: Harnessing LLMs for Verifiable Programming of PLCs / arXiv
- Agents4PLC: Automating Closed-loop PLC Code Generation and Verification / arXiv
- ChatGPT for PLC/DCS Control Logic Generation / arXiv
- Exploring LLM Support for Generating IEC 61131-3 Graphic Language Programs / arXiv
- Training LLMs for Generating IEC 61131-3 Structured Text with Online Feedback / arXiv
- Spec2Control: Automating PLC/DCS Control-Logic Engineering / arXiv
- Industrial Automation, Setting the Standard for AI-Generated Control Code / Fraunhofer IKS
- IEC 61131-3:2025 Programmable controllers, Part 3 Programming languages / IEC Webstore
- IEC 61508-3:2010 Functional safety, Part 3 Software requirements / IEC Webstore
- ISO 13849-1:2023 Safety-related parts of control systems / ISO
- IEC 62061:2021 Safety of machinery / IEC Webstore
- ISO/IEC TR 5469:2024 Artificial intelligence, Functional safety and AI systems / ISO
- IEC 61508, Why tool qualification / UL（61508 Association 掲載資料）
- Regulation (EU) 2023/1230 on machinery / Publications Office of the EU
- Machinery / European Commission
- IEC 62443-4-1:2018 Secure product development lifecycle requirements / IEC Webstore
- Principles for the Secure Integration of AI in Operational Technology / CISA ほか
- Thailand’s Investment Applications Reach New Highs in 2025 / BOI
- Thailand Unveils New Incentives for Automotive and HEV/PHEV Manufacturing / Tilleke & Gibbins
- AI boom leaves Thai graduates facing a tougher job hunt / The Star
- What to Expect When the PDPA B.E. 2562 Is Fully Enforced in June 2022 / Gala & Associates
