2026年11月2日

LLM は MCP サーバを介して CNC のデータを参照し、必要な設定変更が可能になる。ただし安全を担保するため、LLM が考えた内容をそのまま実機に送るのではなく、CNC シミュレーター「CNCガイド2」や、プログラムの動作検証が可能な「CNC Reflection Studio」などの PC 上のデジタルツインツールで検証し、シミュレーションで安全性が確認された後、最終的にオペレーターが目で見て承認した場合のみ実機へ転送、適用する仕組みだとされている。会場のデモでは、加工面に筋目などの不良が生じた際に AI加工面チューナーがサーボデータや加工プログラムから加減速パラメータなどの原因を推定して改善案を提示しプログラム修正まで行う例、CNC のアラームを検知した AIアラーム診断ナビゲーターが原因を推定し対策をシミュレーションで確認してからオペレーターに提案する例、手書き文字を AI文字彫刻デザイナーが加工プログラムへ変換し承認後にレーザー加工機が加工する例が披露された。ファナックの CNC を搭載する工作機械メーカーやソフト開発会社は、この MCP サーバを利用して独自の AI アプリケーションを開発できるようになる。

注目は転送の章で、転送対象には「プログラム」「ユニット設定情報」「イーサ／シリアル機能設定情報」「CPUシステム設定」などがあり、変更内容に応じて選択する。記事は、今回の操作では「全解除」を実行しても「プログラム」のチェックが残っていたため転送前に選択状態を確認したと書いている。また転送画面の「PLC内のプログラム（変数をクリア）」は通常のプログラム保守では不用意に選択しないようにしており、このチェックを外しただけで全ての変数値が必ず維持されるわけではないとも明記している。実際の保守作業で確認した4パターンは、ユニットエディタの設定変更＝ユニット設定情報を PROGRAM モードで転送成功、KV-XLE02 の PLC リンク設定変更＝イーサ／シリアル機能設定情報を RUN モードで転送成功、既存の毎スキャンモジュール修正＝プログラムを RUN モードで転送成功、毎スキャンモジュールの追加＝RUN モードでは転送できず PROGRAM モードで転送成功、というもの。いずれも今回の KV-8000 環境で確認した結果であり、EtherNet/IP の設定追加は同じ方法で対応できる可能性があるが未確認とされている。

設定圧まで遅いなら供給圧力や吸着位置を疑え、到達後に持ち上げた瞬間だけ圧力が落ちるなら袋のしわ、スポンジ摩耗、荷姿変化が候補で、逆にリフト後も圧力を保てるならそこで初めて本搬送へ進める、という組み立てだ。2本目（日本時間11月1日14:10）は同じ発想をラインへ広げる。カメラがワークを見つけた、真空圧も到達した、AMR も目的地へ着いた——自律化ではこの三つを一つの READY にすると途中状態が見えなくなる、という問題提起で、FANUC が教示を減らす AI ビジョンと AMR 搭載向け DC コントローラを発表し、SMC が凹凸のある包装品向け真空グリッパを公開したことで認識・移動・把持を組み合わせやすくなる一方、PLC 側の受渡し条件は増えると述べている。推奨される状態分割は「搬送要求・ワークID→AMR到着→ドッキング→対象認識→姿勢確定→吸着→真空保持→低速持上げ→相手機READY→解放確認→受渡し完了」。認識後に台車が動けば座標は無効、真空が一度到達しても持上げ後に低下すれば搬送禁止、相手機が停止したらワークを保持したまま安全位置で待つ、通信復帰後もどちらがワークを持っているか照合してから再開する、という条件が挙げられている。異常処理も認識不能は再撮像、真空未到達は再吸着、保持低下は退避、ID不一致は隔離と分け、全部を「ロボット異常」にまとめないよう促している。

取りこぼしの原因は2つあると整理されている。1つは、PLC が 20ms ごとに HR の「今の値」を読むだけなので、同じボタンを2回押して同じ値が書かれても気づけないこと。対策は通し番号で、種類・階・通し番号の3つを FC16（連続したレジスタをまとめて書く命令）で1回の書き込みで送り、PLC は通し番号が前回と変わったサイクルだけ新しい指令として扱う。別々に書くと「種類だけ新しく、階は古い」途中の状態を PLC が読むおそれがあるため、まとめ書きが前提になっている。もう1つは、PLC が読む前に次の指令で上書きされること。対策は受け付け確認で、PLC は処理した通し番号を IR10 に返し、画面のサーバーは IR10 が送った番号になるのを確かめてから次の指令を送る。実装では IR10 を 20ms おきに読み、2秒で一致しなければタイムアウトのエラーにしている。起動時については、PLC は最初のサイクルで今の通し番号を覚えるだけにし、起動前に HR に残っていた指令は実行しない。サーバー側も接続時に HR2 を読んでその続きから番号を振り、16bit なので 65535 の次は 0 に戻す。なお記事は、本物のエレベータには PLC のプログラムだけに頼らない安全装置がたくさんあり、このコードは練習用だと明記している。

