⚙️ Vault運用

2026-08-03_作業ログ

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

作業ログ 2026-08-03

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

本番 https://list.scale-group.co.jp/ ／ v1.0.61 ／ commit 210da33 ／退化チェック全項目クリア

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

ログインを一人ひとりのアカウントへ — システム作業 — 完了
管理画面7枚を実データ化 — システム作業 — 完了
SCALE CRM の架電リストへ直接インポート — システム作業 — 完了
死んでいたボタンを全部配線／参考データの残骸除去 — システム作業 — 完了
一覧の全項目表示・列の表示設定・列幅・表示件数 — システム作業 — 完了
絞り込みの作り直し（連絡先・除外・業界・所在地） — システム作業 — 完了
売上予測の精度の測り方の誤りを是正 — システム作業＋相談 — 完了
企業説明文の生成ロジック — システム作業 — 完了
充足率を100%に近づける仕組み — システム作業 — 進行中
全件スクショの受け皿づくり — 相談＋システム作業 — 一部完了

1. ログイン（大串指示で設計変更）

合言葉ひとつ → ユーザー管理に登録した人だけ入れる方式へ。

大串 y-ogushi@scale-group.co.jp / ●●●●●●（管理権限）
点検用 check@scale-group.co.jp（認証情報＝~/.scale_list_login）
PBKDF2-HMAC-SHA256 10万回・塩つき。平文は持たない。本番実測198ms
締め出し防止: 自分自身と最後の管理者は停止・削除・降格できない／台帳0人のときだけ環境変数の合言葉で入れる

2. 管理画面7枚

ダッシュボード（収録データ14項目）／ユーザー管理／企業ラベル／保存条件／リスト追加履歴／外部連携／コメント定型文。
企業詳細に社内コメント欄を新設。実体のない3画面（API・その他・拠点ラベル）は削除。

3. CRM の架電リストへ直接インポート

「リストに追加」→ 案件・セグメント・架電担当・件数 → 件数確認 → 実行。
本番のデモ案件で2件入れて確認し、後片付けまで実施。

事故防止4枚: 2段階確認／INSERTのみ／1回5,000件まで／同じ案件の既存は電話番号で除外。
入れると案件名と追加者がラベルとして自動で付く。CSVダウンロードは廃止（大串判断）。

4. 死んでいたボタン／参考データの残骸

参考の器のボタンは disabled のまま置かれていた（参考では行を選ぶと有効になる）。
全てクリア／保存／共有／検索条件設定／リストに追加／コメント一括登録が全部死んでいた。CSVもこれで押せなかった。

成果物に参考のデータが残っていた — ダミー企業262件・参考の収録件数1,964,248・伏せ字URL。
指紋チェックが色と社名しか見ていなかったのが原因。退化チェックに追加した。

5〜6. 一覧と絞り込み

列を「うちが持っている項目」で定義し直し20列を初期表示
歯車の表示設定（並べ替え・表示切替）＋列幅をつまんで変更。保存は user_prefs（アカウント別）
表示件数の切り替え（25/50/100/200）
大業界チェックで中業界が全部チェックされる仕様に
フリーワード実装（説明文・事業タグ・小業界が対象）
所在地に地方まとめ選択（3案・?region=a|b|c）
連絡先はラベル画面の器を流用していてラベル用UIが残っていた → 全部削除＋見出しを参考と同じ灰色帯に

7. 売上予測 — 精度の測り方が誤っていた

「的中74.2%」は業界を持つ会社だけの成績だった。
売上の実データを持つ会社は100%業界も持つため答え合わせが偏っていた。

	ぴったり	±1区分	対象
業界あり	73.6%	98.9%	13万社
業界なし	62.7%	98.0%	216万社

さらに 本番の sales_src が全件NULL で、229万件の推測売上が実測と同じ顔で出ていた（8/2の「明示した」が一度も動いていなかった）。修正済み。

9. 充足率を上げる仕組み

突合の取りこぼし回収（完了）
match_sites.py が prefecture IS NOT NULL でサイトを外していた。所在地が読めなくても
全国で1社しかない商号なら採用に変更 → 企業HP 255,971→290,515／電話 179,073→189,675

会社概要から4項目（進行中）
crawl_profile.py を新設（代表者・設立・資本金・事業内容）。

1回目は本番D1同期と同時に走らせて回線が詰まり、96%が「取得できず」で終わった。
--retry-failed を追加。ただし再試行しても残りの大半は繋がらないと実測で確認
（単独・時間をかけても 0/12。ドメイン切れ・証明書切れ・403 が実体）。

