⚙️ Vault運用

作業ログ_2026-06-25

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

作業ログ 2026-06-25

15:57〜16:10 - SCALE CRM v11.5.99 架電リスト仮想スクロール化（性能本丸①/全4・本番LIVE・実機確認待ち）

対象

SCALE CRM（scale-lead / crm.scale-group.co.jp / 正本 ~/株式会社SCALE/scale-lead/）。本番 v=202606251609 / アプリ v11.5.99。

背景（大串FB）

「リストが重くて開けないクレーム。HubSpotは大量データでもスムーズ。差を洗い出して」→ 6/24に洗い出し（_SCALE_CRM_リスト性能_根本原因とHubSpot対比.md）。本日「全部完璧な状態にしたいから順番にすべて実装して欲しい」→ 本丸4つを順次実装開始。

本丸4つ（順番に実装）

  1. 仮想スクロール（描画O(1)化）← 本日デプロイ・実機確認待ち
  2. サーバーサイドページング（取得O(1)化）← ①OK後
  3. サーバー側で検索/絞り込み/ソート ← ②と同時
  4. 旧chunked blob 7.92MB掃除 ← 独立・安全

① 仮想スクロール（v11.5.99）

  • 真因: 最大案件6,134行×20列＝約12万DOM要素を全行生成→ブラウザのレイアウト/メモリが行数比例で限界＝「開けない」主因。HubSpotが速いのは「見える分だけ描く」O(1)設計。
  • 対策: _clRenderRows/_clVirtualRender 新設。フィルタ・ソート済み全件はメモリ（window._clVRows）保持のまま、DOMは可視範囲+上下バッファ14行のみ。上下スペーサー行（tr.cl-vspacer・CSS height:auto）で全行ぶんのスクロール高を再現。120件超で自動有効（以下は従来描画で挙動不変）。scrollはrAFスロットル。
  • 既存機能整合: 選択（_clSelectedIdsグローバル参照）/sticky固定列/インライン編集（_clEditingActiveで編集中は再描画抑止＝input値が飛ばない・clInlineEditでtrue/clInlineSave冒頭でfalse）/同期（_clTryAppendRowは仮想時デバウンスfilterCL再実行）/行高さ初回実測補正。
  • 安全策: window._clVirtualOn=false で従来の一括描画へ即フォールバック。例外時も自動フォールバック。データ層（filterCL/_cache/per-row同期）一切不変＝退化なし。

編集ファイル

  • lib/calllist_core.js（レンダラ群追加 + filterCL描画を_clRenderRowsに置換 + _clTryAppendRow仮想対応 + clInlineEdit/clInlineSaveに編集フラグ）
  • style.css（#clTB tr.cl-vspacer）/ service.js（COCREATE_VERSIONS v11.5.99）

デプロイ・検証

  • bash deploy.sh（直接prod）。全59関数OK・minify・pre/postバックアップ・本番200・D1正常。
  • backup: scale-lead-2026-06-25-1609-pre-deploy.tar.gz / -1610-post-deploy.tar.gz
  • 本番実体検証: lib_bundle.min.js に _clVirtualRender×5 / _clRenderRows×2 / _clEditingActive×3 / cl-vspacer×3 / _clVRows×4。service.min.js に v11.5.99。

HubSpot/Salesforce体制移行（大串FB「同じ体制で」）— Phase 1 完了