原因として挙がった観点は5つ。観点1は、getValues() が空のセルを空文字で返し、JavaScript では空文字と日付の比較が true になるため期限が空の行が条件を通ってしまう一方、「未定」のような文字は比較が false になって黙って飛ばされること。観点2は、配列の添字とシートの行番号が1つずれていて、印が見出し行や期限前の行に付き、送りすぎと送り漏れが同時に起きるのに例外は1つも出ないこと。観点3は、同じ日に2回動いたときの二重送信と、トリガーを作る関数を2回呼ぶとトリガーが2つになる問題で、記事はトリガーが1人1スクリプトに20個まで作れて上限に当たるまで何も言われないと書いている。観点4は外へ出る所と数で、宛先の1日あたりの上限が無料のアカウントで100、Google Workspace で1,500、1回の実行は6分までであること（Quotas for Google Services を2026年11月1日に確認）、トリガー実行時の例外は画面に出ず「Summary of failures for Apps Script」という件名のメールでトリガーを作った人に届くことが挙げられている。観点5は権限で、GmailApp はリファレンス上どのメソッドも広い Gmail の権限を求めるのに対し、送るだけなら MailApp で足りる、という対比だ。記事の最後には13項目のチェックリストが置かれ、GAS 固有の4項目を除けば VBA のマクロにも当てはまるとされている。

CVE-2026-114596 は 8.2 の「高」で、メッセージ長の検証不備によりメモリの範囲外書き込みを招きコントローラのプロセスをクラッシュさせる。CVE-2026-114597 は 7.5 の「高」で、境界チェックの不備によるメモリの範囲外読み取りとプロセスのクラッシュ。CVE-2026-114598 は 7.5 の「高」で、型の取り違えによりサービス拒否を招き、隣接するメモリの内容が漏えいする恐れもある。4件はいずれも EPICS の中核となる基盤ソフトウェア EPICS Base に影響し、EPICS Base は世界最大級の科学研究プロジェクトや施設の運用に使われているため、各組織は修正を含むバージョン 7.0.11 に更新すべきだとされている。米サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）は火曜日の注意喚起で、悪用に成功するとサービス拒否状態、メモリの破壊、機微情報の開示、場合によっては任意のコードの実行につながる可能性があると警告した。発見した側については、AI エージェント「Cipher」を手がけるセキュリティ企業 Causal Security 社の共同創業者シュバム・ラージ（Shubham Raj）氏が The Register に対し、4件はそれまで知られていなかったもので Cipher が自律的に発見したと語っている。初めて扱う EPICS システムの調査とテスト、4件の攻撃手法の有効性の確認まで含めて所要時間は3時間49分で、最初の調査に人間の介入は必要なく、その後に安全な環境でより踏み込んだ悪用可能性のテストを許可する指示を1回出しただけだという。

CVSS v3.1 の基本値は 9.8、CVSS v4.0 は 9.2、CWE-787（範囲外書き込み）。Brotli ライブラリやバイナリが 1.0.3 から 1.2.0 の範囲にある利用者は、1.0.10、1.1.1、1.2.1 のいずれかへ更新する必要があると記載されている。SSA-045512 が列挙しているのは影響を受けないと分かっている製品で、Heliox Dual Port 60kW、Heliox Flex Pro、SICHARGE FLEX、SICHARGE UC、Sifinity Go、Sifinity Setup、VersiCharge AC Series、VersiCloud が、いずれも全バージョンで CVE-2026-111497 の影響を受けず、理由は Node.js が存在しないこと（コンポーネント非搭載）とされている。2本目の SSA-443410 は Industrial Edge Management（IEM）向けで、Siemens は Industrial Edge への影響を現在評価中だとしている。対応は IEM の構成で分岐し、管理アプリケーションを入れていない場合は、影響を受ける Brotli ライブラリが IEM のソフトウェアスタックに含まれていても該当機能が使われておらず露出していないため対応は不要で、IEDK も同じだという。管理アプリケーションを入れている場合は、修正が出るまで個別の緩和策に従う必要がある。勧告では、Cloud Connector Configurator、Common Configurator（CC on IEM）、Databus Configurator、Edge OPC UA Server Configurator、Flow Creator Configurator について、全バージョンが影響を受け現時点で修正はなく、すべての管理アプリケーションをアンインストールしてファイアウォール／WAF で IEM インスタンスを保護するよう示されている。Common Configurator on Device（CC on Edge）と Data Flow Monitoring は、修正が出るまで停止するよう案内されている。一方 Industrial Edge Hub は 2026年10月29日から、Industrial Edge Management Cloud は 2026年10月28日から中央のクラウドサービス側で修正され、利用者側の対応は不要とされている。