300社の試し（歩留まり39.7%）は上振れだった。contact_score の高い順＝サイトが生きている会社ばかりだったため。
全体では「取得できたサイトの約38%」が正しい見方。

現時点: 12,754社を巡回し 12,272社が取得成功。反映済みで資本金 8,339→12,721。

10. 全件スクショの受け皿

業界（4.6%）は手元のデータから推定できないと確定。
事業テキストがあって業界が無い会社は6件しかない。→ 業界はスクショでしか埋まらない。大串の「全件スクショを送る」判断は正しい。

apply_ocr.py に業界の抽出を追加（マスタに実在する名前だけ・長い名前から当てる）
売上の答え合わせが自分の推測値と突き合わせていた（47.8%と出て危うく取り込みを止めるところだった）。推測値を比較から外した

このセッションの大串FB

ユーザー管理でメアド＋PWを登録し、登録した人だけ入れる設計に
ラベルは手動で付ける機能は不要。CRMへ入れたら案件名と追加者が自動で付く
SalesNowのCSV方式ではなく、リストを選んでインポート→CRMの架電リストに入る設計に
CSVダウンロードは使わないので排除
反応しないボタンは全部機能させる
各社の項目は全部初期表示に
列の表示設定・列幅はそのアカウントにだけ反映
verを押しても変更履歴は見えなくていい
地方まとめ選択は別案をたくさん出して実物で選びたい
充足率が低いところは仕組みを整えて100%に近づける
今後全件スクショを送る（80時間かかってもよい）

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

位置や汎用クラスで消すときは必ず器を限定する。<div class="MuiBox-root を足場にして一番外側の箱ごと消し、業界の画面を真っ白にした（89KB→21KB）。与信スコアでも同じ失敗をしている
参考の1列目は sticky。複製すると全列が左端で重なる
値と出どころ（_src）はセットで本番へ送る。片方だけだと「明示している」つもりが効いていない
精度は実際に適用する母集団で測る。答え合わせに使えるデータが偏っていないか毎回疑う
自分が入れた推測値を、実測との答え合わせに使わない
デプロイ直後にページを開くと、ブラウザが古いJSを新しい ?v= のURLで1年キャッシュする。30秒ほど待ってから開く

12:00-13:00 - 引き継ぎ後の続き（未対応の消し込み）

本番 https://list.scale-group.co.jp/ ／ v1.0.67 ／ commit 5783c9a ／退化チェック全項目クリア

1. 絞り込みのチェックが中央からズレていた（完了）

前セッションで「実機で測れず未計測」としていた件。実際に左下へ寄っていた（実測で上に1px）。
原因は、白い✓を細長い四角の右と下だけに線を引いて45度回した図形で描いていたこと。
回転させた図形は外接四角の中心と見た目の重心が一致しない。
→ MUI標準のチェックアイコンの形に置き換え。24×24 の中で中央設計なので位置調整が消えた。

2. 地方まとめ選択 — 3案は捨て、一覧そのものを括りに分けた（完了・大串FB）

大串「下の都道府県のところに、ブロックごとに分けて大ブロックみたいなのをつけて、
関西だったら関西の県をその括りに入れる方がいい」。

3案を並べる前に、置き場所が間違っていた。 まとめ選択を一覧の上に置いていたので、
どの県がどの地方かは結局読み取れない。3案とも同じ誤りの上に乗っていた（どれを選んでも直らない）。
→ 47県の一覧を地方の括りに分け、見出し＝まとめ選択に。業界の「大業界を押すと中業界が全部つく」と同じ操作に統一。
選択途中は見出し右に「3/9」。?region=a|b|c は削除。

3. 企業名タブを削除（完了・大串FB）

大串「企業名のタブは使わないから削除でいいかも」。
サイドバー項目・画面生成・遷移先の3つを同時に外し、退化チェックに「復活していないこと」を追加
（固有の見出し「基本情報」で判定）。器は _reference/ に残っているので戻せる。

気づいた誤り（自己修正）

変更履歴とコード内コメントに 2026-08-04（未来の日付） を書いていた → 全て 08-03 に修正
check_deployment.sh の画面リストに /filter-name が残っていた。Pages は知らないパスに
トップを200で返すため、消したのに「OK」と出てしまう。リストから外し、/filter-contact を追加

残っている未対応

