⚙️ Vault運用

2026-08-02_作業ログ

最終更新 2026年08月02日 ／ 90_Meta/Claude作業ログ/2026-08-02_作業ログ.md

作業ログ 2026-08-02

詳細の正本は 作業ログ_2026-07-27（7/27〜8/2の全作業を時系列で追記済み・v11.6.32〜48の全リリース詳細/インシデント/学びあり）。このノートは 8/2 handoff のサマリ。

19:10 - /handoff 実行（全テーマ）

このセッションで扱ったテーマ（7/27〜8/2・全部）

  1. パフォーマンス改善①〜④+第2弾（v11.6.32/37: Push化・4秒/緩和ポーリング・JS遅延1MB減・実測ビーコン） — システム作業 — 完了
  2. 未使用機能整理+D1掃除（発信ログ削除・ガイド2画面アーカイブ・旧blob計78MB掃除・解約案件アーカイブ導線） — システム作業 — 完了
  3. 架電対象の仕様変更（アポ獲得除外v11.6.33・今日架電救済廃止v11.6.34） — システム作業 — 完了
  4. 「同期中」長時間表示根治（v11.6.36 スナップLRU3案件） — システム作業 — 完了
  5. 新ロゴ反映（サイドバーv11.6.38/39・ファビコンv11.6.44） — システム作業 — 完了
  6. リストプールUX改善（バッチグループ表示・取込/分配のセグメント連動・名前順ソート v11.6.40〜42） — システム作業 — 完了
  7. 分配119,016件誤爆インシデント（41,189件巻き戻し+confirm/進捗/二重実行ガード v11.6.43） — インシデント対応 — 完了
  8. 日報バグ3件（同一文言調査→運用起因と判明+autoCalcバグ発見→v11.6.48で根治） — システム作業 — 完了
  9. Phase5 完全SalesNow化（LIST vs CRM分析→設計書→5.1完全SQL化v11.6.46→5.2常時サーバー駆動+5.3 v11.6.47） — システム作業 — 5.4計測待ちのみ残
  10. 残タスク1〜5一括（日報根治・週次perf自動報告・0件ガイド・blob掃除 v11.6.48）+データ消失検証（消失ゼロ確認） — 完了

次セッションの残タスク

  • Phase5.4: perf_logを数日蓄積→before/after比較→旧経路(全量ロード/full reconcile)の段階撤去+stats APIのUI接続（設計=scale-lead/docs/PHASE5_SalesNow化_設計.md）
  • 週次perfレポート初回投稿=月曜8:00 launchd（送信先 #ai部署 は仮・大串の希望確認）
  • 運用系: 天野さんへの分配やり直し（抽出件数指定で）／解約案件のアーカイブ操作／過去に0化された稼働時間の手動修正（少数）
  • ~~未回収: 8/2の「トップ」という一言メッセージの意図~~ → 誤字と判明（2026-08-02 大串確認）。対応不要・クローズ

大串FB・学び（このセッションの重要どころ）

  • 「時間かかっても凄い良いものを」「SalesNowくらいのスピード感・操作感で複数人操作」= Phase5の要件。操作感0ms(楽観更新)は死守
  • 巨大処理は confirm+進捗表示+二重実行ガードが無いと「無反応に見えて裏で実走」事故になる（119k分配の実例）
  • 「無い/消えた/0件」系FBはD1正本→並び順/フィルタ/表示の順で疑う（天野②・中業界0件・日報文言の3実例）
  • 検証カールのgrace cookieは24hで切れる／本番/index.htmlは308（/を見る）

19:11 - /handoff 実行（全テーマ）

このセッションで扱ったテーマ（全部）

  1. SCALE LIST 画面の作り込み — システム作業 — 本番反映済み（全21画面）
  2. SCALE LIST データの充実 — システム作業 — 本番D1へ反映済み
  3. 売上予測ロジック — システム作業＋相談 — 実装・229万社に付与
  4. ログイン認証 — システム作業 — 実装・検証済み（最重要）
  5. 企業説明文の出所調査 — 相談 — 正体が判明・実例4,759件を入手

テーマ別の詳細

1. SCALE LIST 画面の作り込み（本番反映済み）

本番 https://list.scale-group.co.jp/ ／ リポ ~/dev/scale-list（現在 v1.0.56）

