TeamWorks 様 確認事項（第8回）

作成: 2026-09-11 / 作成者: DFA Robotics

はじめに（★第7回がまだ未回答です★）

★第7回（2026-09-10 送付）へのご回答は、本書作成時点でまだいただいておりません。★ ★第7回の3件は取り下げません。引き続きお願いいたします。★

第7回でお願いしていたこと	状態
★接続先（ホスト名・ポート）★	★未回答。全体を通じて最優先です★
clean_timetables.precheck の値の範囲と反映時期	未回答
DDL の未反映4件（A-2 / A-3b / B-2 / B-3b）	未回答（★お手すきの折で結構です★）

★あわせて、DB更新用アカウントの発行は、第5回（2026-09-07）・第6回（2026-09-08）から 継続してお願いしている件です。★ ★第7回では書き漏らしてしまいましたが、取り下げたわけではありません。★ ★本書の10章に、あらためて記載しております。急ぎではございません。★

★本書は第7回の追加です。第7回の内容を差し替えるものではありません。★

そのうえで、★ローカルの検証環境でレポート画面まで動かし、あわせて未確認事項の棚卸しを行ったところ、 確認事項が10件になりました。★ ★うち2件（1章・2章）は、放置すると画面に出る内容そのものが壊れる性質のものです。★

本書は次の10部構成です。★すべて質問です。1問1答の形にしております。★

#	内容	優先度
1. 未実施の清掃にも履歴の行は作られるか	★当方の設計の土台です★	★最優先★
2. DATETIME のタイムゾーン	★日本時間の壁時計値か、UTC か★	★最優先★
3. 実際の開始・終了時刻はどこにあるか	started_at / ended_at は予定時刻に見えます	高
4. サマリの率・分子・分母の関係	★計算式と件数列の定義をまとめてお伺いします★	高
5. 未実施行（clean_error = 1）の他カラムの値	★一部はお願い（収集処理の変更を伴います）★	中
6. clean_error が 2 / 3 / 4 のときの扱い	エラー報告・完了率・優先順位	中
7. robot_error_reports.clean_timetable_id はどちらの行を指すか	★エラー率が 0% になる可能性があります★	高
8. control_error_histories は実際に使われるか	★D-Secアラート画面の作り直しに関わります★	中
9. 軽い確認2件	バッテリー履歴 / エリア別完了率	低
10. 継続のお願い: DB更新用アカウント	★第5回・第6回からの継続。時期の目安だけでも★	★最古の待ち★

★なお、5と4の後段は貴社の担当領域（DBとバッチ）への変更を伴いますので、「お願い」として書いております。★ ★そのままで差し支えない、というご判断であれば、その旨をお知らせいただければ当方で対応します。★

---

1. ★清掃が実施されなかった場合も、clean_status_histories に行は作られますでしょうか — 最優先★

1-1. 当方は「作られる」という前提で実装しております

当方は、清掃詳細ログの「出発したかどうか」を次のように判定し、★すでに実装済み★です。

出発しなかった = clean_status_histories に行がある かつ その行の clean_error が 1（異常(清掃未実施)）

★つまり「清掃が実施されなかった場合も、clean_error = 1 の行が1行作られる」という前提です。★ ★この前提が、本作業の設計そのものの土台になっております。★

1-2. ★前提が外れた場合に何が起きるか（正直に書きます）★

★当方は「履歴の行が無い過去の清掃」を『出発失敗』として画面に出す設計にしております。★

したがって、★未実施のときに行が作られない運用ですと、 「結果がまだ書き込まれていないだけの清掃」まで出発失敗として並びます★（★過剰検知★）。

★画面が真っ赤になる一方で、例外もエラーログも出ません。★ ★そのため、当方だけでは正誤を判断できません。★

1-3. お伺いしたいこと（2問）

★Q1-1. 清掃が実施されなかった場合、clean_status_histories に行は作られますでしょうか★

選択肢	内容
★A★	★作られる★（clean_error = 1 の行が1行できる）
B	★作られない★（実施された清掃にだけ行ができる）
C	場合による（条件をお教えください）

★Q1-2. 1つの clean_timetable_id に対し、clean_status_histories は必ず1行でしょうか★

選択肢	内容
★A★	★必ず1行★
B	複数行になることがある（★どういうときかをお教えください★）

