「SemaPLC」とは何か──工場の制御盤コードをAIに書かせて、動くかどうかまで確かめるharness

PLC（Programmable Logic Controller、プログラマブルロジックコントローラ）は、工場のベルトコンベアやロボットアーム、空調設備などを制御する産業用のコンピュータだ。ここに書き込むコード（POU＝Program Organization Unit、プログラム編成単位）をLLMに生成させる試みはすでに動き始めているが、「生成されたコードが既存の工場プロジェクトに組み込まれ、実際に正しく動くか」までを検証した例はほとんどなかった。この隙間を埋めようとする研究が、家電大手Midea傘下の研究チーム（Midea AIRC）が、ロボットメーカーKUKA（Mideaが買収し傘下に置く）・上海交通大学（SJTU）・浙江大学（ZJU）と共同で2026年8月19日にarXivで公開した「SemaPLC」だ。

3行まとめ

1. SemaPLCは、仕様適合・コンパイル・実機PLCランタイム上での動的挙動という3層の外部検証がすべて通るまでタスクを完了と判定しないエージェントharnessで、Midea AIRC・KUKA・SJTU・ZJUの共著論文（arXiv:2608.18565）として2026年8月19日に公開された。
2. 117件の独立POUタスク（Function track）でMiniMax-M2.7・MiniMax-M3・Qwen3.5-Plus・DeepSeek-V4-Flash/Pro・GLM-5.2・GPT-5.5の7モデル全てにおいて既存手法（LLM4PLC・AutoPLC・Agents4PLC）を上回る厳密検証済み合格率を記録し、平均72.6%（最強ベースラインのAutoPLCは63.9%）だった。
3. 実プロジェクトへの組み込みを問う65件のタスク（Project track）では、静的スコアの差は全手法10ポイント以内に収まる一方、実機ランタイムで実行トレースを比較する動的スコアはSemaPLCが52.2、既存手法が22.4〜31.4と大きく開いた。

「モデルが完了と判断したら終わり」をやめる

論文の要旨で強調されているのは、完了判定の仕組みそのものを変えたという点だ。通常、コーディングエージェントはモデル自身が「これで良さそうだ」と判断した時点でタスクを完了とみなす。SemaPLCはこれを許さない。仕様との整合性・コンパイルの成否・実機ランタイム上での挙動という3つの「ログに残る外部チェック」がすべて通るまで、タスクは完了と判定されない。これは前回の記事で紹介した「ハーネスエンジニアリング」の分類でいえば、行動後に観測して自己修正を促す「Sensors（フィードバック制御）」を、しかも人間の目に触れる前の完了条件そのものに埋め込んだ設計といえる。

検証は3段階に分かれている。まず仕様（specification）との整合性、次にコンパイルの成否、最後に実機のPLCランタイム上での挙動だ。論文はこの3段階のうち「動的挙動（dynamic behavior）」が最も情報量が多いと述べている。生成したロジックと正解ロジックの両方を実際のPLCランタイムにデプロイし、実行トレースを比較することでこの動的挙動を測定している。

数字で見る差:Function track（117タスク）

既存ベンチマークに合わせた117件の「独立POUタスク」では、SemaPLCは7つのモデルすべてで最も高い「厳密検証済み合格率」を達成した（分母117、判定不能・空生成は失敗扱い、全手法を同一の判定モデルで採点）。論文のTable 1から、モデル別の数値は次の通り。

SemaPLCの平均72.6%は、最も強いベースラインAutoPLC（63.9%）を8.8ポイント上回る。論文はさらに「ハーネスを剥がした素のバックボーン（bare、スキル・ツールなし）」との比較も行っており、bareに対してSemaPLCは全モデルで8.5〜33.3ポイント改善し、モデル間のスコアのばらつきはbare時の37.6ポイントから14.6ポイントに縮小、bareのコンパイル成功率平均も85.5%から99.2%に上がったと報告している。

数字で見る差:Project track（65タスク）の動的挙動

より難しい「プロジェクトコンテキスト」トラック（生成ロジックが実在のプロジェクト内でコンパイル・実行される必要がある65件のタスク、分母は全タスク固定でコンパイル・デプロイ・タイムアウト失敗はすべて0点扱い）では、統合コンパイル・静的挙動・動的挙動のすべてでSemaPLCが最高平均を記録している。

ここで注目すべきは、静的なスコア（構文やルール適合など）だけを見ていると手法間の差が全手法10ポイント以内に収まり、ほとんど見えないという指摘だ。しかし動的スコア（生成ロジックと正解ロジックを同一の実機PLCランタイムにデプロイし、実行トレースを比較したスコア）では、既存手法が22.4〜31.4だったのに対しSemaPLCは52.2まで差が開いた。論文はこれを「静的な採点ではなく実行こそが、生成された制御ロジックが本当に動くかどうかの忠実なテストだ」とまとめている。

