⚙️ Vault運用

2026-07-06_作業ログ

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

作業ログ 2026-07-06

SCALE CRM v11.6.3 — 性能残課題の洗い出し第2弾＋全部実装（同日完結・本番LIVE）

大串指示

  1. 「SCALE CRMが重い原因で対処しきれてないことないか洗い出して。超高品質なCRMにしたい。架電はひたすら数こなすからちょっとのラグが凄いストレス」
  2. 洗い出し提示後「全部実装して欲しい。完璧に超スピード感もった完璧なツールにして欲しい」

やったこと

  • 洗い出し: 3並列調査（描画操作系/データ層起動同期/配信サーバ側）→ 31_システム開発部/_SCALE_CRM_リスト性能_残課題洗い出し_第2弾
  • 実装（v11.6.3・本番LIVE・実バイト検証済み）:
  • パック① 計算O(n)撲滅（getLatestCallStメモ化/filterCLソート事前計算/統計500msメモ化+編集経路無効化/migrateV3案件別スキップ）
  • パック② 配信（版付き9ファイルimmutable 1年キャッシュ・preloadをcore+lib_bundleへ）
  • パック③ 帯域（/api/calls?digest=1 新設→120秒full reconcileはdigest一致で全件DLスキップ・連続15回上限で保険維持）
  • パック④ D1掃除（旧chunked blob 36キー15.73MB削除・dump=~/scale-lead-backups/chunked_blob_dump/dump_2026-07-06.json・DB 653.7→633.6MB）
  • D2 query.ts 1次絞り強化（c_latest_status整合を本番実測で確認の上、上位集合保証SQLプレフィルタ）
  • 見送り（理由付き・詳細は第2弾ノート）: _routes.json（認証保護が外れる）/ フル遅延ロード（RマップReferenceErrorリスク）/ B4起動並列化・C2ページング（Phase4とセット）
  • スタートカード（リポCLAUDE.md）のデプロイ記載を現在地に同期（GitHub Actions設定済み・実バイト検証ルール）

重要な実測

  • 最大案件mnpg72=現役14,900行（6/24の6,134行から2.4倍に成長中）
  • Cloudflare Pages _headers は同名ヘッダを「結合」（上書きでない）→「! Cache-Control」で取消してから設定（本番実測で発見・学びストックに記録）

デプロイ・検証

  • deploy.sh（pre/post tar.gz）＋ git push（c5ea569, 7ae540d）
  • 本番実バイト検証: index.html ver / core.min.js のCL-FULL-SKIP / immutableヘッダ / service.min.js のv11.6.3 / digest API実動作 / CF canonical一致 — 全部OK
  • 緊急フォールバック: 仮想スクロール=window._clVirtualOn=false / digestスキップは15回上限で自動的に本物fullへ

メンバー実機確認待ち

  • 架電リストの操作感（プリセット/ソート/タブ切替・ステータス連続入力のラグ）
  • 2回目以降のページ表示速度（immutableキャッシュ）
  • [CL-FULL-SKIP] ログがコンソールに出るか（digest スキップの実効）

SCALE CRM v11.6.4 — AI共創+LinkedIn支援の削除（大串指示・本番LIVE）

大串指示

「いらない機能とかシステムは排除した方が軽くなる？」→ 効果整理を提示 →「AI共創系は使わないから削除でOK。LinkedIn支援ももうしないから削除で良いね」

やったこと

  • 削除: AI共創3ファイル+LinkedIn全ページ（計447KB・minify後222KB）+全導線（サービス概要共創ボタン/要確認操作ボタン/スクリプト共創/メールAI生成/LinkedInナビ+ルーティング5エントリ）
  • 移植: バージョン履歴表示（showCoCreateVersionHistory）→ service.js（verバッジクリックは従来どおり動く）
  • 温存（理由付き）: サービス概要ページ本体（架電のトーク前提を見る業務ページ）/ ai.js（共通AIエンジン＝切り返しAI生成・アポメタ・オンボーディングが使用中）/ kickoff.js（実体はオンボーディング）/ 案件channel概念（channel:linkedin案件1件実在）/ D1の全データ（無削除＝gitから実装を戻せば完全復元）
  • 安全確認: 削除4ファイルの提供シンボル182個への外部参照を全数機械チェック→ガード無し参照を全て導線ごと削除。pendingデータ0を本番実測。_ymdLocalはcore.jsに既存定義あり
  • deploy.sh の必須関数チェックが正しく発動（AI共創関数が必須リストに残っていた）→ リストをv11.6.4状態に同期して再デプロイ
  • 効果: 配信JS 2.08MB→1.86MB（-220KB）。本番実バイト検証（MD5一致・アプリ表示v11.6.4・canonical一致）済み
  • commit: 3544918（scale-group-jp/scale-lead）・削除前バックアップ ~/scale-lead-backups/scale-lead_pre-v11.6.4-removal_*.tar.gz

