# TeamWorks の回答待ちで止まっていること（2026-09-30 時点） **作成: 2026-09-30 / ブランチ: `develop` / HEAD: `7fdd822` / 読み手: daichi（DFA）** > ★**本書は調査と文書化だけです。コードは1行も変更していません。**★ > ★`lib/` `app/` `components/` `prisma/` `d-watch-api.yaml` `d-watch-mock.jsx` は読んだだけ★。 > ★`docs/decisions.md` `docs/handoff.md` `CLAUDE.md` も読んだだけ★。★本番DBには接続していません★（D-148）。 ## 0. 本書の目的と読み方 ★**「回答が来ないと何が作れず、何が困るのか」を、画面の見え方で書いたもの**★です。 抽象的な「〜が確認できません」では催促の主語が決まらないため、★**1件ごとに 「いま画面がどう見えているか」「回答が来たら画面がどう変わるか」まで書いています**★。 元になっているのは次の3つです。 | 材料 | 何が書いてある | |---|---| | `docs/handoff/TeamWorks確認事項_第9回_20260915.md`（1,197行） | ★2026-09-17 に送付した本文★。★質問25問 / お願い5件 / 参考情報1章★ | | `docs/decisions.md` D-147（`:11950-12000`） | ★回答待ちの一覧と、それが何をブロックしているかの表★ | | `docs/データの流れ_画面1-5_20260917.md` / `docs/データの流れ_画面6-10_20260917.md`（計3,065行） | ★DBの列 → 関数 → 画面の縦線★ | ### 0-1. ★★本書に出てくる数字の出所★★（`CLAUDE.md` §6-6） | 表記 | 意味 | |---|---| | ★**シード由来**★ | ★本番DB（`133.125.238.144` / `clean_watch`）に入っている★が、★**中身は当方が投入した ダミー**★（`scripts/seed-local-db.ts` 由来・17テーブル 1,787行。D-145 / D-148）。 ★**TeamWorks のバッチや収集処理の挙動を示すものではない**★ | | ★**構造由来**★ | `SHOW CREATE TABLE` / `information_schema` / `EXPLAIN` の `type`・`possible_keys` / サーバー変数 / 権限。★行数に左右されない★ | | ★**画面実測**★ | ★2026-09-17 に監督がブラウザで確認した表示★。★**表示されている値の出所はシード由来**★ | ★**「本番の実データで測った数字は、本書に1つもありません」**★ — ★本番DBにはまだ実データが 入っていないためです★（D-148 項1）。 --- ## 1. ★★1枚で分かる要約表★★ ★困り方は4分類★: ★**機能が作れない**★（実装に着手できない）/ ★**数字が出ない**★（画面に出るが 値が欠ける・段差になる）/ ★**検証できない**★（作れてはいるが正しさを確かめる材料が無い）/ ★**期限がある**★（過ぎると作り直しになる）。 | # | 待っている番号 | 何が止まっているか（★画面で言うと★） | 困り方 | 重さ | |---|---|---|---|---| | ★1★ | ★**Q11-1**★（`started_at`） | ★★要レスキュー店舗の4条件目「出発失敗」が**存在しない**★★。★遅延出発が画面のどこにも出ない★ | ★機能が作れない★ | ★★大★★ | | 2 | Q11-2 / Q11-3 / Q11-4 | 「指示すら出ていない」と「指示は出たが動かなかった」を区別できない。出発成功率の式が不明。リアルタイム表示の余地が分からない | 機能が作れない | 中 | | ★3★ | ★**Q6-1 / Q6-2**★（実施回数の列） | ★★レポート画面の確定期間KPIは「顧客が1社に定まるとき」しか出ない★★。★2社目が入った瞬間に **422 エラー画面**★ | ★数字が出ない★ | ★★大★★ | | 4 | Q2-1 / Q2-3 | 清掃総面積をサマリから取れない。★1清掃に履歴が2行あると面積が黙って倍になる★ | 数字が出ない / 検証できない | 中 | | 5 | 3章（第8回Q4の再掲）/ Q4-1〜Q4-3 | ★確定期間と当期でエラー発生率の定義が食い違い、**グラフが段差になる**恐れ★。検算できない | 数字が出ない / 検証できない | 中 | | ★6★ | ★**7章マスタ投入 + Q7-1〜Q7-5**★ | ★★分類セレクトが5画面すべてで実質「2択」★★（「全ホールディングス / テストグループ001」）。★絞り込みが機能として確かめられていない★ | 機能が作れない / 検証できない | ★大★ | | 7 | Q8-3（報告間隔） | `control_reports` の行数見積もりが ★1,100万行〜7,000万行★ で6倍ぶれる。D-Sログ画面の設計を決められない | 検証できない | 中 | | 8 | Q9-1 / Q9-2 + DDL未反映2件 | 区域別（売り場・通路・レジ前）の内訳が作れない。★**「できない」の一言でも前に進む**★ | 機能が作れない（小） | 小 | | ★9★ | ★**12章 お願い3件 + Q12-1〜Q12-6**★ | ★★本番DBが平文・どこからでも接続可のまま★★。★**実データが入った後は「止める調整」なしに直せない**★ | ★★期限がある★★ | ★★大★★ | | ★10★ | 索引（★依頼は取り下げ済み★） | ★★依頼7本のうち本番DBに入っているのは **0本**★★（2026-09-17 構造由来）。★清掃詳細ログの2年表示が構造的に全表走査★ | 検証できない / 期限がある | 中 | ★**内訳**★: ★機能が作れない 4件★ / ★数字が出ない 3件★ / ★検証できない 5件★ / ★期限がある 2件★ （★重複あり。項目総数は10件★）。 --- ## 2. 1件ずつの詳細 ### ★★2-1. Q11-1 — `started_at` を実際の清掃開始時刻として使ってよいか★★ #### 【いま何が起きているか】 ★**要レスキュー店舗は3条件でしか判定していません**★（`lib/judge/rescue.ts:12-21`）。 | # | 条件 | 実装 | |---|---|---| | R-1 | 未実施が3日以上連続 | ★あり★ | | R-2 | 連続問題レベル3（L3） | ★あり★ | | R-3 | 完了率が前回比20%以上の急落 | ★あり★ | | ★R-4★ | ★**出発失敗（予定時刻＋猶予30分を過ぎても出発しない）**★ | ★★**無い**★★（`lib/judge/rescue.ts:20-22`） | コードのコメントがそのまま状況を説明しています（`lib/judge/rescue.ts:20-22`）: > ★★4つ目の条件（出発失敗を未実施と別に数える）は落としてある★★ — > 実開始時刻がDBに無く、猶予30分の計算をする材料が無いため。 ★**いま「出発失敗」と呼んでいるものは、実際には「未実施」です**★ — 判定は `clean_status_histories.clean_error === 1` の1点だけで、時刻を1秒も見ていません （`lib/db/clean-log-mapping.ts:105-156`）。 ★**ダッシュボードの要レスキュー店舗は 6件表示**★（★画面実測 2026-09-17★。「もっと表示」で 5→6。初期表示5件は `lib/config/index.ts:102` の `RESCUE_INITIAL_VISIBLE = 5`）。 ★この6件は、いずれも「未実施」「L3」「急落」のどれかで拾われたものです★。 ★★**「時間どおりに出発しなかった店舗」は、この6件の選出根拠に1件も入っていません**★★。 ★`clean_error` の分布（★シード由来。100件の画面実測 2026-09-17★）★: ★0（正常）= 83 / 1（未実施）= 12 / 2（セキュリティ有効）= 1 / 3（D-S制御盤異常）= 2 / 4 = 2★。★**`null` は0件**★。 ★つまり「未実施」として拾えているのは12%ぶんだけで、**残る83%の中に遅延出発が混ざっていても 見えません**★。 #### 【なぜ止まっているか】 ★テーブル定義書の `clean_status_histories.started_at` の備考が **「清掃スケジュールの清掃開始日時を格納する」**と書かれており、★**予定時刻の写しとも読める**★★ （第9回 11-1）。 - ★`prisma/schema.prisma:498` の `started_at DateTime @db.DateTime(0)` には、それが実時刻か 予定時刻かを示すものが何もありません★ - ★シードは `started_at` に予定時刻をそのまま入れていた★ため、★当方のデータで差を取っても 必ず0分になります★（`lib/db/report-mapping.ts:213-215`）。★**シードで検証できない種類の問い**★です ★**推測で実装すると、失敗が「例外もテスト失敗も出さずに」消えます**★ — ★仮に `started_at` が予定時刻の写しだった場合、「予定＋30分を過ぎても `started_at` が入らない」は **永久に0件**になり、画面は「全件が時間どおりに出発した」と表示し続けます★（第9回 11-1）。 ★`CLAUDE.md` §7「仕様が不明な箇所を推測で実装すること」の禁止に真正面から当たるため、着手していません★。 #### 【回答が来たら何ができるか】 ★**A（その理解でよい）の一言で足ります**★。手順は既に書いてあります（`docs/handoff.md:4426-4440`）。 - ★要レスキュー店舗に4条件目が足され、★**「予定22:00 / 実際22:47 出発」のように遅れた店舗が リストに乗る**★★ - ★清掃詳細ログの「清掃結果」列で、いまは「正常」に混じっている遅延出発を別扱いにできる★ （`lib/clean-logs/csv.ts:103` / `lib/config/index.ts:302` の `cleanErrorLabel()`） - ★対応アドバイス R1「出発失敗（初回）」（`lib/judge/advice.ts:60-63`）が、★**本来の意味で発火する**★★ — 現状の `departed` は「未実施でない」の意味でしか動いていません #### 【来ないと何が困るか】 ★D-Watch は「夜間に自動実行された清掃を、翌朝DFA運用担当が確認する」運用★です（`CLAUDE.md` §1）。 ★**翌朝の担当者が見落とすのは「動いたけれど遅れた店舗」**★です。 - ★30分遅れて出発した店舗は、完了率が90%以上なら ◎ が付いて**正常な店舗と同じ見た目**になります★ - ★遅れの原因（充電が戻っていない / 障害物 / セキュリティ解除の遅れ）は、翌日以降に 「未実施」へ悪化してから初めて画面に出ます★。★★**1日遅れて気づく運用になります**★★ - ★R1 は「初回の出発失敗」を捕まえて現場へ連絡するためのルール★（`CLAUDE.md` §4.5）ですが、 ★**初回が見えないので、L2（2日連続）になって初めて気づく**★という、エスカレーション設計の 意図と逆の動きになります --- ### 2-2. Q11-2 / Q11-3 / Q11-4 — 出発判定の精度とリアルタイム性 #### 【いま何が起きているか】 ★**「出発失敗」と「未実施」を同じものとして扱っています**★（第9回 11-3 に明記して送付済み）。 - ★Q11-2★: `clean_statuses.clean_status_trans` が 1（清掃指示）で止まったケース＝ ★「指示は出したが動き出さなかった」★は、★**過去に遡れません**★。 `clean_statuses` は清掃ごとに上書きされ、`clean_status_histories` にこの列がありません （`prisma/schema.prisma:470-506` に `clean_status_trans` 相当の列が無い） - ★Q11-3★: サマリには `launch_count` / `launch_ratio` が★実在します★ （`prisma/schema.prisma:721` / `:734`）が、★**計算式を受領していません**★ （定義書の備考は「補足を参照.」のみで、補足の本文が未受領） - ★Q11-4★: 当方は `clean_status_histories` だけを読んでいます。★より短い間隔で更新される テーブルがあるかを知りません★ #### 【なぜ止まっているか】 ★当期（進行中の週・月）のKPIで、★**稼働率と出発成功率が同じ分子を使う近似**★になっています★ （`lib/db/report-mapping.ts:213-225`）: > ★このプロジェクトの清掃詳細データは「出発したか(executed)」の1ビットしか持たない★ > （…）そのため 稼働率（実施回数/予定回数）と出発成功率（定刻出発回数/予定回数）は > ★同じ `executed` を分子に使う★。 実装は `lib/db/report-mapping.ts:396-405`（`operationRate(executed, planned)` と `launchRate(executed, planned)` に★同じ2値★を渡している）。 ★**画面実測（2026-09-17）: レポート画面の当期KPIは 稼働率94% / 出発成功率94%**★ （★シード由来★）。★**この2枚のカードは、当期では構造上必ず同じ値になります**★。 #### 【回答が来たら何ができるか】 - ★Q11-3（式）が来れば★ — ★★確定期間と当期で「出発成功」の定義を揃えられます★★。 ★いまは確定期間が TeamWorks の `launch_ratio`、当期が当方の近似なので、 **週が変わった瞬間にグラフが段差になる可能性があります**★ - ★Q11-2 が「残る」なら★ — 要レスキューの理由を ★「指示が出ていない（制御側の問題）」と「指示は出たが動かない（機体側の問題）」に 割れます★。★翌朝の担当者が、現場に電話するか制御盤を見るかを画面だけで判断できる★ - ★Q11-4 に候補があれば★ — ★清掃の進捗を「終わってから」ではなく途中で出せます★。 ★無いなら「無い」で確定し、現在の形のまま進めます★ #### 【来ないと何が困るか】 - ★**レポート画面のKPIカード2枚が、当期では必ず同じ数字になる**★のに、★画面に説明がありません★ （追記59 §4 #4 でも危険箇所として挙げています）。★見た人は「なぜ同じ？」と思うか、 気づかずに2つの別の指標として読みます★ - ★確定期間（TeamWorks のサマリ）と当期（当方の近似）の段差は、★**バッチが走った翌週の月曜に 初めて現れます**★★。★数字が動いた理由が「実態」なのか「定義の違い」なのか、 その場では判別できません★ --- ### ★★2-3. Q6-1 / Q6-2 — サマリに「清掃実施回数」の列が無い★★ #### 【いま何が起きているか】 ★**レポート画面の確定期間KPIは、「顧客が1社に定まるとき」しか出ません**★。 定まらないときは ★★422 を返して画面にエラーが出ます★★。 決定表は `lib/reports/target-customer.ts:20-30` にあります。 | 入力 | 結果 | |---|---| | `customer_id` が指定されている | その顧客 | | `group_id` 指定・傘下1社 | その顧客 | | ★`group_id` 指定・傘下2社以上★ | ★★422★★ | | どちらも未指定・顧客が1社だけ | その顧客（★**P1 はいまここ**★） | | ★どちらも未指定・顧客が2社以上★ | ★★422★★ | 422 の文言は `lib/reports/target-customer.ts:65-66`: ★「顧客またはグループを指定してください。複数の顧客のデータを合算した数値は出せません。」★ ★**いまこれが表に出ていないのは、本番DBに顧客が1行しか無いから**★です （★シード由来。`customers` 1行 / `groups` 1行★。`docs/handoff/規模前提の見直し_20260917.md:57`）。 ★★**2社目が入った瞬間に、絞り込まずにレポートを開いた全員がこのエラーを見ます**★★。 #### 【なぜ止まっているか】 ★サマリの列と、当方の4つの計算式（`CLAUDE.md` §4.2）を突き合わせると2つ足りません★ （`prisma/schema.prisma:686-702` / `:720-736`。★構造由来★）。 | 率 | 分子 | 分母 | 合算 | |---|---|---|---| | 清掃完了率 | `clean_area` | `task_area` | ★できる★ | | 出発成功率 | `launch_count` | `task_count`? | ★式が未確認（Q11-3）★ | | ★稼働率★ | ★**清掃実施回数の列が無い**★ | `task_count`? | ★★できない★★ | | ★エラー発生率★ | `error_count` | ★**清掃実施回数の列が無い**★ | ★★できない★★ | ★率の平均を取るのは誤り（施設数の違いが消える）★ので、★**合算せず 422 で止める**★という 設計にしてあります（`lib/reports/target-customer.ts:31-33`。 ★D-133「静かに1社を選ぶことは絶対にしない」★）。 #### 【回答が来たら何ができるか】 - ★**Q6-2 が A（列を追加できる）なら**★ — ★★ホールディングス単位・全社単位のKPIが出せます★★。 ★422 が消え、「全ホールディングス / 全屋号」のままレポートを開いて数字が出ます★ - ★Q6-1 が A（当方が `customer_summaries` を合算する）★なら、合算は ★「率の平均」ではなく「Σ分子 ÷ Σ分母」★で実装します（材料が揃えば、という前提） - ★C（追加は難しい）なら★ — ★確定期間は清掃完了率と総清掃面積だけを出し、 稼働率とエラー発生率は**当期のときだけ表示**する形に切り替えます★。 ★決まれば「出ない」ことを画面で説明できます★ #### 【来ないと何が困るか】 - ★★屋号が増えた日に、レポート画面が突然エラーになります★★。 ★機能追加ではなくマスタ投入が引き金なので、DFA の誰も「変更した」認識がありません★ - ★ドン・キホーテ1社の中で屋号を分ける（Q7-1 の A）だけでも2社以上になりえます★ — ★**7章の回答が先に来ると、こちらが即座に問題になる**★という順番の危うさがあります - ★★確定期間の数字を検算できません★★ — 率だけがあって分子・分母が無いため、 ★TeamWorks のバッチと当方の当期集計がズレていても、どちらが正しいか言えません★ --- ### 2-4. Q2-1 / Q2-3 — サマリの面積と、1清掃あたりの履歴行数 #### 【いま何が起きているか】 ★**清掃総面積の画面は、サマリを使わず `clean_status_histories` を毎回その場集計しています**★ （`lib/db/index.ts:1761-1843` の `cleanArea()`）。 ★**画面実測（2026-09-17）: 清掃面積 341,635㎡ / 対象面積 494,000㎡ / 完了率69% / 実施回数538**★ （★いずれもシード由来★）。 ★同じファイルに「番人」が置いてあります★（`lib/db/index.ts:1779-1787`）: > ★1つの `clean_timetable_id` に履歴が2行以上あると `SUM()` が同じ清掃を2回数える★。 > ★例外もテスト失敗も出ず、数字が大きくなるだけ★なので、件数だけ数えて返します。 ★**つまり「面積が倍になっても画面は何も言わない」ことが分かっていて、監視だけ置いてある状態**★です。 #### 【なぜ止まっているか】 - ★**Q2-1**★: サマリの `task_area` / `clean_area` が★期間内の合計なのか、1回ぶんの代表値なのか★が 未確認。★合計でなければ、サマリから総面積を作ると黙って間違った数字が出ます★ - ★**Q2-3**★: ★1つの `clean_timetable_id` に `clean_status_histories` が何行できるか★が未確認。 ★テーブル名（「清掃状態履歴」）は複数行を示唆しますが、状態を表す列が無く1行にも読めます★ （`prisma/schema.prisma:470-506`） - ★シードでは 本清掃538行 : 履歴538行 で **1:1** でした★が、★**これは当方が1:1で入れたから**★です （`docs/handoff/規模前提の見直し_20260917.md:56-57`。★シード由来★）。★仕様の証拠になりません★ #### 【回答が来たら何ができるか】 - ★Q2-3 が A（必ず1行）なら★ — ★`SUM()` のまま確定でき、番人を「念のため」から 「もう要らない」に落とせます★。★クエリも速くなります★ - ★Q2-3 が B（複数行）なら★ — ★**最新の1行に畳んでから足す実装に差し替えます**★。 ★いまの実装は畳んでいないので、実データが B だった場合、★**清掃面積が実際の2倍〜3倍で 表示されます**★★ - ★Q2-1 が A（期間内の合計）なら★ — ★確定期間の総面積をサマリから取れるようになり、 索引の無い `started_at` の全表走査（2-10 参照）を避けられます★ #### 【来ないと何が困るか】 ★★総清掃面積は「顧客に見せる数字」になる性質のもの★★です。 - ★間違っていても、画面は正常に見えます★。★例外も出ず、桁も自然です★ - ★★気づけるのは「実績報告を受け取った顧客が、自社の店舗面積と照らして違和感を持ったとき」★★ という、★いちばん遅くていちばん痛い気づき方★になります - ★いまは番人が件数を返すだけ★（`lib/clean-area/anomaly.ts` 経由でログに出る）なので、 ★**ログを見る人がいなければ誰も気づきません**★ --- ### 2-5. 3章（第8回 Q4 の再掲）/ Q4-1〜Q4-3 — サマリの集計仕様 #### 【いま何が起きているか】 ★確定期間のKPIは `customer_summaries` / `facility_summaries` の率をそのまま読んでいます★ （`lib/db/report-mapping.ts:195-206` の `kpiFromSummaryRatios()`。呼び出しは `lib/db/index.ts:1931` と `:2201`）。 ★★つまり「TeamWorks が何をどう数えたか分からない数字を、そのまま画面に出しています」★★。 ★当期のエラー発生回数は、当方が自前で定義しています★（`lib/db/report-mapping.ts:226-250`）: - ★本清掃行（`precheck = 0`）を指す `robot_error_reports` の件数だけ★（第8回 A7） - ★`clean_timetable_id` が `null` の行 / dangling の行は含めない★ - ★`clean_error` が 2（セキュリティ有効）/ 3（D-S制御盤異常）の清掃は `robot_error_reports` が作られないため入らない★（第8回 A6-1） ★同じファイルのコメントが帰結を書いています★（`lib/db/report-mapping.ts:248-250`）: ★★「したがって『エラー発生率』は実質『ロボット異常の発生率』になる」★★。 #### 【なぜ止まっているか】 ★第8回 A7 の回答が、★**「バッチが実際にそうしている」のか「当方への助言」なのか読み取れませんでした**★★ （第9回 4章）。★当方は助言として受け取って当期側に実装しましたが、バッチ側が同じとは限りません★。 ★3章（第8回 Q4）は「多いので後で回答」という留保のまま★で、★★率の計算式・分子分母の対応・ `task_count` が予定か実施か★★が全部未確定です。 #### 【回答が来たら何ができるか】 - ★Q4-1〜Q4-3 が揃えば★ — ★**確定期間と当期のエラー発生率が同じ定義だと言えるようになります**★。 ★違うなら、当期側を合わせにいけます★（直すのは `lib/db/report-mapping.ts` の1箇所） - ★3章が来れば★ — ★★サマリの数字を検算できるようになります★★。 ★`CLAUDE.md` §4.7 は「サマリには丸め前の小数と分子・分母が格納される（検算可能にするため）」と 書いていますが、★**その検算ができる状態になっていません**★★ #### 【来ないと何が困るか】 - ★★グラフが「段差」になっても、原因を特定できません★★ — ★当期（当方集計）から確定期間（TeamWorks 集計）に切り替わる境目で数字が跳ねたとき、 実態が変わったのか定義が違うのかを、画面からもログからも判別できません★ - ★事前チェック（`precheck = 30 / 60`）のエラーがバッチ側に含まれていた場合★ — ★**確定期間のエラー発生率だけが当期の2〜3倍になります**★。 ★事前チェックは1清掃につき2回走るためです★（`clean_timetables` の実測比 538 : 253 : 253。★シード由来★） --- ### ★★2-6. 7章（マスタ投入）+ Q7-1〜Q7-5 — 分類の実データが無い★★ #### 【いま何が起きているか】 ★★分類セレクトが、5画面すべてで実質「2択」です★★（★画面実測 2026-09-17★）。 | セレクト | 選択肢 | |---|---| | ホールディングス | ★「全ホールディングス」「テストグループ001」の**2つだけ**★ | | 屋号 | ★「全屋号」「テスト顧客001」の**2つだけ**★ | ★選択肢の中身はシード由来★（`groups` 1行 / `customers` 1行 / `facilities` 12行・全行が同じ `customer_id`。`docs/handoff/規模前提の見直し_20260917.md:55-57`）。 ★この2つのセレクトは、★**清掃詳細ログ / アラート / レポート / D-Secログ / D-Secアラート の 5画面が共有しています**★★（`lib/masters/options.ts:5-8`）。 ★★**つまり5画面ぶんの絞り込み機能が、実データで一度も動いていません**★★。 ★★カスケード（ホールディングスを選ぶと屋号が絞られる）も、動いているように見えるだけ★★です — ★1グループ1顧客なので、どちらを選んでも結果が変わりません★。 #### 【なぜ止まっているか】 ★構造（`groups` → `customers.group_id` → `facilities.customer_id`）は3階層になっており、 テーブルの追加は要りません★。★足りないのは中身だけ★です。 さらに、★**投入する前に決めないといけないことが2つ**★あります。 - ★**Q7-1**★: `customers` は★法人（株式会社ドン・キホーテ）★と★屋号（ドン・キホーテ / MEGA / アピタ / ピアゴ）★のどちらの粒度か。★当方は屋号の前提で作っています★ - ★★**Q7-4**★★: ★`customers.group_id = 0`（グループなし）が、★**現状のDDLでは投入できません**★★。 `group_id` は NOT NULL DEFAULT 0 で `groups(id)` への外部キーがあり、 `@@foreign_key_checks = 1` / `sql_mode` に `NO_AUTO_VALUE_ON_ZERO` が無い（★2026-09-13 構造由来★）。 ★`groups` に `id = 0` の行が要りますが、`AUTO_INCREMENT` のため入れられません★ - ★Q7-5★: 「屋号を持たない顧客」が★3階層のどの段が空くという意味か★が未確定。 ★真ん中（屋号）が空く解釈は、`facilities.customer_id` が NOT NULL なので**表現できません**★ ★当方側のセンチネル処理（0 → `null`）は既に1箇所に閉じてあります★ （`lib/format/group-id.ts:77-79` / `lib/db/index.ts:1607` / `:1636`）。★受け皿はできています★。 #### 【回答が来たら何ができるか】 - ★**マスタが入れば**★ — ★★「MEGAドン・キホーテだけの稼働率」「アピタだけのアラート」が 画面で選べるようになります★★。★いまは選択肢が存在しません★ - ★カスケードの正しさを初めて検証できます★ — ★ホールディングスを切り替えたとき屋号セレクトが 正しく絞られるか / 選択が残ったままにならないか★は、★**1グループ1顧客では絶対に再現しません**★ - ★Q7-1 が A（屋号粒度）と確定すれば★ — ★施設マスタ画面のブランド列（`lib/db/index.ts:1636-1646`）が 意味を持ちます。いまは全行が同じ値です★ - ★Q7-4 に結論が出れば★ — ★「グループなし」の表示を作るか作らないかを決められます★ （★D（グループなしの顧客は存在しない）なら作りません★） #### 【来ないと何が困るか】 - ★★翌朝の運用で、担当者が見たい単位で絞れません★★ — ★「今朝おかしいのはMEGAだけなのか、全屋号なのか」が画面で出せない★ - ★★実データ投入日が「機能の初日」になります★★ — ★絞り込みの不具合は、実データが入るまで1つも見つかりません★。 ★見つかるのは、運用が始まった後です★ - ★2-3（Q6-2）と連鎖します★ — ★**屋号が2社以上になった瞬間、レポート画面の確定期間KPIが 422 になります**★。★マスタ投入が先に来て Q6-2 の回答が後だと、機能が一時的に壊れます★ --- ### 2-7. Q8-3 — 制御盤の報告間隔 #### 【いま何が起きているか】 ★D-Sログ画面は、制御盤ごとの「最終通信時刻」を `MAX(reported_at)` で取っています★ （`lib/db/index.ts:1440`。★以前は `control_reports` を全行取り寄せてJSで1件に切っていた★）。 ★`reported_at` に索引が無いため、`EXPLAIN` は `type=index`（フルスキャン）★（★構造由来★）。 ★`MAX(id)` なら `Using index for group-by` が効くことも実測済み★ですが、 ★**`id` の順序と `reported_at` の順序が一致する保証が無い**★ため採っていません （`lib/db/index.ts:1416-1426`）。 ★**画面実測（2026-09-17）: D-Secアラートは5件すべて「通信断」。赤が1色も出ていません**★ （★シード由来★）。★通信断はアンバー（`components/features/ds-alerts/DsAlertsScreen.tsx:36-38` の `typeColor()` が `disconnected → c.wn`）、赤になるのは「セキュリティ無効」だけ★です。 #### 【なぜ止まっているか】 ★`link_schedules` が **0行**★（★2026-09-17 実測。`docs/handoff/規模前提の見直し_20260917.md:58`★） なので、★**`intervals` の実運用値はDBからも取れません**★。 ★行数の見積もりが6倍ぶれます★（★制御盤11台という当方の置き値での試算★）: | 報告間隔 | 2年間の行数 | |---|---| | 60秒（定義書の例） | 約 1,100万行 | | ★10秒（第2回の回答の例）★ | ★**約 7,000万行**★ | ★**ロボット30台という規模の置き直しは、ここには効きません**★ — ★`control_reports` の行数は台数ではなく報告間隔で決まるためです★。 #### 【回答が来たら何ができるか】 - ★上限・下限が分かれば★ — ★★「最大でどこまで積み上がるか」を押さえて、D-Sログ画面の 作り方（ページング / 期間上限 / 集計テーブルの要否）を決められます★★ - ★変更の頻度が分かれば★ — ★その前提がいつまで持つかを判断できます★ - ★索引⑥（`(control_id, reported_at)`）を強く依頼すべきかどうかも、ここで決まります★ #### 【来ないと何が困るか】 - ★★D-Sログ画面が「ある日突然開かなくなる」形の壊れ方をします★★ — ★7,000万行を全表走査するようになれば、タイムアウトするまで画面が返りません★ - ★★そしてそれは、運用が始まって数か月経ってから起きます★★ — ★いま（`control_reports` 14行・★シード由来★）は一瞬で返るので、テストで捕まえられません★ - ★D-Security はセキュリティ解除→清掃→復帰の自動化を監視する画面★です。 ★ここが開けないと、**セキュリティが解除されたまま戻っていない状態に気づけません**★ --- ### 2-8. Q9-1 / Q9-2 + DDL未反映2件 #### 【いま何が起きているか】 - ★**Q9-2（区域別内訳）**★: 実装できているのは★「1清掃エリア（=1ロボット）につき1つの完了率」★までで、 ★**売り場・通路・レジ前といった内訳ではありません**★（`app/api/clean-logs/[id]/areas/route.ts:1-17`）。 ★清掃詳細ログの行を開くモーダルには、エリア単位の行だけが並びます★ - ★Q9-1（`robot_task_reports` の表記）★: ★当方は `clean_task_reports` を**1箇所も読んでいません**★ （`cleanTaskReport` の参照 0件。実測）。★影響はありません★ - ★DDL未反映2件★（★4回目のお願い★）: `clean_status_histories.id` の `AUTO_INCREMENT`（`prisma/schema.prisma:471-474` に 「id は AUTO_INCREMENT ではない。採番はアプリ側」とコメント済み）/ `security_status_histories.reported_at` の `DEFAULT`（`prisma/schema.prisma:420`） #### 【なぜ止まっているか】 ★第8回 A9-2 で「1エリアにつき1つの完了率が取れる」と確定したため、501 の仮実装をやめて 本実装にしました★が、★**本来の問い（1回の清掃の中の区域別内訳）は未解決のまま**★です （`app/api/clean-logs/[id]/areas/route.ts:14-16`）。 #### 【回答が来たら何ができるか】 - ★**取れるなら**★ — ★モーダルが「売り場 92% / 通路 71% / レジ前 45%」のように割れます★。 ★★翌朝の担当者が「どこに障害物があったか」を画面だけで推測できます★★ - ★★**取れないなら「できない」の一言で十分です**★★ — ★機能を諦めて、 `docs/decisions.md` に「やらない」と記録して閉じられます★。 ★**いまは「いつか来るかもしれない」状態で開いたままです**★ - ★DDL2件は、当方の `prisma/schema.prisma` のコメントを1行消せるだけ★です #### 【来ないと何が困るか】 ★★困り方は小さいですが、「閉じられない」こと自体がコストです★★ — ★引き継ぎのたびに未解決項目として持ち越され、読む人が毎回「これは何だったか」を追い直します★。 ★`docs/decisions.md` の確認事項#10 は第8回から生き残っています★。 --- ### ★★2-9. 12章 — お願い3件 + Q12-1〜Q12-6（★期限があります★）★★ #### 【いま何が起きているか】 ★**本番DB（`133.125.238.144` / `clean_watch`）は、平文で、どこからでも接続できます**★ （★2026-09-13 実測。構造由来＝サーバー変数と `SHOW GRANTS`★）。 | 変数／設定 | 実測値 | 意味 | |---|---|---| | `have_ssl` | ★**`DISABLED`**★ | ★サーバーが TLS を提供していない★ | | `require_secure_transport` | ★**`OFF`**★ | ★暗号化されていない接続を受け付ける★ | | 参照用アカウントの接続元 | ★**`参照用アカウント@%`**★ | ★`%` ＝ どこからでも★ | ★★この3つが重なると、DB接続の資格情報は必ず経路上に平文で出ます★★。 ★**そして経路は公開IP上にあります**★。 ★★さらに、これは「テスト環境」ではなく **本番DBそのもの** です★★（D-148 項1。2026-09-17 ユーザー確認）。 ★当方の文書が長らく「テストDB」と書いてきたのは誤りでした★。 #### 【なぜ止まっているか】 ★★解き方が、本番の構成次第で変わるためです★★（第9回 12-6）。 - ★VM と DB が同一の閉域ネットワークに入れるなら★ → ★TLS も接続元制限も「初めから起きない」★ - ★公開IP越しに接続する構成なら★ → ★**いまの状態がそのまま本番に持ち越されます**★ ★**そして、その構成を当方は確認していません**★。 ★D-143 は「サーバー・ネットワークの用意と構築保守は TeamWorks」と書いていますが、 ★**TeamWorks 側の明示確認は未取得**★です★（`CLAUDE.md` §2）。 ★Q12-1〜Q12-6 は、まさにそれを確かめる6問です★。 ★お願い3件★: ★12-3 接続元IPの制限（最優先）★ / ★12-4 TLS の有効化★ / ★12-5 本番用DBアカウントの新規発行★（★過去に実在のDBユーザー名がコミットに含まれ、 Git 履歴に残っています★）。 #### 【★★期限★★】 ★日付ではなく「イベント」で切っています★ — ★★本番に実データが入る前★★。 | 時点 | 作り直しのコスト | |---|---| | ★いま（ダミーのみ）★ | ★★ほぼゼロ★★。アカウントを作り直しても失うものがない | | ★実データが入った後★ | ★★「止める調整」が必要になります★★ | ★過ぎたら必要になること★: 1. ★DBアカウントの再発行★ → ★接続している側（当方のアプリ / TeamWorks の収集処理 / 集計バッチ）を★**いったん全部止めて**★差し替える★ 2. ★TLS の有効化★ → ★サーバ再起動を伴う可能性があり、★**夜間の清掃データ収集を止められません**★★ 3. ★接続元IPの制限★ → ★実データが流れている状態で絞ると、漏れた接続元から収集が止まります★ ★★D-Watch は夜間に自動実行された清掃を翌朝確認する運用★★なので、 ★止められる時間帯が構造的にありません★。 #### 【回答が来たら何ができるか】 - ★Q12-1〜Q12-6 だけでも先に来れば★ — ★★12-3〜12-5 のお願いの内容を確定できます★★ （★閉域で結べるなら、TLS の依頼は取り下げられます★） - ★Q12-1 の回答で、D-143（責任分界）の未確認部分が埋まります★ — ★`CLAUDE.md` §2 に「TeamWorks 側の明示確認は未取得」と書いてある箇所が消せます★ #### 【来ないと何が困るか】 - ★★実データが入った後は、直すのに「全部止める」という調整が要ります★★。 ★その調整は、夜間清掃を止めるという意味です★ - ★★顧客（ドン・キホーテ）の店舗の稼働データが、平文で公開IPを流れます★★ - ★12-5 は TeamWorks にしか頼めません★ — ★アカウントの発行元が TeamWorks だからです★ > ★**申し添え（D-148 項4）**★: ★送付済みの第9回 12-1 は期限を「**ステージング**に実データが > 入る前」と書いています★。★**正しくは「本番に実データが入る前」**★です。 > ★訂正は出さない判断★（D-148 項6 の追記。意図は伝わっているため）ですが、 > ★**先方が「ステージングの話」と読んで優先度を下げている可能性があります**★。 > ★催促するときは「本番の話です」と添えるほうが確実です★。 --- ### 2-10. 索引（★依頼は取り下げ済み。ただし1本も入っていない★） #### 【いま何が起きているか】 ★**第9回1章で挙げた7本は、本番DBに1本も入っていません**★ （★2026-09-17 実測。`information_schema.STATISTICS`。構造由来★。 `docs/handoff/規模前提の見直し_20260917.md:2-5節`）。 ★依頼としては取り下げ済み★です（★「ご対応中と伺った」ため。D-144 / 第9回 1-0★）が、 ★★対応完了の連絡も来ていません★★。 ★いちばん重いのは①②★（`clean_status_histories.clean_timetable_id` と `robot_error_reports.clean_timetable_id`。★索引が1本も無く `possible_keys = null`★）。 ★これは統計に基づくコスト判断ではなく**構造的な全表走査**で、行数が増えても索引を選ぶようには なりません★。 ★当方のアプリはこの2表を `clean_timetable_id IN (…)` の形でしか引きません★。 ★`IN` が1000を超えると1000件ずつに割りますが、★**塊ごとに全表走査が起きます**★★。 #### 【なぜ止まっているか】 ★★索引が入ったかどうかを当方が知る手段が「TeamWorks からの連絡」しかありません★★。 ★`EXPLAIN` を測り直すこと自体は当方でできます★が、★入る前に測っても意味がなく、 入ったタイミングが分かりません★。 ★測り直す項目は12件、既に一覧にしてあります★（`docs/handoff/規模前提の見直し_20260917.md:550-590`）。 #### 【回答（＝完了連絡）が来たら何ができるか】 - ★`EXPLAIN` を測り直し、★**残っているものがあるかを突き合わせられます**★★ - ★★清掃詳細ログの期間上限（`MAX_DATE_RANGE_DAYS = 731`）とCSV行数上限 （`MAX_CSV_ROWS = 20,000`）を、根拠つきで確定できます★★。 ★いまは「規模の前提が変わったので測り直す」と書いたまま保留です★ - ★`control_reports` の⑥が入れば、D-Sログ画面の最終通信時刻が `type=index` から抜けます★ #### 【来ないと何が困るか】 - ★★劣化は「運用が始まって2年目」に現れます★★ — ★当方のシード（31日ぶん）では絶対に再現しません★ - ★走査行数は台数と回数に対して**二乗で効きます**★（★塊の数と1塊あたりの行数が両方とも 比例するため★）。★ロボットが倍になれば走査は4倍★ - ★索引を足すと TeamWorks 側の書き込みがわずかに遅くなります★ — ★**判断は TeamWorks のもの**★ですが、★判断した結果（入れた / 入れない）を知らないと、 当方は画面の作り方を決められません★ --- ## 3. ★★催促するなら、どれを主語にすべきか★★ ★**「25問まとめて」では動きません**★。★主語を1つに絞って、理由と期限を添えるのが効きます★。 ### ★第1優先 — ★★12章（Q12-1〜Q12-6 と、お願い3件）★★★ ★**理由: これだけが「過ぎると作り直しになる」性質のものだからです**★。 - ★他の9件は、回答が遅れても「作れない / 数字が出ない」で止まるだけで、★**後から作れます**★★ - ★12章は、★**実データが入った後は「夜間の収集を止める調整」なしには直せません**★★ - ★★聞き方★★: ★**「Q12-1〜Q12-6 の YES / NO だけ先に」**★と限定する。 ★6問中5問は YES/NO で答えられます★（第9回 12-6）。★お願い3件は、その回答が来てから内容を 組み直すと伝えてあるので、先に6問だけ取りにいくのが筋です★ - ★★添えるべき一言★★: ★**「ステージングではなく本番DBの話です」**★ （★送付した本文が「ステージング」と書いてしまっているため。D-148 項4★） ### ★第2優先 — ★★Q11-1（`started_at` を使ってよいか）★★★ ★**理由: A / B の一言で、止まっている機能が1つ動き出すからです**★。 - ★★回答コストが最小で、効果が最大★★ — ★「A. その理解で問題ない」の5文字で、 要レスキューの4条件目が作れます★ - ★実装手順は既にあります★（`docs/handoff.md:4426-4440`） - ★★聞き方★★: ★**「第9回 11章の Q11-1 だけ、A か B かをお教えください」**★と、 ★1問だけ切り出す★。★11章の他の3問（Q11-2 / Q11-3 / Q11-4）は「急ぎません」と 本文に書いてあるので、混ぜないほうが答えやすくなります★ ### ★第3優先 — ★★Q6-2（サマリに「清掃実施回数」の列を足せるか）★★★ ★**理由: 屋号が2社になった瞬間にレポート画面が 422 になるからです**★。 - ★★7章（マスタ投入）が先に来ると、こちらが即座に問題になります★★。 ★順番が逆になると、機能が一時的に壊れた状態で運用が始まります★ - ★A / B / C の3択で、★**C（難しい）でも当方は前に進めます**★★（表示を減らす形に切り替える）。 ★「決めてもらえれば、どちらでもよい」と伝えるのが効きます★ - ★★聞き方★★: ★**「7章のマスタ投入より前に、Q6-2 の方針だけ決めさせてください」**★と、 ★順番の話として持ち出す★ ### ★第4優先（同時でよい） — ★★7章のマスタ投入（時期の目安だけでも）★★★ - ★★「入れてください」ではなく「いつ頃になりそうか」を聞くのが効きます★★ — ★当方はそれまで検証用の複数グループ・複数顧客を自前で用意して進められます★ - ★Q7-4（`group_id = 0` が入らない件）は★**DDL の矛盾の報告**★なので、 ★投入作業の前に必ずぶつかります★。★セットで持ち出すのが自然です★ ### ★待てるもの（急かさない）★ | 項目 | 待てる理由 | |---|---| | Q11-2 / Q11-3 / Q11-4 | ★本文に「急ぎません」と書いて送付済み★。★無ければ現状の形のまま進める、と回答パターンも書いてある★ | | Q2-1 / Q2-3 | ★安全側（B の前提）で実装する方針を本文に書いてある★。★★ただし現在の実装は畳んでいないので、B だった場合の面積は倍になります（2-4 参照）★★ | | 3章 / Q4-1〜Q4-3 | ★数字は出ている★。★正しさが確かめられないだけ★ | | Q8-3 | ★いま壊れない★。★積み上がってから効く★ | | Q9-1 / Q9-2 / DDL2件 | ★★「できない」の一言でも前に進む★★。★4回目のお願いだが実害が小さい★ | | 索引 | ★依頼は取り下げ済み★。★★催促ではなく「完了しましたらご一報ください」の形★★が筋 | ### ★まとめ（1行）★ ★★**まず 12-6 の6問。次に Q11-1 の1問。この2つだけを、別々に、短く聞く。**★★ --- ## 4. ★TeamWorks 待ちではないのに止まっているもの★（★混同しないため★） ★**ここに挙げた3件は、TeamWorks に催促しても動きません**★。 ### 4-1. ★PR #6 のレビュー★（★人待ち。DFA 内部★） - https://github.com/DFARobotics/d-watch/pull/6（`main` ← `develop`） - ★CI 緑（Lint / Test / Build すべて pass）/ `MERGEABLE` / `CLEAN`★ - ★★残っているのは「レビュアー1名の承認」だけ★★（`docs/handoff.md:5236-5240`） - ★`CLAUDE.md` §6-5「PRは必ずもう1人がレビューしてから main にマージする」★ が待ちの理由 ### 4-2. ★点検記録（F-05）の未決4件★（★DFA の意思決定待ち★） ★B1「サービスとして出すか」は解決（★出す★。D-150）★。★残る4件★: | # | 論点 | 決まらないとどうなるか | |---|---|---| | B2 | オブジェクトストレージの実体（S3互換 / さくら / VMのローカルディスク） | ★実装量が桁で違う★。★ローカルディスクだと写真配信が IP制限の内側に入り、社外から見えない★ | | B3 | 誰が用意し、費用を払い、保守するか | ★D-143 が名指ししたのは「アプリVM / DB / テスト環境」の3つだけで、**ストレージは入っていない**★ | | ★**B4**★ | ★**点検記録に「点検結果」を持たせるか**★ | ★★契約にもモックにも項目別の OK/NG もコメント欄も1つも無い★★。★記録できるのは写真と申し送り1本だけで、**点検の合否がどこにも残らない**★。★後から足すと既存レコードが全部「結果なし」になる★ | | B5 | 誰がどこから入力するか（現場スタッフ / DFA運用担当 / スマホ） | ★スマホなら、レイアウト新設・IP制限の設計変更・トークン配布の3決定が連鎖する★ | ★**B4 が設計上いちばん重い**★（D-150 項2）。★「点検記録」という名前なのに点検の結果が残らない構造★。 ### 4-3. ★4カラムの UPDATE★（★環境待ち。本番DBなので書き込めない★） - ★`robot_error_reports` / `control_error_histories` の `status` / `comment` / `responded_at` / `resolved_at` の更新★ - ★★`SHOW GRANTS` で UPDATE 権限があることは確認済み★★（2026-09-17。★構造由来★）。 ★**それでも実行しません**★ - ★理由: ★**接続先が本番DBそのものだから**★★（D-148 項5。ユーザー指示 2026-09-17） - ★★つまり「権限はあるが、書いてよい環境が無い」★★。 ★書き込みを検証できる環境をどう用意するかは**未定のまま**★（D-148 項6 の #3） - ★これは TeamWorks への質問ではなく、★**DFA 側で環境を決める話**★です★ --- ## 5. ★調べていて気づいた、D-147 の記載と実態の食い違い★ ### ★★5-1. 「確定期間の稼働率・エラー発生率が出せない」は、言い過ぎです★★ ★D-147 項2 の表★（`docs/decisions.md:11979`）と★第9回 6-2 の本文★は、次のように書いています。 > ★確定期間の稼働率とエラー発生率が出せない（分母＝実施回数が無い）★ > ★「1社であっても確定期間の2つの率が出せませんので、訂正いたします」★（第9回 6-2） ★**これは実態と違います**★。 | 事実 | 出所 | |---|---| | ★`operation_ratio` / `error_ratio` の列は**実在します**★ | `prisma/schema.prisma:699-702`（customer）/ `:733-736`（facility）。★構造由来★ | | ★アプリは**それを読んで画面に出しています**★ | `lib/db/report-mapping.ts:195-206`（`kpiFromSummaryRatios()`）。呼び出しは `lib/db/index.ts:1931` / `:2201` | ★**正しくは次の3つです**★: 1. ★**合算できない**★（複数顧客・ホールディングス単位）— ★率の平均は誤りで、Σ分子÷Σ分母の 材料が無い★。★これが `lib/reports/target-customer.ts` の 422 の理由★ 2. ★**検算できない**★ — ★率だけあって分子・分母が無い★ 3. ★**式が分からない**★ — ★3章（第8回 Q4）が未回答なので、その率が当方の定義と同じか不明★ ★**送付済みの本文に「訂正いたします」と書いて強めてしまった箇所なので、次回のやり取りで さらに訂正するのは得策ではありません**★。★ただし、社内で「確定期間の数字が出ていない」と 誤解したまま設計判断をすると危ないので、本書に記録しておきます★。 ### 5-2. 「サマリ由来の面積を使えない」の書き方 ★D-147 項2 は Q2-1 / Q2-3 について「サマリ由来の面積を使えない（現在は `clean_status_histories` から集計）」★ と書いています。★これは正確★ですが、★★より危ないのは Q2-3 のほう★★です — ★**回答が B（複数行できる）だった場合、いまの実装は面積を二重に数えます**★ （`lib/db/index.ts:1779-1787` が番人を置いているのは、まさにそのため）。 ★D-147 の表からはこの危険度が読み取れません★。 ### 5-3. 索引は「対応中」と聞いたまま、1本も入っていません ★D-147 は「1章（索引）は依頼を取り下げ済み（対応中と伺ったため）」と書いています★。 ★★ただし 2026-09-17 の実測で、7本すべてが未投入でした★★ （`docs/handoff/規模前提の見直し_20260917.md:2-5節`。★構造由来★）。 ★取り下げた依頼なので催促はできませんが、★**「対応中」と「未投入」が2週間以上並走している**★ ことは押さえておくべきです★。 --- ## 6. ★回答が来ても、それだけでは解けないもの★ ★**催促の期待値を正しく持つために書いておきます**★。 | # | 項目 | 回答が来ても残ること | |---|---|---| | ★1★ | ★Q11-1（`started_at`）★ | ★★A が来ても、「猶予30分」の値そのものは DFA が決める★★。★`CLAUDE.md` §4.4 は「暫定値。設定値として外出しする」と書いており、**実運用の値は未確定**★。★30分のままでよいかは、実データの遅延分布を見てからでないと判断できない★ | | ★2★ | ★Q6-2（実施回数の列）★ | ★A（追加できる）でも、★**バッチが再実行されて過去のサマリ行に値が入るまで、確定期間の合算は出せません**★★。★既存行の埋め戻しをするかどうかは別の話★ | | ★3★ | ★7章（マスタ投入）★ | ★投入されても、★**当方のダミー1,787行がまだ本番DBに残っています**★（D-148 項3）。★TeamWorks が本番前に削除する予定だが、**削除された確認が要る**★。★削除されると D-141 / D-144 / D-145 の実測記録が全部無効になる★ | | ★4★ | ★12章（お願い3件）★ | ★★接続元IP制限が入っても、当方側のライブラリの既知問題（TLS を有効にしても条件により資格情報が平文で出る）は残ります★★（第9回 12-3）。★**これは DFA 側で解く話**★ | | ★5★ | ★索引★ | ★入っても、★**本番の実データ量でしか本当の効果は測れません**★★。★D-111 項7（`docs/decisions.md:6683-6689`）が「テストDBでは判定できない: 本番のデータ量 / サマリバッチの実挙動 / 本番の `time_zone` 設定」と予告済み★ | | ★6★ | ★Q4-1〜Q4-3（error_count）★ | ★定義が揃っても、★**`clean_error` が 2 / 3 の清掃は `robot_error_reports` が作られない**★（第8回 A6-1）ため、★「エラー発生率」は実質「ロボット異常の発生率」のまま★★（`lib/db/report-mapping.ts:248-250`）。★画面のラベルをどうするかは DFA の判断★ | | ★7★ | ★全般★ | ★★エラー種別は7分類に変換しない方針（D-077 / `CLAUDE.md` §4.8）なので、画面には `EmergencyStop` のような英語識別子がそのまま出ます★★。★`lib/theme-status.ts` の色分けは日本語6文字列の完全一致なので、**生値では全部グレーにフォールバックします**★。★これは TeamWorks の回答では解けません★ | --- **以上。** > ★本書は決定ではありません★。★決めるのは daichi です★。 > ★次に更新するとき★: ★回答を受領したら `docs/decisions.md` に受領日を記録すること★ > （D-147 項3。★送付と受領の両方を記録する作法★ — ★過去に2回、回答済みなのに > 「送付待ち」のまま引き継いだ事故があります★）。