2026年9月4日

最初の一歩は「自分の現場でOPC UAが本当に要るのか」を1枚で確かめること。既存案件で「PLCのデータをExcelやサーバへ吸い上げている経路」を洗い出し、ゲートウェイPCやCSV定期出力といった中継が挟まっているものに印を付ける。その中継こそがOPC UAサーバ内蔵で消せる工数なので、年間の保守時間を掛け算すれば置き換えの費用対効果が出る。次の段階は検証で、UaExpertなどの無償OPC UAクライアントを技術部のノートPCに入れ、手持ちの実機かデモ機に接続してノード階層とデータ型が期待どおりに見えるかを確認する。ここまでは無料で、半日あれば終わる。その先で新規案件に採用するときは、コントローラ本体に加えて上位側の受け皿（SCADAやヒストリアン）の費用が乗るので、数十万円〜の見積り枠を最初から取っておく。注意点は2つ。1つはOPC UAサーバを立てた瞬間に制御機器がネットワークの受け口になるため、VLAN分離とアカウント管理を電気設計の段階で仕様書に書き込むこと。もう1つは処理性能が上がっても既存ラダーの走査周期設計は自動では最適化されないので、置き換え時は必ずスキャンタイム実測を取り直すこと。

最初の一歩は、いま使っているGOT2000プロジェクトのうち「起動待ちと転送待ちで人が止まっている時間」を測ること。装置立ち上げ時にGOTへ画面データを転送する回数を1件の案件で数え、1回あたりの待ち時間を掛ければ、データ転送約7.5倍という数字が自分の何分に相当するかが出る。ここが1案件で1時間を超えるなら機種選定の理由として上申できる。次の段階は、GOT3000の内蔵WEBブラウザ機能を「客先でPCを開けない場面」の代替として設計に織り込むこと。従来はノートPCを持ち込んでインバータやサーボアンプの内蔵Webページを見ていた作業を、盤扉のGOTだけで完結できるかを1機能ずつ棚卸しする。カメラ映像の表示・録画も1台でできるので、これまで別途手配していた記録用PCの見積りを落とせる可能性がある。コスト面は、表示器そのものは上位機種になるほど単価が上がるため、GT37 Wideの静電容量タッチが要るのか、7型クラスで足りるのかを客先の操作頻度で切り分けたい。注意点は、GOT2000のプロジェクト資産をそのまま流用できる範囲を必ずメーカーの移行資料で確認すること。画面部品や解像度が変わると再レイアウトの工数が発生するので、見た目の高解像度化を売りにするなら作画工数を見積りに入れておく。

最初の一歩は、キットを買う前に「異音・異振動で困っている設備」を1台だけ名指しすること。客先で繰り返しコールがかかるモーターやコンベヤの減速機を選び、正常時の音と振動をスマホの録音とハンディ振動計で1週間ぶん取っておく。これは無料でできるうえ、後でAIの学習データの下地になる。次の段階でキットを使い、加速度センサとマイクを同じ場所に貼って正常データを取り、GUI上で学習させて推論結果を見る。ここで大事なのは「AIが当たるか」より「正常データのばらつきがどれくらいか」を掴むことで、季節や生産品種で音が変われば閾値運用は破綻すると分かる。コスト感は、キット購入費と現場での取り付け工数が主で、クラウド課金が要らないぶんランニングはほぼゼロ。従来なら数週間かかったマイコン選定と評価環境の準備が省ける点が実質的な値引きに相当する。注意点は3つ。防爆・防塵区画には後付けセンサを勝手に貼れないので事前に客先の設備管理へ確認すること、電源をPLC盤から取るなら制御電源に余裕があるか確認すること、そして「予知保全ができた」と言う前に、検知した異常が実際の故障につながった実績を最低数件そろえること。空振りのまま導入提案をすると次の話が来なくなる。

この手のオンプレAI基盤は個人や一課で買える価格帯ではないので、最初の一歩は「買う検討」ではなく「客先に持ち込めない情報の棚卸し」にする。手元の案件フォルダを開いて、客先図面、装置仕様書、トラブル報告書、ラダーのコメント表を、外部クラウドAIに貼ってよいもの／絶対に貼れないものの2列に仕分ける。この1枚があるだけで、社内で生成AI利用を止められている理由が「全部危ないから」から「この列だけ危ないから」に変わり、話が前に進む。次の段階は、貼ってよい列だけで先に成果を出すこと。型番や社名を伏せ字にした不具合報告を無料のChatGPTやGeminiに要約させ、月単位の再発傾向を出すところまでは今日できる。オンプレ導入を本気で検討する段になったら、ハードウェアから運用まで一貫対応という提供形態がむしろ足枷になる場合があるので、既存の社内サーバやActive Directoryとどう繋ぐのかを先に情報システム部門へ確認しておきたい。注意点は、閉域だから安全という思い込みで社内の権限設計を省かないこと。設計図面を全社員が引ける状態でAIに載せれば、漏えい経路が外から内に変わるだけになる。

