# TeamWorks 様 確認事項（第5回）

**作成: 2026-09-07 / 作成者: DFA**

第3回・第4回のご回答をありがとうございました。**すべて反映しています。**

本書は次の5部構成です。

| 区分 | 件数 | 性質 |
|---|---|---|
| **1. 解決した件のご共有** | 3件 | ★**回答不要**★。いただいた回答をどう反映したかのご報告 |
| **2. 最新のDDLのお願い** | 1件 | ★**対応済みとのご回答が、受領済みDDLに入っていません**★ |
| **3. 週の帰属についての確認** | 3件 | ★**X-1 は定義書とご回答が食い違っています。最優先**★ |
| **4. エラー情報についての確認** | 3件 | ★**定義書の備考欄が空で、値が分かりません**★ |
| **5. 継続と保留** | 2件 | DB更新用アカウント / B-1・B-2 は保留で了解しております |

---

## 1. 解決した件のご共有（★回答不要です★）

### 1-1. W-1（月跨ぎ週）— いただいたルールをそのまま採用しました

「週の回数と月は明確に区分けする」というご方針に合わせ、
**当方の暦計算を「週を月境界で分割する」方式に統一します。**

- 8/30〜8/31＝**8月第6週** / 9/1〜9/5＝**9月第1週** / 9/6〜9/12＝**9月第2週**
- 2026/8/1 は1日だけでも **8月第1週**
- ★**当方が持っていた別ルール（1日でも翌月が混ざれば翌月の第1週）は破棄しました**★

**暦を2020〜2040年の全252か月で総当たりして検証し、いただいた例と一致することを確認しています。**

### 1-2. D-1（`link_schedules.intervals` の書式）— 解決しました

**区切りはカンマ**で、24個・先頭が0時・最後尾が23時・値は秒（1〜3599）、という理解です。

★**テーブル定義書の備考欄に最初から明記されていました。こちらの確認漏れでした。**★
2往復もお手数をおかけして申し訳ありません。**以後、書式や値域は定義書を先に確認します。**

### 1-3. Q1-1（備考）— ビューアー側で持つことにしました

D-Secログの「備考」は、**DB の項目ではなく運用担当が書き留めるメモ**でしたので、
**ビューアーに入力欄を作り、DFA 側の独自ストアに保存する**形で実装します。
★**メインDB には書き込みません。DB 側の対応は不要です。**★

---

## 2. 最新のDDLをいただけますでしょうか

第4回で「**A-1 / A-3 / B-3b は対応済み**」とのご回答をいただきましたが、
★**受領済みの `clean_watch_20260907.sql`（2026-09-07 10:29 受領）には入っていませんでした。**★

3つの方法（全文差分 / `CREATE TABLE` 単位の抽出 / 制約名の全文検索）で照合しています。

| # | 内容 | 受領済みDDLの状態 |
|---|---|---|
| **A-1** | `robot_error_reports` の主キーを `error_id` にする | **未反映** |
| **A-3** | `contact_type` / `email` の型 | **未反映** |
| **B-3b** | `timestamp` 系の DEFAULT | **未反映** |

**その後に対応いただいたものと思いますので、最新のものをいただけますでしょうか。**
**受領しましたら、当方でその日のうちに照合してご報告します。**

---

## 3. 週の帰属についての確認（3件）

### X-1 ★サマリの `week` は 1〜5 と定義されていますが、第6週はどう格納されますか★

**テーブル定義書**（`customer_summaries` / `facility_summaries` /
`customer_error_summaries` / `facility_error_summaries` の4テーブル）の
`week` カラムの備考には、こう書かれています。

> 第1週 1, 第2週 2, 第3週 3, 第4週 4, 第5週 5　0は月の集計値を表す

**一方、第4回でいただいた W-1 のご回答では、8/30〜8/31 が「8月第6週」です。**

つまり、**定義書の 1〜5 では第6週を表現できません。**

#### 第6週はカレンダー上、実際に発生します