要点のひとつは、PLC が大型モーターに直接電力を供給するわけではなく、PLC は運転の判断や指令を担当し、実際に大きな電力を扱うのは電磁接触器やドライブ装置だという区別だ。DC24V については、低い電圧の方が一般に感電リスクを抑えやすいとしつつ、SELV に適合するには電圧だけでなく他の回路からの適切な分離などの要件を満たす必要があり、24V という数字だけで安全性を判断してはいけないと注意している。電圧降下の例として、配線の往復抵抗0.2Ωに3Aが流れれば0.6Vの降下となり、24V電源でも負荷側が23.4Vになると示している。特に具体的なのが保護協調の節で、1つのスイッチング電源から PLC、センサー、電磁弁へ供給していると、電磁弁の配線で短絡が発生したときに電源の過電流保護が動作して出力電圧が低下し、同じ電源につながる PLC やセンサーまで電圧不足になる可能性があるという。DC24V の分岐に機械式サーキットプロテクタを設置しても、上流のスイッチング電源が先に電流制限を行うと分岐保護器が期待どおりに遮断できない場合があり、そこで電子式サーキットプロテクタが重要になる。例として挙がるオムロンの「S8V-CP」は DC24V の分岐回路を個別に保護する製品で、4分岐・8分岐のタイプがあり、S8V-CP0424 と S8V-CP0824 では定格出力電流を2A、3A、4A、6A、8A、10A から選択でき、UL Class 2 対応の S8V-CP0424S は3.8A固定。ただし電子式プロテクタを採用すれば必ず解決するわけではなく、オムロンの公式資料にも電源容量が不足していると全出力の電圧が低下する可能性が記載されているとして、電源容量、分岐保護器、負荷特性、配線をセットで設計することが重要だとまとめている。入力回路については、三菱電機の MELSEC-F シリーズに関する公式 FAQ が FX3U などの S/S 端子についてシンク入力は S/S 端子を24V側へ、ソース入力は0V側へ接続すると説明している一方、別の公式 FAQ ではシンク入力を「マイナスコモン」、ソース入力を「プラスコモン」と説明しているため、コモンという名称から S/S 端子の実際の接続極性を推測すると混乱する可能性があると指摘している。安全面では、IEC 60204-1 が停止をカテゴリ0、1、2に分類し、非常停止に使用するのはカテゴリ0または1であること、非常停止は他の運転機能に優先し、ボタンを解除しただけで機械が再起動してはならないこと、一般的な PLC のプログラムに停止命令を書くだけでは安全機能として必要な信頼性が確保できるとは限らないことが挙げられている。インバータやサーボドライバの STO（Safe Torque Off）についても、モーターにトルクを発生させないようにする機能であって、装置が電源から電気的に隔離されたわけではないと区別している。

ラベル名にスペースや記号を入れると検索クエリの書き方が変わって一致しにくくなるため、英数字とハイフンだけの名前にしておくのが無難だとされている。毎回手でラベルを付けるのが面倒な場合は、Gmail のフィルタで差出人や件名を条件にラベルを自動付与しておくと、届いた時点で対象になる。コードは、Drive フォルダとラベルを取得し、ラベルが見つからなければエラーで止め、ラベル付きで添付ファイルのあるスレッドを検索して、各添付の MIME タイプが application/pdf か、ファイル名が .pdf で終わるかのどちらかで PDF と判定して保存する、という流れになっている。1回の実行で処理するスレッド数は 50 件を上限にしており、記事はその理由を、1回の実行が最大6分で打ち切られるためで、処理したスレッドはラベルが外れるので残りは次回のトリガー実行で順に片付く、と説明している。初回実行時には Gmail と Drive の両方へのアクセス許可が必要で、定期実行は時間主導型のトリガー（記事の例は1時間おき）で設定する。動作確認の観点は、指定フォルダに PDF が保存されていることと、メールからラベルが外れていることの2点。つまずきポイントとして、ラベル名の完全一致（スペースや全角・半角の違いも別物として扱われる）、検索条件に一致する添付の有無、権限承認の取り直し、MIME タイプと拡張子のどちらにも当てはまらない添付の調べ方、ラベルを外す処理の前でエラーになると次回に同じ PDF がもう一度保存されること、が挙げられている。応用として、受信日時をファイル名に付ける方法、送信元のアドレスで保存先フォルダを振り分ける方法、保存完了を Slack の Incoming Webhook へ通知する方法が示されている。