一覧の「ラベル情報」列を自前ラベル（案件名・追加者）に切り替えるか
→ 本番D1で確認したところ、自社ラベルは現時点で0件（labels 0 / company_labels 0 / list_history 0）。
CRMへ入れ始めてからでないと中身が出ない。大串の判断待ち

14:45 - /handoff 実行（全テーマ・引き継ぎ後の続き分）

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

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

#	テーマ	種別	状態
1	絞り込みのチェックが左下に寄っていた	システム	完了
2	所在地を地方の括りに（3案は廃止）	システム	完了
3	企業名タブを削除	システム	完了
4	一覧のラベル列を自社ラベルに／公的な印を列から外す	システム＋判断	完了
5	会社概要クロールの反映・本番同期・統計更新	データ	反映済（クロールは継続中）
6	スクショの業界照合73.7%の原因究明	調査＋システム	完了
7	連絡先のサイドバー選択印バグ	システム	完了
8	「読み込み中…」の書体	システム	完了
9	連絡先の画面を参考と同じ並びに	システム	完了
10	企業規模ページの不要項目削除（タブ5→2）	システム	完了
11	市区を出せるように	システム	完了
12	中業界が出なくなっていた（退化）	バグ修正	完了
13	一覧の見出しだけ50pxずれていた（退化）	バグ修正	完了

見つけた退化2件（どちらも過去の自分の変更が原因）

中業界が出ない — 8/3に業界画面を真っ白にした事故（89KB→21KB）のとき、
右ペインの器ごと落ちたまま戻っていなかった。器を探すだけの作りだったので、無いと黙って何もしない。
→ 無ければ作る形に（市区と同じ）。消す事故のあとは「消えすぎていないか」を画面で確かめる。

見出しだけ50px右にずれていた — 列幅をつまむ機能が見出しに position: relative を当てており、
参考CSSが固定列用に持つ left: 50px が効いていた。sticky のときは通常位置のままだが、relative にすると left が素直に効く。
データ側は relative にしていないため見出しだけずれた。→ left を打ち消した。
position を変えるときは、その要素が既に持っている left/top を必ず確かめる。

実測で分かったこと

公的な印: インボイス 2,485,327社（49.3%）／補助金 128,981（2.6%）／特許 134,285（2.7%）
→ 一覧の列としては情報量が薄い（大串の見立てどおり）。条件と企業詳細には残してある
市区: 99.8%（502万社） 保有。県と同じ精度で絞れる
企業規模ページ: 従業員数55.2% / 売上47.6% / 設立年月2.7% / 資本金0.3% は残す。
決算月・上場区分・移転情報・関係会社種別・グループ従業員数は列そのものが無い。
従業員数の増減率は過去の従業員数を持っていないので計算できない
スクショの業界照合73.7%の正体＝分類体系の違い（gbiz_jsic 13.2万＝日本標準産業分類 / salesnow 10.4万＝事業モデル）。
ZOZO・ベルーナは参考画面「IT/eコマース」対 JSIC「小売・販売・卸売」で、どちらも正しい

データの現在地（本番）

収録 5,036,034 ／電話 189,675 ／企業HP 290,515 ／資本金 14,897 ／代表者 141,832 ／
設立年月 133,895 ／業界 233,450 ／企業説明文 234,418

このセッションの大串FB

地方は3案から選ぶのではなくブロックごとに分けて大ブロック見出しを付ける
企業名のタブは使わないから削除
インボイス／補助金／特許の公的な印は一覧に要らない
連絡先の画面を参考と同じにして
企業規模の上部タブは使わないものが多い。出せない項目は要らない
市区が出ない仕様になってる。参考と合わせて
進捗が見えないと不安（「時間かかりすぎかも」）→ こまめに状況を報告する

自分のミス（記録）

changelog とコード内コメントに 2026-08-04（未来の日付） を書いた → 全て修正
コメントに大串の発言をそのまま引用し、成果物に参考システム名が残った → 退化チェックが検知 → 修正

15:29 - 中断中の作業を引き継ぎ用に記録（容量のため別セッションへ）

状況

昨日 2026-08-02 17:05 を最後に、走らせていたクロール2本がMacのスリープで停止していた。
済んだ分は site_identity に保存済みなので、続きから再開できる。

	停止位置
汎用JP	188,500 / 728,452	26%で停止
.or.jp	28,000 / 36,995	76%で停止
電話の取得	完了	66,942社・37,573件検出

本番: 企業HP 291,462 ／電話 189,695（手元と本番にズレなし）

