2026年11月3日

機能は3つ。「ディープデバッグ」は、現在から過去までのプログラム挙動や各種センサの信号を比較解析し、カウント差やON/OFF時間のズレなど微細な差分を自動検出して、異常箇所と原因候補を優先度付けして示す機能。プログラムロジックだけでなく、KV-Xシリーズのドライブレコーダに記録された過去の変数／デバイス値やイベント履歴まで専用AIで解析し、正常時との差分を抽出するとしている。同社はこれを「世界初」としており、その根拠には「2026年10月時点、当社調べ」と注記が付いている。また「設備停止原因を教えて」のように発生状況を自然文で訊くと、ドライブレコーダ機能をAIトリガで自動実行し、過去データを記録するという。
「ラダー自動生成」は、自然文の指示からラダーやST言語のプログラムを自動作成する機能。たとえば「原点復帰後、指定位置へ移動し、完了するまで待機して」と文章のまま指示すると位置決めプログラムを作成し、条件分岐、演算・文字列処理、センサ通信などのプログラムも、使用する変数・構造体の定義やコメント付きで生成できるとしている。生成したプログラムはそのまま挿入でき、AIで検証済みのためそのまま変換できるという。参照するデータベースにはPLCマニュアルに加えてキーエンス製センサの接続ガイドも含まれ、AIエージェントが高精度に認識できる形式へ独自に調整しているとしている。
「ビジュアル要約」は、PLCプログラムを解析し、システム構成・動作フローチャート・各モジュールの処理内容などをHTML形式で出力する機能。要約内容は行コメントやブックマークとしてプログラムに挿入できるため、トラブル対処時や別担当者への引き継ぎ時にイチから読み込まずに動作を把握できるとしている。さらに、位置決めプログラムのエラー処理モレや、センサ通信処理でのタイムアウト時間の未設定など、試運転では見つけづらいバグもプログラム解析で発見し、修正すべき理由や改善内容まで提示するという。
商品概要は、型式がLite版：KV-INL1／Pro版：KV-INP1、KV-INP3、KV-INP10。対応CPUユニットはプログラマブルコントローラ「KV-Xシリーズ」のKV-X550／KV-X530／KV-X520／KV-X500で、KV-Xシリーズの実機がなくても使用できるとしている。動作環境はWindows 11（64 bit）、ハードディスク空き容量2 GB以上、KV STUDIO Ver.13 以降、インターネット接続必須。問い合わせ先は同社の制御システム事業部とされている。

例に使うのは、モータ2台（コンベア2本）を動かす小さな制御盤で、記事のために作った架空の盤だと明記されている。構成は配線用遮断器MCCB1・MCCB2、電磁接触器MC1・MC2、サーマルリレーTHR1・THR2、モータM1・M2、そしてPLC。ここに「コンベアを1本増やすので、モータM3を足してほしい」という仕様変更が来たと想定する。
汎用CADの場合、人が手で直す場所は、系統図、展開接続図（回路図）、部品表、端子表、ケーブル表、I/O表、盤内の配置図、表紙・図面目次の8種類になる、と数え上げている。M3という1つの情報を8種類の図面・帳票に人が書き写すことになり、全部が合っているかを確かめるのも人だとする。
筆者は、書き写す時間よりも見比べる時間の方が重く感じるとし、回路図ではMC3なのに部品表ではMC2のまま、I/O表のアドレスが1つずれている、といった食い違いは図面を並べて目で追わないと見つからないと書いている。設計者が1人で描いて1人で確かめる現場では、見落としがそのまま盤の製作や配線に進んでしまうとも述べている。
データベース型では、M3を足すときに人がするのは回路図にM3の回路を描き足すことで、部品表・端子表・I/O表・ケーブル表は描いた内容から作り直される。記事は、回路図に描き足す手間そのものはあまり変わらず、大きく変わるのは書き写しと見比べが無くなることだとまとめている。盤内の配置図は製品によって差があり、部品表と連動して直るものもあるとしている。
注意点として3つを挙げる。1つ目は部品のデータ（型式・メーカー・端子の情報など）を先に整える必要があることで、記事は、電気CADのメーカー自身も新製品の発表で「データベース型は使い始める前に数百〜数万点の部品データを作る必要があり、専任の人がいない会社には導入が難しい」という趣旨の説明をしていると紹介している。2つ目は、同じ部品でも人によって型式の書き方が違う（ハイフンの有無、電圧を付けるか）と部品表で別の部品として数えられるため、図面の書き方・部品の名前の付け方を先に決める必要があること。3つ目は、自動にできるのはCADに付いている機能の範囲だけで、そのためのデータを整えるのにも時間がかかり、CAD自体も高価であること。
移ると得しやすい現場として「似た設備を何台も作る（流用が多い）」「仕様変更が多く直し忘れが怖い」「部品表・I/O表の書き写しに時間を取られている」「部品や書き方のルールを決めて守れる」を、得しにくい現場として「一品物ばかりで図面の流用が少ない」「一度描いたらほとんど直さない」「帳票を作る仕事がほとんどない」「書き方が人ごとにバラバラで整える人もいない」を挙げ、迷ったらまず「この1年で、仕様変更のたびに何か所を書き写したか」を数えてみるのがおすすめだとしている。