論文はこの差が縮む条件にも触れている。最強モデルGPT-5.5では、SemaPLCの動的スコアがAgents4PLCを1.8ポイント上回るにとどまり（65.4対63.6）、静的挙動ではむしろAgents4PLC側が上回る（84.1対最大88.8）。つまりSemaPLCの優位性はモデルが弱いほど大きく、フロンティアモデルでは差が縮小する「モデル自体の実力を補う保険」としての性格が強いと論文自身が分析している。

論文が挙げる実例（コーキング精製プラントのタスク「Section 8」）はこの構造を具体的に示している。低流量（FT-701が50kg/hr未満）で目標値を500に、センサー故障時は2500に切り替えるという要件に対し、LLM4PLCとAutoPLCはコンパイルエラーで失敗、Agents4PLCはコンパイルには成功するもののロジックの優先順位を取り違え（低流量の代入が故障時の代入を上書きしてしまう）誤動作した。SemaPLCも最初の候補は同じ誤りを含んでいたが、実機ランタイム上でFT-701を30kg/hrに強制入力したところ期待値500に対し実際は2500のままだったことを検出し、原因別に分岐する修正を加えて再検証まで自動で完了させたという。

実行コストの内訳:リクエスト数は増えるが、待ち時間は同等

論文のTable 6は、最強ベースランのAgents4PLCとの実行コスト比較も報告している。Function trackではSemaPLCのリクエスト数はAgents4PLCとほぼ同じ（6.5対6.3件/タスク）だが、実行時間はAgents4PLCの454秒に対しSemaPLCは71秒と大幅に短い（Agents4PLCが反復のたびにPLCverif・nuXmvのモデル検査を呼び出しているため）。一方Project trackでは実行時間はほぼ同等（347秒対344秒）だが、SemaPLCのリクエスト数はAgents4PLCの6.9件/タスクに対し34.1件/タスクと大きく増える。SemaPLCの検証ゲートはチェックが通るまでツール呼び出しを続ける設計のため、リクエスト数はモデルによって16.4〜60.4件と変動する、と論文は説明している。

GitHubリポジトリの実体:Sema系列3作目、MCPツール16種

SemaPLCはGitHub（midea-ai/SemaPLC）で公開されており、READMEには「自然言語の制御要件を、動くPLCプログラムに変換するエージェント駆動IDE」と書かれている。READMEによれば、SemaPLCはMidea AIRCが進める「Sema」シリーズの3作目にあたり、1作目のsema-code-core（コーディングエージェントを組み込み可能なインフラに分解、arXiv:2604.11045）、2作目のSemaClaw（ハーネスエンジニアリングによる汎用パーソナルエージェント、arXiv:2604.11548）と並ぶ位置づけになっている。技術構成は、React+Vite製フロントエンドとNode製バックエンドを持つWebアプリsema-plc-webと、MCPサーバーまたはCLIとして動くsema-plc-tools（plc_check・plc_compile・plc_buildAndRunなど16種の構成可能なツール）に分かれ、実行基盤にはOpenPLC Runtime v4をDocker一式で使う。README上のバッジは「License: MIT」と表示している一方、GitHub APIが返すlicenseフィールドはother／NOASSERTION（自動検出不能）で、両者の表示は一致していない。GitHub APIで確認したリポジトリの実データは、star 71・fork 3・open issues 0、作成日は2026年6月26日、直近pushは2026年8月25日だった（いずれも本記事執筆時点のスナップショット）。論文の公開（8月19日）より前からリポジトリ自体は動いていたことになる。

実機の動作映像までは確認していない

一次資料として読んだのはarXivの論文HTML全文（Abstract・Table 1/2/6・ケーススタディ部分）とGitHubリポジトリのREADME・GitHub APIのメタデータであり、実際にPLCランタイム上でSemaPLCが生成したコードが動く様子の映像や、OpenPLC Runtime自体を手元で動かしての実行ログは確認していない。72.6%や52.2といった数字は論文が自己報告した評価結果であり、査読を経た数値かどうか、第三者による追試があるかどうかはこの記事の範囲では判断できない。動的挙動の評価シナリオ（最大6種類とされる）の具体的な内容や、Appendix B・Cで説明されているタスクコーパス・PLCツール群・スキルライブラリの詳細までは読み込んでいない。また「Secomea」や「Semaphore」など、産業制御・プログラミング分野の既存語とはスペルも読みも近いため、検索して情報を探す際は「SemaPLC」の綴りを正確に入れる必要がある。

関連記事

• ハーネスエンジニアリングとは何か──「エージェント＝モデル＋ハーネス」という考え方
• AIコーディングアシスタント比較──Copilot/Cursor/Claude Code【2026年】
• AIエージェントとは──指示に答えるAIと、仕事を進めるAIの違いをわかりやすく整理する