2026年9月7日

この話はGX Works3を使う自分の環境にそのまま重なる。プロジェクトがバイナリで、gitにもテキスト差分にも載らないという制約は、オムロンでも三菱でも同じだから、CLI型のAIコーディングを無理に持ち込む必要がない。最初の一歩は、今のPCで使っているClaude（またはChatGPT/Gemini）のデスクトップ版・ブラウザ版のチャットに、GX Works3から抜いた1つのファンクションブロックのSTを貼って、「この処理をコメント付きで読み解いて」と頼むところから。無料枠でその日のうちに試せる。次の段階は、コピー＆ペーストの往復を前提に手順を固めること。仕様をテキストで書く → AIにSTを書かせる → 机上でトレースさせる → GX Works3に貼ってビルド → 出たエラーメッセージをそのままチャットに貼り返す、という往復を自分のルールとして決めておくと、毎回考えずに回せる。コストは基本ゼロ（サブスク内）で、増えるのは自分の手作業の時間だけ。注意点は2つ。1つは、客先の装置仕様やタグ名がそのまま外部サービスへ渡る点で、貼る前に固有名詞をダミーへ置換する自分ルールを先に決めること。もう1つは、バイナリ保存＝差分が取れないので、AIに書かせたコードを入れる前のプロジェクトを必ずファイル名にリビジョン番号を付けて別保存しておくこと。ここを省くと、動かなくなったときに戻れない。

「AIが他言語の常識を持ち込む」という診断は、そのままGX Works3のST/ラダーにも効く。三菱のSTにも独自の命令セットと方言があり、AIはIEC 61131-3の一般論やSiemensのSCLの記法を平気で混ぜてくる。最初の一歩は、md（テキスト）ファイルを1枚作り、冒頭に「使ってよい命令は手元のGX Works3リファレンスに載っているものだけ。載っていない構文は使わない」と1行だけ書いて、以降に自分が実際に踏んだ間違いを「現象／原因／正しい書き方」の3列で足していくこと。今週のバグ1件から始めればよく、10行あれば効き始める。次の段階は、そのファイルをチャットの最初に毎回貼るのをやめ、Claude Desktopのスキルやプロジェクト、ChatGPTのカスタム指示など「常駐させる」置き場に移すこと。ここまで来ると、貼り忘れによる品質のブレが消える。さらに進めるなら、同じ要領でGOT（表示器）のスクリプト用、キーエンスKV用と分けて持ち、装置メーカーごとに切り替える。コストはゼロ（テキストファイルだけ）、必要なのは書き足す習慣のほうだ。注意点は、この手のルール集は「書いていない地雷は普通に踏む」ので、生成物の最終確認を人間が外せないこと。特に自己保持やインターロックの条件は、AIが文法的に正しいコードを出しても安全側とは限らないので、実機転送前に必ず机上トレースを挟むこと。

注目すべきはモデルの新しさより「MCP経由でCADを操作させ、曖昧な指示から形まで持っていった」という工程の作り方のほうだ。制御設計側で同じ形に落とすなら、最初の一歩は設計そのものではなく設計の前段、つまり仕様の詰めをAIに任せること。客先からの曖昧な引き合いメール（「搬送を自動化したい」程度）をそのまま貼り、「制御仕様を確定させるために客先へ聞くべき質問を、動作条件・安全・異常時の復帰・既存設備との取り合いの4分類で出して」と頼む。無料枠で今日試せて、ヒアリング漏れの保険になる。次の段階は、出てきた仕様案からI/Oリストとタイムチャートの下書きまでを作らせ、そこからSTの骨組みを起こすこと。ここまでを1本の流れにすると、この投稿でいう「構想→詳細」の往復が制御側でも回り始める。コストは、チャットの範囲なら月数千円のサブスク内で収まる。CADや設計ツールをMCPで直接操作させる段階へ進むと、ツールの対応可否と社内のセキュリティ承認が要るので、まずはコピー＆ペーストで工程の価値を確かめてからにしたい。注意点は、この投稿自体が個人のベンチマークであり、出てきた案が良く見えるほど検証を飛ばしたくなること。AIが出した機構案・制御案は必ず「その条件が成立しないケース」を自分で1つ挙げてから採用する、というブレーキを自分に掛けておくとよい。

