2026年10月14日

「PLCは決められた動作を速く正確に、IPCは膨大なデータを集めて分析判断」という役割分担の整理は、今の設計レビューでそのまま使える。最初の一歩として、自分が担当した直近1案件の仕様書を開き、要求を「msオーダーで確定実行が要る＝PLC側」「データを溜めて後から判断したい＝PC側」の2列に手で振り分けてみる。紙とExcelだけで30分、コストはゼロ。次の段階は、PC側に振り分けた要求のうち「工程終了後の分析でも間に合うもの」と「作りながら直したいもの」を分けること。後者が出てきた案件が、将来IPC併設やエッジ処理を提案できる候補になる。客先に出す資料では「脊髄と大脳」の比喩がそのまま通じるので、盤の構成図に「制御（確定実行）」「解析（判断）」のラベルを足すだけで説明が早くなる。注意点は、国内の既設設備にこの構成をそのまま持ち込むとIPC分のコストと管理対象（OS更新・ウイルス対策・バックアップ）が増えること。まずは既存PLCのデータ収集点（アナログ値・サイクルタイム・警報履歴）を洗い出して、「本当に高速に処理したいデータが現場にあるか」を確認してから機器を増やす順番にしたい。なおこの買収は株式取得が2027年1月予定で、PLC一体型の新製品は2030年度までの目標なので、明日の案件で使える話ではなく「提案の筋書き」として仕込む段階と割り切るのが現実的だ。

明日できる一歩は、いま手元にある作画データを1画面だけコピーして、背景色をR31・G34・B38に変え、数値の文字サイズを他より2段階大きくする——この2操作だけ。〔編集〕→〔画面属性設定〕（Ctrl＋M）で背景、テキスト部品の〔プロパティ〕でサイズを触るだけなので15分で終わり、ツール費用はゼロ。次の段階は、自社の標準色の意味を1枚の紙に決めてしまうこと。緑＝運転、黄＝注意・リセット、赤＝異常と停止の3行を決めて共有ファイルに置けば、担当者が変わっても画面の見え方が揃う。筆者が挙げている「赤がリセットにも停止にも使われていた」状態は、実際に客先で誤操作クレームになりやすい部分なので、既存機の色の意味が混ざっていないかを棚卸しする価値がある。コスト感としては標準部品の設定だけなら工数のみ、自作画像に進むとボタン3枚×個数の画像作成工数が乗る（記事はSVGで描いてPNGに書き出している）。注意点は上限と保守性で、イメージ数と容量の上限があるうえ、地の色を変えると角を塗った画像を作り直すことになる。だから自作画像は運転・停止・リセットのような主役ボタンに限定し、数値やラベルは標準部品の設定で整えるという線引きを、見積段階で決めておくのが安全だ。既存案件の改造見積に「画面デザイン整え一式」を数時間分だけ載せておくと、次の立ち上げで現場の問い合わせが減る。

制御設計の周辺にも同じ形の仕事がある。装置ごとに分かれたI/Oリスト、現場ごとのパラメータ台帳、月次の不具合記録——どれも「バラバラのファイルを1つにまとめて集計」そのものだ。最初の一歩は、過去3カ月の不具合報告ファイルを1フォルダに集め、Power Queryの「フォルダーから」→「結合および変換」を押すだけ。Excel 2016以降なら追加費用ゼロ、マクロ禁止の客先PCでも使える。次の段階は表記ゆれの正規化で、装置名や部品名が「ｼﾘﾝﾀﾞ」「シリンダ」「シリンダー」に散っているところを「値の置換」で寄せ、比較キー列を1本作る。ここまで作れば、月別×装置別の不具合件数が自動で出るので、客先への改善提案に数字を付けられる。共有や定期実行まで欲しくなったらGAS側へ移す判断で、記事のmergeSales／dedupe／summarizeの3関数構成をそのまま骨格に使える（トリガーで毎朝実行）。注意点は記事も挙げている「重複の定義」で、同じ日・同じ装置・同じ現象が本当に重複なのか、別号機の同時発生なのかは業務側でしか決められない。機械的に消さず、重複候補を一覧にして自分の目で確認する手順を必ず挟むこと。もう1点、日付が文字列で入っているファイルはそのままだと月で集計できないので、データ型を日付に直す工程を最初に固定しておくと後戻りが減る。

