テストDBのデータ出所と、無効になる「実測」の洗い出し（2026-09-17）

作成: 2026-09-17 / ブランチ: develop / HEAD: 0b941b3 / 作成者: 調査担当

★本書は調査と文書化だけです。コードは1行も変更していません。★ ★lib/ app/ components/ prisma/ d-watch-api.yaml は読んだだけです。★ ★docs/decisions.md docs/handoff.md docs/spec.md CLAUDE.md も読んだだけです。★ ★テストDBは読み取りのみ。SELECT と SHOW と information_schema しか実行していません。★ ★本書は決定ではありません。決めるのはユーザーです（7章に判断が要る点をまとめました）。★

0. ★★きっかけ★★

ユーザー（2026-09-17）: ★「サマリの情報はあなたがcursorに依頼したものなので、 情報がおかしいのは当然では？」★

第9回2章が根拠にしていた施設名「メガバリューマート中央本店」「バリューマート北町店」が、 ★当方 fixtures のダミー名（lib/fixtures/clean-logs.ts:95-96 / lib/fixtures/facilities.ts:42）★ だったことを監督が確認したのが発端です。

★本書は「本当にそうか」を1テーブルずつ実測で確かめ、これまでの『実測』のうち何が無効に なるかを仕分けたものです。★

1. ★★結論（先に4行）★★

2. ★★調べ方（再現できる形で）★★

★実測環境★: テストDB（★読み取りのみ★）。接続情報は .env.local（★値は本書に書きません★）。 使い捨てスクリプトはリポジトリ外（スクラッチパッド）に置き、mysql2 で SELECT のみ実行しました。

実行したのは次の5種類だけです。

-- ① 全テーブルの行数
SELECT TABLE_NAME FROM information_schema.TABLES WHERE TABLE_SCHEMA=DATABASE();
SELECT COUNT(*) FROM <各テーブル>;
-- ② 中身の突き合わせ（全列）
SELECT * FROM customers / groups / devices / facilities / sections / robots / controls / ...;
-- ③ 投入時刻・作成時刻
SELECT MIN(created_at), MAX(created_at) FROM <各テーブル>;
SELECT TABLE_NAME, CREATE_TIME FROM information_schema.TABLES WHERE TABLE_SCHEMA=DATABASE();
-- ④ 索引・サーバー設定
SELECT * FROM information_schema.STATISTICS WHERE TABLE_SCHEMA=DATABASE();
SHOW VARIABLES WHERE Variable_name IN ('eq_range_index_dive_limit','version','time_zone','system_time_zone', ...);
-- ⑤ 9件の記録の再実測（判定分布 / 遅延 / 1日あたり件数）

★★時刻の読み方（重要）★★:

SELECT NOW()             → 2026-09-17 03:59:48   （実行時の日本時間は約 12:59）
SHOW VARIABLES system_time_zone → UTC
SHOW VARIABLES time_zone        → SYSTEM

★DBサーバーの時計は UTC です★。★したがって created_at / CREATE_TIME は JST = 値 + 9時間★ として読みます（★scripts/seed-local-db.ts に created_at を書く箇所は grep で0件なので、 これらは DB の DEFAULT current_timestamp が入れた値＝サーバー時計です★）。

3. ★★テーブルごとの出所一覧（全39テーブル・行数つき）★★

3-1. ★★行が入っている17テーブル — すべて当方由来★★（合計 ★1,787行★）

★★先方由来の行は 1行も見つかりませんでした★★。

3-2. ★0行の22テーブル★

cache / cache_locks / clean_link_schedules / clean_task_reports /
clean_timetable_histories / customer_contacts / customer_error_summaries /
facility_contacts / failed_jobs / jobs / job_batches / link_schedules /
migrations / password_reset_tokens / personal_access_tokens /
robot_instruct_histories / robot_task_versions / section_robot_statuses /
security_statuses / security_status_histories / sessions / users

★★これらが0行なのは「当方のシードが書いていないから」であって、 「先方の収集処理が書いていないから」ではありません★★。★0行から何かを読み取ってはいけません★。

★参考★: migrations が0行であること、cache / jobs / sessions / users 等の ★Laravel の雛形テーブルが含まれること★から、★このスキーマは先方の Laravel アプリの マイグレーション定義から作られ、★テストDBには DDL として流し込まれた★と読めます（★推定★）。

