# TeamWorks 様 確認事項（第10回）

**作成: 2026-10-01 / 作成者: DFA Robotics**

**第9回（2026-09-17 送付）につきましては、まだご回答を受け取っておりません。**
お忙しいところ恐れ入りますが、本書に載せ直した項目について、ご回答をお願いいたします。

**2026-10-01、ステージング（`clean_watch`）に実データが入ったことを確認いたしました。** ありがとうございます。それによって生じた確認事項も、本書にまとめております。

> ★**第9回の設問のうち、本書に載っていないものはご回答不要です。**★
> ★**第9回のお願い（12章の3件・9章の DDL 2件）も、ご対応不要です。**★
> 第9回の番号は振り直しておりません（「第9回 Q7-3」のように参照いたします）。
> 新しい設問には `N-1`〜`N-14` の番号を付けております（`N-7` は欠番です）。

## まずお答えいただきたい2つ

1. ★**1章 N-14**★ — ステージング・本番DBのタイムゾーンと、時刻の列に書く値（a〜d）。画面の時刻の表示に直結します
2. ★**2章 N-2 / N-3 / N-4**★ — `status` の値の意味 / `clean_ratio` の作り方 / `task_area`・`clean_area` の意味。画面の「清掃結果」「完了率」「総清掃面積」がこの3列で決まります

# 1. ステージングの投入予定・タイムゾーン

### N-6. ステージングの入れ替えと、今後の投入予定について

当方が以前に入れた検証用のダミーデータは見当たらなくなり、2026-09-30 の夜〜10-01 の未明に実データが入ったと見ております。
ただし `robot_error_reports` の11行中10行は、`created_at`（09-30 15:20〜10-01 01:10）が、その行の `robot_id` が指す `robots` の行の `created_at` より前になっております（例: ロボット10番のエラーの行は 09-30 15:20、`robots` の10番の行は 10-01 00:07。時刻は DB に入っている値そのままで、日本時間と読んでおります）。`groups` / `customers` / `facilities` / `sections` / `robots` / `controls` / `link_schedules` は、いずれも 09-30 23:25〜10-01 00:09 に作られております。

| # | 当方の理解・お伺いしたいこと | ご回答 |
|---|---|---|
| a | 当方のダミーは貴社で削除いただき、2026-09-30 の夜〜10-01 の未明に実データを入れていただいた | YES / NO |
| b | **今後は、このステージングの中身を消して入れ直すことは無い**（データが積み上がっていく） | YES / NO（NO の場合、次の入れ替えの予定をお教えください） |
| c | `robot_error_reports` の行が、指している `robots` / `facilities` の行より前に作られている理由（施設・ロボットの行を同じ番号のまま作り直されたのでしょうか） | お分かりになる範囲で結構です |

**b をお伺いするのは**、当方がこのステージングで4カラム（`status` / `comment` / `responded_at` / `resolved_at`）の更新を検証させていただくためです。
4カラム以外には書き込みませんが、実データのエラー行の「対応状況」が書き換わることがございます。入れ替えの予定がございましたら、その前後は検証を控えます。

**あわせて、まだ0行のテーブルについて、入る時期の目安をお教えください。**

| テーブル | 0行の間に、当方の画面で起きていること | 時期の目安 |
|---|---|---|
| `clean_schedules` / `clean_timetables`（清掃の予定） | 清掃詳細ログ・ダッシュボード・アラートが空です | |
| `customer_summaries` / `facility_summaries` | レポート画面の確定期間が空です。最初の週次バッチ（2026-10-04（日）6:00）から作られる、という理解でよろしいでしょうか | |

### N-10. 当方が以前に受け取った `clean_task_reports` のCSV（189行）は、どの環境のデータでしょうか

本書2章の分析の一部は、このCSVに基づいております。
ID の体系から当時のステージングとは別のDBのものと見ておりますが、ステージングに入った2行の `task_area`（`1377.39502` / `898.892509`）がCSVの中の値と一致しましたので、同じ収集処理が書いたデータと考えております。

