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回にも入れていません。当方は、空の値がありうるロボット番号の列を読まない作りにして、古い定義のままで動かしています |
以上です。
