2026-08-01_作業ログ
作業ログ 2026-08-01
SCALE LIST — 機能の取捨と画面の詰め
本番: https://list.scale-group.co.jp/ ／ リポ: ~/dev/scale-list
大串の決定
| 論点 | 決定 |
|---|---|
| データが無い項目（資金調達・財務・テクノロジー・拠点・部署人物） | 消さずに「データ未収録」と表示して残す |
| SCALEスコア | 削除 |
| 与信スコア | 不要（リストの企業は顧客の見込み客で、その支払い能力はSCALEのリスクではない） |
| 次にやること | 連絡先の充実度で並べ替え |
やったこと
1. 連絡先が多い順の並び替え（依頼分）
企業名順だと「あ」から始まる会社ばかり上に来て、架電できる会社が埋もれる。
電話・企業HP・メール・問い合わせフォームが何個そろっているか（0〜4）で並べ替え。
503万件を毎回数えるとD1が耐えないので contact_score 列＋索引を持たせた（計算3秒・索引17秒）。
分布: 4個 14,474 ／ 3個 45,469 ／ 2個 47,641 ／ 1個 41,911 ／ 0個 488万
2. 検索窓が上に8pxずれていた（大串指摘）
<form> にブラウザ既定の下マージン16pxが残り、箱が 32→48px になって
ヘッダー(56px)の中で中央に来ていなかった。参考システムはCSSリセットで消していたが、
保存したCSSにそのリセットが含まれていなかった。form { margin: 0 } で中央（y=28）に揃えた。
3. 左サイドバーが押せない（大串指摘）
押せなかったのはデータを持っていない項目だった（企業名・業界・所在地などは正常）。
決定どおり薄く表示して理由を出す形に。
「連絡先」は実データがあるので画面を新設（電話11.2万・HP13.5万・メール2.2万・フォーム6.3万）。
4. 右上の3アイコンにメニュー（大串指摘）
アプリ切替＝SCALEの各システムへのリンク／お知らせ＝収録件数／アカウント＝出どころ。
5. SCALEスコアを削除
上部のチップと「検索条件設定」内の点数スライダーの2箇所。
今日踏んだ罠
a. 伝播の確認を「変えていないもの」で判定していた
HTMLだけ変えた回に app.js のハッシュで伝播判定 → 古いHTMLでも一致して誤判定。
変えたものの中身で確認する（消した文字列が本番から消えたか）。
b. ブラウザが古いHTMLを掴み続ける
同じタブでクエリを変えても古いJSを読み続けた。新しいタブで開くと解決。
これで「実装したのに動かない」を30分以上追いかけた。
c. HTMLブロックの削除は <div> と </div> を数える
正規表現で切ると入れ子の途中で切れて画面が崩れる。削除後にタグ数の一致を必ず検証。
d. 例外1件で28万件の処理が全部止まる
サイト側のリンクに全角記号が混ざっていて urljoin が ValueError。
それが ThreadPoolExecutor の map から伝播してプロセスごと停止（23,000件で停止）。
1件ずつ try/except で囲む。
進行中
未使用 .co.jp 28万ドメインのクロール（残り約10時間）
サイトに書かれた商号＋本社所在地を読んで法人番号に突合する。
中間実測: 社名49%・所在地57%が読め、そのうち66.7%が1社に確定。
全件なら約8.8万社が新たに紐付く見込み（企業HP 13.5万 → 約22万・1.6倍）。
完了後: match_sites.py --apply → verify_contacts.py → sync_to_d1.py
未使用 .co.jp 28万件から企業を特定（完了・本番反映済み）
成果
| 前 | 後 | |
|---|---|---|
| 企業HPあり | 134,622 | 222,921（+88,299・1.66倍） |
| 電話番号あり | 112,106 | 141,844（+29,738・1.27倍） |
架電できる会社（本番実測）: 東京都 27,087 ／ IT 8,118 ／ 従業員20〜50人 46,519
やったこと
まだどの企業にも紐付いていない .co.jp を 281,471件クロールし、
サイトに書かれた商号と本社所在地を読んで法人番号に突合した。
- 社名が読めた 149,215（53.0%）／所在地 162,593（57.8%）／電話 47,483（16.9%）
- 商号が完全一致し都道府県も一致し 1社に絞れた 90,687件（69.6%） を採用
- 同名が複数当たった 16,500件は取り違えるので捨てた
ドメイン名から会社を推測する方式（match_domains.py）は15,672件しか当てられていなかった。
サイトを読んで突合する方式にして5.8倍になった。
電話番号の検証（サイト突合ぶん・30,728件）
| 件数 | 扱い | |
|---|---|---|
| 所在地と一致 | 28,583 (93.0%) | 採用 |
| フリーダイヤル/IP | 1,155 (3.8%) | 採用 |
| 所在地と食い違い | 350 (1.1%) | 消した |
| 存在しない局番 | 40 (0.1%) | 消した |
| 携帯番号 | 600 (2.0%) | 消した |
一致率93.0%。トップページから拾ったとき（68.6%）より大幅に高い。
会社概要のテーブルから「電話」ラベル付きで取っているぶん精度が高いということ。
取り方を変えると精度がここまで変わるのは今後の設計に効く知見。
一日の連絡先データの推移（7/31朝→8/1）
| 7/31朝 | 8/1 | |
|---|---|---|
| 電話番号 | 84,101 (1.7%) | 141,844 (2.8%) |
| 企業HP | 134,622 (2.7%) | 222,921 (4.4%) |
| 問い合わせフォーム | ほぼ無し | 62,884 |
次の伸びしろ
- 商号が一致せず当たらなかった 23,128件（屋号・ブランド名でサイトを出している会社）
- 同名が複数当たって捨てた 16,500件（住所の市区町村まで読めれば絞れる）
- 電話が載っていなかった残り（フォームのみの会社）
2026-08-02 追記 — 突合の精度を上げ直した
自分で入れたデータの誤りを見つけて取り消した
会社概要から住所が取れないとき、本文から都道府県名を1つ拾うようにしていた。
そこで 「都道府県をお選びください 北海道 青森県 …」というフォームの選択肢を拾い、
先頭の都道府県（多くは北海道）をその会社の所在地だと誤認していた。
該当1,349件。電話の市外局番で裏が取れた307件は残し、1,042件は紐付けごと取り消した。
以後、都道府県名が3つ以上並ぶ住所は「使えない住所」として突合に使わない。
入れたデータを後から疑って検証する工程を挟まないと、静かに誤りが積もる。
同名複数を市区町村で絞った
同じ県に同名の会社が複数あると取り違えるので捨てていた（16,500件）。
サイトに市区町村まで書いてあれば1社に決まるので、そこで絞った。
- 8,563件が追加で確定。確定率 69.6% → 76.2%
- それでも絞れない7,720件は引き続き捨てる
本番の現在地（2026-08-02）
| 7/31朝 | 8/2 | |
|---|---|---|
| 企業HP | 134,622 | 231,319（1.72倍） |
| 電話番号 | 84,101 | 145,591（1.73倍） |
| 問い合わせフォーム | ほぼ無し | 62,884 |
架電できる会社: 東京都 28,649 ／ IT 8,132 ／ 従業員20〜50人 46,880
SalesNow の過去CSVを1箇所に集約（大串指示）
~/Downloads/SalesNowリスト/（51ファイル・187MB）。
import_csv.py は新旧どちらの置き場所も見るようにした
（片方だけ見ていると次の取り込みが黙って0件になる）。
残る伸びしろ
- 商号が一致せず当たらない 22,830件（屋号・ブランド名でサイトを出している会社）
- 市区町村でも絞れない 7,720件
- 住所が都道府県だけしか読めなかった 69,969件（会社概要のテーブルを取り切れていない）