2026年8月19日

最初の一歩は、いま担当している装置のうち「相手機器と2信号だけでやり取りしている箇所」を洗い出すこと。GX Works3でデバイスコメントを検索して、"開始" "完了" "要求" "許可" が付いたビットデバイスをCSVに書き出せば、30分で棚卸しできる。次の段階は、洗い出した1系統について状態遷移表を紙1枚で作ること。列を「状態番号／状態名／遷移条件／通信断からの復帰先」の4つにし、記事にある準備完了・到着・位置決め完了・受渡し許可・実行中・完了を素直に当てはめる。実装はビット信号を並べるのではなくD（データレジスタ）1点に状態番号を持たせ、相手機器と互いに読み合う形にすると、あとで状態を足しても配線と信号定義を増やさずに済む。コストはゼロで、必要なのは設計時間だけ。既存機の改造なら半日〜1日、新規設計なら仕様書段階で組み込めば実質追加工数はない。注意点は2つある。1つは、状態番号を持たせた瞬間に「通信断からの復帰先」を決めていないと、かえって状態が増えた分だけ迷子になる箇所が増えること。復帰先を決めていない状態は作らない、をルールにする。もう1つは、相手がロボットや画像処理装置の場合、相手側の状態定義を先に確認しないと番号の意味がズレること。取り合い仕様書に状態番号の対応表を必ず1枚入れておく。

明日試せる最初の一歩は「自分のGX Works3方言テンプレート」を1枚作ること。既存プロジェクトから自己保持・FOR文・構造体定義のSTコードを3例だけコピーし、テキストファイルに貼って「以下はGX Works3で実際にコンパイルが通ったSTの書き方です。この方言に厳密に従って書いてください」という前置きを付ける。それをChatGPTやGeminiの無料枠に毎回貼るだけで、記事が指摘する「方言ばらつき」の大半が消える。次の段階は、そのテンプレートをGX Works3のライブラリではなく、社内共有フォルダのプロンプト資産として育てること。生成→コンパイル→NGだった箇所をテンプレートに追記、というループを2週間回せば、四則演算・IF文・入出力代入はほぼ手直しなしになる。コストは無料枠で十分に始められ、業務で常用するなら月20ドル程度の個人プラン、部門展開ならAPI従量で月数千円規模から。注意点は記事が繰り返す「検収者が必須」で、精度95%は「20行に1行間違う」と読むべき数字である。生成したSTは必ずシミュレータで空運転してから実機に入れる運用を先に決めておく。もう1つ、FOR文と構造体は「機種別書き換え必須」に分類されているので、この2つは最初からAIに書かせず自分で書く、と割り切ったほうが速い。まずは自機1プロジェクトの入出力代入部分だけをAIに書かせて、空振り確認から入るのが安全。

ビルオートメーション規格に見えるが、狙い目は「工場の付帯設備」である。生産ラインのPLCではなく、工場棟の空調・照明・換気は多くの場合BACnetかDALIで動いていて、生産設備側のデータとは完全に分断されている。最初の一歩は、自社工場の空調・照明の制御盤を1面開けて、通信仕様のラベル（BACnet/IP・KNX・DALIのどれか）を写真に撮ること。既存システムを触らずにIntelligent Edge Kiloを1台足すだけで読める、という構成が成立するかがそこで判断できる。次の段階は、読めた環境データを生産データと同じタイムスタンプで並べること。「盤内温度が上がった日に特定のサーボアンプがアラームを出している」といった相関は、この2つが別システムに分かれている限り一生見えない。コストは公表されていないので、まず販売代理店に「マイコン1台＋クラウド1年」の見積を取るところから。規模から言って評価用1台なら数万円台、本格導入でも数十万円規模で収まる見込みだが、確認が要る。注意点は、既存のビル管理会社との契約範囲を先に確認すること。読み取りだけでも「BAシステムへの機器追加」と見なされる契約は珍しくない。読み取り専用・書き込みなしで始める、と明文化しておくと話が通りやすい。