影響範囲はアプリを「作って配る」側のツールなので、現場のEdge機器そのものの更新作業より先に、自分や協力会社の開発PCを確認するのが順番として正しい。最初の一歩は、App Publisher を入れている端末の棚卸しを15分で作ること（誰のPCに入っているか、バージョンは何か）。設計者のノートPCや検証用の仮想マシン、客先貸与PCまで含めて洗い出すのがポイントで、こういうツールは1人が入れたまま忘れられやすい。次の段階がV1.27.9以降への更新で、アドバイザリ記載のダウンロード先から取得する。費用はライセンス次第だがアドバイザリ上の対策は更新のみ。合わせて、このチェーンの入口が「管理サーバーへの通信をなりすまされること」である点から、App Publisher を使う作業を社外Wi-Fiや客先の共用ネットワークで行わない運用ルールを1行決めておくと効く。注意点は適用範囲を広げすぎないこと。今回のアドバイザリが対象にしているのは App Publisher であって、稼働中のEdgeデバイスやアプリ全体の一律更新を求めるものではない。現場に対しては「配布ツール側の更新が要る」と正確に伝え、設備停止を伴う更新と混同させないほうが調整が早い。最後に、客先から「ウチのEdgeは大丈夫か」と聞かれたときに備えて、SSA番号（SSA-968435）とCVE番号をそのまま引用できるメモを残しておくと、報告書作成が数十分短縮できる。

他社PLCの現場に呼ばれたときに一番つらいのは「ファイルは預かったのに開けない」状態で、この記事のやり方はその空振りを出張前に潰せる。最初の一歩は、手元に預かっているACDのコピーを1つ作り、テキストエディタで開いて「Saved - V」を検索するだけ。ツールはメモ帳で足り、実機接続も不要なので5分で終わる。次の段階は、読み取れたバージョンを前提にPCDCで対応するLogix Designerを探し、出張の前日までにインストールと起動確認まで済ませること。インストールとアクティベーションは時間がかかるので、現地の朝にやる作業に入れないのが肝心だ。あわせて、記事が区別している3つ——ACD内の保存履歴バージョン、プロジェクトのController Revision、実機のFirmware Revision——を自分の出張チェックリストに3行で書き写しておくと、客先への質問が具体的になる（「対象PLCの型式とファーム版数を事前に教えてください」と1通メールを出すだけで現地の手戻りが減る）。コストは実質ゼロだが、ライセンス・利用権限がないとダウンロードできない点は事前に社内の調達担当へ確認が要る。注意点は、保存履歴の版数だけで実機の状態を決めつけないこと。手元のACDが古ければ実機側が更新されている可能性があるので、現地ではまずUpload（PLC→PC）で現行プログラムを取ってバックアップを保存してから着手する。Download（PC→PLC）と混同すると既設設備へ古いプログラムを書き込む事故になるので、作業指示書の動詞を「Upload」と明記しておきたい。

