作ったプログラムを、いきなり現場の設備に転送して動かしていませんか？
「現場で機械を動かしながら、バグが出たらその都度直せばいいや」 この「ぶっつけ本番」でとりあえず動かすスタイルは、高額な設備を破損させる最大の原因です。
実務9年の現場エンジニアである私が断言します。現場でのデバッグに依存しているうちは、いつまで経ってもバグと手戻りのループから抜け出せません。
今回は、これまでの連載で学んだ「ラダー」「ST言語」「FB（ファンクションブロック）」すべてに共通する、品質を担保するための「机上デバッグ（シミュレーション）」の極意を解説します。
これから現場で戦っていくあなたに、「現場で一つもミスをするな」とは言いません。これから数え切れないほどの失敗をして、冷や汗をかきながら成長していくはずです。
しかし、「パソコンの中で潰せるバグ」を現場に持ち込み、致命的な事故を起こすことだけは絶対に防がなければなりません。
最後まで読んで、余裕を持って現場の立ち上げ（試運転）に臨むための「確実な品質保証スキル」を身につけましょう。
「現場デバッグ」という妥協を捨て、「実機確認」と呼べ
プログラムを書き終えた直後、「早く動くところを見たい」という誘惑に駆られる気持ちは痛いほど分かります。 しかし、未検証のプログラムを実機に書き込むのは、テストではなくただの「運試し」です。
- インターロックのラダー記述が漏れていて、シリンダ同士が激突する。
- ST言語の計算ミスで、サーボモーターが想定外の猛スピードで暴走する。
現場でこれらの事故が起きてから「すみません、バグでした」では済まされません。
ここで、設計者として絶対に持つべきマインドセットをお伝えします。
今日から、「現場デバッグ」という言葉を口にするのをやめてください。 代わりに「実機確認」と呼ぶように意識を変えるのです。
「デバッグ（バグ取り）」という言葉を使うと、無意識のうちに「現場にバグがあるのは当たり前（現場で直せばいい）」という甘えが生まれます。
設計者にとって、現場はバグを探す場所ではありません。
「机上で完璧に作り上げた論理が、現実の機械でも想定通りに動くことを『最終確認（検証）』する場所」なのです。
【結論】現場はバグを探す場所ではない。パソコンの中（机上）で論理バグを全て出し尽くせ。
シミュレータの活用と「ボトムアップテスト」の基本
では、実機を使わずにどうやってパソコンの中でバグを出し尽くすのか。 現代のPLC設計ソフト（GX Works、KV STUDIO、Sysmac Studioなど）には、パソコンの中に仮想のPLCを作り出す「シミュレーション機能」が標準搭載されています。 これを使えば、実機に繋いでいるのと同じように接点のON/OFFや現在値の推移を確認できます。
このシミュレータを使った具体的な実践に入る前に、私が現場で必ず実践しているテストの基本概念をお伝えします。
初心者がやりがちな最悪のミスは、「いきなり全体（メインルーチン）を動かしてテストしようとする」ことです。
全体を動かしてバグが出た時、それが部品（FB）のせいなのか、司令官（全体回路）のせいなのか特定できず、迷宮入りしてしまいます。
▶ 急がば回れ「下から上へ」
私は「ボトムアップテスト」という手法を強くお勧めします。
- 部品の単体テスト： まず、FB単体はもちろん、「ラダーの自己保持回路」や「ST言語の計算処理」など、一番小さな『機能の単位（部品）』が正しく動くか確認する。
- 結合テスト： 部品を組み合わせた機能をテストする。
- 全体テスト： 最後にメインルーチンを通す。
「テスト済みの部品」は、他の案件で再利用する時にテストを省略できます。この積み重ねが、将来的に最強の時短を生むのです。
PLCシミュレータを使った実務のデバッグ（検証）手法
このボトムアップの考え方を踏まえ、現場で必ず行うべき「3つの定石」を解説します。
① FB（部品）は「隔離して単体テスト」せよ
FBのような「部品」をテストする際、本番のラダー回路の中に「M0」などのテスト用デバイス（仮のスイッチ）を一時的に書き込んで、強制起動させていませんか？
シミュレータでは実機がないため、どうしても仮のスイッチを使って手動で信号を与え、擬似的にテストを進める必要があります。しかし、それを本番回路の中でやってしまうと、以下の2つの致命的な問題が起きます。
- 原因が切り分けられない： 動かなかった時、「FBの中身（金型）」が間違っているのか、「本番回路の起動条件（外側）」が間違っているのか、全く分からなくなります。
- 最悪の二次災害： 後でそのテスト用接点を消し忘れ、本番で誤作動を起こします。
▶ 実務の定石：テスト用ドライバ（暫定プログラム）を作る
本番のプログラムとは別に、「テスト専用のプログラムブロック」を新規作成します。そこにFBを1個だけ配置し、単独で検証を行います。
- 【絶対のルール】FBの中身はいじらない： テストのためにFBの中身を一時的に書き換えてバイパスしてはいけません。コードを書き換えてしまうと、戻し忘れた時に「テストしたFB」と「本番のFB」が別物になり、大事故に直面します。
- 【実機アンサーの突破法】： 実機からの通信アンサーなどが来ない場合は、回路はいじらず、シミュレータの機能で「待機している内部変数の現在値だけを強制的にON（数値書き換え）」してプログラムを騙して突破します。
💡 新人が陥る罠
「テストのためだけにわざわざ専用回路を書くなんて無駄だ」と思うかもしれません。しかし、本番回路を汚さず、終わったらドライバごと捨てるだけのこの手法が、結果的に一番早く安全にデバッグを終えられます。
ここで「FB単体は完璧だ」と証明できれば、後で本番に組み込んで動かなかった時、「FBの中身は絶対に合っているから、外側の条件がおかしいんだ」と迷わずデバッグの的を絞れるのです。
② 司令官（全体回路）は「歩進」と「血流」を追え
①で「部品（FBなど）」が完璧に動くことを証明しました。次は、それらに命令を下す「司令官（全体回路）」のテストです。手当たり次第にスイッチを入れるのではなく、以下を確認します。
- 工程の歩進テスト（ラダー/SFC）：
自動運転が「吸着」→「搬送」→「下降」などと順番通りに進むか。シミュレータ上で、次の工程へ進むための完了条件（仮想のセンサ入力など）を一つずつ手動でONにし、シーケンスが途中でだんまりになる（進まなくなる）ことなく、正しく歩進するかを見届けます。 - データの血流テスト（ST言語）：
ST言語で組んだ複雑な演算結果が、正しいタイミングでラダーやFBに渡されているか。「ウォッチウィンドウ（デバイスモニタ）」に注目すべき変数を並べ、品種データの読み込みから計算、出力までの「数値の変化（血の巡り）」に異常がないかを追跡します。
部品が正しくても、指示を出すタイミングや渡すデータが間違っていれば機械は衝突します。一つ一つのステップを指差呼称するつもりで確認してください。
③ 強制ON/OFFで「意地悪な入力」を与えろ
実機では怖くて試せないテストこそ、シミュレータのデスクの上でやるべきです。
「設計通りに動くか」ではなく、「想定外の操作をされても安全に止まるか（異常系）」をテストします。
- リミットスイッチが「両方同時にON」するという物理故障を起こしてみる。
- STの計算式に「0」や「マイナス」を入れ、ゼロ除算エラーでPLCがダウンしないかテストする。
- インターロック条件を無視して、あり得ないタイミングで手動ボタンを押してみる。
- 非常停止ボタンを押した瞬間、PLC内部の「自己保持」や「工程歩進」が即座にリセットされ、安全な待機状態に戻るかを確認する。
💡 プロの鉄則（安全概念）
機械の動力を物理的に遮断して安全を守るのは「安全リレー等ハードウェア」の役割であり、PLCのプログラムで行うことではありません。 ここでテストするのは、あくまで「PLC側も非常停止を正しく認識し、内部のプログラム状態をバグなく初期化できているか」の確認です。
👇あわせて読みたい
▶【安全回路】PLCで安全を守ってはいけない理由（安全リレーの基礎）
▶【機能安全】IEC 61508とは？現場エンジニアが知るべき安全の原則
このように、ユーザーが絶対にやらないような「意地悪な操作」を徹底的に行い、それでもプログラム全体がバグらない（安全側に倒れる）ことを確認するのが、机上デバッグです。
【結論】シミュレータ上でラダー・ST・FBすべてに「最悪の条件」を与えて検証せよ。
まとめ：品質は「机上」で作られ、「現場」で確認される
ここまでの内容を振り返ります。
- マインド： 「現場デバッグ」の甘えを捨て、現場は調整の場であるという「実機確認」の意識を持つ。
- 手順（ボトムアップ）： いきなり全体を動かさず、下から上へテストする。
- 定石①（FB隔離）： 本番回路を汚さず、「テスト用ドライバ」で単体検証する。
- 定石②（全体血流）： 司令官を動かし、工程の歩進とデータの受け渡しを追う。
- 定石③（異常系）： ゼロ除算やあり得ない故障を意図的に起こし、限界テストする。
現地で機械の前に座り込み、焦った顔でPCを開いて一からラダーを書き直している姿。あの地獄のような苦労は「机上のシミュレーション」で半分以上減らすことができます。
現場の時間は限られています。机上で潰せる論理バグは、会社にいるうちに全て出し尽くす。 そうやって、現場での貴重な時間と体力を「実機でしかできない調整」のために残しておける設計者を目指してください。
理想と現実：失敗しながら登っていくあなたへ
ここまで、シミュレータによる「机上での完璧な品質保証」の理想を語ってきました。 しかし、現場を知るエンジニアとして、あえて残酷な現実をお伝えします。
机上でどれだけテストをしても、バグを「完全にゼロ」にすることは絶対にできません。
▶ 理由①：実機からの「アンサー」が来ない
最大の理由は、実機が繋がっていないシミュレータでは、どうしても「無視（バイパス）」しなければテストを進められない回路が存在するからです。
- サーボアンプからの「位置決め完了」信号
- 他の装置との特殊な通信アンサー
- ハードウェア依存の安全回路フィードバック
これらは、実際に機器が繋がっていないとONになりません。テストを進めるためには一時的に強制ONで誤魔化したり、回路をバイパスするしかありません。意図的に無視した箇所がある以上、机上のテストはどう足掻いても「完璧」にはなり得ないのです。
▶ 理由②：現場の「物理的なトラブル」
さらに、現場に出ればソフト以外のトラブルも容赦なく襲いかかってきます。
- 想定の位置でセンサがオンしない。
- シリンダの空気圧が強すぎて、想定より早く端に到達してしまう。
だからこそ、現場に出たあなたは現実の壁にぶつかり、焦り、たくさん失敗することになります。しかし、それで良いのです。現場の泥臭い失敗からしか学べない技術が山ほどあります。
【結論】机上テストの本当の目的
重要なのは、完璧が無理だとしても、「ソフトの論理バグ」を机上で『可能な限りゼロ』に近づけておくことです。
それをして初めて、現場では物理トラブルの解決や、バイパスせざるを得なかった回路の「答え合わせ（実機確認）」に100%集中できるようになります。
ここまで当ブログの連載を読み切ったあなたには、マニュアルには載っていない「プロの設計思想」がすでにインストールされています。
机上で磨き上げたプログラムを握りしめ、堂々と現場の「実機確認」に臨んでください。 そして、たくさん失敗しながら、あなただけの経験値を積み上げていってください。応援しています！
