# D-Watch TeamWorks への回答待ち一覧

**作成: 2026-10-19（同日改訂: TeamWorks 宛てだけに絞った） / 作成者: DFA Robotics（D-Watch 開発）**

D-Watch の開発で、いま TeamWorks の回答・情報・作業を待っているものをまとめました。
番号の「TW」は TeamWorks 宛てを表します。
各項目には、以前にもらった回答と、それでも載せている理由を書いています。

# 1. 一覧

| 番号 | 待っていること | 頼んだ日 | 過去の回答 | 優先度 |
|---|---|---|---|---|
| TW-1 | 事前チェックのエラーに付く予定の番号の念押し確認 | 2026-10-07 | あり | 低〜中 |
| TW-2 | 清掃結果のデータが、清掃の終了から最大どれくらい遅れて入るか | 2026-10-07 | あり | 中 |
| TW-3 | ステージングへのデータ投入が終わったという連絡 | 2026-10-07 | あり | 高 |
| TW-4 | ステージングサーバーへの D-Watch の設置（`.env` での組み直し）と完了の連絡 | 2026-10-07 | あり | 高 |
| TW-5 | エラー表のシリアル番号の列を長くする作業（DB の定義の変更） | 2026-10-05 | あり | 低 |

TeamWorks には、第12回の確認事項（R-1〜R-3）と、ステージングへの設置依頼を送っています。
第12回の確認事項には、2026-10-19 時点で回答の記録がありません。
D-Security の制御盤の記録についての第13回の確認事項（S-1〜S-8）は作成中で、まだ送っていないため、この一覧には入れていません。
優先度は当方の見立てです（高: 画面の確認や公開の前提になるもの / 中: 作りを変える可能性があるもの / 低: 急がないもの）。

# 2. 各項目の詳細

### TW-1. 事前チェックのエラーに付く予定の番号の念押し確認

| 項目 | 内容 |
|---|---|
| 待っていること | 清掃の前にロボットの状態を確かめる「事前チェック」でエラーが見つかったとき、エラーの記録に付く予定の番号が、事前チェックの予定の番号か、本清掃の予定の番号か。今回は念押しの再確認です |
| 相手 | TeamWorks |
| 頼んだ日 | 2026-10-07。第12回の確認事項 R-1（社内の記録は D-172・D-175） |
| 過去の回答 | TeamWorks から2回もらっています。(1) 第8回（2026-09-11 送付）A7「どちらも指しています」（D-114）。(2) 第10回 N-11 の回答「A」（2026-10-02）。A は「事前チェックと本清掃は予定の種類（`precheck`）で見分けられる」です。当方は 2026-10-02 に「想定どおり」と記録しました（D-155） |
| それでも載せている理由 | 2026-10-07 にユーザーが「事前チェックも本清掃も同じ番号が付く気がする」と見立てました（D-172）。ステージングのエラー16行も、すべて本清掃の番号が付いています。事前チェックの番号が付いた行は、まだ1行もありません。過去の回答と食い違わないかを念のため確かめます |
| 変わること | 本清掃の番号が入る場合、アラート画面の「30分前異常」などの表示が1件も出なくなります。画面は事前チェックの予定の番号が付いたエラーだけを拾っているためです。その場合は、事前チェックのエラーの見分け方を教えてもらい、拾い方を作り直します |
| それまでの扱い | 過去の回答どおりの作りのまま（事前チェックの予定の番号が付いたエラーだけを「N分前異常」として出す） |

### TW-2. 清掃結果のデータが、清掃の終了から最大どれくらい遅れて入るか

| 項目 | 内容 |
|---|---|
| 待っていること | 清掃結果の表（`clean_task_reports`）の行が、清掃の終了から、普段どれくらい、遅いときは最大どれくらい遅れて書き込まれるか |
| 相手 | TeamWorks |
| 頼んだ日 | 2026-10-07。第12回の確認事項 R-2（社内の記録は D-173・D-175） |
| 過去の回答 | 2026-10-07 にユーザー（daichi）が「30分より遅れる可能性はあります」と回答（D-172）。これを受けて「結果待ち」の表示を作りました（D-173） |
| それでも載せている理由 | 遅れの上限が分かっていません。1時間以内なら、いまの2時間を短くできます。2時間を超えるなら、延ばす必要があります |
| 変わること | 「結果待ち」と表示する時間（いまは2時間）を決め直します。短すぎると、書き込みが遅れただけの清掃を「出発失敗」と出してしまいます。長すぎると、本当に失敗した清掃に気づくのが遅れます |
| それまでの扱い | 予定の終了から2時間は「結果待ち」と表示し、失敗に数えません。2時間を過ぎても結果が無い清掃は「出発失敗」と表示します。2時間は設定で変えられます |

### TW-3. ステージングへのデータ投入が終わったという連絡