次にやること（3つ・独立しているのでどれからでも可）

① 未突合の反映（クロール不要・すぐ効く・まずこれ）
社名は読めているのに未突合が 49,497件（うち都道府県も読めているもの 37,644件）。
match_sites.py --apply → verify_contacts.py --bare-too --apply → sync_to_d1.py で
新しくクロールしなくても企業HPが増える。

② 汎用JPのクロール再開（188,500/728,452 で停止）
③ .or.jp のクロール再開（28,000/36,995 で停止・残り30分ほど）

長時間まわすときは先に caffeinate -dimsu &。
前回これをやらずに2本とも落ちた。

置き場所

コマンド込みの手順は ~/dev/scale-list/CLAUDE.md の
「中断中の作業」（先頭近く）に書いた。別セッションはそこを見れば再開できる。

未コミットの差分について

functions/api/_query.js / web/app.js / web/filters.js と
scripts/sync_contacts_to_d1.py / db/d1_contacts/ に未コミットの差分があった。
別セッションの作業中のものと判断し、触っていない。

20:39 - 夕方の作業（SCALE LIST・本番 v1.0.86）

本番 https://list.scale-group.co.jp/ ／全項目を実機で検証ずみ。

オリジナル化（大串の基準で対応）

大串「オリジナル化はコードの順序や参考システムの名前が入ってなければいいよ」。

実測すると CSSの97.9%・企業詳細HTMLの75.3%が参考のまま残っており、
css-1cbuney のような Emotion が中身から作ったハッシュのクラス名が156個そのまま出ていた。

→ 697個を sl-0000 形式に一括置換（CSS・HTML・JSに同じ表を当てる。
ビルド最後に残存0を検証して、1つでも残っていたら止める）。

置き換えは一番最後に当てる。 ビルド途中の処理は参考のクラス名を
目印にしているので、先に置き換えると消し漏れる。

CSSの規則の並び順は変えていない。 変えると後勝ちの関係が崩れて表示が壊れる。

「持っていない」は数える前に言わない

8/3 昼に「メールの部署別・有効性確認済・FAX・SNS は1件も持っていない」と判断して
連絡先の項目を置かなかったが、誤りだった。取り込み済みの company_contacts に
入っていて、本番D1へ載せていなかっただけ。

種別	社数	種別	社数
FAX番号	66,220	代表メール	21,885
Facebook	1,306	広報	717
X	1,009	セールス	572

companies_master に列が無い＝持っていない、ではない。

速さ（実測で前後比較）

	前	後
件数（条件なし）	3,647ms	209ms
件数（都道府県）	867ms	44ms
件数（従業員区分）	4,286ms	51ms
絞り込み画面の切り替え	990ms	5〜19ms

件数は data_stats と facet_counts から数え置きを返す（refresh_facets.py で286行）
切り替えは サイドバーとパネルの器だけを差し替える（読み込み直さない）

「条件ではないパラメータ」を黒リストで書くと効かない。画面は ?v= のような
付随パラメータを付けるので、知らないパラメータが1つ付いた瞬間に速い経路が外れる。白リストで書く。

踏んだ罠（再発防止）

同じ塊が2つあり、片方は display:none。 1つ目で return すると
隠れている方を消して画面は変わらない。社名・説明文・移転履歴・事業タグで4回踏んだ。全部消す
消す器を1つ間違えると巻き込む。 企業情報・業界・事業タグ・本社住所移転履歴は
ひとつの箱に入っており、セクションの箱で消したら企業情報の表ごと消えた。
巻き込みたくないものを含む手前で止める
overflow:hidden の枠に足すと、はみ出した分が切られて何も見えなくなる
伏せ字を # に置き換えるのは無害化ではない。 # は自分自身を指すので、
<iframe src="#"> はページが自分自身を中に読み込む（詳細ページの「謎のゾーン」の正体）
デプロイ直後にページを開かない。 HTMLが新しい ?v= を指したのを確認しただけで
開くと、エッジがまだ古いJSを返している間にブラウザが新しいURLで古い中身を1年キャッシュする。
掴み直すには fetch(url, {cache:'reload'}) してからリロード。CLAUDE.md に書いてあるのに飛ばした
参考の保存物は「その時の状態」ごと固まっている。 行のチェックが
「チェック済みの図形」で焼き込まれており、外しても絵が変わらなかった
複製すると増えるものがある。 列を複製すると見出しの並び替え矢印も
IconButton として増えるので、「最後の IconButton」で歯車を拾うと矢印を掴む