★補足★: 当方は現在、★複数行あった場合は ended_at が最新の1件を採用する★ という規則で実装しております。B の場合、この選び方で差し支えないかもあわせてお教えいただけますと助かります。

1-4. ★なぜお伺いするか★

• ★前提が外れても「出発失敗」という機能自体は残せますが、上記のとおり過剰検知になります。★
• ★運用担当が毎朝見る画面ですので、誤検知が続くと画面そのものが信用されなくなります。★
• ★本書のなかで、当方の実装への影響がいちばん大きい項目です。このため冒頭に置いております。★

---

2. ★DATETIME に入っているのは日本時間の壁時計値でしょうか、UTC でしょうか — 最優先★

2-1. 当方の側で起きていること（実測）

★当方のアプリは、DATETIME の値を UTC として読んだうえで、さらに9時間足しています。★ ★DBが日本時間の壁時計値を持っている場合、画面に出る時刻が9時間ずれます。★

内訳は次の2段です。いずれも当方のコードを実測して確認したものです。

#	何が起きるか
1	★当方が使っている Prisma の MariaDB 用アダプタは、DATETIME を UTC の値として読みます★（new Date(値 + "Z") という実装です）。★この挙動は設定で変更できません。接続文字列に timezone を指定しても効きません★（アダプタがドライバ側の変換を通らないためです）
2	★その値を画面用の日本時間に直す処理が、さらに9時間足します★

具体例です。

DBの clean_timetables.start_at の生値	DBが日本時間の場合、実際は	★当方の画面に出る時刻★
2026-09-11 02:00:00	9月11日 深夜2時の清掃	★9月11日 11:00★

2-2. ★表示だけの問題ではありません★

★未来の予定を一覧から外す判定にも、この時刻を使っています。★

D-Watch は「★夜間に自動実行された清掃を、翌朝 DFA の運用担当が確認する★」という使い方を想定しています。 上の例で、★運用担当が翌朝8時に画面を開くと、深夜2時の清掃が「11:00の予定」と読まれます。★ ★まだ来ていない予定として扱われ、一覧から消えます。★

★つまり、確認したい清掃がちょうど画面に出ない、という壊れ方をします。★ ★このため最優先でお伺いしております。★

2-3. お伺いしたいこと（4問）

★Q2-1. DATETIME 列に格納されているのは、次のどちらでしょうか★

選択肢	内容
★A★	★日本時間の壁時計値★（深夜2時の清掃なら 02:00:00 が入っている）
★B★	★UTC の壁時計値★（深夜2時の清掃なら 17:00:00（前日）が入っている）
C	列によって違う（違う場合、どの列がどちらかをお教えください）

対象として特に知りたい列は次のとおりです。

テーブル	列
clean_timetables	start_at / end_at
clean_status_histories	started_at / ended_at
clean_statuses	started_at / ended_at
robot_error_reports	errored_at / responded_at / resolved_at
control_error_histories	同種の日時列

★Q2-2. データ収集処理が書き込むときの基準は、次のどれでしょうか★

選択肢	内容
A	サーバのローカル時刻（日本時間）で書いている
B	UTC に直してから書いている
C	Pudu Cloud から返ってきた値をそのまま書いている（この場合、Pudu 側がどちらかもお分かりでしたら）

★★Q2-3. 実データを1行だけご提示いただけませんでしょうか★★

★clean_timetables の任意の1行について、次の2つをお教えください。★

#	教えていただきたいもの
1	★start_at の生値★（例: 2026-09-11 02:00:00）
2	★それが実際には何時の清掃を指すか★（例: 9月11日の深夜2時の清掃）

★この2つがあれば、当方で機械的に検証できます。★ ★1行で結構です。以後この件でお伺いすることはありません。★

なお、第7回でお願いしている接続先をいただければ、★生値そのものは当方で見られます★。 ただし ★その値が実際に何時の清掃を指すのかは、当方には分かりません★ ので、 ★2番だけはどうしてもお伺いする必要があります★。

★Q2-4. TIMESTAMP 型の列について、本番DBの time_zone 設定をお教えください★

created_at / updated_at のほか、control_reports.reported_at / security_status_histories.reported_at は ★TIMESTAMP 型★ です。

★TIMESTAMP は DATETIME と違い、セッションの time_zone 設定によって読み出される値が変わります。★ このため、DATETIME とは別にお伺いしております。

