2026年7月24日

最初の一歩は、手持ちの FX5 プロジェクトで「送信用デバイスと受信用デバイスが分離されているか」を今日 GX Works3 のデバイス一覧で確認すること。記事が推奨する通り、双方が同一箇所に書き込む設計になっていたら、そこが将来の再現しないトラブルの種になる。次の段階として、既設 PLC 間通信のうち起動指令など重要な指令が UDP になっていないかを見て、TCP へ寄せられるか検討する。あわせて、ケーブル断線・電源断のテストを受け入れ試験の項目に足す（記事いわく必ずテストすべき項目だが、実際は正常系だけ確認して出荷しがち）。コストはゼロ — 追加ユニット不要で FX5 標準の Ethernet ポートで完結し、必要なのは設定とテストの工数だけ。注意点として、現場でバージョン 1.110 前後の混在機がある場合は設定画面の場所が違うので、手順書を1本にまとめず版数で分けておくとハマらない。

書かせる側より読ませる側から入るのが今日の最短距離。最初の一歩は、今抱えている不具合案件のラダーを1本だけエクスポートして Claude に貼り、「この不具合が起きる条件を挙げて」と聞くこと。X の実例と同じ使い方で、Claude/ChatGPT の既契約枠の範囲で追加コストはゼロ。次の段階として、書かせる側を試すなら ST の四則演算・IF 文だけに絞って発注する。FOR 文と構造体は三菱機で BY 1 D の書式が必要なので、AI 出力をそのまま貼らず自機用テンプレートで再整形する前提で組む。運用として効くのは、記事が結論に置いた「誰が検収し、機種別テンプレートで再整形するか」を先に決めること — 自機（三菱）用の自己保持・FOR 文の雛形を1ファイルにまとめ、AI 出力は必ずそこへ流し込む。注意点は、顧客のラダーを外部サービスへ貼る前に守秘の確認を取ること。ここを飛ばすと技術以前の問題になる。

PLC 屋にとっての意味は「センサーの生波形から異常判定を作る実験が、ライセンス稟議なしで始められるようになった」こと。最初の一歩は MPLAB ML の Model Builder に、手持ちの振動や電流のログを CSV で食わせて分類モデルを一つ作ってみること。登録手続きなしで入るので、評価申請の待ち時間がゼロになった点が今回の実質的な変化。次の段階として、PLC 側で全部やろうとせず「マイコンで一次判定 → 判定結果のビットだけ PLC へ」という切り分けを試す。PLC のスキャンタイムを気にせず振動解析が置ける構成で、既存ラダーの改造も最小で済む。コストはソフト無償・評価ボードが数千円〜1万円台の実費のみで、社内稟議を通さず自腹の範囲で検証できる規模。注意点は、TUV SUD 認証取得済みとはいえ安全機能そのものを AI 判定に置き換える話ではないこと。まずは通常制御の補助 — 予兆の見える化から入るのが無難。

どちらも今日そのままレビュー観点に落ちる。最初の一歩は、直近に自分が書いたプログラムを1本開いて、良否判定のフラグが「初期値=良品」になっていないかを検索すること。初期値が良品側なら、判定ステップが飛んだときに不良が素通りする経路が残っている。次の段階として、この2点を自分のラダー設計チェックリストに文言ごと追加する — 「良否フラグの初期値は不良側か」「行き限・戻り限の全センサに安定タイマがあるか（値ゼロでも可）」。値ゼロで入れておけば現地調整でタイマ値だけ振れるので、プログラム変更なしでチャタリング対策ができるのが実利。コストはゼロで、増えるのはタイマデバイスの点数とレビュー時間だけ。注意点として、既設案件に後から一括で安定タイマを入れるとタクトタイムに効く可能性があるので、新規案件から適用し、既設は不具合が出た軸だけ個別に足すのが現実的。