問い合わせ返信の話に見えるが、この型は制御設計の「レビュー待ち」にそのまま効く。最初の一歩は、スプレッドシートを1枚作り、列を doc_id / 案件名 / 種別（図面・ラダー・取説）/ 作成日 / review_status / 確認者 / 期限 / hold_reason にして、いま自分がレビュー待ちで抱えている成果物を全部並べること。ここまでは30分、費用ゼロ。次の段階でGASを1本書き、READY_FOR_REVIEW と IN_REVIEW の合計が例えば5件を超えたら新規行を自動でHOLDにし、hold_reason に review_wip_limit_exceeded を入れる。記事のコードをほぼそのまま移植でき、GASは無料枠で動く。ここまで作ると「上司に確認を回したのに止まっている案件」が可視化され、自分の待ち時間の犯人が自分なのか相手なのかがはっきりする。理由コードは自分の業務に合わせて作り替えたい。evidence_missing は「現地写真がない」、reviewer_unavailable は「客先担当が出張中」に読み替えると、そのままFEの実務語彙になる。注意点は2つ。上限を厳しくしすぎると仕事が全部HOLDになって形骸化するので、まず実測値の1.2倍くらいから始めること。そして LockService と同じ発想で、複数人が同時に同じシートを触る運用なら排他制御を入れないと行がずれて上書き事故になる。

Mendix を自分で使っていなくても、この一件は「客先の現場アプリが何で作られているか把握しているか」を試す踏み絵になる。最初の一歩は、担当している工場で使われている点検記録アプリや帳票アプリの作りを1つずつ確認すること。ローコード基盤で作られていて社内SSOでログインしているなら、この分類の脆弱性が直撃する構造になっている。次の段階は、客先の情報システム部門へ「SSO連携しているローコードアプリのモジュール版数を確認してほしい」と、CVE番号とCVSS値を添えて1通メールを出すこと。これは無料で、自分の信用が上がる動き方でもある。実務上の注意は、SAML署名検証の不備は「ログイン画面が普通に出るのに乗っ取られる」タイプなので、現場の人が気づく症状がないこと。だから稼働監視やアラームでは検知できず、版数管理でしか防げない。あわせて、自分が客先に持ち込むツール類（リモート保守用のVPNクライアント、監視ツール）についても、ProductCERT のようなベンダーのアドバイザリ配信を購読しておきたい。購読自体は無料で、月に数分読むだけで「知らずに古い版を持ち込む」事故を減らせる。

客先で「生成AIは禁止です」と言われて話が終わる場面が増えているなら、この報告書は交渉材料になる。最初の一歩は、第6章の提言と第5章のテストシナリオ一覧だけを読み、自分の現場で言われている禁止理由（図面が学習される、ログが外に出る）に対応する項目を2〜3個抜き出してメモにすること。読むのは無料で、通勤中に終わる分量に絞れる。次の段階は、その抜き出しを持って客先の情報システム担当と話すこと。「AIを入れさせてください」ではなく「御社が心配しているのはこの項目ですよね、公的機関がここを検証しています」という順で出すと、担当者が上に説明する材料になる。技術的にも使い出がある。GPU非搭載の10年前のリユースサーバーとOSSだけで基盤を組んだという構成は、装置立ち上げ後に余った検証用PCや、更新で外した産業用PCの再利用と発想が同じで、投資判断を待たずに社内実験を始める言い訳になる。注意点は、この実証はあくまで「統制できる形にした」話であって、AIの回答精度を保証するものではないこと。閉域で動かしても誤った回答は出るので、ラダーや配線に直結する判断をAIの出力だけで下さない運用ルールは別途要る。あわせて、SBOM や監査ログといった章立ての言葉は客先のIT部門には通じても現場には通じないので、報告書をそのまま回覧するのは避けたい。

客先の不具合対応で一番きついのは「再現しない」ことなので、最初の一歩は今の装置で「トラブル時に何が残っているか」を書き出すことにしたい。アラーム履歴だけなのか、波形も残るのか、そのときのラダーのどのステップで止まったのか。この棚卸しをすると、ドライブレコーダ再生機能が埋めるのは「映像と操作履歴と波形とラダーを突き合わせる作業」だと具体的に説明できるようになる。次の段階は、新規案件で表示器を選ぶときに、この機能を「復旧時間の短縮」として見積書の別行に立てること。夜間に呼び出されて現地で2時間かけていた切り分けが、翌朝の再生で済むなら、客先にとっては停止時間の削減として計算できる。4言語の音声合成は、外国人作業者が入っている現場での作業指示に直接効くので、そこが課題の客先には優先して提案したい。注意点は、記録が残るということは「操作者が何をしたか」も残るということで、現場に無断で入れると人事的な警戒を生む。導入時は必ず現場のリーダーに、目的が原因究明であって監視ではないと説明しておく。もう1つ、Windows 搭載モデルを現場に置くならOS更新と持ち込みUSBの扱いを最初に決めること。ここを詰めずに入れると、帳票の自動化で得た時間を保守で吐き出すことになる。

