2026年8月24日

これは自分で買える話ではないが、「PLCの下位制御 ＋ 上位の最適化ソフト」という組み合わせが標準になる前提で、自分の設計成果物の出し方を変えておくと効く。最初の一歩は、いま担当している装置1台について「上位に渡せるデータ」を棚卸しすること。GX Works3のデバイスコメント／ラベル一覧をCSVで書き出し、そこに「この値は装置内制御専用」「この値は上位へ出す意味がある（電力量・稼働率・段取り時間）」の1列を足すだけでよい。次の段階は、その"上位へ出す"列に命名規則を与えること。装置ごとにD100の意味が違う状態だと、上位ソフトを入れる段でそこが全部工数になる。ここはGeminiやChatGPTの無料枠にCSVを貼って「この命名は一貫しているか、例外を挙げて」と聞くだけでも当たりが取れる。コストはゼロ〜数千円/月の範囲で、必要なのは時間だけ。注意点は、この整理を客先仕様の変更として持ち込まないこと。あくまで自分の設計標準の内側で持ち、次に似た装置を作るときの雛形にする。上位ソフト導入の話が客先から降りてきたときに、タグ表がすでに揃っている状態を作っておくのが目的である。

「機械データを体系的に収集・処理・転送する」層が製品として売られ始めた、というのが実務上の読みどころ。自分でやるならまず、担当装置のデータ取得を"体系的"にする定義を1枚書くところから始める。具体的には、取りたい値（サイクルタイム／エラーコード／稼働状態／消費電力）ごとに、収集周期・保持期間・転送先の3つを表に埋める。周期を決めずにとりあえず全部1秒で取るのが一番よくある失敗で、後からストレージとネットワークで詰まる。次の段階は、いきなりベンダー製Edge機器を買わずに、手元のPLCとGX Works3のロギング機能、あるいはラズパイ＋Node-REDで同じ表を実装してみること。ここまでは既存資産＋数千円〜1万円台で試せる。それで「収集の型」が固まってから、TAS Edgeのような製品を見積もると、比較軸が価格ではなく「自分の表を満たすか」になる。注意点は、客先ネットワークに勝手にEdge機器をぶら下げないこと。データを外へ出す構成は、次のトピック（閉域網の話）と同じ審査を通す必要がある。

レトロフィット案件の手順書として、そのまま真似できる粒度になっている。押さえるべきは「全部置き換えない」判断で、強電のリレー回路は残し、壊れた温度制御だけをPLCに移している。客先の古い装置で「基板が製造中止で直せない」と言われたときに、この切り分けができるかどうかで見積もりが一桁変わる。最初の一歩は、手元の案件から1台選び、既存回路を「強電で残す部分」「PLCへ移す部分」の2色で塗り分けた図を描くこと。次の段階が、この記事と同じくセンサの論理（a接点かb接点か、断線時どちらに倒れるか）とサーミスタの抵抗値─温度の対応表を実測で取ること。ここを図面の記載だけで済ませると、火が入ってから温度が読めない事故になる。特にバーナー制御は失敗すると危険側なので、温度センサ断線時に必ず消火側へ倒れる設計にし、PLCのアナログ入力の断線検出とラダー側のインターロックを二重で入れる。コストはFX3Gクラス＋アナログ入力アダプタで数万円、端子台・ターミナルリレー込みでも十万円に届かない範囲。注意点は、乾燥機・炉のような燃焼系は法令・保安上の扱いが装置ごとに違うので、客先設備でやる場合は必ず設備所有者と安全側の責任範囲を文書で合意してから着手すること。

設計部の帳票自動化をGASで作り込んでいる人ほど刺さる話。最初の一歩は、自分のアカウントで動いているトリガーを全部書き出すこと。Apps Scriptの「トリガー」画面を開いて、スクリプト名・実行頻度・平均実行時間を3列のスプレッドシートに手で写すだけでよい。所要10分、コストゼロ。この時点で「もう使っていないのに5分おきに回っているスクリプト」が必ず1〜2本出てくるので、まずそれを止める。次の段階は、重い処理をトリガーから外すこと。具体的には、毎回全行を読み直している処理を「最終処理行を別シートに保存し、その続きだけ処理する」形に変える。GX Worksのタグ表チェックや点検記録の集計のように、1日1回まとめて回せばよい処理を1分おきに回している構成が一番危ない。注意点として、この枠は共有される性質なので、部署の共用アカウントでGASを運用している場合は自分だけ直しても解決しない。トリガー一覧のスプレッドシートを共有して「誰の何が何秒使っているか」を可視化するところまでやって初めて対策になる。落ちたことに気づく仕組みは別途必要で、成功したことを記録して記録が途切れたのを見る形が要る。

