# TeamWorks 回答 — 確認事項 第10回（原文） 受領を確認した日: 2026-10-02（daichi がチャットに貼付。先方の送信日時は未確認） 対応する送付版: `docs/handoff/TeamWorks確認事項_第10回_20261001_送付版.md`（D-153） ★以下は原文のまま。選択肢の記号（A/B/C…）の意味は送付版の各設問を参照★ --- 1.ステージングの投入予定・タイムゾーン --- N-6. ステージングの入れ替えと、今後の投入予定について a. Yes. b. No. 時期は未定だがステージング環境なのでデータの入れ替えはありうる. c. プログラムのtimezoneがJST, データベースのtimezoneがUTCだったため. timezoneをJSTで統一したので, 以降は指摘のような「ズレ」は生じない. 0 行テーブルへのデータ登録は10/5中に何らかのデータを格納する. +++ N-10. 当方が以前に受け取った clean_task_reports のCSV（189行）は、どの環境のデータでしょうか --- c: その他. Pudu Cloudから取得したデータ. 運用開始後はこのようなデータが格納される +++ N-14. ステージング・本番DBのタイムゾーンと、時刻の列に書く値について（本章で最優先） --- a. UTC b. JSTに補正した値. created_atの9時間後はcreated_atがUTCだったため. c. No. default にcurrent_timestamp, on update current_timestamp() としている. 基本的にフレームワーク側でtimezoneを設定し値を暗黙的に投入しているが, 一部のテーブルに対する登録/更新ではフレームワークの機能をOFFにしてデータ投入を行っている場合があり, そのため差が生じた. この件は, 既にデータベース側の設定を変更し, timezoneの規定値を'Asia/Tokyo'と設定し直し, データの再登録を実施済み. mysql> select @@time_zone; +-------------+ | @@time_zone | +-------------+ | SYSTEM | +-------------+ 1 row in set (0.01 sec) mysql> select @@system_time_zone; +--------------------+ | @@system_time_zone | +--------------------+ | JST | +--------------------+ 1 row in set (0.00 sec) +++ N-1. 「予定外のタスク」は、clean_timetable_id が NULL であることだけで見分けてよろしいでしょうか --- A. +++ N-2. clean_task_reports.status（清掃結果）の値の意味をお教えください --- 0 清掃開始前 / 1 清掃中 2 清掃中断 3 清掃キャンセル 4 清掃正常終了 5 清掃異常終了 +++ N-3. clean_task_reports.clean_ratio は、どのように作られていますでしょうか --- B. 計算式が間違っているので, 訂正したら回答する. N-3 にあわせて — 第9回3章（第8回 Q4）の再掲：サマリの率・件数の式 週のサマリは, 集計タスク実行時(毎週日曜日, もしくは毎月1日)の前週日曜日から土曜日を期間として集計する. 清掃1回毎にclean_area / task_area * 100 (100より大きい値は100, 小数点第2位以下切捨て)で計算しているので, これらの値を合算し平均値を求める, となる. ただし, これらの集計値に事前確認の結果は含めない(あくまで確認なので). 具体的にはclean_timetables, もしくはclean_timetable_historiesのprecheckが0のデータのみ, 集計対象となる. これらのことから, 当然clean_taimetable_idがNULLのデータも集計対象外となる. +++ N-4. task_area と clean_area は、それぞれ何の面積でしょうか --- A. clean_area > task_area となるのは清掃対象面積を複数回清掃する場合があるため. clean_areaは清掃した面積の総和. +++ N-8. 1つの clean_timetable_id に対して、clean_task_reports は何行できますでしょうか --- A. +++ N-9. 「その清掃が何日の清掃か」は、どの列で決まりますでしょうか --- A. +++ N-5. 制御盤のエラーは、robot_error_reports にどのように入りますでしょうか --- a. A robot_error_reportsはあくまで清掃ロボットで発生したエラーを格納するテーブルだったが, エラー全般を格納するテーブルとする. そのためいくつかテーブルの仕様を変更する必要がある. 具体的には以下のとおり. robot_id は nullを許可する. serial_number は nullを許可する. robot_id がnull, かつserial_numberが null の場合はセキュリティエラー, robot_id がnull, かつserial_numberが not null の場合はD-S制御盤エラー, robot_id がnot null, かつserial_numberが not null の場合は清掃ロボットエラー とする. セキュリティエラー, D-S制御盤エラーの場合は以下の通り. error_level: CRITICAL error_type: SECURITY_ON / D-S_CONTROL_FAILURE error_detail: security is enabled. / no regular report from the D-S control. b. A +++ 第9回 Q4-3 の聞き直し — 制御盤のエラーは、サマリの error_count に入りますでしょうか --- N-5の回答により, Aが正解となる. +++ N-11. robot_error_reports の行が、事前チェック・本清掃・清掃時間外のどれで起きたものかは、どう見分ければよいでしょうか --- A +++ 第9回 Q4-1. サマリの error_count は、事前チェック（precheck = 30 / 60）のエラーを除いて数えていますでしょうか（再掲） --- A +++ 第9回 Q4-2. clean_timetable_id が NULL のエラー行は、サマリの error_count に含まれますでしょうか（再掲） --- B +++ 第9回 Q6-1. グループ（ホールディングス）単位の集計は、どちらの想定でしょうか（再掲） --- C +++ 第9回 Q6-2 と Q11-3 をまとめて — 「清掃実施回数」として launch_count を使ってよろしいでしょうか --- B. 清掃タスクを開始できた回数。清掃タスクを正常終了できた回数ではない. そのためoperation_ratio とlaunch_ratio は必ずしも一致はしない. +++ N-12. 年次サマリは、毎年1月1日 6:00 に前年分が作られる、という理解でよろしいでしょうか --- Yes. +++ 第9回7章のお願い（マスタ投入）— 投入はこれで一区切りでしょうか --- B, 未定, レビュー後然るべきタイミングで. +++ 第9回 Q7-3. facilities.shop_id は何を表す列でしょうか --- B. PUDUが割り振った番号 +++ 第9回 Q7-4. グループに属さない顧客（group_id = 0）は、どの形で扱われますか --- D. +++ 第9回 Q8-3（改）. この設定（10秒〜60秒）を、運用の範囲と考えてよろしいでしょうか --- a.No 0～3599 b.制御盤ごとに個別に変える control_reports は基盤毎に1レコード用意し, 最終報告日時を格納する.そのためこのテーブルに格納されるレコード数 = D-S制御盤の総数となる. 2年間で3900万行にはならない. +++ 第9回 Q9-2. 1回の清掃の中の、区域別（売り場・通路・レジ前など）の内訳は取得できますか --- できる. sections単位. +++ N-13. clean_schedules.contract は何に使う列でしょうか --- A. clean_timetables, clean_schedulesにレコードを作成する場合, 事前確認のレコードを作成する/しないの基準.