シン｜AI×エンジニア

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

センサや測定機から数値が入った瞬間、その値を判定に使っていないだろうか。 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の本質は報告書を電子化することではない。故障時と復旧時を同じ条件で比較できる証拠を残し、次の切り分けを一段速くすることです。

吸着OKは入っているのに、持ち上げた瞬間にワークがずれる。 袋やシュリンク包装品では、こういう止まり方がやっかいです。 停止中は真空圧力が閾値へ達している。でも上昇すると袋が変形し、しわから漏れて保持力が落ちる。 SMCは、凹凸へ追従するスポンジ式真空グリッパ「ZGS-X7」を公開しました。形状追従性が上がっても、PLCの吸着成立を圧力スイッチ1点だけで決めると、搬送中の余裕までは分かりません。 例えば見るのは四つです。 設定圧への到達時間。 到達時の真空圧力。 短距離リフト後の圧力低下。 対象ワークID。 設定圧まで遅いなら、供給圧力や吸着位置を疑える。到達後、持ち上げた瞬間だけ圧力が落ちるなら、袋のしわ、スポンジ摩耗、荷姿変化が候補です。逆にリフト後も圧力を保てるなら、そこで初めて本搬送へ進めます。 吸着OKだけでは、停止中に一瞬届いたのか、搬送中も保持できるのか分かりません。 真空吸着は、圧力閾値へ到達したことで成立ではない。 少し持ち上げた後も保持できたことを確認して搬送許可にする。変形ワークほど、この一段が落下停止の切り分けに効くと思います。

カメラがワークを見つけた。真空圧も到達した。AMRも目的地へ着いた。だから次工程へ搬送する。 自律化では、この三つを一つのREADYにすると途中状態が見えなくなる。 FANUCは教示を減らすAIビジョンとAMR搭載向けDCコントローラを発表し、SMCは凹凸のある包装品向け真空グリッパを公開した。認識、移動、把持を組み合わせやすくなる一方、PLC側の受渡し条件は増える。 状態は「搬送要求・ワークID→AMR到着→ドッキング→対象認識→姿勢確定→吸着→真空保持→低速持上げ→相手機READY→解放確認→受渡し完了」と分けたい。 認識後に台車が動けば座標は無効。真空が一度到達しても、持上げ後に低下すれば搬送禁止。相手機が停止したら、ワークを保持したまま安全位置で待つ。通信復帰後も、どちらがワークを持っているか照合してから再開する。 認識不能は再撮像、真空未到達は再吸着、保持低下は退避、ID不一致は隔離。全部を「ロボット異常」にまとめない。 自律化の完成度は、正常時に勝手に動けるかではない。途中で条件が変わっても、ワークの所在を失わず安全に止まり、同じ状態から再開できるかで決まる。

主幹ブレーカの遮断容量は足りている。 それなのに、北米向け制御盤のSCCRが要求値へ届かない。 こういう時、さらに大きなブレーカへ替えればよいと考えやすいですが、見る場所が違うことがあります。 三菱電機は、製品名、単線結線図、必要SCCR値から機器を探せるSCCRポータルを公開しました。SCCRで確認するのは主幹だけではありません。 例えば見るのは四つです。 設置先の利用可能短絡電流。 主回路で最も低い機器のSCCR。 保護機器との試験済み組み合わせ。 実際に組み込んだ最終BOM。 接触器や端子台のSCCRが低ければ、主幹を大きくしても盤全体の値は上がりません。逆に、指定ブレーカとの試験済み組み合わせが使えるなら、形番、電圧、電線などの条件をそろえることで必要値へ届く可能性があります。 ここを最終BOMと結び付けていないと、立上げ後に「同じ容量」の接触器へ交換しただけで、通常運転はできてもSCCRの成立条件を外してしまう。 SCCRはPLCでアラームにできない設計条件です。 だから主幹の数字ではなく、盤内の最も弱い主回路と実装した組み合わせで判断する。北米向け盤では、この照合を部品交換後まで残すことが、現場で効くと思います。

段取り替えが終わり、作業者が「完了」を押した。治具番号も合っている。クランプもON。だから自動運転を開始する。 でも、ワークと治具の間に切粉が残っているかもしれない。ブラシは摩耗しているかもしれない。設備移設後のX・Yレベルが、締付けで変わっているかもしれない。 JIMTOFでは、着座隙間の数値出力、二軸同時レベル測定、ブラシ突出しの自動調整が展示されている。人が確認していた段取りを、現物値で確定する範囲が広がっている。 PLCでは「品種・治具ID照合→クランプ→着座値更新→工具状態確認→補正上限確認→条件保存→試運転・初品確認→自動運転許可」と分けたい。 着座確認後にクランプを解除したら、以前のOKは無効。摩耗追従が上限へ達したら、補正を続けず工具交換。ワーク位置補正が同じ方向へ増え続けるなら、ロボットで追従する前に治具のずれを疑う。 測定値には対象ID、設定版、時刻、調整前後値を付ける。通信タイムアウトやID不一致なら「段取り未完」へ戻し、完了ボタンだけで飛び越せないようにする。 段取り自動化の本質は、作業者のボタンをなくすことではない。正常な現物状態が成立したと、設備自身が説明できることだ。

