外部機器の状態の確認と表示のベストプラクティス - 『接続中』だけで済ませない設計

産業用カメラ、バーコードリーダ、PLC、計測器、プリンタ、シリアル機器、USB 機器。
外部機器とつながる Windows アプリでは、実際の不具合そのもの より先に、画面の状態表示が現実とずれること で事故ることがかなり多いです。

たとえば、こんな状態です。

• OS からは見えているのに、別プロセスが掴んでいて使えない
• open はできたのに、原点復帰やウォームアップ、認証が終わっていない
• 機器はぶら下がっているが、応答はもう止まっている
• 取得スレッドが死んでいるのに、最後の値だけ画面に残っている
• 想定外の個体や firmware なのに、単に「接続中」と表示してしまう

ここで本当に知りたいのは、つながっているかどうか だけではありません。
いま何を安全にやってよいか です。

目次

1. 1. まず結論
2. 2. なぜ「接続中」が危ないのか
3. 3. まず分けるべき状態
   • 3.1 内部で分けたい状態軸
   • 3.2 UI は全部を平面的に見せなくてよい
4. 4. 状態確認のベストプラクティス
   • 4.1 起動時列挙と到着 / 削除通知
   • 4.2 「存在」「開ける」「応答する」「使える」を分ける
   • 4.3 event と poll を混ぜる
   • 4.4 監視処理と UI を分離する
   • 4.5 個体識別を安定させる
5. 5. 表示のベストプラクティス
   • 5.1 一枚で見る判断表
   • 5.2 文言は「状態 + 理由 + 次の行動」
   • 5.3 stale data を隠さない
   • 5.4 重要度に応じて見せる場所を変える
   • 5.5 複数台表示では要約と詳細を分ける
6. 6. 再接続と運用のベストプラクティス
   • 6.1 再接続は backoff 付きにする
   • 6.2 flapping をならす
   • 6.3 最低限残すべきログ
   • 6.4 監視停止と機器停止を混同しない
7. 7. 機器タイプ別の見落としやすい点
   • 7.1 USB / PnP 機器
   • 7.2 シリアル機器
   • 7.3 ネットワーク機器
   • 7.4 SDK 依存のカメラ / 計測機器
8. 8. やってはいけないこと
9. 9. まとめ
10. 10. 参考資料

1. まず結論

外部機器の状態確認と表示で一番効くのは、状態を 1 個の boolean に潰さないこと です。

少なくとも次は分けたほうが安全です。

• 存在: OS から見えているか
• セッション確立: 自アプリが open / login / initialize 済みか
• 応答性: heartbeat や status query に返るか
• 機能準備: 実際の操作をいま受け付けられるか
• データ鮮度: 画面の値は新しいか
• 構成一致: 想定した個体、型番、firmware か
• 監視健全性: そもそも監視処理が生きているか

かなり雑に言うと、こうです。

存在確認は OS 側、使用可否はアプリ側、鮮度判定は画面側で持つ。

この 3 つを混ぜないだけで、状態表示はかなり安定します。

2. なぜ「接続中」が危ないのか

「接続中」という文言は、1 つの文言で複数の意味を勝手に背負ってしまいます。

実際には、少なくとも次の問いが混ざっています。

1. OS から対象機器の interface が見えているか
2. 自アプリがその機器を open / login / initialize できているか
3. 軽い問い合わせに期限内で返るか
4. いま要求した操作を安全に実行できるか
5. 画面に出ている値は新しいか
6. 想定した個体・型番・firmware か

この 6 つのどれを満たしているかで、「使える」の意味は変わります。

たとえば、次の 4 つは全部違います。

• 未接続
  そもそも OS が対象 interface を見つけていない
• 接続済み / 確認中
  物理的には見えているが、初期化や認証が終わっていない
• 接続済み / 使用不可
  応答はあるが、warming up、busy、interlock、media なしなどで動作できない
• 値が古い
  以前は取得できていたが、画面の値は freshness budget を超えている

これらを全部「接続中」で潰すと、operator は何をすればよいか判断できません。

3. まず分けるべき状態

おすすめは、内部状態は多軸で持ち、UI では必要に応じて要約する ことです。

3.1 内部で分けたい状態軸

軸	何を意味するか	典型的な確認方法	UI で見せたい例
存在	OS から対象 interface が見えているか	起動時列挙、arrival / removal 通知	未接続 / 接続済み
セッション	自アプリが open / login / initialize 済みか	handle / SDK 初期化結果	確認中 / 初期化中
応答性	status query や heartbeat に返るか	timeout 付き軽量問い合わせ	応答あり / 応答遅延 / 応答なし
機能準備	実際の操作がいま可能か	device-specific status	使用可能 / busy / warming up
データ鮮度	表示値が新しいか	timestamp / sequence	最新 / 値が古い
構成一致	想定機器と一致しているか	model / serial / firmware / profile	対象機器 / 想定外の機器
監視健全性	アプリの監視経路が生きているか	worker heartbeat / loop lag	監視中 / 監視停止