自分の案件がプラント規模でなくても、「データベースを分割して規模に応じてスケールさせる」という考え方は、装置単体の制御設計にも持ち込める。最初の一歩は、いま担当している装置のデータ（生産実績・アラーム履歴・トレンド）が、1つのファイルやテーブルに全部押し込まれていないかを見直すこと。GOTのロギングやSDカードのCSVが1本にまとまっていると、増設のたびに書き換えが要る。次の段階は、系統やラインの単位で保存先を分けておき、後から系統を1つ足しても既存の設定に触らずに済む構造にすること。ここは実装コストがほぼゼロで、後々の改造工数に効く。監視制御システムそのものの導入検討に入るなら、コスト感は装置1台の話ではなく、エンジニアリング込みで数百万円以上のプロジェクト規模になる前提で客先と話を始めること。注意点は、セキュリティ向上をうたう製品でも、現場でUSBメモリやリモート保守回線の運用が緩ければ意味が薄れること。製品選定と同時に、誰がどの端末から触れるかの運用ルールを客先と決めておきたい。

帳票番号の重複は、制御屋にとっては馴染みのある「排他制御を忘れた共有リソース」の話そのもので、PLCで複数タスクから同じデバイスを触って値が飛ぶのと同じ構造だ。自分の業務で効くのは、社内でGASを使って通し番号を振っている場面すべて。試験成績書番号、装置の製番、現地作業報告書の番号あたりが該当する。最初の一歩は、自分（または同僚）が書いたGASで「読み取り → +1 → 書き戻し」をしている箇所を検索し、その前後を `LockService.getScriptLock()` で挟むこと。数行の修正で、今日中に終わる。次の段階は、番号を振る処理を1つの関数に集約して、複数のスクリプトから同じロジックを呼ぶ形にすること。今は帳票ごとにコピペされていることが多く、片方だけ直して片方が残る、という事故になりやすい。コストは無料（GASの標準機能のみ）。注意点は、ロックを取る範囲を広げすぎると、複数人が同時に帳票を出す繁忙期にタイムアウトが増えること。ロックは採番の前後だけに絞り、PDF生成やメール送信まで含めないこと。あわせて、番号が飛んだ・重複した履歴を残すログシートを1枚用意しておくと、後から監査を求められたときに説明できる。

この投稿の価値は、更新案件の見積もり段階で「何を調査工数として積むか」の一覧になっている点にある。最初の一歩は、この5項目（I/Oの実動作／タイムチャート／異常発生時の挙動／電源投入時の初期状態／途中停止からの復帰）をそのままチェックリスト化して、次のPLC更新の引き合いで客先に提示すること。テキストファイル1枚で今日作れて、調査工数を「AIの言うことだから」ではなく現場の実感として説明できる。次の段階は、この調査結果を残す形式を決めること。旧機での実測値（タイマ設定値、通信周期、電源投入直後の各デバイス値）をスプレッドシートに列で持ち、新機で同じ列を埋めて左右で見比べる。ここが後の「新旧比較」の証拠になる。AIを噛ませるなら、旧ラダーのコメントとデバイスコメントを貼って「使われていない可能性がある信号を列挙して」と聞くと、死んだ信号の当たりを付けるのに使える。ただし判断は必ず実機のモニタで確認すること。コストは追加ツールなしでゼロ、増えるのは現地調査の日数（装置1台なら半日〜1日）で、これを見積もりに入れられるかが分かれ目。注意点は、客先が「プログラムを移すだけでしょう」と考えている場合、この調査が値引き対象になりやすいこと。上の5項目を先に見せて、省いた場合に起きること（立ち上げ時の予期しない動作、復帰不良）まで文書で残しておくと、後の責任分界が楽になる。

