2026年9月22日

最初の一歩は、いま担当している設備の「同期が要る軸」と「要らない軸」を1枚の表に書き出すこと。GX Works3のプロジェクトからサーボ軸の一覧をCSVに出して、軸ごとに「位置決めだけ」「補間が要る」「電子カム・同期が要る」の3分類を付けるだけでいい。250μsや72軸という数字は、この分類で同期が要る軸が何軸あるかが分からないと自分の案件に効くかどうか判断できない。
次の段階は、他社製サーボ・I/Oを混在させたときのエンジニアリング手順の比較。既存のCC-Link IE構成でやっている「機器追加→プロファイル登録→軸設定→試運転」の工数を実測でメモしておき、EtherCAT側のESIファイル運用と並べて見積もる。次回の見積時に「ネットワークを変えると工数がどう動くか」を口頭でなく数字で言えるようになる。
コストは、検討段階なら無料（カタログとマニュアルの読み込み、既存プロジェクトの棚卸しのみ）。実機評価に進むとコントローラ・サーボ一式の借用または購入が要るので、まずは代理店にデモ機貸出の可否を聞く段階で止めるのが安い。
注意点は、対応ネットワークが増えたからといって既存案件を置き換える理由にはならないこと。客先の保全担当が触れる工具（コンフィギュレータ、診断画面）が変わる影響のほうが、立ち上げ時の工数より長く効く。置き換えを検討するなら、保全側の教育コストを最初の見積に入れておく。

最初の一歩は、次の立ち上げ案件で「PDOマップ確認シート」を1枚作ること。列は〈オフセット／バイト数／データ型／符号／エンディアン／Rx・Txはどちら視点か／版数〉の7つで十分で、Excelでも手書きでもいい。相手ベンダのマニュアルを見ながら自分で埋め、埋まらない欄はその場でベンダに質問する。この「埋まらない欄」が後で必ず化けるので、空欄のまま試運転に入らない。
次の段階は、指令の受け渡しをハンドシェイクに変えること。GX Works3側で指令ワードに「要求No.」を1ワード足し、機器側の「受付No.」「完了No.」と突き合わせてから次工程へ進めるラダーにする。既存の「完了ビットON待ち」を残したままでいいので、番号一致条件をAND条件として追加するところから始められる。
コストはゼロ（設計時間だけ）。強いて言えばデバイス点数が指令1件あたり2〜3ワード増えるが、MELSECのワードデバイスで困る規模ではない。工数は1軸あたり半日程度を見ておけば足りる。
注意点は、通信断からの復帰処理。「つながったら前回の出力を戻す」を既定にしていると、装置が途中状態のまま動き出す。再接続後は構成IDと現在位置・ワーク有無を照合するまで出力保持にして、復帰は人が操作する別ボタンに割り当てておく。

最初の一歩は、直近で終わった案件1件について〈分類／成果物／形式／状態〉の4列だけのシートを作り、納品したファイルを全部行に起こすこと。スプレッドシートで30分もあれば埋まる。ここで「どこにあるか分からない」「最新版がどれか分からない」成果物が何件あるかが見えるので、次の案件の標準フォルダ構成をそれに合わせて作り直せる。
次の段階は、IT系資料のうち1種類だけをMarkdownに寄せること。おすすめは操作手順書で、Wordの体裁調整が一番無駄になっている資料だから。GitでもGoogle ドライブでもいいので差分が追える場所に置き、PDF書き出しだけ納品用に残す。ここまで来ると、仕様変更のたびに「どこを直したか」を客先へ説明する時間が確実に減る。
コストは無料枠で始められる。CADは既存のものをそのまま使い、DXF保存を「発行前に必ずやる」運用に変えるだけでいい。DWG TrueViewのようなビューアも無償で入手できる範囲。AI支援を試す段階でも、まずはDXFをテキストとして読ませる程度なら既存のChatGPT/Claudeの無料・既契約枠で足りる。
注意点は、DXFにしたからといってAIが即座に実用的な図面を吐くわけではない点。記事自体も第3章で検証するとしている段階なので、まずは「AIが読める形で残す」ところまでを目的にする。客先提出物の正本はあくまでPDFと元ファイルで、AI生成物を無検証で納品物に混ぜない。