この仕組みは「契約更新期日」より「客先への提出物の期日」に効く。制御設計だと、図面出図・部品表提出・現地調整の立会日程・検査成績書の提出、といった期日がメールとExcelに散っている。最初の一歩は、いま抱えている案件の期日をスプレッドシート1枚に「案件名／提出物／期日／ステータス／通知日」の5列で書き出すこと。10案件でも15分で埋まる。次に記事のコードをそのまま貼り、Webhookの送信先だけ自分のSlackなりTeamsなりに向ける。Slackを使っていない現場なら、送信先をSlack Incoming Webhookの代わりにGmailのMailApp.sendEmailに差し替えれば同じロジックがそのまま動く。次の段階は、これを個人ToDoから「班の共有シート」に上げること。3日前通知が班チャンネルに飛ぶようになると、「言った/言わない」の遅延が構造的に減る。コストはGoogleアカウントとSlack無料プランだけで完結し、ゼロ円。注意点は記事も強調するsetHours(0,0,0,0)の日付正規化で、これを飛ばすと「当日なのに通知されない」「前日に2回来る」が起きる。もう1つ、二重送信防止の通知日列を必ず実装すること。これが無いと、トリガーがリトライした日に同じ通知が班全員に複数回飛び、翌週には誰も見なくなる。まず自分1人・1案件で1週間回してから共有化するのが安全。

この事件でいちばん現場に刺さるのは「WAGOのパスワードが初期値のままだった」という一点である。最初の一歩は今日、担当している客先設備のうち通信機能を持つ機器（PLC、リモートI/O、産業用ルータ、HMI、画像処理装置）の一覧をExcelに書き出し、「初期パスワードのままか」列を1つ足すこと。自分が納めた盤なら30分で埋まる。埋まらない機器があること自体が指摘事項になる。次の段階は、変更できない機器を「変更不可」として明示的に記録し、その分をネットワーク側で囲うこと。記事が言う到達可能性と操作権限の分離は、非保持型権限委譲のような専用実装まで行かなくても、保守用VLANの分離、S7やMCプロトコルのポートを保守端末のIPだけに絞るL3スイッチのACL、という形で近似できる。コストは棚卸し自体はゼロ、L3スイッチやFWの設定変更で数万円〜十数万円の工事、本格的な権限委譲コントローラの追加なら1ラインあたり数十万円規模を見込む。注意点を2つ。1つは、記事自身が「初期侵入・デフォルト認証情報・ネットワーク偵察は防げない」と書いていること。つまりパスワード変更をサボったまま高度な仕組みを買っても意味がない。順番は必ずパスワードとネットワーク分離が先である。もう1つは、客先設備のパスワードを勝手に変えないこと。棚卸し表を持って行って「変更提案書」として出すのが、フィールドエンジニアの立場では正しい進め方になる。

「取得66%→活用51.4%→効果あり43.9%」は、自分の現場に当てはめると「データは取っているのに使っていない」という一言に集約される。最初の一歩は、客先設備で既に取れているのに誰も見ていないデータを1つ特定すること。サーボアンプの負荷率トレンド、インバータの積算運転時間、PLCの停止要因カウンタ、あたりが典型で、GX Works3のデバイスメモリを1回吸い上げれば当日中に確認できる。次の段階は、そのデータを「月1回、A4半ページの所見」に変える定型作業を作ること。白書が言う逓減構造は、取得と活用の間に「誰が見るか」を置いていないことで起きる。所見の宛先を保全課長など実在の1人に固定すると、この段の漏れが止まる。さらにAIOの考え方をここに接続すると、所見のフォーマットをCSVとMarkdownで残しておくだけで、来年GeminiやNotebookLMに丸ごと放り込んで年次傾向を出せる資産になる。逆にPDFやスクリーンショットで残すと、そこで行き止まりになる。コストはゼロ円から始められ、Workspaceを既に契約しているなら追加費用は不要。注意点は、白書の「中小企業の55%が策定予定なし」を客先への営業トークに使わないこと。数字は自分の提案を組み立てる材料であって、相手を説得する棍棒にすると警戒される。もう1つ、AIOのために基盤から作ろうとしないこと。効果が出やすいのはサプライチェーン領域と示唆されているが、自分の持ち場は設備データなので、まず1設備1指標から始めるのが現実的である。

