2026年8月28日

まず「自分の装置は MHS の土俵に乗るのか」を棚卸しするところから始めてほしい。今週やるなら紙一枚で十分で、担当している設備を「イーサネット経由でプログラムから読み書きできる」「専用ソフトからしか触れない」「盤の手動操作しかない」の3列に分けるだけでいい。MHS は「プログラム可能なインターフェースを持つ装置」が前提なので、この棚卸しがそのまま将来の適用可否リストになる。次の段階は、その1列目の装置について「AI に触らせてよい範囲」を先に決めることだ。MHS が機能仕様と一緒に安全な運転パラメータを持つ設計になっているのは示唆的で、ロボットアームの速度と角度を仕様側で縛るのと同じことを、あなたの装置でもやる必要がある。手を動かすなら、既存の PLC に「外部指令の受け口」を1点だけ作り、そこに速度上限・ストローク上限・インターロック条件をラダー側でハードに焼き込む練習をしておくといい。上位が何を言ってこようとラダーが最後に弾く、という構造を今のうちに標準化しておけば、MHS でも別の規格でも土台は使い回せる。コスト感は段階で大きく違う。棚卸しと「受け口＋上限ラダー」の設計は自分の工数だけでゼロ円、MCP サーバを立てて Claude から自機のシミュレータを叩く実験までなら PC 1台とサブスクの範囲、実機とつなぐ段階からは安全評価と保護カバー・非常停止の見直しが入るので数十万円〜のオーダーになると見ておきたい。注意点は2つ。1つは、現時点で MHS は研究プレビューでウェイトリスト運用であり、明日から誰でも使える規格ではないこと。もう1つは規制側で、EU 機械規則 2023/1230 が 2027年1月20日に適用され AI ベースの安全機能を初めて対象にする以上、輸出案件を持つ装置屋にとっては「AI で動かす」が設計思想の話から適合性評価の話へ移るということだ。海外向け装置を扱っているなら、この日付だけは今から社内の設計標準の改訂スケジュールに書き込んでおいてほしい。

ここで効くのは半導体の成膜そのものではなく、「最適解に加えて、なぜそれが最適かのルールを一緒に出させる」という手続きのほうだ。制御設計の現場に落とすなら、サーボや温調のパラメータ調整が一番近い。最初の一歩は、今やっている調整を記録に変えることから始まる。ゲイン、フィルタ、加減速時間などの設定値と、そのときの整定時間・オーバーシュート・異音の有無を1試行1行でスプレッドシートに残す。20〜30行たまったところで、その表を CSV にして Gemini や Claude に貼り、「この表から、整定時間を短くしつつオーバーシュートを 0.5% 以下に保つための条件を、if-then 形式のルール3つにまとめて」と頼む。ここで大事なのは最適値を1点だけ出させないことで、ルールの形にさせるからこそ、次に別の機種を触るときに人間が持ち込める知識になる。次の段階は、そのルールを機種横断で検証することだ。同型機3台に同じルールを当てて外れる台があれば、外れた理由（負荷イナーシャ、配管長、周囲温度）がそのままルールの条件節に追加すべき変数になる。この往復を2〜3周すると、社内の立ち上げ手順書に書ける精度になる。コストは無料枠の生成 AI とスプレッドシートだけなのでゼロ円で始められ、試行を自動で回すところまで作り込むなら計測器のロギング環境が要るので数万円〜。注意点として、AI が出したルールを鵜呑みにして実機の安全側パラメータを緩めないこと。ルールはあくまで「次に試す条件の候補」として扱い、上限値・トルク制限・非常停止の設定は従来どおり人間が決める、という線引きを最初に紙に書いておくと事故を防げる。