ここで大事なのは、機器が悪い状態 と アプリが観測できていない状態 を分けることです。

3.2 UI は全部を平面的に見せなくてよい

内部で多軸に持つと、画面がうるさくなりそうに見えます。
でも UI は全部を同じ重みで出す必要はありません。

おすすめは 3 層です。

• 上段に 要約状態
• その下に 理由
• 必要なら 詳細パネル

たとえば、

• 要約: 接続済み / 使用不可
• 理由: ウォームアップ中 残り約 18 秒
• 詳細: model serial firmware last heartbeat last frame time

のように分けると、情報量を増やしてもかなり読みやすくなります。

4. 状態確認のベストプラクティス

4.1 起動時列挙と到着 / 削除通知

Windows で外部機器を扱うときの土台は、起動時に既存機器を列挙し、以後は arrival / removal 通知を受ける ことです。

特に押さえておきたいのは次です。

• 通知だけでは既存機器は拾えない
• runtime communication では setup class より interface class のほうが自然
• remove 通知と I/O error の見え方が前後することがある

実務ルールとしてはシンプルです。

1. 起動時に列挙する
2. 通知を購読する
3. 通知を受けたら再列挙して内部状態を reconcile する

4.2 「存在」「開ける」「応答する」「使える」を分ける

外部機器の事故は、ここをまとめて扱ったときに増えます。

• 存在する
  OS から interface が見えている
• 開ける
  他プロセス競合や権限問題なしに handle / session を持てる
• 応答する
  軽い問い合わせに timeout 内で返る
• 使える
  実際の操作を受け付けられる

この 4 つは同じではありません。

4.3 event と poll を混ぜる

event ベースだけ、poll ベースだけ、のどちらかに寄せ切るより、検出は event、健全性確認は poll が実務では扱いやすいです。

• arrival / removal は event
• heartbeat / status query は poll
• freshness 判定は timestamp / sequence

この分け方にすると、接続検出と実使用可否を切り離しやすくなります。

4.4 監視処理と UI を分離する

UI thread で直接 open / read / status query を回すと、表示の都合と監視処理の都合が簡単に混ざります。

おすすめは、

• 監視ワーカーが state store を更新
• UI は state store を購読して描画
• UI 操作は command として監視層へ渡す

という形です。

これで、監視停止と機器停止を分けて扱いやすくなります。

4.5 個体識別を安定させる

friendly name や COM3 のような見た目の識別子だけで状態を追うと、個体を取り違えやすくなります。

できれば、

• serial number
• logical device id
• stable device path
• 機器側の個体 ID

のような ぶれにくいキー を内部で持ったほうが安全です。

5. 表示のベストプラクティス

5.1 一枚で見る判断表

実際の状態	UI の要約	補足表示
interface なし	未接続	ケーブル、電源、USB 接続を確認
interface あり、初期化中	接続済み / 確認中	初期化中、認証中、ウォームアップ中
応答あり、操作条件未達	接続済み / 使用不可	busy、media なし、interlock open
応答あり、値が古い	接続済み / 値が古い	最終更新 12 秒前
応答なし	応答なし	再接続中、通信 timeout
想定外個体	想定外の機器	model / serial / firmware 不一致
監視処理停止	監視異常	監視ワーカー停止、再起動が必要

5.2 文言は「状態 + 理由 + 次の行動」

エラー や 異常 だけでは、画面としては弱いです。
メッセージは次の 3 要素に寄せたほうが、operator が迷いにくくなります。

• 状態: 何が起きているか
• 理由: なぜそう判断したか
• 次の行動: 何をすればよいか

たとえば、

• 接続済み / 使用不可 - ウォームアップ中 - 約 18 秒待ってください
• 応答なし - heartbeat timeout - ケーブルと電源を確認してください
• 想定外の機器 - Firmware 2.1.0 が必要です - 対象機器を確認してください

のような形です。

5.3 stale data を隠さない

last known value は役に立ちます。
ただし live value の顔で見せない ほうが安全です。

おすすめは、

• 値の横に timestamp
• 値の age 表示
• stale になったら色やラベルを変える
• 一定時間を超えたら操作可能判定から外す

です。

5.4 重要度に応じて見せる場所を変える

status bar は便利ですが、見落とされやすいです。
critical な異常は、status bar の隅にだけ置かないほうが安全です。

• 軽微な状態変化: status bar
• 作業継続可能な注意: inline notice
• 操作停止が必要な異常: 主表示領域、ダイアログ、バナー

という使い分けが素直です。

5.5 複数台表示では要約と詳細を分ける

複数台の機器を扱う画面では、全件詳細を常に出すと見づらくなります。

• 上部に 全体サマリ
• 下部に 機器ごとの行
• 選択時に 詳細ペイン

の 3 段にすると、全体把握と個別切り分けを両立しやすいです。

