# テスト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行）★★

| # | 結論 |
|---|---|
| ★1★ | ★★テストDB（`clean_watch`）に入っている **行は、1行残らず当方（DFA）の `scripts/seed-local-db.ts` 由来** です★★。★先方由来の行は **0行**★ |
| ★2★ | ★★ただし **器（スキーマ・索引・型・照合順序・サーバー設定・権限）は先方由来** です★★。★39テーブルすべての `CREATE_TIME` が `2026-09-11 19:28:12`（JST換算）で揃っており、当方は1テーブルも作っていません★ |
| ★3★ | ★★したがって「構造を見た実測」は有効、「行の中身を数えた実測」は無効★★ です。★9件中 **2件が有効（構造由来）・7件が無効（データ由来）**★。★追加で3件の無効を発見しました（合計10件が無効）★ |
| ★4★ | ★★**D-141 の結論（面積はサマリを読まず `clean_status_histories` から集計する）は維持できます**★★。★根拠が崩れても、**別の構造的な理由が独立に成立している**ためです（6-1節）。★**実装の変更は不要です**★ |

---

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

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

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

```sql
-- ① 全テーブルの行数
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行★）

| テーブル | 行数 | ★当方由来と断定できる根拠（実測値 → 出所の `file:line`）★ |
|---|---|---|
| `clean_timetables` | ★1,044★ | id が `1001〜1279` / `3001〜3279` / `101001〜` / `201001〜`。★`3001` は `scripts/seed-local-db.ts:443` の `EXTRA_VOLUME_ROW_ID_BASE`★ |
| `clean_status_histories` | ★538★ | 全行 `task_area = 1000` = ★`scripts/seed-local-db.ts:317` の `TASK_AREA_SQM`★ |
| `robot_error_reports` | ★49★ | id が `RER-1001-main` / `RER-1011-30` 形式。`comment` が★「seed-local-db が生成したダミーの備考。実在の対応内容ではない。」= `scripts/seed-local-db.ts:560`★ |
| `facility_summaries` | ★24★ | 全24行 `task_count=100` / `task_area=1000` = ★`scripts/seed-local-db.ts:1669-1670`★。`clean_ratio` の12値は★`lib/fixtures/reports.ts:204-329` の `completion_rate` と完全一致★ |
| `clean_schedules` | ★21★ | id `21〜32` が fixtures、`9001〜9009` が★`scripts/seed-local-db.ts:445` の `EXTRA_VOLUME_SCHEDULE_ID_BASE`★ |
| `clean_statuses` | ★18★ | id 1001 の `clean_ratio = 90.1` = ★`lib/fixtures/clean-logs.ts:95` の境界値ケース★ |
| `facility_error_summaries` | ★18★ | `error_level = "seed-dummy"` = ★`scripts/seed-local-db.ts:525`★ / `error_detail` = ★同 `:527`★ |
| `robots` | ★14★ | シリアル14件すべて `8111R5628060011` 等 = ★`lib/fixtures/facilities.ts` の `serial_number`★ |
| `sections` | ★14★ | `section_name` が `清掃エリア（ロボット101）` 形式 = ★`scripts/seed-local-db.ts:886` のテンプレート文字列★ |
| `control_reports` | ★14★ | `serial_number` が `DS-001`〜 = ★`lib/fixtures/ds-devices.ts`★ |
| `facilities` | ★12★ | 施設名・住所・電話・担当者・`contract` の全列が★`lib/fixtures/facilities.ts` と一致★ |
| `controls` | ★11★ | `password` が全行 `"seed-local-placeholder-password"` = ★`scripts/seed-local-db.ts:198`★ |
| `control_error_histories` | ★5★ | `comment` が「回線業者に確認中」= ★`lib/fixtures/ds-alerts.ts:57`★ / 「現地ネットワークを確認中」= ★同 `:125`★ |
| `customer_summaries` | ★2★ | `task_count=100` / `task_area=1000`（同上） |
| `customers` | ★1★ | `customer_name = "テスト顧客001"`。★これは**旧版の当方シード**の値★（5章） |
| `groups` | ★1★ | `group_name = "テストグループ001"`（同上） |
| `devices` | ★1★ | `maker_id=1` / `model_name="CC1"` = ★`lib/config` の `MAKER_NAMES` / `ROBOT_MODELS`★ |

★★先方由来の行は **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. ★★先方由来のもの（＝そのまま根拠にしてよいもの）★★

| 対象 | 実測値 |
|---|---|
| ★スキーマ★ | ★39テーブル。全テーブルの `CREATE_TIME` が `2026-09-11 10:28:12`（UTC）= ★**2026-09-11 19:28:12 JST**★ で完全に揃う★ |
| ★索引★ | 各テーブル 1〜7本。★すべて Laravel が自動生成する名前（`*_foreign` / `*_unique` / `PRIMARY`）★で、★複合索引は1本も無い★ |
| ★型・照合順序★ | 全テーブル `InnoDB` / `utf8mb4_unicode_ci` |
| ★サーバー★ | ★`10.11.19-MariaDB-ubu2204`★ / `character_set_server=utf8mb4` / `collation_server=utf8mb4_general_ci` |
| ★サーバー変数★ | ★`eq_range_index_dive_limit = 200`★ / `time_zone=SYSTEM` / ★`system_time_zone=UTC`★ |
| ★権限★ | 参照用アカウントの `SHOW GRANTS`（D-143 / 監督が実測済み） |
| ★構築主体★ | ★テスト環境は **DFA が契約し、TeamWorks が構築・保守**★（D-143 §1。`docs/decisions.md:11280`） |

---

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

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

| # | 決め手 | 実測 |
|---|---|---|
| ★1★ | ★リポジトリにしか存在しない文字列が入っている★ | `"seed-local-placeholder-password"` / `"seed-dummy"` / 「seed-local-db が生成したダミーの備考。実在の対応内容ではない。」— ★いずれも `scripts/seed-local-db.ts` にしか無い★ |
| ★2★ | ★id の採番規則が当方の定数と一致★ | `clean_timetables` の `3001〜3279` = `EXTRA_VOLUME_ROW_ID_BASE`(`:443`) + `EXTRA_VOLUME_DAYS=31`(`:441`) × 9台 = 279件。★1行もずれない★ |
| ★3★ | ★★「当方の**旧版**シードの値」が入っている★★ | `customers` = `テスト顧客001` / `groups` = `テストグループ001`。★この2つは `a5502ac`（2026-09-09）で入り、`a66ad67`（2026-09-16「マスタを fixtures 由来の2グループ4顧客に広げる」）で**消えた**★。★現行の `scripts/seed-local-db.ts:753` には「以前はここで作っていた」という記述だけが残っている★。★**先方が当方の旧版シードの文字列を偶然使うことはあり得ない**★ |
| ★4★ | ★投入が22秒の一括★ | `created_at` が全テーブルで `2026-09-12 17:27:57`〜`17:28:19`（UTC）= ★**2026-09-13 02:27:57〜02:28:19 JST**★。★1回のスクリプト実行★ |
| ★5★ | ★器と中身の時差★ | 器（`CREATE_TIME`）は ★2026-09-11 19:28 JST★、中身（`created_at`）は ★2026-09-13 02:28 JST★。★**約31時間空いている＝別の主体・別の操作**★ |

---

## 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時間前**★です。★つまり流したのは「未コミットの作業ツリーの版」★

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

| # | 経路 | 補足 |
|---|---|---|
| ★A★ | ★`dwatch_local` を `mysqldump` し、その SQL をテストDBへ流した★ | ★ガードを通らずに同じ中身が入る。最も自然★ |
| B | ガードを外した／別のコピーを作って直接流した | ★ガードは「うっかり」を止めるためのもので、外そうと思えば外せる★ |
| C | 別の一時スクリプトで `INSERT` した | ★`created_at` が22秒で揃う点はどの経路でも説明できる★ |

★★いずれにせよ「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行である」 —
  ★**当方が入れた行を数えているだけのもの**★

| # | 記録 | 場所 | ★仕分け★ | 理由（実測 → 出所） |
|---|---|---|---|---|
| ★1★ | サマリの `task_area` が全24行 `1000` ちょうど | ★D-141 §1（`docs/decisions.md:10995`）★ | ★★データ由来（無効）★★ | ★`1000` は `scripts/seed-local-db.ts:1670` の `SUMMARY_TASK_AREA_SQM`★。★「8月月次と9月第2週で同じ値」なのも、当方が同じ `facilityPerformance` を両期間に複製しているから★ |
| ★2★ | `clean_status_histories` 538行 / Σ`clean_area`=341,635 / Σ`task_area`=494,000 | D-141 §7 / `docs/handoff.md` 追記52 §3 | ★★データ由来（無効）★★ | ★538 = fixtures 259 + ボリューム 279★。★494,000 = 494行 × `TASK_AREA_SQM`(1000)★（未実施44行は `task_area=0`）。★**ただし「自前SQLの合計とAPIの返り値が一致した」という検算そのものは、データが何であれ成立する実装の突き合わせなので有効**★（6-1節） |
| ★3★ | 1.45回/日/台 → 2年で約193万行 | ★D-144 §2（`docs/decisions.md:11406`）★ / `docs/handoff/規模前提の見直し_20260917.md` §2-3 | ★★データ由来（無効）★★ | ★1.45 = 538 ÷ 31日 ÷ 12エリア。538 も 31 も 12 も当方の投入値★（`EXTRA_VOLUME_DAYS=31` は `:441`） |
| ★4★ | `clean_timetables WHERE precheck=0` が毎日ちょうど18件 | `docs/handoff/規模前提の見直し_20260917.md` §2-2 | ★★データ由来（無効）★★ | ★18件/日は当方の `clean_schedules`（fixtures 12本 + シード9本）から当方のシードが生成したもの★。★「`clean_schedules` から再現できる」のは、当方の入力と当方の出力が整合しているというだけ★ |
| ★5★ | 予定時刻と `started_at` の差が全538行で0分 | 第9回11章 | ★★データ由来（無効）★★ | ★シードが `started_at: startAt`（＝予定時刻そのもの）を書いている★（`scripts/seed-local-db.ts:1220` / `:1287` / `:1340` / `:1587` / `:1606`）。★**再実測しても 0分 × 538件。当然です**★。★ただし結論は維持できる（6-2節）★ |
| ★6★ | `clean_task_reports` は0行 / `link_schedules` は0行 | 第9回11章 / 規模前提の見直し §2-1 | ★★データ由来（無効）★★ | ★当方のシードが書かないテーブルだから0行なだけ★。★**テーブルが存在すること（`CREATE_TIME` 2026-09-11）は構造由来で有効**★ |
| ★7★ | 判定フィルタ「problem」が実測37.0% | `docs/handoff/規模前提の見直し_20260917.md` §2-4 | ★★データ由来（無効）★★ | ★再実測: ◎232 / ○107 / △79 / ×120（△×=199 = 37.0%）★。★この分布は `scripts/seed-local-db.ts:459` の `EXTRA_VOLUME_GRADE_CYCLE`（当方が決めた巡回表）が決めている★ |
| ★8★ | `eq_range_index_dive_limit = 200` の MariaDB 実測 | `docs/handoff/規模前提の見直し_20260917.md` §5 | ★★構造由来（有効）★★ | ★再実測で `200` を確認★。★サーバー変数なので行の中身に依存しない★。★ただし「このサーバーの値」であり、本番サーバーは未確認（元の記録にもその旨あり）★ |
| ★9★ | 索引が1本も入っていない（`information_schema.STATISTICS`） | ★D-144 §1（`docs/decisions.md:11398`）★ | ★★構造由来（有効）★★ | ★再実測で確認★。★`clean_status_histories` は `PRIMARY` / `id_unique` / `facility_id_foreign` / `section_id_foreign` の4本のみ。依頼した7件の複合索引は0本★ |

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

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

| # | 記録 | 場所 | 仕分け |
|---|---|---|---|
| ★10★ | ★「実データ（テストDB）で急落が一覧から消えていた（2026-09-13: 7件中5件 / 2026-09-12: 7件中5件）」★ | ★D-137 §0（`docs/decisions.md:10406`）★ | ★★データ由来（無効）★★。★ただし結論（APIで件数を切らない）は構造由来のロジックで維持できる★（6-3節） |
| ★11★ | ★「`CONSECUTIVE_LOOKBACK` の『7カレンダー日に1回は清掃予定がある』前提を**実データで初めて検証**した。最も疎い `weeks="1000001"` で最大間隔6日」★ | ★D-144 §5 #4（`docs/decisions.md:11458`）★ | ★★データ由来（無効）★★。★`weeks="1000001"` は `lib/fixtures/schedules.ts` の当方のダミー★。★「検証した」ではなく「未検証のまま」★ |
| ★12★ | ★「番人（多重計上の検知クエリ）が該当0件だった＝1タスクに履歴は1行」★ | ★D-141 §2 / `docs/handoff.md` 追記52 §2-3★ | ★★データ由来（無効）★★。★当方のシードが1:1で書いているので0件になるのは当然★。★第9回 Q2-3 は未解決のまま★ |

### ★★仕分けの集計★★

| 区分 | 件数 | 内訳 |
|---|---|---|
| ★構造由来（有効。そのまま残す）★ | ★2★ | #8 / #9 |
| ★★データ由来（無効。訂正注記が要る）★★ | ★★10★★ | #1〜#7 / #10〜#12 |

---

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

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

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

| # | 理由 | 種別 |
|---|---|---|
| ★1★ | ★★この画面の期間は**自由な日付範囲**（D-141 §4）★★。★サマリは `year/month/week` の粒度でしか存在せず、「8月10日〜9月5日」のような範囲を合計する手段が構造的に無い★ | ★★構造由来。データとは無関係に成立★★ |
| ★2★ | ★★進行中の期間（当週・当月・当年）はサマリテーブルに存在しない★★（`CLAUDE.md` §4.7）。★既定が「全期間」なので、必ず当期を含む★ | ★★構造由来★★ |
| ★3★ | ★`task_area` / `clean_area` が期間内の合計かどうかは、★**いまも分かっていない**★（第9回 Q2-1 で照会中）。★`CLAUDE.md` §7「仕様が不明な箇所を推測で実装しない」に従えば、**合計だと仮定してサマリを読むほうが禁止事項に触れます**★ | ★方針由来★ |

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

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

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

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

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

| 根拠 | 出所 | 仕分け |
|---|---|---|
| ★①テーブル定義書の備考「**清掃スケジュールの清掃開始日時を格納する**」★ | ★先方資料★ | ★★有効★★ |
| ②実データで予定時刻との差が全538行0分 | ★当方のダミー★ | ★★無効★★ |

★★①だけで「`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` の段落の直後）★

```markdown
> ★★**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件」の直後）★

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

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