最初の一歩は、いま一番重いスプレッドシートを1つ決めて手動計算に切り替えてみること。制御設計まわりなら、I/Oリストとタグ表をVLOOKUPで突き合わせている管理簿か、複数機種の部品表を集計している見積シートが候補になる。行を100行貼り付けたときの待ち時間を、切替前後でストップウォッチで測ってメモしておくと、チームに広めるときの説得材料になる。
次の段階は、現地調査データの取り込みに使うこと。客先工場で採った測定値やアラーム履歴をCSVで貼り込むシートは、貼るたびに全再計算が走って手が止まりやすい。貼り込み中は手動、貼り終わってから一括更新、という手順を作業手順書に1行書き足すだけで運用に乗る。
コストはゼロ。既存のGoogle スプレッドシートの設定変更なので追加ライセンスも要らないし、失敗しても自動計算に戻すだけで元に戻る。
注意点は、手動にしたまま放置すると古い値のままのシートを他人が見る危険があること。共有する管理簿に使う場合は、シート先頭に「手動計算：最終更新日時」のセルを置き、更新したら日付を手で入れる運用をセットにする。1人作業の重い計算シートには向くが、複数人が同時に見る帳票は自動のままにしておくほうが安全。

最初の一歩は、無料公開されている第1章を読んで、手元のWindows PCにCODESYSの開発環境を入れて起動するところまでをやること。実PLCもHMIも不要と書かれているので、会社PCの持ち出し制限がある環境でも自宅PCで完結できる。三菱一本でやってきた人ほど、Simulationだけで周期実行の挙動が見られる環境を1つ持っておく価値がある。
次の段階は、いま担当している装置の一番単純なシーケンス（起動・停止・非常停止からの復帰あたり）を、ラダーではなくSTで書き直してみること。本の題材が模擬搬送装置なので、コンベヤ1条の搬送制御なら題材をほぼそのまま自分の設備に読み替えられる。ここで「STだと条件の入れ子がどれだけ読みやすくなるか／かえって追いにくくなるか」を自分の目で判断できるようになる。
コストは書籍が500円、開発環境は自分で用意する前提。学習に使う時間のほうが大きいので、平日夜1時間×1週間くらいの枠を先に取ってしまうほうが確実。
注意点は、CODESYSで身に付けたSTの書き方をそのままGX Works3へ持ち込めるとは限らないこと。IEC 61131-3系の考え方は共通でも、メーカーごとの命令や制約は別物なので、学ぶのは「周期実行とステート設計の考え方」に絞る。客先の実機へ未検証のSTを入れるのは、社内で模擬動作を通してからにする。

最初の一歩は、客先常駐用・出張用に持ち歩いているノートPCで、PANATERM系のツールが入っているかとそのバージョンを確認すること。Windowsの「アプリと機能」で一覧を出し、上の5製品名に当たるものがあればバージョンを控える。サーボの調整で1回だけ入れて、そのまま残っているPCが現場には結構ある。
次の段階は、社内の保全PC・持ち出しPCの棚卸しに広げること。自分のPCだけ直しても、客先で共用している調整用PCが古いままなら意味が薄い。資産管理台帳がある会社なら「PANATERM」で検索、無い会社なら保全チームにチャットで1行聞いて回るだけでも十分効果がある。該当すればベンダの配布ページから最新版に更新する。
コストはゼロ（アップデート作業の時間のみ）。ただし現場の調整用PCは「今のバージョンで動いているから触るな」と言われやすいので、更新は装置停止中の枠でやるか、予備PCで先に動作確認してから本番PCに適用する段取りにしておく。
注意点は2つ。影響として挙げられているのは細工されたUSBデバイス接続によるWindowsのDoSであって、サーボアンプ本体やモータが乗っ取られるという話ではない。過剰に騒がず、ただし「現場で拾ったUSBメモリを調整用PCに挿す」習慣は今回を機に止める。もう1つ、脆弱性の対象はここに挙がったツールに含まれるドライバなので、同じPCに入っている他社ツールまで一律に更新推奨とは読み替えない。棚卸しの対象は対象製品に絞って進める。