SCALE CRM v11.6.5 — 架電体感の目玉3本（方向①全部実装・本番LIVE）

大串指示

「方向①: 架電体感の『目玉機能』はすべて実装して欲しい」（外販強化ロードマップ候補より）

実装3本

  1. ⚡連続架電モード（キーボード完結・新機能）: 架電リスト右上「⚡連続架電」→ 表示中リストの「今日未架電・空きスロットあり」行を上から順にパネル表示。数字キー1-9,0=ステータス / Enter=保存して次へ / M=メモ(Cmd+Enter保存) / S=スキップ / Esc=終了。進捗i/N表示。保存は既存経路を完全再利用（軽=saveQuickResult / アポ獲得等=必須項目モーダル→Slack通知は既存の完全データ保証のまま・保存後自動で次へ）
  2. 初回ロード4並列チャンク化: digestでrowid範囲取得→4等分並列DL→rowid順連結。DL時間1/3〜1/4。本番実証=4チャンク合計14,900件=digest完全一致。失敗/小規模(2千行未満)は従来単発へ自動フォールバック
  3. Phase4整合テスト完了: 本番14,900行の実データで、クライアント述語(Node実行)と本番query.tsを19ケース機械照合→不一致0（全preset+st/cp/sg/q/複合+early-return検証）。数十万行到達時に window._clServerMode=true で即切替可能な状態に。既定OFF維持（現規模はクライアント側が最速）

デプロイ・検証

  • bash deploy.sh（pre/post tar.gz）・commit 78d2d83・アプリ表示ver v11.6.5 実バイト確認・digest lo/hi実API確認
  • 実機確認ポイント: ⚡連続架電ボタン→数字キー入力→Enterで次の会社に進むか / リロード時コンソールに [LOAD v11.6.5] parallel OK が出るか

SCALE CRM v11.6.6 — Slack通知のPMメンション4系統（本番LIVE）

大串指示

「Slack通知にPMメンションをちゃんと付けたい。アポ報告・架電報告・作業報告・リスト依頼、全部。架電報告と作業報告はスレ型だからタイトルにはメンション無し・中身のメッセージに付ける」

実装（方針転換の記録が重要）

  • v9.173/174「メンションは全部なしで」で過去に全廃した機能を、大串指示で復活。以後この4系統はメンション有りが正（コメントに転換履歴を明記済み）
  • ①アポ報告=冒頭に獲得者+PM+大串 ②架電報告スレ=親無変更・スレ内メッセージにPM+大串 ③作業報告スレ=稼働開始/中断報告にPM+大串（稼働終了日報はv11.5.46で実装済み） ④リスト依頼=冒頭にPM+大串
  • 既存の _slackBuildMentions（失注/日報で実績・slackUserId未登録は自動スキップ・重複排除）を全系統で再利用
  • 本番実測: slackUserIdは実質全員登録済み（未登録=デモのみ）・PM=大串/細川 → 即日機能
  • commit 4f47ffc・アプリ表示ver v11.6.6 実バイト確認済み（minify後の構造でメンション連結を確認）

実機確認ポイント（実際のSlack通知は実運用の操作で発火）

  • 架電でステータス変更 → 架電報告スレの新メッセージに @大串 @細川 が付くか（親タイトルには付かないか）
  • アポ獲得 → アポ報告チャンネルの投稿冒頭にメンションが付くか
  • リスト依頼作成 → 依頼投稿冒頭にメンションが付くか