# 第9回確認事項の送付手順（2026-09-16 作成）

**作成: 2026-09-16 / 作成者: DFA Robotics（調査担当）**

> ★★**その後どうなったか（2026-09-16 追記。本書より新しい）**★★
>
> ★**3案のうち、ユーザーは「案B: 1通に統合する」を選びました**★（D-143）。
> したがって★本書 §3-3 の3案の比較は「決める前の検討材料」として読んでください★。
> ★**案C が成立しないことの根拠（第9回に本番構成を問う設問が0件）だけは、いまも有効**★です。
>
> 統合の結果:
> - 第9回に ★12章（DB接続経路のお願い3件・確認6問）★ を新設（コミット `9e8c0f7`）
> - ★設問 20問 → 26問 / お願い 10件 → 13件★（★既存20問はすべて残存を確認済み★）
> - ★PDF を再生成済み★ — ★17ページ → **23ページ** / 318,253 bytes★。点検スクリプトは ★OK★
>   （コミット `1726817`）。★初版は `DWatch_確認事項_第9回_20260915_初版.pdf` に退避★
> - ★§1-4 のリスク（スクリプトが本文をハードコード）は現実化する前に処理済み★ —
>   ★`.md` と `make` と `check` の3点セットを同時に直したので、いまは一致しています★
> - ★§1-5 の「目視が必要」は実施済み★（監督が PDF を開いて確認。★日本語の字形・12章の内容とも問題なし★）
>
> ★★残るのは「送付（daichi）」と「送付日を `docs/decisions.md` に記録すること」だけです★★。

---

## この文書の位置づけ

- 対象は `docs/handoff/TeamWorks確認事項_第9回_20260915.md`（★716行 / 全20問＋依頼9件★。実測 `wc -l`）です。
- ★**本書は段取りだけを書いています。送付そのものは daichi が行います**★（二重送付を避けるため。
  第6回と同じ作法。`docs/decisions.md:2169`「★第6回は daichi から送付する★」）。
- ★**本書は第9回の本文を1文字も書き換えていません**★。鮮度点検で見つかった点は
  §3 に「提案」として並べるだけにとどめています。
- ★**`docs/handoff/セキュリティ申し送り_20260916.md` も読むだけで、書き換えていません**★。

> ★**本書に認証情報は書いていません**★（`CLAUDE.md` §9.3）。
> ホスト・DBユーザー名も本書では扱いません（既出の `file:line` の参照のみ）。

---

# 1. ★PDF の実測状況（2026-09-16 実測）★

## 1-1. 生成物は存在し、再生成も通ります

| 項目 | 実測 |
|---|---|
| 生成済み PDF | `docs/handoff/pdf/DWatch_確認事項_第9回_20260915.pdf` / ★272,675 bytes★ / ★2026-09-15 18:40:22★ |
| 生成スクリプト | `docs/handoff/pdf/make_teamworks_qa9_pdf.py`（1,547行 / 2026-09-15 18:40:16） |
| 点検スクリプト | `docs/handoff/pdf/check_teamworks_qa9_pdf.py`（959行 / 2026-09-15 18:41:20） |
| ★再生成の結果★ | ★**成功（終了コード 0）**★。`DWATCH_PDF_OUT` を一時ディレクトリに向けて実行し、既存 PDF は上書きしていません |
| ★再生成物との一致★ | ★**バイト数は完全一致（272,675）**★。相違は ★74バイトのみ★で、いずれも `/CreationDate` `/ModDate` と ファイルID（PDF のメタデータ）。★**本文のストリームは完全に同一**★ |

★**帰結: いま手元にある PDF は、いまのスクリプトが作るものと中身が同じです。**★
★**送付前に作り直しても、作り直さなくても、届く内容は変わりません。**★

> ★**PDF はリポジトリに入っていません**★ — `.gitignore:53-54` が `docs/handoff/pdf/*.pdf` を
> 除外しており、`git ls-files docs/handoff/pdf/` にも `.py` と `README.md` しか出ません（実測）。
> ★手元のファイルが消えても、スクリプトから再生成できます★。

## 1-2. 点検スクリプトの結果は ★OK★

`python docs/handoff/pdf/check_teamworks_qa9_pdf.py <PDF>` の実測（終了コード 0）:

