1. はじめに

11月にABEJAに入社した内田です。ABEJAには多くのAIエンジニアがいますが、私のバックグラウンドはAIではなく制御システムインテグレーションが専門です。せっかくAIが売りの企業に入社したので、AIと制御やFAでよく利用されるPLCを組み合わせたテーマで今回のテックブログを書いてみようと思います。

制御システムの開発現場では、以下のような課題がよくあるのではないでしょうか：

複数POU・GVL・Taskにまたがるプロジェクトの可読性の低下
既存プロジェクトを担当することになったが、解析して運用・保守・改修が大変

本記事では、これらの課題に対して以下のアプローチを試みます。

CODESYSのプロジェクトをXML形式でエクスポートし、AI（LLM）に解析させて構造理解・設計書生成を行う。

普通のプログラミング言語で書かれているプロジェクトであれば、テキスト形式のソースコードをそのままAIで解析させたり、VSCodeなどエディタ上でCopilotなどコーディング支援AIを使って対話的に内容把握したり、Deepwikiのようなツールで自動ドキュメント作成を行ったりと、多様なアプローチが可能です。一方で、PLCのプログラミングでは開発環境とコードが密に関係しているため、AIでの支援が得られにくいというのが現状です。ST言語でプログラムを作る場合はテキストとして扱えるため、比較的AIで取り扱いやすいのですが、ラダー（LD）やファンクションブロックダイアグラム（FBD）など、Visual Programingを含む場合は、取り扱いが難しくなります。

CODESYSの場合、プロジェクトの内容をXML形式でエクスポートする機能があります。プロジェクト全体の情報を１つのファイルにまとめることができ、AIへの入力として比較的扱いやすくなります。今回は一度XMLでExportしたものをAIに解析させるアプローチを取ることにしました。

2. CODESYSとは

CODESYSというワードを聞いたことがない方向けに簡単にCODESYSについてご紹介します。 CODESYSは、いわゆるSoftware PLCの一つであり、産業用オートメーション（FA）システムの構築に幅広く使われています。通常のPLCの場合、専用ハードウェアでプログラムが動作しますが、Software PLCの場合、CODESYSのRuntimeが動けば、PLCハードウェアの他、ラズパイのようなSBCやWindows上などでも動作可能です。CODESYSを使ったプログラミングでは、ST言語、FBD、LD、などのIEC 61131-3規格に準拠したプログラミング言語やCFCというCODESYS独自拡張をサポートしており、ユーザーフレンドリーな開発環境を提供しています。開発環境自体は無料で使用可能で、ランタイムも検証用として2時間動作させられるので、気軽に試すことが可能です。

3. 検証環境の準備

検証するにあたり、公式で提供されているサンプルプロジェクトを使用します。なるべく、いろいろなプログラム手法が使われているものを選びたかったので、ST言語、LD、CFCで書かれたファイルを持つ「Refrigerator Control」というExample Projectを使用することにしました。

検証作業環境

今回の検証では以下のソフトウェアを使用しました。

CODESYSバージョン: 3.5 SP21 Patch 1
AIツール:
- ChatGPT（GPT-5.1 Thinking）
- Gemini 2.5 Pro
- GPTでPLCOpenのガイドラインを知識設定したもの
- GeminiのGemでPLCOpenのガイドラインを知識として設定したもの

CODESYSは、比較的新しいV3.5 SP21を使用しました。XMLファイルの解析に使うAIツールには、ChatGPTとGeminiを使用しました。使用したモデルはGPT-5.1 Thinking、Gemini-2.5 Proです。それに加えて、PLCOpenが公開しているコーディングガイドラインなどを知識として設定したGPTとGemを作成し、使用しました。

検証に使うプロジェクト（Refrigerator Control Example）の概要

今回の検証では、CODESYSが公式に公開しているExample Projectのうち、「Refrigerator Control」を使用します。このExampleプロジェクトは、ST言語、LD言語、CFC言語で書かれたコードを含み、かつ、コード量自体はかなり小さいため最初の分析にはちょうど良いと考え選択しました。実際のプロジェクトはもっと大規模なものになると思うので、今回は初めの一歩という位置付けです。

Example Project自体は、CODESYSをインストールした後、以下のフォルダにインストールされています。私の環境では、Archive fileをダブルクリックしてもプロジェクトが読み込まれない場合がありました。その場合、開発環境を開き直接Importしてください。

