# TeamWorks 様 確認事項（第7回）

**作成: 2026-09-10 / 作成者: DFA Robotics**

★**最新のDDL（`clean_watch_20260909.sql`）をお送りいただき、ありがとうございました。**★
（2026-09-09 受領。第6回でお願いしていた項目です）

また、★**率のカラムを小数第一位まで持つ形（`double(4,1)`）に変更いただき、ありがとうございました。**★
★**当方からお願いしていた内容が、そのまま反映されておりました。**★
これで当方の判定処理が正しく行えるようになります（詳細は第1部）。

本書は次の5部構成です。

| # | 内容 | 優先度 |
|---|---|---|
| **1. 照合結果のご共有** | いただいたDDLを当日中に照合しました。MariaDB の件と、★依頼2件の取り下げ★もこちらです | ★**回答不要**★ |
| **2. 接続先（ホスト名・ポート）** | ★**第6回からの継続。あとはこれだけです**★ | ★**最優先**★ |
| **3. DDL の未反映項目（4件）** | 採番・桁数・DEFAULT・索引の食い違いです | ★お手すきの折に★ |
| **4. `precheck` に入る値の範囲** | 反映時期と既存データの扱い | 中 |
| **5. 面積の型変更について** | ★**共有のみ。質問はありません**★ | ★**回答不要**★ |

★**今回は、お伺いすることを3件に絞りました。**★
（★**接続先** / **DDL の未反映4件** / **`precheck` の値域**★）
★**お伺いする件数が少ないほど、早くお返事をいただけると考えたためです。**★
★**第1部と第5部は当方からの共有ですので、回答は不要です。**★

---

## 1. 照合結果のご共有（★回答不要です★）

第6回で「★**受領しましたら、その日のうちに照合してご報告します**★」とお約束していた件です。
★**2026-09-09 に受領し、当日中に照合を完了しました。**★

### 1-1. 照合方法

★**ローカルの MySQL に読み込み、09-07版・09-02版と `information_schema` で機械的に差分を取りました。**★
目視ではなく、列名・型の両方を双方向で突き合わせています。

### 1-2. ★率のカラムが小数第一位になっていました（13列）★

| 変更前 | 変更後 |
|---|---|
| `tinyint unsigned`（整数） | ★**`double(4,1)`（小数第一位）**★ |

対象は ★**13列**★ です。

| テーブル | 列 |
|---|---|
| `customer_summaries` / `facility_summaries` | `operation_ratio` / `launch_ratio` / `clean_ratio` / `error_ratio`（各4列） |
| `clean_status_histories` / `clean_statuses` / `clean_task_reports` / `robots` / `section_robot_statuses` | `clean_ratio`（各1列） |

★**これで当方の判定が正しく行えるようになりました。ありがとうございます。**★

当方は清掃完了率から4段階（◎○△×）の判定を行っており、
★**その境界値は 90.0 / 90.1 / 70.0 / 70.1 / 10.0 / 9.9 と、すべて小数第一位までです。**★

整数で格納されていると、★**例えば 89.6% が `90` に丸められて格納され、
本来「○」であるべきものが「◎」になってしまう**★という問題がありました。
★**今回の変更で、この問題は解消しました。**★

### 1-3. テーブル・列の増減はありませんでした

★**`CREATE TABLE` は 39 で、09-07版・09-02版と同数です。**★ テーブル名の集合も完全に一致しました。
★**列の増減もありません。**★ 今回の変更は型（と一部の DEFAULT）だけでした。

なお、面積のカラムも `decimal` から `double` に変わっておりましたので、
この点だけ第5部で申し添えます（★**当方に実害はありません**★）。

### 1-4. ★本番が MariaDB であることをお教えいただき、ありがとうございました★

★**本書をお送りする前に、本番サーバが MariaDB であることをお教えいただきました。ありがとうございます。**★

（09-09版のダンプヘッダが `5.5.5-10.11.13-MariaDB-log` になっており、
09-07版までの `MySQL 8.0.41` と異なっておりましたので、お伺いしようとしていた件です。
★**先にご回答いただけましたので、本書からは質問を取り下げました。**★）

当方の対応状況を申し添えます。