客先工場に持ち込む自分の機材が、まさにその「攻撃の入り口」に当たる立場なので他人事ではない。最初の一歩は、自分の保守用ノートPCとUSBメモリの棚卸しを今日やること。具体的には、（1）そのPCがどの客先のネットワークに繋がった履歴があるか、（2）USBメモリを何台の装置に挿したか、（3）最後にOSとウイルス対策の定義を更新したのはいつか、の3点をメモに書き出す。ここで「複数の客先を1本のUSBで回っている」なら、それが最優先の是正項目になる。次の段階は、客先ごとにUSBを分ける／持ち込みPCはプログラム転送専用にしてメールもブラウザも使わない、という運用ルールを自分の中で固定すること。数千円のUSBを客先の数だけ買って色分けし、ラベルを貼るだけで実行できるので、コストは実質ゼロに近い。次に効くのが、客先に入る前に「この装置のネットワークはどこに繋がっているか」を必ず聞く習慣で、閉域網だと聞かされても保守用の回線や無線APが後付けされている例は珍しくない。注意点は、これを客先のセキュリティ指摘として持ち出さないこと。まず自分の持ち込み機材を整えて、聞かれたときに「うちはこうしています」と説明できる状態を作るのが先で、その状態そのものが受注時の差別化になる。

開催が8月27日なので、まず今日のうちに申し込むかどうかを決めるのが最初の一歩。オンライン開催なので移動コストはゼロ、参加そのものより「聞く前に自分の仮説を書いておく」ことに価値がある。事前準備として、客先で一番よく止まる設備を1台挙げ、「何が壊れて止まるのか」「その前兆は何に出るのか（音・振動・電流・温度・サイクルタイム）」「その前兆を今どうやって知るのか」の3行を紙に書いてから聞く。セミナーの主張が「原因はAI精度やデータ量ではなく設備構造や動作原理の理解にある」なので、自分の3行が埋まらない設備は、センサを付ける以前の段階だと分かる。次の段階は、埋まった設備から1つだけ選んで、真因の仮説を検証する最小の計測をやること。振動ならスマホの加速度計アプリでも傾向は取れるし、電流ならクランプメーターとデータロガーで数千円〜数万円の範囲に収まる。注意点は、この話を「AIを入れれば予知保全ができる」という提案書に化けさせないこと。セミナー自体がその失敗を主題にしているので、聞いた後に客先へ持っていくなら、AI名ではなく「この設備のこの故障モードを、この計測で何週間前に見つける」という単位で出す。オンラインセミナーは録画が残らないことも多いので、当日メモを取りながら聞き、翌日中に上の3行へ反映するところまでを1セットにする。

前のトピックの「前兆をどう計測するか」に対する、配線工事なしの選択肢がこれ。バッテリー駆動＋ワイヤレスという構成が効くのは、客先の設備に手を入れる許可が取りにくい場面で、電源工事も信号線引き回しも要らずに数週間だけ様子を見られる点にある。最初の一歩は、購入前に「どの設備のどこに貼るか」を決めること。モーター軸受けのハウジング、減速機のケース、ポンプの吐出側といった、故障モードが振動に出る場所を1〜3点に絞る。3軸なのでアンバランス（回転方向）とミスアライメント（軸方向）を分けて見られるが、貼る向きを記録しておかないと後でどの軸が何か分からなくなるので、設置時に写真とスケッチを残す。次の段階は、正常時のデータを最低2週間取ってベースラインにすること。異常検知は「いつもと違う」を見る仕組みなので、いつもを持っていないと何も判定できない。ここを飛ばして異常時だけ測る失敗が一番多い。コスト感は、この種のワイヤレス振動センサは1点あたり数万円〜十数万円のレンジで、まずは1点だけ買って自社設備で試すのが現実的。注意点は、バッテリー駆動である以上、サンプリング周期を上げるほど電池が減ること。常時高分解能で測りたいなら有線を選ぶべきで、この製品は「配線せずに傾向を掴む」用途に当てるのが筋である。