異常は出ていないのに、特定ワークだけ検査タクトが長い。 調べると、オートフォーカスを何度もリトライして、最後は正常終了している。 ニコンはJIMTOFで、AF失敗時に撮影位置を変えながら再試行できるNEXIVの機能を紹介しています。自動復帰で大事なのは、最終的に成功したかだけではありません。 例えば見るのは四つです。 測定点ID。 リトライ回数。 再試行で変更した位置・探索条件。 各回の失敗理由。 同じ命令を繰り返して偶然成功しただけなら、レンズ汚れや治具ずれを隠します。逆に、位置を0.2mmずらした時だけ成功すると分かれば、局所的な反射やエッジ形状を先に疑える。条件を変えても失敗するなら、ワーク違い、照明、取付高さへ調査を移せます。 正常完了の1ビットだけでは、1回で測れたワークも、5回目で測れたワークも同じです。リトライ回数が増えているのに、故障するまで気づけません。 自動リトライは、止めないためだけの処理ではない。 何を変えて再試行し、何回目で成立したかを残す。これが、再現しにくい測定停止を保全できる兆候へ変える判断になると思います。

最初に「問い合わせから契約後のフォローまで追える仕組み」と書きました。 契約後の流れを7つに分けました。
着金確認、連絡の登録、インタビュー、回答、打ち合わせ、構成案、運用中。 今どこにいるかが一覧で分かると、「あの人どうなってたっけ」が減ります。 工程管理の表を、お客さん一人ずつに持たせた感じです。

ロボットコントローラや産業用PCを再起動したあと、画面は戻った。標準PLCもRUN。だから「設備READY」をONにする――統合制御では、この判断が少し危ない。 FANUCは安全PLCをロボットコントローラへ搭載し、三菱電機はOT監視を産業機器へ組み込み、ベッコフはCNC・PLC・解析をPC上で統合する。配線や機器間通信を減らせる一方、同じ筐体の中に通常制御、安全、セキュリティー、解析が同居する。 PLCで気になるのは、READYを一つにしないこと。標準PLC RUN、安全構成一致、安全通信成立、セキュリティー隔離なし、解析結果有効、HMI正常は別々に持つ。 例えばHMIだけ再起動したなら安全ラッチは残す。解析がタイムアウトしたならCNC周期は待たせず、補正を無効化して基準値へ戻す。マルウェア検出時も、即非常停止、現サイクル完了後停止、新規起動禁止をリスクに応じて分ける。 変更時は版・権限を照合し、バックアップ、オフライン検証、保全モード、機能別起動確認、統合試験を通してから自動運転を許可する。途中ワークがあるなら、位置、工程番号、工具、クランプ、レシピまで照合する。 統合の価値は箱と配線を減らすこと。設計の仕事は、故障原因と復旧条件まで一つにしないことだ。

AMRは所定位置まで来た。ロボットもReady。 でもアームを動かした瞬間、コントローラが再起動する。 ファナックは、AMR・AGV搭載向けにDC電源対応の「R-50iA Compact DC」を発表しました。移動体のバッテリを使いやすくなりますが、立上げで見るべきなのは停止中の定格電圧だけではありません。 例えば確認するのは四つです。 AMRの停止・ブレーキ状態。 バッテリ残量。 動作中の最低DC電圧。 走行・昇降軸・ロボットの同時負荷。 待機中は正常でも、ロボット加速時だけ電圧が落ちるなら、給電ケーブルやコネクタを先に疑える。AMR駆動と重なった時だけ落ちるなら、電力容量か同時動作条件の問題です。残量低下時だけなら、作業開始SOCが低すぎると判断できます。 ここを取らずにRobotReadyと通信異常だけを残すと、全部「ロボットがたまに切れる」に見える。ネットワークやプログラムを追っても再現条件が見つかりません。 DC電源の移動ロボットは、停止中の電圧ではなく最大負荷時の最低電圧で成立を決める。 どの動作が重なった時に、どこまで電圧が落ちたか。ここが分かれば、配線、電源容量、動作インターロックのどこから直すかを選べます。