中身の3パターンが投稿の続きにある形なので、ここは「自分の現場版の3パターン」を先に作ってしまうのが実利がある。最初の一歩は今日30分でできる。手元の直近プロジェクト1本を GX Works で開き、コピペで作った回路ブロックを検索して、デバイス番号の置き換え漏れ・タイマ番号の重複・立ち上がり接点の元信号が旧ブロックのまま、の3点だけを目視で潰す。ほぼ確実に1つは出てくるはずで、出てきたパターンをメモに残す。次の段階は、これを人力の目視から機械の検査に移すことだ。GX Works からデバイス使用一覧やプロジェクトを CSV／テキストで書き出し、Excel か GAS で「同一タイマ・カウンタ番号が複数の回路で出力側に使われていないか」を突き合わせるだけのチェック表を作る。二重コイルと番号重複はこれで相当な割合が機械的に拾えるので、コピペ由来の事故は目に見えて減る。さらに進めるなら、書き出したラダーのテキストを生成 AI に貼って「このブロックはこの上のブロックのコピー元と何が違うか、デバイス番号の差分だけを表にして」と頼む使い方が効く。差分を人間が読む形にしてくれるので、置き換え漏れが一覧で浮かぶ。コストは、目視とチェック表なら手持ちのツールだけでゼロ円、AI に読ませる部分も無料枠で試せる。注意点は2つで、1つは社外案件のラダーを外部サービスへ貼るのは秘密保持の問題があるので、まず自社の練習用プロジェクトか、デバイス名を伏せ字にしたものでやること。もう1つは、機械チェックが通ったことを「動作確認した」と読み替えないこと。番号の重複は拾えても、コピー元の回路が今回の設備で意味を成すかどうかは人間にしか判断できない。

「保存＝即本番」という性質は、制御屋にとってはオンライン書き込みそのものなので、扱い方も同じにするのが早い。最初の一歩として、引き継いだ GAS を開いたらコードを1文字も触る前に、プロジェクト全体をコピーして `〇〇_退避_20260828` という名前の別プロジェクトを作ってしまう。ラダーで言えば書き込み前の吸い上げに当たる作業で、これをやっておけば変更履歴に頼らずいつでも戻せる。次の段階は、時間主導トリガーの扱いだ。定期実行が保存だけで置き換わるということは、あなたが編集している最中の中途半端なコードが夜中に走る可能性があるということなので、修正に着手する前にトリガー一覧を開いて対象トリガーを一時削除し、スクリーンショットで設定内容を残しておく。作業が終わって動作確認できてから同じ設定で作り直す。この「止める→直す→戻す」の順番を守るだけで、業務が止まる事故はほぼ防げる。実務での最初の対象としては、日報や点検記録をスプレッドシートに集める GAS、あるいは客先報告書のフォーマット整形をしている GAS が向いている。壊れても翌朝手作業で埋め合わせが利く範囲から始めるのが安全だ。コストはすべて Workspace の標準機能なので追加費用ゼロで、かかるのは1本あたり30分程度の手間だけ。注意点として、退避コピーを作るときにスプレッドシートやフォームへのバインドがある場合は、コピー先が本番のシートを掴んだままになることがある。退避プロジェクトのトリガーは必ず空のままにして、二重に走らせないこと。ここを外すと、直すつもりが本番データを二重書き込みする側に回ってしまう。

「半年後に別の担当者が触っても壊れていないことを機械的に保証する」というのは、まさに制御設計で引き継ぎのたびに困っている話なので、GAS を持っているなら試す価値がある。最初の一歩は、いきなり全体をテストしようとしないこと。今動いている GAS の中から、判定ロジックが1つだけ入った関数を選ぶ。たとえば点検記録の「測定値が管理値を外れていたら NG を返す」関数や、日報から稼働時間を計算する関数がちょうどいい。その関数だけを SpreadsheetApp などの GAS 固有 API に触らない純粋な関数として切り出し、入力と期待値の組を5つ書く。上限ちょうど、上限＋0.1、空欄、文字列、マイナス値の5つで、境界のバグはほぼ拾える。次の段階は、この形をテンプレート化して横展開することだ。GAS 固有の API を触る部分と判定ロジックを分けるという書き方さえ守れば、テストできる範囲は自然に広がる。制御屋にとっては、シーケンスの判定条件をシミュレータで空打ちしてから実機に入れるのと同じ発想だと考えるとしっくりくるはずだ。コストは、Node.js と Vitest と clasp がいずれも無料なので金銭的にはゼロ。かかるのは最初の環境構築の半日程度で、2本目からは1本あたり1時間もかからない。注意点は、テストが通ったことを「業務が正しい」と読み替えないこと。テストが保証するのは、あなたが書いた期待値どおりに関数が動くことだけで、管理値の設定そのものが間違っていれば通ったまま間違い続ける。だから期待値の表を作るときは、現場の管理値表と突き合わせて数字を写す工程を必ず人間の手順として残しておきたい。

