2026年9月15日

これは今日そのまま真似できる、数少ない「AI×制御設計」の実装知です。最初の一歩は、自分が普段AIに投げるプロンプト（またはClaude Code／ChatGPTのカスタム指示・プロジェクト指示）の先頭に、記事のNG/OK対比を5行だけ貼ること。「数値リテラルには必ず型を明示（USINT#0、T#5s、BYTE#16#01）」「配列添字はINTに変換して渡す（USINT_TO_INT）」「配列は1始まり（または0始まり）と明記」「Execute型FBはDone後に必ずExecute:=FALSE」「文字列は+ではなくCONCAT、REALは等価比較しない」。所要10分、費用ゼロです。次の段階は、レビュー側の機械化。記事が言う「`:= 0` や `= 1` のような裸の数字を検索する」は、Sysmac Studio からSTをテキストで書き出して、エディタの正規表現検索で `:=\s*[0-9]` を引っかければ一覧になります。これを自機のSTプロジェクト1本で試して、何件出るかを数えるところから始めてください。ゼロ件なら今の書き方は安全側、数十件出るならAI以前に自分の資産側にも同じ地雷が埋まっています。3段目は、三菱系（GX Works3 / ST）に読み替える作業です。メーカごとに厳しさが違うと記事自身が断っているので、そのまま横流ししてはいけません。自分の環境で「型付きリテラルなしで通るか」「添字の暗黙変換が通るか」を、捨てプロジェクトで各3行ずつ試して、通る／警告／エラーの3分類の表を作る。半日で終わって、以後ずっと効きます。コストはゼロ、必要なのは開発環境だけ。注意点は2つ。ひとつめは、Execute型FBの罠は「ビルドが通ってしまう」種類なので、AI生成コードのレビュー基準を「ビルドが通ったらOK」にしていると素通りすることです。連続起動（2回目・3回目）のテストを受入条件に入れてください。ふたつめは、AI生成STを客先の実機にいきなり流さないこと。記事の4パターンは「気づきやすいバグ」であって、論理そのものの妥当性は別問題です。

「AIに判断させるが、最後の一線はAIの外側で止める」という構造そのものが、制御屋の既存設計と地続きなのが今日の要点です。実のところ、あなたがラダーで毎回書いているインターロックは、この記事で言うガードレールと同じ役割を果たしています。最初の一歩は、AIを入れる前に、いま担当している設備1台について「安全制約の一覧」を紙1枚に書き出すこと。人が入ったら動かさない、この軸がこの位置にある間は隣の軸を動かさない、圧力がこの値を超えたら排気、といった条件をラダーから拾って文章化します。所要1〜2時間、費用ゼロ。これは将来AIを入れるかどうかに関わらず、装置の引き継ぎ資料としてそのまま使えます。次の段階は、この一覧を「AIに触らせない領域」として物理的・論理的に分離すること。記事が言う多層構造を自分の盤に読み替えると、上位でAIが指令を出す構成にしても、安全リレー・セーフティPLC・ハードワイヤの非常停止は従来どおり別系統で残す、という設計になります。ここを兼用してコストを削ると、AIが誤った指令を出したときに止める手段がなくなります。3段目は「過度な停止を89%削減」という数字の読み方です。これは安全側を緩めた結果ではなく、止めずに済む場面で止めなくした結果として書かれています。自分の現場に置き換えるなら、まず「本当は止めなくてよかったのに止まった」チョコ停を1か月分記録してみてください。日報や設備ログから拾えます。この件数が多いなら、AI以前に、インターロック条件が過剰に広く取られている可能性があります。コスト感としては、記録と条件の棚卸しはゼロ円、実際のフィジカルAI導入は現時点では社会インフラ向けの検証段階なので、中小規模の装置にすぐ降りてくる話ではありません。注意点は、この種の技術が普及したとき、客先から「AIが出した指令を監視する層はどこにあるのか」と聞かれる側に自分が回ることです。答えられる用意を今から作っておくのが実利です。

