シン｜AI×エンジニア

綺麗な文章なんて、一言も書けません。 現場5年のしがないPLC技術者。 副業未経験から1ヶ月。 AIに頭のモヤモヤを投げ込んで、デバッグを繰り返した結果、会社以外で「10万円」につながりました。 特別な才能や実績があったわけではありません。 やったのは、現場で培った「トラブルシュート思考」をAIに移植し、自分の泥臭い経験を足したことだけ。 月20万の安定した余白を作って、大切な人と値段を見ずに旅行を楽しむ。 これは、その目標に向けた不器用なエンジニアの泥臭い全記録です。 👇

PLCはRUN。通信リンクもUP。画面も動いている。 それでもセンサ値だけ古い、軸応答だけ遅い、上位履歴だけ抜ける。機能が一つのコントローラへ集約されるほど、こういう「一部だけ止まる」が見えにくくなります。 ルネサスはモータ制御・産業Ethernet・Linux処理を統合したRZ/T2Nを発表。ELCOはPLC、IO-Link、モーション、Web HMIなどをIP67機器へ集約。Beckhoffも一つのPC制御基盤でモーション、安全、画像、計測まで扱います。 PLC側で欲しいのはRUNビット一つではなく、MotionTask_Alive、TaskOverrunCnt、FieldDataAge、HMI_Heartbeat、OPCUA_LastUpdateのような機能別状態です。 例えばIO-Link温度が正常範囲でも、最終更新から3秒経過していれば工程条件に使わない。Web HMIだけ停止なら制御を継続できる場合がある。反対にモーション周期超過やEtherCAT更新異常なら、画面が動いていても停止側へ入れる。 復帰も同じです。HMIサービス再起動、通信再接続、該当工程の再初期化、全軸原点復帰を一括にしない。 統合制御で本当に必要なのは、何でも一台で動かすことではなく、一部が崩れたときに「どこまで止め、何を保持し、どこから戻すか」を機能単位で決めておくことです。

非常停止も安全扉も正常。 ロボットも手動では動く。 なのに自動起動だけ通らない。 こういう時、PLC側には「ロボット準備未完了」しか返ってこないことがある。外部起動を再送しても、同じタイムアウトを繰り返す。 川崎重工が11月に発売したFシリーズコントローラ S-typeは、ユーザー認証、権限管理、セッション管理、操作ログ、ファイルの完全性確認などを備える。安全条件とは別に、セキュリティ上の理由で動作を受け付けない場面が増えるということでもある。 例えば保全後の自動起動なら、確認するのは四つ。 ログイン中のユーザー権限。 セッションの有効期限。 実行プログラムの番号と承認状態。 セキュリティログに残った拒否理由。 PLCが「Ready OFF」だけを見ていると、権限不足もファイル不一致も安全インターロック不成立に見える。そこで非常停止回路やPROFIsafeを調べても、原因には届かない。 逆に、安全成立、運転モード成立、プログラム成立、起動受付可能を分けて残せれば、次に見る場所が決まる。起動要求時の品種番号とプログラム番号も残っていれば、権限の問題か、段取り替え後の選択違いかまで判断できる。 セキュリティ機能を増やすほど、拒否理由は制御状態として見えるようにしたい。 止める機能だけ強くしても、理由が分からなければ現場は管理者権限で逃げてしまう。復旧時間と安易な権限昇格を減らすのは、「動かない」を細かく分ける設計だと思う。

コードリーダで番号が読めた瞬間に、そのワークの識別が完了した扱いにする。現場ではよくある実装ですが、搬送停止や再読取が入ると急に怪しくなります。 SPS 2026に向け、LeuzeのDCR 300i、Datalogicの読取・マーキング製品群、Balluffの複数カメラ構成が発表されています。読取能力は上がっていますが、PLCが受け取るのはあくまで「認識結果」です。 気になるのは、その結果が今いるワークのものか。Read_OKだけで進めず、読取要求ごとにRequestIDを発行し、WorkID、RecipeID、在席位置、結果有効期限を一組で持たせたい。 例えば読取後にコンベヤが停止し、同じワークを再読取した場合。最初のIDを保持するのか、再読取で更新するのか。加工開始後に上位レシピが変わった場合は、現在ワークへ反映せず次ワークから切り替える。マーキング途中で停止した場合は、自動再実行せず「結果不明」として隔離する。 複数カメラなら、全結果が同じInspectionIDかも確認する。一台だけ未応答なら品質NGではなく、検査未成立として扱う。 「読めた」「加工指令を出した」「完了信号が来た」を別々に管理しても、WorkIDで結ばれていなければ追跡にはなりません。トレーサビリティの強さは、履歴の量ではなく、間違った組合せをPLCが成立させないことに出ます。