| # | 内容 |
|---|---|
| 1 | ★**アプリの実装に生の SQL は1件もありません。**★ すべて Prisma のクエリビルダ経由ですので、★**現時点で対応が必要な箇所はありません**★ |
| 2 | ★**DBクライアントのドライバも、すでに MariaDB 用のもの（`@prisma/adapter-mariadb`）を使っております**★ |
| 3 | ★**「どうしても MariaDB 特有の DML を使いたい場合はその箇所をお知らせください」とのご指示、承知しました。**★ ★**その必要が生じた際にご連絡します。**★ |

なお、★**当方のローカルの検証環境は MySQL です**★ので、
★**今後もし生の SQL を書く場合は、MySQL と MariaDB の双方で通る書き方に注意いたします。**★

### 1-5. ★これまでお願いしていた2件（外部キー／索引・主キー）を、今回の依頼から外します★

第5回・第6回でお願いしておりました
★**B-1（`clean_timetable_id` の外部キー／索引）**★ と
★**A-1（`robot_error_reports` の主キー）**★ について、
★**当方の実装が固まり、いずれも当方側で支障が無いことがはっきりしました。**★
★**今回の依頼から外させてください。**★

#### B-1（`clean_timetable_id` の外部キー・索引）

★**当方は、これらのテーブルを全件取得し、アプリ側で突き合わせる実装にしました。**★

- `clean_timetables` / `clean_status_histories` / `robot_error_reports` を、
  それぞれ ★**WHERE 句なしの全件取得**★で読み出しています
- 読み出したあと、`clean_timetable_id` をキーにした対応表をメモリ上に作り、そこで結合しています
- ★**つまり、`clean_timetable_id` で「検索」をしておりません。**★
  ★**索引は WHERE 句で絞り込むときに効くものですので、この実装では使われません。**★

★**この実装はすでに完成しており、外部キーが無いまま清掃ログの画面が動いております。**★

また、★**どの索引が必要かは、実際のクエリの形と、実データの量・分布で決まります。**★
★**当方はまだ実データを1行も見ておらず、絞り込みのクエリも書いておりません。**★
★**この状態で特定の索引を名指しでお願いするのは、当方の根拠が薄いと考え直しました。**★

★**したがって、現時点で支障はありません。**★
★**将来クエリの形が変わって索引が必要になりましたら、
その時点で具体的なクエリを添えて、あらためてご相談します。**★

過去の確認書では外部キーの追加をお願いしておりましたが、
★**当方の実装方針が定まった結果、当方の見立てが変わりました。**★
お手数をおかけしました。

#### A-1（`robot_error_reports` の主キー）

`error_id` を識別子として使う方針は第4回のご回答でいただいており、当方はその前提で実装しております。

★**主キーが無くても当方の実装は動いております。`error_id` に UNIQUE がありますので、
一意性は担保されています。**★
★**当方の実装で支障が無い以上、DDL の変更をお願いする根拠がありませんので、
こちらも依頼から外します。**★

---

## 2. ★接続先（ホスト名・ポート）をお教えいただけますでしょうか — 最優先★

★**第6回でもお願いした件で、恐れ入りますが繰り返しになります。**★

★**参照用アカウントは 2026-09-08 にいただいておりますので、あとは接続先だけです。**★

★**接続先のホスト名（または IP アドレス）と、ポート番号**★

をお教えいただければ接続できます。

### あわせて確認させてください

| # | 確認したいこと | 補足 |
|---|---|---|
| 1 | ★**接続元IPの制限はありますか**★ | ある場合、**当方の接続元をお伝えします**のでお知らせください |
| 2 | ★**SSL/TLS 接続は必須でしょうか**★ | 必須の場合、**証明書の受け渡し方法**もお教えください |
| 3 | ★**接続先はステージング環境でしょうか、本番環境でしょうか**★ | 当方の扱い（参照のみ / 負荷のかけ方）を合わせたいためです |

### ★なぜ急いでお願いしているか★

- ★**9月中に PPIH 様向けにデモを実施する可能性があります。**★
- ★**実データでお見せできるかどうかが、この接続情報で決まります。**★

### ★当方の準備状況★

★**接続情報さえいただければ、すぐに使える状態になっております。**★