四足歩行ロボットを買う話ではなく、「点検の代替」という切り口で読むのが実務的である。送電ケーブルトンネルで実運用に入っているということは、人が入りづらく・照度が低く・定形巡回である場所から順に置き換わっているという意味になる。自分の担当現場でそれに当たるのは、天井配管ラック、ピット、集塵ダクト周り、深夜無人時間帯のライン、あたり。最初の一歩は、客先で「人が入りにくいのに定期点検が必要な場所」を3つ挙げてもらい、点検頻度と1回あたりの人工をヒアリングして表にすること。ここが埋まらないと導入検討そのものが始まらない。次の段階は、いきなり四足歩行機を検討せず、固定カメラ＋LiDARの定点監視で代替できないかを先に潰すこと。記事が挙げるフィジカルAIの本質は「環境を感知して自動判断する」ところにあり、移動機構は必須ではない。コスト感は、固定カメラ＋エッジ推論の定点監視なら1点あたり数十万円規模、四足歩行機の導入は本体だけで数百万円規模を見込む必要がある。原価削減が進んでいるのは中国製部品の話で、日本での導入価格がそのまま下がるわけではない点に注意。もう1つの注意点は、「日本の脳＋中国の身体」を自社の提案に翻訳するとき、調達先の選定が輸出管理や客先の調達方針に触れる可能性があること。技術的に成立しても購買が通らない、は製造業では日常なので、企画段階で購買部門を巻き込んでおく。

開催まで9日、参加費無料、場所は秋葉原。最初の一歩は今日中に上記の詳細ページを開いて申込を済ませることで、締切が近いイベントは「行くか迷っている間に埋まる」のが常なので、まず枠を取ってから予定を調整する順序が正しい。次の段階は、当日を「情報収集」で終わらせない準備をすること。20以上のセミナーがあるということは、全部回ると何も残らない。事前に自分の課題を2つだけ紙に書いて持っていく——たとえば「既設ラインのカメラ画像で異常検知を回すとき、推論をエッジに置くかクラウドに置くかの判断基準」「PoCで終わった案件を実装まで持っていった顧客が、何を変えたのか」——この2問を実機デモとパートナー事例のブースで直接ぶつけると、カタログには載っていない失敗談が出てくる。テーマ自体が「PoCから実装へ」なので、この質問は主催側の想定内でもある。コストは交通費だけで、参加費は無料。半日の外出を確保できるかどうかが唯一のハードルになる。注意点は2つ。1つは、エッジAIプラットフォームの見積は本体価格だけを見ても意味がなく、推論モデルの再学習・保守の年間費用まで聞かないと後で効いてくること。ブースで必ず「運用開始2年目の費用」を聞く。もう1つは、当日撮った写真や貰った資料を翌日中に社内共有フォルダへ整理してしまうこと。1週間置くと二度と開かない。

SalesforceをFA現場に読み替えると、これは「設備の通信パスワードとAPIキーをどこに配ったか誰も把握していない」問題そのものである。最初の一歩は、自分が作ったGASやスクリプトで外部にアクセスしているものを全部挙げ、「サービス名／キー名／保管場所／最終更新日」の4列で1枚のシートにすること。自分の作ったものだけなら30分。この時点でたいてい2〜3箇所は忘れていたものが出てくる。次の段階は、記事の再発防止策のうち「読み取り専用の確認入口」を実装すること。GASなら、doGet相当ではなくメニューから呼べるcheckConnection()関数を1つ足し、レコードを作らず1件だけ読んで成否をログに出す。これがあると、キーを回した日に「どこが生きているか」を副作用ゼロで確認できる。3つ目に、キー名の命名統一。SF_TOKENとSF_SECURITY_TOKENが混在する話は、FA側でもPLC_IPとPLC_ADDRESSの混在という形で必ず起きるので、命名規則をシートの先頭行に書いておく。コストはゼロ円で、必要なのは棚卸しの時間だけ。注意点は、棚卸しシートに実際のパスワードやトークンの値を書かないこと。書くべきなのは「どこに配ってあるか」であって値そのものではない。値を1枚に集めると、今度はそのシートが最大のリスクになる。もう1つ、GitHub Secretsのように後から値を読めない保管場所があることを前提に、「更新したら必ず動作確認まで通す」を手順書に明記しておく。