センサのLEDは点灯している。 でも、PLCの入力はずっとOFF。 こういう時、検出距離を何度調整しても直らないことがあります。 バルーフは近接センサ「BES Entry Line」にNPN仕様を追加しました。NPNもPNPも昔からある方式ですが、交換や海外仕様の流用では、この違いがそのまま入力不成立につながります。 例えば見るのは四つ。 センサがPNPかNPNか。 入力ユニットのコモン電位。 検出時の入力端子電圧。 出力から入力まで電流が流れる経路。 LEDが点灯しても、PLC入力回路へ電流が流れた証明にはなりません。PNPセンサにNPN前提の入力配線を組み合わせれば、センサ内部は検出していても入力は変わらない。ここで入力タイマを延ばしても、待つ時間が増えるだけです。 逆に、LEDと端子電圧が両方変わるのにPLCだけOFFなら、入力コモン、点番号、ユニット設定へ進める。端子電圧も変わらなければ、出力方式、配線、コネクタを先に疑える。 センサLEDは「対象を見つけた」の確認。 PLC入力成立は「正しい電流経路ができた」という別の確認です。この二つを分けるだけで、立上げ時の無駄な位置調整をかなり減らせると思います。

現地立上げでタイマを変更し、インターロックを1点追加。設備が動いたので「修正完了」。でも、その変更が担当者のPCやPLC本体にしか残っていないことがある。 ctrlX OSのGit統合や、テキストファイルで管理するCODESYS 4の登場で、PLCも差分と版数を追いやすくなってきた。 ただし正式版に戻すのはプログラムだけではない。I/O構成、IP・局番、機器パラメータ、HMI、レシピ、保持値の変換条件まで同じリリース番号へひも付ける。 現地変更前にPLCから吸い上げ、基準版と比較する。変更後は出力重複、SET解除、タイマリセットを確認し、途中停止、通信断、電源再投入、品種切替を試す。 運転途中でステップ条件を変えたなら、現在ステップが新ロジックでも成立するかを見る。矛盾するなら、その場で継続せずワーク排出か原点確認から復帰する。 設備が直った瞬間は、まだ仮修正。差分を吸い上げ、試験し、版数を確定し、別のPCから同じ状態を復元できて初めて正式な修正になる。PLCの版管理はバックアップ作業ではなく、次回立上げを壊さないための制御設計だと思う。

バッテリー残量は十分。 でも、AMRが昇降を始めた瞬間だけ止まる。 こういう時は、停止後の電圧を見ても原因が残っていません。 シーメンスは24V／48Vバッテリーへ直接つなぐAMR向け駆動系を発表しました。走行、操舵、昇降を同じ低電圧系で動かすほど、動作が重なった瞬間の電圧降下が効いてきます。 例えば残すのは四つ。 DCリンクの最低電圧。 全軸のピーク電流。 その時に動いていた軸。 低電圧・電流制限の発生状態。 停止後は負荷電流が下がり、電圧も戻る。現在値だけなら「残量70％、電圧正常、走行軸異常」に見えて、モータや通信を先に疑ってしまいます。 逆に、走行加速と昇降開始が重なった時だけ最低電圧が落ちていれば、電池の内部抵抗、給電コネクタ、配線降下へ進める。特定軸の電流だけ増えていれば、その軸の機械負荷やブレーキ解除を疑える。電圧低下前に警告域へ入ったことが分かれば、昇降開始を保留し、急停止になる前に動作を分ける判断もできます。 AMRの電源異常で残したいのは停止後の正常値ではなく、負荷が重なった瞬間の最低値。 残量率より最低電圧と軸の組合せを残す方が、再現待ちと部品の当て交換を減らせると思います。

