GitBucket
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 ブロックからの項目抽出 / 追加されるはずの制約名の全文検索）で行い、いずれも同じ結果でした。
伺いたいこと:
- これらは「これから対応」という理解でよいでしょうか。 それとも 意図的に見送られたものがありますか（あれば、その旨だけ教えていただければ こちらは現行DDLに合わせて実装します）
- 対応いただける場合、まとまった段階で改めて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週 |
伺いたいこと:
- サマリテーブル側も同じルールでしょうか。 もし「週の開始日が属する月」で数えておられる場合、上の例は8月の週になり、 当方の画面（9月第1週）と食い違います
- 違っていた場合、どちらに合わせるべきかご意見をいただけますか。 当方はどちらでも実装できます
なお月次・年次は暦月・暦年の日単位で締める（週とは独立）認識です。
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 は、当方の作業を止めていません
引き続きよろしくお願いします。