影響範囲が @siemens/maps-ng パッケージのみと明記されているので、まずやるべきは「自分は当事者か」の切り分けだ。最初の一歩は、客先で納めた HMI や監視画面のうち、ブラウザで開く形式のものを洗い出し、地図表示を使っている画面があるかを確認すること。工場のレイアウト図や設備配置図を地図コンポーネントで描いている監視システムがあれば当たりで、なければ今回は対象外と結論を書いて終わらせてよい。この「対象外だと文書で結論づける」工程まで含めて15分で終わる。次の段階は、当たった場合の更新計画だ。Siemens が新バージョンを出しているので最新版に上げるのが正解だが、現場の監視システムは止められない時間帯があるので、更新のタイミングを客先の生産計画と突き合わせて決める。攻撃条件が「細工されたURLを開いてピンにマウスを重ねる」である以上、更新までの暫定策としては、監視 PC から外部リンクを開かせない運用と、オペレータへの「監視画面のURLはブックマークからしか開かない」という周知が効く。コストは、パッケージ更新自体はライセンス内なので追加費用なしで、実作業は動作確認を含めて半日〜1日を見ておく。注意点として、この手の Web コンポーネント由来の脆弱性は「制御機器ではないから関係ない」と扱われて放置されやすい。実際に狙われるのは制御機器そのものではなく、それを見ている端末のブラウザセッションのほうなので、OT 側の資産台帳に「監視画面が使っている Web コンポーネントとそのバージョン」の列を足しておくと、次に同種の勧告が出たときの判断が数分で済むようになる。

無料・事前登録制で会期が来週の9月3〜4日なので、行くか行かないかを今日中に決めてしまうのが実利がある。最初の一歩は、事前登録を先に済ませてしまうことだ。登録は無料なので、当日行けなくなっても失うものはない。逆に登録を後回しにすると定員や締切で落ちる。狙いを「AIエージェント活用の留意点」の回に絞るなら、9月4日（金）10:30〜11:30 のワークショップセッション WS C だけを目的に、午前だけ抜ける形でも十分に成立する。次の段階は、聞きに行くなら質問を3つ用意していくことだ。展示会の講演は一般論に寄りやすいので、自分の案件に引きつけた具体的な問いを持っていくかどうかで持ち帰りの量が変わる。制御設計・現場対応をやっている立場なら、「エージェントに装置のパラメータ変更まで任せている事例で、変更前の承認はどう取っているか」「誤操作したときの責任分界はどこに引いているか」「導入した現場で最初に止まったのはどの工程か」あたりが効く。留意点が主題の講演なので、この種の質問は本題とも噛み合う。コストは参加費が無料なので、実質かかるのは交通費と半日〜1日の時間だけ。首都圏以外から出るなら費用対効果を測りにくいが、同時開催の「AI Innovation Tokyo 2026」「DXシステム開発 Expo 2026」も同じ会場で回れるので、AI 関連の情報収集をまとめて1日で済ませる日と割り切ると計算が合う。注意点は、この手のイベントで聞いた導入事例を、そのまま社内で「他社はやっている」と紹介しないこと。展示会で語られる事例は成功側に寄っているので、持ち帰った話は必ず「自分の設備で最初に詰まるのはどこか」に翻訳してから共有したい。