| # | 済んでいること |
|---|---|
| 1 | ★**いただいたDDLからローカルにDBを作成し、実DDLと列レベルで完全一致させました**★（差分0件を機械的に確認済み） |
| 2 | ★**`prisma db pull` でスキーマを取り込み済みです**★（今回の23列の型変更も反映済み） |
| 3 | ★**施設マスタ・スケジュール・D-Secログ・D-Secアラート・清掃詳細ログの5画面が、そのローカルDB経由で動くところまで実装済みです**★ |

★**接続先をいただければ、接続文字列を差し替えるだけです。**★

また第6回でお伝えしたとおり、接続でき次第、`error_type` の値の分布・`robots.status` の実出現値・
週次サマリの `week` の値域など ★**当方で数えられるものは当方で確認します**★ ので、
★**その分だけ貴社への照会が減ります。**★

---

## 3. DDL の未反映項目（4件）を、お手すきの折にご対応いただけますでしょうか

★**お忙しいところ恐縮です。3回目のお願いになります。**★
第5回・第6回でお願いしていた項目のうち、★**4項目が 09-09版でも未反映でした。**★

★**今回のDDLは率と面積の型変更が主眼だったかと存じますので、
これらは単に今回のスコープに入っていなかっただけかと思っております。**★
状況だけ共有させてください。

| # | お願いしていた内容 | ★09-09版の実測★ |
|---|---|---|
| A-2 | 履歴テーブルの `id` を AUTO_INCREMENT で採番 | `clean_status_histories.id` / `clean_timetable_histories.id` とも `bigint(20) unsigned NOT NULL`。AUTO_INCREMENT 無し |
| A-3b | `facility_contacts.email` を `varchar(100)` に | `varchar(255) DEFAULT NULL` のまま（`contact_type` は `tinyint(3) unsigned` で反映済みです） |
| B-2 | `robot_task_versions.clean_schedule_id` にインデックス | KEY は `robot_task_versions_robot_id_foreign`（`robot_id`）のみ。`clean_schedule_id` のインデックスは0件 |
| B-3b | `security_status_histories.reported_at` に DEFAULT | `timestamp NOT NULL`、DEFAULT なしのまま |

### 3-1. ★この4件は、当方の設計上のお願いではなく、具体的なズレです★

1-5 で取り下げた2件（外部キー／索引・主キー）は、
★**「DBの設計をどうするか」という判断を伴うお願い**★でした。
★**当方の実装方針が固まり、必要がなくなりましたので取り下げました。**★

★**一方、この4件は性質が違います。**★
★**いずれも、採番・桁数・DEFAULT・索引の有無という、具体的で機械的な食い違いです。**★

| # | 食い違いの中身 | 補足 |
|---|---|---|
| A-2 | ★採番の仕組み★ | `id` に AUTO_INCREMENT が無く、★**誰が採番するのかが決まっていない状態**★です |
| A-3b | ★桁数★ | 「`email` は `varchar(100)` とします」とご回答いただいた桁数が、★`varchar(255)` のまま★です |
| B-2 | ★索引の有無★ | ★**定義書で `fk` と記載されている列**★ですが、実DDLには外部キーも索引もありません |
| B-3b | ★DEFAULT の有無★ | `timestamp NOT NULL` に DEFAULT 句がありません |

★**いずれも「どちらが正なのか」が当方には判断できない箇所です。**★
★**意図的なものでしたら、その旨だけお知らせいただければ結構です。**★

### 3-2. ★お手すきの折で結構です★

★**いずれも当方の開発を止めておりません。**★
★**お手すきの折に、まとめてご対応いただければ十分です。**★

> ★**急かす意図はありません。**★ 状況が分かれば大丈夫です。
> ★**次回まとまった段階でDDLをいただければ、同じように当日中に照合してご報告します。**★

---

## 4. `clean_timetables.precheck` に入る値の範囲をお教えいただけますでしょうか

### 4-1. 現状の理解

- `clean_timetables.precheck` は現行 ★**`tinyint unsigned` / 既定値 `0`**★ です（09-09版でも変化なし）
- ★**DFA 側で「`0` = 本清掃 / `60` = 60分前 / `30` = 30分前」のように、分前の数値をそのまま入れる方向で
  ご検討いただいている**★ と伺っております
- 設定値によっては ★**`20` なら20分前**★ のように、任意の分数が入りうるとも伺っております

### 4-2. お伺いしたいこと