安全I/Oや高速カウンタの処理を機械側へ置く製品が増えている。危険検知や高速トリガをPLCスキャン待ちにせず、その場で処理できるのは大きい。 ただ、局所で止められることと、局所だけで再起動してよいことは別。 例えば搬送ユニットのドアが開き、安全I/Oが出力を遮断した。ドアを閉めれば安全入力は戻る。でも途中ワークが中間位置で、上流には次ワークが待っているかもしれない。ここで安全入力の復帰だけを見て自動再開すると、干渉や二重搬送が起きる。 停止時はPLCへ、原因、工程番号、ワーク有無、軸位置、直前指令を残す。復帰時は危険源なし、機構停止、途中ワーク確定、安全通信・通常通信正常を照合する。 リセットは入力正常の立上がりで自動生成しない。作業者のリセットと自動運転再開も分ける。通信断なら局所停止を保持し、PLCが状態を再取得できるまで再起動させない。 処理を分散するほど、中央PLCの仕事が減るわけではない。速い停止は現場側へ任せ、原因管理と再起動条件は設備全体で持つ。これが、分散制御を立上げやすく、無効化されにくい安全設計にする境界だと思う。

ハンドの「閉端」がONしている。 でも、ワークをつかんでいない。 こういう時は、エア圧より先に閉端の意味を確認したい。 CKDは、薄さ8mm・質量11gでシリンダスイッチも搭載できる超小形平行ハンドを展開しています。小さいハンドでも、閉側スイッチをそのまま把持完了にすると誤判定は残ります。 例えば外径把持で見るのは四つ。 ワークなしの全閉位置。 正常ワークをつかんだ位置。 把持時の供給圧力。 持ち上げ後のワーク有無。 閉側スイッチを全閉位置に合わせると、空振りした時ほど確実にONする。一方、正常にワークをつかむと爪は途中で止まるため、実際には把持できていても閉端タイムアウトになることがあります。ここで監視時間だけ延ばしても、判定位置は直りません。 逆に正常把持位置を寸法公差込みで決め、圧力と持上げ後のワーク有無まで確認すれば、空振り、厚み違い、斜め把持、圧力不足を分けられる。途中停止後も、閉信号が残っているだけで搬送を続けず、ワーク有無を再確認できます。 シリンダスイッチが確認しているのは爪の位置。 把持完了は「正しい位置で止まり、保持できた」という別の工程条件として作る。この分け方が、たまに起きる取り損ねの切り分けに効くと思います。

産業用PCやHMIを交換したあと、画面が表示されてPLCの現在値も見えた。ここで「復旧完了」として自動運転を押したくなる。 ファナックの新i PCや、既存画面資産を継承するオムロンNS-Bのように、更新しやすい製品は確実に増えている。ただ、交換しやすさと、自動復帰の成立条件は別の話。 PLC側で見たいのは、単なる通信正常ではない。OS起動、アプリ起動、PLC接続、レシピID・版数一致、保持値復元、時刻同期、操作権限確認を分け、全部そろって初めてAutoReadyにする。 例えばレシピ転送の途中でLANが抜けたら、旧値と新値が混在した領域を採用しない。再接続後も直前の起動指令を再送させず、指令OFFを確認してから新しいONを受け付ける。 HMIだけ再起動した場合は、画面の工程番号ではなく、PLCが持つ実ステップ、ワーク有無、軸位置を正とする。照合できなければ限定モードへ落とし、自動起動は禁止する。 更新後の立上げで確認すべきなのは、画面が映るかではない。「どの条件が戻れば、装置を再び動かしてよいか」である。交換性の高い機器ほど、復帰条件をPLC側に明文化しておく価値が上がる。

