2026年11月5日

最初の一歩は、今担当している既存のロボットセルの安全回路構成図を1枚だけ取り出して、「外付け安全PLC＋安全リレー＋安全I/Oで何点を受けているか」を数えること。非常停止、安全扉スイッチ、安全レーザスキャナの入力点数と、それにぶら下がる配線本数が、そのままこの製品で削れる候補の見積になる。次の段階は、その数字を使って盤設計側の金額比較を作ること。安全PLC本体＋安全I/O＋盤内スペース＋配線工数と、R-50iAのソフトPLCライセンス（価格は記事に書かれていないので要見積）を並べ、どの構成規模から逆転するかを自分で押さえておくと、客先への提案が「新製品が出たらしい」で止まらなくなる。コストは、調べる段階は無料（カタログと自社の過去見積だけ）。導入はロボット制御装置の世代更新を伴うので、セル単位で数百万円規模の設備投資案件として扱うのが現実的。注意点は3つ。ひとつはPL eという安全度が自社の必要なPL判定と一致しているかを、リスクアセスメントの結果と突き合わせて確認すること。ふたつめは、安全EtherNet/IPで直結する周辺機器が本当に対応しているかの確認（手持ちの安全I/Oが対応していなければ省配線の効果は出ない）。みっつめは、工程制御盤を市販タブレットのブラウザに出す構成は、そのタブレットとネットワークの管理責任が新しく発生するという点。発売は2027年1月なので、今期ではなく来期の予算に乗せる話として社内に共有しておくと動きやすい。

最初の一歩は、公開物をダウンロードして自分のPCで動かし、「シミュレーター側の信号と、PLC側のデバイス番号をどう突き合わせているか」の1点だけを見ること。ここが机上デバッグの成否を決める部分で、投稿者自身が過去に頓挫した箇所でもある。次の段階は、自分が今持っている一番単純な設備（搬送コンベヤ1本＋ストッパ1個＋在荷センサ2点くらい）を題材に、同じ要領で3Dモデルと信号表を作ってみること。自機の1プロジェクトで、実機なしに「ストッパが上がる前に搬送指令が出たら止まるか」を確認できれば、それだけで立ち上げ初日の手戻りが1件減る。もう一段進めるなら、干渉チェックのシナリオをCSVの動作シーケンス表として書き出し、GX Worksのデバイスコメントと列を揃えておく。これで台数が増えても信号割り付けを手作業でやり直さずに済む。コストは、公開物を試す範囲は無料。自分で作る場合もCADと生成AIの既存契約の範囲で始められ、追加費用はゼロから月数千円規模。注意点は、机上デバッグで通ったことは「ロジックが通った」だけで、実機のセンサ応答時間や機械的なガタは再現されないという前提を外さないこと。シミュレーターを信じて実機確認を省くのではなく、実機で確認する項目を絞るための道具として使う。配布物を客先設備の検証に使う場合は、同梱ソフトを改変して自社管理のものにしてから使うほうが後々の責任分界が楽になる。

最初の一歩は、今動いている設備のラダーから「測定値を比較している接点」を1箇所だけ探し、その比較命令の直前にどんな条件が直列で入っているかを数えること。DataValidだけ、あるいは何も入っていないなら、そこが投稿の指摘どおりの穴になっている。次の段階は、その1箇所に測定有効窓のビットを1本追加すること。ワークID一致、クランプ完了、ロボット退避、センサReadyをANDでまとめた内部リレーを作り、比較命令をそのビットで囲うだけでよい。これは半日の改造で入る。もう一段進めるなら、NG出力を「寸法NG」と「判定不能」の2本に分けて、判定不能側にはタイムアウト・校正期限・姿勢不良のどれで落ちたかを示す状態コードを持たせる。復帰手順書がこの状態コードごとに1行で書けるようになり、夜間の呼び出しが減る。コストは、既存設備への追加はPLCの空きビットと改造工数だけなのでゼロ円〜工数数人日。新規設計なら最初からこの形にしておけば追加費用はない。注意点は2つ。ひとつは、有効窓を厳しくしすぎるとタクトが落ちるので、圧力安定や安定確認のタイマ値は実機で実測してから決めること。ふたつめは、RequestID／ResultIDの照合は測定機側がIDを返す仕様であることが前提なので、機器選定の段階で通信仕様書のどこにIDがあるかを確認しておく。選定時に確認しておかないと、後からソフトでは作れない。