```markdown
> ★★**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（「外挿の前提を置き直した」の計算ブロックの直後）★

```markdown
> ★★**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` の行。表の直後）★

```markdown
> ★★**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` の表の直後）★

```markdown
> ★★**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（「動作確認」の冒頭）★

```markdown
> ★★**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回/日/台の出所を「実測」と書かない★）:

```markdown
- データ量: ★**約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のデータを根拠に先方へ問うこと — ★**原則やめる**★★★

| 種別 | 先方へ出してよいか |
|---|---|
| ★構造（DDL / 索引 / 型 / カラムの有無 / `EXPLAIN` の `possible_keys` / サーバー変数 / 権限）★ | ★★出してよい★★ |
| ★★行の中身（行数 / 分布 / 合計 / 「全件が同じ値」 / 「0行である」）★★ | ★★出さない★★。★どうしても必要なら「★当方の検証用データでの観測です★」と本文に明記する★ |

★理由★: ★★テスト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行足すことを提案します（★決めるのはユーザーです★）★★:

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

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

| ❌ 悪い | ✅ よい |
|---|---|
| ★「実データで538行を確認」★ | ★「テストDBで538行（★**出所: 当方の `scripts/seed-local-db.ts`**★）」★ |
| ★「実測で全24行が1000だった」★ | ★「当方のシードが `SUMMARY_TASK_AREA_SQM=1000` を入れているため、全24行が1000（★構造の確認にはならない★）」★ |
| ★「索引が1本も無い（実測）」★ | ★そのままでよい（★`information_schema.STATISTICS` は構造由来★）★ |