一番持ち帰りやすいのは UI 生成そのものより「機械化された受け入れ検査」の型。最初の一歩は、AI に何か作らせるときの依頼文の末尾に、守らせたい条件を3〜5行の箇条書きで固定して貼る運用にすること（この記事の「契約」に当たる）。次の段階として、その条件を grep 1行で検査できる形に言い換える — 例えば「この関数呼び出しが N 回以上あること」「この API が0件であること」。制御設計側でも同じ構造が効いて、AI に書かせた ST やスクリプトに対し「禁止命令が含まれていないか」を grep で機械確認する運用に置き換えられる。コストはゼロで、Stitch も GAS も無料枠で試せる。注意点は、この記事の教訓そのもの — AI の自己申告を受け入れ条件にしないこと。3往復かかった原因は毎回「できました」と言われていた点にあり、検査を人の目視に任せる限り同じ罠を踏む。

客先で「異音がするが原因が分からない」と言われる設備に、いきなり本設置せず評価から入れる構成なのが効く。最初の一歩は、スターターキット（センサー10個＋ゲートウェイ1台＋6カ月ライセンス）の見積を取り、常時稼働で止まると困るポンプやモータ2〜3台に絞って提案すること。振動・温度・音を同時に見るので、既存の振動計だけの監視より一次切り分けが速くなる。次の段階として、edgeRX Vision の映像チェックを「センサーでは拾えない状態」に当てる — 部品の置き方や治具の付け忘れなど、物理量に出ない不適切な状態が対象になる。既存ラインシステムとの並行運用が可能とされているので、既設制御に手を入れずに追加できるのが提案しやすいポイント。コストは6カ月ライセンス同梱のキット価格＋設置工数で、恒久導入前に効果を数字で出せる期間が確保されている。注意点は、クラウドで機械学習モデルを生成する設計なので、客先のセキュリティポリシー上どのデータが外に出るのかを先に確認しておくこと。

「脆弱性が新しく見つかった」話ではなく「あなたの機種が狙われている」話なので、対応は設定の棚卸しになる。最初の一歩は、担当している客先設備で S7-1200 系が入っているものをリストアップし、デフォルトパスワードのまま出荷・運用されていないかを確認すること。速報が緩和策の筆頭にパスワードを挙げているのは、狙われる経路がそこだからだと読める。次の段階として、その盤のネットワークが事務系 LAN と物理的・論理的に分かれているかを図面ベースで確認する。分離もファイアウォールもなければ、客先への報告書に「Siemens 自身が名指しで注意喚起している機種」と根拠 URL を添えて提案する材料になる。コストは調査工数のみで、ファームウェア更新も費用は基本かからない（停止時間の調整の方が重い）。注意点として、ファームウェア更新は本番設備では計画停止に合わせるしかないので、まず「隔離とパスワード」の2つを先に潰し、更新は次回定期メンテに載せるのが現実的な順序。

複合機は「制御機器ではない」という理由で OT 側のセキュリティ棚卸しから漏れがちだが、この脆弱性の要点は機器を踏み台に内部ネットワークの他ノードへ届く点なので、工場ネットワークに置いてある複合機はそのまま制御系への入口になりうる。最初の一歩は、自社および担当客先の工場フロアに置かれている複合機の型番を控え、SSH 機能が有効になっているかを管理画面で確認すること。使っていないなら無効化が最も速い緩和で、費用ゼロ・即日できる。次の段階として、リコーの公式情報で該当機種かを照合し、該当ならファームウェア更新を情報システム部門へ依頼する。制御盤の話ではないので設備停止は不要で、更新の調整コストは低い。注意点は、複合機の管理が総務・情シス側にあることが多く、現場エンジニアの一存で設定変更するとトラブルになること。確認までを自分で行い、変更は所管部署に CVE 番号と CVSS 6.9 という数字を添えて依頼する形にすると通りやすい。