| 選択肢 | 内容 |
|---|---|
| A | 本番DBから出したもの |
| B | 開発など、ステージング・本番以外の環境のもの |
| C | その他（お教えください） |

**ご回答は記号だけで結構です。**
あわせて「Pudu Cloud から実際に返った値か、手で作った値か」をお教えいただけますと助かります（手で作った値でしたら、当方は2章の分析を取り下げます）。

### N-14. ステージング・本番DBのタイムゾーンと、時刻の列に書く値について（★**本章で最優先**★）

第8回では、次のとおりご回答いただいております（原文のまま）。

> A2.JSTです.
> （@@time_zone = SYSTEM / @@system_time_zone = JST）
> システムが生成する日付時刻はJSTで生成, PUDUから返却される値はUNIX時間なので, JSTで補正して格納する, としています.

2026-10-01 にステージングを読み取りのみで確認したところ、**サーバーの時計は UTC**（`@@system_time_zone = UTC`）ですが、**書き込まれている値は列の型（TIMESTAMP / DATETIME）によらず JST** でした。第8回 A2 の「システムが生成する日付時刻はJSTで生成」のとおりと理解しております。

そのうえで、**9時間ずれて見える列が2つ**ございます。

- **`control_reports.reported_at`**: 11行とも、同じ行の `created_at` の**ちょうど9時間前**です（UTC で書かれているように見えます）
- **`robot_error_reports.errored_at`**: 行の `created_at` の**約9時間後**です（例: 行の作成 09-30 21:40 / `errored_at` 10-01 06:31）。清掃は夜の21時台に始まっておりますので、JST への補正が二重にかかっているように見えます

| # | お伺いしたいこと | 選択肢 |
|---|---|---|
| a | `control_reports.reported_at` に書いている時刻の基準 | A. JST / B. UTC / C. その他 |
| b | `robot_error_reports.errored_at` に書いている時刻 | A. Pudu の値を JST に補正したもの / B. 補正なし / C. その他。あわせて、`created_at` の約9時間後になっている理由をお分かりになる範囲で |
| c | `created_at` / `updated_at` は、常に値を明示して書いておりますでしょうか | YES / NO（NO の場合、既定値 `current_timestamp()` によりその行だけ UTC が入ります） |
| d | **本番DBも同じ（サーバーは UTC、書き込む値は JST）でしょうか** | A. 同じ / B. 違う（どう違うかをお教えください）/ C. 未定 |

当方は DB の値をそのまま JST として表示しておりますので、D-Security ログの「最終通信」は9時間早く、アラートのエラー検知時刻は9時間遅く出ております。ご回答をいただくまで、当方では補正いたしません。

# 2. `clean_task_reports` の仕様

当方は清掃の実績を `clean_task_reports` から読み、清掃の予定（`clean_timetables`）とは `clean_timetable_id` で突き合わせております。

### N-1. 「予定外のタスク」は、`clean_timetable_id` が NULL であることだけで見分けてよろしいでしょうか

「清掃予定をサーバーで決められるものは `clean_timetable_id` が発行され、予定外のタスクは NULL になる」と伺っております。
ステージングの2行はどちらも NULL ですが、`clean_timetables` がまだ0行のため、「予定外のタスク」なのか「予定がまだ入っていないための NULL」なのかを区別できておりません。

| 選択肢 | 内容 | 当方の動き |
|---|---|---|
| **A** | **NULL であることだけで十分**（NULL ＝ 予定外のタスク） | このまま実装します（ご回答はこの一言で結構です） |
| B | ほかに区別する列がある（列名をお教えください） | その列で見分けます |
| C | 予定外でなくても NULL になる場合がある（例: 予定との引き当てに失敗した場合 など） | その場合を見分ける方法をお教えください |

C に当たるかどうかの参考までに、ステージングの2行がどちらかもお教えいただけますと助かります。