①実機OK（大串「一旦大丈夫そう。俺が触った感じ」）後、大串「やれることは全部やって100点・HubSpotやSalesforceと同じ体制で」→ サーバー駆動＋DB索引の本格CRM基盤へ4フェーズ移行開始。
- Phase 1 完了（本番D1）: call_rows に generated VIRTUAL column 7個＋index 6本。EXPLAIN QUERY PLAN で USING INDEX 実証。データ無変更・退化ゼロ。
- Phase 2 完了（latest_status索引化）: c_latest_status（STATUS_PRIORITY argmax式10,903字・getLatestCallStをSQLで完全再現）＋index。照合400行で不一致0＝クライアントgetLatestCallStと完全一致。
- Phase 3 完了（サーバークエリAPI）: functions/api/calls/query.ts 新規。_clRowPasses/getLatestCallSt/getDormantDays/_clQMatch/STATUS_PRIORITY をverbatim移植（退化防止の肝）。index1次絞り→JS2次絞り→ソート→LIMIT/OFFSET。_clIsRecentlyEditedはrecentIds配列で引き継ぎ。認証付き実件数テストで preset無し=5043 / apo=2 / cp=内藤=2074 全てD1完全一致・無認証403でgate確認。既存クライアント無変更＝退化ゼロ。
- Phase 4 完了（v11.6.0・本番反映・既定OFF）: クライアントをサーバー駆動。filterCL冒頭に分岐→_clServerQuery→/api/calls/query→可視範囲200行取得→_clServerRender（仮想描画）→スクロール追従query（debounce）。window._clServerModeフラグ・既定OFF＝現規模6千行は①仮想スクロール維持（退化ゼロ・filterCL分岐はOFF時素通り）。将来数十万行で window._clServerMode=true。本番lib_bundleに_clServerQuery×6反映確認・query API 403 gate生存。
- ON時の残課題（実ONで詰める）: 編集/同期poll/統計/bulkBarの完全整合（基本骨格=表示サーバー駆動まで）。フィルタ述語はquery.tsと_clRowPassesの2重メンテ。
- = HubSpot/Salesforce体制 Phase1-4 全実装完了。配管は全部通った。現規模は①、蛇口（serverMode）は将来開ける。
- ロールバック: DROP INDEX idx_cr_proj_*（6）＋ ALTER TABLE call_rows DROP COLUMN c_*（7）。既存未使用で無害。
- ④旧blob掃除は中止：厳密確認で現役データと判明（_putLargeWithChunksの正常chunked保存・起動時に_initSupabaseが_cacheへ復元）。削除すると壊れる。洗い出し時の「7.92MBゴミ」判定は誤りと訂正。

重要な技術判断

  • 現規模（最大6,534行/有効5,043）では①で体感解決済み。Phase 2-4 は数十万行スケールへの布石（大串の長期視点）。
  • ①＝一度取得→以後ローカルで一瞬／サーバー駆動＝操作のたび往復。数十万行未満では①が速い→Phase 4の本番ONは規模が増えてから（フラグ段階）。

注意・退化リスク

  • 仮想スクロールは window._clVirtualOn=false で即フォールバック可。メンバー実使用の声で最終確認。
  • Phase 4 は退化リスク最大（フィルタ10次元＋クライアント状態_clIsRecentlyEdited＋ソート＋ページングをサーバー駆動化）→ テスト環境/フラグ限定で検証してから本番ON。
  • 本番D1スキーマを変更した（generated column＋index）→ 基準点 hubspot_migration とロールバック手順を記録済み。

12:02 - /handoff 実行

対象システム

TERASU CRM（terasu-mgmt / 本番 crm.terasu.scale-group.co.jp）。正本は本日 ~/dev/terasu-mgmt へ移行（GitHubリポ scale-group-jp/terasu-crm）。

セッション背景

「TERASU CRMの開発の続き」から開始。状況把握→GitHub連携移行→残タスク棚卸し→A/B/D一括実装→紹介アポバグ(SL SALON)の真因解決→更新通知「クリックで更新」復活、まで一気通し。

完了タスク（詳細）

  1. GitHub Actions 自動デプロイ移行: 正本を Drive(~/株式会社SCALE/hp/terasu)→~/dev/terasu-mgmt へ移動。GitHubリポ scale-group-jp/terasu-crm 作成。.github/workflows/deploy.yml(terasu-hp型・ビルド不要)。平文secret(AUTH_SECRET/FORM_INTAKE_TOKEN)を wrangler.toml から除去→CF project環境変数Secret＋ローカル.dev.vars。repo secret ●●●●●● 登録。旧Drive正本は凍結マーカー設置。今後は git push origin main で約40秒自動デプロイ。
  2. 残タスク棚卸し: 5並列調査でA(バグ)/B(データ安全性5)/C(機能7)/D(掃除5)/E(大串アクション)に整理→ Vault _SCALE_TERASU_CRM_残タスク一覧.md 新規作成。
  3. A/B/D 実装(v3.0.326): A1紹介アポバグ4経路防御修正 / B1 client portal CAS化 / B2 監査ログD1共有化 / B4 3-wayマージ後勝ち改善 / B5 差分ポーリングsinceマージン / D1 checkout@v5 / D2 lens死にコード削除 / D3 設計書3点superseded / D4 行レベル化方針確定。
  4. A1真因の特定と解決(v3.0.327→328): 大串実機で「アポ獲得リストにあるのに商談管理に乗らない(SL SALON/建設業)」。診断トレース(window._lastDealSync)を仕込み→コンソールで ReferenceError: _nowISO is not defined を確認＝真因。_dealSyncFromSources新規作成パスの createdAt:_nowISO()(未定義・v3.0.319一本化時混入)を new Date().toISOString() に修正。大串実機で SL SALON/建設業が商談管理に出ることを確認(商談数15→17)。診断トレース除去・company空補完は維持。
  5. 更新通知「クリックで更新」復活＋自動化(v3.0.329): 新版検知(_checkAppVersion)が index.htmlの core.js?v= 変化を見るが、?v=20260624a固定で検知できず「✓最新」のままだった。deploy.yml の sed で ?v= をデプロイ時に commit SHA へ自動置換。毎デプロイで「クリックで更新」が必ず出る(手動?v=更新不要)。本番で ?v=c2bb9d80 に統一確認。