| 検査 | 結果 |
|---|---|
| 1. ページ数・サイズ | 17ページ / 266.3KB / 抽出17,651文字 |
| 2. ★フォント埋め込み★ | ★**BIZ UDGothic（R / Bold）を5サブセット埋め込み**★。★中国語向けフォントの混入なし★ |
| 3. 原稿の文言 | 444項目を検査、★欠落 0★ |
| 4. ALTER TABLE | ★7本すべて、索引名・列名まで一致★ |
| 5. 実測値（数値） | 65項目、★欠落 0★ |
| 6. 識別子の語中改行 | 90件検査、★割れ 0★ |
| 7. 章・設問の採番 | ★11章 / 22問。原稿に無い設問番号なし★ |
| 8. 豆腐（グリフ欠け） | ★なし★（651文字種を BIZ UDGothic R / B で照合） |
| 9. 空白ページ | ★なし★（全17ページに本文あり） |
| 10. 認証情報 | ★漏れなし★。IPは許可した1つのみ、`mysql://` は伏せ字 |

★**点検スクリプトが見るもの**★: PDF から抽出したテキストと、スクリプト内に転記した原稿の文言の照合。
★**生成スクリプトを import しません**★（`check_teamworks_qa9_pdf.py:9-11`）ので、生成側の実装が
変わっても検査結果は独立です。

## 1-3. ★日本語フォントは明示指定されています（問題なし）★

`make_teamworks_qa9_pdf.py:71-73`:

- `FONT_DIR = "C:/Windows/Fonts/"` から ★`BIZ-UDGothicR.ttc` / `BIZ-UDGothicB.ttc`★ を登録
- 同 `:10-11` に ★「中国語向けフォント（SimSun / Microsoft YaHei / Noto Sans SC / STSong 等）は
  漢字の字形が異なるため使わない。フォールバックにも混ぜないこと（CLAUDE.md §0-3）」★ と明記
- 点検スクリプトが ★中国語フォントの混入★ と ★豆腐★ の両方を検査し、★どちらも「なし」★（§1-2）

★**`CLAUDE.md` §0-3 の要求を満たしています。ここに直す点はありません。**★

## 1-4. ★★リスク: 生成スクリプトは本文をハードコードしています★★

★**`make_teamworks_qa9_pdf.py` は `.md` を読みません。**★
実測: 同スクリプト内の `open(` / `read_text` / `Path(` のうち、原稿を読む箇所は ★1件もありません★
（`:16` の「原稿は docs/handoff/TeamWorks確認事項_第9回_20260915.md」は ★docstring の記述★であって
読み込みではありません）。表データと `build()` の本文に ★文言が直接書き込まれています★。

★**点検スクリプトも同じです**★ — `check_teamworks_qa9_pdf.py:9-11` が
★「下に転記した原稿の文言だけ」を見る★と明記しており、`.md` を開く処理はありません。

### ★この構造から出るリスク★

| リスク | 内容 |
|---|---|
| ★★`.md` を直すと PDF とズレる★★ | 原稿を1文字でも直したら、★`make_*.py` と `check_*.py` の両方を手で直す★必要があります。★直し忘れても、点検は「OK」と言います★（点検側も同じ古い文言を持っているため） |
| ★逆向きは検出できる★ | `make_*.py` だけ直して `check_*.py` を直し忘れた場合は、★点検が「欠落」で落ちます★。この向きは安全です |

★**したがって §3 の「足したほうがよい項目」を本文に採り入れる判断をされた場合は、
`.md` / `make_*.py` / `check_*.py` の3点セットで直す必要があります**★（`docs/handoff/pdf/README.md`
「次回（第6回）を作るとき」の手順2・3と同じ）。

> ★**現時点では3者は一致しています**★（点検 444項目・欠落0 が実測の裏付け）。
> ★**本文を直さずにそのまま送るなら、このリスクは顕在化しません。**★

## 1-5. ★点検スクリプトでも見られないもの（目視が必要）★

`check_teamworks_qa9_pdf.py` の出力自身が最後に警告しています:

> 「表の列幅崩れ・改ページ位置は、この点検では見られない。★全ページの目視確認は省かないこと★」

`docs/handoff/pdf/README.md` にも ★第2回で列幅不足の折り返しが5箇所発生し、第5回でも
サマリ表の列幅を 44mm → 50mm に直した★実績が記録されています。
★**17ページの目視は省かないでください**★（→ §4 の手順3）。

## 1-6. ★ついでに見つかった小さなズレ（送付には影響しません）★

`docs/handoff/pdf/README.md` の「対応関係」表が ★第5回までしか載っていません★（第6〜9回が未記載）。
「実績」表も第5回どまり。★送付には影響しないため、本書では直していません★。

---

# 2. ★鮮度点検 — いま送って問題ないか★

## 2-1. ★★結論: そのまま送れます★★

