2026年9月3日

まず自分の手元にある「もう納めた・止めても誰も困らない」テストプロジェクトを1本用意して、read-only 系のコマンドだけを流すところから始める。タグ一覧やブロック構成を JSON で吐かせて、GX Works3 でいう「タグ表を CSV 出力」と同じ感覚で AI に読ませられるかを確認する。
次の段階は、変更系を dry-run のまま走らせて差分だけを読む運用。ここで「AI が出した差分を自分が説明できるか」を試すのが本番の分かれ目で、説明できない差分に `--apply` を付けないというルールを自分に課す。
三菱系がメインなら直接は使えないが、考え方は今日から移植できる。GX Works3 でも「AI に読ませるのはエクスポートしたテキストだけ」「書き戻しは人間の手で」という境界を先に決めておけば、ツールが追いついたときにすぐ乗れる。
コストは、ツール自体は OSS なので実質ゼロ。掛かるのは TIA Portal のライセンスと自分の検証時間で、初回の素振りは半日みておけばよい。
注意点は3つ。コンパイルが通ることと仕様が正しいことは別物なので、インターロックの妥当性は必ず人間が別途検証する。稼働中設備へのオンライン書き込みは、ツールが禁じていても自分の運用としても禁じる。導入前にライセンス条項（配布形態によって MIT と AGPL-3.0 が混在する）を客先案件に持ち込めるか確認する。

明日できる最初の一歩は、今担当している装置1台について「処理の時間要求表」を1枚作ること。エクセルで3列（処理名／許容遅れ／落ちたときに何が起きるか）だけでよい。インターロック、非常停止、位置決め、画像判定、ログ書き出し、帳票送信を並べると、たいてい「なぜかスキャンに同居している遅くていい処理」が1つ2つ見つかる。
次の段階は、その表を根拠に切り分けを提案すること。時間保証が要る処理は PLC のスキャンに残し、履歴保存や帳票出力はゲートウェイ PC や上位に逃がす。三菱系なら、CPU のスキャンタイム実測値を before/after で並べれば説得材料になる。
この表は AI と相性がよい。処理名と許容遅れを貼って「この構成でスキャンタイムが跳ねるリスクがある箇所を挙げて」と聞けば、見落としの当たりを付けられる。ただし最終判断は実測で、AI の指摘は仮説として扱う。
コストはゼロ。既存の設計レビュー1時間を、この表のレビューに置き換えるだけで済む。
注意点は、この切り分けを「性能が足りないから」と説明しないこと。今のコントローラは性能が足りている。足りていないのは時間保証の設計で、そこを言い分けないと客先には単なる構成の複雑化に見える。

最初の一歩は「案件フォルダの雛形コピー」を1本組むこと。案件番号と客先名をフォームで受けて、Copy Drive file で標準フォルダ（図面／タグ表／議事録／検査成績書）を複製し、Move Drive file で年度フォルダ配下へ入れる。新規案件の立ち上げでいつもやっている手作業がそのまま1フローになる。
次の段階は Reply to email との組み合わせ。客先から届く「現地調査日程の確認」のような定型メールに、スレッドを保ったまま受領返信を自動で返す。スレッドが割れないので、後から不具合対応の経緯を追うときに時系列が壊れない。
現場側は Chat 返信が効く。装置停止の一報を受けるスペースに、Markdown のチェックリスト（電源／エア／原点／インターロック）を自動投稿すれば、一次切り分けの抜けが減る。コードブロックが使えるのでエラーコードの貼り付けも読みやすい。
コストは、Workspace の対象エディションを契約していれば追加費用なし。GAS を書かずに組めるのが利点で、初回の1フローは1〜2時間で作れる。
注意点は権限まわり。管理者が組織外へのデータ共有に承認を要求できる設定になっているので、客先ドメインを含むフローは必ずその承認を有効にしてから作る。図面が入ったフォルダを自動コピーする以上、コピー先の共有設定は毎回目視で確認すること。