**発生条件**: ★**31日月で1日が金曜または土曜、または30日月で1日が土曜**★
（28日・29日月では発生しません）。
**2020〜2040 の252か月のうち55か月＝年平均2.6回**発生します。

★**そして 2026年5月と8月は、すでに過ぎた月です。**★

| 年月 | 1日の曜日 | 日数 | **第6週の範囲** | 状態 |
|---|---|---|---|---|
| 2025-03 | 土 | 31日 | 3/30〜3/31（2日） | 過去 |
| 2025-08 | 金 | 31日 | 8/31 のみ（**1日**） | 過去 |
| 2025-11 | 土 | 30日 | 11/30 のみ（**1日**） | 過去 |
| **2026-05** | 金 | 31日 | **5/31 のみ（1日）** | ★**過去**★ |
| ★**2026-08**★ | 土 | 31日 | ★**8/30〜8/31（2日）**★ | ★**先月。確定済み**★ |
| 2027-01 | 金 | 31日 | 1/31 のみ（1日） | 今後 |
| 2027-05 | 土 | 31日 | 5/30〜5/31（2日） | 今後 |
| 2027-10 | 金 | 31日 | 10/31 のみ（1日） | 今後 |

つまりこれは「将来こうなったら困る」という話ではなく、
★**すでに格納先が必要になっている**★という話です。
**2026年9月6日（日）6:00 の週次バッチが集計した「前週」には、
`2026年8月 第6週`（08-30〜08-31）が含まれるはずです。**

#### ★この範囲は1〜2日しかないため、欠けても気づきにくいです★

上の表のとおり、第6週の実日数は**1日または2日**です。そのため、

- もし「`week` は1〜5」という前提で実装されていると、
  **08-30〜08-31 の2日分がどこにも格納されないまま、総量としては目立たず数字が落ちます**
- 逆に「第5週に含める」実装だと、**2026年8月第5週が 08-23〜08-31 の9日間**になり、
  当方の暦計算（日曜〜土曜で切り、月境界で分割）と**範囲がズレます**

**どちらも、当方の画面と貴社のサマリで数字が食い違う形になります。**

#### 参考: 2026年8月の週の切れ目（全6週）

1日が土曜の31日月なので、**第1週と第6週の両方が短くなります**。

| 週 | 期間 | 日数 |
|---|---|---|
| 8月第1週 | 08-01（土）のみ | **1日** |
| 8月第2週 | 08-02（日）〜08-08（土） | 7日 |
| 8月第3週 | 08-09（日）〜08-15（土） | 7日 |
| 8月第4週 | 08-16（日）〜08-22（土） | 7日 |
| 8月第5週 | 08-23（日）〜08-29（土） | 7日 |
| ★**8月第6週**★ | ★**08-30（日）〜08-31（月）**★ | ★**2日**★ |

#### お伺いしたいこと

**次のどちらでしょうか。**

| 案 | 内容 | 当方の対応 |
|---|---|---|
| **A** | **定義書が古く、`week` に 6 が入る** | 当方はこの前提で実装します（下記） |
| **B** | **`week` は 1〜5 のままで、第6週は別の扱いになる** | ★**扱いを教えてください**★（第5週に含める / 行を作らない / 別の値 など） |

★**当方の方針: `week` の上限を 6 として実装します。**★（DFA として決定済み）

第6週がカレンダー上で実際に発生する以上、**上限5では表現できない期間が生じる**ためです。

| 項目 | 当方の実装 |
|---|---|
| API の `week` パラメータ | ★**1〜6**★ |
| 画面の期間ナビ | 「2026年8月 **第6週**」を表示し、8月第6週 ⇄ 9月第1週 を行き来する |
| サマリの読み込み | **`week = 6` の行が来る前提**で読みます |
| `week = 0` | **月の集計値**として扱い、週次の指定値としては受け付けません（X-2 参照） |

`week` カラムの型は `unsigned tinyint` なので **6 は物理的に格納できます**。
ですので、**A であれば当方はこのまま進められます。**
ただし**定義書の備考が「1〜5」のままだと、貴社・当方とも後から読んだときに判断できません**。
★**定義書の備考の更新をお願いできますでしょうか。**★

