作業ログ 2026-08-05

SCALE CRM v11.6.59 〜 61（大串FB連続対応・全て本番LIVE）

v11.6.59（git 4ea4bd8）表示崩れ・Slack文面・再架電通知

1. 横スクロールで列が重なる問題 — 真因は自分が v11.6.51 で入れたホバー色が半透明だったこと。左固定列（チェック/#/企業名/電話番号）は元々不透明な背景で下を通る列を隠していたのに、rgba(59,130,246,.13) で上書きしたため透けて多重に見えた → 合成後と同等の不透明色 #182234 に変更。選択行は cl-row-sel クラスを付けて #22304d で選択色を維持
2. Slack文面: 「SCALEランク：S（トップ）」「D（要改善）」の評価文言を削除（大串「Dで要改善とか出るの失礼」）
3. Slack文面: 「通電：3（17.6%）」の括弧内の率を削除（直下に通電率行があり重複）
4. 再架電アラーム廃止: 30秒監視と boot 直後実行を停止（使用者ゼロ）。関数・カード描画は残置＝2行戻せば復活。日時の入力/列表示は記録として維持

v11.6.60（git 9be139f）再架電フィルタ刷新＋メモ追記式

• 「本日再架電」→「再架電」: ①recallDate あり ②callPerson === currentUser（自分の担当のみ・未割当除外）③最新架電日 < recallDate（設定日以降に架電済み＝対応済みは出さない）。過去・今日・未来すべて表示（大串指示で未来も含めた）
• クライアント _clRowPasses とサーバー query.ts（rowPasses + SQL）を1:1実装。early リスト2箇所に登録（has_recall が v11.6.55 で片方漏れていたのも同時修正）
• 架電後メモを追記式に: 従来は c.memo を丸ごと上書き。入力欄は毎回まっさら（v9.184）のため、1社に複数回架電すると前回のメモが消えて最後の1回分しか残らなかった → 「【MM/DD ステータス】本文」を先頭に積む方式へ
• talkScript / apoKnowledge は別物として独立のまま（大串判断）

v11.6.61（git 3b41d70） ステータスが反映されない／保存が消える の根治【最重要】

• 真因: _clServerBridgeRows に保存直後ガードが無かった。保存は非同期（diffPush）なので押した直後はサーバー未反映の瞬間がある。そこへポーリング/Push/フィルタ変更でサーバー行が返ると _cache を古い値で上書き → 画面が押す前に戻る
• さらに prevSnap まで古い値で更新されるため diffPush が差分を検出できず 保存そのものが消える危険もあった（v11.6.45 のブリッジ導入以降ずっと）
• 修正: _clPending[pid][callId] がある行（D1へ未確定）と、_statusJustSavedAt から8秒以内の行はサーバー値で上書きしない。他メンバーの変更は従来どおり反映
• 「勝手に上下に飛ぶ」も同じ真因の可能性が高い（ステータスが戻る→フィルタ条件が変わる→行が移動）

画面収録(185秒)の解析

• ffmpeg のシーン検出 → 10箇所の変化点を抽出 → 121秒（最大変化0.29）と128秒（モーダル閉じ）を詳細比較
• 確認できたこと: モーダルを閉じた後の表示位置は保持されている（v11.6.50/60 の効果）／行の文字重なりは横スクロール由来（v11.6.59 で修正済み）
• 「反映されない」は動画では瞬間を捉えられず、コード側から真因を特定して v11.6.61 で根治

企業モーダルのデザイン案（大串依頼・実物HTMLで提出）

• 現状: 約37個の入力欄が縦一列、うち15個が架電①〜⑤の枠（ほぼ空）。「見る」より「編集する」画面になっている
• 3案を実物HTMLで作成（~/Downloads/SCALE_CRM_企業モーダル_デザイン案.html）:
• 案A カルテ型: 上部に社名・電話・最新状況を大きく／下は左=企業情報・右=架電履歴タイムライン
• 案B 2カラム型: 左に企業情報を固定（スクロールしない）・右を履歴＋メモの作業領域に
• 案C 一覧密集型: 4列グリッドで1画面に全部・スクロールほぼゼロ
• 削除/集約の提案: スクリプト（残骸）・アポ獲得日/獲得者（自動入力）・架電時間帯①〜⑤（自動セット）は削除／失注理由・再架電日・商談日・商談URLはステータスモーダルと重複のため履歴へ集約／架電①〜⑤の空欄5組は実際の回数ぶんだけ行表示 → 37項目 → 実質15前後
• 大串の選択待ち（案が決まり次第 実装）

学び