客先で装置が止まっていて、後ろで生産管理が待っている状況ほど、この先回りが正当化されやすい。だからこそ、事前にルールを決めておかないと現場では必ず答えを言ってしまう。最初の一歩は、後輩と現場に入る前に「今日は何分まで待つか」を口頭で決めること。ライン停止中なら5分、停止していない調査なら30分、というように時間で線を引けば、その場の空気で判断しなくて済む。次の段階が、答えではなく手順を渡す形に変えること。「Y10が出ていないなら、条件のうちどれが不成立か、GX Worksのモニタで上から見ていって」のように、結論ではなく次に見る場所を渡す。ラダーモニタは、この渡し方が非常にやりやすい道具である。さらに進めるなら、対応後に「どこで詰まったか」を1行だけ書かせて溜めること。溜まったものは、そのまま自分のチームのトラブルシュート集になる。コストはゼロで、必要なのは待つ時間だけ。注意点は、待つことを目的化しないこと。ライン停止時間そのものが客先の損失なので、時間で区切る前提は崩さず、区切ったら迷わず答えを出して、振り返りを後でやる方に回す。そして、先に「聞いてほしいのか、一緒に手を動かしてほしいのか」を本人へ確認する一言を入れるだけで、同じ答えを言うにしても受け取られ方が変わる。

客先の図面や仕様書をGeminiに読ませたことがあるなら、まず自分の使い方が組織の設定でどう扱われているかを確認する側に回る必要がある。最初の一歩は、自社の管理者に「Geminiアプリとサイドパネル版Geminiは、いま有効か無効か」を聞くこと。この2つは別々に制御できるので、「Geminiは禁止と言われたがサイドパネルは動いている」といった食い違いが起きやすい。次の段階は、会話履歴がGoogle Vaultの保持・監査の対象になっているかを確認すること。対象なら、自分が打ち込んだ客先名や型番は後から検索・エクスポートされ得る前提になる。ここが分かると、使ってよい情報の線が具体的に引ける。実務的には「客先名・図番・個人名は伏せ字にして投げる」という自分ルールを作り、GX Worksのタグ表を投げるときも会社名を含むシート名を消してから貼る。コストはゼロで、必要なのは確認の手間だけ。注意点は、自分だけ守っても意味が薄いこと。同じ設計部で誰かが客先図面をそのまま貼っていれば同じリスクになるので、確認した内容を短いメモにして共有し、「禁止」ではなく「この形なら使ってよい」という書き方で回すと定着しやすい。

「AIに読ませる前提でメモを書く」というやり方の練習台として使える。効くのは、客先ごとのトラブル対応履歴のように、あとで横断して探したくなる情報。最初の一歩は、新しいツールを入れる前に、いま持っているメモを1件だけMarkdownで書き直してみること。日付・客先（伏せ字可）・装置・現象・確認した箇所・原因・対策、の見出しを固定するだけでよい。この見出しが揃っていると、AIに「今月の原因の内訳を表にして」と頼んだときに素直に返ってくる。次の段階で、同じ形のファイルが10件ほど溜まったところでHubble.mdのようなAI前提のツールに入れ、ダッシュボードを作らせてみる。無料・オープンソースなので金銭コストはゼロ、かかるのは導入と学習の時間だけ。注意点が2つある。ひとつは、AIにファイルを直接編集させる仕組みである以上、意図しない上書きが起こり得ること。業務のメモを預けるなら、必ずGitかクラウドドライブでバージョン履歴が残る場所に置く。もうひとつは、客先の固有名詞や図番をそのまま書かないこと。見出しの形さえ揃っていれば伏せ字でも集計はできるので、最初から伏せ字で書く癖を付けておくほうが後で困らない。

「AIが無理だと言ったら、それは本当に無理なのか」を疑う姿勢が、そのまま自分のデバッグ作業に効く。最初の一歩は、次にAIに設計や不具合を相談したとき、「できません」「原因の特定は困難です」と返ってきたところで止めないこと。代わりに「では次に確認すべき値を3つ挙げて」「切り分けのために追加で仕込むログを提案して」と、判断ではなく手順を要求する形に言い換える。ここが今回の話の要点で、AIが強かったのは結論を出す部分ではなく、デバッグコードを追加して解析を続ける力仕事の部分だった。制御設計に落とすなら、ラダーの不具合調査で「この出力が出ない原因を教えて」ではなく、「この条件式のうち、監視すべきデバイスを優先順に並べて」と聞く。無料枠のChatGPT/Geminiでも十分試せるのでコストはゼロ、明日の調査からそのまま使える。次の段階は、AIに書かせた内容を自分の記録として残す運用にすること。今回の話でもコミットメッセージはAIに書かせている。作業報告書や不具合対応記録の下書きをAIに書かせ、事実だけ自分で直す形にすると時間が減る。注意点は、粘り続けるのは人間側の判断だということ。AIが諦めても押し切れたのは、押した本人が原因の当たりを持っていたからで、当たりのないまま押し続けると誤った方向の調査に時間を溶かす。30分で切り上げて実機を見る、という自分の区切りは持っておく。