★**事実誤りは1件も見つかりませんでした。**★
★**古くなっているのは「予定です」という時制だけで、いずれも“もう実装した”方向のズレです。**★
★**送付を止める理由にはなりません（むしろ依頼の根拠は強くなっています）。**★

## 2-2. ★時制が古くなった箇所（4件。すべて「予定」→「実装済み」）★

| # | 箇所 | 本文の記述 | いまの実測 |
|---|---|---|---|
| 1 | `TeamWorks確認事項_第9回_20260915.md:44` | 「表示期間を★現在の上限31日から、上限2年に広げる★予定です」 | ★**すでに実装済み**★。`lib/config/index.ts:359` `MAX_DATE_RANGE_DAYS = 731`（D-136。`docs/decisions.md:10233`） |
| 2 | 同 `:165`（1-4 ご依頼⑤） | 「清掃総面積を期間で絞って集計する画面 を追加する予定です」 | ★**すでに実装済み**★（D-141。`docs/decisions.md:10964`）。`app/api/clean-area/route.ts` / `lib/db/clean-area-source.ts` / `components/features/clean-area/` |
| 3 | 同 `:260`（Q2-2） | 「『清掃総面積の累計』を画面に表示する機能 を追加する予定です」 | 同上 |
| 4 | 同 `:374` / `:426`（6章・7章） | 「ホールディングス単位のKPIを画面に出す予定です」 | ★分類の復活は実装済み（D-138。`docs/decisions.md:10593`）★。ただし ★合算に必要な材料がDBに無い★という本文の主張は現在も正しい |

★**ズレの向き**★: いずれも ★**「予定」と書いてあるものが、もう動いている**★ です。
★**依頼を弱める向きではありません。**★ 相手に誤った情報を渡すことにはなりません。

## 2-3. ★★Q5-1（面積の単位は㎡か）★★ — 重みが上がっています

★**本文は直す必要がありません。ただし状況が変わったことは把握しておいてください。**★

| 時点 | 状況 |
|---|---|
| 2026-09-15（本文作成時） | 「画面に単位を表示する★以上★、推測で書くわけにまいりません」（`:339`）＝ ★これから出す★ |
| ★2026-09-16（いま）★ | ★**清掃面積画面が実際に「㎡」を出しています**★。`lib/config/index.ts:696` `export const AREA_UNIT = "㎡" as const;` |

★実測で確かめた「1箇所に閉じ込められているか」★:
`AREA_UNIT` を参照しているのは `lib/format/number.ts:62` / `components/features/clean-area/CleanAreaScreen.tsx`
ほかで、★画面・API に `"㎡"` の直書きはありません★。`app/api/clean-area/route.ts:98` は
★レスポンスに単位を入れない★方針を明記しています。

★**帰結: 回答が「㎡ではない」だった場合、直すのは `lib/config/index.ts:696` の1行です。**★
★**本文の主張（「単位を伺った記録がない」）はいまも事実ですので、書き換え不要です。**★

## 2-4. ★足したほうがよい項目（★提案のみ。本文は直していません★）★

★**いずれも「送付を止めてまで足すもの」ではありません。**★
★**daichi の判断で、足す／足さない／第10回に回す を決めてください。**★

| # | 提案 | 理由 | 優先度（当方の見立て） |
|---|---|---|---|
| ★P-1★ | ★索引①②の緊急度を「予定」から「稼働中」に上げる★（`:44`） | ★2年検索はすでに本番コードで動いています★（`MAX_DATE_RANGE_DAYS = 731`）。「広げる予定」より「もう広げた」のほうが依頼の根拠が強い | ★中★（送付を遅らせてまでやる価値はない） |
| P-2 | ご依頼⑤の根拠を「予定の画面」から「実装済みの画面」に直す（`:165`） | 同上。`clean_status_histories` の `groupBy` + `_sum` は既に稼働中（`lib/db/clean-area-source.ts`） | 中 |
| P-3 | `require_secure_transport = OFF` を参考章に足す | ★第9回の参考章には `have_ssl` と `参照用アカウント@%` しかありません★（`:705-706`）。申し送り文書は3つ目として `require_secure_transport` を実測記録しています（`セキュリティ申し送り_20260916.md:143`） | ★低★（→ §3 の案次第では不要になります） |
| P-4 | 本番の施設数・台数（8章 Q8-1/Q8-2）を社内で決める線も併記する | `docs/decisions.md:9607` が ★「これは TeamWorks ではなく DFA 側で決めること」★ と明記している。★聞いても「そちらで決めてください」と返る可能性★ | 低 |