#	教えていただきたいもの
1	★本番DBの time_zone の設定値★（global と session の既定値）
2	★データ収集処理が接続する際に time_zone を設定していますか★（していれば、その値）

2-4. ★なぜお伺いするか★

• ★当方から伺っているのは「おそらく日本時間です」までで、確定しておりません。★
• ★推測で実装すると、ずれていた場合に「画面には出ているが1つもデータが無い日がある」という 形で表面化します。例外もエラーも出ないため、気づくのが遅れます。★
• ★上の2-2 のとおり、運用そのものが成り立たなくなる性質の問題ですので、 当方の判断で決めてしまわず、お伺いすることにしました。★

---

3. clean_status_histories の started_at / ended_at は予定時刻でしょうか

3-1. 現状の理解

テーブル定義書の備考に、次のようにございました。

列	定義書の備考
clean_status_histories.started_at	★「清掃スケジュールの清掃開始日時を格納する」★
clean_status_histories.ended_at	★「清掃スケジュールの清掃終了日時を格納する」★

★この書き方ですと、実際に清掃を始めた時刻ではなく、予定の時刻に読めます。★

いっぽう clean_statuses 側の同名の列（started_at / ended_at）は ★備考が空欄で、NULL 許可★ になっております。 ★こちらが実績時刻なのかもしれない、とも読めます。★

★当方には、どちらが正か判断できませんでした。★

3-2. お伺いしたいこと（2問）

★Q3-1. clean_status_histories.started_at / ended_at は予定時刻という理解で合っていますでしょうか★

選択肢	内容
A	★合っている。予定時刻が入る★
B	実績時刻が入る（定義書の備考が実態と違う）
C	開始と終了で違う（違う場合、どちらがどちらかをお教えください）

★Q3-2. A の場合、実際に開始・終了した時刻はどこかに保持されますでしょうか★

選択肢	内容
A	★clean_statuses.started_at / ended_at が実績時刻★
B	clean_task_reports 側に実績時刻がある（列名をお教えください）
C	★実績時刻は保持していない★
D	その他（お教えください）

3-3. ★なぜお伺いするか★

• ★清掃詳細ログの画面に、清掃の開始・終了時刻を表示します。★ ★予定時刻を実績として出してしまうと、運用担当が「定刻どおりに動いた」と誤読します。★
• ★同じ清掃に履歴が複数ある場合、当方は ended_at が最新の1件を採用する実装にしています（Q1-2）。★ ★予定時刻だとすると、この選び方の根拠が変わります。★
• ★C（保持していない）でも当方の実装は動きます。★ ★その場合は、画面に予定時刻である旨を明示する形に直します。★

---

4. サマリの率・分子・分母の関係をお教えください

★本節の後段のお願いは、バッチの変更を伴う可能性があります。そうと分かるように書いております。★

4-1. お伺いしたいことの全体像

サマリテーブル（customer_summaries / facility_summaries）には ★率4列（operation_ratio / launch_ratio / clean_ratio / error_ratio）★ と ★件数3列（task_count / launch_count / error_count）★ がございます。

★当方は、この率と件数の関係が読み取れずにおります。★ ★関連する内容が分散しないよう、1つの節にまとめてお伺いいたします。★

★補足★: 定義書の比率4列の備考は ★「補足を参照.」★ とのみ記載されており、 ★その「補足」の該当部分が、当方の受領範囲に含まれておりませんでした。★ ★もし文書としてお持ちでしたら、それをお送りいただくだけで本節（Q4-1〜Q4-4）はすべて解決します。★

4-2. お伺いしたいこと（4問）

★Q4-1. 率4列は、それぞれどの式で算出されていますでしょうか★

★分子と分母が何かを、1行ずつお教えいただけますと助かります。★

列	当方の理解	ご回答（分子 ÷ 分母）
operation_ratio（稼働率）	清掃実施回数 ÷ 清掃予定回数
launch_ratio（出発成功率）	定刻出発回数 ÷ 清掃予定回数
clean_ratio（清掃完了率）	★Σ清掃面積 ÷ Σ清掃対象面積（面積ベース）★
error_ratio（エラー発生率）	エラー発生回数 ÷ 清掃実施回数

★特に分からずにおります点★: ★件数列は task_count / launch_count / error_count の3つだけで、 operation_ratio の分子にあたる「清掃実施回数」の列が見当たりません。★ ★このため当方の実装では、当期（進行中の週・月）の稼働率と出発成功率が必ず同じ値になっております。★ ★これが正しいのかどうかを判断できずにおります。★