最初の一歩は、自分の業務文脈を1本のカスタム指示に落とすこと。「私は装置メーカーの制御設計担当。PLC は三菱 GX Works3 が主。回答は結論を先に、手順は箇条書き、単位は SI、推測は推測と明示すること」程度を保存する。これを一度書けば、Sheets でタグ表を触るときも Gmail で客先返信を書くときも同じ前提で返ってくる。
次の段階は、面ごとの追加指示。Sheets 側には「表を触るときは列の意味を先に確認し、勝手に行を並べ替えない」、Gmail 側には「客先向けは敬体、社内は常体」など、事故りやすい癖を先に潰す指示を足す。
効くのは報告書と帳票。不具合対応の報告メールを Gmail のサイドパネルで下書きさせるとき、毎回「現象・原因・処置・再発防止の4段で」と打ち込んでいたものが不要になる。1日10回のプロンプト打ち直しが消えると体感が変わる。
コストは、Gemini が使える Workspace エディションなら追加費用なし。管理者設定も不要なので、自分のアカウントだけで今日始められる。
注意点は、カスタム指示は「好みの反映」であって「正しさの保証」ではないこと。型番や設定値は必ず一次資料で裏を取る。あと、客先固有の情報を指示文へ書き込まないこと。個人設定として保存され続けるので、案件が終わっても残る。

今日やることは版数の棚卸し1点。JVN の該当ページによれば影響を受けるのは XG-X VisionTerminal Ver.3.6.0000 以前と XG VisionTerminal Ver.5.5.0010 以前で、対策は XG-X VisionTerminal Ver.3.7.0000 以降へのアップデート（XG VisionTerminal 側は XG-X への移行が推奨）。客先の画像処理機で XG シリーズを使っている案件を思い出して、まず「どの盤に何 Ver が入っているか」の一覧を作る。
次の段階は運用ルール。この脆弱性は細工された設定ファイルを利用者が開くことで機微情報が漏えいし得るという性質なので、回避策は「信頼できない設定ファイルを開かない」に尽きる。客先やライン担当から送られてくる設定ファイルを、素性を確認せずにダブルクリックしない運用へ変える。持ち込み USB の扱いも同じ線で見直す。
アップデートの現実的な段取りは、次の定期停止に合わせること。画像処理機の版数を上げると判定パラメータの互換で揉めることがあるので、更新前に現行の設定ファイルとマスタ画像を必ず退避し、更新後は良品・不良品の既知サンプルで再現確認をしてから本稼働へ戻す。
コストはソフト更新自体は無償の範囲だが、実質コストは停止時間と再検証。1機種あたり半日〜1日の停止枠を見込んで客先と調整する。
注意点は、CVSS の基本値が中程度（CVSS 4.0 で 6.7）で攻撃元区分がローカルなため、緊急停止してまで当てる性質ではないこと。「今すぐ止める」ではなく「次の停止で確実に当てる」＋「不審な設定ファイルを開かない」の2段で客先に説明するのが誠実。

この手の公的な調査報告書は、客先に提案を通すときの「うちだけじゃない」材料として効く。最初の一歩は、報告書本体を落として自分の担当業種（需要設備、送配電など）の節だけを読み、コストと人材不足に関する記述をそのまま引用できる形で1枚にメモしておくこと。
次の段階は提案書への織り込み。遠隔監視や自動計測の提案が「便利だから」で止まると予算が付かないが、「国の機関の調査でも普及の最大の障壁はコストと人材と示されている＝御社だけの悩みではない」と置くと、話が費用対効果の議論へ進む。
自分の業務に直結するのは、AI による異常予測・寿命予知の位置づけを冷静に見ておくこと。タブレット活用やデジタル計器のような「記録のデジタル化」に比べ、AI 予測は導入が進んでいない領域なので、そこをいきなり提案すると空振りしやすい。まずは点検記録の電子化とデータ蓄積を先に通し、AI はその次の段階として置く。
コストはゼロ（報告書は公開資料）。掛かるのは読む時間だけで、必要な節に絞れば1〜2時間。
注意点は、報告書の数字を提案書に引くときは必ず年度と調査対象を併記すること。業種によって普及度がまるで違うので、他業種の高い数値を自分の客先に当てはめると足元をすくわれる。