### N-2. `clean_task_reports.status`（清掃結果）の値の意味をお教えください

テーブル定義書の備考が空欄でしたので、値の意味が分かっておりません。
ステージングの2行はどちらも `status = 4` ですが、1行は `clean_ratio = 100`、もう1行は `clean_area = 0` / `clean_ratio = 0` / `clean_time = 0` でした。

| 値 | CSV での行数 | ステージングでの行数 | 意味（ご記入をお願いします） |
|---|---|---|---|
| 3 | 2 | 0 | |
| 4 | 161 | 2 | |
| 5 | 4 | 0 | |
| 6 | 22 | 0 | |
| その他の値 | — | — | 入りうる値があればお教えください |

Pudu Cloud の値をそのまま入れている場合は、その旨と、Pudu 側の項目名だけお教えいただければ結構です。

### N-3. `clean_task_reports.clean_ratio` は、どのように作られていますでしょうか

テーブル定義書の備考は「清掃実施面積 / 清掃対象面積 で計算する」、第2回のご回答（B-3）は「取得元で 100 に丸められるため上限は 100」でした。
ところが当方が受け取ったCSVでは、**`clean_area > task_area` の行が189行中129行**あり、`clean_area ÷ task_area` と `clean_ratio` が一致しない行が多くございます。

| 選択肢 | 内容 |
|---|---|
| A | **Pudu Cloud が返す値をそのまま入れている**（面積から計算していない） |
| B | 貴社で計算している（式をお教えください） |
| C | その他 |

当方は清掃完了率として `clean_ratio` をそのまま使い、複数回の清掃は単純平均（清掃1回＝1票）で束ねております。差し支えがございましたらお知らせください。

### N-3 にあわせて — 第9回3章（第8回 Q4）の再掲：サマリの率・件数の式

第8回で「多いので後で回答」とご留保いただいた件です（丸めは「小数第2位以下切り捨て」と伺いました）。
当方は当期（進行中の週・月）を「清掃1回ごとの `clean_ratio` の単純平均」で出しておりますので、サマリが面積の比で作られていると、週が切り替わったところで数字が段差になります。

| サマリの列 | 当方の理解 | ご回答（分子 ÷ 分母） |
|---|---|---|
| `operation_ratio`（稼働率） | 清掃実施回数 ÷ 清掃予定回数 | |
| `launch_ratio`（出発成功率） | 定刻出発回数 ÷ 清掃予定回数 | |
| **`clean_ratio`（清掃完了率）** | **清掃1回ごとの `clean_ratio` の平均？ それとも Σ`clean_area` ÷ Σ`task_area`？** | |
| `error_ratio`（エラー発生率） | エラー発生回数 ÷ 清掃実施回数 | |
| `task_count` | 清掃予定回数 | |

あわせて、予定外のタスク（`clean_timetable_id` が NULL の行）が `task_count` に入るかもお教えください。
定義書の比率の備考にある「補足を参照.」の補足の本文を、当方はまだ受け取っておりません。文書としてお持ちでしたら、それをお送りいただくだけで結構です。

### N-4. `task_area` と `clean_area` は、それぞれ何の面積でしょうか

テーブル定義書では `task_area` = 清掃対象面積 / `clean_area` = 清掃実施面積 ですが、当方の社内で「`task_area` が実際に清掃した面積ではないか」という話が出ました。
定義書どおりなら N-3 の129行は「対象より広く清掃した」ことになり、逆に読むとステージングの1行（`task_area = 1377.39502` / `clean_area = 0` / `clean_time = 0`）は「0秒で約1,377㎡を清掃した」ことになって、どちらも説明がつきません。

| 選択肢 | 内容 |
|---|---|
| A | **定義書どおり**（`task_area` = 清掃対象面積 / `clean_area` = 実際に清掃した面積） |
| B | `task_area` が実際に清掃した面積（その場合 `clean_area` は何かをお教えください） |
| C | Pudu Cloud の値をそのまま入れている（意味は Pudu の定義による） |