★**当方の推奨は「本文は直さずそのまま送る」です。**★
★理由: §1-4 のとおり本文を直すと `.md` / `make_*.py` / `check_*.py` の3点を直す必要があり、
17ページの目視もやり直しになります。得られるもの（時制の精度）に対して手間が大きいためです★。

---

# 3. ★★セキュリティ申し送りとの重複整理★★

## 3-1. 重複している範囲（★実測で1行ずつ突き合わせました★）

★重なっているのは、第9回の末尾「参考: テスト環境について（申し送り）」（`:698-711`。★14行★）と、
申し送り文書の「1. テストDBが公開IPに平文（TLS無効）で開いています」（`:124-191`。★68行★）です★。

| 記述 | 第9回 | 申し送り | 判定 |
|---|---|---|---|
| テスト環境のホストとポート | `:700` | `:132` | ★**重複**★ |
| `have_ssl = DISABLED`（TLS無効） | `:705` | `:142` | ★**重複**★ |
| 接続元 `参照用アカウント@%`（どこからでも接続可） | `:706` | `:144` | ★**重複**★ |
| 「現在は検証用データのみなので支障なし」 | `:708` | `:159-160` | ★**重複**★ |
| ★依頼3点（接続元IP制限 / TLS有効化 / パスワード）★ | `:709-710` | `:178-180` | ★**重複**★（★第9回は「ご検討ください」、申し送りは「ご依頼です」と強さが違うだけ★） |
| `require_secure_transport = OFF` | ★無し★ | `:143` | ★申し送りのみ★ |
| 誰が直せるかの切り分け（DB管理者 / 契約主体） | ★無し★ | `:164-172` | ★申し送りのみ★ |
| ★期限「ステージングに実データが入る前」★ | ★無し★ | `:78-100` | ★申し送りのみ★ |
| 測定日・測定者の明示（2026-09-13 / DFA） | ★無し★ | `:135-136` | ★申し送りのみ★ |

★**つまり第9回の参考章は、申し送り §1 の“短縮版”です。**★
★**第9回にあって申し送りに無い記述は、1件もありませんでした。**★

★申し送り文書自身もこの重複を自覚しています★ — `セキュリティ申し送り_20260916.md:184-190` の
引用ブロックが ★「すでに一度お伝えしている件です」★ とし、★第9回 `:698-711` を名指し★したうえで
★「ただし第9回確認書を送付したという記録が残っていない。送付済みかどうかを先に確定する必要がある」★
と書いています（同 `:461-471` の付録 A-4 も同じ）。

★**その前提条件は、2026-09-16 に確定しました: 第9回は未送付です。**★
★**したがって申し送り §1 は「再掲＋強化」ではなく、実質的に“初出”になります。**★

## 3-2. ★申し送りにあって、第9回にまったく無い部分★

★申し送り471行のうち、第9回と重ならない部分が大半です★:

| 節 | 内容 | 第9回との関係 |
|---|---|---|
| §2（`:193-292`） | ★`mariadb` コネクタの脆弱性3件★。★`ssl: true` でも平文パスワードが漏れる★ / `No fix available` の理由（`@prisma/adapter-mariadb@7.10.0` が `mariadb` 3.4.5 を完全固定） | ★完全に新規★ |
| §3（`:294-376`） | ★実在のDBユーザー名が Git 履歴に残存★。アカウント再発行の依頼 | ★完全に新規★ |
| §4（`:378-427`） | ★本番構成の YES/NO 5問★（VM と DB が閉域で結べるか） | ★完全に新規★。★★第9回に「構成」を問う設問はありません★★ |
| §5（`:429-445`） | DFA側でやったこと／やれないこと | ★完全に新規★ |

★★重要: §2 は §1 の依頼内容を変えます★★ — ★「TLS を有効にしても、このコネクタでは
資格情報が保護されない可能性がある」（`:255-262`）ため、申し送りは「TLSより先に経路を閉じてほしい」
という順序を主張しています★。★第9回の参考章（`:709-710`）は TLS を素直に並べており、
★★この2つを別々に送ると、依頼の優先順が食い違って届きます★★。

## 3-3. ★★3案とその帰結★★（★決めるのは daichi です★）

### ★案A: 第9回と申し送りを同時に送る（2通）★