記事は、この4つを必ずしも同じ計算機に配置する必要はないとし、Observeを電力計・センサ・IoTゲートウェイ、Predictをエッジ、Decideをエッジと人、ActをPLC・設備コントローラに置く構成例を示している。
クラウド中心の構成については、複数拠点のデータを統合でき、長期間のデータ分析やAIモデルの学習・更新にも適しているとする。一方、制御判断をクラウドに依存させる場合はネットワーク障害や通信遅延を考慮する必要があり、接続が切れたときに安全に運転を継続するのか、最適化制御を停止するのか、最後に受け取った指令を維持してよいのかを事前に設計する必要があるとしている。重要なのはクラウドを使わないことではなく、クラウドが使えなくなっても現場の安全と必要な運転を維持できる構造にすることだと書いている。
エッジ中心の構成は、必要な機能をローカルに実装することでクラウドとの通信が切れても現場側で判断を継続できるとする。ただし計算資源は限られ、現場ごとにハードウェアが必要で、ソフトウェア更新や構成管理などのメンテナンスも必要になるため、エッジに置けばすべて解決するわけではないとしている。AIBODは、Intelligenceはエッジが良いと考えており、現場側のIntelligenceを担う製品群としてAIBOD FEXを開発していて、電力ピークカットシステムが最初のFEXだと述べている。
「PLCには、すでにIntelligenceがある」という整理も置いている。設備の起動条件、停止条件、異常時の処理、他設備とのインターロックといったロジックには、長年の設備設計や現場経験が反映されていることがあるとする。例として、エッジが「コンプレッサの運転を調整したい」と判断しても実際にその操作が許されるかは設備の状態によって変わるため、エッジは最適化のための制御要求を生成し、PLCは設備の運転条件を確認して許可された操作を実行し、安全に関わる機能は必要な安全関連システムで独立して確保する、という役割分担が考えられるとしている。新しいAIやソフトウェアを導入するために既存PLCのロジックをすべて置き換える必要はないという立場だ。
「人もアーキテクチャの一部」として、今日は特別な製品を製造していて通常なら停止できる設備が止められない、メンテナンス中の設備がある、といったコンテクストがすべてデジタル化されているとは限らないことを挙げる。誰が判断するのか、どの条件で承認が必要なのか、承認されなかった場合はどうするのか、判断結果をどのように記録するのかも設計対象だとしている。
配置の判断には、Response Time（必要な応答時間、制御周期）、Reliability（通信断・故障時の動作）、Safety（安全に関わる機能と責任）、Computing（必要な計算資源）、Data（データの所在、通信量、機密性）、Maintainability（更新、保守、障害対応）、Cost（初期費用、通信費、運用費）、Human Responsibility（判断権限、承認、説明責任）の8つの観点を挙げ、この考え方をVLP（Variable Layer Partitioning）と呼んでいる。
記事は代表的な3構成として、Architecture A：クラウド中心型、Architecture B：エッジ中心型、Architecture C：PLC・ルール中心型（需要電力の閾値などを利用し、AIを使用せず既存の制御技術を中心に構成）を比較しているが、この比較は設計上の一般的な内容であり、実際の応答時間、費用、信頼性は機器仕様・通信条件・既存設備・実装方式により異なると注記している。今回のArchitecture Decision #002は「Intelligenceの配置は、機能だけでなく実行条件から決める」で、進め方としては、まず電力計測を確立し、次に設備の運転状態を把握し、その後に予測と判断の機能を追加し、さらに設備側の許可条件を確認しながら制御連携を検証する、という段階的な流れを示している。

