現場記録：バッチが炉から出る前に真空リークを発見する

精密ステンレス部品のバッチが、真空焼入れ後に脆くなって出てくる。オーステナイト化保持と窒素クエンチのどこかで何かがおかしくなった——だが炉自体の制御系はその原因を語ってくれない。熱処理ログには緑のチェックマークが表示されている。数時間後に行われるラボの硬度試験で、ようやく問題が明らかになる。その頃にはもう、バッチは次の工程へ移動してしまっている。

「サイクルが終わった」ことと「なぜ失敗したかが分かっている」ことの間にあるこのギャップこそ、真空熱処理ラインで私たちが繰り返し直面してきた課題であり、それを埋めるために構築したのがこのリファレンス監視システムだ。発生から数秒以内に根本原因を捕捉し、ラボの硬度データと自動的に相関させ、スライドではなく実際の熱サイクル上で実証する。ここで重要な失敗モードは二つあり、それぞれ工程の両端に位置する：保持中の真空リークと、圧力不足の窒素クエンチだ。ベンチ上での症状は同じ——脆化——だが炉の中での原因はまったく異なる。

良品バッチが不良になる二つの経路

オーステナイト化保持中（マルテンサイト系ステンレスでは通常1000〜1050°C付近）の真空ドリフトは、酸素や水分を表面に到達させ、粒界のクロムを枯渇させる——エッジで欠けやすい、軟らかく脱炭した層ができてしまう。窒素クエンチが遅い場合はまったく逆の損傷が起きる：800〜500°Cの帯域に長く留まりすぎると、粒界に沿ってクロム炭化物が析出し、表面状態とはまったく無関係な粒界破壊経路が生まれる。どちらも最終的には脆化するが、正しいタイミングで正しい窓を監視していなければ、バルク硬度スペックには一切現れない。

そのため、この監視システムはバッチが終わってから「規格内だったか」を確認するようなことはしない。二つのライブ条件を常時監視している：SOAK中のチャンバー圧力が0.05 mbarの上限を超えていないか、そしてQUENCH中に800→500°Cを通過する時間が130秒の上限を超えていないか——さらに、現在の冷却傾斜を外挿する予測チェックにより、帯域を通過し終わる前にクエンチの遅れを検知できる。模擬したリークでは15.2秒で検知した。模擬した圧力不足のクエンチでは、予測チェックが32.3秒で作動した——通過がまだ完了していない段階でだ。

flowchart LR
    PLC["炉PLC<br/>OPC UAサーバー"] -- "DataChange<br/>サブスクリプション" --> RE["ルールエンジン"]

    RE -- "SOAKフェーズ:<br/>真空度 > 0.05 mbar<br/>30秒継続" --> A1["アラート: 真空ドリフト<br/>約15秒"]
    RE -- "QUENCHフェーズ:<br/>800→500°C > 130秒、<br/>または遅延傾向" --> A2["アラート: クエンチ遅延<br/>約32秒(予測)"]
    RE -- "バッチが<br/>COMPLETEへ" --> CERT["熱処理証明書"]

    LAB["ラボ硬度結果"] -. 相関 .-> CERT
    A1 -.-> CERT
    A2 -.-> CERT

事後ではなく、PLCの「考え」をリアルタイムで読む

私たちはこうしたシステムを、旧世代のPLCが話すベンダー独自プロトコルではなく、OPC UA上に構築している。この選択は、見た目以上に重要だ。「今の温度は？」と1秒ごとに尋ねるポーリング型クライアントは、変化がどれだけ速く起こるかに賭けているに等しい——そして15分のクエンチサイクルは、800〜500°Cの過渡状態を2分足らずで通り過ぎてしまうこともある。OPC UAのサブスクリプションモデルはこれを逆転させる：変化が起きた瞬間にPLC側からプッシュされ、監視システムのルールエンジンは推測した間隔ではなく、その通知に反応する。バッチ終了時ではなく数秒で故障を捕捉できたのは、ポーリングを速くしたからではない。ポーリングそのものをやめたからだ。

私たちを静かに欺いていたかもしれないバグ

最初のバージョンは、フェーズ・温度・真空度・経過時間という四つの独立したタグをそれぞれ購読していた——それぞれがPLC上で個別のOPC UA書き込みとして更新される。これはティアードリード（不整合読み取り）が起きるのを待っているようなものだ：新しいフェーズ値が、一つ前のスキャンサイクルの圧力読み取り値と対になって届く可能性がある。四つの書き込みが一つの原子的な単位として購読者に届く保証はどこにもないからだ。実際に起きた現象もまさにその通りだった——通常バッチの保持フェーズ中に、実際には発生していない真空違反が一瞬報告された。原因は、クライアントが「SOAK」フェーズの更新を、0.5秒前の「まだ大気圧から下がりきっていない」という古い圧力値と組み合わせて読み取ってしまったことだった。修正方法は、相関する四つのタグを四つの独立した事実として扱うのをやめることだった：スキャンごとに一度だけ書き込まれるJSONスナップショット一つを、単一のまとまりとして購読する。この誤報は二度と発生しなかった。

二つ目のバグはより微妙で、ある意味さらに厄介だった。エラーを出すのではなく、実際の結果を静かに上書きしてしまうタイプのバグだったからだ。Webダッシュボードはバッチをまたいで再接続する仕組みになっており、サイクルの間に再起動する必要はない。だが、完了したバッチのPLCプロセスは、COMPLETEに到達した後も次のバッチが始まるまで数スキャン分だけ居座り続ける。その窓の間に再接続すると、同じバッチIDを再び読み取ってしまい、SOAKやQUENCHの履歴を一切持たない、すでに完了したスナップショットを元に新しい監視インスタンスを構築してしまう。その結果「問題なし」というきれいなPASSを報告し、直前に正しく生成されていたFAIL証明書を上書きしてしまう。どちらのバグも、ハッピーパスを一度だけ流すデモでは表面化しなかっただろう。だが、システムを連続稼働させた瞬間——炉が実際に稼働する唯一の方法——両方とも表面化した。

一貫して流れるテーマ

ここで使われている技術は、どれも特別に目新しい計測技術ではない。硬度ラボのデータを熱処理証明書にフィードバックすること。ポーリングループの代わりにサブスクリプションを使うこと。四つの独立したタグの代わりに一つの原子的なタグを使うこと。それぞれを正しく作り込む価値があった理由は、熱処理炉が二つの大きく異なる失敗モードのどちらが起きたかを自ら告げてはくれないからだ——炉はただ静かになり、理由を自分で探さなければならない不良部品を渡してくる。多くの場合、それはバッチがすでに工場を出た後のことだ。

これこそが、私たちSimplicoが日々取り組んでいる領域だ：精密製造の現場では、ミツトヨのノギスやPLC、炉のコントローラーがすでに部品に関する真実を生成している。足りないのはただ一つ、それをリアルタイムで読み取り、不良バッチが流出する前にSPCやERPへ届けるシステムだけだ。もし貴社が、計器やコントローラー画面から今も手作業で転記したデータを使ってIATF 16949、ISO 13485、AS9100の監査に対応しているなら、それはまさに私たちのsimpliFactoryアーキテクチャレビューが見つけ出すべき課題だ。予約はこちら——セールストークではなく、90分間の対話だ。