3-3. ★★先方由来のもの（＝そのまま根拠にしてよいもの）★★

4. ★★出所の決め手（5点）★★

★どれか1つでは弱いですが、5つが同じ日時を指しているので断定できます★。

5. ★★どうやって入ったか（★推定★。断定しません）★★

★★事実★★:

• ★scripts/seed-local-db.ts は lib/db/local-guard.ts の assertLocalDwatchDatabaseUrl() により、 ★localhost/127.0.0.1 かつ DB名 dwatch_local にしか書けません★（lib/db/local-guard.ts:11-33）
• ★したがって、このスクリプトをそのままテストDBに向けて流すことはできません★
• ★投入時刻（2026-09-13 02:28 JST）は、ボリュームデータのコミット 041a809（2026-09-13 11:34 JST）より 9時間前★です。★つまり流したのは「未コミットの作業ツリーの版」★

★★推定される経路（どれかは特定できていません）★★:

★★いずれにせよ「DFA が入れた」ことは動きません★★。 ★誰がどの経路で入れたかは記録が見つかりませんでした★ （docs/decisions.md / docs/handoff.md を「テストDB＋投入/シード/ダンプ」で grep して0件）。 ★これ自体が申し送りの欠落です★（8章に作法の提案を書きました）。

6. ★★9件の仕分け★★

★判定の基準★:

• ★★構造由来（有効）★★ … information_schema / SHOW CREATE TABLE / SHOW VARIABLES / EXPLAIN の possible_keys / カラムの有無・型 / 権限 — ★行が1行も無くても同じ答えが出るもの★
• ★★データ由来（無効）★★ … 行数・値の分布・合計・「全件が同じ値」・「0行である」 — ★当方が入れた行を数えているだけのもの★

★★追加で見つかった無効（3件）★★

★指示された9件のほかにも、同じ理由で無効になる記録があります★。

★★仕分けの集計★★

6-1. ★★D-141 の結論は維持できるか — できます★★

★問い★: ★「面積はサマリを読まず clean_status_histories から集計する」の根拠が崩れたが、 結論は変わるのか。実装を直す必要があるのか。★

★★答え: 結論は維持。実装の変更は不要です。★★ 理由は3つあります。

★★つまり、崩れたのは「TeamWorks の集計式が合計になっていない可能性が高い」という先方への当て推量の部分だけです★★。 ★★「サマリを読まない」という選択自体は、①②だけで独立に成立します★★。

★直すべきは、決定文のうち次の一文です★（D-141 §1）:

TeamWorks の集計式がこの列を「合計」として書き込んでいない可能性が高い ★これは当方のダミーデータを見て書いたもので、根拠がありません★

6-2. ★★第9回11章（実開始時刻）の結論は維持できるか — できます★★

★11章の主張は2本立てでした★:

★★①だけで「clean_status_histories.started_at は予定時刻の写しと読める」は成立します★★。 ★設問（実開始時刻はどこか）は取り下げる必要がありません★。

★確認済み★: ★docs/handoff/TeamWorks確認事項_第9回_20260915.md は別のエージェントが すでに全面改訂済み★です（2026-09-17 時点で本書の筆者が読んで確認）。 ★冒頭に「おことわり — テスト環境のデータは当方が入れたものでした」が入り、 2章・7章・11章のいずれも②を取り下げ済み★。★本書から先方向け文書へ足すべきことはありません★。

6-3. ★★D-137 の結論は維持できるか — できます★★

★D-137 の本質は「連続日数の降順 + 上限5件」という並べ方と切り方の組み合わせが、 急落（consecutive_problem_days が 1〜2 にしかならない）を★構造的に★押し出す、というロジックです★。 ★実データの7件/5件は、そのロジックの例示にすぎません★。 ★★ロジック自体はデータに依存しないので、結論（APIで件数を切らない）は維持できます★★。

7. ★★訂正注記の文案（そのまま貼れます）★★

★作法★: ★決定は書き換えず、訂正注記を後ろに足す★（前例: D-136 §2 の docs/decisions.md:10281 付近。★引用ブロックで ★★2026-09-17 訂正★★（D-XXX） と書く形★）。

