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

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

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

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

| 区分 | 件数 | 性質 |
|---|---|---|
| **1. ご質問への回答** | 2件 | 第2回でいただいた逆質問へのお答え |
| **2. 当方で変更するもの** | 4件 | **回答不要。** 認識に相違があればご指摘ください |
| **3. 追加でお伺いしたいこと** | 4件 | **D-1・D-2 が解決しないと画面の中身が埋まりません** |

---

## 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. 当方で変更するもの（回答不要）

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

| # | 変更 | 根拠となったご回答 |
|---|---|---|
| 2-1 | **D-Secログの「通信状態」を3状態（正常 / 通信断 / 異常）から2状態（正常 / 異常）に変更** | `controls.status` が 0/1 の2値で、かつ「異常＝生死報告が来ていない」とのことなので、**通信断と異常は同じもの**だと理解しました |
| 2-2 | **D-Secアラートの「種別」列を落とす** | 制御盤で発生するアラートは**「生死報告がない」の1種類だけ** |
| 2-3 | **アラートの「詳細」列も落とす** | 種別が1つしかないため詳細文が存在しない |
| 2-4 | **通信断の判定は `control_reports.reported_at` からの経過時間で行い、しきい値は `link_schedules.intervals` から取る** | Q1-2 のご回答どおり。書式のみ D-1 で確認させてください |

---

## 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つが対応先不明**です。

| 画面に出す値 | `robots.status` の対応 |
|---|---|
| 待機中 | `0` Standby |
| 充電中 | `201` Charging Line / `202` Charging Pile |
| セキュリティ有効 | `security_statuses.status = 1` から判定 |
| **ハンドルアップ** | **該当なし** |
| **緊急停止** | **該当なし** |
| **オフライン** | **該当なし** |

この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` で機械的に取り込み、差分をご報告します。