• 自分が入れた修正が次の不具合を生むことがある。v11.6.51（固定列にホバー色を乗せる）→ 半透明だったため v11.6.59 で「列が透ける」を生んだ。色を上書きするときは不透明かどうかを必ず確認する（sticky 要素の背景は「下を隠す」役割を持つ）
• 「押しても反映されない」は楽観更新とサーバー同期の競合を最初に疑う。UI側ではなくデータ層（ブリッジ）に原因があった。しかも prevSnap まで潰すため「保存が消える」という更に重い症状を内包していた
• 上書き系の関数を書くときは「未確定の変更を持つ行を除外する」をセットで設計する（v11.6.31 分配・v11.6.54 CSV取込に続き3例目）

12:17 - /handoff 実行（全テーマ）

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

1. 案件切替後のフリーズ根治（v11.6.49） — システム作業 — 完了
2. アポ取り消しの調査＋残骸クリア（v11.6.50 C） — 調査+システム作業 — 完了
3. 画面収録①の解析 → 操作品質根治 A/B/C（v11.6.50） — システム作業 — 完了
4. ステータス変更モーダル（D）の扱い — 相談 — 現状維持で決定
5. 使い勝手3点＋ファビコン透過（v11.6.51 / 52） — システム作業 — 完了
6. 読み込み速度の調査 → boot 76%削減＋先出し（v11.6.53） — 調査+システム作業 — 完了（先出しは後で撤回）
7. 同種問題の横断洗い出し → 3つの穴を塞ぐ（v11.6.54） — 調査+システム作業 — 完了
8. B-3 全期間走査画面の取りこぼし根治（v11.6.55） — システム作業 — 完了
9. 先出しの撤回＋起動失敗の自動記録（v11.6.56） — システム作業 — 完了
10. 起動時「読み込み中」の根治（v11.6.57） — システム作業 — 完了（全員が毎回踏んでいた ReferenceError）
11. Slack投稿失敗の記録＋稼働時間の矛盾警告（v11.6.58） — システム作業 — 完了
12. 横スクロール列重なり・Slack文面・再架電通知廃止（v11.6.59） — システム作業 — 完了
13. 再架電フィルタ刷新＋メモ追記式（v11.6.60） — システム作業 — 完了
14. ステータスが反映されない/保存が消える の根治（v11.6.61） — システム作業 — 完了
15. 性能計測のノイズ除外（v11.6.62） — システム作業 — 完了
16. 企業モーダルをカルテ型に刷新（v11.6.63・案A採用） — システム作業 — 完了
17. Phase5.4 before/after 比較 — 調査 — 実行済み・旧経路撤去は保留
18. 山本さんの稼働開始がSlackに出ない件 — 調査 — 原因未確定（記録の仕組みを設置済み）

Phase5.4 比較結果（2026-08-05 実測・cutoff=8/2 08:04Z）

• 旧経路（clLoadRows全量ロード/full reconcile）の撤去は保留（GO条件2/3が未達）
• 最悪1518秒はPCスリープ由来のノイズと判明 → v11.6.62 で60秒超を計測対象から除外
• boot_ms 悪化は v11.6.57 の ReferenceError が原因の可能性が高い（after期間の大半で毎回 renderPage が失敗していた）→ 8/6以降の再計測で確認

次にやること（優先順）

1. phone_support_list の悪化調査（細川さん 2.8回/本・実フリーズ）
2. boot_ms の再計測（v11.6.57 の効果を確認）
3. 企業モーダル: スクリプト／アポ獲得日・獲得者を編集フォームからも消すかの判断待ち
4. Phase5.4 旧経路撤去（1・2が解消してから）
5. 週次perfレポートの送信先チャンネル確認（#ai部署 は仮のまま）
6. 運用系: 天野さんへの分配やり直し／解約案件のアーカイブ／稼働時間0化の手動修正

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

• 「画面が一瞬切り替わったり他の行にいったりカクってしたり。こういうところが品質悪いって感じる所以」
• ステータス変更モーダル（D）は現状維持でいい
• 担当者の自動変更トーストはどんなときも出さない
• Slackの「D（要改善）」等の評価文言は失礼なので出さない
• 再架電フィルタは自分の担当のみ・未来も含める
• 架電後メモは追記式（日付＋ステータス付き）。トーク／ナレッジは別物として独立のまま
• 企業モーダルは案A カルテ型

12:17 - /handoff 実行（全テーマ）

本番 https://list.scale-group.co.jp/ ／ v1.0.93 ／ commit 0c8bf96 ／
退化チェック全項目クリア ／ 未コミット差分なし

このセッションで扱ったテーマ（全部・すべて SCALE LIST）

データの現在地（本番）

このセッションで踏んだ罠（再発防止）