最初の一歩は、非常停止交換のチェックリストを紙1枚で作ること。項目は投稿が挙げる4点をそのまま使えばいい——①押下時に2入力ともOFFになるか、②片側だけ開いたときに不一致（ディスクレパンシー）を検出するか、③解除後に入力が復帰するか、④リセット後の再起動条件が正しいか。次の交換作業でこれを持って現場に行き、サインを入れて客先に渡す。
次の段階は、②の「片側だけ崩す」試験を安全に行う手順を決めること。安全リレーユニットや安全PLCの入力端子で片チャンネルを外す方法を、機種ごとに社内手順として書いておく。GX Works3側で安全プログラムを使っているなら、不一致検出のエラーコードと復帰条件も併せてメモしておくと、現場で「エラーが出たがこれは想定内」と即答できる。
コストはゼロで、追加の工具も要らない。強いて言えば試験時間が1台あたり10〜15分増えるだけ。その代わり「押したら止まった」で終わらせた交換が後から効いてくる事故を防げる。
注意点は、安全回路の試験は必ず危険区域に人がいない状態で、かつ客先の安全管理者の承認を得てから行うこと。片チャンネルを外す試験は、手順を誤ると安全機能が無効な状態で装置が動く。試験中は機械の主電源または動力を落とし、復旧手順まで含めて事前に紙に書いてから着手する。

最初の一歩は、いま関わっている設備で「異常時に何を止めるか」を機能単位に分解した表を1枚作ること。行に〈PLC制御／画像処理／HMI／ログ保存〉、列に〈止める範囲／継続可否／復帰条件〉を置いて埋める。集約構成の案件でなくても書ける表なので、まずは既存設備でやってみると、いまの設計が「全部止める」一択になっていることが可視化される。
次の段階は、ウォッチドッグの設計を明文化すること。産業用PCに制御を載せる構成を検討するなら、PC外部の安全リレーまたは独立したPLCで出力を安全状態へ落とす経路を1本残す。GX Works3側で既存PLCを監視用に残す構成なら、PCからのハートビートが一定周期途絶えたら出力OFF、というラダーは数十ステップで書ける。
コストは、検討・表作成の段階はゼロ。外部ウォッチドッグ用に安全リレーや小型PLCを1台足す場合でも数万円規模で、集約で削減できる機器点数を考えれば埋まる範囲に収まることが多い。
注意点は、復帰条件の設計を後回しにしないこと。投稿が言うとおり「PCが立ち上がっただけで途中工程を再開しない」を守るには、レシピ・軸位置・ワーク有無の照合が要る。ここを作り込まないまま集約すると、復旧のたびに人が手動でワークを抜く作業が発生して、集約で得たはずの工数が消える。客先に提案する前に、復旧手順書のドラフトまで作ってから持っていくのが安全。

最初の一歩は、ガイドライン本体をJEMAのサイトから入手して目次だけ通読し、「設計時に自分が選定するモータ」に関わる章に付箋を打つこと。トップランナー制度は効率値の規制なので、ライフサイクルCO2や素材まで話が広がると、選定理由の書き方そのものが変わる。設計仕様書のモータ選定根拠欄に何を書くべきかを先に把握しておく。
次の段階は、レアアースを使わないリラクタンスモータが自分の案件に入るかを1件だけ試算してみること。搬送コンベヤやポンプのように負荷変動が読める用途から当たるのが現実的で、メーカーの選定ツールで同容量のIPMと比較して、効率・体格・価格・インバータ側の制御方式の4点を表にする。ここで「ドライブ側の設定が変わる」ことが分かるのが一番の収穫になる。
コストは、調査段階は無料（ガイドライン閲覧とメーカー選定ツール）。実機比較に進むと評価用モータとドライブの手配が要るので、まずは代理店に類似案件の実績を聞く段階で止めるのが安い。
注意点は、客先の設備更新でモータを変える提案は、保全側の予備品在庫と直結すること。既存在庫と型式が変わると、客先は予備品を二重に持つことになる。提案するなら、更新台数がまとまるライン単位のタイミングを狙い、予備品の整理計画までセットで出す。ガイドラインは推進の方向を示すもので、個別案件の選定を縛るものとして客先に説明しない。