「事実と評価を分けてから話す」は精神論に見えて、実は帳票の設計で解ける問題なので、そこに落とすのが早い。最初の一歩は、A6サイズのカードを作って工具箱に入れておくことだ。上半分に「発生時刻（時:分:秒）」「アラーム番号」「該当I/O番号」「そのときの運転モード」の4項目だけを枠で用意し、下半分は空白にして所見を書く欄にする。異常が出たら上半分を先に埋めるという物理的な順序を作ってしまえば、口が先に動くのを構造で止められる。次の段階は、このカードをそのまま報告フォーマットにすることだ。Google フォームで同じ4項目＋所見の構成を作り、スマホから現場で入力させれば、送信時刻がタイムスタンプ代わりになるうえ、スプレッドシートに全件たまる。半年ためると「どのI/Oが何回目の犯人か」を集計できるようになり、これは勘に頼っていた再発対策を数字に変える材料になる。さらに進めるなら、たまった記録を生成 AI に貼って「同じI/O番号が絡む事象を時系列でまとめ、共通する運転モードがあるか」と聞く使い方が効く。人間が見落とす頻度の偏りを拾ってくれる。コストは、カード運用なら印刷代だけ、Google フォームとスプレッドシートも Workspace の範囲なので実質ゼロ円。注意点は、この記録を個人の評価に使わないと最初に宣言しておくこと。誰が対応したかを責任追及の材料にした瞬間、現場は書かなくなるか、書く内容を無難に丸めるようになる。集めたいのはI/O番号と時刻という事実であって、担当者の技量ではない、という線引きを運用の最初に明示しておきたい。

これは「立ち上がりでしか値を読まないブロックに、連続変化する指令を渡そうとした」という、メーカーを問わず踏む型の落とし穴なので、自分の手持ち資産で同じ地雷を踏んでいないかを確認するのが先だ。最初の一歩は、手元のモーションプログラムを開いて、Execute の立ち上がりでパラメータをラッチするタイプのブロック（位置決め、速度指令、トルク制限）を全部拾い出し、そこへ渡している値が定数か変数かを見ることだ。変数を渡しているのに Execute が常時 ON のままなら、値を変えても効かない、あるいは前回値が残るという症状の候補になる。次の段階は、渡す側で明示的に「値を確定してから起動する」順序を作ることだ。指令値を専用のワークデバイスにコピーする1スキャンを挟み、そのコピー完了ビットを条件に Execute を上げる。1スキャン分の遅れは実害がほぼ無い一方、前回値が残る系のバグはこれでほとんど消える。加えて、投稿にあるような「入力は正しいのにドライブが前回の速度を受け取る」現象は、指令が本当に届いているかを PLC 側からは確認できないので、ドライブから読み戻せる実速度・実指令値をモニタ変数として常時ロギングしておくと、次に再発したときに切り分けが数分で終わる。コストは、プログラム側の対策なので追加費用はゼロ、ロギングを追加する場合も既存の SCADA かデータロガーの範囲で収まることが多い。注意点は、この手の「動いたからよし」の回避策は、書いた本人以外には意図が読めないこと。ワークデバイスを経由させる1スキャンには必ずコメントで理由（立ち上がりでしか読まれないため、指令確定後に Execute を上げる）を書き残しておかないと、次に触る人が「無駄な処理」として消してしまい、同じ不具合が再発する。

これは「AI に承認を任せる仕組みは、それ自体が壊れ方をする」という話なので、自分の使い方に直接効く。最初の一歩は、AI エージェントに何を見せているかの棚卸しだ。今日 Claude Code や同種のツールを起動しているフォルダを確認し、その上の階層に客先の図面、見積、パスワードを書いたメモ、クラウドの認証情報が置かれていないかを見る。記事が挙げている「ホームディレクトリ・SSH鍵・クラウド認証情報をエージェントのランタイムに露出させない」は、そのまま「作業用フォルダをホーム直下から切り離す」という一手で効く。次の段階は、実行の場所を分けることだ。手元 PC で全部やるのをやめ、素性の分からないリポジトリやダウンロードしたアーカイブを扱う作業は、使い捨ての仮想マシンかコンテナの中でだけ行う。Windows なら Hyper-V か WSL の別ディストリビューションを1つ用意しておけば、壊れたら作り直せる。記事の攻撃がアーカイブの展開と import を経由している以上、「よそから来た zip を開く作業」を隔離するだけで踏む確率は大きく下がる。3つ目に、承認の出し方を見直したい。auto mode が有害なプロセスの生成は許可し、その後始末のコマンドをブロックしたという事例が示しているのは、自動承認が「危ないほうを通し、安全なほうを止める」向きにも外れ得るということだ。だから、ネットワーク通信を伴うコマンドとファイル削除を伴うコマンドだけは自動承認から外し、目で見る運用に戻しておくのが現実的な落としどころになる。コストはいずれもゼロ円で、仮想マシンを1つ作る半日と、設定の見直しに30分。注意点として、これは Claude Code 固有の欠陥として片付けないこと。分類器で危険な操作を弾く設計はどのベンダーのエージェントも採っているので、同じ型の破られ方は横並びで起こり得る。「安全機構があるから大丈夫」ではなく「安全機構が外れても被害が閉じる場所で動かす」という置き方に変えるのが本筋だ。