当方は「総清掃面積」の画面で `clean_area` を足し上げております。B の場合は足す列を差し替えます。

### N-8. 1つの `clean_timetable_id` に対して、`clean_task_reports` は何行できますでしょうか

ステージングの1行は `created_at` 00:45 の後、`updated_at` 01:55 に更新されておりましたので、A と読んでおります。

| 選択肢 | 内容 |
|---|---|
| A | **必ず1行**（清掃1回につき1行。途中経過は同じ行を更新する） |
| B | **複数行できる**（例: 中断して再開した場合 など。どんなときかをお教えください） |

### N-9. 「その清掃が何日の清掃か」は、どの列で決まりますでしょうか

ステージングの2行は、どちらも 9/30 の夜に始まり（`started_at`）、10/1 に終わっております（`ended_at`）。
定義書の `created_at` の備考は「清掃日を設定(Y-m-d 23:59:59)」ですが、実際の値は 10-01 00:45:03 です。
サマリと当方の当期集計で日の決め方がそろっていないと、月末・週末の清掃が別の期間に数えられます。

| 選択肢 | 内容 |
|---|---|
| A | `started_at` の日付 |
| B | `created_at`（定義書の「Y-m-d 23:59:59」は古い記載か、今後そうなるのか、もお教えください） |
| C | 予定（`clean_timetables.start_at`）の日付（予定外のタスクの場合はどうなるか、もお教えください） |
| D | その他 |

# 3. エラーの集約

当方は、制御盤のエラーも含めて、エラーの情報は `robot_error_reports` に集約されると理解しております。

### N-5. 制御盤のエラーは、`robot_error_reports` にどのように入りますでしょうか

DDL では `robot_id` が NOT NULL・`robots(id)` への外部キーで、どの制御盤のエラーかを記録する列（`control_id` 相当）がございません。
ステージングの11行はすべて `error_type = LostLocalization` で、制御盤由来と見られる行はまだございません。

| # | お伺いしたいこと | 選択肢 |
|---|---|---|
| a | 制御盤のエラーの入れ方 | A. 制御盤が属するエリアのロボットの `robot_id` を入れる / B. DDL を変更する（`robot_id` を NULL 可にする、`control_id` を足す など）/ C. その他 |
| b | **`control_error_histories` は、今後も書かれますでしょうか** | A. 今後も書く（両方に入る）/ B. 書かない（`robot_error_reports` だけ）/ C. しばらくは両方、いずれ片方 |

a は、あわせて**制御盤由来の行を見分ける方法**（`error_type` の値など）をお教えください。
b は、第8回 A8 で「使います」と伺っておりましたので確認です。当方の D-Security アラート画面は、いまは `control_error_histories` から作っております。

### 第9回 Q4-3 の聞き直し — 制御盤のエラーは、サマリの `error_count` に入りますでしょうか

当方が `clean_error` を持つ表を読まなくなりましたので、伺い方を改めました。当期の集計をサマリと同じ数え方にそろえるための確認です。

| 選択肢 | 内容 |
|---|---|
| A | **含む**（`robot_error_reports` に入った制御盤のエラーも数える） |
| B | **含まない**（ロボットのエラーだけを数える。その場合、何で見分けているかを一言） |

### N-11. `robot_error_reports` の行が、事前チェック・本清掃・清掃時間外のどれで起きたものかは、どう見分ければよいでしょうか

当方はこれまで、`clean_timetable_id` から予定（`clean_timetables.precheck`）を引いて見分けておりました（第8回 A7）。
ステージングの11行は、すべて `clean_timetable_id` が NULL です。`errored_at` は N-14 のとおり9時間ずれている可能性がございますので、発生時刻の時間帯から清掃中かどうかを読むことは控えております。