移管・移設案件の立ち上げに入る前に、この投稿が挙げる記録項目をそのままチェックシートにするのが早い。最初の一歩は、設備ID／レシピ版数／計測器の校正ID／設定値と実測値／試作ロット／品質状態の6項目を1枚のExcelに列として並べ、直近の案件で埋められるか試すこと。埋まらない列が、いまのデータロギング設計の穴だ。次の段階は、埋まらなかった項目をPLC側に足すこと。設備IDとレシピ版数はD/Wレジスタに定数で持たせてログに乗せるだけなので工数は小さく、校正IDは文字列デバイスか帳票側の手入力で十分間に合う。コスト感としては、既設のロギング機能（PLCのメモリカードやSCADAのヒストリ）に項目を追加するだけなら設計工数のみで、外部システムの追加は不要。そのうえで運用側に効かせたいのが「初回品は品質保留、承認後に量産許可」と「途中で変えたら確認工程へ戻す」の2行で、これはプログラムではなく手順書に書く話なので客先の品証と合意しておく必要がある。注意点は、タイマ変更やセンサ交換の履歴が残らない現場では、この運用が宣言だけで終わること。変更履歴をPLCのイベントログか作業記録に必ず残す仕組み（変更時に日時と担当者を押させるだけでもよい）を先に作ってから、許可の取り消しルールを導入したい。移設前の旧工場で蒸気圧・流量・原料温度の実測値を数日分取っておくと、新工場で結果が違ったときの比較材料になる——これは移設が決まった時点でしか取れないデータなので、案件初期に提案する価値が高い。

自分の使い方に引き戻すと、効くのは「エージェントがWebやコードを読むときに悪意ある指示を踏む」という前提の置き方だ。最初の一歩は、自分がAIに読ませている外部データの棚卸し。メーカーのPDF仕様書、客先から届いたExcel、ネットで拾ったサンプルコード——ここに指示が埋め込まれていても気づけない前提で、AIに「ファイルを操作させる」作業と「読んで要約させる」作業を分けてしまう。無料でできる運用の切り分けなので今日から適用できる。次の段階は、記事が挙げている「境界で止まったときに頑張りすぎる」挙動への備え。自分の手元でエージェントを走らせるときは、権限を与えるフォルダを案件ディレクトリ1つに限定し、削除や上書きの前に確認を要求する設定にしておく。コストはゼロだが、設定を一度作る手間が要る。さらに進めるなら、監査ログの残し方まで決めておく。ベンダー側はスクラッチパッドを読む監視を作っているが、自分の環境でそれに相当するのは「AIが何を実行したかの記録」なので、コマンド履歴や差分が後から追える置き方にしておきたい。注意点は、この記事の数値はいずれもベンダー自身の評価であり、攻撃成功率0.7%という値は特定のベンチマーク（Gray SwanのIPI、15回の適応的試行）での結果だということ。「0.7%だから踏んでも大丈夫」ではなく、「頻度は下がったが起きるときは起きる」として、機密ファイルや客先データを含むフォルダには最初からアクセスさせない設計のほうが安い。最後に、業務で使うなら「否定的な結果を正直に報告させる」姿勢は人間側にも必要で、AIが「できません」と言ったときにそれを押し返すか受け入れるかの判断は自分の責任に残る。

ここで真似する価値があるのは成果ではなく手順——「読めないコードを、まず読める形にしてからテストする」という順番だ。制御設計でも、他人が書いた長大なラダーやST、引き継ぎ資料のないマクロを押し付けられる場面は多い。最初の一歩は、客先から預かったSTやスクリプトの一部をAIに貼って、処理の塊ごとにコメントを付けさせ、長い処理を意味のある単位に分けた説明を出させること。ChatGPTやGeminiの無料枠で今日試せる（客先コードの扱いは後述の注意を守る前提で）。次の段階は、記事と同じようにテスト側を作ること。PLCならシミュレータ上で入力パターンを並べた確認表をAIに作らせ、境界値（上限・下限・ゼロ・異常値）を網羅させる。実機を触らずに空振りを洗えるので、立ち会い時間を削れる。コスト感としては無料枠〜月数千円のAPI利用で収まり、設備投資は不要。注意点が2つ。1つは守秘で、客先のプログラムやレシピをそのまま外部サービスへ貼るのは契約違反になり得るので、変数名を伏せた抜粋にするか、社内で許可されたツールに限る運用を先に決めること。もう1つは責任の置き場で、記事が描いているのもLLMに「答え」を出させた話ではなく、人が読み、テストを回し、判断している構図だ。AIが出した修正案をそのまま設備へ書き込まず、シミュレータと試運転で確かめてから適用する——この順番を崩さない限り、使う価値のほうが大きい。