手順はスプレッドシートのメニューから「拡張機能」→「Apps Script」を選び、コードを貼り付けて保存・実行し、初回は権限の確認ダイアログで許可を選ぶ流れ。
処理の中身は、getDataRange().getValues() で旧・新の両シートを読み、A列の値を trim() してキーにしたMapを2つ作る。新データにあって旧データにないキーは「追加」、両方にあって行全体の文字列比較が一致しないキーは「変更（旧）」と「変更（新）」の2行、旧データにあって新データにないキーは「削除」として差分行に積み、先頭に「区分」列を足したヘッダー付きで差分シートへ書き出す。旧と新で列数が違うと setValues が失敗するため、全行の列数をそろえてから書き込んでいる。
区分列は色分けされ、追加は緑（#d9ead3）、削除は赤（#fce8e6）、変更は黄（#fff2cc）。前回の色が残らないように、内容だけを消す clearContents() ではなく内容と書式をまとめて消す clear() を使うとしている。実行後はアラートで出力行数が表示され、変更は旧・新の2行で数える。
つまずきポイントも具体的に挙がっている。「シートが見つかりません」はシート名の全角・半角スペースや末尾の空白が原因でコード内の名前と完全一致が必要。全行が「変更」として出る場合は旧データと新データの列構成（列の数・並び順）が同じかを確認し、列が1つ増えただけでも全行が「変更」と判定される。キー以外の列にある前後の空白や、日付・数値の表示形式の違い（文字列の「001」と数値の1など）も不一致の原因になる。追加と削除が同じキーで両方出る場合は、キー列に全角スペースや途中の改行が混じっていないかを確認する（trim() で除去されるのは前後の空白だけ）。
速度については、GASで遅くなりやすいのは getRange() や setBackground() をセル1つずつ何度も呼ぶ処理であり、このコードは getValues() / setValues() / setBackgrounds() でまとめて読み書きしているので数千行程度なら問題なく動くとしている。それでも6分の実行時間上限に近づく場合は、比較する列を絞るよう勧めている。
応用として、キー列をA列以外にする場合はコード冒頭に const KEY_COL = 2; のように定数を定義してインデックスを置き換えること、差分があった場合にGmailで通知する処理を追加して時間主導型トリガーと組み合わせれば変更検知を自動化できること、各バージョンをシート名に日付を付けて保存しておけば3シート以上の世代管理（v1→v2→v3）に同じロジックを使い回せることを挙げている。

記事は、これは11月2日に新しい侵入被害が確認されたという発表ではなく、同社はこの動作自体を意図した製品の動作と説明している、と明記している。問題は、設定を読む側が一つの項目で別の接続経路までまとめて保護できたと考えてしまうことだとする。
Siemensの説明では、変数ごとのアクセス属性が効くOPC UA・Web APIの接続と、PLCの保護レベルなどで管理するPG/HMI通信を区別している。記事はこの用語をほどいて、変数は設備の状態や設定値などを扱うデータの項目、OPC UAやWeb APIは別のシステムがデータを読み書きする接続方法、PGはプログラミング装置、HMIは人が設備を操作・監視する画面に関係する言葉だと説明する。そのうえで、設定項目の名前にHMIという言葉があっても、それだけでPG/HMI通信を含む一律のアクセス制限だと判断できない、というのが今回の大事な点だとしている。
TIA Portalの文書にも、変数のアクセス属性だけでは一般的なアクセス保護を実装できず、その属性が無効でも他のアプリケーションから読み書きできる場合があると記載されている、と紹介している。
ただし記事は、ここから「誰でも操作できる」と結論を飛ばしてはいけないと注意する。別の経路では別の保護設定や権限を確認する必要がある、という話であり、今回の案内だけで個々の設備が無防備かどうかは分からないとしている。記事に添えられた模式図についても、矢印は接続の区分を示すもので通信成功や攻撃経路を表さず、実際の適用範囲は機種と構成、製品文書で確認するものだと書かれている。
Siemensは、該当する製品文書に沿ったアクセス保護の設定を勧め、TIA Portal文書の説明を改善するとしている。記事は、今回の情報を一律に「最新版へ更新すれば終わり」という依頼に置き換えず、接続別の設定確認へつなげることが必要だとまとめている。出典として、JVN「Siemens製品に対するアップデート（2026年10月）」（2026年10月14日公開、11月2日更新）、Siemens ProductCERT「SSB-091449」（2026年10月13日公開・最終更新）、SiemensのSTEP 7 V21の文書を挙げ、公開情報の確認日は2026年11月3日、依頼・確認・試験の進め方は一般的な提案であり特定の現場の構成や被害を示すものではない、と注記している。

投稿者は、完全な配線図（full wiring diagrams）と純正マニュアルを持っており、それらが機械についてほぼすべてを網羅していると述べている。
そのうえでの質問は二択で、リレーの回路図を土台にしておおむねそのままラダーロジックへ翻訳してよいのか、それとも機械が本来どう動くべきかに基づいてPLCプログラムをゼロから書いた方がよいのか、というもの。この投稿は質問であり、収集した本文の範囲には結論や採用した方針は示されていない。