★決定番号は D-XXX のままにしてあります。採番は監督が行ってください★ （grep -n "^### D-" docs/decisions.md | tail -3 で最終番号を実測してから採ること）。

7-1. ★D-141 §1（docs/decisions.md:10995 の段落の直後）★

> ★★**2026-09-17 訂正 — この節の実測は、当方が入れたダミーデータを見たものでした**★★（D-XXX）
>
> ★`facility_summaries` / `customer_summaries` の24行は、★**当方の `scripts/seed-local-db.ts` が
> 投入したもの**★でした（`SUMMARY_TASK_COUNT = 100` / `SUMMARY_TASK_AREA_SQM = 1000` は
> `scripts/seed-local-db.ts:1669-1670`。`clean_ratio` の12値は `lib/fixtures/reports.ts:204-329`）。
> ★**「全24行の `task_area` が 1000 ちょうど」なのも「8月月次と9月第2週で同じ値」なのも、
> 当方がそう入れたからです**★。
>
> ★★**したがって「TeamWorks の集計式がこの列を『合計』として書き込んでいない可能性が高い」
> という記述は取り下げます**★★。★先方の集計バッチは、テストDBで一度も動いていません★
> （サマリ3テーブルの中身がすべて当方のシードで、`customer_error_summaries` は0行）。
>
> ★★**ただし本節の結論（この画面は常にサマリを読まず `clean_status_histories` から集計する）は
> 維持します**★★。★根拠を次の2点に差し替えます（いずれも構造由来で、データに依存しません）★:
>
> 1. ★この画面の期間は**自由な日付範囲**（本決定 §4）であり、サマリは `year/month/week` の
>    粒度でしか存在しない。★範囲を合計する手段が構造的に無い★
> 2. ★既定が「全期間」なので必ず**当期**を含むが、★進行中の期間はサマリテーブルに存在しない★
>    （`CLAUDE.md` §4.7）
>
> ★**実装の変更は不要です**★。★第9回 Q2-1（集計バッチが合計を書く仕様か）は取り下げません★ —
> ★仕様が不明であることは変わっていないためです★。
> 詳細: `docs/handoff/テストDBのデータ出所_20260917.md`

7-2. ★D-141 §2（番人の段落。「実データ（テストDB・ローカルDBとも）では…該当0件」の直後）★

> ★★**2026-09-17 訂正**★★（D-XXX）: ★この「該当0件」は、★**当方のシードが
> 1タスク = 1履歴行で書いているから**★です（`scripts/seed-local-db.ts`）。
> ★★**1つの `clean_timetable` に履歴が何行できるかは、依然として分かっていません**★★
> （第9回 Q2-3 で照会中）。★番人はそのまま残します★ — ★分からないままなので、
> 静かに二重計上されるより警告が出るほうがよいという判断は変わりません★。

7-3. ★D-141 §7（「実測値（動作確認）」の節末尾）★

> ★★**2026-09-17 訂正 — この節の数字の出所**★★（D-XXX）: ★`clean_status_histories` 538行 /
> Σ`clean_area` = 341,635 / Σ`task_area` = 494,000 は、★**当方が投入したダミーデータの合計**★です
> （`task_area` の 1000 は `scripts/seed-local-db.ts:317` の `TASK_AREA_SQM`）。
> ★★**したがって本番のデータ量・面積の実勢を示すものではありません**★★。
>
> ★**ただし「自前SQLの合計とAPIの返り値が一致した」「粒度を変えても全体合計が変わらない」
> という確認は有効です**★ — ★これはデータの中身ではなく**実装の経路**を突き合わせたものだからです★。

7-4. ★D-144 §2（「外挿の前提を置き直した」の計算ブロックの直後）★

> ★★**2026-09-17 訂正 — 置き直しの根拠のうち「1.45回/日/台」は当方のダミー由来でした**★★（D-XXX）
>
>

538行 ÷ 31日 ÷ 12エリア = 1.45 回/日/台

★この 538 / 31 / 12 は、すべて★**当方の `scripts/seed-local-db.ts` が決めた値**★です
（31日は `EXTRA_VOLUME_DAYS`（`:441`）、538行は fixtures 259 + ボリューム 279）。
★★**本番の清掃回数を示すものではありません**★★。