★Q4-2. 件数3列の定義をお教えください（特に launch_count）★

当方は、清掃詳細ログの画面で「その清掃が出発したかどうか」を次のように判定しており、★実装済み★です。

出発した = clean_status_histories に行がある かつ その行の clean_error が 1（異常(清掃未実施)）ではない

★サマリの launch_count も同じ定義でしょうか。★

選択肢	内容
A	★同じ。clean_error != 1 の件数★
B	★clean_error = 0（正常）のみを数える★（2 / 3 / 4 も出発していない扱い）
C	★「定刻」を判定している★（予定時刻から一定時間内に開始したものだけ。その場合、猶予時間もお教えください）
D	その他（お教えください）

★あわせて、task_count（清掃予定回数と理解しております）と error_count の数え方も 一言でお教えいただけますと助かります。★

★Q4-3. 率カラムと、件数カラムから再計算した値は一致しますでしょうか★

★当方の検証用ダミーデータで検算したところ、一致しない行がございました。★

★先にお断りいたします★: ★当方はまだ実データに接続できておりません。★ ★下記はいただいたDDLから当方がローカルに作ったダミーデータに対する検算です。★ ★差が出た原因が当方の作ったデータ側にある可能性が高いと考えております。★ ★貴社のバッチに問題がある、という指摘ではありません。★

項目	実測値
突き合わせた行数	★施設サマリ 24行★
食い違った行数	★6行★
最大の差	★0.5 ポイント★
例	facility_id = 4: ★launch_ratio = 84.5★ に対し、★launch_count / task_count × 100 = 85.00★

選択肢	内容
A	★一致する★
B	★丸めのぶんだけ、わずかにずれることがある★
C	★率と件数は別の元データから作っているため、必ずしも一致しない★

★Q4-4. 率カラムの丸め方をお教えください★

double(4,1)（小数第一位）に格納する際、小数第二位以下をどう処理されていますでしょうか。

選択肢	内容
A	四捨五入
B	切り捨て
C	切り上げ

★★お願い（Q4-3 が B / C の場合）★★

★もし率と件数が一致しない作りでしたら、一致する形にしていただけないでしょうか。★ ★バッチの変更を伴うお願いですので、難しければ「一致しません」とお知らせいただくだけで結構です。★ ★その場合、当方は差が出ても異常とみなさない実装にします。★

4-3. ★なぜお伺いするか★

• ★定義が違うと、レポート画面の「出発成功率」と、清掃詳細ログの「出発」の件数が食い違います。★ ★同じ画面群の中で数が合わないと、運用担当はどちらを信じてよいか分かりません。★
• ★当方は、サマリの値を当方の計算で上書きしない方針です。★ ★貴社のバッチが出した値をそのまま表示しますので、定義を合わせておく必要があります。★
• ★当方の設計方針では、サマリは「丸める前の小数」と「分子・分母」の両方を持ち、 検算できることを前提としております。★ ★貴社が件数列を用意してくださっているのも、この趣旨と理解しております。★
• ★実データに接続したあと差が出たときに、「当方の実装の誤り」なのか 「バッチの仕様どおり」なのかを切り分けられません。★ ★先に「一致するはず／しないはず」が分かっていれば、当方だけで判断できます。★

---

5. 未実施の行（clean_error = 1）の、ほかの列には何が入りますでしょうか

★本節は、1章の Q1-1 が A（行が作られる）だった場合のお伺いです。★ ★Q5-2 の後半は、収集処理の変更を伴う「お願い」です。そうと分かるように書いております。★

5-1. お伺いしたいこと（2問）

★Q5-1. clean_error = 1 の行の clean_status には何が入りますでしょうか★

clean_status_histories.clean_status の備考は、定義書上 ★「2: 清掃終了(セキュリティ有効), -1: 清掃完了(セキュリティ無効)」の2値のみ★ で、 ★未実施を表す値がありません。★

選択肢	内容
A	★既定値の 0 が入る★
B	2 が入る
C	-1 が入る
D	その他（お教えください）

★Q5-2. task_area / clean_area / clean_ratio は 0 でしょうか★

選択肢	内容
A	★3列とも 0★
B	task_area には予定していた清掃対象面積が入る（clean_area / clean_ratio は 0）
C	その他（お教えください）