これは明日の立上げでそのまま使える切り分けフォーマットです。最初の一歩は、この4段（PLC内部指令／送信PDO・制御ワード／受信の状態ワード／実際の出力周波数）を、担当装置のモニタ画面として先に作っておくこと。GX Works3 なら「ウォッチウィンドウ」に4つの要素を1画面に並べて登録し、プロジェクトに保存しておきます。所要30分、費用ゼロ。トラブルが起きてから作ると、その場でデバイス番号を探すところから始まって時間を失います。次の段階は、この4段をチェックシート化して、切り分け結果を「どこまで届いていたか」で記録する運用にすることです。異常名（速度切替異常）ではなく到達点（送信PDOまでは変わっていた）で残すと、次に同じ現象が出たときに調査の開始位置が変わります。紙1枚でよく、装置ごとにファイルへ挟んでおけば引き継ぎ資料にもなります。3段目は、生成AIの使いどころです。この手の切り分けはAIに「どこが悪いか」を当てさせても役に立ちませんが、モニタした4つの値を貼って「この組み合わせから何が言えるか、次に見るべき候補を挙げて」と聞くのは有効です。ChatGPT / Gemini の無料枠で足ります。ただし機器型式や客先名は入れず、値と挙動だけを渡してください。コストは、ここまで全部ゼロ円。追加投資が要るとすれば、EtherCAT のマスタ側パケットを見るためのアナライザですが、多くの場合は上記4段のモニタで足ります。注意点は2つ。ひとつめは、インバータ側の「運転モード・指令受付条件」は機種ごとにパラメータ番号が違うので、装置ごとに該当パラメータ番号を先に控えておくこと。現場でマニュアルを引き始めると30分持っていかれます。ふたつめは、状態ワードのビット定義を自己流で覚えないこと。メーカのマニュアルの該当ページを印刷して盤に入れておくのが、結局いちばん速いです。

統合セルの話に見えますが、中身は「復帰シーケンスの設計」で、2台構成の小さな設備でも同じことが起きます。最初の一歩は、担当している設備1台について「何を正とするか」の表を作ること。行に情報（工程ステップ／加工状態／把持状態／ワーク有無／要求ID）、列に保持先（PLC／CNC・加工機／ロボット／センサ）を置いて、各行で正とする保持先に丸を付けるだけです。A4横1枚、所要1時間、費用ゼロ。ここで2か所に丸が付く行があれば、それが将来の復帰事故の候補です。次の段階は、異常リセットの挙動を実際に確認すること。今の設備で「途中で止めて、リセットを押したら何が起きるか」を、ワークを入れた状態と抜いた状態の2パターンで試します。加工済みワークに再加工を指示しないか、手でワークを抜いたことに気付くか。ここで気付かない設計になっていたら、ワーク有無センサの値を復帰条件に入れる改造を、次の停止機会に合わせて提案できます。3段目は、投稿が言う「指令・受付・動作中・完了を一つのビットにまとめない」の実装です。M接点1点で「取出し要求」を表している箇所を探し、要求／受付／実行中／完了の4点に割り直します。デバイスは食いますが、止まった瞬間にどの段階だったかがラダーモニタだけで分かるようになり、電話一本での遠隔切り分けが現実的になります。コストはデバイス点数だけ、金額ゼロ。注意点は3つ。ひとつめは、復帰条件を厳しくすると自動再開しない場面が増えるので、HMIに「何が矛盾しているか」を必ず表示すること。表示なしで止めるだけだと現場が勝手にリセットを連打します。ふたつめは、要求IDを持たせるなら、電源断をまたいで保持するデバイス（ラッチリレー）に置くこと。3つめは、この表は装置ごとに違うので、テンプレ化して他装置へコピーするときも必ず1行ずつ見直すことです。

