# TeamWorks 様 確認事項（第4回）— 修正版DDLの照合結果と追加確認

**作成: 2026-09-07 / 作成者: DFA**
**対象DDL: `clean_watch_20260907.sql`（2026-09-07 10:29 受領）**

修正版のDDLをありがとうございました。**受領したその日に照合しています。**

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

| 区分 | 件数 | 性質 |
|---|---|---|
| **1. 修正版DDLの照合結果** | 7件中2件が反映 | **5件がまだ入っていません。** 状況をお知らせください |
| **2. 新しくお願いしたいこと** | 2件 | **W-1 は集計の食い違いに直結します** |
| **3. 第3回からの継続** | 2件 | まだ回答をいただいていないもの |

> 第3回でお伺いした **D-3（セキュリティ解除の判定）は当方で解決しました。**
> 「制御盤の生死報告」と「セキュリティ解除の状態」は別の概念で、
> 生死報告が来ない場合はサーバーから制御盤異常としてエラーが上がるが、
> **セキュリティ解除はエラーにならず別の値で管理される**、という整理です。
> `security_statuses.status = 0` の継続から当方で導出します。**回答は不要です。**

---

## 1. 修正版DDLの照合結果

`clean_watch_20260902.sql` との差分は**14行**でした。テーブル数は 39 で変化ありません。

### 反映されていたもの（2件）— ありがとうございました

| 内容 | 変化 |
|---|---|
| `customer_contacts.contact_type` | `bigint unsigned` → **`tinyint unsigned`** |
| `clean_task_reports` の `created_at` / `updated_at` | **`DEFAULT CURRENT_TIMESTAMP`** を付与（`updated_at` は `ON UPDATE` 付き） |

### ★まだ入っていないもの（5件）★

| # | お願いしていた内容 | 現在のDDL |
|---|---|---|
| **A-1** | `error_id` を主キーと位置付けて対応 | **PRIMARY KEY 無しのまま。** UNIQUE KEY は `error_id` のみ |
| **A-2** | 履歴テーブルの `id` を auto_increment で採番 | `clean_status_histories.id` / `clean_timetable_histories.id` とも **AUTO_INCREMENT 無し**。ファイル全体の `AUTO_INCREMENT` 数が **50 で 09-02 版と同数** |
| **A-3b** | `email` を両テーブルとも `varchar(100)` | **`facility_contacts.email` が `varchar(255)` のまま**（`contact_type` だけ直っています） |
| **B-1** | 外部キー3本を追加 | **3本とも無し。** `CONSTRAINT` 総数が **48 で 09-02 版と同数**。制約名（`clean_statuses_clean_timetable_id_foreign` 等）を全文検索しても見つかりません |
| **B-2** | `robot_task_versions.clean_schedule_id` にインデックス | KEY は `robot_id` のみ |
| **B-3b** | `security_status_histories.reported_at` に DEFAULT | **`timestamp NOT NULL` のまま** |

照合は**3つの方法**（09-02版との全体差分 / 各 `CREATE TABLE` ブロックからの項目抽出 /
追加されるはずの制約名の全文検索）で行い、いずれも同じ結果でした。

**伺いたいこと:**

1. **これらは「これから対応」という理解でよいでしょうか。** それとも
   **意図的に見送られた**ものがありますか（あれば、その旨だけ教えていただければ
   こちらは現行DDLに合わせて実装します）
2. 対応いただける場合、**まとまった段階で改めてDDLをいただけますか。** 目安の時期があれば

> **急かす意図はありません。** 上記5件は**いずれも当方の開発を止めていません。**
> こちらは受領したDDLをそのまま `prisma db pull` で取り込む運用にしているため、
> **状況が分かれば十分**です。

---

## 2. 新しくお願いしたいこと（2件）

### W-1 ★月跨ぎの週を、どちらの月に数えていますか★

**週次サマリを作成いただくのは TeamWorks 様側**という理解です（毎週日曜 6:00 / 前週 日〜土）。
一方、進行中の週（当期）は当方が詳細テーブルから集計します。
**両者で「週の帰属」が食い違うと、同じ週が別の月に集計されます。**

**当方は次のルールで実装します。**

> **その月の1日を含む週が、その月の第1週。**
> 言い換えると「**1日でも翌月が混ざれば、その週は翌月の第1週**」

具体例:

| 週 | 当方の扱い |
|---|---|
| `2026-08-23(日) 〜 08-29(土)` | 8月の週 |
| **`2026-08-30(日) 〜 09-05(土)`** | ★**9月第1週**★（8/30・8/31 を含むが 9月に数える） |
| `2026-09-06(日) 〜 09-12(土)` | 9月第2週 |

**伺いたいこと:**

1. **サマリテーブル側も同じルールでしょうか。**
   もし「週の開始日が属する月」で数えておられる場合、上の例は**8月の週**になり、
   **当方の画面（9月第1週）と食い違います**
2. 違っていた場合、**どちらに合わせるべきかご意見をいただけますか。**
   当方はどちらでも実装できます

なお月次・年次は暦月・暦年の日単位で締める（週とは独立）認識です。

### W-2 `robot_error_reports.error_type` に入る値の一覧をご作成いただけますか

第3回でもお伺いした件です。**実装は止めずに進めます**（未知の値はすべて「その他」に寄せます）が、
**一覧をいただければ分類の精度が上がります。**

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

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

**網羅でなくて構いません。** 実際に流れている値を、お手元で確認できる範囲で
書き出していただけると助かります（例: 直近1か月の `SELECT DISTINCT error_type` の結果など）。

**急ぎではありません。** 届いた時点で分類ルールに追加します。

---

## 3. 第3回からの継続（2件）

| # | 内容 | 状態 |
|---|---|---|
| **D-1** | `link_schedules.intervals`（`VarChar(120)`）の**書式**。実際に入っている値の例を1〜2件 | **★これが分からないと D-Secログの通信断判定が実装できません★** 最優先でお願いします |
| **D-4** | `PrecheckItem.id` の切替対象は「`id` と `error_id` のどちらを使うか」だけで、**型は `varchar` のまま**という理解でよいか | 継続。数値型に変わる可能性があるなら、API の破壊的変更になるため事前に知りたいです |

**継続（第1回から）**: **DB更新用アカウントの発行**（`robot_error_reports` /
`control_error_histories` の `status` / `comment` / `responded_at` / `resolved_at` のみ UPDATE 可）。

---

## おわりに

**優先度をつけるとすれば D-1 → W-1 → 1の5件 → W-2 の順**です。

- **D-1** が無いと D-Secログの通信状態が出せません
- **W-1** は集計の数字が食い違う話なので、実装が進む前に揃えておきたいです
- **1の5件** と **W-2** は、当方の作業を止めていません

引き続きよろしくお願いします。