編集ファイル（~/dev/terasu-mgmt）

  • lib/referrals.js - A1: _rfSyncDealOnStatus追加(status変更時に商談管理へ即連携)
  • lib/appointments.js - A1: _apoDelRow確認文をrf/sc(ライブソース)別に
  • lib/deals.js - A1: _nowISO→new Date().toISOString()修正・company空補完・診断トレース(後に除去)
  • core.js - B2(監査ログD1化) / B4(_mergeValue) / B5(_pollSince)
  • functions/api/client/data.ts - B1: CAS+rev加算化
  • functions/api/data/[key].ts - B1コメント
  • .github/workflows/deploy.yml - D1(checkout@v5) + ?v=自動cache-bust
  • index.html / client_index.html - キャッシュバスター
  • lib/manual.js - changelog(v3.0.326→329)
  • 削除: lib/lens_integration.js(D2)

デプロイ・バックアップ

  • backup: ~/terasu-backups/terasu_2026-06-25_pre-github-migration.tar.gz / _pre-ABD-batch.tar.gz
  • GitHub Actions 自動デプロイ(複数回)・全成功
  • 本番 v3.0.329 / ?v=c2bb9d80 / トップ200・auth/me 200・form-intake 401
  • 主要commit: c184efe(初回) c50d1cd(A/B/D) 0aed027(構文エラー※) d288c59(hotfix) c2bb9d8(更新通知)

試したこと・学び

  • A1は当初「status変更時トリガー」だけ実装したが、既存アポ(SL SALON)は救えず。診断トレースで真因(_nowISO)を一発特定できた＝トラブルシューティング集の「トレーサ仕込み→ログ収集→真因特定」が有効。
  • やらかし: changelog(manual.js body_markdown=テンプレートリテラル)にバッククォートを入れて構文エラーを一度push(0aed027)。即hotfix(d288c59)で復旧。&&で構文OK時のみpushする運用と、バッククォート禁止を reference_terasu_changelog_no_backtick に記録。

ユーザーFB（重要）

  • 「他システムと同じようにgithub連携してできるように」→ 実装完了
  • リポ名は terasu-crm を選択(CF project名はterasu-mgmtのまま)
  • 「①入ってないね アポカクトクリストにはあるけど商談管理には連携されてない」→ 真因_nowISO修正で解決
  • 「前まではクリック更新ってボタンで出る仕様だったのに復活させて」→ 復活＋自動化完了
  • 「SLサロンは出てきた！ハイパーリロードしたら」→ 解決確認

注意ポイント・退化リスク

  • TERASU CRM正本は ~/dev/terasu-mgmt（旧Drive ~/株式会社SCALE/hp/terasu は凍結・触らない）
  • changelog(manual.js)にバッククォート禁止(構文エラーで本番全壊)。デプロイ前 node --check lib/manual.js を必ず通す
  • core.js のデータ層(D/S/PD/PS/楽観ロック)は保護資産・Read→Edit厳守
  • ver=changelog bullet数(Python実測)・デプロイ報告で実測ver明記

次のセッションで取り得る選択肢

  1. B3: 複数人同時編集の本番実地テスト(2ブラウザ・大串/担当アクション)の結果反映
  2. C群(要判断): C2外部連携モックの実装/休眠・C3パートナーページ配線・C4 SCALE Baseタスク移植の要否・C5 FS部署タスク など(着手前に方針確認)
  3. C1 月次レポートのクライアント向け運用報告(解約防止)・C6 業界AI推定・C7 GA4連携

引き継ぎファイル

/tmp/handoff_20260625_120241.txt

14:59 - /handoff 実行（TERASU公式HP スマホ最適化）

対象システム

TERASU公式HP（~/dev/terasu-hp / GitHub: scale-group-jp/terasu-hp / 本番 terasu.scale-group.co.jp / preview preview.scale-hp-showcase.pages.dev）

セッション背景

TERASU公式HPのスマホ版(SP)最適化を大串の実機FBを受けて多数バッチで実施。改行タイミング・文言・レイアウト(特にCONTACT)・ローディング中央化など。全部 preview ブランチに積み上げ、本番(main)は未反映。大串が実機で確認しOKを出したら一括本番反映する運用。