| 観点 | 帰結 |
|---|---|
| 相手の手間 | ★★重い★★。716行＋471行を同時に受け取る。★重複部（§3-1 の5項目）を2回読ませる★ |
| 回答の早さ | ★★遅くなる恐れ★★。第9回の ★最優先である索引①②★ が、量に埋もれます |
| 期限への影響 | ★**最良**★。セキュリティ4項目が ★いま★ 相手に届く。「ステージングに実データが入る前」に最も余裕ができる |
| ★混乱の危険★ | ★★あり★★ — §3-2 のとおり、TLS の扱いについて★2通で優先順が食い違います★ |
| ★準備の手間★ | ★★申し送りの PDF がありません★★（→ §3-4）。第9回と同じ体裁で出すなら ★`make_*.py` / `check_*.py` を新規に書く必要★ |

### ★案B: 申し送りを第9回の追補として1通にまとめる★

| 観点 | 帰結 |
|---|---|
| 相手の手間 | ★軽い★。1通で完結し、★重複を消せる★（第9回の参考章を削り、申し送り §1 に寄せる） |
| 回答の早さ | ★★遅くなる★★ — ★★統合には本文の書き換えが要り、`.md` / `make_*.py` / `check_*.py` の3点セット＋17ページの目視をやり直すことになります★★（§1-4 / §1-5）。★**今日中の送付はまず無理です**★ |
| 期限への影響 | ★★悪い★★。統合作業の日数ぶん、セキュリティ4項目の到達が遅れます |
| 混乱の危険 | ★**最小**★。優先順を1つの文書で示せる |
| ★★致命的な問題★★ | ★★申し送りは宛先が確定していません★★ — `セキュリティ申し送り_20260916.md:43-77` が ★項目1の宛先（契約主体次第）★ と ★項目4の宛先（両論併記）★ を ★「ユーザー（daichi）判断待ち」★ としています。★TeamWorks 宛の第9回に丸ごと混ぜると、★**DFAインフラ担当に出すべき部分まで TeamWorks に送ることになります**★★ |

### ★案C: 第9回を先に送り、申し送りは構成の確認（項目4）の回答後に送る★

| 観点 | 帰結 |
|---|---|
| 相手の手間 | ★最も軽い★。まず716行、回答を挟んでから471行 |
| 回答の早さ | ★**最良**★。★索引①②が単独で目立ちます★（本文 `:716` が「★1章の索引①②だけでも先にご対応いただけますと★」で締めくくられている） |
| 期限への影響 | ★★危険★★ — ★★第9回に「本番構成」を問う設問がありません★★（§3-2 で実測）。★つまり「項目4の回答」は第9回を送っても返ってきません★。★**待っていても永遠に来ません**★ |
| 混乱の危険 | 小 |
| ★成立させる条件★ | ★申し送り §4 の Q1〜Q5（YES/NO 5問。`:414-427`）だけを先に切り出して送る★なら成立します。★その場合は「案C'」として、5問だけの短い問い合わせを第9回と同時か直後に出す形になります★ |

### ★当方の見立て（★決定ではありません★）★

★**案A を、順序をつけて実施する形（A'）が最も無理がないと考えます。**★

1. ★第9回を先に送る（本文そのまま。PDF は再生成不要）★
2. ★同日〜翌営業日に、申し送りを別便で送る★。★その際、送り状に「第9回末尾の参考章と §1 は同じ件です。
   §1 のほうが詳しいので、そちらをご覧ください」と1行添える★ ← ★★重複を消さずに、読む順だけ示す★★
3. ★申し送りの宛先が未確定な部分（§0-1 注1 / 項目4）は、daichi が先に切り分ける★

★理由★: ★重複は5項目・14行しかなく（§3-1）、1行の断り書きで無害化できます★。
★一方、統合（案B）は3点セットの直しと目視のやり直しが発生し、★期限に対して割に合いません★★。

## 3-4. ★★申し送り文書には PDF 生成スクリプトがありません（実測）★★

`docs/handoff/pdf/` に存在するのは ★第1回〜第9回（`qa2`〜`qa9` ＋ `ddl_review`）だけ★です（実測 `ls`）。
★`セキュリティ申し送り_20260916.md` に対応する `make_*.py` / `check_*.py` はありません★。

| 送り方 | 必要な作業 |
|---|---|
| ★`.md` のまま送る★ | ★作業ゼロ★。ただし ★体裁が第1〜9回と揃いません★ |
| ★PDF で送る★ | ★`make_teamworks_qa9_pdf.py` を雛形にスクリプトを新規作成★（`README.md` の手順2・3）。★471行ぶんの表データの書き起こしが必要★ |

★**これは案A / 案B / 案C のどれを選んでも発生します。daichi の判断が要る点です（→ §6）。**★

---

# 4. ★送付までの手順（誰が・何を・どの順で）★