設計業務の自動化をGASで組んでいる人には、地味ですが致命的な前提の話です。記事自身が「将来的に6分に統一される可能性がある」と書いている以上、実務側の答えは「30分に頼らない構造にしておく」の一択になります。最初の一歩は、自分が書いたGASのうち、1回の実行が数分を超えるものを洗い出すこと。Apps Script の「実行数」画面を開いて、実行時間の列を降順に眺めれば1分で分かります。費用ゼロ。制御設計まわりだと、タグ表の一括チェック、図面ファイル名の棚卸し、複数スプレッドシートの横断集計あたりが該当しがちです。次の段階は、6分を超えるものを「分割実行」に直すこと。定番の作り方は、処理対象の行番号を PropertiesService に保存しておき、1回の実行では例えば200行だけ処理して、続きがあれば `ScriptApp.newTrigger` で1分後の自分自身を予約し、終わったらトリガーを削除する形です。この骨格は generative AI に「GASで、処理位置をPropertiesServiceに保存して分割実行するテンプレートを書いて」と頼めば10分で出てきます。3段目は、監視との組み合わせです（軸Bのトリガー未着監視の話と直結します）。分割実行にすると「途中の回でこけて、以降が動かない」失敗モードが増えるので、最終回が終わったときだけ完了を記録する仕組みを必ず付けてください。コストは全部ゼロ円、必要なのは Google アカウントだけです。注意点は2つ。ひとつめは、この記事の実測はWorkspace有償環境1つでの結果なので、自社アカウントで同じとは限らないこと。自分の環境で1度だけ同じ検証（1分ごとにログを吐く無限ループ）を回して、何分で切られるかを確かめておくのが確実です。ふたつめは、公式ドキュメントが6分と書いている以上、客先や社内に説明するときの根拠は6分側にしておくこと。実測30分を前提に設計を説明すると、仕様変更で切られたときに言い訳ができません。

外観検査の自動化は「カメラを付ければ終わり」ではなく、ワークをどう動かして何面撮るかで難易度が決まります。この展示が示しているのは、検査AIと、それを多方向から当てるための動きを、1ユニットにまとめた構成です。最初の一歩は、客先で「目視検査が残っている工程」を1つ選び、スマホで20枚だけ写真を撮ること。良品10枚、不良10枚。撮るときに気付くのが本番で、照明の当たり方で見え方が変わる、角度を変えないと見えない欠陥がある、という点が分かります。所要30分、費用ゼロ。ここで「1方向から撮れば判別できる」なら固定カメラで済み、Type-U のような可動ユニットは要りません。次の段階は、その20枚を汎用の生成AI（ChatGPT / Gemini の無料枠）に渡して「この10枚と10枚を分ける特徴を挙げて」と聞いてみることです。人間が言語化できていない判定基準が炙り出されます。AI検査の導入提案で最初につまずくのは、客先の検査員が「なんとなく分かる」で判定している基準の不在なので、ここを先に埋めておくと話が前に進みます。3段目で初めて、MiraLens のような現場画像で学習するプラットフォームや、i-WRIST Type-U のような多方向撮像ユニットの見積を取る段階に入ります。コスト感としては、ここまでの棚卸しはゼロ円、検査AIプラットフォームは年額のライセンス費、ロボットユニットを含めると設備投資として数百万円規模を見込む話になるので、いきなり見積から入ると企画が止まります。注意点は2つ。ひとつめは、AI判定の出力をそのまま良否判定として下流に流すと、誤判定時の責任の所在が曖昧になること。当面は「AIがNGと言ったものだけ人が見る」という選別補助の位置づけから始めるのが安全です。ふたつめは、学習用画像の権利と持ち出し可否を客先に先に確認すること。製品の外観写真は、それ自体が機密扱いになる現場があります。