データ（クロール）

クロールが途中で死ぬ真因はスリープではなく database is locked だった。
journal_mode=WAL でも書き込み同士はぶつかり、busy_timeout が無いと待たずに即死する。
4つのスクリプトに PRAGMA busy_timeout = 60000 を追加 → スリープを越えて生き残った
未突合の反映は増分ゼロ。残る49,497件は「同名が複数＝取り違える」17,900件と
「登記名でない」29,690件で、設計上わざと採らないもの。「クロール不要で増える」は誤りだった
.or.jp 完走（8,594件・所在地28.3%・電話5.2%）／汎用JP は 224,500/530,162 で継続中

大串の判断（この時間帯）

オリジナル化は「コードの順序と参考システム名が入っていなければよい」
企業詳細の値の文字は案1（18px / 700）に決定
削除: ラベルを編集／共有／Powered by AI／自動生成の注記／事業タグ／本社住所移転履歴／
連絡先情報タブ／この会社に付いている印／連絡先の充実度／コメント一括登録／ラベル一括編集／
企業検索タブ／本社所在地のフリーワード／検索窓のJCコード
「リストに追加」は参考の CSVダウンロードと同じ位置・同じ塗りボタンに
連絡先・除外は色以外は参考と全く同じに（＝白いカードの中に節を並べる）
見出しの並び替えは効く6列だけにして、残り14列からは矢印を消す

2026-08-04 午前 — 部署の直通番号・連絡先情報タブ・共通パスワード（v1.0.90）

部署・拠点の直通番号が取れた（新しい武器）

大串「参考の連絡先情報みたいに部署ごとの電話番号とかって取れない？これ取れたら超強い」。

crawl_divisions.py を新設し、企業HPのお問い合わせ・アクセス・拠点・会社概要から
「部署名＋電話番号」を読んだ。31.6万社を巡回して 18,817社 / 42,194組。
内訳は本社・支店営業所が主で、本社の受付を通さずに現場へ当たれるのが価値。

出し先も作った:
- 企業詳細に 「連絡先情報」タブを復元（8/3 に中身が空で消したものを、中身が取れたので戻した）
- 中身＝代表の連絡先＋部署・拠点の連絡先（tel: で押せる）
- 代表と同じ番号には「（代表と同じ）」と添える（かけ先を間違えないため）
- 絞り込みに 「部署・拠点の直通」 を追加

歩留まりは無作為300社で先に測る。 会社概要のとき「連絡先が多い順」で
選んで 39.7% と出したのは上振れだった。無作為だと 9.3%（本社を除くと 5.3%）。

区切りの無い数字を電話番号として採らない。
「古物営業法に基づく表示 01001605808」（公安委員会の許可番号）を電話として拾っていた。
許可番号は0から始まる11桁で電話と見分けが付かない。フリーダイヤルだけ例外。

パスワードを全員共通に（大串指示）

「理想は全員PWは一緒。●●●●●● で。メアド登録して、そのメアド＆●●●●●●で入れる」。
→ 登録はメアドだけでよくなり、一覧にも合言葉を出した。

ハッシュの形式を取り違えて、全員を締め出しかけた。
本番は hex なのに base64 で書いていた。ログインできることを確かめてから反映する。
（ログイン周りは「壊れても画面上は何も起きない」ので、確認を飛ばすと詰む）

共通パスワードは、辞めた人が出たら全員ぶん変えることになる。
環境変数 SCALE_LIST_SHARED_PASS●●●●●● で差し替えられるようにしてある。

データの現在地（本番）

	8/3朝	8/4
企業HP	290,515	348,154
電話番号	189,675	211,183
部署・拠点の直通	0	18,817社 / 42,194組

汎用JP（530,162件）・.or.jp（8,594件）ともクロール完走。

踏んだ罠（今日ぶん）

索引の名前はDB全体で1つしか使えない。 「別名で作って最後に入れ替える」方式で
入れ替え前に索引を作ると、2回目以降が必ず already exists で落ちる。
古い表を落とせば索引も消えるので、落として入れ替えてから作る。
なお止まり方は設計どおりで、本番のデータは前のまま欠けなかった
完了待ちのループが自分自身を検知して永久に待った。
pgrep -f <名前> は自分のコマンドラインにも一致する
画面の座標で要素を探すと関係ないものまで掴む（ヘッダーの通知・アカウントを消した）。
器を限定する。今日だけで3回踏んだ