工作機械のクーラントが減った。液面下限が入ったので補給ポンプを30秒回し、タイマ完了で加工再開。 シーケンスとしては簡単。でも配管が詰まっていたら、ポンプだけ回って液は増えていない。原液切れなら濃度も違う。別品種用の液を供給していたら、正確に間違える。 JIMTOFでは、濃度・pH・温度・液量を管理するシステム、腐敗を抑える油剤、VFD制御の循環ポンプが展示されている。加工液はもう、機械の横にある付帯設備ではなく、加工品質を成立させるプロセス条件として見る必要がある。 PLCでは「供給要求→液種照合→供給元残量→弁切替→ポンプ起動→圧力・流量成立→液量上昇→濃度安定→加工許可」と分けたい。 ポンプONでも圧力が上がらない。圧力はあるのに液量が増えない。補給後も濃度が戻らない。こうした場合は完了タイマを待つのではなく、漏れ、詰まり、エア噛み、原液不足、供給先違いとして停止位置を分ける。 軽度の濃度逸脱なら現サイクルを完了し、新規投入を禁止して補正・撹拌・再測定へ進む。循環や冷却を失った場合は、工具や主軸を守るため加工を中断する。 ポンプを回せる設備ではなく、必要な液が必要な状態で加工点へ届いたことを確認できる設備が強い。補給完了はタイマではなく、現物条件で確定したい。

位置決め異常は出ていないのに、特定の角度だけ原点復帰や加工位置が不安定になる。 こういう時がやっかいです。 現在位置は読めている。エンコーダアラームもない。だから機械のガタ、サーボ調整、プログラムの順に疑ってしまう。 ファゴールは、UTリングエンコーダの信号品質をPSED2からグラフ付きPDFとして出せる機能を発表しました。新しいのは診断技術そのものではなく、アラームになる前の状態を比較できる形にしたことです。 例えば定期点検で見るのは、軸角度、信号品質、取付ギャップ、暖機状態の四つ。 全周平均だけではなく、同じ角度ごとに前回と比べます。 特定区間だけ品質が落ちるなら、リング面の汚れ、局所損傷、偏心を先に疑える。逆に全周で下がり、暖機後ほど悪化するなら、ヘッド取付、電源、ケーブル側へ調査を移せます。 位置正常とアラームの2ビットしか残していないと、どちらも「たまに位置がずれる」に見えます。結果として、まだ使える部品を交換したり、関係の薄いサーボゲインを触ったりする。 エンコーダ保全で残したいのは、故障した事実だけではなく、どの位置で余裕が減ったか。 アラーム前の信号品質を軸位置と結び付ける。これが、再現しにくい位置ずれで最初に調べる場所を変える判断になると思います。

機上計測で寸法が取れた。PLCにも数値が返った。そこで、その値をそのまま工具補正へ書く。自動化としてはきれいに見えるが、現場ではここが一番怖い。 JIMTOF関連でも、エンコーダの信号品質、工具の機上測定、歯車の全数検査など、「測って次の制御へつなぐ」製品が増えている。新しいのは計測原理そのものより、測定が生産シーケンスの中へ深く入ってきたことだ。 PLCでは「通信正常」「測定完了」「測定品質有効」「補正許可」を分けたい。工具IDとレシピが一致し、校正済みで、軸姿勢や温度などの条件が成立して初めて、補正演算へ進める。 測定中に一時停止した。復帰時に工具番号が変わった。測定値は返ったが信頼度が不足した。補正量は上限内でも、同じ方向への補正が連続している。こうした途中状態では、値が存在しても補正は禁止する。 有効な測定結果が規格外なら、工具交換やワーク隔離へ進む。一方、対象未検出や信号品質不足は測定不能なので再測定する。この二つを同じNGにすると、復旧手順も履歴も崩れる。 さらに、補正前後値、工具・ワークID、レシピ版、補正量、実行時刻を残し、次サイクル反映後に再測定する。自動補正の価値は、人が入力しなくてよいことではない。誤った値を使わない条件まで自動化できて、初めて閉ループ制御になる。

厚さの数値は出ているのに、追加工したら残肉が規格を外れた。 こういう時、測定器の精度だけを疑うと長引きます。値は正常範囲。でも、その値が現在のワークを今の測定点で測った結果とは限りません。 レニショーはJIMTOFで、機上超音波厚さ計測プローブRUP60を国内初公開しています。測定結果を追加工へ戻せるなら、PLC・NC側で大事なのは値より「今回の測定が成立したか」です。 例えば確認するのは四つです。 ワークID。 測定点ID。 測定シーケンス番号。 校正条件と正常終了。 測定開始時に前回の有効ビットを消さないと、通信断やサイクル中断後も古い正常値が残ります。数値だけ範囲判定すれば、その値で現在ワークを追加工してしまいます。 逆に、要求番号と応答番号が一致し、現在ワークの指定点を正常測定し、校正条件も有効だと確認できれば、その値を補正へ渡せる。途中でプログラムやワーク座標が変わったら、測定済み状態を失効させます。 工程内計測は、測定値を読むだけでは閉ループにならない。 「どのワークを、どの条件で、今回測れたか」まで加工許可に使うこと。もっともらしい前回値で削ってしまう事故を防ぐには、ここが効いてくると思います。