2026-08-12_作業ログ
作業ログ 2026-08-12
05:37 - /handoff 実行（全テーマ）
セッションは 2026-08-11 早朝〜08-12 早朝。SCALE LIST が主軸だが、
途中で SCALE CRM 連携の本番障害とユーザー権限の問い合わせが割り込んだ。
状態の正本は~/dev/scale-listの git log と リポ直下 CLAUDE.md。
ここには git に乗らない決定・FB・落とし穴を残す。
このセッションで扱ったテーマ（全部）
- SalesNow スクショ取り込み（IT大業界を制圧） — システム作業 — 10業界・37,632社 完了
- ** スクショの取りこぼし7,069社（44%）** — システム作業 — 救済＋自動照合まで完了
- 社名を読める表記に（979,610社） — システム作業 — 本番反映・実機確認済み
- ** CRM追加が失敗して見えた本番障害** — システム作業 — 真因を根治
- CRM のユーザー権限（喜多さんがデモ案件を選べない） — システム作業 — データ修正＋再発防止
- LinkedIn人物データの取得可否 — 調査・意思決定 — 打ち切り（無料では届かない）
- 部署データが少ない件 — 調査・意思決定 — HPからは限界と確定。SalesNowのタブ撮影待ち
- 夜間ガード（本番書き込みの時間制限） — システム作業 — 入れたが大串判断で停止
- 夜通し運転の体制 — システム作業 — 行列＋見張りを新設し、6業界を無人で完走
テーマ別の詳細
1. SalesNow スクショ取り込み — IT大業界10本・37,632社
大串が中業界を1本ずつ撮り、こちらが shot_to_data.sh で流す運用が固まった。
| 中業界 | 社数 | HP | 電話 | 代表者 | SNS | 部署 |
|---|---|---|---|---|---|---|
| Webアプリ・サービス運営 | 16,089 | 61.4% | 49.7% | 35.7% | 19.2% | 4.1% |
| 受託開発 | 11,841 | 92.8% | 78.5% | 39.5% | 15.4% | 4.1% |
| eコマース | 2,918 | 85.4% | 63.4% | 20.6% | 30.8% | 3.3% |
| Webマーケコンサル | 2,407 | 86.5% | 67.8% | 31.3% | 24.3% | 2.7% |
| ITインフラストラクチャー | 1,983 | 93.8% | 86.1% | 46.6% | 18.0% | 5.9% |
| ソフトウェア販売 | 806 | 88.1% | 72.3% | 24.3% | 16.6% | 3.6% |
| デジタル系コンテンツ | 720 | 85.8% | 61.2% | 26.8% | 24.7% | 2.5% |
| 情報セキュリティ | 390 | 85.6% | 76.4% | 40.5% | 25.4% | 5.4% |
| クラウド系/SaaS/ASP | 300 | 98.3% | 63.0% | 95.0% | 38.3% | 5.0% |
| スマホアプリ | 178 | 84.8% | 23.0% | 24.7% | 11.2% | 3.4% |
| 合計 | 37,632 | 78.2% | 63.9% | 36.1% | 19.4% | 4.0% |
実数: 架電できる 24,039社 / DMできる 7,297社 / 代表者名が分かる 13,574社
気づき
- eコマースだけ Instagram(548) が X を上回った。EC は Instagram 運用が本業に近く、DM営業の相性が良い
- クラウド系/SaaS/ASP は質が突出（HP 98.3%・代表者95.0%）。300社と小さいが精度は最高
- スマホアプリは電話23.0%と低い。架電向きではなくSNS経由が現実的
残り: その他IT（大串が 2026-08-12 に撮る予定）。撮ればIT大業界11本が完成。
2. スクショの44%を取りこぼしていた（最大の学び）
Webアプリで大串が18,011社撮ったのに、DBには 8,993社しか入っていなかった。
大串の「全部で約18000社だからね」の一言で発覚。こちらは取り込みログの
「◯◯社に入れました」を見て正常だと思っていた。
- スクショには法人番号が 17,973社ぶん写っていた＝撮影は完璧
- 真因は OCR の行の組み直し（生データは座標付きの文字断片で、1行にまとめる段で落ちる）
- 7,069社を
rescue_industry.pyで救済 → 9,021社 → 16,090社（達成率100.2%）
恒久対策: shot_to_data.sh に「1.5 取りこぼしを数えて救う」を挟み、
毎回「撮った数 vs 入った数」を突き合わせて達成率を出す。95%未満で警告。
→ 以後の6業界はすべて達成率100%超、取りこぼしゼロ。
学び — 処理が「成功」で終わっても、入るはずの数と入った数は別。
ログの成功メッセージは「落ちなかった」ことしか保証しない。
3. 社名を読める表記に（979,610社）
大串「冒頭にひし形マーク入っていたり、「」あったりするのなんで？ 正式表記でかかないと」。
数えたら3つの別々の理由が混ざっていて、直すべきは1つだけだった。
| 見た目 | 件数 | 正体 | 扱い |
|---|---|---|---|
| 全角英数字 | 889,279社 | 法人番号データは英数字を全角で持つ。スペースの違和感の正体 | 直す |
◆ |
64社 | JIS規格外の漢字（外字）の代替。元の字はデータに無い | 直せない |
「」 |
131社 | 登記上の正式名称（宗教法人「正德寺」など） | これが正しい |
〆 |
5社 | 屋号記号。実在する正式表記 | これが正しい |
A案（原本を残す）を採用。name_norm 列を新設し、画面とAPIだけが COALESCE(name_norm, name) を見る。
NFKC正規化は使わない（㈱→(株)、①→1 と変換しすぎる）。
原本と同じ行は NULL に戻す。全件持つと本番へ649MB・2,519ファイル（10時間コース）になった。
4. CRM追加の本番障害 — 真因は「存在しない変数」
テスターから Unexpected token '<', "<!DOCTYPE "... is not valid JSON の報告。
当初は「本番D1への書き込みと競合した」と見立てたが、誤診だった。
真因は import.js の最後の行の labelNames（どこにも定義していない）。
追加そのものは成功しているのに返事を組み立てる段で例外になり、
Worker ごと落ちて Cloudflare の HTML が返っていた。
HTMLしか返らないので原因に辿り着けなかった。
「例外をJSONで返す」改修を入れた瞬間に正体が見えた。握りつぶす作りはバグを隠す。
実害: 画面は失敗表示なのに 117件がCRMへ入っていた（二重登録は無し）。
直したこと（大串「そもそもタイミング被ったらエラー出るのがおかしい。仕組みでなんとかならないの？」）
- API: onRequestPost を try で包み何があってもJSONを返す
- 画面: postJson() で状態を見てから読み、JSONでなければ1.5秒→3秒と最大3回やり直す
- 二重登録: CRMへ書く前に exclusions（PRIMARY KEY）へ場所取り。DBが排他制御の役をする
5. CRM のユーザー権限（喜多さん）
「デモ案件が選べない」。原因は member_rows の projects に5案件が残っていたこと。
CRM側の表示は role === 'admin' ? '全案件' と役割だけで決めており、データを見ていない。
つまり CRM の設計では管理者にとって projects は意味を持たない。それを制限として
読んでいたのは SCALE LIST だけだった。
- 喜多さんの
projectsを空に（大串の許可を得てCRM本番データを1行修正・他13名は無変更） - 再発防止: SCALE LIST 側を CRM の考え方に合わせ、管理者は projects に関わらず全案件
6. LinkedIn人物データ — 打ち切り（大串判断）
大串「SalesNowがどうやってLinkedIn情報を取得しているか考えて、真似るのがいい」。
経路を全部潰した。
| 経路 | 結果 |
|---|---|
| LinkedIn を直接クロール | robots.txt が User-agent: * / Disallow: / で全面禁止 |
| 企業HPのリンク | 200社を実測して 0.0% |
| 会社ページから従業員 | 2人だけ。/people は302 |
| Common Crawl | LinkedInは入っていない（CCBotが許可されていない） |
| Bing RSS / DuckDuckGo | 日本語クエリが壊れる／202でボット判定 |
| 検索エンジンのインデックス | 技術的には完全に効く（実証済み）が有料 |
実証できたこと: site:linkedin.com/in "社名" でタイトルに氏名・役職・会社名が揃う。
酒井俊英 - 代表取締役 - 株式会社コムネットシステム（従業員100人の中小企業でも取れた）。
打ち切りの理由: Google Custom Search JSON API は 新規顧客に閉じられている
（公式に "This API is not available for new customers." と明記・2027-01-01 廃止）。
キーを発行して検証したが403。Braveは月1,000クエリ＋クレカ登録必須。
大串「無料だと枠少ないからやっぱりいいや」。
書いた sns_linkedin.py（精度13/13）は叩き先を差し替えるだけで動く状態で残してある。
7. 部署データが少ない件
大串「部署だいぶ少なくない？」「どの会社にも絶対部署は複数あるはず」「仕組みをもっと欲しい」。
実態: 43,114件のうち 54.6%が「本社」等の拠点。最多は「本社」6,127件。
大串が求めた「受付で止まらず担当直通」になっていない。
やったこと: 収集経路を1本→5本に増やし（フォームの選択肢・組織図・採用ページ・sitemap）、
判定精度を19/19まで締めた（三好カントリー倶楽部『北陸・中部』等の誤検出を潰した）。
結論: 新経路でも歩留まり1.2%。日本の中小企業HPには組織図が無く、
問い合わせフォームにも部署の選択肢がない（実測で4社中3社は接続すらできない）。
→ SalesNow の「部署データ」タブを撮るのが唯一の道。
途中で語尾に「支店・営業所」を足しかけたが、2026-08-07 に「拠点は対象外」と
決めた判断と矛盾するため撤回した。拠点を増やすと欲しい部署がさらに埋もれる。
8. 夜間ガード — 入れたが停止
CRM障害を「本番D1との競合」と誤診し、深夜0時〜朝6時のみ本番へ書く仕組みを入れた。
真因が別と判明し、リトライ等で落ちる筋を塞いだので、大串判断で既定オフ。
NIGHT_FROM = 0 にした瞬間、h >= 0 が常に真になりガードが全時間帯で素通りした。
日をまたぐ時間帯（21→8）用の式だった。日中に本番へ書き込んでしまった。
FROM < TO なら FROM <= h < TO を使う。全24時間で検証してから直した。
9. 夜通し運転の体制
業界ごとに「前の処理を待つ」ループを別々に nohup で起動したら、
全部まとめて死んで行列が止まっていた。 大串の「進んでるー？」で気づくまで数十分無駄にした。
run_queue.sh: 1本のプロセスで業界を順に流す。1業界落ちても次へ進むqueue_watchdog.sh: 5分おきに監視し、止まっていたら未処理業界から自動再開。
未処理の判定は「スクショの枚数×約16社」とDBの社数の突き合わせ（記録ファイルに頼らない）
→ 6業界を 02:16 に無人で完走。見張りは一度も出番なし。落ちた段ゼロ。
このセッション全体の大串FB（重要なやつ全部）
- 「許可なくどんどん進めて欲しい」 — 確立した段取りの続きは聞かずに実行する（恒久）
- 「中業界の全部入れたときの報告で各項目の充足率の表を出すルールにして欲しい」
→ 覚えておくのではなくスクリプトが最後に必ず出す形にした（恒久） - 「たくさん埋まっている会社の詳細ページリンクいくつか欲しいな」 → 報告に自動で付く
- 「Webアプリ・サービス運営の中業界、全部で約18000社だからね」 — この一言で44%の取りこぼしが発覚
- 「売上規模と大業界、従業員数は絶対に中業界数と一致するはず」 — 正しかった。全部100%に
- 「廃業カウントって本当に正当性あるんかな？ これミスあったら結構しんどいからね」
→ 検証して正当と確認（国税庁の登記閉鎖日）。ただし引き算での集計をやめ直接数えるよう修正 - 「そもそもタイミング被ったらエラー出るのがおかしいな。仕組みでなんとかならないの？」
- 「中業界のスクショとった報告したものからやっていくのが効率良さそう」 — 運用を切り替え
- 「無料だと枠少ないからやっぱりいいや」 — LinkedIn打ち切り
- 「夜通し進めておいてね。明日朝には完成させておきたいから」
技術的な学び（同じ道を二度歩かないため）
- macOS はファイル名を NFD（濁点を分解）で保存。日本語フォルダをシェルのグロブで探すと見つからない → Python で NFC に揃えて比較
/を含む中業界がある（クラウド系/SaaS/ASPサービス）。フォルダ名では:に化けるので、最初の:だけを区切りとし残りは/に戻す- D1 は同時に2つのインポートを受け付けない（
Cannot start another import） - Google Custom Search JSON API は新規顧客に閉じている（2027-01-01 廃止）
- エラーを握りつぶす作りはバグを隠す（HTMLを返していたせいで真因に辿り着けなかった）
db/*.sqlを一括除外していてスキーマ正本がgit管理外だった → 例外指定して追加- 待機ループは死ぬ。夜通しの処理は1本のプロセス＋見張りで組む
07:0x - 残骸プロセスの掃除（残タスク棚卸しの中で発見）
待機ループは「死んでいた」のではなく、永久に発火しないまま生きていた
上の「待機ループは死ぬ」は見立てが違っていた。朝に数えたら、昨夜の
while pgrep -f "shot_to_data.sh|research_fill.py" 形式の待機ループが
6本とも生きたまま残っていた（最長12時間16分）。
真因は pgrep -f が待機ループ自身の起動文字列にもマッチすること。
自分が生きている限り条件が真であり続けるので、待ち先が終わっても永久に発火しない。
「行列が止まった」ように見えて、プロセスは死んでいないので気づきにくい。
実害3つ:
- 抱えている caffeinate -dimsu が生き続け、Macが一晩中スリープしない
- 万一発火すると取り込み済みの業界を再実行する（6本とも完了済み業界だった）
- 前セッションのClaudeが起動した監視シェル2本も同じ形で残っていた
→ 待機ループ12本＋監視シェル2本＋queue_watchdog.sh を停止。caffeinate ゼロを確認。
→ 正本（~/dev/scale-list/CLAUDE.md）を修正し、pgrepで待ち合わせを書かない／
順番に流すのは run_queue.sh の役目／夜通し流したら翌朝 pgrep -fl で残骸を掃除、
を明記した（commit 4a44da0）。
学び — プロセスが「生きている」と「仕事をしている」は別。
pgrep で他プロセスを待つ仕組みは、書いた瞬間に自分を数えてしまう。
あわせて直した小さいこと
~/dev/scale-list の main に upstream 追跡が無く、git pull が素通りしていた
（「最新化したつもり」になる罠）。git branch --set-upstream-to=origin/main main で解消。
12:30 - /handoff 実行（全テーマ）
このセッションで扱ったテーマ（全部）
- 未来共創「師業・士業分科会」ページ制作（/hp-flow・クライアント用） — システム作業 — Step6改良ループ中・preview公開済み・本番未反映
- scale-brain リポの rebase 中断復旧 — システム作業 — 解決済み（main同期・push済み）
テーマ別の詳細
1. 師業・士業分科会ページ（メインテーマ）
- 参考HP: speelead.com（スピリード株式会社・WordPress）。/hp-flow v2.5 で Step1〜4完了（完全mirror→ダミー化→t-sb-接頭辞で全オリジナル化・確認①②大串承認済み）→ Step5流し込み → Step6改良ループで大量FB反映中
- 成果物の正本: ~/dev/client-miraikyousou（preview ブランチ）の
_preview/bunkakai/。preview URL: https://preview.client-miraikyousou.pages.dev/_preview/bunkakai/ - ビルドパイプライン: ~/dev/hp-speelead/（git管理外のローカル作業場）
- mirror.py→site/（完全mirror原本・不変）→ dummify.py→site_dummy/ → originalize.py→site_original/ → build_bunkakai.py→site_build/ → rsync→client-miraikyousou/_preview/bunkakai/ → commit+push（preview自動デプロイ約30-40秒）
- 修正は必ず build_bunkakai.py（+sbx_sections.py）を編集して再ビルド。site_build直編集はrsyncで消える
- 現在のページ構成: ヒーロー(タイトル/サブ/テキスト・モノクロ) → 得られること(5カラムアイコンカード) → この分科会について(左リーダーカード+右こんな分科会です+3ポイント・高さ揃え) → 活動内容(極太アンダーライン型・案22)+開催概要(2カラム・白背景) → メンバー紹介(横スク3カード) → こんな方におすすめ(マーカーハイライト型・案07・中央寄せ) → 参加するメリット(案13コーナーカットカード型・斜線帯あり) → 参加者の声(斜線帯なし) → FAQ(トップページ準拠details/summary・3問) → 流れ(番号+線アイコン+白パネル・下半分#1A1A1A) → 他の分科会を見る(カンプ3カード) → 共通CTA/フッター(site-footer.js)
- 開催レポート・活動実績セクションは削除済み(2026-08-12大串指示・仮の実績数字48回/320名/25件/1200名も撤去)
- メンバー紹介調整済み(2026-08-12): カード縮小で3枚見え（PC/タブ・swiper-slide幅=calc((100%-112px)/3)）・freeMode+mousewheel+grabCursorで自由スクロール（矢印ボタン残存）・詳しく見るを名前直下へ（margin .5em）
- 流れカードはstep全体白化（アイコン部分含む・.t-sbf-step{background:#fff}）
- 背景斜線の幅はPC27vw/SP58vw（原本ABOUT帯と同一・「もっと細く」FB反映）→ さらに山型∧配置（2本が上端中央の頂点で合流・X交差ではない・注入帯6+原本deco3ヶ所すべて同配置・2026-08-12「山の形」FB）
- 流れカードは内部余白も詰め済み（head高さauto・body min-height撤廃・アイコン→タイトル間圧縮）
- 他の分科会カードに実名投入済み: マーケティング分科会／AI活用分科会／セキュリティ分科会（紹介文はClaude起草=要事実確認・タグ月1回/オンライン等とリンク先は仮のまま）・タイトルにtext-wrap:balance
- 右固定サイドバー: コミュニティ概要/次回開催/エージェント登録の3カード・gains〜FAQ範囲・コンテンツと同スクロール(sticky解除済み)・PC1200px以上で右レール・帯背景はレール下まで全幅化
- FAQ背景は#1A1A1A（白系反転・2026-08-12）
- 配色: 白黒グレーの無彩色（2026-08-12大串指示）。背景斜線は全セクション配置のまま1セクション1本（45度）に統一済み（大串FB「多すぎる」=セクション数でなく1セクション内の本数の意。2本クロス→1本・原本deco3ヶ所のslash-2も非表示・opacity0.12・大串確認待ち）
- CTA統一済み(2026-08-12): ピル型4ヶ所（無料イベントに参加する/詳しく見る×3）をトップページver186のt-cta-style型（テキスト+下線+→・hoverでgap拡大）に統一。ダーク背景2セクションは白版。原本::afterのrotate90deg+矢印画像の無効化が必要だった（t-sb-cta-unifyスタイル）
- 参加するメリット差し替え済み(2026-08-12): 案13コーナーカットカード型（承認済み支給コード）。白背景のためborder:1px solid #e0e0e0追加（備考どおり）・タイトルにtext-wrap:balance（環/境孤立解消）・PC3列/タブ2列/SP1列確認済み
- Step7向けメモ: タブレット768/SP390でページ全体が右にはみ出す既存事象あり（メンバー紹介・参加者の声・メリット等の右端見切れ。今回の変更以前から・レスポンシブStep7で対処）
- 未確定・仮のもの: エージェント登録2ボタンのリンク先(#)／メンバー・リーダー写真(プレースホルダ)／実績数字(48回/320名/25件/1200名=仮)／参加者の声(仮)／FAQ回答(起草・要事実確認)／他の分科会カード(プレースホルダ文言・リンクvoid)／次回開催日の更新運用／最終設置URLパス未定
- 残ステップ: Step7レスポンシブ → Step8著作権監査 → Step9 Lab還元 → Step10 QA → Step11本番公開(承認必須) → Step12公開後SEO
- 技術学習(learning.mdにも記録): palt字幅マッチングダミー／aspect-ratioタイルのgrid最小幅爆発はminmax(0,1fr)／display:noneのbrがChromeで1文字行を作る／ブラウザペイン0×0・スクロール後compositor固着→headless Chrome+DOM実測で検証／レール帯はmargin-right:-372px+padding-right:372pxの階層連鎖で全幅化
2. scale-brain rebase復旧
- detached HEAD+rebase-merge残骸 → rebase --abort → Daily衝突(2026-08-10)を両取りマージ → main同期・push済み
このセッション全体の大串FB（重要なやつ全部）
- ページ配色は白・黒・グレー（無彩色）
- タイトルは日本語のみ・英語表記なし・左右斜線(/ /)は維持
- サイドバー: 右固定→範囲はgains〜FAQ→最終的に「コンテンツと同スクロールで常時表示」(tall-sticky)→※最後は同スクロールに変更
- デザイン差し替えは承認済みカンプのコードをそのまま使う運用（勝手なデザイン考案不要）
- 背景の点と線(パーティクル)は削除・斜め帯は全セクションに
17:07 - /handoff 実行（全テーマ）
本番 https://crm.scale-group.co.jp/ ／ v11.6.98 ／ ⚠ 未コミット29ファイル（最新commitは f2cebc9 = v11.6.78。v11.6.79〜98はデプロイ済みだが未コミット）
このセッションで扱ったテーマ（全部）
- 画面の整理（ナレッジ集・設定・ユーザー管理・案件管理・セグメント管理・オンライン状況） — システム作業 — 完了
- 5画面のアーカイブ（MTG/パートナーオンボーディング/案件横断ダッシュ/契約情報/ダッシュボード） — システム作業 — 完了
- 開始までのスケジュールが空だった問題 — バグ根治 — 完了（データ救出済み）
- 権限と稼働の分離（PM権限チェック廃止） — 設計変更 — 完了
- SCALEランク基準の刷新（商談実施率80%・全5単価） — 分析＋実装 — 完了
- ランク基準の取り残し防止（正本1つ＋デプロイ時チェック） — 根治 — 完了
- Slack定時通知3本（週次/パートナー別/記入もれ） — システム作業 — 完了・テスト送信済み
- 稼働時間の計測ルール4条 — 設計＋実装 — 完了
- 個人ダッシュ×成果管理の統合（案1タブ切替） — システム作業 — 完了
- 架電ナレッジのロジック変更 — システム作業 — 完了
- アポ音声の自動保存（Zoom→Drive→CRM） — 新機能 — 作業途中
テーマ別の詳細
11. アポ音声の自動保存（このセッションの最大テーマ・作業途中）
目的: 「Zoomphoneで録音を探す→Driveに入れる→リンクを貼る」を全自動化し、ナレッジが勝手に溜まる体制にする
構成（3回の壁を越えて確定した形）:
Zoom(録音完了) → Cloudflare Worker(scale-lead-voice) → D1のvoice_queueに保存待ち
→ Apps Script(5分おきに取りに来る) → Zoomから音声DL → Driveへ保存 → Workerへ結果通知
→ call_rowsのaudioUrlを更新 → アポ獲得リストの音声列に🎧
なぜこの形か（重要な経緯）:
- 当初はサービスアカウント鍵でDrive APIを叩く設計 → 組織ポリシー iam.disableServiceAccountKeyCreation で鍵が作れず断念
- 次にWorkerからApps Scriptを叩く設計 → Workspaceが「組織外からウェブアプリを呼ぶ」のを禁止しており403
- 最終的に「Apps Scriptが取りに行く」向きに逆転させて回避（外から叩かないので制限に当たらない）
設定済み:
- Zoomアプリ SCALE CRM Voice Sync（既存を再利用・Activated）／webhook検証Validated済み
- イベント: Call recording is completed + Caller call log is completed
- Worker Secret登録済み: ZOOM_SECRET●●●●●● / ZOOM_ACCOUNT_ID / ZOOM_CLIENT_ID / ZOOM_CLIENT_SECRET / GAS_SECRET
- Apps Script デプロイ済み・5分トリガー設定済み・権限承認済み
- CRM側: アポ獲得リストに音声列（audioUrl）／案件編集に「アポ取得音声フォルダ」（driveFolderId）
未完（次の一歩）:
1. 大串が各案件の「アポ取得音声」フォルダを作成 → CRMに登録（RYSは 1W6HzE51gCgE5dJArbtbI2qcJZJiheCGv が既存）
2. 1案件だけ空撃ちで確認 → 5月まで遡って一括取り込み（/backfill?from=&to=&dry=0）
3. ENABLE_UPLOAD=true にして本稼働
実測データ: Zoomに録音が5月〜現在で約3,600件残存（7月1,948件・6月838件・5月777件）。7月分の空撃ちでアポ獲得行と23件一致（フォルダ未登録のため全部スキップ＝安全に停止中）
踏んだ地雷:
- 電話番号の照合で「末尾9桁」だけを見ると、市外局番の桁数が違う番号（075-213-0001等）で別の会社に誤って当たる。先頭の+81と0を正規化してから比べること（normTel修正済み）
- call_rowsの主キーは row_id ではなく call_id
- Apps ScriptのSECRET: ●●●●●●
5-6. SCALEランク基準の刷新と取り残し防止
- 商談実施率 90%→80%、単価23,000円(税抜)で計算し時給は税込25,300ベースで表示
- 全5単価に展開（時給ラインを揃えAPIを逆算）。全25セルを機械検算・担当者通電あたりアポ率は全単価で単調増加
- 取り残しがあった: Slackのパートナー成果報告だけ旧基準のままだった（基準を2箇所に持っていたため）
- → 正本を lib/pagecore_targets.js の1つに固定し、scripts/sync-rank-basis.js が Worker用JSONを生成。deploy.sh が一致をチェックしてズレたら止まる
8. 稼働時間の計測ルール（大串GO）
実データで116件中22件しか稼働時間が入っておらず、中身も「押してすぐ止めた」「16時間の止め忘れ」ばかりだった。以下4条を実装:
1. タイマーが動いている間はその時間を稼働にする（タイマーが正）
2. タイマーが止まっている間の架電操作は、その間隔を稼働に足す（押し忘れケア・30分以上の間隔は除外）
3. タイマーが動いたまま30分以上操作が無ければ、最後の操作時刻で締める（止め忘れ対策）
4. 中断後に架電を再開したら、押し直さなくても計測が戻る（自動再開）
※ 稼働0.5h未満で率を出さない案は大串が却下（再架電だけの日もあるため）。1時間未満は「◯分」表示
7. Slack定時通知3本（投稿先 C0BP7468T43 = pm部署_scalelead）
- 週次報告（木7:00）／パートナー別 成果報告（木7:10）／記入もれ（毎朝8:00）
- 形式: 親メッセージ=タイトルのみ、スレッド内の先頭に @大串 @喜多
- 除外ルール: アーカイブ/終了 + テスト用フラグ(デモ案件) + 商品区分=自社商品(TERASU)
- テスト送信済み・本稼働ON
このセッション全体の大串FB
- 説明文・件数表示・使い方ガイドの類は基本いらない（とことん削る）
- 色は減らす。注意すべき所だけに使う
- 数値は必ず検算してから入れる
- ランク基準を変えたら関連する全部が一緒に変わるようにする
- 自社商品(TERASU)は数値報告に含めない
- パスワードは全員 ●●●●●● で統一（欄自体を消す）
- アポ音声はアポが取れた会社の「最初の架電から最後まで」全部入れる
- ファイル名は 2026-08-12_株式会社ABC_喜多.mp3 形式
19:05 - アポ音声の自動保存 本稼働＋誤爆の根治（続き）
本番 https://crm.scale-group.co.jp/ ／ voice Worker = scale-lead-voice ／ 保存済み 37件・エラー0
やったこと
- 過去分の一括取り込み（5/1〜8/12）を実行 → 37件保存（RYS/結G/結G_エアコン/チャネルワークス/カロンジ）
ENABLE_UPLOAD=trueにして新着も本稼働（本番 /health で実測）- 大串の指摘から誤爆を2件根治（下記）
踏んだ地雷（同じ道を辿らないため）
- Zoomの録音一覧は1回で30日分しか返らない（エラーにならず黙って一部だけ返す）。
5/1〜8/12を一度に投げると1,333件、月ごとに割ると3,599件。→ Worker側で30日ずつ自動分割（splitRange）。 - 電話番号だけで照合すると案件をまたいで誤爆する。株式会社Ａrpが「結グループ(SNS)」と
「結グループ_エアコン」の両方のリストに存在（SNS=6/10失注／エアコン=7/24アポ獲得）。
SNSの6/10録音がエアコンのアポ音声として保存された。
→ 同じ番号が複数案件にある時は「録音日に最も近い架電日を持つ案件」を選び、アポ行でなければ保存しない。 - 取次で番号が変わると本題の会話が丸ごと取れない。Ａrpは本社(043-222-2424)に44秒→店舗直通
(043-306-2887 = Arphy千葉)へ3分35秒＋2分35秒。店舗番号はCRMに無いので拾えなかった。
→ アポ通話の後30分以内に、同じ人がCRM未登録番号へかけた通話は取次とみなして同じ会社に保存。
途中で別の登録番号に架電したら打ち切り（隣の会社を巻き込まない）。過去分で5件該当。 - 「音声が44秒で途切れる」は途切れではない。Zoom側の録音実尺が44秒（他は31/48/85/96/493秒とバラバラ）。
短いのは取次だけが録れていたため。→ 3の対策で本体が入るようになった。
残っている宿題
- 誤爆1件のDrive削除は大串の手作業待ち（エアコン/株式会社Ａｒｐ/2026-06-10_…mp3）
- 「同じ番号が複数案件にあり日付でも決められない」録音が35件、保留（保存しない）のまま
- CRMの音声列は1行1リンクのみ。企業フォルダのリンクに変える案は保留（大串判断待ち）
- workers/voice 一式はまだ未コミット（29ファイルの未コミットと同様、大串の判断待ち）
20:45 - 追加: 毎朝の追いかけ取り込み（大串GO・これで完成）
- 紐づけのきっかけは「アポ獲得になった時」ではなく「Zoomの録音が終わった時」。
Zoomは全通話を録音していて、録音完了のたびにWorkerがCRMを見に行き、
その時点でアポ獲得の行と番号が一致した分だけ保存する（全通話は保存しない）。
→ 夕方まとめて入力すると録音通知は過ぎていて拾えない、という穴があった。 - 対策: 定時実行ハブ(scale-lead-scheduled)に 毎朝6:00 JST(=21:00 UTC "0 21 * * *") で
直近3日ぶんを取り込み直すvoice_backfillを追加。二重保存はrecording_idで弾く。
vars: JOB_VOICE_BACKFILL/VOICE_URL/VOICE_DAYS、Secret: ●●●●●●(=音声WorkerのGAS_SECRET)。
手動実行/run?job=voice_backfill&dry=1（X-Run-Tokenヘッダ必要）。 - 音声列は企業フォルダのリンクに統一（12行を貼り替え済み・以後は保存時に自動）。
Apps Scriptにフォルダリンクを送る()を追加（過去分の貼り替え用・普段は不要）。 - 大串チェック済み・OK。「音声の入れる体制バッチリ」との評価。
- 参考: 8月の架電は 8/2(3本)/8/3(14本)/8/4(19本) で止まっている（8/5以降は架電なし）。
12:30 - /handoff 実行（全テーマ）
このセッションで扱ったテーマ（全部）
- 未来共創「師業・士業分科会」ページ制作（/hp-flow・クライアント用） — システム作業 — Step6改良ループ中・preview公開済み・本番未反映
- scale-brain リポの rebase 中断復旧 — システム作業 — 解決済み（main同期・push済み）
テーマ別の詳細
1. 師業・士業分科会ページ（メインテーマ）
- 参考HP: speelead.com（スピリード株式会社・WordPress）。/hp-flow v2.5 で Step1〜4完了（完全mirror→ダミー化→t-sb-接頭辞で全オリジナル化・確認①②大串承認済み）→ Step5流し込み → Step6改良ループで大量FB反映中
- 成果物の正本: ~/dev/client-miraikyousou（preview ブランチ）の
_preview/bunkakai/。preview URL: https://preview.client-miraikyousou.pages.dev/_preview/bunkakai/ - ビルドパイプライン: ~/dev/hp-speelead/（git管理外のローカル作業場）
- mirror.py→site/（完全mirror原本・不変）→ dummify.py→site_dummy/ → originalize.py→site_original/ → build_bunkakai.py→site_build/ → rsync→client-miraikyousou/_preview/bunkakai/ → commit+push（preview自動デプロイ約30-40秒）
- 修正は必ず build_bunkakai.py（+sbx_sections.py）を編集して再ビルド。site_build直編集はrsyncで消える
- 現在のページ構成: ヒーロー(タイトル/サブ/テキスト・モノクロ) → 得られること(5カラムアイコンカード) → この分科会について(左リーダーカード+右こんな分科会です+3ポイント・高さ揃え) → 活動内容(極太アンダーライン型・案22)+開催概要(2カラム・白背景) → メンバー紹介(横スク3カード) → こんな方におすすめ(マーカーハイライト型・案07・中央寄せ) → 参加するメリット(案13コーナーカットカード型・斜線帯あり) → 参加者の声(斜線帯なし) → FAQ(トップページ準拠details/summary・3問) → 流れ(番号+線アイコン+白パネル・下半分#1A1A1A) → 他の分科会を見る(カンプ3カード) → 共通CTA/フッター(site-footer.js)
- 開催レポート・活動実績セクションは削除済み(2026-08-12大串指示・仮の実績数字48回/320名/25件/1200名も撤去)
- メンバー紹介調整済み(2026-08-12): カード縮小で3枚見え（PC/タブ・swiper-slide幅=calc((100%-112px)/3)）・freeMode+mousewheel+grabCursorで自由スクロール（矢印ボタン残存）・詳しく見るを名前直下へ（margin .5em）
- 流れカードはstep全体白化（アイコン部分含む・.t-sbf-step{background:#fff}）
- 背景斜線の幅はPC27vw/SP58vw（原本ABOUT帯と同一・「もっと細く」FB反映）→ さらに山型∧配置（2本が上端中央の頂点で合流・X交差ではない・注入帯6+原本deco3ヶ所すべて同配置・2026-08-12「山の形」FB）
- 流れカードは内部余白も詰め済み（head高さauto・body min-height撤廃・アイコン→タイトル間圧縮）
- 他の分科会カードに実名投入済み: マーケティング分科会／AI活用分科会／セキュリティ分科会（紹介文はClaude起草=要事実確認・タグ月1回/オンライン等とリンク先は仮のまま）・タイトルにtext-wrap:balance
- 右固定サイドバー: コミュニティ概要/次回開催/エージェント登録の3カード・gains〜FAQ範囲・コンテンツと同スクロール(sticky解除済み)・PC1200px以上で右レール・帯背景はレール下まで全幅化
- FAQ背景は#1A1A1A（白系反転・2026-08-12）
- 主な活動内容は案09チェックアイコン型に差し替え（20案ギャラリー
_preview/katsudo-an/から大串選定・旧案22アンダーライン撤去・2026-08-13） - ヘッダーにロゴ横ラベル「師業・士業分科会」（※大串指示は「士業・師業」だったがページ内表記に合わせた・ヘッダーinnerは3カラムgridなのでロゴとラッパー化必須・2026-08-13）
- サイドバーはsticky+単独スクロール（max-height:calc(100vh-105px)+overflow-y:auto・「サイドバーだけでスクロール」FB・2026-08-13）
- メンバーカードは5枚（01堀弘/02渡邉遼太郎/03-05プレースホルダ・3枚見え+freeModeスクロール・画像はmerit-img06まで在庫・2026-08-13）
- 最終CTAは分科会専用バナー（明朝2行コピー+白ボタン「分科会に参加する」→/event/+枠ボタン「お問い合わせ」→/contact/（2026-08-13変更。 本番miraikyoso.jpの/contactは404=トップの既存リンクも404・preview環境は200・Step11本番公開時に要解決）・右に画像PHフェード・紺/オレンジ参考を無彩色適応・共通site-footer.jsが挿入する
.mkctaをこのページだけCSS非表示（クラスはmk-cta2でなくmkcta・#site-footerの兄弟に挿入される）・2026-08-13） - ヒーロー背景は明PH画像+左黒→右透過グラデ（hero-slide画像を明PHに強制再生成・ラベル右寄り・2026-08-13）
- タイトル斜線は全セクション見出しに統一（メンバー紹介仕様=clamp(26,2.4vw,38)/斜線.85em/2px/30deg・gains__ttl/tfaq__h/ttl-03/subtitleを揃えた・2026-08-13）
- フォントはトップページ準拠に統一（和文=Helvetica Neue+ヒラギノ系ゴシック/欧文数字=t-display・Zen Old Mincho全撤去・--t-sb-font-primaryのJostも置換・2026-08-13）
- 詳しく見るは名前直下ぴったりに（ttl-05 margin-bottom .35em+btn margin0・2026-08-13）
- ヘッダーの分科会名はナビリンク化（未来共創コミュニティとはの右隣・href="./"でこのページへ・ドロワーにも追加・ロゴ横ラベルは廃止・2026-08-13）
- 得られること5カラムは拡大済み（アイコンclamp(64,6vw,92)/見出しclamp(13.5,1.2vw,19)/本文clamp(13,1.05vw,16)・2026-08-13）
- 主な活動内容ブロックはPCで右へシフト（padding-left clamp(24,5vw,72)・2026-08-13）
- 関連インタビューセクション新設（メンバー紹介の実HTML複製・流れ〜他の分科会の間・id=t-sb-interviews・カードはPH=記事は大串選定待ち・専用Swiper(.t-sbiv)・bg-main+t-sbx-secラッパーでダーク帯とレール全幅を再現・2026-08-13）
- FAQは最終CTA直上へ移動（並び: …流れ→関連インタビュー→他の分科会→FAQ→最終CTA→フッター・2026-08-13）
- フッターに分科会グループ追加（コンテンツ列に「分科会」+子リンク「師業・士業分科会」→/_preview/bunkakai/・共通site-footer.js編集=v187・bak取得済み・ 本番URL決定時にリンク差し替え必須・2026-08-13）
- FV/最終CTAは実画像に差し替え済み（大串支給の生成画像・正本=hp-speelead/src_images/。ビルドはPH一括生成の後にsrc_imagesから実画像を配置する順序・hero-slide01系は同命名で全サイズcover生成・最終CTA=assets/media/finalcta-bunkakai.jpg・2026-08-13）
- 2026-08-13 FB6点反映済み: CTA〜スライドバー間隔+48px（members/interviews）／インタビューカードの番号・黒三角削除／他の分科会カードコンパクト化+SUBCOMMITTEE英字削除／メリット背景#1A1A1A（見出し白・border撤去・レール全幅=.t-sb-body #t-sb-meritに-372pxルール追加が必要だった）／インタビュー背景#F5F5F5（文字黒反転・見出しはttl-01直指定が必要）／最終CTA画像44%→60%+フェード浅く
- 2026-08-13 FB続き: 得られること横幅max-width:110rem/幅94%に拡大／最終CTA縦padding clamp(72,8vw,120)／活動内容・開催概要の斜線を.85em+gap.5emに統一（base固定1remが原因だった）／全セクションタイトル左寄せ（gains__ttl/tfaq__h/おすすめのtxt-ctrをflex-start/left化）／関連インタビュー〜他の分科会の余白圧縮（両側paddingをclamp(20,2.5vw,36)に）
- 2026-08-13 微調整: 他の分科会の上余白は復元（圧縮しすぎFB）・インタビュー下のみ軽圧縮(clamp32-56)／こんな方におすすめタイトルだけ中央（他は左寄せ）／最終CTAフェード最小化で画像3/5比率
- 2026-08-13 微調整続き: 他の分科会カードは中間サイズに再拡大（padding34/32・ttl22px）／FAQ〜最終CTA間にclamp(20-40px)の白余白
- 2026-08-13: 関連インタビュー下余白をclamp(10-20px)に再縮小／山型帯の共通背景化は一度実装→大串「やっぱり元に戻して」で撤回済み（othersは個別帯・個別背景に復元）
- 参加者の声は案08大型センタースライダー型に差し替え済み（2026-08-13承認・支給コードそのまま・t-sbvs-スコープ・5秒自動送りループ/矢印・ドット手動+タイマーリセット/ホバー停止/grid重ね置きで高さ固定・素のJSを