★**前提: 送付の実行者は daichi です。以下で「担当」が daichi の行は、代行しません。**★

| 手順 | 担当 | やること | 完了の判定 |
|---|---|---|---|
| ★0★ | ★daichi★ | ★§6 の判断事項を決める★（特に ★重複の扱い（§3-3 の案）★ と ★申し送りの宛先★） | 案が1つに決まっている |
| 1 | 誰でも | ★PDF を再生成する（任意）★<br>`DWATCH_PDF_OUT=C:/Users/daich/Downloads python docs/handoff/pdf/make_teamworks_qa9_pdf.py` | 終了コード 0 / 272,675 bytes 前後 |
| 2 | 誰でも | ★点検スクリプトを走らせる★<br>`python docs/handoff/pdf/check_teamworks_qa9_pdf.py <PDFのパス>` | ★「結果: OK」かつ終了コード 0★ |
| ★3★ | ★★人間（daichi 推奨）★★ | ★★17ページの目視確認★★ — ★表の列幅崩れ・改ページ位置・識別子の折り返し★。★点検スクリプトでは見えません★（§1-5） | 全17ページを見た |
| 4 | daichi | ★社内メンバーへの連絡★ — 「第9回を今日送る」旨を共有し、★★二重送付を防ぐ★★（`docs/decisions.md:2169` と同じ理由） | 共有済み |
| ★5★ | ★★daichi のみ★★ | ★★送付★★（PDF ＋ 送り状）。★案A' なら、送り状に §3-3 の1行を添える★ | 送信済み |
| ★6★ | ★daichi または作業者★ | ★★`docs/decisions.md` に送付記録を追記する（→ §5 の文案）★★ | `grep -n "第9回" docs/decisions.md` に送付記録が出る |
| 7 | 作業者 | ★`docs/handoff/セッション引き継ぎ_20260916.md` §2 の1位★ を「済」に更新する（★別作業。本書では触っていません★） | — |

> ★★手順6 を飛ばさないこと★★ — ★第1回・第4回で同じ記録漏れを2回やっています★
> （`docs/handoff.md:1545-1549` / `docs/decisions.md:430-431` `:1208` `:1402`）。
> ★第5回も「回答受領日は分かるが送付日が未確認」という中途半端な状態で残っています★
> （`docs/decisions.md:1399`）。★**今回が3回目になりかけました。**★

---

# 5. ★★送付後に `docs/decisions.md` に貼る記録の文案★★

★**決定番号は `D-XXX` のままにしてあります。**★

> ★★理由★★: `docs/decisions.md` は ★番号順に並んでいません★（`docs/decisions.md:10370-10371` が
> 「★このファイルは番号順に並んでいないので末尾では最大値を判断できない★」と明記）。
> ★採番は「全番号を数値順に並べた実測で最大値を確認してから」行う作法★になっています
> （D-135 / D-137 / D-141 の採番注記。`:10005` `:10371` `:10967`）。
> ★★本書の作成時点（2026-09-16）の最大は D-141 ですが、送付までに別の決定が入る可能性があります。
> したがって採番は監督が送付確定後に実測してから行います。★★

## 5-1. ★貼り付け用（★`D-XXX` と `YYYY-MM-DD` を置き換えてください★）★