コードリーダは「読取OK」。 でも、違う品種のレシピで装置が動き始める。 こういう時は、読取精度より前回値の残り方を見たい。 SICKの新しいコードリーダは、1D・2Dコードを画像で読み取り、EthernetやUSBで設備へ組み込める。ただ、PLCが読取OKだけで工程を進めると、今回のワークを確認したとは限りません。 例えば見るのは四つ。 今回の読取要求番号。 返ってきたコード文字列。 期待する品種との一致。 その結果を使用済みにしたか。 新しいワークが来ても前回の結果有効を落としていなければ、今回の読取りが失敗しても古いコードで品種切替が成立する。読取OKは残り、文字列も前回値。この情報だけでは「読み取れた」のか「前回値を見ている」のか分かりません。 逆に、ワーク到着で前回結果を無効化し、今回の受付時間内に届いた文字列だけを期待値と比較すれば、読取不能、異品種、応答更新なしを分けられる。ワーク搬出時に結果を使用済みにすれば、途中停止からの復帰でも次ワークへ持ち越しにくい。 コード読取で確認したいのは、文字が読めたことではなく、今回の要求に対して正しいワークを確認したこと。 この一段をPLCで持つと、再現しにくい品種違いの切り分けがかなり変わると思う。

PLC専用AIが、停止原因の解析、ラダー生成、既存プログラムの要約まで行う製品が具体化してきた。 便利なのは間違いない。初めて見る装置で「この出力は何条件か」「正常時と異常時でどのI/Oが違うか」を探す時間はかなり減りそう。 ただ、AIが作ったラダーを既存セクションへそのまま入れるのは怖い。例えば「原点復帰後に指定位置へ移動」と指示しても、扉閉、相手機構退避、ワーク保持、サーボREADY、途中停止からの再開条件まで、文章に書かなければ抜ける可能性がある。 生成回路はまず別領域へ置く。出力コイル重複、SET解除、タイマリセット、通信タイムアウト、品種切替時のデータクリアを確認する。 試験も正常動作だけでは足りない。移動中にREADYが落ちた、Busy中に通信断、異常リセット時に軸が中間位置、レシピ変更中に始動要求。この時に出力がどうなり、どこから復帰するかまで試す。 AIで速く作れるほど、確認せず現場へ入る速度も上がる。これから重要になるのはラダーを書く速さより、AIの変更を止め、比べ、試し、人が承認するレビュー設計だと思う。

異常は記録できているのに、AIが示す候補が毎回「結果」に見える。 こういう時は、解析性能より先に記録を始める場所を疑いたい。 キーエンスがPLC専用AI「KV Intelligence」を発表した。ドライブレコーダの履歴から正常時との差を比較できる。ただ、最終アラームをトリガにすると、原因信号はすでに消えていることがある。 例えば、シリンダ前進タイムアウト。 見るのは、前進指令、後退端、ワーク有無、前進端の四つ。記録はタイムアウト発生時からではなく、その数秒前を含める。比較する正常サイクルも、同じ品種・同じ運転モードにそろえる。 タイムアウト後だけを見ると、前進出力OFF、インターロック解除、異常処理開始という「止めた結果」ばかりが残る。これではセンサ、空圧、機械抵抗、PLC条件のどこから疑うか決めにくい。 逆に、指令より先に後退端が抜けた、指令後も後退端が残った、前進端が一瞬入って消えた、と分かれば、次に見る場所が変わる。リトライ前の状態を残せれば、再現待ちもしなくて済む。 AIデバッグで先に設計したいのは質問文ではなく、原因が残っている記録窓。異常を記録するだけでなく、切り分けに使える時系列を渡せるかが、デバッグ時間に効いてくると思う。

センサや測定機から数値が入った瞬間、その値を判定に使っていないだろうか。 JIMTOF 2026では、着座確認の数値出力、オンマシン計測、加工から測定までの自動化が目立った。測れる項目が増えるほど、PLC側で重要になるのは数値処理より「いつの、何の値か」を成立させる条件設計だと思う。 例えば着座量が返ってきても、ワークID一致、品種レシピ確定、クランプ完了、ロボット退避、圧力安定、センサReadyがそろう前なら、その値はまだ判定材料ではない。 測定途中でクランプが外れたら値を破棄。通信が復旧しても旧値を再利用しない。品種が変わったら測定済みフラグを落とす。DataValidだけでなくRequestIDとResultIDを照合し、安定確認後の値だけをラッチする。 さらに寸法NGと、姿勢不良・校正期限切れ・測定タイムアウトによる「判定不能」は別状態にする。ここを一つのNGビットへまとめると、原因も復帰手順も分からなくなる。 数値が見える設備より、「その数値を使ってよい理由」がPLC上で追える設備の方が強い。計測の自動化は、センサをつなぐ仕事ではなく、測定有効窓を作る仕事だ。