最初の一歩は、自分が過去に書いたGASを1本開いて、「読んでから書くまで」が1つの関数の中に閉じているかを見ること。点検記録の採番、治具の貸出予約、立会日程の押さえ——どれも同じ構造で、2人が同時に押した瞬間に番号が重複する。該当したら、その関数の先頭にgetScriptLock()とwaitLock(30000)、末尾のfinallyにreleaseLock()を足すだけで直る。所要10分。次の段階は、残席や在庫のような「数」を別セルに持っている処理を、記事と同じく確定行の合計に置き換えること。ずれた時に直せなくなる原因が消えるので、点検記録の消耗品在庫表などはこの形が楽になる。もう一段進めるなら、締切や有効期限の判定をe.response.getTimestamp()のようなサーバ側の時刻に寄せること。現場でタブレットを開いたまま放置して夕方に送信される運用では、クライアント時刻や画面表示の数字を信じると必ず事故る。コストは全部無料枠で完結し、メール通知を使う場合だけGmailの送信上限（記事では個人のGmailで1日100通）が制約になる。注意点は、制御設計者にはこの構造が見慣れているはずという点を逆に利用すること。ロックは要するにインタロックで、「排他区間の中で読んで書く」はPLCの排他制御と同じ発想だから、GASの文法よりも排他区間の境界をどこに置くかに時間を使うほうが効く。releaseLock()をfinallyに書き忘れると後続が全部タイムアウトする、という失敗の形まで記事に書かれているので、そこだけはコピーして使う。

最初の一歩は、客先に置いてある産業用PCの一覧を作り、OSの種類とサポート期限の列だけを埋めること。画像処理用、データ収集用、SCADA端末——台数は意外に多く、CentOSやサポートの切れたディストリビューションが残っている確率は高い。ここが埋まっていないと、客先から「SBOMを出してほしい」と言われた時に即答できない。次の段階は、そのうち1台を対象に、今入っているソフトウェアの構成一覧を手で書き出してみること。手でやると30分〜数時間かかると分かり、SPDXやCycloneDXで機械的に出せることの価値が自分の時間で測れる。もう一段進めるなら、次に更新する1台をこの構成（商用Linux＋SBOM一括提供付き）で見積に入れ、「更新費用＋2032年までのサポート」と「無償OSで組んで自社で脆弱性を追う工数」を並べて客先に出す。選定理由が説明できる見積になる。コストは、棚卸しは無料。産業用PCの更新は1台あたり数十万円規模で、ライセンスは組み込み利用の形態によって変わるので要見積。注意点は3つ。ひとつは、SBOMが出せることは脆弱性がないことではないので、受け取ったSBOMを脆弱性管理ツールに通す運用側の手順まで決めないと意味がないこと。ふたつめは、IEC 62443-4-1はサプライヤー側の開発プロセスの規格なので、自分たちが組み上げたシステム全体の適合を主張する根拠には使えないこと。みっつめは、OSを入れ替えると既存のアプリケーションや取り込みドライバの動作確認がやり直しになるので、更新計画には必ず再検証の工数を乗せること。

最初の一歩は、自分が直近で対応したトラブル1件について、「原因を切り分けるまでに開いたファイルと、それぞれどこにあったか」を列挙すること。図面はサーバー、過去の変更履歴はメール、設定値は自分のPC、前回の対応メモは紙——こう並べると、出光が解いた「分断」が自分の手元にもあると分かる。次の段階は、その1件分だけ、機器名をキーにしたフォルダを作って図面・設定ファイル・トレンドの画面キャプチャ・対応メモを集約してみること。プラットフォームを買う前に、「機器にひも付ける」という形が自分の仕事で効くかどうかはこれで判断できる。もう一段進めるなら、朝イチの不具合報告をPowerPointに起こすのをやめて、機器名・現象・時刻・運転データの該当範囲・写真の5項目だけのテンプレートに置き換える。出光が稼働率低下の一原因として挙げた「共有に時間がかかる」をそのまま削る動きで、客先の当直担当にも渡しやすい。コスト感は2段構え。機器名キーのフォルダ整理とテンプレート化は無料で明日からできる。CDFのような産業用データ統合プラットフォームの導入は、記事の規模（累積ユーザー約2500人）から分かるとおり全社案件で、数千万円以上のシステム投資として扱う話なので、個人で持ち込む対象ではない。注意点は、記事でも鳳城氏が「各プラントの業務フローは、似ているようで全く異なっていたり、データの形式が違っていたりしたため、現場との調整が非常に難しかった」と述べている点。道具より先に、どのデータを誰が正とするかの合意が要る。もうひとつ、AIエージェントによる異常検知と判断支援は2030年に向けた目標で、すでに稼働している話ではないので、客先に紹介するときに「もう動いている事例」として語らないこと。