```markdown
### D-XXX `[確定]` TeamWorks 確認事項 ★第9回★ を送付した（★送付日を記録に残す★）

> ★**採番についての注記**★: 本エントリを書くにあたり、全決定番号を数値順に並べる実測を行い、
> 最終番号が `D-XXX`（`docs/decisions.md:XXXXX`）であることを確認してから連番を採った。
> ★このファイルは番号順に並んでいないため、末尾を見るだけでは最大値を判断できない★
> （`docs/decisions.md:10370-10371`）。

**決定日**: YYYY-MM-DD

**何を送ったか**

| 項目 | 内容 |
|---|---|
| 原稿 | `docs/handoff/TeamWorks確認事項_第9回_20260915.md`（★716行★） |
| 送付物 | `DWatch_確認事項_第9回_20260915.pdf`（17ページ / 272,675 bytes。★`docs/handoff/pdf/make_teamworks_qa9_pdf.py` から生成★） |
| 中身 | ★全20問＋依頼9件★（11章構成）。★1章の索引7件が最優先★ |
| 作成日 | 2026-09-15 |
| ★送付日★ | ★**YYYY-MM-DD**★ |
| 送付者 | ★daichi★（★二重送付を避けるため送付は daichi が行う作法。`docs/decisions.md:2169`★） |
| 送付前の点検 | `check_teamworks_qa9_pdf.py` → ★「結果: OK」（444項目・欠落0 / ALTER TABLE 7本 / 実測値65項目 / 豆腐なし / 認証情報の漏れなし）★ ＋ ★17ページの目視確認★ |
| ★本文の書き換え★ | ★**なし**★（2026-09-15 の作成時のまま送付した） |

**★本文をそのまま送った理由★**

2026-09-16 に鮮度点検を行い、★事実誤りは0件★であることを確認した
（`docs/handoff/第9回送付手順_20260916.md` §2）。
★古くなっていたのは「予定です」という時制4箇所のみ★で、いずれも
★「予定と書いたものが、もう実装済み」★という向きだった（D-136 の731日 / D-141 の清掃面積画面）。
★依頼を弱める向きではなく、相手に誤った情報を渡すことにはならない★と判断した。

★また生成スクリプトは原稿をハードコードしている★（`.md` を読まない）ため、
★本文を直すと `.md` / `make_*.py` / `check_*.py` の3点と17ページの目視をやり直すことになる★。
★得られるもの（時制の精度）に対して手間が大きいため、そのまま送った★。

**★回答待ちになったもの★**

| 章 | 待っている番号 | ブロックされていること |
|---|---|---|
| 1 | 依頼①〜⑦ | ★2年検索（`MAX_DATE_RANGE_DAYS = 731`）が全表走査のまま★ |
| 2 | Q2-1 / Q2-2 / Q2-3 | サマリ由来の面積を使えない |
| 3 | 第8回 Q4 | サマリの率・分子・分母の関係 |
| 4 | Q4-1 / Q4-2 / Q4-3 | 当期と確定期間で `error_count` の定義が食い違う恐れ |
| 5 | Q5-1 | ★`AREA_UNIT = "㎡"` の根拠★ |
| 6 | Q6-1 / Q6-2 | 複数顧客の合算ができない |
| 7 | Q7-1〜Q7-5 | 分類の本番データ / `group_id = 0` の投入 |
| 8 | Q8-1 / Q8-2 / Q8-3 | 本番規模の見積もり |
| 9 | Q9-1 / Q9-2 ＋ DDL2件 | — |
| 10 | DB更新用アカウント | ★4カラムの UPDATE が1本も書けない★ |
| 11 | Q11-1 / Q11-2 / Q11-3 | ★要レスキューの4条件目「出発失敗」★ |

**★次にやること★**

- ★回答を受領したら、受領日も本台帳に記録する★
  （★送付時と回答受領時の両方で記録するのが本プロジェクトの作法★。`docs/decisions.md:1211`）
- ★第1回・第4回で送付記録の漏れを2回やっている★（`docs/handoff.md:1545-1549`）。
  ★第5回も送付日が未確認のまま残っている★（`docs/decisions.md:1399`）。★同じことを繰り返さない★
```

## 5-2. ★申し送り文書を送った場合に足す行（★案A / 案A' を採った場合★）★

```markdown
| ★同時に送ったもの★ | `docs/handoff/セキュリティ申し送り_20260916.md`（471行 / 4項目）。
★第9回の末尾「参考: テスト環境について（申し送り）」（`:698-711`）と項目1が重複するが、
統合せず別便とした★（`docs/handoff/第9回送付手順_20260916.md` §3-3 案A'）。
★送り状に「§1 のほうが詳しい」旨を1行添えた★ |
```

---

# 6. ★★daichi の判断が要る点★★

| # | 判断事項 | 選択肢 | ★当方の見立て★ | 出典 |
|---|---|---|---|---|
| ★J-1★ | ★★重複の扱い★★ — 第9回と申し送りをどう送るか | ★案A（同時2通）／案B（統合1通）／案C（時間差）／案A'（同時だが送り状で読む順を示す）★ | ★**案A'**★。★統合は期限に対して割に合わない★ | §3-3 |
| ★J-2★ | ★★申し送りの宛先★★ — 項目1（契約主体）と項目4（VM/DB） | TeamWorks / DFAインフラ担当 / 両方 | ★当方では決められません★。★申し送り文書自身が「判断待ち」と明記★ | `セキュリティ申し送り_20260916.md:43-77` `:461-471` |
| ★J-3★ | ★申し送りを PDF にするか★ | `.md` のまま送る / 生成スクリプトを新規作成する | ★体裁を揃えるなら PDF だが、★**スクリプトの新規作成が要ります**★★ | §3-4 |
| J-4 | ★本文を直すか★（§2-4 の P-1〜P-4） | 直さず送る / 直してから送る / 第10回に回す | ★**直さず送る**★ | §2-4 |
| J-5 | ★第9回の PDF を再生成するか★ | 既存を使う / 作り直す | ★どちらでも同じ★（★本文ストリームは完全一致。差は日時メタデータ74バイトのみ★） | §1-1 |
| J-6 | ★8章 Q8-1 / Q8-2（施設数・台数）を社内で決めるか★ | TeamWorks に聞く / 社内で決める | ★`docs/decisions.md:9607` が「DFA側で決めること」と明記★。★聞いても返らない可能性★ | §2-4 P-4 |