安全停止を入れたのに、コンベヤがしばらく動き続ける。 インバータの故障とは限りません。 安川電機は、CIP Safety経由でSTOとSS1-tを使えるインバータ用オプションを発売しました。ここで注意したいのは、SS1-tが「停止を確認してからSTO」ではなく、設定時間で減速した後にSTOへ移る時間監視方式だということです。 例えば見るのは四つ。 安全要求を受信した時刻。 減速を開始した時刻。 最大負荷時に実際に止まった時刻。 STOへ移行した時刻。 空荷では2秒で止まっても、最大積載では3.5秒かかる。SS1-tを2秒にすると、停止途中でトルクが切れ、残りは惰走になる可能性があります。逆に長すぎれば、扉を開けてから危険源が動力を持つ時間が延びる。 ここまで分かれば、通信異常や安全入力より先に、減速時間、負荷条件、回生能力、安全距離を見直せる。 SS1-tは停止指令の1ビットではなく、「減速開始からSTOまで」の時間設計です。最も止まりにくい条件で実停止時間を測ることが、安全停止のデバッグに効くと思います。

OT監視で不審な通信を検知した。だから非常停止を入れる。 一見安全そうですが、動作中のロボット、ワークを保持したクランプ、熱処理中の炉を無条件に落とすと、別の危険を作ることがあります。逆に「生産優先」で警告だけにすれば、設定変更や異常指令を見逃します。 最近は、OT／IT統合監視、産業機器内での脅威検知、セキュリティ機能内蔵コントローラが具体化しています。PLC側で必要なのは、セキュリティ異常を一つの停止入力にまとめないことです。 状態は「検知→対象機器特定→変更内容保存→遠隔書込み遮断→生産影響判定→安全影響判定→復旧承認」と分けたい。 未知の読出し通信なら監視強化。不正ログインなら遠隔接続を遮断してローカル運転。レシピやタイマの版が違えば次サイクル禁止。動作中の異常指令なら制御停止。安全プログラムへの影響が疑われるなら安全停止を維持する。 復旧も、ネットワークが戻っただけでは不十分です。PLCプロジェクト、レシピ、強制状態、軸位置、ワーク所在を確認し、必要なら安全低速、空運転を経て自動へ戻す。 安全停止は危険源への対処。セキュリティ隔離は侵入経路への対処。二つを混ぜず、止め方と戻し方を機能ごとに決めることが、止めすぎず守れるOTセキュリティです。

炉内温度は180℃で安定している。 でも、その180℃が数分前から更新されていない。 こういう状態が一番見落としやすい。 オプテックス・エフエーは、接触式・非接触式の温度をIO-Linkへ集約する構成を公開しました。多点温度をPLCへ取り込めても、温度値だけで滞留時間を進めると、通信停止や入力異常時の最終値を正常温度として使う可能性があります。 例えば炉内保持時間を見るなら、確認するのは四つ。 現在温度が上下限内か。 入力データが有効か。 最終更新から何秒経ったか。 範囲内が連続して何分続いたか。 180.2℃のまま値が固まると、上下限比較だけでは正常です。そのまま保持タイマを進めれば、実際の炉温が下がっていても加熱完了になる。 逆にデータ無効や更新タイムアウトでタイマを止めれば、温度範囲外と計測異常を分けられる。復旧後も、品質条件が「合計60分」なら積算再開、「連続60分」ならリセットと判断できます。 温度管理は、値が範囲内かだけでは成立しない。 その値が有効で、今も更新され、必要時間連続したことまで確認する。この条件分けが、後から追えない加熱不足を防ぐと思います。

Claude Codeとの会話が長くなりすぎて、そろそろ限界になりました。 新しい会話に移る前に、AI自身に引継ぎ書を書かせました。 
どこまで終わったか。何を決めたか。やってはいけないことは何か。 交代勤務の申し送りと同じです。 
ここが雑だと、次の人が事故ります。次の人がAIでも同じでした。

