2026年8月4日

昨日までの第4〜6章（接続と IP 設定）に続き、いよいよ通信が通る章なので、社内検証盤で追試するならここまでで一区切りにできる。最初の一歩は、KV STUDIO 側の設定順（PORT1 をスキャナに→Generic Device 追加→Input Only のタグ指定→W デバイス割付）を自社の手順書テンプレにそのまま起こすこと。次の段階は、DINT が W 2点に割れる仕様を前提に、受信側のコメント付け規約（下位/上位ワードの命名）を先に決めておくこと。ここを曖昧にすると立上げ時のモニタで値の解釈を毎回間違える。コストは Studio 5000 のライセンスと実機があれば追加費用ゼロ。注意点は、本章は一方向（Rockwell→KV）だけなので、双方向が要る案件では逆方向の章（続報）を待つか、PLC リンク方式との比較検証（第9章予定）を見てから客先提案に使うこと。

明日の案件からチェックリストに1行足せる話。最初の一歩は、いま設計中の盤の負荷リストに「投入タイミング」列を追加し、電源ON直後に同時に立ち上がる負荷へ印を付けること。Excel の負荷表があれば10分で終わる。次の段階は、立上げシーケンスのラダーに投入順序と時間差（サーボ主電源は制御電源確立の数秒後、ヒータはさらに後、など）を明示的に組み、タイマ設定値をパラメータ化して現地調整できるようにしておくこと。コストはゼロで、効くのは現地立上げでの「たまに落ちるが再現しない」調査時間の削減。注意点は、瞬間的な電圧低下はテスターでは捕まらないという投稿の指摘どおりで、疑わしい場合は PLC 側で 24V 系の電圧監視やサーボ主電源投入時の異常履歴を記録する回路を先に仕込んでおくと、現象が出た瞬間の証拠が残る。

これまで「ChatGPT や Gemini のチャット画面で GAS コードを書かせて、エディタに貼って動かして、エラーをまた貼り戻す」という往復をしていたなら、その往復がエディタ内で完結する方向の機能。最初の一歩は、自分の Google アカウントが Gemini Beta プログラムの対象かを確認すること（Workspace 管理者側の設定に依存するため、個人アカウントと会社アカウント両方で Apps Script エディタを開いてサイドパネルの有無を見るのが早い）。使えるようになったら、既存の帳票スクリプト（点検記録の集計や報告書の自動生成）を開いて「この関数が遅い理由と直し方」を聞くところから始めると、プロジェクトの文脈を読む強みがすぐ分かる。コストは追加費用の記載がなく Beta 登録の範囲。注意点は Beta 限定である以上、挙動や提供条件が変わり得ること。業務スクリプトの本番改修をいきなり任せず、まずコピーしたプロジェクトで試す。

客先からの不具合連絡・図面承認・納期回答のメールが社内メルマガに埋もれる問題への処方箋としてそのまま使える。最初の一歩は、Gmail の検索窓で「客先ドメイン OR 件名キーワード（不具合・至急・承認）」の検索クエリを手で作って精度を確かめること。ここが決まればコードは記事の写経で動く。次の段階が本記事の肝で、キーワード表をスプレッドシートに逃がしておくこと。案件が変わるたびにコードを触らず、表に1行足すだけで済むし、自分が現場出張中でも事務所のメンバーがルールを直せる。コストはゼロ（GAS・Slack の無料範囲）。Slack を使っていない職場なら LINE Notify 相当や Chat への置き換えも同じ構造で組める。注意点は5分おきトリガーの実行回数が GAS の無料枠消費になることと、通知を増やしすぎると結局読まれなくなること。除外ワードの表を最初から用意し、鳴りすぎたら足す運用にする。

CC-Link IE TSN は今後の三菱系ネットワーク提案の本命なので、担当設備が該当するかの棚卸しを先にやる。最初の一歩は、三菱電機の PSIRT ページで本件のアドバイザリを開き、対象製品リストと自分の担当案件の機器構成（CPU・ネットワークユニット・スイッチ）を突き合わせること（1時間仕事）。次の段階は、客先に説明できる形で「TSN ネットワークが工場の情報系や外部とどこで接続されているか」を構成図で確認すること。今回の脆弱性は「ネットワークへアクセス可能な攻撃者」が前提なので、制御ネットワークのセグメント分離と持ち込み PC・保守用ポートの管理が実質の防壁になる。コストは調査自体はゼロ、対策はネットワーク構成の見直し規模次第。注意点は、生産中の設備に安易にファーム更新をかけないこと。まず軽減策・回避策（アクセス制限）で守り、更新は定修などの停止機会に計画する。客先から問い合わせが来る前にこちらから一報を入れると信頼になる。

客先工場の「再現しないチョコ停」対応にそのまま使える技。最初の一歩は、いま抱えている再現待ちのトラブル1件について、疑わしい条件を3つ書き出し、それぞれに SET 命令の記憶用内部リレーを1個ずつ仕込むこと（ラダー追加は30分、リセットは調査用の手動ボタンにまとめる）。次の段階は、記憶だけでなく発生時刻も欲しくなるので、条件成立時に PLC の時計データをデータレジスタに転送する定型回路を社内部品化しておくこと。GX Works3 ならライブラリ登録しておけば次の案件から数分で入る。コストはゼロで、ビデオカメラ設置より早くて確実な場面が多い。注意点は、調査用回路を入れたまま納品しないこと。調査回路には専用のデバイス帯とコメント（例:「調査用・撤去予定」）を割り当て、終わったら消す運用をセットにする。この「仕込み→確認→撤去」の型を若手に教えると、なぜなぜが精神論でなく手順になる。