直したもの
- 中業界が縦1列だった → 参考と同じ4列に。自前ラッパーが親グリッドの1カラム（248px）に収まっていたのが原因
- 件数が1,000ms超 → 119ms。絞り込みに使う industry_large / industry_mid に索引が無く、毎回503万行を数えていた
- 上部の条件チップを表示（大業界 IT ✕ ／ 中業界 受託開発 ✕ …）。器とCSSは参考のものが揃っていて、中身だけ落ちていた
- ロゴを押すと企業一覧へ戻る

作ったもの
- 企業詳細ページ /company?cn=法人番号（一覧の企業名から遷移）
- 右上メニューの先の10画面（ダッシュボード/ユーザー管理/API/その他/企業ラベル管理/拠点ラベル管理/保存条件管理/CSVダウンロード/外部連携/コメント管理）を参考の実DOM/実CSSで再現。一旦そのまま（中身をSCALE仕様に変えるのは後）
- バージョンバッジ（ヘッダー右端・案a）。SCALE CRM と同じ仕様＝最新は緑「✓ 最新」で押すと変更履歴／新版は橙「クリックで更新」で最新を取り直す。自動リロードはしない

消したもの（大串決定）
- サイドバー: 資金調達・財務・テクノロジー・拠点・部署人物・マイアカウント・ラベル（8/1の「消さずに残す」方針を変更）
- 詳細ページ: JCコード・業態・決算月・上場区分・中業界サブ・小業界・スコア類・アクティビティ・従業員推移
- 中業界サブ／小業界は「持つべき項目」から除外（充足率1.3%/1.4%）

2. SCALE LIST データの充実（本番D1反映済み）

項目 件数
収録企業 5,036,034
売上 2,396,678（102,910 → 23倍）
電話番号 177,017
企業HP 256,260
企業説明文 4,759
  • 過去に契約していた他のリストツールのCSV 5本（4,976社）を発見して取り込み（INTERMIND ほか）。法人番号を持つので誤マッチなし
  • スクショ取り込みを全項目対応に（行テキストごと保存 → 後から項目を増やしても撮り直し不要）

3. 売上予測ロジック（実装済み）

中業界 × 従業員数帯 → 売上区分の対応表。半分で学習・半分で答え合わせ:
的中 74.2% ／ ±1区分まで 98.9% ／ 外れ 1.1%

推測値には必ず sales_src='estimate' を立て、画面で「（推測）」と灰色で明示。実測と混ぜない。

4. ログイン認証（最重要・検証済み）

これが入るまで、URLを知っていれば誰でも503万社のデータを見られた（CSVも無防備）。

  • functions/_middleware.js が全リクエストを通す関門。未ログインは画面→/login、API→401
  • ログイン画面は SCALE CRM と同じUI（ダーク・角丸カード・グラデーションボタン・ロゴのみ）
  • メールアドレス（@scale-group.co.jp 必須）＋パスワードの2欄
  • 合言葉は ~/.scale_list_pass●●●●●●（Cloudflare Pages の環境変数 SCALE_LIST_PASS●●●●●●）
  • 検証済み: 未ログイン→302/401 ／ 社外メール→401 ／ 社内メール＋正しいPW→200

次の一手: Cloudflare Access（Google SSO・ドメイン限定）にすると更に堅牢。設定はZero Trustの管理画面が必要。

5. 企業説明文の出所調査（相談・決着）

参考の企業説明文は HPから作っていない（JBCCのHPに該当文言が1つも無い）。正体は:
- 「〜事業」の羅列＝参考の「小業界」欄の値そのもの
- 全体がテンプレートへの穴埋め（設立年月・所在地・小業界・大中業界）

→ 他ツールのCSVから実例4,759件が手に入ったので、生成ロジックの教師データにできる状態。

このセッション全体の大串FB

  • 中業界の配置・チェックの位置を参考と完全に揃える
  • 業界を選んだら件数がすぐ出るようにする
  • 右上メニューは一旦そのまま完全再現、後からSCALE仕様に変える
  • 企業詳細ページは案1（参考の骨格・項目だけ入れ替え）
  • 1社あたり持つべき項目にあるものだけを詳細ページに出す
  • 中業界サブ・小業界は不要
  • 従業員推移・アクティビティは不要
  • デザイン案はチャットでなく実物を作って見せる
  • サイドバーは必要なものだけ表示（データが無い項目は消す）
  • バージョンバッジはヘッダー右端・案a（枠なし）
  • ログイン画面は SCALE CRM と同じUI/UX・ロゴだけ・メアド＋PW
  • 社内メンバー以外使えないようにする

