GitBucket
TeamWorks 様 確認事項（第10回）
作成: 2026-10-01 / 作成者: DFA Robotics
★本書は、第9回（2026-09-17 送付）でまだご回答をいただいていない項目と、 ステージングに実データが入ったことで新たに生じた確認事項を、1通にまとめたものです。★ ★第9回の番号は振り直しておりません★（「第9回 Q7-3」のように参照いたします）。 ★新しい設問には
N-1〜N-14の番号を付けております★（★N-7は欠番です★）。 ★当方の管理表の番号ですので、章の順とは一致いたしません。ご了承ください★。
はじめに
★第9回（2026-09-17 送付）につきましては、まだご回答を受け取っておりません。★ ★お忙しいところ恐れ入りますが、★本書に載せ直した項目について、ご回答をお願いいたします★。 ★第9回の項目のうち、当方の事情が変わって不要になったものは取り下げ、10章に一覧にしております★。
★2026-10-01、ステージング（133.125.238.144 / clean_watch）に実データが入ったことを確認いたしました。★ ありがとうございます。★当方が以前に入れた検証用のダミーデータも見当たらなくなっておりました★ （ご対応いただいたものと存じます。1章でその確認をお願いしております）。
★第9回12章（DB接続経路。お願い3件・Q12-1〜Q12-6）は、弊社内で「検証段階のため保留とし、 顧客へ配布する段階で改めて検討する」ことにいたしました。★ ★本書ではお伺いいたしません。ご対応も不要です★（10章）。
★あわせて、第9回の本文に事実と異なる記載が1件ございました。9章で訂正いたします。★
本書の構成
本書は10章構成です（★質問25問 / 参考情報1章 / 訂正1件 / ご報告1章★）。★お願いはございません★。
| # | 内容 | 種別 | 設問数 | お急ぎの度合い |
|---|---|---|---|---|
| 1. ステージングの入れ替えと今後の投入予定・タイムゾーン | ★★タイムゾーン（N-14）は画面の時刻の表示に直結します★★ | 質問 | 3 | ★N-14 は高★ / ほかは中 |
2. clean_task_reports の仕様 |
★★status の意味・clean_ratio・面積2列（N-2 / N-3 / N-4）★★ほか |
質問 | 7 | ★N-2・N-3・N-4 は高★ / ほかは中 |
| 3. エラーの集約 | ★制御盤エラーの入れ方 / 事前チェックとの見分け方★ | 質問 | 3 | 中 |
| 4. サマリ | ★第9回 Q6-2 と Q11-3 を1問にまとめました★ | 質問 | 5 | 中 |
| 5. グループ・顧客マスタ | ★投入ありがとうございます。残りの確認です★ | 質問 | 4 | 中 |
| 6. 制御盤の報告間隔 | ★入った設定値で確認の形に改めました★ | 質問 | 1 | 低 |
| 7. 軽い確認 | ★「できない」「不明」の一言でも結構です★ | 質問 | 2 | 低 |
| 8. 参考 — 索引 | ★ご依頼ではありません。当方が見ている列の差し替えです★ | ★参考情報★ | — | — |
| 9. 訂正1件 | ★第9回 6-2 の理由説明★ | ★訂正★ | — | — |
| 10. 当方の方針・伺った内容のご報告と、取り下げる設問 | ★差し支えがあればお知らせください★ | ★ご報告★ | — | — |
★★お急ぎの度合い★★
| 度合い | 章・番号 | 理由 |
|---|---|---|
| ★高★ | ★1章 N-14★（タイムゾーンと時刻の列） | ★★画面の時刻の表示に直結します★★（★D-Security ログの「最終通信」などがずれる恐れ★） |
| ★高★ | ★2章 N-2 / N-3 / N-4★（status の意味 / clean_ratio の作り方 / task_area・clean_area の意味） |
★★実データが入り、画面の「清掃結果」「完了率」「総清掃面積」がこの3列で決まる状態になりました★★ |
| 中 | 1章（N-14 以外）/ 2章（N-2〜N-4 以外）/ 3章 / 4章 / 5章 | ★画面の数字の意味・段差に関わります★ |
| 低 | 6章 / 7章 | ★いま困ってはおりません★ |
| — | 8章 / 9章 / 10章 | ★ご回答は不要です★（10章は、当方の方針に差し支えがある場合のみお知らせください） |
★★まずは「1章の N-14」と「2章の N-2 / N-3 / N-4」だけでも、先にお答えいただけますと大変助かります。★★ ★いずれも YES / NO・選択肢の記号、または値の意味の一覧でお答えいただけるようにしております★。
★本書に出てくる数字の出所★
| 表記 | 意味 |
|---|---|
| ★構造★ | SHOW VARIABLES / SHOW GLOBAL STATUS / information_schema / DDL。★行の中身に左右されません★ |
| ★先方投入★ | ★2026-10-01 に貴社がステージングへ入れられたデータ★を、当方が★読み取りのみ★で数えたもの。★測った時刻は 2026-10-01 12:18〜12:33（JST）★です。★その後の投入で変わっている可能性がございます★ |
| ★CSV★ | ★当方が以前に受け取った clean_task_reports のCSV（189行）★。★出所を1章 N-10 でお伺いしております★ |
| ★当方の計算★ | 上の値から当方が計算したもの。★実測ではございません★ |
★時刻は、DB に入っている値をそのまま書いております★（★日本時間と読んでおります。1章 N-14★）。
1. ステージングの入れ替えと今後の投入予定・タイムゾーン
この章で伺うこと: ★入れ替えの事実確認と、予定のテーブルがいつ入るか（N-6）★ / ★当方が受け取ったCSVの出所（N-10）★ / ★★タイムゾーンと時刻の列（N-14）★★。
1-1. ★当方から見えていること★（★先方投入★。2026-10-01 12:18〜12:22 に測定）
| テーブル | 行数 | 備考 |
|---|---|---|
groups |
2 | 5章 |
customers |
2 | 5章 |
facilities |
11 | ★実店舗10件＋1件★（5章） |
sections / robots / controls |
各 11 | |
link_schedules |
22 | ★1エリアにつき2行★（6章） |
control_reports |
11 | |
robot_error_reports |
11 | 3章 |
★clean_task_reports★ |
★2★ | 2章 |
★clean_schedules★ |
★0★ | |
★clean_timetables★ |
★0★ | |
clean_status_histories |
0 | ★当方はもう読んでおりません★（10章） |
control_error_histories |
0 | 3章 |
customer_summaries / facility_summaries |
0 / 0 | 4章 |
★あわせて、次のことが見えております★。
- ★当方が以前に入れた検証用のダミー（17テーブル・1,787行）は見当たりません★
- ★サーバーは、第9回の時点と同じものです★（★構造★。
@@hostnameが同じで、2026-09-11 以降再起動されていない） - ★マスタ（
groups〜link_schedules）のcreated_atは ★09-30 23:25〜10-01 00:09★ に集まっております★ （★実データが入ったのは 09-30 の夜〜10-01 の未明と見ております★） - ★一方、
robot_error_reportsのcreated_atは ★09-30 15:20〜10-01 01:10★ で、★11行中10行が、指しているrobotsの行より前に作られております★（例: ロボット10番のエラーの行は 09-30 15:20、robotsの10番の行は 10-01 00:07）。robot_idは11行ともrobotsに実在いたします
1-2. お伺いしたいこと（3問）
★N-6. ステージングの入れ替えと、今後の投入予定について★
| # | 当方の理解・お伺いしたいこと | ご回答 |
|---|---|---|
| ★a★ | ★当方のダミーは貴社で削除いただき、2026-09-30 の夜〜10-01 の未明に実データを入れていただいた★ | ★YES / NO★ |
| ★b★ | ★今後は、このステージングの中身を消して入れ直すことは無い★（★データが積み上がっていく★） | ★YES / NO★（★NO の場合、次の入れ替えの予定をお教えください★） |
| ★c★ | ★robot_error_reports の created_at がマスタより前の時刻になっている理由★ |
★お分かりになる範囲で結構です★（★当方には理由が分かりませんでしたので、念のための確認です★） |
★b をお伺いするのは★、★当方がこのステージングで4カラム（status / comment / responded_at / resolved_at）の 更新を検証させていただくためです★（10章）。★入れ替えの予定がございましたら、その前後は検証を控えます★。
★あわせて、まだ0行のテーブルについて、入る時期の目安をお教えください。★
| テーブル | 0行の間に、当方の画面で起きていること | 時期の目安 |
|---|---|---|
★clean_schedules / clean_timetables★（清掃の予定） |
★★清掃詳細ログ・ダッシュボード・アラートが空です★★（★当方は予定を起点に画面を作っております★） | |
customer_summaries / facility_summaries |
★レポート画面の確定期間（前週・前月）が空です★。★★最初の週次バッチ（2026-10-04（日）6:00）から作られる★★、という理解でよろしいでしょうか |
★N-10. 当方が以前に受け取った clean_task_reports のCSV（189行）は、どの環境のデータでしょうか★
★本書2章の分析の一部は、このCSVに基づいております★（★出所「CSV」★）。
★当方では、★当時のステージングとは別のDBから出たもの★と見ております（★ID の体系が違うため★）。★ ★一方で、★ステージングに 2026-10-01 に入った2行の task_area（1377.39502 / 898.892509）が、 CSVの中の値と一致した★ため、★同じ収集処理が書いたデータ★と考えております★。
| 選択肢 | 内容 |
|---|---|
| ★A★ | ★本番DBから出したもの★ |
| B | ★開発など、ステージング・本番以外の環境のもの★ |
| C | その他（お教えください） |
★ご回答は記号だけで結構です。★ ★「Pudu Cloud から実際に返った値か、手で作った値か」だけは、念のためお教えいただけますと助かります★ （★手で作った値でしたら、当方は2章の分析を取り下げます★）。
★★N-14. ステージング・本番DBのタイムゾーンと、時刻の列に書く値について（★本章で最優先★）★★
★画面の時刻の表示に直結しますので、本章でお伺いいたします。★
★第8回でいただいたご回答★（2026-09-11 受領。原文のまま）
A2.JSTです. （@@time_zone = SYSTEM / @@system_time_zone = JST） システムが生成する日付時刻はJSTで生成, PUDUから返却される値はUNIX時間なので, JSTで補正して格納する, としています.
★当方の理解★（★ステージング★。2026-10-01。読み取りのみ）
★サーバーの時計は UTC ですが、書き込まれている値は JST です。★ ★第8回 A2 の「システムが生成する日付時刻はJSTで生成」のとおりと理解しております★。
| 項目 | 実測値 | 出所 |
|---|---|---|
@@system_time_zone / @@time_zone |
★UTC★ / SYSTEM（NOW() は UTC を返します） |
★構造★ |
| 書き込まれている値 | ★列の型（TIMESTAMP / DATETIME）によらず JST の壁時計の値★。例: robots.updated_at の最新が 15:00 のとき、JST の時刻は 15:17、NOW() は 06:17 でした |
★先方投入★ |
| 列の既定値 | ★current_timestamp()★（★値を明示しない書き込みがあると、その行だけ UTC になります★） |
★構造★ |
★★9時間ずれて見える列が2つございます★★（★先方投入★）
| 列 | 見えていること | 当方の見立て（★断定はいたしません★） |
|---|---|---|
★control_reports.reported_at★ |
★11行とも、同じ行の created_at のちょうど9時間前★（例: reported_at 09-30 14:32:49 / created_at 09-30 23:32:49） |
★UTC で書かれているように見えます★ |
★robot_error_reports.errored_at★ |
★行の created_at の約9時間後★（例: 行の作成 09-30 21:40 / errored_at 10-01 06:31） |
★清掃は夜の21時台に始まっておりますので、★JST への補正が二重にかかっているように見えます★★ |
★お伺いしたいこと（4点）★
| # | お伺いしたいこと | 選択肢 |
|---|---|---|
| ★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 の仕様
この章で伺うこと: ★予定外のタスクの見分け方（N-1）★ / ★
statusの値の意味（N-2）★ / ★clean_ratioの作り方（N-3。サマリの率の式＝第8回 Q4 の残りを含みます）★ / ★面積2列の意味（N-4）★ / ★1回の清掃あたりの行数（N-8）★ / ★清掃日を決める列（N-9）★。
2-0. 前提 — ★当方は清掃の実績を clean_task_reports から読む形に切り替えました★
★当方はこれまで clean_status_histories を読んでおりましたが、★clean_task_reports だけを読む形に 切り替えました★（10章）。★清掃の予定（clean_timetables）とは clean_timetable_id で突き合わせます★。
★そのため、この表の仕様が当方の画面の正しさに直結いたします。★
★なお、started_at と clean_timetable_id につきましては、ご説明を伺っております（10章 10-2）。★
★N-1. 「予定外のタスク」は、clean_timetable_id が NULL であることだけで見分けてよろしいでしょうか★
★「清掃予定をサーバーで決められるものは clean_timetable_id が発行され、予定外のタスクは NULL になる」と 伺っております★（10章 10-2）。★
★当方はこの理解で、★clean_timetable_id が NULL の行を「予定外のタスク（実際に行われた清掃）」として扱います★。 ★そのうえで、見分け方がこれだけで足りるかを確認させてください。★
| 選択肢 | 内容 | 当方の動き |
|---|---|---|
| ★A★ | ★NULL であることだけで十分★（NULL ＝ 予定外のタスク） | ★このまま実装します★（★ご回答はこの一言で結構です★） |
| B | ★ほかに区別する列がある★（★列名をお教えください★） | ★その列で見分けます★ |
| C | ★予定外でなくても NULL になる場合がある★（★例: 予定との引き当てに失敗した場合 など★） | ★その場合を見分ける方法をお教えください★ |
★いまステージングに入っている2行は、どちらも NULL です★（★先方投入★）。★clean_timetables がまだ0行ですので、 この2行が「予定外のタスク」なのか「予定がまだ入っていないための NULL」なのかを、当方では区別できておりません★。 ★C に当たるかどうかの参考までに、この2行がどちらかもお教えいただけますと助かります。★
★N-2. clean_task_reports.status（清掃結果）の値の意味をお教えください★
★テーブル定義書の備考が空欄でしたので、値の意味が分かっておりません★。
| 値 | ★CSV★ での行数 | ★先方投入★ での行数 | 意味（ご記入をお願いします） |
|---|---|---|---|
| 3 | 2 | 0 | |
| 4 | 161 | ★2★ | |
| 5 | 4 | 0 | |
| 6 | 22 | 0 | |
| ★その他の値★ | — | — | ★入りうる値があればお教えください★ |
★気になっている行★: ステージングの2行はどちらも status = 4 ですが、★1行は clean_ratio = 100、 もう1行は clean_area = 0 / clean_ratio = 0 / clean_time = 0★ でした（★先方投入★）。 ★同じ値で「全部できた清掃」と「何もできなかった清掃」の両方が表されているように見えます★。
★Pudu Cloud の値をそのまま入れている場合は、その旨と、Pudu 側の項目名だけ★お教えいただければ 結構です（当方で Pudu の資料を当たります）。
★当方は現在、★この値を変換せずにそのまま画面に出しております★（10章）。
★N-3. clean_task_reports.clean_ratio は、どのように作られていますでしょうか★
★いま見えていること★
★テーブル定義書の備考は次のとおりです★。
清掃実施面積 / 清掃対象面積 で計算する. 100を超過する値が生成される場合もある. 小数点以下は四捨五入とする.
★また第2回のご回答（B-3）では「取得元で 100 に丸められるため上限は 100」と伺っております★。
★ところが、clean_area ÷ task_area と clean_ratio が一致しない行が多くございます。★
| 項目 | 値 | 出所 |
|---|---|---|
clean_area > task_area の行 |
★129 / 189（68.3%）★ | ★CSV★ |
Σclean_area ÷ Σtask_area |
90.2% | ★CSV★（当方の計算） |
clean_ratio の平均 |
★78.5%★ | ★CSV★（当方の計算） |
| 一致しない例 | 面積比 13.8% の行の clean_ratio が 100.0 / 面積比 162.8% の行の clean_ratio が 61.0 |
★CSV★ |
| ステージングの1行 | 885.183105 ÷ 898.892509 ＝ 98.5% に対し、★clean_ratio は 100★ |
★先方投入★ |
★ご回答のお願い★
| 選択肢 | 内容 |
|---|---|
| ★A★ | ★Pudu Cloud が返す値をそのまま入れている★（★面積から計算していない★） |
| B | ★貴社で計算している★（★式をお教えください★） |
| C | その他 |
★当方は、清掃完了率として clean_ratio をそのまま使い、複数回の清掃は単純平均（清掃1回＝1票）で 束ねることにいたしました★（10章）。★面積の比は使っておりません★。 ★この使い方に差し支えがございましたら、お知らせください。★
★N-3 にあわせて — 第9回3章（第8回 Q4）の再掲：サマリの率・件数の式★
★第8回で「多いので後で回答」とのご留保をいただいた件です。取り下げておりません。★ ★丸め（第8回 Q4-4）は「小数第2位以下切り捨て」とご回答いただきましたので、★残りは式と件数の定義です★。
★特に clean_ratio が気になっております。★ ★当方は当期（進行中の週・月）を「清掃1回ごとの clean_ratio の単純平均」で出しております。 ★サマリの clean_ratio が面積の比で作られていると、週が切り替わったところで数字が段差になります。★
| サマリの列 | 当方の理解 | ご回答（分子 ÷ 分母） |
|---|---|---|
operation_ratio（稼働率） |
清掃実施回数 ÷ 清掃予定回数 | |
launch_ratio（出発成功率） |
定刻出発回数 ÷ 清掃予定回数 | |
★clean_ratio（清掃完了率）★ |
★清掃1回ごとの clean_ratio の平均？ それとも Σclean_area ÷ Σtask_area？★ |
|
error_ratio（エラー発生率） |
エラー発生回数 ÷ 清掃実施回数 | |
task_count |
清掃予定回数 | |
launch_count |
★4章（第9回 Q6-2 / Q11-3）でお伺いしております★ | |
error_count |
★4章（第9回 Q4-1 / Q4-2）と3章でお伺いしております★ |
★あわせて、★予定外のタスク（clean_timetable_id が NULL の行。N-1）がサマリのどの列に数えられるか★も お教えいただけますと助かります★（★予定回数 task_count に入るか、入らないか★）。
★文書としてお持ちでしたら、それをお送りいただくだけで結構です★（★定義書の比率の備考にある 「補足を参照.」の補足の本文を、当方は受領しておりません★）。
★N-4. task_area と clean_area は、それぞれ何の面積でしょうか★
★当方の中で理解が食い違いました。★
| 出典 | task_area |
clean_area |
|---|---|---|
| ★テーブル定義書★ | ★清掃対象面積★ | ★清掃実施面積★ |
| ★当方の社内での話★ | ★実際に清掃した面積★ではないか、という話が出ました | — |
★定義書どおりに読むと、N-3 の「clean_area > task_area が68%」は「対象より広く清掃した」ことになり、 説明がつきません。★ ★一方で、ステージングの1行は ★task_area = 1377.39502 に対し clean_area = 0 / clean_time = 0★ です （★先方投入★）。★task_area を「実際に清掃した面積」と読むと、★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 は何行できますでしょうか★
★第9回 Q2-3（clean_status_histories について同じことを伺った設問）の置き換えです★。
| 選択肢 | 内容 |
|---|---|
| ★A★ | ★必ず1行★（★清掃1回につき1行。途中経過は同じ行を更新する★） |
| B | ★複数行できる★（★例: 中断して再開した場合 など。どんなときかをお教えください★） |
★ステージングの1行は、★created_at 00:45 の後、updated_at 01:55 に更新されておりました★（★先方投入★）。 ★同じ行を後から更新する作り（A）と読んでおりますが、確認させてください。★
★当方は、★2行以上あった場合は最新の1行だけを使い、ログに警告を出す★作りにしております。★ ★B の場合、面積を足すと同じ清掃を2回数えてしまいます★ので、足し方を見直します。
★N-9. 「その清掃が何日の清掃か」は、どの列で決まりますでしょうか★
★いま見えていること★（★先方投入★。ステージングの2行）
| 列 | 型 | 1行目 | 2行目 |
|---|---|---|---|
started_at |
DATETIME | 2026-09-30 22:00:20 | 2026-09-30 21:00:39 |
ended_at |
DATETIME | 2026-10-01 00:02:52 | 2026-10-01 01:00:00 |
created_at |
TIMESTAMP | ★2026-10-01 00:45:03★ | ★2026-10-01 00:45:07★ |
★テーブル定義書の created_at の備考は ★「清掃日を設定(Y-m-d 23:59:59)」★ ですが、 ★実際の値は 10-01 00:45:03 で、23:59:59 ではございません★。★
| 選択肢 | 内容 |
|---|---|
| ★A★ | ★started_at の日付★ |
| B | ★created_at★（★定義書の「Y-m-d 23:59:59」は古い記載か、今後そうなるのか、もお教えください★） |
| C | ★予定（clean_timetables.start_at）の日付★（★予定外のタスクの場合はどうなるか、もお教えください★） |
| D | その他 |
★なぜお伺いするのか★
★上の2行は、どちらも ★9/30 の夜に始まり 10/1 に終わっております★。★ ★貴社のサマリ（週・月の集計）がどちらの日に数えているかと、当方の当期集計がそろっていないと、 ★月末や週末の清掃が、確定期間と当期で別の期間に数えられます★★。
3. エラーの集約
この章で伺うこと: ★制御盤のエラーを
robot_error_reportsにどう入れるか（N-5）★ / ★そのエラーがサマリのerror_countに入るか（第9回 Q4-3 の聞き直し）★ / ★事前チェック・本清掃・清掃時間外のエラーの見分け方（N-11）★。
3-0. 当方の理解
★エラーの情報は、制御盤のエラーも含めて robot_error_reports に集約される、と当方では理解しております。★
★N-5. 制御盤のエラーは、robot_error_reports にどのように入りますでしょうか★
★DDL の上で気になっている点★（★構造★）
| 列 | 定義 | 制御盤のエラーを入れるときに気になる点 |
|---|---|---|
robot_id |
★NOT NULL・robots(id) への外部キー★ |
★制御盤のエラーには、対応するロボットが無い場合があるかと存じます★ |
control_id 相当 |
★列がございません★ | ★どの制御盤のエラーかを記録する場所がございません★ |
serial_number |
NOT NULL | ★ロボットの製品番号の列と理解しております★ |
★ステージングの11行は、★すべて error_type = LostLocalization、robot_id はすべて実在のロボット★で、 ★制御盤由来と見られる行はまだございません★（★先方投入★）。
★お伺いしたいこと（2点）★
| # | お伺いしたいこと | 選択肢 |
|---|---|---|
| ★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 から作っております★。 ★B の場合、当方はこの画面の取得元を robot_error_reports に差し替えます★。
★第9回 Q4-3 の聞き直し — 制御盤のエラーは、サマリの error_count に入りますでしょうか★
★第9回 Q4-3 は「clean_error が 2 / 3 の清掃はサマリの error_count に含まれるか」を伺っておりました。★ ★当方が clean_error を持つ表を読まなくなりましたので、★伺い方を改めます★。★
| 選択肢 | 内容 |
|---|---|
| ★A★ | ★含む★（★robot_error_reports に入った制御盤のエラーも数える★） |
| B | ★含まない★（★ロボットのエラーだけを数える★。★その場合、何で見分けているかを一言★） |
★当方の当期の集計を、★サマリと同じ数え方にそろえるため★の確認です。
★N-11. robot_error_reports の行が、事前チェック・本清掃・清掃時間外のどれで起きたものかは、どう見分ければよいでしょうか★
★いま見えていること★（★先方投入★）
| 項目 | 値 |
|---|---|
| 行数 | 11 |
★clean_timetable_id が NULL の行★ |
★11（全行）★ |
error_type |
★LostLocalization のみ★（error_level は Error 9行 / WARNING 2行） |
errored_at（発生時刻） |
★9/30 23:24 の1行と、10/1 06:31〜09:50 の10行★（★1章 N-14 のとおり、9時間ずれている可能性がございます★） |
★当方はこれまで、★clean_timetable_id から予定（clean_timetables.precheck）を引いて、 「事前チェックのエラーか、本清掃のエラーか」を見分けておりました★（第8回 A7「どちらも指しています」）。
★★clean_timetable_id が NULL の行は、そのどちらにも振り分けられません。★★ ★★そのため、いまの11行は、当方の画面のアラートにもエラー発生率にも1件も出ておりません★★ （★当方側の作りの問題ですので、扱いは当方で考えます★）。
★なお、errored_at は1章 N-14 のとおり9時間ずれている可能性がございますので、★発生時刻の時間帯から 清掃中かどうかを読むことは控えております★。★
★ご回答のお願い★
| 選択肢 | 内容 |
|---|---|
| ★A★ | ★予定が入れば、clean_timetable_id が埋まる★。★事前チェック・本清掃は precheck で見分けられる。★清掃時間外・予定外のタスク中のエラーは NULL のまま★ |
| B | ★別の方法で見分ける★（★お教えください★） |
| C | ★見分けられない★ |
★A であれば、ご回答は記号だけで結構です。★ ★第8回 A6-2 で「条件（製品番号・エラー発生日時）が合わなければ NULL のまま」と伺っておりますので、 ★A の理解でよいかの確認です★。
4. サマリ
この章で伺うこと: ★
error_countの数え方（第9回 Q4-1 / Q4-2）★ / ★グループ単位の集計（第9回 Q6-1）★ / ★実施回数としてlaunch_countを使ってよいか（第9回 Q6-2 と Q11-3 を1問にまとめました）★ / ★年次サマリの作成時期（N-12）★。
4-0. 前提
★当方は、確定した期間（前週・前月・前年）の数字を ★customer_summaries / facility_summaries の週・月・年の 3粒度★ から読み、進行中の期間（当週・当月・当年）は詳細のテーブルから当方で集計しております★。
★ステージングの customers が2行になりましたので、複数の顧客の数字をまとめて出す場面（全体・グループ単位）が すでに生じております。★ ★Q6-1 / Q6-2 は、そのための確認です★。
★第9回 Q4-1. サマリの error_count は、事前チェック（precheck = 30 / 60）のエラーを除いて数えていますでしょうか★（再掲）
| 選択肢 | 内容 |
|---|---|
| A | ★除いている★（本清掃 precheck = 0 のみ） |
| B | ★除いていない★ |
★第8回 A7 の「サマリには含めない、とするのが正しいでしょう」が、★バッチが実際にそうしているのか、 ご見解なのか★を読み取れませんでしたので、改めて伺います。
★★第9回 Q4-2. clean_timetable_id が NULL のエラー行は、サマリの error_count に含まれますでしょうか★★（再掲。★重みが増しました★）
| 選択肢 | 内容 |
|---|---|
| A | ★含む★ |
| B | ★含まない★ |
★3章 N-11 のとおり、ステージングのエラー行は現在11行すべてが NULL です。★ ★★B の場合、いまのエラーは1件もサマリに数えられないことになります★★。
★第9回 Q6-1. グループ（ホールディングス）単位の集計は、どちらの想定でしょうか★（再掲）
| 選択肢 | 内容 |
|---|---|
| ★A★ | ★当方が customer_summaries の複数行を合算する★（★テーブルの追加は不要★） |
| B | ★group_summaries を追加してバッチで集計する★ |
| C | ★グループ単位の集計は想定していない★ |
★A の場合、当方は率を「率の平均」ではなく「Σ分子 ÷ Σ分母」で計算し直します。★次の Q6-2 の材料が要ります★。
★★第9回 Q6-2 と Q11-3 をまとめて — 「清掃実施回数」として launch_count を使ってよろしいでしょうか★★
★経緯★
★第9回 Q6-2 では「サマリに清掃実施回数の列を追加していただけないか」をお願いし、 Q11-3 では「launch_count / launch_ratio の式」を伺っておりました★。
★★実施回数の列につきましては、「launch_count と違いが無いので検討中」と伺っております。★★ ★そこで、★2問を1問にまとめ、伺い方を改めます★。★
★お伺いしたいこと★
★サマリの launch_count を、当方の「清掃実施回数」として使ってよろしいでしょうか。★
| ご回答 | 当方の動き |
|---|---|
★A. よい★（launch_count ＝ 清掃を実施した回数） |
★列の追加のお願いは取り下げます★。★稼働率・エラー発生率の合算と検算に launch_count を使います★（★ご回答はこの一言で結構です★） |
| ★B. 違う★ | ★launch_count が何を数えているかを一言お教えください★（★例: 予定時刻から〇分以内に出発したものだけ★） |
★A の場合の確認★: ★そのとき、operation_ratio（稼働率）と launch_ratio（出発成功率）は★同じ値になるはず★と 当方は考えております★。★同じ値にならない場合は、その違いを1行でお教えください。★
★参考までに、当方の率の式です（★要件定義★）。
稼働率 = 清掃実施回数 ÷ 清掃予定回数 × 100 出発成功率 = 定刻出発回数 ÷ 清掃予定回数 × 100 エラー発生率 = エラー発生回数 ÷ 清掃実施回数 × 100
★なお、第9回 6-2 の本文で、この件の理由の説明に誤りがございました。★9章★をご覧ください★。
★N-12. 年次サマリは、毎年1月1日 6:00 に前年分が作られる、という理解でよろしいでしょうか★
★週次（毎週日曜）・月次（毎月1日）は伺っております。★年次も同じ形で「毎年1月1日 6:00 に前年分」と理解して おりますが、★明示のご確認をいただいておりませんでした★。
★YES / NO★（★NO の場合、作られる時期をお教えください★）
5. グループ・顧客マスタ
この章で伺うこと: ★投入はこれで一区切りか★ / ★屋号の扱い（第9回 Q7-1・Q7-2・Q7-5）の結論の時期★ / ★
shop_idの意味（第9回 Q7-3）★ / ★グループに属さない顧客を作るか（第9回 Q7-4）★。
5-1. ★投入いただいたこと — ありがとうございます★
★第9回7章でお願いしていたマスタの投入を、ステージングで確認いたしました★（★先方投入★）。
groups |
customers |
facilities |
|---|---|---|
| PPIH | 株式会社ドン・キホーテ | 10件 |
| CHANGE HOLDINGS | 株式会社DFA Robotics | 1件 |
★お伺いしたいこと — 投入はこれで一区切りでしょうか★
| 選択肢 | 内容 |
|---|---|
| ★A★ | ★P1 の開始時点ではこの形★（★施設が増えるときに足していく★） |
| B | ★まだ追加の予定がある★（★時期の目安をお教えください★） |
5-2. ★屋号の扱い（第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 は何を表す列でしょうか★（再掲）
★第9回の時点では値が全行 "0"（当方のダミー）でしたので、値から推し量れずにおりました★。 ★いまは値が入っております★（★先方投入★）: ★11件とも9桁の数字で、先頭は「5」、すべて異なる値★です。
| 選択肢 | 内容 |
|---|---|
| ★A★ | ★顧客側（ドン・キホーテ様）の店舗コード★ |
| B | ★貴社（または Pudu）が振った番号★ |
| C | その他 |
★A であれば、当方は店舗の検索や表示に使ってよいかを社内で判断いたします。★
★第9回 Q7-4. グループに属さない顧客（customers.group_id = 0）は、作らない想定でよろしいでしょうか★（再掲）
★第9回では「group_id = 0 は、現状の DDL（外部キー制約）では投入できないように見えます」と ご報告しておりました★（★構造★）。
★今回投入いただいた2社は、どちらもグループに属しております★ので、★いまは問題が起きておりません★。
★第9回の選択肢を再掲いたします（第9回をお手元にご用意いただかなくてもお答えいただけるように）★。
| 選択肢 | 内容 | 当方の動き |
|---|---|---|
| A | ★groups に id = 0 の行（グループなし）を1件入れる★（INSERT には NO_AUTO_VALUE_ON_ZERO が要ります） |
「グループなし」を表示します |
| B | ★外部キー制約 customers_group_id_foreign を外す★ |
「グループなし」を表示します |
| C | ★group_id を NULL 可にする★ |
NULL を「グループなし」として表示します |
| ★D★ | ★グループに属さない顧客は作らない（必ずどこかのグループに属する）★ | ★「グループなし」の表示を作りません★ |
★ご回答は記号だけで結構です★。
6. 制御盤の報告間隔
この章で伺うこと: ★入った設定値（10秒〜60秒）が運用の範囲と考えてよいか（第9回 Q8-3）★。
6-1. ★入っている設定値★（★先方投入★）
★第9回 Q8-3 では「報告間隔の下限・上限・変更の頻度」を伺っておりました★。 ★link_schedules に値が入りましたので、★伺い方を確認の形に改めます★。★
type（定義書: 通信種類） |
エリア数 | intervals（0時〜23時） |
|---|---|---|
| ★1（D-S制御盤 ⇔ 制御サーバ）★ | 10 | ★0〜6時・21〜23時は 10秒 / 7〜20時は 60秒★ |
| ★1（D-S制御盤 ⇔ 制御サーバ）★ | 1 | ★終日 10秒★ |
| 2（制御サーバ ⇔ Pudu Cloud） | 11 | 終日 10秒 |
★この設定のままですと、control_reports は ★2年で約3,900万行★ になる計算です★ （★当方の計算★。制御盤11台。第9回でお示しした「60秒なら約1,100万行 / 10秒なら約7,000万行」の間に入ります）。
★第9回 Q8-3（改）. この設定（10秒〜60秒）を、運用の範囲と考えてよろしいでしょうか★
| # | お伺いしたいこと | 選択肢 |
|---|---|---|
| ★a★ | ★運用中も、報告間隔は ★10秒〜60秒★ の範囲に収まる★ | ★YES / NO★（★NO の場合、下限・上限の目安★） |
| ★b★ | ★変更の頻度★ | ★基本的に変えない / 制御盤ごとに個別に変える / 運用中に随時変える★ |
★a が YES であれば、ご回答は「YES」と b の一言で結構です。★
7. 軽い確認
この章で伺うこと: ★区域別の内訳（第9回 Q9-2）★ / ★
clean_schedules.contractの用途（N-13）★。 ★いずれも「できない」「不明」の一言で結構です★。
★第9回 Q9-2. 1回の清掃の中の、区域別（売り場・通路・レジ前など）の内訳は取得できますでしょうか★（再掲）
★当方が出せているのは「1清掃エリア（＝1ロボット）につき1つの完了率」までです★。 ★取得できない場合は「できない」とお答えいただければ、当方はこの機能を諦めます。★
★N-13. clean_schedules.contract は何に使う列でしょうか★
★clean_schedules に contract という列がございます（★構造★。varchar(10)、既定値 "0000000000"）★。 ★facilities.contract（契約フラグ）と★型も既定値も同じ★です★。
★当方は facilities.contract だけを契約フラグとして読み、clean_schedules.contract は読んでおりません。★ ★この扱いでよいかの確認です★。
| 選択肢 | 内容 |
|---|---|
| ★A★ | ★読まなくてよい★（★用途を一言いただけますと助かります★） |
| B | ★読むべき★（★facilities.contract との使い分けをお教えください★） |
★DDL 未反映の2件（第9回）— 取り下げます★
★第9回でお願いしていた2件は、いずれも★取り下げます★（理由は 10章）。★ご対応は不要です★。
8. 参考 — 索引（★ご依頼ではありません★）
★索引につきましては、現在は検証段階であり、運用段階で随時ご対応いただけると伺っております。★ ★本章は依頼ではございません。★ ★当方の画面が使う列が変わりましたので、第9回1章の一覧を差し替えて お知らせするものです★。★ご対応の際に突き合わせていただければ幸いです★。
★2026-10-01 時点の状況は、ステージングの ★構造★（information_schema.STATISTICS）から確認したものです★。
| # | テーブル | 当方が見ている列（順序も含みます） | 2026-10-01 の状況 | 第9回からの変更 |
|---|---|---|---|---|
|
|
clean_status_histories |
clean_timetable_id |
— | ★外しました★（★当方はこの表を読まなくなりました★） |
| ② | robot_error_reports |
clean_timetable_id |
★索引なし★ | 変更なし |
| ③ | clean_timetables |
(precheck, start_at) |
★単一列の索引のみ★ | 変更なし |
| ④ | clean_timetables |
(facility_id, start_at) |
★単一列の索引のみ★ | 変更なし |
|
|
clean_status_histories |
started_at |
— | ★外しました★（同上） |
| ⑥ | control_reports |
(control_id, reported_at) |
★control_id のみ★ |
変更なし |
| ⑦ | control_error_histories |
occurred_at |
★索引なし★ | ★3章 N-5 b が B（書かない）なら不要です★ |
| ★⑧★ | ★clean_task_reports★ |
★clean_timetable_id★ |
★索引なし★ | ★新しく加えました★（★予定との突き合わせ。①の置き換えです★） |
| ★⑨★ | ★clean_task_reports★ |
★started_at★ |
★索引なし★ | ★新しく加えました★（★期間で絞る集計。⑤の置き換えです★） |
★当方の見立てでは ⑧ と ② が重めです★（★当方はこの2表を clean_timetable_id IN (…) の形で引くため、 索引が無いと、行が増えるほど全行を読む回数が増えます★）。★⑨は総清掃面積と、年次の当期集計で使います★。
★当方はメインDBのスキーマを変更いたしません★。★上記を当方で実行することはございません★。 ★ご対応が済みましたらお知らせいただけますと、当方で実行計画（EXPLAIN）を測り直します★。
9. ★★訂正1件 — 第9回 6-2「なぜ『清掃実施回数』が要るのか」の理由の説明★★
★第9回の本文に、事実と異なる記載がございました。お詫びして訂正いたします。★
第9回の記載
★確定した期間（前週・前月）の稼働率・エラー発生率そのものが、サマリからは出せません。★
★上のとおり、1社であっても確定期間の2つの率が出せませんので、訂正いたします。★
★正しくは★
★誤りでした。★ ★サマリには operation_ratio（稼働率）と error_ratio（エラー発生率）の列が 実在し（★構造★）、★当方はそれを読んで、確定期間の稼働率・エラー発生率を画面に出しております★。
★実施回数の列が無いことで当方が困っているのは、次の3点です★。
| # | 困っていること | 内容 |
|---|---|---|
| 1 | ★合算できない★ | ★複数の顧客・グループの数字をまとめるとき、率は平均できず、★Σ分子 ÷ Σ分母★ で出し直す必要がある。その分子（実施回数）が無い★ |
| 2 | ★検算できない★ | ★率はあるが、稼働率の分子が無いため、率が正しいかを確かめられない★ |
| 3 | ★式が分からない★ | ★第8回 Q4（本書2章 N-3 で再掲）が未回答のため、その率が当方の定義と同じかが分からない★ |
★お願い・お伺いの中身は変わりません。★ ★本書では4章で「launch_count を実施回数として使ってよいか」の 形に改めております★。
★第9回で「訂正いたします」と書いた箇所を、さらに訂正することになりました。★重ねて失礼いたしました。★
10. 当方の方針・伺った内容のご報告と、取り下げる設問
10-1. ★当方で決めた方針★（★ご回答は不要です。差し支えがある場合のみお知らせください★）
★以下は、貴社のご回答ではなく、当方（DFA）の社内で決めたことです。★
| # | 方針 | 関係する章 |
|---|---|---|
| 1 | ★清掃の実績は clean_task_reports から読みます★。★clean_status_histories は読みません★ |
2章 |
| 2 | ★清掃完了率は clean_task_reports.clean_ratio を使い、複数回の清掃は★単純平均（清掃1回＝1票）★で束ねます★。★面積の比（Σclean_area ÷ Σtask_area）は使いません★ |
2章 N-3 |
| 3 | ★未実施＝予定に対応する clean_task_reports の行が無いこと★、と判定します |
2章 |
| 4 | ★「出発失敗」と「未実施」は区別せず、同じものとして扱います★ | — |
| 5 | ★サマリは週・月・年の3粒度を読みます★。★進行中の期間は詳細のテーブルから当方で集計します★ | 4章 |
| 6 | ★clean_task_reports.status や robot_error_reports.error_type は、★値を変換せず、そのまま画面に出します★★ |
2章 N-2 |
| 7 | ★★ステージングで、robot_error_reports / control_error_histories の4カラム（status / comment / responded_at / resolved_at）の更新を検証させていただきます★★。★4カラム以外には書き込みません★。★実データのエラー行の「対応状況」が書き換わることがございます★ |
1章 N-6 b |
| 8 | ★面積の単位は ㎡ として表示します★（第9回でご報告済み） | — |
| 9 | ★★第9回12章（DB接続経路。お願い3件・Q12-1〜Q12-6）は、検証段階のため保留とし、顧客へ配布する段階で改めて検討いたします★★ | — |
10-2. ★伺った内容★（★当方はこの理解で実装いたします★）
| # | 伺った内容 | 当方の扱い |
|---|---|---|
| 1 | ★★clean_task_reports.started_at は、実際に清掃を開始した時刻であり、started_at / ended_at のような過去形の列は清掃の実施後に記載される、と伺いました。★★ |
★当方はこの理解で実装します。★ |
| 2 | ★★清掃予定をサーバーで決められるものは、今後 clean_timetable_id が発行され、予定外のタスクは NULL になる、と伺いました。★★ |
★当方はこの理解で実装します。★（★見分け方が NULL だけで足りるかは 2章 N-1 でお伺いしております★） |
10-3. ★取り下げる設問★（★ご回答は不要です★）
★本書で取り下げるもの★
| 番号 | 内容 | 取り下げの理由 |
|---|---|---|
| 第9回 Q2-1 | サマリの面積は期間内の合計か | ★当方はサマリの面積を読まなくなりました★（総清掃面積は clean_task_reports から集計） |
| 第9回 Q2-3 | 1つの予定に clean_status_histories は何行できるか |
★当方は clean_status_histories を読まなくなりました★（★clean_task_reports について 2章 N-8 で伺い直しております★） |
| 第9回 2-4（参考） | 年次サマリの面積の桁あふれ | ★サマリの面積を読まなくなりましたので、当方には影響がございません★ |
| 第9回 Q9-1 | robot_task_reports は clean_task_reports のことか |
★当方は clean_task_reports を読む形にしましたので、確認は不要になりました★ |
| ★第9回 9章 DDL 1★ | clean_status_histories.id の AUTO_INCREMENT |
★当方は clean_status_histories を読まなくなりました★ |
| ★第9回 9章 DDL 2★ | security_status_histories.reported_at の DEFAULT |
★当方のアプリは security_status_histories を読んでおりません★（★当方の実装に影響がございません★） |
| 第9回 Q11-1 | clean_status_histories.started_at を実開始時刻として使ってよいか |
★clean_task_reports.started_at が実際の開始時刻と伺いましたので、不要になりました★（10-2 の1） |
| 第9回 Q11-2 | 「清掃指示」で止まったケースは履歴に残るか | ★「出発失敗」と「未実施」を同じ扱いにすると、当方で決めました★（10-1 の4） |
| 第9回 Q11-4 | より短い間隔で更新されるテーブルはあるか | ★当方は clean_task_reports を読む形にしました★（★過去形の列は実施後に記載されると伺っております。10-2 の1★） |
| ★第9回 12章★ | ★DB接続経路（お願い3件・Q12-1〜Q12-6）★ | ★検証段階のため保留とし、顧客へ配布する段階で改めて検討いたします★（10-1 の9） |
| 第8回 A10 の件 | ★書き込みを検証できる環境（ステージング）のご相談★ | ★★ステージングに書き込んでよいと弊社内で決めたため、ご相談は不要になりました★★（10-1 の7） |
★第9回の時点で取り下げ済みのもの★（★念のための再掲です★）
| 第9回の番号 | 内容 |
|---|---|
| 1章 | 索引のご依頼（★参考情報に改めました。本書8章★） |
| Q2-2 | サマリの面積が合計でない場合の経路 |
| Q5-1 | 面積の単位（★弊社で㎡と確定★） |
| 旧 Q8-1 / Q8-2 | 施設数・台数（★弊社で決めるべきことでした★） |
| 10章 | DB更新用アカウントの発行（★発行済みでした★） |
10-4. ★第9回の全項目の行き先★（★突き合わせ用★）
| 第9回 | 本書での扱い |
|---|---|
| 3章（第8回 Q4） | ★再掲★ → 2章 N-3 の後半 |
| Q4-1 / Q4-2 | ★再掲★ → 4章 |
| Q4-3 | ★聞き直し★ → 3章（制御盤のエラーが error_count に入るか） |
| Q6-1 | ★再掲★ → 4章 |
| Q6-2 / Q11-3 | ★1問にまとめました★ → 4章（launch_count を実施回数として使ってよいか） |
| 7章 お願い（マスタ投入） | ★ご対応いただきました★ → 5章（一区切りかの確認のみ） |
| Q7-1 / Q7-2 / Q7-5 | ★結論の時期の目安のみ★ → 5章 |
| Q7-3 / Q7-4 | ★再掲★ → 5章 |
| Q8-3 | ★確認の形に改めました★ → 6章 |
| Q9-2 | ★再掲★ → 7章 |
| 12章（お願い3件・Q12-1〜Q12-6） | ★保留★ → 10-3 |
| Q2-1 / Q2-3 / 2-4 / Q9-1 / DDL 2件 / Q11-1 / Q11-2 / Q11-4 | ★取り下げ★ → 10-3 |
| 1章 / Q2-2 / Q5-1 / 旧 Q8-1・Q8-2 / 10章 | ★第9回で取り下げ済み★ |
以上です。ご確認のほど、よろしくお願いいたします。
★繰り返しになりますが、まずは次の2つだけでも先にお答えいただけますと大変助かります。★
- ★★1章 N-14 — ステージング・本番DBのタイムゾーンと、時刻の列に書く値（a〜d）★★
- ★★2章 N-2 / N-3 / N-4 —
statusの値の意味 /clean_ratioの作り方 /task_area・clean_areaの意味★★