対象として確認されたのはmacOS版とWindows版で、Cursorは両バージョンの配布を停止している。
Phorionの分析によると、攻撃者は拡張機能の「extension.js」というファイルの冒頭に悪意あるコードを追加しており、拡張機能が読み込まれた段階で不正な処理が始まる仕組みだった。悪意あるコードはネットワーク経由で別のコンピューターを遠隔操作するための仕組みであるSSHを悪用するもので、攻撃者はSSH接続を許可する「authorized_keys」というファイルに自分の公開鍵を追加し、不正にログインできる状態を作ろうとしていた。
さらに、PCから攻撃者のサーバーへ接続する「リバースSSHトンネル」も設定されており、攻撃者が外部サーバーを経由してPCに接続できるようになっていた。macOSのLaunchAgent、Linuxのcron、Windowsのタスクスケジューラなどを使用してPCの再起動後も接続を再開するコードも含まれていたという。
バックドアには、PC名やユーザー名、OSの種類、公開IPアドレス、Gitに設定されたメールアドレスなどを収集して攻撃者に送信する機能も組み込まれていた。Phorionによると、パスワードやAPIキーなどに関連する環境変数の名前も収集対象だったが、環境変数に保存された秘密情報そのものを送信する処理は確認されなかったとのこと。
なお、多くのmacOSおよびWindows環境では管理者権限が不足するため、今回問題となったコードではSSHサービスの有効化に失敗するとCursorは説明している。ただし、攻撃者のSSH鍵の追加や自動起動設定の作成、PC情報の送信は実行されているうえ、SSHサービスが有効になっているPCでは不正アクセスにつながる可能性があるとされる。
Cursorは問題の拡張機能を削除するとともにマーケットプレイスの一時停止や調査を実施し、攻撃者が使用していたサーバーも停止させた。影響を受けたユーザー向けに確認手順と修復用スクリプトを公開しており、Claude Codeをアンインストールしても不正なSSH鍵や自動起動設定が残る可能性があるため、該当バージョンをインストールしたユーザーには追加の対処を推奨している。また、ニュース共有サイト「Hacker News」にAnthropicの関係者が登場し、Anthropicのシステムや従業員のPCが侵害された事件ではなく、Cursorのマーケットプレイスを通じて改ざん版が公開されたものであることを強調し、Anthropicの公式配布経路にあるClaude Codeは影響を受けていないと述べたと記事は伝えている。

」の1行をプロンプトとして渡した。CONDITIONS.md には実行ごとに変わる条件、競技時間やレギュレーション、ポータルのURLが書かれており、詳しい指示はsystem promptに追記する形で渡している。起動後、競技エージェントには一度も指示を入力していない。コーディングエージェント対策で偽の指示を含むAGENTS.mdが仕込まれていたようだが、エージェントは従わずに作業を続けたと記事は書いている。
スコアの最高が30分以上伸びなくなった14:02、Claude Codeのhookが監査役のサブエージェントの起動を促し、14:03に起動した。監査役は、エージェントがこれまでの判断を書き残した記録を、準備しておいたチェック項目の一覧と突き合わせて見直すサブエージェントとして実装されている。14:28に届いた報告の指摘を順に試したところ大半はスコアが下がる結果になったが、スコアが伸びたのは「応答を遅らせる時間を固定にする形と、届いているリクエストのレートを見て調整する形を、両方比べたか」というチェック項目から試した手で、15:49にこの日の最高の629,638点が出た。監査役は14:03と16:31の2回起動され、どちらも約22分で終わっている。
一方で、同じ構成でも走行ごとにスコアが大きくばらつくことが分かったとも書いている。この構成の12回の走行は474,987〜629,638点に散らばり、走行の序盤の毎秒リクエスト数が回ごとに分かれ、それがアプリの設定によらないため、エージェントはベンチマーカー側の違いと見た（原因は確定しなかった）。走行ごとの差のほうが終盤に試したどの手の差より大きいと、エージェントは記録に残している。
今回のISUCONは最終スコアが最後の走行のスコアで決まるため、どこで止めるかは事前に準備しておいたツールで決めた。この構成で測ったスコアの一覧と残り時間から「あと何回走らせられるか」を計算し、その回数だけ走らせ直せるときの期待値を閾値にして、最後の走行が閾値以上なら止め、下回ればもう1回走らせる。残り回数が減ると閾値も下がるので終盤ほど止まりやすくなる仕組みで、17:41の5回目に625,857点（閾値562,595）が出た時点で止めている。この5回目は、この構成の12回のなかで2番目に高いスコアだった。
結果として記事が挙げている数字は、最終スコア625,857点（競技中の最高は629,638点）、負荷走行86回（0点の回を含む）、コミット19個、人間からセッションへの入力0回、エージェントが人を呼んだ回数0回、トークンは出力が約90万・キャッシュからの読み込みが約1.3億（どちらもサブエージェントを含む）、モデルはClaude Opus 5.5、コンテキストは最大で約96.7万トークンで、コンパクションは16:27の1回のみ（966,927から22,752トークンへ減った）。