技術的な学び（再発防止）

  • "<head" not in html は <header> にマッチする。CSSリンクが1つも入らず画面が崩れた
  • 参考の詳細ページは同じ値を2箇所に持つ（片方は非表示）。1つだけ書き換えると「データは入っているのに画面は変わらない」
  • CSSを行単位で重複除去すると壊れる（@media など複数行の規則を切る）。素直に全結合する
  • version.json をエッジにキャッシュさせると新版を永久に検知できない。no-cache では不十分で no-store が要る
  • 同期スクリプトを並行実行すると互いの分割SQLを消し合う。置き場所を列ごとに分けた
  • D1は一時的な internal error を返す。1本落ちただけで止めるとと229万件は終わらない。リトライして先へ進む
  • 認証を入れると退化チェックが全項目NGになる（未ログインで302）。チェック側も先にログインさせる
  • 桁区切りのカンマをピリオドと誤読すると10倍ずれる（2,311人→311）
  • 従業員数は出所が違うと系統的にずれる（gBizINFO 900 vs 参考 1,193）。答え合わせは同じ出所同士で

19:40 - Phase5.4 計測着手（大串「残タスクでそっちがやるのあるなら進めて」）

やったこと（git 44c24b6・push済み・Actions success）

  • 比較ツール新設 scale-lead/scripts/perf_ab_compare.py: perf_log を cutoff（v11.6.45 デプロイ=2026-08-02T08:04Z）で before/after に分割し、画面別・メンバー別に 「1ビーコンあたりの longtask 回数」で正規化比較（合計回数は稼働量に比例するので判定に使えない）。worst_ms 列は誤帰属があるため page_stats JSON を正とする
  • 設計書 docs/PHASE5_SalesNow化_設計.md の Stage5.4 を実務レベルに拡張: 比較コマンド・before ベースライン確定表・計測状況・旧経路撤去の GO 条件3つを明文化
  • 週次レポート perf_weekly_report.py（launchd で本番稼働中）は触っていない（比較は別スクリプトに分離）

before ベースライン確定（2026-07-26T08:04Z〜08-02T08:04Z / 108ビーコン / 9人）

画面 1ビーコンあたり 合計 最悪
call_list 10.4回 1,123回 24.0秒
list_pool 3.3回 352回 21.6秒
list_request 0.4回 41回 70.7秒

メンバー別: 山本 10.0回/本（計1,084）／大串 4.0回/本（計430・最悪24.0秒）／金森 0.7回/本（最悪70.7秒）

判明したこと（重要）

  • after のビーコンは 0 件。8/2 の最終ビーコンは 07:40Z＝16:40 JST で、v11.6.45 のデプロイ（17:04 JST）より前。8/1〜8/2 が土日で実稼働なし
  • → Phase5 の効果測定は 8/3(月) 以降の実稼働待ちで確定。平日2〜3日で before と同等のビーコン数が積まれる見込み
  • 旧経路（clLoadRows 全量ロード / full reconcile）の撤去と stats API の UI 接続は、GO条件3つが揃うまで着手しない

GO 条件（設計書に明記）

  1. call_list の1ビーコンあたり回数が before(10.4回) 比で明確に減少 2. 最悪msが24.0秒→数秒に桁で低下 3. after 期間にデータ不整合・苦情ゼロ

学び（Phase5.4 計測）

  • after 0件を「-100%改善」と表示するツールは危険（改善と計測不能は別物）→ 「計測待ち」表示に修正。性能比較ツールは母数ゼロの扱いを最初に決める
  • 性能の before/after は稼働量で正規化しないと嘘になる（合計回数は人が使った量に比例するだけ）
  • JS等の静的ファイルは未ログイン curl だと 403（grace cookie 失効後）。ver 実バイト検証はログイン cookie が要る／フロント無変更のリリースでは ver は上がらないのが正

20:10 - SCALE LIST 残タスク一気に実装（管理画面7枚＋認証作り替え）

本番 https://list.scale-group.co.jp/ ／ v1.0.57 ／ commit 0085e7c

大串の指示（セッション途中で設計変更）

「PWは●●●●●●／メアドはy-ogushi@scale-group.co.jp／ユーザー管理でメアドとPWを登録できるようにして、登録したものだけ入れる設計に」

→ 合言葉ひとつ＋会社ドメイン → 一人ひとりにアカウントへ作り替え。
PBKDF2-HMAC-SHA256 10万回で保存（本番実測 198ms・WorkersのCPU上限に余裕）。