これは道具を買う話ではなく、明日から使えるフォーマットの話なので導入コストはゼロ。最初の一歩は、記事の5つの質問をそのままA4の切り分けシートに落とし、現場に持っていくバインダーに10枚入れておくこと。呼ばれた瞬間に手が動くようにしておくと、焦って盤を開ける前に症状が確定する。次の段階は、このシートをそのまま報告の下書きに使うこと。「未確認」の欄を残したまま客先に一次報告を出すと、原因が確定していない段階でも「どこまで見たか」が伝わり、時間稼ぎではなく進捗として受け取られる。ここが効くのは、遠方の現場で「まだ分かりません」と電話するしかない場面である。さらに一歩進めるなら、入力X→内部状態M→出力Y の並びをGX Worksのモニタ画面のウォッチウィンドウに固定登録しておく。装置ごとに起動条件のデバイス、インタロックのM接点、出力Yを3グループで登録したファイルを作っておけば、現地で毎回デバイスを探し直す時間が消える。注意点は、この順序は「PLCが原因のとき」に速いのであって、電源やエアや機械的な噛み込みが原因のときは遠回りになること。盤に着く前に、現場の人へ「音はしたか」「エアは来ているか」を1問ずつ聞く癖を先に付けておきたい。あわせて、後輩に渡すときは「この順で見ろ」ではなく「未確認を未確認と書け」の方を強調すると、報告の質が先に上がる。

制御屋にとっての実利は「自分が書いたスクリプトの点検」にある。最初の一歩は、現場向けに書きためたPythonやGASの小物ツールを1つ選び、Mantisに読ませて指摘が出るか試すこと。CLIから使える構成なので、手元のPCとGitHubアカウントがあれば追加の課金なしに始められる。特に、客先データを扱うスクリプトでパスワードやAPIキーをコードに直書きしていないか、外部から受け取ったCSVをそのまま実行系に流していないかといった指摘が出れば、それだけで元が取れる。次の段階は、社内の共有ツールに広げる前に、Googleが自ら書いている注意書きのとおり隔離環境で回すこと。AIが出した修正コードをそのまま本番のツールに当てると、動いていたものが静かに壊れる。真陽性率が7％未満になる場合があるという数字は、裏返せば「指摘の大半は外れることがある」という意味なので、指摘の件数を成果として報告しないほうがいい。注意点として、客先から預かった図面データやレシピを含むリポジトリを解析対象にするなら、社外サービスにコードが渡る経路になっていないかを事前に確認すること。ここは軸Aのクローズド環境の話と地続きで、「便利だから使う」の前に「何がどこへ出ていくか」を1度図に描く癖を付けたい。

使う側として押さえるべきは、モデルの強さそのものより「ベンチマークの数字はハーネス次第で変わる」という一点である。最初の一歩は、自分の使い方でモデルを乗り換えるかどうかを、公開スコアではなく手元の課題で決めること。過去に手こずったラダーの仕様書要約や、英文マニュアルからのパラメータ抽出を3件用意して、いま使っているモデルと新モデルに同じ入力で投げ、当たり外れを自分で数える。ChatGPTの有料プランを既に契約しているなら追加費用はゼロで、半日で終わる。API利用を検討するなら、入力100万トークンあたり10ドル・出力50ドルという価格を自分の使用量に掛けて、月額の上限を先に決めておきたい。次に、セキュリティ面の受け止め方。攻撃側の道具としての性能が上がったということは、自分が客先に持ち込むリモート保守環境やVPN機器の設定不備が、これまでより短時間で見つかる世界になったという意味になる。だから対策は難しい話ではなく、初期パスワードの残置、不要ポートの開放、退職者アカウントの残存という基本項目を今月中に1周点検することに尽きる。注意点は、長いコンテキストで高い精度が出るという結果を「全部貼れば読んでくれる」と読み替えないこと。図面や仕様書を丸ごと投げる運用は、精度以前に情報の持ち出し規定に触れる。

これは今日5分で終わる作業なので、最初の一歩は自分のアカウントで記事のコマンドをそのまま実行して、公開リポジトリに Claude-Session 行が残っていないかを確認すること。gh コマンドが入っていなければ、GitHub の検索窓で自分のアカウントとキーワードを指定するだけでも当たりが付く。次の段階は、~/.claude/settings.json に attribution の sessionUrl を false で入れて、以後のコミットで付かないようにすること。設定ファイルはユーザー単位とプロジェクト単位の両方に置けるので、私物PCと会社PCの両方に入れておく。すでに公開済みのコミットについては、履歴を書き換えるとチームのブランチが壊れるため、慌てて rebase しないこと。まずは「そのリポジトリが本当に公開でよいのか」を見直し、業務スクリプトを個人アカウントの公開リポジトリに置いているなら private へ落とすほうが先である。費用はかからないが、時間は取られるので週末の作業に回すのが現実的。もう一段広げると、AIツールが自動で付ける情報はセッションURLだけとは限らない。コミットメッセージ、PR本文、ログファイルに何が自動で書き込まれるかを、導入時に1度目視で確認する運用を自分のルールにしておきたい。特に客先常駐で会社支給PCを使う場合、外部サービスへのリンクがコミットに残ること自体が規程違反になる職場もある。