GitBucket
TeamWorks 様 確認事項（第6回）
作成: 2026-09-08 / 作成者: DFA Robotics
★参照用アカウントを発行いただき、ありがとうございました。★ （GRANT SELECT ON clean_watch.* / DB名 clean_watch。2026-09-08 に受領しております）
また第5回以降にいただいた error_type の24値と error_level の4値のご回答も、 ありがとうございました。いずれもすでに反映しています。
本書は次の4部構成です。
| # | 内容 | 優先度 |
|---|---|---|
| 1. 解決した件のご共有 | いただいた回答をどう反映したかのご報告 | ★回答不要★ |
| 2. 接続先（ホスト名・ポート）のご連絡 | ★あとはこれだけで接続できます★ | ★最優先★ |
| 3. 最新のDDLのお願い | 第5回からの継続。A-1 / A-3 / B-3b | 高 |
| 4. 継続と保留 | DB更新用アカウント / B-1・B-2 は保留で了解しております | — |
★質問は2件です。今回は質問を2件に絞ってあります。★ エラー種別についてお伺いする予定だった件は、★当方で確認できるようになりましたので取り下げました★（1-5）。
1. 解決した件のご共有（★回答不要です★）
1-1. 参照用アカウントを受領しました
GRANT SELECT ON clean_watch.* にて発行いただきました。ありがとうございます。 認証情報は当方の環境変数ファイルにのみ保管し、文書・リポジトリには残していません。
あとは接続先さえ分かれば繋がる状態です（第2部）。
1-2. error_type の24値・error_level の4値をいただき、対応表を作成しました
Y-1 / Y-2 のご回答をありがとうございました。 24値がすべて EmergencyStop のような英字の識別子であることが分かりましたので、 当方でその一覧を整理した資料を作成し、実装の突き合わせ先としています。
varchar(100) という長さも、この形であれば納得がいきました。
1-3. ★エラー種別の扱いを変更しました（貴社側の追加対応は不要です）★
当方は当初、error_type を7分類（ハンドルアップ / LostLocation / オフライン / ブラシエラー / 緊急停止 / 充電不足 / その他）に寄せて表示する設計でおりました。
いただいた24値と突き合わせたところ、7分類のうち3つに対応する値が見当たりませんでした。 ここで当方が推測で対応付けを行うと、現場に誤った指示を出すおそれがあります （例: モーター異常を「ブラシエラー」と表示してしまう）。
そこで方針を変更し、
★DBに格納されている値を、変換せずそのまま画面に表示する方式にしました。★
したがって ★画面には EmergencyStop のような識別子がそのまま出ます。★ これは意図した挙動です。 ★実データの分布を確認したうえで、必要になった時点で表示名を整えます。★
★この変更により、貴社側で追加の対応が必要になることはありません。★ むしろ、貴社が後から値を追加された場合でも当方の画面が壊れなくなります。
1-4. Warning / Event の非格納も、そのまま前提にしました
※Warning, Event はファイルに記録するけど, データベースに情報として格納しない予定.
とのご注記を承知しました。 ★当方は Fatal / Error の2つだけが読める前提で実装します。★ 重要度の表示もこの2段階を前提に設計しています。
なお「内容をみて後から判断するかもしれない」とのことでしたので、 コード自体は4値すべてを受け取れる形にしてあります。 後から Warning が入るようになっても、当方の画面は壊れません。
1-5. ★エラー種別についての照会は、当方での確認に切り替えました★
第5回・第6回で、ハンドルアップやブラシエラーが error_type のどの値に当たるかを お伺いする予定にしておりました。
しかし 1-3 のとおり、格納されている値をそのまま表示する方式に変更しましたので、 ★分類の対応付けについてお伺いする必要がなくなりました。★
あわせて、★参照用アカウントをいただきましたので、error_type に実際に入っている値は 当方で確認できます。★
したがって、★これらの照会は取り下げます。★
★実データを確認して疑問が残った場合は、あらためてお伺いします。★ その際は ★具体的な件数や値を添えてお尋ねします★ ので、ご判断いただきやすいかと存じます。
2. ★接続先（ホスト名・ポート）をお教えいただけますでしょうか — 最優先★
アカウントはいただきましたので、あとは
★接続先のホスト名（または IP アドレス）と、ポート番号★
をお教えいただければ接続できます。
あわせて確認させてください
| # | 確認したいこと | 補足 |
|---|---|---|
| 1 | ★接続元IPの制限はありますか★ | ある場合、当方の接続元をお伝えしますのでお知らせください |
| 2 | ★SSL/TLS 接続は必須でしょうか★ | 必須の場合、証明書の受け渡し方法もお教えください |
| 3 | ★接続先はステージング環境でしょうか、本番環境でしょうか★ | 当方の扱い（参照のみ / 負荷のかけ方）を合わせたいためです |
★なぜ急いでお願いしているか★
- ★9月中に PPIH 様向けにデモを実施する可能性があります。★
- ★実データでお見せできるかどうかが、この接続情報で決まります。★
- サンプルデータでの動作確認は済んでおり、★画面自体は動いています★。 実データに接続できれば、そのままデモに使えます。
接続情報だけが、現時点で当方から埋められない部分です。
★接続でき次第、当方で確認する内容を先に共有しておきます★
貴社への照会をこれ以上増やさないためです。 以下は実データを見れば当方で確認できますので、繋がった時点で照会が減ります。
| # | 確認する内容 | もともとの照会 |
|---|---|---|
| 1 | robot_error_reports.error_type に実際に出現する値と件数の分布 |
第6回 1-5（取り下げた照会の裏取り） |
| 2 | robots.status に実際に出現する値 |
第2回でいただいたコード表との突き合わせ |
| 3 | 週次サマリの week に 6 が入る行があるか |
★第5回 X-1★ |
| 4 | week = 0 / month = 0 AND week = 0 の粒度 |
★第5回 X-2★ |
| 5 | 月跨ぎ週が2行に分かれて格納されているか | ★第5回 X-3★ |
| 6 | error_level に Warning / Event が入っていないか |
第6回 1-4 |
★これらは実データを見れば当方で確認できますので、貴社への照会を減らせます。★ 確認した結果は、こちらからご報告します。
3. 最新のDDLをいただけますでしょうか（第5回からの継続）
第4回で「A-1 / A-3 / B-3b は対応済み」とのご回答をいただきましたが、 ★受領済みの clean_watch_20260907.sql（2026-09-07 10:29 受領）には入っておりませんでした。★
3つの方法（09-02版との全体差分 / 各 CREATE TABLE ブロックからの項目抽出 / 追加されるはずの制約名の全文検索）で照合し、いずれも同じ結果でした。 ★お願いしていた7項目のうち、反映されていたのは2項目です。★
| # | 内容 | 受領済みDDLの状態 |
|---|---|---|
| A-1 | robot_error_reports の error_id を主キーと位置付けて対応 |
★未反映★（PRIMARY KEY 無し。UNIQUE KEY は error_id のみ） |
| A-3 | contact_type / email の型 |
★一部のみ★（customer_contacts.contact_type は tinyint unsigned に修正済み。★facility_contacts.email が varchar(255) のまま★） |
| B-3b | security_status_histories.reported_at の DEFAULT |
★未反映★（timestamp NOT NULL のまま） |
反映いただいていた2件（customer_contacts.contact_type の型、 clean_task_reports の created_at / updated_at の DEFAULT）は、 当方のスキーマにも取り込み済みです。ありがとうございました。
参照用アカウントをいただいたので、当方でも確認できるようになりました
★prisma db pull でスキーマを取り込めば、DDL の再受領を待たずに現状を確認できます。★ この点でも接続情報（第2部）が効いてきます。
ただし、★取り込めるのは「今こうなっている」という状態だけで、 それが意図された最終形かどうかは当方には判断できません。★ そのため、まとまった段階で DDL をいただけると確実です。
★受領しましたら、当方でその日のうちに照合してご報告します★（第5回と同じ運用です）。
急かす意図はありません。 上記3件はいずれも当方の開発を止めていません。 状況が分かれば十分です。
4. 継続と保留
継続: DB更新用アカウントの発行（第1回から）
robot_error_reports / control_error_histories の status / comment / responded_at / resolved_at ★の4カラムのみ★ UPDATE 可、 という権限をお願いしております。
「後で必要なテーブルに更新権限を付与する」とのご連絡をいただいており、承知しております。 ★恐れ入りますが、発行の見込みをお教えいただけますでしょうか。★
★当方の作業は止まっておりません。★ 対応状況の更新機能は画面まで実装済みで、書き込み先を差し替えるだけの状態です。 時期の目安さえ分かれば、そこに合わせて段取りします。
保留で了解しているもの: B-1 / B-2
外部キー3本とインデックスについて「後で登録する」とのご回答でしたので、 ★保留で了解しております。★ ★当方の開発は止まっていません。★ 登録された際に、DDL の再受領時にあわせて確認します。
データ保持ポリシーについて（★催促ではありません★）
過去データをどれだけ遡って保持するかについては、 ★当方の都合で後回しにしております。★ 画面の期間指定の上限に関わる話ですが、P1 の実装には影響しません。 ★貴社へのお願いではありませんので、ご対応は不要です。★
おわりに
★今回は、お伺いすることを2件に絞りました。★ 優先度をつけるとすれば次の順です。
| 順 | 項目 | 理由 |
|---|---|---|
| 1 | ★接続先（ホスト名・ポート）★ | ★アカウントはいただいたので、これだけで接続できます★。9月中のデモを実データで行えるかがここで決まります |
| 2 | ★最新のDDL★ | 受領後、当方でその日のうちに照合してご報告します |
★1（接続先）が最優先です。これだけ先にいただければ、当方で確認できることが一気に増えます。★ 第2部の表に挙げた6件は、繋がった時点で当方で確認できますので、 その分だけ貴社への照会が減ります。
引き続きよろしくお願いします。