| 選択肢 | 内容 |
|---|---|
| A | **予定が入れば、`clean_timetable_id` が埋まる**。事前チェック・本清掃は `precheck` で見分けられる。清掃時間外・予定外のタスク中のエラーは NULL のまま |
| B | 別の方法で見分ける（お教えください） |
| C | 見分けられない |

**A であれば、ご回答は記号だけで結構です。**

# 4. サマリ

当方は、確定した期間の数字をサマリ（週・月・年）から読み、進行中の期間は詳細のテーブルから集計しております。

### 第9回 Q4-1. サマリの `error_count` は、事前チェック（`precheck = 30 / 60`）のエラーを除いて数えていますでしょうか（再掲）

第8回 A7 の「サマリには含めない、とするのが正しいでしょう」が、バッチの実際の動きなのかご見解なのかを読み取れませんでしたので、改めて伺います。

| 選択肢 | 内容 |
|---|---|
| A | 除いている（本清掃 `precheck = 0` のみ） |
| B | 除いていない |

### 第9回 Q4-2. `clean_timetable_id` が NULL のエラー行は、サマリの `error_count` に含まれますでしょうか（再掲）

ステージングのエラー行は、現在11行すべてが NULL です（N-11）。**B の場合、いまのエラーは1件もサマリに数えられません。**

| 選択肢 | 内容 |
|---|---|
| A | 含む |
| B | 含まない |

### 第9回 Q6-1. グループ（ホールディングス）単位の集計は、どちらの想定でしょうか（再掲）

ステージングの `customers` が2行になり、複数の顧客の数字をまとめて出す場面がすでに生じております。

| 選択肢 | 内容 |
|---|---|
| A | **当方が `customer_summaries` の複数行を合算する**（テーブルの追加は不要） |
| B | `group_summaries` を追加してバッチで集計する |
| C | グループ単位の集計は想定していない |

A の場合、当方は率を「Σ分子 ÷ Σ分母」で計算し直しますので、次の設問の材料が要ります。

### 第9回 Q6-2 と Q11-3 をまとめて — 「清掃実施回数」として `launch_count` を使ってよろしいでしょうか

実施回数の列の追加につきましては「`launch_count` と違いが無いので検討中」と伺いましたので、2問を1問にまとめました。

| ご回答 | 当方の動き |
|---|---|
| **A. よい**（`launch_count` ＝ 清掃を実施した回数） | 列の追加のお願いは取り下げ、稼働率・エラー発生率の合算と検算に `launch_count` を使います（ご回答はこの一言で結構です） |
| B. 違う | `launch_count` が何を数えているかを一言お教えください（例: 予定時刻から〇分以内に出発したものだけ） |

A の場合、`operation_ratio`（稼働率）と `launch_ratio`（出発成功率）は同じ値になるはずと考えております。違う場合は、その違いを1行でお教えください。

### N-12. 年次サマリは、毎年1月1日 6:00 に前年分が作られる、という理解でよろしいでしょうか

週次（毎週日曜）・月次（毎月1日）は伺っておりますが、年次は明示のご確認をいただいておりませんでした。

**YES / NO**（NO の場合、作られる時期をお教えください）

# 5. グループ・顧客マスタ

第9回でお願いしていたマスタの投入を、ステージングで確認いたしました。ありがとうございます。

### 第9回7章のお願い（マスタ投入）— 投入はこれで一区切りでしょうか

| 選択肢 | 内容 |
|---|---|
| A | **P1 の開始時点ではこの形**（施設が増えるときに足していく） |
| B | まだ追加の予定がある（時期の目安をお教えください） |

### 第9回 Q7-1・Q7-2・Q7-5. 屋号の扱い — 結論の時期の目安

「検討中」と伺っております。いまは `customers` に法人名（株式会社ドン・キホーテ）で入っておりますので、第9回 Q7-1 の選択肢 B（法人の粒度）と読んでおります。
結論が出る時期の目安だけ、お教えいただけますでしょうか（急かすものではございません）。