注目したいのは「作業手順と記録業務を一体化した」という設計思想のほうで、これは製品を買わなくても真似できる。現場の帳票は、手順書（紙またはPDF）と記録用紙が別物になっていることが多く、作業者は手順を見ながら別の紙に書く。その分離がヒューマンエラーと教育コストの源になる。最初の一歩は、自分が客先で回している点検・立ち上げ作業を1つ選び、Googleフォームで「手順1文＋その場で入力する測定値の欄」をセットにしたフォームを作ること。手順を読む場所と書く場所が同じになるだけで、飛ばしが減る。無料で今日作れる。次の段階は、フォームの回答をスプレッドシートに溜め、GASで作業日報のPDFを自動生成して客先へ送る形にすること。ここまでで、報告書作成の時間がほぼゼロになる。さらに進めるなら、異常値が入ったときだけ自分にメールが飛ぶ条件を足す。コストはGoogle Workspaceの範囲内で追加費用なし、パッケージ製品を入れる場合は年額のサブスクリプション規模になる前提で客先と話す。注意点は、記録が紙からデジタルへ移ると「誰がいつ入力したか」が残ること。これは品質上の利点だが、現場作業者からは監視と受け取られやすいので、導入時に「入力の手間を減らすため」と目的を明示しておくこと。

「作業の動画から動きを学ぶ」という方向性は、まだ仮想環境での確認段階なので、今すぐ装置に載る話ではない。だが自分の業務で先回りできることが1つある。動画を撮って残しておくことだ。最初の一歩は、客先での立ち上げや不具合対応のとき、スマホで作業と装置の動きを短く撮る習慣をつけること（客先の撮影許可の確認は必須）。コストはゼロ。次の段階は、その動画を自分の資産として整理すること。装置名・工程・トラブル内容でフォルダを分け、1本ずつ1行のメモを付けておく。これは将来この種のAIが実用化されたときの学習素材になるだけでなく、現時点でも「前に同じ症状を見た」を思い出すための最短の手段になる。今日効く使い方としては、撮った動画からキーフレームを切り出してAIに見せ、「この動作で不自然な点はあるか」と聞く、あるいは動画を見ながら口頭で説明した内容を文字起こしさせて作業報告書の下書きにする、といったところ。無料〜サブスク内で回せる。注意点は、客先の設備が写る動画は機密性が高く、外部AIサービスへのアップロードが契約上禁止されている場合があること。撮影許可とAI利用の可否は別の話なので、両方を先に確認しておくこと。

三菱電機のFA製品を日常的に使う立場なら、この出展は「今後のGX Works3やロボット周辺がどこへ向かうか」を無料で確認できる機会になる。最初の一歩は、10月13〜16日の幕張メッセ、ホール8のブース8H412を今のうちに手帳へ入れ、CEATECの来場登録（例年オンラインで事前登録制）を済ませておくこと。交通費以外のコストはかからない。次の段階は、行く前に自分の質問を3つ用意すること。ここが決定的で、展示は眺めるだけだと何も残らない。自律ねじ締めのデモなら「力加減の調整はどのセンサの値を使っているのか」「ティーチングの手間は従来のロボットと比べてどう変わるのか」「既設のロボットに後付けできるのか、専用機なのか」あたりが実務に直結する。ヒューマノイドの棚入れのほうは自分の案件から遠いので、時間を掛けすぎないほうがよい。「現場特有の事象への対応ノウハウを学習する技術」の学習データをどう集めるかだけ聞いておけば十分。注意点は、展示会のデモは条件を整えた環境での動作であること。ワークのばらつきや照明条件を変えたときにどうなるかは展示では見えないので、客先へ持ち帰る前に必ず自社での検証条件を確認すること。行けない場合でも、会期後に公開される動画や記事で同じ3つの質問を追いかけられる。