★★あわせて、お願いがございます（収集処理の変更を伴います）★★

★もし A（3列とも 0）でしたら、task_area にだけは「予定していた清掃対象面積」を 入れていただけないでしょうか。★

★難しい場合は、現状のままで結構です。★ ★当方は clean_error を見て未実施を判別する実装にしておりますので、 「0 が入る」と確定していれば、それに合わせて実装します。★ ★値が分かることが第一で、変更は二の次です。★

5-2. ★なぜお伺いするか★

★清掃完了率が面積ベース（Σ清掃実施面積 ÷ Σ清掃対象面積）だからです。★

★未実施の行の task_area が 0 だと、その清掃が分母から丸ごと抜けます。★ 結果として ★「実施できなかった日が多い施設ほど、完了率が高く出る」★ という 逆転が起きます。予定面積が入っていれば、分母に残り、実態に近い率になります。

また、clean_ratio についても理由がございます。

• ★当方は clean_ratio = 0 を「出発はしたが、清掃がほとんど進まなかった」として ×判定で表示しております。★
• ★つまり clean_ratio だけを見ても、「0% しか清掃できなかった」と 「そもそも実施していない」を区別できません。★
• ★現在は clean_error で区別できておりますので、支障はありません。★ ★ただし、未実施の行に何が入るかを取り違えると、この区別が崩れます。★

---

6. clean_error が 2 / 3 / 4 のときの扱いについて

6-1. 現状の理解

clean_status_histories.clean_error には、次の値があると伺っております。

0: 正常
1: 異常(清掃未実施)
2: 異常(セキュリティ有効)
3: 異常(D-S制御盤異常)
4: 異常(清掃ロボット異常)

★当方は現在、「1 以外は未実施ではない（＝出発した）」として扱っております。★ ★そのうえで、2 / 3 / 4 の行について次の点が分かりませんでした。★

6-2. お伺いしたいこと（6問）

★Q6-1. clean_error が 2 / 3 / 4 のとき、robot_error_reports にも行は作られますでしょうか★

選択肢	内容
A	★2 / 3 / 4 のいずれも作られる★
B	★4（清掃ロボット異常）のときだけ作られる★
C	★作られない★（履歴の clean_error にだけ記録される）
D	場合による（条件をお教えください）

★Q6-2. 作られる場合、その行の clean_timetable_id は埋まりますでしょうか★

選択肢	内容
A	★埋まる★（どの清掃のエラーかを対応づけられる）
B	空（NULL）のことがある

★埋まる場合、それが「事前チェックの行」と「本清掃の行」のどちらを指すかは、 ★7章の Q7-1★ でお伺いしております。★

★Q6-3. 2 / 3 / 4 の行の clean_ratio と面積（task_area / clean_area）には何が入りますでしょうか★

選択肢	内容
A	★途中まで清掃した実際の値が入る★（例: 40% まで進んで異常終了したら clean_ratio = 40）
B	★0 が入る★（異常なので実績は記録しない）
C	値によって違う（違う場合、どれがどちらかをお教えください）

★Q6-4. 1回の清掃で複数の異常が同時に起きた場合、clean_error はどれになりますでしょうか★

★clean_error は1カラムですので、1つの値しか入りません。★ ★優先順位の規則がございましたらお教えください★（例:「1 が最優先」「後から起きたもので上書き」など）。

★Q6-5. clean_error に 5 以上の値が入る可能性はございますでしょうか★

unsigned tinyint（0〜255）ですので、将来の拡張余地があると理解しております。

選択肢	内容
A	★0〜4 のみ。5 以上は入らない★
B	入りうる（★予定されている値がありましたらお教えください★）

★Q6-6. clean_statuses.clean_error と clean_status_histories.clean_error の使い分けをお教えください★

★同じコード表ですが、定義書の論理名が異なっております★ （clean_statuses 側が ★「エラー」★、clean_status_histories 側が ★「結果」★）。

選択肢	内容
A	★同じ意味。clean_statuses が最新、履歴側が過去分★
B	意味が違う（★違いをお教えください★）

★補足★: ★当方は現在、履歴側（clean_status_histories）だけを読んでおります。★ ★これで差し支えないかもあわせてお教えいただけますと助かります。★

6-3. ★なぜお伺いするか★