記事の核心は「システムプロンプトはソフトな制約であり、技術的な保証を与えない」という一文で、これは自分のAI活用にそのまま効く。最初の一歩は、いま使っているAIツールのうち「勝手に書き込める先」を洗い出すこと。Claude CodeやCodexにファイル編集を許している作業フォルダ、GASでAIに書かせたスクリプトがアクセスするスプレッドシート、この2つが典型である。書き込み先を紙に3つ書けば、リスクの輪郭は掴める。次の段階は、記事の第2層(隔離)と第3層(決定論ゲート)を自分の規模に縮めて真似ること。隔離は、AIに触らせるフォルダを業務データの本体から物理的に分け、コピーだけを置くこと。決定論ゲートは、AIの出力をそのまま実行せず「実行前に人間かスクリプトが1回チェックする段」を必ず挟むこと。たとえばAIに書かせたGASは、本番シートではなくコピーシートで1回走らせてから移す。この2つだけで、記事が想定する被害パターンの大半は自分の環境では成立しなくなる。コストはゼロ円で、必要なのは運用ルールの明文化だけ。Cloud KMSやgVisorは自社でエージェントをサービスとして提供する場合の話であり、個人の業務効率化では過剰になる。注意点は、「AIに指示文で禁止したから大丈夫」という発想をやめること。記事が言う通り、指示は回避され得るし、モデルが更新されると振る舞いが変わる。禁止は仕組みで作る。もう1つ、社内でAI利用を広げるとき、この記事のフレーム(ソフトな制約とハードな保証の区別)は説明資料としてそのまま使える。

「自己申告ではなく別プロセスで検証」は、そのまま制御設計のAI活用に置き換わる。AIにSTコードやGASを書かせて「動作確認しました」と返ってきたとき、それはコードを書いた本人の自己採点でしかない。最初の一歩は、AIに作業を頼むときの依頼文の末尾に「完了条件」を先に書く癖をつけること。たとえば「GX Works3のシミュレータでコンパイルエラーがゼロであること」「テストデータ3件で期待値と一致すること」と、測れる形で書く。記事の言う「完了の条件を本当のゴールから逆算して先に決める」がこれに当たる。次の段階は、検証をAI以外の手に渡すこと。GASなら、AIが書いたコードをAIにレビューさせるのではなく、自分が用意した入力3件を通して出力を目視する。ラダーやSTなら、シミュレータという「AIが結果を書き換えられない別プロセス」を必ず挟む。3つ目に、diffを残すこと。AIに既存スクリプトを直させたら、変更前後を必ず別ファイルで残して差分を見る。ここを飛ばすと、いつの間にか要件そのものが書き換わっていても気づかない。コストはゼロ円で、依頼文のテンプレートを1つ作るだけ。注意点は、完了条件を厳しくしすぎるとAIがそこだけを最適化する、という同じ罠が別の形で出ること。記事が4番目に「指標を定期的に疑う」を置いているのはそのためで、月1回、自分が使っている完了条件が形骸化していないかを見直す時間を取るとよい。

「最新版どれですか」は制御設計の現場でもそのまま起きる。客先へ送る不具合調査報告、部品の比較検討表、試験結果のまとめ——これらをAIにHTMLで作らせてメール添付すると、数往復で誰も最新版が分からなくなる。最初の一歩は、個人無料枠の100MBで自分の報告物1件だけ試すこと。npx --yes @artifactshare/cli initを打つだけなので、Node.jsが入っていれば10分で終わる。テキスト主体のHTML報告書なら100MBは実質使い切れない容量なので、個人利用の範囲なら無料枠で完結する。次の段階は、コメント機能を「社内レビュー」に使うこと。上長や先輩にURLを1本送り、修正指示をコメントで受け、CLIでコメントを回収してAIに直させ、同じURLで次版に更新する。メールの往復が消える分、レビューの回転が上がる。部門で本格運用するなら100GBで月4,500円、ユーザー数無制限なので班単位で使っても定額なのは読みやすい。注意点は2つ。1つは客先データの取り扱いで、外部SaaSに客先の不具合情報や図面由来の数値を置くことになるため、社内の情報管理規程を先に確認すること。ソースコードが公開されておりセルフホストが自由なので、規程上まずければ社内サーバーで立てる選択肢もある。もう1つ、永続URLは便利な反面「消したつもりが残る」ので、案件終了時に削除する運用ルールを最初に決めておくこと。