見習うべきは自動化の中身より「先に測ってから自動化した」という順序のほうだ。フィールドエンジニアリングの周辺業務は、出張報告、経費精算、日報、作業写真の整理と、どれも1件あたり数十分の手作業が積み上がっている。最初の一歩は、今週の出張1件について、報告書作成に何分かかったかをスマホのタイマーで測って書き留めるだけ。3件も測れば平均が出て、改善の効果を後から数字で言えるようになる。コストゼロ、所要は測る時間だけ。次の段階は、いちばん時間を食っている工程を1つだけ自動化すること。多くの場合は「同じ内容を複数の書式へ転記している」ところなので、Googleフォームで1回入力 → スプレッドシートに蓄積 → GASでDocsのテンプレートへ差し込んでPDF化、という流れに置き換える。半日で組めて、Google Workspaceの範囲内なら追加費用はない。さらに進めるなら、交通費や日当の金額を出張先マスタから自動で引いてくる。注意点は、経費精算まわりは会社の規程と経理の承認フローに縛られること。自分の手元で作った帳票が正式書式として通るかを先に経理へ確認しないと、二重入力が増えるだけになる。まずは「自分が下書きを作る時間を減らす」範囲に限定して始めるのが安全。

自分の使い方に引き付けると、これは「知らないドメインからのリンクを踏む機会が増えている」という警告として効く。AIに調べ物をさせると、出典として見慣れないドメインのURLが返ってくることが日常的にあり、そこを無防備に踏むのが一番危ない導線になる。最初の一歩は、AIが出したURLを開く前にドメイン部分だけを見る癖をつけること。メーカーの技術資料を探しているのに、社名と無関係な新しめのgTLD（`.top` `.xyz` `.shop` など）が返ってきたら、そのリンクは開かずに検索し直す。コストゼロ、今日から。次の段階は、業務PCで「メーカー公式ドメインのブックマーク集」を作ってしまうこと。三菱電機、オムロン、キーエンス、SMC、その他よく使うメーカーのマニュアルページを登録しておけば、そもそも検索結果を経由しなくなる。30分の作業で、フィッシングの入口を1つ潰せる。さらに進めるなら、客先へ持ち込むノートPCではブラウザの警告機能を無効化しないこと、そしてダウンロードした実行ファイルは必ず自社に持ち帰ってから開くこと。注意点は、この統計は新規登録ドメイン全体の話で、個別のサイトの安全性を判定するものではないこと。「新しいドメイン＝詐欺」と決めつけると、正当な新興ツールやコミュニティサイトまで排除してしまうので、あくまで「初見のドメインは一段慎重に」という運用に留めるのが現実的。

業務でNotebook系のAIツールに社内資料を放り込む使い方は便利だが、この発表で気に留めたいのは監査ログの追加そのものより「ユーザーデータがグローバルに保存され、リージョン指定に対応していない」という注記のほうだ。客先の装置仕様書や図面を扱う立場では、ここが社内規程や客先との秘密保持契約に触れる可能性がある。最初の一歩は、自分がNotebook系ツールに何を入れているかを棚卸しすること。マニュアル類（公開資料）ならほぼ問題ないが、客先名入りの仕様書・不具合報告・見積は別扱いにする、という線を自分の中に引く。所要30分、コストゼロ。次の段階は、社内で使っているなら情シスまたは管理者に「Gemini Notebookの監査ログが見られるようになったので、うちの利用状況を一度出してほしい」と依頼すること。誰が何を入れているかが見えると、ルールを作る根拠になる。管理者側なら、BigQueryへのエクスポートは既定で無効なので、必要なら有効化の判断がいる。さらに進めるなら、公開資料だけを入れる「共有ノートブック」と、個人の下書き用を分けて運用する。注意点は、ログが取れることと安全であることは別だという点。監査ログは事後に追跡できるようにするだけで、入れてしまったデータが戻るわけではない。入口のルール（何を入れないか）を先に決めるほうが効く。