---

# 付録: ★回答が来たら何が動き出すか（★実測で裏取り済み★）★

★出典は `docs/handoff/セッション引き継ぎ_20260916.md` §3 の表ですが、★**鵜呑みにせず1件ずつ実測で確認しました**★。★

| 待っているもの | 動き出すこと | ★実測の裏取り★ | 判定 |
|---|---|---|---|
| ★索引依頼①②★<br>（`clean_status_histories` / `robot_error_reports` の `clean_timetable_id`） | ★2年ぶんの詳細ログ検索が軽くなる★ | `lib/config/index.ts:359` ★`export const MAX_DATE_RANGE_DAYS = 731;`★ を実測。★2年表示はすでに稼働中★（D-136。`docs/decisions.md:10233`） | ★★裏取り済み。ただし引き継ぎ表の「2年検索が重いまま」は★**もう実装済みのものが重い**★という意味であり、より切迫している★★ |
| ★Q11-1★（実開始時刻の所在） | ★要レスキューの4条件目「出発失敗」が実装可能になる★ | `lib/judge/rescue.ts:34` の `RescueReason` は ★3値のみ★（`not_executed_streak` / `escalation_l3` / `completion_drop`）。同 `:15` が ★「未実施が3日以上連続（＝出発失敗と同義）」★ と明記。`lib/config/index.ts:53-59` にも ★「回答が来たら4つ目の条件を足す」★ | ★★裏取り済み★★ |
| ★Q5-1★（面積の単位） | ★`AREA_UNIT` の根拠が確定する★ | `lib/config/index.ts:696` ★`export const AREA_UNIT = "㎡" as const;`★。同 `:690-695` が ★「回答が違っていたら全画面が間違った単位を主張する。だから1箇所に置いている。直すのはここ1行で済む」★ | ★★裏取り済み。★1行で直せる★のも実測どおり★★ |
| ★DB更新用アカウント★（10章） | ★4カラム（`status` / `comment` / `responded_at` / `resolved_at`）の UPDATE が書けるようになる★ | アプリコード（`app/` `lib/`。`lib/generated/` を除く）に ★DB書き込みは1件もありません★（実測）。`CLAUDE.md` §3 の「DB接続アカウント（2種）」と一致 | ★★裏取り済み★★ |
| ★Q2-1★（サマリ面積の合計性） | サマリ由来の面積を使う／使わないが確定する | `lib/clean-area/aggregate.ts:16-18` が ★「`facility_summaries` / `customer_summaries` の `task_area` / `clean_area` は実データで全行 1000 固定であり、期間内の合計になっていない（第9回 Q2-1 で照会中）」★ と明記。★現状は `clean_status_histories` から毎回集計★ | ★★裏取り済み★★ |
| ★Q7-4★（`group_id = 0` がFKで入らない） | ローカルDBに「グループなし」の顧客を投入できるようになる | `scripts/seed-local-db.ts:773-776` が ★「`groups` に id=0 の行は無いので `group_id = 0` は外部キー違反になりうる」★、同 `:801` `:1870` に ★保留処理と「第9回 Q7-4 照会中」の注記★ | ★★裏取り済み★★ |
| ★Q11-3★（出発成功率の計算式） | 出発成功率の式が確定する | `lib/reports/target-customer.ts:13` の表に ★「出発成功率 / `launch_count` / `task_count`? / ★式が未確認★」★ | ★★裏取り済み★★ |
| ★Q6-2★（「清掃実施回数」列の追加） | 複数顧客の合算（稼働率・エラー発生率）ができるようになる | `docs/decisions.md:10714` ★「複数顧客の合算 / 稼働率・エラー発生率を合算する材料がDBに無い（第9回 6章で照会中）」★ | ★★裏取り済み★★ |

★**訂正が要る点は1件もありませんでした。**★
★**ただし索引①②の行だけは、「2年検索が重いまま」ではなく
★**「すでに稼働している2年検索が、全表走査のまま動いている」**★ と読むのが正確です。**★

---

**以上です。**