• 同じ塊が2つあり、片方は display:none。 1つ目で return すると隠れている方を消して
  画面が変わらない。社名・説明文・移転履歴・事業タグで4回踏んだ。全部消す
• 消す器を1つ間違えると巻き込む。 企業情報・業界・事業タグ・移転履歴は同じ箱。
  セクションごと消したら企業情報の表まで消えた。巻き込みたくないものの手前で止める
• 座標で要素を探すな。 「…」を座標で探してヘッダーの通知とアカウントまで消した（3回目）
• 伏せ字を # に置換するのは無害化ではない。 # は自分自身を指すので
  iframe src="#" はページが自分自身を中に読み込む（詳細ページの「謎のゾーン」の正体）
• デプロイ直後にページを開かない。 HTMLが新しい ?v= を指したのを見ただけで開くと、
  エッジがまだ古いJSを返している間にブラウザが新URLで古い中身を1年キャッシュする。
  掴み直しは fetch(url, {cache:'reload'}) → リロード
• 索引の名前はDB全体で1つ。 「別名で作って最後に入れ替える」方式で入れ替え前に
  索引を作ると2回目以降が必ず失敗する。落として入れ替えてから作る
• 完了待ちのループが自分自身を検知して永久に待った（pgrep は自分にも一致する）
• ハッシュ形式（hex/base64）を取り違えて全員を締め出しかけた。
  ログイン周りは壊れても画面上は何も起きないので、通ることを確かめてから反映
• 画面に鍵を付けたらAPIも塞ぐ。 付けた直後 /api/analytics と
  /api/admin/users(GET) が200を返していた（誰が登録されているか読めた）。
  一般権限のアカウントで叩いて確かめる
• 「持っていない」と言う前に取り込み済みのテーブルを数える。
  「部署別メール・FAX・SNSは1件も無い」は誤りで、載せていなかっただけだった
• 歩留まりは無作為抽出で測る。 連絡先が多い順で選ぶと上振れする
• 設定ファイルのせいだと決めつけない。 監視17画面NGの真因は
  点検用アカウントが本番から消えていたこと。ログインAPIの応答とusersテーブルを先に見る

このセッションの大串FB・判断

• オリジナル化の基準＝コードの順序と参考システム名が入っていなければよい
• 全員共通パスワード ●●●●●●。メアド登録だけで入れる
• 企業詳細の値の文字は案1（18px / 700）
• 連絡先・除外は色以外は参考と全く同じに
• 見出しの並び替えは効く列だけ（残りは矢印を消す）
• CRM導線はメニュー先頭＋リスト追加直後の2箇所
• メニューの鍵はユーザー管理とダッシュボード
• 削除: ベル／人マークの中のユーザー管理／アクティビティ／コメント管理／外部連携／
  企業検索タブ／本社所在地のフリーワード／検索窓のJCコード／ラベルを編集／共有／
  Powered by AI／自動生成の注記／事業タグ／本社住所移転履歴／この会社に付いている印／
  連絡先の充実度／コメント一括登録／ラベル一括編集

判断待ち（唯一の残タスク）

消費数を「行単位」で追うか。
いまは案件単位で数えているため、CRM に元からある行（現在 24,857行・架電済み2,819行）も
一緒に数えてしまい、消化率が当てにならない（100%超もあり得る）。
直すには「どの追加で・どの電話番号を入れたか」を控え、その番号だけを突き合わせる。
作業量1〜2時間・既存データは壊さない。
まだSCALE LISTから1件も入れていないので、いま直せば最初から正確。
やらない場合でも、追加数・業界別・従業員数別は正確に使える。

12:30 追記 — 残タスクの判断（消費数）

大串「メンバーごとの消費量は入れない方向性でいいや」。
→ 消費数（架電された数・消化率）は出さないことにして、CRMを読む処理ごと削除。
案件単位でしか突き合わせられず、その案件に元からあった行（24,857行・架電済み2,819行）
まで数えてしまうため、消化率が当てにならなかった。
当てにならない数字を出すくらいなら出さない。

ダッシュボードの分析に残るのは「メンバー別（作った回数・追加した数）」
「業界別・従業員数別・都道府県別・案件別」。どれも SCALE LIST が確かに持っている事実だけ。

鍵を付けた副作用で監視が落ちた。 点検用アカウント（一般権限）が
/api/stats を読めなくなっていた。点検用は全体を見張る役なので管理権限にした。
権限を絞ったら、その権限で動いている自動処理がないか確かめる。

左ナビに外部連携・コメント管理が残っていて押すと404だったので外した。

本番 v1.0.94 ／ commit 114c585 ／ 退化チェック全項目クリア ／ 未コミット差分なし
残タスクなし。