| ご回答 | 当方の動き |
|---|---|
| 時期の目安 | 「〇月ごろ」の形で結構です。それまでは、いまの法人の単位のまま表示します |
| 法人で確定 | 絞り込みの見出しを「屋号」から「顧客」に変えます（画面は増えません）。第9回 Q7-1・Q7-2・Q7-5 はご回答不要になります |

### 第9回 Q7-3. `facilities.shop_id` は何を表す列でしょうか（再掲）

いまは値が入っており、11件とも9桁の数字で、先頭は「5」、すべて異なる値です。

| 選択肢 | 内容 |
|---|---|
| A | **顧客側（ドン・キホーテ様）の店舗コード** |
| B | 貴社（または Pudu）が振った番号 |
| C | その他 |

### 第9回 Q7-4. グループに属さない顧客（`group_id = 0`）は、どの形で扱われますか（再掲）

`customers.group_id` は「NOT NULL・既定値 0・0 はグループなし」と伺っております。ところが外部キー制約（`customers_group_id_foreign` → `groups.id`）があるため、`groups` に `id = 0` の行が無いと、`group_id = 0` の顧客は投入できないように見えます。今回投入いただいた2社は、どちらもグループに属しております。

| 選択肢 | 内容 | 当方の動き |
|---|---|---|
| A | `groups` に `id = 0` の行（グループなし）を1件入れる（INSERT には `NO_AUTO_VALUE_ON_ZERO` が要ります） | 「グループなし」を表示します |
| B | 外部キー制約 `customers_group_id_foreign` を外す | 「グループなし」を表示します |
| C | `group_id` を NULL 可にする | NULL を「グループなし」として表示します |
| **D** | **グループに属さない顧客は作らない**（必ずどこかのグループに属する） | 「グループなし」の表示を作りません |

ご回答は記号だけで結構です。

# 6. 制御盤の報告間隔

### 第9回 Q8-3（改）. この設定（10秒〜60秒）を、運用の範囲と考えてよろしいでしょうか

`link_schedules` の報告間隔は、D-S制御盤 ⇔ 制御サーバが10秒（0〜6時・21〜23時）/ 60秒（7〜20時）です。
このままですと `control_reports` は2年で約3,900万行の計算です（当方の計算）。

| # | お伺いしたいこと | 選択肢 |
|---|---|---|
| a | 運用中も、報告間隔は10秒〜60秒の範囲に収まる | YES / NO（NO の場合、下限・上限の目安） |
| b | 変更の頻度 | 基本的に変えない / 制御盤ごとに個別に変える / 運用中に随時変える |

**a が YES であれば、ご回答は「YES」と b の一言で結構です。**

# 7. 軽い確認

### 第9回 Q9-2. 1回の清掃の中の、区域別（売り場・通路・レジ前など）の内訳は取得できますか（再掲）

当方が出せているのは「1清掃エリア（＝1ロボット）につき1つの完了率」までです。取得できない場合は「できない」の一言で結構です（当方はこの機能を諦めます）。

### N-13. `clean_schedules.contract` は何に使う列でしょうか

`clean_schedules.contract` は、`facilities.contract`（契約フラグ）と型も既定値も同じ列です。
当方は `facilities.contract` だけを契約フラグとして読んでおります。

| 選択肢 | 内容 |
|---|---|
| A | **読まなくてよい**（用途を一言いただけますと助かります） |
| B | 読むべき（`facilities.contract` との使い分けをお教えください） |

**以上です。ご確認のほど、よろしくお願いいたします。**

繰り返しになりますが、まずは次の2つだけでも先にお答えいただけますと大変助かります。

1. ★**1章 N-14**★ — ステージング・本番DBのタイムゾーンと、時刻の列に書く値（a〜d）
2. ★**2章 N-2 / N-3 / N-4**★ — `status` の値の意味 / `clean_ratio` の作り方 / `task_area`・`clean_area` の意味