• ★当方のアラート画面は、robot_error_reports を元に作っております。★
• ★したがって Q6-1 が C（作られない）の場合、履歴側にだけ異常が記録され、 その清掃はアラートに一切上がってきません。★ ★運用担当は、清掃詳細ログを1行ずつ見に行かないと気づけないことになります。★ ★この場合は、当方が履歴側も見てアラートを組み立てる実装に変えます。★
• ★逆に A（両方に作られる）の場合は、同じ出来事を二重に数えないよう気をつける必要があります。★ ★Q6-2 で clean_timetable_id が埋まるのであれば、当方で突き合わせて重複を除けます。★
• ★Q6-3 は、清掃詳細ログの完了率と◎○△×判定の意味が変わります。★ ★B（0が入る）ですと、途中まで清掃できた清掃も一律 × になります。★
• ★Q6-5 は、当方が「1 以外は出発した」という実装にしているためです。★ ★5 以上に「未実施」を意味する値が増えると、その清掃が出発した扱いになってしまいます。★

★いずれも当方で対応できます。どちらなのかが分かれば十分です。★

---

7. robot_error_reports.clean_timetable_id は、事前チェックの行と本清掃の行のどちらを指しますでしょうか

7-1. 現状の理解

clean_timetables には、★本清掃の行★ と ★その事前チェックの行（precheck が 1 / 2、parent_id で本清掃を指す）★ があると理解しております。

★当方は「robot_error_reports.clean_timetable_id は事前チェックの行を指す」という前提で実装しております。★

7-2. お伺いしたいこと（1問）

★Q7-1. robot_error_reports.clean_timetable_id はどちらの行を指しますでしょうか★

選択肢	内容
★A★	★事前チェックの行を指す★（precheck が 1 / 2 の行）
★B★	★本清掃の行を指す★（precheck が 0 の行）
C	エラーの発生時点による（★清掃中に発生したエラーがどちらに付くかをお教えください★）

★あわせて、清掃中（本清掃の実行中）に発生したエラーは、どちらの行に紐づくかをお教えください。★

7-3. ★なぜお伺いするか★

• ★レポート画面のエラー発生率の分子を、clean_timetable_id から本清掃の行へたどり直して数えております。★
• ★このため、本清掃の行に直接付く運用ですと、たどり直しが空振りし、 そのエラーが1件も数えられません。★
• ★★結果としてエラー発生率が 0% と表示されますが、例外もエラーログも出ません。★★ ★「エラーが無い」と読める画面になってしまうため、お伺いしております。★

---

8. control_error_histories は、実際に使われるテーブルでしょうか

8-1. 資料のあいだで食い違いがございます

★当方の受領資料のなかで、このテーブルの位置づけが食い違っております。★

出典	記載
★テーブル定義書の役割欄★	★「現時点では未使用. 清掃状態, 清掃状態履歴で確認できるため.」★
★第2回のご回答★	★このテーブルの status の値域（0: 未対応 / 1: 対応中 / 2: 対応済）を直接お教えいただいております★
★同・制御盤の生死報告について★	★「制御盤の生死報告が来ない場合は、サーバーから『制御盤異常』としてエラーが上がる」★
★DB更新権限のお願い（10章）★	★このテーブルの4カラムを更新対象に含めております★

★当方は「使われる」と解釈し、D-Secアラート画面（F-07）をこのテーブルから作っております。★

8-2. お伺いしたいこと（1問）

★Q8-1. control_error_histories には、実際にデータが入りますでしょうか★

選択肢	内容
★A★	★入る★（定義書の役割欄の注記が古い）
★B★	★入らない・未使用★（★制御盤異常はどのテーブルで確認すればよいかをお教えください★）
C	今は入らないが、今後入れる予定（★時期の目安がありましたら★）

8-3. ★なぜお伺いするか★

• ★B（未使用）の場合、D-Secアラート画面が常に空になります。★ ★画面としては表示されるものの、1件も出ないという状態です。★ ★この場合は、当方が別のテーブルから組み立て直す作り替えが必要になります。★
• ★実データに接続すれば件数は当方で数えられますが、「たまたま0件」なのか 「そもそも入らない設計」なのかは、当方には判断できません。★
• ★このテーブルについては、これまで一度もお伺いしておりませんでした。恐れ入ります。★

---

9. 軽い確認を2件、お願いいたします

★どちらも「無ければ無いで結構です」という性質のものです。★