★**変わらないこと**★:
- ★「ロボット30台未満」はユーザー申告であり、テストDBとは無関係★ — ★そのまま有効★
- ★`possible_keys = null` による全表走査は★**行数によらず構造的に起きる**★ — ★結論は不変★
- ★走査行数が台数×回数に対して二乗で効くこと★ — ★式の性質なので不変★

★**変わること**★: ★★1台1日あたりの回数（1.00 / 1.29 / 1.50 の3通り）は、
**いずれも根拠を失いました**★★。★本番の回数は**不明**です★。
★`MAX_CSV_ROWS = 20,000` を据え置く判断（§4）は変えませんが、
その根拠は「外挿が安全側」ではなく★★「本番の回数が分からないので、いま変える理由が無い」★★
に置き換わります。★実データが入ったら測り直すこと（D-136 §8）★。
詳細: `docs/handoff/テストDBのデータ出所_20260917.md`

7-5. ★D-144 §5 #4（CONSECUTIVE_LOOKBACK の行。表の直後）★

> ★★**2026-09-17 訂正**★★（D-XXX）: ★#4 の「**実データで初めて検証**」は誤りです★ —
> ★`weeks="1000001"`（週2回）は `lib/fixtures/schedules.ts` の★**当方のダミー**★でした。
> ★★**「7カレンダー日に1回は清掃予定がある」という `CONSECUTIVE_LOOKBACK` の前提は、
> 依然として未検証です**★★。★本番のスケジュールに週1回のものが1本でも入ると、
> 連続日数が黙って切れます（例外もテスト失敗も出ません）★。★実データが入ったら最初に確かめること★。
>
> ★#3（`control_reports` の台数前提）については訂正不要です★ —
> ★「制御盤11台はテストデータ由来で本番の根拠が無い」と**すでに正しく書かれている**ためです★。

7-6. ★D-137 §0（docs/decisions.md:10406-10413 の表の直後）★

> ★★**2026-09-17 訂正 — 上の表はダミーデータでの観測でした**★★（D-XXX）
>
> ★2026-09-13 / 09-12 の「7件」「消えていた4件」は、★**当方が投入したダミーデータ**★での観測です。
> ★**「ユーザーがわざわざ新設を指示した条件が、実データでほぼ機能していませんでした」は
> 言い過ぎでした**★ — ★実データではまだ何も確かめられていません★。
>
> ★★**ただし本決定の結論（APIで件数を切らない）は維持します**★★ —
> ★「連続日数の降順 + 上限5件」では急落（`consecutive_problem_days` が 1〜2）が
> 構造的に押し出される★というロジックは、★データに依存しないためです★。
> ★上の表は、そのロジックの**例示**として読んでください★。

7-7. ★docs/handoff.md 追記52 §3（「動作確認」の冒頭）★

> ★★**2026-09-17 訂正**★★（D-XXX）: ★この節の「テストDB（読み取りのみ）で実施」の数字
> （538行 / Σ`clean_area`=341,635 / Σ`task_area`=494,000 / 番人の該当0件）は、
> ★**当方が投入したダミーデータでの観測**★です。★**本番のデータ量を示すものではありません**★。
> ★経路の突き合わせ（自前SQLとAPIの一致・粒度を変えても合計が不変）としては有効です★。
> 詳細: `docs/handoff/テストDBのデータ出所_20260917.md`

7-8. ★docs/spec.md:45（F-02 のデータ量。★決定ではないが、すべての外挿の根っこ★）★

★★現状の記載★★:

- データ量: ★**約45行/日、年間約1.6万行**★、保持2年
  - ★2026-09-17 実測に基づく★ — ★ロボット30台未満（DFA把握）× 1.5回/日/台★。
    1台1日あたりの回数は、テストDB（…）の `clean_timetables WHERE precheck=0` が
    ★毎日ちょうど18件★・スケジュール保有12台、から算出。

★★差し替え案★★（★1.5回/日/台の出所を「実測」と書かない★）:

