# 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. ★★**1章 N-14** — ステージング・本番DBのタイムゾーンと、時刻の列に書く値（a〜d）★★
2. ★★**2章 N-2 / N-3 / N-4** — `status` の値の意味 / `clean_ratio` の作り方 / `task_area`・`clean_area` の意味★★