C:\Program Files\CODESYS 3.5.21.10\CODESYS\Projects\RefrigeratorControl.projectarchive

このアーカイブファイルをCODESYSの開発環境にインポートすると、以下のプロジェクト構造が確認できます。

Exampleの中には、以下のファイルが含まれていました。

PLC_PRGというCFCで書かれたプログラム
SignalsというLDで書かれたプログラム
SimulationというSTで書かれたプログラム
Diagnosis, Live_Visu, VisualizationなどのHMI関連ファイル
Glob_Varというグローバル変数ファイル

その他、タスク構成やライブラリ、使用デバイスについても文書化の際に把握したい情報になります。

AIへ入力するXMLファイルの作成

CODESYSのProjectデータは、2種類のXMLフォーマットでExportすることが可能です。Export機能の詳細は、公式ドキュメントを参照してください。

２種類のXMLは、それぞれCODESYS独自のXMLフォーマットとPLCOpenが定義した標準XMLフォーマットです。CODESYS XML formatでは、全てのCODESYS固有情報を保持することができ、CODESYS環境間のプロジェクト移行やバックアップとして利用できます。一方で、PLCOpen XML formatでは、デバイス固有設定などCODESYS Projectで含まれないものもありますが、異なるPLC間でコード移植を行なう際などに利用されます。また、標準フォーマットの仕様が定義されているので、頑張れば外部ツールでの解析を行なうことも可能です。

プロジェクトデータを実際にExportすると、CODESYS XMLでは、.exportという拡張子のファイルが生成され、PLCOpen形式では、 .xmlという拡張子のファイルが生成されます。本記事では、両方のXMLフォーマットを使用して解析を試みます。実際にExportされたデータについて以下に記載します。

.exportファイル

データサイズ：3.3M 、ファイル行数：45301行、中身はこんな感じです。

<ExportFile>
  <StructuredView Guid="{21af5390-2942-461a-bf89-951aaf6999f1}">
<Single xml:space="preserve" Type="{3daac5e4-660e-42e4-9cea-3711b98bfb63}" Method="IArchivable">
  <Null Name="Profile" />
  <List2 Name="EntryList">
    <Single Type="{6198ad31-4b98-445c-927f-3258a0e82fe3}" Method="IArchivable">
      <Single Name="IsRoot" Type="bool">True</Single>

.xmlファイル

データサイズ：62K 、ファイル行数：1058行、中身はこんな感じです。

<?xml version="1.0" encoding="utf-8"?>
<project xmlns="http://www.plcopen.org/xml/tc6_0200">
  <fileHeader companyName="" productName="CODESYS" productVersion="CODESYS V3.5 SP21 Patch 1" creationDateTime="2025-11-12T17:51:44.3164415" />
  <contentHeader name="RefrigeratorControl.project" modificationDateTime="2025-11-12T17:46:05.0958991">
    <coordinateInfo>
      <fbd>
        <scaling x="1" y="1" />
      </fbd>

4. AIを用いたPLCコードの解析検証

検証のゴール

この記事における検証のゴールを以下のように定めました。

ExportしたXMLの内容をAIで解析・上流仕様書の生成が可能か検証する。
複数のモデルとXMLファイルで出力を比較し、コーディングなしですぐにできる組み合わせの中で最適なものを見つける。
実際の開発・保守業務で使用するために必要なギャップを整理する。

検証方法

検証は以下の流れで行いました。

入力データは、２つのXMLと、XMLからコードに関する部分を抽出したものの計4種類とする。
AIツールは、ChatGPT（GPT-5.1 Thinking）、Gemini 2.5 Proをそのまま使うパターンと、PLCOpenのドキュメントでGPT, Gemを作るパターン。
入力は、「＋」でファイルをそのまま添付。
出力結果と人力でプロジェクトをチェックした結果を比べて、ちゃんと仕様書が出力されているか、情報の網羅性など複数の観点で定性的評価を行う。

設計文書生成の指示は、以下のプロンプトを使用しました。

codesys_doc_gen_instructions · GitHub

検証結果

各ケースでの実際の出力は、こちらのレポジトリにアップロードしました。

出力された設計文書の正確性・完全性の観点では、今回のExampleのような小規模プロジェクトでは、どのモデルでも大域的な構造は正しく抽出されていました。特にプロジェクト名やタスク構成、主要POU構成、主要機能、用途などは正しく抽出できているようです。出力結果を見ると、入力ファイルのXML形式の違いはあまり影響しておらず、使用したモデルの違いの方が影響が大きく出ていました。