完了タスク（詳細・全部preview・本番未反映）

  • 第1弾(トップ index.html): ローディングTERASUロゴSP縦中央／見出し読点削除／導入文・理由01-03・DEMOにSP改行＋文言(最大15ページまですべて月額1万円のみ／SEOや／つくる→作る)／CONTACT
  • 第2弾(about): mission文・制作会社以上・約束01-03・FAQ「制作について」の改行＋文言(HP→ホームページ/数百万→300万/企画・デザイン)。FAQは可視＋JSON-LD整合
  • 第3/4弾(about FAQ): 料金契約6/制作デザイン7/修正運用5/機能6/ドメイン3/解約2/制作の流れ をSP改行
  • CONTACT(TOP): 「左テキスト・右矢印密着」。矢印はabsolute(left:61%/top:50%)でテキスト直後。タイトル1.4rem/font12.5px/矢印52px
  • CONTACT全展開: 上記を11主要ページ(about/works/company/contact/privacy/guide×5/column一覧)に統一(sp-line-fixes注入＋body__txtにu-spbr改行)
  • 納期FAQ: 改行のみ(納期は2ヶ月維持・1ヶ月にしない＝①A判断・恒久ルール)
  • 約束01: 「初期10万・月額1万円」括弧追加＋改行調整
  • about FAQ 10項目 改行再調整＋ブログ文言「追加も運用に含まれます→追加まで運用します」(JSON-LD整合)
  • company(運用会社): イントロ＋代表メッセージの改行。イントロ文言短縮「中小企業のホームページ制作を→ホームページを」(※要確認)

編集ファイル（preview ブランチ）

  • index.html／about/index.html／company/index.html／works・contact・privacy・guide×5・column/index.html／_assets/theme/style.css（ローディングSP中央）

デプロイ・ブランチ

  • 全て preview ブランチに push。preview最新コミット e369761
  • 本番(main)未反映（main=689e309）。git checkout main && git merge preview && git push で fast-forward 一括反映
  • SP改行=t-sp-br(about/880px)・u-spbr(index/CONTACT展開/766px)。空行=二重br(SP時のみ)。全てSP専用＝PC不変(計測確認済)

試したこと・学び

  • CONTACT矢印密着が難航: flex bodyがテキスト幅に縮まず空白→矢印をabsolute固定＋タイトル小型化で3行クリーン化して解決
  • ローカルプレビュー launch.json "terasu-local"(8799)で preview MCP使用。viewportリセット/アニメ未発火の癖→eval計測＋強制reveal併用
  • Cloudflare Pages はデプロイ直後一時的500を返すことがある(伝播後200)。直後の500に騙されない
  • TOP「出会いを生むホームページを。」はHTMLでなく画像＝句点削除コード不可(②そのまま)

ユーザーFB（重要）

  • CONTACT「左に文字・右に矢印」、離れすぎNG→密着
  • 納期2ヶ月のまま(①A)・1ヶ月に戻さない
  • TOP出会いの句点は画像なのでそのまま(②)
  • プレビューリンクは毎回同じ(preview.scale-hp-showcase.pages.dev 固定・最新上書き)

注意ポイント・退化リスク

  • 本番未反映。本番反映は大串OK後に preview→main fast-forward
  • PC不変厳守(全変更@media SP限定)
  • コラム記事11本のCONTACTは別デザイン(オレンジ)で今回対象外
  • about の terasu-sp-fixes(Codex領域)と私の sp-line-fixes が共存

次のセッションで取り得る選択肢

  1. company イントロ文言の確認: 「中小企業のホームページ制作を→ホームページを」短縮のままでOKか／「中小企業」を残すか(大串判断)
  2. 全スマホ修正の本番反映: 大串OK → git checkout main && git merge preview && git push(fast-forward・約40秒で本番反映)
  3. コラム記事のCONTACTも統一する場合は別途(オレンジ→白カード化)

引き継ぎファイル

/tmp/handoff_20260625_145943.txt

16:36 - /handoff 実行（HackCamp HubSpotマニュアル IS拡張＋メールテンプレ）

対象システム

HackCamp HubSpotマニュアル（hackcamp-hubspot-manual）
- ローカル正本: ~/dev/hackcamp-hubspot-manual-source.html ＋ ~/dev/hackcamp-hubspot-manual-gen.py
- 出力: ~/dev/hackcamp-hubspot-manual/（gen.py実行で生成）
- 本番: https://hackcamp-hubspot-manual.pages.dev/（社内向けnoindex・直接prod OK）