最初の一歩は、自分のPC上でAIエージェント（Claude Code や Codex 等）が読める範囲に、認証情報がベタ書きで置かれていないかを洗うこと。ホームディレクトリの `.env`、設定ファイル、過去に書いた検証スクリプトが対象になる。制御屋でも、客先の装置にリモート接続するためのVPN設定やクラウド収集のAPIキーを、検証用スクリプトに直書きしたまま忘れていることはよくある。
次の段階は、エージェントに渡す作業フォルダを分けること。装置データの解析やGAS開発をAIにやらせるなら、その作業専用のフォルダを切って、資格情報を含むファイルはそこに置かない。読み書きの対象を絞るだけで、「エージェント経由で認証情報が別システムへ動く」経路をかなり潰せる。
コストはゼロ。フォルダ構成と置き場所を変えるだけで、追加のツールもライセンスも要らない。GitLabの機能そのものは自社でGitLabを使っていなければ関係ないが、記事の「認証情報とコンテキストがシステム間を行き来する」という捉え方は、どのエージェントを使っていても当てはまる。
注意点は、客先から預かった情報（図面、レシピ値、生産データ）をAIに読ませる判断を個人でしないこと。自分の資格情報を守る話と、客先の機密を外部サービスへ出す話は別問題で、後者は必ず社内ルールと客先の合意が要る。まずは自分の認証情報の整理という、誰の許可も要らない範囲から始める。

最初の一歩は、自分がAIに触らせているフォルダに CLAUDE.md と AGENTS.md のどちらが置いてあるかを確認すること。GASのスクリプトを置いているフォルダ、装置データの解析スクリプトを置いているフォルダの2つくらいを見れば十分。片方しか無ければ意図どおりに読まれているし、両方あるなら AGENTS.md 側に書いた指示が効いていない可能性がある。
次の段階は、指示ファイルの中身を「制御屋向けの前提」で1回書き直すこと。たとえば「単位は必ずmm・msで書く」「タグ名は既存の命名規則に合わせる」「生成したコードを客先データで実行しない」といった、毎回口で言っている前提を5〜10行だけ書いておく。これだけで、やり取りのたびに同じ注意を打ち込む手間が消える。
コストはゼロ。テキストファイルを1つ置くだけで、既存の契約プランの範囲で効く。作業時間も初回15分程度。
注意点は、この判定がバージョンに紐づく話であること。投稿が挙げているのは v2.1.277 の挙動なので、自分の環境のバージョンが違えば結果も変わりうる。`CLAUDE.local.md` を置いている人は、それが AGENTS.md の読み込みを止める側に効く点だけ覚えておき、実際の挙動は自分の環境で一度確かめてから運用に組み込む。

最初の一歩は、自分が客先へ送っている報告メールが本当に届いているかを1回確かめること。装置の点検報告や不具合報告書をPDFで送る運用なら、届かずに迷惑メール送りになっていても誰も教えてくれない。テスト用に自分のGmailアカウントへ1通送り、受信トレイに入るかを見るだけで10分で済む。
次の段階は、記事と同じ「経路を分けて試す」考え方を借りること。会社のメールサーバ経由、Google Workspace経由、スマホのキャリアメール経由のように2〜3本で同じ本文を送り、どれが落ちるかを切り分ける。全部落ちるならドメイン側、1本だけ落ちるならその経路の設定という判断になり、情シスに相談するときの材料が具体的になる。
コストはゼロ。GASを書けるなら、記事の「毎朝テストメールを送って判定する」をそのまま真似て、Gmail の送信と受信ラベル確認をトリガーで回す仕組みが1時間ほどで組める。無料枠で完結する。
注意点は、認証（SPF・DKIM・DMARC）が通っていることと、届くことが別だという点。記事のケースも認証はすべてpassしていた。設定を直す前に「いつから落ち始めたか」「その前後で何を変えたか」を時系列で書き出すほうが、原因にたどり着くのが早い。ドメインやメールサーバの設定変更は情シスの管轄なので、自分で触らず切り分け結果を渡す。