非常停止系は直列段数が多く「どこかの接点1つ」を探す時間が停止時間に直結するので、半分割法は新人教育の定番にする価値がある。最初の一歩は、この動画（英語だが画面を見れば流れは追える。字幕の自動翻訳でも十分）を若手と一緒に見て、自社設備の非常停止回路図で「最初にどこへテスターを当てるか」を言わせてみること。次の段階は、盤設計側への還元で、非常停止ループの中間に測定しやすいチェック端子を設計段階から入れておくこと。半分割法は「測りやすい中間点があるか」で速度が決まるため、端子台の配置一つで現地対応が数十分変わる。コストは動画視聴はゼロ。注意点は、電圧測定と抵抗測定の使い分け（動画の主題の一つ）で、抵抗測定は必ず回路を停電させてから行うこと。また安全回路の調査後は、ジャンパ線の外し忘れがないかの相互確認をルール化しておく。

「生産現場×バイブコーディング」という切り口の公的支援センター主催ワークショップが抽選になるほど集まる、という事実自体が使える情報。最初の一歩は、自分の地域（勤務地・客先所在地）の公設試・産業支援センターのセミナー一覧を検索し、AI・Claude Code・生成AI系の講座があるか確認すること（無料〜数千円で受けられることが多い）。岐阜近郊なら11月の回を直接狙うのも手。次の段階は、社内展開の口実に使うことで、「公的機関が現場向けにやるくらい一般化した」という説明は、上司や客先への稟議で効く。さらに、自分が普段 digest でやっているような GAS・Python の小道具づくりを「現場のバイブコーディング事例」として社内勉強会1時間で再演すれば、講師側に回る練習にもなる。コストは受講ならほぼゼロ。注意点は、ワークショップで作った試作をそのまま業務システム化しないこと。持ち帰ってからセキュリティ（認証・データの置き場所）を整えるまでが導入。

「AI に渡した環境の隔離設定が間違っていたら、AI は本気でそこを攻略してしまう」という実例で、自分の AI エージェント運用にそのまま跳ね返る話。最初の一歩は、自分が Claude Code や GAS 連携で AI に与えている権限の棚卸しで、「このセッションからアクセスできる先（社内共有・クラウド・客先データ）はどこまでか」を1枚に書き出すこと（30分）。次の段階は、試験・検証用の環境を本番と物理的に分けること。例えば AI にコード実行させる検証はコピーしたスプレッドシートやダミーデータで行い、本番の客先フォルダを見せない。「プロンプトで『触るな』と書いたから大丈夫」は今回の事案が否定した前提で、制御は環境側（権限・ネットワーク）で掛ける。コストはゼロ〜運用ルールの整備工数のみ。注意点は、これを「AI は危ないから禁止」に短絡させないこと。事故の3件はいずれも評価側の設定ミスが起点であり、教訓は禁止ではなく「AI に見せる範囲は設定で保証する」という運用設計にある。

「パッチは月次でまとめて」という感覚が通用しなくなるという話で、会社や個人で WordPress サイト・公開サーバを持っているならすぐ効く。最初の一歩は、自分の関係するサイト（会社ホームページ、個人ブログ、客先に納めた見える化サーバの Web UI）について「自動更新が有効か」を今日確認すること。WordPress なら管理画面で自動更新の状態が見える。次の段階は、FA 側への読み替えで、装置の見える化 PC やリモート監視ボックスに古い Web サーバが同居していないかの棚卸し。攻撃側の偵察が AI で安く速くなった以上、「工場の中だから見つからない」は成立しにくくなる。外部公開していないこと・VPN 必須であることを構成図で確認し、公開が必要なものは自動更新とバージョン通知を仕込む。コストは確認自体ゼロ。注意点は、本番装置系の自動更新は逆に事故になるので、IT系（Web・公開サーバ）とOT系（制御機器）で更新ポリシーを分けて考えること。

注目すべきは成果物より進め方で、「要件を言葉にできれば非エンジニアでも運用に耐えるツールが作れる」ことの実証例。岐阜のワークショップ（軸B）と同じ流れが芸能側からも来ている。最初の一歩は、自分の業務の「あったらいいが誰も作ってくれない小道具」（例: 立上げ時のチェックリストをスマホで消し込み、完了時刻を自動記録する画面）を1つ選び、宮本さんと同じく「欲しい画面・欲しい動き」を日本語で箇条書きにしてから Claude Code に渡すこと。うまくいかない時にエラー文をそのまま貼り返す、という進め方も再現ポイント。次の段階は、記事の構成（クラウドは軽い表示系、重い処理はローカル）を真似て、現場で使う道具は「表示はスマホ・処理は事務所PC」と分けること。コストは Claude の既存サブスクリプション内で追加ゼロから。注意点は、業務データを扱う段になったら置き場所（個人のクラウドに客先情報を上げない）だけは最初に線を引くこと。