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 であることのご教示、あらためてありがとうございました。引き続きよろしくお願いします。

TeamWorks 様 確認事項（第7回）