メーカーが自社機器の状態監視をクラウドサービスとして出してくる流れは、フィールドエンジニアリング側の仕事の形を変える話なので、製品の詳細より「自分の立ち位置がどう変わるか」で読むのが実用的です。最初の一歩は、担当している客先設備のうち、ポンプ・ブロワ・コンプレッサといった回転機がどれだけあるかを数えること。設備台帳か現地の機器リストから拾えて、所要1時間、費用ゼロ。ここが多い客先ほど、メーカー純正の状態監視サービスが先に入ってくる可能性が高いと考えられます。次の段階は、そのとき自分が何を提供できるかの整理です。メーカー純正サービスは自社機器の内部状態には強い一方、その機器が止まったときに前後の工程がどう連動して止まるか、復帰にどんな手順が要るかは、盤とラダーを知っている側にしか書けません。手元の1設備で「この機器が止まったら、どの工程が何秒後に止まり、復帰にはどの順で何をするか」を書き出しておくと、監視サービスの通知を受け取った後の手順書として、そのまま価値になります。3段目は、自前で似たことをやる場合の現実的なラインです。既設のPLCで取れている値（運転信号、電流、圧力、積算運転時間）をすでに持っているなら、それをスプレッドシートへ日次で吐き出して閾値を2段（注意／異常）で見るだけでも、傾向監視としては成立します。GASとスプレッドシートで組めるので費用ゼロ、ただし24時間の高頻度サンプリングは別の仕組みが要ります。注意点は2つ。ひとつめは、この展示に関して手元で確認できた情報は展示された事実とシステム名に限られるので、仕様・価格・センサー方式を客先に説明するなら必ずメーカー公式の資料に当たること。ふたつめは、監視データをクラウドに上げる話は客先の情報管理規程に触れるので、技術検討より先に社内の情報システム部門を巻き込むことです。

短い投稿ですが、設計のチェックリストに直せる形をしているのが使いどころです。最初の一歩は、投稿が挙げている5項目（退避条件／インターロック／現在位置／原点センサ／他軸との干渉条件）を、そのまま原点復帰の設計レビュー項目にすること。自分の担当装置1台のラダーを開いて、原点復帰ルーチンについてこの5項目が明示的に書かれているかを確認します。所要1時間、費用ゼロ。ありがちなのは、単体復帰の条件しか書いておらず、自動運転の途中状態から戻るケースが想定されていないパターンです。次の段階は、テストケースを「単体で戻る」以外に増やすこと。最低でも、(1) 自動運転の各工程の途中で非常停止をかけてから復帰、(2) 他軸が干渉位置にある状態で復帰、(3) 原点センサを踏んだ位置で電源を入れ直して復帰、の3つは実機で試してください。立上げ中にここを潰しておかないと、客先で人が変わった瞬間に電話がかかってきます。3段目は、投稿が言う「安全に原点まで戻れる状態を作る処理」への作り替えです。具体的には、復帰ボタンを押したらすぐ動き出す構成をやめ、押した時点でまず条件判定だけを行い、揃っていなければHMIに「何が足りないか」を出して動かさない、という2段構えにします。揃っていれば従来どおり復帰する。この改造はラダーの追加だけで済み、費用ゼロです。多関節ロボットを含む設備では、投稿が注意を促しているとおり、ロボット側の原点復帰はPLC側から一括で呼ぶのではなく、姿勢を確認したうえで手順を分けるのが安全側です。注意点は2つ。ひとつめは、干渉条件を厳しくしすぎると「どうやっても復帰できない位置」が生まれるので、必ず手動軸送りで脱出できる経路を残すこと。ふたつめは、復帰手順をHMIの表示とセットで作ったら、その内容を取扱説明書にも反映すること。画面にだけ書いても、客先の担当者が代わると伝わりません。