制御盤からI/Oを出す。バルブマニホールドも装置近くへ置く。配線は短くなり、盤も小さくできる。 でも、盤内で管理していた仕事が消えるわけではない。NPN／PNP、入出力方向、局番、設定版、24V、安全側出力、結露対策が、各ポートと各フィールド機器へ移る。 最近は、NPN・PNPをポートごとに変更できるI/Oハブ、EtherCAT／EtherNet/IP対応の盤外バルブ、筐体用の高通気ベントが具体化している。盤外化の自由度は確実に上がっている。 PLCでは「物理接続済み」「通信成立」「設定一致」「自動運転許可」を分けたい。M12が刺さりノードが見えても、入力予定ポートが出力設定なら動かしてはいけない。交換品なら機器IDと設定版を照合し、安全側出力から空運転する。 通信断時も一律OFFでは決められない。クランプや垂直保持はOFFが危険な場合がある。逆に出力保持したまま再接続すると、設備が途中状態から突然動く。機構ごとに保持、OFF、制御停止、安全排気を決め、復帰時はシリンダ端とワーク状態を再確認する。 さらに盤外ボックスは、IP表記だけで安心しない。コネクタ開放、パッキン劣化、温度変化による結露まで見る。朝一だけ通信が落ちるなら、プログラムより先に筐体内を確認する場面もある。 盤外化は条件設計の削減ではない。設定・環境・復旧条件をポート単位で管理できて、初めて配線削減が設備の強さに変わる。

表示器を交換したあと、画面の設定値は変わっている。 でも機械は前の条件で動いている。 こういう不一致は、画面確認だけでは見つけにくい。 オムロンが既存NS資産を活用できるNS-Bシリーズを公開した。表示器更新の手間を抑えられるのは大きい。ただ、移行完了の基準は「画面が同じように動く」では足りない。 例えば、品種切替画面から加熱時間を変更する。 確認したいのは、HMIが書いた要求値、PLCが採用した実行値、要求レシピ番号、受付完了の4つ。 画面が要求値をそのまま読み返しているだけだと、PLCが運転中変更を拒否していても「変更できた」ように見える。通信が途中で切れ、レシピの一部だけ書き換わった場合も判断できない。 逆にPLC側で、要求番号を受信し、範囲と運転状態を確認し、全項目を一括反映してから受付完了を返せば、画面表示と実際の運転条件を分けて追える。拒否時も「範囲外」「運転中」「レシピ不一致」まで分かれば、通信や表示器を疑う前に条件を直せる。 表示器更新は、入力した値が表示された時点では終わらない。 PLCが採用した値と受付結果まで一致して、初めて書込み成立と判断できる。この差を試験項目に入れておくと、更新後の「設定したはず」を減らせると思う。

アラーム復旧後、保全履歴には「センサ交換、運転確認OK」。ところが翌週また同じ停止。前回の回転数、工具、品種、負荷、交換前の測定値、交換後の再測定値が残っていないため、比較できずに最初から調べ直す。現場ではよくある話です。 主軸近傍のセンサ、携帯型エア漏れ検出器、保全クラウド。最近の発表を並べると、測れる場所と記録手段は確実に増えています。ただ、値と作業メモを別々に保存しただけでは、保全は速くなりません。 PLC側で必要なのは、異常発生時に案件IDを発行し、設備ID、運転モード、ステップ、品種、工具、回転数、負荷、出力指令、待ち入力、タイマ経過値をまとめて保存すること。センサ値には有効フラグと更新時刻も付けます。 例えば、暖機中の振動値と本加工中の値はそのまま比較できない。エア漏れも供給圧力が違えば処置前後の判定にならない。部品を交換しても、同じ条件で再測定して基準内へ戻るまでは「修理済み」でも「復旧確認済み」ではありません。 停止も一律にしない。傾向監視だけ、次サイクル禁止、計画停止、制御停止、安全停止をリスクと影響で使い分ける。止めすぎて監視を無効化される設計も、止めずに故障を育てる設計も避けたい。 保全DXの本質は報告書を電子化することではない。故障時と復旧時を同じ条件で比較できる証拠を残し、次の切り分けを一段速くすることです。