| # | 内容 |
|---|---|
| 1 | ★**この理解で合っていますでしょうか**★ |
| 2 | ★**いつ頃反映される見込みでしょうか**★ |
| 3 | ★★**既存のデータはどうなりますでしょうか**★★ — ★`1` / `2` のまま残るのか、`60` / `30` に更新されるのか★ |
| 4 | ★★**新旧の値が混在する期間はありますでしょうか**★★ |
| 5 | ★**`0` 以外に予約値はありますでしょうか**★ |

★**特に4番をお伺いしたいです。**★
★**混在すると、当方は `1` を「1分前」と読み違えてしまうためです。**★
★**値だけを見て新旧を判別する方法がありませんので、期間が分かれば当方で切り替え時期を合わせられます。**★

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

★**アラート画面で「60分前の異常」「30分前の異常」を出し分けるのに、この値を使います。**★

★**値の意味を取り違えると、現場への連絡タイミングの判断を誤ります。**★
「30分前のチェックで異常が出た」のか「60分前で出た」のかによって、
現場に間に合うかどうかが変わるためです。

なお、★**DDL からは値の意味が読めませんでした**★（カラムコメントが空のため）。
★**型は `tinyint unsigned`（0〜255）ですので、`60` も `30` も `20` も、型の変更なしで入ります。**★
つまり ★**値の意味の変更は DDL には現れません**★ ので、お伺いする次第です。

---

## 5. 面積のカラムの型変更について（★共有のみ。回答は不要です★）

★★**これは要望でも質問でもなく、事実の共有だけです。**★★

### 5-1. 実測

09-09版で、面積のカラムも型が変わっておりました（★**10列**★）。

| 変更前 | 変更後 |
|---|---|
| `decimal(12,6) unsigned` | ★**`double(12,6)`**★（`customer_summaries` / `facility_summaries` は `double(14,6)`） |

| テーブル | 列 |
|---|---|
| `clean_status_histories` / `clean_statuses` / `clean_task_reports` | `task_area` / `clean_area` |
| `customer_summaries` / `facility_summaries` | `task_area` / `clean_area` |

### 5-2. ★★当方に実害はありません★★

★**この変更で当方が困ることはありません。**★ 理由は2つです。

| # | 理由 |
|---|---|
| 1 | ★**viewer に面積を表示する箇所は1つもありません**★（画面に出るのは % だけです） |
| 2 | ★**面積は完了率の計算材料としてのみ使う想定でしたが、率を小数でいただけるようになったため、当方で計算し直す必要も無くなりました**★ |

★**したがって、お戻しいただく必要はありません。**★

### 5-3. ★意図の確認は今回は見送ります★

当初は「率の小数化に伴う変更でしょうか」とお伺いしようと考えておりましたが、
★**上記のとおり当方に実害がありませんので、今回は質問といたしません。**★
★**お伺いする件数を絞り、早くお返事をいただきたいためです。**★

もし何か意図がおありでしたら、★**次回ついでの折にお聞かせいただければ十分です。**★

---

## おわりに

★**今回は、お伺いすることを3件に絞りました。**★
★**お伺いする件数が少ないほど、早くお返事をいただけると考えたためです。**★

優先度をつけるとすれば次の順です。

| 順 | 項目 | 理由 |
|---|---|---|
| ★**1**★ | ★**接続先（ホスト名・ポート）**★ | ★**アカウントはいただいておりますので、これだけで接続できます**★。9月中のデモを実データで行えるかがここで決まります |
| 2 | `precheck` の値の範囲と反映時期 | ★新旧混在の期間があるかどうかを特に知りたいです★ |
| 3 | DDL の未反映4件（A-2 / A-3b / B-2 / B-3b） | ★お手すきの折で結構です。当方の開発は止まっていません★ |

★**1（接続先）が最優先です。**★
★**これだけ先にいただければ、当方で確認できることが一気に増え、その分だけ貴社への照会が減ります。**★

なお、これまでお願いしておりました外部キー／索引（B-1）と主キー（A-1）は、
★**当方の実装方針が固まり必要がなくなりましたので、今回の依頼から外しました**★（1-5 に経緯を記しました）。

率のカラムの小数化、そして本番が MariaDB であることのご教示、あらためてありがとうございました。
引き続きよろしくお願いします。