明日の仕事が変わる話ではないが、押さえるべき点は「学習データを共同で集める」という座組み。装置メーカーとして読むべきは、ロボット単体の性能ではなく、誰がデータを持ち、誰が使えるのかという契約構造のほうだ。最初の一歩として、自社が客先ラインで取っているデータ（サイクルタイム、異常履歴、画像）について「所有者は誰か」を1度整理しておく。
次の段階は客先との取り決め。AI 活用の話が出たときに必ず揉めるのが、現場データを自社の学習に使ってよいかという点。共同で集めて参画企業が使う、という J-HRTI 型の建て付けは、そのまま客先への提案テンプレートになる。「御社のラインのデータを、匿名化した上で当社の判定モデル改善に使わせてほしい。見返りに改善版を優先提供する」という形にできる。
実務的には、オペレーターが操作して学習データを作るという方式自体が示唆的。ティーチングやトラブル対応の操作ログを残す仕組みを、今のうちに装置側に仕込んでおくと、後で AI 化するときの資産になる。ログ出力のフォーマットだけ決めておけば追加コストはほぼない。
コスト感は、自社データの棚卸しは工数のみ。ロボット導入の検討まで進めるなら数百万〜数千万円規模の話になるので、今は情報収集の段階に留めるのが妥当。
注意点は、ヒューマノイドの話をそのまま自社ラインへ持ち込まないこと。既存の産業用ロボットで足りる工程にヒューマノイドを提案すると信用を落とす。見るべきは「多品種で治具を作りきれない工程」に限る。

参考にすべきは HMI の作り方。168 ステーションを1画面で、運転状況・サイクルタイム・アイドル台数・診断の4項目に絞って見せている。自分が次に作る一覧画面でも、まずこの4項目だけに絞って設計してみる。GX Works3 と GT Designer3 の組み合わせなら、ステーション単位の構造体を1つ作って配列化し、一覧画面はその配列を回すだけにすれば、台数が増えても画面を作り直さずに済む。
次の段階は「アイドル台数」の扱い。停止台数ではなくアイドル台数を出しているのが実務的で、稼働率の議論が現場でそのままできる。ラインの日報に手書きしている項目を1つ選んで、まず PLC 側でカウントを持たせ、HMI に出すところから始める。
盤内冷却の話は他人事ではない。繊維くず、切削油ミスト、粉体のいずれかがある客先では、扇風機での暫定対応が恒久化しがちで、数年後に基板不良として返ってくる。引き渡し時の「暫定」は必ず期限と恒久対策を書面に残す。今担当している案件で暫定のまま放置している箇所がないか、今週中に洗い出す。
コストは、排気ファンとフィルタ付きルーバーへの改修なら1盤あたり数万円程度。設計段階で盤の密閉方針を決めておけば追加費用はほぼ発生しない。
注意点は、旧制御配線からの全面更新は引き渡し後の数週間が本番だということ。ダウンタイムゼロを報告できているのは、引き渡し後も監視を続けているから。自分の案件でも、引き渡し1か月は診断ログを取り続ける約束を先に取り付けておくとよい。

開催が今日と明日なので、動くなら今すぐ。最初の一歩は、申込ページを開いて自分の担当領域に近いセッションを1本だけ選ぶこと。全部聞こうとすると結局どれも聞けないので、「現場を止めない」の枠に絞るのが制御設計・現場対応の立場では費用対効果が高い。
次の段階は、聞いた内容を客先提案の語彙に変換すること。OT セキュリティの提案が通らない最大の理由は、情シス向けの語彙で話してしまうこと。「侵入検知」ではなく「装置を止めずに異常な通信を見つける方法」と言い換えられるネタを、セミナーから2〜3個だけ持ち帰る。
自分の業務で直結するのは、盤内のスイッチとリモート I/O のネットワーク分離。同じ話題を扱う枠があれば、既存案件のネットワーク構成図を手元に開きながら聞くと、その場で「うちのあの案件は危ない」が具体的に見つかる。
コストは、この種の WEB セミナーは通常無償。掛かるのは2時間程度の時間だけで、録画配信がある場合は後追いでも成立する。
注意点は、ベンダー主催なので当然自社製品の提案が含まれること。持ち帰るべきは製品名ではなく、脅威の分類と現場での見つけ方のほう。客先には「フォーティネットが言っていた」ではなく「OT ではこういう分類で考える」と伝える。