★**B の場合は、当方の実装をやり直すことになります。**★
**その場合はお早めにお知らせください。** あわせて、
**2026年5月・8月の第6週にあたる期間の数字がどこに入っているか**もお教えください。

### X-2 `week = 0` は「月の集計値」、`month = 0` は「年の集計値」という理解でよいですか

定義書の備考から、次のように読み取りました。

| 粒度 | `year` | `month` | `week` |
|---|---|---|---|
| 週次 | 年 | 月 | **1〜6** |
| 月次 | 年 | 月 | **0** |
| 年次 | 年 | **0** | **0** |

- 週次・月次・年次を区別する専用のカラムは無く、**`month` / `week` が 0 かどうかで粒度を判別する**
- したがって、当方がサマリを読むときは
  **月次を取るなら `week = 0` で絞り、年次を取るなら `month = 0 AND week = 0` で絞る**

★**当方はこの前提で実装します**★（定義書の記載を正とします）。
**違っている場合のみ**お知らせいただければ結構です。
なお**年次の行（`month = 0`）は P1 では読みません。** レポート画面は週次・月次のみのためです。

### X-3 週次バッチの「前週」は、月をまたぐとき2行になりますか

★**これは「矛盾していませんか」というお伺いではありません。**★
**2行になるのが、いただいたルールの当然の帰結**という理解です。
お伺いしたいのは、**バッチの実装がそうなっているか**の確認です。

**気になっているのは、次の2つの単位が一致しないことです。**

| | 単位 |
|---|---|
| **バッチの対象定義** | 「毎週日曜 6:00 に**前週（日曜〜土曜）**を集計」＝ **7日で1本** |
| **サマリの格納単位** | 月境界で分割した週 ＝ **月をまたぐと2本** |

つまり「前週」は7日ひと続きでも、**格納先は2行に分かれる**はずです。

具体例（2026年9月6日〈日〉6:00 のバッチ）:

| 集計対象 | 期間 | 格納される行 |
|---|---|---|
| 前週の8月分 | **08-30（日）〜08-31（月）** | `year=2026, month=8, week=6` |
| 前週の9月分 | **09-01（火）〜09-05（土）** | `year=2026, month=9, week=1` |

★**この場合、1回のバッチで2行が作られるという理解でよいでしょうか。**★

- **もし1行だけ（どちらか一方の月に寄せる）なら、寄せなかった側の期間の数字が欠けます。**
  例では 08-30〜08-31 の2日分、または 09-01〜09-05 の5日分が抜けます
- 当方の画面は「その月の第N週」を指定してサマリを読むため、
  **行が無い週は「データなし」として表示されます**

なお、**この分割によって週ごとの日数が1〜7日で変わります**（上の例では2日と5日）。
稼働率・完了率などの比率は分母も一緒に短くなるため計算は成立しますが、
**「前週比」を並べたときに2日の週と7日の週を比べることになります。**
第4回で「**その分集計結果に差が出ますが、そこは運用後の課題になります**」と
いただいたとおりの認識でおりますので、**この点は回答不要です。**

---

## 4. エラー情報についての確認（3件）

第3回でいただいた D-2 のご回答（**待機中・充電中は `robots.status`、
ハンドルアップ以降は `robot_error_reports` から取得。値は PUDU の
「Common Open Interface Error Codes」**）を踏まえ、**当方で対応表を作る前提で準備しています。**

★**ところが、テーブル定義書の `error_level` / `error_type` / `error_detail` の
備考欄がいずれも空欄で、格納される値が分かりませんでした。**★
値の形が分からないと対応表のキーが決まらないため、以下をお伺いします。

### Y-1 ★`robot_error_reports.error_type`（`varchar(100)`）に入る値の「形」を教えてください★

**PUDU のドキュメントを参照するにあたり、どの形で格納されるかで対応表のキーが変わります。**