生成時間の観点では、モデルと入力ファイルの両方に依存して大きく変わりました。最も短時間で生成が完了したものは、PLCOpen形式のファイルをGeminiで設計書生成した場合で１分程度かかりました。一方で、最も長時間となったのは、gpt-5.1でCODESYS XML形式のファイルを処理した場合で、こちらは5分程度かかりました。その他のケースでは、概ね３分程度でした。

出力された文書品質の観点では、ChatGPTで作成したドキュメントの行数が370行程度に対してGeminiで生成したドキュメントは130行程度でした。ドキュメント内の章立ては、プロンプトの指示に従っており、どの出力でも7章の章立てに整理された文章になっていました。やや、ChatGPTのgpt-5.1 Thinkingで生成した方が説明が細かいように思いました。

今回の簡易的な試行では、PLCOpen XMLで出力し、gpt-5.1 Thinkingで設計書を出力するのが良さそうでした。独自GPTの効果はあまり見られませんでした。今回は分析対象のプロジェクトに標準的な機能しか含まれていなかったので、Motion制御や通信機能を使うものの場合は効果が出てくるかもしれません。

5. 課題

本検証は小規模なExampleプロジェクトを対象とした簡易的な試行であり、実運用レベルのPLCプロジェクトへ適用するにはいくつかの課題が残ります。まずデータ規模に関する問題があります。CODESYS独自の.export形式は数MB・数万行になることが多く、そのままでは多くの大規模言語モデル（LLM）のコンテキストウィンドウを超過してしまいます。そのため、大規模プロジェクトを扱う場合は、よりサイズが小さく構造化されているPLCOpen形式を優先するか、XMLをPOUやモジュール単位で分割して段階的に解析するなど、事前処理が必要です。

次に命名やメタ情報の不統一です。実プロジェクトでは変数名やタグに意味の薄い識別子やアドレス直書きが使われている例が多く、自動解析のみで開発者の意図を正確に把握するのは困難です。このためI/O一覧や回路図、設計コメントといった外部資料を組み合わせて照合（RAG：Retrieval-Augmented Generation）するワークフローを導入し、変数意味の自動解決や検証を行う必要があります。

さらに言語・表現の観点では、ラダー（LD）やファンクションブロックダイアグラム（FBD）、CFCといったグラフィカル言語の情報がテキスト化されても読みやすさや意味が失われる場合があります。これらは単にテキストとして解析するだけでなく、AIに図表（ブロック図や状態遷移図）や要約テキストを生成させるなど可視化を併用することで理解が格段に進むかもしれません。また、XML（特にPLCOpen）からはロジック自体は抽出できても物理I/Oのアドレス割当やデバイス固有設定が含まれないケースがあり、移行や実機検証の際にはデバイス設定情報を別途取得することが必須です。

6. まとめと今後の展望

今回の検証では、CODESYS ProjectをExportしたXMLファイルに対してAIを用いた解析を試みました。規模の小さいプロジェクトでは、概ねプロンプトで指示した内容の情報を拾ってきてくれました。開発環境上はテキスト化されていないLDやCFCのプログラムについても解析できる点は、古いプロジェクトの保守や引き継ぎに役立つのではないかと思います。

今回は公式のExample Projectを使用しましたが、実際の現場ではより複雑なプロジェクトが多く存在します。実際のプロジェクト規模でも同様にAIを活用し、面倒なドキュメンテーションや新しく担当するプロジェクトの解析に役立てることができるか、今後も検証を続けていきたいと考えています。

最後に、PLCベンダーでもAI技術の活用に関する取り組みが進んでいます。今後、CODESYS自体にAI支援機能が組み込まれる可能性もあり、制御システム開発の効率化が期待されます。この動きにも注目していきたいと思います。

参考資料

We are hiring!

ABEJAは、テクノロジーの社会実装に取り組んでいます。技術はもちろん、技術をどのようにして社会やビジネスに組み込んでいくかを考えるのが好きな方は、下記採用ページからエントリーください！（新卒の方やインターンシップのエントリーもお待ちしております！）

careers.abejainc.com

ABEJA Tech Blog

中の人の興味のある情報を発信していきます

CODESYSプロジェクトをAIで読み解く