「動かなかったことに気づけない」は、GASに限らず現場の自動化全般で一番危ない失敗モードです。制御屋の言葉に直すと、これはウォッチドッグタイマの話で、投稿の言う「期限までに完了報告が届かなければ未着」は、定周期でリセットされないタイマが上がったら異常、というラダーとまったく同じ構造をしています。最初の一歩は、自分が回している日次の自動処理（日報集計、点検記録の転記、バックアップ、タグ表のチェック）を書き出して、それぞれについて「動かなかった日に、自分は何日後に気づくか」を横に書くこと。所要20分、費用ゼロ。ここで「気づかない」と書かれたものが対象です。次の段階は、外部サービスを使わずに同じ効果を出す最小構成から始めることです。監視される側と監視する側を別のGoogleアカウント／別のスプレッドシートに分け、処理側は完了時に監視用シートへ1行（日付・件数・結果）を追記、監視側は別トリガーで毎朝「昨日の行があるか」を見てなければメールを飛ばす。これで「処理が動かなかった日」を検知できます。GASだけで組めて費用ゼロ、記事が挙げる scheduled_for / status / metrics の考え方をそのまま列にすればよく、半日で動きます。3段目で、監視側も落ちる可能性を潰すために外部サービス（記事が例示している種類のもの）を検討します。ここで初めて月額が発生しますが、個人利用なら無料枠で足りることが多い領域です。記事の指摘のうち実務で一番効くのは「完了はしたが件数0件」を成功扱いしないことで、これは現場の日報集計で本当によく起きます。0件を正常とするか異常とするかは処理ごとに違うので、書き出した一覧に「0件が正常な日はあるか」の列を足してください。注意点は2つ。ひとつめは、報告の送信だけを再試行する設計にすること。処理全体を再実行すると二重転記が起きます。ふたつめは、監視通知の宛先を自分1人にしないこと。休暇中に止まったまま1週間、という事故がこの種の仕組みの典型的な負け方です。

AIの話ではありませんが、盤設計の見積と現地工数に直接効くので、実利は今日の中でも高い部類です。最初の一歩は、直近に設計した盤1面の図面を開いて、リモートI/Oの外側に別途付けているコモン端子台が何列あるかを数えること。所要15分、費用ゼロ。3線式センサを多用する設備だと、I/O点数と同じだけの＋とコモンが要るので、端子台がI/Oユニットより場所を食っていることが珍しくありません。この列数がそのまま、MT1XR のようなコモン端子台内蔵型に置き換えたときの削減幅の上限になります。次の段階は、工数側の試算です。プッシュイン構造は「差し込むだけ」なので、ネジ締めとの差は1点あたり数秒〜十数秒ですが、256点の盤なら1〜2時間の差になります。さらに効くのは増し締めが不要になる点で、出荷前検査と現地立会いの工程から増し締め作業を落とせるかを、自社の検査要領書と突き合わせて確認してください。3段目は、ネットワーク構成の見直しです。RJ45でスター／ライン／リングのトポロジーに対応するとあるので、いま集中配置しているI/Oを装置側へ分散できるなら、盤〜機側の多芯ケーブルをEthernet1本に置き換えられる可能性があります。ここは削減額が大きい代わりに、TSNのネットワーク設計（サイクルタイム、帯域、冗長）を詰める必要があるので、まず1装置での試験導入から。コスト感としては、リモートI/O本体はコモン端子台を別途買う構成と大きくは変わらない価格帯に収まることが多く、効いてくるのは端子台の調達点数と盤スペース、そして現地工数です。注意点は2つ。ひとつめは、自社標準が三菱系（CC-Link IE TSN）でない客先には提案できないこと。EtherNet/IP や PROFINET 指定の案件では別機種を探すことになります。ふたつめは、スプリング圧結線は電線サイズの許容範囲が製品ごとに決まっているので、現場で使う電線とフェルール端子の組み合わせが適合するかを、採用前に必ずカタログで確認することです。

