第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 は、いまのスクリプトが作るものと中身が同じです。★ ★送付前に作り直しても、作り直さなくても、届く内容は変わりません。★

★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）:

★点検スクリプトが見るもの★: 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 を開く処理はありません。

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

★したがって §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件。すべて「予定」→「実装済み」）★

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

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

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

★実測で確かめた「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回に回す を決めてください。★

★当方の推奨は「本文は直さずそのまま送る」です。★ ★理由: §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回の参考章は、申し送り §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回と重ならない部分が大半です★:

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

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

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

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

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

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

★案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 はありません★。

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

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

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

★★手順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 を置き換えてください★）★

### 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' を採った場合★）★

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

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

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

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

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

以上です。