Parameter Labs が見つけたのは、かなり複雑な攻撃連鎖だった。OpenAI はグラフ機能の一部として MathLive という JavaScript ライブラリを使っており、このライブラリは独自の仮想キーボードを含んでいる。その仮想キーボードは、サンドボックス化された iframe から postMessage() を使って親ページ側で起動できた。メッセージを受け取る側のコードは innerHTML を使っていたため、メッセージを送れるものは誰でも親ページにカスタム HTML を追加でき、しかも HTML プレビューのフレームを含む他のサンドボックスフレームがそのメソッドを呼ぶのを防ぐ仕組みが無かった。innerHTML は script 要素を直接実行しないものの、サンドボックス制限のない新しい iframe を注入するのに使えた。OpenAI の CSP ルールはインラインスクリプトを完全にブロックし、スクリプトの読み込み元もごく少数のドメインに限っていたが、そのうちの1つが YouTube であり、YouTube の oEmbed エンドポイントを使って JavaScript を実行される形で反射させることができた。ChatGPT 上で JavaScript 実行を獲得した後は、API から利用者の非公開データを取得し、画像参照を経由して持ち出すのは容易だったという。最終的な結果として、ChatGPT の共有 URL を作っておくと、サインイン済みの別の利用者がそれを開いたときに、その利用者の非公開データを持ち出したり、本人に代わって操作を実行したりできた。OpenAI はこの穴を閉じ、5,000ドルのバグバウンティを支払ったが、記事の筆者はこれほど深刻な脆弱性に対しては少し安いと思うと書いている。

ゴールはリポジトリの GOAL.md に書き、1行目は「ゴール：最終スコア 100 万点」で、当時の最高は16万点前後、1位でも60万点ほどだった。届かない値をあえて置いたのは、ほどほどの点でエージェントが手を止めないようにするためだという。GOAL.md にはゴールのほか、待ち時間をつくらない、データの整合性を保つ、認証や削除などの動作を変えない、といった守ることも書かれ、エージェントどうしが互いの会話を見られないため、このファイルがチームの共通ルールとして機能した。15時半を過ぎると Slack の投稿の大半が AI どうしのやり取りになり、説明の文が長くて読むだけで時間がかかったため、人間が「人が読めなくていい」と伝えた結果、エージェントの1つが `CLAIM from=b files=... eta=17:20` のような1行の書式を決めた。先頭の語がメッセージの種類で残りは名前＝値、人間に向けた要約だけは TO_HUMAN という種類で日本語にさせ、人間はそれだけを読んで方針を返したという。もう1つの軸が、同時に1本しか実行できないベンチマークの分け合いだ。実行中にデプロイするとアプリが再起動してベンチマークが失敗するため、当初は人間が声をかけ合っていたが、16万点を超えたベンチマークが別の人のデプロイで0点になったこともあった。16時以降はデプロイとベンチマークの担当を1つのエージェントに絞り、残り2つは変更をブランチに push して Slack で知らせる形にした。13時台から16時までに衝突による失敗は5回あり、担当を1つに絞ってからは起きていない。ただし担当エージェントがベンチマークに追われて他の2つの変更をしばらく取り込まず、人間に指摘されて取り込んだ構成でその時点の最高 204,224 点が出たという経緯もあり、記事は実行の担当と、Slack を読んで次に何を試すか決める担当は分けるべきだったと振り返っている。終了後の振り返りとして「エージェントをそのまま使っても20万点前後までは来る。差がつくのは、エージェントに渡す道具や手順と、問題についての知識のほうだ」という言葉が引かれている。当日3人が使ったトークンは合計約25.3億で、推定費用は約944ドル（記事は推定で実際の請求とは一致しないと注記している）。