9-1. お伺いしたいこと（2問）

★Q9-1. 事前チェック時点のバッテリー残量を保持するご予定はございますでしょうか★

robots.battery は ★現在値のみ★ で、履歴が無いと理解しております。 このため、★事前チェック（60分前 / 30分前）の時点でバッテリーが何%だったか★ を、 当方から取得する手段がございません。

選択肢	内容
★A★	★保持する予定は無い★
B	保持する予定がある（★どのテーブル・列になるかをお教えください★）

★A（予定が無い）でしたら、当方は事前チェック画面のバッテリー欄を恒久的に空欄として確定いたします。★ ★その確認だけができれば十分です。追加のご対応は不要です。★

★Q9-2. Pudu Cloud から、清掃エリア別の完了率は取得できますでしょうか★

要件定義の段階から未解決のまま持ち越している項目です。 ★清掃1回のなかで、エリアごとに何%清掃できたか★ という粒度のデータです。

選択肢	内容
★A★	★取得できる★（★どのテーブルに入る想定かをお教えください★）
★B★	★取得できない★（Pudu Cloud API が返さない）
C	未確認（★その旨をお知らせいただければ、当方は B と同じ扱いで進めます★）

★B または C でしたら、当方はこの機能を Phase B 送りとする判断材料にいたします。★ ★現在は、該当のAPIを「未実装」を返す形で仮置きしております。★

9-2. ★なぜお伺いするか★

• ★どちらも「無い」と分かれば、当方は画面から外す・Phase B に送る、という判断ができます。★
• ★分からないままですと、実装するかどうかを決められず、仮置きのまま残り続けます。★
• ★貴社に何かをご対応いただきたいという趣旨ではございません。★

---

10. ★継続のお願い: DB更新用アカウントの発行（第5回・第6回からの継続）★

10-1. お願いしている内容（既に範囲は合意済みです）

★下記の2テーブル・4カラムのみ UPDATE 可、というアカウントの発行をお願いしております。★

テーブル	更新するカラム
robot_error_reports	★status / comment / responded_at / resolved_at★
control_error_histories	★status / comment / responded_at / resolved_at★

★範囲についてはすでに合意いただいており、変更のお願いはございません。★ ★第6回では「後で必要なテーブルに更新権限を付与する」とのご連絡をいただいております。★

10-2. お伺いしたいこと（1問）

★Q10-1. 発行の時期の目安をお教えいただけませんでしょうか★

★急ぎではございません。★ ★「いつ頃になりそうか」という目安だけで結構です。★ ★未定でしたら「未定」とお知らせいただくだけでも助かります。★

10-3. ★なぜお伺いするか★

• ★2026-09-03 からお願いしている件で、当方の外部待ちのなかでいちばん古いものです。★ ★第7回では書き漏らしてしまい、失礼いたしました。★
• ★当方の作業は止まっておりません。★ ★アラート（F-03）と D-Secアラート（F-07）の「対応状況を更新する」機能は、 画面まで実装済みで、書き込み先を差し替えるだけの状態です。★
• ★ただし、対応状況を更新するAPIだけは、書き込み先が無いため未実装のままとなっております。★ ★時期の目安が分かれば、そこに合わせて段取りいたします。★

---

おわりに

★本書では10件をお伺いしております。数が多くなってしまい、恐れ入ります。★

★まずは、この3つだけでも★

★お忙しいと存じますので、優先度の高い3つを先に挙げます。★ ★この3つにご回答いただければ、当方は先へ進めます。★

順	項目	何が起きるか
★1★	★1. 未実施の清掃にも履歴の行は作られるか（Q1-1）★	★A / B のどちらかを選んでいただくだけです。★ ★外れていると、正常な清掃まで「出発失敗」として並びます（過剰検知）★
★2★	★2. DATETIME のタイムゾーン（特に Q2-3 の実データ1行）★	★ずれていると、翌朝の確認時に深夜の清掃が画面から消えます。運用そのものが成り立ちません★。★Q2-3 の1行をいただければ、あとは当方で検証できます★
★3★	★4. サマリの率・分子・分母（Q4-1〜Q4-4）★	★レポート画面の数字が、清掃詳細ログの件数と食い違います★。★「補足」の文書があれば、それをお送りいただくだけで解決します★

残りの優先度