セッション背景

前セッションでFS向けHubSpotマニュアル完成→今セッションでIS向け内容を追加。並行でHackCampの架電後/セミナーアンケートメールも作成。

完了タスク（詳細）

  • マニュアルをFS向け→共通/IS向け/FS向けの3ゾーンに再編（gen.py PAGESのグループ列・サイドバーゾーン見出し）
  • 6/15 Zoom録画「【HackCamp】Hubspotの使用方法」(44分・~/Documents/Zoom/2026-06-15...)をmlx-whisperで文字起こし(/tmp/hs_transcript/audio1627933903.txt)→IS業務を構造化
  • IS向け2ページ新設：「架電の進め方」(iscall)「メール・日程・報告」(isops)
  • 「アポ取得後の更新ルール」(apo)を共通ゾーンに配置（①〜⑥手順・スクショapo-1〜5配置済）
  • 「更新ルール」→「商談後の更新ルール」に改名
  • iscall詳細化：架電時の更新①架電日②メモ③NA育成④架電ステータス(最後)。apo④商談情報表・⑤warn強化。isops各cardに手順flow-list＋スクショ枠
  • ゾーン見出し：色分け→文字大きく(14px太字・色なし)
  • HackCamp_架電後メールテンプレ集作成(32_FS部署/)＝御礼/資料送付/不通フォロー/メール希望の4種＋共通ルール
  • セミナーアンケートメール：12名分を温度×状況で個別作成（守屋/坂井/横田/瀬野/梅澤/野崎/梅田/吉村/渡邉/根岸/坂根/戸島）
  • Couchbase出水様への日程変更返信

編集ファイル

  • ~/dev/hackcamp-hubspot-manual-source.html - 全セクション本体（apo/iscall/isops追加・厚く）
  • ~/dev/hackcamp-hubspot-manual-gen.py - PAGES 3ゾーン化・iscall/isops追加・SHORT
  • ~/dev/hackcamp-hubspot-manual/style.css - figure.shot・ゾーン見出し・余白
  • ~/Obsidian/SCALE-Brain/32_FS部署/HackCamp_架電後メールテンプレ集.md - 新規

デプロイ・バックアップ

  • 本番: 全10ページ HTTP 200・反映済み
  • backup: ~/hackcamp-hubspot-manual-backups/（毎回tar.gz）
  • changelog管理なし（このシステムはgen.py方式・changelog.tsなし）

試したこと・学び

  • mlx-whisper導入済み（~/Library/Python/3.9/bin/mlx_whisper）。今後も録画を文字起こし→マニュアル化できる
  • スクショ受け渡し＝大串が ~/Pictures/Screenshots/Hubspotマニュアル/ に格納→Claudeが ls -t→sips -Z 1400サムネ→Read識別→img/へ sips -Z 1600 配置
  • チャット添付画像は保存不可。上記フォルダ経由が確実
  • ツールエラー注意：Editを count/invoke 形式で書くとmalformed。必ず正しい関数呼び出し形式で

ユーザーFB（重要なやつ全部）

  • 架電ステータスは必ず最後に更新（Slack通知連動・他項目空欄で通知が飛ぶ）
  • ゾーン見出しは色だとごちゃつく→文字を大きくして区別
  • アポ取得後の更新ルールは共通ゾーン（IS抜きでアポ取る可能性あり）
  • ボリューム多いほど良い・どんどん厚く・極力スクショ付き（写真は空白枠で置く）
  • 【メール】既存導入済み(有料ユーザー)には日程打診しない（事故防止）／セミナー後メールは「本日」禁止→「先日/このたび」（送付が当日とは限らない）／姓と様の間に半角スペース／送付資料は左詰め箇条書き／件名は【要件】HackCamp大串形式

注意ポイント・退化リスク

  • 編集は必ず source.html → gen.py 実行（各HTML直接編集禁止＝上書きされる）
  • ~/Pictures/Screenshots/Hubspotマニュアル/ のスクショ運用を継続
  • 残スクショ枠＝iscall系4(date/memo/na/status)＋isops系3(mail/calendar/report)＝計7枠＋既存未配置(contact-detail/company-detail)

次のセッションで取り得る選択肢

  1. 残スクショ7枠を配置（大串がフォルダに入れたら識別配置→再デプロイ）
  2. iscallの「架電リスト(ビュー)」部分を録画から厚く（資料DL経由/セミナー参加・未視聴の違い、スクリプト使い分け）
  3. 共通ページ(contact/deal等)もさらに厚く・録画の細かい話を追加

引き継ぎファイル

/tmp/handoff_20260625_163652.txt