2026年10月13日

明日の一歩は、客先にRockwell機がある案件の「オンライン修正の社内手順書」を1枚作ること。記事の操作列（Start Pending Rung Edits → Accept → Test Edits → 動作確認 → Assemble）をそのまま章立てにし、各段で「この時点で出力はどう動くか」を自分の言葉で埋める。埋まらない行が自分の理解の穴なので、そこだけ検証機で空振りさせる。次の段階は、手順書に「事前に現行プログラムを Upload してバックアップを取る」「Verify でエラーが無いことを確認する」をチェック欄として先頭に置き、現場で飛ばせないようにすること。MELSEC 側の運転中変更と並べて「どちらも全体ダウンロードは設備停止を伴う／変更の反映タイミングが操作ごとに違う」という共通の注意点を1行で書いておくと、GX Works3 と Studio 5000 を行き来する客先対応で頭の切り替えが速くなる。コストは既存ライセンスと検証機だけで追加費用ゼロ、所要は半日程度。注意点は2つ。ひとつは Test Edits に入った瞬間から実機のロジックが変わるので、出力先（シリンダ・コンベア）を切り離した状態で練習すること。もうひとつは差分比較を当てにしないこと。記事でも Compare Tool は差分表示まで到達していないので、変更前後の ACD を日付入りで必ず手元に残し、「何を変えたか」はテキストメモで二重に持つ運用が現実的。

この話は「AIにラダーを書かせる」より手前の、実務でいちばん効く使い方に落とせる。最初の一歩は、自分が過去に書いたインターロック1本を選び、ラダー図を見ながらニーモニック相当の命令列（LD／AND／ANI／OR／OUT）を手でテキストに書き起こすこと。10行程度で十分。次に、その命令列と現在値（X・Mの ON/OFF）を貼り付けて「この出力がONしない直接原因の接点を1つ挙げて、根拠も書いて」とChatGPTやGeminiに投げる。狙いは設計の自動化ではなく、夜間の電話対応で「どの接点を見るか」を言語化する訓練と、説明文の雛形づくり。次の段階は、I/Oコメント（例: X25＝搬送コンベア安全カバー開）を命令列に併記してから渡すこと。デバイス番号だけの回答が設備信号名の回答に変わり、現場の保全担当へそのまま読み上げられる文章になる。コストは無料枠で今日試せる。注意点は3つ。実機のプログラムやI/Oコメントは顧客資産なので、デバイス名を伏せたサンプルで練習すること。AIの説明は仮説であって裏取りは必ずオンラインモニタで行うこと。そして記事の論点はあくまで「IL的表現の可能性」の考察なので、ツール側がIL入出力に対応しているかは自分のメーカー環境で別途確認が必要なこと。

自分でGASを書いているなら、刺さるのは①の「画面に出していない関数は呼べる」。最初の一歩は、手持ちのGASを開いて `doGet`／`doPost` を持つWebアプリ型のスクリプトだけを数える（たいてい1〜3本）。その中で画面から呼ぶ必要のない関数名の末尾に `_` を付け、1本だけ動作確認する。ここまで30分、費用ゼロ。次の段階は、記事の②に当たる「外から来た文字をシートに書いている箇所」の棚卸し。点検記録フォームや不具合報告フォームの回答をシートへ流している処理が該当するので、書き込み先の列を書式なしテキストにするか、先頭に `'` を付ける処理を1行足す。客先名や製番が `=` や `-` で始まる運用があると実害が出やすい。その次に、記事と同じ診断を回すかを判断する。プラグインの実行には有料プランとPython 3.9以上、差分スキャンにはGitが必要なので、まず自分のプランと環境で条件を満たすかの確認が先。満たさない場合でも、①②③の3種類をチェックリスト化して自分のGASを目で追うだけで大半は拾える。注意点は、パッチをそのまま当てないこと。GASは自動テストが置きにくく、記事でも確認手段はレビューだとされている。帳票を生成するスクリプトなら、当てる前に当月分のシートをコピーして退避し、出力PDFを1枚見比べてから本番へ戻す手順を自分の運用に組み込んでおく。

これはそのまま自分の担当設備の「診断ビットの受け方」の設計に落ちる。最初の一歩は、客先設備で既に来ている診断系の信号（ポジショナの異常・要注意、インバータのアラーム予兆、センサのヘルスビット）を1枚の表に並べ、各ビットが現在どこへ入っているかを「停止」「警報だけ」「どこにも入っていない」の3列で分けること。たいてい3列目が一番多い。次の段階は、重要度の高い機器を数台だけ選ぶこと。アズビルの事例が加熱炉の燃料ガス・空気・排ガス用のうち11台に絞ったのと同じ発想で、全数ではなく「止まると全停止に直結する弁・モータ」から始める。そのうえでPLC側に、診断レベルの継続時間を計るタイマと、工程値（温度・流量・開度偏差）が追従しているかの判定を1ラングずつ足し、「診断注意が続いていて工程値も崩れている」ときだけ計画停止へ進む条件を作る。コストはPLC改造だけなら数時間の工数、クラウド診断サービスまで入れるなら年額のサービス費と計装工事が別途必要なので、まずは手元のビットの整理が費用ゼロで効く。注意点は、診断ビットをいきなり停止条件へ入れないこと。止まりすぎる設備は現場でバイパスされ、せっかくの予兆が死ぬ。もうひとつ、補修後の再開条件も同時に決めておくこと。値が戻っただけで運転許可を出さず、原因確認・試運転・基準値の取り直しを経るようにしておくと、同じ弁で再発したときの切り分けが速い。