最初の一歩は、モデルを乗り換える前に「自分の定番タスク3本」で比較すること。制御設計なら、①タグ表 CSV の命名規則チェック、②客先向け不具合報告のドラフト、③英文マニュアルの該当箇所抽出、あたりが定番のはず。同じプロンプトを流して、手直しに掛かった時間を測る。ベンチマークのスコアより、この実測のほうが判断材料になる。
次の段階は推論レベルの使い分け。5段階あって無効化できないということは、軽いタスクに重い推論を使うと時間もコストも無駄になるということ。定型の文章整形は low、設計の妥当性を突き詰める議論は high 以上、と自分の中で対応表を作っておく。
セーフガードの誤介入が減ったという点は、実務では地味に効く。装置の安全回路や異常時の挙動について相談すると、これまで「危険」と判断されて話が止まることがあった。インターロックの条件整理のような相談が通りやすくなるか、手元の1件で試す価値がある。
コストは、サブスクリプションの範囲で使えるなら追加費用なし。API 従量で使う場合は、タスクによって半額以下になるという報道があるので、月次の請求を1か月分だけ突き合わせて実際の変化を確認する。
注意点は変わらない。モデルが賢くなっても、型番・設定値・規格番号の裏取りは自分でやる。特に科学タスクが強くなったという話に引きずられて、計算結果をそのまま設計に載せないこと。検算は必ず別経路で行う。

発想をそのまま制御設計に移すと、「毎朝決まった時刻に走らせたい定例作業」が対象になる。最初の一歩は、自分の朝のルーチンを3つ書き出すこと。案件フォルダの更新確認、客先からの未返信メールの洗い出し、進行中案件の期限チェックあたりが典型で、このうち1つを自動起動に載せる。
次の段階は「一次調査」の移植。本番エラーの一次調査を任せるという発想は、装置の異常ログの一次切り分けにそのまま効く。夜間に出た異常コードの一覧を朝の時点で分類（電源系／通信系／センサ系／不明）させておけば、出社してすぐ優先順位を判断できる。ログの置き場と分類ルールさえ決めれば、あとは定型作業。
注意すべきは責任分界。AI に任せるのは「分類と一次仮説」までで、処置の判断は必ず人間が行う。前段のトピックにもあった話だが、切り出すべきは判断そのものではなく、判断の材料を揃える手前の作業。
コストは、記事の趣旨どおりサブスクリプションの定額内で回せるのが利点。ただし自動起動は使っていないつもりでもトークンを消費するので、頻度は最初「1日1回・平日のみ」から始めて、効果を見てから増やす。
注意点として、客先の図面やタグ表が入ったフォルダを自動処理の対象に含めないこと。人が都度確認して投げるのと、自動で毎朝走るのとでは、情報の扱いに対する客先の見え方がまったく違う。対象フォルダは社内資料に限定したうえで、先に上長へ運用を共有しておく。

個人の立場で今日できることは少ないが、押さえるべき流れは「セキュリティ用途に振った専用モデルが分かれ始めた」という点。最初の一歩として、自分が普段使っている汎用モデルに OT セキュリティの相談をしたときの回答品質を、一度意識して観察してみる。専用モデルの存在は、裏を返せば汎用モデルがこの領域で慎重に振る舞うということでもある。
次の段階は、使い分けの線引き。脆弱性情報の要約や、JVN の記述を平易な日本語に直す、といった読解タスクは汎用モデルで十分。一方で「この構成が攻撃可能か」を判断させるような用途は、そもそも AI に任せる話ではなく、客先のセキュリティ担当や専門ベンダーに回す。この線を先に引いておく。
実務で効くのは、政府・重要インフラ向けにアクセスを限定したプログラムが作られたという事実そのもの。客先の工場が重要インフラに関わる場合、相手側のセキュリティ要求水準は今後上がる。装置を納める側として、盤内ネットワークの構成図と通信ポート一覧を、いつ聞かれても出せる状態にしておく。
コストはゼロ。構成図とポート一覧の整備は、既存案件の資料をまとめ直すだけで、1案件あたり1〜2時間。
注意点は、この種の発表を客先への提案材料に使わないこと。限定プログラムであり、装置メーカーが直接使えるものではない。使えるのは「大手がこの領域に投資している＝要求水準が上がる」という文脈の説明までに留める。