| 項目 | 内容 |
|---|---|
| 待っていること | TeamWorks がステージングのDBに入れているデータ（清掃の予定と、その結果のつながりを含む）の投入が終わったという連絡 |
| 相手 | TeamWorks |
| 頼んだ日 | 2026-10-07。第12回の確認事項 R-3（お願い）。投入中であることは 2026-10-06 に把握（社内の記録は D-158・D-175） |
| 過去の回答 | 第10回の回答（2026-10-02）で、空のテーブルには「10/5中に何らかのデータを格納する」、マスタの追加は「未定、レビュー後然るべきタイミングで」、データの入れ替えは「ありうる。時期は未定」。第11回 P-14（2026-10-05）で、入れ替えるときは前日までに連絡すると「承知」 |
| それでも載せている理由 | 投入には終わりの時期が決まっていません。そのため「完了」の連絡が来ないままになるおそれがあります。連絡を待つだけにせず、下の当方の目安でも確かめ直しを始めます |
| 当方の目安（案） | 連絡が無くても、次のどちらかで確かめ直しを始めます。(1) 終わった本清掃の予定の95%以上に、清掃結果がつながったとき。(2) 2026-10-31 を過ぎたとき。目安はユーザーの了承を得て決めます |
| 変わること | 実データで画面をまとめて確かめ直します。清掃の予定と結果のつながり方、ダッシュボード・アラート・結果待ちの出方、時刻のずれが無いこと、画面の速さなどです |
| それまでの扱い | 投入途中のデータで画面は動いています。予定とつながっていない結果は「予定外の清掃」として扱うため、その予定は「出発失敗」に見えることがあります。2026-10-07 時点では、結果87行のうち80行が予定とつながっていました |

### TW-4. ステージングサーバーへの D-Watch の設置（`.env` での組み直し）と完了の連絡

| 項目 | 内容 |
|---|---|
| 待っていること | TeamWorks が保守しているステージングサーバーで、D-Watch のコンテナを `.env` で組み直す作業と、その完了の連絡（公開URL・起動の記録） |
| 相手 | TeamWorks |
| 頼んだ日 | 2026-10-07 に設置依頼書を作成（D-176）。組み直しの中身は 2026-10-19 に決め、daichi から TeamWorks に伝えます |
| 過去の回答 | TeamWorks から「Docker の環境を作るためにソースを見たい」と依頼があり、2026-10-08 にソース一式を TeamWorks の GitBucket に載せました（D-177。2026-10-19 に最新版へ更新）。これで、設置依頼書の Q1（Dockerfile は TeamWorks が作る）と Q4（コードは GitBucket で受け渡す）は、事実上決まりました |
| それでも載せている理由 | 2026-10-19 に、ステージングのコンテナが `.env.local` という設定ファイルを読んでいることが分かりました。このファイルはサーバー側で作られたもので、GitBucket のソースには入っていません。設定を正しい形で渡し直す必要があります |
| 組み直しの要点 | (1) コンテナのソースの置き場所にある `.env.local` を消す。(2) 代わりに `.env` を作る。(3) ビルドし直して起動する |
| `.env` に書くもの | ログイン用の合言葉（`AUTH_TOKEN`）は、開発用とは別の32文字以上の新しいもの。参照用DBの接続情報5つ（ホストは、コンテナの中から届く宛先にする）。更新用DBのユーザーとパスワード（`DATABASE_WRITE_USER` / `DATABASE_WRITE_PASSWORD`）。`USE_FIXTURES=false`。値はこの文書には書きません |
| 接続元の制限 | かけません（許可リストは空のまま、空なら全部通す設定のまま。2026-10-07 の判断どおり。D-176）。この2つはソースの中の定数（`lib/config/allowed-ips.ts`）なので、`.env` には書きません |
| うまくいった目印 | 起動の記録に `- Environments: .env` と出ること |
| 変わること | DFA の関係者が、社外からも実データで画面を確かめられるようになります |
| それまでの扱い | 実データの画面は、DFA の開発用PCからだけ確かめています |

設置依頼書の残りの設問（Q2 合言葉の作り方・Q3 公開URLと証明書・Q5 載せ替えの頼み方）は、回答の記録が社内の資料にありません。

### TW-5. エラー表のシリアル番号の列を長くする作業

| 項目 | 内容 |
|---|---|
| 待っていること | エラーの表（`robot_error_reports`）のシリアル番号の列を、20文字から100文字に広げる DB の定義の変更 |
| 相手 | TeamWorks |
| 頼んだ日 | 2026-10-05（第11回の回答の中で TeamWorks が申し出） |
| 過去の回答 | 第11回 P-8 の回答（2026-10-05）で、TeamWorks が「本日中に varchar(100) に変更する」 |
| それでも載せている理由 | 2026-10-06・10-07 に確かめた時点では、20文字のままでした（D-158・D-171） |
| 変わること | 変更を確かめたら、当方の DB の定義（Prisma）を DB から取り込み直します。あわせて、ロボット番号の列が空でもよくなった変更（ステージングでは変更済み）も取り込まれます |
| それまでの扱い | 急ぎません（2026-10-07 のユーザー判断。今のシリアル番号は20文字に収まるため）。第12回にも入れていません。当方は、空の値がありうるロボット番号の列を読まない作りにして、古い定義のままで動かしています |

**以上です。**