前のトピックの防御策が、そのままオプション1つで手に入る形になっているので、今日から使える。最初の一歩は、素性の分からないコードを読むときだけ `--restricted` を付けて起動する習慣にすることだ。ネットで拾ったサンプル、客先から送られてきたプロジェクト一式、GitHub の知らないリポジトリを読ませるときは、コマンド実行と WebFetch が落ちた状態で読ませる。ファイルツールが作業ディレクトリの中に留まるので、上の階層の資料を巻き込む事故も同時に防げる。次の段階は、用途で起動方法を分けることだ。自分が書いたコードを直させる普段の作業は従来どおり、読むだけ・調べるだけの作業は `--restricted`、という2本立てにして、後者をバッチファイルかシェルの alias にしておくと、判断を毎回しなくて済む。`CLAUDE_CODE_RESTRICTED=1` で環境変数からも指定できるので、調査用のターミナルプロファイルを1つ作ってそこに設定を焼いてしまうのが手っ取り早い。注意すべき副作用として、`--restricted` はユーザー・プロジェクト・ローカルの設定ファイルを無視するので、普段使っている許可設定やプロジェクト固有の指定はすべて効かなくなる。「いつもの動きをしない」と感じたらこのオプションのせいなので、切り分けの一番目に置いておきたい。逆に言えば、設定ファイル自体が汚染されている可能性を疑う場面ではこれが効く。コストはサブスクの範囲でゼロ円、必要なのはバージョンを上げることだけ。もう1つ、同じリリースで同一マシン上のセッション間メッセージングがテレメトリ無効時にも使えるようになっているので、社内ネットワークの制約でテレメトリを切っている環境でも複数セッションを連携させる使い方が可能になった。閉じたネットワークで運用している人は、ここも合わせて確認しておくといい。

これは自分の雇用より、「若手にどう仕事を渡すか」の設計に効く話として読むのが実利がある。制御設計の現場で AI に置き換わりやすいのは、まさに若手が経験を積むために振られてきた仕事——タグ表の作成、コメントの整備、既存プログラムの読み解き、報告書の下書き——だからだ。最初の一歩は、自分のチームで新人に振っている作業を1週間分書き出し、「AI に投げたら10分で終わるもの」に印を付けてみることだ。おそらく半分近くが該当する。次の段階は、その印が付いた作業を単純に AI へ移すのではなく、渡し方を変えることだ。具体的には、新人に「まず自分でやる」ではなく「AI に出させた結果をレビューして、間違いを3つ指摘する」という形で渡す。タグ表の命名規則チェックでも、ラダーの二重コイル検査でも、AI の出力には必ず取りこぼしと過検出が混ざるので、そこを見つける作業は現物の理解がないとできない。つまり、経験を積む場としては元の作業と同等かそれ以上に機能する。3つ目に、レビュー結果を記録に残すことを勧めたい。「AI がこう言ったが、実際はこうだった」という差分は、そのまま社内のノウハウになり、次に AI へ渡すときのプロンプトにも組み込める。コストは追加のツールが要らないのでゼロ円、必要なのは仕事の振り方を決め直す時間だけだ。注意点として、この研究が示しているのは職種と年齢による雇用変化の偏りであって、あなたの会社で誰を採るべきかを直接教えてくれるものではない。数字を根拠に採用や配置を語るのではなく、「若手が経験を積む経路が細くなりやすい」という警告として受け取り、経路を自分の手で作り直すほうへ使いたい。