客先の夜間呼び出しで一番効くのは「電源を入れ直す前にやること」をカード1枚にしておくこと。最初の一歩は、記事の記録項目（型式／ERR・PWR・RUNのランプ状態／増設ユニットのLED／発生日時／直前の動作／最近の変更）を名刺サイズのメモに落とし、工具箱と携帯の写真フォルダに入れる。現場では電話口で「ランプを写真で送ってください」と言えるようになるだけで切り分けが1往復短くなる。次の段階は、自分が担当する機種ごとに診断メニューの階層を控えておくこと。FX5なら［診断］→［システムモニタ］と［診断］→［ユニット診断（CPU診断）］→［イベント履歴］、MELSEC-Q系でGX Works2を使う現場なら診断機能の場所が違うので別行に分ける。原因調査だけなら書き込みが不要という点は、客先で「プロジェクトを書き込んでいいか」の確認待ちで止まる時間をそのまま削れる。さらに一段進めるなら、イベント履歴をCSVで吐ける機種・バージョンのときは取得して、設備ごとのフォルダに日付名で貯めること。同じ設備で3回集まると、停止が特定の品種切替や特定時刻に偏っていないかが目で見える。コストはゼロ、必要なのは記録の習慣だけ。注意点は2つ。ERRランプが消えたことと原因が解決したことは別で、SM50での解除は要因を取り除いた後に限ること。そして自己診断で出力がOFFになっていても安全とは限らないので、復旧操作の前にシリンダ・電磁弁・モータの状態と安全回路のリセット条件を目視で確認する手順を、カードの最後に必ず入れておくこと。

会期は10月13〜16日なので、行くか行かないかを今日決められる。行く場合の最初の一歩は、目的を2つに絞ること。ひとつは三菱電機グループのホール8・8H412でねじ締めのデモを見て、「部品の状態を見極めて力加減と角度を調整する」とは具体的にどのセンサ値をどの周期で見ているのかを質問すること。もうひとつは「Serendie×OTセキュリティ」のブースで、客先工場の制御ネットワークに外部接続を足すときの分離方針を聞くこと。どちらも自分の見積や客先提案に直結する質問で、カタログを集めるより価値が高い。行けない場合は、受賞3件を「自分の仕事への距離」で読み替えるだけでも十分使える。TUSS の音源分離は、現場の雑音の中から異常音を切り出す方向の技術なので、今の案件で「ベテランが音で気づいている異常」を1つ書き出し、どのタイミングで音を録れば判定材料になるかを考えておく。費用は入場登録のほかは交通費のみ、質問内容を事前にメモしておけば滞在半日で足りる。注意点は、TUSS は2027年度中の実装・適用を目指す段階とされていること。客先へ「もう使える技術」として紹介しないこと。展示で見た内容はそのまま提案書に転記せず、自社で再現できる範囲（既存センサで取れるデータ）に翻訳してから持ち込むのが安全。

AIツールを複数試している人ほど、自分のPCで何が何を読めるのか分からなくなっている。最初の一歩は、業務PCで `npx geiger-scan` を1回走らせて、「HOLDS-SECRETS」と「BROAD-FILESYSTEM」のラベルが付いた項目だけを拾うこと。Node.js 18以上が入っていれば追加インストールもアカウント作成も不要で、10分で終わる。次の段階は、拾った項目を「今も使っている／もう使っていない」に二分し、使っていない側のMCPサーバーや拡張機能を設定から外すこと。客先の図面やPLCプロジェクトを置いているフォルダが広いファイルアクセス権の射程に入っていたら、作業フォルダを分けるだけでも効く。さらに `--json` で baseline.json を残しておき、月初にもう一度 `--diff` で比較すれば、自分が気づかないうちに増えた拡張機能に気づける。費用はゼロ。注意点は3つ。社用PCでツールを走らせる前に、社内規程で未承認ツールの実行が禁じられていないか確認すること。レポートはキー名や設定ファイルのパスという社内情報の一覧になるので、HTMLレポートを共有フォルダやチャットに貼らないこと。そして記事でも触れられている指摘のとおり、棚卸しで数が分かること自体が安全を意味しないので、重要なデータはバックアップを別に取ってから整理に入ること。

客先との仕様打合せやトラブル報告のオンライン会議が多いなら、効くのは「議事メモから次の作業へ落とすまで」の時間。最初の一歩は、自分のアカウントが対象エディション（Business Standard／Plus、Enterprise Standard／Plus、教育向けは Google AI Pro for Education）かを管理者に1行で確認すること。対象外なら今回は見送りで、代わりに手元の議事メモから宿題だけを抜き出す定型の指示文を作っておく。対象なら、次の一歩は社内の打合せ1本で「Take notes for me」をONにして会議後画面の「Routines for this meeting」を開き、アクションアイテムを Google Tasks に出す方だけを試すこと。メール下書きより先にTasks側を試すのは、誤りがあっても外部へ出ないから。使えると判断したら、客先会議では「議事録はこちらで作成して後送します」と口頭で合意してから使うルールを自分に課す。コストは既に該当プランを使っているなら追加費用なし、試すのは1会議15分。注意点は3つ。顧客の装置仕様や不具合内容が議事メモとして残るので、社外秘情報の扱いが社内規程で許されるか先に確認すること。機能はロールアウト中で自分の画面にまだ出ない可能性があること。そして下書きはあくまで下書きなので、客先へ出すフォローアップメールは納期・費用・責任分担の3点を必ず自分の目で直してから送ること。