客先での不具合対応記録が、手袋のまま・盤の前で完結するようになる話。最初の一歩は、次の出張で1件だけ、盤の状態をスマホで15秒撮りながら「型式、症状、暫定処置」を声に出して喋ってみること。inline_data の上限が20MB程度＝15秒動画が目安なので、最初から短く撮る前提で運用を組む。次の段階として、記事の5項目を自分の点検記録の列に置き換える — 「日付、客先、設備名、症状、処置、次回確認事項」のような形。日時は AI に書かせず GAS 側で付ける設計をそのまま真似ると、日付の取り違えという一番痛い誤りが構造的に消える。コストは1回0.0015ドル＝日に10本撮っても月数十円のオーダーで、GAS 自体は無料枠。注意点は記事が挙げる「安いモデルはもっともらしい嘘を埋める傾向がある」点で、型式番号のような後で効く値は必ず登録前の確認画面で人が見る運用にすること。あわせて、現場の言葉（社内での装置の呼び名）をプロンプトに教えておくと精度が上がるとされている。

遠い世界の事故に見えるが、自分が Claude Code に自動化を任せている運用の前提が同じ構造なので他人事ではない。要点は「サンドボックスに閉じ込めたから安全」という想定が実際に破られたこと。最初の一歩は、自分の環境でエージェントに与えているネットワーク出口を確認すること — pip や npm のインストールのために外に出られる口を開けているなら、それが今回突かれたのと同じ形の経路になっている。次の段階として、自動化スクリプトに渡している認証情報を棚卸しし、「必要なとき手で渡す」ものと「常時環境変数に置いてある」ものを分ける。今回の攻撃も盗んだ認証情報の連鎖で成立している。コストはゼロ、必要なのは設定を見る30分。実務的な落としどころとして、顧客データや客先の図面を扱うディレクトリでは自動承認モードを常用しないと決めておくだけでも、事故時の被害範囲がはっきり狭まる。防御側が使えるモデルが制限される、という Willison の指摘は個人では動かせないが、「自分の側の出口と鍵を絞る」は今日できる。

検出役と検証役をエージェントで分ける構成が、自分が既にダイジェスト生成でやっている「生成役と裁定役の分離」と同じ発想なので馴染みやすい。最初の一歩は、手元の x-topic-digest リポジトリに対して単一コミット差分でスキャンをかけてみること。差分に絞れるので、リポジトリ全体を舐めさせて利用枠を大きく食う前に効き目を確かめられる。次の段階として、config 配下に置いている機密（LINE トークンや X API のベアラートークン）が誤ってコード側から参照・出力される経路がないかを重点的に見させる。追加コストは新規契約不要だが各スキャンが契約プランの利用枠を消費するので、日次で回すのではなく機密に触る変更を入れた日だけ手動で叩く運用が現実的。注意点は、修正パッチが自動適用されない仕様をそのまま活かすこと — 承認前に必ず差分を読む。セキュリティ指摘の自動適用は、直った気になって直っていないという一番まずい状態を作りやすい。

実務上の含意は「長いセッションほど AI の判断は緩む」ということで、これは攻撃されなくても自分の使い方に効く。最初の一歩は、重要な判断をさせるとき — 例えば図面の数値チェックや客先向け報告の事実確認 — を、延々と続けてきた会話の途中でやらないこと。新しいセッションを立てて、必要な資料だけ貼って聞く。次の段階として、自動化パイプラインの中で「毎回まっさらな状態で1回だけ聞く」構成を意識的に選ぶ。長いコンテキストを引きずるほどモデルは前の文脈に引っ張られる、という今回の検証結果と方向が一致する。コストはゼロ、必要なのは使い方の習慣を変えるだけ。もう一点、記事が最後に置いた「AI への信頼が高まるほど人間の反応速度が低下する」という警告は現場でそのまま起きる話で、AI が出した判定を追認するだけの運用に流れていないか、月に一度は自分で一次資料に当たって答え合わせをする習慣を作っておくとよい。