TeamWorks 様 確認事項（第3回）— ご回答への返信と追加確認

作成: 2026-09-03 / 作成者: DFA 対象DDL: clean_watch_20260902.sql（2026-09-02 受領）

第2回「確認事項」へのご回答をありがとうございました。 Q1・Q2 で止まっていた D-Security 画面と清掃詳細ログの設計が進められます。

本書は次の3部構成です。

1. ご質問への回答

1-1.「備考ってありましたでしょうか?（見落とし?）」について

DB側の項目ではありません。こちら（ビューアー）側で持つべきものでした。

D-Secログ画面のモックに「備考」列があり、サンプル値として 「セキュリティ復帰失敗」「6時間以上通信なし」が入っていました。 Q1-3 でご回答いただいた「アラートは生死報告がないの1種類だけ、詳細文は無い」を踏まえると、 これらは検知側が出す情報ではなく、運用担当が手で書き留めるメモとして 想定されていたものだと分かりました。

→ ビューアー側に入力欄を作り、当方の独自ストアに保存します。DB側の対応は不要です。 点検記録や運用設定と同じ扱いで、メインDBには書き込みません。

なお control_error_histories.comment については、 アラート1件ごとに運用担当が対応時に書き込む欄（更新可4カラムの1つ）という理解で、 デバイスごとの備考とは別物と考えています。この認識で合っていますか。

1-2.「切り替えられる形にした場合のデメリットは?」について

恒久的なコストはほぼありません。 ただし切り替える瞬間に2つ、避けられない影響があります。

(1) 切り替えた瞬間、それ以前に画面が持っていた ID が全部無効になります

対応状況の更新はアラート一覧の行から行うため、 画面を開いたままの担当者が「対応中」を押すと、古い ID で更新をかけて 404 になります。 リロードすれば直るので実害は小さいですが、 運用が動いていない時間帯に切り替えていただく必要があります。

(2) 切替をまたぐと、同じレコードが別の ID で記録され、ログの追跡が切れます

「いつ・誰が・どのアラートを対応済みにしたか」を後から追うとき、 切替前後で ID が変わるため同一性が分からなくなります。 切り替えた日時を当方の記録に残しておけば読み替えられるので、これも致命的ではありません。

(3) コードに分岐が残る問題は、作り方で消せます

ID をどちらにするかの決定を1つの関数に閉じ込め、 それ以外のコードは ID の中身を一切知らない形にします。 こうすれば分岐は1箇所だけで済み、テストもその関数に2パターン書けば足ります。

逆にこれをやらずに ID を扱う全箇所へ分岐を散らすと、切替が現実的に不可能になります。 この形で実装しますので、恒久的な負担は生じません。

1点だけ確認させてください（D-4）。 「切り替える可能性がある」のは id と error_id のどちらを使うかであって、 型は両方とも varchar のままという理解でよいでしょうか。 もし将来 id を数値型（bigint auto_increment）に変える可能性があるなら、 API の型が文字列から数値に変わる破壊的変更になり、切替の難度が大きく上がります。

2. 当方で変更するもの（回答不要）

ご回答を受けて、こちらの画面仕様を次のように変更します。 認識に相違があればご指摘ください。

3. 追加でお伺いしたいこと（4件）

D-1 ★link_schedules.intervals の書式★

VarChar(120) で「時間帯別の設定（単位: 秒）」とのことですが、書式が分かりません。

実際に入っている値の例を1〜2件いただけますか。 （例: 0-6:600,6-22:120,22-24:600 のような形なのか、JSON なのか、区切り文字は何か）

これが分からないと通信断の判定が実装できません。

D-2 ★robot_error_reports.error_type に実際に入る値★

清掃詳細ログには、清掃開始の60分前・30分前のロボット状態を出す欄があります。 表示する値は6種類ですが、いただいた robots.status のコード表と突き合わせると 3つが対応先不明です。

この3つは robot_error_reports.error_type から判定することになると考えています。

先の回答で「error_type は PUDU Cloud 由来で列挙が未定義。プログラム側で分類する必要がある」と 伺っていますが、実際に入っている値をご存じの範囲で列挙いただけますか（網羅でなくて構いません）。 分類ルールはこちらで作り、未知の値は「その他」に寄せます。

D-3 「セキュリティ解除されたまま」の判定

Q1-3 で「制御盤のアラートは生死報告がないだけ」と伺いました。 一方で画面には「セキュリティが解除されたまま戻っていない」というアラートを出したいと考えています。

これは security_statuses.status = 0（セキュリティ無効）が続いている状態から、 当方で導出してよいでしょうか。 制御盤側でこれを検知してどこかに記録している、ということはありませんか。

D-4 PrecheckItem.id の型（1-2 の再掲）

切替の対象は「id と error_id のどちらを使うか」だけで、 型は varchar のままという理解でよいですか。

おわりに

D-1・D-2 についてご回答をいただければ、D-Secログの通信断判定と 清掃詳細ログの状態表示が完成します。 それまでの間も画面とAPIの骨格は作れますので、作業は止まりません。

C（修正版DDL）は本日中とのこと、ありがとうございます。 受領しましたら prisma db pull で機械的に取り込み、差分をご報告します。