「自分はWeb開発者ではないから関係ない」と読み飛ばしたくなる話ですが、生成AIを業務に入れた時点で当事者になっています。Claude Code や Codex のようなコーディングエージェント、MCPサーバ、Pythonで書いた収集ツール、GASから呼ぶライブラリ——これらはすべて npm / PyPI からパッケージを引いてきます。しかも、AIエージェントは「必要そうなライブラリを勝手に入れる」ので、自分が承認していない依存が増えていきます。最初の一歩は、自分の手元で動いている自動化ツールについて、依存パッケージの一覧を出すこと。Node なら `npm ls --depth=0`、Python なら `pip list`。所要10分、費用ゼロ。名前も用途も思い出せないものが並んでいたら、それが攻撃対象面です。次の段階は、記事が推奨する2つの設定を入れることです。ひとつは lockfile を必ずコミットすること（`package-lock.json` / `requirements.txt` のバージョン固定）。もうひとつは cooldown で、記事は7日、急ぐ場合でも3日の待機を勧めています。npm なら `.npmrc` に設定を1行足すだけで、「公開直後の版は入れない」状態にできます。keyv の例で悪性版が30分で増殖し、TanStack では20〜26分で報告が届いたことを踏まえると、この数日の待機が実質的な防御になります。費用ゼロ、作業10分。3段目は、業務PCと実験環境の分離です。客先の図面や設計データが入っているPCで、AIエージェントに自由にパッケージを入れさせるのは、今回の事例に照らすとリスクが高い。試すなら別環境（別ユーザーアカウント、仮想マシン、あるいは専用の安いPC）で、というのが現実的な線引きです。注意点を2つ。ひとつめは、npm v12 でインストールスクリプトが既定で無効化されたことは朗報ですが、自分の環境がv12以降かは別問題なので `npm -v` で確認すること。ふたつめは、この記事が示しているのは「正規の経路でも悪性版は出る」という点なので、公式・有名パッケージだから安全という判断はもう成り立たないことです。最後の線引きは「万一そのPCの中身が抜かれても致命傷にならないか」に置いてください。

この記事は「サボる側」の話として読むと何も得られませんが、「自分の効率化をどう可視化して自分の利益にするか」の設計図として読むと実用的です。制御設計やフィールドエンジニアリングは、成果が装置の稼働という形で外に出る分、AIで浮かせた時間が見えにくい職種です。最初の一歩は、自分がAIで置き換えた作業を「作業名・従来の所要時間・現在の所要時間」の3列で記録し始めること。タグ表のチェックに2時間かかっていたのが20分、報告書の下書きが1時間から15分、といった粒度で構いません。スプレッドシート1枚、記録は1件30秒、費用ゼロ。これが3か月たまると、記事の調査が言う「隠す／隠さない」の前に、そもそも数字がないから交渉できない、という状態を抜けられます。次の段階は、浮いた時間の使い道を自分で先に決めることです。記事の事例が示しているのは、報告した結果として仕事が詰め込まれるという懸念ですが、これは「浮いた時間が空白として見えるから埋められる」構造でもあります。先に「この時間は過去トラブルの水平展開資料づくりに使う」「この時間は自分の標準ラダーライブラリの整備に充てる」と枠を取っておくと、埋められる前に自分の資産づくりに回せます。3段目は、共有の仕方の選択です。記事にあるとおり、ノウハウ共有を求められること自体が負担になるので、口頭で説明する形ではなく、プロンプトや手順をドキュメント1枚にして渡す形にしておくと、同じ説明を何度もしなくて済みます。コストはゼロ、効くのは自分の時間です。注意点を2つ。ひとつめは、記事が隠す理由として「雇用主がAI活用ポリシーを定めていない」を挙げている点で、これは裏を返すと、ポリシーがない状態で客先データをAIに入れると、後から問題になったときに個人の判断として責任が来るということです。効率化を隠すかどうか以前に、何を入れてよいかは会社に確認して記録を残しておくべきです。ふたつめは、この記事が示す不信の構造は自分が将来管理する側に回ったときにも出るので、「浮いた時間をどう配分するか」を先に決めた制度でないと、部下は同じことをするという前提で読んでおくことです。