この記事が効くのは、記事全体ではなく「AIには書かせるだけ、外への操作は決まった処理で行う」という一文。最初の一歩は、自分が今AIに任せている作業で、AI自身が外に出せてしまう権限を1つ探して外すこと。たとえば日報や点検記録の自動生成で、AIにメール送信やファイルサーバーへの書き込みまでやらせているなら、AIの出力はローカルのファイルに書くだけにして、送信は固定のスクリプトやAction側に移す。これだけでAIが誤った宛先に出す経路が消える。次の段階は、同じ考え方を客先データの扱いに当てること。図面やラダー、アラームログをAIに渡す作業を、「AIが読めるフォルダ」と「社外に出る経路」を別々に管理する形に分け、AIが動く側からは外部送信の口を持たせない。もう一段進めるなら、記事と同じくAIを動かすコンテナと、通信を許可するコンテナを分ける構成を自分の検証環境で試す。iptablesでデフォルト拒否にして必要な宛先だけを開ける形は、客先のネットワーク分離の設計と考え方が同じなので、FA側の説明にもそのまま使える。コストは、権限を外す整理は無料。コンテナ構成の検証も手持ちのPCとDockerで無料。LLM利用料は記事の実測（PRレビュー1回$0.01〜$0.1、週次の全体テストで$3.02）が目安になるが、これはオープンウェイトモデルを低コストで使った場合の数字なので、同じ構成を商用APIで組めば桁が変わる。注意点として、記事の著者はペネトレーションテストの対象をrunner内に立ち上げた自分たちのアプリに限り、外部のサービスには一切リクエストを送らない構成にしている。この境界を外した検証は、客先設備が相手なら絶対にやらないこと。試すなら自分の検証環境だけに閉じる。

自分の使い方に当てると、効くのは「読み取りは広く許可されている」という一点。最初の一歩は、コーディングエージェントを起動しているPCのホームディレクトリに何が置いてあるかを自分の目で確認すること。客先からもらった図面やパラメータファイル、VPNの設定、過去案件のラダーのバックアップ——作業フォルダをプロジェクトに絞っていても、これらは読める範囲に入っている可能性がある。次の段階は、置き場所を分けること。客先の機密を含むフォルダを、エージェントを動かすユーザーから読めない場所（別ユーザー、別ボリューム、あるいは普段はマウントしない外付け）に移す。これは30分で終わり、設定ファイルをいじるより確実に効く。もう一段進めるなら、他人のリポジトリやサンプルを手元で動かすときの手順を決めておく。クローンしたら最初に.codex/config.tomlや同等の設定ファイルを開き、sandbox_modeやapproval_policyに緩い値が入っていないかを見てからTrustする、という1行の手順書で足りる。コストはすべて無料で、必要なのは自分の運用を1回棚卸しする時間だけ。注意点は3つ。ひとつは、承認を自動化するAuto-reviewは判断を別のAIに移すだけで、Sandboxの制限を外す機能ではないという区別を混ぜないこと。ふたつめは、記事が挙げているのはCodexの仕組みなので、他のエージェントの保護対象や既定値がこれと同じとは限らない点。使っているツールごとに確認する。みっつめは、承認ポリシーをneverにしてもSandboxの制限は残るとされているが、それは「何も起きない」という意味ではないので、客先データを扱うセッションでは承認を求める設定のまま使うこと。