| 想定される形 | 例 |
|---|---|
| PUDU のエラーコードの**数値を文字列で** | `"10001"` |
| PUDU の**コード名（英字）** | `"HandleUp"` / `"LOST_LOCATION"` |
| **日本語の名称** | `"ハンドルアップ"` |
| **コードと名称の組み合わせ** | `"10001:HandleUp"` |

★**実際に入っている値を1〜2件、そのままお見せいただけると確実です。**★
（`varchar(100)` という長さから、コード番号だけではない可能性が高いと見ていますが、推測は避けたいです）

**あわせて、`error_type` が空文字や NULL になるケースがあるかもお教えください。**
当方は「**未知の値は「その他」に寄せる**」方針で実装するため、
**空の場合も「その他」に寄せてよいか**を確認させてください。

### Y-2 `robot_error_reports.error_level`（`varchar(20)`）に入る値の一覧を教えてください

**定義書の備考欄が空**で、値が分かりません。`varchar(20)` なので文字列と思われますが、

- `"warning"` / `"error"` のような英字の区分でしょうか
- `"軽度"` / `"重度"` のような日本語でしょうか
- PUDU 側の区分をそのまま入れているのでしょうか

★**当方はこの値を画面の重要度表示や並び順に使いたいと考えています。**★
値の一覧と、**それぞれの意味（どちらが重いか）**をお教えいただけますでしょうか。

### Y-3 サマリ側の `error_type` は `robot_error_reports.error_type` と同じ値域ですか

`customer_error_summaries` / `facility_error_summaries` にも
`error_level` / `error_type` / `error_detail` / `error_count` の4カラムがあり、
**1行 = 1エラー種別 × 期間の集計行**という設計と読み取りました。

★**この `error_type` は、`robot_error_reports.error_type` と同じ値が入るという理解でよいでしょうか。**★

- **同じ**であれば、当方が作る対応表を**明細とサマリの両方で使えます**
- **違う**（サマリ側では別の分類にまとめている等）の場合は、
  ★**サマリ側の値の一覧もお教えください**★

**当方のレポート画面は「エラー種別の内訳」をサマリから読む設計です。**
明細とサマリで分類が違うと、**同じ画面の中で明細とサマリの数字が突き合わせられなくなります。**

**また `error_detail`（`text`）に何が入るかもお教えください。**
画面に出す想定であれば、**長さの目安**（1行程度か、長文が入りうるか）を知りたいです。

---

## 5. 継続と保留

### 継続: DB更新用アカウントの発行（第1回から）

`robot_error_reports` / `control_error_histories` の
`status` / `comment` / `responded_at` / `resolved_at` **のみ** UPDATE 可、という権限をお願いしております。

★**恐れ入りますが、発行の見込みをお教えいただけますでしょうか。**★
当方はいま開発用のサンプルデータで実装しており**作業は止まっていません**が、
**実DBへの接続に進む段階で必要になります。**

### 保留で了解しているもの: B-1 / B-2

**外部キー3本とインデックスについて「後で登録する」とのご回答でしたので、保留で了解しております。**
★**当方の開発は止まっていません。**★ 登録された際に、DDL の再受領時にあわせて確認します。

---

## おわりに

**優先度をつけるとすれば次の順です。**

| 順 | 項目 | 理由 |
|---|---|---|
| 1 | ★**X-1**★（`week` の上限） | ★**B の場合、当方の実装をやり直すことになります**★。A であればそのまま進められます |
| 2 | ★**最新のDDL**★ | 受領後、当方でその日のうちに照合します |
| 3 | ★**Y-1**★（`error_type` の値の形） | 清掃詳細ログの状態表示（ハンドルアップ / 緊急停止 / オフライン）が作れません |
| 4 | **Y-2 / Y-3** | 重要度表示と、レポートのエラー内訳に使います |
| 5 | **X-2 / X-3** | 確認のみ。**当方の作業は止まっていません** |
| 6 | **DB更新用アカウント** | 実DB接続の段階で必要になります |

引き続きよろしくお願いします。