6. 再接続と運用のベストプラクティス

6.1 再接続は backoff 付きにする

応答が止まったときの再接続を、最短ループで叩き続けないほうが安全です。

• device / driver / SDK に負荷をかける
• ログが洪水になる
• 一時的な不安定を悪化させる
• UI が激しく揺れる

からです。

おすすめは、

• 初回はすぐ retry
• だめなら段階的に間隔を伸ばす
• 上限を設ける
• 手動 再接続 も用意する

です。

6.2 flapping をならす

USB 接触不良やネットワーク瞬断のような場面では、状態が短時間で行き来します。
ここで生イベントをそのまま UI に出すとかなり見づらいです。

なので、

• 内部ログは生イベントのまま残す
• UI は短い確認期間を置いてから確定表示する
• ただし critical 異常はすぐ見せる

という使い分けが扱いやすいです。

6.3 最低限残すべきログ

状態表示の改善は、ログ設計とほぼセットです。

項目	例
timestamp	2026-03-20T10:23:41.512+09:00
stable device key	camera:A1B2C3
表示名	前工程カメラ
旧状態 -> 新状態	Ready -> Stale
理由	heartbeat timeout firmware mismatch
エラーコード	HRESULT Win32 SDK code
last success	2026-03-20T10:23:36.011+09:00
age / RTT	5.5s 320ms
retry count	3
app / firmware version	App 1.8.2 / FW 2.4.1

特に大事なのは、状態遷移ログ です。

6.4 監視停止と機器停止を混同しない

• poll loop が例外で死んだ
• SDK callback が止まった
• acquisition worker が deadlock した
• state store 更新だけ止まった

こういうとき、機器は生きていてもアプリは観測できていません。
この状態を 未接続 や 応答なし だけで出すと、機器側の問題に見えてしまいます。

なので、監視経路の健全性 は別軸で持ったほうがよいです。

7. 機器タイプ別の見落としやすい点

7.1 USB / PnP 機器

• 通知だけでは existing device は拾えない
• runtime では setup class より interface class が自然
• composite device は複数 interface を出すことがある
• remove 通知と I/O error の見え方が前後することがある

7.2 シリアル機器

COMx が見えているだけでは安心できません。

• ポート自体はあるが、対象機器がぶら下がっていない
• 別プロセスが open している
• 応答はもう止まっている
• read / write が timeout で固まる

シリアルでは、存在 と 応答 と 使用可能 を特に分けたほうが安全です。

7.3 ネットワーク機器

ping が通ることと、アプリが使えることを同一視しないほうがよいです。

• 名前解決できるか
• TCP 接続できるか
• アプリ層 handshake できるか
• status が ready か
• 値が fresh か

の段階があります。

7.4 SDK 依存のカメラ / 計測機器

SDK callback が来ていることだけで live と決め打ちしないほうが安全です。

• callback thread 自体が止まる
• frame は来るが timestamp が進んでいない
• image stream は来るが control channel が死んでいる
• reconnect 後の設定再適用が終わっていない

ので、SDK の外から見た健全性も持つと安全です。

8. やってはいけないこと

• 状態を 接続中 / 未接続 / エラー の 3 つに潰す
• 通知だけで existing device も拾えると思う
• open 成功をそのまま 使用可能 とみなす
• last known value を fresh な顔で見せる
• timestamp を表示しない
• UI thread で open / read / status query を回す
• retry を最短ループで回す
• critical な異常を status bar にだけ出す
• 未接続 と 監視停止 を混同する
• friendly name や COM3 だけで個体識別する

9. まとめ

外部機器連携アプリで本当に大事なのは、何を確認したら、どこまで言ってよいか を決めることです。

とくに次が効きます。

存在している
自アプリが開ける
応答している
いまその操作ができる
画面の値が新しい

この 5 つを分ける。

そのうえで、かなり雑に言うと次です。

• 起動時は列挙、以後は通知
• 使用可否は heartbeat と device-specific status で決める
• 表示値には timestamp と age を持たせる
• critical な異常は見落とされにくい場所へ出す
• 監視系の異常を機器異常に見せない

「接続中」と出せることより、その表示が現実とどれだけずれにくいか のほうが実務ではずっと大事です。

10. 参考資料

• Microsoft Learn, CM_Register_Notification
• Microsoft Learn, Registering for Notification of Device Interface Arrival and Device Removal
• Microsoft Learn, Registering for Device Notification
• Microsoft Learn, Comparison of setup classes and interface classes
• Microsoft Learn, Device Information Sets
• Microsoft Learn, SetupDiEnumDeviceInterfaces
• Microsoft Learn, Communications functions
• Microsoft Learn, ClearCommError
• Microsoft Learn, COMMTIMEOUTS structure
• Microsoft Learn, WaitCommEvent
• Microsoft Learn, Monitoring Communications Events
• Microsoft Learn, Status Bars (Design basics)
• Microsoft Learn, UX checklist for desktop applications