### 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回12-1「★いま（検証用データのみ）★ … ★実データは入っておりません★」 |
| ★第9回12章の期限が「★ステージングに実データが入る前★」という**相対的な**書き方になっている★ | `docs/handoff/TeamWorks確認事項_第9回_20260915.md` 12-1 |
| ★第9回7章で `groups` / `customers` の本番マスタ投入を**お願い中**（未回答）★ | 同7章 |
| ★更新用アカウントの付与も「後日」のまま（時期未定）★ | D-078 |

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

---

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

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

| 対象 | 判断 |
|---|---|
| ★`lib/clean-area/`（面積の集計。D-141）★ | ★★変更不要★★。★6-1節のとおり、結論は構造由来の理由で独立に成立する★ |
| ★`lib/clean-area/anomaly.ts` の番人★ | ★★残す★★。★Q2-3 が未解決である以上、番人を外す理由が無い★ |
| ★`MAX_CSV_ROWS = 20,000`（`lib/config/index.ts:384`）★ | ★★据え置き（D-144 §4 のまま）★★。★ただし根拠が「外挿が安全側」から「本番が不明なので変える理由が無い」に変わる★ |
| ★`CONSECUTIVE_LOOKBACK.calendarDaysPerScheduleDay`（`lib/config/index.ts:169`）★ | ★★値は据え置き★★。★ただし「検証済み」ではなく「未検証」に戻る★（7-5節）。★実データが入ったら最初に確かめる項目★ |
| ★`AREA_UNIT`（㎡）★ | ★変更不要★。★元から「DFAの判断であり先方未確認」と記録されている（D-141 §3）★ |
| ★`lib/` / `app/` に14か所残る「約360行/日・年間約13万行」系のコメント★ | ★★本作業の対象外（D-144 §2 で未修正と記録済み）★★。★書き換えるときは、新しい数字も「見積もり」であることを明記すること★ |

★★**判定ロジック（`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 のみ
```