順	項目	理由
4	7. robot_error_reports.clean_timetable_id の指す先	★エラー発生率が 0% と表示される可能性があります。例外が出ないため気づけません★
5	3. 実際の開始・終了時刻の所在	画面に予定時刻を実績として出してしまうためです
6	6. clean_error 2 / 3 / 4 の扱い	★アラートに上がるか、完了率がどうなるかが変わります★
7	8. control_error_histories は使われるか	★未使用でしたら D-Secアラート画面を作り直します★
8	5. 未実施行の他カラムの値	★値が分かれば十分です。変更は二の次です★
9	★10. DB更新用アカウント★	★最古の待ち（2026-09-03〜）ですが、急ぎません。時期の目安だけで結構です★
10	9. 軽い確認2件	★「無い」と分かれば当方で判断できます★

★第7回の3件について★

★第7回でお願いしている3件（接続先 / precheck の値域 / DDL の未反映4件）は、 本書によって取り下げるものではありません。★

★とりわけ接続先は、本書の10件を含めた全体を通じて最優先です。★ ★接続できれば、当方で数えられるものは当方で確認しますので、 その分だけ貴社への照会が減ります。★

（本書の1・2・4・5・6・8 も、接続できていれば当方で実データを見て ★部分的には★ 自力で確認できたものです。★ただし「その値が何を意味するか」 「たまたま0件なのか、そもそも入らないのか」は当方には判断できませんので、 いずれにせよお伺いすることになります★。）

お忙しいところ恐れ入りますが、よろしくお願いいたします。

---

★ご回答欄★

★この表に一言だけご記入いただく形でも、下の自由記入欄にまとめてご記入いただく形でも結構です。★ ★上位3つ（Q1-1 / Q2-3 / Q4-1〜Q4-4）だけでも助かります。★

質問番号	質問の要約	ご回答
★★Q1-1★★	★未実施の清掃にも clean_status_histories の行は作られるか（A / B / C）★
★Q1-2★	1つの clean_timetable_id に履歴は必ず1行か（A / B）
★Q2-1★	DATETIME は日本時間の壁時計値か、UTC か（A / B / C）
★Q2-2★	収集処理が書き込むときの基準（A / B / C）
★★Q2-3★★	★clean_timetables の1行の start_at の生値と、それが指す実際の時刻★
★Q2-4★	本番DBの time_zone 設定と、収集処理の接続時の設定
Q3-1	clean_status_histories.started_at / ended_at は予定時刻か（A / B / C）
Q3-2	実績時刻の所在（A / B / C / D）
★★Q4-1★★	★率4列の計算式（分子 ÷ 分母）。または「補足」の文書★
★Q4-2★	task_count / launch_count / error_count の定義（launch_count は A / B / C / D）
★Q4-3★	率と件数から再計算した値は一致するか（A / B / C）
★Q4-4★	率の丸め方（A / B / C）＋検算のお願いの可否
Q5-1	clean_error = 1 の行の clean_status（A / B / C / D）
Q5-2	同・task_area / clean_area / clean_ratio（A / B / C）＋面積のお願いの可否
Q6-1	clean_error 2/3/4 でエラー報告も作られるか（A / B / C / D）
Q6-2	その行の clean_timetable_id は埋まるか（A / B）
Q6-3	2/3/4 の行の clean_ratio と面積（A / B / C）
Q6-4	複数の異常が同時に起きた場合の clean_error の優先順位
Q6-5	clean_error に 5 以上が入りうるか（A / B）
Q6-6	clean_statuses.clean_error と履歴側の使い分け（A / B）
★Q7-1★	robot_error_reports.clean_timetable_id は事前チェック行か本清掃行か（A / B / C）
★Q8-1★	control_error_histories にデータは入るか（A / B / C）
Q9-1	事前チェック時点のバッテリー残量を保持する予定（A / B）
Q9-2	Pudu Cloud からエリア別完了率は取得できるか（A / B / C）
★Q10-1★	★DB更新用アカウントの発行時期の目安（未定でも結構です）★

自由記入欄

第7回の3件（未回答分）

項目	ご回答
★接続先（ホスト名またはIP / ポート）★
接続元IP制限の有無 / SSL-TLS の要否 / ステージングか本番か
clean_timetables.precheck の値の範囲・反映時期・既存データの扱い・新旧混在期間の有無
DDL の未反映4件（A-2 採番 / A-3b 桁数 / B-2 索引 / B-3b DEFAULT）