- データ量: ★**約30〜45行/日、年間約1.1〜1.6万行**★、保持2年（★**いずれも見積もりです**★）
  - ★根拠★: ★ロボット30台未満（DFA把握。2026-09-17 ユーザー申告）★ ×
    ★1台1日あたり1〜1.5回（★**仮置き**★）★
  - ★★**注意: 1台1日あたりの回数は実測値ではありません**★★ — ★2026-09-17 の旧記載は
    テストDBの `clean_timetables` を数えたものでしたが、★**その行は当方が投入した
    ダミーデータ**★でした（`docs/handoff/テストDBのデータ出所_20260917.md`）。
    ★本番の清掃回数は**不明**です★
  - ★**旧記載「約360行/日、年間約13万行」は施設200件を前提にした外挿**★。
    ★この数字を根拠にしたコメントが `lib/` と `app/` に14か所残っている★（★未修正★）

8. ★★今後どう扱うべきか★★

8-1. ★★テストDBのデータを根拠に先方へ問うこと — ★原則やめる★★★

★理由★: ★★テストDBの行は当方が入れたものなので、先方のバッチ・収集処理の挙動を一切示しません★★。 ★これを根拠に問うと、先方に「自社の不具合」と誤解させる指摘を送ることになります★ （★第9回の初版が実際にそうなっていました。送付前に気づけたのは幸いです★）。

★この区分は D-111 項7（docs/decisions.md:6683-6689。2026-09-11）で既に宣言されていました★ —

★★テストDBでは判定できない★★: ★本番のデータ量★ / ★サマリバッチの実挙動★ / ★本番の time_zone 設定★

★★D-141 §1（サマリの面積）も D-144 §2（データ量の外挿）も、この表の1行目と2行目に そのまま当たっていました★★。★表はあったのに、5日後に守られませんでした★。

8-2. ★★「実測」と書くときに必ず添えること（提案）★★

★★CLAUDE.md §9.3 か §6 に1行足すことを提案します（★決めるのはユーザーです★）★★:

- ★★「実測」と書くときは、**その行の出所を必ず併記する**★★
  （★「当方のシード由来」/「先方投入」/「構造（`information_schema`・`SHOW`・`EXPLAIN`）」★）。
  ★出所を書けない数字は「実測」と呼ばない★

★具体的な書き方の例★:

8-3. ★★テストDBへ何かを入れたときの申し送り（提案）★★

★★今回いちばん困ったのは「誰が・いつ・何を入れたか」がどこにも書かれていなかったこと★★です。

• ★テストDBに1行でも入れたら、docs/decisions.md に★投入日時・投入元（どのコミット・どのスクリプト）・ 対象テーブルと行数★を残す★
• ★scripts/seed-local-db.ts の冒頭に★「★このスクリプトの出力をテストDBへ持ち込む場合は decisions.md に記録すること★」★の注記を足すことを検討する（★本作業では触っていません★）

8-4. ★★実データが入るのはいつか — ★不明★★★

★docs/decisions.md / docs/handoff.md / docs/spec.md / 第9回の各章を検索しましたが、 ★時期を示す記載は1件もありませんでした★。

分かっているのは次だけです。

★★したがって「実データが入る時期」は不明です★★。 ★★第9回への回答が来るまで、テストDBで「本番がどうなっているか」を確かめることはできません★★。

9. ★★実装を直す必要があるもの — ★ありません★★★

★lib/ app/ components/ を読んで確認しました★。

★★判定ロジック（lib/judge/）には一切影響がありません★★ — ★閾値も丸めも、テストDBの行とは無関係だからです★。

10. ★★本書で触ったもの / 触っていないもの★★

★触った★: ★docs/handoff/テストDBのデータ出所_20260917.md（本書。新規1ファイルのみ）★

★★触っていない★★:

docs/decisions.md / docs/handoff.md / docs/spec.md / CLAUDE.md          … 読んだだけ
docs/handoff/TeamWorks確認事項_第9回_20260915.md                        … 読んだだけ（別作業中）
docs/handoff/規模前提の見直し_20260917.md / その他 docs/handoff/*.md     … 読んだだけ
docs/handoff/pdf/**                                                      … 開いていない
lib/ / app/ / components/ / prisma/ / scripts/ / d-watch-api.yaml        … 読んだだけ
git                                                                       … log / show のみ。add・commit・push なし
テストDB                                                                  … SELECT / SHOW / information_schema のみ