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 に作られております。

b をお伺いするのは、当方がこのステージングで4カラム（status / comment / responded_at / resolved_at）の更新を検証させていただくためです。 4カラム以外には書き込みませんが、実データのエラー行の「対応状況」が書き換わることがございます。入れ替えの予定がございましたら、その前後は検証を控えます。

あわせて、まだ0行のテーブルについて、入る時期の目安をお教えください。

N-10. 当方が以前に受け取った clean_task_reports のCSV（189行）は、どの環境のデータでしょうか

本書2章の分析の一部は、このCSVに基づいております。 ID の体系から当時のステージングとは別のDBのものと見ておりますが、ステージングに入った2行の task_area（1377.39502 / 898.892509）がCSVの中の値と一致しましたので、同じ収集処理が書いたデータと考えております。

ご回答は記号だけで結構です。 あわせて「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 への補正が二重にかかっているように見えます

当方は 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」なのかを区別できておりません。

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 でした。

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 が一致しない行が多くございます。

当方は清掃完了率として clean_ratio をそのまま使い、複数回の清掃は単純平均（清掃1回＝1票）で束ねております。差し支えがございましたらお知らせください。

N-3 にあわせて — 第9回3章（第8回 Q4）の再掲：サマリの率・件数の式

第8回で「多いので後で回答」とご留保いただいた件です（丸めは「小数第2位以下切り捨て」と伺いました）。 当方は当期（進行中の週・月）を「清掃1回ごとの clean_ratio の単純平均」で出しておりますので、サマリが面積の比で作られていると、週が切り替わったところで数字が段差になります。

あわせて、予定外のタスク（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㎡を清掃した」ことになって、どちらも説明がつきません。

当方は「総清掃面積」の画面で clean_area を足し上げております。B の場合は足す列を差し替えます。

N-8. 1つの clean_timetable_id に対して、clean_task_reports は何行できますでしょうか

ステージングの1行は created_at 00:45 の後、updated_at 01:55 に更新されておりましたので、A と読んでおります。

N-9. 「その清掃が何日の清掃か」は、どの列で決まりますでしょうか

ステージングの2行は、どちらも 9/30 の夜に始まり（started_at）、10/1 に終わっております（ended_at）。 定義書の created_at の備考は「清掃日を設定(Y-m-d 23:59:59)」ですが、実際の値は 10-01 00:45:03 です。 サマリと当方の当期集計で日の決め方がそろっていないと、月末・週末の清掃が別の期間に数えられます。

3. エラーの集約

当方は、制御盤のエラーも含めて、エラーの情報は robot_error_reports に集約されると理解しております。

N-5. 制御盤のエラーは、robot_error_reports にどのように入りますでしょうか

DDL では robot_id が NOT NULL・robots(id) への外部キーで、どの制御盤のエラーかを記録する列（control_id 相当）がございません。 ステージングの11行はすべて error_type = LostLocalization で、制御盤由来と見られる行はまだございません。

a は、あわせて制御盤由来の行を見分ける方法（error_type の値など）をお教えください。 b は、第8回 A8 で「使います」と伺っておりましたので確認です。当方の D-Security アラート画面は、いまは control_error_histories から作っております。

第9回 Q4-3 の聞き直し — 制御盤のエラーは、サマリの error_count に入りますでしょうか

当方が clean_error を持つ表を読まなくなりましたので、伺い方を改めました。当期の集計をサマリと同じ数え方にそろえるための確認です。

N-11. robot_error_reports の行が、事前チェック・本清掃・清掃時間外のどれで起きたものかは、どう見分ければよいでしょうか

当方はこれまで、clean_timetable_id から予定（clean_timetables.precheck）を引いて見分けておりました（第8回 A7）。 ステージングの11行は、すべて clean_timetable_id が NULL です。errored_at は N-14 のとおり9時間ずれている可能性がございますので、発生時刻の時間帯から清掃中かどうかを読むことは控えております。

A であれば、ご回答は記号だけで結構です。

4. サマリ

当方は、確定した期間の数字をサマリ（週・月・年）から読み、進行中の期間は詳細のテーブルから集計しております。

第9回 Q4-1. サマリの error_count は、事前チェック（precheck = 30 / 60）のエラーを除いて数えていますでしょうか（再掲）

第8回 A7 の「サマリには含めない、とするのが正しいでしょう」が、バッチの実際の動きなのかご見解なのかを読み取れませんでしたので、改めて伺います。

第9回 Q4-2. clean_timetable_id が NULL のエラー行は、サマリの error_count に含まれますでしょうか（再掲）

ステージングのエラー行は、現在11行すべてが NULL です（N-11）。B の場合、いまのエラーは1件もサマリに数えられません。

第9回 Q6-1. グループ（ホールディングス）単位の集計は、どちらの想定でしょうか（再掲）

ステージングの customers が2行になり、複数の顧客の数字をまとめて出す場面がすでに生じております。

A の場合、当方は率を「Σ分子 ÷ Σ分母」で計算し直しますので、次の設問の材料が要ります。

第9回 Q6-2 と Q11-3 をまとめて — 「清掃実施回数」として launch_count を使ってよろしいでしょうか

実施回数の列の追加につきましては「launch_count と違いが無いので検討中」と伺いましたので、2問を1問にまとめました。

A の場合、operation_ratio（稼働率）と launch_ratio（出発成功率）は同じ値になるはずと考えております。違う場合は、その違いを1行でお教えください。

N-12. 年次サマリは、毎年1月1日 6:00 に前年分が作られる、という理解でよろしいでしょうか

週次（毎週日曜）・月次（毎月1日）は伺っておりますが、年次は明示のご確認をいただいておりませんでした。

YES / NO（NO の場合、作られる時期をお教えください）

5. グループ・顧客マスタ

第9回でお願いしていたマスタの投入を、ステージングで確認いたしました。ありがとうございます。

第9回7章のお願い（マスタ投入）— 投入はこれで一区切りでしょうか

第9回 Q7-1・Q7-2・Q7-5. 屋号の扱い — 結論の時期の目安

「検討中」と伺っております。いまは customers に法人名（株式会社ドン・キホーテ）で入っておりますので、第9回 Q7-1 の選択肢 B（法人の粒度）と読んでおります。 結論が出る時期の目安だけ、お教えいただけますでしょうか（急かすものではございません）。

第9回 Q7-3. facilities.shop_id は何を表す列でしょうか（再掲）

いまは値が入っており、11件とも9桁の数字で、先頭は「5」、すべて異なる値です。

第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社は、どちらもグループに属しております。

ご回答は記号だけで結構です。

6. 制御盤の報告間隔

第9回 Q8-3（改）. この設定（10秒〜60秒）を、運用の範囲と考えてよろしいでしょうか

link_schedules の報告間隔は、D-S制御盤 ⇔ 制御サーバが10秒（0〜6時・21〜23時）/ 60秒（7〜20時）です。 このままですと control_reports は2年で約3,900万行の計算です（当方の計算）。

a が YES であれば、ご回答は「YES」と b の一言で結構です。

7. 軽い確認

第9回 Q9-2. 1回の清掃の中の、区域別（売り場・通路・レジ前など）の内訳は取得できますか（再掲）

当方が出せているのは「1清掃エリア（＝1ロボット）につき1つの完了率」までです。取得できない場合は「できない」の一言で結構です（当方はこの機能を諦めます）。

N-13. clean_schedules.contract は何に使う列でしょうか

clean_schedules.contract は、facilities.contract（契約フラグ）と型も既定値も同じ列です。 当方は 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 の意味