やったこと

  • 管理画面7枚を実データ化（ダッシュボード／ユーザー管理／企業ラベル／保存条件／CSVダウンロード履歴／外部連携／コメント定型文）＋企業詳細に社内コメント欄
  • 中身の無い3画面（API・その他・拠点ラベル）を削除
  • 売上予測に都道府県・社歴を追加（+0.5ptどまりと実測）
  • 企業説明文の生成ロジック（229,659社）
  • Cloudflare Access 導入手順書（結論＝2段階認証が要るときだけ入れる。自前ログインと二重管理になるので入れるなら自前は外す）

見つけた重大な不具合（本番で起きていた）

本番の sales_src が全件 NULL で、229万件の推測売上が実測と同じ顔で出ていた。
8/2 に「推測値は画面で（推測）と明示」と報告していたが、一度も出ていなかった。
sync_to_d1.py が値だけ送って出どころを送っていなかったのが原因。

精度の数字の取り違え

「売上予測の的中74.2%」は業界を持つ会社だけの成績だった。
売上の実データを持つ会社は100%業界も持つため、答え合わせが偏っていた。
実際に推測を付ける229万社のうち216万社は業界なし。業界を隠して測ると 62.7%（±1区分98.0%）。

学び（横展開すべきもの）

  1. 値と出どころ(_src)は必ずセットで送る — 片方だけだと「明示している」つもりが本番で効かない
  2. 精度は「実際に適用する母集団」で測る — 答え合わせに使えるデータが偏っていないか毎回疑う
  3. 位置で消すCSS（nth-child）は器を限定する — table th:nth-child(5) が後から足した管理画面の表も壊した
  4. 本番D1に無い列をSELECTするとAPIごと落ちる（error 1101）— 列を足してからコードに入れる
  5. Cloudflare Pages は知らないパスにトップを200で返す（404にならない）— 消したことの確認はHTTPでなく中身で
  6. エッジキャッシュは Cache-Control: no-cache でもHTMLを持つ — 消えたかの確認は必ずクエリ付きで

20:45 - SCALE CRM v11.6.49: 案件切替後のフリーズ根治（大串FB・本番LIVE・git 0ea79ed）

大串FB: 「案件切り替えてからフリーズの時間が長い」（架電リスト4,481件のスクショ付き）

真因 — Phase5で表示は速くなったが、切替の瞬間に旧経路が丸ごと上乗せで残っていた

  1. 【主因】!_clHasCache で return する旧ガードが生存。キャッシュが無い案件は「全量ロード(数MB)が終わるまで画面を一切描画しない」。表示はサーバークエリ200行で即出せるのに、スナップLRU(直近3案件・v11.6.36)から外れた案件を開くと必ず数秒〜十数秒の空白になっていた
  2. 全量ロード（数MBのDL + 全行 JSON.parse + snapMap の全行 stringify）が案件切替と同期で実行
  3. 完了後に renderCallList() を再実行 = ページ全体の innerHTML 再構築 + 2回目の /calls/query
  4. _clSaveSnapshot が localStorage へ数MBを同期書き込み（その間ブラウザが止まる）

修正（v11.6.49・4点）

  1. サーバー駆動時は _cache が空でも待たずに即描画（従来モードは不変）
  2. 全量ロードを _clIdle（requestIdleCallback / fallback setTimeout）でアイドルへ退避
  3. 完了後の再描画を _clRefreshHeaderCounts()（ヘッダー件数＋ゴミ箱件数だけ更新）に置換 → サーバークエリが切替1回あたり2回→1回
  4. スナップ保存もアイドルへ
  • 互換: 表示/編集/集計の結果は不変（レポート・日報の互換維持）。キルスイッチ sb_cl_server_off='1' で全経路従来動作
  • 検証: node --check OK ／ min ビルド反映確認（_clIdle/_clRefreshHeaderCounts/clHdrCount）／本番200・index.html が新 v=202608022041 を配信

学び

  • 新方式へ移行するときは「旧方式の待ちガード」を必ず一緒に外す。表示経路だけ速くしても return で待つコードが残っていれば体感は改善しない（むしろ新旧が上乗せで遅くなる）
  • 体感フリーズ＝CPUブロックとは限らない。perf_log の longtask は 298/441ms（before最悪24秒より桁で小さい）のに体感は悪化＝正体は「画面が出るまでの空白」だった。longtask だけ見ていたら見落とす
  • 移行期は「新経路 + 旧経路の並走」が最も重くなる。並走させるなら旧経路は必ずアイドル/オンデマンドへ落とす